Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.04.1988 - 

Kurzsichtige Argumente stehen oft besseren Einsichten entgegen:

Qualität von Anfang an spart Wartungskosten

50 bis 70 Prozent der gesamten Life-Cycle-Kosten entfallen heute auf die Softwarewartung. In Zukunft soll dieser Prozentsatz sogar noch ansteigen, prophezeit Hartwig Dirscherl*. Um die Wartungsfreundlichkeit zu erhöhen, empfiehlt der DV-Fachmann die Anwendung problemorientierter Entwicklungsmethoden sowie eine optimierte Planung.

In den letzten Jahren gewann die Wartbarkeit von Software als wesentlicher Teil der Qualitätssicherung zunehmend an Bedeutung. Die Notwendigkeit, die Wartungsfreundlichkeit zu verbessern, ist zwar manchen DV-Managern, Projektleitern und Programmentwicklern bewußt, doch wird diese Einsicht meist von der Projektrealität überrollt. Kosten und Projekttermine sind die vordergründigen und kurzsichtigen Argumente, die einer Umsetzung entgegenstehen.

Software unterliegt im Gegensatz zur Hardware keinem Verschleiß. Hardware muß aufgrund der Abnutzung und der verschleißbedingten Defekte gewartet werden. Die Begriffe Wartung und Wartungsfreundlichkeit bedürfen in Bezug auf Software deshalb einer genaueren Definition: Treffender wäre es, hier von Softwarepflege und -änderung zu sprechen.

Vier Parameter der Wartungsmaßnahmen

Wartungsfreundlich ist eine Software dann, wenn sie folgende Bedingung erfüllt: Der Aufwand für das Erkennen von Fehlerursachen und für deren Korrektur sowie für die Optimierung, Erweiterung und Änderung ist möglichst gering. Harry Sneed (Spektrum 1986, Kongreß für SW-Maintainability) werden Wartungsmaßnahmen von folgenden Parametern bestimmt: Stabilisierung (Fehlerbeseitigung), Optimierung, Änderung und Erweiterung der Software.

Nach der Auswertung zahlreicher Software-Projekte sind zirka 50 bis 70 Prozent der gesamten Life-Cycle-Kosten für Wartungsmaßnahmen anzusetzen. Dies variiert je nach Umgebung, Einsatz, Art der Software und so weiter. Einzelne Firmen konnten diesen Anteil bereits durch entsprechende Ansätze und Methoden reduzieren. Doch nach Einschätzung relevanter amerikanischer Institute steigt der Prozentsatz im Durchschnitt eher noch.

Das US Government Accounting Office (GAO) veröffentlichte im Report 1979 einen Bericht über die Überprüfung von Softwareprojekten. Demnach konnten nur zwei Prozent der Softwareprodukte in der Form, wie sie ausgeliefert wurden genutzt werden. Ein wesentlicher Grund dafür sind ungenaue, nicht adäquate Pflichtenhefte. Das Ergebnis zeigt aber auch, daß nach der Entwicklungsphase erhebliche Änderungs- und Erweiterungsarbeiten notwendig werden, um die Software für den Anwender akzeptabel zu machen.

Die zunehmenden Kosten und die Personalauslastungen für die Softwarewartung können insbesondere von den Unternehmen, die in eigener Verantwortung Software entwickeln, kaum mehr aufgebracht werden. Dadurch fehlt es auch an Kapazitäten für Neuentwicklungen. Es sind also Ansätze zu finden, die enormen Kosten der Wartungsmaßnahmen durch Anwendung problemorientierter Softwaremethoden und Optimierung der Planung zu senken.

Angaben zur Wartungsfreundlichkeit der Software sind in vielen Pflichtenheften entweder gar nicht oder nur in sehr allgemeiner Form enthalten. Eine entsprechende Beurteilung in den Reviews, bei der Verifikation, der Validierung oder der Abnahme der Software ist deshalb meist nur in einer subjektiven Allgemeinaussage möglich - wenn überhaupt.

