Kapitel 8 - Software-Metriken

Software-Metriken

• Messen von verschiedenen Aspekten, um diese verständlicher darzustellen
• Metriken für Produktivität
• Versucht Voraussagen zu erleichten
• Wie war die Produktivität bei vorangegangenen Projekten?
• Wie kann vergangene Produktivität auf aktuelle Projekte extrapoliert werden?
• Helfen den technischen Prozess der für Produktion verwendetet wird und das Produkt selbst, zu verstehen
• Messungen finden statt um das Produkt zu verbessern
• Notwendig für Planung, Kosten -> Abschätzungen möglich

Gründe fürs Messen

• Qualität eines Produktes bestimmen
• Produktivität der Angestellten überprüfen
• Den Nutzen neuer SE-Tools und Vorgehensweisen untersuchen
• Baseline für Abschätzungen schaffen

Direktes und indirektes Messen

• Lines Of Code (LOC or KLOC)
• Ausführungsgeschwindigkeit
• Speicherverbrauch
• Gemeldete Defekte / Zeitperiode

• Funktionalität
• Qualität
• Komplexität
• Wartung

Kategorien von Software-Metriken

• Produktivitäts-Metriken (Fokus auf SE Prozess)
• Qualitäts-Metriken (Wie nah ist Produkt an Kundenanforderungen)
• Technische Metriken (Fokus auf Produkt selbst, z.B. Modularität)
• Größen-Orientierte Metriken( Direkte Messwerte)
• Funktionsorientierte Metriken (Indirektes Metriken)
• Meschenorientierte Metriken (Informationen über die Arbeitnehmer die es produzieren)

Größe-orientierte Metriken

• Direkte Messungen welche mit Entwicklung korrespondieren
• Produktivität = KLOC / person-month
• Qualität = Fehler / KLOC
• Kosten = $ / KLOCK
• Dokumentation = Seitenanzahl / KCLOC
• Vorteil: einfach zu messen

• Nicht als bester Weg zum Messen aktzeptiert
• Sprachabhängig
• Planer muss LOC abschätzen, lange vor Analyse abgeschlossen ist

Funktionsorientierte Metriken

• Indirekte Messungen der Software und des Prozesses mit Fokus auf Programmfunktionalität
• Empirische Beziehungen basieren auf zählbaren Messungen

• Number Of Inputs
• Number Of Outputs
• Number Of Files
• Number Of External Interfaces
• Ergebnis: Total Count

Function-Points-Methode

• FP = Gesamtanzahl * [ 0.65 + 0.01 Sum(1..14)(Fi)]
• Fi sind Faktoren zwischen 0 und 5, welche die Semantik und Komplexität des Problems beschreiben
• 0.65 und 0.01 sind empirische Konstanten
• 1 bis 14 sind 14 verschiedene Aspekte wie z.B
• F1 : Benötigt das System Backup und Revovery
• F2 : Ist die Performance kritisch?
• F3 : Soll der Code wiederverwendbar sein?
• Produktivität = FP / Person-Month (Analog zu Size-Orienten direktem Messen)

Feature-Points-Methode

• Erweiterung der Function-Point-Methode in zusätzlicher algorithmischer Betrachtung
• Count-Total beinhaltet außerdem eine Abschätzung der Algorithmenkomplexität
• Sprachunabhängig und basiert auf Daten früh aus der Evolution

• Subjektive Abschätzungen
• keine dirkte physikalische Bedeutung
• Daten schwer sammelbar sind

Metriken und Sprachen

• Assembler (300)
• FORTRAN (100)
• Pascal (90)
• Code Generatoren (15)

Argumente für Software-Metriken

• Welche Nutzeranforderungen ändern sich am häufigsten?
• Welche Module im System sind am Fehleranfälligsten?
• Wieviel Testzeit muss für jedes Modul eingeplant werden?
• Wieviele Fehler kann ich beim Testen durchschnittlich erwarten?
• Schwierigste Part ist das Datensammeln

Wie kann die Qualität von Software definiert werden?

• Konformität zu vorher spezifizierter Funktionalität und Performanceanforderungen
• Qualität wird also über die Anforderungen gemessen
• Standards geben heute vor, welche Aspekte immer erfüllt sein müssen
• Implizite Qualitätsanforderungen auch wichtig (wie z.B. gute Wartbarkeit)

