Einführung in die Theorie und Praxis der Softwaremessung

Softwaremessung – Wie man Entwicklungsprozesse analysiert und verbessert
Kommentare

Ein Zweck der Softwaremessung ist es, das Anwendungssystem besser zu verstehen. Dazu dienen Zahlen. Sie helfen uns, die Zusammensetzung eines komplexen Gebildes wie ein Softwaresystem zu begreifen. Die Anwendungen der Softwaremessung sind vielfältig und reichen von der Aufwandsschätzung, der Unterstützung der Projektsteuerung bis hin zur Verbesserung der zwischenmenschlichen Kommunikation. Doch lesen Sie selbst: Wir starten im ersten Teil dieser Artikelserie mit den Grundlagen und geben eine Einführung.

Um das Thema Softwaremessung zu verstehen, muss man sich mit den Dimensionen von Software auseinandersetzen. Diese Dimensionen spiegeln sich in den einzelnen Phasen als Messobjekte wieder. Anhand dieser Parameter ist festzulegen, was gemessen werden kann (beispielsweise die Qualität oder Quantität des Sourcecodes durch die Größen Modularität und Konvertierbarkeit). Doch zuvor fragen wir nach den Zielen, dem Sinn und dem Zweck der Softwaremessung. Einen Überblick über die gesamte Artikelserie finden Sie im Kasten „Softwaremessung – Eine Einführung in drei Akten“.

Softwaremessung – Eine Einführung in drei „Akten“
Das Thema Softwaremessung ist umfangreich in Theorie und Praxis. Für das Ableiten von Handlungsvorschlägen muss man sich mit einigen konzeptionellen Ansätzen beschäftigen.
Teil 1: In diesem Artikel geht um die Ziele und Gegenstände der Softwaremessung. Je nach Messobjekt und Entwicklungsphase sind unterschiedliche Verfahren notwendig. Es werden Ansätze zur Messung der Softwarequantität besprochen.
Teil 2: Im Mittelpunkt von Teil 2 „Softwarequalität – so misst und verbessert man Software“ steht die Frage: „Was ist Softwarequalität“. Wenn man es definieren kann, kann man es vielleicht auch messen und objektivieren?
Teil 3
: Produktionsprozesse sollen möglichst effektiv sein. Softwareentwicklung ist jedoch eine Disziplin im Grenzbereich zwischen ingenieurmäßigen Vorgehen und künstlerischer Arbeit. Lässt sich dennoch die Produktivität bestimmen und kann Verbesserungspotenzial abgleitet werden? Der Artikel „Softwaremessung: Wie misst man die Produktivität von Softwareprojekten?“ verrät es.

Ziele

Die Softwaremessung dient nicht dem Selbstzweck, obwohl einige der gewonnenen Ergebnisse zunächst durchaus einen interessanten und lesenswerten Beitrag liefern, ohne dass sich der direkte Zugang zu einer Verwertung ergibt. Zusammengefasst sind die Ziele der Softwaremessung (Abb. 1) [1: Sneed, H.; Seidel, R.; Baumgartner, M.: „Software in Zahlen. Die Vermessung von Applikationen“, Carl Hanser Verlag München, 2010]:

  • Besser verstehen: Die Analyse eines Objekts führt in erster Linie dazu, dieses besser zu verstehen. Besteht eine Software aus mehreren Teilmodulen, so hilft es, den Aufbau, das Zusammenwirken und die Bedeutung der Teilmodule für das Ganze zu verstehen.
  • Vergleichbarkeit: Aufwandschätzungen – verbunden mit einer Kostenprognose – künftiger Projekte basieren auf Vergleichen mit abgeschlossenen Systementwicklungen. Die Aussage, das Projekt ist einzigartig und in keiner Weise vergleichbar, führt mit Sicherheit zu langen Gesichtern auf Seiten der Verantwortlichen. Fundierte Einschätzungen auf der Basis von „Zahlenwerken“ sind dagegen hilfreich.
  • Steuerung: Die Ergebnisse der Messung können dazu beitragen, aktuelle und künftige Projekte besser zu steuern. Der aktuelle Projektstand kann nur dann festgestellt werden, wenn man weiß, wie groß der voraussichtliche Gesamtaufwand ist.
  • Verbesserung der Kommunikation zwischen den Beteiligten: Die Messung quantitativer Größen liefert auf jeden Fall bessere Aussagen als lediglich qualitative Aussagen. Ein Beispiel: „Das Modul umfasst 30 000 Zeilen Quellcode“ ist deutlich aussagekräftiger als eine Feststellung, dass es sich um eine „mittelgroße“ Einheit handelt.
  • Beurteilung (Evaluierung): Das Projekt kann hinsichtlich seiner Gesamtdimension eingeordnet und beurteilt werden. Hieraus können auch Kostenprognosen abgeleitet werden.
  • Verbesserungspotenzial aufdecken: Quantitative Kenngrößen können Hinweise darauf geben, wo mögliche Problemstellen zu erwarten sind. Ein künftiger Verbesserungsbedarf kann ggf. daraus antizipiert werden. Beispielsweise kann der Umfang eines Teilprojekts die Notwendigkeit einer architekturverbessernden Modularisierung dieses Moduls andeuten.

