Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.07.1992 - 

Projektmanagement in der Praxis (Teil 14)

Qualitätssicherung: Integraler Teil der Entwicklungsarbeiten

Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen

Projektgruppe, München und Honorarprofessor an der Universität Göttingen;

Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe,

München.

Die Bedeutung der Qualitätssicherung wird zwar durchweg betont, in der Projektpraxis wird sie aber häufig Opfer des Zeitdrucks oder anderer Umstände. Erforderlich sind Formen der Qualitätssicherung, die integraler Teil der Entwicklungsarbeiten sind.

Das Spektrum der organisatorischen Ansätze, die in den untersuchten Projekten der Qualitätssicherung dienen sollten, war recht groß. Es reichte von hochformalisierten Regelungen bis zu weitgehend naturwüchsig entstandenen, informellen Verfahren. In der Vielfalt der Regelungen der Qualitätssicherung und ihrer Handhabung in der Praxis war ein verbindlicher, allgemein gültiger Kodex nicht erkennbar.

In etwa jedem vierten Projekt gab es eine eigene Gruppe oder Abteilung, die für die Qualitätssicherung formal zuständig war; in etwa einem Fünftel der Projekte gab es Qualitätsbeauftragte. Häufiger als auf solch "externe" Instanzen trafen wir auf projektinterne Qualitätssicherung: durch den Projektleiter (46 Prozent) oder durch die Kollegen (28 Prozent). Etwa ein

Viertel der Projekte, vorwiegend kleinere, kam ohne jede formalisierte Regelung der Qualitätssicherung aus.

So verschieden die Träger der Qualitätssicherung, so unterschiedlich waren auch die angewandten Methoden.

- In jedem dritten Projekt stützte man sich auf Qualitätsreviews, in denen nach jedem Arbeitsschritt dessen Ergebnisse von einem Kreis sachverständiger Kollegen und Führungskräfte kritisch durchleuchtet und diskutiert wurde.

- Häufig praktiziert wurden auch unterschiedliche Formen des Code-Reading durch den Projekt- oder Gruppenleiter oder Kollegen.

- Vereinzelt trafen wir auf die Bildung von Qualitätsgespannen, in denen jeweils zwei Entwickler wechselseitig für die Qualität der Arbeit des anderen "zuständig" waren.

Hinter der Vielfalt von Gestaltungsansätzen, die in kaum zwei Projekten gleich waren, ließen sich zwei "Philosophien" erkennen, an denen diese ausgerichtet waren:

- Inspektionsansatz: Qualität soll durch Kontrolle von außen gewährleistet werden. Der Projektstand und die Arbeitsprodukte werden nach festgelegten Prüfkriterien beurteilt.

- Diskussionsansatz: Qualität soll sich als Resultat eines kritischen Verständigungsprozesses ergeben, in den für die einzelnen Arbeitsprodukte neben dem "Autor" auch andere Mitglieder des jeweiligen Teams einbezogen sind.

