Definitionen für Softwarequalität erschöpfen sich häufig in allgemeinen Erläuterungen: Das Produkt ist im Hinblick auf den Anwenderkreis mit geringem Aufwand benutzbar, portabel und führt korrekt, zuverlässig und effizient die geforderten Funktionen aus. Zudem soll im Interesse der SW-Entwickler der Aufwand des Testens, der Wartung und Änderungen möglichst gering sein. Damit ist jedoch die Qualität des Produktes noch keineswegs ausreichend definiert.

Die aufgeführten Eigenschaften sind qualitativer Art und somit bei einer Vielzahl von Beteiligten nicht sicherbar, weil diese Qualitätsbegriffe für eine Überprüfung nicht konkret genug sind. Diskussionen innerhalb der Entwicklungsteams oder mit den Kunden zeichnen sich zur Zeit doch häufig darin aus, daß zwar jeder der Beteiligten Kriterien wie Bedienerfreundlichkeit oder Zuverlässigkeit fordert, aber jeder wiederum etwas anderes konkret unter diesen Eigenschaften versteht. Für den einen Kunden drückt sich Bedienungsfreundlichkeit in der Menütechnik, für den anderen in der Kommandotechnik aus. Effizienz mißt Benutzer A in Zeiteinheiten einer Dialogfunktion, Anwender B in benötigten Systemressourcen der Rechenanlage.

Aber auch in der Entwicklungsgruppe selbst sind die Anforderungen nicht einheitlich. Der eine beabsichtigt, jede Programmieranweisung inline in Prosa zu dokumentieren; der andere - in der Praxis häufiger anzutreffende Typus - sieht nur die Notwendigkeit, den Autorennamen im Programm festzuhalten. Für manche Systemanalytiker bedeutet Modularisierung gleich Atomisierung einer komplexen Aufgabenstellung, während andere auch Modularität definieren, aber beispielsweise statt hundert nur fünfzig Module für erforderlich halten. Die Liste unterschiedlicher Auffassungen über Software-Qualitätseigenschaften läßt sich beliebig fortsetzen.

Damit die eingangs aufgeführten Anforderungen nicht reine Makulatur bleiben, ist die Festlegung quantitativer Anforderungen an das Produkt erforderlich. An dieser Stelle wird man derzeit die erste Enttäuschung erleben. Außer einer Vielzahl von qualitativen Eigenschaften findet der Interessierte nur in wenigen Veröffentlichungen Vorschläge für quantitative Kenngrößen.

Ausprägung nach Produkttyp unterschiedlich

Dies mag darin begründet sein, daß viele Kenngrößen einzeln betrachtet trivial erscheinen gegenüber einer qualitativen Definition einer Anforderung. Sicherbar ist letztendlich aber nur die banal erscheinende quantitative Kenngröße, wobei ihre Ausprägung je nach Produkttyp und Einsatzumgebung unterschiedlich sein kann.

Die generelle Vorgehensweise bei der Entwicklung von Qualitätsmaßen beginnt mit der Festlegung von Kriterien der Softwarequalität. Diese Kriterien werden in einem Top-down Vorgehen durch weitere Kriterien beschrieben beziehungsweise konkretisiert. Diese Verfeinerung wird schrittweise fortgesetzt, bis eine Stufe erreicht ist, auf der die qualitativen Eigenschaften in quantitative Meßgrößen umgesetzt werden können. Mit diesen quantitativen Meßgrößen können jetzt formale Eigenschaften eines Programms wie Größe oder Komplexität gemessen werden. Die auf der unteren Ebene gewonnenen Meßergebnisse werden in einem Bottom-up-Ansatz zu Aussagen auf den Kriterienebenen verdichtet. Mit dieser Aggregation erhält man nur quantifizierte Aussagen über die Qualität beziehungsweise einzelne qualitative Eigenschaften von Softwareprodukten.

An der Definition solcher Qualitätskriterien und Meßgrößen arbeiten zur Zeit verschiedene Institutionen. Zielsetzung hierbei ist eine weitgehend einheitliche Verwendung der Begriffe, um zu einer quantitativen und damit objektiven Beurteilung der Qualität von Softwareprodukten zu kommen.

Zur Beantwortung der Frage "Wer sichert die Qualität" sind die Aufgaben einer Qualitätssicherungsstelle und die Alternativen der ablauf- und aufbauorganisatorischen Eingliederung näher zu untersuchen. Die Aufgaben der Qualitätssicherungsstelle umfassen analytische Maßnahmen zur Feststellung der Qualität, beispielsweise die Überprüfung definierter Zwischenprodukte, um eine Abnahmeentscheidung zu treffen. Um die geforderte Qualität der Zwischenprodukte zu erreichen, sind aber auch konstruktive Maßnahmen seitens der Qualitätssicherungsstelle notwendig. Dazu gehört der Einsatz geeigneter Werkzeuge und Methoden zur Systementwicklung.

