CC-REPRINT. Aufwandsschätzung in der Softwarewartung. Harry M. Sneed CC GmbH, Wiesbaden. Case Consult. The Evolution Experts

Transkript

1 CC-REPRINT Aufwandsschätzung in der Softwarewartung Harry M. Sneed CC GmbH, Wiesbaden Published in: GI Software-Management Tagung 2000 in Marburg

2 Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved

3 Harry M. Sneed CC GmbH, Wiesbaden Aufwandsschätzung in der Softwarewartung Abstrakt Verfahren für die Aufwandsschätzung haben sich bisher im wesentlichen auf die Neuentwicklung von Software beschränkt. Die Wartung und Weiterentwicklung wurde vernachlässigt. Dennoch beansprucht die Wartung bzw. die Weiterentwicklung inzwischen mehr als 2/3 des IT Budgets. Projekte wie Jahr-2000 und EURO Umstellung sind Wartungsprojekte ebenso wie Projekte für die Sanierung und den funktionalen Ausbau. Auch solche Projekte müssen geschätzt werden. Der vorliegende Beitrag beschreibt ein Verfahren, das der Autor in der Wartungspraxis entwickelt hat, basierend auf der statischen Analyse der vorhandenen Programme und der Unterscheidung zwischen Pflegekosten, Weiterentwicklungskosten und Overhead Kosten. Dabei werden bisherige Schätzmodelle wie COCOMO, unction- Point und Object-Point einbezogen und ergänzt. Das Verfahren ist noch nicht bestätigt, dazu sind noch weitere empirische Daten erforderlich, aber es kann schon als Denkansatz für weitere Ansätze dieser Art dienen. Keywords Management der Softwarewartung, Software Aufwandsschätzung, ehleranalyse, Impact Analyse, Change Management Reprint aus GI Software-Management-Tagung in Marburg Seite 1

4 1. Das Wesen von Software-Wartungsprojekten Softwarewartung ist laut dem ANSI-Standard 1219 "Software Maintenance Guide" alle Arbeiten an einem Softwareprodukt nach dem ersten produktiven Einsatz, d.h. ab dem Augenblick, an dem ein System in Produktion geht, wird es gewartet [ANSI/IEEE,98]. Software Wartung beinhaltet demnach sowohl die Instandhaltung vorhandener Versionen als auch die Erstellung weiterer Versionen. Die erste wird als Wartung im engeren Sinne begriffen, die letztere mehr als Weiterentwicklung verstanden. Der allgemeine Begriff "Softwarewartung bezieht sich also auf Wartung im engeren Sinne sowie auf Weiterentwicklung [Lientz/Swanson,80]. Zur Wartung im engeren Sinne gehören:! korrektive und! adaptive Wartung [Lienz/Swanson,78]. Korrektive Wartung befaßt sich mit der ehler- bzw. Mängelbehebung. Adaptive Wartung bezieht sich auf die kurzfristige Anpassung der Software im Hinblick auf Änderungen in der Umgebung oder im Verfahren, das von der Software abgebildet wird. Zur Weiterentwicklung gehört die! enhansive und! perfektive Wartung [Lientz/Swanson,81] In der enhansiven Wartung werden neue unktionen und/oder neue Daten in ein vorhandenes System eingefügt. Dabei sind die Softwareentwickler in ihrer Handlungsfreiheit durch die Architektur, die Sprache, die Dokumentation und alle anderen Eigenschaften der real existierenden Software eingeschränkt. Sie haben nicht mehr die Möglichkeit, neue Technologien einzuführen oder neuen Konventionen zu folgen, denn der größte Teil des Systems existiert bereits und sie müssen sich danach richten. Darin liegt der große Unterschied zu einer Neuentwicklung, bei der das Projekt uneingeschränkt neue Verfahren, Werkzeuge und Architekturen benutzen kann. Eine Neuentwicklung bedeutet vom Grund auf mit den Anforderungen anzufangen, wobei natürlich Teile des alten Codes als Bausteine wiederverwendet werden können. Eine Weiterentwicklung bedeutet, von der bestehenden Implementierung - Architektur und Code - auszugehen und neue Codebausteine in die bestehende Struktur einzubauen. Perfektive Wartung hat mit der Optimierung bzw. der Verbesserung der Software zu tun. Sanierungsmaßnahmen wie Restrukturierung und Refaktorierung gehören zur perfektiven Wartung [Sneed,91]. In Anbetracht der iterativen Softwareentwicklung, die heute vielerorts im Zusammenhang mit der Objekttechnologie propagiert wird, ist die Grenze zwischen Neuentwicklung und Weiterentwicklung fließend [Lorenz,93]. In der Tat ist aber eine iterative Softwareentwicklung nach dem ersten produktiven Einsatz einer Version eine Weiterentwicklung, denn die Grundstruktur bzw. Basisarchitektur bleibt invariant. Es kommen lediglich nur zusätzliche Bausteine - Objekte oder Reprint aus GI Software-Management-Tagung in Marburg Seite 2

