So verwenden Sie nTask für das Wasserfall-Projektmanagement – ​​Ein praktischer Leitfaden für Einsteiger

Veröffentlicht: 2019-08-09

Wir haben eine umfassende Analyse verschiedener Faktoren durchgeführt, die das Wasserfall-Projektmanagement beeinflussen. Dies hat uns geholfen, die Verwendung der nTask-Projektmanagementsoftware zur Lösung solcher Probleme zu vereinfachen. Wasserfall ist ein beliebtes SDLC-Projektmanagementmodell.

Es ist jedoch an verschiedenen Stellen kompliziert. Dieser Artikel beschreibt, wie Sie nTask verwenden können, um mit maximaler Produktivität in Bezug auf alle Ihre wasserfallorientierten Geschäftsmodelle auszukommen. Wir sind einen Schritt weiter gegangen, um verschiedene reale Anwendungsfälle und Beispiele zu veranschaulichen, in denen Wasserfall implementiert ist, und wie man nTask verwenden kann, um diesen Prozess weiter zu vereinfachen – und so weiter und so weiter.

Was müssen Sie über Wasserfall-Projektmanagement wissen?

Wasserfall Projektmanagement

Die Wasserfallmethode ist die traditionelle und am häufigsten verwendete Methode für das Projektmanagement. Es folgt einem sequentiellen, linearen Prozess, weshalb es oft als „linear-sequentielles Lebenszyklusmodell“ bezeichnet wird. Wie der Name schon sagt, konzentriert sich Waterfall auf die Planung des Lebenszyklus des Projekts, indem das Projekt in unverwechselbare, separate und exklusive Teile unterteilt wird: In einem Wasserfallmodell muss jede Phase abgeschlossen sein, bevor die nächste Phase beginnen kann.

Der Abschluss jedes einzelnen Schrittes in der Wasserfall-Methodik führt wie ein echter Wasserfall zur nächsten Phase des Projekts. Sobald ein Segment des Projekts abgeschlossen ist, können keine weiteren Änderungen daran vorgenommen werden und es kann auch kein Schritt übersprungen werden, um den nächsten abzuschließen. Jede Stufe ist somit abhängig von der Vollendung der vorhergehenden Schritte oder Ebenen. Dies macht das Wasserfallmodell am nützlichsten für kleinere Projekte mit klar definierten Anforderungen und weniger Unsicherheiten. Seine Einfachheit und einfache Implementierung hat es zur beliebtesten Version des Systems Development Life Cycle (SDLC) für Softwareentwicklungs- und IT-Projekte gemacht.

Bei der Verwendung des Wasserfallmodells liegt der Schwerpunkt darauf, sicherzustellen, dass die Anforderungen und das Design den Anforderungen des Projekts entsprechen, bevor zu den späteren Phasen der Entwicklung übergegangen wird.

Hintergrund des Wasserfall-Projektmanagements

Quelle – Codeacademy.com

Der Ursprung des Wasserfallmodells wird oft der Fertigungs- und Bauindustrie zugeschrieben. Die Wasserfallmethode war ideal für diese Branchen, da sie einem stark strukturierten Produktionsprozess folgen: Anforderungen werden in der Anfangsphase des Prozesses klar formuliert und umrissen, und die restlichen Phasen werden auf der Grundlage der Anforderungen entwickelt. Genau wie bei der Wasserfallmethode sind spätere Änderungen in jeder Phase des Projektmanagementzyklus nicht nur zu kostspielig, sondern in einigen Fällen unmöglich.

Dr. Winston W. Royce, der oft, aber fälschlicherweise als „Vater von Waterfall“ bezeichnet wird, wird mit der ersten formalen Beschreibung des Prozesses in einem Artikel akkreditiert, den er 1970 schrieb. Was Dr. Royce beschrieb, war ein fehlerhaftes Modell für die Softwareentwicklung, wie er es tat argumentierten für ein Modell mit mehreren Iterationen oder Läufen. Er argumentierte, dass ohne mehrere Iterationen des Projekts, wobei die erste ein Prototyp wäre, das Projekt zu riskant wäre und sogar zum Scheitern einladen würde. Seiner Meinung nach war die Prototyp-Iteration wesentlich, um die Anforderungen und Technologien des Projekts besser zu verstehen und sicherzustellen, dass das Endprodukt die Anforderungen des Kunden erfüllt.

Zusätzliche Lektüre:

Die 7 wichtigsten Funktionen, auf die Sie in Ihren kostenlosen Projektmanagement-Tools achten sollten

Während Dr. Royce die erste bekannte Beschreibung des Prozesses zugeschrieben wird, wird die erste bekannte Präsentation Herbert D. Benington zugeschrieben. Am 29. Juni 1956 hielt Herbert D. Benington auf dem Symposium über fortschrittliche Programmiermethoden für digitale Computer eine Präsentation über die Entwicklung von Software für SAGE. In seinem Vortrag beschrieb er den Einsatz solcher Phasen im Software Engineering. Dennoch wurde der Begriff „Wasserfall“ nicht verwendet, um den Prozess zu beschreiben.

