Wirtschaftlichkeit ist die Fähigkeit, mit beschränkten Mitteln auszukommen. In der Welt der Produktion heißt das, mit möglichst wenig Betriebsmitteln in einer möglichst kurzen Zeit ein möglichst umfangreich und qualitativ hochwertiges Produkt zu liefern. Ein Software-System ist ein Produkt. Als solches hat es einen Umfang und eine Qualität. Sein Umfang - sprich Quantität - ist an der Anzahl seiner diskreten elementaren Funktionen sowie an der Anzahl seiner diskreten elementaren Datenelemente meßbar, seine Qualität dagegen an seiner Effektivität, Zuverlässigkeit und Rentabilität. Effektivität wird an Hand des Bedienungskomforts, des Zeitverhaltens und des Speicherbedarfs gemessen. Zuverlässigkeit ist eine Frage der Korrektheit und der Sicherheit Rentabilität läßt sich schließlich aufgrund der Wartbarkeit, der Ausbaufähigkeit und der Übertragbarkeit ermitteln.
Es versteht sich, daß es hier Zielkonflikte gibt. So zum Beispiel zwischen Effizienz und Komfort, zwischen Komfort und Sicherheit sowie zwischen Effektivität und Rentabilität. Das ist in der realen Welt, die von der Software abgebildet wird, nicht anders. Dort wimmelt es von Widersprüchen und Zielkonflikten. Wie kann es in der Software anders sein, die letzten Endes nur ein Spiegelbild der Wirklichkeit ist. Da gibt es schon den Konflikt zwischen Quantität und Qualität. Entweder macht man wenig gut oder viel oberflächlich. Man kann etwas in die Länge ziehen und dadurch Kosten sparen oder mit großem Aufwand in kurzer Zeit bewältigen. Wie in anderen Produktionszweigen stehen Quantität, Qualität, Zeit und Kosten in Wettbewerb miteinander. Sie bilden die vier Ecken des Teufelsquadrats (Siehe Abbildung 1). Für sich allein ist dieses Quadrat nur ein Denkmodell. Erst duch ein weiteres inneres Quadrat, das auf das andere gelegt wird, gewinnt es eine wirtschaftliche Bedeutung. Dieses zweite Quadrat stellt das Machbare dar. Seine Größe wird durch die Produktivität bestimmt. Zu irgendeinem Zeitpunkt hat ein Produktionsbetrieb eine gegebene Produktivität. In der Welt der industriellen Fertigung ist sie meßbar und wird in Produktionseinheiten ausgedruckt. In der Welt der Software-Produktion wird die Produktivitätsmessung durch die Unfaßbarkeit des Produkts erschwert. Was soll man messen? Die einen bewerten die Anweisungen im Programm, andere Ablaufzweige beziehungsweise Kanten im Ablaufgraphen, noch andere zählen die Datenein- und -ausgaben und andere messen Funktionspoints, die sich aus den Schnittstellen zwischen Vorgängen und Objekten ergeben. Aber allen Behauptungen zum Trotz hat sich noch kein Maßstab wirklich durchgesetzt. Darin liegt das Hauptproblem der Software-Wirtschaftlichkeit. Es ist hier noch nicht gelungen, Produktivität akkurat zu messen. Solange dies der Fall ist, ist Software in der gleichen Kategorie wie die bildenden Künste - eine nicht faßbare kreative Aktivität. Eine Software-Wirtschaftlichkeitslehre käme einer Wirtschaftlichkeitslehre der bildenden Künste gleich.
Sollte es aber gelingen, Software-Produktivität wirklich zu messen, wäre es auch möglich, eine Lehre der Software-Wirtschaftlichkeit zu propagieren. Dann wüßte man nämlich die Größe des inneren Quadrats in dem Teufelsquadrat und wäre in der Lage, dieses Quadrat beliebig zu verschieben - zum Beispiel in Richtung Quantität, wobei Qualität, Zeit und Kosten kürzer kämen, in Richtung Zeit, wobei an die Qualität, Quantität und Kosten Zugeständnisse erforderlich sind, in Richtung Zeit und Kosten, wobei Qualität Quantität geopfert werden oder in Richtung Qualität und Quantität, wobei hier Zeit und Kosten "Federn lassen müssen". Diese Manipulation setzt jedoch voraus, daß die Produktivität eine faßbare Größe ist. Dann wäre die Software-Wirtschaftlichkeit wie andere Wirtschaftlichkeiten eine Frage der Optimierung beziehungsweise eine Frage des Ausgleichs widersprechender Ziele - der Traum mancher Software-Manager.
Auf diesem Hintergrund ist das Opus - Software Engineering Economics - von Barry Boehm zu verstehen. Boehm, ein bekannter Software-Wissenschaftler, macht einen großen Wurf. Er bemüht sich, die ganze bisherige Forschung auf dem Gebiet der Software-Wirtschaftlichkeitslehre zusammenzufassen und auszuwerten. Gleichzeitig versucht er, eine praktische Lösung zum Problem der Software-Kostenschätzung anzubieten - ein von ihm ausgearbeitetes Kostenmodell - das Constructive Cost Model - "Cocomo" genannt. Daß auch dieses Modell nicht viel besser ist als die bisherigen Modelle darf niemand Boehm zum Vorwurf machen.
Software-Engineering ist eine viel zu junge und unreife Disziplin, als daß man eine wirklich fertige Lösung zu erwarten hätte. Die Stärken des Cocomo-Modells sind seine Erfahrensdatenbasis von 67 repräsentativen Projekten, seine Rücksichtnahme der wichtigsten Produktivitäts- und Qualitätsfaktoren, seine Berücksichtigung der Beziehung zwischen Zeit und Aufwand und seine Einbeziehung der Wartungskosten. Die Schwächen sind der Maßstab für die Messung der Systemgröße, nämlich die umstrittene "Lines of Code" und die willkürliche Gewichtung der Produktivitäts- und Qualitätsfaktoren die nachher miteinander multipliziert werden. Durch die multiplikative Gewichtung der Einflußfaktoren führt die Über- beziehungsweise Untergewichtung der Faktoren zu einem verzerrten Ergebnis.
Das Cocomo-Modell setzt die Definition des Systemumfangs voraus. Dieser Umfang wird jedoch erst sichtbar, wenn man die Vorgänge und Objekte des Systems spezifiziert hat. Aus der Anzahl der Objekte und Vorgänge und der Schätzung ihrer Komplexität wird die geschätzte Anzahl Anweisungen ermittelt. Je genauer der Umfang spezifiziert ist, desto genauer wird die darauf basierende Aufwandsschätzung. Neben der Quantität muß auch die Qualität des geplanten Systems zum Ausdruck kommen. Dafür werden Qualitätsfaktoren wie zum Beispiel Zuverlässigkeit, Wartbarkeit, Übertragbarkeit und Effizienz vorgegeben und gewichtet.
Die Eingaben der Cocomo-KaIkulation sind also
- Quantität (in Anweisungen) und
- Qualität (in Qualitätsmerkmalen).
Die Konstante der Kalkulation ist die gegenwärtige betriebliche Produktivität, die durch die gewichteten Produktivitätsfaktoren zum Ausdruck kommt.
Die Ausgaben der Kalkulationen sind:
- der Entwicklungsaufwand (in Mannmonaten)
- die Entwicklungszeit (in Kalendermonaten) und
- der jährliche Wartungsaufwand (in Mannmonaten).
Als erstes gilt es, die Quantität in Kilo-Anweisungen auszudrücken. Dazu muß man die Anzahl Funktionen und den Komplexitätsgrad jedes geplanten Vorgangs sowie die Anzahl Daten und den Integrationsgrad jedes Objekts schätzen. Aus dieser Schätzung läßt sich die Anzahl Verarbeitungs- und Beschreibungsanweisungen ableiten. Diese Zahl wird anschließend um einen Overhead-Faktor erhöht.
Zweitens werden die gewünschten Qualitätsmerkmale über eine Gewichtungstabelle in Multiplikationsfaktoren umgesetzt. Diese Faktoren reichen von 0,5 bis 3,0, der Aufwand kann also auf Grund der Qualitätsfaktoren verdreifacht werden. Die einzelnen Qualitätsfaktoren werden anschließend durchmultipliziert, um die Qualitätsgewichtung zu erreichnen. Die Gesamtqualitätsnote ist also das Produkt der einzelnen Qualitätsfaktoren (Siehe Abbildung 2).
Drittens wird die Produktivität des Betriebes durch einen ähnlichen Produktivitätsfaktor ausgedrückt. Dieser Faktor kommt durch die Bewertung verschiedener Subfaktoren zustande. Dazu gehören Hardware-Faktoren wie Rechnerkompatibilität, Testmodus, Rechnerverfügbarkeit und Speicherkapazität; Software-Faktoren wie Phasenkonzept, Methoden, Werkzeuge und Sprachen; sowie Personalfaktoren wie Ausbildung, Erfahrung, Sprachkenntnisse und Anwendungskenntnisse.
Die durchschnittliche Produktivität ist eines. Bei höherer Produktivität sinkt die Zahl, bei niedriger Produktivität steigt sie. Den größten Einfluß auf die Produktivität hat laut Boehm die Qualität der Mitarbeiter. Hochqualifizierte Mitarbeiter können vierfach produktiver sein als durchschnittliche, und sogar achtfach mehr als schlechtqualifizierte Mitarbeiter. An zweiter Stelle kommen die Hardware-Bedingungen. Durch bessere maschinelle Ausrüstung läßt sich die Produktivität nach Boehm um das Zwei- bis Dreifache erhöhen. Erst an dritter Stelle kommen die Software-Faktoren. Auch die besten Software-Werkzeuge und Methoden können die Produktivität nur um das Zweifache erhöhen. Wenn es also um eine Erhöhung der Produktivität geht, müssen zuerst qualifizierte Mitarbeiter herangeschafft werden, zweitens muß eine adäquate maschinelle Unterstützung zur Verfügung stehen, und drittens, müssen die nötigen Methoden und Werkzeuge eingeführt werden (Siehe Abbildung 3).
Erst nachdem die Quantität, Qualität und Produktivität feststeht, lassen sich die Cocomo-Formeln anwenden. Diese Formeln basieren auf Erfahrungswerten. Sie sind zum einen ein statistischer Durchschnitt verschiedener quantitativer Schätzverfahren. Es sind im einzelnen:
Walston/Felix
MM = 5,2 (QUAN) 0,91
Nelson MM = 4,9 (QUAN) 0,98
Basili MM = 1,5 (QUAN) 1,02
Jones MM = 1,0 (QUAN) 1,40
Halstead MM = 0,7 (QUAN) 1,50
Putnam MM = 2,5 (QUAN) 1,05
Zum anderen sind sie das Ergebnis einer Untersuchung von 67 verschiedenen Software-Projekten, bei denen die Produktivität in Anweisungen pro Manntag gemessen wurde. Diese Projekte kamen sowohl aus der kommerziellen Datenverarbeitung als auch aus der technisch/wissenschaftlichen und der systemtechnischen Programmierung. Allerdings haben sie alle in Kalifornien stattgefunden, wo möglicherweise andere Produktionsbedingungen herrschen als in der Bundesrepublik Deutschland.
Man hat die Produktivität in diesen Projekten in einen trigonometrischen X/Y-Graphen eingetragen und die Achsen geplottet. Daraus ergaben sich die Multiplikations- und Gewichtungsfaktoren für die Formel.
Die daraus resultierenden Formeln für die Aufwandsschätzung sind wie folgt:
für Batchsysteme
MM = 2,4 (QUAN) 1,05
x (QUAL x PROD)
für Online-Systeme
MM = 3,0 (QUAN) 1,12
x (QUAL x PROD)
für Realtime-Systeme
MM = 3,6 (QUAN) 1,20
x (QUAL x PROD)
Hinzu kommen die Formeln zur Berechnung der minimalen Kalenderzeit. Sie sind wie folgt:
für Batchsysteme
ZEIT = 2,5 (MM) 0,38
für Online-Systeme
ZEIT = 2,5 (MM) 0.35
für Realtime-Systeme
ZEIT = 2,5 (MM) 0,32
Schließlich gibt es auch eine Formel zur Berechnung der Wartungskosten. Sie lautet:
(MM (W)) Pro Jahr = MF (ACT)
x MM (E) x (2-WART)
wobei:
MM(W) = Mannmonate für die jährliche Wartung
MF = Multiplikationsfaktor 0,8 bis 1,2
ACT = Annual Change Traffic beziehungsweise Prozentsatz jährliche Änderung
MM (E) = Entwicklungsaufwand in Mannmonate
WART = Wartungsfreundlichkeit (0,1 bis 1,9)
Dies sind die Grundformeln des Cocomo-Systems.
Um die Grundformel zu erläutern soll ein Batchsystem mit 32 000 auslieferbaren Anweisungen als Beispiel dienen. Bei einer durchschnittlichen Qualität und Produktivität ist die Berechnung:
MM = 2,4 (32) 1,05 x (1 x 1)
MM = 91 Mannmonate
ZEIT = 2,5 (91) 0,38
ZEIT = 14 Monate
Bei kleineren Projekten ist die Produktivität höher, bei größeren Projekten ist sie niedriger. Deshalb sollte man stets bemüht sein, möglichst kleine Projekte zu planen. Im Prinzip heißt das, je mehr Leute an einem Projekt arbeiten, desto geringer ist die Produktivität des Einzelnen. Mit 32 K Anweisungen liegt die Produktivität bei 352 Anweisungen pro Mannmonat. Für Projekte mit 8 K Anweisungen liegt die Durchschnittsproduktivität bei 376 Anweisungen pro Mannmonat und für Projekte mit 128 K Anweisungen liegt die Durchschnittsproduktivität bei 327 Anweisungen pro Mannmonat.
Natürlich haben Qualität und Produktivität eine große Wirkung auf den Aufwand. Wenn die Qualitätsforderungen um 50 Prozent über dem Durchschnitt liegen, steigt der Aufwand von 91 auf 136 Mannmonate. Wenn aber die Produktivität um 100 Prozent erhöht wird, sinkt der Aufwand zurück auf 68 Mannmonate, denn 0,5 Produktivität X 1,5 Qualität ergibt 0,75 des Durchschnitts. Insofern hat die Gewichtung der Produktivität und der Qualität eine große Wirkung auf den Aufwand und die Projektdauer.
Das Cocomo-Modell teilt sich in drei Stufen:
- Elementary
- Intermediate und
- Advanced.
In dem Elementary-Modell werden die Grundformeln ohne Einbeziehung der Qualität und Produktivität angewandt. In dem Intermediate-Modell werden die Qualitäts- und Produktivitätsfaktoren mitberechnet. In dem Advanced-Modell werden darüber hinaus alle Subsysteme beziehungsweise sogar einzelne Vorgänge für sich geschätzt. Dafür bietet Boehm eine Reihe von Formularen zur Aufwandsschätzung der Komponenten an. Natürlich wird der Aufwand für die Schätzung dadurch erheblich höher, das Ergebnis aber viel genauer.
Für die Anwendung des Advanced Modells muß das System viel gründlicher spezifiziert sein. Je formaler die Spezifikation, desto besser die Kalkulation.
Leider wird die Produktivität nach diesem Verfahren immer noch in Anweisungen gemessen, da dieser Maßstab bisher der einzige gemeinsame Nenner in der Software-Welt war. Boehm hat ihn von seinem Vorgänger auf dem Gebiet der Aufwandsschätzung übernommen und nur verfeinert. Inzwischen bieten sich jedoch andere Maßstäbe an, zum Beispiel der Function Point.
Das Problem mit den Anweisungen liegt darin, daß sie in der Frühphase eines Projekts schwer zu schätzen sind. Außerdem sind sie von der Programmiersprache abhängig. Ein Programm in Cobol hat ungefähr 1,5 mal mehr Anweisungen als dasselbe Programme in PL/1. Function Points sind aber unabhängig von der Sprache. Man muß nur wissen, welche Vorgänge und Objekte zu programmieren sind und welche Beziehungen sie miteinander haben, das heißt welche Objekte Eingabe-Bewegungen, welche Ausgabe-Bewegungen und welche Objekte Stammdateien beziehungsweise Datenbanken bilden werden.
Zur Aufwandsschätzung nach der Function-Point-Methode sind lediglich Angaben zu den Anforderungen an das EDV-System aus der Anwendersicht notwendig - sogenannte Geschäftsvorfälle beziehungsweise Vorgänge. Die für diese "Black-box"-Betrachtung benötigten Informationen liegen natürlich früher vor als die Anzahl der Anweisungen, die vom technischen Konzept beziehungsweise vom Systementwurf abhängt. Auch lassen sich so Alternativen zur Realisierung besser vergleichen, da den zu realisierenden Funktionen innerhalb des Systems ihr Aufwandsanteil direkt zugeordnet werden kann. Im einzelnen sind den Vorgängen folgende Datenbeziehungen zuzuordnen:
- Eingaben, die zu verarbeiten sind
- Ausgaben, die angefordert werden und
- Datenbestände, die fortzuschreiben sind.
Außerdem werden noch verschiedene Randbedingungen des Projekts berücksichtigt, zum Beispiel Antwortzeitrestriktionen. Aufgrund dieser gewichteten Einflußfaktoren sowie der Vorgang/Objekt-Beziehungen und der Vorgangskomplexität errechnet man die Function Points. Die Umrechnung in Mannmonate erfolgt über eine unternehmensspezifische Kurve für die durchschnittliche Produktivität.
Neuere Untersuchungen haben gezeigt, daß schon mit einer Basis-Produktivitätskurve, Schätzungen mit einer Abweichung von ± 10 Prozent möglich sind. Bei fortschreitender Anwendung kann die Kurve unternehmensspezifisch angepaßt werden. Hieraus ist ersichtlich, daß mit der Function-Point-Methode ein lernendes Verfahren vorliegt, das heißt die bei laufenden und abgeschlossenen Projekten gemachte Erfahrung wird zur Verbesserung künftiger Schätzungen genutzt. Auch paßt sich das Verfahren so an sich ändernde Entwicklungsbedingungen selbständig an.
Das Cocomo- wie auch das Function-Point-Modell bieten Ansätze an, das Problem der Software-Wirtschaftlichkeit in den Griff zu bekommen. Keine dieser Methoden kann aber ohne ein ordentliches Software-Entwicklungsverfahren wirken. Sie müssen in das Phasenkonzept eingebettet werden. Wo ordentlich geplant und formal spezifiziert wird, lassen sich beide Methoden ohne nennenswerten Mehraufwand verwenden.
Wo, wie in den meisten deutschen Betrieben, heute weder sorgfältig geplant noch formal spezifiziert wird, kann weder die eine noch die andere Methode nützliche Ergebnisse bringen. Was in der deutschen Software-Landschaft Not tut, ist eine Systematisierung der Produktionsverfahren bei gleichzeitigem Einsatz moderner Produktionsmittel. Nur dann ließe sich eine stabile Erfahrungsdatenbasis aufbauen, aufgrund dessen man mit Cocomo oder mit Function Point schätzen könnte.
Zum Schluß soll darauf hingewiesen werden, daß sowohl die Cocomo- als auch die Function-Point-Methode in dem Buch "Aufwandsschätzung von DV-Projekten" von Thomas Noth und Mathias Kretzschmer, im Springer Verlag erschienen, ausführlich beschrieben sind. Dieses Buch ist die erste Darlegung der Software-Wirtschaftlichkeitslehre in deutscher Sprache. Das Buch von Boehm heißt "Software Engineering Economics" und ist im Prentice Hall Verlag erschienen. Beide Bücher gehören zur Grundlektüre eines deutschen Software-Managers.
Harry M. Sneed ist Geschäftsführer der Software Engineering Service GmbH, Neubiberg bei München.