Software Metriken

Institut für Informationswirtschaft 

Informationswirtschaft III 

Software-Metriken 

Wolfgang H. Janko 

Stefan Koch 

Janko/Koch Informationswirtschaft 3 

Seite 1


Inhaltsverzeichnis 

1. Grundlagen 

2. Lines-of-Code 

3. Cyclomatic Complexity 

4. Halstead-Maß 

5. Metriken der objekt-orientierten 

Programmierung 

6. Mannmonat 


Seite 2


Grundlagen 

• Metrik: Zuordnung einer Zahl zu einer Entität, um ein 

spezielles Attribut dieser Entität zu charakterisieren 

• Klassen von Software-Metriken 

– Produktmetriken: Maßzahlen für das Software- 

Produkt 

– Prozessmetriken: Quantifizierung von Attributen des 

Entwicklungsprozesses und der 

Entwicklungsumgebung 

• Attribute von Entitäten 

– interne, d.h. solche, die an der Entität selbst 

gemessen werden 

– externe, d.h. solche, die nur daran gemessen 

werden können, wie die Entität in einer 

Beziehung zu ihrer Umwelt steht 


Seite 3


Grundlagen 

• Messung von Software-Metriken 

– direkt: ohne Abhängigkeit von einem anderen 

Attribut 

– indirekt: inkludiert die Messung eines oder 

mehrerer anderer Attribute 

– objektiv (algorithmisch): Messung kann nach einem 

Algorithmus vorgenommen werden, Ergebnis 

ist daher reproduzierbar und hängt nicht von 

Ort, Zeit oder Beobachter ab 

– subjektiv 


Seite 4


Grundlagen 

• Anforderungen an Software-Metriken (Meta-Metriken zur 

Evaluation von Metriken, meist nur subjektiv messbar) 

– Einfachheit 

– Validität (wird das gemessen, was gemessen werden 

soll) 

– Robustheit (Sensitivität der Metrik auf Änderungen, 

die die Performanz der Software nicht 

beeinflussen) 

– Analysierbarkeit mit statistischen Mitteln 

– Eignung im Rahmen des Software- 

Projektmanagements 

– ’wholeness’ (die Komplexität einer 

zusammengesetzten Entität soll mindestens die 

Summe der Komplexitäten ihrer Teile betragen) 


Seite 5


Grundlagen 

– Sensitivität auf atomare Änderungen 

– andere Auflistung: ’association, consistency, 

discriminative power, tracking, predictability, 

repeatability’ 


Seite 6


Grundlagen 

• Verwendung und Nutzen 

– jede Erhebung sollte von klaren und wohldefinierten 

Zielen geleitet sein, da jede Messung Kosten 

verursacht (z.B. Goal/Question/Metric-Ansatz: 

ausgehend von Definition der Projektziele wird 

systematisch eine Verfeinerung dieser in Form 

einer Reihe von Fragen vorgenommen, die 

dann jeweils durch passende Metriken mit 

quantitativen Daten beantwortet werden 

können; damit soll eine zielgerichtete 

Erhebung von ausschließlich tatsächlich 

benötigten Metriken sichergestellt werden.) 


Seite 7


Grundlagen 

– Feststellung (’assessment’) im Rahmen der 

Steuerung eines Software-Projekts (Wie weit 

sind wir?) 

– Vorhersage (’prediction’) von Charakteristiken von 

Projekten (Aufwandsschätzung) 

– andere Einteilung: 

• taktische Anwendung in Rahmen des 

Projektmanagements 

• strategische Anwendung im Rahmen der 

Prozessverbesserung (basierend auf den 

Daten von alten Projekten wird der 

Entwicklungsprozess angepasst) 


Seite 8


Grundlagen 

• meistens gemessen: Größe und Komplexität von Software- 

Artefakten, Aufwand der Entwicklung 

• inzwischen aber auch: andere Artefakte der Entwicklung 

von Software, z.B. die während dieses Prozesses 

mittels E-Mail oder Diskussiongruppen stattfindende 

Kommunikation 


Seite 9


Lines-of-Code 

• eine der gebräuchlichsten Metriken für die Größe einer 

Software 

• LOC oder Programmzeilen 

• jedoch unterschiedliche Definitionen (Was wird gezählt?) 

– ausführbare Programmzeilen oder Anweisungen in 

jeder gängigen Definition inkludiert 

– Kommentare ? 

– Leerzeilen ? 

– ohne diese beiden: NCSS (Non Commentary Source 

Statements) 

– Deklarationen von Variablen oder Prozeduren ? 

– Anweisungen im Header ? 

– Compiler-Anweisungen ? 


Seite 10


Lines-of-Code 

– Programmzeile kann mehrere Anweisungen 

umfassen 

(Trennzeichen) 

– bei Überarbeitungen: Zählung von Löschen und 

Modifikation von einzelnen 

Programmzeilen 

– Zählung bei Wiederverwendung von Code- 

Bestandteilen(Reuse) 

• organisationsweit einheitliche Definition unumgänglich 

• Verbindung zum Anreizsystem beachten 