Projektleiter sind gewöhnlich nur bis zur Fertigstellung eines konkreten Projektes zuständig und tragen anschließend für den Einsatz keine Verantwortung mehr. Der Projektleiter hat somit in erster Linie das Interesse, die funktionalen Ziele bei der Softwareentwicklung zu erfüllen und den vorgegebenen Zeitrahmen einzuhalten, und dies insbesondere, wenn andere Qualitätsmerkmale der Software wie die Wartungsfreundlichkeit im Pflichtenheft nicht oder nur vage gefordert sind.

Daraus ergibt sich, daß die Merkmale der Softwarewartbarkeit eindeutig, klar und nachprüfbar im Pflichtenheft formuliert werden müssen. Ebenso wichtig ist die Kontrolle dieser Funktions- und Qualitätsmerkmale während des gesamten Entwicklungsprozesses - beginnend bei der Anforderungsanalyse bis zu den Testphasen, der Verifikation und Validierung sowie der Abnahme. Werden nur vage Aussagen zur Wartbarkeit im Pflichtenheft gemacht, fällt es den Controllern oder dem Qualitätssicherungspersonal schwer, Fehler zu berichtigen.

Durch spätere Änderungen und Erweiterungen des Softwaresystems kommen meist erhebliche Kosten, hinzu. Die entsprechende Kontrolle kann entweder durch eigene Mitarbeiter des Auftraggebers erfolgen oder auch von externen Controllern durchgeführt werden. Der zweite Weg wird wohl in Zukunft oft der effektivere und kostengünstigere sein.

Auch im Interesse der Hersteller muß es liegen, die Wartungsfreundlichkeit der im Auftrag erstellten Software zu erhöhen. Als Gegenargument der Anbieter wird aber wiederholt vorgebracht, daß eine schlechtere Wartungsfreundlichkeit größere Folgeaufträge begünstige. Das ist allerdings sehr vordergründig und kurzsichtig: Erstens leidet auf Dauer das Image der Firma darunter, und zweitens wirkt sich bei Festpreisprojekten eine schlechte Wartungsfreundlichkeit für den Entwickler schon in den Testphasen wie ein Bumerang aus. Denn Fehlerbeseitigungen benötigen sehr viel mehr Aufwand und schmälern den Gewinn unter Umständen erheblich.

Da langfristig der wirtschaftliche Erfolg eines Projekts und des Unternehmens von der Wartungsfreundlichkeit abhängt, hat die Firmenleitung entsprechende strategische Ziele festzulegen und durchzusetzen. Diese Ziele sind dem Projektmanagement vorzugeben und zu kontrollieren. Hierzu werden firmeninterne Qualitätssicherungsrichtlinien gebraucht, die in die jeweiligen Projektspezifikationen und Pflichtenhefte eingebracht werden müssen. Leider existieren solche Richtlinien nur bei weniger als 50 Prozent der Softwareanbieter.

Design-Reviews lassen wichtige Fragen offen

In großen Software-Häusern ist eine Qualitätssicherung, die die Anforderungen im Detail definiert und entwicklungsbegleitend überwacht, bereits selbstverständlich. Doch es gibt auch Akzeptanzprobleme - insbesondere bei Systemhäusern. Hier wird die Einhaltung und Überprüfung der Qualitätsmerkmale noch als die Domäne der Entwickler angesehen. Oft fehlt es auch an qualifiziertem Personal, oder Mitarbeiter in der Qualitätssicherung haben Probleme, gegenüber den Softwareentwicklern fundiert zu argumentieren.

In den Design-Reviews wird dann häufig nur Kritik an formalen Kleinigkeiten angebracht. Essentielle Fragen dagegen, zum Beispiel ob Testprozeduren grundsätzlich den Anforderungen an Zuverlässigkeit oder Wartungsfreundlichkeit entsprechen, bleiben offen.

Für Aufgaben der Qualitätssicherung sind deshalb nur erfahrene Softwareentwickler geeignet, die fähig sind, das gesamte System zu überblicken, und die sich nicht zu sehr in bedeutungslosen Formalismen zu verlieren. Selbstverständlich ist hierbei eine formal korrekte Dokumentation eine wesentliche Voraussetzung für die Wartungsfreundlichkeit.

