Dr. Peter Hruschka International Product Manager CASE bei GEI - Gesellschaft für Elektronische Informationsverarbeitung GmbH, Aachen
Viele suchen heute nach Allheilmitteln, den Anwendungsstau zu lindern, der alle DV-Anwender plagt. Wenn man dabei nur auf die Produktivitätssteigerung der Programmierer schielt, hat man vielleicht nicht das richtige Ziel vor Augen.
Verschiedenste Lösungsansätze wurden und werden versucht: massive Attacken auf die Anzahl Codezeilen pro Jahr, Massenautomatisierung zur Generierung von Programmzeilen, und auch neue wissensbasierte Ansätze zur Systementwicklung. Keine davon hat den wirklichen Durchbruch geschafft. Die Lösung für des Problem Anwendungsprogrammierung liegt vielleicht weniger bei der Produktivität der Entwickler, sondern in der Qualität der Endprodukte.
Einige Studien in den USA haben jüngst gezeigt, daß man 75 Prozent der Software für kommerzielle Anwendungen zu spät fertigstellt, um sie sinnvoll einsetzen zu können. Oder daß sie zu Programmen führt, die nicht das produzieren, was der Anwender braucht - wenn sie überhaupt abgeschlossen werden.
Nehmen wir als Beispiel ein Unternehmen, das beliebige Gebrauchsgüter herstellt. Der Manager dieses Unternehmens stellt eine Ausschuß- oder Zurückweisungsrate von 75 Prozent fest. Als Entschuldigung wird genannt: Das fertige Produkt funktioniert entweder nicht, oder es kommt wegen umfangreicher Nacharbeiten zu Lieferschwierigkeiten. Er würde sehr rasch zu dem Schluß kommen, daß hier kein Kapazitäts- oder Produktivitätsproblem vorliegt, sondern ein Qualitätsproblem.
Untersucht man Firmen, die eine statistische Qualitätssicherung für ihren Produktionsprozeß eingeführt haben, so wird diese Aussage nur bekräftigt. Traditionelle Qualitätssicherung sondert lediglich bei der Endkontrolle die mangelhaften Teile aus. Die statistische Qualitätssicherung führt hingegen Toleranzstandards für Einzelteile ein. Sie stellen sicher, daß die einzelnen Teile am Ende zusammenpassen und als Ganzes funktionieren. Auf der Teilproduktebene erreicht man mit statistischer Qualitätssicherung ungefähr die gleiche Gesamtproduktivität, aber mit wesentlich weniger Ausschuß.
Auf höheren Integrationsebenen ist jedoch ein interessanter Effekt zu beobachten: Fügt man die Teilprodukte zusammen, dann funktioniert das Gesamtprodukt auf Anhieb - ohne daß man vielen Teilprodukten noch Nacharbeiten erledigen muß. Ohne diese Zeit- und Geldverschwendung der Nachbesserung steigt die Produktivität rasant an!
Die Software Entwicklung ist einer Produktion ähnlich, die mehrstufig aus Komponenten Gebrauchsgüter herstellt. Obwohl die Kosten für Software denjenigen für viele Gebrauchsgüter sehr nahe kommen, hat sich die Industrie hier noch nicht zu ingenieurmäßigen Verfahren durchgerungen, um die benötigte Qualität zu erreichen.
Wie also lassen sich Softwaresysteme von hoher Qualität herstellen? Und was bedeutet Qualität hier überhaupt? Betrachten wir nur einen kleinen, aber wesentlichen Teil dieses umfangreichen Problems. Der amerikanische Consultant Philip Cosby hat in seinem Buch "Quality is free" eine einfache Definition der Qualität aufgestellt: "Qualität ist die Übereinstimmung mit den Anforderungen". Diese Definition gilt für Software genau so wie für andere Güter. Wenn es gelingt, die Anforderungen adäquat festzulegen,
dann haben wir eine gute Basis für Qualitätsprodukte. Jeder Systemanalytiker wird bescheinigen, daß auch dies keine einfache Aufgabe ist.
Aber trotzdem gibt es immer noch Software-Entwickler die diese Problematik mit Intuition allein angehen. Verglichen mit der Fertigung hieße das, aus vorgegebenen Plänen die Maße der Präzisionsteile per Abschätzung herauszulesen.
Die Aufgabenstellung ist also vorgegeben - aber leider nur in der Sprache der Anwender. Hier muß - wie in jeder anderen Ingenieurwissenschaft auch - Ingenieurwissen einsetzen und man muß die Aufgabe mit Werkzeugen angehen. Die Zeiten, wo solche Werkzeuge nur Bleistift und Augenmaß waren, sind auch im Software Engineering längst vorbei.
Erhebt man Anspruch auf Professionalität, so ist hier das Wort Case - Computer Aided Software Engineering - fällig. Case gibt die Chance, wohlgemerkt die Chance, von 75 Prozent Ausschuß wegzukommen. Voraussetzung dafür ist ja, das zu lösende Problem in die Modellwelt zu übersetzen, um Kommunikation in einer verständlichen, aber präzisen Notation zu ermöglichen. Textliche, grafische und formale Darstellungen sollte man dazu kombinieren.
Eine qualitätsorientierte Produktion hört jedoch nicht nach dem Erfassen der Anforderungen auf. Im nächsten Schritt muß man sicherstellen, daß diese Anforderungen auch erfüllt werden. Dies ist bei Software - Gott sei Dank - leichter als bei der Produktion von Gebrauchsgütern.
In diesem Bereich stellen die führenden Case-Produkte schon Werkzeuge zur Verfügung. Spätestens durch Implementierungs-Überlegungen kommen jedoch im Normalfall noch weitere Verfeinerungen im Entwurf hinzu. Case-Werkzeuge, die hier Anforderungen mit den ursprünglichen Konzepten vergleichen und sogar Teile des endgültigen Codes automatisch generieren, sind da eher noch die Ausnahme.
Kurz gesagt: Case-Werkzeuge können heute einen qualitätsorientierten Produktionsprozeß unterstützen. Dadurch, daß man Fehler bereits sehr früh ausschaltet, passen die Code-Modulen, die zusammenpassen müssen, auch tatsächlich zusammen, und man bekommt die Software-Fabrik diesseits der Software-Steinzeit. Die Produktivität steigert man dann automatisch, indem die ehemals 75 Prozent Software-Schrott auch zu einsetzbarer Ware werden.
Man sollte noch einmal darüber nachdenken ob hier nicht seit langem die Wirkung mit der Ursache des Problems verwechselt wird. Wenn wir 75 Prozent unseres Aufwands verschwenden, dann ist es höchste Zeit, wirklich lauffähige Systeme für realistisch kalkulierende Firmen zu erstellen - mit Qualität als dem wichtigsten Ziel vor Augen.