prozentualer Defektanteil

(1)

Unternehmensweite Messprogramme

Seminar "Messen und Prüfen von Software", WS 2001/02

erstellt von

Irene Bonomo-Kappeler

Angefertigt am Institut für Informatik der

Universität Zürich

Prof. Dr. M. Glinz Betreuer: Christian Seybold

Aenderungsgeschichte des Dokuments

Version Datum Autor Kommentar

1.0 08.01.2002 Irene Bonomo Erster Entwurf zu Handen der Seminarleitung 1.1 15.01.2002 Irene Bonomo Definitive Version

(2)

Inhaltsverzeichnis

1 Einleitung... 3

1.1 Zum Dokument ... 3

1.2 Die Unternehmung Hewlett Packard (HP) ... 3

1.3 Ausgangslage des Messprogramms... 3

1.3.1Das Produktivitätsframework... 3

1.3.2Prozess- und Produktqualität ... 4

1.3.3Unterstützung ... 4

2 Strategie −−−− 10 Schritte zum Erfolg ... 5

2.1 Schritt 1 − Unternehmens- bzw. Projektziele... 5

2.2 Schritt 2 − Verantwortlichkeiten ... 5

2.3 Schritt 3 − Forschung ... 5

2.3.1Produktivität ... 5

2.3.2Qualität ... 6

2.3.3Aufwandschätzung ... 7

2.3.4Arbeitsumgebung ... 7

2.3.5Kategorien von Software... 8

2.3.6Phasen im Entwicklungsprozess... 8

2.4 Schritt 4 − Erste Messkriterien... 8

2.4.1Grösse ... 8

2.4.2Personal/Zeit/Kosten ... 9

2.4.3Defekte ... 9

2.4.4Schwierigkeit (optional) ... 9

2.4.5Kommunikation (optional) ... 9

2.5 Schritt 5 − Verkauf der ersten Messdaten ... 10

2.5.1Der Faktor Mensch... 10

2.6 Schritt 6 − Werkzeuge... 10

2.7 Schritt 8 − erste Erfolge ... 12

2.7.1Erfolgsgeschichte: Statistische Qualitätssicherung ... 12

2.7.2Erfolgsgeschichte: Probleme im Entwicklungsprozess ... 12

2.7.3Erfolgsgeschichte: Voraussage der Testdauer... 14

2.8 Schritt 9 − eine unternehmensweite Datenbank ... 14

2.8.1Implementierung... 14

2.8.2Verteilung... 15

2.8.3Auswertungsmöglichkeit: Zeitreihen ... 15

2.8.4Auswertungsmöglichkeit: Überprüfung von Schätzungen (Beispiel) ... 15

2.8.5Qualität der Daten... 16

2.8.6Projektspezifische Messungen... 16

2.8.7Vergleiche von Messdaten ... 17

2.9 Schritt 7 − Kurs ... 17

2.10 Schritt 10 − Weiterentwicklung ... 17

3 Blick in die Zukunft ... 18

3.1 Management der Komplexität ... 18

3.2 Die neue Rolle des Projektleiters ... 18

4 Zusammenfassung... 19

4.1 Bilanz nach 3 Jahren ... 19

4.2 Fazit... 19

5 Anhang ... 20

5.1 Glossar... 20

5.2 Verzeichnis aller referenzierten Dokumente ... 20

1 Einleitung

1.1 Zum Dokument

Das Dokument wurde im Rahmen des Seminars "Messen und Prüfen von Software" erstellt und fasst das Buch Software metrics: establishing a company-wide program von R.B. Grady und D.L.

Caswell [GraCas87] zusammen. Die Autoren haben zwischen 1983 und 1986 in der Unternehmung Hewlett Packard (HP) ein unternehmensweites Software-Messprogramm eingeführt und haben dieses Buch geschrieben, um ihre Erfahrungen anderen Unternehmungen zur Verfügung zu stellen.

Kapitel 1 gibt eine Übersicht über die Unternehmung Hewlett Packard, stellt die Motivation für das Messprogramm vor und zeigt verschiedene Voraussetzungen und Randbedingungen auf. Im Kapitel 2 werden das Vorgehen und die Ergebnisse des Messprogramms detailliert beschrieben. Kapitel 3 wagt einen Blick in die Zukunft. Kapitel 4 fasst anschliessend die wichtigsten Erkenntnisse zusammen.

1.2 Die Unternehmung Hewlett Packard (HP)

HP verstand sich zum damaligen Zeitpunkt als Computer- und Instrumente-Hersteller und beschäftigte 85'000 Mitarbeiter, die in 66 Produkt-Divisionen arbeiteten. Die Divisionen wurden als Profit Centers geführt, die sehr selbständig agierten und jeweils über eigene F&E-Abteilungen mit zwischen 40 und 150 Ingenieuren verfügten.

1.3 Ausgangslage des Messprogramms

Das unternehmensweite Messprogramm entstand aus einer Task Force, welche beauftragt wurde, die Software-Qualität und –Produktivität zu verbessern. Diese Task Force schlug vor, a) durch den Einsatz von Werkzeugen kurzfristige und b) durch eine generelle Entwicklungsumgebung langfristige Produktivitäts-Steigerungen zu erzielen. Dies führte zur Gründung des HP Software Engineering Lab (SEL), für das auch die beiden Autoren arbeiteten.

1.3.1 Das Produktivitätsframework