So sind einige Aufgabenschwerpunkte für eine Qualitätssicherungsstelle nicht wegzudenken:

- Aufstellen eines allgemeinen Qualitätssicherungsplanes und Modifikation dieses Rahmenplanes für einzelne Projekte.

- Auswahl und Betreuung der erforderlichen Methoden und Werkzeuge zur Systementwicklung.

- Beratung und Schulung der Programmierer und Systemanalytiker für den Einsatz dieser Werkzeuge.

- Entwicklung quantitativer Kenngrößen für die Abnahme definierter Zwischenprodukte zwischen den einzelnen Entwicklungsphasen.

- Berichterstattung an übergeordnete Stellen bezüglich Produktentwicklung, festgestellter Mängel und Verbesserungsvorschläge.

Kompetenz sichert Qualität

Die Organisation der einzelnen Arbeitsabläufe, die Bildung von Stellen und die Zuordnung einzelner Aufgabenschwerpunkte wird von Unternehmen zu Unternehmen unterschiedlich sein. Die Festlegung der Kompetenzen und Verantwortlichkeit für die Qualitätssicherungsstelle sowie die Bildung erforderlicher Informationswege zu anderen Stellen ist eine grundlegende Voraussetzung damit eine definierte Qualität gesichert werden kann.

Die Organisationslehre der Betriebswirtschaft behandelt unterschiedliche Organisationsstrukturen wie Linien-, Stab-, Matrix- oder Projektorganisationen. Aus empirischen Untersuchungen liegen zwar bereits Aussagen über Vorteile und Nachteile der einzelnen Strukturen vor. Diese sind aber noch umstritten.

Alternativen zur Organisationsstruktur können die institutionalisierte Abteilung Qualitätssicherung oder die Bildung projektbezogener Qualitätssicherungs-Gruppen sein.

Die Vorteile bei einer institutionalisierten Abteilung sind die Kontinuität der Mitarbeitenden und die "Verpflichtung" durch Institutionalisierung. Nachteile ergeben sich beispielsweise durch "Abteilungsdenken" oder die Ablehnung dieser "Kontrollinstanz" durch die Softwareentwickler.

Insbesondere diese Nachteile sprechen für die Bildung projektbezogener Qualitätssicherungsgruppen. Die Teilnehmer sind Delegierte aus dem Entwicklungsteam und den späteren Anwendern des Produktes.

Es ist im einzelnen festzulegen, in welchen Phasen eine Teilnahme der verschiedenen Personengruppen sinnvoll ist. Durch die Einbeziehung und Mitwirkung aller Personengruppen, die in Verbindung zu dem zu erstellenden Produkt stehen, werden die häufig anzutreffenden Feststellungen wie "wir wurden ja nicht befragt" verhindert.

Erfahrung wird gebunkert

Wie einzelne Unternehmen die Funktion Software-Qualitätssicherung und ihre Arbeitsabläufe organisiert haben, ist derzeit relativ unbekannt. Dies mag zum einen daran liegen, daß viele Unternehmen sich noch in einem Status der Experimentierphase befinden, zum anderen aber auch in dem falsch verstandenen Konkurrenzdenken, die selber gemachten Erfahrungen - und seien es auch schlechte - anderen publik zu machen.

SW-Qualität wird automatisch erreicht, setzt man nur die geeigneten Werkzeuge ein. Der in dieser werbewirksamen Aussage enthaltene Anspruch konnte jedoch bisher nicht erfüllt werden. Denn ein großer Teil der am Markt angebotenen SW-Tools sind lediglich mehr oder minder komfortable Editoren beziehungsweise sehr programmiernahe Instrumente.

Mittlerweile hat sich die Erkenntnis durchgesetzt, daß SW-Qualität nicht nur eine Sache der Codierung ist. Die ersten Phasen des Entwicklungsprozesses wie Problembeschreibung, Definition der Benutzeranforderungen und Grobentwurf haben bereits großen Einfluß auf die SW-Qualität.

Um den gesamten SW-Entwicklungsprozeß zu unterstützen, sind mehrere verschiedenartige Werkzeuge erforderlich. Hier reicht es nun nicht aus, für jede Phase der Programmentwicklung irgendein geeignetes Instrumentarium einzusetzen. Vielmehr ist die Verträglichkeit der einzelnen Tools miteinander von großer Bedeutung.

Die Ergebnisse der Anwendung eines Werkzeugs in einer Phase sind Input für das Werkzeug der nachfolgenden Phase. Voraussetzung für die daraus erforderliche Kompatibilität ist eine einheitliche Methodik. Dadurch wird die grundsätzliche Vorgehensweise zunächst einmal unabhängig von bestimmten Werkzeugen festgelegt. Diese müssen flexibel genug sein, um sie auch bei verschiedenartigen Problemstellungen einsetzen zu können.

