Diplomarbeit. Konzeption und prototypische Realisierung einer Telemetrie-basierten Mess-Architektur

Transkript

1 Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Arbeitsgruppe Softwaretechnik Diplomarbeit Konzeption und prototypische Realisierung einer Telemetrie-basierten Mess-Architektur Themensteller: Betreuer: Prof. Dr.-Ing. habil. R. Dumke Dipl.-Inform. Martin Kunz vorgelegt von: Christoph Ullwer Walther-Rathenau-Str Magdeburg Matrikelnummer:

2 Otto-von-Guericke-Universität Magdeburg Ullwer, Christoph: Konzeption und prototypische Realisierung einer Telemetrie-basierten Mess-Architektur Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, 2006.

3 Inhaltsverzeichnis III Inhaltsverzeichnis Abkürzungsverzeichnis... V Abbildungsverzeichnis... VI Tabellenverzeichnis... VIII Verzeichnis der Code-Fragmente... VIII 1 Einleitung Motivation und Zielstellung Aufbau der Diplomarbeit Software-Messung und Software-Management Aspekte der Software-Messung Ziele der Softwaremessung Metriken und Messwerkzeuge Aspekte des Software-Managements Bewertung der Prozessgüte... 9 Personal Software Process Die PROBE-Methode zur Größenabschätzung Akzeptanzproblem von PSP und Software-Messung Softwareprojekt-Telemetrie Begriffsklärung Automatisierung von Software-Messung Automatisierung der Datenerfassung Definition und Speicherung der Daten Analyse von Daten Datenschutz und Datensicherheit Software-Management durch Softwareprojekt-Telemetrie Soziale Aspekte der Softwareprojekt-Telemetrie Metriken-Programm und Projekt-Management Telemetrie-basierte Mess-Infrastrukturen Begriffsklärung Eigenschaften und Anforderungen Klassifikation und Vergleich verschiedener Systeme Projekt Hackystat Hackystat Systemarchitektur... 48

4 Inhaltsverzeichnis IV Anwendungsszenario von Softwareprojekt-Telemetrie Definition von Projekten Darstellung und Analyse Bedarf eines OpenOffice Sensors OpenOffice.org API und UNO UNO Komponenten-Technologie Services und Komponenten Service Manager und Component Context Das Ereignismodell Implementierung des OpenOffice Moduls Anforderungen und Definition des Sensors Implementierung des Sensors Integration in OpenOffice.org Integration in das Hackystat-Framework Automatisierung der Installation Integration in den automatischen Build-Prozess Qualitätssicherung der Implementierung Ergebnisse und Einsatz der entwickelten Lösung Realisierung eines Hackystat Servers im Messlabor Einsatz des OpenOffice Sensors für Softwareprojekt-Telemetrie Zusammenfassung und Ausblick Literaturverzeichnis Anhang A A1. Aufgabenstellung A2. Inhalt der CD Anhang B Lineare Regression Anhang C System-Konfiguration C1. Sensor-Konfiguration C2. Server-Konfiguration Anhang D Docbook des OpenOffice-Sensors Impressum Selbständigkeitserklärung

5 Abkürzungsverzeichnis Abkürzungsverzeichnis API Application Programming Interface ASE Agile Softwareentwicklung CAME Computer Assisted Software Measurement and Evaluation CASE Computer Aided Software Engineering CMM Capability Maturity Model CMMI Capability Maturity Model Integration DBMS Datenbankmanagementsystem DIN Deutsches Institut für Normung e.v. GPL GNU General Public License HTML HyperText Markup-Language HTTP HyperText Transfer Protocol IDE Integrated Development Environment ISO International Organization for Standardization IT Informationstechnologie JDBC Java-Database-Connectivity LGPL GNU Library General Public License LOC Lines of Code MS Microsoft PROBE PROxy Based Estimating PROM Professional Metrics PSP Personal Software Process SDK Software Development Kit SDT Sensor Data Type SEI Software Engineering Institute SOAP Simple Object Access Protocol SQL Structured Query Language TDL Telemetrie Definition Language TSP Team Software Process UML Unified Modelling Language UNO Universal Network Objects URL Uniform Resource Locator XML extensible Markup Language XP Extreme Programming V