Das Produktivitätsframework stellt die Produktivität, verstanden als Output (Wert) geteilt durch Input (Kosten), und ihre wichtigsten Einflussfaktoren dar, die Kandidaten für Messkriterien sind:

PRODUKTIVITÄT

Kundenbedürfnisse

Komplexität des Problems

Einschränkungen der Umgebung

WERT Schwierigkeit

KOSTEN

Zeit Kapital Personal

Personen- monate Menge Wieder-

verwendbarkeit Qualität

Grösse

Funktionen Elemente Programm-

grösse Defekte

Abbildung 1: Das Produktivitätsframework

(3)

1.3.2 Prozess- und Produktqualität

In den 70er-Jahren des 20. Jahrhunderts war Japan wegweisend, was die Qualitätssicherung der industriellen Produktion betraf. Die Japaner gingen vom Ansatz aus, dass sich die Qualitäts- sicherung nicht nur auf das Produkt an sich, sondern ganz wesentlich auch auf den Prozess zur Erstellung dieses Produkts konzentrieren muss. Mit anderen Worten: Qualität kann nicht nach- träglich in ein Produkt hineingeprüft werden, sondern nur in einem qualitativ hochstehenden Produktionsprozess entstehen.

Diese Idee wurde ins Messprogramm von HP übertragen, das folgerichtig sowohl die Qualität des Software-Erstellungsprozesses als auch die Qualität der Software selbst im Visier hat.

Um einen Prozess zu verbessern, sind 4 Schritte erforderlich. Das HP-Messprogramm konzentierte sich zu Beginn vor allem auf das „Verstehen“:

Ändern Verstehen

Automatisieren Überwachen

Abbildung 2: 4 Schritte zur Prozess-Verbesserung

1.3.3 Unterstützung

Die Autoren gingen davon aus, dass ein unternehmensweites Messprogramm nur mit aktiver Unterstützung des (oberen) Managements realisiert werden kann.

Ausserdem war ihnen klar, dass Menschen grundsätzlich bereit sind, nach Standards zu arbeiten, aber nur, wenn der Standard erreichbar ist, und speziell, wenn sie beim Setzen des Standards beteiligt waren.

2 Strategie −−−− 10 Schritte zum Erfolg

Das unternehmensweite Software-Messprogramm wurde bei HP in den folgenden 10 Schritten umgesetzt, welche anschliessend nicht ganz in der gleichen Reihenfolge mehr oder weniger detailliert ausgeführt werden.

1. Bestimme Unternehmens- bzw. Projektziele für das Messprogramm 2. Ordne die Verantwortlichkeiten zu

3. Untersuche Forschungsergebnisse 4. Definiere erste Messkriterien

5. Verkaufe die ersten erhobenen Messdaten

6. Stelle Werkzeuge für das automatische Sammeln und Analysieren der Messdaten zur Verfügung

7. Biete einen Kurs zur Software-Messung an

8. Veröffentliche Erfolgsgeschichten und fördere den Austausch von Ideen 9. Stelle eine Mess-Datenbank zur Verfügung

10. Schaffe einen kontrollierten Mechanismus, um den Standard weiter zu entwickeln.

2.1 Schritt 1 −−−− Unternehmens- bzw. Projektziele

Im Schritt 1 wurden die Methoden, die verwendet werden sollen, das Kostendach, die Dringlichkeit sowie die Unterstützung durch das Management bestimmt.

2.2 Schritt 2 −−−− Verantwortlichkeiten

Im Schritt 2 wurde die organisatorische Eingliederung der Verantwortung für das Software- Messprogramm bestimmt. Ausserdem wurden Personen rekrutiert, welche mit der Umsetzung der Ziele des Messprogramms betraut wurden.

2.3 Schritt 3 −−−− Forschung

Im Schritt 3 haben die Autoren aufgrund verschiedenster interner und externer Publikationen untersucht, welches der Stand der Forschung in Sachen Software-Messung ist. Ihre Untersuchung konzentrierte sich auf die Kriterien

• Produktivität,

• Qualität und

• Aufwandschätzung.

Folgende Erkenntnisse haben die Autoren aus ihren Untersuchungen gewonnen:

2.3.1 Produktivität

Als Mass für die Produktivität ist Codezeilen pro Personenmonat allgemein anerkannt.

Zwischen Amerika und Japan existieren beträchtliche Produktivitäts-Unterschiede: Während ein amerikanischer Software-Ingenieur im Durchschnitt pro Monat 100 – 500 Codezeilen schreibt, bringt es ein japanischer Software-Ingenieur auf 500 – 800 Codezeilen neuen Code bzw. 2500 – 3100 Zeilen wiederverwendeten Code.

Die Produktivität wird durch die folgenden modernen Programmiertechniken massgeblich positiv beeinflusst:

• top-down Design

• modularer Design

• Design-Reviews

• Code Inspections

• Qualitätssicherungs-Programme

(4)

Auch die Programmiersprache hat einen grossen Einfluss auf die Produktivität: Die Verwendung von Pascal führt beispielsweise zu 1,5- bis 2-mal höherer Produktivität als die Verwendung von Assembler oder C.

Das Produktivitäts-Verhältnis zwischen neuem Code und wiederverwendetem Code liegt bei 1 : 5.

2.3.2 Qualität

