Projektmanagement Techniken - Einsatz von Metriken

Projektmanagement Techniken - Einsatz von Metriken
Ziele dieses Abschnittes: - Motivation der Messung von diversen SW-Aspekten; - Aufzeigen der Problematik bei der Erfassung/Messung von SW-Eigenschaften; - beispielhafte Präsentation und Diskussion einiger bekannter Metriken; - Beschreibung spezieller Metriken für OO-Design; - Diskussion des Einsatzes von Metriken für die Verbesserung des SW-Prozesses; - strategische Entscheidungen im SW-Projektmanagement;

Metriken Eine Software-Metrik ist jede Art von Maßzahl, die ein SW-Produkt, SW-Prozeß, oder entsprechende Dokumentation charakterisiert. Motivation: - Messung von Qualitätseigenschaften wie Wartbarkeit, Änderbarkeit, Portabilität, Effizienz, etc. zwecks Überprüfung der Erfüllung und zwecks Vorhersagen. - Vergleich alternativer Lösungen zwecks Auswahl; - Aufwandschätzung; Kosten-, Terminschätzung; - Überwachung und Verbesserung des SW-Prozesses; - Verbesserung des SW-Managements, etc. ; - experimentelle Validierung der “besten Praktiken”.

Metriken grobe Unterteilung in:
Prozeß-Metriken: quantifizieren Attribute des Entwicklungsprozesses sowie der Umsysteme der SW-Entwicklung. Beispiele: Entwicklungskosten, Dauer einzelner Phasen, Erfahrungsgrad der Programmierer, Tooleinsatz; Produkt-Metriken: stellen Messungen am SW-Produkt dar. Beispiele: LOC (Lines of Code), Anzahl der verwendeten Variable/Operatoren, zyklomatische Komplexität, Kopplungs- grad, Art der Anwendung wie technisch, kommerziell, etc. .

Metriken einige bekannte Klassen von Metriken und deren Vertreter :
1) Größen-Metriken (“size metrics”) 1a) LOC: Lines of Code Gründe für die hohe Bedeutung dieser Maßzahl: - ist einfach zu erheben, nach Fertigstellung des Programms! - ist Basis zahlreicher Modelle für die Aufwandschätzung - stellt die Basis zur Berechnung der Produktivität dar Vorsicht: verschiedene Interpretationen möglich: zählen Kommentarzeilen?, Leerzeilen?, Datendeklarationen?... daher: einheitliche Definition für konsistenten Vergleich verschiedener Messungen erforderlich, z.B:

Metriken Eine “line of code” ist jede Zeile Programmtext, die kein Kommentar und keine Leerzeile ist, unbeachtet der Tatsache, wieviele Anweisungen oder Fragmente davon sie enthält. Insbesondere sind exekutierbare wie auch nicht-exekutierbare Anweisungen zu zählen. 1b) Anzahl von Tokens (“token count”) Token: syntaktische Einheit, die von Compiler unterschieden wird; Grundlage von Halstead’s Software Science Metrics: eine der best dokumentierten und meist diskutierten Metriken; Klassifikation von Tokens in Operatoren und Operanden;

Metriken Operator: Symbol oder Schlüsselwort, welches eine Aktion spezifiziert; z.B.: +, /, WHILE, IF, ( ), EOF, ... Operand: Symbol, welches Daten repräsentiert; Beispiele: Variable, Konstante, Labels; N .. Größe eines Programms := Anzahl von Tokens : N = N1 + N2 N1: Operator-Anz.; N2: Operanden-Anz. charakteristische Größen in Halstead’s Metriken: h1 .. Anzahl der verschiedenen Operatoren h2 .. Anzahl der verschiedenen Operanden Vokabular einer Sprache .. h = h1 + h2 weitere Maßzahl für die Größe eines Programms: Volumen .. V = N * log2 h

Metriken (zu diskutierende) Hypothese: Die Länge eines Programms ist ausschließlich eine Funktion von h1 und h2: N’ = h1 * log2 h1 + h2 * log2 h2 Vorsicht: keine eindeutigen Definitionen für hi (in Analogie zu Problematik der Messung von S = Anz. der LOC). Kommentar: Ergebnis einer Studie an 1000 Programmen besagt, daß zwischen S, N und V ein linearer Zusammenhang besteht; Folgerung: alle drei Größen sind gleich gut zur Messung der (relativen) Größe eines Programms geeignet: Anmerkung: N und V sind weiters robuste Metriken: Variationen in der Klasifikation von Operatoren und Operanden wirken sich auf die Größe kaum aus.

Metriken 1c) Anzahl der Module oder Anzahl der Funktionen beide problematisch, da i.a. große Variationsbreiten bezüglich der Größe einzelner Module/Funktionen; 1d) Größenentsprechungen bei Wiederverwendung Problematik: obige Metriken sind ungeeignet, falls Code wiederverwendet wird; Code-fragmente müssen meist adaptiert werden, deren Integration bedeutet ebenfalls Aufwand; der Geamtaufwand (Sgesamt) setzt sich aus dem Aufwand für neu zu erstellenden Code (Sneu) und einen gewichteten Aufwand für adaptierten Code (k*Sreuse) zusammen: Sgesamt = Sneu + k*Sreuse

Metriken 2) (einige) Datenstruktur-Metriken: erfassen jene Datenmengen, die eingegeben, verarbeitet und von einem Programm ausgegeben werden; 2a) Datenmenge Ermittlung als Anzahl der Einträge der Cross-Referenz-Liste; Vorsicht: Deklarierte, aber nicht verwendete Einträge sind nicht zu zählen! Die Metriken: VARS .. Anz. der Variablen, h2 und N2 (siehe 1b) sind in etwa gleich gute, robuste Datenmengen-Metriken.

Metriken 2b) Inter-Modul Beziehungen
i) strukturelles “Fan-in” und “Fan-out” eines Moduls: Constantine and Yordon (1979) Das “Fan-in” eines Moduls M ist die Anzahl der Module, die Daten an M (direkt oder indirekt) übergeben. Das “Fan-out” von M ist die Anzahl der Module, die (direkt oder indirekt) von M Daten erhalten (auf M’s Daten zugreifen). Interpretation: große Fan-in Werte bedeuten hohe Kopplung zwischen Modulen aufgrund zahlreicher Abhängigkeiten; große Fan-out Werte deuten auf eine hohe (Kontrollfluß-) Komplexität rufender Module; Problematik: Datenstruktur-Aspekte und Datenflüsse zwischen Komponenten werden nicht berücksichtigt.

Metriken ii) “informational fan-in/fan-out” eines Moduls: Henri und Kafura (1981) informational fan-in/fan-out einer Komponente K setzt sich zusammen aus der Anzahl der lokalen Datenflüsse aus K und der Anzahl der globale Datenstrukturen, die K updatet. Die Anz. der Datenflüsse inkludiert aktualisierte Prozedur-Parameter sowie Prozeduren, die K aufruft. Komplexität einer Komponente: KomplexitätH&K = Größe * (fan-in * fan-out)2 Größe: beliebiges Größenmaß Problematik: - kein Unterschied, ob ein einfacher Datenwert oder eine komplexer Verbund übergeben werden; - ergibt 0 für Komponenten ohne externe Interaktion

Metriken 3) Metriken basierend auf der logischen Struktur
3a) Zyklomatische Komplexität ZK (McCabe, 1976) Die ZK gibt die Anzahl der unabhängigen Pfade in einem Programmgraphen an. Bei einem unabhängigen Pfad wird mindestens eine ‘neue’ Kante im Programmflußplan beschritten. ZK := Anzahl(Kanten) - Anzahl(Knoten) + 1 Bedeutung: Gibt die Anzahl der notwendigen Testfälle zur Zweigüberdeckung an. Maß für Testbarkeit/Testaufwand; Basis für Schätzung der Wartbarkeit. Berechnung der ZK direkt aus dem Programm: ZK = Anzahl der Bedingungen; Eine komplexe Bedingung mit N Prädikaten zählt als N.

Metriken Beispiel: Zwei verschiedene Programmflußgraphen mit gleicher ZK a) ZK = = 3 b) ZK = = 3 (nach Conte, Abb. 2.25, S. 69)

Metriken 3b) Schachtelungstiefe von Anweisungen je höher die Schachtelungstiefe, umso schwerer die Verständlichkeit einer Anweisung; Maß: durchschnittliche Schachtelungstiefe einer Anweisung Bewertungsergebnisse (Kitchenham, 1990): - Die Größe und auch die Zyklomatische Komplexität sind gleich gute Maße für die Vorhersage der Komplexität wie strukturelles- und “informational fan-in/fan-out”. - Fan-out selbst ist ein besseres Komplexitätsmaß als “informational fan-in/fan-out”. - “Informational fan-in/fan-out” eines Designs ist nützlich für die Schätzung des Aufwandes für die Implementierung.

