Menü

Fallstudie: Beseitigung von Wasserfallfehlern und agilen Entwicklungsprozessen mithilfe eines Hybridmodells

  • Haupt
  • Agiles Testen
  • Fallstudie: Beseitigung von Wasserfallfehlern und agilen Entwicklungsprozessen mithilfe eines Hybridmodells

case study how eliminate flaws waterfall

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Agiles Wasserfall-Hybridmodell

Das Wasserfallmodell war die ideale Wahl für die Softwareentwicklung. In diesem Modell wird eine Idee zu einer verwendbaren Software in einem sequentiellen Prozess, der die Phasen Initiierung, Analyse, Implementierung, Test und Wartung durchläuft.

Das Wasserfallmodell hat jedoch einige Nachteile.

Die agile Softwareentwicklung wurde entwickelt, um die Probleme des Wasserfallmodells zu beseitigen. Es hat einen völlig neuen Rahmen. Während das Wasserfallmodell ein sequentielles Design hat, folgte das Agile-Modell einem inkrementellen Ansatz.

Als Kunden, die früher dem Waterfall-Modell folgten, zu Agile wechselten, brachte der Übergang viele Probleme mit sich. Der Grund dafür ist die Unanpassbarkeit an einen anderen Ansatz für die Softwareentwicklung. Das Endprodukt stellte sich als Katastrophe heraus.

Agiles Wasserfall-Hybridmodell

Daher wurde eine neue Methodik entwickelt, die als „Hybrid“ bezeichnet werden kann, um ein robustes Endprodukt zu gewährleisten, indem die Vorteile der Modelle Agile und Waterfall ausgewählt werden.

Lassen Sie uns zuerst die Entwicklungsmodelle 'Wasserfall' und 'Agil' kennenlernen und dann zum 'Agilen Wasserfall-Hybridmodell' mit den jeweiligen Vor- und Nachteilen übergehen.

Was du lernen wirst:

Wasserfall-Modell

Das Wasserfallmodell ist ein Ansatz zur Entwicklung von Software, die ein Projekt in endliche Phasen unterteilt. Man sollte erst dann zur nächsten Phase übergehen, wenn die vorhergehende Phase überprüft und verifiziert wurde.

Im Wasserfallmodell überlappen sich die Phasen nicht.

=> Lesen Sie hier mehr über das Wasserfallmodell.

Abbildung 1 zeigt das Wasserfallmodell:

Wasserfall-Modell

Vorteile des Wasserfallmodells:

  • Einfach und leicht zu verstehen und zu verwenden.
  • Starres Modell - Jede Phase verfügt über spezifische Ergebnisse und Überprüfungsprozesse.
  • Dokumentation und Artefakte sorgfältig gepflegt.
  • Geeignet für Projekte, bei denen die Anforderungen gut verstanden werden.

Nachteile des Wasserfallmodells:

  • Nicht geeignet für Projekte, bei denen sich die Anforderungen ändern können.
  • Die Kosten für die Behebung von Fehlern sind sehr hoch, wenn sie zu einem späteren Zeitpunkt erkannt werden.
  • Kein gutes Modell für komplexe und lange Projekte.
  • Bis spät im Lebenszyklus wird keine funktionierende Software erstellt.

Agiles Modell

Wikipedia definiert das agile Modell als 'eine Gruppe von Softwareentwicklungsmethoden, die auf iterativer und inkrementeller Entwicklung basieren und bei denen sich Anforderungen und Lösungen durch die Zusammenarbeit zwischen selbstorganisierenden, funktionsübergreifenden Teams entwickeln.'

Das Modell hat seine eigenen Prinzipien, die dazu neigen, die Prozesse in den Hintergrund zu rücken.

=> Weitere Artikel zur agilen Methodik finden Sie hier.

(Klicken Sie auf das Bild, um es vergrößert anzuzeigen.)

Agiles Modell

Vorteile des Agile-Modells:

  • Kundenbeteiligung am Prozess.
  • Ein hoher ROI als funktionierende Software wird häufig geliefert.
  • Selbst späte Änderungen der Anforderungen können problemlos berücksichtigt werden.
  • Kontinuierliche Verbesserung von Produkt und Prozess.

Nachteile des agilen Modells:

  • Fehlende Betonung auf Design und Dokumentation.
  • Das Team sollte stabil und kompetent sein.

Kollaboratives (Hybrid-) Modell

Das kollaborative Modell zielt darauf ab, beide Modelle zu kombinieren - Waterfall und Agile. Die Nutzung des Waterfall- und des Agile-Ansatzes sichert den Erfolg des Projekts. Es beseitigt die Nachteile beider Modelle; und gleichzeitig die Vorteile beider zusammenführen.

