Wir alle streben danach, dass unsere Softwareprojekte pünktlich und im Rahmen des Budgets* geliefert werden. Software ist komplex und wenn wir den Erfolg nicht planen, ist es unwahrscheinlich, dass er „einfach so passiert“. Bei der Planung von Softwareprojekten verfügen wir glücklicherweise über Erfahrungen aus vergangenen Fehlschlägen, aus denen wir lernen können. Wir sollten die Lehren aus diesen Fehlern nutzen, damit unsere Projekte den „pathologischen“ Weg vermeiden können.
Was meinen wir damit, dass ein Projekt verspätet ist? Bei Verspätung geht es in Wirklichkeit darum, dass ein Projekt im Vergleich zu den Erwartungen verspätet geliefert wird, oder mit anderen Worten: verspätet im Vergleich zur Schätzung. Um Enttäuschungen zu vermeiden, müssen wir realistische Erwartungen (Schätzungen) schaffen UND die Aktivitäten durchführen, um Probleme zu vermeiden, die dazu führen könnten, dass die Schätzungen nicht erfüllt werden.
In einer Studie über 84 Projekte von IBM und AT&T stellte Capers Jones fest, dass Projekte, die sechs Monate oder mehr verspätet waren, in der Anfangsphase kaum Anzeichen dafür zeigten, dass sie in Schwierigkeiten waren. Bei den letzten Projekten wurden viele wichtige Aktivitäten gespart, insbesondere: Anforderungsüberprüfungen, Inspektionen und Qualitätskontrolle. Bei all dem geht es darum, frühzeitig auf Qualität zu achten.
Warum wurden sie falsch geschätzt? Entweder war der Kostenvoranschlag unangemessen oder Aktivitäten, die den Zeitplan hätten einhalten können, wurden nicht ordnungsgemäß durchgeführt.
Capers nennt 10 Faktoren, die zu einer Schätzungs-/tatsächlichen Diskrepanz führen:
*Einige Parteien profitieren von den zusätzlichen Kosten, die bei der Verlängerung eines Projekts entstehen.
Wie KI helfen kann
Die Planung beginnt frühzeitig, wenn Sie wissen oder die Anforderungen erkennen. ScopeMaster nutzt KI, um Ihnen einen schnellen Einblick in die Anforderungen zu ermöglichen. Was dazu führt bessere Pläne.
Faktoren, die den Software-Zeitplan beeinflussen und schätzen Sie die Zuverlässigkeit ein
| Faktor | Beschreibung | Auswirkungen auf den Zeitplan | Schadensbegrenzung |  |
|---|---|---|---|---|
Metrikfehler |
Die Verwendung ungeeigneter Metriken wie Story Points oder ähnliches führt zu schlechten Schätzungen | Bis zu 100% | Verwenden Sie funktionale Größenbestimmung, COSMIC Function Points | ScopeMaster automatisiert die funktionale Größenbestimmung und beseitigt die meisten dieser Fehler. |
Technologieanpassung |
Unsicherheit/Verzögerung bei der Einführung neuer Werkzeuge/Technologien/Techniken | Beobachtete Auswirkungen können Schätzungsfehler von bis zu 150% verursachen | Warten Sie mindestens einen Monat, bis die neue Technologie in Betrieb genommen wird, und planen Sie dies ein | |
Kritische Pfadfehler |
Die Illusion, dass der Fortschritt auf Kurs ist, bis das Projekt durch ein blockierendes Ereignis zum Stillstand kommt | Fehler in Zeitplänen von bis zu 25% | Eine bessere Überwachung kritischer Pfade und eine proaktive technische Risikominderung können diese minimieren. | ScopeMaster regt dazu an, frühzeitig über Komplexitäten und Integrationen nachzudenken, die häufige Ursachen für CP-Probleme sind |
Größen-/Umfangsprobleme |
Eine falsche Unterschätzung des wahren Ausmaßes eines Projekts führt zu einem Anstieg des Arbeitsaufwands und des Zeitplans. Qualität und Vollständigkeit der Anforderungen wirken sich auch auf die Fähigkeit zur korrekten Dimensionierung aus | Fehler 15-100% | Eine funktionale Dimensionierung und eine automatisierte Vollständigkeitsprüfung werden dazu beitragen, dies zu mildern. | Gelöst durch ScopeMaster (auch für unerfahrene Projektmanager). |
Schleichende Benutzeranforderungen |
Sich ändernde Anforderungen (im Gegensatz zu fehlenden Anforderungen) führen zu einem Anstieg des Arbeitsaufwands und des Zeitplans. | Bei längeren Projekten sind die Fehlerraten höher (2-10% pro Monat). | Dies sollte geplant und angenommen werden (Agile). | ScopeMaster hilft auf verschiedene Weise: Verbesserung der Qualität früher Anforderungen, bessere Ermittlung und Volatilitätsverfolgung |
Zuordnungsfehler |
Einer Aktivität innerhalb eines Projekts wird nicht die erforderliche Personalausstattung zugewiesen. Jede Person, die eine bestimmte Rolle ausübt, verfügt über eine begrenzte Arbeitskapazität und muss zum richtigen Zeitpunkt im Projekt zugewiesen werden. | Fehler bis 100% | Kompetente Manager, die die Aufgabenkapazitäten verstehen (siehe unten). | ScopeMaster hilft, indem es eine funktionale Größe bereitstellt, aus der Zuweisungsumfänge ermittelt werden können. |
Fehler bei der Produktionsrate |
Die Differenz zwischen der erwarteten und der tatsächlichen Produktionsrate. | 20-100% | Realistische und angemessene Produktionsratenmessungen helfen z. B. CFP/Monat für ein bestimmtes Team. | ScopeMaster hilft, indem es eine funktionale Größe bereitstellt, anhand derer Produktionsraten gemessen, bewertet und überwacht werden können. |
Personalaufbau |
Wenn es nicht gelingt, zur richtigen Zeit die richtige Anzahl an Mitarbeitern mit den richtigen Fähigkeiten einzusetzen, führt dies zu Verzögerungen. | Es ist wahrscheinlich, dass die Auswirkungen erst nach Wochen oder sogar Monaten auftreten. | Kompetente Manager sollten angemessen planen. | ScopeMaster hilft, indem es eine funktionale Größe bereitstellt, aus der Zuordnung und Umfang bestimmt werden können. |
Aufgabenauswahl |
Wenn nicht alle Projektaktivitäten – nicht nur die Codierung – berücksichtigt werden, führt dies zu Planungsfehlern. | Beobachtet bis 1000% | Kompetente Manager sollten alle Aktivitäten angemessen planen. | |
Exekutive oder politische Einmischung |
Führungskräfte erlassen Zeitvorgaben oder andere unangemessene Zwänge, die zu schlechter Qualität führen. | Fehler bis zu 50% für den Zeitplan, 100% für die Kosten | Kompetente Manager sollten solchen Eingriffen energisch entgegentreten. | ScopeMaster erstellt funktionale Größenschätzungen, aus denen realistische Zeitpläne ermittelt und zur Verteidigung verwendet werden können. |
Aktivitätsbasierte Planung basierend auf der funktionalen Größe
Planung von Softwareprojekten
Der wichtigste Faktor bei der Bestimmung der Dauer eines Projekts ist seine Größe. Unter Größe verstehen wir die Funktionsgröße. Die funktionale Größe ist das zuverlässigste Mittel zur Dimensionierung eines Softwareprojekts. Im Gegensatz zu Story Points (bei denen es sich um eine nichtlineare, subjektive, technische Proxy-Schätzung des Aufwands handelt) ist die funktionale Größe im Allgemeinen konsistent und liegt innerhalb weniger %, unabhängig davon, wer sie dimensioniert.
Um festzustellen, wie viel von jeder Aktivität für unser Projekt angemessen ist, müssen wir beide verstehen Aufgabenumfang (wie viel Kapazität eine Person bewältigen kann) und ihre Produktionsrate (wie viel Kapazität sie in einem bestimmten Zeitraum adressieren können). Diese werden in der folgenden Tabelle basierend auf der Funktionsgröße der Software, an der gearbeitet wird, in Funktionspunkten angezeigt.
Es gibt zwei Hauptstandards für die funktionale Größe: traditionelle (IFPUG) Funktionspunkte und COSMIC-Funktionspunkte. Letzteres empfehlen wir vor allem deshalb, weil es sich sehr gut mit unvollständigen Anforderungen befasst. Sie müssen nicht alle Anforderungen kennen, um die Größe einer Software zu bestimmen (was Sie im Allgemeinen mit IFPUG tun).
Aktivitätszuweisungen und durchschnittliche Produktivität
Für aktivitätsbasierte Planung
Nicht alle dieser Aktivitäten sind bei allen Projekten erforderlich. Als Richtlinie gilt: Je größer das Projekt, desto mehr davon müssen Sie durchführen.
| Aktivität | Umfang der Personalzuweisung, FP | Monatsproduktion, FP |
|---|---|---|
Anforderungen |
333 | 175 |
Prototyp entwickeln |
500 | 150 |
Die Architektur |
1000 | 300 |
Projektpläne |
1000 | 500 |
Ersten Entwurf |
250 | 175 |
Detailliertes Design |
250 | 150 |
Designbewertungen |
200 | 225 |
Codierung |
175 | 50 |
Akquisition wiederverwenden |
500 | 600 |
Paketkauf |
2000 | 400 |
Codeinspektionen |
150 | 150 |
Unabhängige Verifizierung und Validierung |
500 | 125 |
Konfigurationsverwaltung |
1000 | 175 |
Integration |
1000 | 250 |
Benutzerdokumentation |
1000 | 70 |
Unit-Tests |
200 | 150 |
Funktionsprüfung |
200 | 150 |
Integrationstests |
250 | 175 |
Systemtests |
250 | 200 |
Feldtests (Betatests). |
1000 | 250 |
Abnahmetests |
1000 | 350 |
Unabhängige Tests |
750 | 200 |
Qualitätskontrolle |
1000 | 150 |
Installation und Schulung |
2000 | 350 |
Projektmanagement |
1000 | 100 |
Eine äquivalente, auf CFP basierende Tabelle ist nicht verfügbar. Dennoch ist es sinnvoll, FP und CFP als ungefähr gleichwertig zu betrachten, wenn diese Daten für die aktivitätsbasierte Planung verwendet werden.
Ein aktivitätsbasierter Ansatz ist besonders nützlich, da er uns hilft, das Personal und die Fähigkeiten zu identifizieren, die während des Projekts benötigt werden. Werkzeuge wie z SRM® von Namcook Analytics SEER für Software von Galorath, SLIM von QSM oder Wahre Planung von Unison (ehemals Price Systems) kann darüber hinaus helfen, indem es im Laufe der Zeit ein geeignetes Personalprofil für ein bestimmtes Projekt bereitstellt.
Dies ist eine gekürzte Version von Tabelle 11.4, veröffentlicht in „Estimating Software Costs, zweite Auflage“ von Capers Jones. Erhältlich bei Amazon. Bitte beachten Sie, dass dies nur eine Veranschaulichung der Aktivitäten und ihrer Personalbesetzung und Produktivitätsraten (implizite Kosten) ist. Sie werden feststellen, dass es sich lohnt, eigene Maßstäbe für diese Aktivitäten festzulegen.
Frühe Schätzung
Wenn Sie Hilfe bei der Schätzung von Größe, Dauer und Personalausstattung eines Projekts benötigen, bevor Sie die Anforderungen kennen, dann ist Software Risk Manager (SRM) von Namcook Analytics ein geeignetes Tool. Es nutzt historische Projektdaten und verschiedene Algorithmen, um Schätzungen zu Größe, Dauer, Personalausstattung und vielem mehr zu erstellen. SRM finden Sie bei Namcook Webseite.
Abschluss
Die wichtigsten Erkenntnisse aus diesem Artikel sind:
- Es ist möglich, realistische Kostenvoranschläge für Softwareprojekte zu erstellen die einigermaßen konsistent mit dem sind, was letztendlich passiert.
- Die Größe (funktionale Größe) ist der wichtigste Faktor Auswirkungen auf Aufwand und Dauer. Die Zuverlässigkeit der Größenschätzung hängt von zahlreichen Faktoren ab.
- Ein aktivitätsbasierter Ansatz basierend auf der funktionalen Größe kann eine vernünftige Schätzung des Aufwands (und damit der Kosten) liefern.
- Wenn wir den Aufwand und die typischen Produktivitätsraten kennen, können wir die Dauer angemessen einschätzen.
- Sehr große Projekte profitieren auch von einem parametrischen Planungstool, das die Größe und Fähigkeiten eines Teams im Laufe der Zeit während des gesamten Projekts vorhersagen kann.