Ein Beispiel für eine "außengesteuerte" Vorgehensweise bei der Qualitätssicherung: In einem großen Industrieunternehmen gilt für alle Entwicklungsprojekte ein Vorgehensmodell, in dem detailliert festgelegt ist, welche Aktivitäten von welchen Stellen in den einzelnen Projektphasen durchgeführt werden und welche Ergebnisse sie erledigen müssen. In diesem Vorgehensmodell gibt es auch einen umfangreichen Katalog von "Prüfobjekten" für die projektbegleitende Qualitätssicherung sowie einen ausführlichen Maßnahmenplan. Prüfobjekte waren dabei Software-technischer Art, aber auch Zieldefinitionen, Terminpläne, selbst Schulungsunterlagen. Dieses Modell sollte in dem Projekt erstmalig zur Anwendung kommen. Gemeinsam mit Vertretern der Qualitätssicherungs-Gruppe wurde im Projektteam festgelegt, wie die einzelnen Phasen zu dokumentieren waren und welche Dokumente der Qualitätssicherung zur Prüfung vorgelegt werden sollten. Darüber hinaus sollten von der Qualitätssicherung Standards für die Programmierung festgelegt und regelmäßig code readings durchgeführt werden. Die fertig entwickelten Module sollten dann zur Prüfung an die Qualitätssicherung übergeben werden. Zur Erledigung aller dieser Aufgaben stand neben der Projektleiterin lediglich eine Mitarbeiterin zur Verfügung. Diese Mitarbeiterin brach irgendwann - wegen totaler Überforderung, wie man erzählt - zusammen und übernahm eine andere Aufgabe; an ihre Stelle trat eine neu eingestellte, sehr junge, unerfahrene Mitarbeiterin, die den Aufgaben kaum gewachsen war, insbesondere fehlte ihr offensichtlich der nötige Respekt bei den Entwicklern, die ihr meist an Alter wie an Erfahrungen weit überlegen waren. Das de facto bestehende Vakuum im Bereich der Qualitätssicherung wurde zum Teil ausgeglichen durch die sehr engagierte Projektleitung, den kontinuierlichen und sehr engen Kontakt, den die Projektleiterin mit ihren Mitarbeitern hielt.

Qualitätsstandards nur für ein Drittel

Dieses Schicksal der Qualitätssicherung ist typisch für einen beträchtlichen Teil der Projekte, in denen der "Inspektionsansatz" verfolgt wurde. Zwischen dem formal festgelegten Verfahren zur Qualitätssicherung und seiner tatsächlichen Anwendung im Projekt verlauf bestand eine beträchtliche Diskrepanz.

Nach den Angaben unserer Gesprächspartner, die unsere Recherchen in einem Teil der Projekte im wesentlichen bestätigten, wurde Qualitätssicherung nur in 48 Prozent der Projekte konsequent praktiziert. In 26 Prozent wurde sie weitgehend formal gehandhabt, in etwa einem weiteren Viertel stand sie nur auf dem Papier oder fehlte ganz.

Diese defizitäre Durchführung der Qualitätssicherung war im wesentlichen zurückzuführen auf fehlende bzw. unzureichende Qualitätskriterien, relativ geringe Verbindlichkeit dieser Kriterien und unzureichende Ressourcen.

Unzureichende Qualitätskriterien: In einem Großteil der Projekte konnte man nicht auf etablierte Qualitätsstandards zurückgreifen. Diese mußten erst im Verlauf des Projekts definiert werden beziehungsweise hätten definiert werden müssen.

Nur in gut einem Drittel der Projekte konnte man auf Qualitätsstandards, die für das Unternehmen vorgegeben waren, zurückgreifen, wobei jedoch in der Hälfte der Projekte diese noch durch projektspezifische Qualitätsvorgaben ergänzt wurden. In 40 Prozent der Projekte stützte man sich ausschließlich auf solche projektbezogenen Standards, in immerhin einem Viertel fehlten solche.

Man hatte erkennbar Schwierigkeiten, "Qualität" zu definieren. Das galt für Projektleiter Entwickler und Qualitätsbeauftragte gleichermaßen. In vielen Projekten war kein einheitliches, gemeinsames Qualitätsverständnis erkennbar. Qualität definierten Gesprächspartner sehr unterschiedlich.

"Egozentrisches Qualitätsverständnis"

"Qualität, das heißt für mich zuallererst, daß ich keine Rücklaufe kriege- also keine Funktionen zurückkommen, die beim Kundentest Fehler aufwiesen. Qualität bedeutet aber auch, daß die Arbeit gut dokumentiert ist, so daß auch ein anderer damit arbeiten kann."

"Qualität meiner Arbeit ist erstens, daß das Programm tut, was es tun sollte, und zweitens, daß es abgesichert ist gegen Fehlerfälle, daß es also zu keinen Systemabstürzen oder ähnlichen Problemen bei der Anwendung kommt. In den Richtlinien standen zwar Kriterien zu Übersichtlichkeit und Lesbarkeit, aber mit denen weiß ich nichts anzufangen."

