Qualitätsmanagement im Softwareprojekt

Walter Wintersteiger

Die Kunst des Qualitätsmanagements besteht weitestgehend darin, die Risiken zu erkennen, richtig einzuschätzen und dann erst die am besten geeigneten Maßnahmen aus dem reichhaltigen Repertoire der Qualitätsplanung und -lenkung in angemessenem Umfang einzusetzen.

Das Rad muss nicht immer wieder neu erfunden werden. Was brauchen wir und unsere Mitarbeiter, um fremde Erfahrungen, wie sie in Qualitätsmanagement-Handbüchern und ähnlichen Dokumenten manifestiert sind, annehmen zu können? Wo bleiben die Bemühungen bezüglich Wissenstransfer, Know-how-Pool, Learning Organization?

Ein Qualitätsmanagementsystem ist nicht nur ein Wissenspool, aus dem jeder schöpfen darf und schöpfen soll und in den jeder auch hineinfüllen darf und soll, es ist auch ein gelebter Satz von Regeln - ein Regelkreis: wer, wie, was zur gemeinsamen Reife beitragen kann und soll.

Aus diesem Grund macht es wenig Sinn, Qualitätsmanagement in einem einzelnen Projekt isoliert zu betrachten beziehungsweise zu betreiben. Außerdem wird sich der Aufbau einer Qualitätsmanagementsystems für ein Projekt kaum rentieren. Was aber ganz wichtig ist: Art und Umfang des Qualitätsmanagements in einem Projekt muss projektspezifisch evaluiert und festgelegt werden, und zwar dynamisch, d.h. dem wachsenden Wissensstand im Projekt entsprechend! Mit anderen Worten: in den Projektablauf integriert.

"Integrierte Querschnittsaufgabe"

Qualitätsmanagement sollte nach dem heutigen Erkenntnisstand sowohl in den Unternehmen als auch in Projekten als "integrierte Querschnittsaufgabe" gesehen beziehungsweise praktiziert werden. (Vgl.: Hans Dieter Seghezzi: Integriertes Qualitätsmanagement. Hanser Verlag 1996). Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung sind integrierte Bestandteile der Projektabwicklung, und es sind alle Projektmitglieder in angemessener Form beteiligt.

"Angemessen" - das heißt immer so, dass ein Projekt mit formalem Qualitätsmanagement besser abschneidet als eines ohne. Also: nicht zu viel und nicht zu wenig. "To do the things right - the first time".

Qualitätsmanagement muss rentabel sein

Qualitätsmanagement muss sich rentieren, im Unternehmen und in jedem einzelnen Projekt. Durch zufriedene Kunden dank konstanter Produkt-/Dienstleistungsqualität, Preis- und Termintreue, durch Senkung der Nonkonformitätskosten (weniger Fehler), durch höhere Effizienz dank besser organisierter Abläufe (höhere Transparenz, bessere Kommunikation, effektivere Mitarbeiterführung) und dank qualifizierter und motivierter Mitarbeiter und durch wachsendes Vertrauen aller Beteiligten.

Als Maßstab für die Bemessung des Umfanges der qualitätssichernden Aktivitäten können in einem (einmaligen) Projekt nicht die (bisherigen) Fehlerkosten herangezogen werden, vielmehr sind es die Risiken, die sorgfältig ermittelt und überwacht werden müssen.

Als potentielle Projektrisikofelder nennt Hedwig Kellner in ihrem Buch "Die Kunst, DV-Projekte zum Erfolg zu führen" (Carl Hanser Verlag 1994) namentlich:

• Fremde Ressourcen
• Politik
• Umwelteinflüsse
• Technische Probleme
• Personelle Engpässe
• Konflikte im Team
• Projektleiter
• Nachträgliche Änderungen
• Mangelhafte Planung
• Schätzfehler

Qualitätsbeauftragte

Es mag immer wieder Gründe geben für den Einsatz eigener Qualitätsbeauftragter im Projekt, wie zum Beispiel fehlendes Vertrauen der Kunden in die Projektleitung, unzureichendes Wissen des Projektleiters und der Projektmitarbeiter bezüglich Qualitätsmanagement, mangelnde Konsequenz in der Planung und vor allem in der Umsetzung der qualitätssichernden Maßnahmen. Aber das Ziel sollte sein und bleiben: Das Projektteam ist nicht nur verantwortlich für das WAS, sondern auch für das WIE.