Faktoren der Software-Qualität

• KLOC (direktes Messen)
• Nutzbarkeit, Wartbarkeit... (Indirekte Messwerte)

Messen der Qualität

• Jede Softwarequalitätsmessung kann nur unvollständig sein
• Die Wortanzahl einer verbalen Beschreibung der Funktionaliät kann als Indikator für Komplexität benutzt werden(Umso mehr Wörter, desto schwerer zu Komplexer)
• Wie viele Sprünge im Code? -> Wie ist der Testaufwand?
• Modulaufrufe anderer Module -> Wartbarkeit
• Zugriff auf globale Daten oder lokale Variablen geben Auskunft über Verständlichkeit des Codes
• Anzahl an nicht standartisierten Features -> Portabilität

Testplan

• Für Qualitätskontrolle wird Testplan benötigt
• Kontrakt zwischen Kunden und Entwickler und Entwickler und Qualitätssicherungsteam

Audit

• Qualitätssicherungsleute prüfen das Tests sinnvoll durchgeführt

Software-Reviews

• Reviews werden an verschiedenen Punkten in Entwicklungsprozess gemacht
• Sollen Fehler aufdecken, um diese so früh wie möglich eliminieren zu können
• 50-60 % aller fehler entstehen schon im Entwurf (Reviews reparieren bis zu 75 % dieser Fehler)

Kosten von Fehlern in der Software

• Steigen exponentiell mit Fortschreiten der Entwicklung
• Kosten während Entwuf = 1, während Tests 15 und nach Release 60-100

Fehlervermehrung im Lauf der Softwareentwicklung

• Fehler aus jeder Phase werden an die nächste weitergegeben
• In dieser entstehen nun wieder neue Fehler
• Ohne Reviews kaum Fehler in Spezifikation und Entwurf entdeckt
• Mit Reviews werden ¾ der Fehler erkannt und behoben, da schon im Entwurf "getestet" wird

Qualitätszertifikat

• ISO 9001 ist nicht industriebezogen
• ISO 9003 von 9001 für Software abgeleitet
• 20 Hauptmerkmale werden behandelt, wie Document control, Design control, Process control, Training, Contract review, Quality system
• Zertifikat welches Kunden versichert, daß Firma nach Standarts arbeitet

Software-Metriken und Software-Qualität

• Immer unvollständig
• Teilweise individuelle Einschätzung
• Zum Teil nur indizierte, abgeleitete Angaben über Qualität

• Anzahl von Branches -> Testbarkeit
• Zugriff auf globale Variablen -> geringe Wartbarkeit des Systems
• Anzalh lokaler Variablen -> aufwendiges Debuggen
• Nicht-standart-Features -> Portabilität

McCabe's zyklomatische Komplexität

• Hypothese: Komplexität hängt von Komplexität des Kontrollflußgraphen ab (Program Graph)
• Experimente zeigen Beziehungen zwischen McCabe's Metrik und Anzahl an Fehlern im Source Code (und der Zeit diese zu korrigieren)
• V(G) ist Indikator für maximale Modulgröße und sollte bestimmten Wert nicht überschreiten, sonst schwer zu testen
• Problem: Metrik sehr spät im Software Projekt gemessen
• Deshalb müssen Metriken gefunden werden, die schon im Entwurf messen können

Metriken für den Entwurf

• Grundidee ist, daß externe Komplexität eines Moduls in Verbindung mit Anzahl an Flüssen (in/export) zwischen Modul und Umwelt steht
• Interne Kompexität = LOC

• Direkt => Modul A gibt parameter zu B
• Indirekt => Modul A gibt Wert zu B zurück

• Modul A schreibt DS und Modul B liest vom DS
• Fan-In / Fan-Out (alles was reingeht und rauskommt egal ob lokal oder global)
• Complexity = length * (fi * fo)2

Anwendung von Metriken

• Filter, welcher die komplexesten Module identifiziert
• Zum Untersuchen von Entwicklermethoden
• Untersuchen der steigenden Komplexität während der Wartung
• Die Teile / Module finden die die meisten Fehler / Arbeit machen -> Redesign + Reimplementation