"Qualität meiner Arbeit ist dann erreicht, wenn die Funktion das, was sie soll, fachlich abdeckt; die Funktion soll gut strukturiert, funktionsfähig und gut lesbar sein."

"Qualität meiner Arbeit ist, eine gestellte Ausgabe so zu lösen, daß sie terminlich und finanzmäßig sauber abgewickelt ist. Das Programm muß so entwickelt sein, daß der Kunde mit dem Produkt umgehen und es weiterbearbeiten kann. Da ich nie mehr das Produkt in die Finger kriege, muß es so gebaut sein, daß der andere es auch verstehen kann. Dazu ist es notwendig, daß ich beschreibe, warum ich was gemacht habe; bei dieser Beschreibung beschränke ich mich auf das, was nicht im Handbuch oder sonstwo beschrieben ist. Im Grunde fängt Qualität bereits ganz am Anfang mit der Hinterfragung der Anforderungen an, ich muß mich reindenken und wissen, was und wie der Kunde sich die Realisierung gedacht hat. Im Verlauf des Prozesses fordere ich den Kunden auf, rückzumelden, ob er mit meinem Produkt umgehen kann."

So umfassende Definitionen, wie diese letzte, waren allerdings die Ausnahme. Bei zahlreichen Softwareentwicklern trafen wir auf eine Einstellung, die man als "egozentrisches Qualitätsverständnis" bezeichnen könnte, das heißt man orientierte sich im wesentlichen an Qualitätsvorgaben, die man sich selbst gesetzt hatte, agierte sozusagen als sein eigener Qualitätsbeauftragter.

Das vielfach vage Qualitätsverständnis und die Abweichungen, die sich hier innerhalb der Projektteams zeigten, ließen eine ausdrückliche Verständigung über Qualitätsziele und Qualitätskriterien besonders wichtig erscheinen. In nur wenigen Projekten wurde aber konsequent der Versuch gemacht, einen solchen Qualitätskonsensus im Team herzustellen. Das war dann meist ein aufwendiges Unterfangen. Schon die Definition dessen, was man unter "Qualität" fassen wollte, konnte zu grundsätzlichen Überlegungen und Auseinandersetzungen führen. Immer wieder wurde deutlich, daß für die Bestimmung der Qualität ein eindeutiger Zielbezug notwendig gewesen wäre, und gerade dieser fehlte in vielen Projekten genauso wie Konventionen oder Vorgaben für das Vorgehen bei der Softwareentwicklung, deren Einhaltung als Qualität gemessen werden konnte. Selbst dort, wo Kriterien formuliert wurden, machte deren Operationalisierung Schwierigkeiten. So fiel es schwer, Begriffe wie "Lesbarkeit" oder "Wartbarkeit" in harte, eindeutig überprüfbare Kriterien zu übersetzen.

"Wir haben letztlich keine verbindlichen Qualitätskriterien und so kommen wir auch nicht zu meßbaren Ergebnissen. Ich nehme mir eine Spezifikation vor und analysiere sie auf ihre Konsistenz. Was ich nicht erfassen kann, aber natürlich erfassen müßte, ist, ob die Spezifikation das enthält, was die Anwender wirklich brauchen. Da fehlt mir der Einblick, ich habe keine Zeit, mich mit den Anwendern zu unterhalten."

Geringe Verbindlichkeit: In den meisten Projekten hatten die Regelungen zur Qualitätssicherung nur relativ geringe Verbindlichkeit. Ihre Durchsetzung hing in hohem Maß von den jeweiligen Umständen ab.

Qualitätssicherung quasi als Holschuld

"Ich hatte keine Machtposition. Wenn ich sagte, ich kann das nicht durchgehen lassen, dann haben sie es doch durch gehen lassen, einfach wegen des Zeitdrucks, auch wenn es sich dann später gerächt hat. Wenn ich mich dann trotzdem durchsetzen wollte, mußte ich da so fundiert argumentieren, da so in die Tiefe gehen, das kostete mich zuviel Zeit. Das macht man nur ein paarmal, dann läßt man es." Qualitätssicherung wurde so quasi als Holschuld behandelt. Der mit der Qualitätssicherung Beauftragte mußte nicht nur die Einhaltung der Qualitätsstandards überwachen, er mußte auch letztlich selbst da für sorgen, daß seine Kritik Konsequenzen hatte.