Laut Wikipedia waren Bell und Thayer die ersten, die den Begriff „Wasserfall“ in einem Artikel von 1976 verwendeten.

In den 1980er Jahren wurde das Wasserfallmodell wegen seiner starren Natur heftig kritisiert.

Aufgrund der sich ändernden Bedürfnisse der Softwareentwicklungsbranche und des Versagens der Linearität des Wasserfallmodells bei der Bereitstellung von frühem Feedback sind viele Versionen des Wasserfallmodells entstanden. Diese Versionen werden oft gemeinsam als modifizierte Wasserfallmodelle bezeichnet.

Das modernere Wasserfallmodell hat Rückkopplungsschleifen in die vorherigen Phasen, um Änderungen zu ermöglichen. Andere Versionen des Wasserfallmodells sind das „Sashimi-Modell“ von Peter DeGrace (Wasserfall mit überlappenden Phasen), das V-Modell oder das gebogene Wasserfallmodell usw.

Die Wasserfall-Methodik und ihre Entwicklung – Das traditionelle Wasserfall-Modell

So verbessern Sie die Produktivität von Remote-Teams

Seit den 1970er Jahren verwenden Unternehmen und Projekte die Wasserfallmethode für das Projektmanagement. Die Verwendung eines einfachen Flussdiagramms, das bei Punkt A begann und aufeinanderfolgenden Schritten folgte, um sein Ende zu erreichen, war nicht nur leicht zu verstehen, sondern auch leicht zu implementieren. Die Phasen der Wasserfall-Methodik wurden von Dr. Royce entwickelt, um kostspielige Überarbeitungen im letzten Teil des Projektentwicklungszyklus zu vermeiden. Dr. Royce versuchte zu erklären, wie das Wasserfallmodell seiner Erfahrung nach mit dem Risiko des Scheiterns verbunden ist.

In Royces ursprünglichem Wasserfallmodell skizzierte er diese Phasen, um die Bedeutung dieser Schritte für große und komplexe Softwareentwicklungsprojekte hervorzuheben. Er wollte auch darauf hinweisen, dass, da die Schritte unterschiedlich geplant und ausgeführt werden, die beste Nutzung der Ressourcen erfordert, dass das Team Personen umfasst, die diese Schritte am besten ausführen können.

Typische Stadien eines Wasserfallmodells

Die verschiedenen Phasen des Wasserfallmodells können je nach Projektrahmen und Anforderungen modifiziert, eliminiert oder erweitert werden.

Die aufeinanderfolgenden Schritte in einem typischen Wasserfallmodell sind wie folgt:

  1. Konzeption : In dieser Phase keimt die Idee für das Projekt. Diese Phase beinhaltet eine grobe Bewertung des Prozesses, z. B. ist das Projekt von Vorteil, welche Kosten wären damit verbunden usw.
  2. Initiierung : Nach der Konzeption wird das Projekt initiiert, indem ein Projektteam eingestellt wird, Ziele, Umfang, Zweck und Ergebnisse definiert werden. Diese Phase ist entscheidend, da das Wasserfallmodell betont, dass die Anforderungen und das Design den Anforderungen des Projekts entsprechen.
  3. Anforderungserfassung und -analyse : Alle möglichen Projektanforderungen werden vom Team gesammelt und analysiert, um die Durchführbarkeit des Projekts zu prüfen. Dies kann auch erfordern, dass das Team das Geschäftsmodell des Kunden versteht und die mit dem Projekt verbundenen potenziellen Risiken analysiert. Alle in dieser Phase erstellten Informationen werden anschließend in einem Pflichtenheft dokumentiert.
  4. Design : In dieser Phase wird die Anforderungsspezifikation untersucht, bewertet und das Systemdesign für den Abschluss des Projekts vorbereitet. Hardware- und Softwareanforderungen werden identifiziert und die Gesamtsystemarchitektur wird definiert. Die in dieser Phase gemachten Designvorgaben werden in der Codierungsphase verwendet.
  5. Implementierung/Codierung : Dies ist die Phase, in der die Entwicklung/Codierung gemäß der Designspezifikation tatsächlich beginnt. Der Projektmanager delegiert Aufgaben unter Teammitgliedern, die normalerweise aus Programmierern, Schnittstellendesignern und anderen Spezialisten bestehen, und verwendet Tools wie Compiler, Debugger, Interpreter und Medieneditoren. Abhängig von der Art des Projekts und der Teamgröße wird das Team in kleinere Einheiten aufgeteilt.
  6. In den meisten Fällen wird das System zunächst in kleinen Programmen, sogenannten Units, entwickelt und in die nächste Phase integriert. Während jede Einheit entwickelt wird, wird sie auf ihre Funktionalität getestet, was als Einheitentest bezeichnet wird. Das endgültige Ergebnis dieses Schritts können eine oder mehrere Produktkomponenten sein, die gemäß einem vordefinierten Codierungsstandard erstellt und fehlerbeseitigt, getestet und integriert werden, um die Anforderungen der Systemarchitektur zu erfüllen. Unabhängig von der Teamgröße sind Zusammenarbeit und Koordination entscheidend, um sicherzustellen, dass alle Anforderungen erfüllt werden.
  7. Testen : Sobald alle entwickelten Einheiten integriert sind, wird das gesamte entwickelte System auf Fehler getestet. In dieser Phase wird auch die Einhaltung der Kundenerwartungen überprüft.
  8. Bereitstellung : Nach Abschluss aller Tests wird das Produkt oder der Prozess an den Kunden geliefert, auf den Markt gebracht oder implementiert. Dabei sind alle gängigen branchenspezifischen Richtlinien, Vorschriften und/oder Organisationsrichtlinien strikt einzuhalten. Darüber hinaus müssen Verifizierungen und Tests nach der Implementierung durchgeführt werden, um den Erfolg der endgültigen Implementierung zu bestätigen.
  9. Wartung : Falls vom Endbenutzer Probleme festgestellt werden, muss das Entwicklungsteam das Produkt beheben, ändern oder modifizieren, um seine Wirksamkeit sicherzustellen. Der Wartungszeitraum gilt in der Regel für einen bestimmten und zuvor vereinbarten Zeitraum.