Es existiert ein interessanter Zusammenhang zwischen Produktivität und Qualität: qualitativ bessere Software führt automatisch zu Produktivitäts-Gewinnen, da weniger Zeit für Fehlersuche und –behebung erforderlich ist.

Als Mass für die Qualität gilt die Anzahl Defekte. Dabei wird zwischen „prerelease“ und

„postrelease“ Defekten unterschieden.

In Japan wurde mit statistischen Methoden die (zu erwartende) Defektdichte von Software berechnet. Dabei ergab sich eine maximale Defektdichte von 12,2 Defekten pro 1000 Codezeilen, das Minimum wurde erwartungsgemäss bei wiederverwendetem Code erreicht. Eine erste ähnliche Untersuchung bei HP ergab eine Defektdichte von durchschnittlich 8,12 Defekten pro 1000 Codezeilen.

Bei IBM wurden die Defekte nach Phasen, in denen sie entstanden sind, aufgeschlüsselt:

8%

42%

25% 25%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

Analyse Design Implementierung Dokumentation

prozentualer Defektanteil

Abbildung 3: Entstehung von Software-Defekten pro Phase

Eine andere Studie klassifizierte Defekte nach dem Behebungs-Aufwand. Dies ergab folgende Resultate:

Defekt-Anteil Behebungs-Aufwand 68% weniger als eine Stunde

26% zwischen einer Stunde und einem Tag 5% zwischen einem Tag und einer Woche

1% mehr als eine Woche (Maximum: sechs Wochen)

Seminar "Messen und Prüfen von Software", WS 2001/02 Das Verhältnis zwischen Software-Entwicklung und Pflege beträgt:

49%

43%

8%

0% 10% 20% 30% 40% 50% 60%

Pflege Entwicklung Andere

Abbildung 4: Anteil am Softwareentwicklungs-Aufwand

2.3.3 Aufwandschätzung

Drei Schätzmethoden wurden untersucht, welche alle auf der Anzahl Codezeilen basieren, aber auch versuchen, die Art der Software, die Technologie und die Erfahrung der Projektmitarbeiter mit einzubeziehen:

• COCOMO

• SLIM

• COPMO

Die damalige HP-Infrastruktur bestand aus einem Werkzeug namens Softcost, welches anhand der Grösse und der Schwierigkeit eines Projekts Projektaufwand, -zeit und –ressourcen berechnet.

Dabei wird die Schwierigkeit anhand von 45 Faktoren (Stabilität der Anforderungen, Produkt- Komplexität, Erfahrung des Projektteams, Vertrautheit mit der Programmierumgebung etc.) ermittelt.

2.3.4 Arbeitsumgebung

Unter Arbeitsumgebung werden der Arbeitsplatz, die Entwicklungs-Werkzeuge und die Kommunikationshilfsmittel verstanden.

Die Arbeit eines Software-Ingenieurs besteht im wesentlichen zu je ca. einem Drittel aus

• kommunikativen Projektaktivitäten (Sitzungen, Reviews, Diskussionen)

• individuellen Projektaktivitäten (lesen, Code und Dokumentation verfassen) und

• nicht projektspezifische Aktivitäten

für welche ihm eine optimale Umgebung zur Verfügung gestellt werden muss.

Eine Studie von Tom DeMarco und Tim Lister hat gezeigt, dass Produktivitäts-Unterschiede bei Programmierern (im Verhältnis von 5,6 : 1) eng mit der Zufriedenheit mit der Arbeitsumgebung korrelieren.

Was die Kommunikation betrifft, hat eine Untersuchung am MIT gezeigt, dass die Kommunikations-Aktivitäten mit zunehmender physischer Distanz drastisch abnehmen. Dies ist bei der Bildung von Projektteams zu berücksichtigen:

Distanz (m) Reduktion der Kommunikation 25 2/3 50 9/10

(5)

2.3.5 Kategorien von Software

Um vergleichbare Daten zu erhalten, hat HP die Software-Entwicklungsprojekte in 4 Kategorien eingeteilt:

• Firmware: Software für Instrumente und Peripheriegeräte.

• Systemsoftware: Software für Computer, Netzwerk-Software, Sprachen und Datenbanken.

• Applikationen: Software, welche auf der Systemsoftware operiert und Kundenbedürfnisse in einem bestimmten Bereich, z.B. Produktion, Medizin, Finanz etc., erfüllt

• Spezialsoftware: interne Informationssysteme, Testsoftware etc.

2.3.6 Phasen im Entwicklungsprozess

HP hat den Software-Entwicklungsprozess in 4 Phasen mit folgenden Meilensteinen eingeteilt:

• Die Phase Analyse/Spezifikation ist abgeschlossen, wenn die externe Spezifikation (ES) freigegeben ist.

• Die Phase Design ist abgeschlossen, wenn die interne Spezifikation (IS) freigegeben ist.

• Die Phase Implementierung ist abgeschlossen, wenn der Systemtest beginnt.

• Die Phase Test ist abgeschlossen, wenn das Release eingeführt wird.

2.4 Schritt 4 −−−− Erste Messkriterien

Das erste Meeting des Software Metrics Council (mehr davon in Abschnitt 2.10) fand im August 1983 statt und hatte folgendes Ziel:

“To gain agreement on a set of software measurment criteria which managers feel are meaningful, reasonable to collect, and can be used to measure progress and predict results.“

Aus den folgenden Gründen wurde kein bestehendes Messmodell einfach übernommen:

• es konnte kein „bestes“ Modell bestimmt werden

• die Beschränkung auf ein Modell implizierte den Verzicht auf die Vorteile der anderen Modelle

• HP wollte ein eigenes Modell entwickeln

Die Messkriterien, welche aus dem ersten Meeting des Software Metrics Council resultierten, waren die folgenden, und zwar hat man sich ganz bewusst auf eine kleine Anzahl wohldefinierter Messkriterien beschränkt:

2.4.1 Grösse

Wie gross ist die Software, die produziert wird?

Als Standard-Mass für die Grösse wurde die Anzahl Codezeilen (NCSS = noncomment source statements) gewählt. Darin sind auch Compiler-Anweisungen, Daten-Deklarationen und ausführbare Zeilen inbegriffen, nicht aber Kommentar- und Leerzeilen. Nach Möglichkeit soll ein automatischer Zeilenzähler verwendet werden.

Die Rapportierung erfolgte mittels eines Formulars:

Compiler-Anweisungen Daten-Deklarationen ausführbare Zeilen NCSS (Subtotal) Kommentarzeilen Leerzeilen TOTAL ZEILEN

% wiederverwendeter Code

# Prozeduren Objektcode in Bytes

# Zeilen in der Dokumentation

2.4.2 Personal/Zeit/Kosten

Was kostet es an Zeit und Geld, die Software inkl. zugehöriger Dokumentation zu erstellen?

Als Standard-Mass für die Kosten wurde der Personenmonat (engineering month) gewählt. Darin sind auch Überstunden und die Zeit für das Testen inbegriffen, nicht aber Abwesenheiten aufgrund von Ferien und Krankheiten. Ebenfalls nicht inbegriffen sind die Projektmanagement-Aktivitäten.

Die Rapportierung erfolgte mittels eines Formulars, aufgeschlüsselt nach Projektphasen:

Phase Personenmonate Kalendermonate

Analyse / Spezifikation Design

Implementierung Test

Total

2.4.3 Defekte

Wie viele Defekte stecken in der Software?

Das Standard-Mass ist die Anzahl Defekte. Ein Defekt ist eine Abweichung von der Spezifikation oder ein Fehler in der Spezifikation eines Software-Produkts. Darin sind Anforderungen und Schreibfehler nicht enthalten.

Die Rapportierung erfolgte mittels eines Formulars, aufgeschlüsselt nach Projektphasen:

Phase eingefügte Defekte gefundene Defekte korrigierte Defekte Analyse / Spezifikation

Design Implementierung Test

Total

Im ersten Standardisierungs-Schritt werden die Defekte noch nicht nach Schwere unterschieden.

2.4.4 Schwierigkeit (optional) Wie komplex ist die Software?

Das Standard-Mass für die Schwierigkeit ist eine Zahl zwischen 35 (einfach) und 165 (schwierig).

Diese Zahlen ergeben sich aus dem in Abschnitt 2.3.3 erwähnten Werkzeug Softcost.

2.4.5 Kommunikation (optional)

Wie viel Aufwand kostet die Kommunikation mit anderen Einheiten?

Das Standard-Mass für die Kommunikation ist die Anzahl Schnittstellen eines Projektteams zu anderen Organisationseinheiten.

(6)

2.5 Schritt 5 −−−− Verkauf der ersten Messdaten

Natürlich war es ausserordentlich wichtig, das Top Management, die Projektleiter und die Software-Ingenieure vom Nutzen des Messprogramms zu überzeugen, sie zum Mitmachen und zum korrekten Messen zu bewegen.

Zu diesem Zweck startete das Software Engineering Lab eine Verkaufs-Kampagne. Der Software Metrics Council fungierte als Verkaufsorganisation, und das Software Engineering Lab stattete ihn mit dem erforderlichen Verkaufsmaterial und viel Unterstützung aus. Ebenso wurden natürlich auch die ersten ca. 40 Projektleiter (key accounts) unterstützt, welche sich bereit erklärten, beim Mess- programm mitzumachen.

Das Verkaufsmaterial bestand aus:

• einer Management Broschüre für die Leiter der Divisionen, der F&E-Abteilungen und der Qualitätssicherung.

• einem Satz Präsentationsfolien mit folgenden Inhalten:

o Warum den Software-Entwicklungsprozess messen?

o Nutzen der Messdaten für das Top Management o Nutzen der Messdaten für die Projektleiter o Nutzen der Messdaten für die Software-Ingenieure

• Kopien aller Formulare

• Erfolgsgeschichten aus Projekten (reference accounts)

2.5.1 Der Faktor Mensch

Eine der Herausforderungen des Messprogramms war, dass Software-Ingenieure nicht „gemessen“

werden wollen, und zwar aus Angst, dass diese Daten gegen sie verwendet werden könnten.

Daher wurde im Software Metrics Council vereinbart, dass die Messdaten nicht zur Messung der Leistung einzelner Software-Ingenieure, sondern nur ganzer Teams verwendet werden sollen.

Abgesehen davon wurde mehr Wert auf Trends gelegt als auf einmalige absolute Messwerte.

Darüber hinaus wurde auch dem Change Management gebührend Beachtung geschenkt und mittels

„Force-Field Analysis“ die Vor- und Nachteile des Messprogramms aus Sicht der Manager und der Ingenieure gegenübergestellt. Um die Nachteile (Kosten, Zusatzaufwand) zu minimieren, wurden die Formulare möglichst einfach gestaltet, Werkzeuge zur Verfügung gestellt etc.

