Von Harry Sneed*

Um den Aufwand eines Softwareprojekts abzuschaetzen, gibt es eine Reihe von unterschiedlichen Methoden. Nicht alle sind jedoch sinnvoll. Ausserdem stellt die Wahl des richtigen Verfahrens nur einen von vier Faktoren dar, mit deren Hilfe sich das Risiko der Aufwandskalkulation minimieren laesst. Der wichtigste ist wohl die

Erfahrung des Schaetzers.

Der Markt verlangt, dass die Kosten und die Dauer eines Softwareprojekts, sei es ein Entwicklungs-, Wartungs- oder ein Sanierungsvorhaben, schon im voraus bekannt sind. Dieser Wunsch ist verstaendlich. Wer will nicht wissen, wieviel er fuer eine Leistung bezahlen und wie lange er darauf warten muss?

Andererseits ist die Aufwandsschaetzung von Softwaredienstleistungen eine aeusserst schwierige Angelegenheit mit vielen teuflischen Ungewissheiten. Es gibt zwar einige sinnvolle Regeln, die man getrost befolgen kann. Aber ebenso existieren jede Menge unsinniger Praktiken, die durch Unwissen und Unerfahrenheit in die DV-Welt getragen werden.

Wer Softwareprojekte kalkulieren muss, geht ein grosses Wagnis ein. Der Stand der Schaetzkunst ist laengst nicht so weit gediehen, dass irgendein Experte auch nur annaehernd risikolos operieren koennte. Ergo sind alle Software-Anbieter, die Festpreisprojekte offerieren, Hasardeure.

Externe Softwarehaeuser haben mit verlaesslichen Kostenprognosen besondere Schwierigkeiten, weil sie als Aussenseiter die anwendungsspezifische Umgebung oft nur unzureichend kennen. Jeder Anwender ist mit seiner eigenen Umgebung vertraut und hat daher den Vorteil auf seiner Seite, wenn es darum geht, zuverlaessige Aussagen zu machen. Denn eins steht inzwischen fest: Softwareproduktivitaet ist umgebungsabhaengig und wird es immer bleiben.

Folglich ist es muessig, eine Durchschnittsproduktivitaet zu definieren, die allenfalls einen akademischen Wert besitzen kann. Es gibt einfach keine Durchschnittsprojekte. Jedes Projekt und jede Projektumgebung sind einmalig. Das gilt auch dann, wenn das selbe Vorhaben am selben Ort zwei Jahre spaeter noch einmal durchgefuehrt werden koennte. Solange der Mensch die Hauptlast der Softwareprojekte traegt, werden diese Vorhaben weitgehend undeterminierbar bleiben.

In dem Masse aber, wie die Technik ermoeglicht, den Menschen aus dem Software-Entwicklungs- und -Wartungsprozess herauszudraengen, sprich: diesen Prozess zu automatisieren, steigt die Schaetzbarkeit. Produktionsprozesse in anderen Bereichen der Volkswirtschaft sind nur deshalb relativ gut kalkulierbar, weil der menschliche Anteil stark reduziert wurde. In der Softwareproduktion hingegen haengt die Produktivitaet sehr stark von der Kreativitaet, vom Know-how und von der Motivation der Projektmitarbeiter ab. Dies ist eine bittere Wahrheit.

Da es aus heutiger Sicht unmoeglich ist, den Unsicherheitsfaktor bei der Aufwandskalkulation auszuschalten, kommt es darauf an, ihn wenigstens zu verringern. Erst wenn sich diese Erkenntnis durchgesetzt hat, ist es sinnvoll, ueber den Nutzen von Schaetzmethoden zu diskutieren.

Minimieren laesst sich das Risiko der Aufwandsschaetzung durch folgende vier Faktoren:

- Erfahrung des Schaetzers,

- Wiederholbarkeit des Prozesses,

- Messwerte aus vergangenen Projekten,

- Wahl der geeigneten Schaetzmethode.

Am wichtigsten ist vielleicht die Erfahrung des Schaetzers. Derjenige, der ein Softwareprojekt kalkuliert, sollte unbedingt schon einige vergleichbare Vorhaben geschaetzt haben. Er muss mit der Applikation und der verwendeten Softwaretechnologie vertraut sein. Demzufolge sind die Erfahrungen des Schaetzers nur bedingt uebertragbar. Neuland betritt er beispielweise dann, wenn sich seine Kenntnisse hauptsaechlich auf die konventionelle Entwicklung beschraenken, er aber ein objektorientiertes Softwareprojekt schaetzen soll. Das gilt auch fuer unterschiedliche Rechnerarchitekturen. Wer bisher ausschliesslich Mainframe-Projekte durchgefuehrt und kalkuliert hat, wird mit Client-Server-Vorhaben erst einmal Erfahrungen sammeln muessen. Leider sind die Moeglichkeiten dafuer zeitlich und raeumlich begrenzt. Deshalb muessen externe Schaetzer den Aussagen der internen Mitarbeiter grosses Gewicht beimessen.