Das kollaborative Modell kann in einem Projekt implementiert werden, indem Folgendes ausgeführt wird:

Kollaboratives (Hybrid-) Modell

Das kollaborative Modell kann also wie folgt schematisch dargestellt werden:

b Baum und b + Baum

Kollaboratives (Hybrid-) Modell 2

Vorteile des Hybridmodells

  • Kombiniert die Vorteile von Agile- und Waterfall-Prozessen.
  • High-Level-Design ist darauf vorbereitet, Wasserfallprinzipien anzuwenden.
  • Das Codieren und Testen erfolgt nach einer agilen Methodik.

Agiles Wasserfall-Hybridmodell - Lernen Sie anhand eines Beispiels -Eine Fallstudie

Das Softwareunternehmen 'ABC Software Service' bietet Dienstleistungen für einen Kunden an, eine Universität namens 'XYZ University', um seine Software zu entwickeln, zu testen und zu warten (Live-Produktionsunterstützung).

Die Hauptfunktionen des Kontos sind:

  1. ABC Software Services muss die Anwendungen der XYZ University aktualisieren. Die Datenbank muss aktualisiert werden und alle Anwendungen müssen auf die neueste auf dem Markt verfügbare Technologie umgestellt werden.
  2. Bisher wurden alle von ABC Software bearbeiteten Projekte im Waterfall-Modell ausgeführt.
  3. Zwei der Anwendungen mit hohem Datenverkehr und hoher Priorität sollten jetzt neu entwickelt werden. Die erste ist 'Online-Anmeldungen', die zweite 'Online-Prüfungen'.
  4. Der Kunde XYZ University wollte nun, dass diese Anwendungen mithilfe des agilen Modells der Softwareentwicklung bearbeitet werden.

Das erste Projekt in einem agilen Modell für ABC Software waren Online-Registrierungen. Nach der Durchführung dieses Projekts wurde in einer Reihe von Rückblicken festgestellt, dass die folgenden Prozesse viele Mängel aufwiesen.

Diese Mängel wurden bei der Durchführung des zweiten Projekts „Online-Prüfungen“ behoben und daher im Hybridmodell ausgeführt.

So beseitigen Sie Fehler in Wasserfällen und agilen Entwicklungsprozessen mithilfe eines Hybridmodells:

Lassen Sie uns diese nacheinander ausführlich besprechen.

# 1. Keine Dokumentation:

Eines der agilen Prinzipien im agilen Manifest besagt: Agile gibt „Arbeitssoftware über umfassende Dokumentation“ mehr Wert. Nach Ansicht der agilen Methodik sollte die Dokumentation „gerade noch gut genug“ sein, und es wird mehr Wert darauf gelegt, eine funktionierende Software auszuliefern. Bei der Dokumentation werden keine großen Anstrengungen unternommen, aber für Konten wie die XYZ University, die über ein engagiertes Support-Team verfügen, um Fehler zu beheben, die bei Live-Projekten festgestellt wurden, kann sich diese Gewohnheit als Hindernis erweisen, wenn wir sie langfristig analysieren.

Im Laufe der Jahre, als Projekte im Wasserfallmodell ausgeführt wurden, wurden Dokumente gepflegt und aktualisiert, damit das Support-Team sie verstehen und entsprechend arbeiten konnte. Lösungsdesign, technisches Design, exemplarische Dokumente usw. waren einige der vorbereiteten Dokumente. Nachdem das Projekt beendet war, wurde dasselbe an das Support-Team übertragen.

Im Fall des Projekts „Online-Registrierungen“ wurden jedoch keine derartigen Dokumente erstellt, was sich als kostspielig erwies. Als das Projekt live ging, wurden viele Tickets von Endbenutzern gesammelt und das Support-Team hatte keine Ahnung, wie es daran arbeiten sollte. Das Team hatte kein Dokument zum Nachschlagen.

Dies war eine wichtige Lektion, und für das nächste Projekt wurden Dokumente zu „Online-Prüfungen“ geschrieben und effektiv übertragen.

=> Lesen Sie hier mehr darüber, warum Dokumentation wichtig ist.

#zwei. Keine UAT / End-to-End-Tests:

Im agilen Modus der Softwareentwicklung erhalten Tester die Builds, um sie schrittweise zu testen. Diese Builds werden so lange integriert, bis der endgültige Build vollständig erstellt ist. Tester testen die in jedem Sprint abgedeckten Anforderungen und führen weiterhin Regressionstests des Builds durch, der sich immer wieder summiert.

