Die Wasserfalltechnik ist in Stufen unterteilt. Projektleiter müssen in ihren Projektplänen Schätzungen für den Zeitaufwand (und damit das Geld) für jeden Schritt angeben. Wir haben bereits festgestellt, dass Zeitschätzungen für jedes Projekt von Natur aus problematisch sind, noch mehr, wenn sie früh in der Projektlaufzeit festgelegt werden müssen. Für Softwareprojekte ist das einfach nicht machbar. Ziehen Sie die Möglichkeit in Betracht, während der Definitionsphase eine qualitativ akzeptable Liste von Fähigkeiten zu erstellen. Im Prinzip sollte dies dem Projektteam ermöglichen, den Zeitaufwand für die Entwicklung jedes Features realistisch einzuschätzen. In der Realität gibt es jedoch zu viele Unsicherheiten, um eine angemessene Näherung zu geben:
In der Realität gibt es jedoch zu viele Unsicherheiten, um eine angemessene Näherung zu geben:
- Häufig stellt sich nach der Entwicklung einer Funktion heraus, dass der Client sie nicht benötigt. Daher können die Stunden, die mit der Entwicklung dieses Features verbracht wurden, als vergeblich angesehen werden.
- Im Laufe des Projekts können sich Anforderungen ändern.
- Soll die Fähigkeit zu hohen oder zu geringen Kosten bereitgestellt werden? Es gibt viele Implementierungs- und Realisierungstechniken.
- Wie wird die Funktionalität technisch gestaltet? Das Design hat großen Einfluss auf die Zeit, die für die Erstellung benötigt wird.
- Inwiefern muss die Funktion auf hohem Niveau sein? Soll beispielsweise eine Webanwendung jederzeit vollumfänglich zugänglich sein oder soll sie für einige Stunden pro Jahr ausfallen?
- Die zum Erkennen und Beheben von Softwareproblemen erforderliche Zeit variiert zwischen Minuten und Wochen.
- Wie lange dauert die Installation und Integration der neuen Software in die aktuellen Systeme des Kunden?
- Der Mangel an Informationen über mögliche Lösungen wirkt sich zusätzlich auf die Zeitschätzungen aus. Darüber hinaus ist es schwierig, den Zeitaufwand für den Erwerb des erforderlichen Fachwissens abzuschätzen.
Die obige Liste zeigt, dass eine Vielzahl von Variablen die Zeitdauer beeinflussen können, die für die Entwicklung einer neuen Software erforderlich ist. Der Zeitaufwand für die Entwicklung eines Features zu Beginn eines Projekts wird oft viermal zu niedrig oder viermal zu hoch eingeschätzt. Dies impliziert, dass die erforderliche Zeit viermal mehr oder viermal weniger als eine fehlerhafte Schätzung betragen kann. Im Laufe des Projekts werden diese Schätzungen genauer. Nach Abschluss des funktionalen Designs wird die Marge auf 25 % zu viel oder zu wenig verringert. Erst wenn das Merkmal entwickelt wurde, ist eine Schätzung mit hoher Zuverlässigkeit möglich.
Softwarerisiken #
Projektmanagement-Software wird nie ganz fehlerfrei sein. Selbst für bekannte Programme, die weit verbreitet sind (zB Word, Excel, Explorer, OS X, PHP und Flash), gibt es im Internet Listen bekannter Fehler. Regelmäßig werden neue Versionen auf dem Markt bereitgestellt, die Softwarefehler beheben. Kunden verlangen manchmal, dass Software fehlerfrei ist. In Wirklichkeit würde ein solches Ziel jedoch die Fertigstellung einer Software unmöglich machen. Außerdem sind Softwarefehler oft nicht programmimmanent.
Flash wurde verwendet, um ein Lehrspiel zu erstellen. Der Kunde stimmte zu, das Spiel als Datei zu bekommen und auf seinem eigenen Server zu installieren. Im Laufe des Projekts bat der Kunde darum, dem Spiel eine Highscore-Funktion hinzuzufügen, um die Wettbewerbsfähigkeit der Spieler zu verbessern. Dies würde etwas PHP-Skriptcode benötigen. Die Spieleentwickler entwickelten und testeten den Skriptcode auf ihrem eigenen Server mit Linux. Es war erfolgreich. Der Client hat das Spiel und den Skriptcode erhalten. Der Client verwendete jedoch einen Windows-Server, und aus irgendeinem Grund funktionierte das Skript nicht mehr richtig. Die besten Noten wurden nicht beibehalten. Der Programmierer braucht letztendlich eine Woche, um das Problem zu beheben. Wie sich herausstellt, funktionieren PHP und Windows nicht immer gut zusammen. Das Skript war in seiner Gesamtheit absolut fehlerfrei! Er konnte es mithilfe eines Hacks zum Laufen bringen, und alle waren zufrieden – aber wer sollte diese zusätzliche Arbeitswoche bezahlen?
Ein weiteres Softwareentwicklungsprojekt umfasste auch die Erstellung von Lehranwendungen. Das Problem war, dass die Software für die Entwickler gut funktionierte, aber nicht gut für den Kunden. Nachdem alle anderen Möglichkeiten ausgeschöpft waren, beschloss der Programmierer, dem Kunden einen Besuch abzustatten. Wie sich herausstellte, betrieb der Kunde einen Pentium III-Rechner aus den frühen 1990er Jahren. Die Langsamkeit des Computers trug zur schlechten Leistung der Software bei. Außerdem haben die Programmierer die Software auf einem Pentium III ausprobiert und sie hat gut funktioniert. Eine weitere Untersuchung ergab, dass der PC des Kunden aufgrund einer Virus- und Spyware-Infektion langsam lief.
Umgang mit Unsicherheiten in der Projektentwicklung #
Die Unsicherheit, die durch die obigen Instanzen gezeigt wird, verkompliziert den Prozess der Entwicklung von Projektplänen . Außerdem erschwert es die Verhandlungen zwischen den Parteien. Jemand muss die Risiken tragen, die mit der zusätzlichen Arbeit verbunden sind, die durchgeführt werden muss. Bei stundenweiser Zahlung trägt der Auftraggeber das Risiko. Bei Vereinbarung eines Pauschalhonorars (wie bei geförderten Projekten) trägt der Softwareentwickler das Risiko. Bei mehr als zwei Personen wird die Situation komplexer. Wer sollte in diesem Szenario die Kosten für die zusätzlichen Arbeitsstunden für das Projekt tragen?
Häufig kommt es zu Streitigkeiten darüber, wer für Verzögerungen zur Verantwortung gezogen werden sollte. Oft ist der Verantwortliche schwer zu identifizieren. Es ist durchaus denkbar, dass keiner der Beteiligten ein Verschulden trifft, da die „Verzögerung“ durch eine falsche anfängliche Schätzung der benötigten Stundenzahl verursacht wurde. Überhöhte Projektstunden und die Frage, wer zahlen soll, sind in der IT-Branche häufige Streitpunkte.