Metriken 4 Design-Metriken:
4.1) Prinzipien des Strukturierten Entwurfs und deren Messung: Kopplung: Anzahl der Verbindungen zwischen Modulen (Schnittstellenbreite) Kohäsion: verwandte Funktionen sollen in einem Modul zusammengefaßt werden Messung: z.B. hohes Fan-in bedeutet geringe Kohäsion Komplexität: wächst mit zunehmender Anzahl von Kontrollkonstrukten (vgl. ZK) und Tiefe des Modulbaumes Modularität: Über- und Untermodularisierung sind unerwünscht Modulgröße: große Module und eine hohe Tiefe des Modulbaumes (genauer: “structure chart”) sind zu vermeiden Bewertung: Kopplung hat höchste Korrelation mit Defektanzahl!

Metriken: OOD-Metriken (nach Chidamber & Kemerer, 1994)
4.2)Metriken für den Objekt-Orientierten Entwurf (OOD) 4.2a) Gewichtete Methoden per Klasse (GMK) Die Klasse C1 habe die Methoden M1, … , Mn mit den Komplexitäten k1, … , kn. GMK = Summe (i=1 bis n) ki Als Komplexität kann ein beliebiges (klassisches) Komplexitätsmaß verwendet werden, z.B. die ZK. Falls alle Komplexitäten mit 1 bewertet werden, ist GMK gleich der Anzahl der Methoden einer Klasse.

Metriken Gesichtspunkte: - Die Anzahl und Komplexität von Methoden sind Anzeichen für den Aufwand für die Kodierung, das Testen und die Wartung der Klasse. - Je höher die Anzahl der Methoden einer Klasse, unso höher der potentielle Einfluß auf die Subklassen, da diese die Methoden erben. - Klassen mit sehr vielen Methoden sind mit hoher Wahrscheinlichkeit applikations-spezifisch, was ihre Wiederverwendbarkeit einschränkt.

Metriken 4.2b) Tiefe des Vererbungsbaumes (TV)
Die TV einer Klasse C ist die Länge des längsten Pfades von C zur Wurzel der Subklassenhierarchie (i.e. des Vererbungsbaumes, im Falle von Einfachvererbung). Gesichtspunkte: - Je tiefer eine Klasse C liegt, umso größer ist die Anzahl der Methoden, die C erbt und umso schwieriger ist es, C’s Verhalten abzuschätzen und zu verstehen. - Tiefe Hierarchien bedingen eine hohe Design-Komplexität, da viele Klassen und Methoden involviert sind. - Je tiefer eine Klasse in der Hierarchie liegt, umso größer ist die potentielle Wiederverwendbarkeit geerbter Methoden.

Metriken 4.2c) Anzahl der Kinder (AK)
Die AK ist die Anzahl der direkten Subklassen einer Klasse C in der Subklassenhierarchie. Gesichtspunkte: - Je größer die AK, umso größer die Wiederverwendung, da Vererbung eine Form von Wiederverwendung darstellt. - Die AK einer Klasse C vermittelt ein Maß für den potentiellen Einfluß von C auf den Entwurf. Die Methoden von Klassen mit einer hohen AK sollten daher besonders gründlich getestet werden.

Metriken 4.2d) Kopplung zwischen Klassen (KZK)
Die KZK-Zahl einer Klasse C ist die Anzahl der Klassen, mit welchen C gekoppelt ist. Zwei Klassen C1 und C2 sind gekoppelt, wenn die Methoden von C1 die Methoden oder Instanzvariablen von C2 verwenden oder vice versa. Gesichtspunkte: - Starke Kopplung zwischen Klassen widerspricht dem modularen Entwurf und verhindert Wiederverwendung. Je unabhängiger eine Klasse ist, umso einfacher kann sie in einer anderen Applikation wiederverwendet werden. - Mit wachsender Zahl der Kopplungen zwischen Klassen wächst die Zahl der Klassen, die bei Änderungen einer Klasse betroffen sind. Dadurch verschlechtert sich die Wartbarkeit des Systems. Intensiveres Testen erforderlich!

Metriken 4.2e) Response für eine Klasse (RFK)
Die Response-Menge RS einer Klasse C ist jene Menge von Methoden, die potentiell als Reaktion auf den Empfang einer Nachricht durch ein Objekt der Klasse C exekutiert werden können. RS = {M} Èallei {Ri} {M} .. Menge aller Methoden von C {Ri} .. Menge von Methoden, die von der Methode i aufgerufen werden. RFK = Card(RS) Kardinalität von RS

Metriken Gesichtspunkte: - Eine hohe RFK einer Klasse C erschwert das Testen von C, da die testende Person die von C’s Methoden gerufenen Methoden anderer Klassen verstehen sollte. - Eine hohe RFK einer Klasse C führt zu einer hohen Komplexität von C. - Entscheidungshilfe bei der Allokation von Test- Ressourcen: Beim Systemtest sollten Klassen mit hohen RFK-Werten als strukturelle Treiber herangezogen werden, um einen hohen Prozentsatz an Code-Überdeckung zu erzielen. Grund: eine kleine Anzahl von Klassen kann Verursacher der Exekution von einer großen Anzahl von Methoden in einer Anwendung sein.

Metriken 4.2f) Mangel an Kohäsion in Methoden (MKM)
MKM basiert auf dem Begriff des Ähnlichkeitsgrades von Methoden einer Klasse. Der Ähnlichkeitsgrad zweier Methoden M1 und M2 einer Klasse C ist die Anzahl jener Instanzvariablen von C, die sowohl M1 als auch M2 verwendet. MKM = [Anzahl der Methodenpaare (Mi,Mj) einer Klasse C mit Ähnlichkeitsgrad gleich 0] - [Anzahl der Methodenpaare von C mit Ähnlichkeitsgrad ungleich 0] Mit steigender Anzahl ähnlicher Methoden von C steigt die Kohäsion von C.

Metriken Gesichtspunkte: - Kohäsion von Methoden fördert Kapselung; - Geringe Kohäsion impliziert, daß die Klasse ein Kandidat für eine mögliche Aufsplittung in Subklassen ist. - Geringe Kohäsion vergrößert die Komplexität und erhöht dadurch die Wahrscheinlichkeit, daß Fehler während der Entwicklung begangen werden. - Geringe Ähnlichkeit von Methoden deutet auf einen schlechten Entwurf (genauer: schlechte Klassenstruktur) hin.

Metriken 5) Metriken, die ab frühen Phasen eingesetzt werden können:
5a) das FURPS+ Modell (von HP): Zweck: Organisation und Bewertung von QualitätsAttributen; meßbare Festlegung von Prioritäten; Anwendung: Katalog zur Festlegung von Zieleigenschaften des Produktes gemeinsam mit dem Kunden zu Beginn der Entwicklung; Planung der Erfüllung einzelner Attribute bei Meilensteinen; laufende Überprüfung der Erfüllung während des SW-Prozesses, z.B. im Laufe der Reviews;

Metriken - FURPS+ Functionality: Performance:
Feature Set Speed Capabilities Efficiency Generality Resource Consumption Security Throughput Response Time Usability: Supportability: Human Factors Testability Aesthetics Extensibility Consistency Adaptability Documentation Maintainability Reliability: Compatibility Frequency/Severity of Failure Configurability Recoverability Serviceability Predictability Installability Accuracy Localizability Mean Time to Failure

Metriken - QFD 5b) QFD - Quality Function Deployment
Ursprung: Bewertung von Hardware-Produkten in Japan wesentliche Merkmale: Repräsentation der “Stimme des Kunden” (“voice of the customer”) zur Angabe von Anforderungen (siehe linke Spalte des Graphen auf der nächsten Folie); Gewichtung der Anforderungen durch den Kunden (“customer value”, zweite Spalte); Anwendung und Form: QFD-Planungsmatrix - für Quantifizierung der Anforderungen an ein Produkt - zum quantitativen Vergleich der Attribute konkurrierender Produkte

Metriken - Beispiel eines QFD-Matrixdiagramms
(Grady, Abb. 4-2, S. 34)

Metriken - QFD (allgemeine) Kommentare zur QFD-Matrix: Kopfzeile: Auflistung der Design-Charakteristika des Produktes (ggf. auch des Vergleichsproduktes), “Product Features”; als Bewertung der Zusammenhänge zwischen Anforderungen und Produktmerkmalen dienen die Symbole: sehr starke Beziehung starke Beziehung schwache Beziehung die Spalte “Customer Value” gibt die maximale Bewertung vor; dieser Wert ist der gewünschte Wert als auch eine Gewichtung; die letzte Spalte quantifiziert das Ausmaß, zu welchem eine Anforderung erfüllt wird;

Metriken - QFD Kontext des Beispiels: - Planung von Upgrades eines Systems zur Unterstützung der Aufwandsbewertung und -berichterstattung; - die Anforderungen sind nach dem FURPS+ Schema aufgelistet; - Bsp.: die dritte Zeile: “track by phase ...” erhält im momentanen System die Bewertung 2 (von max. = 4); dieser Wert wird primär durch die starke Beziehung zu “ data collection sheets” erzielt; ein neues Attribut ist: “phase information” - dieser Zusatz würde zur maximalen Bewertung mit 4 führen; - Das momentane System (li. Teil der Matrix) hat in Summe nur 12 von 50 Punkten; das geplante Gesamtsystem (gesamte Matrix) wird mit 44 Punkten bewertet.

Metriken 6) Metriken für Aufwand und Kosten
Problematik: wie können Aufwands/Kostendaten ermittelt werden? Endziel: Feststellung des Gesamtkosten! Vorsicht bei Kostenvergleich: was alles ist neben der reinen Entwicklungszeit inkludiert? z.B. Urlaub, Kaffeepausen,... Bedeutung: i) Vorhersage der Kosten für neue Projekte aus Daten abgeschlossener Projekte; ii) wichtiger Managementaspekt; Preisgestaltung; Auswahl künftiger Projekte, ...

Metriken Unterscheidung: Mikro-Meßebene: einzelne Programmierer - kleines Projekt Messung: primär: Aufzeichnungen der Programmierer Makro-Meßebene: Prgrammierteams - große Projekte Produktivität in LOC/Zeiteinheit ist geringer; vergleiche: Geschwindigkeit bei 100 m Lauf und Marathon Zusatzaufwand für das Verstehen der Spezifikation, Abstimmen von Schnittstellenspezifikationen, Besprechungen,.. Messung: Formulare, Logs, On-line Erfassung; soll rasch gehen! Vorsicht bzgl. Über- und Unterschätzung bei Aufwand-Erhebungen, die auf einer Beurteilung der Entwickler beruhen! empfehlenswert: Trennung der Beurteilung von Personal vom Projektmanagementprozeß!

Metriken 7) Defekte und Zuverlässigkeit
Software hat (einen) Fehler, falls sie für korrekte Inputs falsche Resultate liefert. - Derselbe Fehler kann zu fehlerhaftem Verhalten für verschiedene Input Mengen führen. - Eine bestimmte Inputmenge kann mehrere Fehler aufdecken. Ein Defekt ist die Evidenz der Existenz eines Fehlers. Die Schätzung der Anzahl der Defekte in einer SW ist für das Management der Test- und Wartungsphase sehr bedeutsam. + Testaufwand, + Timing für Release, + Versionsplanung,... Voraussetzung für Schätzungen: Messung der Defekte

Metriken 7a) Defekte in Verlauf des Software Lebenszyklus’
Analysephase: Mißverständnisse bei der Formulierung der Anforderungen; Design: Ursachen für Defekte: falsches Verständnis der Anforderungen; Behebung: Erkenntnis der Inkonsistenz des Entwurfs mit der Spezifikation; entsprechende Reaktion; Kodierung: Ursachen: falsches Verständnis des Entwurfs, falsche Imple-mentierung, z.B. falsche Programmlogik, Datenstruktur, etc. Behebung: Änderung des Codes oder des Entwurfs: “What you really want is what I have written” .

Metriken Testphase: wichtig: umfassende, möglichst unabhängige Testfälle Behebung: Änderungen des Programmcodes. Wartung: Verwendung der SW: jeder Lauf bedeutet einen “Testfall”; Behebung: Änderung des Codes oder, im Falle hoch zuverläßiger SW, Änderung der Dokumentation! Bei Änderungen der Dokumentation ist oft unklar, ob die Ursache ein Fehler in der Dokumentation oder im Code ist. Ausgangspunkt für Defekt-Messungen: Fehler, die zu Design-, oder Code Änderungen führen.

Metriken 7b) Metriken zur Messung von Defekten in SW:
i) Anzahl der Änderungen im Design (alle Phasen) Zählung der einzelnen separaten Änderungen durch den Entwickler; ii) Anzahl der Fehler (ab Kodierungsphase) Messung: Anzahl der verschiedenen Fehlerberichte und ggf. Zählund durch Programmierer vor der Testphase iii) Anzahl der Programmänderungen (wegen Fehlern) Unter einer Programmänderung versteht man die Änderung einer zusammenhängenden Menge von Anweisungen, die eine abstrakte Aktion repräsentieren.

