Richtlinie: Metriken
Dieser Richtlinie erläutert die Prinzipien, auf denen die Erfassung von Metriken aufbaut und zeigt einige Beispiele für wertvolle Metriken.
Beziehungen
Hauptbeschreibung

Prinzipien

  • Metriken müssen einfach, objektiv, leicht zu erheben, einfach zu interpretieren und schwer zu missinterpretieren sein.
  • Die Erfassung der Metriken muss automatisiert und entkoppelt sein, d. h. sie darf sich nicht auf die Aktivitäten der Entwickler auswirken.
  • Metriken müssen schon früh im Lebenszyklus zur Qualitätsbewertung beitragen, während die Bemühungen zur Qualitätssteigerung von Software noch effektiv sind.
  • Absolute Metriken und Trends müssen aktiv vom Management- und Entwicklungspersonal zur Kommunikation von Fortschritt und Qualität in einem einheitlichen Format verwendet werden.
  • Die Entscheidung zwischen einer minimalen und einer umfassenderen Metrikmenge hängt von der Art des Projekts und seinem Umfeld ab. Bei großen Projekten oder solchen mit zwingenden Sicherheits- bzw. Verfügbarkeitsanforderungen kann es hilfreich sein, technische Metriken zu erfassen und zu analysieren, sofern sich sowohl Entwicklerteam als auch Bewertungsteam mit Metriken auskennt. Möglicherweise erfordert der Liefervertrag die Erfassung bestimmter Metriken, oder die Organisation versucht, ihre Fähigkeiten und Prozesse in bestimmten Bereichen zu verbessern. Um allen Umständen gerecht zu werden, gibt es keine einfache Antwort. Der Projektleiter muss das Passende auswählen, wenn der Bewertungsplan festgelegt wird. Wenn Sie zum ersten Mal ein Messprogramm einführen, ist es sinnvoll, es eher einfach zu halten.

Taxonomie der Metriken

Beispiele für Metriken, die verschiedene Aspekte des Projekts zeigen:

  • Fortschritt anhand von Komplexität und Größe
  • Stabilität anhand der Änderungsrate bei Anforderungen oder Implementierung, Größe oder Komplexität
  • Modularität anhand der Reichweite der Änderung
  • Qualität anhand der Anzahl sowie Art der Fehler
  • Reife anhand der Fehlerhäufigkeit
  • Ressourcen anhand einer Gegenüberstellung von tatsächlichem Aufwand und geplantem Aufwand für das Projekt

Trends sind wichtig und sogar wichtiger als die Überwachung von absoluten Metriken zu bestimmten Zeiten.

Metrik Zweck Beispielmessung/Perspektiven
Fortschritt Iterationsplanung
Vollständigkeit
  • Anzahl der Klassen
  • SLOC (Anzahl der Quellcodezeilen)
  • Funktionspunkte
  • Szenarios
  • Testfälle

Diese Messwerte können auch pro Klasse und pro Paket erhoben werden.

  • Überarbeitungsaufwand pro Iteration (Anzahl der Klassen)
Stabilität Konvergenz
  • Anzahl und Typ der Änderungen (Gegenüberstellung von Programmfehlern und Verbesserungen sowie von Schnittstelle und Implementierung)

Diese Messwerte können auch pro Klasse und pro Paket erhoben werden.

  • Überarbeitungsaufwand pro Iteration
Anpassungsfähigkeit Konvergenz
"Softwareüberarbeitung"
  • Durchschnittliche Mannstunden pro Änderung

Diese Messwerte können auch pro Klasse und pro Paket erhoben werden.

Modularität Konvergenz
"Softwareausschuss"
  • Anzahl der modifizierten Klassen/Kategorien pro Änderung

Diese Messwerte können auch pro Iteration erhoben werden.

Qualität Iterationsplanung
Überarbeitungsindikator
Release-Kriterium
  • Anzahl der Fehler
  • Mangelerkennungsquote
  • Mängeldichte
  • Vererbungstiefe
  • Klassenkopplung
  • Umfang der Schnittstelle (Anzahl der Operationen)
  • Anzahl der überschriebenen Methoden
  • Methodengröße

Diese Messwerte können auch pro Klasse und pro Paket erhoben werden.

Reife Testabdeckung/-eignung
Leistungsfähigkeit bei Verwendung
  • Teststunden pro Fehler und Fehlertyp

Diese Messwerte können auch pro Klasse und pro Paket erhoben werden.

Ausgabenprofil Finanzieller Einblick in
das Verhältnis von Planung und Realität
  • Manntage pro Klasse
  • Vollzeitpersonal pro Monat
  • Budgetverbrauch in %

Minimale Gruppe von Metriken

Selbst die kleinsten Projekte brauchen eine Fortschrittskontrolle, um festzustellen, ob das Projekt im Zeitplan und im Budget liegt, und falls nicht, ob eine Neukalkulation durchgeführt und der Rahmen gegebenenfalls angepasst werden muss. Die folgende minimale Liste ist deshalb auf die Fortschrittskontrolle ausgerichtet.

  • Fertigstellungswert. Der Fertigstellungswert wird verwendet, um Zeitplan und Budget für den Rest des Projekts neu zu kalkulieren und/oder festzustellen, ob der Projektrahmen geändert werden muss.
  • Mängeltrends. Mängeltrends werden verwendet, um den Aufwand vorherzusagen, der für die Abarbeitung der Mängelliste erforderlich ist.
  • Testfortschrittstrend. Anhand von Testfortschrittstrends kann festgestellt werden, wie viel der Funktionalität bereits fertiggestellt ist.

