Wie sich SW-Projekte kalkulieren lassen

02.04.2007
Von Rainer Risch
Damit die Kosten eines Entwicklungsprojekts nicht aus dem Ruder laufen, sollte vor dem Start eines solchen Vorhabens eine Kalkulation stehen, die zwar möglichst genau, aber gleichzeitig wenig komplex ist.

Für die Aufwandsabschätzung von Softwareprojekten gibt es eine Reihe klassischer, von Wissenschaftlern entwickelte Kalkulationsmethoden, die auf den statistischen Werten vieler Projekte basieren. Die wichtigsten Ansätze stammen aus den 80er Jahren. Populär ist zum Beispiel das Verfahren, die funktionale Größe einer Software mit Function Points (FP) nach den ISO-normierten Regeln der International Function Point User Group (IFPUG) oder auch des Common Software Measurement International Consortium (Cosmic) zu bewerten. Function Points liefern dabei eine Maßzahl für den Systemumfang, die aus einer Beschreibung ermittelt wird. Dabei werden alle Elementarfunktionen aufgelistet und nach ihrer Komplexität (= Anzahl der Function Points) bewertet. Hinzu kommen weitere Function Points für die Datenverwaltung. Für eine Kalkulation wird die Summe aller ermittelten Function Points als Maßzahl für die funktionale Größe herangezogen: Den Aufwand ermittelt man aus der Multiplikation der FP-Summe mit dem Faktor "Aufwand pro FP", den man aus einem früheren Projekt kennt.

Genauer rechnen mit Cocomo

Eine gegenüber dieser Dreisatzmethode verbesserte Hochrechung liefert das Constructive Cost Model (Cocomo). Die Basis für die Formeln hier ist ein Statistik-Pool, der verschiedenste Projekteinflussgrößen ("effort adjustment factors") berücksichtigt, so dass man bei der Anwendung speziell auf die Projektsituation eingehen kann. Die Formeln sind durch die Projektdatenbasis der Carnegie Mellon University, wo Cocomo entwickelt wurde, kalibriert. Eine unternehmensspezifische Kalibrierung ist jedoch heutzutage praktisch unmöglich, womit sich die Frage stellt, wie übertragbar dieses Verfahren auf die eigene Situation überhaupt ist.

Genau genommen entsprechen beide Verfahren kaum noch den heutigen Rahmenbedingungen von Software-Entwicklungsprojekten: Früher waren IT-Projekte stets Neuentwicklungen, so dass statistische Erfahrungen anderer auf die eigene Situation übertragbar waren. In der Zwischenzeit haben sich die Szenarien in der Softwareentwicklung jedoch stark gewandelt: Zum Einsatz kommen neue Techniken wie tragfähige Infrastrukturen, mächtige Softwarebibliotheken und integrierte Tools. Zudem erobert die Software als Teil komplexer Gesamtsysteme die verschiedensten Anwendungsbereiche - beispielsweise solche mit physikalischen Komponenten und Echtzeitanforderungen, etwa in der Mechatronic oder im Multimedia-Umfeld. Dort gibt es ganz spezielle und neuartige Entwicklungsprozesse, für die kaum fundierte Erfahrungen vorliegen. Sie sind durch Adjektive wie "inkrementell", "iterativ", "agil" oder "extrem" charakterisiert.

Voraussetzungen für die Aufwandskalkulation

Aufwandskalkulationen müssen vergleichbar und nachvollziehbar sein. Deshalb sollte die IT-Organisation das Thema im Sinne ihrer Governance-Aufgaben steuern. Dazu zählen:

  • Die Benennung eines Themenverantwortlichen, der Prozesse und methodische Ansätze definiert und in die Arbeit der Projektleiter integriert.

  • Die Zusammenstellung der bisher genutzten erfolgreichen Ansätze und Best Practices innerhalb des Unternehmens sowie der geeigneten Ansätze, die von außen kommen (Ist-Aufnahme).

  • Die Planung von Aktivitäten, um zukünftige firmenspezifische Best Practices zu definieren und schrittweise einzuführen. Wenn im Unternehmen Aufwandskalkulationen eher stiefmütterlich und situationsabhängig behandelt werden, führt die Planung typischerweise zu folgenden nächsten Schritten:

  • Eine Festlegung, wie frühe Aufwandskalkula- tionen und die tatsächlichen Projektaufwände als Erfahrungen dokumentiert werden sollen (Erfahrungsdatenbasis mit Auswertungsmöglichkeiten).

  • Eine Erweiterung der Projektmodelle (Vorgehensrichtlinien für Projekte und deren Einhaltung) um die Aufwandskalkulation in frühen Phasen und die Dokumentation der Erfahrungen am Ende des Projekts.

  • Die Unterstützung aller Projekte durch Aufwandskalkulation.

  • Eine Optimierung der Verfahren und Hilfsmittel.

