Ein wenig verstaubt ist er inzwischen schon, der Begriff "Softwarekrise". Wen wundert's in der extrem kurzlebigen Computerbegriffswelt. Nur erfolgreich bekämpft ist das, Syndrom nicht. Im Gegenteil Ingenieurgeist und -ehre haben zwar mit dem "SW-Engineering" schon bald ein Gegenmittel ins Leben gerufen, wegen der immer noch exponentiell wachsenden Softwaremöglichkeiten konnte es jedoch bis heute nicht entscheidend wirksam werden.
Sicher gibt es eine Menge brauchbarer Engineering-Vorschläge, umgesetzt werden sie jedoch selten - oder sie verpuffen punktuell angewandt wie der Tropfen auf dem heißen Stein. Inzwischen hat sich die Qualitätssicherung dazugesellt. Sie steht in natürlicher Analogie zu anderen Ingenieurdisziplinen, in denen die Erkenntnis schon alt ist, daß man Qualität in ein Produkt reicht hineinprüfen, sondern nur "hineinentwickeln kann, dieses Ergebnis aber dann gründlich überprüfen muß. Insofern sind SW-Engineering und SW-Qualitätssicherung, abgestimmt aufeinander, die logischen Mittel zur Bewältigung der Krise, die durch die immensen Kosten und die mangelnde Qualität des Produktes "Software gekennzeichnet ist, mit allen Folgen für die Betroffenen, Hersteller wie Anwender.
Um es gleich vorwegzunehmen, eine Wunderwaffe kann die SW-Qualitätssicherung im Augenblick noch nicht sein. Sind nämlich die Verfahren, die angewendet werden sollten, weitgehend bekannt, so stecken die Möglichkeiten der physikalischen Meßbarkeit von Software, vornehm "SW-Metrik", noch in den Babyschuhen.
Diese Disziplin ist erst dabei, das Gehen zu lernen. Und ohne diese Meßbarkeit ist die SW-Qualitätssicherung ein solides und geduldig anzuwendendes Handwerkszeug, nicht besonders attraktiv, aber wichtig für eine Ganzheitslösung, die in aller Bescheidenheit oder gerade wegen der Bescheidenheit vielversprechend ist. Aber auch dieses Handwerkszeug will erst einmal beschafft sein, der Umgang damit gelernt werden.
Die derzeitige Praxis der SW-Qualitätssicherung sieht so aus, daß sie von weitsichtigen Managern vorgeschrieben wird. So man auch Hardwarehersteller ist, verfügt man bereits über eine geeignete Organisation. Das läuft so ab (Ähnlichkeiten mit lebenden Personen sind ... ):
Anruf des SW-Entwicklers bei Herrn Meier von der Qualitätssicherung, der mit der Wahrnehmung der SW-QS beauftragt werde (mürrisch): "Ja, hallo, hier Edelmann, also wir wären jetzt fertig zur Abnahme."
Meier. "Ja, hm, ja dann komm ich mal rüber."
Man trifft sich am Rechner.
Edelmann: Also, wir lassen das jetzt mal laufen, da ist kein Fehler mehr drin."
M: "Ich sollte aber vielleicht vorher das Programm mal ansehen."
E: Wenn Sie meinen, aber das ist Assembler, wissen Sie, das kann man nicht so einfach lesen."
E legt M. den Quellcode vor. M. blättert angeregt in den endlosen Seiten.
M: "Hier, fehlt da nicht ein Komma."
E: "Ja richtig, ist aber nur ein Kommentar."
M. (liest vor): "Im folgenden wird der Registersatz gesafet da Re-entrancy gefordert ist - nach "gesafet" muß das Komma stehen."
E: "Ist aber unwichtig."
M: "Ja schon, aber..."
E: (ungehalten): "Gut, machen wir noch rein."
M: "Haben Sie das Programm analysiert?"
E: "Selbstverständlich! Unsere lineare Regressionsanalyse hat eindeutig ergeben, daß die Texturmerkmale mit den ablaufinvarianten Pseudostrukturcharaktern autoinovolutarisch konsistent ist."
M: "Aha, und das recht aus?"
E: "Nun hören Sie mal, wir müssen es doch wissen. Jetzt sollten wir uns aber den Ablauf ansehen."
M: "Na ja, wenn Sie meinen."
Auf dem Drucker erscheint:
"PROGRAMM ABXOO2/CX/0E, VERSION: A/05C", einige Lampen flackern, nach spannenden Minuten kommt der Ausdruck: PROGRAMMENDE: 0 FEHLER."
E (stolz): "Sehen Sie, alles in Ordnung!"
M (unsicher): "Ja, aber, ich habe doch gar nichts gesehen."
E (geringschätzig): Hier steht doch: 0 Fehler!"
M: "Was testen Sie da eigentlich?"
E: "Das Programm natürlich."
M (entschlossen): "Schon, aber so kann ich das nicht beurteilen und auch nicht unterschreiben."
Man trennt sich. Kurz darauf klingelt das Telefon chefartig heftig bei M: "Sagen Sie mal Meier, geht das Programm nun oder nicht?"
M: "Ich kann es so leider nicht beurteilen."
Chef: "Ja, Sie sind doch die hochbezahlten Fachleute, soll ich denn alles selber machen ...(und so weiter)
Also denken Sie daran, da steht 'ne Million dahinter, bis morgen muß das klar gehen."
M zu E: "Also, können wir noch mal?"
E: "Aber bitte, jederzeit."
"PROGRAMM ABX002/CX/0E, VERSION: A/06" "PROGRAMMENDE: 0 FEHLER"
M: "Da hat sich doch die Version geändert."
E: "Ja, wir mußten noch was machen." M (resigniert): "Sind Sie wirklich sicher, daß es fehlerfrei ist?"
E: "Aber ja doch."
M: "Na gut, geben Sie her, wo muß ich unterschreiben?"
14 Tage später steht der aufgeregte Kunde vor der Tür und verlangt Schadenersatz, weil wegen der hohen Fehlerzahl ein ordentlicher Betrieb nicht aufgenommen werden kann. Hinterher Anruf des Chefs bei M: "Da leistet man sich eine sündhaft teuere QS und dann dies..."
Völlig überzogen, das Beispiel? Ich denke nicht.
Ziehen wir die Erkenntnisse daraus:
- Die besten SW-Engineeringmethoden helfen nichts, wenn die Ergebnisse nicht überprüfbar sind, beziehungsweise die Überprüfung nicht transparent ist.
- Es würde auch nichts nützen, wenn das QS-Personal hervorragend ausgebildet ist; ohne entwicklungsbegleitende Verfahren, nur konfrontiert mit einem Endergebnis allein, ist nichts zu machen.
- Die einfache Änderung der Version im Beispiel deutet auf die übliche Unart hin, daß der Entwickler seine eigene Versionsführung völlig unkontrolliert betreibt, was eine wirtschaftliche und erfolgreiche Wartung der Software beinahe ausschließt, zumal der Entwickler in der Wartungsphase meistens schon lange unter dem Termindruck neuer Projekte steht.
- Zum Schluß die bittere Erkenntnis, daß die QS eine verflixt undankbare Aufgabe hat. Ein Grund mehr, sie ernst zu nehmen. Wenn es so läuft wie im Beispiel, hat man nur den Schwarzen Peter (fast) Unschuldigen zugeschoben.
Wie geht man also richtig vor?
Wesentlich ist die Einteilung der Software in überschaubare, kontrollierbare Schritte, Phasenkonzept der Softwareentwicklung genannt.
Diese Phasen sind:
- Die SW-Anforderung (das Was?)
- Der SW-Entwurf (das Wie?)
- Die SW-Realisierung (Codierung und Modultest)
- Die SW-Integration
- Der SW-Betrieb
Diese Phasenaufteilung ist bei allen modernen Engineeringverfahren mehr oder weniger deutlich. Bezüglich der Qualitätssicherung haben die Phasen die Bedeutung von abzunehmenden Teilschritten, für die vor allem gilt, daß ein Zurückspringen von einer Phase in eine vorhergehende nur kontrolliert erfolgen darf.
Eine entscheidende Bedeutung kommt hierbei der Dokumentation zu. Sie darf keine "lästige Angelegenheit" sein, keine ungeliebte, zusätzliche Phase am Ende der Entwicklung, sondern die Dokumente sind vielmehr die verbindlichen Ergebnisse der einzelnen Phasen und müssen entsprechend behandelt werden. Die nächste Folge befaßt sich mit der Abnahme der einzelnen Phasen und mit den geplanten und vorhandenen Werkzeugen zur Unterstützung dieser Aktivitäten.
Fortsetzung folgt
Friedrich Haugg ist als Diplom-Mathematiker bei MBB in Ottobrunn in der SW-Qualitätssicherung tätig.