Diagramm 2: Prinzipielle Darstellung eines typischen Wasserfallmodells für die Softwareentwicklung

Wasserfall Projektmanagement

Popularität des Wasserfall-PM-Modells

Warum hat das Wasserfallmodell trotz Dr. Royces Versuch, die Menschen vor den Fallstricken des Modells zu warnen, eine so allgegenwärtige Popularität erlangt?

Die Wasserfallmethode ist die am häufigsten verwendete Methode für das Projektmanagement. Dieses Modell wurde in verschiedenen Branchen eingesetzt, noch bevor es den Namen „Wasserfall“ erhielt. Die Hauptgründe für die Popularität und weite Verbreitung des Wasserfallmodells sind folgende:

  • Einfach zu verstehen, zu verwenden und zu verwalten

Die meisten Projektmanager finden die Struktur des Wasserfallmodells einfach zu verstehen und umzusetzen, da es dem Lebenszyklus eines Projekts folgt. Außerdem muss das Team nicht geschult und mit der Wasserfall-Methodik vertraut gemacht werden. Die Starrheit des gesamten Prozesses macht ihn nicht nur einfach zu implementieren und zu kontrollieren, sondern reduziert auch die Belastung des Projektmanagements.

  • Diszipliniert

Der klar strukturierte Ansatz des Wasserfallmodells erleichtert die Überwachung und am Ende jeder Phase können der Projektmanager und der Kunde sichtbare Fortschritte sehen. Da für die Anforderungs- und Entwurfsphase ein Maximum an Zeit aufgewendet wird, sinkt die Wahrscheinlichkeit, dass das Team die Deadline verpasst, drastisch.

  • Qualität und ausführliche Dokumentation

Die Dokumentation wird von Anfang an gepflegt und aktualisiert. Die strenge Art und Weise, wie Dokumente aktualisiert werden, stellt sicher, dass zwischen dem Team und dem Kunden ein vollständiges Verständnis darüber besteht, was geliefert wird. Dies macht nicht nur die Planung und Gestaltung einfacher, sondern hilft auch den Beteiligten, wenn sie mehr Details über eine bestimmte Phase sehen müssen.

  • Minimale Kundenbeteiligung

Das Wasserfallmodell ist so konzipiert, dass, sobald die Anforderung klar definiert und verstanden wurde, eine Kundenpräsenz nicht unbedingt erforderlich ist. Dies entlastet das Team von zusätzlichen Belastungen und verhindert die Einführung neuer Änderungen in der späteren Phase des Projekts, was wiederum den rechtzeitigen Abschluss des Projekts sicherstellt.

  • Abteilungsbildung

Die Flexibilität des Wasserfallmodells ermöglicht es, dass verschiedene Mitglieder des Teams an anderen Projekten beteiligt sind oder die Arbeit an anderen Projekten fortsetzen, je nachdem, in welcher Phase sich das Projekt befindet. Mit festgelegten Fristen für jede Entwicklungsphase durchläuft das Projekt den Entwicklungsprozess und setzt nacheinander Ressourcen frei .

  • Qualitätssicherung

Dieses Modell ist ideal für Projekte, deren Anforderungen klar und streng definiert sind und bei denen eine nachträgliche Änderung der Anforderungen nicht möglich wäre. Darüber hinaus ist das Wasserfallmodell ideal für Projekte, bei denen die Qualität des Produkts gegenüber Zeit- oder Kostenaspekten bevorzugt wird.

