Diplomarbeit. Otto-von-Guericke-Universität Magdeburg. Functional Size emeasurement. Größenmessung. Fakultät für Informatik.

Transkript

1 Otto-von-Guericke-Universität Magdeburg Functional Size emeasurement Konzeption und prototypische Realisierung eines Portals zur funktionalen Größenmessung Diplomarbeit Fakultät für Informatik Institut für Verteilte Systeme Arbeitsgruppe Softwaretechnik Themensteller: Betreuer: Prof. Dr. Reiner R. Dumke Dipl.-Inf. Mathias Lother vorgelegt von: René Braungarten An der Seilerbahn Schönebeck Matrikelnummer:

2 Braungarten, René: Konzeption und prototypische Realisierung eines Portals zur funktionalen Größenmessung Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, 2004.

3 Danksagung I Danksagung Bei der Anfertigung der vorliegenden Diplomarbeit wurde ich von vielen Seiten direkt oder indirekt unterstützt, wofür ich mich an dieser Stelle recht herzlich bedanken möchte. Namentlich erwähnt sei dabei in erster Linie mein Betreuer, Diplom-Informatiker Mathias Lother, der durch seine vielen wertvollen Anregungen im Rahmen gemeinsamer Diskussionen und seine ständige Hilfsbereitschaft sehr zur Entstehung dieser Arbeit beigetragen hat. Ebenso gilt Herrn Professor Dumke mein besonderer Dank für die Vergabe dieser interessanten Themenstellung und für seine exzellente Betreuung während meines gesamten Studiums. Nicht zuletzt durch das von ihm vermittelte und geförderte Auslandspraktikum am Software Engineering Management Research Laboratory von Professor Abran an der ÉTS in Montréal/Kanada konnte ich mein Wissen im Bereich des Software-Engineering stark vertiefen sowie unzählige einmalige und kostbare Erfahrungen sammeln. Darüber hinaus bedanke ich mich bei Herrn Professor Paul für die schnelle Zusage, mir als Zweitgutachter zur Verfügung zu stehen. Auch genannt seien ausnahmslos alle Mitarbeiter der Arbeitsgruppe Softwaretechnik, die das Forschen und Arbeiten in einem sehr angenehmen Klima ermöglicht haben. Nicht vergessen werden soll auch Herr Dr. Feuerstein von der Hochschule Magdeburg- Stendal, der es mir gestattet hat, an seinem reichhaltigen praktischen Erfahrungsschatz teilzuhaben. Abschließend möchte ich mich herzlichst bei meinen Eltern, meinem Bruder und meinen Freunden bedanken, die mir während meines Studiums und der Erstellung dieser Diplomarbeit stets den für mich so wichtigen Rückhalt gegeben haben. Ihre großzügige Unterstützung und fortwährende Motivierung hat maßgeblich zum erfolgreichen Gelingen meines Studiums beigetragen.

4 II

5 Inhaltsverzeichnis III Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Kode-Fragmente Abkürzungsverzeichnis VII VIII VIII IX 1 Einleitung Motivation Zielstellung Aufbau der Diplomarbeit Software-Messung, Merkmalsabschätzung und Benchmarking Begriffsklärungen Einordnung in das Softwaremanagement Projektmanagement Operatives Projektmanagement (Projektcontrolling) Strategisches Projektmanagement Interdependenzen: Das Teufelsquadrat Softwarequalitätsmanagement Qualitätsaspekte Maßnahmen zur Qualitätssicherung Bezug zu Software-Messung, Aufwandsschätzung und Benchmarking Aspekte der Software-Messung Software-Metriken und -Maße Auswahl der Messziele (GQM) Programmgröße als Messziel Physikalische Größe: LOC Funktionale Größe: Functional Size Measurement Aspekte der Merkmalsabschätzung Statistische Grundlagen Einführung Regressionsgerade und -gleichung Der Determinations-Koeffizient R² Das Konfidenzintervall... 24

6 IV Inhaltsverzeichnis Das Vorhersage-Intervall Aufwandsschätzung Betriebswirtschaftliche Relevanz Einflussfaktoren und Schätzgenauigkeit Erforderliche Vorarbeiten Allgemeine Schätzregeln und typische Probleme Schätzansätze Schätzmethoden Aspekte des Benchmarking Kategorisierung Das interne Benchmarking Das externe Benchmarking Schlüsselschritte für ein erfolgreiches Benchmarking Die Problematik der Informationsbeschaffung Informationsquellen Die Datenbasis der ISBSG Hintergründe des integrierten Ansatzes Software-Werkzeuge für das CAME Measurement Dashboards Portalansatz Portale Begriffsbestimmung Anforderungen Funktionale und systemtechnische Anforderungen Qualitative Anforderungen Klassifizierungen von Portalen Spezialisierungsgrad Interaktionsgrad Art der wechselseitigen Beziehungen B2X-Unternehmensportale Ausprägungen von B2E-Unternehmensportalen Ausgewählte technologische Hintergründe Das Referenzmodell für Portale Die Bereitstellung heterogener Inhalte Portlets Integration von Anwendungen Das Schichtenmodell... 52

7 Inhaltsverzeichnis V Überblick möglicher Integrationstechnologien Marktstudie im Segment Portal Server Das Marktsegment Eine Produktübersicht Publizierte Untersuchungen Umfrageergebnisse der FAZ Analyse der CSC Ploenzke AG Fazit der Marktstudie und Design-Entscheidung Apache Jetspeed als Portal-Server Das Modulare Architekturkonzept Apache Turbine als Fundament MVC Design Pattern Die Fulcrum Service-Architektur Zusatzmodule zur Erweiterung der Funktionalität Die Portal Structure Markup Language Die Registrierung von Portlets Die Sprache zur Seitenbeschreibung Beschreibung der Portallösung Erfassung von Projekt- und Produktivitätsdaten Die unternehmensinterne Projektdatenbank Beurteilung und Entwicklungspotenzial Aufwandsschätzungen mit dem Applet Estimation Zugangsbeschränkung und Gebührenabrechnung Zusammenstellung adäquater Projektdaten Interaktive Präsentation der Schätzung Beurteilung und Entwicklungspotenzial Benchmarking Der projektspezifische Benchmarking Report Der unternehmensinterne Project Visualizer Beurteilung und Entwicklungspotenzial Ausgewählte Aspekte der Realisierung UML-Modellierungen für Spezifikation und Entwurf Prototypische Entwicklung der CAME-Werkzeuge Absicherung der persistenten Datenhaltung Konzeptioneller Datenbankentwurf Logischer Datenbankentwurf Datenbankdefinition Die Project Database und Project Visualizer... 91