"Ich war total überfordert, selbst nachzuschauen, was jeweils der letzte Stand war. An sich hätten ja die Entwickler mir ihre Arbeit bringen müssen. Das geschah aber nicht."

Unzureichende Ressourcen: Gerade die Behandlung von Qualitätssicherung als Holschuld trug zur strukturellen Überforderung der Qualitätssicherung in vielen Projekten unter qualifikatorischen wie vor allem unter zeitlichen Aspekten bei. Viele Regelungen der Qualitätssicherung, die auf dem Papier überzeugend und einleuchtend aussahen, waren allein schon aus Zeitgründen unmöglich einzuhalten. Ihre Wirksamkeit war weniger ein Problem unzureichender Methoden als verfügbarer Zeit.

Die Qualitätsbeauftragten hatten durchweg zu wenig Zeit, um ihrer Aufgabe nur halbwegs gerecht zu werden. Den Softwareentwicklern fehlte die Zeit, die Vorschläge und Korrekturhinweise der Qualitätssicherer umzusetzen. Allein der Umfang der produzierten Dokumente ließ eine wirksame Qualitätssicherung unmöglich erscheinen. Der Qualitätsbeauftragte hinkte immer hinter dem Fortgang der Arbeiten her, eine Korrektur der durch ihn aufgewiesenen Qualitätsdefizite verbot der allgemeine Zeitdruck.

"Das Problem ist, die Gruppe produziert, und ich arbeite immer hinter der Gruppe her. Wenn ich einen Fehler gefunden habe, da sind die inzwischen schon wieder weiter, und das Ganze hängt dann in der Luft."

Nur in wenigen Projekten war Qualitätssicherung von der jeweiligen Projektsituation, den jeweiligen Gegebenheiten und Zwängen unabhängig. Qualitätssicherung wurde quasi aus dem "eigentlichen" Projektgeschehen ausgegliedert und damit sozusagen zur subsidiären Maßnahme.

Erleichtert wurde dieser Umgang mit "Qualität" dadurch, daß viele Qualitätsmängel erst in der Anwendung und da oft erst nach längerer Zeit erkennbar wurden. Unter Umständen waren diese auch vom Auftraggeber zunächst oder überhaupt nur schwer zu beurteilen, etwa Kriterien wie Lesbarkeit, Wartbarkeit oder auch Güte der Dokumentation. Gerade die Unbestimmtheit von Qualität, die Schwierigkeit, eindeutig meßbare Vorgaben zu definieren, die eigentlich die Notwendigkeit institutionalisierter Qualitätssicherung unterstreicht, erleichterte in der Praxis eine doppelte Moral im Umgang mit der Qualität. Grundsätzlich wurde eigentlich in allen Projekten der Qualitätssicherung höchstes Gewicht zugewiesen. Unter den- oft selbst geschaffenen- Sachzwängen der Projektabwicklung erwies sich diese Zuweisung meist als brüchig. Angesichts drohender Terminüberschreitung und Überziehung des Budgets ging es dann vorrangig nur noch darum, daß das System funktionierte; Qualitätssicherung mußte da notwendigerweise zurücktreten. Die Grundsätze der Qualitätssicherung wurden unter dem Druck der Verhältnisse meist sehr rasch recht abstrakt. Diese mangelnde Durchsetzungsfähigkeit und Verbindlichkeit der Qualitätssicherung war so Ausdruck bestehender Prioritäten: Letztlich stand die Einhaltung des finanziellen und terminlichen Rahmens im Vordergrund. Es zeigen sich hier gewisse Parallelen zur Planung des Personaleinsatzes: Einerseits werden formale Kriterien aufgestellt, andererseits sorgt man nicht dafür, daß diese auch in der Praxis wirklich zum Tragen kommen können.