Abb. 1: Die Ziele der Softwaremessung

Eine Softwaremessung kann einmalig (aus einen bestimmten Anlass) oder regelmäßig, d. h. wiederholend durchgeführt werden. Ein punktueller Anlass kann beispielsweise darin bestehen, wenn man als Entwicklungsfirma für eine bestehende Software die Wartung übernehmen möchte. Die Messung ist dann ein Teil der notwendigen Quellcodeanalyse, um sich über die Dimensionen, die Komplexität und den möglichen Aufwand der Wartung ein Bild zu machen. Regelmäßige Messungen können während fortlaufender größerer Entwicklungsprojekte angezeigt sein. Dabei bestimmen die Ziele einer Messung die Methoden und die dadurch zu ermittelnden Kennzahlen (Metriken). Allgemein gilt: Eine Softwaremetrik ist eine Maßzahl, die Eigenschaften eines Prozesses oder eines Softwareelements quantitativ (in Form von Zahlen) abbildet und damit die Voraussetzungen für formale Vergleichs- und Bewertungsmöglichkeiten schafft.

Objekte der Softwaremessung

Sowohl die Software selbst (siehe kommender Abschnitt) als auch der Prozess der Erstellung sind hoch komplex und können deshalb nicht mit einer Methode gemessen bzw. durch eine Kennzahl beschrieben werden. Eine erste Unterscheidung der Messung kann sich darauf beziehen, ob das Resultat des Entwicklungsprozesses (also die Software selbst) oder der Erstellungsprozess vermessen wird. Vermisst man das Objekt, so kann man beispielsweise dessen Größe bestimmen. Vermisst man den Prozess, geht es häufig um die Effektivität der Entwicklung. Diese beiden Begriffe werden auch als Produkt- bzw. Prozessmaße bezeichnet. Aus den ermittelten Werten können Bestimmungsgrößen für die Ressourcen abgeleitet werden, die für die Durchführung der Entwicklungsprozesse notwendig sind. Für Produkt-, Prozess- und Ressourcenmaße stehen jeweils unterschiedliche Größen zur Messung zur Verfügung (Tabelle 1).

Tabelle 1: Klassifikation von Softwaremaßen, Darstellung nach [2]

Weiterhin kann nach direkten und indirekten Maßen differenziert werden. Direkte Softwaremaße werden durch Untersuchung des entsprechenden Objekts ermittelt. So gehören die Länge (gemessen in LOC = Lines of Code) und die Komplexität (gemessen durch die Anzahl der Entscheidungspunkte) des Sourcecodes zu den direkten Maßen. Ein indirektes (abgeleitetes) Maß ist dagegen die Zahl der (noch) enthaltenen Fehler im Programm. Die Zahl der gefundenen Fehler hängt – abgesehen von Syntaxfehlern – zum Beispiel von den angewendeten Testmethoden und deren erreichten Überdeckungsgrad ab. Auch Angaben zu Kosten sind indirekte Maßgrößen, die sich aus anderen Parametern ergeben. Ein Merkmal ist deren schwierigere Bestimmung, da zwischen der Messung der Kennzahl und der Bestimmung des endgütigen Softwaremaßes ein mehr oder weniger subjektiver und anfälliger Prozess der Dateninterpretation liegt. Beispielsweise ist aus den direkten Größen Umfang des Quellcodes und Komplexität auf eine Kennzahl zum erwarteten Aufwand zu schließen (Abb. 2). Das Management ist natürlich primär an den aussagekräftigeren abgeleiteten Größen interessiert.