8 VI Inhaltsverzeichnis Generelle Bemerkungen zur Entwurfsentscheidung Die Realisierung ausgesuchter Funktionalitäten Das Applet Estimation Die Realisierung ausgesuchter Funktionalitäten Installation und Anpassung des Jetspeed Portal-Servers Installation Modifikation des äußeren Erscheinungsbildes Einbindung der CAME-Werkzeuge als Portlets Das Anlegen neuer Benutzer Zusammenfassung 109 Literaturverzeichnis 111 Anhang A A1. Textteil der Studie aus dem Laborpraktikum Anhang B B1. UML-Modellierungen B2. Datenbankdefintion B3. MVC-Elemente der Formularverarbeitung B4. Installationsprotokoll von Jetspeed Selbständigkeitserklärung 167

9 Abbildungsverzeichnis VII Abbildungsverzeichnis Abbildung 1: Kategorien des Software-Managements... 7 Abbildung 2: Kybernetischer Schätz-Regelkreis... 9 Abbildung 3: Das Teufelsquadrat von Sneed Abbildung 4: Schema zur Anwendung einer Skala Abbildung 5: Ein Beispiel zur GQM-Methode Abbildung 6: Prinzipielles Vorgehen der Funktionalen Größenmessung Abbildung 7: Entwicklung der Methoden zur funktionalen Größenmessung Abbildung 8: Elemente der IFPUG FPA Abbildung 9: Elemente der Mark II FPA Abbildung 10: Elemente der COSMIC Full Function Points Abbildung 11: Die Streuung der Schätzgenauigkeit beim Projektverlauf Abbildung 12: Günstige Zeitpunkte für Aufwandschätzungen Abbildung 13: Funktionale und systemtechnische Anforderungen an Portale Abbildung 14: Klassifikation nach dem Spezialisierungsgrad Abbildung 15: Klassifikation nach dem Interaktionsgrad Abbildung 16: Ausprägungen von B2E-Unternehmensportalen Abbildung 17: Das Referenzmodell für Portale Abbildung 18: Strukturierung möglicher Inhalte Abbildung 19: Schichtenmodell der Anwendungsintegration Abbildung 20: Situation im Marksegment im April Abbildung 21: Veränderte Situation im Marktsegment im März Abbildung 22: Argumente für die Einführung von Unternehmensportalen Abbildung 23: Potenzielle Favoriten der Portal-Software Abbildung 24: Übersicht der Evaluationsergebnisse Abbildung 25: Das MVC-Entwurfsmuster Abbildung 26: Die fünf Assembler-Elemente und die Komposition zu einer Antwortseite 64 Abbildung 27: Der Anfrage-Antwort-Zyklus beim Assembler-Service Abbildung 28: Ein Erfassungsbogen innerhalb der Projektdatenbank Abbildung 29: Zugangsbeschränkung beim Estimation Abbildung 30: Die Auswahl adäquater Projektdaten beim Estimation Abbildung 31: Die interaktive Präsentation der Schätzung Abbildung 32: Der projektspezifische Benchmarking Report Abbildung 33: Der unternehmensinterne Project Visualizer Abbildung 34: Use-Case-Diagramm für die Portallösung Abbildung 35: Komponentendiagramm für die Portallösung Abbildung 36: Aktivitätendiagramm für die Portallösung Abbildung 37: Konzeptioneller Datenbankentwurf mit dem ER-Modell Abbildung 38: Abbildung des MVC-Entwurfsmusters auf die 3-tier Architektur Abbildung 39: Schema für die Abbildung der Formulare auf Dateinamen Abbildung 40: Sequenzdiagramm für die Formularverarbeitung und -validierung Abbildung 41: Das Java RMI Kommunikationsmodell Abbildung 42: Sequenzdiagramm der allgemeinen Vorgehensweise bei RMI

10 VIII Tabellenverzeichnis und Verzeichnis der Kode-Fragmente Tabellenverzeichnis Tabelle 1: Eigenschaften verschiedener Skalentypen Tabelle 2: Werte von t α Tabelle 3: Einflussfaktoren für die Aufwandsschätzung Tabelle 4: Ausprägungen von Geschäftsbeziehungen und die Realität (schwarz) Tabelle 5: Übersicht zu B2X -Unternehmensportalen Tabelle 6: Evaluationskriterien zur Portalstudie der CSC Ploenzke AG Tabelle 7: Durch Turbine bereitgestellte Dienste Tabelle 8: Standard-Portlets in Jetspeed Verzeichnis der Kode-Fragmente Kode-Fragment 1: Vergleich der Generierung einer HTML-Seite über Java und ECS.. 67 Kode-Fragment 2: Ein Eintrag in der PortletRegistry Kode-Fragment 3: Eine PSML-Seitenbeschreibung für den Standardbenutzer Kode-Fragment 4: Die SQLConnectionBean für die Datenbank-Interaktion Kode-Fragment 5: Einbindung der SQLConnectionBean in eine JSP-Seite Kode-Fragment 6: Ausprägung der Konfigurationsdatei db.properties Kode-Fragment 7: Import der benötigten Java-Ressourcen für das Cewolf -Pake Kode-Fragment 8: Erzeugung eines Datasets für Diagrammerzeugung Kode-Fragment 9: Anpassung und Veranlassung der Generierung in einer JSP Kode-Fragment 10: Definition des RemoteInterface Kode-Fragment 11: Die Anmeldung eines entfernten Objekts an der RMI-Registrierung 102 Kode-Fragment 12: Clientseitiger Zugriff auf die entfernten Objekte Kode-Fragment 13: MouseAdapter für die Intervalldisposition Kode-Fragment 14: Sortierung des Vektors der Intervallgrenzen Kode-Fragment 15: Berechnung und Ausgabe innerhalb der Intervallgrenzen Kode-Fragment 16: Die Registrierung einer Instanz des IFramePortlet

11 Abkürzungsverzeichnis IX Abkürzungsverzeichnis ACID AEMESD API ASMA B2B B2C B2E B2P CAME CARE CASE CD-ROM CMM CMS COCOMO COM CORBA COSMIC CRM CSC DASMA DB DBMS DCOM DDL DDR DIN DML DOM EAI EAP ECP ECS EEP EIP EJB EKP ER ERP ÉTS FAZ FFP FP FPA FSeMP FSM FUR GQM GUFPI HSQL Atomarity, Consistency, Isolation and Durability Association Espanola des Metrics del Software Application Programming Interface Australian Software Metrics Association Business-to-Business Business-to-Consumer Business-to-Employee Business-to-Public Computer-Assisted Measurement and Evaluation tools Computer-Aided ReEngineering tools Computer-Assisted Software Engineering tools Compact Disc - Read Only Memory Capability Maturity Model Content Management System Constructive Cost Model Component Object Model Common Object Request Broker Architecture The Common Software Metrics International Consortium Customer Relationship Management Computer Sciences Corporation Ploenzke AG Deutschsprachiger Anwenderverband für Softwaremetriken und Aufwandsschätzung e.v. Datenbank Datenbank-Managementsystem Distributed COM Data Definition Language Defects Delivery Date Deutsches Institut für Normung e.v. Data Manipulation Language Document Object Model Enterprise Application Integration Enterprise Application Portal Enterprise Collaborative Portal Element Construction Set Enterprise Expertise Portal Enterprise Information Portal Enterprise JavaBeans Enterprise Knowledge Portal Entity-Relationship Enterprise Ressource Planning École de technologie supérieure Frankfurter Allgemeine Zeitung Full Function Point Function Point(s) Function Point Analysis Functional Size emeasurement Portal Functional Size Measurement Functional User Requirements Goal Question Metric Gruppo Utenti Function Point Italia Hypersonic-SQL

