Hardwarekosten sind heute im Bewußtsein des DV-Managements und der Unternehmensführung fest verankert und oft ein beliebter Diskussionsgegenstand. Demgegenüber haben die Softwarekosten nicht annähernd den gleichen Stellenwert in Diskussionen, sondern man beklagt lediglich die Softwarekrise oder zitiert abgeklärt das Gesetz von Murphy, nach dem bei der Software all das schief geht, was schief gehen kann.

Möchte man die Kosten wirtschaftlicher Software betrachten, dann ist zuvor die Klärung des Begriffs "wirtschaftlich" sinnvoll. Unter Wirtschaftlichkeit wird das Verhältnis von Leistung zu Kosten verstandene Die Leistung des Produktes Software wird wesentlich durch Qualitätsmerkmale bestimmt. Der heutige Praxisstand ist dabei nicht zufriedenstellend.

Wie bei vielen anderen Produkten bildet sich auch bei der Software eine Lebenszyklusbetrachtung heraus. Man unterscheidet Softwareentwicklung, Softwarebetrieb und - da es offensichtlich ein beträchtlicher Aufwand ist - Softwarewartung. Es liegt nahe, die Lebensphasen auch für eine Kostenbetrachtung zu verwenden.

Die Kostenbetrachtung erfolgt klassisch in den Dimensionen der Kostenarten, Kostenstellen und Kostenträger und kann der Wirklichkeit zeitlich vorgelagert sein - Kostenplanung -, zur Wirklichkeit synchron verlaufen oder ihr zeitlich nachgelagert sein - Kostenkontrolle.

LoC-Formeln nicht zufriedenstellend

Bei der Analyse der Kostensituation in der Software-Entwicklung fällt insbesondere auf, daß verläßliche Unterlagen für eine Kostenplanung fehlen. Hiermit sind Verfahren der Aufwandsschätzung gemeint. Man hat den Eindruck, daß heute Verfahrensansätze, die es schon einmal Mitte der 60er Jahre gab, eine kräftige Wiedergeburt erleben: die Lines-of -Code-Betrachtungen.

Nun ist es in der Tat verlockend, eine Basisgröße wie LoC zur Schätzung des Aufwandes und möglicherweise sogar der Zeit für die Software Entwicklung heranzuziehen. Allerdings waren die Erfahrungen mit den damaligen LoC-Formeln nicht zufriedenstellend, ganz abgesehen davon, daß sich prinzipielle Argumente gegen eine solche Basisgröße finden lassen. Es lohnt jedoch, einen Blick auf die inzwischen eingetretene Entwicklung zu werfen. Aus jeweils einer großen Zahl von Daten über abgelaufene Entwicklungsprojekte haben viele Autoren mit Hilfe statistischer Verfahren Schätzmodelle erarbeitet.

Als Beispiel sei das Schätzmodell von Boehm kurz skizziert:

- Eine grobe (und damit ungenaue) Version des Schätzmodelles hat die Form:

Mannmonate = 2,4 LoC 1,05

1000

- Eine verfeinerte (und damit genauere) Version des Schätzmodells hat für normale ("organic") Entwicklungsprojekte die Form:

Mannmonate 15 SDEMi * 3,2

i=l

LoC 1,05

1000

Hinter der Größe 15 SDEMi . 3,2

i=1

verbergen sich Einflußfaktoren, die sich auf:

- Softwareprodukteigenschaften (zum Beispiel Produktkomplexität),

- Eigenschaften der Hardware, auf dr. (oder für die) das Softwareprodukt entwickelt wird (zum Beispiel Speicherbegrenzungen),

- Eigenschaften der Entwicklungsmitarbeiter (zum Beispiel Entwicklungserfahrung),

- Projekteigenschaften (zum Beispiel der Einsatz von Entwicklungswerkzeugen) beziehen.

Ohne Details dieses Schätzmodells diskutieren zu wollen, seien zwei Aspekte besonders hervorgehoben: - Die Größe des Exponenten besagt, daß (in der LoC-Zahl) große Softwareprodukte überproportional mehr Entwicklungsaufwand haben als kleine Softwareprodukte; diese Aussage hat übrigens das Boehm-Schätzmodell mit vielen anderen Modellen gemeinsam.

- Unter den Einflußfaktoren haben die Eigenschaften der Entwicklungsmitarbeiter die größte Spannweite das heißt, der Aufwand in der Zahl der Mannmonate wird hierdurch im Vergleich zu den anderen Eigenschaften, also zum Beispiel auch dem Einsatz von Entwicklungswerkzeugen, am stärksten beeinflußbar.

