Konzept: Metriken
Metriken sind Zahlen, die als Messkriterien für den Qualitätsstandard beim Vergleich verschiedener Elemente oder Zeiträume verwendet werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Warum werden Messungen durchgeführt?

Wir führen Messungen hauptsächlich durch, um Kontrolle über ein Projekt zu haben und damit in der Lage zu sein, es zu verwalten. Wir führen Messungen durch, um festzustellen, wie nah bzw. wie weit entfernt wir von den Zielsetzungen sind, die wir uns in unserem Plan in Bezug auf Fertigstellung, Qualität, Konformität mit Anforderungen usw. gesetzt haben.

Wir führen Messungen auch durch, um in der Lage zu sein, auf der Basis der in der Vergangenheit gewonnenen Erfahrungen bessere Schätzungen für Aufwand, Kosten und Qualität abgeben zu können. Und schließlich führen wir Messungen durch, um bewerten zu können, welche Verbesserungen wir im Laufe der Zeit in einigen Schlüsselaspekten der Prozessleistung erzielen und damit welche Auswirkungen Änderungen haben.

Die Kosten, die Messungen verschiedener Schlüsselaspekte eines Projekts verursachen, sind nicht unerheblich. Deshalb es nicht sinnvoll, einfach alles zu messen, nur weil man es kann. Wir müssen sehr präzise Ziele für diese Messungen setzen und nur solche Metriken erfassen, die uns erlauben, diese Ziele zu erreichen.

Es gibt zwei Arten von Zielen:

  1. Kenntnisziele: Dafür werden Verben wie auswerten, bewerten, vorhersagen, überwachen verwendet. Sie möchten den Entwicklungsprozess besser verstehen. Sie möchten z. B. die Produktqualität beurteilen, Daten für die Tests erfassen, den Testumfang überwachen oder Änderungsanfragen protokollieren.
  2. Änderungs- oder erreichte Ziele: Diese Ziele werden mit Verben wie erhöhen, reduzieren, verbessern, erreichen oder beenden beschrieben. Gewöhnlich sind Sie daran interessiert zu verfolgen, wie sich die Dinge mit der Zeit zwischen zwei Iterationen oder zwei Projekten ändern oder verbessern.

Beispiele:

  • Fortschritt in Bezug auf den Plan überwachen
  • Kundenzufriedenheit verbessern
  • Produktivität verbessern
  • Vorhersagbarkeit verbessern
  • Wiederverwendung erhöhen

Diese allgemeinen Managementziele lassen sich nicht direkt in Metriken umsetzen. Wir müssen sie in mehrere kleinere Teilziele (oder Aktionsziele) umsetzen, die die Aktionen festlegen, die die Projektmitarbeiter ausführen müssen, um das Ziel zu erreichen. Außerdem müssen wir sicherstellen, dass die involvierten Personen die Vorteile verstehen.

Beispiele

Das Ziel "Kundenzufriedenheit verbessern" könnte sich wie folgt zerlegen lassen:

  • Kundenzufriedenheit bestimmen
  • Kundenzufriedenheit über mehrere Releases hinweg messen
  • Sicherstellen, dass die Zufriedenheit steigt

Das Ziel "Produktivität verbessern" könnte sich wie folgt zerlegen lassen:

  • Aufwand messen
  • Fortschritt messen
  • Produktivität über mehrere Iterationen oder Projekte hinweg berechnen
  • Ergebnisse vergleichen

Anschließend müssen für einige der Teilziele (aber nicht alle) verschiedene Metriken erfasst werden.

Beispiel

"Kundenzufriedenheit messen" kann beispielsweise abgeleitet werden aus

  • der Kundenübersicht (in der Kunden Noten für verschiedene Aspekte verteilen),
  • der Anzahl und der Wertigkeit der Anrufe bei der Hotline für Kundenunterstützung.

Weitere Informationen hierzu finden Sie in [AMI95].

Es ist sinnvoll, diese Ziele nach Organisation, Projekt und technischen Anforderungen zu kategorisieren. Auf diese Weise erhalten Sie ein Gerüst für die zuvor beschriebene Präzisierung.

Bedarf eine Organisation an Metriken