In fast allen Projekten war man in der Retrospektive mit der Wahrnehmung und Wirksamkeit der Qualitätssicherung nicht so recht zufrieden. Besonders die Berichte der Qualitätsbeauftragten klangen überwiegend eher ernüchternd. Die Diskrepanz zwischen der Bedeutung ihrer Aufgabe und dessen, was sie tatsächlich realisieren konnten, war ihnen meist nur zu sehr bewußt.

"Ich habe alle zwei Wochen meinen Bericht an den Projektleiter geschrieben mit Hinweisen auf das, was ich gefunden habe, und das, was ich vorschlage. Meist kam da überhaupt keine Reaktion. Die hatten ja nicht mal die Zeit, meinen Bericht zu lesen ."

Konsequenzen wurden allerdings aus dieser Unzufriedenheit, soweit für uns erkennbar, nur in erstaunlich geringem Maß gezogen. Am ehesten setzte

man an den Methoden an, nicht aber an den Voraussetzungen ihrer effektiven Anwendung.

So lag in einem Unternehmen die Qualitätssicherung in einem Projekt in den Händen eines Qualitätsbeauftragten, dessen Tätigkeit aber nicht zuletzt wegen des allgemeinen Zeitdrucks weitgehend folgenlos geblieben war. Im Folgeprojekt wurde eine neue Lösung eingeführt: ein weitgehend formalisiertes Verfahren der Qualitätskontrolle durch die Gruppe selbst. Das eigentliche Kernproblem, die mangelnde Zeit, blieb dabei aber völlig ausgeklammert.

All dies verweist auf die Bedeutung der Rahmenbedingungen, unter denen Qualitätssicherung praktiziert werden mußte. Qualitätssicherung war keine isolierte oder isolierbare Maßnahme. Sie war untrennbar Teil des ganzen Projektgeschehens. Damit konnte Qualitätssicherung immer nur so gut oder so schlecht sein, wie es die Rahmenbedingungen erlauben. Insofern sagte auch die beste Regelung auf dem Papier zunächst wenig aus, wenn sie nicht im Kontext der gesamten Projektorganisation und Projektdurchführung gesehen wurde.

Hier schnitten Projekte, in denen nach dem Diskussionsansatz vorgegangen wurde, insgesamt besser ab. Mochte die Meßlatte "Qualität" auch bisweilen weniger hoch gelegt worden sein, die Diskrepanz zwischen Anspruch und Ausführung war meist geringer als beim Inspektionsansatz..

Erste Reviews am Ende der Konzeptphase

Kernstück der Qualitätssicherung eines Projekts in einem Softwarehaus war eine Serie von Reviews, in denen jeweils der "Autor", der Projektleiter, zwei weitere Mitglieder des Entwicklungsteams, unter Umständen auch der Projektmanager und ein "externer" Experte, der nicht dem Entwicklungsteam angehörte, teilnahmen. Erste Reviews fanden statt am Ende der Konzeptphase, in denen jeweils der Grobentwurf eines Teilsystems zur Diskussion gestellt wurde. Weitere Reviews gab es dann bei Vorlage der Feinentwürfe, nach Abschluß der Realisierung und der Tests.

Bei zweijährigem Projekt 60 Reviews

Obwohl es keine formale Regelung für die Durchführung dieser Reviews gab wurde das Verfahren, auf das sich der Projektleiter und das Projektteam zu Beginn des Projekts verständigt hatten, konsequent und mit beträchtlichem Zeitaufwand praktiziert. Insgesamt wurden im Lauf des etwa zweijährigen Projekts 60 solcher Reviews durchgeführt, die jeweils einen halben bis einen ganzen Tag dauerten.

Qualitätssicherung eng verquickt

Der Aufwand von über 200 Mannarbeitstagen - etwa 10 Prozent des gesamten Projektvolumens - war bei der Projektplanung einkalkuliert worden. Das Projekt wurde im vorgegebenen Termin- und Kostenrahmen abgewickelt. Projektleiter wie Entwickler betrachten die konsequente Durchführung der Reviews als wesentliche Voraussetzung dafür, daß das Projekt erfolgreich abgeschlossen werden konnte.