Diese Metriken werden im Folgenden detaillierter beschrieben.

Fertigstellungswert

Die gebräuchliste Methode ([PMI96]) für die Messung des Fortschritts ist die Fertigstellungswertanalyse.

Der einfachste Weg, den Fertigstellungswert zu ermitteln, besteht darin, die Summe der ursprünglich geschätzten Aufwände für alle fertig gestellten Aufgaben zu bilden. Der Prozentsatz der Fertigstellung kann für das Projekt kann berechnet werden, indem der Fertigstellungswert durch den ursprünglich geschätzten Gesamtaufwand für das Projekt geteilt wird. Die Produktivität (bzw. der Leistungsindex) ist der Fertigstellungswert geteilt durch den tatsächlichen Aufwand für die fertig gestellten Aufgaben.

Nehmen Sie beispielsweise an, der Codierungsaufwand wurde auf mehrere Aufgaben verteilt, von denen viele bereits fertig gestellt sind. Die ursprüngliche Schätzung für die bereits fertig gestellten Aufgaben betrug 30 Tage Aufwand. Der Gesamtaufwand für das Projekt wurde auf 100 Tage geschätzt, so dass davon ausgegangen werden kann, dass das Projekt zu rund 30 % fertig gestellt ist.

Graph des Fertigstellungswertfortschritts

Angenommen, die Aufgaben wurden in nur 25 Tage fertig stellt, d. h. das Budget wurde unterschritten. Somit ergibt sich ein Leistungsindex von 30:25 = 1,2 bzw. 120 %.
Jetzt können Sie hochrechnen, dass das Projekt die geschätzte Fertigungsstellungsdauer um 20 % unterschreitet, und ihre Schätzungen entsprechend anpassen.

Hinweise
  • Der Leistungsindex darf nur verwendet werden, um Schätzungen für ähnliche Aufgaben anzupassen. Eine frühe Fertigstellung von Aufgaben im Bereich der Anforderungserfassung deutet nicht darauf hin, dass die Codierung schneller abgeschlossen sein wird. Deshalb berechnen Sie den Leistungsindex nur für ähnliche Aufgabenarten und passen die Schätzungen nur für ähnliche Aufgaben an.
  • Ziehen Sie auch andere Faktoren in Betracht. Werden zukünftige Aufgaben von ähnlich ausgebildetem Personal unter ähnlichen Bedingungen ausgeführt? Sind die Daten durch Aufgaben, die erheblich über- oder unterbewertet wurden, verwässert? Wurden Arbeitszeiten einheitlich berichtet (beispielsweise sollten Überstunden auch dann angegeben werden, wenn sie nicht bezahlt werden)?
  • Werden Schätzungen für neue Aufgaben bereits im Leistungsindex berücksichtigt? Wenn ja, liegen die Schätzungen für neue Aufgaben tendenziell näher am Ziel und verschieben Leistungsindex damit näher an die 100 %. Sie sollten entweder alle noch nicht fertig gestellten Aufgaben neu kalkulieren oder das folgende Verfahren aus Extreme Programming anwenden [JEF01]. Bezeichnen Sie die ursprünglichen Schätzungen als "Punkte" und messen Sie neue Aufgaben in denselben "Punkteinheiten", ohne die tatsächliche Leistung anzupassen. Der Vorteil der "Punkte" liegt darin, dass Verbesserungen (oder Verschlechterungen) in der Leistung verfolgt werden können ("Projektgeschwindigkeit" in der XP-Terminologie).

Wenn Aufgaben umfangreich sind (länger als 5 Tage) oder es eine Menge von Aufgaben gibt, die teilweise fertig gestellt sind, möchten Sie sie möglicherweise in Ihrer Analyse berücksichtigen. Fügen Sie einen subjektiven "Prozentsatz für Fertigstellung" hinzu und multiplizieren Sie diesen mit dem geschätzten Aufwand für die Aufgabe. Fügen Sie diesen Wert dem Fertigstellungswert hinzu. Wenn Sie klare Regeln für die Zuordnung des Prozentsatzes für Fertigstellung haben, werden die Ergebnisse konsistenter. Beispielsweise könnte eine Regel festlegen, dass eine Codierungsaufgabe, in der noch keine Codeprüfung durchgeführt wurde, keinen höheren Fertigstellungsgrad haben kann als 80 %.

Weitere Informationen zum Fertigstellungswert finden Sie im Abschnitt Vollständige Gruppe von Metriken: Projektplan.

Mängeltrend

Oft ist es hilfreich, den Trend der offenen und der geschlossenen Mängel zu verfolgen. Dadurch erhalten Sie ein grobes Indiz dafür, ob die Mängelbehebungsarbeiten signifikant im Rückstand sind und wie schnell Mängel geschlossen werden.