12 X Abkürzungsverzeichnis HTML HTTP IBM ID IDL IEC IFPUG ISBSG ISO IT J2EE J2SDK JCP JDBC JFPUG JSP JSR LOC MIS MVC NASSCOM NESMA OCS ODBC OLAP OMG ONE OSI PDA PDF PET PPL PSML PSP RDBMS RDF RPC RMI RSS SAP SAQ SAX SEI SEMRL SLIM SMLab SoD SQL SQP SSE SSL SSO SST SWE TCL TLD HyperText Markup Language HyperText Transfer Protocol International Business Machines Identificator Interface Definition Language International Electronical Commission International Function Point Users Group The International Software Benchmarking Standards Group International Standardization Organization Informationstechnologie Java 2 Enterprise Edition Java 2 Software Development Kit Java Community Process Java Database Connectivity Japanese Function Point Users Group Java Server Pages Java Specification Request Lines of Code Management Information System Model-View-Controller National Association of Software and Service Companies Netherlands Software Metrieken Gebruikers Associate Open Content Syndication Open Database Connectivity Online Analytical Processing Object Management Group Open Net Environment Open Systems Interconnection Personal Digital Assistant Portable Data Format Project Elapsed Time Primary Programming Language Portal Structure Markup Language Personal Software Process Relationales DBMS Resource Description Format Remote Procedure Calls Remote Method Invocation RDF Site Summary Systems, Applications & Products in Data Processing Swiss Association for Quality Simple API for SAX Software Engineering Institute Software Engineering Management Research Laboratory Software Lifecycle Management Software Measurement Laboratory Speed of Delivery Structured Query Language Software Quality Program Error Sum of Squares Secure Socket Layer Single Sign-On Total Sum of Squares Summary Work Effort Tool Control Language Tag Library Descriptor

13 Abkürzungsverzeichnis XI TPM UKSMA UML UQAM URL VAF VPN WAP XML XSL XSLT Transaction Processing Monitor The United Kingdom Software Metrics Association Unified Modelling Language Université du Québec à Montréal Uniform Resource Locator Value Adjustment Factor Virtual Private Networking Wireless Application Protocol extensible Markup Language extensible Stylesheet Language XSL Transformations

14

15 1 Einleitung 1 1 Einleitung 1.1 Motivation Mit fortschreitender, zeitlicher Entwicklung erlangten Computer und ihre Anwendungen einen derart hohen Stellenwert, dass sie aus unserem Alltag kaum noch wegzudenken sind und sich mehr und mehr zum kritischen und integralen Bestandteil für nahezu alle Bereiche unseres Lebens entwickelt haben. So schützen heutzutage beispielsweise computergestützte Fahrassistenz- und Sicherheitssysteme in Kraftfahrzeugen unzählige Fahrzeuginsassen vor den Folgen schwerwiegender Verkehrsunfälle oder retten deren Menschenleben in Kliniken über intelligente, lebenserhaltende Geräte sowie durch von menschlichen Experten ferngesteuerte Operationsroboter, die besonders bei medizinisch komplizierten Eingriffen zum Einsatz kommen. Vor allem aber auch im Bereich der Forschung und Entwicklung ist der Einsatz von Computern und Software heute unabdingbar, da er den Prozess des Gewinnens von Erkenntnissen ungemein beschleunigt. Demzufolge stellt sich die Software-Entwicklung als ein Wirtschaftszweig mit einer großen Bedeutung und einem hohen sowohl volkswirtschaftlichen als auch evolutionären Potenzial dar. Trotz dieser immensen Attraktivität und der Aussichten auf hohe Ertragschancen bestehen aber enorme Risiken im Hinblick auf marktwirtschaftliche Aspekte. Nicht unerhebliche Einflussfaktoren sind dabei die fortwährende Globalisierung und der dadurch stetig wachsende, weltweite Konkurrenzdruck. Das resultierende Überangebot an Entwicklungspotenzial in der Software-Branche führte schon vor einigen Jahren zu einem Wechsel der makroökonomischen Marktlage. Ausgehend von einem Verkäufermarkt, bei dem üblicherweise der Auftragnehmer den Preis bestimmt, wandelte sich die Situation zu einem Käufermarkt, bei dem der Auftraggeber auf Grund eines Überangebots über den besten Preis verhandeln kann. [Kindler 1995] Deshalb drängt sich zur Erhaltung der Wettbewerbsfähigkeit und Existenzsicherung die Notwendigkeit auf, so effizient wie möglich Software zu produzieren. Dazu muss das Management eines Unternehmens in der Lage sein, vor einer Angebotsabgabe in der Software-Entwicklung geeignete Maßnahmen zur Prognose ökonomischer Eckdaten und treibender Kostenfaktoren, zur Bewertung von Risiken sowie zur Qualitätssicherung zu ergreifen. Den Entscheidungsträgern stehen dabei die ingenieur-wissenschaftlichen Herangehensweisen des Software-Engineering [Dumke 2000] helfend zur Seite, im Speziellen die Software-Messung, die Merkmalsab- und Aufwandschätzung sowie das Benchmarking. Grundlage aller Betrachtungen sind die im Zuge der Software-Messung an abgeschlossenen und laufenden Entwicklungsprojekten ermittelten Rahmendaten ( business data ), wie zum Beispiel die funktionale Größe der ausgelieferten Software, die letztendliche Projektdauer aufgeschlüsselt nach den benötigten Qualifikationen der Mitarbeiter oder auch die Anzahl der nicht behobenen Defekte. Meist verfügt man jedoch über ein zu geringes oder nur homogenes Repertoire solcher Rahmendaten. Infolgedessen bietet sich die Möglichkeit an, auf eine extern erstellte Datenbasis wie sie zum Beispiel von dem australischen, nicht-kommerziellen Fachverband ISBSG angeboten wird, zurückzugreifen. Diese enthält unzählige, freiwillig beigesteuerte Informationen heterogener Entwicklungsprojekte namhafter Klassenbester der Branche in anonymisierter Form.

