Messprogramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von Bauer & Partner Application2Web AP6

Transkript

1 Messprogramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von Bauer & Partner Application2Web AP6 Autoren: Bernd Freimut (IESE) Jochen Hiller (Bauer & Partner) Ralf Kalmar (IESE) Teade Punter (IESE) Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministerium für Wirtschaft und Technologie unter den Förderkennzeichen 16IN0047 und 16IN0048 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. IESE-Report Nr /D Version Dezember, 2002 Eine Publikation des Fraunhofer IESE

2

3 Das Fraunhofer IESE ist ein Institut der Fraunhofer-Gesellschaft. Das Institut überträgt innovative Software-Entwicklungstechniken, -Methoden und -Werkzeuge in die industrielle Praxis. Es hilft Unternehmen, bedarfsgerechte Software-Kompetenzen aufzubauen und eine wettbewerbsfähige Marktposition zu erlangen. Das Fraunhofer IESE steht unter der Leitung von Prof. Dr. Dieter Rombach Sauerwiesen Kaiserslautern

4

5 Abstract Dieses Arbeitspapier dokumentiert Ziele, Fragen und Metriken gemäß der GQM-Methode und beschreibt die Erfassung und Auswertung der Messdaten eines Messprogramms, welches begleitend zu einem Entwicklungsprojekt der Bauer & Partner GmbH im Jahr 2002 durchgeführt wurde. Die Ziele von Bauer & Partner bestanden dabei im Kennenlernen und Erproben der messbasierten Verbesserung im Allgemeinen und der Erreichung des Verbesserungsziels Minimierung der Fehlerrate im Speziellen. Der Bericht dokumentiert dabei die Ergebnisse des Arbeitspakets 6.2 des Projekts Application2Web, in dessen Kontext diese Arbeiten durchgeführt wurden. Schlagworte: GQM, Metriken, Fehler, Regressionstest i

6

7 Inhaltsverzeichnis 1 Übersicht Einordnung Vorgehen Inhalt des Dokuments 2 2 Ziele Verbesserungsziel Messziel 4 3 Spezifikation der Messungen Fragen zu Qualitätsaspekten Fragen zu Einflussfaktoren auf die Qualitätsaspekte (engl. Variation Factor) 12 4 Messplan Auswahl der zu erfassenden Metriken Datenquellen und Messmethode Planung Datenerfassung Datenanalyse Interpretation der Daten 16 5 Ergebnisse Datenerfassung Interpretation der Ergebnisse Vollständigkeit der Datenerfassung Fehlerschwerpunkte im System Einfluss der Testabdeckung von Regressionstests Fehlerursache Auswirkung der Fehler Abgeleitete Maßnahmen Bewertung der Vorgehensweise und der Ergebnisse 20 Anhang A Datenerfassungsbögen 21 A.1 Projektcharakterisierung 21 A.2 Fehlererfassung 21 Anhang B Detaillierte Definition der Attribute zur Charakterisierung der Fehler. 24 iii

8 B.1 Defect Type (Defect Type for Target=Design/Code) 24 B.2 QUALIFIER (applies to Defect Type) 26 B.3 Impact 26 B.4 Location 26 B.5 Effort 27 B.6 Test-coverage 27 Anhang C Prozessübersicht Integrationstest 28 Anhang D Referenzen 29 iv Copyright Fraunhofer IESE 2001

