Schlechtes Image erschwert die Arbeit der QS-Abteilung:

Güteprüfung ist mehr als eine lästige Pflicht

18.01.1985

Qualitätssicherung muß nicht zwangsläufig als Störenfried in DV-Projekten empfunden werden. Bestehende Methoden und Werkzeuge bieten durchaus befriedigende Lösungen an, Doch nur die Einsicht in die Notwendigkeit der QS-Maßnahmen verspricht auch den gewünschten Erfolg.

Für den Begriff "Software-Qualität" gibt es meines Erachtens zur Zeit noch keine exakte, allgemein anerkannte Definition. Im Rahmen dieses Beitrages reicht ein ganz allgemeines Verständnis des Begriffes. Unter ,"Qualität" kann man sich zum Beispiel in Anlehnung an DIN 55 350 (l) die Summe der Eigenschaften und Merkmale eines Produktes oder einer Tätigkeit vorstellen, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse beziehen.

Entscheidend für die Qualität des Endproduktes ist jedoch die Qualität eines jeden Zwischenproduktes während der gesamten Projektlaufzeit.

Zwei Wege führen zum Ziel

Innerhalb der QS werden häufig zwei Arten unterschieden (2), nämlich konstruktive und analytische Maßnahmen zur Qualitätssicherung. Durch den Einsatz konstruktiver Maßnahmen zur QS wird erreicht, daß das entstehende Produkt von vornherein bestimmte Eigenschaften (Qualitätsmerkmale) hat. Ein typisches Beispiel dafür ist die Verwendung einer bestimmten Programmiersprache eines bestimmten Compilers.

Im Gegensatz dazu dienen die analytischen Maßnahmen der Feststellung der Qualität eines Produktes. Inspektion, Walk-through, Review, Programm-Verifikation oder Test sind Beispiele für analytische Maßnahmen.

Dieser Beitrag bezieht sich in den weiteren Ausführungen überwiegend auf die analytischen Maßnahmen. Denn im Gegensatz zu den konstruktiven Maßnahmen, die eine gewisse Qualität fast automatisch erzeugen - man denke zum Beispiel an das Ergebnis eines fehlerfreien Compile-Laufes -, ist bei analytischen Maßnahmen die menschliche Mitarbeit verstärkt gefordert.

"Risiko" bedingt QS-Aufwendungen

Auf die Notwendigkeit des Einsatzes von Maßnahmen zur QS muß nicht besonders hingewiesen werden. Ein Blick in die allgemeine Literatur zu diesem Thema zeigt, daß sich eigentlich alle betroffenen Gruppen in der Theorie über diese Problematik im klaren sind; sei es auch nur, um ein Gütesiegel für Software zu erhalten. Auch die Beschreibung nicht durchschaubarer Software-Systeme (3) schärft den Blick für QS.

Die Erkenntnis dieser Problematik hat auch in vielen Fällen zur Ergreifung von Maßnahmen zur QS geführt. Der Umfang der qualitätssichernden Maßnahmen hängt dabei normalerweise vom Verwendungszweck der erstellten Software ab. Je höher das mit dem Einsatz der Software (DV-Projektergebnis) verbundene "Risiko" ist, desto umfangreicher werden die erforderlichen QS-Aufwendungen sein.

Es ist unbestritten, daß Unternehmensleitung, Auftraggeber, DV-Management, Datenschutzbeauftragte und RZ-Leitung besonderes Interesse an Qualitätssicherung haben. Das Interesse ist zwar durchaus unterschiedlich und auf verschiedene Qualitätsmerkmale ausgerichtet, aber vorhanden ist es in jedem Fall.

Unlust beeinflußt oft das Ergebnis

Durch die folgende Behauptung soll ein Aspekt besonders hervorgehoben werden: Nicht nur der Nutznießer, Empfänger oder Auftraggeber eines Produktes beispielsweise Zwischenproduktes hat ein (berechtigtes) Interesse an QS, sondern auch jeder Mitarbeiter im DV-Projekt ist daran interessiert, möglichst qualitativ hochwertige Produkte zu erstellen.

Demzufolge müßte jeder Mitarbeiter Maßnahmen zur QS begrüßen und aktiv unterstützen, da sie es ihm ermöglichen, vernünftige Produkte zu erstellen. Da QS dennoch vielfach als lästige Pflicht empfunden wird, kann man davon ausgehen, daß untaugliche Methoden und Werkzeuge verwendet oder diese falsch beziehungsweise ungeschickt eingesetzt werden.

"Qualis" gelten als unproduktiv

Die Qualitätssicherung beziehungsweise der QS-Mitarbeiter hat im allgemeinen ein relativ schlechtes Image. In Anwenderkreisen werden die "Qualis" leicht als für die Projektarbeit unproduktive Mitarbeiter betrachtet. Erfolglose Versuche, einen Anwendungsentwickler zum Wechsel in die QS zu bewegen, können diese Aussage belegen.

Maßnahmen zur QS werden denn auch aus den unterschiedlichsten Gründen für entbehrlich gehalten:

- Zeitmangel,

- Projekt klein, überschaubar,

- alles erfahrene Mitarbeiter,