Abb. 2: Von direkten zu indirekten Softwaremaßen

Dimensionen und Eigenschaften von Software

Software ist ein immaterielles Gut, das primär durch die Dimensionen Quantität, Komplexität und Qualität charakterisiert werden kann (Abb. 3). Ansatzpunkte, was unter diesen Dimensionen verstanden wird, liefert Tabelle 2.

Tabelle 2: Dimensionen von Software, Darstellung nach [1]

Abb. 3: Dimensionen von Software [1]

Die Messung von Softwarequantität

Dieser Abschnitt beschäftigt sich mit einer möglichen Bestimmung der Quantität – also der Größe bzw. dem Ausmaß – einer Software. Wenn man von der Größe einer Anwendung spricht, dann meint man sehr oft die Größe des Quellcodes. Da Software jedoch aus einer Vielzahl von Einzelteilen besteht, kann man deren Größe auch an unterschiedlichen Teilprodukten messen. Dies sind:

  • die Größe der Anforderungsspezifikation
  • die Größe des Entwurfs
  • die Größe des Codes
  • die Größe der Testware
  • die Größe der Nutzungsdokumentation

In den kommenden Textabschnitten wird auf die Größenmessung des Quellcodes und der Anforderungsspezifikation eingegangen, deren Maße geben bereits gute Hinweise zur Einschätzung des Gesamtprodukts.

Größenmessung des Quellcodes

Der Quellcode bildet den Kern einer Anwendung. Die anderen Bestandteile des Softwareprodukts könnten zur Not auch fehlen, d. h. die Anwendung ist beispielsweise durchaus auch ohne Benutzerdokumentation lauffähig. Aus der Größe des Codes lassen sich gute Rückschlüsse auf die Quantität des gesamten Systems schließen. Die Aussage ist beispielsweise wichtig, um eine Prognose zum Wartungsaufwand zu treffen, insbesondere wenn die Anwendung nicht aus dem eigenen Hause stammt. Unter dem Quellcode versteht man die Kombination aus Algorithmen und Datenstrukturen. Wichtige Elemente zur Beschreibung des Codes sind Tabelle 3 zu entnehmen.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Tabelle 3: Wichtige Codegrößen, eigene Darstellung in Anlehnung an [1]

Abb. 4: Die Zahl öffentlicher Klassen als Quantitätsindikator des Quellcodes, hier: .NET Framework [3]

Die Analyse des Quellcodes ist natürlich stark davon abhängig, welche Programmiersprache zum Einsatz kommt. Programmiersprachen ihrerseits können bestimmten Paradigmen zugeordnet werden. Folgende Programmierparadigmen wurden im Laufe der Zeit entwickelt [4]:

  • Imperatives Programmierparadigma: Das Programm besteht aus einer Folge von Anweisungen, die streng sequenziell abgearbeitet werden. Das Konzept des imperativen Programmierparadigma beruht auf Funktionen und Prozeduren zur Abbildung der Funktionalität und Wiederverwendung von Quellcode. Der bekannteste Vertreter ist die Programmiersprache C.
  • Objektbasiertes Programmierparadigma: Diese Programmiersprachen kennen Objekte zur Kapselung von Daten und Funktionalität. Weitergehende Konzepte, wie beispielsweise Vererbung oder die Abbildung von Beziehungen zwischen Objekten, werden jedoch nicht angeboten. Objektbasierte Sprachen können damit als Vorstufe der objektorientierten Programmierung aufgefasst werden. Ein Beispiel ist JavaScrip.
  • Objektorientiertes Programmierparadigma: Programmiersprachen dieser Gattung erweitern das objektbasierte Programmierparadigma um die typischen Konzepte der Objektorientierung, wie Vererbung und Polymorphie. Moderne und häufig eingesetzte Vertreter sind Java und C#.
  • Funktionales Programmierparadigma: Ein funktionales Programm besteht nur aus einer Reihe von Funktionsaufrufen. Eigenständige Wertzuweisungen existieren nicht, alle Elemente können als Funktionen aufgefasst werden. Einsatzgebiete sind Anwendungen der künstlichen Intelligenz, Compilerbau und Computeralgebrasysteme. Funktionale Sprachen beruhen auf dem so genannten Lambda-Kalkül. Beispiele funktionaler Programmiersprachen sind LISP, Haskell und mit zunehmender Bedeutung die Sprache F#.
  • Logisches Programmierparadigma: Im Mittelpunkt steht der Aufbau einer Datenbasis, die aus Fakten und Regeln besteht. Fakten sind dabei wahre Aussagen im Sinne der Mathematik. Im Vordergrund steht die Problemformulierung nicht der Lösungsalgorithmus. Die Sprache PROLOG basiert auf dem logischen Paradigma.
  • Deklaratives Programmierparadigma: Überbegriff für das funktionale und das logische Paradigma.