9 1 Übersicht 1.1 Einordnung Das von BMWI und VDI geförderte Projekt Application2Web unterstützt Firmen methodisch bei der Implementierung/Portierung von Web-fähigen Applikationen. Bauer & Partner ist ein Mitglied des Projekt-Konsortiums, welches vom Forschungszentrum Informatik (FZI) und Fraunhofer Institut für Experimentelles Software-Engineering (IESE) geleitet wird. Ein Arbeitspaket des Projekts beschäftigt sich mit Qualitäts- und Prozessmanagement. Im Rahmen dieses Arbeitspaketes arbeiten Bauer & Partner und IESE zusammen an der Implementierung von Software- Metriken zur Prozess- und Produktverbesserung, die auf Basis des Goal- Question-Metrik Paradigmas (GQM) [vsol99] ermittelt und ausgewertet werden sollen. Dieses Arbeitspapier dokumentiert Ziele, Fragen und Metriken gemäß der GQM-Methode und beschreibt die Erfassung und Auswertung der Messdaten zur Unterstützung des Verbesserungsziels Minimierung der Fehlerrate des Produkts Top-Logic in der Produktion. Top-Logic ist Element einer größeren Produktfamilie. Da die Grundstruktur der Produkte und die Entwicklungsprozesse innerhalb der Familie gleich sind, können die hier dokumentierten Fragen und Metriken auch einfach auf entsprechende Messziele von anderen Mitgliedern der Produktfamilie angepasst werden. 1.2 Vorgehen Das Vorgehen hält sich an die beim Fraunhofer IESE etablierte und mehrfach erfolgreiche Anwendung des GQM-Ansatzes zur messbasierten Prozessverbesserung, der nachfolgend grob skizziert wird und in Abbildung 1 auf Seite 2 grafisch dargestellt ist. Gemeinsam mit Bauer & Partner wurde zunächst ein Verbesserungsziel definiert. Die Erreichung des Verbesserungsziels soll mit Hilfe von Messdaten unterstützt werden. Hierzu wurde ein Messziel abgeleitet, welches charakterisiert, welcher Aspekt des Entwicklungsprozesses zu welchem Zweck und unter welchem Gesichtspunkt mittels Messung untersucht werden soll. Der betroffene Teil des Entwicklungsprozesses wurde grafisch modelliert und dokumentiert. Mit Hilfe eines Interviews bei Bauer & Partner wurden für das Messziel Qualitätscharakteristika und Einflussfaktoren identifiziert, welche in Fragen formuliert wurden.hypothesen zu den möglichen Antworten charakterisierten das implizite Wissen. Aus den Fragen wurden die nötigen quantitativen und qualitativen Informationen abgeleitet, die zur Beantwortung nötig sind (in Form von Metriken). 1

10 Ausblick (die nächsten Schritte sind nicht mehr Teil dieses Dokuments): Nach Planung der Datensammlung werden Daten erfasst und eine Auswertung und Analyse der Messdaten erfolgt. Die Messdaten werden zur Entscheidungsunterstützung für die Ableitung von Prozessoptimierungen und Verbesserungsmaßnahmen genutzt. Verbesserungsziel validieren Verbesserung Messziel Fragen zum Ziel Interpretation Analyse Hypothesen zu Antw. Metriken für Antworten validieren Messdaten Datenerfassung Abbildung 1: Übersicht zum Vorgehen 1.3 Inhalt des Dokuments Die nachfolgenden Kapitel dokumentieren das in Abschnitt 1.2 beschriebene Vorgehen. Kapitel 2 enthält das Verbesserungsziel, sowie das daraus abgeleitete Messziel, Kapitel 3 die abgeleiteten Fragen und die Metriken zum Messziel. Die Durchführung der Messungen ist in Kapitel 4 beschrieben. Die Ergebnisse und Analysen der Messdaten sind nicht Teil dieses Dokuments. Die Anhänge enthalten Datenerfassungsbögen, eine Prozessübersicht zum Integrationstest, eine Liste mit Literaturreferenzen, Details zur Fehlerklassifikation und ein Glossar. 2 Copyright Fraunhofer IESE 2001