Graph für Mängeltrend

Mängeltrends sind nur eine der in Rational ProjectConsole angebotenen Metriken.

Hinweise
  • Egal ob sie eine Codezeile betreffen oder ein komplettes Neudesign erfordern, Änderungsanfragen sollten nicht alle dieselbe Gewichtung erhalten. Dies wird durch Anwendung einiger der folgenden Techniken erreicht:
    • Achten Sie auf "Ausreißer". Änderungsanfragen, die erhebliche Arbeit erfordern, sollten als solche gekennzeichnet und als separate Aufgaben verfolgt werden. Sie sollten nicht zusammen mit den allgemeinen Programmkorrekturen in einen Topf geworfen werden. Falls viele kleine Korrekturen den Trend beherrschen, ziehen Sie eine Gruppierung in Betracht, so dass jede Änderungsanfrage eine konsistente Arbeitseinheit darstellt.
    • Sie können auch weitere Informationen aufzeichnen, beispielsweise eine subjektive "Aufwandskategorie" wie "weniger als 1 Tag", "1 Tag", "weniger als 5 Tage" oder "mehr als 5 Tage".
    • Sie können auch die geschätzte Quellcodezeilenzahl zusammen mit der tatsächlichen Quellcodezeilenzahl pro Änderungsanfrage aufzeichnen. Weitere Informationen finden Sie im Abschnitt Kleine Gruppe von Metriken.
  • Wenn zuwenig Mängel aufgezeichnet werden, kann dies ein Hinweis darauf sein, dass zuwenig getestet wird. Achten Sie auf den Aufwand, der in die Tests gesteckt wurde, wenn Sie Mängeltrends auswerten.

Testfortschrittstrend

Der ultimative Messwert für die Vollständigkeit ist die Menge der integrierten Funktionalität.
Wenn alle Ihre Entwicklungsaufgaben eine Gruppe integrierter Funktionalität darstellen, könnte ein Trenddiagramm zum Fertigstellungswert ausreichend sein.

Der Testfortschrittstrend ist eine einfache Möglichkeit, den Fortschritt zu kommunizieren.

Graph für den Fortschritt des Abnahmetests

Hinweise
Einige Testfälle können einen wesentlich höheren Wert als andere haben oder einen höheren Aufwand als andere bedeuten. Interpretieren Sie nicht zu viel in diesen Graphen hinein. Er bietet lediglich eine gewisse Sicherheit dafür, dass es einen Fortschritt in Richtung vollständiger Funktionalität gibt.

Kleine Gruppe von Metriken

Die vorher beschriebene minimale Gruppe von Metriken ist für viele Projekte nicht ausreichend.

Software Project Management, a Unified framework [ROY98] empfiehlt die folgenden Metriken für alle Projekte. Beachten Sie, dass diese Metriken die geschätzte und die tatsächliche Quellcodezeilenzahl für jede Änderungsanfrage erfordern, deren Erhebung einen gewissen Zusatzaufwand erforderlich macht.

Metriken und Basismetriken

Gesamt-SLOC SLOCt = Geschätzte Gesamtgröße des Codes. Diese kann sich erheblich ändern, wenn die Anforderungen besser verstanden und die Designlösungen weiter ausgereift sind. Wiederverwendete Software, die vom Team angepasst wird, muss mit eingerechnet werden.
SLOC unter
Konfigurationssteuerung
SLOCc = Aktuelle Referenzversion
Kritische Mängel SCO0 = Anzahl der SCOs vom Typ 0 (SCO steht für Software Change Order, Softwareänderungsauftrag, ein anderer Begriff für Änderungsanfrage)
Normale Mängel SCO1 = Anzahl der SCOs vom Typ 1
Verbesserungsvorschläge SCO2 = Anzahl der SCOs vom Typ 2
Neue Features SCO3 = Anzahl der SCOs vom Typ 3
Anzahl der SCOs N = SCO0 + SCO1 + SCO2
Noch zu erledigende Nacharbeiten (Schadhaftigkeit) B = kumulierte schadhafte Quellcodezeilen der aktuellen Referenzversion entsprechend SCO1 und SCO2
Fertig gestellte Nacharbeiten (Fixes) F = Kumulierte reparierte Quellcodezeilen der aktuellen Referenzversion
Nacharbeitungsaufwand E = Kumulierter Aufwand für Behebung von SCOs der Typen 0, 1 und 2
Verwendungsdauer (UT, Usage Time) UT = Anzahl der Stunden, die eine bestimmte Referenzversion unter realistischen Anwendungsszenarios betrieben wurde

Qualitätsmetriken für das Endprodukt

Aus diesen wenigen Metriken können einige interessantere Metriken abgeleitet werden:

Ausschussverhältnis B/SLOCt, verworfene Menge des Produkts in Prozent
Nacharbeitungsverhältnis E/Gesamtaufwand, Nacharbeitungsaufwand in Prozent
Modularität B/N, durchschnittliche Schadhaftigkeit pro SCO
Anpassungsfähigkeit E/N, durchschnittlicher Aufwand pro SCO
Reife UT/(SCO0 + SCO1), durchschnittliche Zeit zwischen Mängeln
Wartungsfreundlichkeit (Ausschussverhältnis)/(Nacharbeitungsverhältnis), Produktivität der Pflege