Warum verwenden nicht mehr Projekte das Wasserfall-Projektmanagementmodell?

Einige der größten Vorteile des Wasserfallmodells verwandeln sich je nach Art des Projekts in seine Nachteile.

Die größte Einschränkung der Wasserfallmethode für Softwareentwicklungsprojekte besteht darin, dass sie nicht gut für lange oder umfangreiche Projekte geeignet ist. Weitere Nachteile sind: (6)

  • Wenig bis keine Änderungen oder Überarbeitungen:

Die Betonung des Wasserfallmodells auf klaren und klar definierten Anforderungen bedeutet, dass Änderungen der Anforderungen nach der Fertigstellung nicht nur schwierig, sondern auch kostspielig wären. Daher ist das Wasserfallmodell nicht für Projekte mit vagen Anforderungen geeignet. Dies bedeutet auch, dass jede Änderung der Software und Hardware in langfristigen Projekten schwierig zu bewältigen wäre. Dies impliziert auch, dass unerwartete Projektereignisse nicht mit dieser Methode angegangen werden können.

  • Verspätete Lieferung des Produkts:

Da die früheren Phasen des Modells dem Verständnis der Anforderungen gewidmet sind, beginnt die Softwareentwicklung später im Projektlebenszyklus. Dies bedeutet, dass die Beteiligten die Software erst später im Projektlebenszyklus sehen können.

  • Unpraktikabilität des Sammelns genauer und vollständiger Anforderungen :

Das Sammeln klarer, gut definierter und vollständiger Anforderungen in der Anfangsphase ist nicht nur schwierig, sondern für einige Projekte auch unpraktisch. Häufig haben Kunden zu Beginn des Projektlebenszyklus kein klares Bild von allen Anforderungen, sondern lernen und klären Anforderungen im Laufe des Projekts.

Moderne Darstellung des Wasserfallmodells

Wasserfall Projektmanagement

Trotz seiner verschiedenen Nachteile gehört das moderne Wasserfallmodell zu den am weitesten verbreiteten Software Development Life Cycle (SDLC)-Modellen. Die moderne Version des Wasserfallmodells enthält Feedbackschleifen während des gesamten Projektlebenszyklus, einschließlich der Wartung nach der Auslieferung.

In diesem Modell ist das Testen keine separate Phase, sondern wird kontinuierlich während des gesamten Softwareprozesses durchgeführt. Während der Wartungsphase kommt dem besondere Bedeutung zu, um sicherzustellen, dass die Software nicht nur wie gewünscht funktioniert, sondern auch zusätzliche Anforderungen in das Design einfließen.

Das moderne Wasserfallmodell zeigt anschaulich den Weg, der während der Entwicklung und Wartung bis zum Ausscheiden der Software eingeschlagen werden muss. Das moderne Wasserfallmodell beseitigt viele der Probleme des traditionellen Wasserfallmodells, bringt jedoch eigene Probleme mit sich. Beispielsweise umfasst der Abschluss jeder Phase eine vollständige und qualitativ hochwertige Dokumentation dieser Phasen und die Genehmigung durch die Software-Qualitätssicherungsgruppe (SQA), und dies muss auch im Falle von Änderungen erfolgen. Das Bestehen auf einer vollständigen Dokumentation kann zu Verzögerungen und unnötigem Papierkram führen.

Das ACME Super ATM Use-Case-Modell zum Abheben von Bargeld

Kurze Beschreibung:

Dieser Anwendungsfall beschreibt, wie ein Bankkunde einen Geldautomaten verwendet, um Geld von einem Bankkonto abzuheben.

Schauspieler:

Die folgende Abbildung zeigt alle Akteure im ACME-Super-ATM-Anwendungsfallmodell.

Zu den Akteuren gehören Kunden, Banksystem, Dienstadministrator und Sicherheitsadministrator.

Voraussetzungen:

  • Der Bankkunde muss im Besitz einer Bankkarte sein.
  • Die Netzwerkverbindung zum Banksystem muss aktiv sein.
  • Das System muss mindestens etwas Bargeld haben, das ausgegeben werden kann.
  • Die Option Barabhebungsservice muss verfügbar sein.

Siehe auch:

5 häufige Herausforderungen im Projektmanagement und Lösungen, um sie wie ein Profi anzugehen

Grundfluss:

  • Karte einführen
  • Karte lesen
  • Kunden authentifizieren
  • Wählen Sie Auszahlung
  • Das System zeigt die verschiedenen Serviceoptionen an, die derzeit auf der Maschine verfügbar sind
  • Wählen Sie Betrag
  • Das System fragt nach dem abzuhebenden Betrag, indem es die Liste der standardmäßigen Abhebebeträge anzeigt
  • Auszahlung bestätigen
  • Führen Sie die Bewertung der verfügbaren Mittel durch
  • Durchführungstransaktion durchführen
  • Karte auswerfen
  • Der Kunde nimmt die Bankkarte aus dem Automaten
  • Bargeld ausgeben
  • Das System gibt die angeforderte Menge an den Kunden aus
  • Das System zeichnet einen Transaktionsprotokolleintrag für die Auszahlung auf
  • Anwendungsfall Ende