11 2 Ziele Dieses Kapitel charakterisiert die Ziele des Projekts. Neben dem übergeordneten Verbesserungsziel wird das daraus abgeleitete Messziel definiert, welches den Ausgangspunkt für die Definition von Metriken darstellt Verbesserungsziel Das folgende Verbesserungsziel wurde definiert: Minimierung der Fehlerrate des Produkts Top-Logic in der Produktion. Definition Fehlerrate: Anzahl der in der Produktion 2 gefundenen bzw. gemeldeten Fehler pro Zeiteinheit. Die Minimierung soll erreicht werden durch eine Optimierung (Verbesserung) des Integrationstests und dort insbesondere der Regressionstests. Jeder Fehler, der bereits vor der Produktion gefunden und behoben wird, verringert die Gesamtfehlerrate in der Produktion. Dabei wird angenommen, dass während der Entwicklung eine konstante Anzahl von Fehlern in das System eingebracht werden. Daher bedeutet eine Erhöhung der gefundenen Fehler im Test eine Minimierung der Produktionsfehler. Man kann das Verbesserungsziel deshalb umformulieren zu: Minimierung des Anteils der in der Produktion gefundenen Fehler von der Gesamtfehlerzahl. min! [Produktionsfehler] / ([Integrationstestfehler] + [Produktionsfehler]), x% der in Integrationstest und Produktion entdeckten Fehler entfallen auf die Produktion Definition Produktionsfehler: Anzahl der in der Produktion gefundenen bzw. gemeldeten Fehler. Definition Integrationstestfehler: Anzahl der während des Integrationstests gefundenen bzw. gemeldeten Fehler. Bei Bauer & Partner wird über die Maßnahme Durchführung von Regressionstests versucht, die Testqualität zu verbessern. Deshalb soll die Einführung dieser Maßnahme über mehrere Releases mit Messungen beobachtet werden, um positive Effekte des Regressionstest zu 1 Bemerkung: neben dem hier dargestellten Verbesserungsziel bzgl. des Integrationstestprozesses wurde noch ein weiteres Verbesserungsziel Zuverlässigkeit bzgl. des Produkts Top-Logic definiert, welches erst später weiter verfolgt werden soll. 2 Unter Produktion wird hier die Zeitraum verstanden, in dem das Produkt im Betrieb beim Kunden eingesetzt wird, d.h. die Entwicklung (und damit alle entwicklungsinternen Tests) abgeschlossen sind. 3

12 dokumentieren und mit weiteren Maßnahmen schlussendlich eine Minimierung der Fehlerrate zu erreichen. 2.2 Messziel Das folgende Messziel wurde zur Unterstützung des Verbesserungsziels mit konkreten Messdaten aufgestellt. Für eine Minimierung ist es notwendig den aktuellen Stand, sowie die Ergebnisse nach zukünftigen Maßnahmen zu kennen: Charakterisiere die Qualität des Regressionstest für das Produkt Top- Logic aus Sicht des verantwortlichen Projektleiters. Qualitätsfaktor Unter Qualität des Regressionstest wird verstanden: Anzahl und Art der entdeckten Fehler (daraus lässt sich der prozentuale Anteil der mit Regressionstests gefundenen Fehler von der Gesamtfehlerzahl ermitteln). Testabdeckung (eine ausreichende Anzahl Testfälle existiert für jede funktionale Anforderung) Verhältnismäßigkeit der Tests (Aufwand Kodierung/Aufwand Test), Stichwort design for testability Zu messendes Objekt Zentrales Objekt der Untersuchung ist der Regressionstest. Regressionstests werden im Top-Logic Projekt nach dem JUnit-Framework mit dem gleichnamigen frei erhältlichen Tool JUnit-TestRunner durchgeführt. Auch ein Teil der grafischen Oberfläche wird mittels HttpUnit einem GUI- Regressionstest unterzogen. Um die Qualität der Regressionstests im Integrationstest besser beurteilen zu können, werden entdeckte Fehler von den folgenden Testprozessen (im Sinne des Entdeckungszeitpunkts) betrachtet (das Produkt in Produktion ist mit aufgeführt, damit die Gesamtfehlerzahl bestimmt werden kann): 4 Copyright Fraunhofer IESE 2001