Metriken Absolute Werte der Defekt-Messungen haben wenig Aussagekraft: 5 Defekte in 100 LOC sind viel, in LOC jedoch wenig; daher: Normalisierung bedeutendste Metrik für den Vergleich der Defektanzahl: Defektdichte := Anzahl(Defekte)/Anzahl(KDSI) Vorsicht bei der Interpretation: eine niedrige Defektdichte kann verschiedene Ursachen haben: - gute Kodierung, - schwaches Testverfahren; weitere wichtige Charakterisierung von Defekten: Zeit für die Behebung (“time for repair”) und geschätzter Zeitaufwand für noch nicht behobene Defekte Art und Quelle des Defektes; Ausmaß der Auswirkung;

Metriken 7c) Software Zuverlässigkeit (“reliability”)
Neben der Anzahl der Defekte ist es wesentlich, die Zeitpunkte des Entdeckens zu vermerken, um die Zuverlässigkeit von SW bestimmen zu können. Annahme: die Entdeckung von Defekten ist ein stochastischer Prozeß; F(t) für t >= 0 .. Verteilung des Zeitintervalls t zwischen dem Aufdecken von Defekten; Interpretation von F(t): Wahrscheinlichkeit, daß während des Intervalls t ein Fehler auftritt;

Metriken Zuverlässigkeit .. R(t) = 1 - F(t); R(t) .. Wahrscheinlichkeit, daß während des Intervalls t kein Fehler auftritt; falls die SW nicht laufend im Einsatz ist, sollte t besser durch die Anzahl der Programmläufe ersetzt werden: dn .. Anzahl der Defekte in n Abläufen: R(n) := 1 - dn/n .. Wahrscheinlichkeit, daß in n Abläufen kein Fehler auftritt. weiteres Maß: mittlere Fehlerrate: MTTF “mean time to failure”

Metriken 7d) Folgerungen aus Defekt-Messungen:
Je früher ein Fehler entdeckt wird unso günstiger ist seine Behebung; - bis zu einem Faktor von 100 (Boehm, 1981); Folgerung: Rechtfertigung für Aufwand für Reviews; Managemententscheidung über die Einteilung der verfügbaren Zeit bei der Entwicklung; ggf. Verlängerung der Testphase, falls zahlreiche Fehler entdeckt werden, da deren Korrektur nach dem Release wesentlich teurer kommt. Intelligente Allokation von Resourcen während der Testphase: z.B.: Module mit hoher zyklomatischer Komplexität werden besonders gründlich getestet; ...

Metriken - Anwendung im PM (nach R. B. Grady, 1992)
Anwendungen von Metriken im SW-PM: Überblick: einige aus Messungen resultierende Daumenregeln als Denkanstöße für das PM; das Ziel/Frage/Metrik Paradigma; Metriken mit dem Ziel: - maximiere die Kundenzufriedenheit; - halte den Engineering Aufwand in vorgesehenen Grenzen; - minimiere Defekte. “Work-Product”-Analyse mit Hilfe von Tools

Metriken - Anwendung - Daumenregeln
ad Planung/Produktdefinition: - Projekte, die primär wiedervervendbare SW einsetzen, benötigen ca. ein Viertel der Zeit und Resourcen im Vergleich zu neuartigen Projekten. - die Aufwandsverteilung (Mittelwert aus 125 HP- Projekten) zwischen den Phasen beträgt in etwa: 18 % Anforderungsanalyse/Spezifikation; 19 % Design 34 % Kodierung 29 % Testen Abweichung für andere Organisationen: +/- 10 %

Design: % aller Design-Fehler können mit Design- Reviews/Inspektionen aufgedeckt werden. wichtig wegen hoher Kosten bei spätem Auffinden! - bei einem durchschnittlichen Projekt werden in einem Engineering-Monat 350 NCSS (non-comment source statements) produziert; die Engineering-Zeit beinhaltet die Aktivitäten in allen Phasen, die zur Produktion der ausgelieferten Codezeilen dienen) (Mittelwert aus 135 HP-Projekten)

Implementierung: - Module mit einer ZK (Zyklomatischen Komplexität) > 10 sind schwerer verständlich und haben eine höhere Fehlerwahrscheinlichkeit als Module mit niedrigerer ZK. Folgerung: besondere Beachtung bei Reviews und Tests! Test: - Typisches ad-hoc Testen ohne Messung der Code- Überdeckung testet nur ca. 55 % des Codes. Mit Instrumentierung bzgl. Code-Überdeckung kann die Überdeckung auf einfache Art auf 80 % gesteigert werden. Folgerung: Einsatz von Tools zur Messung der Code- Überdeckung zwecks einfachen Auffindens von nicht exekutierten Code-teilen. Einbringen weiterer Testfälle.