16 2 1 Einleitung Auf der Basis einer Vielzahl dieser ermittelten oder extern bereit gestellten Informationen lassen sich mit Hilfe Tool-gestützter, statistischer Methoden und algorithmischer Schätzmodelle ungefähre und mitunter sogar auch ziemlich präzise Aussagen über ökonomisch essentielle Merkmale, besonders über den zu erwartenden (Personal-)Aufwand und damit die Entwicklungskosten der zu erstellenden Software, treffen. Ohne diese Option wäre man auf die häufig voneinander abweichenden Beurteilungen und Prognosen meist nur extern verfügbarer, kostenintensiver Experten mit einem reichhaltigen Erfahrungsschatz angewiesen. Für die stetige Verbesserung innerhalb des Software-Entwicklungsprozesses sowie firmeninterner Geschäftsprozesse eignet sich das Benchmarking besonders. In Zusammenwirkung mit Visualisierungen interner aber speziell auch externer Projektdaten dient es zur Verdeutlichung volkswirtschaftlicher und software-technischer Zusammenhänge. Über den stetigen Vergleich mit den besten, in der Branche vorherrschenden Praktiken ( best practices ) und eine realistische und selbstkritische Zustandsbewertung kann sich eine Leistungslücke ( performance gap ) offenbaren, der dann mit geeigneten Maßnahmen begegnet werden kann. Vor allem die Visualisierung ermöglicht es dem Management, den ausführenden Software-Entwicklern aber auch interessierten Kunden, Zusammenhänge auch ohne vertieftes Fachwissen zügig und umfassend zu durchschauen. [Camp 1994] 1.2 Zielstellung Die schon seit geraumer Zeit andauernde Globalisierung nicht nur in der Software-Branche schlägt sich unter anderem in einer internationalen Arbeitsteilung aus Kostengründen nieder, um dem Konkurrenzdruck weiterhin gewachsen zu sein. So geht der Trend [laut Kindler 1995] gegenwärtig dahin, nur noch die Angebotserstellung und die frühen Phasen der Software-Entwicklung, angefangen von der Problemdefinition und Anforderungsanalyse über die Spezifikation bis hin zum Entwurf, in den Ländern West- Europas, den USA oder Japan durchzuführen. Die eigentliche Implementierung, der Test und die Auslieferung geschehen dann meist in Indien, China oder Pakistan auf Grund des niedrigeren Lohnniveaus, wobei beschäftigungspolitische Nachteile billigend in Kauf genommen werden müssen. Die globale Zusammenarbeit auf dem Gebiet der Software-Entwicklung profitiert allgemein in hohem Maße von der Unterstützung durch moderne Kommunikationsmedien. Speziell das Potenzial des Internets in Kombination mit dem von Portallösungen bietet ungeahnte Möglichkeiten für Organisationen, sich gegenüber Interessenten oder Kunden über das Extranet zu präsentieren oder mit den eigenen Mitarbeitern über das Intranet in Kontakt zu treten, sie zu leiten, weiterzubilden, zu informieren oder zur gemeinsamen Entscheidungsfindung beziehungsweise gegenseitigen Unterstützung zu motivieren. Aus diesem Grund besteht das Ziel dieser Diplomarbeit darin, auf der Grundlage eines bestehenden Konzeptes den Entwurf und die prototypische Implementierung eines Portals für die Software-Messung, die Merkmalsabschätzung und das Benchmarking mit wissenschaftlichem Hintergrund und in enger Zusammenarbeit mit dem Fachverband ISBSG und der Otto-von-Guericke-Universität Magdeburg durchzuführen. Besonderes Augenmerk sollte dabei auf die Realisierung eines integrativen Ansatzes gelegt werden, der die ortsunabhängige und personalisierbare Nutzung von selbst entwickelten Software-Werkzeugen aus dem angesprochenen Problemkreis gewährleistet. Ferner soll das praktische Ergebnis dieser Arbeit ein Fundament für die Erweiterung zum Beispiel um Aspekte des elearning und der ecollaboration legen und damit Ansatzpunkt für weitere wissenschaftliche Arbeiten sein.

17 1 Einleitung Aufbau der Diplomarbeit Die vorliegende Diplomarbeit beschäftigt sich mit dem Entwurf und der prototypischen Implementierung eines Portals für die Software-Messung, die Merkmalsabschätzung und das Benchmarking, auf das sich im Folgenden in Anlehnung an die Diplomarbeit von D. Winkler als Functional Size emeasurement Portal (FSeMP) bezogen wird [Winkler 2003]. Dazu werden im zweiten Kapitel die theoretischen Grundlagen für die im weiteren Verlauf behandelten Themenkreise Software-Messung, Merkmalsabschätzung und Benchmarking gelegt sowie das Konzept für die Anwendung eines integrierten Portalansatzes weiter motiviert und spezifiziert. Im dritten Kapitel werden dann die allgemeine Portal-Technologie erläutert, wichtige Anforderungen bestimmt und technologische Hintergründe kurz dargelegt. Letztendlich können dann auf der Basis einer durchgeführten Marktstudie zwei potenzielle Kandidaten für die anschließende Realisierung des FSeMP auserkoren werden, wobei die getroffene Design-Entscheidung näher beleuchtet wird. Darauf folgend ist das vierte Kapitel der funktionalen Vorstellung der Portallösung gewidmet. Es beschreibt die angebotene Funktionalität, beurteilt die Implementierung und zeigt weiterhin mögliche Entwicklungspotenziale auf. Anhand des fünften Kapitels sollen ausgewählte Aspekte der Realisierung aufgezeigt werden. Einerseits wird dazu die gewählte Portal-Lösung charakterisiert, andererseits werden die technologischen Besonderheiten, Erfahrungen und die Bewertung der selbst entwickelten Software-Werkzeuge und der Portallösung dargestellt. Schließlich fasst das sechste Kapitel die Diplomarbeit noch einmal zusammen und gewährt einen Ausblick auf darauf aufbauende, folgende wissenschaftliche Projekte.

18 4 1 Einleitung