Bei kleineren Unternehmen wird zum Teil darüber nachgedacht, eine Abteilung für die Softwarequalitätssicherung einzurichten; mitunter wird auch bereits ein Verantwortlicher eingesetzt. Zu beachten gilt es hier allerdings, daß die Stellung der Entwickler insbesondere in kleineren Softwarehäusern meist so stark ist, daß sie sich einer effizienten Überprüfung durch Qualitätssicherungsinstitutionen oft widersetzen oder gar entziehen. Es kann hier kostenfähiger sein, spezialisierte Unterauftragnehmer einzusetzen, die die Qualitätssicherung aufbauen oder die entsprechenden Aufgaben durchführen.

Es ist daher notwendig, der Qualitätssicherung einen festen Rang innerhalb des Unternehmens einzuräumen. Sie sollte vielmehr als Unterstützung und Hilfestellung für die Entwickler betrachtet werden, und nicht als "unwillkommene" permanente Kritik.

Die Ansätze, die Wartungskosten in den Griff zu bekommen oder gar zu senken, lassen sich in drei Ebenen unterteilen. So bilden geeignete Software-Entwicklungsverfahren die essentielle Basis für eine bessere Wartungsfreundlichkeit; sie verringern die Restfehler in Programmen und reduzieren somit auch den Aufwand für eine Stabilisierung. Wesentliche Prinzipien sind hierbei das Objektorientierte Design, Data Dictionaries, Modularisierung und eine selbsterklärende Software. Ferner müssen das Programm konsistent und strukturiert aufgebaut und die Fehler reproduzierbar sein. Schließlich gilt es zu beachten, daß die Software erweiterbar ist und das Prinzip der Lokalisierung eingehalten wird.

In zunehmenden Maße existieren heute bereits DV-Systeme, die eine automatische Erfassung von Qualitätsgrößen der Hardware erlauben. Die erfaßten Daten werden gesammelt, mit den zulässigen Werten verglichen, statistisch ausgewertet und in Datenbanken abgelegt, auf die der Zugriff jederzeit möglich ist.

Analoge Softwaresysteme für die Qualitätssicherung gibt es heute nur in Ansätzen, obwohl sich analog relevante Größen teilweise ohne große Probleme erfassen lassen. Von einer Akzeptanz solcher Tools ist man aber noch weit entfernt. Beispiele zweckmäßiger Größen zur Beurteilung der Wartbarkeit beziehungsweise Wartungsfreundlichkeit können unter anderem sein: die Modularisierung, der Grad der Kommentierung, die maximale Schachtelungstiefe und nicht-dokumentierte Codeteile. Ferner kommen noch die Vollständigkeit der Header-Information, die Komplexitätswerte, die Zahl der Knoten und die Call-Graph- sowie die Control-Graph-Statistiken hinzu. Für die Beurteilung der Wartbarkeit kann auch die Zahl der aufgetretenen Fehler in den verschiedenen Test-Phasen und der mittlere Zeitaufwand für eine Änderung in Frage kommen.

Bei einigen Entwicklungsumgebungen sind Analyse- und Qualitätssicherungs-Tools integriert. Teilweise ist hiermit eine Analyse der formalen Design-Teile möglich; teilweise erfolgen auch spezifische Qualitätsanalysen des erstellten Code. Selten findet man Werkzeuge, die unabhängig von Entwicklungsumgebungen eingesetzt werden können und auch die Merkmale Wartbarkeit, Wartungsfreundlichkeit prüfen. Die implementierten Analysen sind hier oft nicht ausreichend. Die Ergebnisse sollten daher in Erfahrungsdatenbanken einfließen, die eine projektübergreifende Auswertung ermöglichen.