Eine Organisation muss ihre Kosten pro 'Einheit' kennen und möglicherweise verbessern, ihre Build-Zeiten (Markteinführung) verkürzen, wenn sie ein Produkt mit bekannter Qualität (objektiv und subjektiv) und entsprechendem Wartungsbedarf liefern möchte. Eine Organisation muss unter Umständen von Zeit zu Zeit (oder sogar ständig) ihre Leistung verbessern, um wettbewerbsfähig zu bleiben. Um ihre Risiken mindern zu können, muss eine Organisation die Qualifikationsstufe und die Erfahrung ihrer Mitarbeiter kennen und sicherstellen, dass sie weitere Ressourcen und Fähigkeiten bereitstellen kann, um im ausgewählten Umfeld wettbewerbsfähig zu sein. Eine Organisation muss in der Lage sein, neue Technologie einzuführen und die Kostenvorteile dieser Technologie bestimmen zu können. In der folgenden Tabelle sind einige Beispiele für die Arten von Metriken aufgeführt, die in dieser Hinsicht für eine Softwareentwicklungsorganisation von Relevanz sind.

Problemstellung

Metrik

Kosten pro Einheit Kosten pro Codezeile, Kosten pro Funktionspunkt, Kosten pro Anwendungsfall. Normalisierter Aufwand (in einem definierten Zeitraum des Lebenszyklus, Programmiersprache, Mitarbeiterqualifikation usw.) pro Codezeile, Funktionspunkt oder Anwendungsfall. Diese Metriken sind gewöhnlich nicht einfach Zahlen. Sie richten sich nach der Größe des zu liefernden Systems und nach der Enge des Zeitplans.
Konstruktionszeit Pro Codezeile oder Funktionspunkt benötigte Zeit. Auch dies richtet sich nach der Größe des Systems. Der Zeitplan kann auch durch Aufstocken des Personals gestrafft werden. Dies ist jedoch nur bis zu einem gewissen Punkt möglich. Wo die Grenze liegt, wird durch die Managementfähigkeiten der Organisation bestimmt.
Mängeldichte im gelieferten Produkt (Nach Lieferung) festgestellte Mängel pro Codezeile oder Funktionspunkt.
Subjektive Qualität Benutzerfreundlichkeit, Anwendungsfreundlichkeit, Benutzerakzeptanz. Obwohl diese Aspekte nicht scharf zu fassen sind, wurden Methoden für den Versuch einer Quantifizierung entworfen.
Wartungsfreundlichkeit Kosten pro Codezeile oder Funktionspunkt pro Jahr.
Qualifikationsprofil, Erfahrungsprofil Die Personalabteilung führt in der Regel eine Datenbank mit Informationen zu Know-how und Erfahrung ihrer Mitarbeiter.
Technologische Fähigkeiten
  • Tools - Eine Organisation muss wissen, welche Technologien im allgemeinen Einsatz sind und wie hoch das Fachwissen in Bezug auf die Technologien ist, die nicht regelmäßig verwendet werden.
  • Prozessreife - Wo steht die Organisation beispielsweise auf der SEI-CMM-Skala?
  • Fähigkeiten im Fachgebiet - In welchen Anwendungsbereichen kann die Organisation agieren?
Messungen zur Prozessverbesserung
  • Zeit- und Arbeitsaufwand für die Prozessausführung
  • Mängelraten, kausale Analysestatistiken, Fehlerbehebungsrate, Ausschuss und Nacharbeiten

Bedarf eines Projekts nach Metriken

Ein Projekt muss die folgenden Bedingungen erfüllen, damit es ausgeliefert werden kann:

  • erforderliche funktionale und nicht funktionale Fähigkeiten
  • verschiedene technische Vorgaben
  • finanzielle und terminliche Vorgaben
  • bestimmte Übergangs-, Betriebs- und Wartungsmerkmale

Der Projektleiter muss feststellen können, ob er auf dem richtigen Weg ist, seine Ziele zu erreichen. Beispiele für solche Ziele sind in der folgenden Tabelle aufgelistet, um Ihnen eine Idee davon zu geben, was beim Nachdenken über Projektkontrollen berücksichtigt werden muss.

Problemstellung

Projektaufwand und -budget
  • Wie entwickelt sich das Projekt in Bezug auf Aufwand und Kosten gegenüber der Planung?
Projektzeitplan
  • Erreicht das Projekt seine Meilensteine?
Übergang/Installation
  • Sind die erwarteten Anforderungen bezüglich Aufwand, Kosten und Know-how akzeptabel?
Betrieb
  • Sind die erwarteten Anforderungen in Bezug auf Aufwand und Know-how für den Kunden tragbar?
Wartung/Servicefreundlichkeit
  • Sind die erwarteten Anforderungen in Bezug auf Aufwand und Know-how für den Kunden akzeptabel?