2.6 Schritt 6 −−−− Werkzeuge

Die meisten primären Messdaten (Grösse, Personenmonate, Defekte) wurden mit Hilfe von Formularen erhoben. Lediglich für die Grösse standen ausserdem für die meisten Systeme und Programmiersprachen Line Counters zur Verfügung.

Für die Analyse und Darstellung der Daten wurde das Tool PM2L (Project Management Metrics Tool) entwickelt, welches eine Schnittstelle zu einem kommerziell verfügbaren Spreadsheet hatte.

Damit konnten z.B. die folgenden Grafiken erzeugt werden, die insbesondere als Grundlage für Aufwandschätzungen Verwendung fanden:

0 500 1000 1500 2000 2500

Firmware Systeme Applikationen Reused

NCSS / Personenmonat

Abbildung 5: Produktivität pro Applikationsklasse (94 Projekte)

0 1 2 3 4 5 6 7 8

Firmware Systeme Applikationen Reused

Defekte / KNCSS

Abbildung 6: „prerelease“ Defektdichte pro Applikationsklasse (77 Projekte)

Unter der Applikationsklasse „Reused“ werden Applikationen zusammengefasst, die aus mehr als 75% wiederverwendetem Code bestehen.

(7)

15%

20%

28%

37%

Analyse/ Spezifikation Design

Implementierung Test

Abbildung 7: Anteil Personenmonate pro Phase (43 Projekte)

2.7 Schritt 8 −−−− erste Erfolge

2.7.1 Erfolgsgeschichte: Statistische Qualitätssicherung Für eine Gruppe von Applikationen wurden die „postrelease“ Defekte nach

A. User Interface / Interaction B. Programme

C. Betriebssystem

gruppiert. Dabei fand man heraus, dass fast 40% der Defekte zur Gruppe A gehörten und Anforderungen an zusätzliche Daten, anders dargestellte Daten und neue/geänderte Funktionen beinhalteten.

Aufgrund dieser Erkenntnisse wurde der Entwicklungsprozess derart umgestaltet, dass Prototyping zum Zuge kam, worauf wohl die selben Defekt-Typen auftraten, jedoch nicht mehr „postrelease“, sondern bereits in der Analyse/Spezifikations-Phase.

2.7.2 Erfolgsgeschichte: Probleme im Entwicklungsprozess

Hier geht es um ein Firmware-Projekt, das ähnlich wie in Abschnitt 2.7.1 beschrieben seine Defekte gruppierte und herausfand, dass die meisten von ihnen im Detail-Design gemacht wurden.

0 10 20 30 40 50 60 70 80 90

Detail-Design Codierung Implementierung Architektur

Anzahl Defekte

Abbildung 8: Anzahl Defekte, grobe Gruppierung

Daraufhin wurden die Defekte des Detail-Design weiter analysiert mit folgendem Ergebnis:

0 5 10 15 20 25 30

Register- Zuweisung

Know How Dokument. Stack Register- Paare

Anzahl Defekte

Abbildung 9: Anzahl Defekte, detaillierte Gruppierung

Um die Ursachen der vielen Register-Zuweisungsfehler zu ermitteln, wurde zusätzlich auf ein sog.

Fishbone-Diagramm (Ursache/Wirkungs-Diagramm) zurückgegriffen, welches zeigt, dass die Hauptursachen Seiten-Effekte bei der Register-Benutzung und nicht korrekte Register-Benutzung waren.

(8)

Register- Zuweisungs-

Defekt Seiten-Effekte der

Register-Benutzung

kein Überblick vorhanden schlechte Dokumentation

Nicht korrekte Register-Benutzung fehlendes

Prozessor-Know How kann nicht

gekapselt werden keine Architektur

Abbildung 10: Ursache/Wirkungs-Diagramm

2.7.3 Erfolgsgeschichte: Voraussage der Testdauer

Ein Firmware-Projekt kannte seine durchschnittliche Produktivität (670 NCSS / Personenmonat) und seine durchschnittliche „prerelease“ Defektdichte (9,6 Defekte / 1000 NCSS). Ausserdem ist über die Behebung von Defekten gem. Henry Kohoutek folgendes bekannt:

Defekt-Anteil Behebungs-Aufwand (Stunden / Defekt) 25% 2

50% 5 20% 10 4% 20 1% 50

Mit Hilfe dieser Daten konnte die Testdauer ziemlich genau bestimmt werden.

2.8 Schritt 9 −−−− eine unternehmensweite Datenbank

Um die gesammelten Messdaten auch benützen zu können, müssen sie in einer unternehmensweiten Datenbank zentral gespeichert werden.

2.8.1 Implementierung

In einem ersten Versuch wurde für das Speichern der Messdaten eine Netzwerk-Datenbank benützt.

Diese Lösung konnte sich aber aufgrund ihrer Inflexibilität nicht durchsetzen.

In einem zweiten Schritt wurde entschieden, eine kommerziell verfügbare Spreadsheet-Software für die Speicherung der Messdaten zu benützen. Dieses Spreadsheet wurde Software Metrics Database (SMDB) genannt. Der Spreadsheet-Ansatz hatte folgende Vorteile...

• Das Spreadsheet ist einfach zu ändern.

• Totale werden automatisch generiert.