Alternative Abläufe:

Alternative Flows umfassen die Flows für die folgenden Szenarien:

  • Behandeln Sie die Auszahlung eines nicht standardmäßigen Betrags
  • Umgang mit nicht lesbarer Bankkarte
  • Empfangsabwicklung
  • Fehlerbehandlung
  • Behandeln Sie das Banksystem, das nicht mehr reagiert

Ausnahmeflüsse:

Ausnahmeflüsse umfassen die Flüsse für die folgenden Szenarien:

  • Bewerten Sie die verfügbaren Mittel
  • Auszahlung durchführen
  • Dienstabschaltung
  • Abwicklung von Transaktionsanpassungen

Beitragsbedingungen:

  • Der Geldautomat hat die Karte zurückgegeben und das Bargeld an den Kunden ausgegeben, und die Abhebung wird auf dem Konto des Kunden registriert.
  • Der Geldautomat hat die Karte an den Kunden zurückgegeben, und auf dem Konto des Kunden ist keine Auszahlung registriert.
  • Der Geldautomat hat die Karte zurückgegeben, aber nicht den als vom Konto des Kunden abgehoben registrierten Bargeldbetrag geliefert; die Diskrepanz wird in den Protokollen des Geldautomaten registriert.
  • Der Geldautomat hat die Karte einbehalten, auf dem Konto des Kunden wurde keine Auszahlung registriert und der Kunde wurde benachrichtigt, wo er sich für weitere Informationen wenden kann.

Öffentliche Erweiterungspunkte:

Keiner

Spezielle Anforderungen

  • Zuverlässige Bargeldausgabe

Im Anwendungsfallmodell des ACME-Super-Geldautomaten zum Abheben von Bargeld sind alle Anforderungen festgelegt und klar definiert, daher ist das Wasserfallmodell für dieses Beispiel ideal. Sobald die Anforderungen notiert waren, war nur sehr wenig Feedback vom Kunden erforderlich, und die Entwicklungs- und Designphasen konnten nach einem sequenziellen Liner-Muster abgeschlossen werden. Das Projekt konnte mit Hilfe von Projektmanagement-Software wie nTask einfach verwaltet werden, wobei jede Phase klar definiert und gemäß den Anforderungen aufgeschlüsselt war.

Das ACME-Super-ATM-Anwendungsfallmodell zur Authentifizierung von Kunden

Wasserfall Projektmanagement

Kurze Beschreibung:

Dieser Anwendungsfall wird verwendet, um zu authentifizieren, dass die Person, die den Geldautomaten verwendet (der Kunde), berechtigt ist, die eingeführte Bankkarte zu verwenden, und dass das der Bankkarte zugeordnete Konto aktiv ist.

Schauspieler:

Zu den Akteuren gehören Kunde, Banksystem, Dienstadministrator und Sicherheitsadministrator.

Voraussetzungen:

  • Die Bankkarte wurde in den Geldautomaten eingeführt.
  • Die Bankkarteninformationen wurden erfolgreich gelesen.
  • Ein Kunde befindet sich im Dialog mit dem inkludierenden Anwendungsfall.
  • Die ATM-Sitzungs-ID wurde erstellt.

Grundfluss

  • Karteninformationen validieren
  • Das System sendet die Bankkarteninformationen an das Banksystem
  • Das System sendet auch die ATM-ID und die ATM-Sitzungskennung an das Banksystem
  • Das Banksystem bestätigt, dass die Bankkarteninformationen gültig sind und die Karte verwendet werden kann
  • Überprüfen Sie die Benutzeridentität
  • Das System fordert den Kunden zur Eingabe der PIN auf
  • Der Kunde gibt die PIN ein
  • Das System prüft, ob die eingegebene PIN mit der von der Bankkarte gelesenen PIN identisch ist
  • PIN validiert
  • Anwendungsfall endet

Alternative Abläufe:

Alternative Flows umfassen die Flows für die folgenden Szenarien:

  • Behandeln Sie keine Kommunikation mit dem Banksystem
  • Behandeln Sie keine Kommunikation mit der Bank des Kunden
  • Umgang mit inaktiver Karte oder Konto
  • Umgang mit gestohlener Bankkarte
  • Behandeln Sie ungültige Bankkarteninformationen
  • Handhabung Richtige PIN nicht eingegeben
  • Fehlerbehandlung
  • Behandeln Sie das Banksystem, das nicht mehr reagiert

Ausnahmeflüsse:

Ausnahmeflüsse umfassen die Flüsse für die folgenden Szenarien:

  • Bewerten Sie die verfügbaren Mittel
  • Auszahlung durchführen
  • Dienstabschaltung
  • Abwicklung von Transaktionsanpassungen

Beitragsbedingungen:

  • Der Kunde ist berechtigt, die Karte zu verwenden.
  • Dem Kunden wurde die Nutzung der Karte untersagt und die Karte eingezogen.
  • Der Kunde ist von der Nutzung der Karte ausgeschlossen und die Karte wurde nicht eingezogen.

Öffentliche Erweiterungspunkte

Keiner

Spezielle Anforderungen

Keiner

Im ACME Super ATM Use-Case Model to Authenticate Customer sind alle Anforderungen festgelegt und klar definiert. Die Projektgröße ist klein und kann mit Hilfe eines starren Prozesses problemlos abgeschlossen werden. Nach Aufnahme der Anforderungen konnten die Entwicklungs- und Designschritte in einem linearen Prozess abgeschlossen werden. Das Projekt konnte mit Hilfe von Projektmanagement-Software wie nTask einfach verwaltet werden, wobei jede Phase klar definiert und gemäß den Anforderungen aufgeschlüsselt war.

Branchenanwendung – US-Verteidigungsministerium

Das weit verbreitete Beispiel für die Verwendung der Wasserfallmethode ist das des US-Verteidigungsministeriums. 1985 verwendete das US-Verteidigungsministerium den Wasserfallansatz in DOD-STD-2167A, seinen Standards für die Zusammenarbeit mit Softwareentwicklungsunternehmen. Obwohl sie ihre Methodik nicht als „Wasserfall“ spezifiziert haben, verwendet das US-Verteidigungsministerium (DOD) immer noch die Grundprinzipien des Wasserfallmodells.

Die Regierung der Vereinigten Staaten entschied sich für das Wasserfallmodell, da die Vorteile des Modells ihre Anforderungen perfekt erfüllten. Die Bundesregierung bestand auf technischer Strenge und einem Produkt von höchster Qualität, während sie gleichzeitig eine große Kontrolle über das Endprodukt behielt. Dies zusammen mit der Einbeziehung der sechs Phasen – vorläufiges Design, detailliertes Design, Codierung und Komponententests, Integration und Tests – in Kombination mit umfangreicher Dokumentation, einer starken Präferenz für eine sequenzielle Single-Pass-Entwicklungsmethode und einer starken Überwachung macht DOD -STD-2167 das beste Beispiel für die Wasserfallmethode.

1986 erschien eine Entwurfskopie der Revision A von MIL-STD 2167, die die Betonung des Top-Down-Designs aufhob und die Verwendung von Rapid Prototyping als Alternative zum Wasserfall vorschlug. Dies lag daran, dass das Wasserfallmodell während dieser Zeit stark kritisiert wurde. Trotz der Tatsache, dass sich das DOD von der Wasserfallmethode distanziert hat, behielt die US-Bundesbehörde für Softwareentwicklung und -beschaffung immer noch einen stark hardwareorientierten und Wasserfallansatz bei.

Ein Bericht des National Research Council aus dem Jahr 2010 betonte, wie viele der Terminologien, die zur Beschreibung der Entwicklungsphasen der Konstruktion und Fertigung verwendet werden, sich auf Elemente des Wasserfallmodells wie vorläufige Entwurfsprüfungen und kritische Entwurfsprüfungen konzentrieren. Diese Betonung der Wasserfall-Projektmanagement-Methodik kann auf eine verstärkte Betonung von Qualität und Vertraulichkeit zurückzuführen sein. Die getrennten Phasen des Wasserfallmodells stellen sicher, dass nicht jedes Teammitglied in das gesamte Projekt involviert ist.

Im Jahr 2000 identifizierte DOD Instruction (DODI) 5000.2 den evolutionären Erwerb als bevorzugten Ansatz für den Erwerb. Die Vorschriften der Serie 5000 werden jedoch weiterhin von der für das Wasserfallmodell spezifischen Terminologie dominiert. Preliminary Design Reviews (PDRs) und Critical Design Reviews (CDRs), Markenzeichen des Wasserfallmodells, sind für jedes Programm vorgeschrieben.

Ist das Wasserfall-Projektmanagementmodell etwas für Sie?

Trotz seiner vielen Nachteile und Einschränkungen wird das Wasserfallmodell auch heute noch verwendet. Allerdings erfüllt keine Projektmanagementmethode die Anforderungen aller Unternehmen, nicht einmal alle Projekte, die von demselben Unternehmen abgewickelt werden. Ob es also das ideale Modell für Ihre Projektanforderungen ist, hängt von einer Vielzahl von Faktoren ab.

Da das Geschäft je nach Art, Größe, Branche und vielen anderen Faktoren variiert, gilt dies auch für Projekte. Anstatt nach der besten Methodik zu suchen, sollten Unternehmen diese Methodiken, ihre Verwendung und Anwendungen kennenlernen und sich anhand der folgenden Variablen für die beste Methodik entscheiden:

  • Organisatorische Ziele
  • Grundwerte
  • Limitierungen für das Projekt
  • Projekt Stakeholder
  • Projektgröße
  • Kosten des Projekts
  • Fähigkeit, Risiken einzugehen
  • Flexibilität erforderlich