Fortschrittsindikatoren

Stabilität der Nacharbeiten B - F, Schäden gegenüber Fixes über der Zeit
Nacharbeitungsrückstand (B-F)/SLOCc, derzeit noch zu erledigende Nacharbeiten
Modularitätstrend Modularität über der Zeit
Anpassungsfähigkeitstrend Anpassungsfähigkeit über der Zeit
Reifetrend Reife über der Zeit

Vollständig Gruppe von Metriken

Was soll gemessen werden? Seitenanfang

Im Folgenden sind die Dinge aufgelistet, die gemessen werden sollten:

  • Prozess - Die Reihenfolge der Aufgaben, die ausgeführt werden müssen, um das Softwareprodukt (und andere Arbeitsergebnisse) zu produzieren.
  • Produkt - Die Arbeitsergebnisse des Prozesses einschließlich Software, Dokumenten und Modellen.
  • Projekt - Die Gesamtheit aller Projektressourcen, Aufgaben und Arbeitsergebnisse.
  • Ressourcen - Die Menschen, Methoden und Werkzeuge, die Zeit, der Aufwand und das Budget, die dem Projekt zur Verfügung stehen.

Prozess

Um den Prozess vollständig zu charakterisieren, sollten die Messungen auf der niedrigsten Ebene einer formal geplanten Aufgabe vorgenommen werden. Aufgaben werden vom Projektleiter auf der Basis einer ersten Gruppe von Schätzungen geplant. Die tatsächlichen Werte und die aktualisierten Schätzungen müssen dokumentiert werden.

Metriken

Kommentare

Dauer Für eine Aufgabe verbrauchte Zeit.
Aufwand Aufwandseinheiten der Mitarbeiter (Mitarbeiterstunden, Mitarbeitertage...)
Ausgabe Arbeitsergebnisse und ihre Größe und Menge (Beachten Sie, dass dies Mängel als Ausgabe von Testaktivitäten einschließt).
Nutzung der Entwicklungsumgebung für Software - CPU, Speicher, Softwaretools, Ausstattung (Workstations, PCs), Verbrauchsmaterial. Beachten Sie, dass dies durch die SEEA (Software Engineering Environment Authority) eines Projekts erfasst werden kann.
Mängel, Erkennungsrate, Korrekturrate Die Summe aus Zeit/Aufwand für Korrekturen und die Summe aus Ausschuss/Nacharbeiten (sofern dies gemessen werden kann) müssen ebenfalls erfasst werden. Dies wird wahrscheinlich aus Informationen, die aus den Mängeln (die in dem Fall als Arbeitsergebnisse betrachtet werden) stammen, abgeleitet.
Änderungsanfragen, Mehrarbeitsrate, Vernichtungsrate Hier gilt dasselbe wie für Zeit/Aufwand.
Andere Störungen, die Einfluss auf diese Metriken haben (freier Text). - Dies ist insofern eine Metrik, als es sich um eine Aufzeichnung eines Ereignisses handelt, das den Prozess beeinflusst hat.
Mitarbeiterzahlen, Profile (über der Zeit) und Eigenschaften
Mitarbeiterfluktuation Eine hilfreiche Metrik, die bei einer "Post-Mortem"-Betrachtung erklären kann, warum sich ein Prozess gut oder schlecht entwickelt hat.
Aufwandseinsatz Die Art und Weise, in der Aufwand für die Durchführung der geplanten Aktivitäten verteilt wird (gegenüber der Zeit, die formal für die Kostenabrechnung angefallen ist), kann helfen, die Varianz in der Produktivität zu erklären. Einige Unterklassen des Aufwandseinsatzes sind beispielsweise:
  • Training
  • Einarbeitung
  • Management (beispielsweise durch Teamleiter)
  • Administration
  • Recherche
  • Produktive Arbeit - Es ist hilfreich, dies pro Arbeitsergebnis aufzuzeichnen und zu versuchen, die "Denkzeiten" von den Eingabezeiten, vor allem bei Dokumenten, zu trennen. Daran kann der Projektleiter erkennen, wie viel Zeit ein Entwickler für Dokumentationszwecke aufgebracht hat.
  • Verlorene Zeit
  • Besprechungen
  • Untersuchungen, Walkthroughs, Prüfungen - Aufwand für Vorbereitungen und Besprechungen (einige der genannten Unterklassen können auch separate Aktivitäten sein, deren Zeit und Aufwand gegen eine spezielle Prüfaufgabe gebucht werden)
Untersuchungen, Walkthroughs, Prüfungen (während einer Aufgabe und nicht in getrennt geplanten Prüfungen) Zeichnen Sie die Anzahl und die Dauer sowie die Anzahl der gefundenen Probleme auf.
Prozessabweichungen (als Verstöße gegen die Konformität erhoben, die eine Projektänderung erfordern) Zeichnen Sie die Anzahl sowie ihre Tragweite auf. Dies kann ein Indikator dafür sein, dass mehr Ausbildung erforderlich ist, der falsche Prozess angewendet wird oder die Art und Weise, wie der Prozess konfiguriert wurde, fehlerhaft ist.
Prozessprobleme (als Prozessmängel erhoben, die eine Prozessänderung erfordern) Zeichnen Sie die Anzahl sowie ihre Tragweite auf. Dies kann bei Post-Mortem-Prüfungen hilfreich sein und sorgt für einen grundlegenden Informationsrückfluss an die SEPA (Software Engineering Process Authority).

Produkt

Die Produkte in Rational Unified Process (RUP) sind die Arbeitsergebnisse, d. h. Dokumente, Modelle oder Modellelemente. Die Modelle sind Sammlungen von Elementen, die Dinge darstellen, (die Modellelemente). Die empfohlenen Metriken werden hier zusammen mit den Modellen aufgeführt, zu denen sie gehören. Für gewöhnlich ist es offensichtlich, ob sich eine Metrik auf ein vollständiges Modell oder auf ein Element bezieht. In den Fällen, bei denen dies nicht klar ist, wird erläuternder Text bereitgestellt.

Merkmale von Arbeitsergebnissen

Im Allgemeinen sind bei Messungen die folgenden Merkmale von Interesse:

  • Größe - Gibt die Anzahl der Elemente in einem Modell, die Länge, die Ausdehnung oder die Masse von etwas an.
  • Qualität
    • Mängel - Gibt Hinweise darauf, dass sich ein Arbeitsergebnis nicht verhält wie erwartet, nicht seiner Spezifikation entspricht oder andere unerwünschte Merkmale aufweist.
    • Komplexität - Eine Messung für die Komplexität einer Struktur oder eines Algorithmus. Je höher die Komplexität ist, desto schwieriger ist es eine Struktur zu verstehen und zu ändern. Komplexe Strukturen neigen nachweislich eher zu Fehlfunktionen als weniger komplexe.
    • Kopplung - Eine Messung, die Aufschluss darüber gibt, wie intensiv die Elemente eines Systems miteinander in Beziehung stehen.
    • Kohäsion - Eine Messung, die anzeigt, wie gut ein Element oder eine Komponente der Anforderung entspricht, einen einzigen, klar definierten Zweck zu erfüllen.
    • Einfachheit - Der Grad, zu dem die Operationen oder Methoden einer Klasse durch Zusammensetzen anderer von die Klasse angebotenen Operationen gebildet werden können.
  • Vollständigkeit - Eine Messung, die Aufschluss darüber gibt, inwieweit ein Arbeitsergebnis alle Anforderungen (die dokumentierten und die impliziten) erfüllt. Um das Risiko nicht erfüllter Erwartungen zu minimieren, sollte sich der Projektleiter bemühen, so viele Anforderungen wie möglich explizit zu benennen. Es wurde entschieden, hier nicht zwischen ausreichend und vollständig zu unterscheiden.
  • Rückverfolgbarkeit - Gibt einen Hinweis darauf, dass die Anforderungen einer Ebene durch Arbeitsergebnisse einer niedrigeren Ebene erfüllt werden, und aus der anderen Perspektive betrachtet, dass ein Arbeitsergebnis einer beliebigen Ebene eine Existenzberechtigung hat.
  • Unbeständigkeit - Gibt den Grad der Änderungen bzw. Ergebnislosigkeit in einem Arbeitsergebnis aufgrund von Mängeln und sich ändernden Anforderungen an.
  • Aufwand - Eine Messung für die Arbeit (in Mitarbeiterzeiteinheiten), die erforderlich ist, um ein Arbeitsergebnis zu produzieren.

Nicht alle der aufgeführten Merkmale sind gleichermaßen auf alle Arbeitsergebnisse anwendbar. In den folgenden Tabellen werden die relevanten Merkmale für die jeweiligen Arbeitsergebnisse ausführlich behandelt. Wenn mehrere Metriken für ein Merkmal aufgeführt werden, sind potenziell alle von Interesse, weil sie eine vollständige Beschreibung aus unterschiedlichen Perspektiven liefern. Bei der Rückverfolgbarkeit von Anwendungsfällen bedeutet dies beispielsweise, dass letztendlich alle Anwendungsfälle bis zu einem (getesteten) Implementierungsmodell zurückverfolgt werden können müssen. Zwischenzeitlich ist es für den Projektleiter als Bewertungsmaßstab für den Fortschritt interessant zu wissen, wie viele Anwendungsfälle bis zum Analysemodell zurückverfolgt werden können.

Dokumente

Die empfohlenen Metriken gelten für alle RUP-Dokumente.

Merkmal

Metriken

Größe Seitenanzahl
Aufwand Mitarbeiterzeiteinheiten für Produktion, Änderung und Korrektur
Unbeständigkeit Anzahl der offenen und geschlossenen Änderungen und Mängel; geänderte Seiten
Qualität Wird direkt anhand der Zahl der Mängel gemessen
Vollständigkeit Wird nicht direkt gemessen. Die Beurteilung erfolgt durch Überprüfung.
Rückverfolgbarkeit Wird nicht direkt gemessen. Die Beurteilung erfolgt durch Überprüfung.

Modelle

Anforderungen

Anforderungsattribute

Dies ist eigentlich ein Modellelement.

Merkmal Metriken
Größe
  • Gesamtanzahl der Anforderungen (= Nu+Nd+Ni+Nt)
  • Anzahl der zu Anwendungsfällen zurückzuverfolgenden Anforderungen ( = Nu)
  • Anzahl der nur zu Design, Implementierung und Test zurückzuverfolgenden Anforderungen ( = Nd)
  • Anzahl der nur zu Implementierung und Test zurückzuverfolgenden Anforderungen ( = Ni)
  • Anzahl der nur zu Test zurückzuverfolgenden Anforderungen ( = Nt)

Damit werden die Anforderungen wie folgt unterteilt: Anforderungen, die von Anwendungsfällen modelliert werden, und andere Anforderungen. Es wird erwartet, dass die Rückverfolgbarkeit zu Anwendungsfällen für solche Anforderungen verwaltet wird, die einem Anwendungsfall zugeordnet sind, um das Design, die Implementierung und den Test verfolgen zu können.

Aufwand
  • Mitarbeiter Zeiteinheiten für Produktion, Änderung und Reparatur
Unbeständigkeit
  • Anzahl der Mängel sowie der Änderungsanfragen
Qualität
  • Anzahl der Mängel nach Mängelkategorie
Rückverfolgbarkeit

Anwendungsfallmodell

Merkmal Metriken
Größe
  • Anzahl der Anwendungsfälle
  • Anzahl der Anwendungsfallpakete
  • Dokumentierte Anwendungsfallebene (siehe White Paper "The Estimation of Effort and Size based on Use Cases" auf der IBM Website)
  • Anzahl der Szenarios, Gesamtanzahl und pro Anwendungsfall
  • Anzahl der Akteure
  • Länge des Anwendungsfalls (z. B. Seitenanzahl des Ereignisablaufs)
Aufwand
  • Mitarbeiterzeiteinheiten für Produktion, Änderung und Korrektur
Unbeständigkeit
  • Anzahl der Mängel sowie der Änderungsanfragen
Qualität
  • Dokumentierte Komplexität auf Klassenebene (0-5, in Anlehnung an COCOMO [BOE81]. Der Komplexitätsbereich ist bei höherem Abstraktionsgrad kleiner. Weitere Informationen hierzu finden Sie im White Paper "The Estimation of Effort and Size based on Use Cases" auf der IBM Website).
  • Mängel - Anzahl der Mängel nach Mängelkategorie, offen, geschlossen
Vollständigkeit
Rückverfolgbarkeit
  • Analyse
    • Im Analysemodell realisierte Szenarios/Gesamtanzahl der Szenarios
  • Design
    • Im Designmodell realisierte Szenarios/Gesamtanzahl der Szenarios
  • Implementierung
    • Im Implementierungsmodell realisierte Szenarios/Gesamtanzahl der Szenarios
  • Test
    • Im Testmodell realisierte Szenarios(Testfälle)/Gesamtanzahl der Szenarios

Design

Analysemodell

Merkmal Metriken
Größe
  • Anzahl der Klassen
  • Anzahl der Subsysteme
  • Anzahl der Subsysteme mit Subsystemen...
  • Anzahl der Pakete
  • Methoden pro Klasse (intern, extern)
  • Attribute pro Klasse (intern, extern)
  • Tiefe des Vererbungsbaums
  • Anzahl der untergeordneten Elemente
Aufwand
  • Mitarbeiterzeiteinheiten für Produktion, Änderung und Korrektur
Unbeständigkeit
  • Anzahl der Mängel sowie der Änderungsanfragen
Qualität Komplexität
  • Response For a Class (RFC): Kann schwierig zu bestimmen sein, weil dazu ein vollständiger Satz von Interaktionsdiagrammen benötigt wird.
Koppelung
  • Anzahl der untergeordneten Elemente
  • Kopplung zwischen Objekten (Klassenfächerung)
Kohäsion
  • Anzahl der untergeordneten Elemente
Mängel
  • Anzahl der Mängel nach Mängelkategorie, offen, geschlossen
Vollständigkeit
Rückverfolgbarkeit Nicht zutreffend - Das Analysemodell wird zum Designmodell.

Im Folgenden sehen Sie einige technische Metriken, die spezifisch für die OO-Programmierung sind und mit denen Sie möglicherweise nicht vertraut sind. - Tiefe des Vererbungsbaums, Anzahl der untergeordneten Elemente, Response For a Class (RFC), Kopplung zwischen Objekten und so weiter. Weitere Einzelheiten zur Bedeutung und Geschichte dieser Metriken finden Sie in [HEND96]. Einige dieser Metriken wurden zwar ursprünglich von Chidamber und Kemerer vorgeschlagen (siehe "A metrics suite for object oriented design", IEEE Transactions on Software Engineering, 20(6), 1994), aber IBM hat sie wie in [HEND96] vorgeschlagen angewendet und die Definition von LCOM (Lack of Cohesion in Methods), die in dieser Arbeit präsentiert wird, bevorzugt.

Designmodell