Beeindruckend an diesem Beispiel ist nicht nur die Konsequenz, mit der ein Verfahren praktiziert wurde, auf das man sich im Projekt verhältnismäßig informell verständigt hatte; beeindruckend ist auch, wie eng verquickt die Qualitätssicherung mit dem gesamten Geschehen im Projekt war; Qualitätssicherung war untrennbar Teil des Projektfortgangs und strahlte bereits Impulse auf das gesamte Projektgeschehen aus.

Befaßt man sich genauer mit diesem auf eine Serie von Reviews gestützten Prozeß, so wird erkennbar, daß dessen Wirksamkeit nicht zuletzt auf einer Reihe von Funktionen beruhte, die scheinbar nur indirekt etwas mit Qualitätssicherung zu tun hatten. Zu solchen sekundären Funktionen gehörte zunächst die Herstellung eines Konsenses im Projektteam darüber, was unter Qualität zu verstehen sei. Das Fehlen dieses Konsenses hierüber hatte in anderen Projekten dazu beigetragen, daß aufwendige Maßnahmen der Qualitätssicherung relativ wirkungslos blieben. Diese auf die Dimension der "Qualität" bezogene Konsensbildung trug auch allgemein zur Stärkung des Konsenses und letztlich auch der Kollegialität im Projektteam bei. Eng verwoben war damit ein Prozeß der kontinuierlichen Zielabstimmung im Team, der unkoordinierten Fehlentwicklungen von Teilsystemen entgegenwirkte. Verstärkt wurde auch der kontinuierliche Wissenstransfer über die Projektgrenzen hinaus und die Abstimmung mit anderen Entwicklungsaktivitäten, mit denen Schnittstellen bestanden.

Vor allem diese sekundären Funktionen, die "innengesteuerten" Verfahren der Qualitätssicherung, die am Diskussionsansatz ausgerichtet waren, machten sie effektiv. Umgekehrt waren mit diesem Vorgehen die Voraussetzungen geschaffen, daß diese sekundären Funktionen auch zum Tragen kommen konnten. Die Qualitätssicherung wurde zum Instrument der Konsensbildung im Arbeitsteam. Ihrerseits wurde sie getragen von diesem Konsens. Qualitätssicherung wirkte nicht als ein von außen vorgegebenes Prinzip, auf das hin das Projektgeschehen strukturiert werden mußte, sondern als integraler Teil des gesamten technischen und sozialen Entwicklungsprozesses. Sie wird damit zum Selbstläufer. Dabei besteht eine Wechselwirkung: Nur wo entsprechende Rahmenbedingungen erfüllt sind, kann Qualitätssicherung "funktionieren", und wo sie funktioniert, trägt sie zur Stabilisierung dieser Rahmenbedingungen bei. Es ist ganz offensichtlich die Tatsache, daß sie dieser Wechselwirkung nicht gerecht werden, an der so viele, methodisch durchaus ausgefeilte "außengesteuerte" Ansätze der Qualitätssicherung scheitern.

Realistische Steuerung und Planung des Ablaufs

Dies alles deutet darauf hin, daß die Möglichkeiten, durch ausgefeilte Methoden der Qualitätssicherung eine Verbesserung der Qualität von Software zu erreichen, relativ skeptisch zu beurteilen sind. Der wirksamste Weg zur Qualitätssicherung scheint eine realistische Steuerung und Planung des Projektablaufs zu sein. In einem solchen Projektrahmen werden dann die Maßnahmen zur Qualitätssicherung sowohl notwendig wie wirksam. Auf die bestehende Praxis bezogen heißt dies: Es kommt nicht so sehr darauf an, wie Qualitätssicherung geregelt ist, vielmehr darauf, welche Voraussetzungen geschaffen werden, daß diese zum tragen kommen können.

(wird fortgesetzt)