Glauben ist gut – wissen ist besser: Methoden zur Messung des Softwareumfangs

Eine zukunfts- und wettbewerbsfähige Softwareentwicklung ist ohne Produktivitätsmessungen nicht möglich. Doch wie lässt sich der Umfang einer Software messen?

Nur wer den Output seines Systems kennt, kann die Entwicklungsproduktivität messen und dadurch zuverlässige Aufwandsaussagen für künftige Projekte treffen.

In den letzten Jahrzehnten wurden verschiedenste Messmethoden entwickelt – grundsätzlich lassen sich zwei Grundkonzepte unterscheiden:

  • Code-Metriken: In den 70er Jahren wurden Codezeilen oder Anweisungen gezählt. Bekannt sind mehrere Varianten der Lines-of-Code-Metrik. Codebasierte Metriken messen die Größe eines Programms und sind daher stark von Programmiersprache und -stil abhängig. Für eine Vorab-Bestimmung des zu erwartenden Aufwands eines Entwicklungsvorhabens sind sie daher nicht geeignet.
  • Funktionsorientierte Metriken: In den 80er Jahren entstand der Begriff des funktionalen Umfangs. Die Messung orientiert sich nicht mehr am Code einer Implementierung, sondern an den zugrunde liegenden funktionalen Anforderungen. Diese werden aus den Anwendungsfällen abgeleitet. Dadurch kann der Umfang bereits vor der Implementierung ermittelt werden. Die Prinzipien der Messung wurden 1997 im Standard ISO/IEC 14143 festgelegt und sind Grundlage zahlreicher etablierter Messverfahren.

Nachfolgend stelle ich Ihnen einige Messmethoden vor, die sich – mehr oder weniger stark – am ISO/IEC-14143- Standard orientieren:

  • Function-Point-Analyse (1979): Sie zählt die aus Sicht der Akteure eines Systems (Anwender oder Fremdsysteme) relevanten Elementarprozesse und Datenbestände (Strukturen). Punktwerte ergeben sich aus deren Komplexität, beispielsweise durch die Zählung der beteiligten Datenelemente sowie Teilstrukturen und Abbildung auf Intervallskalen.
  • Bang-Metrik (1982): Hier werden, ausgehend von einer strukturierten Analyse, Functional Primitives gezählt. Deren Punktwerte orientieren sich an der Anzahl der Input- und Output-Token.
  • Data-Point-Methode (1989): Zählung von Tabellen, Schlüssel, Relationen und Attribute in der Datenbank sowie deren Verwendung in Dialogen und Schnittstellen. Punktwerte ergeben sich aus Schätzungen.
  • Use-Case-Point-Methode (1993): Zählt Anwendungsfälle und Akteure. Für die Punktwerte werden dreistufige Intervallskalen verwendet.
  • COSMIC, ehemals Full-Function-Point-Methode (1998): Zählt die Systemgrenzen überschreitenden und für Akteure (Benutzer oder Fremdsysteme) wahrnehmbaren Datenelemente sowie Schreib-/Lesezugriffe auf den Datenhaushalt. Keine Unterscheidung der Punktwerte.
  • Mark II FPA-Methode (1998): Basiert auf der Function-Point-Analyse. Zählt Elementarfunktionen und Zugriffe auf den Datenhaushalt mit festgelegten Punktwerten.
  • NESMA Function-Point-Methode (2005): Ebenfalls auf der Function-Point-Analyse basierend. Neben Näherungsverfahren gibt es die Methode “Detailed FPC”, die identisch mit der ursprünglichen Function-Point-Analyse ist.
  • Data-Interaction-Point-Methode (2006): Zählt die Systemgrenzen überschreitenden und für Akteure (Benutzer oder Fremdsysteme) wahrnehmbaren Datenelemente sowie die damit in Verbindung stehenden Attribute des Datenhaushalts. Die Punktwerte ergeben sich aus der Verwendung der Elemente, beispielsweise als Eingabe- oder Ausgabeelement in einem Dialog oder unterschieden nach Persistenz und Nur-Lese-Zugriff.
  • FISMA Function-Point-Methode (2009): Zählt die Systemgrenzen überschreitenden Datenelemente, deren algorithmische Verwendung und Schreib-/Lesezugriffe auf den Datenhaushalt. Punktwerte sind ebenfalls verwendungsbezogen.

In der Praxis zeigen sich zwischen den Verfahren deutliche Unterschiede – sowohl im Messaufwand als auch bezüglich Vergleichbarkeit und Genauigkeit. In den nächsten Wochen werde ich Ihnen einige dieser Methoden ausführlicher vorstellen.

Aber heute zunächst die Frage: Welche Messmethoden nutzen Sie und wo sehen Sie Vor- und Nachteile?


Bildquelle: Shutterstock

Schreibe einen Kommentar