Messung von Anforderungsgrößen

Je nach gewähltem Entwicklungsmodell werden die Anforderungen in anderen Dokumenten und nach einer anderen Systematik erfasst. Beim evolutionären Entwicklungsmodell dient das Pflichtenheft als Grundlage der Vereinbarung zwischen Auftraggeber und Auftragnehmer. Die Analyse dieses textuellen Dokuments gibt also eindeutige Hinweise auf den Umfang des bereits existierenden Softwaresystems (ex-post-Analyse, zum Beispiel bei der Übernahme eines Wartungsvertrags) bzw. auf den erwarteten Entwicklungsaufwand (ex-ante-Analyse für die Aufwandsschätzung). Es gibt zwar keine Verpflichtungen, das Pflichtenheft nach einer bestimmten Struktur aufzubauen, dennoch haben sich diesbezüglich gewisse wiederkehrende Inhalte und eine regelmäßig angewendete Grundstruktur etabliert (Kasten: „Pflichtenheft“).

Pflichtenheft

Welche Inhalte gehören in ein Pflichtenheft? Eine verbindliche Vorgabe existiert nicht. Aus den existierenden Vorschlägen kann man jedoch sein eigenes Inhaltsverzeichnis zusammenstellen. Eine gebräuchliche Gliederung lautet:
1. Ziele
2. Einsatz (Anwendungsbereiche, Zielgruppen, Betriebsbedingungen)
3. Produktumgebung (Software, Hardware, Orgware, Schnittstellen)
4. Funktionalität (Produktfunktionen, Anwendungsfälle)
5. Daten
6. Leistungen
7. Grafische Benutzeroberfläche (GUI)
8. Entwicklungsumgebung
9. Qualitätsziele
10. Ergänzungen

Dazu noch einige Erläuterungen: Unter Orgware versteht man die Einbindung der Software in die organisatorischen Randbedingungen, wie beispielsweise E-Mail. Wichtig sind auch die Angaben zu den Schnittstellen. Soll beispielsweise eine Integration in ein bestehendes System erfolgen, so sind entsprechende Spezifizierungen notwendig. Für die Darstellung der Funktionalität bedient man sich häufig einer grafischen Visualisierung. Die UML kennt für die schematische Abbildung das Konzept des Anwendungsfalls. Ein Anwendungsfall stellt einen Arbeitsschritt des Systems dar. Die Beschreibung kann formalisiert, mithilfe einer so genannten Anwendungsfallschablone (Textkasten) erfolgen. Alle Anwendungsfälle einer Software definieren die gesamte Funktionalität der Anwendung und werden in einem Anwendungsfalldiagramm dargestellt.

Um die Anforderungen an ein System quantitativ zu beurteilen, kann man die Dokumente bezüglich der in Tabelle 4 notierten Schlüsselwörter auswerten.

Tabelle 4: Häufige Schlüsselwörter zur Bemessung der Quantität der Anforderungen

Insgesamt ist das Thema Anforderungsmessung noch nicht abschließend durchdrungen. In der Literatur werden zwar durchaus einige Methoden vorgestellt und diskutiert, einen umfassenden Ansatz gibt es aber noch nicht. Zu nennen wäre zum Beispiel die Metrik von Ebert [6], die auf einer Nutzwertanalyse der Anforderungen beruht. Gemäß diesem Ansatz genügen nur wenige Kennzahlen, um die Anforderungen unter Kontrolle zu bringen:

  • die Zahl aller Anforderungen
  • der Fertigstellungsgrad der Anforderungen
  • die Änderungsrate pro Entwicklungsphase
  • die Anzahl der Ursachen für die Anforderungsänderung
  • die Vollständigkeit des Anforderungsmodells
  • die Anzahl der Mängel in den Anforderungen
  • der Nutzwert der einzelnen Anforderungen

