Bei der Durchsetzung eines Qualitätssicherungs-Systems ist für alle Beteiligten eine genaue Aufgabenverteilung unerläßlich. Erst wenn alle Betroffenen die festgelegten QS-Maßnahmen als Selbstverständlichkeit betrachten, kann die Realisierung eines solchen Vorhabens als geglückt gelten. In seinem Vortrag anläßlich des von CW/CSE veranstalteten Software-Forums '85 berichtet Rudolf van Megen* über Erfahrungen bei der Einführung von QS-Systemen.
Das Erstellen eines Qualitätssicherungs-Konzepts, die Präsentation vor Bereichsleitern, Abteilungsleitern und gegebenenfalls Gruppenleitern sowie die Schulung aller Mitarbeiter im großen Stil bedeutet noch nicht, daß ein QS-System durchgesetzt ist. Ein QS-System (siehe Abbildung 1) ist erst dann innerhalb einer Unternehmung/Institution eingeführt, wenn alle Anwender von QS-Maßnahmen diese als selbstverständlich ansehen und durchführen.
Aufgabenträger der QS sind zunächst einmal die Mitarbeiter der Projekte. Diese müssen einen großen Teil der qualitätssichernden Aufgaben erledigen. Dazu ist es zunächst einmal - aus der Sicht des Projektleiters - erforderlich, die QS-Maßnahmen einzuplanen. Dies gilt auch dann, wenn grundsätzlich behauptet wird, daß QS generell etwas Altes sei, bei dem man fast alles wie bisher macht, nur eben etwas anders. Dieses "etwas anderes" verlangt die Planung der notwendigen Maßnahmen. Hier stellt aber der Projektverantwortliche vielfach die Fragen: Was kostet QS? Was bringt QS? Welche Auswirkungen ergeben sich auf die derzeitigen Entwicklungsmethoden? Diese drei Überlegungen stehen eigentlich am Anfang jeder Einführung der Qualitätssicherung.
Die Frage danach, was Qualitätssicherung kostet, ist unter dem Aspekt zu betrachten, was als gerechtfertigt und heute notwendiges Maß anerkannt wird und was in der Planung berücksichtigt wurde. Beantwortet man die erste Frage zum Beispiel für die analytische Qualitätssicherung das heißt Testen von Dokumenten und Programmen, dann sind zwischen 30 und 50 Prozent vom Gesamtprojektaufwand hierfür anzusetzen. Ist im Rahmen der Projektplanung ein entsprechender Prozentsatz - der normalerweise aufgrund unternehmensspezifischer Erfahrungswerte zustande gekommen sein sollte - eingeplant worden, dann gibt es für QS keinen Mehraufwand; das heißt allerdings nicht, daß gegebenenfalls doch Verschiebungen der Aufwandsanteile innerhalb des Software-Entwicklungsprozesses aus der Sicht der Qualitätssicherung resultieren.
Häufig wird auch die Frage gestellt, wie die Mitwirkung der zentralen QS aus Projektmitteln abgerechnet wird. Sofern Leistungen der zentralen QS direkt projektindividuell abgerechnet werden, wird vielfach beim Projektleiter schon durch die zusätzlichen Kosten eine Abwehrhaltung erreicht - Kosten sind unter anderem eine seiner Zielgrößen. Die Zurechnung als Gemeinkosten ist im Vergleich dazu viel einfacher, weil sie nicht nur das einzelne Projekt trifft. Die Frage danach, was Qualitätssicherung bringt, ist zunächst abhängig von den Zielen, die bei der Entwicklung des QS-Systems gestellt worden sind. Beispiele für den Nutzen der Qualitätssicherung sind:
Produkte, das heißt Zwischen-/ Endergebnisse müssen fertiggestellt sein, bevor mit anderen Ergebnissen begonnen wird; dadurch wird erreicht, daß nicht der "zweite Schritt vor dem ersten getan wird".
Die Fachseite schreibt die Anforderungen an das Softwaresystem in voller Kenntnis der fachlichen Sachverhalte fest; dadurch wird erreicht, daß die heute vielfach üblichen späteren Änderungen wesentlich seltener auftreten.
Die einzelnen Schritte sind überschaubar; so wird zum Beispiel durch das schrittweise Testen von Programmen - zuerst Bausteintest dann Funktionstest, dann Vorgangstest - erreicht, daß von kleinen Einheiten ausgehend die Testausführung jeweils überschaubar bleibt und dadurch der Aufwand zur Erreichung eines vorgegebenen Ziels geringer ist, als wenn dasselbe Ziel zum Beispiel durch Testen in einem Schritt erreicht werden sollte.
Durch den Support der zentralen QS in den Projekten werden die Mitarbeiter unmittelbar bei ihrer Arbeit unterstützt, das heißt die Umsetzungsproblematik ist nicht da oder gering.
QS kann nicht auf der grünen Wiese aufsetzen
Die Frage, welche Auswirkungen sich auf die derzeitige Entwicklungsmethodik ergeben, ist zunächst einmal berechtigt. Hier wird gegebenenfalls in einem laufenden Projekt vermutet, daß Teile der Dokumentation neu erstellt oder geändert werden müssen oder Dinge nachzuarbeiten sind. Dies ist im wesentlichen eine Frage der Einführungsstrategie. Wenn man davon ausgeht, daß Qualitätssicherung kaum "auf der grünen Wiese" aufsetzt, sondern in eine bestehende und funktionierende Organisation eingebunden werden muß, dann gehört für die Einführung von QS-Maßnahmen sicherlich gutes Fingerspitzengefühl dazu, welche Maßnahmen in welchem Projekt eingeführt werden sollen. Es ist also grundsätzlich nicht erforderlich, daß alle QS-Maßnahmen in allen Projekten gleichzeitig eingeführt werden müssen.
Auswirkungen auf die derzeitige Entwicklungsmethodik können sich zum Beispiel dadurch ergeben, daß bestimmte Aktivitäten oder Aufgaben im Vorgehensmodell ergänzt oder zu anderen Zeitpunkten durchgeführt werden; Auswirkungen sind auch insofern möglich, daß Aspekte der analytischen Qualitätssicherung in die konstruktiven Maßnahmen integriert werden. Wenn diese drei grundsätzlichen Fragen der Projektverantwortlichen zunächst einmal als Hürde genommen worden sind, weil erste Befürchtungen sich nicht bestätigt haben, beginnt die eigentliche Aufgabe der Durchsetzung des QS-Systems.
Die meisten Anwender sind schon mit einem dieser Probleme konfrontiert worden:
- QS macht zusätzliche Arbeit erforderlich, der Termin muß verschoben werden.
- Wegen QS sind zusätzliche Entwickler nötig.
- In diesem Fall konnte kein Bausteintest gemacht werden, da. . .
- QS-System wird nicht angewendet.
So kann Qualitätssicherung zum Sündenbock werden - nachdem diese Funktion bisher von einem anderen neuen Hilfsmittel eingenommen wurde.
Realistische Planung des Restaufwands
Es kann allerdings auch anders sein: Die frühzeitige Testfallermittlung hat sich bereits jetzt bezahlt gemacht. Endlich ist eine realistische Planung des Restaufwands für Testen möglich. Meßbare Zielvorhaben für das Testen sind endlich vorhanden. Positive wie negative Stimmen sind immer zu erwarten; es gibt kaum Maßnahmen wo alle der gleichen Meinung sind.
Ausgangspunkt der Durchsetzung eines Qualitätssicherungs-Systems ist, daß ein QS-Konzept entwickelt wurde und nach den ersten grundlegenden Schritten der Einführung nun die Umsetzung im Rahmen der Projektarbeit erfolgt (siehe Abbildung 2). Bei der Durchsetzung des QS-Systems muß man sich folgender Tatsachen bewußt sein:
QS zum Nulltarif - der Unterschied zwischen Wunsch und Wirklichkeit
Daß Qualität in gewissem Maße Kosten verursacht, ist unbestritten. Die erforderlichen Kosten werden sowohl vom Management als auch vom Projektleiter akzeptiert. Dies um so mehr, als der entsprechende Aufwand nicht grundsätzlich zusätzlich anfällt, sondern bisher bereits vorhanden war, wenn eventuell auch zu anderen Zeitpunkten.
Aufgrund der im Rahmen der Konzeption des QS-Systems festgelegten Aufwandsverteilung für Qualitätssicherung wird der erforderliche Aufwand in den unterschiedlichen Phasen des Projekts eingeplant. Bei der Nachkalkulation für ein Projekt stellt man allerdings häufig fest, daß der ursprünglich geplante Aufwand für alle anderen Aktivitäten beziehungsweise Aufgaben verwendet worden ist, aber nicht - zumindest teilweise nicht - für die geplanten QS-Aktivitäten. So werden zum Beispiel geplante Aufwendungen für das Testen von Dokumenten zunächst einmal dafür benutzt, das Dokument abschließend zu erstellen.
Durchsetzung einer Methode vor der Durchsetzung von Werkzeugen
Werkzeuge zur Qualitätssicherung - zum Beispiel Werkzeuge zum Erstellen der Testumgebung für den Bausteintest und Tools zur Simulation von Dialogschnittstellen für den Vorgangstest - können eine wesentliche Hilfe sein, um über eine reproduzierbare Testumgebung aufzubauen und gegebenenfalls einen automatisierten Soll-Ist-Vergleich durchzuführen. Man kann sogar sagen, daß solche Werkzeuge in gewissem Maße eine Voraussetzung dafür sind, einen Bausteintest überhaupt generell durchzuführen.
Allerdings muß zunächst einmal festgelegt sein, wann Bausteine separat zu testen sind; dies ist um so wichtiger, als normalerweise die generelle Durchführung für alle Bausteine kaum realisierbar ist. Anhand dieses Beispiels wird deutlich, daß vor der technischen Anwendung des Werkzeugs zunächst einmal klar sein muß, wann das entsprechende Werkzeug wie eingesetzt werden soll. Die Methode zur Durchführung der entsprechenden QS-Maßnahmen steht also zunächst im Vordergrund.
Meinungsträger sind der "Motor"
Die Durchsetzung der Qualitätssicherung ist um so leichter realisierbar, je mehr Unterstützung durch sogenannte Meinungsträger gegeben ist. Meinungsträger können aus den ersten Projekten resultieren, die das QS-System anwenden; darüber hinaus kommen die Meinungsträger aber im Anfang zunächst aus der Managementebene. Das Management hat - unter anderen durch Vorgabe einer klaren Qualitätspolitik - mehr Einfluß auf die Softwarequalität als jeder Projektleiter oder Systementwickler.
Planung von QS-Maßnahmen ist notwendig
Die Planung der aufgrund des Qualitätssicherungssystems generell notwendigen QS-Maßnahmen für ein Projekt ist notwendig. Dabei sollte möglichst früh innerhalb eines Projekts festgelegt werden, was zu tun ist. Hierbei besteht durchaus die Möglichkeit, Details später auszuarbeiten. Nur dadurch kann sichergestellt werden, daß eine. "Meßlatte" existiert, an der der Projektverantwortliche gemessen wird. Andernfalls ist durchaus die latente Gefahr vorhanden, daß zwar die globale Anwendung der im QS-System festgeschriebenen Maßnahmen zugesagt wird, im nachhinein stellt sich jedoch heraus, daß es sehr viele Gründe dafür gibt, warum gerade das eine oder andere nicht getan werden konnte beziehungsweise worden ist.
Einbeziehen von Aufgaben/Fachabteilung
Wer heute noch Argumente benutzt, "der Anwender hatte unterschrieben" oder "die Fachabteilung war doch dabei" baut damit nur ein Alibi auf. Aus Sicht der QS stellt die bloße Unterschrift eines Anwenders unter ein Fachkonzept noch nicht sicher, daß das Ergebnis inhaltlich von der Fachseite getragen wird. Gründe dafür sind, daß die Fachabteilung unter Umständen den Inhalt des Fachkonzepts überhaupt nicht detailliert gelesen hat oder nicht verstanden hat, weil unter Umständen Darstellungsformen verwendet worden sind, die für diesen Personenkreis ungeeignet sind.
QS ist mehr als externe Kontrolle, aber externe Kontrolle ist auch notwendig
Wer projektexterne Qualitätssicherung ausschließlich als Kontrolle der Vollständigkeit im Hinblick auf Formalziele versteht, wird bei der Durchsetzung des QS-Systems erhebliche Schwierigkeiten haben. Die zentrale Qualitätssicherung sollte sich auf die Aufgaben konzentrieren, die für die Entwickler eine Hilfe bei ihrer Arbeit sind. Zentrale QS hat unter anderen die Aufgaben: Das QS System festzulegen, für Auswahl und Einführung von QS-Verfahren-/ Werkzeugen und Schulung von QS-Verfahren/-Werkzeugen zu sorgen sowie bei der Anwendung von QS- Verfahren/-Werkzeugen in den Projekten zu beraten.
Gerade die Beratung bei der Anwendung von QS-Maßnahmen ist eine unbedingt notwendige Aufgabe, der zentralen Qualitätssicherung Wenn zentrale QS sich nur als "strategische Betreuung" versteht und nicht unmittelbar die Projektprobleme "anpackt", dann hat diese Funktion schnell die Kurzbezeichnung "Quali". Die zentrale QS soll aber keine Qual, sondern eine Hilfe für die Projekte darstellen.(wird fortgesetzt)
*Rudolf van Megen ist Geschäftsführer der SQS GmbH, Köln.
Der Beitrag basiert auf einem Vortrag der anläßlich des von CW-CSE veranstalteten Software-Forums '85 gehalten wurde. Die vollständigen Proceedings sind zum Preis von 110 Mark bei CW-Edition, Herzogstraße 39, 8000 München 40, erhältlich.