6 Abbildungsverzeichnis VI Abbildungsverzeichnis Abb. 2.1: Messprozess nach ISO [ISO/IEC 2002]:... 6 Abb. 2.2: CASE-Tools bei der Software-Entwicklung (nach [Dumke 2003, S.148]):... 6 Abb. 2.3: Regelkreis zur Produkt- bzw. Prozessverbesserung (nach [Dumke 1996], S.38):... 7 Abb. 2.4: Prozess der Software-Produktentwicklung (nach [Dumke 2003, S.7]):... 8 Abb. 2.5: Aspekte des Software-Managements (nach [Dumke 2003, S.240]):... 9 Abb. 2.6: Schritte des Personal Software Process (nach [Humphrey 1996, S.79]): Abb. 2.7: Die PROBE Methode zur Größenabschätzung (nach [Humphrey 1995, S. 118]):. 14 Abb. 2.8: Darstellung der Regressionsgeraden für PROBE [Humphrey 1995, S. 546]: Abb. 3.1: Erfassung und Aufbereitung von Messdaten (nach [Fenton 1997, S.155]): Abb. 3.2: Organisationskonzepte der Datenverwaltung (nach [Balzert 1996, S.655]): Abb. 3.3: Aspekte einer Mess-Datenbank (nach [Ebert 2005, S.84]): Abb. 3.4: Anzahl von Modulen in Abhängigkeit der LOC [Kitchenham 1996, S.132]: Abb. 3.5: Regression: ohne Transformation (links), mit (rechts) [Fenton 1997, S.219]: Abb. 3.6: Deanonymisierung von Datensätzen (nach [Pommerening 1991, S. 92f.]): Abb. 3.7: Prozessübersicht eines integrierten Metriken-Programms [Ebert 2005, S.119]: Abb. 3.8: Darstellungsmöglichkeiten des Entwicklungsprozesses [Ebert 2005, S.121] : Abb. 3.9: Verantwortungsbereiche des Prozess-Managements (nach [Florac 1999, S.6]): Abb. 4.1: Tool-Unterstützung der Software-Messung (nach [Dumke 2003, S.196]): Abb. 4.2: Daten-Quellen in Kontext von Mess-Infrastrukturen (nach [Ebert 2005, S.83]):.. 38 Abb. 4.3: Datenfluss-Diagramm zur Datenerfassung [Kitchenham 1996, S.119]: Abb. 4.4: Erfassung von Aktivitäten mit Process Dashboard [PSP Dashboard].: Abb. 4.5: Zeitabschätzung von PSP-Daten mit Leap-Tool [LEAP]: Abb. 4.6: Das Balboa-Framework als Client-Server Architektur [Balboa]: Abb. 4.7: PROM-Architektur zur automatischen Datenerfassung [Sillitti 2003, S.339]: Abb. 4.8: PROM Statistik eines Projekts mit Pseudonymisierung [Sillitti 2003, S.341]: Abb. 4.9: Grundlegende Architektur von Hackystat [Johnson 2005, S.79]: Abb. 4.10: SensorShell Schnittstellen und Server-Kommunikation: Abb. 4.11: Workspace und Workspace-Root Definitionen: Abb. 4.12: Definition eines Hackystat-Projektes: Abb. 4.13: Verlaufsanalyse von Ereignissen: Abb. 4.14: Analyse der aktiven Entwicklungszeit des Sensor-Moduls: Abb. 4.15: Zusammenhang zw. Reports, Charts und Streams (nach [Hackystat Doc]):... 55

7 Abbildungsverzeichnis VII Abb. 4.16: Automatische Diagramm-Generierung durch TDL: Abb. 4.17: Release Planung durch Softwareprojekt-Telemetrie [Hackystat Doc]: Abb. 5.1: Interfaces, Services und Implementierung im Kontext von UNO: Abb. 5.2: UnoUrlResolver referenziert den Remote Service Manager [DevGuide]: Abb. 5.3: Übersicht des OpenOffice-Ereignismodells [DevGuide]: Abb. 6.1: Implementierung der OpenOfficeSensor-Klasse im Überblick: Abb. 6.2: Verarbeitung registrierter Aktivitäten durch einen TimerTask: Abb. 6.3: Behandlung spezieller Ereignisse der Benutzeraktivität: Abb. 6.4: Struktur des UNO-Paketes und enthaltene Komponenten: Abb. 6.5: Sequenzdiagramm zur Job-Ausführung (nach [DevGuide]): Abb. 6.6: Klassenarchitektur zur vollautomatisierten Sensor-Installation: Abb. 6.7: Hierarchische Struktur des lokalen Build-Skriptes: Abb. 6.8: JUnit Testfälle im Einsatz : Abb. 6.9: Klassenstruktur implementierter Testfälle und Abhängigkeiten: Abb. 7.1: Web-Interface zum Login für Hackystat im 82 Abb. 7.2: Analyse-Auswahl nach Login des Nutzers in Hackystat: Abb. 7.3: Zeit-Diagramm mit mehreren Streams und Ordinaten: Abb. 7.4: HackyInstaller Konfiguration und Auswahl verfügbarer Sensoren: Abb. 7.5: Installationsdialog des OpenOffice Sensors: Abb. 7.6: Liste der Hackystat-Autoren im Documentation-Framework [Hackystat Doc]: Abb. 7.7: Installation von UNO-Paketen mittels OpenOffice Package-Manager: Abb. 7.8: Informationsdialog des OpenOffice Sensors : Abb. 7.9: Überprüfung der korrekten Datenaufnahme des Sensors:... 87

8 Tabellenverzeichnis VIII Tabellenverzeichnis Tab. 2.1: Qualitätsstufen des CMM ([Humphrey 1989], [Dumke 2003, S.232]) Tab. 2.2.: Aktivitätsmerkmale beim PSP (nach [Dumke 2003, S.127]) Tab. 2.3: Allgemeine negative Aspekte der Software-Messung (nach [Ebert 2005, S.71]) Tab. 3.1: Klassifikation von Software-Störfällen (nach [Kitchenham 1996, S.99]) Tab. 3.2: Metriken zum Erreichen von Projekt-Zielen ([Ebert 2005, S.126] ) Tab. 4.1: Generationen PSP-artiger Datenerfassung (nach [Johnson 2003, S.2]) Tab. 4.2: Vergleich von PROM und Hackystat (nach [Sillitti 2003, S.342]) Tab. 4.3: Hackystat Sensor Daten Typen und assoziierte Sensoren Tab. 6.1: Spezifikation der Attribute des Activity SDT [Hackystat Doc] Verzeichnis der Code-Fragmente Listing 1: Darstellung von Build-Resultaten via Telemetry Definition Language Listing 2: Factory-Spezifikation durch IDL Listing 3: IDL-Spezifikation des Komponenten Kontext Listing 4: Extension Point Definition des OpenOffice Sensors Listing 5: Erfassung von Daten durch die Sensor-Klasse Listing 6: Update-Methode der Klasse OpenOfficeSensorInstaller.java Listing 7: Ausführen von Methoden via Java-Reflection... 77

