In der Softwarewartung liegt ein wichtiger Schluessel zur Kostensenkung. Die Planung beschraenkt sich hier meist darauf, die Wartungskosten als einen konstanten Prozentsatz der Erstellungskosten beziehungsweise des Lizenzpreises festzusetzen - unabhaengig von dem Alter der Software. Robert Huerten* zeigt Alternativen auf.

Juengsten Veroeffentlichungen zufolge liegt der Schwerpunkt der Softwarekosten im Wartungsbereich. 50 bis 80 Prozent der Software- Ausgaben fallen heute dort an. Geht man der Frage nach, auf welcher Basis diese Zahlen ermittelt wurden, so muss man feststellen, dass nur ganz wenige Unternehmen den Wartungsaufwand ueber ein detailliertes Berichtswesen nachweisen koennen. Bei den meisten Anwendern scheint er heute noch nach folgender Regel ermittelt zu werden: Wartungskosten gleich Gesamtkosten der Software-Entwicklung minus Kosten fuer die Neuentwicklung.

Kostensenkung nach dem Verursacherprinzip

Massnahmen, um Wartungskosten zu reduzieren, koennen nur auf der Grundlage folgender Informationen erfolgen:

- Aufwand pro Anwendungssystem und Wartungsjahr,

- Wartungsursachen sowie ihre zeitliche und prozentuale Verteilung,

- Aussagen ueber die unterschiedlichen Wartungsaktivitaeten,

- Einfluss unterschiedlicher Systemumgebungen auf den Wartungsaufwand,

- Staerken und Schwaechen des Entwicklungsumfeldes sowie

- Staerken und Schwaechen des Anwenderumfeldes.

Fuer die Wartung der Software existieren unterschiedlichste Definitionen, die sich von dem in anderen Industrien geltenden Wartungsbegriff deutlich unterscheiden. So grenzt zum Beispiel der Schweizer Unternehmensberater Reinhold Thurner die Softwarewartung nur zeitlich und nicht ueber Aktivitaeten oder Ursachen ab. Thurner definiert den gesamten Aufwand, der nach der Uebergabe oder Einfuehrung eines Systems auftritt, als Wartung. Wenn derart vereinfachend gedacht wird, gewinnt man kaum die notwendigen Detailinformationen zur Steuerung der Softwarekosten.

Der normale Software-Anwender assoziiert mit der Wartung Aktivitaeten, wie er sie von seinem Auto her kennt, also Massnahmen, um dessen Funktionsfaehigkeit zu erhalten. Dabei ist es fuer ihn selbstverstaendlich, dass Reparaturen oder Funktionserweiterungen (beispielsweise der Einbau einer Anhaengerkupplung) keine Wartungsaktivitaeten sind.

Wartungsvertraege zwischen Anwendern und Software-Anbietern wurden bereits in den 70er Jahren geschlossen. Als damals die erste Standardsoftware angeboten wurde, verlangten die Anwender nach Zukunftssicherung ihrer Investitionen. Die Softwarehaeuser erkannten darin einen Markt. Sie uebertrugen den Wartungsbegriff und die Kostensaetze, die der Kunde von der Hardware kannte, auf die Software.

Da keine Kalkulationsgrundlagen fuer die Wartungsgebuehren vorlagen, uebernahmen die Softwarehersteller die Wartungssaetze der Hardwareproduzenten, die damals zwischen zehn und 15 Prozent der Anschaffungskosten beziehungsweise der Mietpreise lagen. Diese Saetze sind bis heute fuer die Softwarewartung immer noch marktueblich und werfen satte Gewinne fuer die Software-Anbieter ab.

Wenn die Software-Manager in den Unternehmen ihre Kosten senken wollen, muessen sie dort anfangen, wo sie ihren eigenen Aussagen nach das meiste Geld ausgeben, naemlich in der Wartung. Geht man systematisch an diesen Bereich heran, so lassen sich dort allein durch organisatorische Massnahmen meist zehn bis 20 Prozent Softwarekosten einsparen.