Merkmal Metriken
Größe
  • Anzahl der Klassen
  • Anzahl der Designsubsysteme
  • Anzahl der Subsysteme mit Subsystemen...
  • Anzahl der Pakete
  • Methoden pro Klasse (intern, extern)
  • Attribute pro Klasse (intern, extern)
  • Tiefe des Vererbungsbaums
  • Anzahl der untergeordneten Elemente
Aufwand
  • Mitarbeiterzeiteinheiten (für Produktion, Änderung und Korrektur)
Unbeständigkeit
  • Anzahl der Mängel sowie der Änderungsanfragen
Qualität Komplexität
  • Response For a Class (RFC): Kann schwierig zu bestimmen sein, weil dazu ein vollständiger Satz von Interaktionsdiagrammen benötigt wird.
Koppelung
  • Anzahl der untergeordneten Elemente
  • Kopplung zwischen Objekten (Klassenfächerung)
Kohäsion
  • Anzahl der untergeordneten Elemente
Mängel
  • Anzahl der Mängel nach Mängelkategorie
Vollständigkeit
Rückverfolgbarkeit Anzahl der Klassen im Implementierungsmodell/Anzahl der Klassen

Implementierung

Implementierungsmodell

Merkmal Metriken
Größe
  • Anzahl der Klassen
  • Anzahl der Dateien
  • Anzahl der Implementierungssubsysteme
  • Anzahl der Subsysteme mit Subsystemen...
  • Anzahl der Pakete
  • Methoden pro Klasse (intern, extern)
  • Attribute pro Klasse (intern, extern)
  • Größe der Methoden*
  • Größe der Attribute*
  • Tiefe des Vererbungsbaums
  • Anzahl der untergeordneten Elemente
  • Geschätzte Größe* nach Fertigstellung
Aufwand
  • Mitarbeiterzeiteinheiten (Zeiten für Produktion, Änderung und Korrektur werden separat aufgeführt)
Unbeständigkeit
  • Anzahl der Mängel sowie der Änderungsanfragen
  • Schadhaftigkeit* jeder korrigierenden bzw. verbessernden Änderung, geschätzt (vor der Korrektur) und tatsächlich (beim Schließen)
Qualität Komplexität
  • Response For a Class (RFC)
  • "Cyclomatic Complexity" von Methoden**
Koppelung
  • Anzahl der untergeordneten Elemente
  • Kopplung zwischen Objekten (Klassenfächerung)
  • Message Passing Coupling (MPC)***
Kohäsion
  • Anzahl der untergeordneten Elemente
  • Lack of Cohesion in Methods (LCOM)
Mängel
  • Anzahl der Mängel nach Mängelkategorie, offen, geschlossen
Vollständigkeit

* Zum Messen der Codegröße sollte eine Methode ausgewählt und dann konsequent verwendet werden, z. B. ohne Kommentar und ohne Leerzeichen. Nähere Informationen zu den Vorteilen und zur Anwendung von Quellcodezeilen als Metrik finden Sie in [ROY98]. In derselben Referenz finden Sie auch eine Definition für 'Schadhaftigkeit' (Breakage).

** Die Verwendung von "Cyclomatic Complexity" ist nicht allgemein anerkannt, insbesondere nicht, wenn sie auf Methoden einer Klasse angewandt wird. Eine Erläuterung dieser Metrik finden Sie in [HEND96].

*** Stammt ursprünglich von Li und Henry ("Object-oriented metrics that predict maintainability", J. Systems and Software 23(2), 1993) und wird auch in [HEND96] beschrieben.

Test

Testmodell

Merkmal Metriken
Größe
  • Anzahl der Testfälle, Testprozeduren, Testscripts
Aufwand
  • Mitarbeiterzeiteinheiten für die Erstellung von Testfällen usw. (Zeiten für Produktion, Änderung und Korrektur werden separat aufgeführt)
Unbeständigkeit
  • Anzahl der erhobenen Mängel und Änderungsanfragen für das Testmodell
Qualität
  • Mängel - Anzahl der Mängel nach Kategorien (offen, geschlossen). Hierbei handelt es sich um Mängel, die zum Testmodell selbst eingereicht werden. Mängel, die vom Testteam zu anderer Software eingereicht werden, gehören nicht dazu.
Vollständigkeit
Rückverfolgbarkeit
  • Anzahl der in der Zusammenfassung der Testauswertung als erfolgreich aufgelisteten Testfälle/Anzahl der Testfälle

Management

Änderungsmodell - Ein Notationsmodell für konsistente Darstellung - Die Metriken werden von jedem System zusammengestellt, das für die Verwaltung von Änderungsanfragen verwendet wird.

Merkmal Metriken
Größe
  • Anzahl der Mängel und Änderungsanfragen nach Kategorie und Status, außerdem nach Anzahl adaptiver Änderungen und Anzahl korrigierender Änderungen
Aufwand
  • Aufwand zur Behebung von Mängeln und Aufwand zur Implementierung von Änderungen in Mitarbeiterzeiteinheiten.
Unbeständigkeit
  • Schadhaftigkeit (geschätzt, tatsächlich) der Untergruppe des Implementierungsmodells
Vollständigkeit
  • Anzahl der aufgedeckten Mängel/Anzahl der vorhergesagten Mängel (sofern ein Zuverlässigkeitsmodell verwendet wird)