– weder ’künstlich’ überlange Programme sinnvoll, 

um gute 

Produktivitätskennzahlen zu erreichen, 

– noch Programme unter unverhältnismäßig hohem 

Zeitaufwand möglichst kurz halten 


Seite 11


Lines-of-Code 

• Vorteil: einfach, verständlich, automatisiert erhebbar 

• Probleme 

– Sprachabhängigkeit, für die Lösung eines Problems 

sind in unterschiedlichen Sprachen 

unterschiedlich viele Zeilen nötig (damit keine 

Vergleichbarkeit der erhobenen Daten) 

– mißt eigentlich nur Größe (etwa für die Speicherung 

oder einen Ausdruck) 

– und nicht Komplexität (Beispiel rekursive 

Programme: geringe Anzahl von LOC, aber 

hoher Schwierigkeitsgradbei der Entwicklung) 


Seite 12


Lines-of-Code 

Beispiel 

use DBI; 

#open log files 

while() { 

my $count; 

if (/^RCS file: cvsroot([^]+)(.+),/) 

{ 

$project=$1;$realfile=$1."/".$2; 

$file=$realfile; 

$file =~ tr/’/"/; 

$sumadd=0;$sumdel=0;$count++; 

my $instr="insert into file values (’$file’,’$project’)"; 

print $instr; 

} 

elsif (/^date: (.+); author: (w+); state: Exp;$/) 

{ 

$date=$1;$prog=$2; 

$lines_total=‘wc -l ¨$datadir/$realfile¨‘; 

} 

close CVS; 

} 

LOC: 21, 20 (ohne Leerzeilen), 19 (ohne Kommentar), 17 (ohne 

Deklarationen), 12 (nur Zeilen mit Befehlen), 16 (jeder Befehl)? 


Seite 13


Cyclomatic Complexity 

• zyklomatische Komplexität (McCabe) 

• beruht auf der Kontrollflußstruktur (’control flow graph’ 

oder ’flowgraph’) eines Programms 

• mißt die Anzahl der linear unabhängigen Wege durch den 

Flowgraph F 

• bei e Kanten, n Knoten und p 

Zusammenhangskomponenten 

v(F) = e − n + 2p (1) 

• v(F)>=1 

• Knoten: Block sequentieller Anweisungen, die keine 

internen Verzweigungen aufweisen 

• Kante: möglicher Kontrollfluß zwischen den Knoten 

• Zusammenhangskomponenten: unabhängige 

Programmkomponenten (Module / Prozeduren, >=1) 


Seite 14



• Annahme: Module mit einer Cyclomatic Complexity von 

mehr als 10 besonders fehleranfällig 

• erlaubt Aussagen über die Komplexität des Kontrollflusses 

• beeinflußt vor allem das Testen, bei dem alle Pfade 

betrachtet werden sollten 

• eigentlicher Umfang des Programmes wird nicht beachtet, 

da jeder Knoten des Graphen beliebig viele 

Anweisungen enthalten kann, solange sich keine 

Verzweigung darunter befindet 


Seite 15




Seite 16


Halstead-Maß 

• Grundidee: Zählen von Operatoren (Symbole, die den Wert 

oder die Anordnung eines Operanden beeinflussen) 

und Operanden (Variablen oder Konstanten) 

• gemessen werden jeweils die Gesamtanzahl der 

Operatoren und Operanden (N1 und N2) sowie die 

Anzahl der verschiedenen Operatoren und Operanden 

(n1 und n2) in der vorliegenden Implementierung 

Beispiel (N1=4, N2=4, n1=2, n2=3) 

print $name; 

print $adresse; 

print $alter; 

$alter++; 


Seite 17


Halstead-Maß 

• Vokabular: n = n1 + n2 

• Implementierungslänge: N = N1 + N2 

• Größe der Implementierung eines Algorithmus: Volumen 

V = N log2 n (in Bit, abhängig von 

Implementierungssprache) 

• es kann dann das Verhältnis zum minimalen oder 

potentiellen Volumen (in einer Programmiersprache, in 

der der betrachtete Algorithmus bereits definiert oder 

implementiert ist, zum Beispiel als Subroutine oder 

Prozedur) berechnet werden (Programmstufe L) 

• Schwierigkeit D des Verständnisses invers zu der 

Programmstufe (um ein Konzept jemandem zu 

erklären, der über nur geringes Wissen verfügt, muß 

ein höheres Volumen verwendet werden) 


Seite 18


Halstead-Maß 

• Kombination mit Cyclomatic Complexity: 

– in einem ersten Schritt wird jeder Kontrollstruktur 

eine Cyclomatic Complexity gleich ihrer 

Schachtelungsebene plus eins zugeordnet (also 

jenen der obersten Ebene 1, darunter 2,...) 

– für jeden Operator bzw. Operand, der Teil einer 

Kontrollstruktur ist, wird zu N1 bzw. N2 eins 

hinzugefügt (wie üblich), plus der 

Schachtelungsebene der jeweiligen 

Kontrollstruktur (also im Endeffekt die 

Cycl. Compl. der Kontrollstruktur dazugezählt) 