19 2 Software-Messung, Merkmalsabschätzung und Benchmarking 5 2 Software-Messung, Merkmalsabschätzung und Benchmarking 2.1 Begriffsklärungen Zunächst soll die Bedeutung der im weiteren Verlauf verwendeten Begriffe geklärt werden, bevor auf ihre Besonderheiten eingegangen werden kann. Software-Messung: Die Fachliteratur [Dumke 2000, S.151] definiert den Terminus der Software-Messung wie folgt: Software-Messung (software measurement) ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineering mit der Ausrichtung auf spezielle Messziele (measurement goals) und der ggf. Einbeziehung von Messwerkzeugen (measurement tools). Dabei können die Messziele mannigfaltiger Natur sein und sich auf alle Teilaspekte (Produkte, Prozesse, Ressourcen) der Software-Entwicklung beziehen. Die Auswahl der korrekten und adäquaten Messziele ist eine essentielle Voraussetzung und Grundlage für die erfolgreiche Merkmalsabschätzung und das Benchmarking. Es werden bei der Software-Messung neben direkt oder auch physikalisch messbaren Merkmalen wie Größe und Zeit auch so genannte indirekt oder nur empirisch messbare Merkmale, wie zum Beispiel das Fehlerverhalten, die Benutzerfreundlichkeit oder die Zuverlässigkeit erhoben, die auf dem Hintergrund der Erfahrungen in der Software- Entwicklung und -Anwendung beruhen und unter Umständen mit Hilfe der GQM hergeleitet werden. [Dumke 2000] Merkmalsabschätzung: Unter einer Merkmalsabschätzung versteht Dumke die Prognose beziehungsweise Vorhersage zu erwartender Charakteristika der Software-Entwicklung und -Wartung auf der Basis einer vorgegebenen Formel bzw. allgemein gehaltenen Berechnungsvorschrift bezüglich eines speziellen Merkmals oder einer gesamten Merkmalsgruppe. [Dumke 2002a] Derartige Schätzaufgaben können beispielsweise die Prognose der Kosten der Software- Entwicklung für eine Entwicklungsphase oder auch das gesamte Entwicklungsprojekt, die Abschätzung der Qualitätsmerkmale nach der ISO 9126 sowie eine Aufwandserhebung für einzelne Entwicklungsphasen oder das gesamte Software-Projekt sein. Benchmarking: Das Benchmarking in seiner ursprünglichen Form wurde unter der Bezeichnung competitive benchmarking schon im Jahre 1979 von dem damals größten, nordamerikanischen Druckerund Kopiererhersteller, der Xerox Corporation, erstmals zum Vergleich von Qualität, Eigenschaften und Kosten eines eigenen Produktes mit dem einer konkurrierenden Organisation angewendet. David T. Kearns (adaptiert von [Camp 1994]), der lange Zeit Geschäftsführer der Xerox Corporation war, definierte daher Benchmarking derart: Benchmarking ist der kontinuierliche Prozess, Produkte, Dienstleistungen und Praktiken zu messen gegen den stärksten Mitbewerber oder die Firmen, die als Industrieführer angesehen werden.

20 6 2 Software-Messung, Merkmalsabschätzung und Benchmarking Diese formale Definition wurde von Camp aufgegriffen und die vier Kernaussagen detaillierter erklärt [Camp 1994]: 1. Es herrscht die Notwendigkeit eines kontinuierlichen Prozesses, da Benchmarking ein stetiger Vorgang der Selbsteinschätzung und -verbesserung sowie ein permanenter Managementprozess ist, der trotz fortwährender Dynamik der ökonomischen Einflüsse ein gewisses Maß an Effizienz gewährleistet. 2. Das Bestimmen der besten Industriepraktiken ( best practices ) zur Erlangung einer Überlegenheit geschieht im Rahmen einer qualitativen, wörtlichen Beschreibung. Allerdings ist auch eine Quantifizierung für eine spätere, analytische Auswertung zur Effizienzbestimmung über das Messen der Resultate der führenden Unternehmen möglich. 3. Nahezu alle Aspekte des Geschäftlebens eignen sich hervorragend, um von einem erfolgreichen Benchmarking zu profitieren. 4. Firmen, die als Industrieführer angesehen werden, bedürfen einer kritischen, vorherigen Überprüfung, um unerwünschte Effekte und Einflüsse wie Skrupellosigkeit oder sogar illegale Vorgänge a priori auszuschließen. Schließlich bringt Camp diese Auffassungen in einer Arbeitsdefinition auf einfache Weise zum Ausdruck: Benchmarking ist die Suche nach den besten Industriepraktiken, die zu Spitzenleistungen führen. [Camp 1994, S. 16] Die im Folgenden häufig verwendeten Begriffe Projekt und Aufwand sollen nun erläutert werden: Projekt: Die Übersetzung des Wortes Projekt aus dem Lateinischen als Planung, Entwurf oder Vorhaben [Duden 1996] erscheint recht allumfassend. Eine Konkretisierung des Terminus im Hinblick auf die Software-Entwicklung liefert dann jedoch Dumke: Ein Projekt (project) ist der konkrete Prozess zur Entwicklung eines konkreten Software-Produkts mit den dafür notwendigen Ressourcen. [Dumke 2000, S. 8] Im Allgemeinen wird in einem Projekt eine Vision erstmals unter Mithilfe einer besonderen Form der Projektorganisation und mit einem begrenzten Budget verwirklicht. [Knöll 1991] Aufwand: Die Betriebswirtschaftslehre definiert nach Knöll den Aufwand allgemein als den gesamten Wertverbrauch einer Abrechnungsperiode. [Knöll 1991] Verfolgt man nun jedoch das Ziel der Erfolgs- und Wirtschaftlichkeitsbestimmung, so kann man sich an der Präzisierung des Begriffs durch Lücke in [Knöll 1991, S.17] orientieren: Aufwand ist der für die Zwecke der Erfolgsermittlung erfasste Verbrauch an Gütern und Dienstleistungen in einer Periode. Bildet man diese letztgenannte Definition auf den Problemkreis der Software-Entwicklung ab, so erhält man den Verzehr von Ressourcen als treibenden Kostenfaktor. Insbesondere die zeitliche Bindung qualifizierten Personals spielt gegenüber der fast zu vernachlässigenden aufzuwendenden Maschinenleistung und dem benötigten Material eine wichtige Rolle. Die Multiplikation des Aufwandes mit einem speziell für die Entwicklungsumgebung ermittelten Verrechnungssatz hat als Ergebnis die Kosten zur Folge. [Knöll 1991]

21 2 Software-Messung, Merkmalsabschätzung und Benchmarking Einordnung in das Software-Management Eine herausgestellte Bedeutung für das Software-Ingenieurwesen hat das Software- Management, wobei es Dumke wie folgt definiert: Das Software-Management (software management) ist die Planung, Überwachung und Steuerung des Prozesses und der dabei einzusetzenden Ressourcen zur Entwicklung, Wartung und Anwendung von Software- Systemen. [Dumke 2000, S. 183] Die im Zuge der Anwendung des Software-Managements auftretenden Aufgaben und Herausforderungen sollen in Abbildung 1 illustriert werden. Software-Management Entwicklungsmanagement Wartungsmanagement Anwendungsmanagement Projektmanagement (SLIM, COCOMO, FSM) Qualitätsmanagement (ISO 9000, CMM, GQM) Konfigurationsmanagement (Änderungssteuerung, usw. ) Konfigurationsmanagement Nothilfemanagement Einsatzmanagement Umstellungsmanagement Havariemanagement Erfahrungen Schätzformeln Messungen Abbildung 1: Kategorien des Software-Managements (nach [Dumke 2000]) Die für die weiteren Betrachtungen und die Thematik dieser Diplomarbeit wichtigen Teilaspekte des Entwicklungsmanagements sind das Projektmanagement und das Qualitätsmanagement, welche nachfolgend näher beleuchtet werden Projektmanagement Die einschlägige Literatur [Dumke 2000, S. 192] definiert das Projektmanagement derart: Das Projektmanagement (software project management) beinhaltet die planenden, kontrollierenden und steuernden Aktivitäten für die termingerechte Bereitstellung der Ressourcen und der kostengerechten Realisierung eines Software-Produktes. Dabei unterscheidet man es nach Bundschuh [Bundschuh 2000] in das operative (auf Projektebene) und strategische (globale Sicht) Projektmanagement. Neben der Projektsteuerung ( controlling ) und der Risikobewertung ist die Aufwandsbeziehungsweise Kostenschätzung zur Bewältigung der entstehenden Entropie wesentlicher Bestandteil des operativen wie auch strategischen Projektmanagements.