Funktionale Anforderungen
  • Sind die Anforderungen gültig und vollständig?
  • Sind die Anforderungen einer Iteration zugeordnet?
  • Werden die Anforderungen plangemäß realisiert?
Nicht funktionale Anforderungen
  • Leistung
    • Erfüllt das System die Anforderungen an Reaktionsfähigkeit, Durchsatz, Wiederanlaufzeit?
  • Kapazität
    • Kann das System die erforderliche Anzahl gleichzeitiger Benutzer bewältigen? Kann die Website die erforderliche Anzahl von Treffern pro Sekunde bewältigen? Ist genügend Speicher für die erforderliche Anzahl von Kundenstammdaten verfügbar?
  • Qualitätsfaktoren
    • Zuverlässigkeit: Wie häufig darf eine Systemstörung auftreten und wie wird eine Systemstörung definiert?
    • Benutzerfreundlichkeit: Ist das System einfach und intuitiv zu verwenden? Wie lang ist die Einarbeitungszeit und welches Know-how ist erforderlich?
    • Fehlertoleranz/Stabilität/Belastbarkeit/Überlebensfähigkeit: Funktioniert das System auch noch, wenn Störungen auftreten? Kann das System mit fehlerhaften Eingaben umgehen? Kann das System nach einer Störung automatisch wiederhergestellt werden?
  • Spezielle Engineering-Anforderungen
    • Sicherheit: Kann das System ohne Gefahr für Leben oder Einrichtungen (direkt oder indirekt) betrieben werden?
    • Datenschutz/Vertraulichkeit: Schützt das System sensible Daten vor unbefugtem Zugriff? Kann das System zerstörerische Angriffe abwehren?
    • Umweltbelastung: Erfüllt das System die Umweltschutzauflagen?
  • Weitere behördliche oder gesetzliche Anforderungen
  • Vorgaben
    • Äußere Umgebung: Kann das System in der vorgeschriebenen Umgebung betrieben werden?
    • Ressourcen, Host, Ziel: Entspricht das System die Vorgaben bezüglich CPU, Hauptspeicher, Sprache, Hardware-/Softwareumgebung?
    • Verwendung gebrauchsfertiger (COTS, Commercial-off-the-Shelf) oder anderer vorhandener Software: Erfüllt das System seine Vorgaben für Wiederverwendung?
    • Mitarbeiterverfügbarkeit und -Know-how: Kann das System mit den verfügbaren Mitarbeitern (Anzahl und Typ) erstellt werden?
    • Schnittstellenunterstützung/Kompatibilität: Kann das System die erforderlichen Zugriffe auf und von anderen Systemen unterstützen?
    • Wiederverwendbarkeit: Welche Vorkehrungen wurden getroffen, um das System wiederverwendbar zu machen?
    • Vorgegebene Standards: Sind das System und die Entwicklungsmethode kompatibel?
    • Andere Designvorgaben (z. B. Architektur, Algorithmen): Verwendet das System den erforderlichen Architekturstil? Werden die vorgeschriebenen Algorithmen verwendet?

Dies ist zwar eine ausführliche, aber keine erschöpfende Liste der Problemstellungen für den Projektleiter. Einige dieser Problemstellungen erfordern die Erfassung und Analyse von Metriken, und einige sogar die Entwicklung spezieller Tests (um Messwerte abzuleiten), damit die gestellten Fragen beantwortet werden können.

Bedarf an Metriken aus technischer Sicht

Für viele Projektanforderungen gibt es keine direkten Messwerte und selbst für diejenigen, für die es welche gibt, ist es möglicherweise nicht klar, was getan bzw. geändert werden muss, um diese zu verbessern. Anstelle verschiedener Qualitätsattribute der höheren Ebene wie der im ISO-Standard 9126 (Softwarequalitätsmerkmale und -metriken) und zuvor im Abschnitt "Projektanforderungen" angegebenen können Qualitätsmerkmale der unteren Ebene verwendet werden, um Qualität zu erzeugen. Diese technischen Messwerte haben Engineering-Charakter (strukturell und verhaltensbezogen) und -Auswirkungen (für Prozess und Produkt), die zu den Metrikanforderungen auf Projektebene beitragen. Die Attribute in der folgenden Tabelle wurden verwendet, um eine Beispielsammlung von Metriken für RUP-Arbeitsergebnisse und den RUP-Prozess abzuleiten. Weitere Informationen hierzu finden Sie in  Richtlinie für Arbeitsergebnis: Metriken.