9 1 Einleitung 1 1 Einleitung Die zunehmende Komplexität von Software sowie fehlende Methoden und Instrumente damit umzugehen, führen zu immer immenseren Kosten sowie kaum erfüllbaren Qualitätsanforderungen und Zeitvorgaben. Als Reaktion auf die andauernde Softwarekrise seit den 60er Jahren wird die Hinwendung zu einer ingenieurmäßigen Software-Entwicklung gefordert. Im Ingenieurwesen herrscht heutzutage Einigkeit darüber, dass unterschiedlichste Messungen in Verbindung mit Standards notwendige Grundlage reproduzierbarer, präziser und kontrollierbarer technischer Vorgänge sind [Dumke 1996, S.3]. Aufgrund dieser Aussagen lässt sich also folgende Schlussfolgerung ziehen: If software development is to viewed as an engineering discipline, it requires a measurement component that allows us to better understand, evaluate, predict and control the software process and product. [Basili 1990] Trotz des vorhandenen theoretischen Potentials auf dem Gebiet der Software-Messung erscheint deren effektive Anwendung bis dato weit entfernt von den Gepflogenheiten der Praxis. Die Gründe für die Diskrepanz zwischen Theorie und Praxis sind vielfältig: neben der schlichten Unwissenheit der Anwender ist es oftmals kaum möglich, die durch Theoretiker entwickelten Methoden und Modelle auf den speziellen Kontext eines konkreten SoftwareProjektes anzuwenden (vgl. auch [Johnson 2005, S.76f.]). Hinzu kommt, dass bis Mitte der 90er Jahre der überwiegende Teil der Software-Metriken eher zum Gebrauch auf der Organisationsebene bestimmt war. Mit dem Erscheinen von Humphreys A Discipline for Software Engineering [Humphrey 1995] wurden jedoch die Software-Messung und die Analysetechniken auf den Bereich des individuellen Entwicklers angepasst. Dieser so entwickelte Personal Software Process (PSP) dient vor allem den verbesserten Möglichkeiten der Projektabschätzung als auch der Qualitätssicherung und beruht vor allem auf zwei grundlegenden Annahmen. Erstens muss die PSP-artige MessdatenErfassung und Analyse durch einen individuellen Entwickler signifikante Vorteile für diese Einzelperson liefern. Zweitens muss dieser Nutzen ausreichend groß sein, sodass der Entwickler den PSP auch im Anschluss der Aneignung nachhaltig einsetzt. Während die erste Annahme durch verschiedene Studien1 bestätigt werden konnte, zeichnet sich doch immer stärker ein Akzeptanzproblem der dauerhaften Anwendung von PSP ab. Die Gründe hierfür liegen vor allem beim zusätzlichen, hohen Aufwand aufgrund einer durchweg manuellen Datenerfassung und Analyse, als auch in der dadurch verursachten Ablenkung von der eigentlichen Entwicklungstätigkeit. 1 Vgl. auch [Johnson 2003].