In Deutschland ist mit dem Thema Anforderungsmanagement die so genannte Sophist-Gruppe sehr intensiv beschäftigt. Sie schlagen die in Abbildung 5 gezeigten Kriterien zur Messung der Anforderungsqualität vor.

Abb. 5: Anforderungsmetrik nach Sophist-Gruppe [7]

Anwendungsfallschablone [5]

Ein Anwendungsfall kann frei beschrieben werden. Für mehr Übersichtlichkeit hilft eine einheitliche Gliederung, insbesondere bei einer Vielzahl von Anwendungsfällen. Nicht immer müssen alle Punkte der Schablone gefüllt werden. Wichtig ist, die Beschreibung an der Problemstellung zu orientieren und als Mittel der Analysephase technische Aspekte außer Acht zu lassen.

• Anwendungsfall: Name des Anwendungsfalls.
• Ziel: Kurze Beschreibung der Zielstellung des Anwendungsfalls.
• Akteure: Rollen/Organisationseinheiten/externe Systeme, die mit dem Anwendungsfall zu tun haben. Dieser Punkt ist nur in einem Mehrbenutzersystem von Interesse, wo verschiedene Benutzer unterschiedliche Aufgaben und Berechtigungen haben.
• Kategorie: Primär oder sekundär – hier wird zwischen wichtigen und weniger wichtigen Anwendungsfällen differenziert. Primäre Anwendungsfälle sind den Kernaufgaben der Anwendung gewidmet.
• Initiierendes Ereignis: Ein Ereignis, das zur Auslösung des Anwendungsfalls führt.
• Vorbedingungen: Notwendige Bedingungen, um den Anwendungsfall bearbeiten zu können.
• Nachbedingung bei Erfolg: Ergebnis bei erfolgreicher Bearbeitung.
• Nachbedingung bei Misserfolg: Ergebnis bei erfolgloser Bearbeitung.
• Standardspezifikation: Beschreibung der einzelnen Aktionen in Bezug auf die Durchführung des Anwendungsfalls:
– Aktion 1: Beschreibung der ersten Aktion
– Aktion 2: Beschreibung der zweiten Aktion
– …
– Aktion n: Beschreibung der n-ten Aktion
• Erweiterung der Standardspezifikation: In einigen Fällen sind die Standardaktionen durch weitere Maßnahmen zu erweitern:
– Aktion 1a: Erweiterung der ersten Aktion
– Aktion 1b: Erweiterung der ersten Aktion
– …
• Alternativen zur Standardspezifikation: Gegebenenfalls existiert zu einer nicht ausführbaren Standardaktion eine Alternative:
– Aktion 1a: Alternative Ausführung der ersten Aktion

Fazit und Ausblick

Der Beitrag hat einen Einstieg in das Thema Softwaremessung gegeben. Ein Thema, das noch in den „Kinderschuhen“ der (Wirtschafts-)Informatik steckt und den umfassenden Ansatz zur Lösung wohl noch eine Zeit lang weiter schuldig bleiben wird. Dennoch liefert die Beschäftigung mit dem Thema viele Ansatzpunkte, ein vorliegendes Softwaresystem unter einer gegebenen Zielsetzung zu analysieren. Spätestens wenn es um einen konkreten Fall in der Praxis geht – zum Beispiel die Aufwandsschätzung für ein Wartungsprojekt – muss man die Theorie verlassen und sich für eine akzeptable Messmethode und eine plausible Interpretation der Ergebnisse entscheiden. In der kommenden Ausgabe steht das Thema Softwarequalität auf der Tagesordnung. Trotz aller Forderung nach qualitativ hochwertiger Software und nach einem möglichst zertifizierten Herstellungsprozess liegt bis heute der Qualitätsbegriff teilweise im Dunkeln. Wir versuchen, etwas Licht in die Sache zu bringen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

 

Aufmacherbild: Hand with tape measure out of laptop via Shutterstock / Urheberrecht: goir

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -