Erfolgsmessung der Gestaltung der Qualitätssicherung

Inhaltsverzeichnis

1 Einleitung

2 Qualität und Qualitätssicherung
2.1 Der Qualitätsbegriff
2.2 Softwarequalität als Drei-Ebenen-Hierarchie
2.3 Qualitätssicherung
2.3.1 Ziele der Qualitätssicherung
2.3.2 Maßnahmen der Qualitätssicherung

3 Erfolgsmessung der Qualitätssicherung
3.1 Erfolgsmessung anhand der zu erwartenden Fehlerzahl
3.2 Erfolgsmessung der Qualitätssicherung bei Hewlett-Packard
3.3 Ein kostenorientierter Ansatz der Erfolgsmessung
3.4 Erfolgsmessung anhand der Produktivität
3.5 Erfolgsmessung durch Experten-Beurteilung

4 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 3-1: Fehlerentwicklung über die Zeit

Abb. 3-2: Service-Anfragen nach Veröffentlichung

Abb. 3-3: Fehlerprofil einer HP-Division

Abb. 3-4: Dreiecksverteilung des SAL

1 Einleitung

Um beurteilen zu können, ob die Gestaltung der Qualitätssicherung in einem Unternehmen angemessen ist, muss sowohl deren Wirksamkeit als auch der erforderliche Aufwand überprüft werden. Benötigt wird daher ein Maß für den Erfolg der Qualitätssicherung. Ziel dieser Arbeit ist es, verschiedene Vorgehensweisen zu beschreiben, anhand welcher die Zielerreichung, d.h. der Erfolg der Qualitätssicherung gemessen werden kann, bzw. wie existierende Schwachstellen oder Defizite bei der bisherigen Gestaltung der Qualitätssicherung in Softwareprojekten aufgedeckt und behoben werden können. Dazu werden, nach der Klärung grundlegender Begrifflichkeiten, zunächst Ziele der Qualitätssicherung definiert sowie die zur Erreichung dieser Ziele ergriffenen Maßnahmen strukturiert und beschrieben. In Kapitel 3 werden anschließend verschiedene Ansätze und Maße vorgestellt, die zur Erfolgsmessung der Qualitätssicherung herangezogen werden können. Diese entstammen der, speziell in Bezug auf die Erfolgsmessung, spärlich gesäten, empirischen Literatur oder basieren auf Fallstudien, welche die Lösungen großer Softwarehäuser, wie z.B. Hewlett-Packard, zu dieser Problemstellung beschreiben.

2 Qualität und Qualitätssicherung

2.1 Der Qualitätsbegriff

Balzert definiert den Begriff Qualität als die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.^[1] Aufgrund der Einzigartigkeit von Softwareprodukten in Bezug auf ihre Entwicklung und Verwendung kann diese Definition auch auf Softwarequalität übertragen werden. Softwarequalität^[2] wird dementsprechend durch eine entwicklungsspezifische Menge von Qualitätsmerkmalen beschrieben, deren Ziel es ist, bestimmte Qualitätsanforderungen zu erfüllen. Sechs Qualitätsmerkmale von Softwareprodukten sind in der ISO-Norm 9126 definiert. Diese sind: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Qualitätsanforderungen legen fest, welche Qualitätsmerkmale für ein spezifisches Softwareprodukt als relevant erachtet werden und welche quantitative Ausprägung von dem jeweiligen Qualitätsmerkmal verlangt wird.

2.2 Softwarequalität als Drei-Ebenen-Hierarchie

Es ist kaum möglich, einen Wert für die Softwarequalität oder auch den eines Qualitätsmerkmals direkt zu bestimmen. Softwarequalität wird dazu begrifflich in Qualitätsmerkmale, -attribute und –maße zerlegt.^[3] Auf oberster Ebene der so entstehenden Hierarchie befinden sich die entwicklungsspezifisch relevanten Qualitätsmerkmale, welche jeweils durch eine Menge von Qualitätsattributen verfeinert werden, die wiederum auf unterster Ebene durch Qualitätsmaße mess- und bewertbar gemacht werden. Das Qualitätsmerkmal „Zuverlässigkeit“ kann so beispielsweise in die Qualitätsattribute „Reife“, „Fehlertoleranz“ und „Wiederherstellbarkeit“ zerlegt werden, wobei das Qualitätsattribut „Reife“ durch das Qualitätsmaß „Mean Time to Failure“ (=Zeit bis zum nächsten Systemabsturz bzw. Auftreten eines Fehlers) gemessen werden kann.

Qualitätsmaße erlauben also quantitative Rückschlüsse auf die Ausprägung eines Qualitätsattributs.^[4] Beruhen diese auf physischen Beobachtungen am Softwareprodukt, z.B. die enthaltene Fehlerzahl, spricht man von einem objektiven Qualitätsmaß. Fließen in die Messung personenbezogene Einschätzungen o.ä. ein, ist das Qualitätsmaß subjektiv. Weiterhin lassen sich direkte und indirekte Qualitätsmaße unterscheiden. Die in einem Modul enthaltene Fehlerzahl ist ein direktes Qualitätsmaß. Wird dieses Maß jedoch zum Zwecke der Vergleichbarkeit verschiedener Softwaremodule über die Modulgröße normalisiert, spricht man von einem indirekten Qualitätsmaß.

Wurden alle Attribute eines Qualitätsmerkmals mittels repräsentativer Qualitätsmaße gemessen, kann je nach Bedeutung der einzelnen Attribute in Bezug auf das übergeordnete Merkmal eine Gewichtung der Werte vorgenommen werden.^[5] Man erhält so ein quantitatives Maß für alle Qualitätsmerkmale.

2.3 Qualitätssicherung

Es genügt nicht, Qualitätsanforderungen lediglich aufzustellen.^[6] Genauso wichtig ist es, dafür zu sorgen, dass diese auch erfüllt werden. Qualitäts-management umfasst alle Maßnahmen der Planung, Lenkung und Kontrolle, um die Qualität von Prozess und Produkt eines Softwareentwicklungsprojekts sicherzustellen. Man unterscheidet zwischen konstruktiven und analytischen Qualitätsmanagement-Maßnahmen. Zu den konstruktiven Qualitäts-management-Maßnahmen zählen alle Methoden, Sprachen, Werkzeuge, Richtlinien, Standards und Checklisten, die dafür sorgen, dass der Prozess bzw. das entstehende Produkt à priori die Qualitätsanforderungen erfüllt. Durch analytische Qualitätsmanagement-Maßnahmen wird gemessen, inwieweit die entwicklungsspezifisch relevanten Qualitätsmerkmale die Qualitätsanforderungen erfüllen. Die Durchführung analytischer Maßnahmen ist Aufgabe der Qualitätssicherung.

2.3.1 Ziele der Qualitätssicherung

Die Qualitätssicherung in einem Softwareentwicklungsprojekt verfolgt zwei wesentliche Ziele – die Validierung und die Verifizierung des entstehenden Produktes.^[7] Unter Validierung wird hier die Überprüfung der Tauglichkeit eines Softwareproduktes bezogen auf seinen Einsatzzweck verstanden. Hier geht es um eine Prüfung gegen die Bedürfnisse des Kunden. Wird die Übereinstimmung zwischen spezifizierter und tatsächlicher Ausprägung der Qualitätsmerkmale eines Softwareproduktes überprüft, spricht man von Verifizierung. Es handelt sich also um eine Prüfung gegen die expliziten Qualitätsanforderungen.

2.3.2 Maßnahmen der Qualitätssicherung

Zur Erreichung der Ziele der Validierung und Verifizierung werden im Rahmen der Qualitätssicherung in allen Phasen eines Softwareentwicklungsprojektes analytische Qualitätsmanagement-Maßnahmen durchgeführt.^[8] Diese bringen von sich aus keine zusätzliche Qualität in den Entwicklungsprozess oder das Produkt ein, sondern messen lediglich das existierende Qualitätsniveau^[9]. Mit Hilfe analytischer Qualitätsmanagement-Maßnahmen können jedoch Ausmaß und Ort von Fehlern identifiziert werden. Analytische Maßnahmen können in allen Phasen eines Softwareentwicklungsprojektes angewandt werden. Balzert unterscheidet zwischen analysierenden und testenden Maßnahmen. Analysierende Maßnahmen sammeln gezielt Informationen über ein Prüfobjekt, z.B. ein einzelnes Software-Modul, ohne dieses jedoch auszuführen oder Eingaben zu tätigen. Statische Vorgehensweisen wie u.a. Code-Reviews, Inspektionen, Walkthroughs und Audits sind dieser Maßnahmenart zuzuordnen. Testende Maßnahmen führen das Prüfobjekt mit Eingaben aus. Hierzu zählen dynamische Tests, wie z.B. Funktionsabdeckungstests, Zufallstests, Anweisungs-, Zweig- und Bedingungsüberdeckung,^[10] symbolische Tests, Simulationen und Schreibtischtests.

Aufgabe der Qualitätssicherung ist zwar lediglich die Durchführung analytischer Maßnahmen, allerdings sind diese eng mit den konstruktiven Qualitätsmanagement-Maßnahmen verknüpft bzw. voneinander abhängig.^[11] Die Durchführung eines umfassenden Modultests, z.B. hinsichtlich der Zweigüberdeckung, ist nur dann möglich, wenn auch eine ausreichende Modularisierung (konstruktive Maßnahme) vorliegt. Fehlende oder geringe konstruktive Maßnahmen erfordern in der Regel viele aufwendige analytische Maßnahmen. Es gilt, durch vorrausschauende Planung konstruktiver Maßnahmen, den analytischen Aufwand zu reduzieren. Aus diesem Grund ist es auch sinnvoll, bei einer Betrachtung der Erfolgsmessung der Gestaltung der Qualitätssicherung, konstruktive Qualitätsmanagement-Maßnahmen nicht unbeachtet zu lassen, sondern sie in mögliche Ansätze mit einzubeziehen.

3 Erfolgsmessung der Qualitätssicherung

3.1 Erfolgsmessung anhand der zu erwartenden Fehlerzahl

Das Testen von Software im Rahmen der Durchführung analytischer Qualitätsmanagement-Maßnahmen ist derzeit die am meisten benutzte Methode, um sich über deren Qualität und Eignung für den Gebrauch ein Bild zu verschaffen.^[12] Das sich hier ergebende Problem ist jedoch, dass durch Testen zwar Fehler aufgedeckt werden, Fehlerfreiheit aber keineswegs garantiert werden kann. Für die Erfolgsmessung der Gestaltung der Qualitätssicherung stellt sich also die Frage, ob die während eines Softwareentwicklungsprojektes ergriffenen, qualitätssichernden Maßnahmen auch wirklich zu einer Erfüllung der Qualitätsanforderungen führen bzw. geführt haben.

Die in einem Softwareprodukt enthaltene Fehlerzahl ist ein beliebtes, zur Beurteilung von Softwarequalität herangezogenes Maß. Im Folgenden werden Maße vorgestellt, die es ermöglichen, auf Basis der Fehlerzahl, Aussagen zum Erfolg der Gestaltung der Qualitätssicherung zu machen.

Grundsätzlich stellt sich in diesem Zusammenhang die Frage, mit wie vielen Fehlern in der Software überhaupt zu rechnen ist. Thaller gibt dazu verschiedene Formeln für die Berechnung der zu erwartenden Fehlerzahl in Abhängigkeit verschiedener Faktoren wie LOC, Erfahrung des Entwicklungsteams, Änderungen am Lastenheft während der Entwicklung usw. an.^[13] Sofern vorhanden kann auch der Industriedurchschnitt als Richtlinie herangezogen werden. Generell gilt allerdings, dass Zahlen aus dem eigenen Unternehmen aussagekräftiger sind, nur müssen diese erst einmal in aufwändiger, langjähriger Arbeit einheitlich^[14] erfasst werden. Eine Gegenüberstellung erwarteter und gefundener Fehler informiert über Erfolg oder Misserfolg der durchgeführten Tests bzw. der Gestaltung der Qualitätssicherung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 - 1: Fehlerentwicklung über die Zeit^[15]

Je später ein Fehler im Entwicklungsprozess gefunden wird, desto kostspieliger wird seine Behebung. Die Qualitätssicherung sollte es also anstreben, möglichst viele Fehler möglichst früh zu entdecken. Anhand der kumulierten gefundenen Fehler über die Projektlaufzeit kann man messen, wann man die zu erwartende Fehlerzahl erreicht hat und die jeweils gefundenen Fehler einzelnen Phasen im Projekt zuordnen.^[16] In Abb. 3-1 stellt Kurve A den optimalen Verlauf der gefundenen Fehlerzahl über die Projektlaufzeit dar. Realisierbare Zahlen sind 50-75% gefundene Fehler während der Entwicklung und 90-97% während des Systemtests.^[17] Ein Kurve B ähnelnder Verlauf sollte möglichst vermieden werden. In dieser Situation sollte von Seiten der Qualitätssicherung zu verstärkter und sorgfältigerer Anwendung analytischer Qualitätsmanagement-Maßnahmen gedrängt werden.^[18] Wird ein Großteil der Fehler nämlich erst während des Systemtests gefunden, deutet dies z.B. auf unzureichende Modultests hin. Analysierende und testende Maßnahmen, wie z.B. Anweisungs- oder Zweigüberdeckungstests oder auch Design-Reviews wurden offensichtlich in den Anfangsphasen des Projektes nicht sorgfältig genug durchgeführt. Überprüft werden kann dies beispielsweise durch den Einsatz automatisierter Tools, die den Anteil des durch solche Tests untersuchten Programmcodes messen.^[19] Im Rahmen der in Kapitel 3.2 behandelten Fallstudie des Softwarehauses HP, konnte anhand dieser Tools bei 22 betrachteten Softwareprodukten, von denen die Entwickler überzeugt waren, sie ausgiebig und vollständig getestet zu haben, festgestellt werden, dass im Durchschnitt lediglich 50% des Programmcodes überprüft wurde.

[...]

^[1] Vgl. zu diesem Absatz Balzert /Software-Management/ 257, 272-273

^[2] Für diesen Text gilt: Qualität = Softwarequalität

^[3] Vgl. zu diesem Absatz Balzert /Software-Management/ 258-260, Rosqvist, Koskela, Harju /Expert Judgement/ 41-42 sowie Evans, Marciniak /Software Quality Assurance/ 161-162

^[4] Vgl. Liggesmeyer /Software-Qualität/ 6

^[5] Vgl. zu diesem Absatz Rosqvist, Koskela, Harju /Expert Judgement/ 42 sowie Müller, Paulish /Software-Metriken in der Praxis/ 56-60

^[6] Vgl. zu diesem Absatz Balzert /Software-Management/ 278-280

^[7] Vgl. zu diesem Absatz Balzert /Software-Management/ 101 sowie Trauboth /Software-Qualitätssicherung/ 147

^[8] Vgl. zu diesem Absatz Balzert /Software-Management/ 279-281

^[9] d.h. die Ausprägung der relevanten Qualitätsmerkmale bzw. -attribute

^[10] Beschreibung dieser Verfahren in Liggesmeyer /Modultest/ 62-108

^[11] Vgl. zu diesem Absatz Balzert /Software-Management/ 281-282

^[12] Vgl. Thaller /Software Metriken/ 82

^[13] Vgl. Thaller /Software Metriken/ 83-84

^[14] Eine unternehmensweit einheitliche Definition von z.B. LOC ist notwendig um Vergleichbarkeit zwischen einzelnen Projekten zu ermöglichen.

^[15] Vgl. Thaller /Software Metriken/ 87 sowie Müller, Paulish /Software-Metriken in der Praxis/ 84, 97

^[16] Vgl. Thaller /Software Metriken/ 86-87

^[17] Vgl. Müller, Paulish /Software-Metriken in der Praxis/ 84, 96-97

^[18] Vgl. Thaller /Software Metriken/ 87

^[19] Vgl. Grady /Measuring Software-Quality/ 64