Es hat den Anschein, als ob diese neuen, durch empirische Untersuchungen gewonnenen Schätzmodelle verstärkt Eingang in die Praxis finden. Es wäre dabei zu wünschen, daß ihr Einsatz mit Bedacht erfolgt, denn sie lassen sich infolge des differenzierten Ansatzes nicht sinnvoll zu einer Durchschnittsbetrachtung in Richtung einer Produktivitätsangabe ("unsere Entwicklungsmitarbeiter haben eine Produktfamilie von 80 LoC/Manntag") verwenden.

Kostensenkende Maßnahmen

Die Struktur eines Schätzmodells zeigt gleichzeitig lohnende Ansätze für kostensenkende Maßnahmen: Die bessere Qualifikation und Erfahrung der Entwicklungsmitarbeiter kann nachhaltig dazu beitragen, den Entwicklungsaufwand zu senken. Sicherlich sind darüber hinaus Projekteigenschaften wie die Organisation des Entwicklungsprozesses oder der Einsatz von Entwicklungswerkzeugen hilfreich.

Es ist aber vielleicht nützlich, sich in unserer "toolgläubigen" Zeit zu vergegenwärtigen, daß Hauptansatzpunkte zur Senkung der Entwicklungskosten bei den Entwicklungsmitarbeitern liegen. Bei weiteren Möglichkeiten der Kostensenkung sei nur noch ein Aspekt besonders hervorgehoben: Bei vielen Herstellprozessen für physische Güter wie auch Hardware sind mehr als 50 Prozent der Herstellkosten Qualitätssicherungskosten. Diese Situation kennen wir auch bei der Software-Entwicklung, allerdings nur in der Entwicklungsphase "Programmierung".

Hier entfallen oft 50 Prozent und mehr des Phasenaufwandes auf die Qualitätssicherung, nämlich das Testen. Unter der Zielsetzung einer Kostensenkung ist es notwendig, die Qualitätssicherung auch in den der Programmierung vorgelagerten Entwicklungsphasen zu intensivieren, zum Beispiel durch Structured Walk Through um Qualitätsmängel möglichst frühzeitig zu erkennen und mit relativ geringen Kosten beseitigen zu können.

Mängel sichtbar

Das Feld des Softwarebetriebs erscheint auf den ersten Blick kostenmäßig völlig erschlossen: Aus Accounting-Routinen lassen sich die auf einen Kostenträger entfallenden Kostenarten ermitteln und monatlich den Benutzern verrechnen. Bei näherer Betrachtung werden jedoch Mängel sichtbar. Diese Form der Kostenermittlung und -verrechnung erfüllt nicht wünschenswerte Zielsetzungen einer Kostenrechnung, etwa Transparenz und Reproduzierbarkeit.

Der Benutzer kann sich aus der in der CPU-Zeit oder EXCPs aufgeschlüsselten Rechnung keinen Reim machen, und/oder er stellt mit Erstaunen fest, daß er für die jeweils in gleichem Umfang betriebenen Anwendung in zwei Monaten unterschiedlich hohe Rechnungen erhält. Hier sind Abhilfen angebracht, die aus der kostenrechnerischen Behandlung anderer Gebiete durchaus bekannt sind, etwa Stückkosten (Kosten pro Debitorenbuchhaltung) oder Durchschnittskosten (gemittelt über ein Kalenderjahr).

Ein anderer Mangel erscheint jedoch noch gravierender: Accounting-Routinen fehlen bei Mini- und Mikrorechnern, so daß keine für eine Kostenermittlung und -verrechnung bequeme Datenerfassung vorhanden ist. Man sollte sich jedoch vergegenwärtigen, daß dort die Kosten für Hardware, Systemsoftware und Anwendungssoftware pro Periode oft jetzt schon unter den Personalkosten des Mitarbeiters am Bildschirmarbeitsplatz liegen und sich diese Tendenz noch nachhaltig verstärkt. Angesichts dieser Perspektive werden Bemühungen der Software-Ergonomie, die Software besser an den Menschen anzupassen, vielleicht verständlicher.

Kaum vernünftige Überlegungen

Kostensenkende Maßnahmen beim Softwarebetrieb sind besonders dann effizient, wenn sie dem Kostenbewußtsein des Benutzers entspringen können. So ist etwa aus der Praxis bekannt daß Umfragen bei Benutzern, welche Programme sie noch benötigen, erbracht haben, daß alle Programme benötigt werden, zu Recht, denn bei fehlenden Kostenangaben in der Sprache des Benutzers, zum Beispiel Kosten pro Fehlzeitstatistik, können kaum vernünftige Kosten/Nutzen-Überlegungen angestellt werden.

Neben solchen wertanalytischen Maßnahmen zur Kostensenkung werden heute noch gebräuchliche Aktivitäten zur besseren Maschinenressourcennutzung ("tuning") wegen der Entwicklung des Preis/Leistungsverhältnisses der Maschinenressourcen an Bedeutung verlieren und dafür Maßnahmen zur Dialoggestaltung mit dem Ziel eines ergonomisch richtigen Mitarbeitereinsatzes wichtiger werden.

Erschreckende Ergebnisse

Die Analyse der Kostensituation in der Softwarewartung zeigt erschreckende Ergebnisse: Während der gesamten Betriebszeit eines Softwareproduktes übersteigen die Wartungskosten die Entwicklungskosten, zum Teil sind sie ein Mehrfaches der Entwicklungskosten. Spätestens hier bemüht man sich uni eine genauere Definition der Softwarewartung. Es wird zwischen Fehlerbeseitigung ("corrective maintenance"), Anpassung ("adaptive maintenance") und Weiterentwicklung ("perfective maintenance") unterschieden.

Empirische Untersuchungen zeigen, daß mindestens die Hälfte der Wartungskosten für die Weiterentwicklung entstehen, Fehlerbeseitigung und Anpassung (zum Beispiel an neue Betriebssystemversionen) machen jeweils weniger als ein Viertel der Wartungskosten aus. Hier wird eine falsche Grundeinstellung von Software-Entwicklern (oft gleich Softwarewaren) und Softwarenutzern sichtbar, nämlich die Annahme, daß ein Softwareprodukt eine unbegrenzte Lebensdauer hat, und im Laufe der Zeit den Bedürfnissen entsprechend weiterzuentwickeln ist.

Zwar ist es richtig, daß Programme nicht rosten, aber sie altern in dem Sinne, daß ihre Struktur hardware- und softwaretechnologisch nicht mehr dein Stand der Technik entspricht und damit das Ende einer wirtschaftlichen Lebensdauer erreicht wird. Diese Bewußtseinsänderung muß erst eintreten, um den hohen Anteil der Weiterentwicklung an den Wartungskosten zurückdrängen zu können. Zur weiteren Analyse der Wartungskosten seien noch zwei empirisch sichtbare Phänomene genannt:

- Nach der Inbetriebnahme eines Softwareproduktes steigen die Wartungskosten zunächst stark an. Es darf vermutet werden, daß manche Softwareprodukte erst in der Betriebsphase zu Ende entwickelt werden.

- Die Wartung bezieht sich oft nur auf einen geringen Teil eines Softwareprodukts.

Arbeit am Eisberg

Hier drängen sich zunächst organisatorische Maßnahmen auf, nämlich eine Trennung von Entwicklungs- und Wartungsabteilung. Es will einfach nicht einleuchten, daß man nur knapp die Hälfte der Entwicklungsmitarbeiter in eine feste Projektorganisation für die Software-Entwicklung einbindet, und andere Entwicklungsmitarbeiter in einem "Wartungseisberg" arbeiten.

Wir sind es im übrigen auch bei anderen Gütern (zum Beispiel Autos) gewohnt, zwischen Entwicklungs- und Wartungsorganisation zu unterscheiden. Auch empirische Untersuchungen sprechen für eine bessere Effizienz von getrennter Entwicklungs- und Wartungsorganisation von Softwareprodukten, so daß es für mich nicht ganz verständlich ist, warum sich erst wenige Unternehmen hierzu entschieden haben.

Als weitere kostensenkende Maßnahme ebenfalls organisatorischer Natur ist eine bessere Ablauforganisation zu nennen: Wartungsanforderungen müssen formalisiert erfaßt, mindestens bei Weiterentwicklungsanforderungen einer Genehmigungsprozedur unterzogen und in ein Planungs- und Kontrollsystem einbezogen werden. Dazu gehört auch die Verrechnung von Wartungskosten - ein Phänomen, das durch Wartungsverträge und -kosten für Standardsoftware inzwischen in das Bewußtsein des Benutzers eingedrungen ist.

Es wird allgemein die Hoffnung geäußert, daß ein verstärkter Einsatz von Methoden, Verfahren und Werkzeugen im Entwicklungsprozeß hilft, Wartungskosten zu senken. Infolge der Kalenderzeitstruktur ist diese Hoffnung noch nicht einer Gewißheit gewichen; es sind eher Einzelfälle bekannt geworden, in denen Programmgeneratoren einen extrem "wartungsfreundlichen" Code erzeugt haben.