Qualität

Attribute

Tauglichkeit der Anforderungen
  • Unbeständigkeit: Änderungshäufigkeit, Einführungsrate neuer Anforderungen
  • Gültigkeit: Handelt es sich um die richtigen Anforderungen?
  • Vollständigkeit: Fehlen irgendwelche Anforderungen?
  • Richtigkeit der Beschreibung: Sind die Anforderungen richtig beschrieben?
  • Klarheit: Sind die Beschreibungen verständlich und unmissverständlich?
Tauglichkeit des Designs
  • Kopplung: Wie weitreichend sind die Verbindungen zwischen den Systemelementen?
  • Kohäsion: Haben die Komponenten jeweils einen einzigen, klar definierten Zweck?
  • Primitivität: Können die Methoden und Operationen einer Klasse aus anderen Methoden oder Operationen der Klasse erstellt werden? Wenn ja, sind die Methoden und Operationen nicht primitiv (wünschenswertes Merkmal).
  • Vollständigkeit: Werden die Anforderungen durch das Design vollständig realisiert?
  • Unbeständigkeit: Häufigkeit von Architekturänderungen.
Tauglichkeit der Implementierung
  • Größe: Wie nahe ist die Implementierung an der Mindestgröße (für die Problemlösung)? Entspricht die Implementierung den Vorgaben?
  • Komplexität: Ist der Code algorithmisch schwierig oder kompliziert? Ist er schwierig zu verstehen und zu ändern?
  • Vollständigkeit: Stellt die Implementierung eine getreue Realisierung des Designs dar?
Tauglichkeit des Tests
  • Abdeckung: Wie gut stellt der Test die Software auf die Probe? Werden alle Anweisungen von den Tests ausgeführt? Exerziert der Test viele Pfade durch den Code?
  • Gültigkeit: Sind die Tests selbst eine korrekte Reflexion der Anforderungen?
Tauglichkeit des Prozesses (niedrigste Ebene)
  • Mängelrate, Mängelursache: Wie häufig treten Mängel in einer Aufgabe auf und was sind die Ursachen?
  • Aufwand und Dauer: Wie lange dauert eine Aktivität und wie viel Personalaufwand ist erforderlich?
  • Produktivität: Wie ist der Ertrag einer Aktivität pro Mitarbeiter?
  • Tauglichkeit der Arbeitsergebnisse: Wie ist die Mängelrate in den Ausgaben einer Aufgabe?
Effektivität von Prozess-/Tooländerungen (dieselben Attribute wie bei Tauglichkeit des Prozesses, allerdings werden hier prozentuale Änderungen und keine absoluten Werte verwendet):
  • Mängelrate, Mängelursache
  • Aufwand und Dauer
  • Produktivität
  • Tauglichkeit der Arbeitsergebnisse

Eine ausführliche Beschreibung der Metrikkonzepte finden Sie in [WHIT97].

Was ist eine Metrik?

Wir unterscheiden zwischen zwei Arten von Metriken:

  • Eine Metrik ist ein messbares Attribut einer Entität. Der Projektaufwand ist beispielsweise ein Messwert (d. h. eine Metrik) für die Projektgröße. Um diese Metrik berechnen zu können, müssen Sie alle Einträge in den Arbeitszeittabellen für das Projekt zusammenzählen.
  • Eine primitive Metrik ist ein Rohdateneintrag, der für die Berechnung einer Metrik verwendet wird. Im zuvor genannten Beispiel sind die Einträge in der Arbeitszeittabelle die primitiven Metriken. Eine primitive Metrik ist normalerweise eine Metrik, die in einer Datenbank enthalten, aber nicht isoliert für Auswertungen herangezogen wird.

Jede Metrik setzt sich aus einer oder mehrere erfassten Metriken zusammen. Deshalb muss jede primitive Metrik klar identifiziert und ihre Erfassungsprozedur klar definiert werden.

Metriken für die Unterstützung von Änderungs- oder Erfolgszielen sind häufig "erste Ableitungen" über der Zeit (oder über Iterationen oder über das Projekt). Wir sind an einem Trend und nicht an einem absoluten Wert interessiert. Zur "Verbesserung der Qualität" müssen wir prüfen, ob sich der Restbestand bekannter Mängel mit der Zeit verringert.

Vorlagen

Vorlage für eine Metrik