Projektplan (Abschnitt 4.2 des Softwareentwicklungsplans)

Die folgenden Messwerte stammen aus der Anwendung von Fertigstellungswerttechniken für das Projektmanagement und werden kollektiv "Cost/Schedule Control Systems Criteria" (C/SCSC) genannt. Eine einfache Fertigstellungswerttechnik wird im Abschnitt Minimale Gruppe von Metriken beschrieben. Eine tiefergehende Analyse kann mit verwandten Metriken durchgeführt werden, zu denen die Folgenden gehören:

  • BCWS, Budgeted Cost for Work Scheduled
  • BCWP, Budgeted Cost for Work Performed
  • ACWP, Actual Cost of Work Performed
  • BAC, Budget at Completion
  • EAC, Estimate at Completion
  • CBB, Contract Budget Base
  • LRE, Latest Revised Estimate (EAC)

Dies sind abgeleitete Faktoren für Kosten- und Terminplanabweichungen. Nähere Informationen zur Anwendung eines Fertigstellungswertansatzes im Softwareprojektmanagement finden Sie in [ROY98].

Projekt

Das Projekt muss in Bezug auf Typ, Größe, Komplexität und Formalität charakterisiert werden (obwohl Typ, Größe und Komplexität in der Regel die Formalität bestimmen), da diese Aspekte Erwartungen bezüglich verschiedener Schwellenwerte für Messungen auf niedrigerer Ebene bedingen. Andere Vorgaben müssen im Vertrag (oder in Spezifikationen) erfasst werden. Metriken, die aus dem Prozess, dem Produkt und aus den Ressourcen abgeleitet werden, erfassen alle anderen Metriken auf Projektebene. Projekttyp und -umfeld (Domäne) können in einer Textbeschreibung dokumentiert werden, um sicherzustellen, dass genügend Details für die Charakterisierung des Projekts vorhanden sind. Dokumentieren Sie die Projektgröße in Form von Kosten, Aufwand, Dauer, Umfang des zu entwickelnden Codes und zu erbringenden Funktionspunkten. Die Komplexität des Projekts kann - relativ subjektiv - beschrieben werden, indem das Projekt in einem Diagramm abgebildet wird, das die technische und verwaltungsbezogene Komplexität im Vergleich mit anderen, bereits fertig gestellten Projekten zeigt. [ROY98], Abbildung 14-1 zeigt ein solches Diagramm.

Die abgeleiteten Metriken, die in [ROY98] beschrieben sind und die Hauptindikatoren für den Projektleiter sind, ergeben sich aus den Metriken, die für Produkt und Prozess erfasst werden. Dies sind:

  • Modularität = Durchschnittliche Schadhaftigkeit (NCNB*) pro verbessernder oder korrigierender Änderung im Implementierungsmodell
  • Anpassungsfähigkeit = Durchschnittlicher Aufwand für verbesserende oder korrigierende Änderungen im Implementierungsmodell
  • Reife = Aktive Testzeit/Anzahl korrigierender Änderungen
  • Wartungsfreundlichkeit = Produktivität der Pflege/Produktivität der Entwicklung = [tatsächliche kumulativ Fixes/kumulativer Aufwand für verbessernde und korrigierende Änderungen]/[geschätzte Zahl für NCNB bei Fertigstellung/geschätzter Produktionsaufwand bei Fertigstellung]
  • Stabilität der Nacharbeiten = Kumulative Schadhaftigkeit-kumulative Fixes
  • Nacharbeitungsrückstand = [kumulative Schadhaftigkeit-kumulative Fixes]/einem Einheitentest unterzogener NCNB

* NCNB ist die Codegröße ohne Kommentare und ohne Leerzeichen.

Der Fortschritt muss im Projektplan mit Metriken für die Fertigstellung von Arbeitsergebnissen dokumentiert werden, wobei (aus der Perspektive des Fertigstellungswerts) die Produktion funktionierender Software im Vordergrund steht.

Wenn ein Schätzmodell wie COCOMO (siehe [BOE81] verwendet wird, müssen die verschiedenen Skalierungs- und Kostenfaktoren dokumentiert werden. Diese liefern eine relativ detaillierte Charakterisierung des Projekts.

Ressourcen

Zu den zu messenden/bewertenden Elementen gehören Menschen (Erfahrung, Know-how, Kosten, Leistung), Methoden und Tools, (in Bezug auf Auswirkung auf Produktivität und Qualität, Kosten), Zeit, Aufwand, Budget (verbrauchte Ressourcen, verbleibende Ressourcen).

Das Mitarbeiterprofil muss nach und nach dokumentiert werden, den Typ (Analytiker, Designer usw.), die Qualität (impliziert Kosten) und das Team anzeigen, dem das Profil zugeordnet wird. Ist- und Plandaten müssen dokumentiert werden.

Das COCOMO-Modell setzt auch hier die Charakterisierung von Erfahrung und Fähigkeit des Personals und der Softwareentwicklungsumgebung voraus und ist ein geeignetes Framework, um diese Metriken zu pflegen.

Ausgaben, Budget und Planungsinformationen stammen aus dem Projektplan.