– ergibt gewichtetes Maß für die Komplexität (die 

Operatoren und Operanden auf den unteren 

Ebenen der Verschachtelung werden höher 

bewertet) 

Seite 19 

Janko/Koch Informationswirtschaft 3


Metriken der objektorientierten 


• steigende Popularität des objekt-orientierten Paradigmas 

• Analyse und die Quantifizierung von Attributen der 

entsprechenden Designs und Software-Artefakte 

zunehmend wichtiger 

• bekanntester Ansatz von Chidamber und Kemerer 

(Maßzahlen für jede Klasse, teilweise gute Indikatoren 

für fehleranfällige Klassen) 

– ’weighted methods per class’: Komplexität einer 

Klasse, für jede Funktion der Wert 1 

– ’depth in inheritance tree’: Länge des längsten 

Pfades durch die Vererbungshierarchie bis zum 

betrachteten Modul 

– ’number of children’: Anzahl der Klassen, die direkt 

von dieser erben 


Seite 20




– ’coupling between methods’: Anzahl der Module, die 

mit dem betrachteten gekoppelt sind (wenn 

eine davon die Funktionen und/oder die 

Instanzvariablen der anderen benutzt) 

– ’response for a class’: Anzahl der Methoden, die 

potentiell ausgeführt werden können, wenn ein 

Objekt der betrachteten Klasse eine Nachricht 

empfängt 

– ’lack of cohesion on methods’: Anzahl der 

Methoden-Paare, die keine gemeinsamen 

Instanzvariablen haben, abzüglich der Anzahl 

der Methoden-Paare, die solche besitzen 


Seite 21




• Ergänzungen und andere Ansätze: 

– ’inheritance coupling’: Anzahl der Vaterklassen, mit 

der eine Klasse gekoppelt ist (wenn eine der 

geerbten Methoden eine neue oder neu 

definierte Variable oder Methode benutzt) 

– ’coupling between methods’: Anzahl der neuen oder 

neu definierten Methoden, mit denen die 

geerbten Methoden gekoppelt sind 

– ’number of objects/memory allocation’: Anzahl der 

Befehle, die neue Objekte oder Speicher in 

einer Klasse allozieren 

– ’average method complexity’: durchschnittliche 

Größe der Methoden einer Klasse (z.B. in LOC) 


Seite 22




– MOOD-Gruppe: Method Inheritance Factor, 

Attribute Inheritance Factor, Coupling Factor, 

Clustering Factor, Polymorphism Factor, 

Method Hiding Factor, Attribute Hiding Factor 

und Reuse Factor (alle in Prozenten, sollen 

grundlegende Mechanismen des 

objektorientierten Paradigmas wie Kapselung 

oder Vererbung ohne Berücksichtigung der 

Implementierungssprache ansprechen, 

Systemsicht, und damit komplementär zu dem 

Ansatz von Chidamber und Kemerer) 


Seite 23


Mannmonat 

• Mann- oder Personenmonate sind die gebräuchlichste 

Metrik für den Aufwand, beispielsweise eines Projekts 

wie einer Software-Entwicklung 

• 1 Mannmonat bedeutet vereinfacht die Tätigkeit eines 

Menschen über ein Monat 

• 1 Mannmonat sind 19 Manntage bzw. 152 Mannstunden, 

12 Mannmonate sind ein Mannjahr 

• Mannmonate sind der gebräuchlichste Output von 

Aufwandsschätzungsmodellen 


Seite 24


Mannmonat 

• grundsätzlich würden logischerweise 24 Mannmonate der 

Arbeit eines Menschen für 2 Jahre, oder von 24 

Menschen für 1 Monat entsprechen 

• Zusammenhang ist aber nicht durchgehend gegeben: 

– durch eine höhere Anzahl von Beteiligten entstehen 

höhere Kommunikationskosten (wenn in einer 

Gruppe von n Personen jeder mit jedem 

kommunizieren muss, gibt es n(n−1)/2 

Kommunikationswege, der Aufwand steigt 

folglich von quadratischer Ordnung), die den 

linearen Zuwachs an Fortschritt (eine Person 

bringt immer x Fortschrittsgewinn) irgendwann 

übersteigen 


Seite 25


Mannmonat 

– Aufgaben sind nicht auf beliebig viele Personen 

verteilbar (in der Software-Entwicklung wie in 

der Produktion physischer Güter), wenn die 

Entwicklungszeit verringert werden soll, muss 

dies aber passieren: in der SW-Entwicklung 

Modularisierung (Klassen) mit definierten 

Schnittstellen (auch zur Reduzierung der 

notwendigen Kommunikation und 

Koordination) 


Seite 26


Mannmonat 

– ’The Mythical Man-Month’ (Brooks): bei 

Überschreiten von Terminen wird durch das 

Management oft mehr Personal zugeführt; 

dadurch, daß die erfahrenen Mitarbeiter diese 

nun anlernen müssen, damit sie produktiv 

werden, kann sogar eine Verzögerung 

eintreten (Brooks’s Law: ’Adding manpower to 

a late software project makes it later’) 


Seite 27

Software Metriken

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?