13 Für das Messziel relevante Prozessschritte Integrationstestprozess Produktion Fehlerprotokoll (für Fehler in freigegebenen Klassen) Code-Review Trouble-Ticket System Implementierung/ Korr. Komponententest Check-In (Freigabe der Klasse) Bug-Review JUnit-Systemtest (Regressionstest) GUI-Test GUI-Regressionstest System in Produktion Fehlerprotokoll Legende Fehlerquelle Kontrollfluss Messen der Anzahl der Fehler Abbildung 2: Für die Messung relevante Teile des Entwicklungsprozesses Eine Übersicht zum gesamten Integrationstestprozess ist im Anhang C enthalten. Zielumgebung Top-Logic ist eine Plattform für Wissensmanagementsysteme. Top-Logic wird von einem Entwicklungsteam mit ca Entwicklern umgesetzt. Es handelt sich um eine webbasierte Anwendung, die auf Basis von Java Technologien (J2SE, J2EE) entwickelt wird. Die Plattform setzt auf generische Ansätze wie flexible Modelle durch änderbare Metaschemata, einsteckbare Komponenten und Services, Portalelemente, Workflows, Regeln etc. Zusätzlich zur Top-Logic Wissensmanagement-Plattform werden Lösungen auf Basis dieser Plattform entwickelt, die den Kunden bereitgestellt werden. Hier sind nochmals ca Entwickler beteiligt. Die Top-Logic Plattform besteht aus mehr als 2000 Java-Klassen, sowie mehr als 2000 Oberfächenelementen (JSP s, HTML). Eine Lösung besteht typischerweise aus mehr als 400 Klassen und mehr als 500 Oberflächenelementen. Alle Entwickler arbeiten sehr eng zusammen. Die Entwicklung findet in gemeinsamen Büroräumen statt, was eine hohe Teamkommunikation ermöglicht. Der Entwicklungsprozess basiert auf einer iterativen Vorgehensweise (auf Basis des Rational Unified Process (RUP)). Es werden kurze Iterationszyklen von ca. 3-4 Wochen definiert. Neue Produktreleases erscheinen 3-4 mal pro Jahr, dabei ist ein Major-Release. Wesentlicher Bestandteil des Entwicklungsprozesses ist eine testzentrierte Vorgehensweise, wie sie auch im Extreme Programming (XP) Paradigma definiert ist. Die Entwickler schreiben auf Basis von JUnit Entwicklertests, die 5

14 in einer Gesamttestsuite als Regressionstest reproduzierbar ausgeführt werden könnnen. Dies geschieht mindestens einmal pro Woche, in der Regel aber täglich als Teil des nächtlichen Build-Prozesses. Diese idealtypische Prozess wird nicht von allen Entwicklern gleichermaßen gut gelebt. Einzelne Komponenten sind sehr gut durch Regressionstests abgedeckt, während für andere Komponenten fast überhaupt keine Regressionstests existieren. Hier spielen Einflüssen wie die Akzeptanz der Vorgehensweise durch einen Entwickler, Aufwände für Regressionstests sowie die aktuelle Projektsituation mit Lieferterminen eine wesentliche Rolle. Rollen Es sind im Wesentlichen zwei Rollen für das Messziel relevant: der Entwickler/Tester und der Projektverantwortliche. Die Rolle des Testers bezieht sich hier auf Entwickler-Tests, es werden im Moment aufgrund der Projektgrößen keine fachlichen Abnahmetests berücksichtigt. Das Messziel ist aus Sicht des Projektverantwortlichen zu sehen, der gleichzeitig die Rolle eines Process Owners (d.h. Prozessverantwortlicher) innehat. Es ist abzusehen, dass auch die Entwickler/Tester bei der Datenerfassung involviert werden, da sie die Fehlerbehebung vornehmen (s. auch Darstellung des Integrationstestprozesses in Anhang C). 6 Copyright Fraunhofer IESE 2001

15 3 Spezifikation der Messungen Dieses Kapitel enthält eine Auflistung aller Fragen, deren Beantwortung die Erreichung des Messziels unterstützen. Die Fragen sind gruppiert bzgl. des Qualitätsaspekts und bzgl. der Einflussfaktoren. Fragen, die den Qualitätsaspekt betreffen beziehen sich direkt auf die Qualität des Regressionstests. Fragen zu den sogenannten Einflussfaktoren beziehen sich auf Umgebungscharakteristika, die einen Qualitätsaspekt positiv oder negativ beeinflussen (z.b. die Erfahrung eines Entwicklers beeinflusst die Entwicklungszeit, d.h. Entwickler entwickeln schneller mit längerer Erfahrung). Qualitätsaspekte und Einflussfaktoren wurden in einem Interview mit dem Projektverantwortlichen und einem erfahrenen Entwickler ermittelt. Die tatsächlich erfassten Metriken und damit die Fragen, welche beantwortet werden können, sind im Messplan (Kapitel 4) aufgeführt Fragen zu Qualitätsaspekten Fehleranzahl QF 1 Wie viele Fehler wurden in den folgenden Prozessen gefunden (absolut und relativ für ein Release): Komponententest, Code-Review, Regressionstests, GUI-Test, GUI-Regressionstest, Bug-Review, Produktion? Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion Wie viele Fehler wurden gefunden? Produkt Datum TopLogic R Fehlerzahl Komponententest Regressionstest GUI-Tests GUI-Regressionstests Produktion Prozess 7

