Von Karl-Ferdinand Daemisch*
Eine analytische Marktstudie zu CASE hat sich nicht mit Kriterienkatalogen begnuegt, die von Anbietern auszufuellen waren. Praxisbezug ergab erst ein Abgleich mit Testinstallationen und Implementierungen in Unternehmen. Welche Rolle spielen die ISO- 9000-Normen im CASE-Umfeld?
Software und ihre Entwicklung ist und bleibt fehlerbehaftet. Das Problem kennen sowohl die IT-Abteilungen in den Unternehmen als auch die sicherheitskritischen Programme der Nasa und professionelle System- und Softwarehaeuser. Hier wie dort wirkt sich diese Binsenweisheit gravierend aus, obwohl fuer Tests - als Faustformel - ohnehin schon rund die Haelfte der gesamten Projektzeit anzusetzen ist.
Gegen beim Kunden reifende Bananensoftware
"Es kann auf die Dauer jedoch kaum angehen, dass Kunden die Betatester fuer neue Softwarepakete spielen", kommentiert Uwe Kaufmann von der Koelner Firma Qualitec Ebasco, einem Tochterunternehmen der TUEV-Rheinland-Gruppe, eine in diesem Markt leider haeufig anzutreffende Praxis.
Angesichts solcher Missstaende war es naheliegend, dass sich die Qualitaetspruefer vom Technischen Ueberwachungsverein um Software zu kuemmern begannen. Ihr Verfahren ist eine genormte Vorgehensweise nach den unter DIN-ISO 9000 veroeffentlichten Regeln. Dahinter steht die Ueberlegung: Was in der industriellen Fertigung moeglich ist, sollte auch im Software-Engineering realisierbar sein.
Doch ganz so einfach ist es nicht. Allein die sehr fertigungsorientierte Sprache der Normen tut sich mit der Definition von Software und ihren Kriterien schwer. Widerstand ruehrt sich aber auch in der neuen objektorientierten Welt. Deren Propheten betonen den kreativen Akt, das Design staerker als eine nuechtern angelegte Softwarekonstruktion.
Qualitaetssicherung gilt der Prozesslenkung
Das ist nicht verwunderlich: Werden ISO-9000-Normen zitiert, ist bei 60 Prozent aller Faelle von DIN ISO 9001 (Qualitaets-Management- System) mit QS-Modellen zu Design/Entwicklung, Produktion, Montage und Kundendienst die Rede. Auf die Norm 9002, einer Untermenge zu 9001, entfallen noch 35 Prozent.
Kaum fuenf Prozent aller fraglichen Punkte beziehen sich auf den fuer Software-Entwicklung am ehesten zutreffenden Normabschnitt 9003. Zu ihr gehoeren, aus den auch als Euro-Norm EN 29000 bekannten Festlegungen, der Teil 3 des insgesamt vierteiligen 9000er Katalogs und Teil 2 (Dienstleister) des 9004- Leitfadenkompendiums. Koennen diese Normen zu sicherer und weitgehend fehlerfreier Software fuehren? "QS ist nicht in erster Linie produktbezogen zu sehen", stellt Kaufmann klar. QS benoetigt jedoch mess- und greifbare Groessen. Hier liegt denn auch, durch Regelablaeufe, ein erster Ansatz fuer Computer Aided Software Engineering (CASE). Software-Aufgaben kommt Kaufmann dann naeher: "Das eigentliche Ziel von QS ist die Prozesslenkung." Als Beispiel fuer die Programmentwicklung nennt er die Rueckverfolgung von Release-Versionen: Welcher Kunde hat welches Release? Welcher Entwickler arbeitet mit welchen Mitteln an welchem Release-Stand? Diese ISO-Anforderungen sind zwar oft erfuellt, in vielen Software- Unternehmen jedoch nicht dokumentiert - eine Schwachstelle. Verhelfen damit CASE-Tools den Software-Unternehmen zu besseren Produkten? In der Industrie, so ein Erfahrungswert, werden immer noch rund 80 Prozent aller CASE-gestuetzten Projekte vorzeitig abgebrochen. Die Antwort von Dr. Georg Herzwurm, Mitarbeiter am Lehrstuhl fuer Wirtschaftsinformatik der Uni Koeln, differenziert daher: "Zumindest die Suche nach geeigneten traditionellen wie objektorientierten CASE-Tools kann unsere Studie erleichtern.
Aber der Anwender muss sich im klaren sein, dass der Kauf von CASE- Werkzeugen nicht automatisch zum Erfolg oder zur ISO- Zertifizierung fuehrt." Herzwurm wertete auf der einen Seite der Studie Ergebnisse einer empirischen Untersuchung in der deutschen Versicherungswirtschaft aus. Hier setzen 42 Prozent der Anwender CASE bereits ein, 28 Prozent planen dies. Die restlichen 30 Prozent befassen sich nicht damit. Auf der anderen Seite begnuegte sich Herzwurm nicht mit Kriterienkatalogen, die von den Anbietern auszufuellen waren. Ohne Qualitaetssicherung kommt also auch eine derartige Arbeit nicht aus.
Die Angaben der CASE-Hersteller wurden von den Pruefern nicht einfach uebernommen, sondern mit Testinstallationen und bei Endanwendern verifiziert. Insgesamt sind 60 Werkzeuge anhand von Frageboegen, 27 auf der Basis des Kriterienkatalogs erfasst. In den Evaluierungsbeispielen wurden 17 Tools ausgewertet, darunter "Maestro II" von Softlab oder das PC-gestuetzte Systems Engineer, aber auch das in Deutschland von Instrumatic vertriebene objektorientierte und Workstation- sowie Unix-basierte "Teamwork" von Cadre. Komponenten dieses Systems waren auffallend haeufig bei verschiedenen Elementen innerhalb des QS-Rahmens nach ISO 9003 als Beispiele von - vorsichtig formuliert - teilerfuellten Anforderungen genannt. Die Anwender mit positiven CASE-Erfahrungen nannten als Vorteile eine Verbesserung der Qualitaet und der Ergebnisse, der Wartbarkeit sowie der Koordination der Entwickler und des Projekt-Managements. Dies sind alles Argumente fuer die ISO-Normen. Widerstand der Beteiligten und unterschaetzte Kosten fuehrten zu negativen Aussagen: Mangelhafte Werkzeuge, fehlende Integration oder Ausbildungs- und Beratungsdefizite erbrachten weder mehr Produktivitaet noch qualitative Verbesserungen.
Erwartungen nicht zu hoch ansetzen
"So schlecht sind die Erfahrungen also insgesamt nicht", urteilt Herzwurm. "Das trifft allerdings nur zu, wenn die Erwartungen nicht zu hoch sowie Einfuehrung und Einsatz richtig geplant sind." Ergebnisse zu den Aspekten Kosten und Zeit entnimmt er amerikanischen Untersuchungen des Forschungsinstituts Ovum aus dem Jahre 1993. Sie ergaben Fuenfjahreskosten pro Entwickler von 36000 Dollar. Ein Break-even sei, so die US-Studie, etwa nach drei Jahren zu erwarten: Nach zwei Tagen Produkt- und zwei Wochen Methodenschulung seien etwa zwei Jahre zur Beherrschung von Tool und Methoden vorzusehen.
Fast 60 Prozent der untersuchten Werkzeuge sind neueren Datums und wurden in den Jahren seit 1990 in den Markt eingefuehrt. Analyse, Entwurf und Realisierung unterstuetzen ueber 90 Prozent der Tools. Pflege und Wartung umfassen noch 60, Erprobung und Konsolidierung nur mehr 50 Prozent.
Meist favorisieren die Werkzeuge nur eine Methode. Mehrfache Verwendung kommt nur in einem objektorientierten System, bei Cadres Teamwork nach Shlaer/Mellor sowie in einer zweiten Version nach Rumbaugh vor. Das bietet dem Anwender eine hoehere Bandbreite der Methodenwahl. Structured Analysis (SA) spielt - als funktionale Methode - mit 40 Prozent den zahlenmaessigen Vorreiter. Bereits auf 30 Prozent Marktanteil kommen objektorientierte Ansaetze wie OOA und OOD (Object-oriented Analysis/Design).
Den Tools mangelt es an Durchgaengigkeit
Die Untersuchung unterscheidet die Tools jedoch nicht nach Grundlagen wie Shlaer/Mellor oder Rumbaugh. Standards wie das V- Modell (das Vorgehensmodell der deutschen Bundeswehr), CASE Data Interchange Format (CDIF), Information Ressource Dictionary System (IRDS) sowie das ECMA-Referenzmodell (European Computer Manufactures Association) bringen weitere Elemente von QS in traditionelles CASE ein. Der Mangel an Durchgaengigkeit ist die groesste Schwachstelle bei funktionalen Tools.
Dem stehen Staerken wie Standards, stabile und ausgereifte Mittel mit breiter Funktionsabdeckung in der Software-Entwicklung gegenueber.
Objektorientierte Methoden dagegen zeichnen sich durch ihre Durchgaengigkeit aus. Bei den Spitzenprodukten finden sich bereits sehr gute Anbindungen an relationale Datenbanken und C++-Compiler. Eine Schwaeche fand Herzwurm mit seinen Mitarbeitern allerdings heraus: Ein unreifer Markt kennt kaum Methodenstandards. Die universitaeren Untersuchungen ergaben eine breite Streuung bei Funktionalitaet und Qualitaet der Werkzeuge.
Daher beruft er sich auf Werner Mellis, Lehrstuhlinhaber am Koelner Institut fuer Wirtschaftsinformatik: Fuer die Objektwelt sollten Pilotprojekte den Entwicklern Erfahrungen sowie Kenntnisse der Methoden und ihrer Eignung bringen. Ein QS-Ziel ist die Absicherung der unternehmerischen Produkthaftung. Daher bildete eine Analyse des Ist-Zustands fuer potentielle CASE-Anwender generell und fuer Softwarehersteller insbesondere den unumgaenglich ersten Schritt in Richtung ISO.
Organisatorische Massnahmen stehen in der Software-Entwicklung dabei im Vordergrund. Darin sind die Entwicklungsprozesse ebenso festzulegen wie Verfahren zu ihrer angemessenen Dokumentation. Diese muss Antworten liefern, ob die Prozesse auch wirklich vollstaendig so entwickelt wurden wie dokumentiert.
Werkzeuge koennen eine Hilfe sein, um den QS-Systemleitfaden nach der internationalen Norm umzusetzen. Entsprechend leistungsfaehige CASE-Werkzeuge decken dabei sowohl die Management- als auch produktive Funktionen in den verschiedenen Entwicklungsstadien und QS-Phasen ab.
Daraus laesst sich die Dokumentation fuer ein - vor allem im amerikanischen Markt wichtiges - Zertifizierungs-Verfahren nach ISO 9000 ableiten.
"Der Weg zu CASE", so der Koelner Wirtschaftsinformatiker, "fuehrt ueber die Altsysteme." Dann konkretisiert er: "CASE ist ein wichtiges, aber nicht das einzige Element fuer Softwarequalitaet unter ISO 9000." Die Begruendung zitiert er aus dem "IEEE Software- Magazin": "A Fool with a Tool remains a Fool, only his Foolness is automated."
CASE-Tools sind nicht mehr als QS-Elemente
ISO-Normen koennen jedoch qualifiziertere Grundlagen zur Bewertung liefern als heute noch weitgehend uebliche Verfahren. Sie funktionieren mehr oder weniger nach dem Prinzip von Versuch und Irrtum.
Exemplarisch ist IBMs Verhalten gegenueber externen Auftragnehmern. Befinden sich in vorgelegten Test-Listings zu viele Fehler, sind sie ein Beweis fuer nachlaessige Arbeit. Zu wenige Bugs liefern aber ebenfalls Grund zum Misstrauen. Die Testmethoden koennten lueckenhaft oder vielleicht nur schlampig angewendet sein.
Solche Verfahren koennen die ISO-9000-Normen sicher nicht verbessern. "Ziel der ISO-Reihe ist es nicht, von Organisationen entwickelte, eigene Qualitaetssysteme zu normen", so Kaufmann. Er raeumt ein: "Wir wissen, dass speziell die 9001-Terminologie auf Software nicht so recht passt. Dafuer ist nur die Norm 9003 besser anwendbar."
Dass auch diese Regeln verbesserungsfaehig sind, belegt ihre 1994 vorgesehene, neu ueberarbeitete Reihe. Software wird aber auch in Zukunft keine zu Spielzeug oder Eierkocher analoge Produktzulassung erhalten.
Qualitaet laesst sich nicht umfassend garantieren
Die grosse Huerde beim Wunsch nach Zertifizierung ist eine umfangreiche Dokumentation. Sie hat bereits beim Antrag zur Zertifizierung vorzuliegen: "In Deutschland muss sie nicht so extrem ausfuehrlich gehalten sein wie in den USA.
Die deutsche Norm kennt zwar harte Muss-, aber auch Kann- Bestimmungen", troestet Kaufmann deutsche Unternehmer. Sie haben es sogar leichter als in Amerika: Genormte Hilfestellung beim Verfassen von QS-Handbuechern ist unter DIN ISO 10013 zu erhalten.
Noch befinden sich die Verfahren zur Qualitaetssicherung von Software in der Entwicklung. Haeufig muessen sich Auditor und Auditierter noch an die Problemstellungen herantasten. "Daher wird es fuer Programmpakete ein Funktionssiegel analog zum Signet ,Gepruefte Sicherheit' zumindest auf absehbare Zeit nicht geben", vereitelt Kaufmann allzu grosse Hoffnungen.