- Kostenfrage,

- der Glaube, eingesetzte Werkzeuge garantieren automatisch Qualität.

Der Verzicht auf QS mag im Einzelfall berechtigt sein, oft aber liegt eine Fehleinschätzung der Situation vor.

QS-Maßnahmen werden zwar oft in DV-Projekten mit eingeplant, greifen aber häufig erst zu einem recht späten Zeitpunkt. So entsteht die Situation, reagieren zu müssen, anstatt vorausschauend die Weichen zur Erlangung von Qualität stellen zu können.

Solange das Projektmanagement bis hin zur Unternehmensleitung bei Zeitknappheit zuerst auf die Erlangung von Qualitätsmerkmalen verzichtet, darf man sich nicht wundern, wenn auch die besten und teuersten Werkzeuge keine Qualität garantieren. Gleiches gilt für Kunden oder Fachabteilungen, die an der Fertigstellung und dem Einsatz eines Projektergebnisses interessiert sind.

Qualität hat ihren Preis. Hierüber müssen sich alle Beteiligten im klaren sein. Verzichtet auch nur eine beteiligte Gruppe zugunsten eines eigenen, scheinbaren Vorteils auf bestimmte Qualitätsmerkmale ist der Weg bereitet für einen insgesamt nachlässigeren Umgang mit Maßnahmen zur QS.

Aufklärung verbessert QS-Image

Dabei werden durchaus unterschiedliche Anforderungen an die Qualität der DV-Produkte gestellt. Geschieht dieses nicht in Kooperation, so sind die Schwierigkeiten bereits vorprogrammiert. Gleiches gilt für die Kooperation zwischen der eigentlichen Institution QS und den anderen Mitarbeitern im DV-Projekt. Die Folgen fehlender Integration der QS in das Gesamtprojekt werden leicht unterschätzt.

Qualität darf nicht einfach pauschal gefordert werden, sondern für jedes Produkt oder Zwischenprodukt sollten den beteiligten Mitarbeitern die speziell geforderten Qualitätsmerkmale erläutert werden. Ein allgemeines Programmiererhandbuch ist normalerweise für den Einzelfall nicht ausreichend. Ein allgemeines Verständnis von Qualität ist eigentlich bei allen DV-Projekt-Mitarbeitern vorhanden; die Erreichung bestimmter Qualitätsmerkmale wird dadurch allerdings kaum garantiert.

Auch analytische Maßnahmen zur QS dürfen nicht dazu dienen, im nachhinein Fehler oder Abweichungen festzustellen und zu rügen, sondern müssen den Urheber davor bewahren, diese Mängel zu produzieren beziehungsweise ihn in die Lage versetzen, diese selbst erkennen zu können.

Der QS muß durch alle DV-Projekt-Phasen hindurch das nötige Gewicht beigemessen werden. Dieses geschieht häufig durch die Vorgabe qualitätsbezogener Ergebnistypen im Rahmen von Projektplanungsinstrumenten.

Tool-Einsatz allein nützt wenig

Die Einsicht in diese Notwendigkeit muß unbedingt auch bei allen Projekt-Randgruppen erreicht werden (DV-Ausbilder, Fach- und Führungskräfte in allen DV-Nutzer-Bereichen, Datenschutzbeauftragte, Unternehmensleitung). Nur so läßt -sich ein gewünschter Qualitätsstandard erreichen. Insbesondere wenn Schwierigkeiten im Projektverlauf auftreten, kommt es auf diese allgemein vorhandene Einsicht an.

Was zur notwendigen Imageverbesserung - von QS getan werden kann, hängt sehr stark von den Umständen im Einzelfall ab. Eine gleichberechtigte Einbettung der QS in die Projektarbeit ohne unnötige Hervorhebung der Prüf- und Kontrollfunktionen wäre ein sinnvoller Weg zur Imageverbesserung. Schulungen, die Einsicht in die, Notwendigkeit von QS fördern und die Aufgaben und Möglichkeiten des einzelnen im Rahmen der QS hervorheben, tragen sicherlich zur weiteren Integration der QS in die DV-Projektarbeit bei.

Weiterentwickelte Werkzeuge werden den Einsatz von QS zwar verbessern, es ist aber nicht abzusehen, daß sie in naher Zukunft diese zwischenmenschlich-kommunikativen Probleme lösen beziehungsweise die Lösung dieser Probleme überflüssig machen.

Literaturverzeichnis

(l) DIN 55 350

Deutscher Normenausschuß e. V.

Begriffe der Qualitätssicherung und Statistik

Begriffe der Qualitätssicherung, Grundbegriffe

(2) Balzert 82

Die Entwicklung von Software-Systemen H. Balzert

Bibliographisches Institut, Mannheim/Wien/Zürich 1982

(3) Weizenbaum 77

Die Macht der Computer und die Ohnmacht der Vernunft

J. Weizenbaum

suhrkamp Taschenbuch wissenschaft 274, Frankfurt am Main 1977

*Andreas Haase ist leitender Berater für SW- Projekte in der Versicherungsbranche bei der PU - Partnerschaftliche Unternehmensberatung GmbH, Hamburg.