16 (b) QF 1 GUI-Regressionstests 4% Wie viele Fehler wurden gefunden? Produktion 9% Komponententest 29% Produkt Datum TopLogic R GUI-Tests 15% Regressionstest 43% Metrik Hypothese Bemerkung Defect_Count: Anzahl der Fehler pro Woche je Prozess (s.o.) Daten aus Produktionsphase sind erst nach Entwicklungsabschluss verfügbar Fehlerattribute QF 2 Was war die Fehlerursache für die in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung je Prozess und Gegenüberstellung mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 2 Was war die Fehlerursache? 100% 80% Produkt TopLogic R3 Datum Fehlerzahl 60% 40% 20% Ursache 5 Ursache 4 Ursache 3 Ursache 2 Ursache 1 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess Produktion Metrik Hypothese Defect_TestReliability Klassifikation jedes erfassten Fehlers nach seiner Ursache im Hinblick auf das Vorhandensein eines Testfalls: Skala: No tests Tests incomplete Tests raised 8 Copyright Fraunhofer IESE 2001

17 QF 3 Bemerkung Daten aus Produktionsphase sind erst nach Entwicklungsabschluss verfügbar Wie hoch war der Aufwand für die Fehlerkorrektur der in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 3 Wie lange dauerten Fehlersuche und -behebung? 100% 90% 80% 70% Produkt TopLogic R3 Datum Fehlerzahl 60% 50% 40% >1 Tag <1 Tag <1h 30% 27 20% 10% 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess 2 Produktion QF 4 Metrik Hypothese Bemerkung Defect_ETR Klassifikation jedes entdeckten Fehlers nach Aufwand zur Fehlersuche und Fehlerbehebung (Effort to Repair, ETR): Skala: small (<1h), medium (<0.5 day), large (>=0.5 day) Es ist kein Ziel den Gesamtaufwand zur Fehlersuche/- behebung zu erfassen. Wie hoch war die Schwere (Auswirkung, impact) der Fehler der in den Prozessen Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest, Produktion entdeckten Fehler? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 4 Wie war die Schwere der Fehler verteilt? 100% 90% 80% 70% Produkt TopLogic R3 Datum Fehlerzahl 60% 50% 40% 30% critical major minor 20% 10% 0% 2 Komponententest Regressionstest GUI-Tests GUI- Regressionstests 2 Prozess Produktion Alle Daten sind rein fiktiv! 9

18 Metrik Hypothese Bemerkung Defect_Impact Klassifikation jedes entdeckten Fehlers nach seiner Schwere aus Kundensicht: Skala: Component Functionality System/Application Workaround No Relevance Frage könnte noch in Unterfragen verfeinert werden: z.b. In welcher Phase wurden die meisten kritischen Fehler entdeckt? QF 5 Welche Fehlertypen wurden in den Prozessen Komponententest, Regressionstest, GUI-Test, Produktion entdeckt? (Verteilung absolut/relativ je Prozess und im Vergleich mit anderen) Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 5-1 Worin lag die Fehlerursache? - Fehlerbehebung Fehlerzahl Komponententest 2 9 Regressionstest GUI-Tests 3 90 GUI-Regressionstests 8 22 Produktion Functionality Checking Interfaces Concurrency Design Produkt TopLogic R3 Datum Checking Functionality Design Concurrency Interfaces Alle Daten sind rein fiktiv! (b) QF 5-2 Worin lag die Fehlerursache? - Art der Behebung Fehlerzahl 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Komponententest Regressionstest GUI-Tests GUI- Regressionstests Prozess Produkt TopLogic R3 Datum unnecessary incorrect missing 2 4 Produktion Alle Daten sind rein fiktiv! Metrik Defect_Type: Klassifikation jedes entdeckten Fehlers nach Art der Korrektur (Art) Skala (angelehnt an ODC/type): Requirements Robustness Functionality 10 Copyright Fraunhofer IESE 2001