Solche Erfahrungsdatenbanken für Software, die zur fundierten Kontrolle des Entwicklungsprozesses und als Planungsbasis für zukünftige Projekte dienen, existieren jedoch fast nur in der Literatur. Einige Unternehmen haben dieses Problem schon seit einiger Zeit erkannt und damit begonnen, Qualitätssicherungsdaten projektübergreifend zu erfassen und abzuspeichern.

Oft besteht in Unternehmen die Tendenz, ältere Programme, die den gewachsenen Anforderungen nicht mehr genügen, zu verschrotten und statt dessen neue Softwaresysteme zu erstellen. Dies ist aber in vielen Fällen sehr uneffektiv und teuer. Tools, die ältere Programme umsetzen, zum Beispiel von Fortran IV in das besser strukturierte Fortran 77, können eine sehr kostengünstige und effektive Alternative zu einer Neuentwicklung darstellen.

Eine Restrukturierung sollte aber nicht nur den Code umfassen, sondern auch die entsprechende Dokumentation, angefangen von der Spezifikation bis zu den User-Manuals. Sie sollte mit dem Ziel durchgeführt werden, die Software zuverlässiger, leichter erweiterbar, verstehbar, effizienter und testbarer zu gestalten.

Restrukturierungen erweisen sich auch dann als sinnvoll, wenn der Wartungsaufwand sehr stark ansteigt, zum Beispiel bei Software mit veralteten Sprachkonzepten. Durch die Softwaresanierung lassen sich Wartungskosten nach Harry Sneed um bis zu 100 Prozent reduzieren.

In diesem Zusammenhang sollte der Aufbau von Firmen-Libraries Erwähnung finden: Softwaremodule neu zu schreiben, wenn ein Problem bereits gelöst und implementiert ist, ist Zeitverschwendung. Dies klingt sehr einleuchtend. Die Frage lautet aber, in welchen Softwarehäusern es Libraries gibt, in denen getestete Module abgelegt und einheitlich dokumentiert sind und die auch den anderen Mitarbeitern zugänglich sind. In Großunternehmen ist dies teilweise realisiert. Aber gerade für die kleineren Softwarehäuser, die einem größeren Konkurrenzdruck ausgesetzt sind, wäre dies an sich eine Lebensnotwendigkeit.

Entwicklung und Wartung liegen nicht in einer Hand

Die Softwareentwicklungen erscheinen oft als schlecht planbar; Das sieht man zum Teil schon darin, daß oft die veranschlagte Entwicklungszeit erheblich überschritten wird. Bei der Softwarewartung ist das Problem oft viel größer. Denn die Wartung wird meist von anderen Mitarbeiter-Teams durchgeführt als an der Entwicklung beteiligt waren. Dies ist auch ein Grund, den Wartungsprozeß anders als den Entwicklungsprozeß zu modellieren und Organisations- und Management-Maßnahmen differenziert zu entwickeln.

Bisher aber existieren für dieses Gebiet fast keine zufriedenstellenden Ansätze oder Planungsmodelle. Ergebnis der Konzepte sollte deshalb sein, den Aufwand abzuschätzen und zu optimieren. Ferner gilt es festzulegen, welche Entwicklungs- beziehungsweise Testumgebungen notwendig sind, wieviel Personal zu welcher Zeit mit welcher Qualifikation benötigt wird und welche sonstigen Voraussetzungen noch berücksichtigt werden müssen.

Ein weiteres, wesentliches Ergebnis der Wartungsplanung und der hieraus gewonnenen Erkenntnisse muß es sein, die Softwareentwicklung in Richtung auf eine bessere Wartungsfreundlichkeit zu beeinflussen. Basis hierfür sind die erfaßten und analysierten Parameter.

Die Stabilisierung ist am wenigsten planbar

Manche Teile der Wartung, wie die Optimierung, die Änderung und die Erweiterung der Software können mehr oder weniger als planbar eingestuft werden. Zu den nicht planbaren Wartungsmaßnahmen gehört die Fehlerbeseitigung (Stabilisierung). Es werden derzeit allerdings Instrumentarien und Basisdaten untersucht, die eine grobe Abschätzung der Fehlerhäufigkeit und damit des notwendigen Aufwandes erlauben. Es müssen also auch für die nicht planbaren Wartungsmaßnahmen Personal und Ressourcen bereitgehalten werden.