- Projekte, die primär aus wiederverwendbarem Code bestehen, weisen eine Defektdichte (#Defekte/Größe) von ca. einem Drittel jener von neuen Projekten auf. Wartung: - Der Aufwand für die Wartung/Erweiterung von SW ist ca mal so groß wie der Aufwand zur Erstellung neuer SW. - Für ca. 10 Defekte, die während des Testens gefunden werden, wird 1 Defekt nach dem Release gefunden. - Es benötigt ca mal soviel Zeit um Defekte in großen, reifen SW-Systemen zu beheben als diese Defekte vor, oder unmittelbar nach dem erstem Release zu korrigieren. Schlußkommentar zu Daumenregeln: Diskutiere, wofür Regeln solcher Art nützlich sind sowie die Folgerungen und nötige Anpassung an Unternehmenskontext.

Metriken - Anwendung - das ZFM Paradigma
Das Ziel/Frage/Metrik (ZFM) Paradigma: Zweck: Das ZFM Paradigma hilft sicherzustellen, daß die Auswahl und der Einsatz von Metriken von den Projekt- und Unternehmenszielen abgeleitet wird: Skizze: Ziel 1 Ziel Frage1 Frage Frage 3 Frage 4 Metrik1 Metrik2 Metrik3 Metrik Metrik5

Metriken - Anwendung - Beispiele
Anwendung des ZFM- Paradigmas - Beispiel 1: Ziel: Maximiere die Kundenzufriedenheit Frage: Anhand welcher Attribute kann Kundenzufriedenheit ermittelt werden? Metrik: FURPS+ , ggf. mit Prioritäten und Gewichtung; Frage: Welches sind die Indikatoren der Kundenzufriedenheit? Metriken: Daten aus Befragungen, QFD; Frage: Welche und wieviele Probleme treffen Kunden? Metriken: Rate eingebrachter Defekt-Berichte; Anzahl nicht behobener Defekte; post-release Defekt-Dichte; ...

Beispielgraph zur Verfolgung der Erfüllung von FURPS- Attributen im Projektverlauf: (Grady 1992, Abb.4-3, S.36)

Beispielgraph zur Veranschaulichung der Hereinkommenden Defekt-Berichte und deren Abschlüsse sowie des Fortschrittes bei der Korrektur (Grady 1992, Abb. 4-5, S. 37) Der Graph in der Abb. stellt die Gesamtsicht eines Unternehmens dar. Analoge Graphen können für einzelne Projekte (zwecks Überwachung, Aufwandschätzung,...) erstellt werden. (Grady 1992, Abb. 4-5, S. 37)

Anwendung des ZFM- Paradigmas - Beispiel 2: Ziel: Eingrenzung des Engineering-Aufwandes Frage: Welcher Aufwand wird für div. Aktionen benötigt? Metrik: Messung des Aufwandes, z.B. je Phase: aus dem Aufwand in frühen Phasen kann der Restaufwand geschätzt werden (vgl. %-Sätze in Daumenregel Nr. 2). Frage: Wie können Wartungskosten verringert werden? Metriken: (z. B.) - Messung der Wartbarkeit durch den Prozentsatz an Moduln, die bei einem Fehler betroffen sind; - post-release Defektraten; - Code-Überdeckung beim Testen Frage: Sind Reviews/Inspektionen/.. effektiv? Metrik: Messung des Aufwandes versus “Erfolges” für obige Aktivitäten: siehe Graph auf nächster Folie;

Beispielgraph zur Verfolgung der Effektivität von Code-Inspektionen; Kommentar: nach jeder Inspektion wird die Anzahl der gefundenen Defekte mit 5 h multipliziert (i.e. untere Schranke des Auffindens und Korrigierens eines Fehlers beim Testen). Davon wird der Aufwand für die Inspektion subtrahiert. Werte über der Null-linie deuten auf effektive Inspektionen hin. (Grady, Abb. 5-4, S. 45)

Anwendung des ZFM- Paradigmas - Beispiel 3: Ziel: Minimierung von Defekten These: Sammle und verwende detailliere Information über Defekte, um Release-Entscheidungen zu fällen! Frage: Wann werden welche Fehler begangen? Metriken: Kategorisierung von Fehlern nach deren Entstehung/Art Frage: Mit wievielen post-release Defekten ist zu rechnen? Metriken: - Prozentsatz der Zweigüberdeckung beim Testen; - Anzahl der gefundenen Fehler beim Testen; - Anzahl der Fehler je Modul; - Anzahl der durch einen Fehler betroffenen Module, etc.

Beispielgraph zur Analyse von Defekten je Modul: (Grady 1992, Abb.6-5, S. 61) Folgerungen aus der Defekt-Analyse: 3 von 13 Moduln sind für 76% der Defekte vor dem Release “verantwortlich”. 6 monate nach dem Release ist die Situation ähnlich. Konsequenz: gründlicheres Testen bzw. (längerfristig) Umschreiben dieser Module; höchste Vorsicht bei Erweiterungen dieser Module und bei Änderungen, die diese Module betreffen

Graph zum Vergleich der Effektivität von Testtechniken: (Grady 1992, Abb. 6-4, S. 60)

Kommentar zum Vergleich von Testtechniken (s. Folie): 6 bekannte Testtechniken wurden auf fixierte Zustände von zwei fertiggestellten SW-Projekten angewendet. Resultat: Signifikante Differenzen zwischen den Techniken sowohl auf der Unit-Ebene als auch auf der Ebene des Konfigurierten Source-Codes (CSC). Jede Säule zeigt den Prozentsatz der Gesamt-Fehleranzahl bei der Anwendung eines Testverfahrens an. Einige Fehler wurden von mehreren Testverfahren aufgedeckt. Es gilt als wahrscheinlich, daß andere Projekte zu verschiedenen Säulenhöhen je Test führen. Jedoch: gesicherte Konsequenz: für effektives Testen sollten mehrere Testverfahren eingesetzt werden!!!

Graph zum Aufzeigen des Zusammenhanges der Strukturellen Komplexität (Fan-out2/10) und der Defekt-Dichte in einem speziellen Projekt. (Grady 1992, Abb.7-12, S.80) Konsequenzen: Messung der Design-Komplexität können für Fehler-Verhersagen verwendet werden. Entsprechende Module können z.B. besonders gründlich getestet werden.

Metriken - Anwendung - Work-Product-Analyse
Ein “Work-Product” ist ein textueller oder graphischer Output einer SW-Entwicklungsaktivität, z. B. ein Klassendiagramm, Datenflußdiagramm, Package-Diagramm, Programmflußgraph eines Moduls, Pseudocode einer Prozedur, Code, Unit-test Manual, Ergebnisse des Integrationstests, etc. . Bedeutung von Work-Products: - Standardisierte Repräsentation, die ein starkes Ausmaß an gemeinsamer Terminologie aufweist; Folgerung: bessere, allgemeine Verständlichkeit und teilweise Analysierbarkeit durch automatisierte Tools;

- Toolunterstützung erlaubt automatisierte Checks, die Feedback für Entwickler als auch für Manager bieten; kein (oder minimaler) Zusatzaufwand für Messungen ausgewählter Attribute und aufbereitete Darstellungen zwecks Beurteilung der Qualität. - Gemeinsame Terminologie erleichtert Inspektionen/ Reviews der Work-Products zwecks Auffindens jener Probleme, die automatisierte Tools nicht erkennen. - Automationsunterstützte Berechnung von Werten für ausgewählte Metriken und übersichtliche Repräsentation; Unterstützung der Überprüfung und Visialisierung des Projektfortschrittes z.B. für Managementberichte. Anmerkung: die Work-Product-Analyse ist ein wesentlicher Aspekt des Einsatzes von CASE-Tools.

Beispiele: - Code-Analyse ermöglicht Bestimmung der LOC, Anz. der vorkommenden Operatoren/Operanden; - Analyse des Programmflußgraphen ermöglicht die Berechnung der Zyklomatischen Komplexität: links: Graph mit akzeptabler ZK; rechts: zu hohe ZK (Grady Abb. 8-2 und 8-3, S. 88)

Beispiele - Fortsetzung: - typische Ergebnistabelle zur Analyse der Zweigüberdeckung beim Testen einzelner Prozeduren: Grady, Abb. 8-5, S. 90

Projektmanagement Techniken - Einsatz von Metriken

Ähnliche Präsentationen

Präsentation zum Thema: "Projektmanagement Techniken - Einsatz von Metriken"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Projektmanagement Techniken - Einsatz von Metriken

Ähnliche Präsentationen

Präsentation zum Thema: "Projektmanagement Techniken - Einsatz von Metriken"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback