8.0 Wasserfall vs. zyklisches Projektmanagement (Teil 1)

EIN Wasserfall-Modell , das Sechsphasenmodell ist ein Wasserfallmodell. Mit anderen Worten, die Stufen treten sequentiell auf. So wie es unmöglich ist, gegen einen Wasserfall stromaufwärts zu schwimmen, schließt die reine Wasserfalltechnik ein Zurückkehren in eine abgeschlossene Phase aus.

Es ist nicht ideal, das Design während der Implementierungsphase zu ändern und so die Implementierung zu stoppen. Der Wasserfall-Ansatz ist aus verschiedenen Gründen für Softwareentwicklungsprojekte oft weniger geeignet.

  • Softwareentwicklung ist ein künstlerisches Unterfangen; es ist praktisch schwierig, alle Bedürfnisse (Funktionalitäten) vorherzusehen.
  • Die Schätzung der Zeit, die für die Entwicklung eines Features erforderlich ist, ist sehr schwierig.
  • Während des gesamten Lebenszyklus des Projekts sollten die Benutzer in der Lage sein, alle Zwischenergebnisse zu testen.

Softwareentwicklung ist ein künstlerisches Unterfangen #

Für den Uneingeweihten scheint es bei der Softwareentwicklung eher um Technik als um Erfindungen zu gehen. Es bezieht sich jedoch in vielerlei Hinsicht auf das Erfinden. Im Schöpfungsprozess weiß man nie genau, was passieren wird.

Die Designer und Programmierer, die für die Entwicklung neuer Software verantwortlich sind, müssen Antworten auf die gestellten Fragen finden. Ungeachtet der vielen Techniken und Arbeitsvorschriften ist die Erstellung von Computercode noch immer weitgehend unbekannt und daher unberechenbar. Programmierer können aus Millionen von Lösungen auswählen, die in Dutzenden von Programmiersprachen geschrieben sind und auf Tausenden verschiedener Hardwarekombinationen und Softwareplattformen arbeiten. Diese Flexibilität hat zwar viele Vorteile, macht das Projekt jedoch auch schwieriger zu verwalten als konventioneller Projektmanagement (wie Bau- oder Bauvorhaben).

Implementierung einrichten #

Der Wasserfall-Ansatz erfordert die Definition von Anforderungen als Folge der Definitionsphase des Projekts . Idealerweise sollte für den Rest des Projekts eine minimale zusätzliche Abweichung von diesen Kriterien erfolgen. Der Wasserfall-Ansatz der Softwareentwicklung erfordert zunächst einen erheblichen Aufwand bei der Analyse der erforderlichen Funktionalität (Anforderungen). Dies führt zu einem funktionalen Design (siehe I für weitere Informationen zu funktionalen Designs). Der Softwarearchitekt erstellt während des gesamten Designprozesses ein technisches Design, wobei das funktionale Design als Referenz verwendet wird. Darüber hinaus enthält das technische Design Anweisungen zur Ausführung der erforderlichen Funktionalität.

Obwohl dies ein einfaches Problem zu sein scheint, betrachten Sie das folgende Szenario. Im Rahmen eines Projekts wird ein neues Fahrzeug entwickelt. Als aktiver Autofahrer haben Sie die Aufgabe, automobile Bedürfnisse zu entwickeln. Sie besprechen sich mit anderen Autofahrern und stellen eine erschöpfende Liste zusammen:

  • Das Auto muss vier Personen Platz bieten;
  • Das Auto muss vorne auf der linken Seite des Fahrers ein Lenkrad haben; • Das Fahrzeug muss über ein Bremspedal, ein Gaspedal und eine Handbremse verfügen.
  • Die Scheinwerfer des Autos müssen weiß und die Rückleuchten müssen rot sein. (die wirkliche Liste wäre natürlich riesig)

Design & Modellierung #

Die Designer erstellen anhand Ihrer Liste ein neues Design, das viele Monate später erstellt wird. Wenn Sie die Straße hinuntergehen, sehen Sie, dass ein Fahrzeug zum Stehen gekommen ist. Sie stellen fest, dass Sie Bremslichter von Ihrer Liste weggelassen haben! Du nimmst schnell Kontakt mit dem Ingenieur des Autoherstellers auf, der bei deinem Anruf fast platzt. Sie behaupten, dass es sich um eine geringfügige Anpassung handelt. Für die Autobauer ist es jedoch eine Katastrophe. Bereits gefertigte Autos müssen komplett demontiert, Leitungen von den Bremspedalen nach hinten verlängert, das Fahrzeugheck komplett auf die Bremslichter umkonstruiert und bereits gefertigte Kofferraumklappen verschrottet werden, und die Liste geht weiter.

Obwohl das obige Szenario lächerlich erscheint, stellt es in der Softwareentwicklung ein fast tägliches Ereignis dar. Programmierer gehen fälschlicherweise davon aus, dass die Kunden, Kunden oder Benutzer des zu erstellenden Produkts genau verstehen, was sie wollen. Kunden glauben fälschlicherweise, dass Softwareentwickler alles in kürzester Zeit erstellen (und ändern) können. Dies ist der Hauptgrund für Streitigkeiten zwischen Verbrauchern und Softwareentwicklern.