Untersucht man die am Markt angebotenen Instrumentarien zur Softwareentwicklung, wird die Diskrepanz zwischen diesen allgemein anerkannten Anforderungen und der Wirklichkeit deutlich.

Tools taugen nicht zur Analyse

Qualitätssicherung ist durch ihre Maßnahmen sowohl konstruktiv als auch analytisch. Durch entsprechenden Einsatz von Werkzeugen wird ein Produkt mit Qualität konstruiert. Daneben sind aber auch Werkzeuge erforderlich um zu analysieren, inwieweit die Qualitätsanforderungen im Rahmen der Konstruktion erfüllt wurden. Der überwiegende Teil der am Markt angebotenen Tools hat vorwiegend konstruktiven Charakter.

Um die Qualität messen zu können, müssen - wie bereits erwähnt - Prüfkriterien definiert sein. Diese sind in Abhängigkeit von der Entwicklungsphase festzulegen. Am konkretesten sind solche Qualitätskriterien bisher für das Endprodukt "Programm" entwickelt worden. Nun ist es jedoch sehr mühsam, die Überprüfung quantitativer Kenngrößen manuell durchzuführen. Der Aufwand bei Programmsystemen mit mehreren Tausend Lines of Code ist beträchtlich. Daraus resultiert die Forderung nach geeigneten Werkzeugen, um diese Aufgabe zu erfüllen.

Eine Vielzahl von Prüfkriterien bezieht sich auf formale Eigenschaften eines Programms und sind somit auch automatisch meßbar. Daneben existieren jedoch auch Eigenschaften, die bisher nur durch den Menschen beurteilt werden können. Auch hier ist eine Werkzeugunterstützung möglich, um beispielsweise eine Vorauswahl der zu beurteilenden Programmteile durchzuführen und das Ergebnis der Beurteilung zu verwalten und weiterzuverarbeiten.

Diese funktionalen Anforderungen an ein Werkzeug zur Messung der Programmqualität waren für das Institut für Wirtschaftsinformatik an der Universität Saarbrücken Ausgangspunkt für die Entwicklung des Programmsystems "Epsos-D", welches die Beurteilung formaler Eigenschaften ermöglicht und darüber hinaus auch die Prüfung der funktionalen Eigenschaften unterstützt. Das Programmsystem ist eine dialogorientierte Prüfungsumgebung, in der verschiedene Werkzeuge zur Qualitätssicherung zusammengefaßt sind.

Die Anwendung des Systems erfolgt in mehreren Schritten. Zunächst werden die formalen Qualitätseigenschaften von Programmen zergleidert:

- lexikalische Analyse

Es werden sämtliche im Programm enthaltenen Elemente wie Anweisungen, Daten oder Kommentare erfaßt und in der Datenbasis abgelegt

- Strukturelle Analyse

Die Folgen von Anweisungen, wie sie bei der Ausführung des Programms ablaufen, werden in einem Programmgraphen abgebildet.

- Messung der Qualitätsmerkmale

Basierend auf den bisherigen Analyseergebnissen werden Meßgrößen für die Qualitätsmerkmale ermittelt. Hierbei werden Qualitätsmerkmale unterschieden, die automatisch meßbar sind und solche, die nur im Dialog mit dem Menschen gemessen werden können.

- Beurteilung der Qualitätskriterien

Aus den Meßgrößen werden Beurteilungen der Qualitätskriterien abgeleitet.

Die auf verschiedenen Ebenen verdichteten Ergebnisse bieten dann einen guten Überblick über die Qualität von Programmen und Programmteilen. Die Meßgrößen decken Schwachstellen sehr detailliert auf.

Auf der Basis der Meßergebnisse werden dann jene Programmelemente ermittelt, die wegen ihrer Konstruktion softwaretechnische Risiken beinhalten. Diese Vorauswahl kann dazu genutzt werden, solche risikobehafteten Programmteile einer besonders intensiven funktionalen Prüfung zu unterziehen.

Das Programmsystem wird auf einem IBM-PC-XT implementiert. Es ist für den Einsatz zur Softwareentwicklung und Qualitätssicherung auf Mikrorechnern, aber auch als Workstation zur Prüfung von Programmen auf Großrechnern konzipiert.

Jörg Ahlers und Wilfried Emmerich sind wissenschaftliche Mitarbeiter am Institut für Informatik der Universität des Saarlandes, Saarbrücken.

Informationen zum Programmsystem Epsos-D sind erhältlich vom Institut für Wirtschaftsinformatik an der Universität des Saarlandes Direktor Prof. A.-W. Scheer, Gebäude 14, 6600 Saarbrücken 11.