In Kapitel 2 wurden die Kosten als zentrales Thema eingeführt. Nachfolgend werden diese Überlegungen konkret auf das Software Engineering angewandt. Dabei geht es um grundsätzliche Überlegungen zu Nutzen und Kosten; konkrete Methoden der Kostenschätzung werden in Abschnitt 8.4 behandelt.
Die Ziele derer, die ein Software-Projekt in Auftrag geben oder die es durchführen, sind zu einem beträchtlichen Teil irrational, denn die persönlichen Interessen (die meist unbewusst bleiben) sind nur selten die Interessen der Organisation. Dieser Punkt wird hier nicht vertieft, er wäre ein ergiebiges Thema für ein Buch über Software-Psychologie.
In vielen Situationen ist es völlig klar, ob eine benötigte Software gekauft oder neu entwickelt werden muss. »Kaufen« bedeutet in diesem Zusammenhang eigentlich »Wiederverwenden«; es spielt dabei grundsätzlich keine Rolle, ob dafür etwas bezahlt wird. Wenn es um Betriebssysteme, Compiler, Frameworks und andere hochkomplexe Standard-Software geht, wird niemand an eine Eigenentwicklung denken, auch wenn es dann und wann solche gegeben hat (z. B. Linux). Umgekehrt ist bei sehr speziellen Anwendungen klar, dass sie auf dem Markt nicht zu finden sind. Wer eine neuartige Benzineinspritzung produzieren will, muss auch die Software dafür entwickeln oder entwickeln lassen.
Zwischen diesen Extremen gibt es aber eine breite Grauzone, in der zwei Modelle miteinander konkurrieren, make or buy, Neuentwicklung versus Wiederverwendung. Die Neuentwicklung kann dabei im eigenen Hause stattfinden oder in Auftrag gegeben werden; Wiederverwendung kann sowohl durch den Einsatz eines Software-Produkts vom Markt als auch durch die Anpassung einer vorhandenen Software stattfinden. (Auch die Software vom Markt muss eventuell angepasst werden.)
So wie der Maßschneider in der Regel nicht dazu rät, den alten Anzug zu verändern, sondern lieber einen neuen schneidert, plädieren die Entwickler meist für die Neuentwicklung. Ihr wichtigstes Argument ist die größere Flexibilität, die präzise Erfüllung der Anforderungen. Für den Kauf oder die Wiederverwendung spricht, dass man rasch eine ausgereifte Software bekommt. Damit gewinnt man Zeit und Planungssicherheit.
Entschieden wird am Ende meist auf der Grundlage der zu erwartenden Kosten. Allerdings vergleicht man dabei die bekannten Kosten für den Kauf oder die nicht genau bekannten Kosten der Anpassung mit den nur sehr ungenau zu schätzenden Kosten der Neuentwicklung. Gerade wenn die perfekte Lösung angestrebt wird, sind erhebliche Kostenüberschreitungen eher die Regel als die Ausnahme.
So kommt es oft wie in Abbildung 4–1 gezeigt: Man entscheidet sich für die Neuentwicklung, weil sie, so die Annahme, zu einem geringeren Preis eine bessere Software schafft. Wenn die Entwicklung fortschreitet, steigen die Kosten weit über die erste Schätzung. Die käufliche Software wird zur selben Zeit möglicherweise billiger, oder ihr Funktionsumfang wächst. Am Ende hat man ein teures System gebaut, das man nun auch lange Zeit warten muss; bei der käuflichen, schnell verfügbaren Software wäre eine regelmäßige Wartung für sehr viel weniger Geld zu haben.
Allerdings muss gewährleistet sein, dass der Software-Hersteller noch lange Zeit Reparaturen, Anpassungen und Portierungen vornimmt; seine Stabilität ist also sehr wichtig. Um sich bei einer Pleite des Lieferanten wenigstens den Zugriff auf den Quellcode zu sichern, kann man eine Hinterlegungsvereinbarung treffen (Escrow Agreement). Dann wird die jeweils aktuelle Fassung der Software in regelmäßigen Abständen bei einem Treuhänder hinterlegt. Unter festgelegten Bedingungen bekommt sie der Kunde ausgehändigt. Damit ist aber noch nicht sichergestellt, dass er mit der Software auch etwas anfangen kann.
Abb. 4–1 Entscheidung zur Neuentwicklung nach optimistischer Aufwandsschätzung
Bei einer Wiederverwendung entstehen die Kosten durch die meist größeren Anpassungen (siehe Abschnitt 24.3.1), und die Wartungsproblematik ist komplizierter als bei einer Standard-Software. Damit liegt die Wiederverwendung mit ihren Vor- und Nachteilen zwischen Kauf und Neuentwicklung.
Das bedeutet: Sofern es sich um Software handelt, die das zentrale Knowhow der Firma enthält, gibt es zur Eigenentwicklung keine Alternative. Liegt die Leistung der Software aber nicht im Kern des Geschäfts, das das Unternehmen betreibt, so ist ein Kauf oder eine Wiederverwendung fast immer vorteilhaft. Die ganz neue, ideale Software ist meist ein teurer Traum, dessen hohe Kosten wesentlich zuverlässiger sind als seine Verheißungen.
Wir hatten bereits in Abschnitt 2.1 ausführlich diskutiert, dass es beim Software Engineering, und damit auch bei der Durchführung von Software-Projekten, um
die Minimierung der Kosten und
die Maximierung des Nutzens
geht. Dieses Thema wird hier erneut angesprochen, diesmal mit deutlich engerem Verständnis von Nutzen und Kosten.
Der Nutzen einer Software ist durch den mittels der Software erzielbaren Vorteil bestimmt, beeinflusst durch
den Grad der Übereinstimmung zwischen Produkt und tatsächlichen Anforderungen,
zusätzliche Leistungen, Komfort und Flexibilität.
Hier ist von den tatsächlichen Anforderungen die Rede; wir müssen grundsätzlich davon ausgehen, dass es keine Möglichkeit gibt, diese Anforderungen exakt und vollständig zu erheben, vor allem weil sie auch den Benutzern nicht bewusst sind. Außerdem ändern sich die Anforderungen während der Entwicklung. Diese Probleme werden in Kapitel 16 ausführlich diskutiert.
Zusätzliche Leistungen, Komfort und Flexibilität bedienen Wünsche, die erst mit dem Einsatz oder während des Einsatzes entstehen. Das spielt vor allem bei Produkten für den Markt eine Rolle. Wer eine Software zur Verwaltung von Musikstücken kauft, wird sich vielleicht für ein Produkt entscheiden, bei dem ein Musiklexikon integriert ist, obwohl das Vorhandensein dieser Komponente keine Anforderung des Käufers war.
Die Kosten sind vor allem Herstellungs- und Betriebskosten. (Natürlich ist es hier willkürlich, den Komfort beim Nutzen aufzuführen; er könnte ebenso komplementär bei den Kosten erscheinen, dann als Mangel an Komfort.) Die folgende allgemeine Gegenüberstellung (Tab. 4–1) ist dem Buch von Jones (1990, S. 87/8) entnommen.
Benefits |
|
Labor during development |
Use of existing labor |
Labor during operation |
Reduced operational labor |
New equipment? (purchase, maintenance, depreciation) |
Replacement of equipment maintenance? (sale, maintenance, depreciation) |
New software purchases |
Other use of new software |
Conversion from old system to new |
Improvement of system |
Increased data gathering |
Increased control |
Employee discontent |
Employee satisfaction |
Training for employees |
Increased productivity |
Lost opportunities |
Better market stance, basis for further growth |
Tab. 4–1 Kosten und Nutzen nach Jones
Im konkreten Fall muss man versuchen, Kosten und Nutzen abzuschätzen und damit zu bestimmen, wie lange es dauert, bis sich die Investition auszahlt. Abbildung 4–2 zeigt schematisch, wie der Break-even-Point bestimmt werden kann.
Abb. 4–2 Bestimmung des Break-even-Points (nach Jones, 1990)
Allerdings enthält diese Abschätzung unvermeidlich eine Reihe von Annahmen, die kaum gesichert werden können, sowohl im Bereich des Nutzens (vor allem beim nicht messbaren Nutzen, der hier die Differenz zwischen messbarem Nutzen und Gesamtnutzen begründet) als auch bei den Kosten (Entwicklungskosten, Zinsentwicklung usw.). Die Abschätzung ist also spekulativ. Man muss auch beachten, dass die leere Alternative oft nicht gegeben ist, d. h., es ist z. B. nicht möglich, einfach abzuwarten, wenn die Hardware nicht mehr wartbar ist oder eine Änderung nicht mehr aufgeschoben werden kann. Schließlich lässt sich nicht ausschließen, dass nach der Entscheidung über eine Neuentwicklung Änderungen eintreten, die der Kalkulation die Grundlage entziehen.
Bei der Software-Bearbeitung entstehen die größten Kosten durch die Gehälter. Weitere erhebliche Kosten verursachen Räume, Rechner und Netzwerke sowie Software, die Teil der Infrastruktur oder auch Teil des Produkts ist. Tabelle 4–2 zeigt links die permanent anfallenden Kosten, rechts solche Kosten, die durch das Projekt verursacht sind.
Laufende Kosten |
Projektbezogene Kosten |
Gehälter |
Kosten des Zeitpersonals |
Management, Werbung |
Vertragskosten |
Räume |
Spesen |
Rechner, Netzwerke und Software als Teile der Infrastruktur |
Hardware und Software als Teile des Produkts bzw. der Anlage |
Tab. 4–2 Laufende und projektbezogene Kosten
Die Aufwandsverteilung hängt natürlich sehr stark vom gewählten Entwicklungsmodell ab. Wenn nach dem Prinzip »Code and Fix« (Abschnitt 9.1.1), gearbeitet wird, fließen (scheinbar) 100 % des Aufwands in die Codierung. Geht man nach einem Phasenplan vor, ist eine Verteilung 40/20/40 (Aufwand vor, für und nach der Codierung, Zahlen nach Boehm, 1987) angemessen. Bei modernem Vorgehen wird der Aufwand nach vorn verlagert, d. h., der Aufwand für Spezifikation und Entwurf steigt, der für den Test sinkt (60/15/25; vgl. Baskette, 1987).
»Nach Gefühl« wird der Kostenanteil der Codierung oft überschätzt, er macht in Wahrheit etwa 15 bis 20 % der Entwicklungskosten aus. Mehr lässt sich dabei also auch nicht einsparen! Dagegen wird der Test unterschätzt; je weniger nach jedem der frühen Entwicklungsschritte geprüft wird, umso höher ist sein Anteil, er kann über 50 % liegen, wenn man wie üblich die Korrekturkosten zu den Testkosten zählt.
Die Kosten der Integration werden oft völlig vergessen. Natürlich geht es dabei nicht einfach um das Binden der Teilresultate, sondern um eine verkappte korrektive Wartung, die dafür sorgt, dass sich die Teile am Ende doch zusammenfügen lassen. Der dafür notwendige Aufwand kann den für die Codierung übersteigen. Bei systematischem Vorgehen ist der Integrationsaufwand viel kleiner.
Man betrachte zum Vergleich das Vorgehen beim Bau des Eiffelturms: Die Stahlteile wurden am Fuße des Turms fertig bearbeitet und dann nach oben gezogen. Passten die Bohrungen für die Nieten nicht, dann wurde das Teil wieder heruntergelassen und unten in Ordnung gebracht oder ersetzt. Im Stahlbau war das 1889 revolutionär, in der Software wäre es noch heute ungewöhnlich, denn die Komponenten werden meist rasch und ohne Skrupel modifiziert, bis der Linker Ruhe gibt!
Mit dem Betrieb beginnt auch die sogenannte Wartung (Korrektur, Anpassung und Erweiterung, siehe Kap. 22); sie kostet – über die gesamte Lebensdauer – meist mehr oder sogar viel mehr als die Entwicklung, 2/3 des Aufwands oder mehr gehen in die Wartung (Abb. 4–3).
Abb. 4–3 Kostenverteilung – ohne/mit Berücksichtigung der Wartung (nach Boehm)
Die Qualitätskosten, die als Aufwände für die Sicherung und Steigerung der Qualität (Prävention) oder auf Grund mangelnder Qualität (Reparatur- und Folgekosten) entstehen, können u. U. die nackten Herstellungskosten übersteigen. Am deutlichsten wird dieser Effekt, wenn durch einen Software-Fehler hohe Folgekosten entstehen. Das ist nicht nur bei den spektakulären Anwendungen in der Steuerung von Kernkraftwerken oder Waffensystemen der Fall, sondern auch bei vielen Informationssystemen (Banken) und bei scheinbar unproblematischen Massenartikeln wie Spielzeugen, wo eine Rückrufaktion den Hersteller in den Ruin treiben kann. (Darum waren die Puppenhersteller unter den ersten Sponsoren der Forschung zum Thema Programmtest.)
Abbildung 4–4 zeigt schematisch die Differenzierung der Software-Kosten. Die Aufwendungen für die Fehlerverhütung sind also nicht an den Netto-Herstellungskosten zu orientieren, die auch bei schlechtester Qualität anfallen, sondern an den Gesamtkosten. Die Qualitätskosten können leicht dominieren, also die Netto-Herstellungskosten übersteigen. Wenn die Herstellung einer Software 10 000 € kostet, aber mit einer Wahrscheinlichkeit von 10-3 ein durch die Software verursachter Schaden von 20 Mio. € auftritt, dann sind die Fehlerkosten statistisch doppelt so groß wie die Herstellungskosten. Es lohnt sich dann, durch Aufwand für die Qualitätssicherung in der Größenordnung der Netto-Herstellungskosten die Fehlerkosten zu drücken.
Abb. 4–4 Kostendifferenzierung in Richtung Fehlerkosten
Die Software-Entwicklung läuft bis zur Codierung top-down, d. h. vom Allgemeinen (Aufgabe) zum Speziellen (Code); nach der Codierung bottom-up, von der Code-Zeile zum Gesamtsystem. In diesem Zusammenhang sind zwei verschiedene, sich verstärkende Phänomene wichtig:
Fehler werden meist auf derselben Abstraktionsebene entdeckt, auf der sie begangen wurden (Abb. 4–5). So zeigt sich beispielsweise ein Entwurfsfehler nicht in der Codierung, sondern beim Versuch, die Module zu integrieren1.
Fehlerkosten steigen mit der Latenzzeit exponentiell an, d. h., die Kosten eines Fehlers in der Spezifikation steigen auf das Hundertfache, wenn er nicht sofort, sondern erst nach Auslieferung entdeckt wird (Abb. 4–6). Bezugsgröße ist der Schaden durch einen Fehler, der sofort (z. B. innerhalb einer Stunde oder eines Tages) entdeckt wird.
Abb. 4–6 Relative Fehlerkosten über der Latenzzeit nach Untersuchungen bei IBM, GTE, TRW, DoD (Boehm, 1979)
Offensichtlich fallen also früh begangene Fehler erst spät auf und erzeugen dann gewaltige Kosten. Daher rentiert sich auch ein sehr hoher Aufwand, um sie zu vermeiden. Die Vermeidung früher (d.h. teurer) Fehler hat höchste Priorität!