Das bedeutet also, dass die Voraussetzungen zur Anwendung der klassischen Kalkulationsansätze nicht mehr gegeben sind. Haben sie deshalb ihren Wert verloren? Nein: Die Prinzipien, auf denen sie aufbauen, gelten weiter und sie können erfolgversprechend in jeder Situation eingesetzt werden!

Eine Aufwandskalkulation, die zu der aktuellen Situation in den Unternehmen passt, sollte im Idealfall vier Schritte berücksichtigen:

  • Das Projekt und seine IT-Lösung beschreiben (zum Beispiel in einem Lastenheft),

  • den Umfang einer IT-Lösung im Sinne der Menge ihrer Features beschreiben,

  • vergleichbare frühere Projekterfahrungen heranziehen und

  • Expertenwissen nutzen.

Im Folgenden wird zu jedem dieser Schritte auch eine abgespeckte Methodenversion angegeben. Diese zeichnet sich dadurch aus, dass sie weniger Aufwand erfordert, ihre Ergebnisse dafür aber auch nicht ganz so belastbar sind.

Projektbeschreibung

Die zwei wichtigsten Kriterien für verlässliche Systembeschreibungen sind die Nachvollziehbarkeit und Vollständigkeit in der Breite. Systembeschreibungen sollten im Idealfall einer unternehmensweit gültigen Struktur folgen und dann sofort von jedem verstanden und auf ihre Vollständigkeit hin überprüft werden können. Bei Neuentwicklungen sind beispielsweise immer Listen von Funktionen und Komponenten, Datenmodellen und Use Cases nötig. Embedded-Systeme etwa können über Modelle aus der Entwicklung und dem Design beschrieben sein, die Anpassung einer Standardsoftware über die zu verändernden Anteile der grafischen Oberfläche (GUI). Im Hinblick auf die nächsten Kalkulationsschritte muss aber meistens die Spezifikation vervollständigt oder durch Expertenannahmen ergänzt werden.

Light-Version: Es reicht zunächst ein grober Check auf Vollstän- digkeit in der Breite und die Abschätzung der noch nicht beschriebenen Anteile. Der Erfolgsfaktor besteht darin, dass keine universelle Struktur für Systembeschreibungen im Unternehmen definiert werden muss, sondern lediglich für Organisationseinheiten mit homogenen Auf- gaben.

Maßzahlen für den Umfang ermitteln

Eine Maßzahl ist dann sinnvoll, wenn vermutet wird, dass der Aufwand eines IT-Projekts proportional zur Maßzahl zunimmt. Das gilt beispielsweise für die Anzahl von Use Cases, Entitäten eines Informationsmodells, Schnittstellen, Modellen oder Modellelementen, GUI-Kom- ponenten und vor allem auch für Function Points. Nutzbar sind die Maßzahlen natürlich nur dann, wenn es andere Projekte gibt, für die dieselbe Maßzahl mit dem jeweiligen Aufwand in Korrelation gesetzt wurde. Dann lässt sich deren Aufwand pro Maßzahl hochrechnen.

Light-Version: Die Größe einer zu entwickelnden Software kann direkt in das Verhältnis zu ei- nem anderen, ähnlich entwickelten System gesetzt werden. Erfolgsfaktor: Ratsam ist es, "be- liebte" Maßzahlen zu nutzen und keine künstlichen zu erfinden. Wenn zum Beispiel in je- dem Projekt Use Cases beschrieben werden, ist es für alle Beteiligten ganz unkompliziert und auch natürlich, die Anzahl der Use Cases zu nutzen. Gleiches gilt für die Anzahl der Business- Objekte. Im Idealfall sollten diese Maßzahlen auch in ande- ren Zusammenhängen nutzbar sein oder bereits genutzt werden. So lassen sich Function Points im Betrieb zur Kostenumlage heranziehen, was nahe legt, diese auch für die Kalkulation zu verwenden.

Aufwand und Zeiten aus früheren Projekten hochrechnen