• Grafiken können einfach und schnell erzeugt werden.

• Die Spreadsheet-Software war schnell verfügbar.

• Sie war einfach zu bedienen.

...und folgende Nachteile:

• Keine Integration mit anderen Werkzeugen, die Messdaten generieren.

• Läuft lokal auf Personal Computern und erfordert folglich manuelle Verteilung der Daten.

• Erlaubt nur eine beschränkte Datenmenge.

Das Spreadsheet wurde grob folgendermassen aufgebaut:

Projekt-Name monatliche Kosten Kalendermonate Grösse eingefügte Defekte gefundene Defekte korrigierte Defekte Projektinformation Softwareklasse Schwierigkeit Projekt 1

Projekt 2 Projekt 3 ...

2.8.2 Verteilung

Die Verteilung des Spreadsheet warf folgende Probleme auf:

• Anonymität: Sollen die Projektnamen und die Namen der Projektleiter publiziert werden?

Man entschied sich dafür, dass dies jeder Projektleiter selber entscheiden konnte. 95% der Projektnamen und 80% der Namen von Projektleitern konnten publiziert werden.

• Sicherheit: Die Daten dürfen unter keinen Umständen der Konkurrenz in die Hände fallen.

Dass die meisten Projektnamen nichts mit den Produktnamen gemeinsam hatten, entschärfte dieses Problem.

• Übertragungsmedium: Wie werden die Daten verteilt? Hier wurde e-Mail gewählt, teil- weise sogar Diskette.

• Empfängerkreis: Wem soll das Spreadsheet zur Verfügung stehen? Jeder, der Messdaten liefert, bekommt das aktualisierte Spreadsheet innert Wochenfrist zurück. Der Software Metrics Council, die Divisionsmanager und die Projektleiter künftiger Mess-Projekte erhalten es vierteljährlich.

2.8.3 Auswertungsmöglichkeit: Zeitreihen

Mittels dieser Datenbank können folgende Zeitreihen-Auswertungen und Regressions-Analysen über mehrere Projekte gemacht werden:

• Entwicklung der Produktivität (NCSS / Personenmonat)

• Entwicklung der Defektdichte (Defekte / KNCSS)

2.8.4 Auswertungsmöglichkeit: Überprüfung von Schätzungen (Beispiel) Ein Firmware-Projekt verfügt über 3½ Software-Ingenieure.

Aus der Datenbank entnehmen wir, dass

• die Firmware ähnlicher Instrumente im Durchschnitt 30 KNCSS Assembler-Code umfassen.

• die durchschnittliche Produktivität von Firmware-Projekten 400 NCSS / Personenmonat beträgt.

• die durchschnittliche „prerelease“ Defektdichte von Firmware-Projekten 6,5 Defekte / KNCSS beträgt.

• vom Aufwand eines Firmware-Projekts im Durchschnitt 15% auf Analyse, 23,1% auf Design, 38,8% auf Implementierung und 23,1% auf Test entfallen.

(9)

Damit lassen sich, ohne Berücksichtigung der Programmiersprache, die folgenden Schätzungen machen:

• Der Projektaufwand wird 75 Personenmonate betragen (30 KNCSS / 400 NCSS).

• Davon entfallen 11 Personenmonate auf Analyse (15% von 75), 17,4 auf Design, 29 auf Implementierung und 17,5 auf Test.

• Die Projektdauer wird 21,4 Kalendermonate betragen (75 / 3½ ).

• Im Test werden 195 Fehler gefunden (6,5 Defekte/KNCSS * 30 KNCSS)

Berücksichtigt man zusätzlich die Programmiersprache (hier Assembler) fällt die durchschnittliche Produktivität gemäss Datenbank auf 300 NCSS / Personenmonat, wodurch sich der Projektaufwand auf 100 Personenmonate erhöht, was bei diesem Projekt ziemlich genau der Realität entsprach. Je präziser die Datenbank-Abfrage formuliert werden kann, desto genauer werden also die Schätzungen.

Ebenfalls mit Hilfe der Datenbank kann man nach jeder Phase eine zunehmend genaue Schätzung des Restaufwands vornehmen. Man geht vom absoluten Aufwand aller Projekte pro Phase aus und bildet „Aufwand-Multiplikatoren“ für jede Phase. Ein Aufwand-Multiplikator von 6 nach der Analyse-Phase bedeutet z.B. dass der kumulierte Aufwand am Projektende 6-mal so hoch sein wird. Eine Datenbank-Auswertung für Systemsoftware-Projekte ergab folgende Aufwand- Multiplikatoren:

Phase kumulierter Aufwand (Personenmonate)

Aufwand- Multiplikator Analyse/Spezifikation 218 6,01

Design 477 2,75

Implementierung 887 1,48

Test 1310 1

Damit lassen sich aufgrund der eigenen tatsächlichen Aufwände in den ersten Phasen der Rest- aufwand und damit der Totalaufwand schätzen.

Ein Qualitätsmass für Schätzungen ist der Estimating Quality Factor (EQF) von Tom DeMarco.

Der EQF entspricht dem Verhältnis – bei mehrmaligen Schätzungen – zwischen den tatsächlichen Aufwänden und dem Schätzfehlern, d.h. eine Schätzung war umso besser, je höher der EQF ist.