19 Design Concurrency Interfaces Ext. comp. Defect_Qualifier: Klassifikation jedes entdeckten Fehlers nach Art der Korrektur (Aktion) Hypothese Bemerkung Skala (angelehnt an ODC/qualifier): Missing Incorrect Out of Scope Frage könnte noch in Unterfragen verfeinert werden: z.b. Verteilung von Impact ohne Fehler mit Qualifier externer Ursache usw. QF 6 Wie waren die in den Prozessen Komponententest, Regressionstest, GUI-Test, Produktion entdeckten Fehler bzgl. des Fehlerorts, d.h. die betroffende Anwendungs-Komponente, d.h. der ursächlichen Produktkomponente verteilt? Objekt Indikator Fehler im Integrationstest: Komponententest, Regressionstest, GUI-Test, GUI-Regressionstest; Produktion QF 6 Wie verteilen sich die Fehler auf Komponenten? GUI 30% User-.Access- Management 2% Reports 17% DataAccess-Layer 6% Sonstige (mit kurzer Angabe) 1% KnowledgeBase 3% Produkt Datum TopLogic R KnowledgeClassification 41% Alle Daten sind rein fiktiv! Metrik Defect_Location Klassifikation jedes entdeckten Fehlers nach der Komponente, in der er behoben wurde. Skala: ContentAssistent Data Access Layer GUI Knowledge Base Other Search Security Wrapper WebDAV Sonstige (mit kurzer Angabe) 11