Der Aufwand eines Projekts kann im einfachsten Fall im Dreisatzverfahren aus einem früheren vergleichbaren Vor- haben ermittelt werden. Die Zeitstrecke ergibt sich aus Best-Practice-Annahmen. Die Anzahl der Beteiligten und die Zeitstrecke sollten dem Optimum entsprechend angesetzt werden. Im Idealfall lassen sich die Erfahrungen aus mehreren früheren Projekten nutzen und plausibilisieren.

Light-Version: Es reicht zunächst, den Aufwand des zu schätzen- den Projekts aus einem Vergleichsprojekt hochzurechnen. Das gelingt umso besser, je ausführlicher die Projekterfahrungen dokumentiert wurden, so dass sie auffindbar, verlässlich und in ihrer Bedeutung für die aktuelle Aufgabe einschätzbar sind. Zum Beispiel muss klar sein, welche Projektphasen berücksichtigt wurden oder ob ein Projekt-Management einbezogen war.

Aufwand und Zeiten nachjustieren

Auf den ersten Blick vergleichbare Projekte können bei genauerer Betrachtung sehr große Unterschiede aufweisen: Eine wichtige Rolle spielt etwa die Erfahrung der beteiligten Per- sonen. Erhebliche Differenzen verbergen sich möglicherweise auch hinter der Projektorgani- sation, dem Innovationsgrad der Lösung, den zu beachtenden Risikostufen oder hinter dem technischen Umfeld. Hier kann man von Cocomo lernen: Das Modell definiert 16 Effort Adjustment Factors (EAF), deren Bewertungen einen Justierungs- faktor für den Aufwand liefern. Erfahrungsgemäß ist dieser Faktor sehr hilfreich, auch wenn er ohne die anderen Teile des Verfahrens, die manchmal ohnehin einen zweifelhaften Wert haben, genutzt wird. Zudem zeigt der Faktor, dass ein tiefes Projektverständnis und eine interne Projektsicht für eine Kalkulation nötig sind.

Light-Version: Ein Experte hat die Möglichkeit, auf Basis seiner Projekterfahrungen Zu- oder Abschläge bei der Bewertung der neuen Aufgabe vorzunehmen. Als Erfolgsfaktor erweist sich hier, wenn Spezifika wie die Erfahrung des Projektteams, die technische Komplexität, die Tool-Unterstützung oder der Inno- vationsgrad der gesuchten Lösung klar dokumentiert und interpretierbar sind. Die Defini- tion konkreter und eindeutiger Faktoren ist dabei zwar nütz- lich, reicht aber nicht vollstän- dig aus. Besser als akademisch ausgetüftelte Kriterien ist eine verbale aussagekräftige Beschreibung.

Die hier beschriebenen Light-Verfahren zeigen deutlich, dass es erfahrene Projektexperten leichter haben, ein Software-Entwicklungsprojekt zu kalku- lieren. Mehr noch: Für eine verlässliche Aufwandsschätzung sind sie unabdingbar.

Bei dem hier vorgeschlage- nen Vorgehen wird aber nicht nur eigenes Wissen herange- zogen. Die Projektexperten nutzen zusätzlich das Wissen aus der Organisation, in der sie arbeiten.

Außerdem wird das Ergebnis der Aufwandsschätzung nachvollziehbar, weil Referenzen zu existierenden Projekten sowie unterschiedliche Projektaspekte wie die Systembeschreibung und Projektcharakteristika dokumentiert werden. Im Idealfall sollte parallel zu den Vorhaben eine Projekterfahrungs-Datenbank aufgebaut, gepflegt und genutzt werden.

Durch diese Offenlegung und Transparenz ist es möglich, die fertige Aufwandsschätzung zu kommunizieren und zu disku- tieren. Zudem kann im laufenden Projekt, wenn sich dieses klarer darstellt, nachjustiert werden. Damit wird die Kalkulation zu einem verlässlichen Management-Instrument bei der Projektsteuerung. (ue)

Empfehlung

Außenstehende können die IT-Projekte eines Unternehmens nicht kalkulieren. Nur Insider sind in der Lage, wirklich verlässliche Planungen zu erstellen.

Projektexterne Experten sind gezwungen, für die Schät- zung Benchmarks als Vergleichsgrößen heranzuziehen. Was diese jedoch für das individuelle Problem bedeu-

ten, ist völlig unklar, die Übertragbarkeit der Werte nicht

geklärt. Projekt-Manager sollten deshalb die Kosten für Software-Entwicklungspro- jekte in Eigenregie kalkulieren können.