Bei der Einführung neuer Verfahren und Werkzeuge zeigt sich in der Praxis häufig, daß Werkzeuge oder Methoden-Handbücher zwar beschafft, aber nur partiell oder gar nicht genutzt werden. Daraus kann man einen Zusammenhang zwischen dem "Reifegrad" eines Unternehmens und den Möglichkeiten für den Einsatz moderner Verfahren und Werkzeuge ableiten.
Eins vorweg: Auch in diesem Beitrag wird bei der Diskussion um den Nutzen des Software-Engineering von einem qualitativen Ansatz ausgegangen. Die Diskussion um die Quantifizierung des Nutzens soll an anderer Stelle geführt werden. Die nachfolgende Argumentation geht von der Hypothese aus, daß der Einsatz von zeitgemäßen Software-Engineering-Verfahren und -Werkzeugen die Qualität der erstellten Produkte als auch die Produktivität im Erstellungsprozeß verbessert.
Eine zweite Hypothese lautet: Zwischen dem "Reifegrad" eines Unternehmens und den Möglichkeiten, moderne Verfahren und Werkzeuge einzusetzen, gibt es einen Zusammenhang. Befindet sich ein Unternehmen bei der Software-Entwicklung in der Verfahrenswelt der 60er oder 70er Jahre, so ist die Einführung von Verfahren, die "State of the Art" in den 90ern sind, mit einem großen Risiko behaftet.
Diese Hypothese wird von einer Analysemethode gestützt, die vom Software-Engineering-Institute an der Carnegie Mellon Universität entwickelt wurde. Diese Methode untersucht den "Reifegrad" einer Unternehmung, um daraus Schlüsse für die Verbesserung der Softwareproduktion zu ziehen. Das amerikanische Department of Defence (DoD) nutzt zum Beispiel diese Methode, um beim Einkauf von fremd erstellter Software die Vertragspartner bezüglich ihrer Leistungsfähigkeit zu bewerten.
Bei der Entscheidung, in welchen Schritten neue Verfahren und Werkzeuge in ein Unternehmen getragen werden können, müssen diese unternehmensspezifischen Ausprägungen unbedingt berücksichtigt werden.
Dies bedeutet, daß vor der Einführung neuer Software-Engineering-Verfahren zunächst eine Phase der "Nabelschau" durchlaufen werden muß.
Dies kann sowohl eine schmerzliche als auch eine schwierige Analyse sein schmerzlich, weil viele Defizite zutage treten, schwierig, weil die Definition des eigenen Standpunktes nur im Verhältnis zu anderen möglich ist. Dazu bedarf es aber nicht nur der Lektüre der einschlägigen Publikationen, sondern vor allem eines Einblicks in die gelebte Realität, um nicht irgendwelchen Schlagworten aufzusitzen. An diesem Punkt sollten sich Unternehmen überlegen, sich eventuell externer Unterstützung zu bedienen. Das Ergebnis dieser Analyse beeinflußt nicht zwangsläufig die Schrittfolge des Einführungsprozesses, sicherlich aber die Größe der
Schritte.
Beginnen sollte man dort, wo der größte Nutzen zu erwarten ist. Betrachtet man den Aufwand, der für Neuerstellung und für Wartung von Software betrieben wird (vergleiche Abbildung 1), so erhält man scheinbar eine klare Richtschnur: Der größte Nutzen ist bei der Einführung von Verfahren und Methoden im Bereich Maintenance zu erwarten. Wird dort die Produktivität um zehn Prozent gesteigert, ergibt dies einen Produktivitätsgewinn von insgesamt acht Prozent - im Gegensatz zu den zwei Prozent, die bei einer gleichen Produktivitätssteigerung im Bereich der Neuentwicklung zu erreichen wäre.
Diese oft vorgetragene Argumentation täuscht jedoch darüber hinweg, daß ein hoher Maintenance-Aufwand in direkter Abhängigkeit zur Qualität der Neuentwicklung steht.
Ziel ist nicht, Unsinn schneller zu machen sondern Unsinn zu vermeiden, also die Qualität der Neuentwicklung zu steigern.
Aber auch der Umkehrschluß, sich bei der Einführung neuer Verfahren und Werkzeuge nur auf den Bereich Neuentwicklung zu konzentrieren, ist aus zwei Gründen nicht tragfähig: Erstens existieren Unternehmen nicht auf einer grünen Wiese; sie sind vielmehr in eine bestehende Welt eingebettet, die nicht ignoriert werden kann.
Zweitens ist es nicht sinnvoll, unterschiedliche Klassen von Mitarbeitern zu schaffen. Das Unternehmen stürzt seine mit Maintenance beauftragten Mitarbeiter in eine Motivationskrise, wenn Investitionen in neue Verfahren für die Mitarbeiter getätigt werden, die mit der Neuentwicklung betraut sind.
Aus diesen Gründen muß bei der Einführung neuer Verfahren sowohl die Neuentwicklung als auch der Bereich der Maintenance bedacht werden. Betrachten wir zunächst die Neuentwicklung: Bei der Implementierung von Software-Engineering steht oft die Diskussion um ein Werkzeug einer einzigen Phase, nämlich der Realisierung, im Vordergrund. Die Frage lautet: Soll dieses Werkzeug ein Tool der dritten, vierten oder gar der fünften Generation sein?
Analysiert man den typischen Ressourcenverbrauch eines durchschnittlichen Projektes zur Neuentwicklung von Software (vergleiche Abbildung 2), so relativiert sich jedoch die Bedeutung dieser Diskussion. Selbst bei einer Verdoppelung der Produktivität in der Phase Realisierung beträgt der Produktivitätsgewinn insgesamt nur 15 Prozent.
Noch deutlicher wird diese Aussage durch die Berücksichtigung der Fehlerbehebungskosten relativiert (vergleiche Abbildung 3). Die Vermeidung eines Fehlers kann höhere Produktivitätsauswirkungen haben als ein noch so schnelles Werkzeug in der Realisierung.
Große Fortschritte durch einfache Veränderungen
Aus diesen Überlegungen folgt, daß Investitionen in die frühen Phasen der Software-Entwicklung den höchsten Nutzen erwarten lassen. In diesen Phasen sollte zunächst versucht werden, neue Verfahren und Werkzeuge zu implementieren. Oft lassen sich durch recht einfache Veränderungen der Ablauforganisation (zum Beispiel professionelles Projektmanagement oder Konfigurationsmanagement) große Qualitäts- und Produktivitätsfortschritte erzielen. Der Einsatz von Werkzeugen kann sich zunächst auch auf diese frühen Phasen beschränken.
Obwohl sich eine Verbesserung der Softwareproduktion grundsätzlich auch ohne Werkzeuge erreichen läßt, kann dies nicht empfohlen werden. Zeitgemäße Software-Engineering-Verfahren sind methodenbasiert, und die Erfahrung zeigt, daß nur eine werkzeugunterstützte Methode ausreichend genutzt wird. In Abhängigkeit von dem "Reifegrad" des Unternehmens und seiner Unterstützungskapazität für die Einführung neuer Verfahren können darüber hinaus natürlich auch spätere Phasen unterstützt werden. Bei begrenzten Ressourcen sollte aber der Schwerpunkt auf den frühen Phasen liegen.
In der Regel ist das Thema CARE (Computer Aided Reverse Engineering) nur sehr mangelhaft in die am Markt erhältlichen Softwareproduktions-Umgebungen integriert. Darüber hinaus herrscht eine sprachliche Verwirrung, was denn unter den Begriffen Re- oder Reverse-Engineering zu verstehen sei. Ohne in diesem Zusammenhang auf die einzelnen Facetten des Themas eingehen zu wollen - auch hier bietet sich eine Vielzahl von Möglichkeiten, ohne hohe Investitionen in eine Softwareproduktions-Umgebung kleine Fortschritte erzielen zu können.
Oft existiert in den Unternehmen kein standardisiertes Verfahren (Vorgehensmodell) für die Sanierung von bestehender Software. Diesen Sanierungsprozeß zunächst einmal auf seine unterschiedlichen Varianten durchdacht zu haben, kann ihn bereits erheblich verbessern. Wenn es um die Sanierung einer Applikation geht, sollte bekannt sein, ob es sich zum Beispiel um ein Problem der Redokumentation, um ein Problem der Restrukturierung oder um die Wiedergewinnung einer fachlichen Spezifikation handelt.
Seit einiger Zeit werden am Markt verstärkt CARE-Werkzeuge angeboten. Die technischen Möglichkeiten zum Re-Engineering sind heute allerdings trotz erkennbarer Weiterentwicklung der Analysewerkzeuge - noch sehr bescheiden. Wollen Unternehmen ihre Applikationslandschaft arrondieren, werden sie die Problemlösung nicht bei den Werkzeugen finden. Tools spielen heute - viel mehr noch als bei der Neuentwicklung - in der Wartungsproblematik nur eine bescheidene Rolle.
Selbstverständlich können Konfigurationswerkzeuge, dynamische Analysatoren oder Werkzeuge zur Strukturierung und Dokumentation eine große Hilfe bei der Wartung darstellen. Allein schon um die oben besprochene Zwei-Klassen-Gesellschaft zu vermeiden, sollten erste Gehversuche mit Reverse-Engineering-Werkzeugen unternommen werden.
Die Neuentwicklung ist bisweilen kostengünstiger
Oft wird sich aber zeigen, daß eine wirkliche Sanierung einer Applikation durch diese Werkzeuge nur bedingt gelöst werden kann. Ist eine Applikation über Jahre hinweg "kaputtentwickelt" worden, kann die kostengünstigste Variante der Sanierung die Neuentwicklung sein.
Der Kern der Maintenance-Problematik ist allerdings betriebswirtschaftlicher Natur. Während in der industriellen Produktion Ersatzinvestitionen in die Produktionsmittel eine Selbstverständlichkeit sind, werden DV-Leitern in der Regel keine ausreichenden Budgets zur Verfügung gestellt, um Applikationen periodisch zu sanieren. Geld gibt es meistens erst dann, wenn es bereits mehrfach ordentlich "geknallt" hat. Dann ist es aber auch im allgemeinen schon zu spät. Solange Unternehmen nicht bereit sind, ausreichend Ressourcen für Ersatzinvestitionen in Software zur Verfügung zu stellen, kann die Maintenance-Problematik weder durch neue Verfahren noch durch neue Werkzeuge gelöst werden.
*Ralf Allwermann ist Spezialist für Anwendungstechnologien und Softwareroproduktionsumgebungen bei der Diebold Deutschland GmbH, Eschborn.