10 1 Einleitung Motivation und Zielstellung Aus den bisherigen Ausführungen wird der Bedarf einer automatischen Datenerfassung und Analyse ersichtlich, um die Akzeptanzproblematik zu lösen und durch eine PSP-artige Software-Messung ein verbessertes Projekt-Management zu ermöglichen. Die Aussicht auf eine vollautomatische Datenerfassung und Analyse wurde bislang jedoch eher pessimistisch eingeschätzt, da verschiedene Messobjekte der Software-Messung ungemein schwer zugänglich sind, was zum Begriff der Softwareprojekt-Telemetrie führt. Die damit verbundenen Anforderungen, wie nicht-obstruktive Software-Messung und exakte zeitliche Erfassung von Entwicklungstätigkeiten im Umfeld des Softwareprojektes, ermöglichen die Überwachung, Kontrolle sowie Kurzzeit-Vorhersagen von Projektzuständen innerhalb des Entwicklungsprozesses. Hierfür ist der Einsatz geeigneter Werkzeuge in allen betroffenen Bereichen unerlässlich, d.h. der eigentlichen Messdatenerfassung, dem Definieren, Speichern und Exportieren der Daten, sowie deren Analyse und Bewertung. Dieser für Softwareprojekt-Telemetrie benötigte technische Unterbau wird als Mess-Infrastruktur bezeichnet. Dabei gelten besondere Anforderungen, die aus den Bedingungen der Softwareprojekt-Telemetrie und dem jeweiligen Anwendungsbereich resultieren. Für die Erstellung einer Basis-Architektur zur Messdatenaufnahme ist es darum nötig, erst einmal einen Überblick der momentan verfügbaren Systeme zu erstellen und diese anhand verschiedener Kriterien zu bewerten. Bei der detaillierten Untersuchung einer prädestinierten Mess-Infrastruktur steht sowohl der allgemeine Aufbau der Architektur und die Funktionsweise, als auch die Analyse des Automatisierungsgrades im Vordergrund. Daneben soll zu Versuchs- und Demonstrationszwecken eine Mess-Infrastruktur im Messlabor [SML@B] des Lehrstuhls für Softwaretechnik, an der Otto-von-GuerickeUniversität Magdeburg, eingerichtet werden. Des weiteren ist für die gewählte Mess-Infrastruktur eine modulare Erweiterung zur Messdatenaufnahme, ein so genannter Sensor, prototypisch zu implementieren. Ziel des zu entwickelnden Sensors ist auch die Unterstützung der Forschung in dem noch relativ neuen Gebiet der empirischen Softwaretechnik. Der Gebrauch des Sensors soll dabei helfen, die Aktivitäten und Vorgänge zu erfassen, die für den Personal Software Process relevant sind. Außerdem dient der erfolgreiche Einsatz der zu entwickelnden Software als Beleg der Machbarkeit einer automatisierten Erfassung und Analyse von Daten für PSP, was eine positive Rückwirkung auf das Forschungsgebiet selbst zur Folge hat. 1.2 Aufbau der Diplomarbeit In der vorliegenden Diplomarbeit wird die grundlegende Problemstellung der technischen Konzeption und prototypischen Realisierung einer Telemetrie-basierten Mess-Architektur dargelegt.

11 1 Einleitung 3 Zur Erläuterung des theoretischen Hintergrunds und der Voraussetzungen des gewählten Lösungsansatzes werden in Kapitel 2. einige ausgewählte Themengebiete der Softwaremessung und des Software-Managements dargestellt. Neben der Motivation und den Zielen der Software-Messung wird insbesondere deren Anwendung zur Bewertung der Prozessgüte durch das Capability Maturity Modell und den daran ansetzenden Personal Software Process (PSP) beschrieben. Die abschließend in Kapitel 2. diskutierten Probleme die sich im Zusammenhang mit Software-Messung und PSP im Speziellen ergeben, führen zu dem in Kapitel 3. diskutierten Lösungsansatz durch Softwareprojekt-Telemetrie. Nach einer allgemeinen Einführung zur Erläuterung des Begriffes und allgemeinen Anforderungen, stehen hier insbesondere die Automatisierung der Erfassung, Speicherung und Analyse von Daten im Vordergrund. Außerdem werden Aspekte des Datenschutzes und der Datensicherheit sowie die Möglichkeit des Software-Managements durch Softwareprojekt-Telemetrie diskutiert. Der für eine automatische und effiziente Software-Messung benötigte technische Unterbau wird in Kapitel 4. durch den Begriff der Mess-Infrastruktur definiert. Die Eigenschaften und Anforderungen von Softwareprojekt-Telemetrie müssen hierbei eine adäquate technische Realisierung finden. Zur Erstellung einer Basis-Architektur und der Messdatenaufnahme werden zunächst vorhandene Systeme klassifiziert und für eine Bewertung miteinander verglichen. Für die anschließend gewählte Lösung soll außerdem der Bedarf eines neuen Sensors für die OpenOffice-Suite motiviert werden. Dafür ist es notwendig die grundlegende Komponenten-Architektur UNO zur Erweiterung der Funktionalität von OpenOffice in Kapitel 5. zu erläutern. Einige ausgewählte Aspekte der Realisierung des Sensors werden schließlich in Kapitel 6. dargelegt. Neben den Anforderungen geht es hierbei vor allem um die Implementierung und die Integration in die Mess-Infrastruktur sowie in OpenOffice. Außerdem kommen einige Gesichtspunkte bezüglich der Qualitätssicherung des entwickelten Moduls zur Sprache. Kapitel 7. zeigt dann die Ergebnisse der Realisierung einer Basis-Architektur im Messlabor SML@B. Außerdem wird der Einsatz des implementierten Sensors und seine Anwendung für Softwareprojekt-Telemetrie beschrieben. Abschließend wird im 8. Kapitel die Diplomarbeit zusammengefasst und ein Ausblick gegeben, inwieweit andere Projekte und wissenschaftliche Arbeiten auf dieser Diplomarbeit aufbauen können.

