Konzeption und prototypische Implementierung eines Frameworks zur automatisierten Softwaremessung

Konzeption und prototypische Implementierung eines Frameworks zur automatisierten Softwaremessung Von der Universität Bayreuth zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigte Abhandlung von Bernhard Daubner geboren in München 1. Gutachter: Prof. Dr. Andreas Henrich 2. Gutachter: Prof. Dr. Bernhard Westfechtel Tag der Einreichung: 05.03.2008 Tag des Kolloquiums: 09.07.2008 Meinem Vater Hermann Daubner (b1940 d1980) gewidmet ii Conceptual Design and prototypical Implementation of a Framework for automated Software Measurement Abstract Within corporate management so called Management Cockpits or Management Support Systems are well known. These IT systems are designed for the visualisation of decision-relevant information. They are able to provide company management with key performance indicators about the company’s operations at a click. Analogously, project cockpits are meant to provide project managers with performance indicators about ongoing IT projects. Examples are test coverage, completion rate, code quality or spent effort. The measurement tools should be able to record these software measures automatically. Available software measurement applications however either strongly depend on certain process models or development environments, can not perform measures automatically but only visualize manually entered information or can only be configured or extended by the user in a limited way. Within this work a framework for automated software measurement is presented. Its main features are the large degree of measurement automation and the possibility, to define the software measures to collect independently of a concrete project. For this purpose context information is used to create anchor points for software measures. A context can be a certain activity of the underlying process model, a project phase or a functionality that has to be implemented. Thus it is possible, for instance, to restrict size measurements on certain project phases or on components that provide a certain functionality. Many measurement tools only allow to measure already completed artefacts or only can collect software measures that concern the whole project. In contrast to these tools the approach presented here makes it possible to define software measures with respect to a certain context. The entities that actually have to be measured need not to be known at the time the software measure is defined. Thus software measures can be collected in a standardized way across project borders. As prototypical implementation of the software measurement approach a framework is presented that is based on an Open-Source project management tool. The framework, which provides API functions to gather simple software measures, allows the flexible definition of complex software measures that are computed automatically at project’s runtime and are visualized where appropriate. The definition of the software measures to collect is done by means of the underlying project management tool. Thus already maintained project information can be reused. In order to proof the potential of this approach the measurement tool is evaluated within the scope of two student software development projects. iii iv Kurzfassung Im Rahmen der betriebswirtschaftlichen Unternehmenssteuerung sind sogenannte Management-Cockpits oder Managementunterstützungssysteme schon länger bekannt. Dabei handelt es sich um EDV-Systeme zur Visualisierung entscheidungsrelevanter Daten, welche insbesondere der Unternehmensleitung auf Knopfdruck wesentliche Kenngrößen (Key Performance Indicators) des Unternehmens darstellen. Analog dazu sollen Projektleitstände den Projektleitern entsprechende Kenngrößen der laufenden IT-Projekte darstellen. Derartige Kennzahlen sind beispielsweise die Testabdeckung, der Fertigstellungsgrad, die Code-Qualität oder der bereits erbrachte Arbeitsaufwand. Diese Softwaremaße sollten dazu von den Messwerkzeugen automatisiert erfasst werden können. Aktuell verfügbare Anwendungen zur Softwaremessung sind jedoch entweder stark an bestimmte Prozessmodelle oder Entwicklungsumgebungen gebunden, können teilweise selbst keine Messwerte ermitteln und dienen somit als reine Visualisierungswerkzeuge oder können nur eingeschränkt von den Anwendern konfiguriert oder erweitert werden. Im Rahmen dieser Arbeit wird daher ein Framework zur automatisierten Softwaremessung vorgestellt. Zu dessen wesentlichen Anforderungen gehören die weitgehende Automatisierung des Messprozesses und die Möglichkeit, die zu erhebenden Softwaremaße unabhängig von einem konkreten Projekt definieren zu können. Dazu werden Kontextinformationen bestimmt, welche als Anknüpfungspunkte für die zu erhebenden Softwaremaße dienen. Ein Kontext kann dabei eine bestimmte Aktivität des zugrunde liegenden Vorgehensmodells, eine Projektphase oder eine zu implementierende Funktionalität sein. Dadurch ist es beispielsweise möglich, Umfangsmessungen auf bestimmte Projektphasen oder auf Komponenten, durch die bestimmte Funktionalitäten implementiert werden, einzuschränken. Im Gegensatz zu vielen anderen Messwerkzeugen, die entweder nur die Vermessung von bereits erstellten Artefakten erlauben oder Softwaremaße nur auf der Ebene des Gesamtprojekts ermitteln können, ermöglicht es der hier dargestellte Ansatz, Softwaremaße in Bezug auf einen bestimmten Kontext zu definieren. Die konkrete Ausprägung der letztendlich zu messenden Entitäten muss zum Zeitpunkt der Definition des Softwaremaßes noch nicht bekannt sein. Dadurch kann erreicht werden, dass Softwaremaße standardisiert und über Projektgrenzen hinweg konsistent ermittelt werden können. Als prototypische Implementierung dieses Softwaremessungsansatzes wird ein Framework dargestellt, welches auf einer Open-Source-Projektverwaltungssoftware basiert. Dieses Framework, welches entsprechende API-Funktionen zur Ermittlung einfacher Softwaremaße zur Verfügung stellt, erlaubt die flexible Definition komplexer v Softwaremaße, welche dann zur Projektlaufzeit automatisiert ermittelt und gegebenenfalls visualisiert werden können. Zur Definition der zu erhebenden Softwaremaße wird auf die Konfigurationsmöglichkeiten der zugrunde liegenden Projektverwaltungssoftware zurückgegriffen. Dadurch können bei der Softwaremessung bereits vorhandene Projektinformationen wiederverwendet werden. Um die Tragfähigkeit des in dieser Arbeit dargestellten Ansatzes unter Beweis zu stellen, wird die Evaluierung dieses Messwerkzeuges anhand zweier studentischer Softwareentwicklungsprojekte dargestellt. vi Vorwort Im Prinzip erwies sich die wirtschaftliche Schieflage, in welche die SchmidtBank KGaA in Hof als mein ehemaliger Arbeitgeber im Jahr 2001 geraten war, als Auslöser für mich, ein Promotionsvorhaben zu beginnen. Ich stand damals nach mehreren Jahren Berufstätigkeit im Banken-IT-Umfeld vor der Wahl, einen unsicher gewordenen Arbeitsplatz gegen ein Projekt mit unbekanntem Ziel und noch weniger bekannten Weg dorthin einzutauschen. Herr Prof. Dr. Andreas Henrich, der damals den neu gegründeten Lehrstuhl für Softwaretechnik an der Universität Bayreuth innehatte, hat mich in persönlichen Gesprächen und per eMail ermutigt, diesen Weg zu gehen. An dieser Stelle möchte ich ihm nicht nur für die Motivation und die Betreuung dieser Arbeit als Doktorvater meinen Dank aussprechen, sondern auch dafür, dass er es mir durch die Anstellung als wissenschaftlichen Mitarbeiter an seinem Lehrstuhl überhaupt erst ermöglicht hat, ein Promotionsvorhaben anzugehen. Auch wenn das Thema eigentlich von Anfang an im Bereich der Werkzeugunterstützung für die Softwaremessung angesiedelt war, lies mir mein Doktorvater die Freiheit, mich zunächst ausgiebig mit benachbarten Themen, wie dem Requirements-Engineering oder der Fortschrittsmessung von SAP-R/3-Projekten zu beschäftigen, um dann nach ca. zwei Jahren doch noch zum letztendlichen Thema dieser Arbeit vorzudringen. Genauso möchte ich mich bei Herrn Prof. Dr. Bernhard Westfechtel nicht nur für die Übernahme des Zweitgutachtens auf das herzlichste bedanken, sondern auch dafür, dass er sich als Betreuer vor Ort geduldig Zeit genommen hat, um mit mir Hindernisse und neue Aspekte zu diskutieren, aber auch, um kritische Anmerkungen und wertvolle Anregungen zu machen. Auch am Lehrstuhl von Prof. Westfechtel fand ich ein anregendes und harmonisches Arbeitsklima vor, welches es mir ermöglichte, meine Doktorarbeit erfolgreich abzuschließen. Einen wesentlichen Anteil an dem fruchtbaren Arbeitsumfeld hatten auch meine zahlreichen Lehrstuhlkollegen, welche auf die Standorte Bayreuth und Bamberg verteilt waren. Namentlich möchte ich hier insbesondere Sabrina Uhrig, Thomas Buchmann, Alexander Dotor, Martin Eisenhardt, Volker Lüdecke, Dr. Karlheinz Morgenroth, Dr. Wolfang Müller und Dr. Günter Robbert erwähnen. Darüber hinaus danke ich auch den weiteren Lehrstuhlmitgliedern Monika Glaser und Bernd Schlesier, die als gute Seelen im Hintergrund für einen reibungslosen Betrieb des Lehrstuhls und seiner Infrastruktur sorgten. Zum Schluss möchte ich mich noch sehr bei meiner Ehefrau Heike bedanken, welche die nicht beneidenswerte Aufgabe übernommen hat, diese Arbeit auf typographische Fehler und unklare Formulierungen durchzusehen. Hof, im Juli 2008 Bernhard Daubner vii 1 Einleitung zu können. Für die Aufwandsschätzungen wiederum sind, neben den Anforderungen an die zu entwickelnde Software, genaue Kenntnisse über die eingesetzten Softwareentwicklungsprozesse notwendig. Dabei ist sowohl in der Literatur als auch bei den operativ tätigen Praktikern akzeptiert, dass Softwaremessung sowohl taktisch im Rahmen der Planung, der Bewertung und des Controllings einzelner Softwareprojekte als auch strategisch zur Gewinnung von Erfahrungen mit den eingesetzten Entwicklungsprozessen und zur Prozessverbesserung erfolgreich eingesetzt werden kann. Die in den Nachrichten vielfach gemeldeten Probleme bei der Umsetzung von IT-Projekten (z. B. LKW-Maut, Job-Portal der Bundesagentur für Arbeit, Bundeswehr-IT-Projekt Herkules) verdeutlichen jedoch, wie schwer es den Beteiligten fällt, die vertraglich vereinbarten Anforderungen an Umfang, Qualität und Kosten der IT-Projekte auch zu erfüllen. Dabei dringen üblicherweise nur die Probleme der populärsten IT-Projekte, welche auch für das Allgemeininteresse von Bedeutung sind, ans Licht der Öffentlichkeit. Die Ursachen für den häufig unbefriedigenden Verlauf oder gar das Scheitern von Softwareentwicklungsprojekten sind vielfältig. Ein Grund ist sicherlich auch in der ungenügenden Anwendung von Software-Messverfahren zur Erkennung von Planabweichungen bei Softwareprojekten und zum Aufbau einer Wissensund Erfahrungsbasis für die verwendeten Softwareprozesse zu suchen. Der Nutzen der Softwaremessung wird zwar auch von den meisten Praktikern grundsätzlich nicht in Frage gestellt, jedoch tragen sämliche Aktivitäten im Rahmen Softwaremessung als Kostenfaktor der Softwaremessung, wie auch alle übrigen Tätigkeiten im Rahmen des unternehmensweiten Controllings, erst einmal nichts zur Produktivität bei. Daher gehören Aktivitäten zur Softwaremessung zu den ersten Tätigkeiten, auf die verzichtet wird, falls sich innerhalb eines Projekts terminliche oder personelle Engpässe abzeichnen. Oder es werden zwar im Rahmen des Softwareentwicklungsprojektes Techniken zur Softwaremessung angewendet, dabei aber nicht die geeigneten Softwaremaße erhoben, die Messverfahren fehlerhaft durchgeführt oder die falschen Schlüsse aus den Messergebnissen gezogen. 1.2 Zielsetzung und Aufbau der Arbeit Das Ziel der vorliegenden Arbeit ist daher, ein Framework zur Softwaremessung zu entwickeln, welches gerade den Praktikern die Anwendung von Software-Messverfahren erleichtern soll. Dies beinhaltet zunächst, die Softwaremessung so weit wie möglich zu automatisieren und damit gleichsam zu standardisieren. Das bedeutet, dass der operativ tätige Automatisierung der Softwaremessung Projektmitarbeiter so wenig wie möglich mit Routinetätigkeiten wie dem manuellen Führen von Prüfund Messlisten belastet werden soll, um sich seinen eigentlichen Aufgaben widmen zu können. Stattdessen sollen durch dieses Framework vordefinierte Softwaremaße (z. B. Produktivitätsmaße) zusammen mit ihrem Kontext (z. B. Kontext der Softwaremessung die zugehörige Aktivität im Rahmen des Softwareentwicklungsprozesses) regelmäßig 2 1.2 Zielsetzung und Aufbau der Arbeit und automatisiert erhoben und die Ergebnisse geeignet aufbereitet werden. Zu diesem Zweck müssen vorher entsprechende Informationsbedürfnisse identifiziert und daraus die relevanten Softwaremaße abgeleitet werden. Dabei sollen in dieser Arbeit weder neue Softwaremaße entwickelt noch gänzlich neue Verfahren zur Erhebung dieser Softwaremaße dargestellt werden. Das hier erarKombination bewährter Ansätze beitete Framework soll stattdessen bewährte Ansätze der Softwaremessung miteinander verknüpfen und mittels Automatisierung eine Möglichkeit zur standardisierten und konsistenten Durchführung bereits bekannter Software-Messverfahren bieten. 1.2.1 Anforderungen an das Softwaremessungs-Framework Konkret soll das zu entwickelnde Framework zur Softwaremessung die folgenden Anforderungen erfüllen: •Automatisierung der Messdurchführung Die eigentliche Softwaremessung soll möglichst automatisiert erfolgen, so dass die Anwender (Projektmanager, Projektmitarbeiter) von entsprechenden Routine-Tätigkeiten entlastet werden. Für Projektinformationen, welche nicht maschinell erfasst werden können (z. B. Arbeitszeiten für bestimmte Tätigkeiten), sollen entsprechende Erfassungmasken zur Verfügung gestellt werden. •Dynamische Definition von Softwaremaßen Softwaremaße sollen von den verantwortlichen Projektmitarbeitern dynamisch zur Projektlaufzeit definiert werden können. Dabei soll auch die Definition komplexer (d. h. mittels mathematischer Formeln verknüpfter) Softwaremaße möglich sein. •Wiederverwendung von Softwaremaßen Einmal definierte Softwaremaße sollen auch in nachfolgenden Projekten wiederverwendet werden können. Daher muss die Erhebung der Softwaremaße in gleicher Weise erfolgen, um die Messergebnisse vergleichbar zu machen. Diese Anforderung impliziert auch, dass es möglich sein muss, die zu erhebenden Softwaremaße unabhängig von einem konkreten Projekt zu definieren. •Automatische Identifikation der zu messenden Entitäten Aus den Forderungen nach der automatisierten Messdurchführung und der Wiederverwendbarkeit von Softwaremaßen folgt unmittelbar, dass das Framework in der Lage sein muss, die letztendlich zu vermessenden Entitäten maschinell zu identifizieren. Bei Softwaremaßen, die sinnvoll auf verschiedene Projekte angewendet werden können, muss dieser Identifikationsmechanismus auch entsprechend über Projektgrenzen hinweg funktionieren. •Visuelle Aufbereitung der Messergebnisse Die Messergebnisse sollen visuell aufbereitet und in übersichtlicher Form dargestellt werden können. 3 1 Einleitung •Persistierung der Messergebnisse Die Messergebnisse sollen dauerhaft gespeichert werden können, um bei der Durchführung von Messungen Vergleichsmöglichkeiten mit früheren Messungen zu haben. •Einfache Handhabung Der Einarbeitungsaufwand in die Benutzung des Softwaremessungs-Frameworks sollte niedrig genug sein, um potentielle Anwender nicht abzuschrecken. Insbesondere sollen durch eine einfache Handhabbarkeit des Systems Softwareentwickler, die bis jetzt keine Softwaremessverfahren eingesetzt haben, ermutigt werden, Erfahrungen mit der Anwendung von Softwaremessungstechniken zu sammeln. •Integrierbarkeit in bestehende Umgebungen Das Softwaremessungs-Framework sollte sich einfach in bestehende Entwicklungsumgebungen integrieren lassen, da es insbesondere bei großen Unternehmen wahrscheinlich ist, dass dort bereits umfangreiche Systeme zur Projektverwaltung und zur Softwareentwicklung im Einsatz sind. •Niedrige Anschaffungsund Betriebskosten Da, wie weiter oben gefordert, die Hemmschwelle zur Anwendung von Verfahren der Softwaremessung mittels des in dieser Arbeit entwickelten Softwaremessungs-Frameworks möglichst klein sein soll, sollten auch keine oder nur geringe Anschaffungsund Betriebskosten anfallen. Diese Forderung lässt sich im Allgemeinen durch die Verwendung von Open-Source-Komponenten erfüllen. •Plattformunabhängigkeit Schließlich sollte das Softwaremessungs-Framework auf möglichst vielen verschiedenen Betriebssystemplattformen einsetzbar sein. Dies ist insbesondere in den Fällen relevant, in denen das Framework in eine bestehende heterogene Systemlandschaft integriert werden soll. Die letzten vier Punkte können auch unter dem Schlagwort „Leichtgewichtigkeit“ subsumiert werden, weil die Anwender des Softwaremessungs-Frameworks nicht geLeichtgewichtiges Framework zur Softwaremessung zwungen werden sollen, ihre Prozesse zu ändern oder auf andere Entwicklungswerkzeuge zu wechseln. Insgesamt ist somit das Ziel dieser Arbeit, ein leichtgewichtiges Framework für die Softwaremessung zu entwickeln, welches es erlaubt, die für die jeweilige Organisation als wichtig erkannten Softwaremaße standardisiert und automatisiert zu erheben. Dieses Framework besteht aus einem methodischen Konzept zur Definition der zu erhebenden Softwaremaße und einer prototypischen Implementierung einer entsprechenden Werkzeugunterstützung. Der weitere Aufbau dieser Arbeit orientiert sich daher an der Motivation, Herleitung und Implementierung dieses leichtgewichtigen Ansatzes. 4 1.2 Zielsetzung und Aufbau der Arbeit 1.2.2 Aufbau der Arbeit Im Kapitel 2 wird zuerst der Themenbereich der Softwaremessung, welcher auch mit dem immer häufiger verwendeten Begriff Softwaremetrie bezeichnet wird, untersucht und näher bestimmt. Dabei sollen insbesondere die Begriffe Softwaremaß und Softwaremetrik gegeneinander abgegrenzt werden. Daneben wird ein grundlegenDefinition und Ziele der Softwaremessung der Überblick über die Ziele und Einsatzmöglichkeiten der Softwaremessung gegeben. Weiter werden Kriterien aufgezeigt, anhand derer die unüberschaubare Menge der in der Literatur beschriebenen Softwaremaße näher klassifiziert und geordnet werden kann. So enthält beispielsweise allein die Softwaremaß-Sammlung ZD-MIS (Zuse/Drabe – Measure-Information-System) [Zus98] über 1500 Softwaremaße zusammen mit einer einheitlichen Beschreibung. Auch wenn somit an verfügbaren Softwaremaßen kein Mangel herrscht, macht es verständlicherweise wenig Sinn, im Rahmen eines Softwaremessungsvorhabens willkürlich einige Softwaremaße auszuwählen und diese während des Projektes zu erfassen. Stattdessen erfolgt der Einsatz von Softwaremessverfahren üblicherweise aufAuswahl geeigneter Softwaremaße grund unternehmerischer Ziele (z.B. Verbesserung der Kundenzufriedenheit) oder zumindest auf Basis von Zielsetzungen innerhalb des Software Engineerings (z. B. Reduzierung des Wartungsaufwandes für die Software), so dass die hierfür relevanten und sinnvoll anwendbaren Softwaremaße entsprechend ausgewählt werden müssen. Daher sollen verschiedene Strategien für eine zielorientierte Auswahl von Softwaremaßen bzw. für einen sinnvollen Einsatz von Softwaremessverfahren dargestellt werden. Zusätzlich wird untersucht, ob es Standard-Softwaremaße gibt, welche für die meisten Softwareprojekte relevant sind und daher grundsätzlich erhoben werden sollten. Anschließend wird in Kapitel 3 der aktuelle Forschungsstand bzw. der aktuelle Stand der Technik auf dem Gebiet der Messwerkzeuge und -verfahren dargestellt. Stand der Technik Die Messwerkzeuge lassen sich dabei folgendermaßen gliedern: •Messwerkzeuge, welche in Standard-Entwicklungsumgebungen integriert sind, dienen hauptsächlich zur Anwendung einfacher Softwaremaße auf den Programmcode bzw. auf UML-Diagramme. •Sogenannte Dashboards können die Ergebnisse bestimmter, vordefinierter Softwaremaße visualisieren. Dabei handelt es sich meistens um Softwaremaße, welche auf Managementebene relevant sind und deren Ausprägungen häufig plakativ in Form einer Ampel dargestellt werden. •Sogenannte Projektleitstände versuchen, Softwaremaße und sonstige Projektinformationen zielgerichtet zu sammeln und entsprechend aufbereitet zu visualisieren. Jedoch sind hier die Softwaremaße im Gegensatz zu den Dashboards nicht fest vorgegeben, sondern frei konfigurierbar. Nachdem in Kapitel 4 zunächst kurz dargestellt wird, welche Softwaremaße insbesondere auf Management-Ebene von Interesse sind, wird anschließend die Kernidee Softwaremaße auf Managementebene dieser Arbeit erläutert. 5 1 Einleitung Zu den Hauptanforderungen an das innerhalb dieser Arbeit entwickelte Framework zur Softwaremessung gehört, dass die zu erhebenden Softwaremaße frei definiert und zur Projektlaufzeit automatisiert erfasst werden können. Damit ergibt sich die Anforderung, dass die Identifikation der zu messenden Entitäten zur Projektlaufzeit maschinell erfolgen muss. Daher wird untersucht, welche Elemente des Softwareentwicklungsprozesses es gibt, die als Anknüpfungspunkte für Softwaremaße dienen Anknüpfungspunkte für Softwaremaße können. Die Verwendung dieser Anknüpfungspunkte ermöglicht es, zur Laufzeit die zu messenden Entitäten automatisiert zu identifizieren. In diese Betrachtungen werden verschiedene Vorgehensmodelle mit einbezogen und auf die Anwendbarkeit dieses Ansatzes hin untersucht. Dabei werden konkrete Handlungsanweisungen für die Definition von Softwaremaßen erarbeitet, welche dann letztendlich zu dem Softwaremessungs-Framework führen. Eine wichtige Messgröße, welche insbesondere im Rahmen des Projektmanagements von Bedeutung ist, ist der Projektfortschritt. Daher soll am Beispiel des Fortschrittsmessung Feature Driven Developments eine Möglichkeit der Fortschrittsmessung dargestellt werden, welche sich auch (zumindest teilweise) automatisieren lässt. Die Ermittlung des Projektfortschritts setzt grundsätzlich die Kenntnis des geplanten Aufwandes voraus. Da dieser insbesondere zu Beginn des Projekts und damit Vertragsmodelle zum Zeitpunkt des Vertragsabschlusses nur schwer und mit entsprechenden Fehlerwahrscheinlichkeiten zu bestimmen ist, sollen auch alternative Bepreisungsmodelle für Softwareprojekte dargestellt werden. Zum Abschluss dieses Kapitels wird der Live-Ansatz vorgestellt. Dieser wurde entworfen, um die Eignung einer Softwareentwicklungsumgebung für die Anwendung agiler Methoden zu beurteilen. Es wird jedoch gezeigt, dass mittels der im LiveReifegradmodell zur Effektivität von Softwaremessung Ansatz dargestellten Konzepte auch die Effektivität von Softwaremessungsmaßnahmen beurteilt werden kann. Daran anschließend wird in Kapitel 5 das Konzept für das SoftwaremessungsFramework erläutert und eine konkrete Implementierungsmöglichkeit mittels der Open Source Software Maven beschrieben, welches ein Framework zur AutomatiImplementierung des Ansatzes sierung von Aufgaben im Rahmen der Softwareentwicklung ist. Zu diesem Zweck wird zunächst die grundlegende Architektur von Maven und dessen Erweiterungsmöglichkeiten mittels Plugins untersucht. Anschließend wird die Architektur des Softwaremessungs-Frameworks beschrieben. Es folgt in Kapitel 6 eine Evaluierung des innerhalb dieser Arbeit entwickelten Softwaremessungs-Frameworks anhand zweier studentischer SoftwareentwicklungsEvaluierung projekte. An dieser Stelle werden auch die Grenzen des beschriebenen Ansatzes erläutert. Abschließend werden in Kapitel 7 die Ergebnisse dieser Arbeit zusammengefasst und es wird ein Ausblick auf weitere Forschungsaspekte bzw. noch offene Problemfelder gegeben. 6 2 Softwaremessung You cannot have a science without measurement. (Richard W. Hamming) 2.1 Definition und Ziele der Softwaremessung 2.1.1 Grundbegriffe Die Softwaremessung beschäftigt sich als Teilgebiet der Softwaretechnik mit der Messung von Eigenschaften von Software und den bei der Erstellung der Software verwendeten Prozessen. Alternativ wird immer häufiger auch der Begriff Softwaremetrie (vgl. [Wik]) verwendet, welcher laut Zuse erstmals im Jahre 1987 eingeführt Softwaremetrie wurde (vgl. [Zus98], S. 15). Der Begriff Messung bezeichnet dabei nach [FP98] einen Prozess, bei dem Attributen von Entitäten aus der realen Welt (den Messobjekten) Messwerte nach klar definierten Regeln zugeordnet werden. Die Softwaremaße beziehen sich dabei auf Attribute eines oder mehrerer Objekte der Softwareanwendung, des Softwareentwicklungsprozesses oder der Softwarewartung. Daher verwenden wir in Anlehnung an [Dum01] die folgende Definition: Definition 2.1 Die Softwaremessung ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineerings mit der Ausrichtung auf spezielle Messziele und ggf. der Einbeziehung von Messwerkzeugen. Bei der Softwaremessung werden also Objekte aus der Welt des Software Engineerings auf Elemente der Mathematik und dabei insbesondere auf Zahlen und Symbole Softwaremessung als Abbildung abgebildet, mit dem Ziel, eine Eigenschaft oder ein Attribut einer Entität aus dem Software Engineering quantitativ zu bestimmen. Beispielsweise wird durch das SoftEntität waremaß Lines of Code (LOC) der Eigenschaft Länge eines Software-Sourcecodes ein Wert, nämlich die Anzahl der Code-Zeilen, zugeordnet. Daher definieren sowohl [FP98] als auch [Zus98] eine Messung als Abbildung von den Eigenschaften von Objekten der empirischen Welt auf formale Objekte (Zahlen oder Symbole). Insbesondere erscheint an dieser Stelle der Begriff der Abbildung von Bedeutung, da sich diese auch bei der Definition des Maßes in der Mathematik finden lässt. Mathematisch ist ein Maß eine Abbildung von einem Teilmengensystem über einer Grundmenge auf die Menge der reellen und komplexen Zahlen. Daher definieren Softwaremaß wir das Softwaremaß innerhalb dieser Arbeit folgendermaßen: 7 2 Softwaremessung Definition 2.2 Ein Softwaremaß ist eine Abbildungsvorschrift, welche Attributen von Elementen des Software Engineerings einen Zahlenwert zuweist, um dieses Attribut näher zu charakterisieren. Dieser Zahlenwert wird als Messwert bezeichnet. Daher muss beispielsweise bei dem Softwaremaß LOC (siehe oben) auch angegeben werden, welche Sourcecode-Zeilen tatsächlich zu zählen sind. In der Literatur und in der praktischen Anwendung differieren hier die Meinungen erheblich. Insbesondere geht es dabei darum, ob auch Kommentarbzw. Leerzeilen zu zählen sind oder nicht (siehe dazu auch Abschnitt 2.3). Sowohl [FP98] als auch [Zus98] weisen an dieser Stelle darauf hin, dass diese Messwerte sich auf verschiedene Mess-Skalen (z.B. nominale, ordinale oder absoMess-Skala lute) beziehen können. Diese Detaillierung ist jedoch für das weitere Verständnis dieser Arbeit nicht notwendig. Für eine tiefergehende Betrachtung wird daher auf die genannten Monographien verwiesen. Viel wichtiger erscheint es stattdessen, an dieser Stelle den Begriff des Maßes von dem der Metrik abzugrenzen, auch oder gerade weil die Begriffe Softwaremaß und Metrik Softwaremetrik sowohl in der deutschsprachigen als auch in der englischsprachigen Literatur oft synonym verwendet werden. Eine Metrik im mathematischen Sinn ist folgendermaßen definiert: Definition 2.3 Sei Xeine beliebige Menge. Eine Abbildung d:X×X−→ Rheißt Metrik, wenn für beliebige x, y, z ∈Xdie folgenden Bedingungen erfüllt sind: d(x, y) = 0 ⇔x=y(Definitheit) d(x, y) = d(y, x)(Symmetrie) d(x, y)≤d(x, z) + d(z, y)(Dreiecksungleichung) Der Wert der Abbildung d(x, y)kann als der Abstand der Elemente xund y voneinander aufgefasst werden. Somit handelt es sich also bei einer Softwaremetrik eigentlich um ein Abstandsmaß: Softwaremetrik Definition 2.4 Eine Softwaremetrik ist eine Abstandsfunktion, die Paaren von Attributen von Softwarekomponenten Zahlen zuordnet. (vgl. [Dum01]) In [FP98] (S. 103) finden sich auch entsprechende Beispiele für Softwaremetriken, welche auch der mathematischen Definition einer Metrik Genüge tun. Beispielsweise werden bei der N-Versionen-Programmierung (vgl. [Avi95], [AC77]) nverschiedene Versionen einer kritischen Softwarekomponente unabhängig voneinander implementiert. Die Annahme dabei ist, dass die Wahrscheinlichkeit, dass die nverschiedenen Beipiele für Softwaremetriken Entwicklerteams dabei jeweils den gleichen Fehler bei der Implementierung begehen, gering ist. Die nProgrammversionen werden dann gleichzeitig ausgeführt und falls sich das Verhalten der verschiedenen Versionen unterscheiden sollte, wird maschinell das Ergebnis ausgewählt, welches die Mehrheit der Programme liefert. Dadurch soll insgesamt die Verlässlichkeit der Anwendung erhöht werden. Wenn man sich nun 8 2.1 Definition und Ziele der Softwaremessung dafür interessiert, wie unterschiedlich die einzelnen Implementierungen tatsächlich ausgefallen sind, kann man eine Verschiedenheitsmetrik definieren, welche den Unterschied zwischen zwei Implementierungen bestimmt. Unabhängig davon, dass dazu zuerst festgelegt werden müsste, wie der Unterschied zwischen zwei Programmen definiert sein soll, handelt es sich bei dieser Softwaremetrik um ein echtes Abstandsmaß. Als zweites Beispiel wird in [FP98] eine Softwaremetrik genannt, welche den Unterschied zwischen der Spezifikation eines Programmes und dem implementierten Programm selbst bestimmt. Dazu muss man diese Metrik als Abstandsmaß zwischen zwei Produkten definieren und sowohl das Programm als auch die Spezifikation jeweils als Produkt betrachten. Der Abstand zwischen dem Programm und der Spezifikation nimmt z. B. zu, wenn das Programm eine spezifizierte Funktionalität nicht aufweist. Ein interessanter Aspekt an dem letztgenannten Beispiel ist, dass hier zwar wiederum eine Softwaremetrik definiert wurde, welche die Distanz zwischen einer Programmspezifikation und dem eigentlichen Programm berechnet, jedoch bei einer Definition eines Maßes auf Basis einer Metrik gegebenen Spezifikation der Wert der Softwaremetrik als Maß für die „Richtigkeit“ eines Programmes betrachtet werden kann. Bzgl. dieses Softwaremaßes ist ein Programm also umso „richtiger“, je kleiner seine Distanz zur Spezifikation ist. 2.1.2 Objekte und Ziele der Softwaremessung Softwaremaße können zunächst nach der Art der zu vermessenden Objekte unterschieden werden. Da sowohl materielle Objekte (z. B. Personen), ideelle Objekte (z. B. Programme) als auch konzeptionelle Objekte (z. B. Prozesse) vermessen werden können, werden diese verschiedenen Arten häufig unter dem Begriff Entität subsumiert (vgl. [FP98], S. 5, [Sim01], S. 21). Entsprechend der während der Softwarebearbeitung identifizierbaren, messbaren Klassifizierung von Softwaremaßen Entitäten hat sich die folgende in [FP98] dargestellte Klassifizierung allgemein etabliert (vgl. [ABCR94], [PGF96], [Zus98]): •Prozessmaße beziehen sich auf Aktivitäten innerhalb des Softwareentwicklungsprozesses. •Produktmaße beziehen sich auf jede Art von Arbeitsergebnissen (z. B. Programme, Dokumente, Testergebnisse), welche aus den Prozessaktivitäten resultieren. •Ressourcenmaße beziehen sich auf Mittel, die für die einzelnen Prozesse benötigt werden. Gründe, diese Softwaremaße innerhalb des Software Engineerings zu erheben, sind Ziele der Softwaremessung laut [PGF96] die Bedürfnisse, die Prozesse, Produkte und Ressourcen zu charakterisieren, zu beurteilen, zu prognostizieren und zu verbessern: 9 2 Softwaremessung Die genannten Entitätstypen werden charakterisiert, um ein Verständnis von Prozessen, Produkten und Ressourcen zu erlangen und eine Vergleichsgrundlage für Charakterisierung zukünftige Bewertungen zu schaffen. Während des Projektverlaufs kann mittels Softwaremessung regelmäßig beurteilt werden, ob der aktuelle Status mit den Planvorgaben übereinstimmt. Softwaremaße Beurteilung fungieren diesbezüglich als entsprechende Sensoren. Auch dienen Softwaremaße dazu, die Erreichung von Qualitätszielen und die Wirkungen von Technologieund Prozessverbesserungen in Bezug auf die Produkte und Prozesse zu beurteilen. Softwaremessung dient der Prognose, da sie eingesetzt wird, um ein Verständnis der Beziehungen zwischen den Prozessen und den dabei erzeugten Produkten zu Prognose schaffen, und um Modelle zur Beschreibung dieser Beziehungen erstellen zu können. Dadurch können bestimmte Attribute prognostiziert werden, indem die gemessenen Werte bestimmter anderer Attribute verwendet werden. Dies ist notwendig, um realistische Kostenschätzungen, Zeitpläne und Qualitätsziele aufzustellen, und um entsprechende Ressourcen einzuplanen. Prognosemaße sind auch die Basis, um Trends durch Extrapolation von Messwerten zu erkennen, wodurch wiederum die vorhanden Kosten-, Aufwandsund Qualitätsabschätzungen aufgrund der aktuellen Daten überarbeitet werden können. Hochrechnungen und Abschätzungen auf Basis historischer Daten helfen bei der Risikoanalyse und bei der Lösung von Zielkonflikten in Bezug auf Designund Kostenanforderungen. Softwaremessung dient Verbesserungszielen, da sie eingesetzt wird, um quantitative Informationen zu sammeln, mittels derer Hindernisse, grundlegende Probleme Verbesserungsziele oder Ineffizienzen erkannt und andere Möglichkeiten identifiziert werden können, um die Produktqualität oder die Performance von Prozessen zu verbessern. Softwaremessung hilft auch bei der Planung und dem Controlling von Verbesserungsbestrebungen. Die Messung der aktuellen Performance liefert die Messlatte, anhand derer beurteilt werden kann, ob Verbesserungsbemühungen die geplante Wirkung zeigen und ob dabei Nebeneffekte auftreten. Geeignete Softwaremaße helfen auch bei der Vermittlung von Zielen und Gründen für Verbesserungsbemühungen, um dadurch eine breite Unterstützung durch die Projektbeteiligten zu erreichen (vgl. [PGF96]). 2.1.3 Klassifizierung von Softwaremaßen Wie im Abschnitt 2.1.2 bereits erwähnt, können Softwaremaße zunächst aufgrund der zu messenden Objekte in Prozess-, Produktund Ressourcenmaße kategorisiert werden. Darüber hinaus können Softwaremaße auch dahingehend differenziert werden, ob die zu messenden Attribute einzelner Entitäten unmittelbar messtechnisch erfasst werden können, oder ob eine wertmäßige Bestimmung einzelner Merkmale nur im Kontext mit anderen Merkmalen oder Entitäten sinnvoll ist. In [FP98] werden für diese Unterscheidung die Begriffe interne Attributeund externe Attribute verwendet. Da jedoch die Softwaremaße selbst klassifiziert werden sollen und dabei der UnDirekte und indirekte Softwaremaße terschied herausgestellt werden soll, ob eine Messung unmittelbar möglich ist oder nicht, werden im Weiteren in Anlehnung an [Sim01] die Begriffe direkte und indirekte 10 2.1 Definition und Ziele der Softwaremessung Softwaremaße verwendet. •Direkte Softwaremaße beziehen sich auf Prozess-, Produktoder Ressourcen-Attribute, welche unmittelbar durch alleinige Untersuchung der entsprechenden Entität messbar sind. •Indirekte Softwaremaße beziehen sich auf Attribute von Prozess-, Produktoder Ressourcen-Entitäten, welche von anderen Entitäten abhängig sind. Hier muss die zu untersuchende Entität in ihrem Kontext betrachtet werden; und das Messergebnis hängt mehr vom Verhalten der Entität als von dieser selbst ab. Beispielsweise können viele Attribute des Sourcecodes unmittelbar durch einfaches Messen ermittelt werden. Hierzug gehören die Länge (z. B. in LOC gemessen) oder die Komplexität (z. B. Anzahl der Entscheidungspunkte), die somit zu den direkten Produktmaßen zählen. Anders verhält es sich z. B. mit der Anzahl der in Beispiele indirekter Softwaremaße einem Sourcecode-Objekt enthaltenen Fehlern. Abgesehen von den eher einfach zu ermittelnden Syntaxfehlern, welche üblicherweise vom Compiler entdeckt werden, muss zum Erkennen von Fehlfunktionen der Code ausgeführt werden und z. B. mittels eines Unit-Test-Mechanismus überprüft werden. Hierbei hängt die Anzahl der gefunden Fehler auch stark von der Güte, d. h. dem Abdeckungsgrad der Unit-Tests ab. Noch weniger unmittelbar zugänglich ist die Anzahl der auf Programmierfehler zurückzuführenden Fehlfunktionen, die erst beim Kunden bzw. beim Anwender entdeckt werden, und somit die Zuverlässigkeit der Software. Dieses Softwaremaß hängt von der Umgebung, in der die fertige Software eingesetzt wird, ab und davon, welche Funktionen der Software im Produktivbetrieb tatächlich aufgerufen werden. Auf Managementebene sind diese indirekten Softwaremaße oftmals von großem InManagementrelevante Informationen mittels indirekter Softwaremaße teresse. So soll beispielsweise die Kosten-Effizienz von Aktivitäten (z. B. von CodeInspektionen) oder die Produktivität von Entwicklerteams ermittelt werden, um Rückschlüsse auf Kostensenkungsmöglichkeiten zu erhalten. Auch der Kunde bzw. der Anwender ist hauptsächlich an indirekten Softwaremaßen wie der Zuverlässigkeit, der Benutzerfreundlichkeit oder der Wartbarkeit interessiert, da er von diesen Aspekten unmittelbar betroffen ist. Diese Faktoren haben unmittelbaren Einfluss auf die Total Cost of Ownership (TCO), d.h. die Gesamtheit der Kosten einer InTotal Cost of Ownership vestition, die über ihren kompletten Lebenszyklus hinweg anfallen, und sind somit für die Kaufentscheidung relevant. Allerdings sind diese indirekten Softwaremaße in der Regel schwieriger zu messen als die direkten. Zusätzlich können sie oft erst relativ spät im Rahmen des Entwicklungsprozesses erfasst werden. So kann z. B. die Zuverlässigkeit erst getestet werden, nachdem die Entwicklung abgeschlossen und das System betriebsbereit ist (vgl. [FP98], S. 74 f.). 2.1.3.1 Prozessmaße Wie im Abschnitt 2.1.2 angeführt, dienen Prozessmaße dazu, ein besseres Verständnis für die verwendeten Prozesse und deren Performance zu erhalten. Allerdings 11 2 Softwaremessung •dem Vergleich der tatsächlichen Prozessumsetzung mit den festgelegten Plänen und Zielen, •der Identifikation und Behebung prozessbezogener Probleme und •der Bereitstellung einer Datenbasis, um Softwaremessung auch in zukünftigen Prozessen implementieren zu können (vgl. [CMM06], S. 178). Der Grad der möglichen Anwendbarkeit von Softwaremaßen hängt aus Sicht des CMMI von den Einblickmöglichkeiten in den Entwicklungsprozess (Visibility Into the Einblickmöglichkeit in den Entwicklungsprozess Software Process, vgl. [PCCW93], S. 19ff.) ab. So stellt im Reifegrad 1 der Softwareentwicklungsprozess eine Art Black Box dar, in welche man Ressourcen hineinsteckt und am Ende (hoffentlich) entsprechende Projektergebnisse bekommt. Diese Einblickmöglichkeiten nehmen mit fortschreitendem Reifegrad zu. So ist beispielsweise beim Reifegrad 3 die innere Struktur der Prozesse bekannt und schließlich kann beim Reifegrad 5 nicht nur in existierende Projekte Einblick genommen werden, sondern es sollten sich auch die Auswirkungen potentieller Prozessveränderungen beurteilen lassen. Im Einzelnen ergeben sich damit die folgenden Möglichkeiten der Softwaremetrie in Abhängigkeit vom erreichten Prozessreifegrad (vgl. [FP98], S. 89 ff., [Kne06], Anwendung der Softwaremetrie im CMMI S. 44 ff.). •Da beim Reifegrad 1 der Entwicklungsprozess nur als ad hoc definiert ist, können mangels Vergleichsmöglichkeiten die hier erhobenen Softwaremaße nur als Basis dienen, um zukünftige Prozessverbesserungen beurteilen zu können. Beispielsweise können zu diesem Zweck Maße wie Projektdauer, Aufwand und Produktivität erhoben werden. •Der Reifegrad 2 zeichnet sich durch das Vorhandensein von Projektmanagement aus. Daher sind die Inputund Output-Größen der Softwareprojekte bekannt und können somit gemessen werden. Sinnvoll erscheint beispielsweise die Messung von Umfang und Volatilität der Anforderungen. Auch kann mittels entsprechender Messungen die Einhaltung von Produktgrößen-, Aufwands-, Kostenund Terminschätzungen überwacht werden. •Beim Reifegrad 3 sind definierte Prozesse vorhanden. Somit sind auch die einzelnen Aktivitäten des Entwicklungsprozesses bekannt und können vermessen werden. Beispielsweise kann jetzt die Verteilung von Aufwänden auf die einzelnen Prozessaktivitäten gemessen und mit anderen Projekten verglichen werden. Durch die definierten Prozesse ergibt sich auch eine Traceability zwischen den Endund Zwischenprodukten bzw. zu den Anforderungen. Diese kann benutzt werden, um die Entstehung, die Verweildauer und die Behebung von Fehlern zu untersuchen. •Auf Reifegrad 4 wird das Quantitative Projektmanagement unter Anwendung von Verfahren zur Softwaremessung explizit vom CMMI-Modell gefordert. Der Fokus der Softwaremessung liegt darauf, die Varianz in den wesentlichen Kennzahlen zu reduzieren, indem Prozessfehler erkannt und behoben werden. 18 2.1 Definition und Ziele der Softwaremessung •Beim optimierenden Reifegrad 5 sollen Kennzahlen und Metriken zur Verbesserung der Prozesse eingesetzt werden. Dabei ist es beispielsweise denkbar, verschiedene Varianten einer Prozessdefinition durchzurechnen, um auf diese Weise die effizienteste Prozessvariante zu finden. Ein weiterer Aspekt ist auch die Erhebung von Benchmarks, um die eigenen Prozesse mit denen der Wettbewerber zu vergleichen (vgl. [CMM06], [Jon00]). 2.1.5 Statistische Prozessregelung Wie bereits im Rahmen der Beschreibung des CMMI-Modells (Abschnitt 2.1.4.2) erwähnt, ist eine Anwendung der Softwaremetrie das Quantitative Prozessmanagement. Dieses verwendet Methoden der Statistischen Prozessregelung (Statistical Process Control (SPC), vgl. [Oak96], [FC04], [CMM06], S. 375 ff.), welche aus dem Total Quality Management stammen und auf das Management von Softwareprozessen übertragen wurden (vgl. [Sei03]). Dabei handelt es sich um ein Verfahren, mittels statistischer Methoden verschiedene Abweichungen bei der Umsetzung von Prozessen zu erkennen. Grundsätzlich Natürliche und außergewöhnliche Abweichungen bei der ProzessPerformance kann es bei der Abarbeitung von Prozessen immer zu Abweichungen vom erwarteten Sollwert in Folge der natürlichen Streuung kommen. Diese entsteht aus einer Vielzahl kleiner und erwarteter Einzeleinflüsse bei der Interaktion zwischen den Komponenten eines Prozesses und ist relativ gut vorhersehbar. Zusätzlich können außerordentliche Einflüsse den Prozessverlauf beeinflussen. Diese treten nur unregelmäßig auf, haben größere Auswirkungen und machen einen Prozess instabil. Bei ihrem Auftreten bedarf es des Eingreifens des Managements. Bei der natürlichen Streuung sind demgegenüber störende Überreaktionen zu vermeiden (vgl. [Sei03]). Eine Möglichkeit, natürliche und außerordentliche Faktoren voneinander zu unterscheiden, stellt die Verwendung sogenannter Kontrolldiagramme (Control Charts, vgl. Abbildung 2.1) dar. In diesen werden beispielsweise die Messwerte, der Mittelwert aller Messwerte und die einbis dreifache Standardabweichung eingetragen. Anschließend lässt sich mittels verschiedener Regeln überprüfen, ob aufgrund dieser Messwerte der Prozess noch unter statistischer Kontrolle ist, da die Abweichungen noch im Rahmen der natürlichen Streuung sind. Beispiel 1 (Statistische Prozessregelung) In einer Firma soll der Aufwand untersucht werden, den die Mitarbeiter jeweils für den Support eines bestimmten Produkts erbringen müssen. In Tabelle 2.2 sind die ingesamt pro Tag angefallenen Aufwände xiin Stunden für den abgelaufenen Monat mit n= 20 Werktagen angegeben. Zusätzlich wurde der absolute Betrag δjder jeweiligen Veränderung angegeben. Aus den Einzelaufwänden xiwird zunächst der Durchschnittsaufwand ¯xberechnet: ¯x=1 n n X i=1 xi≈19,2 (n= 20) 19 2 Softwaremessung Abbildung 2.1: X/MR-Control-Chart zur Statistischen Prozessregelung Tag 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Aufwand 16 20 21 8 28 24 19 16 17 24 19 22 26 19 15 21 17 22 16 14 δ4 1 13 20 4 5 3 1 7 5 3 4 7 4 6 4 5 6 2 Tabelle 2.2: Tabelle mit Aufwänden für den Support eines best. Produkts Anschließend wird aus den täglichen Veränderungen δi(moving range) die durchschnittliche Veränderung ¯ δberechnet: ¯ δ=1 n−1 n X j=2 δj≈5,5 Die Messwerte xi, die Veränderungen δjund die Durchschnittsmaße ¯xund ¯ δwerden in das Kontrolldiagramm eingezeichnet (vgl. Abbildung 2.1). Wenn man nun davon ausgeht, dass die Messwerte normalverteilt sind, dann gilt für die Standardabweichung σder Messwertverteilung, dass • ca. 68,0 % der Messwerte im Bereich ¯x±σ, • ca. 95.0 % der Messwerte im Bereich ¯x±2σund • ca. 99,7 % der Messwerte im Bereich ¯x±3σ liegen (vgl. [Sta05], S. 255 f.). Im Rahmen des SPC ist es üblich, mit einer Näherung sfür die Standardabweichung σzu arbeiten, die sich aus der durchschnittlichen Veränderung ¯ δder Messwerte ergibt: s=¯ δ d2 =5,5 1,128 = 4,88 Hierbei ist d2ein sogenannter bias correction factor nach Harter [Har60], der im obigen Fall den Wert d2= 1,128 hat. 20 2.1 Definition und Ziele der Softwaremessung Damit lassen sich nun die obere und die untere Kontrollschranke UCL (Upper Control Limit) bzw. LCL (Lower Control Limit) zu UCL = ¯x+ 3sund LCL = ¯x−3s berechnen und in das Kontrolldiagramm einzeichnen. Der Bereich zwischen LCL und UCL wird in sechs Zonen der Breite sgegliedert (vgl. Abbildung 2.1). Die Messwerte sollten dabei zufällig, d. h. ohne bestimmte Muster zu bilden, um den Durchnittswert verteilt sein und sich um den Durchschnittswert herum häufen. Anderenfalls wird der Prozess als nicht unter statistischer Kontrolle betrachtet. Um nun Messwerte und Muster von Messwerten zu erkennen, die auf einen unkontrolIdentifikation unkontrollierter Prozesse lierten Prozess hindeuten, gibt es verschiedene Empfehlungen. In [Sta05] werden beispielsweise die folgenden Kriterien vorgeschlagen: •Ein Messwert befindet sich außerhalb der beiden Kontrollschranken. Bei einem kontrollierten Prozess beträgt die Wahrscheinlichkeit hierfür nur 0,3 %. •Sieben oder mehr aufeinander folgende Messwerte befinden sich auf derselben Seite oberhalb oder unterhalb des Durchschnittswertes. Die Wahrscheinlichkeit pdafür ergibt sich z. B. für k= 7 Messwerte aus einer Bernoulli-Kette der Länge kals p=1 2k= 0,78 %. •Mindestens sieben aufeinander folgende Messwerte bilden ein alternierendes Auf-Ab-Muster. Die Wahrscheinlichkeit dafür berechnet sich in analoger Weise als Bernoulli-Kette. •Zwei aufeinander folgende Messwerte befinden sich außerhalb der Warnschranken. Diese werden meistens im Abstand des zweifachen Standardabweichung um den Durchschnittswert festgelegt. Die Anwendung der Statistischen Prozessregelung ist somit eine Möglichkeit, Unregelmäßigkeiten bei der Durchführung von Entwicklungsprozessen zu erkennen. Sie kann verwendet werden, um verschiedene Professionalitätsgrade bei der Prozessumsetzung zu beurteilen, und gibt somit Hinweise darauf, ob Maßnahmen zur Prozessverbesserung angezeigt sind. Eine Weiterentwicklung der Prozessbeurteilung mittels Statistischer Prozessregelung ist die Six-Sigma-Methode (vgl. [Töp04]). Dabei werden bestimmte Prozesse Six Sigma ausgewählt und u. a. mittels Kontrolldiagrammen analysiert. Das Ziel dabei ist, die Prozesse soweit zu kontrollieren, dass die Standardabweichung der Prozessergebnisse langfristig auf jeder Seite des Durchschnittswertes sechs Mal (6σ) in die Toleranzgrenzwerte passen (vgl. [Sta05], S. 423 ff.). 21 2 Softwaremessung 2.2 Ansätze zur Definition von Strategien zur Softwaremessung Nachdem im vorhergehenden Abschnitt die Ziele der Softwaremessung erläutert wurden, sollen im Folgenden verschiedene Ansätze zur konsistenten Implementierung von Strategien zur zielorientierten Auswahl von Sofwaremessungsmaßnahmen dargestellt werden. Hierbei kann im Wesentlichen zwischen sogenannten Top-Downund Bottom-Up-Ansätzen unterschieden werden. Bei den Ersteren wird ein vorgegebenes Ziel oder ein Problem durch schrittweise Zerlegung soweit verfeinert, bis mögliche Lösungsansätze sichtbar werden. Bei der Bottom-Up-Methode wird dagegen zunächst der zerzeitige Ist-Zustand analysiert, um evtl. vorhandene Probleme zu entdecken oder wünschenswerte Veränderungen zu definieren. 2.2.1 Top-Down-Ansätze zur Definition von Strategien zur Softwaremessung 2.2.1.1 Die Goal-Question-Metric-Methode Eine typische Umsetzung des Top-Down-Ansatzes ist die sehr verbreitete GoalQuestion-Metric-Methode (GQM) [BR88], [Bas92], [BCRS94], [SB99]. Wie in [SB99] ausgeführt wird, wurde diese Methode gegen Ende der 1970er Jahre von V. Basili und D. Weiss im Rahmen verschiedener Industrieprojekte entwickelt und später um weitere, auf D. Rombach zurückgehende, Konzepte erweitert. Die Grundidee dieser Methode besteht darin, dass Softwaremessung immer in Hinblick auf ein oder Zielgesteuerte Auswahl von Softwaremaßen mehrere konkrete Ziele durchgeführt werden sollte. Diese Ziele werden durch Verfeinerung auf quantifizierbare Fragen überführt, welche wiederum mittels geeigneter Softwaremaße beantwortet werden können (vgl. [BR88]). Bei der Betrachtung der Ziele muss zwischen Zielen der Softwaremessung und (Qualitäts-)Verbesserungszielen unterschieden werden. Die GQM-Methode spezifiert Ziele der Softwaremessung vs. strategische Ziele und unterstützt Messziele, d.h. Zielsetzungen des Softwaremessungsvorhabens (vgl. [BCRS94]). Diese Ziele können jedoch auf Verbesserungszielen basieren bzw. von diesen abgeleitet sein. Verbesserungsziele richten sich dagegen auf konkrete Zielsetzungen innerhalb eines Unternehmens oder im Rahmen eines Projektes. Dazu gehören beispielsweise die Steigerung der Produktoder Servicequalität, Kostenreduzierung, Verringerung der Time-to-Market-Zeitspanne oder Verringerung des Projektrisikos. Eine Anleitung zur Bestimmung von Managementzielen und deren Verfeinerung zu Verbesserungsund Messzielen findet sich unter anderem in [PGF96]. Die Messziele selbst führen nicht unmittelbar zu einer etwaigen Qualitätsverbesserung oder Verringerung von Entwicklungsaufwand. Stattdessen sollen dadurch Informationen zur Erreichung der Verbesserungsziele gewonnen werden. Insbesondere soll die GQM-Methode einen Lernprozess der Beteiligten über die Zusammenhänge im Rahmen der Softwareentwicklung bewirken ([BCRS94]). Konkret beschreibt die GQM-Methode drei Ebenen der Messausführung: 22 2.2 Strategien zur Softwaremessung •Goal – Konzeptuelle Ebene Diese Ebene behandelt die Frage, welche Ziele mit der Softwaremessung erreicht werden sollen. Diese Ziele werden in Bezug auf einen Zweck (welches Objekt und warum), einer Perspektive (welcher Aspekt und wer) und einem Kontext definiert. •Question – Operationale Ebene Auf dieser Ebene wird versucht, die Ziele mittels verschiedener quantifizierbarer Fragen näher zu gliedern und genauer zu bestimmen (vgl. [BR88]). Dabei müssen die Fragen so gewählt werden, dass durch deren Beantwortung der Grad der Zielerreichung beurteilt werden kann (vgl. [BCRS94]). Die Fragen dienen somit der Operationalisierung der Ziele, d. h. den Zielen werden dadurch Indikatoren zugeordnet, um sie damit der Analyse zugänglich zu machen. Jeder Frage wird auch gleich eine erwartete Antwort in Form eine Hypothese zugeordnet. Dadurch soll das Projektteam dazu angeregt werden, über die aktuelle Situation nachzudenken, wodurch wiederum ein besseres Verständnis für die Prozesse bzw. das Produkt stimuliert werden soll. („Comparison of real answers with these hypotheses will create deep understanding of implicit knowledge and therefore largely contribute to the learning effects of measurement.“, [BCRS94], S. 579) •Metric – Quantitative Ebene Nachdem die Ziele mittels Fragen operationalisiert wurden, werden auf dieser Ebene diejenigen Softwaremaße bestimmt, die zur Beantwortung der Fragen beitragen sollen. Beispiel 2 (Anwendung der GQM-Methode) In Abbildung 2.2 ist als Beispiel für die Anwendung der GQM-Methode die Ableitung von Fragen und Softwaremaßen ausgehend von einem konkreten Ziel dargestellt (vgl. [FP98], S. 85). Das Messziel besteht darin, die Wirksamkeit von Code-Standards zu überprüfen, d. h. ob Sourcecode, der unter Berücksichtigung dieser Standards erstellt wurde, in irgendeiner Art und Weise demjenigen überlegen ist, der ohne die Anwendung von Code-Standards erstellt wurde. Dabei ergibt sich zunächst die Frage, welche Programmierer sich überhaupt an den Code-Standard halten. Anschließend ist zu untersuchen, wie sich die Produktivität von Programmierern, die sich an den Standard halten, zu derjenigen der übrigen verhält. Ein ähnlicher Vergleich muss auch bzgl. der Qualität des dabei erzeugten Sourcecodes durchgeführt werden. Nachdem die Fragen definiert worden sind, müssen diese dahingehend untersucht werden, welche Entitäten gemessen werden müssen, um die Fragen zu beantworten. Beispielsweise muss, vorzugsweise durch eine maschinelle Analyse des SourcecodeRepositorys, festgestellt werden, welche Programmierer die vorgegebenen Code-Standards anwenden. Um jedoch die Wirksamkeit von Code-Standards tatsächlich beurteilen zu können, benötigt man zusätzlich Informationen darüber, welche Erfahrungen die Programmierer mit dem Standard, der Programmiersprache selbst und der 23 2 Softwaremessung Goal: Untersuche die Wirksamkeit von Code-Standards Questions: Wer verwendet den Standard? Welche Produktivität hat der Programmierer? Wie ist die Code-Qualität? Metrics: Anteil der Programmierer, welche die Code-Standards • anwenden • nicht anwenden Erfahrung der Programmierer • mit dem Standard • mit der Sprache • mit der Umgebung CodeUmfang Aufwand Fehler Abbildung 2.2: Beispielhafte Anwendung des GQM-Verfahrens Entwicklungsumgebung haben. Die Frage nach der Produktivität wiederum bedarf einer entsprechenden Definition von Entwicklerproduktivität, welche in der Regel zu dem Quotienten aus entsprechenden Maßen für den Produktumfang und den Entwicklungsaufwand führt. Das Beispiel illustriert, dass im Allgemeinen mehrere Softwaremaße erforderlich sind, Kombination verschiedener Softwaremaße um eine bestimmte Frage zu beantworten. Umgekehrt kann ein bestimmtes Softwaremaß auch als Indikator für verschiedene Fragen dienen. Viel bedeutsamer ist jedoch, dass zusätzlich zu den Fragen und den Softwaremaßen ein Verfahren oder eine definierte Vorgehensweise benötigt wird, wie die Softwaremaße sinnvoll zu kombinieren sind, um dadurch tatsächlich Antworten auf die Fragen zu liefern (vgl. [FP98]). Der GQM-Plan Diese Vorgehensweise wird in einem sogenannten GQM-Plan definiert (vgl. [SB99]). Der GQM-Plan ist ein Dokument, welches Beschreibungen aller Ziele, Fragen, Hypothesen und Softwaremaße für ein Softwaremessungsvorhaben beinhaltet. Er beschreibt die Zerlegung von Messzielen in Fragen und deren Zuordnung zu geeigneten Softwaremaßen und stellt somit die formale Dokumentation des Softwaremessungsvorhabens dar. Dieses Dokument dient als Basis für die Messanleitung, welche VorGQM-Plan als Leitfaden zur Messdurchführung schriften für das Erfassen der benötigten Softwaremaße enthält. Der GQM-Plan dient als Leitfaden für die Interpretation der zu erhebenden Daten. Die Messergebnisse sollen dabei Anworten auf die im GQM-Plan definierten Fragen geben, so dass Rückschlüsse auf die GQM-Ziele möglich sind. 24 2.2 Strategien zur Softwaremessung Abbildung 2.3: Phasen der GQM-Methode Phasen eines GQM-Projekts Die Durchführung eines GQM-Projekts erfolgt in vier Phasen, welche nachfolgend beschrieben und in Abbildung 2.3 illustriert werden (vgl. [SB99]): 1. In der Planungsphase werden die nötigen Informationen für die Vorbereitung und Durchführung eines Softwaremessungsvorhabens gesammelt. Hierzu gehört insbesondere die Auswahl des (Qualitäts-)Verbesserungszieles, d. h. des Bereiches, der aus Managementsicht Optimierungspotenziale aufweist. Zusätzlich wird in dieser Phase ein dediziertes GQM-Team aufgestellt und ein Beispielprojekt zur Anwendung der GQM-Methode ausgewählt. 2. In der Definitionsphase wird das Softwaremessungsvorhaben definiert und dokumentiert, d. h. es werden die Ziele, Fragen, Hypothesen und die zu verwendenden Softwaremaße festgelegt. Hierbei wird auch der GQM-Plan erstellt. 3. Während der Datensammlungsphase findet die eigentliche Erhebung der einzelnen Softwaremaße statt. Die erfassten Maße werden in einer Datenbank gespeichert. In [SB99] finden sich Anleitungen, wie die Datensammlung geplant werden kann, d. h. wie organisatorisch festgelegt werden kann, durch wen, wie und wann bestimmte Softwaremaße erhoben werden sollen. 4. Schließlich werden in der Interpretationsphase die Messergebnisse verwendet, um die gestellten Fragen zu beantworten. Anschließend wird mittels dieser Antworten überprüft, inwieweit die ursprünglich gestellten Ziele erreicht wurden. Die Diskussion der Ergebnisse findet gemäß [SB99] in sogenannten Feedback Sessions statt. 2.2.1.2 Kritik am Top-Down-Ansatz der GQM-Methode Die von Basili, Rombach und Kollegen entwickelte GQM-Methode wurde von der Softwareindustrie bereitwillig aufgenommen und vielfach angewandt (vgl. [HF94]), 25 2 Softwaremessung so dass die meisten publizierten Softwaremessungsvorhaben zumindest ein Lippenbekenntnis bzgl. der Anwendung der GQM-Methode ablegen (vgl. [FN99]). Dennoch gibt es an der beschriebenen Top-Down-Vorgehensweise auch einige Kritik (vgl. [Het93], [BN95]). Als grundsätzliches Problem für jeden Top-Down-Ansatz wird gesehen, dass das zu lösende Problem hinreichend genau definiert sein muss, um es durch Verfeinerung Probleme bei der Zieldefinition in kleinere, leichter lösbare Teilaufgaben zerlegen zu können (vgl. [BN95]). Es wird argumentiert, dass insbesondere im Bereich des Software-Engineerings kein hinreichend genaues Wissen über die Prozesse und die zu erstellenden Produkte vorhanden sei, um die GQM-Ziele korrekt definieren zu können. Aus diesem Grund würden Softwaremanager unter Umständen unsinnige oder nicht erreichbare Ziele definieren. Insbesondere wird als Problem angeführt, dass nicht für alle Ziele bzw. Fragen effiziente Techniken der Softwaremessung zur Verfügung stünden. Dies könne zu dem Probleme bei der Erfassung der Softwaremaße Versuch führen, Softwaremaße auf Bereiche anzuwenden, für die sie nur wenig geeignet sind, da sie zu subjektiv, schlecht definiert oder zu schwierig zu erheben sind (vgl. [BN95]). Es gebe Ziele und Fragen, die relativ einfach zu definieren aber extrem schwierig nachzuprüfen und zu messen seien. Praktiker würden in diesen Fällen bald erkennen, dass die Messergebnisse nur Teilaspekte der Ziele addressierten, und somit befürchten, dass die Messergebnisse nicht korrekt interpretiert werden würden (vgl. [Het93]). So wird auch in [Sim01] die explizite Benennung von Interpretationshilfen und die Darstellung von Abhängigkeiten zwischen Qualitätsmerkmalen und Softwaremaßen vermisst. Auch macht es der Top-Down-Ansatz schwierig, Softwaremaße oder Fragestellungen, die sich in anderen Organisationen oder Projekten bewährt haben, zu integrieStrikte hierarchische Dekomposition ren. Die Bottom-Up-Informationen stehen in Konflikt mit der strikt hierarchischen Dekomposition von Zielen zu Softwaremaßen. Damit ist es schwierig, die mittels der GQM-Methode abgeleiteten Fragen und Softwaremaße gegen andere, evtl. bewährtere auszutauschen (vgl. [BN95]). Weiter wird angeführt, dass die Konstruktion von GQM-Hierarchien zu schlechten Definitionen von zu messenden Attributen und Softwaremaßen führen könne. Hierbei könnten bei verschiedenen Projekten im Rahmen des GQM-Prozesses unUneinheitliche Bestimmung von Messgrößen terschiedliche Definitionen und Softwaremaße für die gleichen Attribute aufgestellt werden. Dadurch werden Vergleiche von Projekten – ein wichtiger Aspekt der Softwaremessung – verhindert (vgl. [BN95]). Bzgl. der GQM-Hierarchien wird von Simon angeführt, dass die fixe Anzahl von drei Verfeinerungsschichten für viele Anwendungen zu restriktiv sei, und plädiert für Fixe Anzahl von Verfeinerungsebenen die Verwendung detaillierterer Verfeinerungsketten. Hierbei habe sich in der Praxis das Vorgehen bewährt, die Ziele der GQM-Methode in hierarchisch angeordnete Subgoals zu verfeinern, die ihrerseits wiederum durch Questions und Sub-Questions hin zu Maßen verfeinert werden (vgl. [Sim01]). Allerdings wird durch eine hierarchische Anwendung der GQM-Methode das oben angeführte Problem der schlechten Projektvergleichbarkeit auf Grund unterschiedlicher Softwaremaßdefinitionen nicht kleiner. Der Umstand, dass die GQM-Methode, welche eigentlich für die Umsetzung von 26 2.2 Strategien zur Softwaremessung Messzielen entwickelt worden ist (siehe Abschnitt 2.2.1.1), in der Praxis letztendlich Managementziele als Ausgangspunkt für die Softwaremessung verwendet, verleite Taktische vs. strategische Ziele zu der Ansicht, dass Softwaremaße nicht unbedingt einer strikten, mathematischen Definition bedürfen. Deshalb seien formlose und ungenaue Definitionen an der Tagesordnung, da von Seiten des Managements die Zeit für eine genauere Spezifikation fehle. Darüber hinaus seien die vom Management gesetzten Ziele häufig von kurzfristigen Zwängen beeinflusst, während durch Softwaremessung eher langfristig orientierte Verbesserungsziele unterstützt werden können (vgl. [BN95]). Durch die Anknüpfung der Softwaremessung an Managementziele bestehe darüber hinaus die Gefahr, dass die Messergebnisse derart manipuliert werden würden, dass sie entsprechende „Fortschritte“ dokumentierten bzw. Defizite verschleierten (vgl. [Het93]). Das Hauptproblem der GQM-Methode ist jedoch sicherlich, erst einmal die „richtigen“ Ziele zu finden und zu dokumentieren. Viele Firmen müssten zunächst einmal Softwaremessungsvorhaben durchführen, um den aktuellen Zustand herauszufinden (vgl. [Het93]), da dies eine notwendige Voraussetzung dafür ist, um überhaupt sinnvolle Ziele definieren zu können (vgl. [BN95]). 2.2.2 Bottom-Up-Strategien zur Softwaremessung 2.2.2.1 Das MQG-Verfahren In der Praxis haben die geschilderten Probleme zur Entwicklung eines umgekehrten GQM-Prozesses geführt, bei dem mittels eines Bottom-Up-Vorgehens zunächst der Fokus darauf gelegt wird, die aktuellen Entwicklungsprozesse und die dabei entwickelten Produkte zu verstehen (vgl. [BN95]). Sowohl von Hetzel [Het93] als auch von Bache und Neil [BN95] wird dazu das MQG-Verfahren (Metric/Question/Goal) vorgeschlagen, welches gemäß folgender Schritte abläuft: 1. Metrics: Zunächst werden Softwaremaße erhoben und die Ergebnisse analysiert. Der Zweck der Softwaremessung liegt dabei in der Stimulierung von Fragen und der Bereitstellung von Einblicken in die Entwicklungsaktivitäten (vgl. [Het93]). 2. Questions: Anschließend wird untersucht, wie die erhaltenen Ergebnisse zu erklären sind und ob es Verbesserungsbedarf gibt. Außerdem wird geprüft, ob die Messwerte von den Erwartungen bzw. Vorstellungen abweichen. 3. Goals: Da nun mögliche Probleme oder Mängel bekannt sind, können entsprechende (Verbesserungs-)Ziele aufgestellt werden. Dem ersten Schritt geht dabei das implizit formulierte Ziel voraus, den aktuellen Zustand herauszufinden. Dieses Ziel unterscheidet sich von denen des dritten Schritts 27 2 Softwaremessung einer in NCSS angegebenen Größe hat. Dazu ist jedoch erforderlich, die Größenmessungen regelmäßig und automatisiert durchzuführen, um auf diese Weise eine Erfahrungsdatenbank aufzubauen. Wegen der Ungenauigkeiten und der Abhängigkeit von der verwendeten Programmiersprache des LOC-Softwaremaßes wurden ab Mitte der 1970er Jahre weitere Halsteads und McCabes Softwaremaße Softwaremaße entwickelt, welche die Bewertung des Umfanges und der Komplexität von Software ermöglichen sollten (vgl. [FN99]). Als Beispiele seien hier die software science measures von Halstead ([Hal77]) und die Komplexitätsmaße von McCabe ([McC76]) genannt. Nach Halstead können der Programmieraufwand und die Implementierungszeit aus den Maßen Programm-Länge und Programm-Volumen abgeleitet werden, welche aus der Anzahl und der Verwendungshäufigkeit der Operanden und Operationen der Programmiersprache berechnet werden (vgl. [Zus98], S. 59 f.). McCabe berechnete unter Anwendung von Methoden der Graphentheorie im Kontrollflussgraphen eines Programmes eine minimale Anzahl von Pfaden, welche er als Cyclomatische Komplexität der Software interpretierte (vgl. [Zus98], S. 60). Die Softwaremaße LOC, NCSS, Halstead-Länge bzw. -Volumen und teilweise auch McCabes Software-Komplexität können erst ermittelt werden, wenn der Quellcode der Software bereits vorliegt. Damit ist ihre Verwendbarkeit zur vorausschauenden Abschätzung des Programmieraufwandes eingeschränkt. Trotzdem werden sie im Original-COCOMO-Modell genau zu diesem Zweck verwendet (vgl. [Boe81]).3 In der Weiterentwicklung zu COCOMO II (vgl. [B+00]) ist es jedoch möglich, die Aufwandsschätzung auf Basis sogenannter Object-Points4durchzuführen. Im Jahr 1979 veröffentlichte Albrecht die Function-Point-Methode, welche es ermöglichte, die Anforderungen an die zu entwickelnde Software mit sogenannten Function-PointMethode Function Points zu bewerten und daraus den Projektaufwand abzuleiten ([Alb79], [AG83]). Dabei wird der Umfang der Anwendung gemäß der vom Kunden geforderten Funktionalität gemessen. Diese Funktionalität wird vom Kunden (z. B. bei den Fachabteilungen) erfragt und anhand eines logischen Systementwurfs quantifiziert. Das Ergebnis ist unabhängig von der für die Implementierung verwendeten Technologie, da die technische Realsierung der Anwendung nicht betrachtet wird (vgl. [BF00], S. 179). Die Function-Point-Methode wurde im Laufe der Zeit beständig weiterentwickelt, so dass es heute mehrere Function-Point-Zählmethoden gibt. Die bekannteste davon IFPUG ist wohl die von der International Function Point Users Group derzeit in der Version IFPUG 4.2 [IFP04] veröffentlichte. Bei der Function-Point-Analyse (FPA) werden im Prinzip für die zu entwickelnde Anwendung die Zugriffe auf logische Datenbestände und die Durchführung von Funktionstypen Transaktionen herausgearbeitet. Diesen als Funktionstypen bezeichneten Funktionen der Anwendung (vgl. Tabelle 2.3) werden Daten-Function-Points bzw. TransaktionsFunction-Points zugeordnet. 3Die Beispiele in der Beschreibung zum Original-COCOMO-Modell beziehen sich auf die Programmierung von Großrechner-Software, wo eine Abschätzung der (COBOL-)Programmzeilen eher möglich ist, als bei modernen objekt-orientierten Programmiersprachen. 4Diese sind nicht identisch mit denen der Object-Point-Methode nach H. Sneed (vgl. S. 36). 34 2.3 Softwaremaße auf Managementebene DatenFunction-Points Internal Logical Files (ILF) Interne Datenbestände, die innerhalb der Systemgrenzen der Anwendung gepflegt werden External Interface Files (EIF) Externe Schnittstellen-Datenbestände, die außerhalb der Systemgrenzen (von anderen Anwendungen) gepflegt werden TransaktionsFunction-Points External Inputs (EI) Externe Eingabedaten mit ihren logischen Datengruppen und Datenelementen External Output (EO) Externe Ausgabedaten mit ihren logischen Datengruppen und Datenelementen External Inquiries (EQ) Externe Abfragen mit ihren logischen Datengruppen und Datenelementen Tabelle 2.3: Bei der FPA bewertete Funktionstypen (vgl. [BF00], S. 190 f.) FTRs/DETs 1–4 DETs 5–15 DETs > > >15 DETs 0–1 FTR gering gering mittel 2 FTR gering mittel hoch > > >2 FTR mittel hoch hoch Tabelle 2.4: Komplexitätsgrade für externe Eingaben nach IFPUG 4.2 ([IFP04]) Die Komplexität der Funktionstypen wird dabei anhand einer Komplexitätsmatrix in „gering“, „mittel“ oder „hoch“ eingestuft und entsprechend mit einer unterschiedlichen Anzahl Funktion-Points bewertet. Beispiel 3 (Function-Points) Ein Kundenverwaltungssystem soll eine Eingabemaske zum Hinzufügen weiterer Datensätze erhalten. Diese Transaktion stellt aus der Sicht der FPA einen EI-Funktionstyp dar, da es sich um externe Eingabedaten handelt. Nun werden die Datenelemente (Name, Vorname, Telefonnummer, usw.) gezählt und diese Anzahl mit DET (data element type) bezeichnet. In diesem Fall gelte beispielsweise DET = 8. Anschließend wird die Anzahl F T R der referenzierten logischen Datenbestände (file type records) ermittelt. Diese gehen in diesem Fall mit F T R = 1 in die Berechnung ein, da logisch nur auf den Datenbestand „Kundendaten“, in denen der neue Datensatz abgelegt wird, zugegriffen wird. Dass die Kundenstammdaten und die Kundenadressdaten evtl. in unterschiedlichen Tabellen abgelegt sind, wird an dieser Stelle nicht berücksichtigt. Mit DET = 8 und F T R = 1 wird gemäß Tabelle 2.4 die Komplexität dieser EI-Transaktion als „gering“ eingestuft und in diesem Fall mit 3 Function-Points bewertet. Die so ermittelten Function-Points werden als ungewichtete Function-Points beUngewichtete und gewichtete Function-Points zeichnet. Anhand von 14 Einflussfaktoren (z. B. Datenkommunikation,Transakti35 2 Softwaremessung onsrate,Benutzerfreundlichkeit, etc.) wird ein sogenannter Value Adjustment Factor (VAF) berechnet, der dann schließlich zu den gewichteten Function-Points führt. Der Value Adjustment Factor Schritt von den ungewichteten Function-Points zu den gewichteten entspricht der Unterscheidung zwischen dem Umfang der zu entwickelnden Anwendung und dem damit verbundenen Aufwand, da bei diesem auch noch weitere Einflüsse auf die Systementwicklung (z. B. Erfahrung der Mitarbeiter, Klarheit der Anforderungen, Prozessreife, etc.) berücksichtigt werden müssen (vgl. [BF00], S. 192, [BF00], S. 22 f.). Allerdings wird auch angeführt, dass diese VAF stark abhängig von der Beurteilung von Experten seien und deshalb wenig für konkrete und eindeutige Aussagen zu den Kosten einer Software geeignet wären. Daher könne man alternativ auch mittels der FPA nur den Umfang der Software in Form von ungewichteten Function-Points bestimmen und mittels parametrisierbarer Modelle, die für verschiedene Industrien entsprechend angepasst sind, ähnlich wie beim COCOMO-II-Verfahren ([B+00]) auf den Aufwand und die Kosten schließen (vgl. [Feh05], S. 170). Die Function-Point-Methode wird zwar nur von einem Teil der industriellen Praktiker verwendet (vgl. [Feh05], S. 166 f.), jedoch ist die Aussagekraft ihrer Ergebnisse grundsätzlich anerkannt (vgl. [HF94]). Leider erfolgt das Zählen der Function-Points grundsätzlich manuell und darf nach Meinung vieler Function-Point-Anwender auch Manuelle Zählung der Function-Points nicht automatisiert werden, da die Zählung auf den Benutzeranforderungen an die Software basiert und jeder Zählschritt dokumentiert und begründet werden muss (vgl. [BF00], S. 132). In der Literatur wird berichtet, dass diese Einschränkung für die COSMIC Full Function Points (CFFP, [ADO+03]) nicht mehr gelte (vgl. [Feh05], S. 171). Bei dieCOSMIC Full Function Points ser Variante der Function-Point-Methode, welche in Konkurrenz zur IFPUG-Version steht, werden Datenbewegungen gezählt, was auch durch die Analyse von UMLDiagrammen möglich sein soll. Auch seien CFFP besser für die Analyse aktueller Multi-Tier-Systeme und Komponenten-basierender Anwendungen geeignet. In diesen seien die für die FPA verwendeten Zählgrößen nur schwer zu finden, da diese noch aus der Mainframe-Programmierung stammten (vgl. [Dek04]). Ebenfalls den Bedürfnissen der objekt-orientierten Programmierung Rechnung tragend wurde von Sneed die Object-Point-Methode [Sne96] veröffentlicht. Dabei Object-PointMethode wird das objekt-orientierte Design der zu implementierenden Anwendung mit sogenannten Class-,Messageund Process-Points bewertet, welche mit dem KlassenEntwicklungsaufwand, dem Integrationsaufwand bzw. mit dem Systemtestaufwand korresponieren. Das gesamte Aufwandsmaß Object-Points ergibt sich als Summe der drei Bestandteile, wobei anschließend noch eine Justierung auf der Basis von Qualitätsanforderungen und Projekt-Einflussfaktoren durchgeführt wird. Grundsätzlich lässt sich die Zählung der Object-Points somit auch automatisieren. Jedoch gibt es kaum industrielle Erfahrungen mit der Anwendbarkeit dieser Methode (vgl. [BF00], S. 211). Auch muss für die Anwendung dieser Methode bereits ein objekt-orientiertes Design-Modell der Anwendung vorliegen, so dass sie in der Angebotsphase eines Softwareprojektes üblicherweise noch nicht eingesetzt werden kann. Für den letztgenannten Fall der frühzeitigen Aufwandsschätzung innerhalb industrieller Softwareentwicklungsprojekte erscheint die Aufwandsschätzung mittels 36 2.3 Softwaremaße auf Managementebene Use-Case-Points (UCP, vgl. [SW01]) als vielversprechende Alternative. Dabei werUse-Case-Points den die in den Use-Cases auftretenden Akteure und Transaktionen, d.h. Ereignisse zwischen dem Akteur und dem System, bewertet. Es wird berichtet, dass die Methode eine recht genaue Aufwandsschätzung erlaubt, wenn sie in Bezug auf die jeweilige Organisation entsprechend kalibriert wurde (vgl. [ADSJ01], [Car05]). Die Firma sd&m berichtet in diesem Zusammenhang von einer eigenen Erweiterung der UCP-Methode, durch die sich die Schätzgenauigkeit für bestimmte Projektarten signifikant verbessern ließ (vgl. [FJE06]). Schließlich wird in Abschnitt 4.2.4 (S. 98 ff.) mit der Darstellung des FeatureDriven Developments eine weitere Möglichkeit gezeigt, den Projektumfang zu speziFeatures fizieren. Dabei wird die Anwendung in einzelne Features (vgl. [PF02]) zerlegt, welche dann gewichtet und gezählt werden können. 2.3.2 Bestimmung von Aufwand und Kosten Betriebswirtschaftlich wird unter dem Aufwand der bewertete Verbrauch aller Güter Aufwand und Kosten und Dienstleistungen in einer bestimmten Periode verstanden (vgl. [RRK06]). Dabei wird zwischen Aufwendungen, die unmittelbar mit der Leistungserstellung im Rahmen des Betriebszwecks zusammenhängen, den sog. Betriebsaufwendungen, und den neutralen Aufwendungen (z. B. außerordentliche Aufwendungen) unterschieden. Zu den Betriebsaufwendungen zählen dagegen beispielsweise Gehälter, Energie, Lizenzkosten und Abschreibungen. Die Betriebsaufwendungen sind im Wesentlichen deckungsgleich mit den Kosten in der Kostenund Leistungsrechnung.5 Unter dem Aufwand für ein Softwareentwicklungsprojekt wird dagegen meistens nur der Zeitaufwand in Personentagen (oder Personenmonaten) verstanden, der zur Projektaufwand Durchführung des Projektes erforderlich ist. Der Projektaufwand ist somit zunächst einmal die tatsächliche Zeit, die alle Mitarbeiter eines Projektes für dieses aufwenden. Dieser Aufwand enthält keinen Urlaub und keinen Krankenstand, sehr wohl aber Schulungen und Reisebzw. Fahrzeiten (vgl. [BF00]). Für die Berechnung der projektbezogenen Kosten des eigenen Personals wird der erbrachte Projektaufwand mit entsprechenden Stundenverrechnungssätzen multipliziert, welche im Rahmen des betrieblichen Rechnungswesens ermittelt werden Stundenverrechnungssätze (vgl. [Bur02], S. 345 ff.). Dabei wird üblicherweise zwischen internen und externen Stundenverrechnungssätzen unterschieden. Die internen Stundenverrechnungssätze sind ein Maß dafür, welcher betriebswirtschaftliche Aufwand mit dem Einsatz eines Mitarbeiters in einem Projekt verbunden ist. Mittels der externen Stundensätze wird entweder die Tätigkeit der Mitarbeiter dem Kunden in Rechnung gestellt, oder die externen Stundensätze fließen in die Berechnung eines Festpreises bei der industriellen Auftragsvergabe ein. 5Bei den Abschreibungen kann es beispielsweise zu Differenzen zwischen den bilanziellen Abschreibungen in der Betriebsbuchhaltung und den kalkulatorischen Abschreibungen in der Kostenrechnung kommen. 37 2 Softwaremessung Aufwandserfassung Voraussetzung für jede Aufwandsund Kostenkontrolle ist das „entwicklungsadäquate“ Erfassen des Personalaufwands, d.h. eine regelmäßige und vollständige Stundenaufschreibung entsprechend der Projektstruktur und – wenn möglich – auch entEntwicklungsadäquate Stundenkontierung sprechend der Prozessstruktur. Um ein wirkungsvolles Projektcontrolling zu ermöglichen, sollte eine Detaillierung des Personalaufwandes nach •Arbeitspakten, •Meilensteinen, •Entwicklungsphasen und •Tätigkeitsarten erfolgen (vgl. [Bur02], S. 341). Wegen des großen Datenumfangs, der somit bei der Stundenkontierung anfällt, ist eine praktikable Aufwandserfassung i. Allg. nur mit Hilfe eines EDV-gestützten Verfahrens möglich. Als Beispiel sei hier das SAP-Arbeitszeitblatt SAP CATS (crossSAPArbeitszeitblatt application time sheet, [SAP03]) angeführt. Dabei handelt es sich um eine Anwendung zur manuellen Erfassung von Arbeitsleistungen auf Basis eines SAP ERPSystems. Dabei können die benötigten Kontierungsobjekte und die anderen Arbeitszeitattribute vom Administrator entsprechend der Organisationsbedürfnisse konfiguriert werden. Die einzelnen Projektmitarbeiter bekommen dann bei der Tätigkeitserfassung nur diese Kontierungsobjekte (Projekte, Arbeitspakete) zur Kontierung angeboten, welche für sie relevant sind. Die Qualität der Stundenaufschreibung wird nach [Bur02] von drei Kriterien bestimmt: Qualität der Zeiterfassung •Genauigkeit •Vollständigkeit •Ehrlichkeit Die Genauigkeit und die Vollständigkeit könne dabei positiv durch Einbinden der Kontenstruktur in einen Netzplan beeinflusst werden, da dadurch eine Plausibilisierung der kontierten Arbeitspakete mit den Netzplandaten möglich ist. Außerdem würden dadurch Kontierungen auf falsche Arbeitspakete und damit auf falsche Konten erheblich verrringert werden. Die Ehrlichkeit würde dagegen ganz entscheidend vom Verhalten der Leitung beeinflusst werden. Denn grundsätzlich sei es auch möglich, dass die kontierten Stunden nicht nur zur Projektbeurteilung, sondern auch zur Mitarbeiterbeurteilung verwendet werden. Daher bestünde zwangsläufig die Gefahr der Manipulation, falls bei Planabweichungen Sanktionen drohten (vgl. [Bur02], S. 345). Eine Möglichkeit, dieses Problem zu mindern, besteht darin, die kontierten Stunden nur auf Team-Ebene auszuwerten. Häufig sei nach [Bur02] auch ein bewusstes „zu viel Kontieren“ auf einzelne, noch nicht ausgeschöpfte Projektkonten zu beobachten. Dieses Kontieren nach dem „Tragfähigkeitsprinzip“ beeinträchtigt natürlich ebenfalls jede zielorientierte Projektkontrolle (vgl. [Bur02], S. 345). 38 2.3 Softwaremaße auf Managementebene 2.3.3 Die Produktivität Ökonomen verstehen unter der Produktivität üblicherweise das Verhältnis zwischen der produzierten Ausbringungsmenge und den dafür beim Produktionsprozess eingesetzten Mitteln. Bezogen auf die Softwareentwicklung ergibt sich somit die Produktivität als Verhältnis zwischen dem erzeugten Produktumfang und den dafür erbrachten Aufwand: Produktivität =Produktumfang Aufwand Um die Produktivität tatsächlich bestimmen zu können, müssen in dieser Gleichung noch die Variablen durch entsprechende Softwaremaße ersetzt werden. Oft wird beispielsweise eine der folgenden Definitionen verwendet (vgl. [FP98], S. 408ff., [Kan03], S. 343 ff., [GC87], S. 19 ff.) Produktivität =LOC Personenmonate oder Produktivität =NCSS Personenmonate LOCProduktivität Als Nachteil dieses Softwaremaßes wird gewöhnlich angeführt, dass sowohl für den Zähler als auch für den Nenner die Bestimmung der genannten Softwaremaße problematisch sei (vgl. [FP98], ebd.). Die Messung des Aufwandes in Personenmonaten mache insbesondere die organisationsübergreifende Vergleichbarkeit problematisch, da ein Personenmonat je nach Unternehmen eine unterschiedliche Anzahl von Stunden bedeuten könne. Innerhalb einer Organisation sollte jedoch die Messung des Aufwandes, wie in Abschnitt 2.3.2 beschrieben, in konsistenter Weise möglich sein. Problematischer ist dagegen, wie im Abschnitt 2.3.1 dargestellt, die Messung des Softwareumfangs, da weder LOC noch NCSS wirklich ein Maß für den Umfang der mit dem Softwareprodukt ausgelieferten Funktionalität darstellen (vgl. [FP98], [Kan03]). Zudem gibt es auch hier wieder Probleme mit der Vergleichbarkeit über verschiedene Projekte und Organisationen hinweg. So formuliert Jones, dass „using lines of code for productivity studies involving multiple languages and full life cycle activities should be viewed as professional malpractice“ (siehe [Jon00], S. 72). Auch kann es vorkommen, dass die nachträgliche Vereinfachung von SourcecodeAbschnitten dahingehend, dass der resultierende Code zwar die gleiche Funktionalität aufweist, aber kompakter, effizienter und evtl. sogar verständlicher ist, zu einem Rückgang der Produktivität führt. In [FP98] wird daher zumindest empfohlen, den Softwareumfang in FunctionPoints zu messen, was dann zu der folgenden Formel für die Produktivität führt: Produktivität =implementierte Function-Points Personenmonate Function-PointProduktivität Allerdings würden sich nach [FP98] viele Manager weigern, Function-Points zu verwenden, da ihnen dieses Maß nicht „griffig“ genug sei. Diese könnten sich zwar unter der Anzahl der Programmzeilen etwas vorstellen, hätten aber nur eine vage Vorstellung von der Bedeutung von Function-Points. 39 2 Softwaremessung In älteren Publikationen wird als Nachteil der Function-Point-Produktivität angeführt, dass das Function-Point-Verfahren fehlerhafte Ergebnisse liefere, wenn daKritik an FunctionPoint-Produktivität mit Software mit einer hohen algorithmischen Komplexität bewertet werden soll (vgl. [MWD96]). Dies liege daran, dass diese Methode für kommerzielle Software entwickelt wurde, bei der der Schwerpunkt in der Manipulation großer Datenbestände, in der Dateneingabe und der Datenausgabe liege (vgl. [BF00], S. 182). So wird auch von Balzert in [Bal98] die LOC-Produktivität als die am besten bewährte dargestellt, wobei sich diese Empfehlung auf den genannten Artikel von Maxwell et al. [MWD96] bezieht. Die genannten Schwächen der Function-Point-Methode waren auch Auslöser für die Entwicklung der verschiedenen Function-Point-Varianten, wie beispielsweise den COSMIC Full Function Points. In neueren Publikationen wird auch von Maxwell die Function-Point-Produktivität angewendet, wobei eine Zählweise verwendet wird, die in etwa den ungewichteten IFPUG 4.0 Function-Points entspricht (vgl. [MF00]). Allerdings wird auch die LOC-Produktivität nicht explizit als ungeeignet dargestellt. Ein interessantes Ergebnis dieser Studie ist, dass die Produktivtät je nach betrachteter Branche von unterschiedlichen Faktoren positiv oder negativ beeinflusst wird. So konnten im Bankenbereich Skaleneffekte bei der Produktivität mit zunehmendem Einflussfaktoren der Produktivität Softwareumfang festgestellt werden. Dies widerspricht der sonst gängigen Meinung, dass mit steigendem Programmumfang die Produktivität sinke (vgl. [Bal98], S. 13). Demgegenüber nahm im Bereich der öffentlichen Verwaltungen die Produktivität mit zunehmender Anzahl an Abfrage-Funktionen zu. Gleichzeitig nahm sie ab, je mehr die Anwender an der Entwicklung mitwirkten. Unabhängig von den genauen Auswirkungen der verschiedenen Einflussgrößen auf die Produktivität zeigt dieses Beispiel, dass Produktivitätsmessungen sich nur mit großer Vorsicht vergleichen lassen. Einen gänzlich anderen Aspekt der Produktivitätsbewertung betrachten dagegen Kan [Kan03], Putnam und Myers [PM03]. Sie gehen nicht von einer zweidimensionalen Produktivitätsdefinition wie bei den obigen Gleichungen aus, sondern führen aus, dass für Softwareprojekte ein dreidimensionales Produktivitätskonzept angemessen Dreidimensionales Produktivitätskonzept sei, welches neben Umfang und Aufwand auch die kalendermäßige Entwicklungszeit mit einschließt. Dies sei deshalb gerechtfertigt, da bei einer Verknappung der zur Verfügung stehenden Zeit sich der Aufwand überlinear vergrößere (vgl. [Kan03], S. 346). Genauer wird dieser Zusammenhang in [PM03] beschrieben. Im Gegensatz zu obigen Produktivitätskonzepten, welche sowohl auf einen einzelnen Mitarbeiter als auch auf ein ganzes Projekt angewendet werden können, definieren Putnam und Myers die Prozessproduktivität wie folgt, wobei sie die Exponenten durch Analyse Prozessproduktivität einer sehr großen Menge empirischer Daten ermittelt hätten (vgl. [PM03], S. 92): Prozessproduktivität =Produktumfang (mit best. Qualität) Aufwand β1 3·Zeit4 3 (∗) Dabei ist der Faktor βein vom Produktumfang abhängiger Parameter, welcher 40 2.3 Softwaremaße auf Managementebene dem Aufwand bei kleineren Projekten ein größeres Gewicht gibt. In [PM02] werden der Prozessproduktivität folgende Eigenschaften zugeschrieben: •Bei der Prozessproduktivität handelt es sich um die Produktivität einer Projektorganisation, welche gemäß eines bestimmten Vorgehensmodells arbeitet, entsprechende Werkzeuge verwendet und dabei durch geeignete Managementpraktiken geführt wird. Die Prozessproduktivität berücksichtigt daher explizit alle Aktivitäten der Softwareentwicklung inklusive Design und Test und beschränkt sich daher nicht auf reine Implementierungsaktivitäten. •Sie unterscheidet sich von der konventionellen Produktivität hauptsächlich dadurch, dass auch die kalendermäßige Entwicklungszeit einen Faktor bei der Produktivitätsermittlung darstellt. •Sie definiert eine nicht-lineare Beziehung zwischen den Maßen Produktumfang, Aufwand und Zeit. Aufgelöst nach dem Produktumfang ergibt sich die folgende Darstellung: Produktumfang =Aufwand β1 3·Zeit4 3·Prozessproduktivität Aus dieser Darstellung wird ersichtlich, dass die benötigte Zeit sublinear, der Aufwand hingegen supralinear mit dem Produktumfang zunimmt. In [PM03] wird jedoch darauf hingewiesen, dass obige Gleichungen kein Naturgesetz darstellten und die beiden Exponenten Näherungen seien, mit denen in der Praxis sehr gute Erfahrungen gemacht worden wären. Obige Gleichung (∗) lässt sich auf beiden Seiten mit 3potenzieren. Anschließend erhält man durch entsprechendes Umformen die folgende Gestalt: Prozessproduktivität3·Zeit4 Produktumfang2·β=Produktumfang Aufwand =konventionelle Produktivität Damit variiert in diesem Modell die konventionelle Produktivität mit der dritten Prozessproduktivität vs. konventionelle Produktivität Potenz der Prozessproduktivität und mit der vierten Potenz der Entwicklungszeit. Daher würde eine Verschlechterung der Prozessproduktivität oder eine zu knapp bemessene Entwicklungszeit zu einer überproportionalen Verringerung der konventionellen Produktivität führen. Eine weitere Umformung von Gleichung (∗) führt zu folgender Darstellung: Aufwand β1 3·Zeit4 3=Produktumfang Prozessproduktivität Wenn man die Prozessproduktivität einer Organisation als konstant betrachtet, so ist die gesamte rechte Seite obiger Gleichung für eine bestimmte Produktgröße Aufwand abhängig von der Entwicklungszeit konstant. Daher sind laut [PM03] der Aufwand und die Entwicklungszeit direkt voneinander abhängig, da der Faktor βfür einen gegebenen Produktumfang eine 41 2 Softwaremessung feste Größe hat.6Insbesondere würde bei einer Verringerung der kalendermäßigen Entwicklungszeit der Aufwand überproportional steigen. 2.3.4 Die Entwicklungszeit Mit der Entwicklungszeit ist die kalendermäßig verstrichene Zeit gemeint. Diese Zeit ist zum einen für den Kunden bedeutsam, da durch die Entwicklungszeit bestimmt wird, wie lange er auf das bestellte Produkt warten muss. Meistens wird die Entwicklungszeit mittels sogenannter Meilensteine gegliedert. Meilensteine kennzeichMeilensteine nen den Beginn und das Ende eines Projekts, den Abschluss einer Projektphase und manchmal auch den Abschluss einer Gruppe von Vorgängen innerhalb einer Phase (vgl. [Bal98], S. 31). Oft werden durch Meilensteine Zeitpunkte definiert, an denen aufgrund des Erreichten eine Entscheidung über den Projektfortgang getroffen werden muss (vgl. [Hen02], S. 64). 2.3.4.1 Termintreue Für einen übersichtlichen Vergleich der tatsächlichen Entwicklungszeiten mit den ursprünglich geplanten und evtl. mit dem Kunden vereinbarten Entwicklungszeiten kann sowohl für das Gesamtprojekt als auch für Teilprojekte, Projektphasen oder Meilensteine die Termintreue bestimmt werden. Dafür muss zunächst für die einzelnen Teilprojekte der Terminverzug T∆berechnet werden. T∆=TV′Ist −TPlan Terminverzug Dabei bezeichnet TV′Ist die voraussichtliche Ist-Dauer und TPlan die geplante Dauer des Vorgangs. Damit kann für jedes Teilprojekt die Termintreue T TTP berechnet werden. T TTP =TPlan −T∆ TPlan ×100 Termintreue Für die Termintreue des Gesamtprojekts mit nTP Teilprojekten gilt dann: T Tges =PT TTP nTP (vgl. [Bur02], S. 336) Falls die (voraussichtliche) Ist-Dauer größer als die geplante Dauer ist, so ergibt sich eine Termintreue von unter 100 %, ansonsten ein Wert von über 100 %. Ziel der Projektführung muss daher sein, insbesondere für die Termintreue des Gesamtprojektes den Wert 100 % zu erreichen und wenn möglich zu überschreiten (vgl. [Bur02], S. 337). Neben der Termintreue, welche statisch das Verhältnis zwischen der (voraussichtlichen) Ist-Dauer und der geplanten Dauer von Vorgängen angibt, kann auch der 6Dies wird von Boehm in [Boe81] in ähnlicher Weise dargestellt. So wird beim COCOMO-Verfahren aus dem Produktumfang der Entwicklungsaufwand und daraus die (optimale) Projektdauer berechnet. 42 2.3 Softwaremaße auf Managementebene Abbildung 2.5: Aufbau des FCM-Qualitätsmodells (in Anlehnung an [Bal98]) dynamische Verlauf von Terminschätzungen untersucht werden. Geeignete Methoden hierfür sind die Meilenstein-Trendanalyse und die Meilenstein-Signalliste (siehe dazu [Bur02], S. 337 ff.). 2.3.5 Messung der Qualität Softwarequalität wird in der ISO-Norm 9126 beschrieben als die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen (vgl. [Int01]). Für die praktische Anwendbarkeit des Qualitätsbegriffs – und um die Qualität eines Produktes überprüfen zu können – wurden Qualitätsmodelle entwickelt, mit denen Qualitätsmodelle der allgemeine Qualitätsbegriff durch Ableiten von Unterbegriffen operationalisiert werden kann (vgl. [Bal98], S. 257, bzw. auch Abschnitt 2.2.3, S. 29ff.). Bei diesen Qualitätsmodellen wird die Qualität mittels eines hierarchischen Systems von Qualitätsmerkmalen (engl. quality factors), Qualitätsteilmerkmalen (engl. quality criteria) und Qualitätsindikatoren (engl. quality metrics) beschrieben. Daher wird ein so aufgebautes Modell auch als FCM-Qualitätsmodell (Final Classification Matrix) bezeichnet (vgl. Abbildung 2.5). Dabei spiegeln die Qualitätsmerkmale hauptsächlich benutzerorientierte Charakteristika wider, während die Kriterien eher der softwareorientierten Sichtweise entsprechen. Die Indikatoren sind ausgewiesene Eigenschaften eines Softwareprodukts, die zu den Qualitätsmerkmalen in Beziehung gesetzt werden können. Quantifizierbare Indikatoren können mit Hilfe von Softwaremaßen bestimmt werden (vgl. [Bal98], S. 258). 43 2 Softwaremessung dass die Fehlerdichte bei der ausgelieferten Software mit steigendem Reifegrad deutlich sinkt. Insbesondere sinkt sie mit zunehmendem Reifegrad mehr als die potentielle Fehlerdichte. Die Qualitätsergebnisse der Projekte überlappen sich auch über die Reifegrade der Unternehmen hinweg. So sind die besten Ergebnisse von Projekten auf CMM-Reifegrad 1 besser als die durchschnittlichen Ergebnisse auf Reifegrad 4. Auch bei diesem Maß besteht der Hauptnutzen darin, die Qualität der eigenen Prozessergebnisse einzuschätzen und die Wirksamkeit von Prozessverbesserungsmaßnahmen beurteilen zu können. 2.4 Zusammenfassung In diesem Kapitel wurden einige grundlegende Begriffe, Konzepte und Verfahren der Softwaremessung eingeführt. Insbesondere wurde dargestellt, warum innerhalb dieser Arbeit der Begriff des Softwaremaßes im Gegensatz zu dem sehr häufig in der Softwaretechnik-Literatur anzutreffenden Begriff der Software-Metrik verwendet wird. Softwaremaße wurden als grundlegende Informationsquelle darstellt, mit deren Hilfe Prozesse, Produkte und Ressourcen im Rahmen des Softwareentwicklungsprozesses charakterisiert und beurteilt werden können. Weiter dienen die mittels der Softwaremetrie gewonnenen Daten sowohl der Prognose künftiger Softwareprojekte als auch der Planung und Kontrolle von Verbesserungsmaßnahmen. Insbesondere das Ziel der Verbesserung von Softwareprozessen und den dabei hergestellten Produkten wurde in Verfahren wie dem CMMI oder der Statistischen Prozessregelung institutionalisiert. Bei diesen Verfahren nimmt die Softwaremetrie eine tragende Rolle ein. Grundsätzlich erscheinen Softwaremessungsvorhaben, welche ohne klare und präzise Anwendungsund Zielvorstellungen angegangen werden, mit hoher Wahrscheinlichkeit zum Scheitern verurteilt (vgl. [HF97]). Daher wurden mehrere Verfahren entwickelt, um eine zielgerichtete Auswahl geeigneter Softwaremaße zu treffen. Mit der Goal-Question-Metrik-Methode haben Basili und seine Kollegen ein Verfahren vorgeschlagen, mit dem die Zielorientiertheit der Softwaremessung sichergestellt werden kann. Dabei werden die Management-Ziele durch schrittweise Verfeinerung soweit zerlegt, dass Softwaremaße angegeben werden können, deren Erhebung Informationen über den Grad der Zielerreichung liefern kann. Aber auch bei der MQG-Methode werden nicht einfach Softwaremaße ohne eine Zielvorstellung erhoben, auch wenn dies zunächst so erscheinen könnte. Die MQGMethode geht von dem impliziten Ziel aus, zunächst den aktuellen Zustand der Softwareentwicklungsprozesse zu ermitteln, um von dieser Basis ausgehend sinnvolle Ziele definieren zu können. Beim bidirektionalen Ansatz schließlich werden die beiden Stoßrichtungen der Softwaremessung kombiniert. Einserseits werden Management-Ziele durch Verfeinerung in Eigenschaften zerlegt und andererseits werden Merkmale des Softwareentwicklungsprozesses mittels Softwaremaße messbar gemacht. Beide Stoßrichtungen 50 2.4 Zusammenfassung werden dann mittels der Qualitätsindikatoren zusammengeführt, wodurch sich eine Traceability zwischen den IT-Strategien und den erhobenen Softwaremaßen ergibt. Daneben hat sich in der industriellen Praxis der Softwaremessung gezeigt, dass die Größen Umfang, Aufwand, Zeitdauer, Qualität und Produktivität zu den Standardkennzahlen gehören, die regelmäßig bei Softwaremessungsvorhaben erfasst werden. Insbesondere haben diese Maße im Rahmen der Vertragsgestaltung und des Projektmanagements eine zentrale Bedeutung. Die Hauptintention der Softwaremetrie besteht letztendlich darin, Softwaremaße zu erheben, um damit die Erreichung bestimmter Ziele zu beurteilen. Dabei ist es wünschenswert, dass diese Softwaremaße möglichst automatisiert erhoben werden können. Zusätzlich ist es insbesondere beim MQG-Verfahren und bei der bidirektionalen Vorgehensweise hilfreich, ein entsprechendes Arsenal mit Softwaremaßen vorrätig zu haben, welche einfach konfiguriert und automatisiert erhoben werden können. Innerhalb der vorliegenden Arbeit wurde daher ein entsprechendes Framework zur Softwaremessung entwickelt, welches dem Anwender erlaubt, sich sogenannte Messwertgeber für Softwaremaße zu definieren, welche dann für die automatisierte Erhebung der gewünschten Softwaremaße konfiguriert werden können. 51 2 Softwaremessung 52 3 Messwerkzeuge Man must shape his tools lest they shape him. (Arthur R. Miller) Dieses Kapitel gibt einen Überblick über verschiedene Ansätze zur werkzeugunterstützten Softwaremessung. Nach der Definition einiger grundlegender Begriffe wird ein Charakterisierungsschema dargestellt, anhand dessen verschiedene Messwerkzeuge hinsichtlich ihrer Konfigurierbarkeit beurteilt werden können. Der Schwerpunkt dieses Kapitels bildet eine Übersicht über den Stand der Technik. Dabei werden verschiedene Messwerkzeuge beispielhaft vorgestellt, um deren Funktionsumfang, aber auch evtl. Einschränkungen aufzuzeigen. Die Reihenfolge orientiert sich dabei am Grad der Konfigurierbarkeit der Werkzeuge und insbesondere an den jeweiligen Möglichkeiten, die zu messenden Softwaremaße bereits vorab festzulegen, so dass die Softwaremessung zur Projektlaufzeit weitestgehend automatisiert erfolgen kann. Nicht näher betrachtet werden dabei Ansätze zur Softwaremessung, welche zwingend in Prozessmanagementbzw. Workflow-Systeme eingebunden sind. Derartige Prozessmanagementund Workflow-Systeme Ansätze werden beispielsweise in [Lot96] oder [DEA98] beschrieben. Dabei geben die Workflow-Systeme den Anwendern die Aktivitäten vor, welche diese als nächstes auszuführen haben, und stoßen die Erhebung der mit der Ausführung der Tätigkeiten verbundenen Softwaremaße an. Allerdings müssen bei den beiden erwähnten Ansätzen die meisten Daten manuell erfasst werden. Durch diese Vorgehensweise ist sichergestellt, dass die Softwaremetrie-Anwendung erkennen kann, welche Projektphasen gerade durchlaufen und welche Aktivitäten dabei durchgeführt werden. Dadurch können die erhobenen Softwaremaße entsprechend zugeordnet werden. Jedoch scheint dieser Ansatz die Softwareentwickler bei ihrer Entscheidungsfreiheit sehr stark einzuengen, so dass die Entwicklerteams nur noch eingeschränkt auf Änderungen des geplanten Projektverlaufs reagieren können. Insbesondere widerspricht ein derartiger Ansatz der in dieser Arbeit angestrebten „Leichtgewichtigkeit“ (vgl. S. 4) des Softwaremessverfahrens. 3.1 Begriffe In der Literatur finden sich, neben der Bezeichnung Messwerkzeuge häufig die Anglizismen Softwaremesstools und CAME-Tools. Dabei wird nach Dumke ein SoftwaCAME-Tools remesstool als Softwarewerkzeug definiert, „welches Komponenten eines SoftwareProduktes oder der Softwareentwicklung in ihrer Quellform oder transformierten 53 3 Messwerkzeuge Form (z. B. als spezielles Modell) einliest und nach vorgegebenen Verarbeitungsvorschriften numerisch oder symbolisch auswertet“ (siehe [Dum96], S. 39). Dagegen seien Tools für die Softwaremessung sowohl Messtools als auch Softwarewerkzeuge, die der Ausprägung der jeweiligen Mess-Strategie, der Aufbereitung der Messobjekte oder der (statistischen) Auswertung bzw. Darstellung der Messergebnisse dienten (vgl. [Dum96], ebd.). Derartige Werkzeuge werden in der Literatur oft auch als CAME-Tools (Computer Assisted Software Measurement and Evaluation, vgl. [EDBSt05], S. 49 ff.) bezeichnet. Innerhalb dieser Arbeit wird mit dem Begriff Messwerkzeug eine ZusammenstelMesswerkzeug lung softwarebasierender Werkzeugkomponenten bezeichnet, welche im Rahmen der Softwareentwicklung •zur Softwaremessung eingesetzt werden können und dabei evtl. noch zusätzliche Funktionalitäten •zur Bewertung der Messergebnisse, •zur statistischen Analyse oder •zur Darstellung der Ergebnisse aufweisen. Diejenigen Teilkomponenten eines Messwerkzeuges, welche für die eigentliche Erfassung, Zählung oder Messung der zu erhebenden Messgröße verantwortlich sind, sollen als Messwertgeber bezeichnet werden. Dies kann im einfachsten Fall z. B. ein Messwertgeber Betriebssystemkommando sein, welches die Anzahl der Zeilen einer Textdatei bestimmt (z. B. das Unix-Kommando wc -l <filename>). Üblicherweise wird man jedoch einen Messwertgeber als API-Funktion im Rahmen eines größeren Softwaremessungs-Frameworks implementieren. Es gibt inzwischen zahlreiche Publikationen, in denen Messwerkzeuge klassifiziert und hinsichtlich ihrer Eignung für bestimmte Sprachen und Softwaremaße und ihrer Integrierbarkeit untersucht werden (vgl. [DW97], [Dum99], [RW05]). Auch gibt es Leitfäden, wie einzelne Aktivitäten der Softwaremessung durch eine Kombination von speziellen Messwerkzeugen und in der Regel bereits vorhandenen OfficeAnwendungen werkzeugmäßig unterstützt werden können (vgl. [KRSZ00]). 3.2 Ein Charakterisierungsschema für Messwerkzeuge An dieser Stelle soll ein Charakterisierungsschema dargestellt werden, welches es erlaubt, Messwerkzeuge in Bezug auf ihre Konfigurierbarkeit und individuelle Nutzbarkeit einzuordnen. Die Darstellung erfolgt dabei in Anlehnung an [MH04]. Ein Messwerkzeug stellt gemäß der Definition im vorhergehenden Abschnitt Funktionen zur •Datensammlung, •Verarbeitung und •Präsentation (Visualisierung) von Softwaremetrie-Daten zur Verfügung. Die Variabilität und damit die Konfigurierbarkeit und kontextabhängige Benutzbarkeit eines Messwerkzeuges kann nun in 54 3.2 Ein Charakterisierungsschema für Messwerkzeuge Bezug auf diese drei Dimensionen charakterisiert werden. Die erste Dimension charakterisiert die Art und Weise der Datensammlung selbst, d. h. die Erfassung, Zählung oder Messung der zu erfassenden Größe. Dies erfolgt durch die Messwertgeber, welche folgendermaßen kategorisiert werden können: Variabilität des Messwertgebers •Vordefinierte Messwertgeber: Hierbei beinhaltet das Messwerkzeug eine vordefinierte Menge von Messwertgebern, mit denen jeweils eine bestimmte Messgröße erfasst werden kann. Diese verrichten den Messvorgang in einer vorgegebenen Art und Weise und es ist nicht oder nur schwer möglich, weitere Messwertgeber in das Messwerkzeug zu integrieren. Ein Beispiel hierfür ist das im Abschnitt 3.3.1 erwähnte Kommandozeilen-Tool CMTJava, welches bei jedem Aufruf grundsätzlich vier vorgegebene Softwaremaße erfasst und das Ergebnis als Messprotokoll ausgibt. •Konfigurierbare Messwertgeber: Hierbei enthält das Messwerkzeug ebenfalls eine vorgegebene Menge von Messwertgebern, deren Verhalten jedoch durch den Benutzer angepasst werden kann. Beispielsweise könnte ein LOC-Messwertgeber Konfigurationsmöglichkeiten bzgl. der Zählvorschriften für Leeroder Kommentarzeilen aufweisen. •Variable Messwertgeber: Bei diesen Messwerkzeugen können die vorhandenen Messwertgeber konfiguriert und zusätzliche Messwertgeber hinzugefügt werden. Üblicherweise werden dazu vom Hersteller des Messwerkzeugs die Schnittstellen, welche ein Messwertgeber implementieren muss, offen gelegt. Die zweite Dimension charakterisiert die Methoden und Funktionen zur VerarbeiVariabilität der Datenverarbeitung tung der gemessenen Daten. Diese können folgendermaßen kategorisiert werden: •Vordefinierte Funktionen: Das Messwerkzeug enthält eine vordefinierte Menge von Funktionen zur Verarbeitung, Bewertung und Verknüpfung der Messwerte. Dadurch wird eine bestimmte Art und Weise der Verarbeitung festgelegt. Beispielsweise könnte auf diese Weise eine Bewertungsfunktionalität für die Wartungsanfälligkeit von Sourcecode-Artefakten implementiert sein. Diese berechnet mittels eines bestimmten Algorithmus anhand dreier Softwaremaße (z. B. LOC, zyklomatische Komplexität, Anzahl der Parameter), ob für den untersuchten Sourcecode mit einem erhöhten Wartungsaufwand zu rechnen ist. •Konfigurierbare Funktionen: Hierbei sind die Funktionen zwar ebenfalls vorgegeben, jedoch können die Verarbeitungsschritte konfiguriert und parametrisiert werden. In obigem Fall wäre beispielsweise denkbar, dass sich die Gewichtung der drei Faktoren parametrisieren lässt. •Variable Funktionen: Bei Messwerkzeugen mit variablen Funktionen können die vorhandenen Funktionen nicht nur konfiguriert und parametriesiert werden, sondern es können auch neue Funktionen hinzugefügt bzw. die vorhandenen ersetzt werden. So könnte in obigem Beispiel bei der Berechnung der 55 3 Messwerkzeuge Wartungsanfälligkeit evtl. noch die Anzahl der Revisionen des SourcecodeArtefakts im Rahmen der Versionsverwaltung mit einfließen. •Dynamische Funktionen: Als Messwerkzeuge mit dynamischer Funktionalität sollen solche Implementierungen bezeichnet werden, bei denen neue Funktionen durch den Endanwender dynamisch zur Laufzeit des Messwerkzeuges konfiguriert werden können. Denkbar wäre hier, dass die Verarbeitungsfunktionen mittels graphischer Symbole in einer Benutzeroberfläche dargestellt werden. Diese könnten dann zur Laufzeit der Anwendung mittels entsprechender graphischer Modellierungsfunktionalitäten zueinander in Beziehung gesetzt werden, so dass dadurch neue Verarbeitungsfunktionalitäten entstünden. Beispielsweise könnte auf diese Weise die Größenmessung und die Revisionszählung für Software-Artefakte zueinander in Beziehung gesetzt werden, so dass sich als kombiniertes Maß die Größenänderung pro Commit-Vorgang im Versionsverwaltungssystem ergibt. Die dritte Dimension betrifft die Präsentation der Messergebnisse. In [MH04] wird dabei zwischen Präsentation und Visualisierung unterschieden. Mit Präsentation sei Variabilität der Präsentation die Zusammenstellung der verarbeiteten Daten und mit Visualisierung die eigentliche visuelle Darstellung gemeint.1Da bei dieser Differenzierung die Abgrenzung zur vorhergehenden Datenverarbeitung schwierig erscheint, soll hier nur der Begriff der Präsentation verwendet werden. Die Präsentation von Ergebnissen kann dabei sowohl textuell als auch graphisch oder mittels entsprechender Mischformen erfolgen. Auch bezüglich der Präsentation lassen sich wieder drei Kategorien unterscheiden. •Statische Ergebnispräsentation: Die Art und Weise der Ergebnisdarstellung ist fest vorgegeben und kann vom Anwender nicht verändert werden. •Konfigurierbare Ergebnispräsentation: Hier kann die Ergebnisdarstellung vor der Anwendung des Messwerkzeuges konfiguriert werden. Beispielsweise kann der Anwender bestimmen, ob das Ergebnis in Tabellenform oder als Graphik dargestellt werden soll. •Dynamische Ergebnispräsentation: Bei dieser Form kann der Anwender zur Laufzeit der Anwendung entscheiden, auf welche Weise die Ergebnisse dargestellt werden sollen. Das hier dargestellte Klassifizierungsschema beschreibt in erster Linie den Grad der Konfigurierbarkeit und der Variabilität der Softwaremesswerkzeuge. Dieses Klassifizierungsschema wurde gewählt, um im nächsten Kapitel verschiedene Grundtypen von Messwerkzeugen voneinander abgrenzen zu können. Daneben zeichnen sich die verschiedenen Messwerkzeuge natürlich auch durch unterschiedlich ausgeprägte funktionale Aspekte aus. Dazu gehört beispielsweise die Funktionale Aspekte 1Beispielsweise könnten im Rahmen der Präsentation die darzustellenden Daten in einer XMLDatei abgelegt werden. Bei der Visualisierung wird dann die XML-Datei wahlweise im HTMLoder PDF-Format ausgegeben. 56 3.3 Messwerkzeuge: Stand der Technik Möglichkeit, bei der Datenerfassung auf verschiedene Quellen zugreifen zu können, oder die Fähigkeit zur Echtzeitverarbeitung. Bzgl. des dargestellten Klassifizierungsschemas werden diese beiden Aspekte von den Dimensionen Datensammlung und Verarbeitung abgedeckt. Darüber hinaus werden derartige funktionale Aspekte im folgenden Abschnitt bei der exemplarischen Beschreibung verschiedener Messwerkzeuge mit dargestellt. Die Gliederung orientiert sich dabei am Grad der Konfigurierbarkeit der Messwerkzeuge. 3.3 Messwerkzeuge: Stand der Technik 3.3.1 In Softwareentwicklungsumgebungen integrierte Messwerkzeuge Neben kommandozeilen-orientierten Messwerkzeugen, wie CMTjava2, welche einfache Komplexitätsund Größenmaße für einzelne Sourcecode-Dateien berechnen können, gibt es schon seit einigen Jahren Messwerkzeuge, die in Softwareentwicklungsumgebungen integriert sind. Beispielhaft hierfür ist die Entwicklungsumgebung Borland Together 20063zu nennen. Diese Entwicklungsumgebung ist eine Weiterentwicklung der ursprünglich von der Firma TogetherSoft entwickelten IDE Together ControlCenter und basiert inzwischen auf der Eclipse-Plattform4. Eine sehr ähnliche Funktionalität wie Borland Together 2006 bietet auch das Eclipse Metrics Plugin5, welches als Open-SourceSoftware verfügbar ist. Die Together-IDE enthält sowohl für den Sourcecode als auch für die mit Together modellierten UML-Diagramme eine große Menge vordefinierter Softwaremaße. Im Together Metrics & Audits Together-Sprachgebrauch wird dabei zwischen Metrics und Audits unterschieden. Eine Metric ist dabei ein wie in dieser Arbeit definiertes Softwaremaß. Beispielsweise gibt es eine Code-Metric, welche die Anzahl der im aktuellen Softwareprojekt vorkommenden Java-Klassen ermittelt. Ein Audit ist dagegen ein Softwaremaß, für das ein Schwellwert definiert wurde. Beispielsweise kann für die maximale Zyklomatische Komplexität einer Methode eine Obergrenze definiert werden. Durch das entsprechende Audit würden dann die Komplexitätswerte aller Methoden berechnet und für diejenigen Methoden, bei denen der Schwellwert überschritten wurde, eine Refaktorisierung vorgeschlagen werden. Die Audits gehen teilweise über den Anwendungsbereich von Softwaremaßen hinaus und dienen auch dazu, Codierungsoder Modellierungsfehler aufzudecken, indem sie die Semantik des Sourcecodes oder des UML-Modells untersuchen. Beispielsweise gibt es ein Audit, welches innerhalb von UML-Zustandsdiagrammen Zustände erkennt, die zwar erreicht, aber nicht mehr verlassen werden können und auch keinen Endzustand darstellen. 2CMTJava ist ein Produkt der Firma Testwell mit Sitz in Tampere (Finnland) (http://www.testwell.fi/cmtjdesc.html) 3http://www.borland.com/de/products/together 4http://www.eclipse.org 5http://metrics.sourceforge.net 57 3 Messwerkzeuge Abbildung 3.1: Konfiguration von Softwaremaßen in Borland Together Um die in Together enthaltenen Softwaremaße verwenden zu können, müssen der Sourcecode bzw. die UML-Diagramme bereits existieren. Anschließend können die Verwendung der Together Softwaremaße zu ermittelnden Softwaremaße ausgewählt und in engen Grenzen konfiguriert werden (vgl. Abbildung 3.1). Beispielsweise kann angegeben werden, ob das Softwaremaß für das gesamte Projekt oder nur auf ein Teilpaket angewendet werden soll und wie die Aggregation eines einzelnen Maßes (z. B. LOC) über das gesamte Paket hinweg erfolgen soll. Angeboten werden hier üblicherweise die Summation, die Mittelwertbildung oder die Ermittlung von Maximalwerten. Eine beispielhafte Darstellung der Messergebnisse ist in Abbildung 3.2 zu sehen. Hier wurden für ein Java-Projekt die Softwaremaße •Halstead-Länge, •Halstead-Volumen, •Lines of Code und •Number of Classes auf Methoden-, Klassen-, Paketund Projekt-Ebene berechnet. Da die HalsteadMaße auf Methodenebene nicht definiert sind, ist bei diesen auf Klassen-Ebene die kleinste Granularität angegeben. Die Softwaremaße wurden nur für den produktiven Sourcecode und nicht für den ähnlich umfangreichen Test-Code ermittelt. 58 3.3 Messwerkzeuge: Stand der Technik Abbildung 3.2: Ergebnisdarstellung für ausgewählte Softwaremaße in Borland Together 2006 Die Fähigkeiten von in Entwicklungsumgebungen integrierten Messwerkzeugen sind somit auf die Bedürfnisse des einzelnen Programmierers zugeschnitten. Dieser Programmierer als Zielgruppe kann damit Code-Bestandteile erkennen, die evtl. zu kompliziert aufgebaut, zu lang oder nicht hinreichend dokumentiert sind. Auch können mit diesen Werkzeugen teilweise potentielle semantische Fehler im Sourcecode oder im Design-Modell entdeckt werden. Eine Verknüpfung der Messergebnisse mit Softwaremaßen, welche außerhalb der IDE ermittelt werden, ist erst einmal nicht möglich, wodurch viele Softwaremaße außen vor bleiben. Es ist mit diesen Tools beispielsweise nicht möglich, den Aufwand zu bestimmen, der für die Implementierung eines Java-Paketes nötig war, und diesen zum Halstead-Volumen dieses Pakets in Beziehung zu setzen. Auch ist es nicht möglich, inhaltliche Selektionskriterien für die Berechnung der Softwaremaße anzugeben. Beispielsweise können die Messwerkzeuge nicht erkennen, ob in bestimmten Paketen des Projektes die Anwendungslogik, die Persistenzoder die Visualisierungs-Komponenten der Anwendung implementiert werden. Somit ist auch ein automatisierter Größenvergleich dieser Komponenten nicht möglich. Allerdings lassen sich die Softwaremetrie-Fähigkeiten von Together mittels seines Modul-Konzepts erweitern. Die Auditund Metric-Funktionalitäten von Together Erweiterbarkeit des Together Quality Assurance Moduls sind im sogenannten Quality Assurance (QA) Modul enthalten. Mittels derartiger Module ist es grundsätzlich möglich, die Funktionalität von Together zu erweitern, da die API von Together offen und dokumentiert ist. Im Prinzip muss für ein eigenes Metric-Plugin eine Java-Klasse erstellt werden, welche die entsprechenden Interfaces aus dem QA-Modul implementiert, und in einem Unterverzeichnis der TogetherModul-Verzeichnisstruktur abgelegt werden (vgl. [CH02], S. 140 ff.). Eine Anwendung dieser Erweiterungsmöglichkeiten wurde in [Dau05] in Form des Metrics Builder Plugins vorgestellt. Diese als Prototyp verfügbare Anwendung erlaubt die Kombination der in Together serienmäßig implementierten Mess-Plugins mit selbstentwickelten Plugins und damit die Definition neuer Softwaremaße. Der Messbereich (einzelne Klasse, Paket, ganzes Projekt) dieser Softwaremaße und auch die Kombination dieser Softwaremaße in Form einfacher mathematischer Terme kann 59 3 Messwerkzeuge Abbildung 3.6: IBM Rational ProjectConsole – Beispielsoftwaremaß: Code-Zeilen-Vergleich zu verschiedenen Meilensteinen (aus [GWI04]) Beim Studium der entsprechenden Herstellerinformationen zur ProjectConsole (vgl. [IJ03], [GWI04], [Ish04]) fällt jedoch auf, dass sich die dort beschriebenen SoftSerienmäßig nur einfache Softwaremaße implementiert waremaße auf das reine Abzählen von Artefakten beschränken. So wird die Anzahl der Anforderungen, die Veränderung der Anzahl von Anforderungen, die Anzahl der Anwendungsfälle (Use Cases) mit einem bestimmten Status und Ähnliches beschrieben. Auch können die Gesamtzahl der Programmcodezeilen (LOC) und deren Veränderung (siehe Abbildung 3.6) oder die Anzahl der auftretenden Fehler gemessen werden. Von den innerhalb der IBM Rational Suite speicherbaren TraceabilityInformationen scheint man herstellerseitig bei der Verwendung der ProjectConsole keinen Gebrauch zu machen. Softwaremessungen in Bezug auf Ressourcenmaße wie Mitarbeitereinsatz, Entwicklungszeiten und Personalaufwände sind nur in Verbindung mit MS Project möglich (vgl. [Ish04]). Allerdings handelt es sich hier, wie auf Seite 62 dargestellt, nicht um Softwaremessung im eigentlichen Sinn, da dabei nur Projektinformationen, welche manuell innerhalb von MS Project gepflegt werden müssen, visualisiert werden. Dazu muss zunächst innerhalb von MS Project ein Projektstrukturplan erstellt und gepflegt werden. Für jedes Arbeitspaket müssen Informationen wie Dauer, RessourKombination von ProjectConsole und MS Project cen, Vorgänger, Zeitaufwand und Fertigstellungsgrad in dem MS Project Projektplan manuell fortgeschrieben werden, d. h. auch hier findet keine automatisierte Messung 66 3.3 Messwerkzeuge: Stand der Technik Abbildung 3.7: IBM Rational ProjectConsole – Beispielsoftwaremaß: Zeitaufwände und Fertigstellungsgrade von Projekt-Meilensteinen (aus [GWI04]) statt. Zusätzlich muss ein sogenanntes Microsoft Project Source Template mit Hilfe der ProjectConsole generiert werden, in dem die zu analysierenden Projekt-Felder definiert werden. Schließlich muss noch ein Mapping von den MS-Project-Feldern zu den ProjectConsole Daten-Tabellen in Bezug auf die Typisierung der Daten angegeben werden. Anschließend können die in MS Project gepflegten Daten mittels der ProjectConsole in Form einer Dashboard-Darstellung visualisiert werden. Beispielsweise werden in Abbildung 3.7 die Zeitaufwände und die Fertigstellungsgrade von ProjektMeilensteinen dargestellt. Auch gibt es eine Darstellung über die Einhaltung von Kostenund Zeit-Budgets mittels einer plakativen Tachometer-Darstellung (siehe Abbildung 3.8). Der Cost Performance Index (CPI) gibt an, ob durch die Projektaktivitäten aktuell mehr oder weniger als die budgetierten Kosten aufgewendet werden. Analog gibt der Schedule Performance Index (SPI) an, ob die Projektaktivitäten dem Zeitplan vorauseilen oder diesem hinterherhinken. Beide Indikatoren sollten ungefähr den Wert Eins annehmen. Da die von der ProjectConsole verwendeten Softwaremaße in Form von PerlSkripten implementiert sind, könnten diese grundsätzlich beliebig um neue MaErweiterbarkeit der IBM Rational Suite ße bzw. Kombinationen von Softwaremaßen erweitert werden. Auch die Werkzeuge ClearCase und ClearQuest können mittels Perl-Skripte erweitert werden. Somit könnte auch auf Informationen, die der ProjectConsole standardmäßig nicht zur Verfügung stehen, zugegriffen werden, so dass diese bei der Definition entsprechender Softwaremaße verwendet werden können. Auch wäre es grundsätzlich denkbar, die Fähigkeiten der ProjectConsole mittels geeigneter Perl-Skripte dahingehend zu erweitern, dass auch Prozessdaten wie Aufwände und Ressourcen mit einbezogen werden können. Dies wird insbesondere durch die einheitliche Perl-Programmierschnittstelle der Bestandteile der IBM Rational Suite begünstigt. Standardmäßig sind derartige Möglichkeiten derzeit jedoch nicht implementiert. 67 3 Messwerkzeuge Abbildung 3.8: IBM Rational ProjectConsole – Beispielsoftwaremaß: Einhaltung von Kostenund Zeit-Budgets (aus [Ish04]) 3.3.3 Projektleitstände Das Hauptunterscheidungsmerkmal von Projektleitständen im Vergleich zu klassischen Dashboards ist nach [MHS+06], dass sich Projektleitstände individueller konfigurieren und bedienen lassen, so dass die auf diese Weise gewonnenen Softwaremaße leichter nutzerspezifisch interpretiert werden können. Auf der anderen Seite werden die Begriffe Projektleitstand, Softwareleitstand, Software Project Control Center (SPCC) und Dashboard auch innerhalb derselben Publikation synonym verwendet Software Project Control Center (vgl. [MHS+06]). Der Unterschied von Projektleitständen zu Dashboards ergibt sich im Wesentlichen durch den Grad der Implementierung •variabler und dynamischer Messverarbeitungsfunktionen und •konfigurierbarer und dynamischer Ergebnispräsentationsmöglichkeiten. Da einige Ziele der Softwaremessung (Prognose, Verbesserung, Schwachstellenanalyse) erst mit einem entsprechenden Erfahrungsdatenbank angegangen werden können, haben Projektleitstände oftmals die Möglichkeit, Messergebnisse in einem Datenbanksystem abzulegen und wiederzuverwenden. Insgesamt ist die Grenze zwischen Dashboards und Projektleitständen eher fließend. Beispielsweise wird die IBM Rational ProjectConsole innerhalb dieser Arbeit als Dashboard eingestuft, da sie weder über eine dynamische Funktionsimplementierung noch über dynamische Ergebnispräsentationsmöglichkeiten verfügt. 68 3.3 Messwerkzeuge: Stand der Technik 3.3.3.1 Idealtypisches Architekturmodell für Projektleitstände Münch und Heidrich haben in [MH04] ein Modell für die Architektur von Projektleitständen beschrieben, welches man wohl auf Grund der Anforderungen an Flexibilität und Konfigurierbarkeit als idealtypisch bezeichnen könnte. Um die Architekturprinzipien tatsächlich implementierter Projektleitstände beurteilen zu können, soll dieses idealtypische Architekturmodell von Münch und Heidrich in diesem Abschnitt dargestellt werden. Das Architekturmodell basiert auf drei Schichten (siehe Abbildung 3.9): •In der Informations-Schicht sind alle zum Betrieb des Projektleitstands benötigten Informationen gespeichert. Neben den Messdaten des aktuellen Projekts und Erfahrungsdaten aus früheren Projekten sind auch funktionale Komponenten zur Datenverarbeitung und zur Darstellung der Ergebnisse in entsprechenden Pools innerhalb dieser Schicht abgelegt. •Die eigentliche Datenverarbeitung findet in der Funktions-Schicht statt. Hier erfolgt die Konfiguration der Verarbeitungsfunktionen, die eigentliche Verarbeitung der Messdaten und die Aufbereitung der Ergebnisse zur graphischen Darstellung. •Die Anwender-Schicht schließlich ist für die Interaktion des Benutzers mit dem Projektleitstand zuständig. Die eigentliche Softwaremessung nimmt dabei nur einen kleinen Anteil innerhalb der Erfahrungsdatenbanken skizzierten Architektur ein. Innerhalb der Informations-Schicht gibt es dazu je eine projektspezifische und eine organisationsweite Erfahrungsdatenbank. Diese müssen die dort bereitgestellten Daten nicht notwendigerweise selbst enthalten, sondern stellen vielmehr Mechanismen zum Zugriff auf verteilte Datenbestände bereit. Die projektspezifische Erfahrungsdatenbank bietet somit Zugriffsmöglichkeiten auf Projektpläne, Projektziele und -eigenschaften sowie auf projektspezifische Softwaremaße, während die organisationsweite Erfahrungsdatenbank Informationen wie Qualitätsmodelle oder qualitative Erfahrungswerte bereit stellt. Die oben angesprochene Flexibilität und Konfigurierbarkeit dieses ArchitekturBausteinkonzept konzepts rührt hauptsächlich daher, dass die Funktionalität des Systems in Form von Bausteinen in drei Pools innerhalb der Informations-Schicht hinterlegt ist, jedoch erst zur Laufzeit gemäß der aktuellen Anforderungen konfiguriert wird. Diese Bausteine implementieren die Verarbeitungsfunktionen des Projektleitstandes, die Sichten auf die Datenbestände und die Schnittstellen zur Ausgabe der Ergebnisse: •Funktionsbausteine: Im sogenannten Pool of Functions sind Funktionen wie Monitoring, Vorhersage oder Anleitung hinterlegt. •Sichten: Um die Ergebnisse der Verarbeitungsfunktionen aus verschiedenen Perspektiven darstellen zu können, stellt das System unterschiedliche Sichten beispielsweise für den Projektleiter oder den Qualitäts-Manager zur Verfügung. •Ausgabeschnittstellen: Da die Sichten schließlich mit einem geeigneten Ausgabesystem (z. B. Web-Browser, Gnuplot, MS Excel) visualisiert werden müssen, ist auch ein Pool mit entsprechenden Schnittstellenfunktionen vorgesehen. 69 3 Messwerkzeuge Abbildung 3.9: Idealtypisches Architekturmodell für Projektleitstände (aus [MH04]) 70 3.3 Messwerkzeuge: Stand der Technik Da die in der Informationsschicht hinterlegte Funktionalität der SoftwareleitstandsKonfiguration Architektur nach Münch und Heidrich so variabel konzipiert ist, resultieren daraus auch entsprechend komplexe Konfigurationsmöglichkeiten. Dies soll in der Customizing-Einheit innerhalb der Funktionsschicht erfolgen. Zunächst müssen die Erfahrungsdatenbanken initialisiert werden, indem alle Datenquellen definiert werden. Dann muss die eigentliche Funktionalität mittels der Funktionsbausteine zusammengestellt werden. Dabei müssen auch Sichten definiert und Ausgabenschnittstellen zugeordnet werden. Die Data-Processing-Einheit soll nun über die ausgewählten und konfigurierten Datenverarbeitung Funktionsbausteine von der Customizing-Einheit informiert werden und diese hinsichtlich benötigter Einund Ausgabeinformationen und Abhängigkeiten zu anderen Funktionsbausteinen analysieren. Während der Ausführung der Funktionsbausteine ruft die Data-Processing-Einheit die entsprechenden Eingabe-Informationen aus den Erfahrungsdatenbanken ab und stößt dabei gegebenenfalls entsprechende Softwaremetrie-Prozesse an. Die Ergebnisse werden an die Präsentations-Einheit übermittelt werden. Da dort je nach ausgewählter Sicht entsprechende Darstellungen generiert werden Präsentation sollen, müssen die Sichten zunächst analysiert werden, um zu ermitteln, welche Ergebnisse der Funktionsbausteine in die Ergebnisdarstellungen integriert werden müssen. Die Ergebnisdarstellungen werden dann zur Visualisierung an die Benutzerschicht weitergeleitet. Parallel dazu können in der Packaging-Einheit Erfahrungen, welche bei der BeErfahrungssammlung nutzung des Projektleitstandes durch den Anwender gewonnen wurden, subsumiert und generalisiert werden, um sie für zukünftige Projekte in den Erfahrungsdatenbanken abzuspeichern. Dabei sollen in der Regel nicht nur einfach die Messwerte persistent abgelegt werden, sondern die Erfahrungen sollen einzeln validiert und zu Erfahrungspaketen gebündelt in einer Experience Base gespeichert werden (vgl. S. 165). Münch und Heidrich haben mehrere Software-Messwerkzeuge hinsichtlich ihrer Konformität mit obigen Empfehlungen für Projektleitstände untersucht und für sieben Werkzeuge die gewonnenen Ergebnisse in [MH04] beschrieben. Von den untersuchten Werkzeugen weisen dabei nur vier entsprechende Möglichkeiten auf, sowohl die Funktionen als auch die Ergebnispräsentationen selbst zu konfigurieren: •ARIS Process Performance Manager11 (IDS Scheer AG) •Amadeus (Arcadia Project) •SEL-NASA Software Management Environment (SME) •WebME Nachdem das System Amadeus bereits im Abschnitt 3.3.2.1 besprochen und als klassisches Dashboard eingestuft wurde, sollen die anderen drei genannten Systeme und weitere Ansätze für Projektleitstände im Folgenden näher untersucht werden. 11 http://www.ids-scheer.com/germany/products/aris_controlling_platform/49532 71 3 Messwerkzeuge 3.3.3.2 ARIS Process Performance Manager Es überrascht ein wenig, dass der ARIS Process Performance Manager (ARIS PPM), welcher von der IDS Scheer AG in Saarbrücken entwickelt und vertrieben wird, in [MH04] als Software Project Control Center eingestuft wurde. Laut Herstellerinformationen (vgl. [PPM07]) handelt es sich dabei um ein Werkzeug zur Analyse, Werkzeug zur Untersuchung von Unternehmensprozessen zur Bewertung und zum Monitoring von Unternehmensprozessen, wie beispielsweise •Auftragsbearbeitung, •Beschaffung, •Kreditbearbeitung und Wertpapiergeschäft im Finanzbereich sowie •zur generellen Überwachung von Service Level Agreements. ARIS PPM wird üblicherweise an ERP-Systeme wie SAP ERP12 angeschlossen, um die Leistung von Geschäftsprozessen anhand von Laufzeitdaten zu messen. Dabei werden Prozesskennzahlen wie •Durchlaufzeiten, •Termintreue oder •Prozesskosten berechnet. Diese Kennzahlen können dann mittels eines sogenannten PerformanceCockpit visualisiert werden (vgl. Abbildung 3.10). Damit ist ARIS PPM ein Werkzeug, um die Performance von betriebswirtschaftlichen Geschäftsprozessen zu messen und zu analysieren. Grundsätzlich ist dieses System dahingehend erweiterbar, dass Daten aus anderen IT-Systemen extrahiert und verdichtet werden können. Allerdings scheint das System auf die Analyse standardisierter Prozesse, wie beispielsweise die Abwicklung einer Bestellung, spezialisiert zu sein (vgl. [PPM07]). Im Software-Engineering hat man es dagegen in der Regel mit variablen Prozessen zu tun. Insbesondere werden die durchzuführenden Projektaktivitäten für jedes Softwarevorhaben projektspezifisch angepasst (Tailoring), so dass das ARIS-PPM-System keine definierten Anknüpfungspunkte finden dürfte. Auch wird von Seiten des Herstellers ein derartiges Anwendungs-Szenario nicht beschrieben. Jedoch weist die Dashboard-Darstellung viele der in Abschnitt 3.3.2 beschriebenen Eigenschaften, wie Trend-Darstellung, Drill-Down-Funktionen und Ampel-Darstellungen auf. Somit könnte ARIS PPM durchaus als Dashboard-Frontend für entspreARIS PPM als DashboardFrontend chende Softwaremetrie-Werkzeuge in Betracht kommen. Im Auslieferungszustand ist die Software jedoch nicht als Leitstand für Softwareprozesse verwendbar. 3.3.3.3 Die SEL-NASA Software Management Environment Auch bei der Software Management Environment (SME, vgl. [HKVD92], [HKV94]), welche am Software Engineering Laboratory des NASA Goddard Space Flight Centers entwickelt wurde, fällt es schwer, diese als Software-Leitstand zu bezeichnen. Vielmehr handelt es sich um ein Frontend zur Auswertung von Erfahrungsdaten über Softwareprojekte, welche in einer Datenbank abgelegt sind. Ein herausragendes 12http://www.sap.com/solutions/business-suite/erp 72 3.3 Messwerkzeuge: Stand der Technik Abbildung 3.10: Performance Dashboard des ARIS Process Performance Managers Merkmal dieses Systems ist jedoch, dass es eine Art Expertensystem integriert hat, welches dem Anwender auf Basis von sowohl aktuellen Projektwerten als auch von Expertensystem Erfahrungswerten konkrete Empfehlungen für die weitere Vorgehensweise geben soll. Die Daten vergangener und aktueller Projekte sind in der sogenannten SELDatenbank abgelegt, welche sich am genannten Software-Engineering-Labor im Laufe mehrerer Jahre entwickelt hat. Zu den gespeicherten Informationen gehören •Aufwände, •Rechenzeitnutzung, •Softwareänderungen, •Softwarefehler sowie •Code-Umfangsdaten in LOC bzw. Modulanzahlen. Letztendlich kennt das SME-System genau acht Softwaremaße dieser Art, wobei es selbst keine Softwaremessungen durchführen kann. Stattdessen müssen die Daten Manuelle Datenerfassung sowohl vergangener als auch aktueller Softwareprojekte manuell in die Datenbank eingepflegt werden. Auch Informationen über das Anwendungsgebiet der Softwareprojekte, verwendete Programmiersprachen, Werkzeuge und Planungsdaten (Zeitund Aufwandsschätzungen) werden in der Datenbank hinterlegt. 73 3 Messwerkzeuge Daneben wurden auf Basis in früheren Projekten gemachter Erfahrungen Modelle entwickelt, welche Beziehungen zwischen bestimmten Entitäten des Softwareentwicklungsprozesses beschreiben. Diese Modelle sind ebenfalls innerhalb des SME-Systems abrufbar. Damit soll es möglich sein, ein aktuelles Projekt im Vergleich zu einem typischen Projekt zu beurteilen und die künftige Entwicklung dieses Projektes vorherzusagen bzw. abzuschätzen. Als Beispiele solcher Erfahrungsmodelle werden in [HKVD92] Funktionen genannt, welche den Personalbedarf innerhalb eines Projektes als eine Funktion über Erfahrungsmodelle die Entwicklungszeit darstellen oder eine Gleichung, welche eine Beziehung zwischen dem Entwicklungsaufwand und der Anzahl der Code-Zeilen herstellt. Schließlich enthält das SME-System noch eine Reihe von Entwicklungsregeln und Problemlösungsvorschlägen in Form eines Expertensystems (siehe folgendes Beispiel). Beispiel 5 (Expertensystemregel) Eine Fehlerrate, die niedriger als gewöhnlich Beispielregel eines Expertensystems ausfällt, kann folgende Ursachen haben: • Ungenügende Testaktivitäten • Erfahrenes Entwicklungsteam • Das Problem ist weniger kompliziert als erwartet Das SME-System bietet nun Möglichkeiten, die aktuellen Projektmaße wie Fehlerrate, Personalstunden oder Code-Umfang (in LOC) zu beobachten13 und sowohl mit ausgewählten vergangen Projekten als auch mit generierten Erwartungswerten zu vergleichen, welche auf obigen Modellen basieren. Ebenfalls ist es möglich, auf Basis der aus vergangenen Projekten gewonnenen Erfahrungsmodelle, die aktuellen Messwerte zu extrapolieren, um so den weiteren Projektverlauf abzuschätzen. Dabei geht das SME-System von einem streng wasserfallartigen Vorgehensmodell aus, welches aus den Phasen •Design •Codierung und Unit-Tests •Integrationstests •Akzeptanztests besteht. Aufgrund dieser Vorhersagemodelle kann das SME-System auch Abweichungen gegenüber dem geplanten Verlauf bestimmter Projektkennzahlen erkennen. Mittels des integrierten Expertensystems versucht das System in diesem Fall, dem Anwender Vorschläge für die weitere Vorgehensweise zu unterbreiten. Die Abbildung 3.11 Vorschläge für die Projektleitung zeigt beispielsweise eine Abweichung der kumulierten Fehlermenge vom erwarteten Verlauf. Dabei wird der erwartete Verlauf inklusive einer möglichen Bandbreite darstellt. Zusätzlich werden mögliche Empfehlungen gegeben. Die Konfigurationsund Funktionsmöglichkeiten des SME-Systems sind somit sehr beschränkt. Das System kennt acht Softwaremaße und besitzt eine feste Anzahl Funktionen zur Beobachtung, Analyse und zum Vergleich dieser Maße. Das System 13Dazu müssen diese Projektmaße vorher manuell erfasst worden sein. 74 3.3 Messwerkzeuge: Stand der Technik Abbildung 3.11: Empfehlungen des SME-Systems aufgrund von Abweichungen gegenüber dem geplanten Projektverlauf (aus [HKVD92]) kann die Softwaremaße nicht selbständig ermitteln, sondern ist auf eine manuelle Pflege der Daten durch den Anwender angewiesen. Herauszuheben ist jedoch das integrierte Expertensystem, welches versucht, aufgrund hinterlegter Erfahrungswerte und Regeln, Abweichungen in den Projektkennzahlen zu erkennen und zu begründen und entsprechende Vorschläge zu unterbreiten. 3.3.3.4 WebME Einen anderen Schwerpunkt legt das von Tesoriero und Zelkowitz entwickelte Softwaremesswerkzeug WebME (Web Measurement Environment, vgl. [TZ97]). Während bei SME der Expertensystemansatz und die Möglichkeiten der Datenvisualisierung im Vordergrund stehen, zeichnet sich das WebME-System durch dynamische DefiDynamische Definition von Softwaremaßen nitionen von Softwaremaßen in einer verteilten Entwicklungsumgebung aus. Zwar wird in [MH04] erklärt, dass das WebME-System auf dem SME-Ansatz basieren würde, und auch die Namensgebung deutet auf einen derartigen Sachverhalt hin. Tatsächlich verwendet WebME jedoch keine Komponenten des SME-Systems und basiert auf einer völlig anderen Architektur (vgl. [TZ97]), welche derjenigen des in Abbildung 3.9 (S. 70) dargestellten idealtypischen Projektleitstandes ähnelt. Dabei kann die Informationsschicht mehrere verteilte Datenquellen enthalten, auf die mittels sogenannter Data-Wrappers zugegriffen wird. Diese implementieren eine einheitliche Schnittstelle zwischen den Datenquellen und der Verarbeitungslogik. Beim WebME-System werden mittels einer Skriptsprache die verarbeitbaren Softwaremaße definiert, welche als Attribute bezeichnet werden. Dabei wird zwischen direkten und indirekten Attributen unterschieden. Direkte Attribute werden durch sogenannte Instruments erhoben. Das sind mittels Data-Wrapper gekapselte Messwertgeber. Indirekte Softwaremaße werden als Equation bezeichnet und ergeben sich durch Kombination von direkten Attributen mittels der vier Grundrechenarten. 75 3 Messwerkzeuge Daten sollten Plugin-artig dem Werkzeug hinzugefügt werden können, um auch alle Entitäten des Softwareentwicklungsprozesses vermessen zu können. •Die Softwaremessung muss so weit wie möglich automatisiert werden. Nur Automatisierung durch automatisierte Softwaremessung kann sichergestellt werden, dass die Messungen überhaupt durchgeführt werden und dass die Messungen in konsistenter Weise erfolgen, um eine Vergleichbarkeit der Messergebnisse zu gewährleisten. Einige der dargestellten Werkzeuge sind dagegen nur als Visualisierungswerkzeuge für bereits in entsprechenden Datenbanken vorhandene Softwaremaße zu betrachten. •Gesammelte Daten werden oftmals zusammenhanglos angeboten, was die Ermittlung und Verfolgung von Abweichungen von den Erwartungswerten und deren Ursachen unmöglich macht. Informationen, welche sich nur aus dem Berücksichtigung des Kontexts Zusammenspiel unterschiedlicher Datenquellen ergeben, bleiben meist völlig unerkannt (vgl. [MHS+06]). Viele Softwaremaße erhalten ihre Bedeutung nur in dem Kontext, in dem sie erfasst werden. Sie können nur beurteilt werden, wenn weitere Rahmenbedingungen oder das Umfeld, innerhalb derer die Softwaremessung durchgeführt wurde, bekannt sind. Beispielsweise sagt die Anzahl der gefundenen Fehler nichts über die Qualität des Entwicklungsprozesses aus, wenn nicht auch der Projektumfang bzw. der Umfang des zu entwickelnden Softwaresystems mit angegeben wird. Somit muss bei der Softwaremessung sichergestellt werden, dass Informationen über den Kontext des Messobjekts – im angegebenen Fall also Informationen über die Projektgröße – ebenfalls bei der Beurteilung des Messwertes zur Verfügung stehen. •Bei der Präsentation der Messergebnisse werden die Daten oftmals ungefiltert und nicht rollenbezogen angeboten. Dadurch müssen die Projektbeteiligten Filtermöglichkeiten eine unnötig große Menge an Daten überblicken, die eigentlich nur für jeweils eine Teilgruppe von Bedeutung sind, wodurch letztendlich die Effizienz bei der Arbeit mit diesen Daten sinkt (vgl. [MHS+06]). •Ein wichtiger Aspekt der Softwaremessung ist das Projekt-Controlling, bei dem Controllinggerechte Softwaremessung insbesondere die Prozesse und die Ressourcen des Softwareprojektes beurteilt werden, mit dem Ziel, die Effizienz der Prozesse zu steigern. Dazu müssen auch die im Rahmen der Softwareentwicklung durchgeführten Aktivitäten bei der Softwaremessung identifiziert und mit erfasst werden können, um diese Aktivitäten auch auf Effektivität und Effizienz hin beurteilen zu können. Viele Messwerkzeuge sind auf die Produkte des Softwareentwicklungsprozesses fokussiert und können daher hauptsächlich im Rahmen des Prozesses erzeugte Artefakte vermessen, jedoch keine Prozesseigenschaften erfassen. Es bedarf jedoch auch der Möglichkeit festzustellen, welcher Personalaufwand beispielsweise mit bestimmten Aktivitäten verbunden ist oder wie effizient 82 3.4 Zusammenfassung und Beitrag dieser Arbeit bestimmte Aktivitäten (z. B. Code-Reviews) sind. Dazu müssen diese Aktivitäten im Rahmen der Softwaremessung automatisiert identifiziert werden können. Dieser Aspekt wird in den oben aufgeführten Ansätzen jedoch gar nicht berücksichtigt, und ist daher ein Kernaspekt des im Rahmen dieser Arbeit entwickelten Frameworks zur Softwaremessung. Zwar wird dieser Aspekt teilweise bereits von der Forderung nach der Kontext-Berücksichtigung abgedeckt, jedoch soll er zur einfacheren Referenzierung im Rahmen dieser Arbeit als Controlling-gerechte Softwaremessung (vgl. Abschnitt 4.1, S. 85 ff.) bezeichnet werden. Wenn man die Erfüllung der genannten Kriterien Kernanforderungen an Projektleitstände •Erweiterbarkeit, •Automatisierung, •Berücksichtigung des Kontexts, •Filtermöglichkeiten, •Controlling-gerechte Softwaremessung zusammen mit leistungsfähigen •Visualisierungsmöglichkeiten als Anforderungen an Projektleitstände betrachtet, so muss man feststellen, dass es derzeit keine existierenden Systeme gibt, welche allen diesen Forderungen gerecht werden. Dies wird auch an den in [HL06] aufgeführten Publikationen zum Thema Softwareleitstände deutlich (vgl. [HL06], S. 83–126). Die dort aufgeführten Softwareleitstände existieren entweder nur in Form eines Konzeptes oder sind auf einen Teilaspekt der Softwareentwicklung, wie beispielsweise die Softwarequalität, eingeschränkt. Als Beleg dafür, dass im Bereich der Projektleitstände noch Entwicklungsbedarf besteht, mag auch das SoftPit-Projekt (vgl. Abschnitt 3.3.3.5, S. 77 ff.) gelten. Dieses Projekt, welches sich naturgemäß stark an dem im Abschnitt 3.3.3.1 (S. 69 ff.) beschriebenen idealtypischen Architekturmodell für Projektleitstände orientiert, scheint grundsätzlich die oben genannten Anforderungen angehen zu wollen. Auch wenn der genaue Funktionsumfang der innerhalb dieses Projektes implementierten Specula-Leitstandsimplementierung nur sehr ungenau beschrieben wird (vgl. [HM07a], [CHM+07]), ergibt sich dennoch an dieser Stelle die Möglichkeit, die Zielsetzungen der vorliegenden Arbeit von denen des Soft-Pit-Projektes abzugrenzen. 3.4.2 Zielsetzung: Ein leichtgewichtiger Projektleitstand Das Soft-Pit-Projekt geht vom Umfang und der Zielsetzung her weit über die eigentliche Softwaremessung hinaus. Die tatsächliche Implementierung einer Projektleitstandsanwendung erscheint nur als Teilprojekt innerhalb des Soft-Pit-Themenkomplexes. Vielmehr stehen dagegen die Auswahl von Key Performance Indikatoren, die Ausarbeitung von Ursache-Wirkungs-Relationen und die Entwicklung von Projektkontrolltechniken im Vordergrund. 83 3 Messwerkzeuge In dieser Arbeit soll dagegen ein eher leichtgewichtiges Framework zur Softwaremessung dargestellt werden, welches zur Umsetzung einer Controlling-gerechten Softwaremessung eingesetzt werden kann. Unter „leichtgewichtig“ ist dabei zu verstehen, dass nicht ausgefeilte Visualisierungsmechanismen und eine komfortable Benutzeroberfläche im Vordergrund stehen sollen. Stattdessen soll das Framework in vorhandene Entwicklungsumgebungen integrierbar sein, und die Anwender sollen durch die Verwendung des Softwaremessungs-Framework nicht gezwungen werden, ihre Prozesse zu ändern. Wie im Kapitel 5 dargestellt wird, ist das Framework skriptgesteuert konzipiert und die Erweiterbarkeit und Konfigurierbarkeit ergibt sich aus der jederzeitigen Anpassbarkeit der entsprechenden Programm-Skripte. Das Ergebnis dieser Arbeit ist damit weder ein Dashboard, im Sinne eines Visualisierungssystems für Softwaremaße, noch ein elaborierter Projektleitstand, wie er im Soft-Pit-Projekt angestrebt wird. Eine gute Charakterisierung wird dagegen durch den Begriff Kommandozeilen-Leitstand gegeben, da die Softwaremessungen KommandozeilenLeitstand selbst mittels in einer Skriptsprache implementierter Messwertgeber erfolgen. Diese Messwertgeber können zur Projektlaufzeit letztendlich auf der Kommandozeile den aktuellen Erfordernissen angepasst werden. Um dabei eine Controlling-gerechte Softwaremessung zu erreichen, bestehen die wissenschaftliche Herausforderungen darin, Möglichkeiten aufzuzeigen, •die zu erhebenden Softwaremaße unabhängig von einem konkreten Projekt zu definieren und •die zu messenden Entitäten durch die verwendeten Messwerkzeuge automatisiert identifizieren zu können. Nur dadurch ist es möglich, wie in Kapitel 1 gefordert (vgl. S. 3), die Softwaremaße wiederzuverwenden und projektübergreifend einzusetzen. Der entsprechende Ansatz wird im folgenden Kapitel dargestellt. Die Kernidee dabei ist, die Softwaremaße an Elemente des Vorgehensmodells anzuknüpfen (vgl. Abschnitt 4.2). Es wird im angegebenen Kapitel gezeigt werden, dass dadurch sowohl •die automatische Identifizierung der zu messenden Entitäten als auch •die Zuordnung der Softwaremaße zu einem Kontext sowie •die konsistente und vergleichende Softwaremessung über Projektgrenzen hinweg ermöglicht wird. 84 4 Prozessintegration Change is the essential process of all existence. (Mr. Spock, Star Trek) 4.1 Controlling-gerechte Softwaremessung Wie im Abschnitt 2.3 dargestellt, sind auf Managementebene und damit auch für das Projekt-Controlling insbesondere die als Kernattribute bezeichneten Messgrößen •Umfang, •Aufwand, •Qualität, •kalendermäßige Zeitdauer und •Produktivität von großer Bedeutung. Diese Kernattribute können im Kontext verschiedener Entitäten untersucht werden. Beispielsweise kann der Aufwand in Bezug auf einzelne Arbeitspakete, Meilensteine, Entwicklungsphasen oder Tätigkeitsarten untersucht werden. Diese kontextabhängige Sichtweise ist für das Projektmanagement und dabei insbesondere für die Aufwandsschätzung und das Projekt-Controlling von Belang. Dies soll durch die folgenden Fragestellungen verdeutlicht werden. Komponentenbezogene Aufwandsverteilung: Welcher Aufwand wurde für die Entwicklung einer bestimmten Softwarekomponente, z. B. des Web-Frontends einer Anwendung, erbracht? Der ermittelte Aufwand kann beispielsweise bei Aufwand für einzelne Softwarekomponenten einem nachfolgenden Softwareprojekt in die Bepreisung oder in Entscheidungen bzgl. des Personalbedarfes eingehen. Eine genaue Berechnung des Herstellungsaufwandes für einzelne Komponenten ist grundsätzlich nur möglich, wenn bei der Zeiterfassung auf Komponentenebene kontiert wird. Da dies in der Praxis nicht immer der Fall ist, sondern meistens nur auf Tätigkeiten kontiert wird, sind heuristische Verfahren (Faustregeln) denkbar, den Herstellungsaufwand für einzelne Komponenten zumindest näherungsweise zu bestimmen. Dies ist beispielsweise möglich, wenn bekannt ist, dass bestimmte Softwareentwickler in der Regel jeweils nur einzelne Komponenten (z. B. Web-Oberflächen) implementieren. Phasenbezogene Aufwandsverteilung: Wie verhalten sich die normierten Aufwände für einzelne Entwicklungsphasen zwischen verschiedenen Projekten? Daraus Aufwand je Phase können evtl. Rückschlüsse auf unterschätzte Schwierigkeiten bei der Projektplanung gezogen werden oder es zeichnen sich Trends bzgl. der Aufwandsverteilung in den abgeschlossenen Projekten ab. Da die Projekte in der Regel einen 85 4 Prozessintegration unterschiedlich großen Umfang haben, müssen die Aufwandsangaben normiert werden, indem sie durch einen Faktor dividiert werden, der die Projektgröße widerspiegelt. Verteilung des Arbeitsfortschrittes: Softwareentwicklung erfolgt heutzutage häufig iterativ. Dabei wird zuerst ein Prototyp entwickelt, der dann in weiteren Iterationsstufen ausgebaut und verfeinert wird. Schließlich werden im Rahmen von Kundenakzeptanztests weitere Modifikationen vorgenommen bzw. noch zusätzliche Funktionen implementiert. Bei dieser Konstellation kann von InterAufwand für Prototyp vs. Gesamtaufwand esse sein, welcher Anteil der fertigen Anwendung bereits in der Prototyp-Phase entstanden ist, und welcher Programmumfang später hinzugefügt wurde. Auch ist interessant, welchen Umfang die Programmänderungen während der Testphasen haben, da daraus Rückschlüsse auf die Genauigkeit bzw. die Stabilität der ursprünglichen Anforderungen gezogen werden können. Falls dieser in den einzelnen Phasen erreichte Arbeitsfortschritt bzw. Fertigstellungsgrad moneEarned Value Analyse tär bewertet wird, so erhält man den in diesen Phasen erzeugten Earned Value (vgl. [Fie05], S. 157 f., [Bur02], S. 371 ff.). Fehlerverteilung: Wie im Abschnitt 2.3.5.3 dargestellt, kann unter bestimmten Bedingungen durch Einführung formaler Designund Code-Reviews die DefectEffektivitätskontrolle Removal-Effectiveness (DRE) deutlich erhöht werden. Die DRE kann zwar erst nach Projektende bestimmt werden, jedoch sollte sich die Effektivität der Reviews auch bereits zur Projektlaufzeit durch eine Verschiebung der Fehlerrate hin zu den früheren Projektphasen zeigen. Der entscheidende Punkt an obigen Beispielen, welche noch weiter fortgesetzt werden könnten, ist, dass es sich hier nicht um einfache Produktmaße, sondern um Prozessmaße handelt, welche von den im Kapitel 3 dargestellten Messwerkzeugen nur unzureichend ermittelt werden können. Es reicht für diese Softwaremaße nicht, den Aufwand, den Code-Umfang oder die Anzahl der Fehler auf Projektebene bestimmen zu können, sondern diese Maße müssen im Kontext einzelner Projektphasen und Aktivitäten oder auch in Bezug auf einzelne Komponenten des zu erstellenden Produkts bestimmt werden können. Natürlich könnten obige Maße aus den im Versionsverwaltungssystem und im Zeiterfassungssystem enthaltenen Informationen manuell und mit einigem Aufwand errechnet werden. Aber für die Integration derartiger Softwaremaße in einen ProjektLeitstand müssen Aufwände zu einzelnen Projektaktivitäten oder Produktkomponenten automatisiert zuordenbar sein. So sollte das System erkennen können, welche Code-Bestandteile z. B. zur Datenbankschicht der zu entwickelnden Anwendung gehören, damit diese bzgl. ihres Umfanges oder der Fehlerdichte vermessen werden können. Genauso sollte das System den Aufwand, der für eine bestimmte Projektphase erbracht wurde, selbständig ermitteln können. Da die Bezeichnungen für die zu entwickelnden Komponenten in der Regel nicht und die der Projektaktivitäten nicht notwendigerweise von vornherein feststehen, müssen generische Bezeichnungen für diese Entitäten definiert werden, welche dann 86 4.1 Controlling-gerechte Softwaremessung zur Definition der entsprechenden Softwaremaße verwendet werden. Gesucht ist daAllgemeine Grundstruktur von Softwareprojekten mit eine Grundstruktur für die zu vermessenden Softwareprojekte, welche mit diesen generischen Bezeichnungen beschrieben wird. Im einfachsten Fall könnte man ein Softwareentwicklungsprojekt mittels der Struktur Analyse — Design — Implementierung — Test — Verwaltung beschreiben. Die Elemente dieser Grundstruktur dienen dann als AnknüpfungsAnknüpfungspunkte für Softwaremaße punkte für die zu ermittelnden Softwaremaße. Dabei wird nicht notwendigerweise vorausgesetzt, dass sich das so beschriebene Projekt eines streng wasserfallartigen Prozessmodells bedingen würde. Die angegebene Struktur beschreibt in diesem Fall nur die Tätigkeitsarten, welche in dem Projekt vorkommen, und es können damit Softwaremaße wie •Design-Aufwand, •aufgetretene Fehler während der Implementierung oder •während der Design-Aktivitäten produzierter Code-Umfang (b=Umfang der Prototypen) definiert werden. Um diese Softwaremaße automatisiert bestimmen zu können, müssen die zu messenden Entitäten (z. B. Produkte, Arbeitszeiten, Fehler) entsprechend mit den (abgeKennzeichnung von Entitäten kürzten) Bezeichnern dieser Grundstruktur, d. h. mit eindeutigen IDs, gekennzeichnet werden. Dies bedeutet im obigen Beispiel, •dass im Rahmen der Zeiterfassung Arbeitszeiten, welche mit Design-Aktivitäten verbunden sind, als solche zu kennzeichnen sind, •dass während der Implementierung aufgetretene Fehler im Bug-Tracking-System entsprechend gekennzeichnet werden und •dass beim Check-in im Versionsverwaltungssystem die Commit-Informationen mit den IDs der verwendeten Projektstruktur versehen werden. Die Anknüpfung von Softwaremaßen an einer derartigen Grundstruktur mit generischen, d. h. projektunabhängigen Bezeichnern (IDs) für die Elemente dieser GrundProjektunabhängigkeit und Vergleichbarkeit struktur, ermöglicht es, die zu ermittelnden Softwaremaße ex ante und unabhängig von einem konkreten Projekt zu definieren. Auch kann somit festgelegt werden, welche Softwaremaße grundsätzlich bei jedem durchzuführenden Softwareentwicklungsprojekt zur Anwendung kommen sollen, um Vergleiche zwischen den einzelnen Projekten durchzuführen. In den nächsten Abschnitten werden daher mögliche Anknüpfungspunkte für Softwaremaße dargestellt und auf ihre Eignung für eine automatisierte Softwaremessung untersucht. Es werden somit Möglichkeiten dargestellt, eine Grundstruktur für Softwareentwicklungsprojekte anzugeben, die unabhängig von einem konkreten Projekt ist, und deren Elemente als Anknüpfungspunkte für Softwaremaße verwendet werden können. 87 4 Prozessintegration 4.2 Anknüpfungspunkte für Softwaremaße Ein Softwareentwicklungsprozess lässt sich grundsätzlich als Verbund von •Projekt-Rollen (Funktionsträger, process roles) beschreiben, die bestimmte als •Aktivitäten bezeichnete Operationen durchführen, welche auf •Prozess-Produkte (Artefakte) angewendet werden (vgl. [Obj05]). Neben den genannten drei Prozesselementen, werden bei der Beschreibung konkreter Vorgehensmodelle typischerweise noch •Phasen und Iterationen, welche den Prozess gliedern, •verwendete Werkzeuge und •Regeln (Methoden, Anweisungen), gemäß derer die Aktivitäten durchgeführt werden, genannt (vgl. Abbildung 4.1). Abbildung 4.1: Grundelemente eines Softwareentwicklungsprozesses Die Prozessregeln und die eingesetzten Werkzeuge sollen innerhalb dieser Arbeit nicht als Anknüpfungspunkte für Softwaremaße verwendet werden, da sie selbst nicht Ausklammerung von Prozessregeln und Werkzeugen vermessen werden können. Es lassen sich lediglich die Auswirkungen ihrer Anwendung und insbesondere deren Effektivität und Effizienz beurteilen. Dazu sind jedoch die Auswirkungen dieser beiden Elemente auf die Aufwände für bestimmte Aktivitäten oder die Qualität der erstellten Artefakte zu untersuchen. Dabei muss zwar tatsächlich festgehalten werden, nach welchen Regeln die Aktivitäten durchgeführt wurden oder welche Werkzeuge bei der Erstellung der Artefakte eingesetzt wurden. Trotzdem erscheint es nicht grundsätzlich sinnvoll, die zu messen88 4.2 Anknüpfungspunkte für Softwaremaße den Entitäten mit IDs für die angewendeten Regeln bzw. die verwendeten Werkzeuge zu kennzeichnen. Falls derartige Untersuchungen bzgl. der Effektivität und Effizienz von Methoden und Werkzeugen durchgeführt werden sollen, so würde man eher deren Auswirkungen bei verschiedenen Projekten oder Teilprojekten betrachten. Da in diesem Fall bekannt ist, welche Aktivitäten oder Artefakte zu welchem Projekt gehören, ist eine einzelne Kennzeichnung hier nicht sinnvoll. Grundsätzlich sind Softwaremessungen bzgl. bestimmter Projekt-Rollen denkbar, wenn untersucht werden soll, welche Kosten für bestimmte Projekt-Rollen anfallen. Dazu können jedoch viel unmittelbarer die Kosten bzw. die Aufwände für die erbrachten Aktivitäten ermittelt werden. Die softwaremetrische Untersuchung von Projekt-Rollen führt letztendlich auch zur Betrachtung der Projektmitarbeiter, welche diese Rollen innehaben. Hier beKeine Softwaremessung an Mitarbeitern steht die große Gefahr, dass man von Seiten der Organisationsleitung versucht ist, die Beurteilung von Mitarbeitern z. B. auf Basis der ermittelten Produktivitätsmaße durchzuführen. Da von einer solchen Vorgehensweise abzuraten ist, da sie in der Regel kein ganzheitliches Bild von der Leistung der einzelnen Mitarbeiter liefern wird, soll im Folgenden die Anknüpfung von Softwaremaßen an Projekt-Rollen bzw. an Projekt-Mitarbeitern nicht weiter betrachtet werden. Als Anknüpfungspunkte für Softwaremaße werden innerhalb dieser Arbeit somit •Aktivitäten, •Artefakte und •Projektphasen (bzw. Iterationen) verwendet. Diese drei Möglichkeiten der Projektstrukturierung werden in den nachfolgenden Unterabschnitten 4.2.1–4.2.3 noch genauer dargestellt. Zusätzlich wird im Abschnitt 4.2.4 mit den sogenannten Features eine weitere Möglichkeit dargestellt, Projekte zu strukturieren. Die Elemente dieser derart definierten Projektstruktur liefern eine Möglichkeit, die im Rahmen des Softwareentwicklungsprozesses auftretenden Entitäten zu kennzeichnen, um sie dann im Rahmen der Softwaremessung wiedererkennen zu können. Da diese Angaben (Aktivität, Artefakt, Projektphase, Feature) Aufschluss darüber geben, innerhalb welchen Projektkontexts die damit gekennzeichneten EntitäKontextinformationen ten bearbeitet wurden, sollen sie im Weiteren als Kontextinformationen bezeichnet werden. Elemente auf Prozessbzw. Instanzebene Dabei ist zu unterscheiden, ob die jeweiligen Entitäten nur auf Instanzebene oder auch auf Prozessebene existieren. Eine Projektentität auf Prozessebene ist beispielsweise die Aktivität „Entwicklung des Datenbank-Designs“. Diese Aktivität wird in jedem Softwareentwicklungsprozess vorkommen, bei dem eine neu zu implementierende Datenbankschicht benötigt wird. Dagegen gehört die Aktivität „Entwicklung des Relationenschemas für die Kundendaten der Fa. XYZ“ zu genau einem Softwareprojekt und damit zu einer bestimmten Prozessinstanz. Softwaremaße auf Prozessebene können zwischen verschiedenen Projekten verglichen werden. Beispielsweise kann auf diese Weise festgestellt werden, ob in einem beSoftwaremaße auf Prozessebene 89 4 Prozessintegration stimmten Projekt der Aufwand für das Datenbank-Design außerordentlich hoch ist. Und nur derartige Softwaremaße auf Prozessebene können, wie es innerhalb dieser Arbeit vorgesehen ist, ex ante definiert werden, um sie dann im laufenden Projekt automatisiert erheben zu können. Da umgekehrt vor dem konkreten Projektstart noch gar nicht bekannt ist, dass für die Kundendaten der Fa. XYZ ein eigenes Relationenschema entwickelt werden muss, können einerseits derartige Softwaremaße Betrachtung der projektübergreifenden Vergleichbarkeit auf Instanzebene nicht von vornherein festgelegt werden und andererseits ist auch keine projektübergreifende Vergleichbarkeit möglich. Es mag im Einzelfall tatsächlich sinnvoll sein, derartige Instanz-Softwaremaße zu bestimmen. Jedoch muss dies dann manuell und projektspezifisch erfolgen. Grundsätzlich lässt sich sagen, dass Softwaremaße auf Prozessebene eher für strategische Ziele und Softwaremaße auf Instanzebene eher für taktische und operative Strategische und taktische Ziele der Softwaremessung Ziele verwendet werden können. Wenn sich z. B. im aktuellen Projekt herausstellen sollte, dass der Design-Aufwand für das angegebene Relationenschema besonders hoch ist, so ist zu erwarten, dass auch die Implementierungsund Test-Aufwände für diesen Teil der Datenbank entsprechend umfangreich werden und dass dies bei der Personalplanung berücksichtigt werden muss. Dies sind operative Überlegungen, welche im Rahmen des aktuellen Projekts durchgeführt werden müssen. Umgekehrt können Softwaremaße auf Prozessebene strategisch eingesetzt werden, um Tendenzen im Verlauf mehrerer Softwareprojekte zu erkennen oder die eigene Prozessqualität bzw. -stabilität zu beurteilen. Da zu diesem Zweck die Maße automatisiert erhoben werden sollten, müssen die zu messenden Entitäten auch bedienerlos identifiziert werden können. In den folgenden Abschnitten soll daher gezeigt werden, wie auf Basis von •Aktivitäten, •Artefakt-Funktionalitäten und •Projektphasen eine projektübergreifende Grundstruktur für Softwareentwicklungsumgebungen definiert werden kann, deren Elemente auch auf der Prozessebene existieren. Im Abschnitt 4.2.4 werden die sogenannten Features als weitere Kontextinformation dargestellt. Diese können für die Fortschrittsmessung im Rahmen eines konkreten Projekts eingesetzt werden, existieren jedoch nicht auf Prozessebene. 4.2.1 Projektaktivitäten als Anknüpfungspunkte 4.2.1.1 Der Projektstrukturplan Die Projektaktivitäten werden üblicherweise mittels eines Projektstrukturplans (engl. Work Breakdown Structure) hierarchisch gegliedert (vgl. [Pro04], S. 112 ff.). Nach DIN 69901 (Projektmanagement, vgl. [DIN87]) beschreibt der Projektstrukturplan (PSP) die Gesamtheit der wesentlichen Beziehungen zwischen den Elementen eines Projektes. Durch ihn wird das Projekt hierarchisch in planbare und kontrollierbaTeilaufgaben re Teilaufgaben und Arbeitspakete strukturiert, wobei sich eine Baumstruktur mit Projektstrukturebenen wie in Abbildung 4.2 ergibt. 90 4.2 Anknüpfungspunkte für Softwaremaße Abbildung 4.2: Projektstrukturplan zur hierarchischen Gliederung eines Projekts Die Arbeitspakete stellen dabei nicht weiter untergliederte Teilaufgaben auf einer beliebigen Ebene des PSP dar. Dabei sollte jedes Arbeitspaket ein in sich geschlosArbeitspakete senes Ergebnis beinhalten. Weiter sollten der Zeitund Kostenaufwand für ein Arbeitspaket im Vergleich zum Gesamtprojekt so gering sein, dass eine wirkungsvolle Projektsteuerung vorgenommen werden kann (vgl. [SZ05], S. 433 ff.). Der Projektstrukturplan enthält alle Projektaktivitäten, die in den einzelnen Entwicklungsphasen durchzuführen sind, und bildet nach Burghardt [Bur02] das Fundament für die gesamte Projektund Produktplanung, insbesondere in Hinblick auf die Termin-, Kostenund Einsatzmittelplanung. Dabei werden drei Arten von Projektstrukturplänen unterschieden. Beim produktTypen von Projektstrukturplänen orientierten Projektstrukturplan richtet sich die Definition der Aufgabenpakete nach der technischen Struktur des zu entwickelnden Systems. In einem funktionsorientierten Projektstrukturplan werden die durchzuführenden Arbeitspakete nach den Tätigkeitsfunktionen wie Analyse, Programmierung oder Testen gegliedert. Beim ablauforientierten Projektstrukturplan schließlich werden die Arbeitspakete gemäß der Prozessphasen bestimmt und strukturiert. Die oberste Projektstrukturebene (Ebene 1 in Abbildung 4.2) eines derartigen Projektstrukturplans spiegelt damit die Prozessabschnitte des Vorgehensmodells wider (vgl. [Bur02], S. 143 f.). Der PSP stellt jedoch nur eine inhaltliche Gliederung der Projekttätigkeiten dar Abgrenzung des Projektstrukturplans vom Projektablaufplan und zeigt nicht die zeitliche Abfolge der Aktivitäten, wie dies beispielsweise in einem Gantt-Diagramm der Fall ist (vgl. [SZ05], S. 433 ff.). Er ist dafür in der Regel ausführlicher hierarchisch gegliedert, da er als Basis für das Controlling eingesetzt wird. Diesbezüglich ist der PSP auch viel stabiler als ein Projektablaufplan, da Änderungen in Bezug auf Termine, Ablaufreihenfolgen und Ressourcen keine Auswirkungen auf den PSP haben. Üblicherweise werden die Projektablaufpläne (Netzpläne, Gantt-Diagramme) auf der Grundlage des Projektstrukturplanes unter Verwendung der Netzplantechnik entwickelt. Dabei wird zunächst ermittelt, welche Abhängigkeiten zwischen den Arbeitspaketen bestehen und welche Vorgänge parallel, nacheinander oder unabhängig voneinander ablaufen können. Zusammen mit Informationen über die für die Arbeitspakete benötigten Ressourcen und evtl. vorgegebene Fristen und Termine wird aus diesen Informationen rechnerisch ein entsprechender Netzplan entwickelt 91 4 Prozessintegration sungen des Zeitplans entschieden. Somit ist es auch sinnvoll, den in den einzelnen Projektphasen erbrachten Aufwand auswerten zu können. Hierzu muss die Angabe der jeweiligen Phase als KontextinProjektphasen als Kontextinformation formation bei der Zeiterfassung mit aufgenommen werden. Als Kontextinformation nur bedingt geeignet ist jedoch die Iteration, innerhalb derer Tätigkeiten erbracht oder bestimmte Artefakte erzeugt wurden. Die Anzahl und Iterationen als Kontextinformation Inhalte der Iterationen werden erst kurzfristig im Laufe der Projektdurchführung geplant. Daher sind Vergleiche bezüglich der Arbeitsaufwände, welche in einzelnen Iterationen erbracht wurden, zwischen zwei Projekten nicht sinnvoll. Dagegen kann innerhalb eines Projekts die Untersuchung der Aufwandsverteilung auf die einzelnen Iterationen durchaus Aufschluss über die Güte der Iterationsplan geben. Innerhalb des V-Modell XT werden dagegen auf Prozessebene keine definierten Projektphasen beschrieben.3Dies mag an der allgemeineren Ausrichtung dieses VorKeine vordefinierten Projektphasen beim V-Modell XT gehensmodells liegen, welches nicht nur für die Durchführung von Softwareentwicklungsprojekten, sondern als allgemeines Vorgehensmodell für eine Vielzahl verschiedenartiger Systementwicklungsprojekte (z. B. auch Hardwareentwicklung) konzipiert ist. Daher gibt es auf der Prozessebene auch keine definierten Projektmeilensteine, sondern die projektspezifischen Meilensteine werden erst im Rahmen der Projektdurchführungsplanung bestimmt (vgl. [BMI06], S. 419). Es gibt zwar sogenannte Projektdurchführungsstrategien, welche eine Reihenfolge festlegen, in der die für das Projekt relevanten Entscheidungspunkte durchlaufen Projektdurchführungsstrategien beim V-Modell XT werden müssen (vgl. [BMI06], S. 603). Diese Entscheidungspunkte regeln jedoch im Wesentlichen nur rechtliche Aspekte, wie die Genehmigung, Ausschreibung, Beauftragung und die Abnahme eines Projektes, und sind nicht zur Kontrolle des Verlaufs der Projektaktivitäten gedacht. Ungeachtet dieser Ausführungen steht es den einzelnen Organisationen, welche das V-Modell XT verwenden, natürlich frei, selbst obligatorische Projektphasen mit entsprechenden Projektmeilensteinen zu definieren. Dies erscheint insbesondere dann sinnvoll, wenn regelmäßig gleichartige Entwicklungsprojekte durchgeführt werden sollen. 4.2.4 Features als Anknüpfungspunkte 4.2.4.1 Feature-Driven Development Neben den Artefakt-Funktionalitäten können auch sogenannte Features als Kontextinformationen für die Anknüpfung von Softwaremaßen verwendet werden. Diese Möglichkeit und die Abgrenzung der Features von den Artefakt-Funktionalitäten soll anhand des Feature-Driven Developments (FDD) dargestellt werden. Dabei handelt es sich um ein iteratives Vorgehensmodell für Softwareentwicklungsprojekte, welches zu den agilen Entwicklungsmethoden gezählt wird. Die Methode wurde zum ersten 3Das V-Modell XT definiert vier Systemlebenszyklusausschnitte (Entwicklung, Wartung und Pflege, Weiterentwicklung und Migration). Diese beziehen sich jedoch auf den gesamten Lebenszyklus des zu entwickelnden Systems und nicht auf das Entwicklungsprojekt (vgl. [BMI06], S. 80). 98 4.2 Anknüpfungspunkte für Softwaremaße Mal von De Luca in [CLD99] veröffentlicht. Eine ausführlichere Beschreibung findet sich in [PF02].4Oestereich und Weiß verwenden in [OW08] zwar ebenfalls Features zur Projektgliederung, betonen jedoch, dass ihr Ansatz sich deutlich von demjenigen De Lucas unterscheide. Das FDD basiert auf acht sogenannten Best Practices, wobei eine dieser Praktiken Feature als kundenwertige Funktionalität als Developing by Feature bezeichnet wird. Ein Feature ist dabei eine Funktionalität, welche für den Kunden einen unmittelbaren Wert hat und in maximal zwei Wochen implementiert werden kann. Dabei wird, wie bei vielen anderen Vorgehensmodellen auch, die Gesamtfunktionalität des zu entwickelnden Systems mittels funktionaler Zerlegung in handlichere Teilprobleme zerlegt. In [PF02] wird jedoch als Problem vieler durch funktionale Anforderungen gesteuerter Entwicklungsprozesse dargestellt, dass bei den dort verwenProbleme aufgrund funktionaler Zerlegung deten funktionalen Bausteinen (z. B. Use Cases,User Stories, Datenfluss-Diagramme usw.) sehr oft die Geschäftslogik mit Aspekten der Benutzerschnittstelle, der Datenhaltung und der Netzwerkkommunikation vermischt werden würde. Wenn derartige Zusammenstellungen funktionaler Anforderungen zu Arbeitspaketen geschnürt und an die Entwickler übergeben werden, resultiere dies oft darin, dass die Entwickler einen großen Teil der Zeit mit der Implementierung von technischen Funktionalitäten, wie der Implementierung von Enterprise Java Beans oder der Definition des O/R-Mappings, verbrächten und somit die eigentlichen Geschäftsanwendungsfunktionalitäten vernachlässigten. Daher wird beim FDD die Liste der funktionalen Anforderungen auf solche mit einem Wert für den Anwender oder den Kunden beschränkt. Zusätzlich werden die Anforderungen so formuliert, dass sie vom Anwender bzw. vom Kunden verstanden werden können. Derartige funktionale Anforderungen werden beim FDD als kundenwertige Features bezeichnet und dienen zur Steuerung und Nachverfolgung des Projektfortschrittes. Dies bedeutet z. B. auch, dass die Entwicklung von InfrastrukImplementierung des technischen Unterbaus zählt nicht zum Projektfortschritt turkomponenten (z. B. einer O/R-Mapping-Komponente) nicht mit zum Projektfortschritt zählt, da sie keinen unmittelbaren Beitrag zu den Geschäftsanwendungsfunktionalitäten liefern und somit für den Kunden nicht relevant sind. Gegenüber dem Kunden wird der Projektfortschritt somit nur in Form von implementierten Features dokumentiert, welche dieser verstehen und bewerten kann. Dabei kann der Kunde einzelne Features in Bezug auf ihre Wichtigkeit für die Geschäftsanwendungsfunktionalität auch priorisieren. 4.2.4.2 Eigenschaften von Features Features werden beim FDD grundsätzlich in der Form <Aktivität> <Arbeitsergebnis> <Objekt> formuliert, wobei in die jeweiligen Formulierungen noch geeignete Artikel und Präpositionen eingefügt werden, um vollständige Sätze zu erhalten. Hierbei kann das 4Da das Feature-Driven Development als Vorgehensmodell relativ unbekannt ist, wird es – im Gegensatz zum V-Modell XT und zum RUP – im Hauptteil dieser Arbeit vorgestellt. 99 4 Prozessintegration Objekt eine Person, ein Ort oder eine Sache sein. Beispiel 7 (Features) • Berechne die Gesamtsumme des Verkaufs. • Ermittle das Guthaben des Bankkontos. • Autorisiere eine Kreditkartentransaktion des Karteninhabers. Features sollen so klein sein, dass sie innerhalb von zwei Wochen implementiert werden können, wobei eine Implementierungsdauer von zwei Wochen als obere Grenze Features sind feingranular gesehen wird. Funktionalitäten, die nicht innerhalb dieses Zeitraumes implementiert werden können, müssen soweit zerlegt werden, dass die so erhaltenen TeilFunktionalitäten jeweils klein genug sind, um die Feature-Eigenschaften zu erfüllen. Es gibt auch Features, welche innerhalb weniger Stunden oder Tage implementiert werden können. Allerdings muss durch ein Feature mehr implementiert werden als z. B. nur die Accessor-Methoden einer Java-Bean. Sowohl obige Beispiele als auch die genannte Granularität, welche für Features gelten soll, machen deutlich, dass ein Feature eine Bedeutung innerhalb der Geschäftsprozesse des Kunden und damit einen Wert für den Kunden haben muss. Ein Feature korrespondiert üblicherweise mit einem Ablaufschritt innerhalb eines Geschäftsprozesses und hat somit eine unmittelbare Bedeutung für den Kunden. Somit haben die Features des FDD eine große Ähnlichkeit zu den beim eXtreme Programming (XP, [Bec04]) verwendeten User Stories. In [BF01] wird die User Story Features vs. XP User Stories als „a chunk of functionality that is of value to the customer“ (siehe [BF01], S. 45) beschrieben. Auch wird hier die User Story als Einheit der Funktionalität bezeichnet, mit der der Fortschritt demonstriert wird, indem getesteter und integrierter Code ausgeliefert wird, der eine User Story implementiert. Der Hauptunterschied zwischen einem FDD Feature und einer XP User Story besteht jedoch darin, dass Features grundsätzlich in der oben angegebenen Form formuliert werden. Zusätzlich werden Features strenger verwaltet als dies bei den User Stories des XP üblich ist, da sie hierarchisch organisiert werden. Features, welche zueinander in Beziehung stehen, werden zu Feature-Sets und diese wiederum zu Major-Feature-Sets zusammengefasst (vgl. [CLD99]). Auch mit den Use Cases des Rational Unified Process haben die FDD Features eine gewisse Ähnlichkeit. Use Cases wurden von Jacobson bereits im Jahr 1992 als Features vs. Use Cases „a description of a set of sequence of actions, including variants, that a system performs that yields an observable result to a particular actor“ (siehe [Jac92]) beschrieben, wobei auch bei dieser Definition betont wird, dass der Use Case (ähnlich dem Feature) ein signifikantes Ergebnis für den Kunden liefert. Laut [PF02] unterscheiden sich die Use Cases von Features dadurch, dass es für die Modellierung von Use Cases keine Empfehlungen gebe, mit welcher Granularität Use Cases modelliert werden sollen und in welchem Format und welcher Detailliertheit sie notiert werden sollen. Im Ergebnis würden Use Case Sammlungen oft 100 4.2 Anknüpfungspunkte für Softwaremaße inkonsistent und unvollständig sein und die einzelnen Use Cases hätten unterschiedliche Granularitätsund Detaillierungsgrade. Zusätzlich würden dabei oft Details der Benutzerschnittstelle und der Persistenz-Funktionalität mit der Geschäftslogik vermischt werden. Aber auch im Ablauf des Softwareentwicklungsprozesses gibt es Unterschiede. So ist der RUP als „use case driven“ beschrieben, d.h. die Ermittlung der funktionalen Anforderungen in einem auf dem RUP basierenden Softwareentwicklungsprozess erfolgt durch die Modellierung von Use Cases. Aus den Use Cases werden dann Aktivitätsund Klassendiagramme abgeleitet. Beim FDD dagegen beginnt die Softwareentwicklung mit der Modellierung eines Domain Object Models (siehe folgender Abschnitt), mit dessen Hilfe im nächsten Schritt die Feature-Liste erarbeitet wird. 4.2.4.3 Die FDD-Aktivitäten Beim FDD werden im Rahmen des Softwareentwicklungsprozesses die folgenden fünf Aktivitäten (FDD Processes, vgl. Abbildung 4.3) ausgeführt (vgl. [CLD99]): 1. Develop an Overall Model Innerhalb dieser Aktivität wird ein sogenanntes Domain Object Model erstellt. Dabei handelt es sich im Wesentlichen um eine Sammlung von UML-KlassenDomain Object Model diagrammen, welche die Beziehungen der Business-Objekte der zu entwickelnden Anwendung beschreiben. Die Klassendiagramme können um bereits identifizierte Attribute und Methoden ergänzt werden. Zusätzlich kann die Funktionalität der Methoden mittels Sequenz-Diagrammen verdeutlicht werden. 2. Build a Features List Das im ersten Schritt erworbene Wissen über die Anwendung wird nun verwendet, um die Feature-Liste zu erstellen. Dazu wird die Anwendungsdomäne in Sachgebiete (z. B. Kundenverwaltung, Versand, Fakturierung) zerlegt, welche verschiedene Geschäftsaktivitäten umfassen. Die einzelnen Schritte der Geschäftsaktivitäten wiederum liefern die entsprechend kategorisierten FeatureListen. 3. Plan by Feature Während dieser Aktivität wird die Reihenfolge, in der die Features implementiert werden sollen, festgelegt. Kriterien für die Planung sind Abhängigkeiten zwischen den Features, Auslastung der einzelnen Entwicklungsteams und die Komplexität der einzelnen Features. Die einzelnen Features werden dabei zu Feature-Sets Feature-Sets und diese wiederum zu Major-Feature-Sets zusammengefasst. Dabei werden jeweils Fertigstellungstermine geschätzt. 4. Design by Feature Diese Aktivität beginnt mit einem sogenannten Domain Walkthrough, bei dem innerhalb des Domain Object Models diejenigen Klassen identifiziert werden, welche mit den aktuell zu implementierenden Features verknüpft sind. Für die 101 4 Prozessintegration einzelnen Features oder auch für mehrere zu einem Feature-Set zusammenÜberarbeiten der Klassendiagramme und Erzeugen von Sequenzdiagrammen gefasste Features werden detaillierte Sequenz-Diagramme entwickelt. Dabei wird auch das Domain Object Model überarbeitet und die betroffenen Klassendiagramme detailliert ausgearbeitet. Anschließend wird eine Inspektion des erarbeiteten Designs durchgeführt. Das Ergebnis dieser Tätigkeiten wird als Design-Paket bezeichnet. 5. Build by Feature Gemäß des in der vorhergehenden Aktivität entwickelten Designs wird ein kundenwertiges Feature implementiert. Die dabei erstellte Software wird einer Eigentliche Implementierung Code-Inspektion unterzogen und mittels Unit-Tests überprüft. Abschließend wird der Code im Versionsverwaltungssystem als „freigegeben“ gekennzeichnet (Promote to Build). Abbildung 4.3: Aktivitäten beim Feature-Driven Development Die ersten drei Aktivitäten werden einmalig nacheinander abgearbeitet und liefern ein Objekt-Modell der Anwendungsdomäne, eine Liste der zu implementierenden Features und einen Implementierungszeitplan mit Verantwortlichkeiten. Die letzten beiden Aktivitäten werden dann iterativ für jedes einzelne Feature durchgeführt Iterative Abarbeitung der Feature-Listen (vgl. Abbildung 4.3). 4.2.4.4 Fortschrittsmessung Da der Großteil des Projektaufwandes (laut [CLD99] mehr als 75 %) auf die Bearbeitung der Aktivitäten Design by Feature und Build by Feature entfällt, kann durch die Ermittlung des Abarbeitungsgrades der Featureliste eine Fortschrittsmessung implementiert werden. Dazu wird in [CLD99] und [PF02] vorgeschlagen, für jedes Feature sechs Meilensteine zu definieren, welche bei der seriellen Abarbeitung der Meilensteine bei der FeatureImplementierung Aktivitäten Design by Feature und Build by Feature für jedes Feature durchlaufen werden (siehe Tabelle 4.1). Die Meilensteine sind durch sechs Aufgaben definiert, welche während der beiden Aktivitäten ausgeführt werden sollen. Ein Meilenstein soll jeweils dann als abgeschlossen betrachtet werden, wenn die jeweilige Aufgabe vollständig erledigt ist. Zusätzlich können die sechs Meilensteine auch bzgl. des Aufwandes gewichtet werden. In [CLD99] werden dazu als erste Näherung die in Tabelle 4.1 aufgeführen anteiligen Aufwände vorgeschlagen. Damit wäre z. B. ein Feature zu 1 % + 40 % + 3 % = 44 % fertig, wenn die drei Aufgaben der Aktivität Design by Feature vollständig abgeschlossen sind. 102 4.2 Anknüpfungspunkte für Softwaremaße Design by Feature Build by Feature Domain Walkthrough Design Design Inspection Code Code Inspection Promote to Build 1% 40% 3% 45% 10% 1% Tabelle 4.1: Die sechs Meilensteine beim FDD mit beispielhaften anteiligen Aufwänden In [PF02] wird betont, dass nur diejenigen Meilensteine bei der Messung berücksichtigt werden sollen, welche bereits erreicht sind, d. h. bei denen die zugehörige Aufgabe vollständig abgeschlossen ist. In Arbeit befindliche Aufgaben werden nicht mitgezählt, so dass z. B. ein Feature mit einer nur zur Hälfte vollendeten DesignAufgabe nach wie vor als nur zu 1 % fertig gilt. Dadurch sollen zu optimistisch geschätzte Fertigstellungsgrade vermieden werden. Der Fehler, den man bei dieser Vorsichtige Schätzung des Fertigstellungsgrades Vorgehensweise bei der Berechnung des Gesamtprojektfortschritts begeht, ist nach [PF02] recht klein, da die einzelnen Features von kleiner Granularität sind und maximal einen Zeitraum von zwei Wochen umfassen. Allerdings müssen im Laufe mehrerer Projekte erst Erfahrungswerte bzgl. der anteiligen Gewichtung der Aufwände für die einzelnen Meilensteine gewonnen werden, da die in Tabelle 4.1 genannten Werte nur ein Vorschlag und diese Gewichtungsfaktoren für die einzelnen Meilensteine nach einigen Projekten anzupassen sind. Mit der Zerlegung in Meilensteine kann zunächst für jedes Feature aus der FeatureListe der Fertigstellungsgrad ermittelt werden. Anschließend kann durch Aggregation der Fertigstellungsgrad für die einzelnen Feature-Sets und schließlich für das Gesamtprojekt ermittelt werden. Zusätzlich kann die Anzahl der noch nicht begonnenen, der bereits in Arbeit befindlichen und der fertig gestellten Features ermittelt werden. Diese Feature-Zahlen können wiederum in Relation zu den einzelnen Feature-Sets, und damit zu den zu implementierenden Geschäftsaktivitäten, oder Major-Feature-Sets, welche den einzelnen Sachgebieten der Anwendungsdomäne entsprechen, gestellt werden. In [CLD99] und [PF02] wird dazu eine tabellenartige graGraphische Darstellung des Fertigstellungsgrades phische Darstellung des Fertigstellungsgrades von Feature-Sets vorgeschlagen (vgl. Abbildung 4.4). 4.2.4.5 Anknüpfungsmöglichkeiten für Softwaremaße Die erleichterte Fortschrittsmessung war eine Motivation für die Entwicklung des Feature-Driven Development (vgl. [CLD99]). Basierend auf den Features, den Feature-Sets und evtl. den Major-Feature-Sets wurde eine Möglichkeit dargestellt, den aktuellen Projektfortschritt einzuschätzen und diesen Projektstatus auch dem Kunden zu vermitteln und zu begründen. Dazu müssen die Features und Informationen über den Abarbeitungsgrad der einzelnen Features von den Projektbeteiligten gepflegt werden. Darüber hinaus sind Features auch Kontextinformationen und kommen somit als Anknüpfungspunkte für Softwaremaße in Betracht, da Aktivitäten wie der DomainWalkthrough oder Design-Tätigkeiten im Kontext eines Features durchgeführt wer103 4 Prozessintegration Abbildung 4.4: Graphische Darstellung des Fertigstellungsgrades eines Feature-Sets (vgl. [PF02], S. 85) den. Allerdings eignen sich die Features weniger gut für die Erhebung projektüberFeatures sind projektspezifisch greifender, vergleichender Softwaremaße, da Features projektspezifisch sind. Features können bezüglich ihrer Eigenschaft als Projekt-Strukturierungselemente mit den Arbeitspaketen eines Projektstrukturplans (vgl. Abschnitt 4.2.1.1) verglichen werden. Ähnlich wie die Arbeitspakete sind die Features von einer bestimmten Projektinstanz abhängig. Aber im Gegensatz zu den Teilaufgaben, welche als Vaterelemente der Arbeitspakete bei einem funktionsorientierten PSP projektübergreifend gültig sein können (Standard-PSP), sind beim FDD auch die Feature-Sets und Major-Feature-Sets vom jeweiligen Projekt abhängig, da diese sich an den betrieblichen Funktionalitätsanforderungen der zu erstellenden Software orientieren. Die dynamische oder zeitliche Projektstruktur beim FDD ist, wie in Abbildung 4.3 Phasenbezogene Aufwandsermittlung dargestellt, durch die Abfolge der Phasen •Develop an Overall Model, •Build a Features List, •Plan by Feature und der •Feature-Implementierungsphase gegeben. An diesen Phasen lassen sich zumindest Arbeitszeitmaße anknüpfen, welche evtl. noch durch Division mit der Gesamt-Feature-Anzahl normiert werden können. Dadurch ist es beispielsweise möglich, die Aufwände für die einzelnen Phasen projektübergreifend zu vergleichen oder über die Aufwände für die ersten Phasen mittels Hochrechnung den Gesamtprojektaufwand abzuschätzen. Als statische Strukturelemente können beim FDD die Aktivitäten der ersten drei Aktivitätsbezogene Aufwandsermittlung Phasen und zusätzlich die in Tabelle 4.1 dargestellten und pro Feature durchzuführenden Aufgaben betrachtet werden. Auch diese sind grundsätzlich als Anknüpfungspunkte für Softwaremaße geeignet. Hier dürfte jedoch weniger im Vordergrund stehen, einzelne Aktivitäten bzw. Aufgaben wie beispielsweise die Designaufwände zwischen zwei Projekten vergleichen zu wollen. Stattdessen kann mittels einer an die104 4.3 Praktische Anwendung der Anknüpfungspunkte sen Implementierungs-Aufgaben angeknüpften Aufwandsermittlung die tatsächliche Aufwandsverteilung (vgl. Tabelle 4.1) bei der Feature-Implementierung für die jeweilige Organisation ermittelt werden, welche wiederum bei der Fortschrittsmessung innerhalb zukünftiger Projekte von Bedeutung ist. 4.3 Praktische Anwendung der Anknüpfungspunkte Im letzten Abschnitt wurden vier Typen von Anknüpfungspunkten für Softwaremaße vorgestellt: •Aktivitäten •Artefakt-Funktionalitäten •Projektphasen •FDD-Features Die ersten drei Typen von Anknüpfungspunkten unterscheiden sich von den FDDFeatures dahingehend, dass sie bereits auf Prozessebene existieren. Softwaremaße, Anknüpfungspunkte auf Prozessbzw. Instanz-Ebene welche sich auf die genannten Kontextinformationen beziehen, können unabhängig von einem konkreten Projekt definiert und damit projektübergreifend verwendet werden. Dies trifft für die FDD-Features nicht zu, da Features konzeptionsbedingt erst zur Laufzeit eines Projektes festgelegt werden können. Der große Vorteil des FeatureKonzepts liegt jedoch darin, dass durch die Überwachung der bereits implementierten Features eine effektive Messung des Projektfortschrittes erfolgen kann. Mit den ersten drei Typen von Anknüpfungspunkten ist dagegen eine Fortschrittsmessung nicht möglich, da diese konkrete und projektspezifische Kontextinformationen benötigt. Die Aktivitätsanknüpfungspunkte ermöglichen insbesondere eine Berechnung der Aufwände, welche für einzelne Aktivitätsarten eines Softwareentwicklungsprojektes Aktivitäts-orientierte Aufwandsermittlung erbracht werden. Dies erleichtert die Beurteilung der Wirksamkeit von Prozessverbesserungsmaßnahmen dahingehend, dass geprüft werden kann, ob sich die (normierten) Aufwände für bestimmte Tätigkeiten tatsächlich ändern, nachdem Modifikationen im Prozess (z. B. die Einführung von Peer-Reviews) durchgeführt wurden. Die Verwendung von Artefakt-Funktionalitäten als Anknüpfungspunkte ermöglicht zunächst eine Beurteilung der Umfänge einzelner Software-Komponenten des Funktionalitätsorientierte Umfangsund Aufwandsermittlung zu entwickelnden Systems und der dafür erbrachten Aufwände. Dadurch erhält eine Organisation die Möglichkeit, langfristig eine Erfahrungsdatenbank aufzubauen (vgl. [BCR94]), um damit die Aufwände künftiger Projekte besser abschätzen zu können (siehe auch Abschnitt 6.2.2). Die Berechnung von Softwaremaßen in Bezug auf einzelne Phasen des Projekts ermöglicht eine Hochrechnung von den in den bereits abgeschlossenen Projektphasen erbrachten Aufwänden auf die für das Gesamtprojekt noch zu erbringenden Aufwände. 105 4 Prozessintegration In Abhängigkeit von den Zielen der Softwaremessung wird man daher eine Kombination der verschiedenen Anknüpfungspunkte einsetzen. 4.3.1 Agile Softwareentwicklung Im Bereich der Agilen Softwareentwicklung gibt es weder hierarchisch strukturierte Aktivitätsbeschreibungen noch sind bestimmte Workflows von vornherein festgelegt (vgl. [Bec04], [Coc01]). Die verschiedenen Vorgehensweisen der Agilen Softwareentwicklung werden stattdessen in Bezug auf anzuwendende Techniken zur Softwareentwicklung und den zugrunde liegenden Prinzipien beschrieben (vgl. [BT05]). Dennoch lässt sich auch für agile Softwareentwicklungsprojekte ein StandardProjektstrukturplan gemäß Abschnitt 4.2.1.1 angeben (vgl. [DHW06b]). Dieser besteht nur aus einer Ebene und enthält die Aktivitäten Agile Aktivitäten •Analyse, •Modellierung, •Implementierung, •Test, •Inbetriebnahme (Deployment), •Konfigurations-Management und •Projektmanagement, die normalerweise innerhalb jedes Softwareentwicklungsprojektes durchgeführt werden müssen. Der Einfachheit halber werden die genannten Tätigkeiten an dieser Stelle als Aktivitäten bezeichnet, auch wenn diese im Rahmen einzelner Vorgehensmodelle auch als Aktivitätsgruppen oder Disziplinen bezeichnet werden. Als zweiter Anknüpfungstyp können die im Abschnitt 4.2.2 dargestellten ArtefaktFunktionalitäten verwendet werden. Somit kann die zweite Dimension der KontextArtefaktFunktionalitäten informationen durch die Funktionsbeschreibungen •Anwendungslogik, •Präsentationsschicht, •Datenhaltung, •Transaktionsverwaltung und •Benutzerund Berechtigungsverwaltung definiert werden. Damit können die zu messenden Entitäten des Softwareentwicklungsprozesses mit zweidimensionalen Kontextinformationen gekennzeichnet werden, wie sie in Tabelle 4.2 als 2-Tupel aufgelistet sind. Um im Rahmen der agilen Softwareentwicklung keinen als unnötig groß empfundenen Mehraufwand zu fordern, kann man sich darauf beschränken, mit diesen Kontextinformationen nur •die Commit-Informationen im Versionsverwaltungssystem und •die Zeitbuchungen im Zeiterfassungssystem zu kennzeichnen. Damit kann nachträglich ermittelt werden, bei welcher Aktivität einzelne Artefakte entstanden sind oder verändert wurden oder für welche Komponenten und während welcher Tätigkeiten die einzelnen Zeitaufwände erbracht wurden (vgl. [DHW06b]). 106 4.3 Praktische Anwendung der Anknüpfungspunkte Analysis Modeling Implementation Test Deployment Config. Mgmt. Project Mgmt. Application Logic (1,1) (2,1) (3,1) (4,1) (5,1) (6,∗) (7,∗) Presentation (1,2) (2,2) (3,2) (4,2) (5,2) (6,∗) (7,∗) Data Management (1,3) (2,3) (3,3) (4,3) (5,3) (6,∗) (7,∗) Transaction Mgmt. (1,4) (2,4) (3,4) (4,4) (5,4) (6,∗) (7,∗) AuthN/AuthZ (1,5) (2,5) (3,5) (4,5) (5,5) (6,∗) (7,∗) Tabelle 4.2: 2-Tupel als Kontextinformationen einer generischen Projektstruktur Diese Vorgehensweise ist jedoch nicht auf die „klassischen“ agilen Softwareentwicklungsprozesse wie das eXtreme Programming [Bec04] beschränkt. Auch auf den RUP, der auch „agil“ durchgeführt werden kann (vgl. [HRS04]), kann dieses Verfahren angewendet werden. Die genannten Aktivitäten entsprechen inhaltlich den Disziplinen des RUP. Bei diesen können jedoch zusätzlich die Disziplinen (CoreWorkflows) feiner in Workflow-Details gegliedert werden (siehe Abschnitt 4.2.1.3, S. 95). Je nach Arbeitsweise und Art der Aufgabenzuordnung an die Projektbeteiligten innerhalb der betrachteten Organisation können somit Softwaremaße an den eher grobgranularen Disziplinen oder an den feingranulareren Workflow-Details angeknüpft werden. Im letzten Fall können die so gewonnenen Softwaremaße immer noch auf die Ebene der Disziplinen aggregiert werden, da jedes Workflow-Detail genau einer Disziplin zugeordnet ist. 4.3.2 Multi-Dimensionale Kontextinformationen Letztendlich ermöglicht dieser Ansatz, die zu messenden Entitäten mit mehrdimensionalen Kontextinformationen zu versehen. Dabei muss innerhalb der Organisation festgelegt werden, welche Kontextinformationen von den Projektbeteiligten jeweils zu pflegen sind. Die dabei zur Verfügung stehenden Möglichkeiten sollen am Beispiel der ZeitBeispiel Zeiterfassung erfassungsdatensätze dargestellt werden. Wie im vorhergehenden Abschnitt gezeigt wurde, bietet die Ergänzung von Zeiterfassungsdaten mit den Kontextinformationen Aktivität und Artefakt-Funktionalität eine brauchbare Grundlage für spätere Auswertungen. Die jeweilige Projektphase braucht bei den einzelnen Zeiterfassungsvorgängen nicht mit angegeben werden, da diese aus dem Datum der Zeiterfassung ermittelt werden kann. Damit ist zusätzlich eine Auswertung der Aufwände nach Projektphasen möglich. 107 4 Prozessintegration der Plan automatisch erstellt und bei Änderungen auf Basis der in den WorkItems gespeicherten Informationen (z. B. Priorität, Dringlichkeit und Abhängigkeiten) einem Update unterzogen werden. Live Dashboard: Im Governance-Level soll schließlich ein Live Dashboard zur Steuerung aller Projektaktivitäten in Echtzeit zur Verfügung stehen. 4.4.2 Beurteilung des Live-Ansatzes Eine Hauptintention des Live-Ansatzes ist die Darstellung eines Regelwerkes, mit dem Softwareentwicklungsumgebungen hinsichtlich ihrer Eignung für die agile Softwareentwicklung eingeschätzt werden können. Diese Beurteilung stützt sich jedoch im Wesentlichen darauf, wie Informationen innerhalb der Softwareprojekte verwaltet und zugänglich gemacht werden. Andere Kriterien, wie beispielsweise die technischen Funktionalitäten der Entwicklungsumgebungen, werden bei diesem Ansatz gar nicht betrachtet. Stattdessen wird darauf hingewiesen, dass das Werkzeug Polarion Development Productivity Platform der Firma Polarion Software5den Live-Level 5 erfüllen würde (vgl. [Riz06]). Auch erscheinen die Kriterien für die Einhaltung der Live-Richtlinien überarbeitungsbedürftig. So wird für den Control-Level verlangt, dass die Work-Items mit Informationen zu Kosten, Zeit und weiteren Attributen versehen werden. Dies würde Widersprüche innerhalb der Live-Richtlinien jedoch teilweise der Single-Source-Richtlinie widersprechen, nach der alle Informationen in der Entwicklungsumgebung nur einmal vorkommen dürfen. Da Zeiterfassungsbelege und Kostenschätzungen ebenfalls als Projektinformationen und somit als Work-Items betrachtet werden müssen, dürfen die Artefakt-Work-Items (z. B. ein Stück Quelltext) nur einen Verweis auf die zugehörigen Controlling-Work-Items haben. In der Praxis ließe sich diese Verbindung beispielsweise dadurch herstellen, dass bei der Zeiterfassung in den jeweiligen Datensätzen das bearbeitete Work-Item bzw. die zugehörige Work-Item-Gruppe mit abgespeichert wird, wie dies auch im Abschnitt 4.1 gefordert wird. Wenn man jedoch den Live-Ansatz nicht als Beurteilungsregelwerk für Softwareentwicklungswerkzeuge, sondern als Reifegradmodell für die Auswertbarkeit von ProLive-Ansatz als Reifegradmodell für die Softwaremessung jektinformationen betrachtet, so kann damit die Integrationsmöglichkeit der Softwaremessung in eine bestimmte Entwicklungsumgebung beurteilt werden. Insbesondere kann mit dem Live-Ansatz beurteilt werden, wie gut eine Entwicklungsumgebung die Ermittlung und Bereitstellung von auf Managementebene relevanten Softwaremaßen unterstützt. •Wenn auf dem Live Foundation-Level die Richtlinien „Einziger Vorfahre“ und „Single-Source“ erfüllt sind, so ist es zunächst einmal möglich, bei der Zeiterfassung, innerhalb der Versionsverwaltung und beim Issue-Tracking einheitliche und eindeutige Verweise auf die betroffenen Work-Items als Kontextinformationen anzugeben. Somit kann festgestellt werden, welcher Zeitaufwand bei5http://www.polarion.com 114 4.5 Zusammenfassung spielsweise mit der Implementierung einer bestimmten Komponente verbunden war. •Durch Links miteinander verbundene Work-Items, wie sie auf dem ConnectionLevel gefordert werden, ermöglichen Traceabilityund Impact-Analysen. Zusätzlich könnte dabei beispielsweise aus der Controlling-Perspektive ermittelt werden, welche Mehrkosten durch einen Änderungswunsch entstanden sind. •Und schließlich ermöglicht es das im Fusion-Level geforderte „Single Repository“ zusammen mit der Versionierung aller Work-Items, nachträglich die Entwicklung und insbesondere die Verschiebung von Aufwandsschwerpunkten zu analysieren. 4.5 Zusammenfassung Zu Beginn dieses Kapitels wurde dargelegt, was im Rahmen dieser Arbeit unter Controlling-gerechter Softwaremessung verstanden werden soll. Hierbei geht es zuKernattribute nächst um die Erhebung der im Abschnitt 2.3 als Kernattribute bezeichneten Messgrößen wie Umfang oder Aufwand. Zusätzlich ist entscheidend, dass diese Maße zusammen mit ihrem Kontext betrachtet werden müssen. Es sind daher Maße wie der Aufwand für eine bestimmte Softwarekomponente oder die Änderung der Fehlerrate nach der Einführung von Peer-Reviews von Interesse. Ein wichtiges Ziel dieser Arbeit ist, eine Möglichkeit darzustellen, die in der jeweiligen Organisation als relevant erkannten Softwaremaße konsistent und einheitlich zu erheben. Dies beinhaltet insbesondere, dass die jeweiligen Softwaremaße grundKonsistente Softwaremessung sätzlich für jedes durchzuführende Projekt ermittelt werden sollen, um bestimmte Aspekte der einzelnen Projekte zu vergleichen. Da es möglich sein soll, diese Maße unabhängig von einem konkreten Projekt zu definieren, müssen sie sich auf Messgrößen beziehen, die bereits auf der Ebene des Softwareprozesses existieren. Im Abschnitt 4.2 wurden daher Möglichkeiten dargestellt, den Softwareentwicklungsprozess zu gliedern und zu strukturieren und ihn letztendlich auf eine generiAnknüpfungspunkte sche Grundstruktur zurückzuführen. Die Elemente dieser Grundstruktur können als Anknüpfungspunkte für die Softwaremaße verwendet werden, wodurch diese projektunabhängig definiert werden können. Im weiteren Verlauf des Kapitels wurde dann die Verwendung von •Aktivitäten, •Artefakt-Funktionalitäten und •Projektphasen als Anknüpfungspunkte für Softwaremaße erläutert. Dabei wurde insbesondere auf die Anwendbarkeit dieses Ansatzes im Rahmen verschiedener Vorgehensmodelle wie dem V-Modell XT, dem Rational Unified Process oder dem eXtreme Programming eingegangen. Als Nachteil der ausschließlichen Betrachtung von bereits auf Prozessebene existierenden Messgrößen wurde die Schwierigkeit dargestellt, auf diese Weise den Pro115 4 Prozessintegration jektfortschritt zu bestimmen. Deshalb wurde mit dem Feature-Driven Development Fortschrittsmessung ein vielversprechender Ansatz vorgestellt, der es einerseits erlaubt, ein Projekt übersichtlich und in kundenverständlicher Form zu gliedern, und andererseits mittels der Features und Feature-Sets dem Projekt eine Strukur einbeschreibt, welche für die Fortschrittsmessung unmittelbar zugänglich ist. Es wurde im weiteren Verlauf dargestellt, dass es aus der Sicht des ProjektControllings optimal wäre, die Anknüpfung von Softwaremaßen an Elemente der Prozessstruktur mit der Fortschrittsmessung durch Bestimmung des Abarbeitungsgrades der einzelnen Features bzw. Feature-Sets zu kombinieren. Dadurch werden für die Softwaremessung letztendlich multidimensionale Kontextinformationen eingesetzt. Zum Abschluss des Kapitels wurde der sogenannte Live-Ansatz betrachtet. Dieser ist zwar als Qualitätsmodell für Entwicklungsumgebungen entworfen worden, jedoch wurde im vorhergehenden Abschnitt gezeigt, dass damit auch die Auswertbarkeit von Projektinformationen beurteilt werden kann. Insbesondere enthält der Live-Ansatz Reifegradmodell für die Softwaremessung ein Reifegradmodell, mit dem die Integrierbarkeit der Softwaremessung in einzelne Entwicklungsumgebungen beurteilt werden kann. 116 5 Implementierung des Maven Measurement Frameworks Maven is a declarative project management tool that decreases overall time to market by effectively leveraging cross-project intelligence. (aus [CMP+07]) 5.1 Die Projektverwaltungssoftware Maven In diesem Kapitel wird eine Möglichkeit dargestellt, die innerhalb dieser Arbeit entwickelte Methode zur Softwaremessung mittels geeigneter Software-Werkzeuge zu realisieren. Die prototypische Implementierung dieses Ansatzes wurde auf ein Messwerkzeug für Java-Projekte beschränkt. Ein Kerngedanke bei der Umsetzung war, die Implementierung möglichst flexibel zu halten, damit das Software-Messwerkzeug für die jeweiligen Projektbedürfnisse problemlos angepasst werden kann. Daher ist auch keine monolithische Anwendung entstanden, sondern eine Werkzeug-Framework, aus dem der Anwender einzelne Bausteine auswählt, um damit die jeweiligen Messungen durchzuführen. Dieses Werkzeug-Framework, welches auf Basis der Projektverwaltungssoftware Maven1entstanden ist, soll im Weiteren als Maven Measurement Framework (MMF) Maven Measurement Framework bezeichnet werden. Maven selbst wird von einigen seiner Entwickler als Project Management Framework bezeichnet (vgl. [CMP+07], S. 22), wobei nach [CMP+07] auch dieser Begriff diese Software nur sehr unzureichend beschreibt. Grundsätzlich kann Maven zunächst einmal als Weiterentwicklung des BuildManagement-Werkzeuges Ant2betrachtet werden und dient somit zum automatisierten Übersetzen von Java-Quelltexten. Während Ant jedoch im Wesentlichen aus einer Sammlung von Anweisungen besteht, mit denen man den Ablauf des Build-Vorgangs definieren kann, enthält Maven entsprechende Verfahrensmuster, welche den Build-Vorgang standardisieren und die Projektverwaltung mittels wiederverwendbarer und gemeinsam nutzbarer Build-Strategien vereinfachen sollen (vgl. [CMP+07], S. 23 f.). Das Ziel der Maven-Entwickler war somit, einige Best Practices bzgl. der Verzeichnisverwaltung und des Build-Prozesses bei Java-Projekten in das Build-Management-Werkzeug zu integrieren. 1http://maven.apache.org 2http://ant.apache.org 117 5 Implementierung des Maven Measurement Frameworks 5.1.1 Ant vs. Maven: Build-Management im Vergleich 5.1.1.1 Build-Management mit Ant Um die Eigenschaften von Maven besser verdeutlichen zu können, soll an dieser Stelle zunächst die Arbeitsweise von Ant anhand eines typischen Ant-Build-Skripts betrachtet werden (siehe Listing 5.1). 1<p r o j e c t name="dms" default ="compile " basedir ="."> 2 3<property name="buil d . prod . d ir " l o c a t i o n="build /prod"/> 4<property name="buil d . t e s t . d ir " l o c a ti o n=" buil d / t e s t "/> 5<property name=" sr c . d ir " l o c a ti o n=" s rc "/> 6<property name=" t e s t . d ir " l o c a ti o n=" t es t "/> 7<property name=" l i b . di r " lo c a t i o n=" l i b "/> 8 9<path id=" pr oje ct . c las spa th"> 10 <pathelement l o c a t io n="${ build . prod . di r }"/> 11 <pathelement l o c a t io n="${ build . t e s t . d ir }"/> 12 <f i l e s e t dir="${ l i b . dir }"> 13 <include name="∗. j a r "/> 14 </ f i l e s e t > 15 </path> 16 17 <targ et name="prepare"> 18 <mkdir di r ="${ bui ld . prod . d ir }"/> 19 <mkdir di r ="${ bui ld . t e s t . d ir }"/> 20 </target > 21 22 <targ et name="compile " depends="prepare"> 23 <javac s r c d ir="${ s rc . dir }" destdir ="${ build . prod . di r }"> 24 <cl as spa th r e f i d =" p ro je ct . c la ss pa th"/> 25 </javac> 26 </target > 27 28 <targ et name="compile−t e s t s " depends="compile"> 29 <javac s r c d i r ="${ t e st . di r }" de std ir ="${ build . t es t . d ir }"> 30 <cl as spa th r e f i d =" p ro je ct . c la ss pa th"/> 31 </javac> 32 </target > 33 34 </project> Listing 5.1: Ant-Build-Skript (aus [Cla05]) In einem Ant-Build-Skript werden die Tätigkeiten des Build-Vorganges mittels sogenannter Targets definiert. Beispielsweise werden durch das Target prepare die VerTargets zeichnisse für den beim Kompilieren erzeugten Bytecode erzeugt. Durch die Targets compile und compile-tests wird anschließend der eigentliche Übersetzungsvorgang angestoßen. Dabei wird aufgrund der hinterlegten Abhängigkeiten bei Bedarf automatisch das jeweils vorher benötigte Target aufgerufen. 118 5.1 Die Projektverwaltungssoftware Maven Die Targets selbst bestehen aus sogenannten Tasks. Dabei handelt es sich um mitTasks tels entsprechender Java-Klassen implementierte Kommandos, welche die einzelnen Aufgaben des Build-Prozesses (z. B. Erzeugen von Verzeichnissen, Übersetzen von Sourcecode) durchführen. Die Tasks werden mittels zugehöriger XML-Elemente und -Attribute konfiguriert. Weiter gilt es als guter Stil, sämtliche Pfadangaben in Form von Variablen (sogenannter Properties) zu hinterlegen. Das in Listing 5.1 dargestellte Ant-Build-Skript erwartet also die Source-Dateien für die eigentliche Java-Applikation und die dazugehörigen Unit-Tests in den angegebenen Verzeichnissen, legt bei Bedarf die gewünschten Ziel-Verzeichnisse an und übersetzt die Java-Sourcen getrennt nach Produktivund Test-Code. Bei der Übersetzung benötigte Bibliotheken müssen im Verzeichnis lib zur Verfügung stehen. Obiges Ant-Build-Skript kann dabei als „kanonisch“ bezeichnet werden, da jedes Java-Projekt im Prinzip derartig aufgebaut ist, was insbesondere für die Trennung der Produktivund Test-Sourcen und der zugehörigen Bytecode-Verzeichnisse gilt. Als Konsequenz muss für jedes Java-Projekt ein sehr ähnliches Ant-Skript erstellt werden. 5.1.1.2 Build-Management mit Maven An dieser Stelle setzten nun die Entwickler von Maven durch Praktizierung des Ansatzes „Konvention statt Konfiguration“ an und legten als Konvention fest, dass Konvention statt Konfiguration die Verzeichnisstruktur eines mit Maven verwalteten Java-Projekts grundsätzlich wie in Abbildung 5.1 auszusehen hat. Abbildung 5.1: Verzeichnisstruktur eines Maven-Projekts 119 5 Implementierung des Maven Measurement Frameworks Die von Maven erwartete Verzeichnisstruktur enthält zumindest die Ordner src und target, in denen die Quelldateien verwaltet bzw. die im Rahmen des BuildEmpfohlene Verzeichnisstruktur Prozesses generierten Dateien abgelegt werden. Die genannten Ordner werden jeweils in Bezug auf Produktivund Test-Code weiter untergliedert. Die Java-Sourcen für die eigentliche Anwendung werden somit grundsätzlich im Ordner src/main/java verwaltet. Parallel zum Java-Ordner sind noch andere Verzeichnisse denkbar, die z. B. XML-Dateien enthalten, aus denen dann entsprechende Java-Sourcen generiert werden, wie es beispielsweise beim Einsatz objekt-relationaler Mapping-Frameworks üblich ist (vgl. [Bos03]). Mit dieser nahezu verpflichtend geltenden Verzeichnis-Konvention erübrigen sich alle in Listing 5.1 aufgeführten Pfadangaben, mit Ausnahme der Ablage von CodeBibliotheken, deren Verwaltung mit Maven später dargestellt werden soll. Zusätzlich erleichtert diese Vorgabe den Entwicklern die Orientierung in neuen Projekten. 5.1.1.3 Mavens Build-Lifecycle Auch die im Ant-Build-Skript aufgeführten Targets kommen grundsätzlich bei allen Java-Projekten in ähnlicher Weise vor, da der Build-Prozess in der Regel aus den Aktionen •Vorbereitung, •Kompilierung, •Test, •Konfektionierung des Installationspakets und •der abschließenden Installation besteht. Dem trägt Maven in Form eines Standard-Build-Lifecycles Rechnung, der aus StandardBuild-Lifecycle 21 einzelnen Phasen3besteht, welche für jedes Projekt in der gleichen Reihenfolge durchlaufen werden. Abbildung 5.2 zeigt eine Teilmenge dieser Phasen aus dem Standard-Build-Lifecycle. Diese Phasen können als Erweiterungspunkte für den durch Maven gesteuerten Build-Prozess betrachtet werden. Die eigentlichen Operationen des Build-Prozesses sind in sogenannten Plugins implementiert. Dabei handelt es sich um Java-Klassen Maven Plugins mit definierten Schnittstellen. Jedes Plugin implementiert dabei ein oder mehrere sogenannte Goals. Beispielsweise enthält das Maven-Compiler-Plugin die Goals Maven Goals compile und test-compile, mit denen die Anwendungs-Quelltexte bzw. die UnitTest-Quelltexte kompiliert werden. Diese Goals werden nun an bestimmte Phasen des Build-Lifecycles gebunden (vgl. Abbildung 5.2). So sind standardmäßig das Goal compiler:compile4der Compile-Phase und das Goal compiler:test-compile der 3Stand vom August 2007 (vgl. [CMP+07]) 4Bei der Beschreibung von Maven-Goals werden per Konvention der Plugin-Name und die Bezeichnung des Goals durch einen Doppelpunkt getrennt notiert. 120 5.1 Die Projektverwaltungssoftware Maven     initialize ⇓     generate-sources torque:om ⇓     process-resources ⇓     compile compiler:compile ⇓     test-compile compiler:test-compile ⇓     test surefire:test ⇓     prepare-package ⇓     package jar:jar ⇓ Abbildung 5.2: Teilmenge von Mavens Default Build-Lifecycle Test-Compile-Phase zugeordnet. Beim Durchlaufen der einzelnen Phasen des BuildProzesses werden nun die an die Phasen gebundenen Goals aufgerufen. Beim Durchlaufen von Phasen, an denen kein Goal angebunden ist, werden auch keine Aktionen durchgeführt. Im Vergleich zu dem Ant-Build-Skript auf Seite 118 ist daher für das Kompilieren der Produktivund Test-Quellcode-Dateien keinerlei Konfigurationsaufwand erforderlich. Der Speicherort der Quellcode-Dateien ist durch Konvention vorgegeben und der Ablauf des Build-Processes durch den Standard-Build-Lifecylce. 5.1.2 Mavens Project-Object-Model 5.1.2.1 Grundlegende Projekt-Konfiguration Trotzdem kommt auch Maven nicht ohne Konfiguration aus, jedoch wird versucht, gemäß dem Prinzip „Konvention statt Konfiguration“, die Konfigurationsdateien möglichst klein zu halten. Der zentrale Ablageort für Konfigurationsdaten ist eine als 121 5 Implementierung des Maven Measurement Frameworks Project Object Model (POM) bezeichnete XML-Datei. Ein Bespiel einer POM-Datei Project Object Model für eine Depotverwaltungsanwendung ist in den Listings 5.2 und 5.3 dargestellt. Das POM eines Maven-Projekts enthält zunächst einmal Informationen über den Namen des Projekts (<name>), eine eindeutige Bezeichnung für die Organisation Projektkoordinaten (<groupId>) und eine eindeutige Basisbezeichnung für das im Rahmen des Projekts erzeugte Artefakt (<artifactId>). Im angegebenen Beispiel wird im Rahmen des Projekts letztendlich ein Jar-Archiv mit der Depotverwaltungsanwendung erzeugt, welches den Dateinamen depotverw-0.1.jar erhält. Der Ablageort der Quelltextdateien muss, sofern er den Maven-Konventionen entspricht, nicht angegeben werden. Jedoch müssen externe Bibliotheken, welche von Deklaration von Abhängigkeiten dem Projekt verwendet werden und von denen das Projekt somit abhängig ist, im POM deklariert werden. Dies erfolgt im Abschnitt <dependencies> der Datei. Bei Verwendung von Maven muss der Entwickler die benötigten Bibliotheken jedoch nicht selbst bereitstellen, sondern sie werden im Rahmen des Build-Vorganges durch Maven selbständig von einem oder mehreren zentralen Repositories heruntergeladen. Im angegebenen Beispiel sind davon die JUnit-Bibliothek, der PostgreSQL-JDBCTreiber und das objekt-relationale Mapping-Tool Torque betroffen, die jeweils mit der exakten Versionsnummer aufgeführt sind. Somit erklärt sich auch die Bedeutung der GroupID für die aktuell zu erstellende Applikation. Die im Beispiel erstellBedeutung der GroupID te Depotverwaltungssoftware kann beim Abschluss des Projektes ebenfalls in einem Bibliotheks-Repository veröffentlicht werden. Dabei kann es sich um ein öffentlich verfügbares, zentrales Repository oder auch um ein organisationsinternes Repository handeln, in denen das Jar-Archiv der Depotverwaltungssoftware über die oben beschriebenen Bezeichner eindeutig aufgefunden werden kann. Das Listing 5.3 zeigt die Konfiguration der im Rahmen des Projektes verwendeten Maven-Plugins. Das in Abbildung 5.2 dargestellte Compiler-Plugin müsste normalerBeispielhafte PluginKonfiguration weise nicht explizit konfiguriert werden, da es standardmäßig an die Compile-Phase des Build-Prozesses gebunden ist. Jedoch können auch, wie in diesem Beispiel, für die Standard-Plugins zusätzliche Informationen, wie beispielsweise die Version des zu erzeugenden Java-Objekt-Codes angegeben werden. Bedeutsamer ist jedoch die Konfiguration der zusätzlich in den Build-Prozess eingebundenen Maven-Plugins. In diesem Beispiel handelt es sich dabei um das TorqueKonfiguration eines O/R-Mapping-Tools Maven-Plugin5. Torque ist ein objekt-relationales Mapping-Tool, welches zur Laufzeit einer Applikation Datensätze einer relationalen Datenbank auf Java-Objekte abbildet (vgl. [Bos03]). Dadurch entfällt in der Java-Applikation die Verwendung von SQL-Statements, welche ansonsten einen Bruch innerhalb des objekt-orientierten Anwendungsdesigns bedeuten würden. Bei der Verwendung von Torque wird in mehreren XML-Dateien das Relationenschema der Datenbank definiert. Zu diesem Relationenschema werden dann durch die Generierung von Java-Code und SQL-Code Goals torque:om und torque:sql sowohl die zugehörigen Java-Klassen als auch die SQL-Anweisungen zum Erzeugen der entsprechenden Datenbanktabellen erzeugt. Letztere werden dann durch das Goal torque:sqlExec ausgeführt. 5http://db.apache.org/torque 122 5.1 Die Projektverwaltungssoftware Maven 1<?xml vers ion ="1.0" encoding="UTF−8"?> 2<p ro je ct xmlns="http : // maven . apache . org /POM/4.0.0" > 3 4<modelVersion >4.0.0</modelVersion> 5<groupId>de . ubt . investment </groupId> 6<a r t i fa c t I d >depotverw</a r t i f a c tI d > 7<packaging>jar </packaging> 8<version >0.1</version > 9<name>Depotverwaltung </name> 10 11 <dependencies> 12 <dependency> 13 <groupId>junit </groupId> 14 <a r t i fa c t I d >ju nit </a r t i fa c t Id > 15 <version >3.8.1</version > 16 <scope>test </scope> 17 </dependency> 18 <dependency> 19 <groupId>postgresql </groupId> 20 <a r t i fa c t I d >po stgresql </a r t i f a ct I d > 21 <version >8.2−504.jdbc3</version> 22 </dependency> 23 <dependency> 24 <groupId>torque </groupId> 25 <a r t i fa c t I d >torque </a r t i f a ct I d > 26 <version >3.3−RC2</version > 27 </dependency> 28 </dependencies> 29 30 <build > 31 <plugins> 32 <!−− hier e r f o l g t die Konfiguration der Plugins −−> 33 </plugins> 34 </build> 35 36 <reporting> 37 <plugins> 38 <plugin> 39 <groupId>metrics . plugin </groupId> 40 <a r t i fa c t Id >halstead−plugin </a r t i fa c t I d > 41 <version >2.0</version> 42 </plugin> 43 </plugins> 44 </reporting> 45 46 </project> Listing 5.2: POM eines Maven-Projekts (Depotverwaltung) 123 5 Implementierung des Maven Measurement Frameworks 5.1.3 Generierung von Projekt-Berichten Die im Project-Object-Model abgelegten Informationen dienen neben der Steuerung des Build-Prozesses auch zur Generierung von Projektberichten. Dazu kann Maven so konfiguriert werden, dass im Rahmen des Build-Prozesses mehr oder weniger ausführliche Projektberichte in Form von HTML-Dokumenten erzeugt werden, welche dann automatisiert in die entsprechenden Verzeichnisse eine Web-Servers übertragen werden können. Standardmäßig enthalten die so generierten Projektseiten diejeniStandardberichte gen Informationen, welche in den POM-Blöcken General Project Information und Build Environment (siehe Abbildung 5.3) enthalten sind und im vorhergehenden Abschnitt beschrieben wurden. Ein Ausschnitt eines solchen Standard-Project-Reports ist in Abbildung 5.4 zu sehen, welche die Liste der Softwareentwickler im Apache Commons Math Projekt12 zeigt. Abbildung 5.4: Entwicklerliste als Teil des Maven Standard-Project-Reports Zusätzlich zu den Standard-Reports können natürlich auch von allen MavenPlugins Projektberichte generiert werden. So kann das PMD-Maven-Plugin13 verPlugin-ReportsPlugin-Reports wendet werden, um den Sourcecode nach bestimmten Regelverletzungen zu untersuchen. Dies können beispielsweise Namenskonventionen (z. B. mind. drei Zeichen für Variablennamen) aber auch nahezu beliebige andere (projektinterne) Programmierrichtlinien (z. B. max. 10 Methodenparameter) sein. In Abbildung 5.5 ist ein beispielhafter Ausschnitt eines derartigen Berichts dargestellt, der Regelverstöße wie einen leeren Catch-Block im Rahmen des Java-Exception-Handlings aufdeckt. 12http://commons.apache.org/math 13http://pmd.sourceforge.net 130 5.1 Die Projektverwaltungssoftware Maven Abbildung 5.5: PMD-Report über Regelverletzungen im Apache-Commons-MathProjekt (Ausschnitt) 131 5 Implementierung des Maven Measurement Frameworks 5.2 Erweiterbarkeit von Maven 5.2.1 Maven Plugins Wie bereits dargestellt, werden die eigentlichen Build-Funktionalitäten von Maven mittels Plugins implementiert. Der Maven-Kern dient dagegen hauptsächlich dazu, Maven-Kern die POM-Datei einzulesen und zu analysieren, Projektabhängigkeiten zu verwalten und die einzelnen Plugins zu starten (vgl. [CMP+07], S. 134 f.). Welche Plugins verwendet werden, wird gesteuert, indem einzelne Plugin-Goals mit einer Phase des Maven-Build-Lifecycles verknüpft werden. Sobald diese Phase beim Durchlaufen des Build-Prozesses erreicht wird, werden die verknüpften Goals und damit die entsprechenden Plugins aufgerufen (vgl. auch Abschnitt 5.1.1.3, S. 120 f.). Jedes Goal innerhalb eines Maven-Plugins wird durch ein sogenanntes Mojo implementiert. Die Bezeichnung Mojo ist eine Anspielung auf den Begriff POJO14, welcher Maven-Mojos für plain old java object steht, also ein einfaches Java-Objekt ohne umfangreiche externe Abhängigkeiten, wie sie beispielsweise bei EJBs Enterprise Java Beans gegeben sind (vgl. [Ric06]). Ein Maven-Mojo, welches ein Goal implementiert, ist daher eine Java-Klasse, welche im Wesentlichen von der Klasse AbstractMojo aus dem Maven-Framework abAbstractMojo als Basisklasse geleitet sein muss. Damit besteht ein Maven-Plugin aus einem oder mehreren Mojos und evtl. notwendigen Hilfsklassen, welche zusammen mit der Datei plugin.xml, in der die Goals und Parameter des Plugins beschrieben sind, zu einem Jar-Archiv gebündelt werden. Ein sehr einfaches Mojo ist in Listing 5.4 abgebildet. Dieses Mojo erwartet als Parameter einen String, welcher dann innerhalb von Mavens Logging-Strom mit ausgegeben wird. Dieses Mojo zeigt auch die Art und Weise, mit der innerhalb des Maven-Frameworks Parameter an Mojos und damit an Goals übergeben werden. Dabei bedient sich Maven des Dependency-Injection-Prinzips (vgl. [Fow04]). Bei diesem Prinzip wird die Verantwortung für die Erzeugung und Dependency Injection Initialisierung von Objekten, welche bei der objektorientierten Programmierung üblicherweise über einen Konstruktor erfolgt, dem Objekt entzogen und dem umgebenden Framework übertragen. Bei Maven werden also Mojos nicht durch parametrisierbare Konstruktor-Methoden initialisiert, sondern das Maven-Framework erzeugt ein Mojo-Objekt und sorgt für die Initialisierung der Mojo-Attribute. Die Motivation für dieses Vorgehen ist, dass dadurch der Programmcode dieser Objekte nicht an bestimmte Interface-Definitionen gebunden ist, welche beispielsweise die Anzahl der Parameter vorgeben würden. Beim Dependency-Injection-Prinzip werden daher die Attribute eines zu erzeugenden Objekts extern konfiguriert, was typischerweise mittels XML-Dateien erfolgt. Somit kann ein Mojo grundsätzlich eine beliebige Anzahl Attribute unterschiedlichster Typen haben. Diese werden in der Datei plugin.xml deklariert und das Maven-Framework sorgt zur Laufzeit des Plugins dafür, dass die Mojo-Attribute entsprechend initialisiert werden. Im obigen Beispiel (Listing 5.4) wird durch die JavaDoc-Annotation @parameter deklariert, dass das nachfolgende String-Attribut message über einen Parameter des 14http://www.martinfowler.com/bliki/POJO.html 132 5.2 Erweiterbarkeit von Maven 1package de . ubt . mavenplugins ; 2 3import org . apache . maven . plugin . AbstractMojo ; 4import org . apache . maven . plugin . MojoExecutionException ; 5 6/∗∗ 7∗ Ausgabe eines St r i ng s 8∗ 9∗ @goal echo 10 ∗/ 11 public class EchoMojo extends AbstractMojo { 12 13 /∗∗ 14 ∗ Auszugebender Text 15 ∗ 16 ∗ @parameter ex pr es si on ="${ echo . message }" 17 ∗ def a ul t −value="Hallo ! " 18 ∗/ 19 private String message ; 20 21 public void execute () throws MojoExecutionException { 22 getLog ( ) . info ( message ) ; 23 } 24 } Listing 5.4: Einfaches Maven-Mojo Mojos initialisiert wird. Durch die Deklaration expression="${echo.message}" wird festgelegt, dass beim Aufruf des Plugins von der Kommandozeile aus mittels Konfiguration auf Kommandozeile -Decho.message="Hier kommmt die Nachricht" dieser Parameter konfiguriert werden kann. Dadurch wird die Expression ${echo.message} definiert, deren Wert dem Mojo-Parameter zugewiesen wird. Zusätzlich wird durch die Parameter-Annotation implizit festgelegt, dass der GoalParameter im Plugin-Abschnitt der POM-Datei konfiguriert werden kann, wie es Konfiguration über POM-Datei bereits anhand des Maven-Compiler-Plugins in Listing 5.3 dargestellt wurde: <configuration> <message>Hier steht der Nachrichtentext</message> </configuration> Schließlich wird noch ein Default-Wert für den Parameter definiert, welcher zum Tragen kommt, falls zur Laufzeit weder die Expression echo.message definiert noch Default-Wert eine Konfiguration innerhalb des POM vorhanden ist. Aber auch der Default-Wert 133 5 Implementierung des Maven Measurement Frameworks wird erst zur Laufzeit vom Maven-Framework an das Mojo übergeben. Dadurch ist es möglich, durch die Deklaration @parameter default-value="${project.name}" das entsprechende Attribut des Mojos mit einem Default-Wert zu initialisieren, welcher erst zur Laufzeit des Mojos bekannt ist. Die Expression ${project.name} wird vom Maven-Framework selbst erzeugt und enthält den aktuellen Projektnamen, der wiederum dem POM des aktuellen Projekts entnommen ist. Somit gibt es drei Möglichkeiten, um zur Laufzeit eines Plugins Parameter an dessen Drei Möglichkeiten der Parameterübergabe Mojos zu übergeben: •Kommandozeilenparameter •Konfiguration über Einträge in der POM-Datei •Default-Werte (Wert u. U. erst durch die Projektumgebung bestimmt) In allen Fällen enthält das Mojo nicht selbst den Code zur Initialisierung der Attribute, sondern die Initialisierung erfolgt gemäß dem Dependency-Injection-Prinzip durch das umgebende Maven-Framework.15 Dies ermöglicht die Erstellung spezieller Plugins zur Ermittlung von Softwaremaßen. Die Messfunktionen können als Plugin-Goals implementiert werden, welche dann aus dem Project-Object-Model ihre Konfigurationsinformationen beziehen. 5.2.2 Beispiel-Plugin: Berechnung der Halstead-Maße Als beispielhafte Implementierung eines Maven-Plugins zur Softwaremessung soll an dieser Stelle ein Plugin zur Berechnung der Halstead-Software-Maße [Hal77] vorgestellt werden. Dieses wurde von Lorenz Singer im Rahmen seiner Bachelor-Arbeit [Sin06] an der Universität Bayreuth entwickelt. Die Halstead-Maße wurden 1977 veröffentlicht und gehören mit zu den bekannteren Softwaremaßen (vgl. [Zus98], S. 1). Sie basieren auf der Annahme, dass die HalsteadSoftwaremaße ausführbaren Programmteile aus Operatoren und Operanden aufgebaut sind (vgl. [Wol03]). Dabei werden typischerweise Variablen und Konstanten als Operanden betrachtet. Die restlichen Programmbestandteile sind somit Operatoren (vgl. [Zus98], S. 37). Die Halstead-Maße selbst basieren auf folgenden Basismaßen: •Anzahl der verwendeten unterschiedlichen Operatoren n1 •Anzahl der verwendeten unterschiedlichen Operanden n2 •Gesamtzahl der verwendeten Operatoren N1 •Gesamtzahl der verwendeten Operanden N2 15Die Objektvariable message in der Klasse EchoMojo ist zwar als private deklariert. Trotzdem ist es über die Java-Reflection-API (http://java.sun.com/docs/books/tutorial/reflect) möglich, von außen auf Objektvariablen zuzugreifen und diese zu modifizieren. Eine beispielhafte Anleitung dazu findet sich u. a. in [Ull07]. 134 5.2 Erweiterbarkeit von Maven Damit lassen sich u. a. die folgenden Halstead-Maße berechnen: Implementierungslänge: N=N1+N2 Vokabular: n=n1+n2 Halstead-Länge: HL=n1·log2n1+n2·log2n2 Halstead-Volumen: HV=N·log2n Zusätzlich zu diesen Maßen hat Halstead auch davon abgeleitete Maße für Schwierigkeit, den Intelligenzgehalt und den Implementierungsaufwand von Programmen angegeben (vgl. [Hal77]). Einige der Halstead-Maße, insbesondere die abgeleiteten Kritik an den Halstead-Maßen Maße, wurden in der Literatur oft kritisiert und teilweise als Beispiele für „confused and inadequate measurement“ (siehe [FP98]) bezeichnet. Jedoch wurde von Wolle in [Wol03] dargestellt, dass sich insbesondere die Implementierungslänge Nals geeigneteres Maß für die Längenmessung von Java-ApplikaBetrachtung der Implementierungslänge tionen als das weit verbreitete LOC-Maß erweist. Diese Ansicht wird von Zuse in [Zus03] bestätigt. Zusätzlich wird darauf hingewiesen, dass sich damit gemäß [Zus98] (Kapitel 8) die Implementierungslänge zur Abschätzung des Wartungsaufwandes für Java-Applikationen empfiehlt. Die Implementierungslänge Nhat insbesondere gegenüber dem LOC-Maß den Vorteil, dass sie weit weniger stark vom Programmierstil (z. B. Klammersetzung) abhängt als das LOC-Maß. Trotzdem ist sie maschinell recht einfach zu ermitteln, nachdem festgelegt wurde, welche Java-Sprachelemente als Operatoren bzw. als Operanden gezählt werden. In [Wol03] findet sich beispielsweise die Inkonsistenz, dass Variablendeklarationen als Operatoren gezählt werden, wenn es sich um eine primitive Variable handelt (int, byte,boolean, etc.), sie jedoch als Operanden zählen, wenn es sich um Referenzvariablen (z. B. String) handelt. Demgegenüber werden von Singer die Deklarationen von Variablen und Methoden einheitlich als Operanden gezählt, was auch dem Originalansatz16 von Halstead entspricht (vgl. [Sin06], S. 32 ff.). Diese Unterscheidung macht sich jedoch nur bei der Halstead-Länge HLbemerkbar. Für die Implementierungslänge Nführen beide Zählweisen zum gleichen Ergebnis. Die Halstead-Länge und das Halstead-Volumen sollen an dieser Stelle auch nicht weiter betrachtet werden, da deren Bedeutung sehr umstritten ist bzw. empfohlen Halstead-Länge und -Volumen wird, zumindest auf erstere noch eine Korrekturfunktion anzuwenden (vgl. [Zus98], S. 546 f., [Wol03]). Verwendung des Halstead-Metrics-Plugin Das im Rahmen von [Sin06] entwickelte Halstead-Metrics-Plugin wird über das Goal MetricsReport aufgerufen. Dieses Goal kann unter anderem über die in Listing 5.5 dargestellten Parameter konfiguriert werden. Dabei werden zunächst die Verzeichnisse für die zu vermessenden Java-Dateien als Parameter definiert, wobei als Voreinstellungen das Source-Verzeichnis für die eigentliche Java-Applikation und das zugehörige Unit-Tests-Verzeichnis hinterlegt 16Halstead verwendet in [Hal77] nur Sprachbeispiele für Algol,Fortran und PL/1. 135 5 Implementierung des Maven Measurement Frameworks 1/∗∗ 2∗ The source dir e ct or y to browse . 3∗ @parameter de fau lt −v alu e="${ p r o je c t . b u i l d . so ur ce Di re ct or y }" 4∗/ 5private String sourceDir ; 6 7/∗∗ 8∗ The t e s t dir ec tor y to browse . 9∗ @parameter de fau lt −v alu e="${ p r o je c t . b u i l d . t es tS ou rce Di re ct or y }" 10 ∗/ 11 private String testDir ; 12 13 /∗∗ 14 ∗ Defines i f t e s t s should be analysed . 15 ∗ @parameter de f au lt −value="true " 16 ∗/ 17 private boolean analyseTests ; 18 19 /∗∗ 20 ∗ S p e c i f i e s the d i re ct o ry where the r ep ort w i l l be gener ated 21 ∗ 22 ∗ @parameter de f au lt −value="${ pr o jec t . rep o rt in g . outputDirectory }" 23 ∗ @required 24 ∗/ 25 private File outputDirectory ; Listing 5.5: Parameter des Halstead-Metrics-Plugin (Auszug) sind. Diese Vorgaben können jedoch über Einträge in der POM-Datei überschrieben werden. Dadurch ist es möglich, das Halstead-Metrics-Plugin auch auf beliebige Plugin auf beliebige Projekte anwendbar andere Java-Projekte anzuwenden, welche nicht Maven als Build-Tool verwenden. Die Ausgabe erfolgt standardmäßig in dem Verzeichnis, in dem auch die übrigen Reports von Maven abgelegt werden. Schließlich kann noch konfiguriert werden, ob die Halstead-Maße nur für den produktiven Sourcecode oder auch unter Einbeziehung des Test-Sourcecodes berechnet werden sollen. Die Abbildung 5.6 zeigt beispielhaft einen Ausschnitt aus einem mit diesem Plugin erstellten Maven-Report. Die Einbindung des Plugins in die POM-Datei ist in Beispiel-Report Listing 5.2 (S. 123) ab Zeile 36 dargestellt. Zum Abschluss der Betrachtungen dieses Plugins bleibt festzustellen, dass dieses Plugin in erster Linie als Nachweis für die Verwendbarkeit von Maven für die Softwaremessung implementiert wurde. Die Halstead-Maße wurden ausgewählt, weil insbesondere in [Wol03] die Implementierungslänge Nund die (korrigierte) HalsteadLänge HLals im Vergleich zu den Lines of Code robustere Maße zur UmfangsmesRobuste Maße zur Umfangsmessung sung von Java-Programmen empfohlen werden. Insbesondere der Halstead-Länge wird diesbezüglich noch weiteres Potenzial zugesprochen, da dieses Maß evtl. doppelt vorhandene Code-Abschnitte nicht mehrfach zählt, da sie allein von dem im 136 5.2 Erweiterbarkeit von Maven Abbildung 5.6: Durch das Halstead-Metrics-Plugin erzeugter Maven-Report (Ausschnitt) 137 5 Implementierung des Maven Measurement Frameworks Programm verwendeten Vokabular abhängig ist. Für die praktische Anwendung dieses Maßes sind jedoch noch weitere Studien notwendig (vgl. [Wol03]). Die Implementierungslänge N, d. h. die Summe aller verwendeten Operatoren und Operanden, ist jedoch als Längenmaß für Sourcecode akzeptiert, und hat gegenüber Implementierungslänge als Umfangsmaß den Lines of Code den Vorteil, dass dieses Maß vom Programmierstil unabhängig ist und dass lange und kurze Ausdrücke unterschiedlich gezählt werden (vgl. [Wol03] und [Zus03]). Da dieses Maß jedoch äquivalent zu den Non-commenting Source Statements (NCSS) [Lee06] ist, wurden diese im Rahmen dieser Arbeit als Längenmaß eingesetzt, da das zugehörige Maven-Plugin regelmäßig aktualisiert wird. 5.3 Messwertgeber als Maven-Plugins Nachdem im vorhergehenden Abschnitt gezeigt wurde, dass mittels Maven-Plugins grundsätzlich beliebige Softwaremaße automatisiert ermittelt werden können, soll an dieser Stelle nun der Begriff des Messwertgebers eingeführt werden. Ein Messwertgeber ist ein Maven-Plugin, welches ein bestimmtes Softwaremaß berechnen kann. Die Bezeichnung Messwertgeber wird in der Messtechnik für GeräMesswertgeber te zur Bestimmung physikalischer oder meteorologischer Größen wie beispielsweise Stromstärke, Druck, Temperatur oder Niederschlagsmenge verwendet. Und ähnlich, wie z. B. ein Windstärkemesser entweder in Bodennähe oder auf einem erhöhten Punkt positioniert werden kann, kann ein Maven-Messwertgeber so konfiguriert werden, dass er nur Messwerte berücksichtigt, die zu einem bestimmten Kontext gehören. Ein Kontext wird dabei durch die im Abschnitt 4.2 dargestellten Kontextinformationen definiert, mittels derer die zu messenden Entitäten vorher gekennzeichnet Kontext wurden. Ein durch einen Messwertgeber ermitteltes Softwaremaß ist somit gekennzeichnet •durch die Art der Messung, die der Messwertgeber durchführt, und •durch den Kontext, auf den die Messung eingeschränkt wird. Somit ist es möglich, einen Messwertgeber, der den Umfang bzw. die Umfangsänderung von Sourcecode-Elementen bestimmen kann, derart zu konfigurieren, dass Konfigurierbarkeit von Messwertgebern seine Messungen auf den Kontext der Analyse-Aktivitäten einschränkt sind. Die Umfangsmessung selbst wird dabei durchgeführt, indem die zu messenden SourcecodeElemente aus dem Versionsverwaltungssystem ausgecheckt und vermessen werden. Um dabei einen bestimmten Kontext berücksichtigen zu können, muss bei den Commit-Informationen mit angegeben worden sein, im Rahmen welcher Aktivität die jeweiligen Sourcecode-Änderungen durchgeführt wurden. Durch Abfrage des Versionsverwaltungssystems, welches ebenfalls in der Maven-POM-Datei referenziert wird, können anhand der Commit-Informationen die im Rahmen bestimmter Aktivitäten erzeugten oder veränderten Sourcecode-Dateien mit den zugehörigen Versionsnummern identifiziert werden und durch sukzessives Aus-checken der betroffenen Versionen kann deren Größenänderung bestimmt werden (vgl. [DHW06a], [DHW06c]). 138 5.3 Messwertgeber als Maven-Plugins 5.3.1 Konfiguration und Funktion von Messwertgebern Am Beispiel der Auswertung der Aktivitäts-Kontextinformationen soll die Konfiguration eines Messwertgebers dargestellt werden. Da innerhalb dieses Beispiels die Projektaktivitäten als Anknüpfungspunkte für die Sourcecode-Umfangsmessung verwendet werden, müssen die Commit-Informationen im Versionsverwaltungssystem um die PSP-Codes der Projektaktivitäten ergänzt worden sein (vgl. Abschnitt 4.2, S. 92). Der Standard-Projektstrukturplan habe in diesem Beispiel nur eine Gliederungsebene, wie er beispielsweise im Abschnitt 4.3.1 (S. 106 f.) beschrieben wurde. Bei diesem PSP finden Programmiertätigkeiten innerhalb der Aktivitäten Verteilung der Programmiertätigkeiten •Analyse (in Form von Prototyping), •Implementierung und •Test (in Form von Programmkorrekturen) statt. Somit ist es aufschlussreich zu ermitteln, wie sich die im Rahmen dieser Aktivitäten erzeugten Code-Umfänge auf die drei Aktivitäten verteilen. Insbesondere erscheint interessant, ob vielleicht ein relativ großer Anteil des letztendlichen CodeUmfangs bereits im Rahmen des Prototyping entstanden ist. Auch kann auf diese Weise untersucht werden, ob im Rahmen der Programmkorrekturen nur einzelne Programmzeilen überarbeitet wurden, wodurch sich der Gesamtumfang nicht geändert hätte, oder ob sich der Programmumfang beim Einpflegen der Korrekturen signifikant vergrößert hatte, was darauf deuten würde, dass dabei zusätzliche bzw. vorher nicht berücksichtigte Anforderungen implementiert wurden (Requirements Creep, vgl. S. 109). Im Bezug auf einen einzelnen Programmierer kann dabei folgendermaßen zwischen Programmiertätigkeiten im Rahmen von Implementierungsund Test-Aktivitäten Abgrenzung von Programmiertätigkeiten im Rahmen von Implementierungsoder Test-Aktivitäten unterschieden werden, damit die SCM-Commit-Informationen mit den korrekten Kontextinformationen gekennzeichnet werden können: Alle Programmänderungen, welche ein Programmierer durchführt, weil er mit dem gerade erstellten Programmabschnitt nicht zufrieden ist oder weil einzelne Unit-Tests fehlgeschlagen sind, welche der Programmierer in kurzen Abständen auf seine Programmsourcen anwendet, zählen als Implementierungs-Aktivitäten. Wenn dagegen im Rahmen der Continuous-Integration-Tests (vgl. S. 128) festgestellt wird, dass der Build-Prozess des Gesamtsystems nicht mehr erfolgreich durchlaufen werden kann (Broken Build, vgl. S. 128), so zählen die zur Korrektur dieser Fehler nötigen Programmiertätigkeiten als Test-Aktivitäten. Gleiches gilt für die Behebung von Fehlern, welche im Rahmen von Systemoder Akzeptanztests festgestellt werden.17 Diese Einteilung lässt sich zumindest teilweise auch im Rational Unified Process wiederfinden (vgl. [Kru04], S. 193 ff.). Auch hier gehört die Durchführung von Unit-Tests und die Durchführung der daraus resultierenden Code-Korrekturen zur Implemen17Beim Systemtest wird das Gesamtsystem gegen die Anforderungen oder die Spezifikation getestet. Beim Akzeptanztest wird das System durch den Anwender (Kunden) getestet (vgl. [SL05]). Der Unterschied zwischen den kontinuierlichen Integrationstests und einem Systemtest ist dabei fließend (vgl. [KK05], S. 154 f.), da mit entsprechend ausgearbeiteten Unit-Test-Suiten auch das Gesamtsystem automatisiert getestet werden kann. 139