22 8 2 Software-Messung, Merkmalsabschätzung und Benchmarking Aufgaben des Projektmanagements: Zu den Herausforderungen des Projektmanagements zählen nach Sneed die Systemdefinition, die Projektkalkulation, -planung und -steuerung sowie die Systemverwaltung. [Sneed 1987] Bei der Systemdefinition kommt es auf die Bestimmung der Qualitätsanforderungen sowie auf die Einordnung der Datenbereiche und Funktionen im Rahmen der Definition des zu erstellenden Systems an. Im Zuge der Projektkalkulation wird dann versucht, den zu erwartenden Aufwand und die daraus resultierenden Kosten abzuschätzen. Im Allgemeinen geschieht das auf der Grundlage des gemessenen Programmumfangs in Kombination mit der Projektdauer, der Produktivität des Entwicklerpersonals und einem adäquaten Verrechnungssatz. Während des Prozesses der Projektplanung hingegen konzentriert man sich auf die Organisation und die Verteilung der anfallenden Aufgaben. Die Projektsteuerung ( controlling ) erweist sich dann für die Bewältigung der Entropie, das heißt die Nichteinhaltung der geforderten Qualitätsstandards oder Termine, als sehr nützlich. Schließlich zeichnen die Aktivitäten der Systemverwaltung für anstehende Fehlerbereinigungen und sowohl technische als auch konzeptionelle Änderungen am System verantwortlich Operatives Projektmanagement (Projektcontrolling) Die über den gesamten Bearbeitungszeitraum eines Software-Entwicklungsprojekts hinweg Anwendung findenden Methoden und Hilfsmittel des so genannten Projektcontrollings beziehungsweise operativen Projektmanagements sollen hauptsächlich zur Determination, Kontrolle und Steuerung sowohl der qualitativen und kostentechnischen als auch der terminlichen Rahmenrichtlinien eines Entwicklungsvorhabens dienen. Hierfür besonders bedeutsame Hilfsmittel sind die operative Aufwandsschätzung und das operative Benchmarking, welche deshalb im Folgenden näher betrachtet werden. Operative Aufwandsschätzung Innerhalb des operativen Projektmanagements macht man sich die operative Aufwandsschätzung zu Nutze, um der Projektleitung rechtzeitig, komprimiert und problemadäquat Informationen über den Fortschritt des Entwicklungsprojektes zur Verfügung zu stellen. Dementsprechend [Bundschuh 2000] sind verschiedene, teils umfangreiche Aufgaben wahrzunehmen. Zuerst müssen auf der Basis solider und fundierter Aufwandsschätzungen die so genannten Soll-Aufwände festgelegt werden. Danach ist es erforderlich, kontinuierlich und gewissenhaft die tatsächlich geleisteten Ist-Aufwände für die respektiven Teilaufgaben des IT-Projekts zu erfassen, um sie im darauf folgenden Schritt mit dem prognostizierten Aufwand zu vergleichen. Daraufhin kann eine Ursachenanalyse eventuelle Abweichungen aufzeigen und Vorschläge für die weitere Projektplanung liefern. Kybernetischer Regelkreis: Der laut Duden [Duden 1996] aus dem Griechischen stammende Terminus der Kybernetik bezeichnet die wissenschaftliche Forschungsrichtung, die sich mit gegenüberstellenden Betrachtungen von Steuerungs- und Regelvorgängen beschäftigt. Sie ist laut ihrem Erfinder (adaptiert von [Bundschuh 2000]), Norbert Wiener, die Wissenschaft vom Verhalten komplizierter Systeme, bei denen Rückkopplungs- und Informationsaustauschprozesse eine wichtige Rolle spielen.

23 2 Software-Messung, Merkmalsabschätzung und Benchmarking 9 Kybernetische Regelkreise stellen sich nach Bundschuh als lenkbare Systeme dar, die über die Fähigkeit verfügen, sich selbst zu steuern. Somit offenbart sich im Zusammenwirken mit der operativen Aufwandsschätzung die exzellente Eignung zur direkten Unterstützung des operativen Projektmanagements. [Bundschuh 2000] Ein derartiger kybernetischer Regelkreis (vgl. Abbildung 2) besteht aus vier bestimmenden Komponenten: einem Regler, einem Stellglied, einer Regelstrecke sowie einem Messglied. Zu den Aufgaben des Reglers gehört das Empfangen von Messinformationen aus Richtung des Messgliedes, die Entscheidungsfindung und die Weitergabe der Zielvorgabe an das Stellglied. Das Stellglied hingegen bestimmt geeignete Aktionen zur Erreichung der Zielvorgabe und gibt diese Information zusammen mit der Zielvorgabe an die Regelstrecke weiter, welche diese Aktionen dann erledigen muss. Dabei ist anzumerken, dass verkürzte Regelstrecken, zum Beispiel in Form des zeitlichen Abstands, der besseren Dosierung der Maßnahmen zur Beeinflussung des Systems zugute kommen. Schließlich ermittelt das Messglied die Stufe der Zielerreichung sowie Anlässe für eventuelle Divergenzen zur Zielvorgabe und reicht diese Daten an den Regler weiter, woraufhin dann der Kreislauf von neuem beginnen kann. Diese Zirkulation charakterisiert Bundschuh als Rückkopplungsprozess (feedback), der zu einem Fließgleichgewicht (Homöostase) oder vielmehr zu einem sich bei störungsfreiem Ablauf selbst regulierenden System führt. [Bundschuh 2000, S. 57] Abbildung 2 verdeutlicht die Vorgehensweise der operativen Aufwandsschätzung anhand eines kybernetischen Regelkreises, beginnend beim Regler. Projektaufgabe Regler (Aufwandsschätzung) Abweichung Ausgangswert Messglied (Soll-/Ist-vergleich) Stellglied (Abgleich Wissensbasis) Ist-Wert Schätzwert Regelstrecke (Aufgabendurchführung) Störungen Abbildung 2: Kybernetischer Schätz-Regelkreis (adaptiert von [Bundschuh 2000]) Operatives Benchmarking Während des operativen Benchmarking werden eine umfassende Analyse und eine anschließende Gegenüberstellung der Merkmale sowie Vor- und Nachteile eines Konkurrenzproduktes mit einer zu großen Teilen ähnlichen Eigenentwicklung durchgeführt.

