In der Fachliteratur wird immer noch unwidersprochen behauptet, dass die Mehrzahl aller Softwareprojekte die geschätzten Kosten und Termine überzieht oder innerhalb der vorgesehenen Zeit nicht die vereinbarten Ergebnisse liefert. Begründet wird diese missliche Situation zum einen damit, dass Softwareerstellung ein kreativer und kaum kalkulierbarer Akt sei. Außerdem fehle es angesichts enger Terminvorgaben an der Zeit für eine aufwändige Detaillierung der Anwenderanforderungen.

Bei der Softwareentwicklung geht es aber im Wesentlichen darum, reale Vorgänge, Regeln und Zustände exakt abzubilden sowie den Computer anzuweisen, eine bestimmte, vorgegebene Arbeitsfolge auszuführen. Etwas abzubilden ist mit Sicherheit kein kreativer Akt. Ein Photoapparat oder ein Scanner kann das besser als jeder Maler. Kreativ ist allenfalls die Gestaltung neuer Vorgänge. Wenn aber zum Beispiel eine Fakturierung vom Postversand auf E-Mail umgestellt wird, so hat sich an dem zugrunde liegenden realen Vorgang des Waren-/Geldtauschs nichts verändert. Lediglich das technische Transportmittel ist ein anderes.

Das Resultat-Gruppen-Element Liefermenge

Resultat- Gruppen- Medium	Resultat- Gruppe	Resultat- Gruppen- Element	Formel	Quell- Gruppen- Element	Quell- Gruppe	Quell- Gruppen- Medium
Drucker	Lieferschein	Liefermenge	Liefermenge = Bestellmenge, wenn Lagermenge >= Bestellmenge	Bestellmenge	Erfassung	Terminal
-	-	-	Liefermenge = Lagermenge, wenn Lagermenge < Bestellmenge	Artikelnummer	Erfassung	Terminal
-	-	-	-	Lagermenge	Lager	Datei

Das Umsetzen einer vorliegenden Beschreibung in eine ablauffähige Befehlsfolge ist mit der Tätigkeit eines Übersetzers zu vergleichen. Diese zu automatisieren scheiterte bisher daran, dass man sich zur Beschreibung des Abbilds nicht auf eine einheitliche Grammatik, Syntax und Semantik einigen konnte. Auf der Seite der Computer ist man mit Compilern und Generatoren der Automatisierung sehr nahe gekommen. Solange jedoch für zu übersetzende Sprachen keine eindeutigen Regeln festgelegt sind, ist eine automatische Übersetzung unmöglich.

In der Praxis zeigt sich immer häufiger, dass Anwender terminliche Anforderungen an die Softwareentwicklung stellen, die bei den heutigen komplexen und integrierten Systemen nicht erfüllt werden können. Kleine Änderungen verlangen in der Regel den gleichen Testaufwand wie merklich größere, sofern man nicht Gefahr laufen will, dass ein Fehler in irgendeinem fernen Programmteil auftritt.

Die Kosten und Termine werden noch immer nicht auf der Grundlage einer zuverlässigen Kalkulation ermittelt. Vielmehr geben die Verantwortlichen Schätzungen ab, mit denen den Wünschen der Auftraggeber entsprochen werden soll. Das erste und folgenschwerste Ergebnis eines solchen Entgegenkommens ist, dass man sich nicht die Zeit nimmt, eine detaillierte, vollständige und verbindliche Aufgabenstellung zu verlangen beziehungsweise zu erstellen. Um eine gute funktionale Anforderung zu bekommen, sollte man einen Aufwand von zirka 20 bis 25 Prozent des späteren Gesamtaufwands einkalkulieren. Es ist der falsche Weg, diese 20 Prozent einsparen und auf ein verbindliches Pflichtenheft verzichten zu wollen.

Wer so vorgeht, berücksichtigt nicht, dass jede Funktion, die nachträglich in eine laufende Entwicklung eingebracht wird, wesentlich mehr Zeit benötigt und teurer ist, als wenn sie von Anfang an eingeplant wurde. Untersuchungen haben gezeigt, dass der Aufwand in solchen Fällen um das Sechsfache und mehr steigen kann. Auch führen die nachträglichen Änderungen zu unsauberen Programmstrukturen, die wiederum höhere Wartungskosten nach sich ziehen. Im Hinblick auf die funktionalen Anforderungen muss die Regel gelten: Die Zeit, die in das Ermitteln der Anforderungen investiert wird, spart ein Vielfaches im Gesamtprojekt.

