Abenteuer Softwarequalität
Prof. Dr. Kurt Schneider leitet das Fachgebiet Software Engineering an der Leibniz Universität Hannover. Er hat in Erlangen Informatik studiert und anschließend an der Universität Stuttgart promoviert. Bei einem Forschungsaufenthalt an der University of Colorado at Boulder beschäftigte er sich mit Techniken zum systematischen Lernen aus Erfahrung im Software Engineering. Er war sieben Jahre bei der DaimlerChrysler AG am Forschungszentrum Ulm tätig. In Projekten mit verschiedenen Unternehmensbereichen spielten Softwarequalität, Prozessgestaltung und wiederum die Erfahrungsnutzung eine wichtige Rolle. Zu seinen Forschungsthemen gehören daneben Softwareanforderungen und agile Methoden, um Informationsflüsse und die Dokumentation in Softwareprojekten zu optimieren. Kurt Schneider legt viel Wert darauf, diese Themen praxisnah zu bearbeiten und zu vermitteln.
Grundlagen und Verfahren für Qualitätssicherung
und Qualitätsmanagement
2., überarbeitete und erweiterte Auflage
Prof. Dr. Kurt Schneider
Kurt.Schneider@inf.uni-hannover.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Birgit Bäuerlein
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.deabrufbar.
ISBN:
Buch 978-3-89864-784-7
PDF 978-3-86491-108-8
ePub 978-3-86491-109-5
2., überarbeitete und erweiterte Auflage 2012
Copyright © 2012 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Barbara, Stefan und Angelika gewidmet
Die Informatik ist eine schnelle Disziplin: Was heute neu ist, kann morgen schon veraltet sein. Internetanwendungen, Smartphone-Apps und zahllose neue Techniken kommen und gehen in einem atemberaubenden Tempo.
Aber auch in der Informatik hat manches Bestand. Die Grundlagen der Softwarequalität gehören dazu. Als 2007 die erste Auflage dieses Buches erschien, wollte ich neben den Techniken zum Testen und Prüfen unbedingt auch vermitteln, wie es sich anfühlt, wenn man für die Qualitätssicherung zuständig ist. Um das ein bisschen lebendiger zu gestalten, habe ich die Figur »Q« eingeführt. Der Leser folgt Q durch verschiedene Situationen in einem Unternehmen. Dabei kommen die Randbedingungen, die Erwartungen und Befürchtungen zum Vorschein, die wesentlich mitentscheiden, was in der Praxis möglich und sinnvoll ist. Die Menschen ändern sich nicht so schnell.
In diesem Buch werden die Grundideen und wichtigsten Methoden der Softwarequalität vorgestellt. Mein Ziel ist immer, dass die Leser nicht nur verstehen, wie ein Ansatz funktioniert, sondern auch, wozu er dient und was man bei der Anwendung bedenken muss. Diese Art von Wissen hat eine »längere Halbwertszeit« als technische Spezifikationen oder Modethemen. An einer Universität sollen die Studierenden Prinzipien kennenlernen, die ihnen auch nach zehn Jahren noch nützlich sind. Dieses Buch ist aus einer universitären Vorlesung entstanden und soll für solche Themen ein solides Verständnis vermitteln.
In der zweiten Auflage hat sich einiges geändert und ist ergänzt oder aktualisiert worden. Neu ist ein Kapitel über die agilen Methoden. Wer sich ernsthaft für Softwarequalität interessiert, muss heute wissen, worum es dabei geht und welche Konsequenzen agile Methoden wie Extreme Programming, Scrum, Lean Software Development oder Kanban auf die Softwarequalität haben. Natürlich können nicht alle diese Methoden im Detail diskutiert werden; für jede einzelne gibt es dicke Bücher. Aber auch hier ist es mein Anliegen, auf wenigen Seiten eine vernünftige Orientierung zu geben.
Ich danke meinen Mitarbeitern am Lehrstuhl Software Engineering für spannende Diskussionen in vielen Softwareprojekten. Raphael Pham nimmt sich zurzeit mit besonderem Engagement der Übungen zur Vorlesung an. Freundlich und kompetent haben mich Heidi Heilmann und Christa Preisendanz vom dpunkt.verlag auch bei der zweiten Auflage unterstützt. Vielen Dank!
Kurt Schneider
Hannover, Februar 2012
Softwarequalität kann eine spannende Sache sein. Das sieht man aber nicht sofort.
Als Student habe ich noch nicht viel von Softwarequalität gehört. Natürlich, wir haben auch damals schon getestet. Aber in den Lehrbüchern hörte sich das alles doch eher bürokratisch und langweilig an. Eher etwas für große Firmen als für spannende Projekte.
Im Laufe der Zeit hatte ich dann an verschiedenen Stellen die Gelegenheit, Softwarequalität in der Praxis mitzuerleben. Da kam es plötzlich neben den Techniken und Verfahren auch auf ganz andere Dinge an – auf Einfühlungsvermögen und Durchsetzungsfähigkeit, auf Aufwand, Kosten und auf guten Überblick. Das war viel aufregender und herausfordernder.
Auch in meiner Vorlesung Software-Qualität bin ich zuerst streng »nach Lehrbuch« vorgegangen. Aber wieder hatte ich das Gefühl, dass da etwas fehlte, und zwar etwas ganz Wichtiges. Dann hatte ich eine Idee. Ich ließ eine fiktive Person immer wieder in der Vorlesung auftauchen. Durch diese Person konnte ich auch Zweifel und Hoffnungen ausdrücken, ohne sie zu sehr mit dem Lehrstoff zu durchmischen. Das hat den meisten Studierenden laut einer Evaluation gut gefallen.
Diesem Buch liegt die gleiche Idee zugrunde. Es behandelt die üblichen Themen, ergänzt sie aber um einige Aspekte, die den Zusammenhang herstellen und das Bild abrunden. Die fachliche Sicht wird ergänzt durch die fiktive Person – und ihre Abenteuer in der Softwarequalität. Das ist für ein Fachbuch vielleicht ungewöhnlich. Ich hoffe aber, dass der Stoff so leichter zu lesen und zu verstehen ist.
Ich möchte mich bei vielen bedanken, die direkt oder indirekt zu diesem Buch beigetragen haben. Das beginnt bei meinen Kollegen an der Universität Stuttgart, Horst Lichter, Marcus Deininger, Jürgen Schwille und Anke Drappa. Mein Doktorvater Jochen Ludewig hat mir viel beigebracht; seine prägnanten Bücher haben mir imponiert, und viele Grundüberzeugungen habe ich von ihm. Marcus Deininger verdanke ich besonders spannende Diskussionen um die »Softwarequanten«, mit denen wir Softwareprojekte und Softwarequalität simuliert haben.
Bei Gerhard Fischer an der University of Colorado at Boulder wurde mir zum ersten Mal das Spannungsverhältnis zwischen Nützlichkeit und Bedienbarkeit von Software bewusst. In Boulder habe ich auch gesehen, wie kreativ man damit umgehen kann.
Auch meinen Kollegen bei DaimlerChrysler möchte ich herzlich danken – es sind zu viele, um sie hier alle zu nennen. Michael Offergeld hat meine Sicht auf Usability geprägt und weiterentwickelt, die ich von Boulder mitgebracht hatte. Viele Beobachtungen verdanke ich der gemeinsamen Arbeit mit Thilo Schwinn, dem Experten für Reviews. In unseren Arbeiten zu erfahrungsbasierter Prozessverbesserung waren viele Kollegen beteiligt, darunter Frank Sazama, Stefanie Lindstaedt und Frank Houdek. Frank Houdek ist jetzt seit langem der ausgewiesene Experte für Anforderungen bei DaimlerChrysler. Die Projekte mit Dieter Rombach und Vic Basili waren eine große Bereicherung für mich und haben meine Erfahrung in der Softwarequalität geprägt. Thomas Gantner war ein Vorbild als ein Projektleiter, dem die Qualität ein echtes Anliegen ist.
An der Leibniz Universität Hannover haben Thomas Flohr, Daniel Lübke und Eric Knauss regen Anteil daran, dass sich meine Vorlesung zur Softwarequalität weiterentwickelt. Etliche Anregungen dazu verdanke ich Martin Glinz von der Universität Zürich. Dieses Buch ist der Versuch, die vielen Einflüsse der letzten Jahre zu sortieren und eine Auswahl davon mit einer durchgängigen Geschichte zu verbinden. Das hat Spaß gemacht.
Ich danke dem dpunkt.verlag für die Betreuung und Heidi Heilmann für die engagierte fachliche Durchsicht; Christa Preisendanz hat sich besonders für das Buch eingesetzt.
Vielen Dank für die inspirierenden Gespräche und die Zusammenarbeit!
Kurt Schneider
Hannover, April 2007
1 Einleitung
1.1 Softwarequalität betrifft viele
1.2 Für wen dieses Buch gemacht ist
1.3 Was Sie von diesem Buch erwarten können
1.4 Das Abenteuer von Q
1.5 Themen und Anspruch
1.5.1 Themenauswahl und Gewichtung
1.5.2 Die Reihenfolge der Themen
1.6 Bedeutung von Softwarequalität
1.7 Wie Q zur Softwarequalität kam
2 Grundkonzepte
2.1 Qualitätsorganisation und Terminologie
2.2 Kosten und Nutzen von Softwarequalität
2.3 Qualitätsbeauftragte
2.4 Eine Vision: Total Quality Management
2.5 Grundbegriffe des Testens
2.6 Normen und Standards
2.7 Qualitätsaspekte, -anforderungen und Qualitätsmodelle
3 Erfahrungen systematisch nutzen
3.1 Qualitätsnetzwerke und Qualitätszirkel
3.2 Leichtgewichtige Dokumentation von Erfahrungen
3.3 Organisation der Erfahrungsverwaltung
3.4 Herausforderungen und Chancen für Erfahrungsnutzung
3.5 Networking in Organisationen und auf Tagungen
4 Messen von Softwarequalität
4.1 Wozu messen und konkretisieren?
4.2 Softwaremetriken
4.2.1 Grundlagen
4.2.2 Was Softwaremetriken messen
4.2.3 Bezug zwischen Metrik und Qualitätsaspekt
4.2.4 Skalen für die Resultate der Metriken
4.3 Diskussion bekannter Softwaremetriken
4.3.1 Lines of code: Der Teufel steckt im Detail
4.3.2 Zyklomatische Komplexität von McCabe
4.3.3 Halstead Software Science
4.3.4 Weitere Metriken: ein Ausblick
4.4 Metriken nach Maß: GQM
4.4.1 Von Zielen zu Fragen zu Metriken – und zurück
4.4.2 Zielorientiertes Messen und Bewerten
4.4.3 Zielfacetten schärfen den Blick
4.4.4 Messung vorbereiten mit Abstraction Sheets
4.4.5 Besonderheiten bei Messung und Auswertung
4.5 Projektfortschritt messen mit Quality Gates
5 Systematisches Testen
5.1 Vorüberlegungen
5.1.1 Testvorbereitung
5.1.2 Vollständig testen?
5.1.3 Woraus ein Testfall besteht
5.1.4 Testfälle dokumentieren
5.1.5 Testfälle ermitteln: eine Strategie
5.1.6 Hintergrund von Fehlern
5.1.7 Übersicht: Black-Box-Test und Glass-Box-Test
5.2 Black-Box-Tests aus der Spezifikation
5.2.1 Minimalforderung und Effizienzprinzip
5.2.2 Äquivalenzklassenmethode
5.2.3 Grenzwertanalyse
5.2.4 Spezifikationsabdeckung optimieren
5.2.5 Klassifikationsbaummethode
5.2.6 Zustandsbasiertes Testen
5.2.7 Testablauf dokumentieren
5.3 Sollwerte aus der Spezifikation
5.4 Glass-Box: Testen nach der Codestruktur
5.4.1 Maße für Codeüberdeckung
5.4.2 Interpretation von Überdeckungsmaßen
5.4.3 Objektorientierung und Glass-Box-Test
5.5 Testfälle für spezielle Qualitätsaspekte
5.5.1 Testfälle in Form von Code
5.5.2 Granularität und Reihenfolge von Prüflingen
5.5.3 Stresstest, Recovery und Security Tests
5.6 Hilfsmittel und Werkzeuge für das Testen
5.6.1 Debuggen ist nicht Testen
5.6.2 Standardhilfsmittel: Testrahmen
5.6.3 Werkzeuge für Glass-Box-Test
5.6.4 Sonstige Hilfsmittel und Werkzeuge
5.7 Testen von grafischen Oberflächen
5.7.1 Sackgasse: System als Ganzes
5.7.2 Capture/Replay-Tools
6 Usability Engineering
6.1 Software und Bedienbarkeit
6.2 Usability als Qualitätsaspekt
6.2.1 Gute Bedienoberflächen und Qualitätsaspekte
6.2.2 Usability definiert sich über Anforderungen
6.3 Aspekte der Benutzerfreundlichkeit nach ISO 9241
6.4 Bedienbarkeit messen
6.5 Konstruktives Usability Engineering
6.5.1 Aufgaben im Usability Engineering
6.5.2 Kernaufgaben in der Anforderungsklärung
6.5.3 Aktivitäten in Entwurf und Entwicklung
6.5.4 Acht Goldene Regeln nach Shneiderman
6.6 Experten-Evaluationen
7 Reviews und Inspektionen
7.1 Rollen und Ablauf
7.2 Hilfsmittel
7.3 Aufwand und Nutzen
7.4 Varianten von Reviews
8 Formale Verfahren
8.1 Prädikatenkalkül und formale Beweise
8.1.1 Grundvorgehen und Basiselemente
8.1.2 Voraussetzungen aus Anforderung ableiten
8.1.3 Verzweigung als Anweisungsart
8.1.4 Schleifeninvarianten
8.2 Verschiedene Spezifikationsstile
8.3 Spezifizieren und Beweisen mit Modellen
8.3.1 Ampelanlage als Petrinetz-Beispiel
8.3.2 Beweise auf Petrinetzen
8.4 Diskussion formaler Techniken
9 Konstruktive Qualitätssicherung
9.1 Analytisch, organisatorisch, konstruktiv
9.2 Maßnahmen, bevor ein Problem auftritt
9.2.1 Bewährte Verfahren
9.2.2 Bewährte Bestandteile
9.2.3 Bewährte Strukturen
9.3 Beispiel Cleanroom: Fehler vermeiden
10 Agile Softwareentwicklung und Qualität
10.1 Die kurze Geschichte der agilen Softwareentwicklung
10.2 Extreme Programming im Überblick
10.3 Testgetriebene Entwicklung in XP
10.3.1 Terminologie und Testarten
10.3.2 Testautomatisierung ist unverzichtbar
10.3.3 Testcode ist seltener fehlerhaft
10.3.4 Test First: Testen vor Codieren
10.3.5 Auswirkungen von Test First
10.3.6 Besserer Produktionscode durch Test First
10.4 Die Rolle der Softwarequalität in XP
10.5 Scrum
10.6 Lean Software Development
10.6.1 Vom Toyota Production System zur Softwareentwicklung
10.6.2 Die Grundkonzepte von Lean
10.6.3 Auswirkungen auf die Softwarequalität
10.7 Kanban
10.7.1 Arbeitsabläufe visualisieren
10.7.2 Pull statt Push: Aufgabenvolumen begrenzen, Durchlaufzeit verkürzen
10.7.3 Ausblick: Kanban für Fortgeschrittene
10.8 Zusammenfassung
11 Das Abenteuer geht weiter
11.1 Rückblick
11.2 Was es noch zu erkunden gibt
11.3 Wann man aufhören soll
Literaturverzeichnis
Abkürzungen
Index
Softwarequalität ist ein Thema, das heute jeden direkt oder indirekt betrifft.
Fast jeder geht privat oder im Beruf ständig mit Programmen und softwaregesteuerten Geräten um: Handys und Autos, Internet oder Waschmaschine. Wir verlassen uns darauf, dass die Programme funktionieren – und zwar so, wie wir es erwarten. Aber dies ist leider nicht immer der Fall.
Nicht nur Fachzeitschriften, sondern auch normale Tageszeitungen berichten immer wieder von großen Softwarepannen. Durch fehlerhaft oder schlecht bedienbare Software geht viel Zeit verloren; Fehlbuchungen kosten Geld und Nerven. Viele Unternehmen verbinden mit Softwarequalität zunächst vor allem Kosten. Sie denken an unzufriedene Kunden oder Rückrufaktionen.
Natürlich gibt es auch Programme von guter Qualität, die nicht abstürzen und die leicht bedienbar sind. Sie sind von Fachleuten entwickelt, denen Qualität ein Anliegen ist. Softwarequalität geht nicht nur Informatiker oder Studierende etwas an: Auch Projektleiter, Manager und sogar Auftraggeber brauchen heute solide Grundkenntnisse, um ihren Anteil zu einer guten Softwarequalität beizutragen.
Was bedeutet aber »gute Qualität« überhaupt? Software und ihre Qualität sind nicht greifbar und daher auch schwer zu messen. Umso wichtiger ist es, dabei systematisch vorzugehen.
Natürlich müssen sich Qualitätsbeauftragte, Entwickler und Projektleiter von Softwareprojekten mit Softwarequalität beschäftigen. Nicht jeder und jede von ihnen muss alle Details kennen, aber einen breiten Überblick und ein gutes Verständnis für die wichtigsten Zusammenhänge kann man erwarten. Dieses Buch soll genau dieses Verständnis fördern.
Damit lässt sich auch gut altes Wissen auffrischen. Wer also schon vieles weiß, der wird sich mit diesem Buch schnell an einiges erinnern, das fast vergessen war. Denn das Buch enthält auch viele konkrete Begriffsklärungen, Beispiele und Tipps. Man kann sich gezielt ein Thema vornehmen und erfährt, wie die Verfahren funktionieren, was also dahintersteckt. Wer zu einem speziellen Thema noch mehr wissen will, wird in der angegebenen Spezialliteratur fündig werden.
Studierende der Informatik und angrenzender Gebiete finden hier Orientierung: Sie können sich mit den Grundideen zum Testen, Messen und von Reviews vertraut machen und sehen Zusammenhänge zu aktuellen Themen wie Bedienbarkeit oder agilen Methoden. Manche Themen sind aus der Praxis motiviert: Quality Gates sind ein Beispiel, das überall verbreitet ist, aber in der Lehre noch selten vorkommt.
Das Buch ist absichtlich schlank und lesbar gehalten, damit man es auch fast wie einen Roman lesen kann. Es ist durchzogen von einer durchgängigen Geschichte: dem Abenteuer von Q in der Softwarequalität. So bekommt man nebenbei einiges darüber mit, was im Kopf von Qualitätsbeauftragten vorgeht. Das können alle brauchen, die einmal in Projekten arbeiten werden. Egal, ob sie mit Qualitätsbeauftragten zusammenarbeiten – oder selbst einer werden wollen.
Viele Manager und Auftraggeber von Softwareprojekten haben erkannt, dass sie sich selbst einen Gefallen tun, wenn sie sich ein Grundverständnis für die eingesetzten Verfahren, für die Stärken und Schwächen, und auch für den Aufwand von Qualitätsmaßnahmen aneignen. Für diesen Zweck kann man einige Abschnitte überspringen, wird aber vom Überblick und dem Zusammenhang profitieren.
Und wenn Sie zu keiner dieser Gruppen gehören, sich aber einfach schon lange für Softwarequalität interessieren? Dann ist das Buch natürlich auch für Sie gemacht.
In diesem Buch geht es darum, allen Interessierten einen fundierten Überblick über das Thema Softwarequalität zu geben. Es gibt dicke Bücher über Software Engineering, in denen auch Softwarequalität eine gewisse Rolle spielt. Diese Einführung konzentriert sich dagegen ganz auf Softwarequalität. Die bekanntesten Begriffe werden geklärt und die wichtigsten Verfahren erläutert. Damit soll der Einstieg in das Thema gelingen.
Jeder, der programmieren kann, hat schon einmal etwas vom Testen gehört. Aber systematisches Testen ist für viele Studierende und Praktiker graue Theorie geblieben. In diesem Buch geht es darum – beim Testen wie bei den anderen Themen –, kurz und verständlich herauszuarbeiten, worauf man achten muss, damit am Ende Software der gewünschten Qualität herauskommt. Auch wenn man nicht das letzte Detail jedes Verfahrens durchdringt, soll man sich nach der Lektüre doch ein gutes Urteil bilden können. Und das ist das Wichtigste.
Softwarequalität ist ein technisches Thema, aber nicht nur ein technisches: Psychologie und Einfühlungsvermögen sind für die Softwarequalität nicht nur wichtig, sondern unentbehrlich. Projekte stehen heute meist unter hohem wirtschaftlichem Druck und sind ständig in Eile. Man muss daher Aufwand und Nutzen von Verfahren einschätzen können, um realistische Qualitätssicherungsmaßnahmen zu planen und erfolgreich durchzuführen. Der ständige Druck wirkt sich auf die Arbeitsweise im Projekt aus und auf die Gefühlslage der Beteiligten – ein wichtiger Aspekt für erfolgreiche Projekte. Wie vermittelt man das in einem Buch?
Ich versuche es mit einer fiktiven Person, Herrn oder Frau »Q«. Neben den Sachinformationen wird in diesem Buch die Geschichte von Q erzählt: das alltägliche Abenteuer, als Qualitätsbeauftragter in einer Softwarefirma zu arbeiten. Diese Geschichte soll die Gefühlsperspektive betonen, Fragen und Bedenken aufgreifen, die auch manchen Leser beschäftigen werden. Herr oder Frau Q hat Informatik studiert und bewirbt sich auf eine Stelle in der Softwarequalität. Indem wir Q durch die fiktive Firma FunGate folgen, lassen sich Zweifel und Hoffnungen besser nachvollziehen, die man in einem traditionellen Lehrbuch unter den Teppich kehren würde, um sich »auf die Sache zu konzentrieren«. Sie gehören aber »zur Sache«! Zweifel und Hoffnungen sind in der Softwarequalität wichtige Voraussetzungen für eine pragmatische Einschätzung.
Die Geschichte von Q ist kursiv gesetzt und hebt sich vom restlichen Text ab; man kann sie also auch leicht überblättern, wenn man möchte. Q soll einen roten Faden durch die Themen der Softwarequalität ziehen und damit ein wenig »Erfahrungsqualität« vermitteln.
Wie wir sehen werden, ist Erfahrung ein Schlüsselbegriff in der Softwarequalität.
Softwarequalität ist ein weites Feld. Wenn man die ökonomischen und menschlichen Seiten des Gebiets mit einschließt, umso mehr. Daher muss man für eine kompakte Übersicht Themen auswählen und andere weglassen. Die hier vorgestellten Themen gehören zum Grundwissen für alle Projektbeteiligten, auch für Kunden von Softwareprojekten.
Damit ist das Thema Softwarequalität nicht erschöpfend behandelt, aber auf eine vernünftige Grundlage gestellt. Je nach Interessenlage kann man sich in verschiedene Richtungen vertiefen.
Welches Niveau von Kenntnissen soll das vorliegende Buch vermitteln? Zumindest muss man die einschlägigen Begriffe »kennen«, sie einordnen können und verstehen, wenn jemand anders sie gebraucht. Das ist die erste Stufe. Sie soll für alle vorgestellten Themen erreicht werden.
In manchen Fällen sollte man zusätzlich in der Lage sein, etwas selbstständig »anzuwenden«, also in einem einfachen Fall durchzuführen. Für diese Stufe sind ausführlichere Informationen nötig, damit der Leser das Verfahren ausprobieren kann. Manche Techniken, wie das Testen, sollte man im Projekt sogar regelrecht »beherrschen«, also auch unter etwas ungewöhnlichen Umständen sicher einsetzen können. Entsprechend werden diese Themen besonders intensiv behandelt.
Um eine Technik zu beherrschen, muss man sie mehrfach selbst anwenden. Hier sind die Grenzen einer Einführung erreicht; dieses Buch soll eine Ermunterung an den Leser sein, die Verfahren auch einzusetzen. Für manche Themen gibt es typischerweise mehr Bedarf als für andere.
Tabelle 1–1 zeigt, von welchem Bedarf man bei normalen Projekten ausgehen kann. Dabei ist natürlich jedes Projekt etwas anders gelagert, die Tabelle kann nur einen ersten Überblick geben. Wer in seinem Projekt beispielsweise modellbasiert arbeitet, wird sich natürlich auf diesem Gebiet vertiefen müssen, während das in anderen Projekten unnötig ist. Aber jeder Projektteilnehmer, ob Entwickler, Projektleiter oder Qualitätsbeauftragter, sollte mit den Themen aus Tabelle 1–1 einigermaßen vertraut sein. Idealerweise gilt das auch für Manager und qualitätsbewusste Kunden von Softwareprojekten.
Die Auswahl und Gewichtung der Themen orientiert sich an deren praktischer Bedeutung, also an Tabelle 1–1. Auch für Themen, die man nicht ständig braucht, wird ein Überblick geboten, damit man die Grundlagen kennt und sie bei Bedarf einordnen kann. Bei Themen, die in Projekten häufiger verlangt werden, ist auch die Darstellung detaillierter.
Sicher wäre es ideal, alle Themen zu beherrschen. Aber der Weg dorthin ist oft weit und steinig. Nach vielen Jahren ist er mit guten und schlechten Erfahrungen gepflastert. Anfangs darf es auch etwas weniger sein: Auf Spezialgebieten wie dem Usability Engineering ist schon viel erreicht, wenn man sich so weit auskennt, dass man mit Spezialisten vernünftig zusammenarbeiten kann.
Darum geht es hier. Dieses Buch soll einen guten Start geben und Orientierungshilfe für diesen Weg liefern.
Tab. 1–1 Wie gut man die Themen für den Projektalltag kennen sollte
Die Qualitätssicherung wird oft systematisch in drei Bereiche eingeteilt: analytische, konstruktive und organisatorische Maßnahmen. Analytische Maßnahmen suchen Fehler, damit man sie beheben kann. Konstruktive versuchen schon bei der Entwicklung, Probleme gar nicht erst entstehen zu lassen. Und organisatorische Maßnahmen bilden den Rahmen um die ersten beiden: Sie schaffen die Voraussetzungen, damit diese wirken können.
Diese Einteilung taucht natürlich auch in diesem Buch auf, die Themen sind aber nach einem anderen Kriterium angeordnet: Wer die Kapitel der Reihe nach liest, wird von ihnen nach und nach an die Softwarequalität herangeführt. Nicht Techniken und Werkzeuge sollen den ersten Eindruck bestimmen, sondern der Zusammenhang, die menschliche Komponente – und was Projektbeteiligte zuerst einmal bewegt: Bin ich hier überhaupt richtig?
Auf das Testen werfen wir zuerst nur einen kurzen Blick. Die Herangehensweisen strahlen auch in andere Bereiche der Softwarequalität aus, aber die Details des Testens müssen noch etwas warten. Am Schluss kommen dann speziellere Themen zu ihrem Recht: Usability oder Bedienbarkeit und agile Methoden, immer in Bezug auf Softwarequalität.
Wer aber nicht der Reihe nach lesen will oder wer schnell etwas sucht, kann direkt in die jeweiligen Kapitel einsteigen.
An Softwarequalität denkt man im normalen Leben eigentlich nur, wenn etwas damit nicht stimmt:
Man hat eine Onlineüberweisung abgeschickt, da bleibt das Programm plötzlich stecken und reagiert nicht mehr. Ist das Geld jetzt überwiesen? Wenn nicht, steht eine Mahnung ins Haus. Also lieber einfach noch einmal überweisen. Aber halt! Wenn die Überweisung doch schon erfasst wurde, würde das zu einer Doppelüberweisung führen – mit überzogenem Konto beim Absender und viel Arbeit, bis man alles rückgängig gemacht hat.
Es kann natürlich immer einmal Verbindungsprobleme geben, wie in diesem Beispiel. Aber es hat mit Softwarequalität zu tun, wie aufwendig es ist festzustellen, ob die Überweisung gerade noch getätigt wurde oder gerade nicht mehr. Definitiv ein Qualitätsproblem liegt vor, wenn das Geld zwar beim Absender abgebucht, aber nicht beim Adressaten gutgeschrieben wurde (unvollständige Transaktion). Wenn eines dieser Probleme mit einer größeren Summe passiert, kann der Ärger entsprechend groß werden. Dann wechselt ein Kunde schon einmal die Bank.
Noch ein Beispiel: Im Internet können auch scheinbar kleine Ungewöhnlichkeiten zu Verlusten führen: Beispielsweise gibt es Onlineshops, die keinen Einkaufswagen anbieten oder nicht wie gewohnt damit umgehen. In einem bestimmten Online-Bekleidungsgeschäft sucht man beispielsweise vergeblich nach einem Einkaufswagen. Mancher Kunde und manche Kundin geben nach einigem Suchen entnervt auf und kaufen eben anderswo ein. Dabei heißt dieser Mechanismus hier einfach nicht Einkaufswagen, sondern »Tasche«. Nun kann man sich streiten, ob man in einem realen Bekleidungsgeschäft eher mit einem Einkaufswagen oder einer Tasche einkauft. Wenn der Laden wegen einer schöneren Formulierung aber Kunden verliert, ist der Streit rasch entschieden. Außerdem würde man ja im Laden hoffentlich auch nicht alles in seine Tasche stecken, solange man noch nicht bezahlt hat. Eine scheinbare Kleinigkeit, die also mehr Verwirrung als Freude stiftet.
Diese Fälle sind real und vor kurzem passiert. Nicht jeder würde sie spontan auf schlechte Softwarequalität zurückführen, aber diese steckt auch dahinter, wenn hier und in tausenden von ähnlichen Fällen Kunden abwandern, Vertrauen verspielt wird und Geld verloren geht. Jeder kennt ähnliche Fälle.
Natürlich liest man in der Zeitung auch von den spektakulären Pannen und Katastrophen: das Computersystem einer Bank, das abstürzt und einen Tag lang nicht verfügbar ist. Noch ein oder zwei Tage länger, und die Bank wäre Bankrott gegangen. Die Handyfirma, die hunderte von Millionen Euro Verlust macht, weil der Warnton einer Baureihe unter gewissen Umständen so laut ertönt, dass er das Gehör schädigen kann – ein Softwareproblem. In einem anderen Fall werden Krebspatienten falsch bestrahlt, weil ein Gerät einen Softwarefehler hat. Auch das System rund um die Gesundheitskarte muss zeigen, dass die Daten darauf sicher gespeichert sind und nicht von Unbefugten angezapft werden können. Diese Liste ließe sich endlos verlängern; überall sind finanzielle und manchmal gar gesundheitliche Schäden die Folge.
Man sollte dabei aber nicht vergessen, dass auch die positive Liste eindrucksvoll und es durchaus möglich ist, mit guter Softwarequalität Kunden zu binden und sogar anzulocken. Niemand würde Bücher bei Internethändlern kaufen, wenn ständig Bestellungen verloren gingen oder verfälscht würden – oder auch nur, wenn die entsprechenden Websites nicht so einfach zu bedienen wären. Das ist nicht zufällig so gekommen, sondern es wurde mit intensivem Ringen um gute Bedienbarkeit, Zuverlässigkeit und Korrektheit erreicht. Ein Triumph der Softwarequalität, wenn auch im Stillen.
Wer sich heute in ein modernes Auto der Oberklasse setzt, bemerkt gar nicht, wie viel Software ihn umgibt. Vom Navigationssystem ganz abgesehen, basieren auch Bremse und Motorsteuerung, dynamische Servolenkung und Airbag, Stabilitätspaket und Klimaanlage auf Software. Sie funktioniert zuverlässig, sicher und unauffällig in Millionen von Fahrzeugen. Eine einzige Panne mit dem Bremsassistenten hätte so gravierende Folgen, dass Softwarequalität ernst genommen werden muss. Zur Freude der Fahrer.
Auch diese Liste ist lang; nur muss man etwas nachdenken, bevor man im eigenen Umfeld Beispiele findet, in denen gute Softwarequalität großen Nutzen gestiftet hat. Man hält es wohl auch bei so komplexen Systemen für »selbstverständlich«, dass sie »normal funktionieren«.
Nichts könnte aber weniger selbstverständlich sein. Softwarequalität ist ein herausforderndes und deswegen auch spannendes Gebiet. Die Auswirkungen auf Wirtschaft, Gesundheit und privates Wohlergehen kann man kaum überschätzen. Grund genug, sein Bestes zu geben.
Q hat Informatik studiert und ist vor kurzem fertig geworden. Wie schon oft ist Q am Frühstückstisch in den Stellenteil der Zeitung vertieft. Bisher waren nicht so viele interessante Sachen dabei. Eine Bewerbung hat Q auch schon geschrieben, aber eher halbherzig. Ganz so eilig ist es nicht mit der ersten richtigen Stelle, schließlich hat Q noch einen Programmierjob, der seit vier Semestern für ein wenig finanziellen Spielraum sorgt. Aber eine richtige Dauerstelle ist das nicht. Eine Stellenanzeige spricht Q an, weil sie nach einer anspruchsvollen Tätigkeit klingt, in der man nicht ständig nur programmieren muss:
Abb. 1–1 Fiktive, aber typische Stellenanzeige für Qualitätsbeauftragte
Im Studium hat Q diverse Vorlesungen über Software Engineering gehört. Auch das Thema Softwarequalität findet Q interessant; in einem studentischen Projekt war Q für die Qualitätssicherung zuständig und weiß daher, wie schwierig das ist. Außerdem klingt es vielversprechend, gleich mit dem Projektleiter auf Augenhöhe verhandeln zu können – und notfalls sogar noch jemanden in der Bereichsleitung zu kennen. Vor allem glaubt Q, über ziemlich gute soziale Fähigkeiten zu verfügen; nicht erst seit dem Softwareprojekt im vorletzten Semester.
Die Anzeige aus Abbildung 1–1 ist genauso fiktiv wie die Firma FunGate, aber die Anforderungen an Qualitätsbeauftragte stammen aus realen Unternehmen. Der Anzeigentext verrät schon einiges über die Erwartungen und Grundkonzepte, die in der Firma herrschen. Nicht überraschend ist wohl, dass ein Informatik-Hintergrund sehr wichtig ist. Eher verblüffend könnte dagegen sein, dass darüber hinaus von Fingerspitzengefühl die Rede ist, also von »soft skills«. Die geforderten »weichen Fähigkeiten« zu haben ist hier eine harte Anforderung! Wer sie nicht mitbringt, wird große Schwierigkeiten haben – und sollte daher die Stelle nicht bekommen. Bewerber sollten die Formulierung in Stellenanzeigen unbedingt sehr ernst nehmen, denn das Wenige, das dort steht, ist meist sehr gut überlegt.
Offenbar ist FunGate keine ganz kleine Firma. Eine sehr kleine Firma hätte kaum explizit einen Qualitätsbeauftragten gesucht; dort wird diese Aufgabe meistens nebenher von Entwicklern übernommen. Q erinnert sich an die Anmeldung bei einem Telefonanbieter. Man musste ein langes Formular auf dem Bildschirm ausfüllen. Links konnte man sehen, welche Schritte noch bevorstanden. Insgesamt waren es 17 Schritte. Im vorletzten Schritt, vor der endgültigen Zustimmung zum Anbieterwechsel, wollte Q noch einmal schnell seine Antwort von Schritt 2 nachsehen und klickte auf diesen Schritt. Wie erwartet wurden die dortigen Angaben angezeigt. Leider konnte Q dann aber nicht mehr zu Schritt 16 zurückspringen und musste alles noch einmal eingeben. So etwas müsste man doch anständiger hinbekommen, denkt Q. Das wäre schon eine lohnende Herausforderung für überzeugte Qualitätsleute, da könnte man etwas für die Kunden bewirken!
In jeder Disziplin gibt es einen Grundstock an Begriffen und gemeinsamen Überzeugungen. Wer schon länger auf dem Gebiet arbeitet, hat diese Begriffe verinnerlicht und geht selbstverständlich davon aus, dass auch die Gesprächspartner mit denselben Annahmen und Ideen vertraut sind.
Auch in der Softwarequalität gibt es solche Begriffe und Konzepte. Wenn man sich dem Gebiet gerade erst nähert, ist es schwer, sie zu »verstehen«. Eigene Erfahrungen fehlen noch. In dieser Situation muss man sich die Begriffe aneignen, ohne noch viel damit zu verbinden. Das kommt dann später.
Q hat sich aufgerafft und eine Bewerbung geschrieben. Erstaunlich schnell kam ein Anruf, man hat Q zum Vorstellungsgespräch eingeladen. Q ist gespannt, was FunGate genau will, und ist zehn Minuten vor dem Termin vor dem Gebäude. Das FunGate-Gebäude im Gewerbegebiet hat mehrere Stockwerke und wirkt modern. In der Eingangshalle von FunGate betrachtet Q die Übersichtstafel.
Abb. 2–1 In der Empfangshalle von FunGate
Q interpretiert die räumliche Anordnung der Bereiche auf der Orientierungstafel (Abb. 2–1): Erfreut stellt Q fest, dass die Qualitätsinitiative ganz nahe bei der Geschäftsleitung sitzt und eng mit Schulungen verbunden zu sein scheint.
Recht erdnah und hardwareverbunden sind die Embedded-Software-Projekte, bei denen Drähte und Motoren eine Rolle spielen. Und was sich da im Keller genau abspielt, bleibt für Q zunächst mysteriös.
Auf dem Weg zum Vorstellungsgespräch im 4.OG kommt Q an einer offenen Tür vorbei. In dem Raum geht es hoch her. Q schätzt, dass sich hier 12–15 Leute angeregt unterhalten. Weil das Gespräch mit Qualität zu tun hat, bleibt Q kurz stehen: »... ach, ich denke mir, dass sich doch jeder bemüht. Wir sind alle gute Programmierer und nehmen uns Zeit, um unsere Programme so weit fehlerfrei hinzubekommen, dass wir völlig damit zufrieden sind. Unser Ziel heißt ›Null Fehler!‹, und das werden wir auch sicher erreichen. Naja, ein oder zwei Fehler finden wir schon mal beim Testen, aber das sind doch nicht viele, oder! Also alles in Butter. Manche arbeiten ja sogar ganz formal, da sind Fehler sowieso ausgeschlossen. Aber das muss man mögen, ich bin eher ein Praktiker, hahaha. Mal sehen, was die neue Q-Beauftragte macht.«
Was Q da hört, wirft doch einige Fragen auf: Nach der Qualitäts-Vorlesung, die Q gehört hatte, war die eigene, subjektive Zufriedenheit kein Qualitätskriterium. Testen bringt hier schon mehr, aber null Fehler sind doch illusorisch! Und es ist keine Schande, das zuzugeben. Überhaupt: Nur einen oder zwei Fehler zu finden, erscheint Q sogar zu wenig. Hat man da nicht eher schlampig getestet? Wer sind diese Leute eigentlich, und warum schwatzen die da einfach in der besten Arbeitszeit? Ach ja: Und wieso soll es unbedingt eine weibliche Qualitätsbeauftragte sein?
Im Vorstellungsgespräch geht der freundliche Personalchef erst einmal auf die Organisation der Softwarequalität bei FunGate ein. Q nimmt sich vor, später bei manchen Punkten nachzuhaken. Der Personalchef erläutert zunächst, wie die Softwarequalität in der Firma eingebettet ist.
Softwarequalität muss in der Organisation einer Firma verankert sein. Dazu gehören die Aufbauorganisation, die Ablauforganisation und ein Qualitätsmanagementsystem. In der Aufbauorganisation sind die Hierarchieebenen und Leitungsfunktionen geregelt, also wie die Softwarequalität in die statische Struktur der Firma eingebettet ist. Damit gute Softwarequalität auch gegen mögliche Widerstände durchgesetzt werden kann, sind zwei Regeln zu beachten:
Qualität ist auf allen Ebenen vertreten und bildet eine eigene Hierarchie, parallel zu der Linien- und Leitungshierarchie der Softwareentwicklung. In Abbildung 2–2 gibt es Mitarbeiter der Qualitätsorganisation auf allen Ebenen. Sie können unterschiedliche Bezeichnungen tragen, wie hier »Qualitätsleiter« oder »Leitung Softwarequalität«. In den Abteilungen wirken die Qualitätsbeauftragten (QB).
Auf jeder Ebene agieren die Qualitäts-Leute als Stabsstellen der jeweiligen Führungskraft auf dieser Ebene. Stabsstellen unterstützen die Führungskraft, ohne selbst Leitungsaufgaben wahrzunehmen. Dies ist durch die dünnen Linien angedeutet, die jeden Bereich (weiß) mit seinem »Schatten« verbinden. Der Schatten (grau) steht für die jeweils zugeordnete Stabsfunktion.
Abb. 2–2 Aufbauorganisation der Softwarequalität nach [Glinz ‘05]
Durch diese Regeln sind die beiden Hierarchien zwar auf allen Ebenen miteinander verbunden, aber Linienverantwortliche können die Qualitätsfachleute nicht zwingen, ihre Qualitätsansprüche zu senken. Denn Weisungsbefugnis besteht nur entlang der dicken (schwarzen und grauen) Linien. Ohne diese Unabhängigkeit hätte die Softwarequalität einen schweren Stand. Bei Termindruck könnte sie leicht an den Rand gedrängt werden. Dieses Prinzip der »Schattenhierarchie für Qualität« ist allgemein bekannt; dennoch wird es nicht immer eingehalten. Viele kleine oder unreife Organisationen kennen zwar dieses Prinzip, befolgen es aber nicht konsequent.
Bei der Ablauforganisation geht es um die dynamischen Abläufe und Prozesse. Aus Sicht der Qualität ist daran interessant, dass das Qualitätsmanagement (QM) einfach einen Unterstützungsprozess für die Entwicklung bildet – neben etlichen anderen, deren Grenzen zum QM übrigens recht fließend sind (Abb. 2–3). Bei aller Unabhängigkeit durch die eigene Qualitätshierarchie sollten sich Qualitätsmitarbeiter ihrer unterstützenden Rolle bewusst sein. Die wirkliche Leistungserbringung, von der ein Unternehmen letztlich lebt, findet in den Hauptprozessen statt. Infrastruktur-, Unterstützungs- und Managementprozesse rahmen diesen Kern ein. Glinz [Glinz ‘05] betont diesen Zusammenhang und strukturiert die Prozesse der Ablauforganisation. Abbildung 2–3 zeigt diese Prozesse, jedoch etwas anders dargestellt: Jeder Prozess ist als Prozesssymbol dargestellt. Die Prozesse laufen möglicherweise alle parallel. Die Schichtung soll verdeutlichen, dass die Hauptprozesse von den unterstützenden Prozessen und der Infrastruktur getragen werden. Die Abläufe im Management sind auch dem Projektmanagement übergeordnet. Hauptprozesse sind höher gezeichnet als die anderen. Das symbolisiert ihre größere Bedeutung, hat aber nichts mit Aufwand oder Umfang zu tun. Alle Prozesse müssen kontinuierlich bewertet und verbessert werden, um Probleme zu beseitigen, auf neue Anforderungen zu reagieren und die Effizienz zu steigern. Daher ist die Prozessverbesserung als umfassendes Prozesssymbol gezeichnet.
Abb. 2–3 Ablauforganisation der Softwarequalität
Die dritte organisatorische Einbettung ist das Qualitätsmanagementsystem (QMS). Es ist in der internationalen Norm ISO 8402 definiert. Nach dieser Norm gehören sechs Felder zum QMS, die hier nur kurz erläutert werden:
Qualitätspolitik: Einstellung und Grundsätze der Firma zur Softwarequalität.
Qualitätsorganisation: Aufbau- und Ablauforganisation zur Einbettung aller Softwarequalitätsaktivitäten in das Unternehmen.
Qualitätsmaßnahmen: Konkrete Aktivitäten zur Förderung der Qualität. Im Zentrum stehen Prüfungen (dabei besonders Testen und Reviews), aber auch Fortbildungsmaßnahmen gehören beispielsweise dazu.
Qualitätsaufzeichnungen: Es reicht nicht, die Maßnahmen durchzuführen. Ihre Resultate müssen auch nachvollziehbar dokumentiert werden. Bei Nachfragen und Kontrollen dienen die Aufzeichnungen als Beleg. Zusätzlich ermöglichen sie, wiederkehrende Probleme in der Firma zu identifizieren und sie intern zu beseitigen.
Dokumentation: Schließt die Aufzeichnungen ein und bettet sie in einen größeren Rahmen.
Auditierung des QMS: Das QMS muss seinerseits regelmäßig geprüft werden, damit sich nicht auf dieser organisatorischen Ebene Mängel einschleichen, die dann auf die Software ausstrahlen. Dies geschieht durch sogenannte Audits, bei denen meist mehrere externe Prüfer (die Auditoren) genau alle Abläufe prüfen.
Die obigen Konzepte ergänzen sich gegenseitig. Idealerweise leiten sie dazu an, Qualitätsziele vorzugeben und sie dann auch konsequent zu verfolgen. Wichtig sind kritische Beobachtung und Reflexion, ohne die eine kontinuierliche Verbesserung nicht möglich wäre. In jeder Firma und jedem Projekt müssen diese abstrakten Konzepte und Begriffe mit Leben gefüllt und konkret umgesetzt werden.
Auch der zentrale Begriff Qualitätsmanagement selbst ist in der Norm definiert:
Qualitätsmanagementsystem: »zur Verwirklichung des Qualitätsmanagements erforderliche Organisationsstruktur, Verfahren, Prozesse und Mittel« (ISO 8402).
Das QMS verwirklicht also das Qualitätsmanagement:
Qualitätsmanagement: »Alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortlichkeiten festlegen sowie diese durch Mittel wie Qualitätsplanung, -lenkung, -sicherung und -verbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen« (ISO 8402).
Die beiden Definitionen verweisen aufeinander, hängen also sehr eng zusammen. Mit Gesamtführungsaufgabe ist die Führungsaufgabe des Projektleiters (oder Abteilungsleiters) gemeint. Qualitätsmanagement ist damit zunächst eine normale Teilaufgabe der Softwareentwicklung. Oft wird sie an Qualitätsbeauftragte delegiert; aber letztlich gehört sie integral zum Entwicklungsprojekt. Das geht die ganze Firma an, auch hier ist zu erkennen, wie Qualitätsmanagement zur Gesamtführungsaufgabe gehört.
Man kann unterscheiden zwischen der Qualitätssicherung, die sich um die Umsetzung der Qualitätspolitik in einem Projekt kümmert, und dem Qualitätsmanagement, das alle Qualitätsbelange über ein einzelnes Projekt hinaus vertritt und darauf achtet, dass in allen Projekten die Qualitätspolitik durchgesetzt wird. Hier ist der Sprachgebrauch nicht ganz einheitlich, diese Unterscheidung ist aber in der Praxis nützlich.
Die Grundeinstellung eines Unternehmens zur Softwarequalität spiegelt sich in der Qualitätspolitik. Das ist eine Festlegung auf Prinzipien, Ziele und Richtlinien, denen man sich verpflichtet fühlt. Nur eine schriftlich fixierte und auch wirklich forcierte Qualitätspolitik verdient diesen Namen. Mit ein paar abstrakten Floskeln ist es nicht getan. Jede Qualitätspolitik sollte drei Grundsätze beachten [Glinz ‘05]:
Qualitätsanstrengungen dienen letztlich immer einem besseren Produkt und Prozess, sind also kein Selbstzweck.
Jeder Mitarbeiter ist für die Qualität seiner Arbeit zunächst persönlich verantwortlich.
Qualitätsbeauftragte sind dafür zuständig, Qualitätsmaßnahmen kompetent durchzuführen – aber nicht dafür, dass sie im Sinne des Projekts »gut ausgehen«. Wenn Mängel gefunden werden, ist das für das Projekt zunächst ärgerlich, aber ein Erfolg der Qualitätsmaßnahme. Nur ein gefundener Fehler kann beseitigt werden.
Dabei muss die Qualitätspolitik nicht höchste Qualität bei maximalem Einsatz von Geld und Ressourcen vorgeben. Sie wird in der Regel bescheidener ausfallen. Oft ist es besser, moderate Ziele zu benennen, die dann auch wirklich einzuhalten sind. »Null Fehler« sind kaum zu erreichen, dagegen sind »fast keine Fehler mehr nach der Auslieferung« eine ehrgeizige, aber erreichbare Vision.
Nach der Qualitätspolitik richten sich dann die anderen, oben angeführten Aspekte und Maßnahmen im Rahmen des Qualitätsmanagementsystems aus.
Qualitätsmaßnahmen müssen sich lohnen. Sie werden eingesetzt, um die eigenen Kosten zu reduzieren. Zu den Kosten zählen sowohl die Fehlervermeidungskosten (was man für Qualitätsmaßnahmen ausgibt) als auch die Fehlerkosten (was man für Fehlerbeseitigung, Haftung oder Entschädigung ausgeben muss, wenn doch Fehler aufgetreten sind). In Abbildung 2–4 sieht man beide Kostentypen, und als dritte Kurve die Summe davon. Offensichtlich ist das wirtschaftliche Ziel, diese Summe zu minimieren, also weder mehr noch weniger Aufwand in die Softwarequalität zu stecken. Auch Softwarequalität wird ganz prosaisch aus wirtschaftlicher Perspektive beurteilt. Damit beginnt das Ringen um den besten Kompromiss, der die Aufgabe qualitätsbewusster Projektmitarbeiter kennzeichnet.
Abb. 2–4 Optimierung der Qualitätsaufwände nach [Frühauf et al. ‘02]
Bevor es zu abstrakt wird, macht der Personalchef an dieser Stelle deutlich, dass trotz aller Qualitätspolitik natürlich ein gesundes Gefühl für die Kosten von Qualitätsanstrengungen erwartet wird: Schließlich will die Firma nicht pleite gehen, weil sie perfekte Qualität sogar noch dort liefert, wo es der Kunde nicht honoriert.
Q ist eher erleichtert: Trotz aller Ideale bleibt man doch am Boden und will einfach ein großes Kostenrisiko (durch Rückrufaktionen, verärgerte Kunden und Nacharbeit) mithilfe von Qualitätsbeauftragten und Qualitätsmaßnahmen reduzieren. Das klingt vernünftig.
Das erste Betätigungsfeld eines Qualitätsbeauftragten ist das eigene Unternehmen. Wenn die gesamte Entwicklung im eigenen Haus abläuft, gilt das auch für die Qualitätsmaßnahmen. Aber in unserer arbeitsteiligen Gesellschaft arbeiten selbst mittelgroße Unternehmen in vielen Projekten für Auftraggeber, die die Software in ein Gerät oder ein komplexes Softwaresystem einbauen wollen. Auf der anderen Seite arbeiten sie mit mehreren Unterauftragnehmern zusammen. Wenn sie sich Teile (oder Softwarekomponenten) anderswo billiger machen lassen können, wird man sie nicht selbst entwickeln. Das ist vernünftig, aber zwischen Auftragnehmern und eigenem Auftraggeber gerät ein Projekt natürlich leicht in eine Sandwich-Position. Darauf müssen auch die Qualitätsbeauftragten reagieren, damit die eigenen Qualitätsbedürfnisse nicht zwischen den Partnern zerrieben werden.
Dem Auftraggeber muss man verdeutlichen, dass alle nötigen Vorkehrungen für die Softwarequalität getroffen wurden und die Ergebnisse sich (hoffentlich) zufriedenstellend entwickeln. Dieser Nachweis bildet den Kern der Qualitätssicherung.
Dagegen wird man den eigenen Auftragnehmern nicht unbesehen alles glauben. Wenn eine zugelieferte Softwarekomponente für das Gesamtprojekt sehr wichtig ist, wird ein versierter und risikobewusster Projektleiter schon vor Auslieferung Prüfberichte fordern und sich regelmäßig immer wieder in die Qualitätsbemühungen der Auftragnehmer einklinken.
Hier kommt es darauf an, das rechte Maß zu finden: Weder möchte man sich blind auf andere verlassen, noch möchte man mehr Aufwand in die Überwachung der Qualitätsmaßnahmen stecken, als durch die Delegation der Aufgabe eingespart wird. Diese Situation verlangt besonderes Fingerspitzengefühl.