12 4 2 Software-Messung und Software-Management 2 Software-Messung und Software-Management Not everything that counts can be counted and not everything that is counted counts. (Albert Einstein)2 2.1 Aspekte der Software-Messung Ziele der Softwaremessung Das Gebiet der Softwaremessung ist ein relativ neues Gebiet der Softwaretechnik und beschäftigt sich mit der Messung von Software-Eigenschaften und der Deutung dieser Messungen. Die Software-Messung (software measurement) ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineering mit der Ausrichtung auf spezielle Messziele (measurement goals) und ggf. der Einbeziehung von Messwerkzeugen (measurement tools). [Dumke 2003, S. 169] Befürworter der Softwaremessung begründen deren Daseinsberechtigung durch Zitieren wissenschaftlicher Theoretiker als auch Praktiker: To measure is to know. (Clerk Maxwell3), You cannot control what you cannot measure. [DeMarco 1986] oder auch What is not measurable make measurable (Galileo Galilei4). Die Zielstellungen der Softwaremessung reichen von einer rein experimentellen Ausrichtung bis hin zu einer nahezu automatisierten, rechnergestützten Qualitätssicherung. Nach [Dumke 1993] gliedern sich die Ziele der Softwaremessung vor allem auch unter dem Aspekt des Machbaren in der Form als : 1. Analyse: in der Weise, dass man erst einmal das richtige Verständnis für die Software bzw. den Entwicklungsprozess erreicht, dass man Probleme lokalisiert und eine qualifizierte Bestandsaufnahme vornimmt. 2. Bewertung: als auf der Basis von Analysen durchführbare Leistungs-, Qualitäts- und Umfangsbewertung. 3. messwertgesteuerte Softwareentwicklung: die gemäß verschiedenen Qualitätsmodellen und Standards eine messwertbezogene Beeinflussung der verschiedenen Softwaremerkmale gewährleistet. Für die eigentliche Software-Messung muss jedoch klar bestimmt werden, was eigentlich gemessen werden soll, und welche Einflüsse sich auf dieses Messen einwirken. Nach [Fenton 2 Zitiert nach [Ebert 1996]. 3 Zitiert nach [Dumke 1996, S.1]. 4 Zitiert nach [Fenton 1997, S.6].

13 2 Software-Messung und Software-Management , S. 74] gilt folgende Klassifikation von Ansatzpunkten der Software-Messung (vgl. auch [Dumke 1996, S.15]): Prozess: mit all den bei der Softwareentwicklung zur Anwendung gelangenden organisatorischen und rechnergestützten Hilfsmitteln und Methoden, Produkt: mit all seinen Ausprägungen in den verschiedenen Entwicklungsphasen und den Bewertungskriterien hinsichtlich Qualität u.a.m. Ressourcen: bezogen auf das beteiligte Personal, die Soft- und Hardwareressourcen und andere Hilfsmittel bei der Softwareentwicklung. Innerhalb dieser drei Klassen werden die zu messenden Merkmale in interne und externe Attribute eingeteilt. Interne Attribute sind dem entsprechenden Messobjekt inhärent, werden also unmittelbar durch das Produkt, den Prozess bzw. die Ressource bestimmt (z.b. Anzahl der Codezeilen eines Softwaremoduls). Externe Attribute äußern sich jedoch in Hinsicht auf das Verhalten des entsprechenden Messobjektes (z.b. Benutzerfreundlichkeit bei der Programmausführung) Metriken und Messwerkzeuge Da im weiteren Verlauf häufig von Begriffen wie Maßen und Metriken die Rede sein wird, erfolgt an dieser Stelle zur Klarheit ein kurzer Exkurs in die Fachterminologie. Nach [Ebert 1996, S.4] ist Messen der Prozess, der Objekteigenschaften der realen Welt Zahlen oder Zeichen so zuordnet, dass diese Objekte anhand von definierten Regeln charakterisiert werden. Eine Software-Metrik als zahlenmäßiger Abstand einer Objekteigenschaft und wird wie folgt definiert: Eine Software-Metrik (software metric) ist gemäß der Maßtheorie (measure theory) eine Abstandsfunktion (distance), die Attributen von SoftwareKomponenten Zahlen (-bereiche) zuordnet. [Dumke 2003, S.176] Beispiele für Software-Metriken in diesem Sinne sind Kennzahlen, Formeln, Faustregeln oder auch die sogenannten SE-Gesetze (software engineering laws)5. Die Zuordnung einer Zahl oder eines Symbols und einer Einheit wird als Maß(engl. measurement)6 bezeichnet: Ein Software-Maß (software measure) ist gemäß der Messtheorie (measurement theory) eine mit einer Maßeinheit (unit) versehene Skala (scale), die in dieser Form ein Software-Attribut bewertet bzw. messbar macht.[dumke 2003, S.177] Die Klassifikationen von Software-Maßen bzw. -Metriken sind in der Fachliteratur vielfältig und gestalten sich beispielsweise nach Gesichtspunkten der messtheoretischen Eigenschaften 5 Vgl. auch [Dumke 2003, S.170]. 6 Die Verwendung der Begriffe Metrik und Maß sind international jedoch durchaus nicht einheitlich.

14 6 2 Software-Messung und Software-Management Messanforderungen technische und Managementprozesse Mess-Feedback Produktinformationen Informationsbedarf Messansatzvorhaben Einverständnis Planung des Messprozesses Planungsinformationen Realisierung der Messungen Messergebnisse Messbewertung Bewertungsergebnisse Messdatenbasis Verbesserungsaktionen Abb. 2.1: Messprozess nach ISO [ISO/IEC 2002] oder der Algorithmisierbarkeit der Software-Maße. Darum folgt an dieser Stelle nur eine grobe Übersicht, welche sich nach [Dumke 1996, S.33] unmittelbar aus den oben beschriebenen Ansatzpunkten der Software-Messung ableiten lässt: Prozessmaße (Maturity-Maße, Managementmaße, Life-Cycle-Maße) Produktmaße (Umfangsmaße, Qualitätsmaße, Komplexitätsmaße, etc.) Ressourcenmaße (Personalmaße, Softwaremaße, Hardwaremaße) Die International Organization for Standardization (ISO) entwickelte den internationalen Messstandard ISO 15939, welcher den Prozess der Software-Messung bestimmt. Hierbei wird der Prozess durch ein Modell beschrieben, welches die Aktivitäten des Messprozesses festlegt (siehe Abbildung 2.1). Forward Software Engineering Backward Software Engineering Respezifikation Spezifikation CASETools CAMETools CARETools Programmcode Redokumentation Abb. 2.2: CASE-Tools bei der Software-Entwicklung (nach [Dumke 2003, S.148])

15 7 2 Software-Messung und Software-Management Um die Kosten7 der Erfassung von Metriken während der Softwareentwicklung möglichst gering zu halten und unnötigen Aufwand zu vermeiden, ist eine weitestgehend automatische Metrikerfassung nötig [Ebert 1996, S.70]. Die hierfür notwendigen Software-Werkzeuge für die Softwaremessung innerhalb des Software-Lebenszyklus' werden hierbei unter dem Begriff CAME-Tools (computer-assisted software measurement and evaluation) zusammengefasst. Diese stellen neben den CARE-Tools (computer-aided reengineering tools) eine eigene Klasse innerhalb der sogenannten CASE-Tools (computer-aided software engineering) dar. Abbildung 2.2 veranschaulicht noch einmal die Integration von Tool-basierten Umgebungen innerhalb des Software Lebenszyklus. Die Voraussetzungen und Anforderungen für toolgestützte Softwaremessung im Kontext Telemetrie-basierter Messarchitekturen werden in Kapitel 4.2 genauer erläutert. Das bloße Messen von Eigenschaften impliziert natürlich noch nicht deren Verständnis und dient auch nicht dem alleinigen Selbstzweck. Vielmehr sollte die Softwaremessung Bestandteil eines allgemeinen Regelkreises sein, der das Analysieren und Bewerten der Messergebnisse mit einschließt, um das Produkt bzw. die Prozesse zu optimieren. Dabei kommen auf Messwerten basierende Korrektur- bzw. Transformationstools zum Einsatz, wie in Abbildung 2.3 dargestellt. Bewerten Messtools Klassifikationstools Messen Verbessern Transformationstools Abb. 2.3: Regelkreis zur Produkt- bzw. Prozessverbesserung (nach [Dumke 1996], S.38) 7 Nach [Pfleeger 1991] und [Card 1990] macht die Erfassung von Metriken während des Software-Entwicklungsprozesses ungefähr 2-5% der Projektkosten aus.

16 8 2 Software-Messung und Software-Management 2.2 Aspekte des Software-Managements Die Aufgaben des Managements sind Lenkung und Gestaltung eines betrieblichen Systems. Nach [Dumke 2003, S.207] wird der Begriff Software-Management wie folgt definiert: Das Software-Management (software management) ist die Planung, Überwachung und Steuerung des Prozesses und der dabei einzusetzenden Ressourcen zur Entwicklung, Wartung und Anwendung von Software-Systemen. Die Konstruktion eines Software-Produktes ist ein kreativer und kooperativer Arbeitsprozess, der die Planung, Durchführung und Kontrolle des Entwicklungsprozesses erfordert (vgl. auch [Rechenberg 2002, S. 1090]). In Anlehnung an das Ingenieurwesen soll das Software-Produkt systematisch als ein so genannter Prozess realisiert werden (siehe Abbildung 2.4). Standards Maßsystem Erfahrungen Anforderungen Prozess (konkret: Projekt) Ressourcen Produkt Anwendungsbereich Personal Software Hardware Abb. 2.4: Prozess der Software-Produktentwicklung (nach [Dumke 2003, S.7]) Zur Abgrenzung von der Ad-hoc-Programmierung definieren wir also: Der Software-Entwicklungsprozess (software development process) ist der gesamte Prozess der Aufgabenstellung, Planung, Realisierung und Bewertung einer Software-/Hardware-Anwendung einschließlich der verwendeten Hilfsmittel und Methoden und dem erforderlichen Personal. [Dumke 2003, S.6] Das organisatorische Modell ist dabei das Projekt und wird definiert als der konkrete Prozess zur Entwicklung eines konkreten Software-Produktes mit den dafür notwendigen Ressourcen [Dumke 2003, S.9]. Das Projektmanagement als Teil des Entwicklungsmanagements wird hierzu wie folgt definiert: Das Projektmanagement (software project management) beinhaltet die planenden, kontrollierenden, und steuernden Aktivitäten für die termingerechte

17 9 2 Software-Messung und Software-Management Bereitstellung der Ressourcen und der kostengerechten Realisierung eines Software-Produktes. [Dumke 2003, S. 216] Die grundlegenden Aspekte des Software-Managements werden noch einmal in Abbildung 2.5 zusammengefasst. Eine wichtige Rolle innerhalb des Projektmanagements spielt das Bewerten und Kontrollieren verschiedener Risiken, wie z.b. die Fluktuation des Personals sowie veränderte oder zusätzliche Anforderungen. Des weiteren sollen benötigte Ressourcen möglichst frühzeitig abgeschätzt werden, wofür verschiedene Schätzmethoden8 nutzbar sind. Software-Management Entwicklungsmanagement Wartungsmanagement Projektmanagement (SLIM, COCOMO, FP) Qualitätsmanagement (ISO9000, CMM, GQM) Konfigurationsmanagement Nothilfemanagement Anwendungsmanagement Einsatzmanagement Umstellungsmanagement Havariemanagement Konfigurationsmanagement (Versionen) Schätzformeln Messungen Erfahrungen Abb. 2.5: Aspekte des Software-Managements (nach [Dumke 2003, S.240]) Bewertung der Prozessgüte Als Qualitätsmanagement bezeichnet man die Sicherung von Qualitätsmerkmalen für das Software-Produkt auf der Grundlage der Prozess- und Ressourcenqualität durch organisatorische Methoden und Maßnahmen unter Anwendung spezieller Techniken und Technologien [Dumke 2003, S.229]. Das Deutsches Institut für Normung definiert den Begriff der Qualität wie folgt: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. [DIN 55350] In der DIN wird damit explizit auch auf einen Qualitätsbegriff für Tätigkeiten, also für Prozesse hingewiesen. Um eine ausreichende Prozess- und Ressourcenqualität zu gewährleisten, können Bewertungsnormen angewandt werden, wie z.b. der internationale Standard 8 Ein Beispiel für ein algorithmisches Schätzmodell ist COCOMO, mit welchem man den Entwicklungsaufwand anhand der zu erwartenden Programmzeilenanzahl bestimmen kann.

18 10 2 Software-Messung und Software-Management ISO 9001:2000. Danach gilt eine entsprechende Zertifizierung erst, wenn alle Fragen nach Erfüllung qualitätssichernder Anforderungen positiv beantwortet werden. Ein weiteres Modell zur Beurteilung der Güte, speziell des Software-Entwicklungsprozesses und zum Bestimmen von Verbesserungsmaßnahmen, ist das Capability-MaturityModell (CMM) [Humphrey 1989]. Ein solches Bewertungsverfahren mit Hilfe eines Fragebogens bzw. Referenzmodells wird auch als Assessment bezeichnet [Balzert 1998, 362]. Beim CMM werden fünf unterschiedliche Qualitätsstufen von Software-Entwicklungsprozessen unterschieden, wobei jede Qualitätsstufe einen bestimmten Reifegrad beschreibt (vgl. auch Tabelle 2.1). Das Erlangen einer Stufe setzt jedoch voraus, dass die Anforderungen an die Prozesse vorhergehender Stufen erfüllt sind. Schwerpunkte der Fragen sind Organisation des Projekt-Managements, des Prozessmanagements und der Technologie [Dumke 2003, S.232f.]. Zum Bestimmen des Reifegrades einer Entwicklungsorganisation wurden zu erfüllende Hauptkriterien (key process area) pro Reifestufe aufgestellt. So genannte Aspekte (key practices)9 geben an, was zu tun ist, um die jeweiligen Hauptkriterien zu erfüllen. CMM-Stufe 1 Initialer Prozess (initial) Prozess-Charakteristika Chaotischer, ad hoc Prozess Unvorhersehbare Kosten Zeit und Qualität 2 Wiederholba- Intuitiver Prozess rer Prozess Kosten & Qualität schwanken (repeatable) gute Termin-Kontrolle Informelle Vorgehensweise Prozess abhängig von Individuen Notwendige Aktionen Planung Fortschrittsüberwachung Änderungsmanagement Qualitätssicherung Prozess-Standards entwickeln Methoden einführen Assessments (punktuell, ad hoc) (Definition, Entwurf, Inspektion, Test) 3 Definierter Prozess (defined) Qualitativer Prozess Zuverlässige Kosten & Termine Verbesserte, aber unvorhersehbare Qualität Prozess ist unabhängig von Individuen, institutionalisiert Prozesse 4 Gesteuerter Prozess (managed) Quantitativer Prozess gute statistische Kontrolle über die Produktqualität Prozess durch Metriken gesteuert Quantitative 5 Optimierender Rückgekoppelter Prozess Prozess Quantitative Basis für andau(optimizing) ernde Kapital-Investitionen in die Prozessautomatisierung & -verbesserung Messniveau analysieren Quantitative cherung vermessen und kontinuierliche Messung & QualitätssiBewertung (punktuell, kontinuierlich) Produktivitätskontinuierliche pläne & Prozessüberwachung Messung, Instrumentierte Prozessumge- Bewertung & Konbung trolle Ökonomisch gerechtfertigte (prozessüberinvestitionen in Technologien greifend) Kontinuierlicher Schwerpunkt auf Prozess-Vermessung & Prozess-Methoden zur Fehlervermeidung kontinuierliche Messung, Bewertung & Verbesserung (gesamtprozessüberdeckend) Tab. 2.1: Qualitätsstufen des CMM ([Humphrey 1989], [Dumke 2003, S.232]) 9 Aspekte geben jedoch nicht an, wie ein entsprechendes Hauptkriterium erreicht werden kann.