24 10 2 Software-Messung, Merkmalsabschätzung und Benchmarking Diese, im weiteren Verlauf als Wettbewerbs-Benchmarking im externen Bereich erläuterte Form des Benchmarking wird in der Literatur (adaptiert von [Sirma 2003]) meist in einem Atemzug mit dem product reverse engineering, der Konkurrenzproduktanalyse, genannt Strategisches Projektmanagement Als primäre Zielstellung des strategischen Projektmanagements lässt sich die kontinuierliche Verbesserung des Prozesses des operativen Projektmanagements, insbesondere der operativen Aufwandsschätzung, der Projektplanung und -realisierung, manifestieren. Aus diesem Grund ist es notwendig, fortwährend unternehmensweite, bedeutsame Kostenund Hinderungsfaktoren sowie effiziente Methoden und Werkzeuge zur Unterstützung des operativen Projektmanagements zu identifizieren. Dies geschieht zum einen über die Durchführung einer strategischen Aufwandsschätzung und zum anderen über das interne und externe Benchmarking. Strategische Aufwandsschätzung Die Strategische Aufwandsschätzung beschäftigt sich mit der stetigen Weiterentwicklung der Methoden und Standards für die Planung und Durchführung der operativen Aufwandsschätzung. Dafür ist es notwendig, Erfahrungen aus vergangenen Prognosen korrekt zu dokumentieren und zur Verbesserung und Bewältigung zukünftiger Abschätzungen zur Verfügung zu stellen ( feed forward ). [Bundschuh 2000] Weiterhin ist die kritische Hinterfragung von Messgrößen wie dem Programmumfang, auf der die meisten Aufwands- und Kostenschätzungen basieren, genauso wie die Identifikation von weiteren, beeinflussenden Faktoren in diesem Zusammenhang von enormer Bedeutung. Strategisches Benchmarking Die Angleichung oder das Übertreffen der Parameter des Geschäftsprozesses der Software- Entwicklung aus dem selbstkritischen Vergleich mit den so genannten Klassenbesten auch aus unterschiedlichen Branchen fasst man unter dem Begriff strategisches Benchmarking zusammen. In der Literatur wird der Terminus des Allgemeinen Benchmarking im externen Bereich häufig synonym verwendet. [Camp 1994] Interdependenzen: Das Teufelsquadrat Die primären Zielvorgaben des Projektmanagements, das heißt die Qualität, die Quantität, die Projektdauer und die Kosten, konkurrieren um die verfügbare Kapazität an Ressourcen innerhalb des IT-Projekts. [Bundschuh 2000] Diese gegenseitige Abhängigkeit verdeutlicht das Teufelsquadrat von Sneed [Sneed 1987], wie es in Abbildung 3 dargestellt ist. Durch den determinierten Umfang des inneren Vierecks wird die begrenzte Kapazität an Ressourcen beziehungsweise Produktivität symbolisiert. Deshalb ruft auf Grund dieses limitierten Umfangs der Mehrverbrauch einer Zielvorgabe die Verknappung an Ressourcen eines oder mehrerer anderer Ziele hervor. [Knöll 1991]

25 2 Software-Messung, Merkmalsabschätzung und Benchmarking 11 Qualität + Quantität + a - - b d + + c - - Projektdauer Kosten Abbildung 3: Das Teufelsquadrat von Sneed (adaptiert von [Knöll 1991]) Softwarequalitätsmanagement Als Softwarequalitätsmanagement definiert Dumke (siehe [Dumke 2002a]) die Sicherung von Qualitätsmerkmalen für das Software-Produkt auf der Grundlage der Produkt-, Prozessund Ressourcenqualität durch organisatorische Maßnahmen unter Anwendung spezieller Techniken und Technologien. Diese Begriffsbildung von Professor Dumke geht dabei davon aus, dass sich die Software-Qualität als die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse bezieht, deuten lässt Qualitätsaspekte Aus der vorangestellten Auslegung des Terminus Softwarequalitätsmanagement wird die notwendige Kategorisierung in Produkt-, Prozess- und Ressourcenqualität deutlich sichtbar. Produktqualität: Software-Produktqualität lässt sich aus den unterschiedlichsten Blickwinkeln betrachten. So beurteilt sie der Anwender meist nur nach den für ihn wichtigen funktionalen Kernaspekten, der so genannten externen Qualität. Hingegen die Software-Entwickler ermessen die für sie essenzielle interne Qualität meist nach software-technischen Gesichtpunkten anhand des Quellkodes, des Entwurfsprozesses sowie der verwendeten selbst entwickelten oder akquirierten Komponenten. Schließlich betrachtet der Projektmanager in aller Regel die Produktqualität keinesfalls losgelöst von der Wirtschaftlichkeit seines Projektes. Dieser Aufteilung nach den verschiedenen Sichten folgt der internationale Standard ISO 9126 beziehungsweise das deutsche Pendant DIN für Produktqualität in der Software- Entwicklung. Zudem disponiert die ISO 9126 zur Vereinfachung und Schematisierung der Qualitätsbestimmung die zur Bewertung herangezogenen Merkmale nach Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit, wobei die Gewichtung der einzelnen Merkmale dann vom jeweiligen Anwendungskontext abhängt (vgl. [Liggesmeier 2002]).

26 12 2 Software-Messung, Merkmalsabschätzung und Benchmarking Prozessqualität: In der Fachliteratur findet man häufig die folgende Interpretation des Begriffes der Prozessqualität für das Umfeld der Software-Entwicklung, wobei sich ein Unternehmen der Software-Branche hierfür nach der ISO 9000:2000 zertifizieren und mit Hilfe des CMM einstufen lassen kann: Die Software-Prozeßqualität ist die Anwendung von Methoden und Techniken des Managements und der Steuerung zur ständigen Verbesserung des Prozesses (als Software Process Improvement (SPI)) mit dem grundlegenden Ziel der Software-Produktqualität. [Dumke 2002a] Ressourcenqualität: Nach Dumke können Ressourcen in der Software-Entwicklung zum einen personeller Natur und zum anderen die zur Verwendung vorgesehenen Software- oder Hardware-Grundlagen sein. [Dumke 2002a] Unglücklicherweise hat man in der Regel keinerlei direkten Einfluss auf die letztendliche Qualität der nicht selbst entwickelten und hergestellten Soft- und Hardware. Treten Qualitätsmängel nicht schon bei der Bewertung und Selektion geeigneter Ressourcen auf, so ist es im Nachhinein meist nur schwer möglich, die gelieferte Qualität noch positiv zu beeinflussen. Deshalb wird umso mehr Wert auf die stetige Verbesserung der Fähigkeiten des Entwickler- Personals gelegt. Der Ende der neunziger Jahre am Software Engineering Institute (SEI) in Pittsburgh (USA) definierte Personal Software Process (PSP) trägt dabei wesentlich zur Produktivitätssteigerung und Verbesserung der Mitarbeiter bei. [Humphrey 1989] Maßnahmen zur Qualitätssicherung Die im Rahmen des Softwarequalitätsmanagements herangezogenen Schritte unterscheidet man (vergleiche [Wallmüller 2001]) nach ihrer Aufgabenabdeckung in organisatorische, konstruktive, analytische und psychologische Maßnahmen. Strategisch von enormer Bedeutung sind die organisatorischen Schritte zum Aufbau, zur Einführung und zur Pflege eines Qualitätsmanagementsystems. Sie entscheiden maßgeblich über den Erfolg der projektübergreifenden oder auch projektspezifischen Qualitätssicherung sowie -verbesserung und tragen damit als Herausforderung für die Unternehmensführung stark zur Erhöhung der Wettbewerbsfähigkeit bei. Der eigentlichen Ausgestaltung der Qualität anhand einer konkreten Planung, der exakten Ermittlung der Qualitätsmerkmale und der daraus hervorgehenden Projektsteuerung dienen die konstruktiven Qualitätsmaßnahmen. Sie wirken einerseits präventiv, also bei der Fehlervermeidung, andererseits aber auch operativ bei der Fehlerbehebung, mit. Im Gegensatz dazu fördern analytische Schritte die Lokalisierung von Mängeln sowie Defekten des Software-Produkts nach der Implementierung und die Bestimmung und Prüfung der geforderten Qualitätsmerkmale. Eventuelle Abweichungen können aus den Ergebnissen der angewendeten Testmethoden für eine Ursachenanalyse leicht erkannt werden. Letztlich tragen auch psychologische Methoden wie das Aussetzen von Erfolgsprämien im Allgemeinen zur aktuellen und zukünftigen Motivation und damit zur Leistungs- und Produktivitätssteigerung der Mitarbeiter im Bereich der Software-Entwicklung bei.

27 2 Software-Messung, Merkmalsabschätzung und Benchmarking Bezug zu Software-Messung, Aufwandsschätzung und Benchmarking Die Maßnahmen und Methoden zur Sicherung der Softwarequalität sind eng mit der Aufwandsschätzung und dem Benchmarking verbunden und bauen im Grunde direkt auf der Software-Messung auf. Von der operativen Aufwandsschätzung und dem operativen Benchmarking profitiert in hohem Maße die Software-Produktqualität. Qualitative Merkmale der Eigenentwicklung können mit denen der besten Produkte führender Unternehmen verglichen werden, um die einträglichsten Industriepraktiken und Methoden zu extrahieren. Danach ist es mit Hilfe der Aufwandsschätzung leicht möglich, den Änderungsaufwand und die zu erwartenden Kosten zu prognostizieren und in die Projektplanung und -steuerung mit einzuarbeiten. Insbesondere bei der Sicherung der Software-Prozessqualität kommt die starke Verbindung des Qualitätsmanagements zur strategischen Aufwandsschätzung und zum strategischen Benchmarking zur Geltung. Innerhalb des Software-Qualitätsprogramms ( Software Quality Program, SQP) kann auf die hierdurch gewonnenen Erfahrungen und dokumentierten Hintergrundinformationen zugegriffen werden, um später in der Lage zu sein, eine zukünftige Software-Entwicklungsaufgabe qualitativ hochwertiger und wirtschaftlich effizienter bearbeiten zu können. Aber auch die Qualität der personellen Ressourcen kann speziell über die bestehenden Formen des Benchmarking positive Impulse erhalten. So können sich die Mitarbeiter anhand ihrer Ergebnisse mit internen und externen Vergleichsobjekten messen und aus ihren Fehlern beziehungsweise Schwächen lernen. 2.3 Aspekte der Software-Messung Software-Metriken und -Maße Die Lektüre der fachbezogenen Literatur (vgl. [Dumke 2000]) liefert eine Beschreibung der Software-Metrik ( software metric ) gemäß der Maßtheorie ( measure theory ) als eine Abstandsfunktion ( distance ), die Attributen von Software-Komponenten Zahlen beziehungsweise Zahlenbereiche zuordnet. Insofern spannen Metriken multidimensionale Räume auf, in denen die Werte der Metriken Punkte darstellen. Das versetzt uns in die Lage, quantitative Vergleiche anstellen zu können. Um nun aber auch noch die Möglichkeit einer konkreten empirischen Bewertung zu haben, benötigt man ein Softwaremaß. Dem tatsächlichen Messen von Software geht also die Definition eines adäquaten Softwaremaßes voran: Gemäß der Messtheorie ( measurement theory ) ist ein Softwaremaß ( software measure ) eine mit einer Maßeinheit versehene Skala ( scale ), die in dieser Form ein Software-Attribut bewertet beziehungsweise messbar macht. Bei einem Softwaremaß wird die empirische Bedeutung also im Allgemeinen durch eine Maßeinheit ausgedrückt. In der Praxis allerdings werden die Begriffe Maße und Metriken aus Unwissenheit häufig synonym verwendet.

28 14 2 Software-Messung, Merkmalsabschätzung und Benchmarking Messobjekt Modell statistische Relation Modell empirische Bewertung Entwurfs- Dokumentation Zielbäume Kosten Skizzen Diagramme Quellcode Strukturbäume Textschemata Flussgraphen Schätzen Korrelieren SKALA Qualitätsmodelle Ursache- Wirkungs- Diagramme Aufwand Eignung Qualität Texttabellen Call-Graphen Kalibrieren Entscheidungsbäume Modernität usw. usw. Justieren usw. usw. numerisches Relativ empirisches Relativ interne Metriken Validation Maße externe Metriken Abbildung 4: Schema zur Anwendung einer Skala [Dumke 2000] Darüber hinaus bestimmt die so genannte Skala die homomorphe Abbildung des numerischen auf das empirische Relativ. Im Speziellen stellt dieses eine Abbildung von der Quantifizierung eines Merkmals auf die Bedeutung im Kontext dar, die durch die gewählte Skala (siehe Abbildung 4 und Tabelle 1) geregelt wird. [Dumke 2000] Skalentyp definierte Relation anwendbare Statistiken anwendbare Testmethoden nominalskaliert ordinalskaliert intervallskaliert verhältnisskaliert (ratioskaliert) Äquivalenz Äquivalenz, größer oder gleich Äquivalenz, größer oder gleich, Verhältniswert in einem Intervall Gleichheit, größer oder gleich, Verhältniswert von je zwei Werten Häufigkeitsverteilung, Modus, Kontingenz Verteilung, Median, Kendall- und Spearman-Korrelation, Assoziation arithmetisches Mittel, Standardabweichung, Pearson-Korrelation, multiple Korrelation geometrisches Mittel, Variationskoeffizient, alle obigen nicht-parametrische Testmethoden (keine Verteilung vorausgesetzt) parametrische und nicht-parametrische Testmethoden Tabelle 1: Eigenschaften verschiedener Skalentypen [Dumke 2000]