Software-Messung
Software-Messung und -bewertung bezeichnet eine Disziplin im Bereich der Informatik,[1] die sich mit der systematischen Vermessung und Bewertung verschiedener Eigenschaften von Softwareprodukten, -prozessen und -projekten befasst. Im Vordergrund steht die Einführung von Messsystemen zur Erfassung, Verarbeitung und Visualisierung von erhobenen Messdaten. Das Ziel liegt üblicherweise in der Evaluierung von Qualitätseigenschaften von Softwareprodukten (wie z. B. der Fehlergehalt), Softwareprozessen (wie z. B. die Effizienz oder Effektivität) oder Softwareprojekten (wie z. B. die Einhaltung von Zeitplänen) und im darauf basierenden Vorschlagen von Verbesserungsmaßnahmen.
Software-Messung und -bewertung ist heutzutage ein gängiges Hilfsmittel im Bereich der professionellen Softwareentwicklung und hilft dabei Qualitätseigenschaften von Interesse transparent und damit kontrollierbar und im Idealfall vorhersagbar zu machen. Es stellt eine der wesentlichen Grundlagen für systematisches Lernen und Verbesserung dar.[2] Industriell genutzte Referenzmodelle im Bereich IT und Softwareentwicklung, wie CMMI (Capability Maturity Model Integration), SPICE (Software Process Improvement and Capability Determination) und ITIL sind ohne Software-Messung nicht umsetzbar.
Grundbegriffe
[Bearbeiten | Quelltext bearbeiten]Softwaremetriken
[Bearbeiten | Quelltext bearbeiten]Softwaremetriken quantifizieren verschiedene Eigenschaften der Software, ihrer Entwicklung und Anwendung[3]. Nach[4] wird durch eine Metrik eine Funktion beschrieben, die eine Software-Einheit (also eine Eigenschaft eines Messobjektes der Softwareentwicklung) auf einen Wert abbildet. Beispielsweise beschreibt die Metrik „Codezeilen“ (engl. „Lines of Code“) eine Funktion, welche die Eigenschaft „Größe/Umfang“ des Messobjektes „Code“ auf eine Zahl abbildet. Diese Funktion (auch Messvorschrift genannt) zählt die Anzahl der Zeilen in einem gegebenen Programmcode.
Softwaremaße
[Bearbeiten | Quelltext bearbeiten]Ein Softwaremaß beschreibt nach IEEE1061[4] die Anwendung einer Metrik. Softwaremaße können auf verschiedenen Skalentypen liegen, was wiederum die möglichen mathematischen Operationen zur Verrechnung der Zahlenwerte einschränkt. Eine Ordinalskala definiert beispielsweise eine Reihenfolge möglicher Klassen (wie „niedrig“, „mittel“, „hoch“), jedoch keinen Abstand zwischen denselben („hoch“ ist nicht dreimal so gut wie „niedrig“). Damit sind lediglich Vergleichsoperationen (z. B. „hoch“ > „mittel“ > „niedrig“) erlaubt.[5] unterscheidet zudem zwischen Basismaßen (Base Measures), die unter Anwendung einer Metrik direkt eine bestimmte Eigenschaft eines Messobjektes bestimmen und abgeleiteten Maßen (Derived Measures), welche mehrere Basismaße kombinieren.
Indikatoren
[Bearbeiten | Quelltext bearbeiten]Ein Indikator evaluiert im Allgemeinen einen aktuellen Zustand oder trifft eine Vorhersage dazu und dient als Grundlage der Entscheidungsfindung.[5] In der Software-Messung werden verschiedene Maße auf Basis eines Analysemodells miteinander kombiniert und mit Entscheidungskriterien angereichert. Beispielsweise kann ein Indikator auf Basis von Maßen darauf hinweisen, welche Module im Programmcode als besonders groß oder komplex eingestuft werden sollten und für die weitere Entwicklung ein Risiko darstellen.
Messdaten
[Bearbeiten | Quelltext bearbeiten]Messdaten bezeichnen nach[5] die Sammlung von Werten, die einem Softwaremaß bzw. Indikator zugeordnet wurden.
Messziele
[Bearbeiten | Quelltext bearbeiten]Ein Messziel beschreibt das hinter einer Software-Messung stehende Ziel. Nach der GQM-Methode[6] beschreibt man dazu (1) das Messobjekt, welches vermessen wird (z. B. einen Schritt des Entwicklungsprozesses oder ein Artefakt), (2) den Zweck zu dem gemessen wird (z. B. zum besseren Verständnis von Zusammenhängen bis hin zur kontinuierlichen Verbesserung von Schwachstellen), (3) den Qualitätsaspekt, der im Interesse der Messung steht (z. B. die Effizienz eines Prozesses oder die Verständlichkeit eines Programmcodes), (4) der Blickwinkel aus dem gemessen wird (z. B. aus Sicht eines Projektleiters oder eines Entwicklers) und schließlich der Kontext, in dem die Messung erfolgt (z. B. Umgebungscharakteristiken, wie Entwicklungsdomäne, Projekttyp, Teamerfahrung oder Programmiersprache). Ein Messziel könnte also beispielsweise darin liegen, einzelne Module des Programmcodes als Messobjekt zum Zwecke der Verbesserung im Hinblick auf deren Komplexität aus dem Blickwinkel eines Qualitätsmanagers in einem bestimmten Kontext zu untersuchen.
Messsysteme
[Bearbeiten | Quelltext bearbeiten]Ein Messsystem bezeichnet im Allgemeinen ein System zur Erfassung, Verarbeitung und Visualisierung erhobener Messdaten. Neben der Spezifikation der adressierten Messziele, Indikatoren, Maße und Metriken zählt hierzu auch insbesondere die Operationalisierung dieser Spezifikation in Form geeigneter Werkzeuge zur Erfassung, Verarbeitung und Visualisierung der Daten sowie geeigneter Prozesse zur Verankerung in der Organisation. Letzteres bezieht sich z. B. darauf, wer Daten in welcher Form zur Verfügung stellt bzw. die Datensammlung anstößt sowie wer sich diese Daten zu welchem Zeitpunkt im Entwicklungsprozess anschaut.
Erfahrungsdatenbanken
[Bearbeiten | Quelltext bearbeiten]Eine Erfahrungsdatenbank bezeichnet nach[5] einen Datenspeicher, der Ergebnisse aus der Software-Vermessung und -Bewertung sowie dabei gemachte Erfahrungen enthält und damit deren systematische Wiederverwendung erlaubt.[7] beschreibt das Konzept der Experience Factories, welches einen organisatorischen Rahmen definiert, um kontinuierliches Lernen und Verbessern in einer Software-Entwicklungsorganisation zu ermöglichen. Neben organisationsspezifischen Erfahrungsdatenbanken, die innerhalb einer Organisation gepflegt und genutzt werden, haben sich in der Vergangenheit zu spezifischen Aspekten auch sogenannte Benchmarking-Datenbanken herauskristallisiert, welche Projekterfahrungen und -daten zum Zwecke des Vergleichs innerhalb bestimmter Domänen und Anwendungsfelder ermöglichen soll. Ein prominentes Beispiel ist International Software Benchmark Standard Group (ISBSG)[8], welche Daten über die Produktivität von Entwicklungsprojekten für verschiedene Kontexte auf Basis funktionaler Größenmaße sammelt.
Vorgehen
[Bearbeiten | Quelltext bearbeiten]Das allgemeine Vorgehen zur Software-Messung und zum Aufbau eines Messsystems wird in[5] beschrieben. Der Grundprozess beginnt zunächst damit klare Ziele, die mit der Vermessung und Bewertung verbunden werden, zu definieren und die Zustimmung der involvierten Personenkreise – von der Führungsebene bis hin zu den betroffenen Mitarbeitern – einzuholen und Ressourcen zur Verfügung zu stellen.
Die Planung des Messprozesses sollte sich an klar definierten Messzielen orientieren. Eine zur Spezifikation von Messzielen verbreitete Methode stellt der Goal-Question-Metric-Ansatz dar.[6] Dazu wird eine Struktur aus Messzielen, Fragen und Metriken aufgebaut. Über Fragen wird das Messziel auf konkrete Informationsbedürfnisse herunter gebrochen, die schließlich auf Metriken abgebildet werden. In einer erweiterten Version dieses Ansatzes wird über die reinen Messziele hinaus auch der Beitrag und Nutzen der Datenerhebung für die Gesamtorganisation diskutiert und explizit modelliert. Im GQM+Strategies-Ansatz[9] werden dazu Messziele mit den Organisationszielen und -strategien verknüpft, so dass sich ein ganzheitliches Bild ergibt. Die Idee der Einbettung von Software-Messung in die Geschäftsprozesse und deren messbasierte Kontrolle steht im Vordergrund beim E4-Ansatz.[10]
Neben der Planung des Messprozesses geht[5] auch auf die eigentliche Sammlung und Analyse der Daten sowie der Ableitung konkreter Verbesserungsmaßnahmen ein. Diese beziehen sich explizit nicht nur auf die untersuchten Messobjekte, sondern vielmehr auch auf Verbesserungen am Messprozess selbst. Die gewonnenen Erfahrungen werden in einer Erfahrungsdatenbank abgelegt.
Die Qualität der Software-Messung und des Messprozesses wird anhand der Effizienz und der Vollständigkeit der Messung in Bezug zu den Messzielen.[11]
Fachgruppe
[Bearbeiten | Quelltext bearbeiten]Im deutschsprachigen Raum kümmert sich die Fachgruppe „Software-Messung und Bewertung“ der Gesellschaft für Informatik e. V. als Kompetenzzentrum um verschiedene Aspekte Rund um die Messung, Analyse und Bewertung von Software im IT-Bereich.[12] Das Ziel liegt darin, Experten aus der Forschung und Industrie regelmäßig zusammenzubringen und einen Informationsaustausch zu aktuellen Themen zu fördern.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ H. Balzert: Lehrbuch Softwaretechnik: Softwaremanagement. Spektrum-Verlag, 2008.
- ↑ R. Dumke, C. Ebert, J. Heidrich, C. Wille: Messung und Bewertung von Software - Stand der Technik und Ausblick. In: Informatik Spektrum. 36. Jahrgang, Nr. 6, 2013.
- ↑ ISO/IEC TR 25000: Software-Engineering – Qualitätskriterien und Bewertung von Softwareprodukten (SQuaRE) – Leitfaden für SQuaRE. ISO/IEC, 2012.
- ↑ a b IEEE Standard 1061: IEEE Standard for a Software Quality Metrics Methodology. IEEE, 1998.
- ↑ a b c d e f ISO/IEC 15939: Information Technology – Software Measurement Process. ISO/IEC, 2007.
- ↑ a b V. Basili, D. Rombach: The Goal Question Metric Approach. In: Encyclopedia of Software Engineering. John Wiley & Sons, 1994.
- ↑ V. Basili, D. Rombach, K. Schneider, B. Kitchenham, D. Pfahl, R. Selby: Empirical Software Engineering Issues – Critical Assessment and Future Directions. Springer-Verlag, 2007.
- ↑ International Software Benchmarking Standards Group. Abgerufen am 4. August 2014.
- ↑ V. Basili, A. Trendowicz, M. Kowalczyk, J. Heidrich, C. Seaman, J. Münch, D. Rombach: Aligning Organizations Through Measurement: The GQM+Strategies Approach. Springer-Verlag, 2014.
- ↑ C. Ebert, R. Dumke: Software Measurement – Establish, Extract, Evaluate, Execute. Springer-Verlag, 2007.
- ↑ A. Abran: Software Metrics and Software Metrology. John Wiley & Sons, 2010.
- ↑ Fachgruppe „Software-Messung und Bewertung“ der Gesellschaft für Informatik e. V.