Name Name der Metrik und alle bekannten Synonyme.
Definition Die Attribute der Entitäten, die mit dieser Metrik gemessen werden, wie die Metrik berechnet wird und welche primitiven Metriken als Kalkulationsgrundlage dienen.
Ziele Liste der Ziele und Fragen, die sich auf diese Metrik beziehen, und ein Grund für die Erfassung dieser Metrik.
Analyseprozedur Wie soll die Metrik verwendet werden. Vorbedingungen für die Interpretation der Metrik (z. B. gültiger Bereich anderer Metriken). Zielwerte oder Trends. Modelle zu verwendender Analysetechniken und Tools. Implizite Annahmen (z. B. der Umgebung oder Modelle). Kalibrierungsprozeduren. Speicher.
Zuständigkeiten Wer erfasst und aggregiert die Messdaten, bereitet die Berichte vor und analysiert die Daten.

Vorlage für eine primitive Metrik

Name Name der primitiven Metrik
Definition Unmissverständliche Beschreibung der Metrik in Bezug auf die Projektumgebung
Erfassungsprozedur Beschreibung der Erfassungsprozedur. Zu verwendendes Datenerfassungstool und -formular. Punkte im Lebenszyklus, an denen Daten erfasst werden. Zu verwendende Prüfprozedur. Wo werden die Daten gespeichert, Format und Genauigkeit.
Zuständigkeiten Wer ist für die Erfassung der Daten verantwortlich. Wer ist für die Prüfung der Daten verantwortlich.

Metrikaufgaben

Es gibt zwei Aufgaben:

  • Projektkontrollplan definieren
  • Messwerte erfassen

Der Projektkontrollplan wird einmal pro Entwicklungszyklus definiert und zwar in der Konzeptionsphase im Rahmen der allgemeinen Planungsaktivität oder manchmal im Rahmen der Konfiguration des Prozesses im Entwicklungsfall. Der Projektkontrollplan kann wie jeder andere Abschnitt des Softwareentwicklungsplans im Verlauf des Projekts nochmals bearbeitet werden.

Die Erfassung der Messwerte ist ein sich wiederholender Vorgang, der mindestens einmal pro Iteration durchgeführt wird, manchmal auch häufiger, z. B. wöchentlich in einer Iteration, die sich über mehrere Monate erstreckt.

Die erfassten Metriken sind Teil des Statusbewertungsdokuments und werden zur Bewertung des Fortschritts und des Zustands des Projekts herangezogen. Sie können auch für spätere Verwendung in Projekteinschätzungen und Trends in der Organisation gesammelt werden.

Wie werden die Metriken verwendet?

Schätzung

Insbesondere der Projektleiter ist mit Planungsaufgaben betraut. Er muss Aufgaben Ressourcen mit Budgets und Zeitplänen zuordnen. Entweder werden Aufwand und Zeitplan anhand einer Beurteilung dessen, was erzeugt werden soll, geschätzt, oder es gibt fixe Ressourcen und einen festen Zeitplan, und es muss eine Schätzung abgeliefert werden, was erzeugt werden kann. Schätzungen beziehen sich normalerweise für Planungszwecke auf die Berechnung des Ressourcenbedarfs basierend auf anderen Faktoren, z. B. Größe und Produktivität.

Vorhersage

Vorhersagen unterscheiden sich nur geringfügig von Schätzungen und beziehen sich gewöhnlich auf die Berechnung des künftigen Werts eines Faktors basierend auf dem aktuellen Wert dieses Faktors und anderer maßgeblicher Faktoren. Wenn Sie beispielsweise eine Probe von Leistungsdaten haben, ist es hilfreich zu wissen (prognostizieren), wie sich das System unter voller Last oder in einer Konfiguration mit beschränkten oder weniger leistungsstarken Ressourcen verhält. Vorhersagemodelle für Zuverlässigkeit verwenden Daten zu Mängelraten, um vorherzusagen, wann das System bestimmte Zuverlässigkeitsstufen erreichen wird. Nach der Planung einer Aktivität benötigt der Projektleiter Daten, auf deren Basis er Fertigstellungszeiten und Aufwand bei Fertigstellung vorhersagen kann.

Bewertung

Bewertungen werden verwendet, um die aktuelle Position für einen Vergleich mit einem Schwellenwert, die Ermittlung von Trends, für den Vergleich zwischen Alternativen oder als Basis für Schätzung oder Vorhersage zu bestimmen.

Weitere Informationen zu Metriken im Projektmanagement finden Sie in [ROY98].