5 Komponenten - dazu. Entscheidend ist, daß das Produkt im produktiven Einsatz ist und daß die Grundarchitektur und Produktionsumgebung nicht verändert wird. Wartungsprojekte unterscheiden sich von Entwicklungsprojekten durch ihre besonderen Einschränkungen. Ein Entwicklungsprojekt erstellt ein Produkt aus dem Nichts. Ein Wartungs- bzw. Weiterentwicklungsprojekt erstellt ein neues Produkt aus einem bestehenden. Ein Entwicklungsprojekt richtet sich nach dem Soll, ein Wartungsprojekt hingegen nach dem Ist. Der Ist Zustand dominiert, denn er muß in der neuen Version immer noch erhalten bleiben und zwar funktional äquivalent auch dann, wenn weitere unktionalität hinzukommt. Bei einer Weiterentwicklung geht es um eine Ergänzung zum Ist. Bei einer Neuentwicklung geht es um die Schaffung eines neuen Ist Zustandes. Der Vorteil von Wartungsprojekten ist die Möglichkeit, den Ist Zustand zu messen und bisherige Erfahrungen in die Zukunft zu projizieren. Der Nachteil ist die Abhängigkeit vom Ist Zustand. Man ist an das, was man bereits geschaffen hat, gebunden. Insofern hat das Projekt wenig Spielraum. Je mehr man geschaffen hat, um so weniger der Spielraum. Bei Wartungsprojekten gibt es noch einen weiteren Nachteil und zwar die Verantwortung für die Erhaltung der bisherigen Versionen. Boehm bezeichnet dies als die Kontinuität der Dienstleistung [Boehm,83]. Ist ein Softwaresystem einmal in Produktion, müssen schwere ehler sofort behoben und dringende Änderungen sofort vorgenommen werden. Diese Notfälle sind unvorhersehbar und daher auch schwer zu planen. Auch manche Gesetzänderung kommt völlig unerwartet. Erschwerend hinzu kommt die Tatsache, daß man sofort reagieren muß. Es ist nicht möglich, wie in Entwicklungsprojekten, die Termine einfach vor sich her zu schieben. Daher müßte genügend Kapazität für solche Instandhaltung vorgehalten werden. Dieser Tatbestand erzwingt eine Teilung von Wartungsprojekten in ein Projekt für die Erhaltung der alten Version und ein Projekt für die Schaffung einer neuen Version. Vielleicht sind die gleichen Personen an beiden Teilprojekten beteiligt, aber sie bleiben zwei unterschiedliche Projekte mit unterschiedlichen Zielen, Aktivitäten und Ergebnissen. Als solche brauchen sie auch eine unterschiedliche Planung und Aufwandsschätzung. Reprint aus GI Software-Management-Tagung in Marburg Seite 3

6 2. Schätzverfahren für Wartungsprojekte Die bisherigen Schätzmethoden haben sich fast ausschließlich mit dem Aufwand für Neuentwicklungen befaßt. Nur einige wenige haben sich der Schätzung des Wartungsaufwandes gewidmet, obwohl inzwischen bekannt ist, daß Wartung zwischen 50% und 80% des gesamten Produktaufwandes ausmachen. Die Ursache dieser Diskrepanz ist sicherlich auf das mangelnde Verständnis für das Wesen der Softwarewartung seitens der IT ührung. Barry Boehm war der erste, der das Thema "Wartungsaufwand" aufgriff. Bereits in seiner ursprünglichen COCOMO-Methode aus dem Jahre 1981 schlug er vor, den Wartungsaufwand auf der Basis des Entwicklungsaufwandes und der jährlichen Änderungsrate justiert durch den Systemtyp sowie die Wartungsfreundlichkeit des vorhandenen Systems zu berechnen [Boehm,81]. Die Gleichung zur Schätzung des Wartungsaufwandes lautet: Aufwand W = M * [(ACT * Aufwand E ) * (2-Wartbarkeit)] Der Systemtyp - hier durch den Multiplikationsfaktor M gekennzeichnet - reichte von 1,0 für einfache Batchsysteme bis zu 3,5 für harte Echtzeitsysteme. Der Aufwand für die Entwicklung - Aufwand E - konnte entweder der geschätzte Aufwand oder der echte Aufwand sein. Die jährliche Änderungsrate - ACT - ist der prozentuale Anteil geänderter, gelöschter und hinzugefügter Codezeilen für ein Wartungsjahr relativ zur gesamten Codemenge. Die Wartungsfreundlichkeit ist ein rationales Maß auf der Skala von 0,5 bis 1,5 mit 1 als mittlerer Wartungsfreundlichkeit, 1,5 als Reprint aus GI Software-Management-Tagung in Marburg Seite 4

7 maximaler Wartungsfreundlichkeit und 0,5 als minimaler Wartungsfreundlichkeit.. D.h. auch mit maximaler Wartungsfreundlichkeit des Produktes kann der Aufwand für Wartung nur um die Hälfte reduziert werden. Das ist auch verständlich, weil die Qualität des Wartungsprozeß mindestens genau so viel Einfluß auf den Wartungsaufwand hat wie die Qualität des Produktes. Unabhängig davon, wie wartungs- freundlich das Produkt ist, wird es immer einen Wartungsaufwand geben [Briand/Kim/Melo/Seaman/Basili,98]. Im neuen COCOMO-Schätzmodell aus dem Jahre 1998 wurde diese Schätzformel um einige zusätzliche aktoren ergänzt. Dazu gehören! mehr Systemtypen auf einer breiteren Skala, jetzt von 0,5 bis 4,0! ein Skalierungsfaktor von 0,91 bis 1,23 und! einige Einflußfaktoren wie Wiederverwendung und Prozeßreife. Außerdem werden neben den Codezeilen als Größenmaß auch unction-points verwendet. Die Änderungsrate bezieht sich auf die unction-points statt auf die Codezeilen. Damit wurde der Wartungsaufwand weniger von der Codemasse und mehr von der unktionalität abhängig gemacht. Insgesamt sind dadurch die Schätzungen um 54% genauer geworden [Boehm/Brown/Chulani,99]. In anderen Schätzmethoden, besonders in der unction-point-methode, ist die Wartungsfreundlichkeit zu kurz gekommen. Einige Anwender dieser Methode haben versucht, sie auch auf Wartungsprojekte zu übertragen und haben sogar weitere wartungsspezifische Einflußfaktoren eingeführt, aber die offizielle Methode geht auf die besondere Problematik der Wartung nicht ein [Hsia./Hsu/Kong/Byrne,98]. Es ist so, als ob diese Methode an der Realität der Software Wartung vorbeiginge. Dabei bedarf sie nur einer Ergänzung. Der Autor hat über die Jahre einige Erfahrungen mit der Schätzung von Wartungsprojekten gesammelt. Das folgende Schätzmodell basiert auf diesen Erfahrungen sowie auf den Grundzügen der COCOMO- und unction-point Schätzmethoden. Es fließen neben den Erfahrungen des Autors auch noch die Erfahrungen aus dem Bereich der ehleranalyse und mehreren Wartungsuntersuchungen in das Schätzmodell ein. Das Schätzmodell mit der Bezeichnung MEST für das Maintenance Effort Estimation Model umfaßt im wesentlichen drei Kostenarten:! die Kosten für die Nachbesserung der letzten Version (corrective & adaptive Maintenance)! die Kosten für die Bereitstellung der nächsten Version (enhansive & perfective Maintenance)! die Kosten der Wartungsadministration (Overhead). Reprint aus GI Software-Management-Tagung in Marburg Seite 5

8 3. Kosten der korrektiven und adaptiven Wartung ür die Schätzung der Kosten der korrektiven und adaptiven Wartung sind vier Schritte vorgesehen 1. Die Zählung der ehler und ad hoc Änderungen aus bisherigen Versionen 2. Die Ermittlung der Aufwände für die bisherige ehlerkorrektur und Anpassung 3. Die Schätzung der ehler und Anpassungen im nächsten Release 4. Die Schätzung des Aufwandes für Korrektur und Adaption bzw. Nachbesserung Die Anzahl ehler aus bisherigen Versionen ist aus der ehlerstatistik zu entnehmen. Die Anzahl adhoc Änderungen ist aus der Änderungsstatistik zu entnehmen. Der Aufwand für die Korrektur und Anpassung insgesamt wird aus der Aufwandserfassung entnommen. Anschließend wird der durchschnittliche Aufwand pro ehlerkorrektur und Anpassung wie folgt errechnet: ehlerbehebungsaufwand mittlerer ehlerbehebungsaufwand = ehleranzahl Reprint aus GI Software-Management-Tagung in Marburg Seite 6

9 z. B. 750 = 1,5 PD pro ehlerkorrektur 500 Änderungsaufwand mittlerer Änderungsaufwand = Änderungsanzahl z.b. 500 = 2,0 PD pro Änderung 250 Zur Schätzung der zu erwartenden Anzahl ehler und Anpassungen in dem gegenwärtigen Release sind vier Kennzahlen ausschlaggebend:! die Anzahl der durchgeführten Änderungen in der letzten Version! die Anzahl behobener ehler in der letzten Version! die Systemgröße der letzten Version in unction-points oder einem vergleichbaren Größenmaß wie z.b. Object-Points! die Systemgröße der jetzigen Version. Bei der Schätzung der korrektiven und adaptiven Wartung ist zu unterscheiden zwischen der letzten Version = Version (i-1), der jetzigen Version im elde = Version (i) und der nächsten Version die zu entwickeln ist = Version (i+1). Es gilt aus der letzten Version zu lernen, die jetzige Version zu pflegen und die nächste Version zu entwickeln. Aus den oben genannten Größen wird zum Einen die letzte ehlerdichte als ehlerdichte (i-1) = ehleranzahl (i-1) errechnet z. B. Systemgröße (i-1) ehlerdichte = 500 = 0, Zum Zweiten wird die Änderungsdichte als Änderungsanzahl (i-1) Änderungsdichte (i-1) = errechnet z. B. Systemgröße (i-1) Änderungsdichte = 250 = 0, Die Summe der beiden Maße für ehlerdichte und Änderungsdichte werden anschließend gebraucht, um die Anzahl der Nachverbesserungen in der jetzigen Wartungsperiode hoch zu rechnen. ür diese Hochrechnung wird neben der gemessenen Systemgröße der jetzigen Version noch die Größendifferenz zwischen der letzten und der jetzigen Version benötigt. Reprint aus GI Software-Management-Tagung in Marburg Seite 7

10 Die geschätzte ehlerdichte ist ehlerdichte (i) = ehlerdichte (i-1) x Wachstumsrate z.b. ehlerdichte = 0,032 x 1,25 = 0,040 Daraus folgt die absolute ehleranzahl, die im jetzigen Release zu erwarten ist. Sie ist das Produkt von Systemgröße und ehlerdichte. ehleranzahl (i) = ehlerdichte (i) x Systemgröße (i) Demnach ist die geschätzte Anzahl ehler im jetzigen Release eine unktion der Systemgröße relativ zur bisherigen ehlerdichte, z.b. ehleranzahl = 0,032 x = 640 Die Schätzung der Änderungsanzahl vollzieht sich nach dem gleichen Verfahren Änderungsdichte (i) = Änderungsdichte (i-1) x Wachstumsrate z.b. Änderungsdichte = 0,016 x 1,25 = 0,020 Änderungsanzahl (i) = Änderungsdichte (i) x Systemgröße (i) z.b. Änderungsanzahl = 0,020 x = 400 ür die Schätzung der korrektiven und adaptiven Wartungskosten muß man außer der absoluten ehleranzahl auch noch die Systemgröße, Systemkomplexität und Systemqualität der letzten und der jetzigen Version berücksichtigen. Daraus läßt sich die Schwierigkeitsdifferenz zwischen den beiden Versionen ermitteln, denn Software wird nicht nur von Version zu Version größer sondern auch komplexer. Außerdem sinkt laut der Evolutionslehre von Belady und Lehman die Qualität [Lehman/Belady,85]. Das bedeutet eine Zunahme im Aufwand, der pro ehlerkorrektur und Anpassung betrieben wird. Die Systemgröße ist die absolute Anzahl Anweisungen, Codezeilen, Data-Points, unction-points, Object-Points usw. Diese Größe wird durch die Komplexität und Qualität des Systems justiert. Die justierte Systemgröße ist das Produkt der Gleichung Systemgröße x Komplexität x Qualität z.b x 1,4 x 0,8 = = 20 K unction-points/object-points Ist_Komplexität Die Komplexität = mittlere_komplexität Reprint aus GI Software-Management-Tagung in Marburg Seite 8

11 z.b. 0,7 = 1,4 0,5 Durch eine überdurchschnittliche Komplexität steigt der Aufwand pro Korrektur und Anpassung. Umgekehrt, durch eine überdurchschnittliche Qualität, sinkt der Aufwand pro Korrektur und Anpassung. Der Qualitätsfaktor rechnet sich also invers als: mittlere_qualität Qualitätsfaktor = Ist_Qualität z.b. 0,5 = 0,8 0,6 Das Endergebnis ist die Schwierigkeitsdifferenz, die benutzt wird, um den Aufwand pro ehlerbehebung und pro Anpassung zu justieren. Sie ergibt sich aus der Differenz zwischen der justierten Größe der jetzigen Version und der Vorgängerversion. z.b., wenn die letzte Version eine justierte Größe von und die jetzige Version eine justierte Größe von hat, ist die Schwierigkeitsdifferenz justierte Systemgröße (i) z.b. justierte Systemgröße (i-1) = 1, Dieser Multiplikationsfaktor wird verwendet, um den Aufwand pro ehlerkorrektur bzw. pro Änderung zu justieren. Bei einem Aufwand von 1,5 PD pro ehler in der letzten Version, ist ein Aufwand von (1,5 x 1,29 = 1,9 PD) pro ehler in der jetzigen Version zu erwarten, und bei einem Aufwand von 2,0 PD pro Änderung in der letzten Version ist mit einem Aufwand von (2,0 x 1,29 = 2,6 PD) pro Änderung in der jetzigen Version zu rechnen. Es bleibt nur übrig, diese Aufwandsfaktoren mit der geschätzten Anzahl ehler und Änderungen zu multiplizieren, um die Aufwände für korrektive und adaptive Wartung zu ermitteln. Bei 640 geschätzten ehlern und 400 geschätzten Änderungen sind das 640 x 1,9 PD = 1216 Personentage für die ehlerbehebung und Reprint aus GI Software-Management-Tagung in Marburg Seite 9

12 400 x 2,6 PD = 1040 Personentage für die Anpassungen. Zusammen macht das 2256 Personentage oder 113 Personenmonate für die Wartung der im elde eingesetzten Version. Es bleibt noch, den Aufwand für die Arbeit an der nächsten Version zu schätzen. 4. Kosten der Weiterentwicklung In einem Wartungsprojekt ist es wie bereits erwähnt wichtig, zwischen der Pflege der jetzigen Version und der Weiterentwicklung der nächsten Version zu unterscheiden. Es könnte sogar von Vorteil sein, die beiden Aktivitäten zu trennen. Ein oder mehrere Mitarbeiter stehen zur Korrektur und Anpassung bereit. Die Anderen sind, insofern als sie nicht zur Hilfe bei der Pflege benötigt werden, voll mit der Weiterentwicklung und Optimierung beschäftigt. Im Gegensatz zu einer Neuentwicklung, wo die Schätzung nur auf vagen Modellen - Datenmodellen für Data-Points, unktionsmodellen für unction-points oder Objektmodellen für Object-Points - basiert, gibt es bei der Weiterentwicklung bereits eine meßbare Codemasse. Nicht nur die Codezeilen und Anweisungen lassen sich messen, sondern auch die Data-Points, Object-Points und unction-points lassen sich durch eine automatische Analyse des Sourcecodes genau zählen. Der Hauptvorteil einer solchen Analyse ist der geringe Aufwand, mit dem er durchgeführt werden kann. Während die Zählung von unction-points anhand eines achkonzepts mehrere Personenmonate in Anspruch nehmen kann, dauert die statische Analyse mehrerer Millionen Sourcezeilen nicht länger als zwei Tage. Die Reprint aus GI Software-Management-Tagung in Marburg Seite 10

13 Ergebnisse sind auch wesentlich genauer. Deshalb läßt es sich auf der Basis existierender Software viel besser schätzen. Das Hauptproblem bei der Schätzung der Weiterentwicklung ist die Ermittlung der prozentualen Änderung bzw. der Wachstumsrate. Basili vergleicht die Weiterentwicklung mit einer Neuentwicklung mit hohem Wiederverwendungsanteil [Basili,90]. Der neue Entwicklungsanteil ist der geplante Systemumfang minus des vorhandenen Systemumfangs. Die Differenz ist die Softwaremasse, deren Erstellung geschätzt werden muß. Sie setzt sich zusammen aus den Code-Zeilen, Object- Points, unction-points usw., die geändert, gelöscht und hinzugefügt werden müssen. Auch gelöschte Einheiten müssen berücksichtigt werden, da sie auch Aufwand verursachen. Daher werden Minusdifferenzen in plus Aufwände umgewandelt. Boehm nennt diese Differenz die Annual Change Rate - ACR [Boehm,84]. Die Schätzung der Änderungsrate reicht von einer groben Mutmaßung bis hin zu einer detaillierten Untersuchung jeder einzelnen Anforderung. Eine gründliche aber vertretbare Methode ist die "Impact-Analyse" mit Hilfe einer Repository [ yson/boldyreff,98]. In die Software-Repository werden sämtliche Entitäten und deren Beziehungen automatisch als Abfallprodukt der Sourceanalyse gespeichert. So wird gespeichert, welche Klassen von welchen anderen erben, welche unktionen von welchen anderen aufgerufen werden, welche Module auf welche Datenobjekte zugreifen und welche Schnittstellen verbinden welche Komponenten. Über diese Beziehungen können Änderungspfade durch die Softwarearchitektur leicht verfolgt werden. Der Ausgangspunkt ist in der Regel entweder die Benutzeroberfläche oder die Datenbasis. Wenn eine Anforderung sich auf eine bestehende Oberfläche bezieht, sollen ausgehend von den betroffenen Oberflächenobjekten die abhängigen Klassen und unktionen identifiziert und ihre Maße proportional zur Tiefe des Eingriffs auf addiert werden. Wenn eine Anforderung sich auf die bestehende Datenbasis bezieht, sollen ausgehend von den betroffenen Datenobjekten die benutzenden Module und unktionen gezählt und anteilmäßig justiert werden. Auf diese Weise entsteht eine Anzahl betroffener unction-points, Objekt-Points, Data-Points und Anweisungen. Hinzu kommen die Größenmaße jener Vorgänge, Datenobjekte und Schnittstellen, die völlig neu hinzu kommen. Die Änderungs- bzw. Wachstumsrate ist die Summe jener Größenmaße dividiert durch die vorhandenen Größenmaße. Z. B. (betroffene Object-Points + neue Object-Points) vorhandene Object-Points Eine entwas anspruchsvollere Variante dieser Impaktanalyse hat der Autor bei der SDS in Wien implementiert. Dort gibt es neben der Source Repository, die aus der Sourcecode Analyse hervorgeht, auch eine Konzept Repository, die aus der Konzeptanalyse aufgebaut wird. Darin sind die wichtigsten Entitäten und Beziehungen des achkonzepts gespeichert, z.b. die Masken, Berichte, Vorgänge, unktionen, Geschäftsobjekte und Geschäftsregeln. Ein Wartungsauftrag bezieht sich zunächst auf eine oder mehrere dieser fachlichen Entitäten. Diese achentitäten sind wiederum über Querverbindungen mit den Programmentitäten wie Komponente, Reprint aus GI Software-Management-Tagung in Marburg Seite 11

14 Klasse, Schnittstelle, unktion und Datentabelle verknüpft. Dadurch ist es möglich, die Impaktanalyse vom Konzept aus zu starten, um die dahinter liegenden betroffenen Programmbausteine und deren unction- bzw. Object-Points zu ermitteln. Hierdurch wird gleichzeitig erkannt, welche Konzeptelemente von den Änderungen betroffen sind [Jorgensen,95]. ür die Schätzung der Weiterentwicklungskosten sind insgesamt vier Schritte erforderlich: 1. Die Messung der gegenwärtigen Softwaregröße. 2. Die Ermittlung der geplanten Änderungsrate aufgrund der Impactanalyse. 3. Die Berechnung der bisherigen Produktivität. 4. Die Projektion der bisherigen Produktivität auf den Umfang der Weiterentwicklung. Im ersten Schritt wird die Größe der letzten Version anhand der statischen Sourceanalyse ermittelt. Ein automatisches Werkzeug liest durch die Source Bibliothek und zählt! Codezielen,! Anweisungen,! Data-Points,! Object-Points und! unction-points. Diese Sourcecode Analyse dauert nur Stunden, bis man die endgültige Größe hat. Gleichzeitig mißt das Werkzeug die technische Komplexität und die innere Qualität der Programme. Heraus kommt ein Koeffizient auf der Skala von 0:1. Im alle der Komplexität sollte er möglichst niedrig sein, im alle der Qualität möglichst hoch. Das Verfahren für die Berechnung dieser Koeffizienten ist nicht Gegenstand dieser Abhandlung, kann jedoch in der einschlägigen Literatur zum Thema Komplexitätsund Qualitätsmetriken gefunden werden [Harrison/Mayel/Klucziny/Dekock,82]. Die Vorschrift für die Ableitung der Qualitätskoeffizienten ist in der ISO-Norm 9126 vorgegeben [Coleman/Ash./Oman,94]. Hier geht es darum, einen Komplexitäts- und einen Qualitätsfaktor zu ermitteln. Der Komplexitätsfaktor ist Kf = Istkomplexität/mittlere Komplexität Wenn also die gemessene Istkomplexität 0,7 und die mittlere Komplexität 0,5 ist, wird der Komplexitätsfaktor 1,4. Der Qualitätsfaktor ist Qf = mittlere Qualität/Ist Qualität Wenn also die gemessene Ist Qualität 0,6 und die mittlere Qualität 0,5 ist, dann wird der Qualitätsfaktor 0,83. Die justierte Systemgröße ist Reprint aus GI Software-Management-Tagung in Marburg Seite 12

15 Sg j = Sg x (Kf) x (Qf) Mit einer Systemgröße von unction-points, einem Komplexitätsfaktor 1,4 und einem Qualitätsfaktor 0,8 ist die justierte Systemgröße unction-points. Im zweiten Schritt wird die gesamte Änderungsrate ermittelt. Sie ist die Summe der Auswirkungsraten aller Wartungsanträge! Erweiterungsanträge! Anpassungsanträge und! Optimierungsanträge Mit drei Erweiterungsanträgen a 0,03 Auswirkungsrate, zwei Verbesserungsanträgen a 0,01 Auswirkungsrate und einem Optimierungsantrag mit 0,04 Auswirkungsrate ist die gesamte Änderungsrate 0,15. Das Änderungsinkrement bzw. das Delta - ist die justierte Systemgröße der letzten Version mal der Änderungsrate - also 3,360 unction-points. = Sg j x Änderungsrate Im dritten Schritt wird die bisherige Produktivität ermittelt als Größeneinheiten pro Arbeitseinheit. Hierfür braucht man eine Geschichte der bisherigen Releaseinkremente 1, 2, 3, usw. Jedes Releaseinkrement wird durch die Anzahl Arbeitseinheiten für das Release dividiert, um die mittlere Produktivität pro Release zu bekommen, z. B. 2,000 unction-points = 1,6 unction-point pro PD 1,200 Personentage Hier kommt es darauf an, einen Trend zu erkennen [Lieberherr/Xiao,93]. Es könnte sein, daß die Produktivität von Release zu Release zunimmt, z.b. sie beginnt mit 1,2 kpt pro Personentag für das erste Release und steigt auf 1,6 kpt pro Personentag für das letzte Release. Es ist jedoch wahrscheinlicher, daß die Produktivität abnimmt, z.b. sie beginnt mit 1,6 für das erste Release und sinkt auf 1,2 für das letzte Release. Aufgrund der Tendenz wird die Produktivität des nächsten Releases als P (i+1) = P (i) + (P (i) - P (i-1) ) Also war die Produktivität des letzten Releases 1,0 und die des vorletzten Releases 1,2. Es ist zu erwarten, daß die Produktivität des nächsten Releases bei ca. 0,8 Pkpt pro Personentag liegen wird. Im letzten Schritt wird die Größe des geplanten Änderungsinkrements durch die projektierte Produktivität dividiert, um den Aufwand für die Weiterentwicklung zu bekommen. z.b. Aufwand We = Sg (i+1) / P (i+1) / 0,8 = 4200 Personentage = 210 PM Reprint aus GI Software-Management-Tagung in Marburg Seite 13