Das Wasserfallmodell wird von Unternehmen verwendet, deren Anforderungen an das Endprodukt festgelegt sind, Zeit und Geld jedoch variabel sind. Das Wasserfallmodell ermöglicht es Projektmanagern, dasselbe Projekt mehrmals zu starten, bis das gewünschte Ergebnis erreicht ist. Nicht viele Unternehmen würden den eingebauten Mechanismus der Wasserfallmethode finden, um ihren Ansatz anzupassen und zu überdenken, bis sie das gewünschte optimale Ergebnis erzielen.

Die Wasserfallmethodik ist ideal für Projekte mit klar verstandenen, festgelegten und dokumentierten Anforderungen, gut verstandenen technischen Tools, Architekturen und Infrastrukturen, Zugang zu umfangreichen Ressourcen mit dem erforderlichen Fachwissen, einem stabilen, gut definierten Produkt und einem kurzen Lebenszyklus. Der lineare Ansatz des Wasserfallmodells lässt keine Entdeckung oder Änderungen an den anfänglichen Produktanforderungen zu. Jede Änderung der Anforderungen würde erfordern, dass das Projekt zu Phase eins zurückkehrt und der gesamte Prozess von vorne beginnt. Dies kann in vielen Branchen ein ernsthaftes Problem darstellen, von denen die meisten nach einem strengen Zeitplan arbeiten.

Die folgende Tabelle ist ziemlich hilfreich. Schau mal.

Tabelle 1: Anforderungen an das Wasserfallmodell

Checkliste für Anforderungen an das Wasserfallmodell
Legen Sie zu Beginn alle Anforderungen fest Ja
Langfristige Projekte Unangemessen
Komplexe Projekte Unangemessen
Häufig geänderte Anforderungen Unangemessen
Kosten Nicht teuer
Kostenschätzung Einfach abzuschätzen
Flexibilität Nicht
Einfachheit Einfach
Unterstützung von Projekten mit hohem Risiko Unangemessen
Erfolgsgarantie Weniger
Einbeziehung des Kunden Niedrig
Testen Spät
Wartung Am wenigsten wartbar
Leichtigkeit der Durchsetzung Einfach

Die Methodik des Projektmanagements ist für die heutigen Unternehmen von entscheidender Bedeutung. Indem Sie einen geeigneten Stil für Ihr Unternehmen verwenden, können Sie die Art und Weise verändern, wie Ihr Team zusammenarbeitet, an Aufgaben arbeitet und Projektmeilensteine ​​erreicht.

Anwendung in der Softwareindustrie

Das Wasserfallmodell ist in der Softwareindustrie weit verbreitet, wenn die Anforderungen an das Produkt klar definiert sind. Laut Royce kann das einfachste Programm in nur zwei Schritten abgeschlossen werden: Analyse und Codierung. Bei komplexeren Programmen kann jedoch mehr Planung erforderlich sein.

Der erste Schritt bei der Entwicklung einer Software wäre die Erstellung des Pflichtenheftes. Damit das Wasserfallmodell effektiv ist, ist es wichtig, dass diese Spezifikationen gut geplant und klar definiert sind. Dies würde beinhalten, mit Geschäftsexperten zu sprechen und die Geschäftsprozesse zu untersuchen, die derzeit von manuellen oder veralteten Computersystemen abgedeckt werden, um den Geschäftsprozess besser zu verstehen.

Siehe auch : Ist JIRA eine kontraproduktive Projektmanagement-Software auf dem heutigen Markt?

Wenn Anforderungen festgestellt werden, müssen sie von Geschäftsexperten und Kunden bestätigt werden. Wenn die funktionale Spezifikation fertiggestellt ist, wird die endgültige Kopie der Anforderungen entworfen und abgeschlossen.

Darauf folgt die Erstellung einer nicht funktionierenden Prototypanwendung samt Benutzeroberfläche. Dies hilft sowohl dem Kunden als auch den Entwicklern zu verstehen, wie das Produkt funktionieren würde. Nach Abschluss dieser Phase beginnt die Entwicklung der Software.

Wenn die Anwendung vollständig und getestet ist, wird ein Beta-Release veröffentlicht und zum Testen bereitgestellt. Alle gefundenen Fehler werden schnell behoben. Wenn keine signifikanten Fehler mehr vorhanden sind, kann die Anwendung als Release-Version 1.0 live gehen.

Anwendung für die Automobilindustrie

