Die Praxis zeigt es immer wieder: Programmierer, Projektleiter und Koordinatoren fühlen sich durch den unvermeidbaren Kostendruck zu Eingeständnissen bei den Sicherungsmaßnahmen des Software-Qualitäts-Managements (SQM) genötigt. Nur zu oft folgt dann dem schlechten Gewissen die operative Katastrophe nach der Markteinführung. Trotz umfangreicher Literatur zum Thema SQM haftet stereotypen Lösungsansätzen wie V-Modell 97, Rational Unified Process (RUP) und Capability Maturity Model (CMM) der Geruch des Theoretischen an, was den Praktiker notwendigerweise abschreckt. Zu komplex und trotz aller Variabilität zu unflexibel sind viele Standardvorgehensweisen. Doch wie findet sich der Projektleiter im Dschungel der möglichen Verfahrensansätze zurecht? Sieben Erfolgsfaktoren sind es, die sich als Quintessenz
langjähriger Projekterfahrung herauskristallisiert haben.
Wissen Sie, was Sie wollen? „Wir haben genau das umgesetzt, was Sie beschrieben haben.“ - Diese Aussage von Programmierern steht stellvertretend für einen Kardinalfehler in der Softwareentwicklung. Die Anforderungen in Fachkonzepten sind häufig unverständlich, interpretationsfähig, irrelevant, unvollständig oder sogar falsch. Nicht umsonst gehören mangelhafte Anforderungen der Fachabteilungen zu den Hauptgründen für das Scheitern von IT-Projekten.
Anforderungen müssen klar definiert sein
Die sieben Erfolgsfaktoren des SQM
1.Wissen Sie, was Sie wollen?
2.Vermeiden Sie ein Fehlerdomino
3.Beachten Sie die Zuständigkeitsfalle
4.Setzen Sie Prioritäten
5.Kaufen Sie nur, was Sie wirklich brauchen
6.Messen Sie’s oder vergessen Sie’s
7.Holen Sie die Mitarbeiter mit ins Boot
Komplex heißt nicht kompliziert. Genau diese Erkenntnis muss die Fachabteilung gewinnen, wenn sie ihre Anforderungen an ein IT-System beschreibt. Dabei muss sie sich nicht nur Gedanken über die Relevanz, Verständlichkeit und Vollständigkeit der Anforderungen machen, sondern auch sicherstellen, dass sie testbar sind. Fast in jedem Fachkonzept sind Anforderungen wie „Antwortzeit des Systems soll gering sein“ enthalten. Doch was bedeutet das im Klartext? Wie sind „soll“ und „gering“ zu bewerten? Jeder Anwender beurteilt dies anders, weil ihm eine objektive Entscheidungsgrundlage fehlt. Es ist daher zwingend notwendig, die Anforderungen so zu beschreiben, dass beim Test eindeutig entschieden werden kann, ob der Testfall erfolgreich war oder nicht. Ist dies nicht möglich, muss auf die Anforderung verzichtet werden.
Abnahmekriterien steigern Qualität
„Die Erweiterung unserer Fachkonzepte um Abnahmekriterien hat die Qualität unserer Produkte erheblich gesteigert.“, bestätigt Walter Cornely, Abteilungsleiter Vertriebsinformation bei den Aachener und Münchener Versicherungen.
Achtung, Fehlerdomino! Als besonders kritisch sind mangelhafte Strategien zur Fehlerprävention zu bewerten: Ihr Katastrophenpotenzial wird oft genug unterschätzt. Eine laufende Prüfung auf Vollständigkeit, Widerspruchsfreiheit und Korrektheit findet im Projekt meist nur oberflächlich statt, da Termine häufig so eng gesetzt sind, dass für eine ausreichende Qualitätssicherung kaum Zeit bleibt. Doch diese vermeintliche Zeit- und somit Kostenersparnis ist in der Praxis trügerisch. Die Mizumo-Studie von 1983 mit dem Titel „Software Quality Improvement“ zeigte bereits eindrucksvoll, wie die Kosten zur Fehlerbehebung steigen, je später ein Fehler entdeckt wird. Statt Qualität am Ende „hineinzuprüfen“, sind präventive Maßnahmen erforderlich, die von Anfang an sicherstellen, dass Fehler frühzeitig entdeckt werden. Checklisten und Dokumentvorlagen sind mit wenig Aufwand erstellbar, aber
sehr wirkungsvoll im Ergebnis.
Vorsicht vor der Zuständigkeitsfalle „Ich dachte, ihr habt das getestet“, heißt es, wenn das Kind in den Brunnen gefallen ist. Die Einsicht, dass Produkte systematisch geprüft werden müssen, ist vielleicht bei den Beteiligten noch vorhanden. Mindestens genauso wichtig ist jedoch für den Testprozess eine klare Rollen- und Aufgabenverteilung.
Bei der Festlegung der Zuständigkeiten darf das Management nicht unberücksichtigt bleiben, nur weil die operative Produktprüfung im Fokus steht. Vom Management wird der Rahmen der Qualitätsmaßnahmen vorgegeben, der für die einzelnen Projekte verbindlich ist. Es überwacht und lenkt auch dessen Umsetzung. Um den Erfolg langfristig zu sichern, ist eine kontinuierliche „SQM-Werbung“ notwendig, in dem alle Einzelprojekte über den erreichten Qualitätsstand regelmäßig informiert werden. Nur wenn sich das Management eindeutig zum SQM positioniert, werden die Qualitätsmaßnahmen in der Praxis angewendet statt im Schrank zu verstauben.
Testpläne erleichtern Kontrolle
Prioritäten setzen: Heutige IT-Systeme sind so komplex, dass ein vollständiger Test unmöglich ist. „Time to Market“ steht daher im Widerspruch zu einem anspruchsvollen Testplan. Der Weg aus dem Dilemma kann nur sein, beim Test Prioritäten zu setzen, um Schäden durch Programmfehler in ausgelieferten Versionen möglichst gering zu halten. In der Praxis hat sich ein einfaches Verfahren bewährt: Zuerst wird das System in überschaubare Testobjekte aufgeteilt und anschließend priorisiert. Als Bewertungsparameter dienen dabei die Komplexität und das Risiko durch potenzielle Fehler. So hat die Komponente zur Tarifberechnung einer Lebensversicherung eine deutlich höhere Priorität (Stichwort: Beraterhaftung) als die Gestaltung der Benutzeroberfläche. Alle wichtigen Planungswerte - zum Beispiel Testbeginn und -ende, Bereitstellungstermine für Testdaten sowie benötigte Ressourcen - werden in einem
Testplan festgehalten, laufend kontrolliert und gegebenenfalls angepasst.
Kaufen Sie nur, was Sie wirklich brauchen: Die SQM-Qualitätsmaßnahmen müssen so ausgewählt werden, dass geforderte Qualität und Kosten im angemessenen Gleichgewicht bleiben. Einwände wie „Woher soll ich vorher wissen, welches die effektivsten Maßnahmen sind? Das ist mir alles zu theoretisch.“ hört man als SQM-Manager nur zu oft. Und in der Tat: Standardverfahren wie V-Modell 97, RUP oder CMM haftet der Geruch des Theoretischen an, da Unternehmen diese Modelle sehr aufwändig an ihre Organisation anpassen müssen und sich möglicherweise erst am Ende herausstellt, ob sie geeignet sind.
Soll man sich überhaupt an ein bestimmtes Standardmodell binden? Ja, aber nur, wenn es sich problemlos den äußeren Randbedingungen anpassen lässt und - im Gegensatz zu so mancher Kahlschlag-Philosophie bestehender Standardkonzepte - auch die schon bestehenden Sicherungsmaßnahmen berücksichtigt. Ein projektbegleitendes, möglichst firmenexternes Coaching kann die praktische Umsetzung unterstützen.
Messen Sie’s oder vergessen Sie’s: Die Entwicklung von Softwaresystemen wird, speziell wenn es sich um PC-Programme handelt, in vielen Unternehmen nicht als Ingenieursdisziplin verstanden („Software Engineering“): Ingenieure messen, ermitteln Kennzahlen und betreiben Statistik. Was in anderen Bereichen also durchaus üblich ist, stößt in der Welt der Softwarequalität an Grenzen. Wie soll man Qualität messen? Was sind objektive Kennzahlen? Oft steht gut gemeinten Ansätzen die Furcht vor allzu feinmaschiger Kontrolle entgegen und ruft den Betriebsrat auf den Plan. Um eine Kosten-Nutzen-Betrachtung der Qualitätsmaßnahmen wird man aber auf Dauer nicht herumkommen.
Wichtig für die Akzeptanz bei Management und Projektmitarbeitern ist die klare Definition, zu welchem Zweck welche Daten gesammelt und ausgewertet werden sollen. Leidvolle Erfahrungen mit kaum verwertbaren Zahlenfriedhöfen sind teures Lehrgeld für ein Unternehmen. Weniger, aber zielgerichtet Daten zu erheben und auszuwerten, ist logischerweise kosteneffektiver als nach dem „Nice-to-have“-Prinzip Datenmüll anzuhäufen.
Mitarbeiter mit ins Boot: Das afrikanische Sprichwort „Wer zusammen in das gleiche Boot steigt, will dasselbe“ bringt es auf den Punkt: Jedes Konzept bleibt Theorie, wenn es in der Praxis nicht die notwendige Unterstützung bei allen Beteiligten hat. Um eine positive Grundhaltung, vielleicht sogar Begeisterung zu erzeugen, sollten neue Qualitätsmaßnahmen idealerweise in einem repräsentativen Pilotprojekt eingesetzt werden, das nicht unter Zeitdruck steht. Zudem ist es hilfreich, die positiven Erfahrungen offen zu kommunizieren. Dabei kommt der personellen Besetzung des Pilotprojekts eine besondere Bedeutung zu. Nach Peter Stöckl („Einführung eines iterativen und inkrementellen Entwicklungsprozesses in Großunternehmen“ in Objektspektrum, März/April 2001) gibt es vier Kategorien von Mitarbeitern. Die relativ kleine Gruppe der „frühen Unterstützer“ sind zuerst von allem Neuen begeistert, weil es
neu ist. Leider sind sie aber in der Regel unkritisch, so dass ein konstruktives Feedback nicht zu erwarten ist. Die ebenfalls kleine Gruppe der „prinzipiellen Gegner“ lehnt alles Neue grundsätzlich ab und setzt sich gar nicht erst mit den Änderungen auseinander. Üblicherweise ist die Gruppe der „zurückhaltend Zustimmenden“ am größten. Sie ist Neuerungen gegenüber prinzipiell positiv eingestellt, bleibt aber kritisch. Die „zurückhaltend Ablehnenden“ gilt es zu überzeugen. Sie sind eher skeptisch, setzen sich aber mit Neuerungen auseinander.
Stille Verweigerung, eine mangelhafte Auseinandersetzung mit dem Thema oder gar offene Ablehnung gefährden jedes Projekt. Wichtig für den Erfolg eines Pilotprojekts ist es daher, keine prinzipiellen Gegner im Team und möglichst mehr zurückhaltend Zustimmende als Ablehnende zu haben. Ein erfolgreich abgeschlossenes Pilotprojekt ist der beste Beweis dafür, dass die Qualitätsmaßnahmen praxistauglich sind. Für Unternehmen, die diese sieben Erfolgsfaktoren konsequent beachten, wird Software-Qualitäts-Management mehr sein als die Summe der Einzelteile.