Die Erfahrung aus vielen Projekten lehrt, dass es selten an Wissen fehlt, sondern an Disziplin. Die wichtigste Voraussetzung für ein integriertes Qualitätsmanagement scheint die Vereinbarung zu sein "Vereinbarungen wirklich einzuhalten".

Fazit

Ein Projekt ist immer ein äußerst spannendes, risikobeladenes Vorhaben. Deshalb sollte gerade in Projekten - mehr noch als im Tagesbetrieb - in Ergänzung zu einem bewussten Projektmanagement auch ein integriertes Qualitätsmanagement nach den Regeln der Kunst betrieben werden. Der Erfolg wird umso größer sein, je mehr Leute selbstverantwortlich Erkenntnisse darüber WIE ein optimaler Projektaufbau und -ablauf gesichert werden kann einbringen und "leben".

Walter Wintersteiger, Dkfm. Dr., MANAGEMENT & INFORMATIK, Dornbirn; Unternehmensberater; langjähriger Leiter Software-Entwicklung; Lehrbeauftragter an Universitäten und Fach(hoch)schulen; Präsident der Österreichischen Vereinigung für Software-Qualitätsmanagement; Auditor der SQS und ÖQS; Delegierter in der EOQ-Softwaregroup; Mitglied ITQualityGroup. www.walter-wintersteiger.com

---

Frageliste: Projekt-Audit

Um die bisherigen Ausführungen etwas zu illustrieren beziehungsweise um besser verstehen zu können, worauf es im Rahmen eines integrierten Qualitätsmanagements ankommt, wird nachfolgend eine Frageliste aus einem Projekt-Audit geboten, die ausgewählte Fragen zum Zustand und zu den Erfolgsaussichten eines bestimmten Projektes enthält.

• Worauf basiert die Erwartung, dass das Projekt erfolgreich realisiert wird (kritische Erfolgsfaktoren (CSF))?
• Sind die Faktoren, welche das Projekt gefährden identifiziert (Riskboard)?
• Ist geklärt, wie das Projekt-Risiko-Monitoring organisiert wird?
• Was bewegt die am Projekt unmittelbar Beteiligten, wenn sie an das Projekt denken?
• Woran können die Verantwortlichen jeweils erkennen, wie es um das Projekt steht? (Transparenz, Steuerungsgrößen im Rahmen des Projektcontrolling)?
• Gab es im Unternehmen ein vergleichbares Projekt, das erfolgreich realisiert wurde? Wenn ja, wurde der Erfahrungstransfer gesichert?
• Welche wichtigen Erkenntnisse wurden im Rahmen der bisherigen Projektarbeit gewonnen und wie werden sie für den weiteren Ablauf verwertet? (Zum Beispiel: Sind die bisherigen (Detail-)Projektpläne im einzelnen eingehalten worden?)
• Konnte nach Verbrauch von 5% des Projektbudgets festgestellt werden, ob der (gesamte) Lösungsansatz im Projekt zum Ziel führt?
• Sind die Anforderungen an das Produkt (bezüglich Installation, Betrieb und Wartung) und an das Projekt (Rahmenbedingungen, Ressourcen, Termin, Ablauf, Aufwand, Kosten) von allen Betroffenen ausreichend (verständlich, vollständig, korrekt) definiert und formell verabschiedet?
• Wurde eine ausreichende Marktanalyse durchgeführt (bezüglich Kunden und Mitbewerbern)?
• Gibt es einen Marketingplan?
• Gibt es eine detaillierte Machbarkeitsstudie für dieses Vorhaben, namentlich im Hinblick auf: Mitarbeiterqualifikation, Sachmittel (Entwicklungsumgebung, Zielumgebung), Methodik, Termin?
• Wie wurden Aufwand / Kosten ermittelt?
• Sind die Rollen der beteiligten Personen und Gremien ausreichend klar definiert, verstanden und akzeptiert?
• Gibt es nicht zu viele "Zuschauer" in der Projektorganisation?
• Ist eine ausreichende Beteiligung der Betroffenen (Kunden) im Projekt gesichert?
• Sind die Mitarbeiter ausreichend ausgebildet / qualifiziert / motiviert für das Projekt? (Zum Beispiel auch bezüglich Audits, Reviews, Tests?)
• Ist für eine ausreichende "Betreuung" der Mitarbeiter im Projekt gesorgt?
• Ist das gesamte Projekt "gut" strukturiert und woran lässt sich das erkennen bzw. nachweisen? (Sachlich, zeitlich, personell).
• Ist die Software-(System-)Entwicklungsumgebung ausreichend erprobt / beherrscht?
• Ist die System-Zielumgebung erprobt / beherrscht?
• Gibt es ein Projekthandbuch, in dem alle wesentlichen Informationen, die die am Projekt Beteiligten (namentlich später Hinzukommende) brauchen, zusammengefasst sind?
• Gibt es ein ergebnisorientiertes Vorgehensmodell für die Projektabwicklung und Software-(System-)Entwicklung? Ist es allen Mitarbeitern ausreichend bekannt und wird es akzeptiert / gelebt?
• Gibt es zumindest Ansätze für ein (künftiges) Software-(System-) Wartungskonzept bzw. einschlägige Anforderungen an die Wartbarkeit?
• Welche Anforderungen / Erwartungen haben die Auftraggeber an das projektinterne Qualitätsmanagement?
• Gibt es einen Konfigurationsmanagementplan im Projekt? (Inklusive Request-, Problem-, Change- und Release-Management)?
• Gibt es einen eigenen Konfigurationsmanager im Projekt?
• Gibt es ein funktionierendes Konfigurationsmanagementsystem?
• Sind die jeweiligen Projekt- / Systementwicklungsergebnisse ausreichend "typisiert", d.h. in Art und Umfang unmissverständlich vorgegeben / vereinbart?
• Gibt es einen umfassenden Kommunikationsplan bezüglich Berichtswesen (projektintern und -extern) und Informations- und Kommunikationswesen (WER, WAS, WIE, WANN ...)?
• Gibt es klare (schriftliche) Arbeitsaufträge für alle Arbeiten an alle Mitarbeiter sowie eine entsprechende Administration dazu?
• Ist allen am Projekt beteiligten (Auftraggeber und Auftragnehmer) klar, welche "Richtlinien" tatsächlich zur Anwendung kommen - und ist das o.k.?
• Sind die wichtigsten Begriffe im Projekt (einvernehmlich) geklärt und beschrieben?
• Gibt es einen Projektcontrolling-Plan wer, was, wie, wann ... im einzelnen plant, überprüft und entsprechende Konsequenzen daraus zieht?
• Werden Reviews geplant durchgeführt?
• Entsprechen die Testkonzepte den Richtlinien?
• Gibt es ein Freigabeprocedere / Abnahmeprocedere für Zwischenprodukte und Endprodukte.
• Gibt es einen Plan für die Erfassung und Auswertung der Qualitätsdaten im Projekt?
• Gibt es einen "kontinuierlichen Verbesserungsprozess" im Projekt?

---

STEV

Am 23. Mai 1984 wurde in Dornbirn der Verein SOFTWARETEST ÖSTERREICH (kurz: STEV) gegründet. Hauptziel war zunächst - in Anlehnung an einen gleichnamigen Verein in Deutschland - die Durchführung von Prüfungen von Software und die Vergabe von Prüfzertifikaten. Weil diese Aufgabe aber bald von einer eigenen Gesellschaft, der Gütegemeinschaft Software, wahrgenommen wurde, verlagerten sich die Ziele des STEV auf das Sammeln, Verwerten und Weitergeben von Wissen über Softwarequalitätssicherung bzw. -management in Österreich. Die jährlichen Fachtagungen und die Seminare waren lange Zeit die einzigen Treffpunkte der heimischen Softwarequalitätssicherungs-Szene. Näheres zum STEV findet sich auf www.softwarequalitaet.at