Software-Qualitätssicherung (QS) steckt weltweit in den Kinderschuhen. Sie ist bisher nicht über den Status eines Feigenblattes hinausgewachsen. Abgesehen von lapidaren Lippenbekenntnissen durch die verantwortlichen Führungskräfte führt sie ein Schattendasein in den meisten Unternehmen: Die Mehrzahl der deutschen Unternehmen hat keine zuständige Stelle für die Software-Qualitätssicherung.
1982 hat Caspar Jones festgestellt, daß nur 15 Prozent des Programmcodes anwendungsspezifisch ist. Die anderen 85 Prozent sind allgemeiner Natur und ließen sich mit ein wenig Mühe wiederverwenden. Der Programmierer selbst hat jedoch wenig Interesse an der Wiederverwendung seines eigenen und erst recht keines an der fremden Codes.
Hierin liegt eine der Hauptaufgaben der Qualitätssicherung: zu verhindern, daß die gleichen Funktionen mehrfach programmiert werden. Code, der nicht erstellt wird, muß weder getestet noch gewartet werden. Jede Anweisung, die nicht geschrieben wird, spart dem Software-Produzenten mindestens 25 Mark an Codier-, Test- und Wartungskosten. Wenn in einem System mit 20000 Anweisungen nur 10 Prozent der Anweisungen eingespart werden, sind das immerhin 50000 Mark.
Ein Beispiel aus der kommerziellen Transaktionsverarbeitung kann dazu dienen, den Nutzen der Code-Einsparung zu illustrieren. Jede Maske, die vom Anwender eingegeben wird, muß erst editiert und formal geprüft werden. Normalerweise schreibt jeder Programmierer eine eigene Routine für diese Funktion, eine Routine, mit 20 bis 40 Anweisungen. Wenn dieser Code einmal als INCLUDE-Segment geschrieben wird, kann er überall in jedes Dialog-Programm hineinkopiert werden. In einem Dialogsystem mit 20 Programmen sind es mindestens 380 Anweisungen, die eingespart werden.
Es gibt zahlreiche andere Beispiele für die Verwendung von COMMON-Code-Standard-Fehlerroutinen, Dateizugriffsschnittstellen, Kalenderprüfroutinen, Tabellenverarbeitung, Plausibilitätsprüfungen etc. In der Tat bestehen kommerzielle Anwendungsprogramme zum größten Teil aus wiederverwendbaren Bausteinen. Es obliegt nur jemanden, der den Überblick hat, auf diese gemeinsamen Funktionen aufmerksam zu machen.
Jay Arthur berichtet aus seiner Erfahrung als Qualitätsprüfer, daß 1 0 bis 20 Prozent des Codes in Anweisungsprogrammen redundant sind. In einem Cobol-Programm mit 2200 Procedure Division Statements konnte er 700 Statements entfernen, ohne die Funktionalität des Programms zu beeinträchtigen. Diese Straffung führte zu einer 30prozentigen Reduzierung der Wartungskosten.
Eine Untersuchung der Universität Purdue von 189 industriellen und militärischen Projekten untermauert das Pareto-Gesetz, nach dem 20 Prozent der Software 80 Prozent der Wartungskosten verursachen. Die überwiegende Anzahl der Probleme stammen aus einem kleinen Teil der Programme und treten im ersten Jahr nach dem Einsatz der Programme auf. Mit einem besseren Test wären über 75 Prozent dieser Probleme vor der Freigabe ans Licht getreten.
Die gleiche Studie kam zu dem Ergebnis, daß sinnvolle Namen und mehr Kommentare die Wartbarkeit der Programme um bis zu 40 Prozent erhöhen. Ein anderes Ergebnis war, daß keine Korrelation zwischen Programmiererfahrung und Programmierqualität erkennbar ist. Im Gegenteil: die Programme der erfahrenen Programmierer haben mehr Fehler und Qualitätsmängel als die Programme von Berufsanfängern.
Aus der Projekterfahrung des Los Alamos Labors geht hervor, daß das Verhältnis zwischen dem Aufwand für Qualitätssicherung und dem Aufwand für Wartung fast 1:1 ist: Für jede Mark, die man in die Qualitätssicherung steckt, spart man eine Mark in der Wartung. Nach der Überarbeitung eines größeren Fortran-Systems mit einer Steigerung der Qualität um 100 Prozent konnte das Los Alamos Labor 160000 Dollar einsparen.
Robert Poston berichtet über die Erfahrung bei Leeds&Northrup Systems in North Wales/Pennsylvania, mit einem Echtzeit-Prozeßüberwachungssystems von 27719 Anweisungen. Das System wurde streng nach den IEEE-Normen für Software-Qualität entwickelt. Im ersten Einsatzjahr des Systems sind lediglich zwei Fehler aufgetreten. Dies entspricht einer Fehlerrate von 0,072 und einer Qualitätssteigerung von 95 Prozent gegenüber früheren Systemen. Gleichzeitig wurde die Produktivität von 7 auf 29 LOC pro Manntag erhöht. 75 Prozent der Fehler sind schon im Unit-Test entdeckt worden. Insgesamt wurden 1056 wiederholbare, dokumentierte Unit-Tests mit 4954 Testfällen gefahren. Danach sind nur noch zwölf Fehler im Systemtest gefunden worden.
Nach den Erfahrungen des IBM-Labors in Böblingen kommen 7,5 bis 15 Fehler pro 1000 Anweisungen vor. Durch Design Reviews, Code-Inspektionen und automatische Programmprüfungen reduziert sich diese Zahl auf unter drei noch vor dem ersten maschinellen Test.
Getrennte Gruppen für Programmierung und Test
Einen der konkretesten Beweise vom Nutzen der Software-Qualitätssicherung haben Victor Basili und seine Mitarbeiter an der Universität Maryland geliefert. Dort wurde ein Experiment mit 15 Kontrollgruppen mit jeweils drei Personen durchgeführt. Fünf Gruppen haben ein Programmsystem nach traditioneller Art ohne Qualitätssicherung durchgeführt. Jedes Teammitglied hat alles gemacht: entworfen, codiert und getestet. Zehn Gruppen haben nach dem "Cleanroom"-Ansatz gearbeitet. Dieser Ansatz sieht eine präzise formale Spezifikation vor, gefolgt von einem Pseudo-Code, in dem nur IF-, WHILE- und CALL-Steuerungen erlaubt sind. Die Programme werden dann auf der Basis des Pseudo-Codes geschrieben. Die "Cleanroom" Teams durften aber nur bis zur Compilierung arbeiten. Ihren Code haben sie gegen die Spezifikation manuell abgeglichen. Getestet wurde durch getrennte Testteams, die die Fehler an die Entwickler berichtet haben.
Die Ergebnisse dieses Experiments geben zum Nachdenken Anlaß. Sechs der zehn "Cleanroom"-Gruppen erfüllten mindestens 91 Prozent der Anforderungen. Dagegen hat keine der konventionellen Gruppen mehr als 80 Prozent der Anforderungen erfüllt. Der Code der "Cleanroom"-Gruppen hatte sinnvolle Namen, mehr Kommentar und weniger Komplexität. Die "Cleanroom"-Programme hatten eine Wiederverwendbarkeit von mehr als 50 Prozent der traditionell entwickelten Programme. Sie hatten auch eine höhere Testdeckung - 97 Prozent gegenüber 86 Prozent, obwohl der Testaufwand niedriger war. Alle zehn der "Cleanroom"-Gruppen haben ihre Phasentermine eingehalten, aber nur zwei der anderen Gruppen.
Das "Cleanroom"-Experiment zeigt eindeutig den Nutzen einer Trennung von Entwicklung und Test. Programmierer, die gezwungen sind, ihre Programme an fremde Tester abzugeben, sorgen dafür, daß die Programme weitgehend korrekt sind. Programmierer, die ihre eigenen Programme testen, verfallen zwangsläufig in ein Trial-und-Error-Syndrom.
Es ist inzwischen müßig, über den Nutzen der Software-Qualitätssicherung zu diskutieren. Der Nutzen ist schon längst nachgewiesen. Die Frage ist nur, ob man den Nutzen kurz-, mittel- oder langfristig betrachtet. Langfristig führt die Software-Qualitätssicherung zu einer bis zu 50prozentigen Verlängerung des Software-Lebenszyklus. Mittelfristig verstärkt sie das Vertrauen der Anwender in die Software. Kurzfristig führt sie zu einer besseren Kontrolle des Managements über den Software-Entwicklungsprozeß und somit zur echten Termintreue.
Literatur
1) Gruman, G.: "Management Cited in Bleak SQA Survey", IEEE Software, May 1988
2) Yourdon, E.: "Software Quality Assurance" American Programmer, Vol. 1, No. 5, July 1988
3) Deutsche Gesellschaft für Qualität e. V.: Software-Qualitätssicherung, DGQ-NTG-Schrift Nr. 12-51, VDE Verlag, 1986
4) Reutyen, H.: "Qualitätssicherung in Software-Projekten", Online, Nr. 1, 1982
5) Shore, J.: "Confessions of a lapsed Software-Engineer", Comm. of ACM, Vol. 31, Nr. 4, April 1988
6) Basili, V./Rombach, H.-D.:"Implementing quantitative SQA - A practical Model", IEEE Software, Sept. 1987
7) Mills, H.: "Principles of Software Engineering", IBM Systems Journal, Vol. 19, Nr. 4, 1980
8) Rombach, H.-D./Basili, V.: "Quantitative Software-Qualitätssicherung", Informatik-Spektrum, Nr. 10, 1987
9) IEEE: Software Engineering Standards, IEEE Computer Society, New York, May 1987
10) Buckley, F.: "Software Standards take shape", Datamation, Oct. 1983
11) Basili, V.: Tutorial on Models and Metrics for Software Management and Engineering, IEEE Computer Society Press, Los Alamitos, 1980
12) Miller, E.: Tutorial - Automated tools for Software
Engineering, IEEE Computer Society Press, Chicigo, 1979
13) Branstad, M.: "Software Engineering Project Standards", IEEE Trans. SE-10, Nr. 1, Jan. 1984
14) Alberts, D.: "Economics of Software Quality Assurance" in Proc. of NCCC Congress, AFIPS Vol 45, Chicago, 1976
15) Boehm, B.: "Software Engineering Economics", Prentice Hall, Englewood Cliffs, 1983
16) Connell, J. /Brice, L.: "Practical Quality Assurance", Datamation, March 1985
17) Sneed, H.: "Software-Qualitätssicherung", Rudolf Müller Verlag, Köln, 1988
18) Crosby, P.: " Quality is Free - The Art of Making Quality Certain", McGraw Hill, New York, 1979
19) Jones, C.: "Programming Productivity - Issues for the Eighties", IEEE Computer Society Press, New York, 1981
20) Arthur, J.: "Software Quality Measurement", Datamation, Dec. 1984
21) Dunsmore, H.: "Evidence supports some truism, belies other", IEEE Software, May 1988
22) Brice, L.: "Existing Computer Applications - Maintain or Redesign - How to Decide" in Tutorial on Software Restructuring, IEEE Computer Society, New York, 1986
23) Poston, R.: "Counting Down to Zero Software Failures", IEEE Software, Sept. 1987
24) Sandscheper, G.: "IBM-Software oder Probleme mit geistigen Produkten", Online, April 1979
25) Selby, R./Basili, V.: "Cleanroom Software Development - An empirical Evaluation", IEEE Trans SE-13, Nr. 9, Sept. 1987
Kosten/Nutzen der Qualitätssicherung
Aus einer Gegenüberstellung der Kosten und Nutzen der Software -Qualitätssicherung geht eindeutig hervor, daß der Nutzen überwiegt.
Die Kosten bewegen sich im Bereich von 7 Prozent bis 50 Prozent der Erstentwicklungskosten. Die Erstentwicklungskosten machen jedoch nur 33 Prozent der Lebenszykluskosten aus, die Kosten der Qualitätssicherung daher nur 2,5 bis 17 Prozent. Bei einer Software, deren Erstentwicklung 200000 Mark und deren Wartung 400000 Mark kostet, werden die Kosten der Qualitätssicherung zwischen 15000 und 102000 Mark betragen. Ist die Qualitätssicherung automatisiert, liegt der Aufwand eher unter 50000 Mark.
Der Nutzen bewegt sich hingegen im Bereich zwischen 10 und 40 Prozent der Lebenszykluskosten. Bei Lebenszykluskosten von 600000 Mark sind es 60000 bis 240000 Mark. Diese Kalkulation ist eine reine Kostenbetrachtung. Dazu kommt der qualitative Nutzen wie zufriedene Anwender, größeres Vertrauen und ein guter Ruf. Wenn man diesen Nutzen zu dem rechnerischen Nutzen hinzufügt, kann es keinen Zweifel geben: Software-Qualitätssicherung lohnt sich.
Schon innerhalb von zwei Jahren nach dem ersten operativen Einsatz der Software könnten sich die Kosten der Qualitätssicherung amortisieren. So gesehen ist eine Qualitätssicherung für jedes Software-System mit einer Lebensdauer von mehr als 24 Monaten angebracht.