-
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.
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 %
|
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.
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.
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.
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.
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
|
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.
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).
|
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].
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.
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.
|