Nachdem alle Sprints abgeschlossen sind und der endgültige Build fertig und vollständig integriert ist, sollte der Tester das gesamte System testen und End-to-End-Tests durchführen. Dies sollte in einer völlig neuen Umgebung erfolgen.

=> End-to-End-Tests für ein Live-Projekt.

Dies hat seine eigenen Vorteile:

  • Das gesamte System wird in einer neuen Umgebung bereitgestellt und der Tester testet den gesamten Ablauf.
  • Dies schafft Vertrauen, da der Build letztendlich als Ganzes in einer Live-Umgebung bereitgestellt werden muss.

Wenn das Online-Registrierungsprojekt getestet wurde, wurde es in der Testumgebung durchgeführt. Nachdem das System alle Fehler getestet und erneut getestet hatte, wurde es für die Abmeldung deklariert. Im Idealfall wurde dies nicht für einen weiteren Zyklus von Systemtests in eine andere Umgebung befördert. (Im Idealfall, UAT erfolgt nach Systemtests In diesem Fall waren die Mitglieder des UAT-Teams jedoch am ersten Testzyklus beteiligt, sodass kein zweiter Zyklus geplant war.

Zu Beginn des Online-Prüfungsprojekts wurde SIT (System Integration Testing) durchgeführt und der Code in eine UAT-Umgebung befördert, in der der zweite Testzyklus durchgeführt wurde. Ergebnis: Alle Fehler mit hoher Priorität wurden erfasst und behoben. Der Build war vor der Go-Live-Veröffentlichung stabil.

#3. Kein Scrum Master:

Das Scrum Master ist dafür verantwortlich, dass ein Team nach den Werten und Praktiken von Scrum lebt. Der Scrum Master gilt als Trainer für das Team, indem er dem Team hilft, die bestmögliche Arbeit zu leisten. Der Scrum Master kann auch als Prozessverantwortlicher für das Team.

Das Online-Registrierungsteam wurde ohne Scrum Master gebildet. Die Wichtigkeit eines engagierten Scrum Masters wurde nicht als wichtig angesehen. Dies führte dazu, dass viele Probleme nicht rechtzeitig gelöst wurden und die Zeit für die Fertigstellung des Projekts häufig die Frist überschritt.

Ein engagierter Scrum Master war jedoch am Online-Prüfungsprojekt beteiligt. Die Projektprobleme und -herausforderungen wurden vom Scrum Master behandelt. Die Projekt- / Sprintberichte wurden erstellt und das Team konnte ihre Fortschritte sehen.

Außerdem fanden für jeden Sprint ordnungsgemäße Sprint-Planungsmeetings und Sprint-Retrospektiv-Meetings statt, die die Leistung des Teams verbesserten. Das Team konzentrierte sich nur auf seine Arbeit und erledigte die für diesen Sprint zugewiesenen Aufgaben. Alle zusätzlichen Reinigungsarbeiten wurden vom Scrum Master durchgeführt.

# 4. Konvertieren von Projektdokumenten in das Product Backlog:

Die ersten Projektdokumente, die in einem Wasserfallmodell erstellt werden, sind Business Requirements Specification (BRS), High-Level-Design, Functional Design usw. Diese Dokumente müssen in ein Product Backlog umgewandelt werden, um die Codierungs-, Test- und Implementierungsphasen auszuführen im agilen Modus. Dies ist ein sehr wichtiger Schritt.

Der Product Backlog ist der Ausgangspunkt eines agilen Projekts. Das Product Backlog ist eine priorisierte Liste von Anforderungen, die für ein Produkt verwaltet werden. Es besteht aus Funktionen, Fehlerkorrekturen, nicht funktionalen Anforderungen usw. Es ist ein wachsendes Dokument, das aufgrund von Kundenfeedback, sich ändernden Anforderungen usw. größer und besser wird.

Als erstes Artefakt eines Projekts ist es am wichtigsten, die Anforderungen aufzulisten und ihnen Prioritäten zuzuweisen. Die Konvertierung von Wasserfallprojektdokumenten in Produktrückstände ist eine große Aufgabe für sich und erfordert ein Brainstorming des gesamten Teams zusammen mit dem Kunden / Stakeholder.

Sobald alle Anforderungen aufgelistet und vom Kunden vereinbart wurden, besteht die nächste Aufgabe darin, sie zu priorisieren, um sie in Sprints aufzunehmen.

# 5. Rückverfolgbarkeitsmatrix:

Ein weiteres wichtiges Artefakt, das normalerweise im Wasserfallmodell beibehalten wird, ist die Rückverfolgbarkeitsmatrix. Um sicherzustellen, dass keine Anforderungen übersehen werden; Eine Rückverfolgbarkeitsmatrix sollte ebenfalls entworfen und gepflegt werden . Normalerweise wird in Agile keine solche Matrix entworfen.

Dies ist eine bewährte Methode für jedes Projekt. Parallel zum Produktstau sollte eine Rückverfolgbarkeitsmatrix erstellt werden. Und es sollte mit den Testfällen verglichen werden, die während des Benutzerakzeptanztests / End-to-End-Tests ausgeführt wurden (diese Phase wird in meinem nächsten Punkt erläutert). Selbst wenn eine Anforderung übersehen wird, kann sie auch in späten Entwicklungsstadien problemlos integriert werden, da Agilität diese zusätzliche Flexibilität und Anpassungsfähigkeit bietet.

Nachdem das Online-Registrierungsprojekt online gegangen war, wurde auf die Anwendung von den Endbenutzern (Studenten, die sich registrieren wollten) zugegriffen. Sie hatten viele Probleme mit der Anwendung. Dies führte dazu, dass viele Tickets für das Produktionssupport-Team gesammelt wurden. Erhöhte Tickets können als Vorfälle, Probleme oder Änderungen klassifiziert werden. Viele Probleme wurden behoben, da davon ausgegangen wurde, dass die Anwendung stabil wird. Aber selbst dann waren in den nachfolgenden Releases mehr als ein Dutzend Änderungsanforderungen / Verbesserungen geplant. Diese Verbesserungen sollten die Anwendung stabilisieren und die Endbenutzererfahrung verbessern.

Letztendlich sind die Kosten des Projekts um ein Vielfaches gestiegen. Wenn ein Projekt nicht ordnungsgemäß auf Agile umgestellt wird, kann dies zu einem Überschwingen des Budgets führen. Dies ist sehr wichtig, um einen gründlichen Übergang eines Projekts zu Agile zu planen. Außerdem sollte die Planung in dem Umfang erfolgen, den das Projekt benötigt, um im agilen Modus ausgeführt zu werden. Richtige Hybridmodelle sollten für ein bestimmtes Projekt entworfen werden.

Vor dem Start des Exam Entry-Projekts wurde dieser Aspekt gut berücksichtigt. Es wurde an ein Hybridmodell gedacht, und es wurde beschlossen, die Anforderungsanalysephase und die Entwurfsphase auf hoher Ebene im Wasserfallmodell und die restlichen Phasen in einem agilen Modell auszuführen.

Das angenommene Hybridmodell kann wie folgt bildlich dargestellt werden:

Kollaboratives (Hybrid-) Modell 3

Fazit:

Es ist offensichtlich, dass sowohl das Wasserfallmodell als auch das agile Modell ihre eigenen Nachteile haben. Es ist also ziemlich realistisch, sich für ein Hybridmodell zu entscheiden, bei dem es sich um einen Ansatz handelt das Beste aus beiden Welten nutzen.

Der wichtigste Aspekt beim Start eines Projekts ist die Entscheidung über das Modell, das das Team übernehmen wird. Dies erfordert eine umfangreiche Planung. Faktoren wie Budget, Zeit, Ressourcennutzung, Komplexität der Anforderungen usw. sollten bei der Übernahme eines Softwaremodells berücksichtigt werden.

Das Hybrid-Modell befindet sich noch im Anfangsstadium. Da immer mehr Unternehmen es übernehmen werden, werden wir mehr über dieses Konzept erfahren.

Das Agile Manifest fordert uns auf, Folgendes zu schätzen:

  • Individuen und Interaktionen über Prozesse und Werkzeuge
  • Arbeitssoftware über umfassende Dokumentation
  • Kundenzusammenarbeit über Vertragsverhandlungen
  • Auf Veränderungen reagieren über einen Plan folgen

Während das Hybridmodell diese 100% nicht einhält. Es legt nahe, dass alle Aspekte gleich wichtig sind. Es liegt an den Kunden / Projektmanagern, zu entscheiden, welche Aspekte mehr wert und welche wertlos sind.

Über den Autor: Dies ist ein Gastartikel von Harshpal Singh. Er verfügt über mehr als 7 Jahre Erfahrung in manuellen, Datenbank-, Automatisierungs- und Leistungstests und arbeitet derzeit als Teamleiter in einem führenden MNC. Er hat an vielen QS-Projekten nach den Entwicklungsmodellen Waterfall, Agile und Hybrid gearbeitet.

Haben Sie Erfahrung mit diesem hybriden Entwicklungs- und Testmodell? Lassen Sie uns in Kommentaren diskutieren.

Literatur-Empfehlungen

^