Während der EQF durchschnittlich bei 3,8 liegt, ist es einer Division bei HP gelungen, ihn mit Hilfe der oben erwähnten Methoden auf 10,39 zu erhöhen.

2.8.5 Qualität der Daten

Die Daten wurden natürlich bis zu einem gewissen Grad validiert, bevor sie in die Datenbank eingetragen wurden (Ausreisser, auffällig runde Zahlen). Gewarnt wird vor einer Überinterpretation von Auswertungen, die aufgrund von ganz wenigen Projekten entstehen, was zu Beginn des Messprogramms natürlich nicht zu vermeiden war. Ebenso ist es wichtig, die einer Schätzung zugrundeliegenden Annahmen genau zu prüfen.

2.8.6 Projektspezifische Messungen

Wenn Projekte von sich aus Messgrössen definieren wollen, ist es wichtig, sich zu fragen:

• Wozu wollen wir Daten sammeln?

• Welche Art von Daten wollen wir sammeln?

• Wie wollen wir sie sammeln?

• Wer soll die Daten sammeln?

• Wie sollen die Daten dargestellt werden?

• Welche Entscheidungen sollen aufgrund dieser Daten gefällt werden?

Am besten benützt man an ein anerkanntes Sofware-Qualitätsmodell als Grundlage und klassiert die Messgrössen nach Wichtigkeit und Machbarkeit. HP hat dafür ein Qualitätsmodell namens FURPS (Functionality, Usability, Reliability, Performance and Supportability) geschaffen.

2.8.7 Vergleiche von Messdaten

Natürlich wäre es erstrebenswert gewesen, die erhobenen Messdaten unternehmens-übergreifend vergleichen zu können, doch fehlten dafür die Standards, beispielsweise ein Standard dafür, wie die Programmgrösse (salopp Lines of Code) genau zu bestimmen ist, was genau als Fehler zählt etc.

2.9 Schritt 7 −−−− Kurs

In einem ersten Versuch wurde ein Kurs lanciert, der zwei halbe Tage dauerte und eine Präsentation des Messprogramms und Erfahrungsberichte umfasste. Leider konnten die Teilnehmer keine praktischen Erfahrungen machen, so dass der Kurs neu konzipiert werden musste.

Der definitive Kurs dauerte drei halbe Tage und bestand aus einer Mischung von Frontalunterricht, Übungen und Diskussion und wurde von einer Fallstudie begleitet. Inhaltlich wurden neben dem HP-Messprogramm insbesondere COCOMO, Softcost (vgl. Abschnitt 2.3.3), die Komplexitäts- masse von Halstead und McCabe sowie das Kohoutek-Modell für die Schätzung der Testzeit (vgl.

Abschnitt 2.7.3) behandelt.

Im ersten Jahr wurde der Kurs 8-mal angeboten, von 110 Projektleitern und Software-Ingenieuren besucht und mit einer Note von 4,8 (von max. 6) bewertet.

2.10 Schritt 10 −−−− Weiterentwicklung

Bei der Weiterentwicklung des Messprogramms spielte der Software Metrics Council eine entscheidende Rolle.

Der Software Metrics Council ist ein (Steuerungs-)Gremium von 20 Managern und Entwicklern aus 13 Divisionen, welche aufgrund ihrer Erfahrung in Entwicklung, Management oder Messung bzw.

aufgrund ihres Einflusses ausgewählt wurden. Sie repräsentieren 75% der Software-Entwickler.

Die Aufgabe des Software Metrics Council ist die Identifikation von Schlüssel-Messgrössen, welche als Grundlage für die Verbesserung des Software-Entwicklungsprozesses dienen können.

Dies umfasst folgende Verantwortlichkeiten:

• oberste Instanz für die Änderung und Freigabe von Standards für Software-Messgrössen

• Forschung und interne Publikation von Informationen und Resultaten

• Begeisterung und Verkauf der Konzepte des Messprogramms

• aktive Beteiligung an den Aktivitäten zur Verbesserung des Software-Entwicklungs- prozesses in der eigenen Division

Der Software Metrics Council tagt zweimal jährlich, einmal für 3 Tage und einmal für 1 Tag.

Daneben ist das Software Engineering Lab als operative Einheit für das Tagesgeschäft zuständig, es studiert Literatur und hält die Mitglieder des Gremiums auf dem Laufenden.

An den während der ersten drei Jahre von 1983 – 1986 stattgefundenen Sitzungen beschäftigte sich der Software Metrics Council mit

• Datenerfassungs-Formularen und Review der erhaltenen Daten

• Überarbeitung der Messgrössen und Management Graphiken

• Aufgaben und Verantwortlichkeiten der Mitglieder

• Standard-Kategorien von Fehlern und der Faktor Mensch

(10)

3 Blick in die Zukunft

3.1 Management der Komplexität

Die Komplexität wurde in den ersten drei Jahren des HP-Messprogramms stiefmütterlich behandelt.

Da die Software-Entwicklung aufgrund der User Interfaces und der vielen Schnittstellen immer komplexer wird, wird hier ein zusätzlicher Effort notwendig sein. Die Komplexität wird in 4 Typen aufgeteilt:

• Inhärente Komplexität: grundlegende Eigenschaft eines Problems, eine komplexere Lösung zu erfordern als ein anderes Problem.

• Unnötige Komplexität: Komplexität in einem Software-Produkt, welche nicht inhärent ist.