20 Hypothese Bemerkung Testabdeckung QF 7 Wie hoch ist die Testabdeckung einer einzelnen Anwendungs-Komponente? Unter Testabdeckung versteht man den prozentualen Anteil der mit Testfällen abgedeckten funktionalen Anforderungen. Objekt Indikator Metrik Hypothese Bemerkung Komponente Bei allen Komponenten: Scatter-Plot Test_Coverage Abschätzung insgesamt und für jede Komponente, wie hoch der Grad der Testabdeckung mittels Regressionstests (?) ist. Skala: rational Coverage_Java=(# JUnit Test-classes / # other classes) Coverage_JSP=(#HttpUnit Test-classes / # JSPpages+# Servlet)) Coverage_Java=40% Coverage_JSP=2-3% Fragen zu Einflussfaktoren auf die Qualitätsaspekte (engl. Variation Factor) VF 1 ErfahrungWie groß ist die Erfahrung der Entwickler/Tester im Projektteam? Objekt Indikator Entwickler und Tester Tabelle high medium low Entwickler Tester Metrik Hypothese Experience Abschätzung für jeden Entwickler und Tester, wie hoch die Erfahrung in Bezug auf die Softwareentwicklung und die verwendete Technologie ist. Skala: Principal Senior Junior Je größer die Erfahrung, desto weniger Aufwand für die Fehlerbehebung. 12 Copyright Fraunhofer IESE 2001

21 Je größer die Erfahrung, desto größer die Testabdeckung. Je größer die Erfahrung, desto weniger Fehler im entwickelten Code. Bemerkung Der Aufwand für die Fehlerkorrektur wird nicht absolut erfasst und kann nur grob geschätzt werden (s. QF1) Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. Zeitdruck VF 2 Wie hoch ist der Zeitdruck auf die Entwickler/Tester für die Fertigstellung einzelner Produktkomponenten? Objekt Indikator Metrik Hypothese Entwickler und Tester Bei allen Komponenten: Scatter-Plot Work_Pressure Abschätzung für jede Komponente, wie hoch der Projektdruck für die Entwicklung war. Skala: high normal Je größer der Zeitdruck, desto geringer die Testabdeckung. Je größer der Zeitdruck, desto mehr Fehler im entwickelten Code. Bemerkung Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. Komplexität VF 3 Wie hoch ist die Komplexität einer Klasse/einer Systemkomponente? Objekt Indikator Metrik Hypothese Klasse/Systemkomponente Tabelle; bei allen Komponenten: Scatter-Plot Complexity Abschätzung, wie hoch ihre Komplexität in Bezug auf die Aufgabenstellung im Projekt ist. Skala: high medium low Je höher die Komplexität, desto höher die Fehlerzahl. J höh di K l ität d t h A f d fü di 13

22 Je höher die Komplexität, desto mehr Aufwand für die Fehlerkorrektur. Bemerkung Die vermuteten Zusammenhänge können erst mit Daten von mehreren Projekten überprüft werden. Der Aufwand für die Fehlerkorrektur wird nicht absolut erfasst und kann nur grob geschätzt werden (s. QF1) Die erhobenen Daten werden auch zur Projektcharakterisierung gezählt und werden für die Interpretation der Qualitätsfaktoren hinzugezogen. 14 Copyright Fraunhofer IESE 2001

23 4 Messplan Der Messplan beschreibt welche Metriken erfasst werden, von wem und auf welche Art und Weise die Erfassung geschieht, und wann die Daten erfasst werden. 4.1 Auswahl der zu erfassenden Metriken Alle der in Kapitel 3 aufgeführten Metriken werden erfasst. 4.2 Datenquellen und Messmethode Die benötigten Daten werden von den Projektmitarbeitern geliefert. Allgemeine Informationen werden vom Projektleiter abgefragt, Daten zu Fehlern liefern die Entwickler. Alle Daten werden zunächst mittels Fragebögen auf Papier erfasst. Eine elektronische Datenerfassung wird jedoch mittelfristig angestrebt. Die Datenerfassung erfolgt in englischer Sprache. Entwürfe für die Datenerfassungsfragebögen sind in Anhang A enthalten. 4.3 Planung Datenerfassung Charakterisierung Das Projekt wird vom Projektleiter zu Beginn des Projektes charakterisiert, um den Kontext der Datenerfassung (z.b. allgemeine Einflussfaktoren) festzuhalten. Hierzu ist vom Projektleiter ein Projektcharakterisierungsbogen auszufüllen (s. Abschnitt A.1). Zum Ende des Projekts werden die Daten noch einmal kontrolliert und ggf. aktualisiert. Fehlererfassung Für jeden behobenen Fehler wird vom Entwickler ein Eintrag in einen Fehlererfassungsbogen vorgenommen (s. Abschnitt A.2). Da die meisten Daten erst zum Ende der Fehlerbehebung vorliegen, sollten Eintragen nach einer erfolgreichen Fehlerbehebung erfolgen. Je Entwickler ist ein eigener Fragebogen zu verwenden. Die Fragebögen werden wöchentlich an eine Person weitergeleitet. Die Daten aus den Fragebögen werden in eine einfache Datenbank übertragen, die eine einfach Aggregation und Analyse erlaubt. 15

24 Abbildung 3 Testabdeckung Eingabemaske zur Übertragung der Fragebögen in eine Datenbank (MS Access) Daten, die zur Ermittlung der allgemeinen Testabdeckung dienen, werden wöchentlich beim Build-Prozess automatisch extrahiert und in elektronischer Form weitergegeben. Die Testabdeckung pro Komponente wird einmal pro Monat abgeschätzt Datenanalyse Die Auswertung und Erzeugung aufbereiteter Diagramme erfolgt nach Bedarf, angepasst an Termine für die Interpretation sowie den Projektverlauf. Eine Intervall von mehr als zwei Monaten sollte jedoch nicht überschritten werden. Eine Verfolgung der Datenvollständigkeit und korrektheit wird wöchentlich durchgeführt, um die Validität der erfassten Daten und damit den Erfolg der Messungen insgesamt zu kontrollieren und zu steuern Interpretation der Daten Die Interpretation der Daten im Hinblick auf das Messziel und das Verbesserungsziel. Die Daten werden gemeinsam von den Datenlieferanten (Projektleiter, Entwickler) und dem Stakeholder (hier der Projektleiter) bewertet und interpretiert. Eine Interpretation der Daten erfolgt mindestens einmal nach der Produktfreigabe, sowie zur Kontrolle der Qualität hinsichtlich der in der Betriebsphase entdeckten Fehler zwei Monate (?) nach Produktfreigabe. 16 Copyright Fraunhofer IESE 2001

25 5 Ergebnisse 5.1 Datenerfassung Begleitend zu einem konkreten Projekt zur Erstellung einer Web-Applikation wurden im Zeitraum Mai-August 2002 Daten gemäß des spezifizierten Messplans erfasst. Die Erfassung endete zwei Wochen nach Auslieferung des Produkts. Insgesamt wurden so 115 Fehler erfasst und dokumentiert. Die Daten wurden anhand der spezifizierten Fragen aggregiert und grafisch aufbereitet dargestellt. 5.2 Interpretation der Ergebnisse Die Ergebnisse wurden zweimal, am und am im Projektteam besprochen und interpretiert. Dabei ergaben sich einige interessante Diskussionen in Bezug auf den Entwicklungsprozess und die Qualitätseigenschaften des Produkts. Einige der Ergebnisse sind hier beispielhaft zusammen mit ihrer Interpretation aufgeführt: Vollständigkeit der Datenerfassung Die Vollständigkeit der erfassten Daten wird auf 30-50% geschätzt. Die niedrige Rate wird auf die geringe Zeit im Projekt und den für die Beteiligten ungewohnten Prozessschritt Datenerfassung zurückgeführt. Aufgrund der fehlenden Daten konnten die Werte nicht hinsichtlich absoluter Werte interpretiert werden. Allen Interpretationen liegt die Annahme zugrunde, dass die erfassten 40-50% repräsentativ für alle entdeckten Softwarefehler sind. 17

26 5.2.2 Fehlerschwerpunkte im System QF 6 Wie verteilen sich die Fehler auf Komponenten? Other 18% Search 7% Security 7% WebDAV 3% Wrapper 9% Produkt Datum TopLogic R ContentAssistent 6% Knowledge Base 6% Data Access Layer 8% GUI 36% Auswertung Die konzeptionell und hinsichtlich ihrer Aufgaben unterschiedlichen Systemteile zeigen, dass es Fehlerschwerpunkte gibt. Die Verteilung war keine große Überraschung für das Team, verdeutlichte jedoch auch das Potential, das die systematische Einführung von automatisierten GUI-Tests hat. Die Fehlerverteilung wurde von den Projektmitgliedern ergänzend gegenüber der Größe der Komponenten und der aktuellen Projektsituation (Neuentwicklung/Änderungen) bewertet Einfluss der Testabdeckung von Regressionstests Testabdeckung in Bezug auf mit Regressionstests gefundene Fehler Wrapper 43,75% WebDAV 93% Security Search Other 17% 20% 0 Knowledge Base 23,50% GUI 4% Data Access Layer 30% ContentAssistent 14% 0% 10% 20% 30% 40% 50% 60% 70% Anteil mit Regressionstests gefundener Fehler Testabdeckung [%]: #JUnit# JUnit-Klassen / # andere Klassen Bei der Erstellung von Testklassen spielt die Abwägung von Kosten und Nutzen eine wichtige Rolle. Als mittelfristiges allgemeines Ziel wurde 50% Testabdeckung genannt. In einem Piloten wäre die Effektivität von einer hohen Testabdeckung noch zu prüfen. Aufgrund der in einigen Systemteilen 18 Copyright Fraunhofer IESE 2001

27 wenigen Daten können nicht alle Werte zum Ziehen von Schlüssen herangezogen werden (z.b. WebDAV). Generell sind positive Effekte durch Regressionstests jedoch abzulesen. Es wurde beschlossen, in Zukunft ein anderes Maß für die Testabdeckung zu nutzen, welches nicht auf Klassenebene, sonder auf tatsächlicher Pfadüberdeckung arbeitet (JProbe), da eine hohe Abdeckung auf Test-Klassenebene nur indirekt die tatsächliche Abdeckung annähern kann Fehlerursache QF 2 Was war die Fehlerursache? 3 9 Produkt Datum TopLogic R Design External Component Functionality Requirements Robustness Interfaces Auswertung Der Anteil der Fehler, die auf Robustheit zurückgeführt wurde, wurde als unerwartet hoch angesehen. Gezielte Beachtung von Grenzfällen bei Code- Reviews wurde als Lösungsmöglichkeit genannt Auswirkung der Fehler QF 4 Wie war die Auswirkung der Fehler verteilt? 5% 2% 11% Produkt Datum TopLogic R % 51% --- Functionality No Relevance System/Application Workaround Component 18% Auswertung