16 5. Kosten der Wartungsadministration Der letzte Kostenfaktor bei der Schätzung der Wartungskosten sind die Kosten der Wartungsadministration bzw. die Overhead-Kosten. Im Gegensatz zu den Kosten eines Entwicklungsprojektes, bei denen die Overhead-Kosten selten über 20% des Gesamtaufwandes steigen, fallen die Overhead-Kosten bei Wartungsprojekten stärker ins Gewicht. Es liegt daran, daß Wartungsprojekte auf zwei Stufen statt finden. Auf der einen Stufe werden die Änderungsanträge gesiebt, registriert, priorisiert, kategorisiert und gebündelt. Anschließend werden sie zugeteilt, überwacht und abgenommen. All dies erfordert einen administrativen Aufwand ungleich höher als den bei einer Neuentwicklung [Guimaraes,83]. Auf der anderen Seite werden die eigentlichen Konzept- und Codeänderungen durchgeführt und getestet. Hier findet jedoch nur der Modul- und Integrationstest statt, da diese Testansätze sich auf die betroffenen Module, Komponenten und Schnittstellen beziehen. Der Systemtest, der sich auf das gesamte System bezieht, wird, weil er Teil des Abnahmeverfahrens ist, zur ersten Stufe bzw. zum Overhead gerechnet. Der Aufwand für den Systemtest ist nicht wenig und muß mit mindestens 20% des kalkulierten Aufwands kalkuliert werden. Reprint aus GI Software-Management-Tagung in Marburg Seite 14

17 Zusammen mit den Planungs-, Organisations- und Steuerungskosten des Wartungsmanagements bringen die Systemkosten ohne Overhead-Kosten laut aller bisherigen Erfahrungen einen administrativen Aufwand von mindestens 33% des operativen Aufwands. Der operative Aufwand ist wiederum Korrekturaufwand + Weiterentwicklungsaufwand In unserem Beispiel sind das 33% von ( ) x 0,33 = 2130 Personentage 6. Kalkulation der Gesamtkosten Die endgültige Schätzung für das geplante Watungsprojekt einschließlich Korrekturkosten, Weiterentwicklungskosten und Overhead-Kosten läuft auf die Zahl 2256 Personentage Korrekturaufwand Personentage Weiterentwicklungsaufwand Personentage Overheadaufwand = 8586 Personentage Gesamtaufwand oder 429 Personenmonate hinaus. Bei der Anwendung der COCOMO- ormel für die Berechnung der Mindestlaufzeit Zeit = PM 0,35 Reprint aus GI Software-Management-Tagung in Marburg Seite 15

18 kommen wir auf eine Mindestlaufzeit von 8 Kalendermonaten. Unter dieser Zeit ist ein neues Release kaum machbar. Wenn die Dauer zwischen Releases kürzer werden soll, muß wohl der Umfang der Weiterentwicklung reduziert werden d.h. weniger Erweiterungen und Optimierungen. 7. Zusammenfassung In diesem Beitrag wurde auf das Wesen der Softwarewartung eingegangen und geschildert, warum sie sich von der Entwicklung unterscheiden. Sie umfasst verschiedene, gegenseitig abhängige Aktivitäten, darunter! ehlerkorrekturen,! Anpassungen,! Erweiterungen und! Optimierungen. Es wurde betont, daß die ehlerkorrektur und Notanpassung der letzten Version von der Weiterentwicklung der nächsten Version zu trennen ist. Am besten wäre es, dies in zwei Teilprojekte zu gliedern [Wilde/Matthews,93]. Bei der Schätzung der Wartungskosten müssen die Kosten der Pflege bzw. Nachbesserung und die Kosten der Weiterentwicklung getrennt geschätzt werden, da sie völlig andere Verfahren benötigen. ehlerkorrektur- und Änderungskosten basieren auf projektierter ehler- und Änderungsanzahl zusammen mit den akkumulierten Aufwände für ehlerkorrekturen und Änderungen. Weiterentwicklungskosten basieren hingegen auf geschätzten Erweiterungen und Optimierungen zusammen mit bisherigen Aufwände für die Entwicklung. Schließlich müssen die Overhead Kosten dazu gerechnet werden. Die Gesamtkosten ergeben sich aus der Summe dieser Kostenfaktoren. Insofern als die Softwarewartung an Bedeutung zunimmt und einen immer größeren Anteil des IT Budgets beansprucht, wird es immer wichtiger, Schätzverfahren für die Wartungsprojekte einzusetzen, um die Kosten und den Nutzen geplanter Releases im voraus besser planen zu können. Dieser Beitrag aus der Wartungspraxis soll als Anstoß für weitere wissenschaftlich fundierte Studien auf diesem wichtigen Gebiet dienen, denn es darf nicht übersehen werden, daß die Aufwände für völlig neue Systeme im Vergleich zu den Aufwänden für die Erhaltung und Weiterentwicklung vorhandener Systeme gering ausfallen. Wenn nicht, ist dies eher ein Zeichen, daß chaotische Verhältnisse vorherrschen [Chan/Ching/Huatto,96]. Reprint aus GI Software-Management-Tagung in Marburg Seite 16

19 Literatur ANSI/IEEE: ANSI/IEEE-Standard , Institute of Electrical and Electronics Engineers, New York, N.Y., 1998 Basili, V.: "Viewing Maintenance as Reuse-oriented Software Development", IEEE Software, Jan. 1990, p. 19 Boehm, B.: Software Engineering Economics, Prentice-Hall, Englewood Cliffs, N.Y., 1981, p. 71 Boehm, B.: "Economics of Software Maintenance", Proc. of 1st Int. Conf. on Software Maint., IEEE Press, Monterey, Dec. 1983, p. 9 Boehm, B.: "Software Engineering Economics" IEEE Trans on S.E., Vol. 10, No. 1, Jan. 1984, p. 4 Boehm,B./Brown,A./Chulani,S: The COCOMO-II Set in Proc. of ESCOM-SCOPE, Herstmonceux, England, May, 1999, p. 6C Briand, L./Kim, Y./Melo, W./Seaman, C./Basili, V.: "Qualitative Evaluation of Maintenance Organizations, Processes and Products", Journal of Software Maint., Vol. 10, No. 4, July 1998, p. 249 Chan, T./Ching, S./Huatto, T.: "An Economic Model to Estimate Software Rewriting and Replacement Times", IEEE Trans on S.E., Vol. 22, No. 8, Aug. 1996, p. 580 Coleman, D./Ash, D./Oman, P.: "Using Metrics to Evaluate Software Systems Maintainability", IEEE Computer, August 1994, p. 42 yson, M./Boldyreff, C.: "Using Application Understanding to Support Impact Analysis", Journal of Software Maint., Vol. 10, No. 2, March 1998, p. 93 Guimaraes, T.: "Managing Application Program Maintenance Expenditures", Comm. of ACM, Vol. 26, No. 10, Oct. 1983, p. 739 Harrison, W./Mayel, K./Klucziny, R./Dekock, A.: "Applying Software Complexity Metrics to Program Maintenance", IEEE Computer, Sept. 1982, p. 65 Hsia, P./Hsu, C./Kong, D./Byrne, E.: "Incremental Delivery Reduces Maintenance Cost - A COCOMO based Study", Journal of Software Maint., Vol. 10., No. 4, July 1998, p. 225 Harrison, W./Mayel, K./Klucziny, R./Dekock, A.: "Applying Software Complexity Metrics to Program Maintenance", IEEE Computer, Sept. 1982, p. 65 Jorgensen, M.: "Experience with the Accuracy of Software Maintenance Task Effort Prediction Models", IEEE Trans. on S.E., Vol. 21, No. 8, Aug. 1995, p. 674 Lehman, M./Belady, L.: Program Evolution - Process of Program Change, Academic Press, London, 1985, p. 52 Lieberherr, K./Xiao, D.: "Object-oriented Software Evolution", IEEE Trans on S.E., Vol. 19, No. 4, April 1993, p. 313 Lientz, B./Swanson, E.B.: Software Maintenance Management, Addison-Wesley Pub. Reading Mass., 1980, p. 9 Reprint aus GI Software-Management-Tagung in Marburg Seite 17

20 Lienz, B./Swanson, E.B./Tompkins, G.E.: "Characteristics of Application Software Maintenance", Comm. of ACM, Vol. 21, No. 6, June, 1978, p. 466 Lientz, B./Swanson, E.B.: "Problems in Application Software Maintenance", Comm. of ACM, Vol. 24, No. 11, Nov. 1981, p. 763 Lorenz, M.: Object-oriented Software Development, Prentice-Hall, Englewood Cliffs, 1993, p. 17 Sneed, H.: "Economics of Software Reengineering", Journal of Software Maintenance, Vol. 3, No. 3, Sept. 1991, p. 163 Wilde, N./Matthews, P.: "Maintaining object-oriented Software", IEEE Software, Jan. 1993, p. 75 Reprint aus GI Software-Management-Tagung in Marburg Seite 18