Die Haelfte der Module ist beim Start vorhanden

Ebenfalls sehr wichtig ist die Wiederholbarkeit der Prozesse fuer Entwicklung, Wartung beziehungsweise Sanierung von Software. In dem Masse, wie Vorgaenge aus bereits bewaeltigten Projekten fast unveraendert in die neuen Vorhaben uebernommen werden, steigt die Schaetzbarkeit der Produktivitaet.

Das trifft in besonderem Masse auf die Sanierung zu. Zum einen sind die Arbeitsschritte dort fast immer die gleichen und koennen zum Grossteil wiederholt werden. Zum anderen lassen sich auch Softwarebausteine aus bisherigen Projekten nutzen. Je groesser der wiederverwendete Teil ist, desto weniger neue Module muessen geschaetzt werden. Einige Softwarehaeuser arbeiten bereits nach der Maxime, dass nur Projekte angenommen werden, bei denen schon beim Start 50 Prozent der Software vorhanden ist. Denn je mehr Prozesse und Produkte wiederverwendet werden, desto sicherer ist die Kalkulation und desto geringer faellt das Risiko aus.

Nicht zu vernachlaessigen ist aber auch die Bedeutung gueltiger Messwerte fuer die eigene Leistung. Die Uebernahme betriebsfremder Produktivitaetswerte kann nur als Einstieg in eine Schaetzmethodik dienen. Verlassen sollte man sich auf keinen Fall darauf. In der Regel ist die Produktivitaet von grossen buerokratischen Organisationen geringer als die von kleinen, flexiblen Business- Einheiten. Hoechste Produktivitaet entwickelt sich bei Einpersonen- Projekten. Anerkannte Feldexperimente ergaben, dass die Produktivitaet einzelner Programmierer zwischen den Faktoren eins bis 25 liegt, die von Organisationen aber nur bis zehn reicht.

Es ist daher absurd, zu glauben, dass eine Function-Point- Produktivitaetstabelle, die die IBM fuer Grossrechnerprojekte aus den 70er Jahren erstellt hat, auf ein Client-Server-Projekt uebertragbar ist, das beispielsweise mit einem 4GL-Produkt erstellt werden soll. Die Softwareproduktivitaet steigt zwar nicht so schnell, wie manche CASE-Hersteller versprechen, aber sie waechst doch stetig von Jahr zu Jahr.

Unterschiede ergeben sich auch aus der Kultur, in deren Rahmen die Projekte stattfinden. Die Produktivitaet in Deutschland mag also ganz anders sein als die in Japan oder in den USA. Auch innerhalb Deutschlands kann sie von Betrieb zu Betrieb stark schwanken - je nachdem, wie die Projekte organisiert und geleitet beziehungsweise die Mitarbeiter motiviert werden.

Es empfiehlt sich daher, dass jedes Unternehmen seine ureigensten Produktivitaetsmetriken erfasst und auswertet. Denn nur mit eigenen Daten koennen algorithmische Schaetzmethoden kalibriert werden, und nur kalibrierte Kalkulationen versprechen exakte Werte. Leider gibt es wenige Firmen in Deutschland, die solche Metriken erfassen und pflegen. Die Mehrzahl der Betriebe hat lediglich Mutmassungen ueber ihre Produktivitaet angestellt.

Das Geschaeft bleibt bis auf weiteres risikoreich

Der vierte risikoreduzierende Faktor besteht in der Anwendung einer systematischen Schaetzmethode. Hier gibt es inzwischen eine grosse Auswahl. Beispielsweise kann nach Lines of Code, Komponenten, Function Points, Data Points und sogar nach Object Points kalkuliert werden. All diesen Verfahren gemeinsam ist, dass ihre Aussagekraft nicht von den Eingabedaten abhaengt.

Wenn die drei anderen Voraussetzungen nicht stimmen, kann auch die beste Schaetzmethodik keine zuverlaessige Kalkulation produzieren. Davon abgesehen sind diese Verfahrensweisen moeglicherweise sehr nuetzlich. Werkzeugunterstuetzung erlaubt es, den Kalkulationsprozess zu strukturieren und wiederholbar zu machen. Die dabei gesammelten Erfahrungen koennen immer wieder in den Prozess eingespeist werden.

Unsinn ist aber die Annahme, Erfahrung und eigene Produktivitaetswerte liessen sich durch eine einzige Methode ersetzen. Ebenso sinnlos ist das Festhalten an einer Durchschnittsproduktivitaet. Der groesste Irrtum entsteht jedoch durch den Glauben an eine risikolose Softwareprojekt-Kalkulation. Software-Entwicklung ist und bleibt - zumindest in den kommenden Jahren - ein High-Risk-Business. Wer sich auf Festpreisprojekte einlaesst, muss wissen, dass seine Kalkulation nur so gut ist wie seine Erfahrung, seine Daten, seine Schaetzmethodik und die Wiederholbarkeit beziehungsweise die Wiederverwendbarkeit seiner Arbeitsergebnisse.