19 11 2 Software-Messung und Software-Management CMMI (Capability Maturity Model Integration) ist die neue Version des Software Capability Maturity Modells und soll dieses allmählich ersetzen [Ahern 2003]. CMMI integriert dabei verschiedene Qualitäts-Modelle für unterschiedliche Entwicklungs-Disziplinen in einem neuen, modularen Modell und umfasst somit einen größeren Anwendungsbereich. Der Einfachheit halber wird in dieser Diplomarbeit nicht zwischen beiden Varianten unterschieden, wenn von CMM die Rede ist Personal Software Process We can, however, no longer muddle through on intuition; the process is too complex and the products too important. (Watts S. Humphrey)10 Nach [Ebert 1996, S.2] ist die Messung des Entwicklungsprozesses und seiner Ergebnisse der kritische Erfolgsfaktor nicht nur in der Software-Technik. Eine besondere Rolle beim Software-Entwicklungsprozess spielt das Personal, denn schon [Brooks 1975] weist auf Produktivitätsunterschiede zwischen Software-Entwicklern von bis zu 1:10 hin. Das hierzu gebräuchlichste Modell zum Bestimmen der Produktivität drückt sich nach [Fenton 1997, S.97] durch folgendes Verhältnis aus: Produktivität = Prozessergebnis des Personals Output personeller Aufwand Kosten während Prozess Input In jüngster Zeit wird der Begriff der Produktivität jedoch aus einer anderen Perspektive betrachtet: Maßgeblich ist dabei der Reparaturaufwand nach der Auslieferung eines Produktes, verursacht durch Fehler, die schon im vornherein korrigierbar gewesen wären. Danach vergleichen einige Software-Ingenieure die Kosten der Fehlervermeidung mit den Kosten der Fehleraufdeckung und -korrektur, um Rückschlüsse auf die Produktivität zu ziehen (siehe auch [Fenton 1997, S.97]). Zur Verbesserung der Effizienz und Wirksamkeit des Entwicklungspersonals entwickelte Humphrey am Software Engineering Institute (SEI) der Carnegie Mellon University ein grundlegendes Modell: den so genannten Personal Software Process (PSP). Dieser soll Software-Entwickler dazu ermutigen, ihre individuelle Leistungsfähigkeit und Produktionsqualität zu bewerten, um die Anforderungen des Capability Maturity Model konkret umsetzen zu können [Humphrey 1995, S.6ff]. Datum Start Stopp Unterbrechungszeit Zeitintervall Aktivität Kommentar Endekennzeichen Anzahl Tab. 2.2.: Aktivitätsmerkmale beim PSP (nach [Dumke 2003, S.127]) 10 Zitiert nach [Florac 1999, S.1].

20 12 2 Software-Messung und Software-Management Grundlage des PSP ist das manuelle Erfassen von Daten mittels Formularen durch den Entwickler (vgl. auch Tabelle 2.2). Aufgezeichnet werden dabei sein individueller SoftwareEntwicklungsprozess und Metriken der Softwareprodukte, z.b. Arbeitszeiten und Unterbrechungen des Programmierers, aber vor allem auch gefundene Software-Defekte. Aus diesen Daten werden nach vorgegebenen Verfahren Analysen erstellt, deren Ergebnisse sich wieder auf den Prozess auswirken. Die dokumentierten Arbeitszeiten etwa werden benutzt, um zukünftig genauere Abschätzungen über die zu investierende Arbeitszeit vorzunehmen. Aus den dokumentierten Defekten werden Prüflisten erstellt, die bei vorgeschriebenen CodeReviews benutzt werden, um individuell typische Defekte zu finden. Neben der Fehlerprävention durch Sammeln und Klassifizieren von Fehlerdaten (Qualitätssicherung) dient PSP also vor allem auch einer verbesserte Größen- und Zeitabschätzung für Software-Projekte. PSP verschiebt dabei die Definition der Metriken, Datenerfassung und Analyse von der Organisationsebene in den Bereich des Individuums. Dem PSP liegt eine autodidaktische Lernstrategie zugrunde, welche die gemessenen Leistungsmerkmale des SoftwareIngenieurs nutzt, um eine Verbesserung des eigenen Prozesses zu motivieren [Hayes 1997]. Abbildung 2.6 zeigt, wie jede Stufe des PSP auf den erlangten Fähigkeiten und gesammelten Daten der vorhergehenden Stufe aufbaut. Studien innerhalb und außerhalb des SEIs bestätigen, dass die Aneignung sowie Anwendung von PSP signifikante Vorteile für die anwendende Person bedeuten kann und folglich auch Verbesserungen der Produktqualität insgesamt. Dies zeigt z.b. die sechsjährige Forschungsstudie eines PSPKurses von [Johnson 2003, S.2.ff.] (vgl. aber auch [Humphrey 1995, S.19ff.], [Humphrey 1996] und [Wesslén 2000]). Das Software Engineering Institute Pittsburgh konnte zeigen, dass sich die Schätzgenauigkeit und Produktqualität durch PSP signifikant verbessern (vgl. [Hayes 1997]). PSP3 Cyclic development PSP2 PSP2.1 Code reviews Design reviews Design templates PSP1 PSP1.1 Size estimation Test report Task planning Schedule planning Cyclic Personal Process Personal Quality Management Personal Project Management PSP0.1 PSP0 Current process Basic measures Coding standard Process improvement proposal Size measurement Baseline Personal Process Abb. 2.6: Schritte des Personal Software Process (nach [Humphrey 1996, S.79])