Kalkulieren statt schätzen

16.02.2006
Von Robert Hürten

Messen der Funktionalität

Aus den Resultat-Gruppen können Maß- und Kennzahlen unterschiedlicher Art abgeleitet werden. Auf der Basis von Resultat-, Quell-Gruppen- und Resultat-Gruppen-Elementen lassen sich Funktionspunkte entsprechend der Function Point Analysis automatisch berechnen. Über diese Methode hinaus lassen sich auch Kennzahlen für die Komplexität der Funktionen bilden. Solche sind zum Beispiel die Verhältnisse von Resultat-Gruppen-Elementen/Quell-Gruppen-Elementen, Resultat-Gruppen-Elementen/Formeln oder die durchschnittliche Anzahl von Operanden in den Formeln.

Bedeutung der Erfahrungsdatenbank

Die gespeicherten Werte früherer Nachkalkulationen bilden die Grundlage neuer Kalkulationen. Aus den Nachkalkulationen lassen sich Produktivitätskurven ableiten, die je nach dem funktionalen Umfang einer Software den zu erwartenden Aufwand zeigen. Wichtig dabei ist zu prüfen, ob nicht verschiedene Klassen von Projekten und Entwicklungsumgebungen zu unterschiedlichen Produktivitätskurven führen. Dies wird dann der Fall sein, wenn Software regelmäßig für unterschiedliche Anwendungsgebiete und/oder Hard- und Softwareplattformen zu erstellen ist.

Ein Problem wird in der Praxis dadurch auftreten, dass Unternehmen in kurzen Abständen Technik und Methoden wechseln, um immer auf dem neuesten Stand der Technik zu sein. In diesem Fall kann sich keine stabile Kalkulationsgrundlage aufbauen. Das ist nicht nur für die Kalkulation schädlich. Gravierender für das Unternehmen ist in einer solchen Situation, dass die Mitarbeiter ihr Know-how nicht stetig verbessern können und damit auch die Softwareentwicklung nicht produktiver wird. Ob Letzteres der Fall ist, lässt sich erst durch eine regelmäßige Nachkalkulation verfolgen.

Ende der freischaffenden Künstler

Solange bei den Programmierern die Vorstellung besteht, dass sie als "Kreative" keine normgerecht formulierten Anforderungen verlangen und einhalten müssen, kann man kaum erwarten, dass Projekte zuverlässig kalkuliert werden.

Wie in der industriellen Fertigung haben sich die Softwareentwickler einheitlichen Normen und Methoden zu unterwerfen. Nach 40 Jahren Softwareentwicklung müsste es doch möglich sein, dass sich Institutionen wie zum Beispiel der Refa e.V., Verband für Arbeitsgestaltung, Betriebsorganisation und Unternehmensentwicklung in Darmstadt, dieser Thematik annehmen und Regelwerke schaffen, die dann in den Unternehmen auch strikt durchgesetzt werden. Es kann nicht so weitergehen, dass zwar unzählige Normen wie ISO oder DIN geschaffen werden, diese sich aber auf der Ebene der Systemanalytiker und Programmierer nicht durchsetzen lassen.

Die Arbeit der Verantwortlichen für Methoden und Tools in der Softwareentwicklung darf sich nicht wie in der Vergangenheit auf den Besuch von Messen und Kongressen beschränken, wo sie die neuesten Entwicklungen einkaufen. Sie müssen daran gemessen werden, ob durch ihre Tätigkeit Softwareentwicklung produktiver wird. Bei den Methoden und Tools darf nicht mehr das "Nice to have" im Vordergrund stehen, sondern das "Good for increasing productivity". Dies muss durch Kalkulationen und Nachkalkulationen dokumentiert und nachgewiesen werden. (hv)