Die globale Betrachtung der Softwarewartung, wie beispielsweise Thurner sie definiert, ist fuer eine sinnvolle Planung der Aktivitaeten nicht zu nutzen. Statt dessen sollte zunaechst der Aufwand, den ein Softwareprodukt ueber seine Lebensdauer hinweg erfordert, in drei Kostenarten getrennt und aufgeteilt werden.

Das sieht dann folgendermassen aus: Fuer die Neuentwicklung werden 30 Prozent, fuer das Nacharbeiten sowie fuer funktionale Aenderungen und Weiterentwicklung 40 Prozent, fuer Wartung und Anwenderbetreuung nochmals 30 Prozent des Gesamtaufwands benoetig. Wartung und Anwenderbetreuung lassen sich nochmals unterteilen in Fehlerkorrektur (sieben Prozent), technische Anpassung (fuenf Prozent), Betreuung im Betrieb (zwei Prozent) und Anwenderbetreuung (16 Prozent).

Empfehlenswert ist es, den Begriff der Wartung im Bereich der Software ueberhaupt nicht mehr zu verwenden. Die Bezeichnung Anwendungs-/Anwenderbetreuung waere viel treffender.

Nacharbeiten einerseits und funktionale Aenderungen beziehungsweise Erweiterungen andererseits sind streng von den eigentlichen Wartungsaktivitaeten zu trennen. Nur so ist eine sinnvolle Planung moeglich.

Kaum ein Softwareprojekt wird innerhalb des vorgesehenen Zeitrahmens abgeschlossen. Um Terminengpaesse zu vermeiden, werden dann geplante, jedoch nicht unbedingt notwendige Aufgaben in die Zukunft verlagert. Arbeiten, die urspruenglich im Entwicklungsaufwand enthalten waren, verschieben sich in die Wartungskosten hinein. Das bedeutet in der Praxis, dass diese Funktionen im Rahmen der Wartung nachtraeglich implementiert werden.

Die Ursachen fuer die nicht unerheblichen Nacharbeiten, die als Wartung deklariert werden, liegen in einem schlechten Projekt- Management. Die Zeitplanungen derartiger Projekte basieren auf unvollstaendigen beziehungsweise schlechten Aufwandschaetzungen.

Funktionale Aenderungen und Weiterentwicklungen lassen sich in der Praxis nie vermeiden. Die Programme muessen auf Veraenderungen im Anwendungsumfeld reagieren. Den Anstoss zu den Aenderungen gibt haeufig nicht der Anwender selbst, sondern beispielsweise der Gesetzgeber. Diese Fremdbestimmung laesst sich nicht in die mittel- und langfristige Planung einkalkulieren.

Anders verhaelt es sich hingegen bei internen Aenderungswuenschen. Sie muessen kuenftig sorgfaeltiger auf ihre Berechtigung und Dringlichkeit hin analysiert werden. Nicht immer besteht die Notwendigkeit, die Forderungen kurzfristig oder ueberhaupt zu realisieren. Solange funktionale Aenderungen im Rahmen pauschalierter Wartungskosten verrechnet werden, ist die Begehrlichkeit der Anwender nach Verbesserungen gross.

Es gibt keine Software, die fehlerfrei installiert wird. In der Praxis zeigt sich, dass Fehler mit zunehmendem Alter der Software zunaechst seltener, aber ab dem vierten Nutzungsjahr wieder vermehrt auftreten. Dieser Schwerpunkt der Fehlerbehebung im ersten Jahr nach der Installation spricht dafuer, dass das Projekt- Management haeufig Schwaechen bei der Qualitaetssicherung aufweist. Durch falsche Planungen entsteht Termindruck, der dazu fuehrt, dass nicht sorgfaeltig und systematisch getestet wird. "Testing on the Job" ist heute die Regel.

Technische Anpassungen werden durch Aenderungen bei Hardware und Systemsoftware ausgeloest. Die Lieferanten lassen dem Anwender bisweilen nicht viel Entscheidungsspielraum, ob oder wann er eine solche Anpassung vornehmen soll. Der Aufwand fuer technische Anpassungen sprengt haeufig den normalen Rahmen der Wartung. In diesen Faellen werden dann Spezialprojekte in Angriff genommen.

Unter Betreuung im Betrieb ist die Unterstuetzung des Rechenzentrums oder anderer Systemverantwortlichkeiten (Netz, Server etc.) durch die Programmersteller zu verstehen. Der Umfang solcher Arbeiten wird weitgehend von der Qualitaet der Rechenzentren bestimmt.

Zur Anwenderbetreuung gehoeren Anwenderberatung, Klaerung und Behebung von Bedienerfehlern etc. Diese Leistungen lassen sich nicht allein aus der Groesse der genutzten Software bestimmen. Auch die Anzahl der Anwender beeinflusst den erforderlichen Aufwand. Bei Anwendungen mit vielen Nutzern wird deswegen immer haeufiger die Verantwortung fuer die Anwenderbetreuung in den Fachbereich verlagert.

Die Leistungsarten in der Softwarewartung verlangen nach unterschiedliche Methoden in der Planung. Drei Verfahren sind hier zu unterscheiden:

- die Function-Point-Methode,

- die Function-Point/Zeit-Methode und

- die Pars-pro-toto-Methode.

Drei Verfahren fuer die Planung

Mit Hilfe der Function-Points wird der funktionale Umfang einer betriebswirtschaftlichen Aufgabe sowie die Qualitaet ihrer Loesung gemessen. Grundlage fuer diese Messung sind die Informationen, die an das System gelangen, von ihm abgegeben werden und in ihm vorgehalten werden. Qualitaet wird als prozentuale Abweichung der Function-Points gegenueber einem definierten Qualitaetsstandard dargestellt. Mit dem Verhaeltnis von realisierten Function-Points pro Zeiteinheit erhaelt man die Masszahl fuer die Produktivitaet einer Software-Entwicklung. Dieses Verfahren hat den Vorteil, dass es zur Ermittlung eines Aufwandes zwischen funktions-, qualitaets- und produktivitaetsbezogenen Groessen unterscheidet.

Bei funktionalen Aenderungen sind einzelne Aufgaben oder ganze Funktionszweige ergaenzend zu gestalten beziehungsweise bestehende Funktionen abzuaendern. Ergaenzungen werden wie echte Neuentwicklungen mit Function-Points bewertet, Aenderungen dagegen nur entsprechend ihrem Anteil an der Gesamtfunktion.

Jeder, der in der Programmpflege taetig ist, weiss, dass der Aufwand fuer eine Aenderung nicht nur von ihrer Groesse, sondern auch vom Umfang des betroffenen Systems abhaengt. Dies ergibt sich allein aus der Tatsache, dass auch bei einer kleinen Aenderung unbedingt ein Systemtest stattfinden sollte.

Um dieser Tatsache Rechnung zu tragen, wird der Aufwand nicht direkt, sondern relativ zur Systemgroesse aus den Function-Points ermittelt. Die Ermittlung des Aufwandes aus der Differenz der Projektstunden und nicht aus der Differenz der Function-Points beruecksichtigt automatisch die Groesse des zu aendernden Projektes.

Um den Aufwand fuer Fehlerkorrektur, technische Anpassung, Betreuung im Betrieb und Anwenderbetreuung zu ermitteln, arbeiten jetzt die ersten Anwender mit einer Aufwandkurve, die in der englischen Literatur als "Badewannen-Kurve" bezeichnet wird. Diese Kurve weist den Aufwand aus, der pro Function-Point eines Projektes in jedem Jahr anfaellt. Das Minimum dieser Kurve wird weitgehend von der Anzahl der Benutzer bestimmt. Aus den Werten oberhalb des Minimums lassen sich Rueckschluesse auf die Qualitaet der Software-Entwicklung ziehen.

Jedes Entwicklungsumfeld wird eine eigene Badewannen-Kurve haben. Hinzu kommen spezielle Einflussfaktoren, die von dem jeweiligen Projekt und dem Wartungsteam abhaengen. Die ersten Erfahrungen zeigen, dass mit den Ergebnissen der Badewannen-Kurve besser zu arbeiten ist als mit den linearen, von der Zeit unabhaengigen Wartungskosten.

Technische Anpassungen (beispielsweise Umstellung von einem Betriebssystem auf ein anderes) koennen nicht auf der Grundlage der Function-Points geplant werden. Um den Aufwand fuer derartige Projekte zu bestimmen, sind zunaechst aus der Gesamtheit aller Teilaufgaben drei bis sechs typische Tasks auszuwaehlen, die dann auf ihren Zeitaufwand hin untersucht werden. Auf der Basis dieser exakten Messungen laesst sich dann der Gesamtaufwand hochrechnen.

Die Definition der Wartungsleistungen weisen auch auf deren Ursachen hin. Wenn die Maengel bekannt sind, dann lassen sich auch Massnahmen dagegen treffen.

Die wichtigsten dieser Massnahmen verlangen Fuehrungsentscheidungen, deren Grundlage nur ein genaues und detailliertes Berichtswesen sein kann. So werden Aenderungen in Programmen beispielsweise zu schnell auf Zuruf vorgenommen. In diesem Fall kann die Fuehrungsentscheidung dahingehend lauten, dass Programme nur in festen Rhythmen geaendert werden duerfen und Abweichungen von dieser Regel einer besonderen Genehmigung beduerfen.

Der Software-Manager muss darauf geschult werden, dass er die Wartung nach oekonomischen Regeln organisiert. Einzelaenderungen in Programmen sollten absolute Ausnahmen sein. Aenderungswuensche sind zu sammeln und unter Programmversionen gebuendelt zu realisieren.

Der Aufwand fuer eine kleine, einzelne Aenderung ist naemlich nur unwesentlich geringer als fuer eine sorgfaeltig geplante Release- Aenderung. Die Zeit fuer das Einlesen in die Programme und das Austesten der neuen Versionen wird kaum differieren.

Bei funktionellen Aenderungen oder Erweiterungen sollte untersucht werden, inwieweit sie fachlich notwendig und terminlich dringend sind. Ueber Dringlichkeitskennzahlen in Verbindung mit einer Kosten-Nutzen-Betrachtung laesst sich dann jede neue Version planen.

Schwere Fehler muessen zuerst behoben werden

Es sind Fehlerklassifikationen einzufuehren, aus denen sich ableiten laesst, wie schnell reagiert werden muss. Solche Klassen sind:

1. Fehler, durch die die Anwendung unbrauchbar wird und die nicht durch organisatorische Massnahmen umgangen werden koennen,

2. Fehler, die die Anwendung zwar schwer beeintraechtigen, aber durch organisatorische Massnahmen voruebergehend umgangen werden koennen,

3. Fehler, die die Anwendung nicht materiell unbrauchbar machen, und

4. Maengel, durch die die Bedienung der Anwendung erschwert wird.

Die Qualitaet des Projekt-Managements hat direkten Einfluss auf die Wartungskosten. Die Terminschwierigkeiten gegen Ende der Projekte haben folgende negative Auswirkungen: Die Programme werden nicht ausreichend getestet, unzureichend dokumentiert oder unvollstaendig abgeliefert. In allen drei Faellen fuehrt das zu erhoehtem Aufwand im ersten Wartungsjahr.

Deswegen muss die Projektplanung auf der Basis von sicheren Aufwandschaetzungen erfolgen. Ausserdem sollte die inhaltliche Kontrolle eine nachtraegliche Erweiterung der urspruenglichen Aufgabenstellung rechtzeitig aufzeigen.

Verbesserungen des Projekt-Managements im Hinblick auf zuverlaessige Terminierung, Qualitaetsplanung und -sicherung koennen ueber die Badewannen-Kurve nachgewiesen werden. Anzustreben ist, die Kurve flach und das Minimum niedrig zu halten. Das heisst, die Kurve sollte ihren Badewannen-Charakter verlieren.