Kalkulieren statt Schätzen

Damit die Softwareentwickler endlich von dem unsicheren Schätzen des Aufwandes zu einer zuverlässigen Kalkulation kommen, müssen sie ihre Arbeitsweise ändern. Besser wäre noch, dies anderen zu übertragen, die industrielle Produkte bereits effektiv kalkuliert haben. Entsprechend Erfahrungen aus dem Ingenieurswesen sollte folgendermaßen vorgegangen werden:

• Funktionale Anforderungen detailliert, vollständig und verbindlich definieren und nach einer einheitlichen Norm erstellen;

• den funktionalen Inhalt der Pflichtenhefte mit einem einheitlichen Maß messen;

• für jedes abgeschlossene Projekt eine Nachkalkulation erstellen, die neben dem Aufwand auch die effektiv realisierte Funktionalität nachweist;

• aus den historischen Nachkalkulationen Produktivitätskurven ableiten, die Rückschlüsse auf den zu erwartenden Aufwand erlauben;

• ein Kalkulationsbüro außerhalb der eigentlichen Softwareentwicklung einrichten, das die zentrale Verantwortung für die Kalkulation hat und sich nach den Erfahrungen der industriellen Fertigung richtet.

Funktionale Anforderungen

In den funktionalen Anforderungen muss der Anwender alle Resultate beschreiben, die ihm die Software liefern soll. Das können kaufmännische Ergebnisse, Informationen zur Steuerung von Maschinen, Bedienung von Schnittstellen, Speicherung von Ergebnissen und anderes sein. Die Norm für die Darstellung der Resultate kann sehr einfach gestaltet werden.

Ein Beispiel: Jedes Resultat wird durch eine Gruppe folgender Informationen beschrieben:

• Resultat-Gruppen-Bezeichnung (etwa Rechnung oder Steuersignal für Sicherheitsventil);

• Resultat-Gruppen-Elemente (alle Informationen einer Resultat-Gruppe mit ihren Verknüpfungen zu ihren Quellen aufführen);

• Resultat-Gruppen-Medium (festlegen, auf welchem Medium der Anwender das Resultat erhalten will);

• Resultat-Gruppen-Layout (der Anwender definiert, in welchem/r Layout/Struktur die Elemente des Resultats zu liefern sind);

• Resultat-Gruppen-Auslöser (der Anwender bestimmt, unter welchen Bedingungen und an welchen Stellen in einem Workflow das Resultat zur Verfügung stehen muss.)

Diese Anforderungen können vom Anwender ohne spezielle IT-Kenntnisse definiert werden. Er muss allerdings selbst genau wissen, welche Resultate er benötigt, um seine geschäftlichen oder technischen Ziele zu erreichen. Hier sind vielleicht auch wieder die klassischen Organisatoren gefragt, die darauf geschult sind, die betrieblichen Anforderungen zu erkennen und logische Abläufe zu gestalten. Die einheitliche Darstellung eines Resultat-Gruppen-Elements kann in einer Tabelle erreicht werden (siehe Kasten "Anforderungs-Ermittlung").

Dieses simple Verfahren ist nicht nur unter dem Aspekt der Kalkulation von Bedeutung. Die Resultat-Gruppen sind sehr langlebige Dokumentationen. So werden sich beispielsweise bei einer Umstellung eines Lieferscheins vom Postversand auf E-Mail im Wesentlichen nur das Medium und das Layout ändern. Die Resultat-Gruppen-Elemente müssten wahrscheinlich nur um die E-Mail-Adressen erweitert werden.

Eine Organisation der Resultat-Gruppen analog zu den Stücklisten wird für Wartung und Programmpflege wesentliche Vorteile bieten. So würde im genannten Beispiel eine Informationsverwendungs-Liste automatisch alle Resultat-Gruppen anzeigen können, in denen Anschriften mit E-Mail-Adressen ergänzt werden müssen.

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)