• Psychologische Komplexität: Komplexität, welche aufgrund der Darstellung eines Produkts entsteht und weder inhärent noch unnötig ist, z.B. komplizierte Spezifikationen in Prosa.

• Kommunikations-Komplexität: Komplexität, welche durch die Anzahl beteiligter Personen oder die Art der Kommunikation verursacht wird.

Zuerst wird ein neuer Software-Entwicklungsprozess vorgeschlagen. Er besteht aus den bekannten 4 Phasen, die neu als Transformationen betrachtet werden, zwischen denen klar definierte, messbare Ergebnisse fliessen. Um die psychologische Komplexität zu reduzieren, sollen diese Ergebnisse (User Interfaces, Datenflussmodelle, Zustandsdiagramme, Hierarchische Strukturen etc.) wenn möglich mittels Grafiken dargestellt werden.

Von den Werkzeugen wird gefordert, dass sie einerseits untereinander durch Schnittstellen verbunden sind und anderseits automatisch Messdaten generieren, wie z.B.

• Anzahl Datenelemente, Anzahl primitive Prozesse bei Datenflussmodellen

• Anzahl Module, Anzahl Datenelemente bei hierarchischen Strukturen

• Anzahl Zweige, Prozeduren, Variablen, Komplexitätsmasse bei Pseudo-Code

• NCSS, Kommentar in %, Komplexitätsmasse bei Source Code

Die Mess-Datenbank soll mit einem Alarmsystem ausgestattet sein, das automatisch eine e-Mail- Meldung an den Projektleiter auslöst, wenn bei einer bestimmten Messgrösse ein bestimmter Schwellwert unter- oder überschritten wird. Damit können inhärente oder unnötige Komplexität identifiziert werden.

Die Kommunikations-Komplexität kann minimiert werden, in dem in jedem Projekt von Beginn weg die Verantwortlichkeiten klar verteilt werden.

3.2 Die neue Rolle des Projektleiters

Die Aufgaben des Projektleiters werden gruppiert nach:

• Analyse-Aufgaben

o Projekt-Definition: Standards und Konventionen, Qualitätsplanung, Entwicklungs- umgebung, Ausbildung, Metriken, etc.

o Schätzung und Planung

• Entwicklungs-Aufgaben

o Projektsteuerung: Versions- und Konfigurationsmanagement, Namens- konventionen, Qualitätssicherung, etc.

o Projektverfolgung: Berichtswesen, Rapporte

Für diese Aufgaben soll dem Projektleiter ein Entscheidungs-Unterstützungssystem zur Verfügung gestellt werden, welches ihm hilft diese Aufgaben zu bewältigen.

4 Zusammenfassung

4.1 Bilanz nach 3 Jahren

Die von Anfang an involvierten Projektleiter und Software-Ingenieure schienen sich an das Messen gewöhnt zu haben und betrachteten es als Teil ihrer täglichen Arbeit.

Nach drei Jahren war es natürlich noch zu früh, abschliessend Bilanz zu ziehen, doch positive Trends waren erkennbar:

• Die durchschnittliche Produktivität konnte gesteigert werden, von ca. 400 NCSS / Personenmonat auf ca. 600 (mit neuem Code) bzw. 700 (mit wiederverwendetem Code).

Die Daten stammen von immerhin 93 Projekten.

• Die durchschnittliche Defektdichte konnte gesenkt werden, von ca. 8 Defekten / KNCSS auf ca. 6 (mit neuem Code) bzw. 4 (mit wiederverwendetem Code). Die Daten stammen von 78 Projekten.

Was hätte man besser machen können?

• Die Messgrössen im Bereich der Qualität haben am meisten gebracht, also hätten man sich von Beginn weg mehr auf die Qualität konzentrieren und mehr Standards vorgeben können.

• Man hätte mehr tun sollen, um früher geeignete Werkzeuge zur Verfügung zu stellen.

• Man hätte mehr für die Messung von Maintenance-Projekten tun sollen.

4.2 Fazit

Software-Messgrössen helfen mit,

• den Software-Entwicklungsprozess besser zu verstehen,

• den Projektfortschritt zu messen,

• eine gemeinsame Terminologie zu schaffen,

• komplexe Software-Teile zu identifizieren,

• das Management von Software-Projekten objektiver zu machen,

• bessere Schätzungen zu machen,

• die eigene Wettbewerbsposition besser zu beurteilen,

• zu verstehen, weshalb Automatisierung notwendig ist,

• Methoden zu finden, welche zu höherer Qualität und Produktivität führen,

• kritische Entscheidungen früher im Entwicklungsprozess zu fällen,

• grundlegende Ursachen von Defekten zu finden.

(11)

5 Anhang 5.1 Glossar

Stichwort Erklärung

Defekt Abweichung von der Spezifikation oder ein Fehler in der Spezifikation eines Software-Produkts, englisch defect

EQF Estimation Quality Factor

F&E Forschung und Entwicklung, englisch R&D

FURPS Functionality, Usability, Reliability, Performance and Supportability

HP Hewlett Packard

KNCSS kilo noncomment source statements NCSS noncomment source statements PM2L Project Management Metrics Tool SEL Software Engineering Lab

SMDB Software Metrics Database

5.2 Verzeichnis aller referenzierten Dokumente

[GraCas87] Grady, R.B. and Caswell D.L. (1987). Software metrics : establishing a company- wide program. Englewood Cliffs, N.J.: Prentice-Hall