Bei der Wartungsplanung erscheint es möglich, von relativ einfachen Erfahrungswerten auszugehen. 30 bis 50 Prozent der gesamten Life-Cycle-Kosten entfallen auf die Entwicklung, der Rest von 50 bis 70 Prozent auf die Wartung. Oft werden aufgrund dieser Annahmen Ressourcen und Personal geplant; sie unterliegen aber sehr großen Schwankungsbreiten und stellen somit nur eine äußerst unzureichende Planungsbasis.

Zu unterscheiden ist in der Wartungsplanung zwischen einer langfristigen, konzeptionellen Planung für die gesamte Wartungsphase und

den Planungen für eine konkrete Wartungsaktion. Für die letzteren können Planungs- und Kostenmodelle zum Einsatz kommen, wie sie für Neuentwicklungen einsetzbar sind; sie ersetzen aber nicht die langfristige Planung.

Bei einer Modellierung der Wartung beziehungsweise bei Wartungskonzepten ist ein differenziertes Vorgehen notwendig: Planbare Wartungen sind anders einzubringen als nicht planbare Wartungsmaßnahmen, denn sie erfordern andere Grunddaten.

Vor allen Dingen ist eine gemeinsame Betrachtung verschiedener Softwareprojekte in deren Wartungsphase unabdingbar. Zwischen den verschiedenen Wartungsprojekten ist eine Optimierung hinsichtlich des Zeitpunktes der Maßnahmen, des Toolkonzepts sowie ähnlicher Kriterien erforderlich. Tools und Entwicklungs-Umgebungen sind im Hinblick auf mehrere Softwarewartungsprojekte anders zu bewerten als im Hinblick auf nur ein Wartungsprojekt. Eine Methode der Optimierung von Softwarewartung ist unter anderem, die Vielfalt der eingesetzten Compiler und Entwicklungsumgebungen zu beschränken - auch wenn es für ein konkretes Projekt keine optimale Lösung sein mag.

Wesentliche Voraussetzung der fundierten Planung ist, daß während des gesamten Entwicklungsprozesses hierfür relevante Daten erfaßt werden. Diese Datenerfassung verfolgt zwei Zwecke: Zum einen soll sie eine bessere Wartungsfreundlichkeit der Software gewährleisten; zum anderen bildet sie auch die Basis für die Wartungsplanung. Untersuchungen ergaben, daß auf diese Weise 30 bis 40 Prozent der Wartungskosten eingespart werden können. Die Mehrkosten in der Entwicklungsphase liegen dagegen nur bei zirka ein bis fünf Prozent.

Grundsätzlich sollten bei Softwareänderungen alle Designstufen in analoger Weise durchlaufen werden; insbesondere sind alle Designdokumente entsprechend zu ändern und zu erweitern. Dies mag zunächst sehr aufwendig erscheinen. Aber nur so kann bei weiteren Änderungen und Erweiterungen ein Chaos vermieden werden.

Probleme mit der Wartbarkeit beziehungsweise der Wartungsfreundlichkeit entstehen insbesondere dann, wenn die Softwareentwicklung in einem zu engen Zeit- und Kostenrahmen durchgeführt wird oder in den Spezifikationen keine Definitionen der Merkmale für Wartungsfreundlichkeit und ähnliches enthalten sind.

Eine weitere Schwierigkeit ergibt sich daraus, daß während des gesamten Entwicklungsprozesses keine geeignete Kontrolle stattfindet, aber auch daraus, daß Softwareentwicklungsmethoden nicht sinnvoll eingesetzt werden und keine geeigneten Planungsinstrumente zur Verfügung stehen.

Wartungsplanung ist sicherlich ein DV-Zweig, der noch sehr viele Basis-Untersuchungen erfordert, aber andererseits erheblich dazu beitragen kann, die enorm wachsenden Softwarewartungskosten in Zukunft zu reduzieren.