Industrien wie die Bau- und Fertigungsindustrie verwenden das Wasserfallmodell, bevor Dr. Royce 1970 seine Arbeit veröffentlichte. Der Montage- und Fertigungsprozess der Automobilindustrie ist starr und erfordert nur wenige Anpassungen, sobald das Werk eingerichtet ist. So werden die wesentlichen Anforderungen bereits vor der Errichtung der Anlage besprochen und festgelegt und der Konstruktions- und Produktionsprozess unter Berücksichtigung der Anforderungen eingerichtet.

Der Montageprozess selbst folgt einer Reihe von Aufgaben, die einfach so ausgeführt werden müssen, oder der gesamte Prozess bricht zusammen. Erst wenn eine Stufe abgeschlossen ist, kann der Prozess zur nächsten Stufe übergehen. Jede Änderung der Anforderungen könnte eine vollständige Überarbeitung des Prozesses erfordern und zusätzliche Zeit und Geld kosten.

nTask Vs Wasserfall in SDLC

Slack-Projektmanagement, ntask, ntask für Slack, Slack-Apps

Sobald Sie festgestellt haben, dass das Wasserfallmodell das für Ihre Anforderungen am besten geeignete Modell ist, müssen Sie die Verwendung eines Cloud-basierten kollaborativen Projektmanagementsystems wie nTask in Betracht ziehen. Tools für die Zusammenarbeit wie nTask wurden speziell entwickelt, um die Produktivität und Effizienz Ihres Teams zu steigern, unabhängig davon, welche Projektmanagementmethode Sie verwenden.

Mit Hilfe von nTask können Sie Projekte unterschiedlicher Größe einfach verwalten, Aufgaben zuweisen und delegieren, Dateien und Informationen in Echtzeit freigeben und alle Ihre Projektmanagementanforderungen erfüllen.

Haben Sie sich entschieden, die Wasserfallmethode auszuprobieren? Nachdem Sie nun gesehen haben, wie wichtig die Dokumentation bei dieser Methode ist, wissen Sie, dass der erste Schritt darin besteht, eine Plattform zu finden, auf der Sie alle erforderlichen Aufgaben nachverfolgen und mit Ihrem Team teilen können.

nTask kann von der Erfassung der Anforderungen bis zur Testphase helfen:

  • Verwalten und klar umreißen Sie die Dauer und die beteiligten Stakeholder jeder Phase.
  • Erfassen, diskutieren und dokumentieren Sie alle Anforderungen in Echtzeit mit allen relevanten Stakeholdern. Mit nTask beginnt die nächste Stufe erst nach Abschluss der vorherigen Stufe, gefolgt nur von der vollständigen Dokumentation und Genehmigung.
  • Erstellen Sie basierend auf den finalisierten Anforderungen einen Workflow für Ihr Team. nTask gibt Ihnen einen klaren Überblick über den Fortschritt des Projekts und ermöglicht es Ihnen, Feedback zu jeder einzelnen Aufgabe in jeder Phase des Wasserfallmodells zu geben.
  • nTask erleichtert die Zusammenarbeit und Kommunikation mit dem gesamten Team oder nur einem Teil des Teams.
  • Mit Hilfe von nTask ist es einfach, eine vollständige Dokumentation für jede Phase des Wasserfallmodells zu erstellen, zu pflegen und zu teilen. Sie können steuern, wer die Dokumentation anzeigen kann, sodass nur relevante Informationen mit Teammitgliedern geteilt werden.

Obwohl wir es an dieser Stelle hassen abzubrechen, ist dies ein zweiteiliger Beitrag. Setzen Sie für weitere Aktualisierungen ein Lesezeichen für diese Seite und vergessen Sie nicht, nach ein oder zwei Wochen nachzufassen. Wenn Sie jetzt etwas mitzuteilen haben, können Sie dies über den Kommentarbereich unten tun. Alternativ können Sie uns eine E-Mail an [email protected] senden. Wir melden uns gerne bei Ihnen zurück.

Lesen Sie auch:

  • Die 21 besten kostenlosen Produktivitäts-Apps des Jahres 2022
  • Die 23 besten To-do-Listen-Apps des Jahres 2022 für die Verwaltung persönlicher Aufgaben
  • 10 grundlegende Projektmanagementfähigkeiten für Projektmanager von 2022
  • Getting Things Done (GTD)-Methode und die 14 besten GTD-Apps und -Tools
  • Top 19 Zeiterfassungssoftware zur Verbesserung der Teamproduktivität
  • 27 Beste Aufgabenverwaltungssoftware für Startups im Jahr 2022
  • Die 36 besten kostenlosen Produktivitäts-Apps von 2022
  • Die 30 besten To-Do-Listen-Apps des Jahres 2022 für die Verwaltung persönlicher Aufgaben
  • Die 22 besten kostenlosen Projektmanagement-Tools für agile Teams im Jahr 2022
  • Verwalten virtueller Teams: Herausforderungen, Tipps und Management-Tools für virtuelle Teams
  • 47 beste Zitate zur Teamarbeit, um Zusammenarbeit und Motivation zu feiern