Während des gesamten Lebenszyklus des Projekts sollten die Benutzer in der Lage sein, alle Zwischenergebnisse zu testen. #
Kunden werden aufgefordert, ihre Bedürfnisse während der Definitions- und Designphase so genau wie möglich zu definieren. Dies ist aus zwei Gründen eine Herausforderung. Zu Beginn haben die Verbraucher ein begrenztes Verständnis für das Potenzial und die Unmöglichkeiten der Informationstechnologie. Sie haben keine Vorstellung davon, was machbar ist oder sein sollte, noch wissen sie, was sie wünschen oder nicht wollen. Zweitens fehlt es den Verbrauchern oft an einem gründlichen Verständnis ihrer eigenen Geschäftsprozesse.
Zahlreiche IT-Initiativen umfassen die Computerisierung der aktuellen Geschäftsprozesse eines Unternehmens. Auch wenn Verbraucher schon lange mit Prozessen arbeiten, fehlt ihnen oft die Fähigkeit, eigene Geschäftsprozesse zu gestalten. Sie mögen auf ihre eigene Weise gut funktionieren, können aber nicht angeben, was diese Art und Weise ist. Vor der Entwicklung von Software, die die Computerisierung vorantreibt, ist eine genaue Prozessdefinition erforderlich. Die Komplexität der Kunden steigt dadurch, dass bestehende Abläufe erklärt werden müssen.
Bestimmungskriterien #
Häufig ist die in der Definitionsphase erstellte Kriterienliste unvollständig. Programmierer erstellen während der Implementierungsphase Software nach dieser Teilliste. Wenn Verbraucher auf Betaversionen neuer Software stoßen, werden zusätzliche Bedürfnisse offensichtlich. „Es sieht gut aus, aber könnten Sie es vielleicht reparieren, damit ich nicht ständig mein Passwort eingeben muss?“ Programmierer beklagen oft, dass Kunden sich nicht sicher sind, was sie wollen. Kunden behaupten, dass Softwareentwickler als Experten früher im Prozess hätten erkennen müssen, was die Kunden wollen.
Für ein Softwareprojekt, das die automatisierte Verarbeitung von Anträgen für einen webbasierten Dienst beinhaltete, wurde ein umfassendes Funktionsdesign erstellt. Zahlreiche Kundenbedürfnisse wurden zusammengestellt. Nach dem Hinzufügen einiger Bildschirmdesigns und Flusszeichnungen konnten die Programmierer loslegen.
Verwalten von Clients und Einschränkungen #
Möglicherweise aufgrund des hohen Zeitdrucks des Projekts oder möglicherweise aufgrund der eher chaotischen Organisation des Kunden, hatten die Konstrukteure vergessen, aus einer kritischen Komponente zu bestehen: der manuellen Verwaltung. Das Programm hat die Anträge bearbeitet. Da die Anträge automatisch bearbeitet werden sollten, argumentierten die Programmierer, dass keine menschliche Verwaltung erforderlich sei. Auch dieses Kriterium wurde im funktionalen Design weggelassen.
Als das Programm zum Testen bereitgestellt wurde, stellte der Kunde fest, dass viele Apps Ausnahmen aufwiesen. Diese Anträge können nicht automatisch bearbeitet werden und müssen manuell bearbeitet werden. Das Programm funktionierte jedoch völlig automatisch.
Die Wasserfall-Projektmanagement erfordert die Prüfung der tatsächlichen Ergebnisse des Projekts am Ende der Umsetzungsphase. Das ist spät Entwicklungsstufe . Zwischen Definitionsphase, Designphase und Implementierungsphase können Monate oder sogar mehr als ein Jahr vergehen. Wenn in einem späten Stadium des Projekts Konstruktionsfehler entdeckt werden, kann es kostspielig, wenn nicht unmöglich sein, das Programm zu ändern, ohne ein neues Projekt vollständig zu beginnen. Da es praktisch unmöglich ist, alle Kriterien im Voraus zu definieren, ist ein Arbeitsansatz wünschenswert, der das Testen von (Zwischen-)Ergebnissen ermöglicht.
Anforderungen analysieren #
Beim Vergleich mehrerer potenzieller Softwareunternehmen erkundigte sich ein Kunde nach den Möglichkeiten. Eine Partei war zögerlich und stellte die Realisierbarkeit vieler Forderungen des Kunden in Frage. Die Gegenseite wurde von einem aggressiven Handelsvertreter vertreten.
Wenn sich ein Kunde nach der Machbarkeit einer bestimmten Anfrage erkundigte, rief der Verkäufer seine Programmierer an. ‚Können wir eine Funktion erstellen, die X tut?‘ Der überwiegend technisch denkende Programmierer meinte, theoretisch sei alles denkbar. Weder der Programmierer noch der Verkäufer waren besorgt über Projektmanagement Machbarkeit (zB Zeit, Geld, Komplexität und Risiko).
Die Aufregung des Außendienstmitarbeiters übertraf die zurückhaltende Haltung des Gegenübers. Der Kunde entschied sich für das aggressive Angebot des Vertriebsmitarbeiters. Das neu akquirierte Projekt wurde dann an einen Projektleiter und ein Team von Programmierern übergeben.
Nach einiger Zeit stellte sich heraus, dass das Projekt hinter den Erwartungen des Kunden zurückblieb. Dies lag unter anderem daran, dass die Verfahren für den Kunden viel komplexer waren, als es zunächst aussah. Während eines hitzigen Austauschs zwischen den beiden Parteien sagte der Kunde, dass der Verkäufer „angegeben hatte, dass die Funktionalität X kein Problem darstellen würde.
