 |
|
|
|
|
|
|
|
||||||
|
|||||||||||||
|
Robert Hürten: Die Grundlagen für ein modernes Softwaremanagement. 2. erweiterte Auflage 2005, 188 Seiten, mit Diskette, € 52,-
|
|||||||||||||
|
Unter folgenden Anschrift sind wir zu erreichen: |
|||||||||||||
|
Stand: |
|||||||||||||
|
|
|
|
|
|
|
||||||||||||
 |
||||||||||||||||||
|
Von hier ausgelangen Sie schnell zu einigen Aufsätzen, die sich kritisch mit Problemen in der Softwareentwicklung auseinandersetzen. |
||||||||||||||||||
|
Softwarecontrolling und Software Metrik.
Unter Softwarecontrolling sollen die Aktivitäten im Rahmen des IT-Controllings verstanden werden, die sich schwerpunktmäßig mit dem Softwarebereich beschäftigen. Dabei soll nicht die optimale Nutzung einer Software Ziel des Softwarecontrollings sein, sondern deren optimale Beschaffung. Die Wirtschaftlichkeit einer Software wird heute allein an den Einsparungen gemessen, die beim Anwender durch den Nutzen der Software ermittelt wird. Das IT-Controlling, wie es heute in den meisten Unternehmen und Verwaltungen betrieben wird, beschäftigt sich ausschließlich mit derartigen Kosten-/Nutzenanalysen. Aus der Sicht der Softwareentwicklung liegen derartige Aktivitäten jedoch außerhalb dieses Bereiches, so daß hier die Bezeichnung externes Softwarecontrolling sinnvoll ist. Solange die Einsparungen durch die Software höher als deren Kosten für Beschaffung oder Erstellung sind, wird selten gefragt, ob der Preis für das Produkt oder dessen Erstellungskosten angemessen ist. Zu welchen Ergebnissen das führt, zeigen folgende, verallgemeinerte Beispiele. Die Budgets für die Softwareentwicklung wachsen proportional mit dem Geschäftsvolumen bzw. mit der Zahl der Geschäftsvorfälle der Unternehmen. Für die Hardwarebudgets ist dieser Zusammenhang berechtigt, weil jeder Anwender zusätzliche Rechnerkapazität benötigt. Die Softwareentwickler geben aber zu, daß die Entwicklungskosten einer Software nicht oder nur minimal durch die Zahl der späteren Nutzer oder bearbeiteten Vorgänge beeinflußt wird. Dies ist zu vergleichen mit der Schriftstellerei, bei der der Zeitaufwand des Autors auch nicht von der Zahl der Käufer abhängt. Beim Buch hängt, im Gegensatz zur Software, der Kaufpreis auch nicht davon ab, wie oft im Hause des Käufers das Buch von Familienmitgliedern oder Freunden gelesen wird. Vergleicht man die Erstellung einer Software mit der Erstellung eines Gebäudes, so fällt auf, daß bei der Software die "Bauleute" die Baustelle nie verlassen. Über die Jahre hin müßten die Kosten für die Software abnehmen, denn irgendwann sollte der Organisations- und Informationsbedarf durch Software abgedeckt sein. Die Softwareentwickler beschäftigen sich jedoch weiter mit der Wartung und der Weiterentwicklung ihrer Programme mit dem Erfolg, daß nach dem Abschluß der eigentlichen und einmaligen Umstellungsarbeiten das Softwarebudget nicht zurückgeht. Die wirtschaftliche Nutzung der erstellten Software in einem Unternehmen führt fast immer zu dem Schluß, daß der Softwarebereich wirtschaftlich arbeitet. Es wird deswegen nicht die Frage gestellt, ob die Kosten des Softwarebereiches angemessen sind. Diese Frage zu beantworten stellt das interne Softwarecontrolling.
2 Internes Softwarecontrolling Das interne Softwarecontrolling beschränkt sich heute darauf zu verfolgen, ob das Budget für den Softwarebereich insgesamt und für die Projekte eingehalten werden. Ob die angesetzten Budgets angemessen sind, ist durchweg nicht Gegenstand des Controllings. Es ist in vielen Unternehmen zu beobachten, daß die Softwarekosten als zu gering im Verhältnis zu den Gesamtkosten angesehen werden, um ein strenges Kostenmanagement zu installieren. Ziel des internen Softwarecontrollings sollte es jedoch auch sein, darauf zu achten, daß die Kosten für die Erstellung und Beschaffung der Software minimiert werden, bzw. Maßnahmen einzuleiten, um dieses Ziel zu erreichen. Voraussetzung zur Realisierung dieser Anforderung ist es, daß die Produktivität der Softwareentwicklung bekannt ist und bewertet werden kann. Es müssen also zunächst folgende Fragen beantwortet werden:
Das Problem, das in den zwei Fragen liegt, ist, daß es bis heute im Softwarebereich noch keine einheitliche Definition für die Produktivität gibt, weil sich vor allem in Deutschland noch kein Maß für die erbrachte Arbeit durchgesetzt hat. Heute übliche Maße in der Softwareentwicklung sind von der aktuellen technischen Realisierung der Software abhängig. So ergibt z.B. die Maßeinheit Lines of Code für ein inhaltlich gleiches Produkt ein anderes Ergebnis bei der Nutzung der Sprache Assembler als bei der Sprache Visuell Basic. Um ein wirkungsvolles internes Softwarecontrolling zu nutzen, muß eine Metrik eingeführt werden, die die Größe einer Software unabhängig von der Art und Weise ihrer technischen und methodischen Realisierung mißt und nicht durch den Aufwand für ihre Erstellung dargestellt wird. Die heute üblichen Maße, wie Anzahl benötigter Arbeitsstunden, lines of code, Anzahl Programme etc., erfüllen diese Anforderungen nicht. Sie messen Verbräuche und lassen kein zuverlässiges Maß für die Produktgröße zu. Sie sind als Maß genau so unzuverlässig wie der Benzinverbrauch eines Kraftfahrzeuges als Maß für die Entfernung zwischen zwei Orten. Zur Bestimmung der Größe einer Software setzt sich international ein funktionsorientiertes Messen durch. Hierbei wird nicht das fertige Softwareprodukt an seinen technisch ausführbaren Codierungen gemessen, sondern an der Funktionalität, die dem Anwender in der Software zur Verfügung gestellt wird. Dieses Maß ist für eine Software immer gleich, unabhängig davon, für welche Hardware und mit welcher Technik sie realisiert wird. Ein Vergleich zum Hausbau soll dies erläutern: Die Größe eines Gebäudes wird sinnvoll an seiner Funktionalität in cbm oder qm gemessen; sie an der Menge der verbrauchten Steine oder des verbrauchten Betons zu messen, wäre zwar theoretisch möglich, ließe aber keine Vergleiche bei unterschiedlichem Material und Technik zu. Das heute am meisten genutzte funktionale Maßsystem basiert auf der Function Point Analysis von A. Albrecht aus dem Jahre 1978. Seine Maßeinheit ist das Function Point. Nach Albrecht wird die Funktionalität einer Software aus der Sicht des Anwenders ermittelt und gemessen. Vereinfachend kann man sagen, daß die Größe der Funktionalität an der Zahl der Informationen gemessen wird,
Die Einführung einer Software Metrik ist eine zwingende Voraussetzung, um ein internes Softwarecontrolling aufzubauen und zu nutzen. Das Meßsystem sollte funktionsorientiert und unabhängig von jeder Art Softwaretechnik sein, denn nur dann lassen sich Auswirkungen unterschiedlicher Techniken auf die Produktivität und damit auf die Kosten einer Software ermitteln und verfolgen. Eine funktionsorientierte Software Metrik liefert im Funktionsumfang die Basiskennzahl, auf deren Grundlage sich Zustände beschreiben und Veränderungen planen und verfolgen lassen.
3 Produktivität in der Softwareentwicklung Die Produktivität (Verhältnis von Output zu Input) in der Softwareentwicklung ist bis heute nur in wenigen deutschen Unternehmen und Verwaltungen bekannt. Die vorhandenen Berichtswesen dienen fast ausschließlich der Projektsteuerung und der Ermittlung der Produktkosten. Aus ihnen kann der Input in Zeit- oder Kosteneinheiten abgelesen werden. Der dagegenstehende Output ist nicht ersichtlich. Das bisherige Berichtswesen muß um eine Größe für den Output, seien es Function Points oder ähnliche Maßgrößen erweitert werden. Erst wenn z.B. die Function Points und die für deren Realisierung erbrachte Zeit bekannt ist, läßt sich die Produktivität in einzelnen Projekten und als Durchschnitt für Entwicklungsumgebungen ermitteln. Man wird auch dann verfolgen können, welche Auswirkungen Änderungen bei einzelnen Kostenverursachern auf die Produktivität im Softwarebereich haben. Es wird z.B. aus dem Berichtswesen ersichtlich werden, ob eine Investition in neue Tools zu einer Verbesserung der Produktivität führte oder nicht. Die fehlenden Produktivitätskennzahlen ließen in der Vergangenheit derartige Analysen nicht zu. Fehlende Kennzahlen für die Produktivität machten es in der Vergangenheit unmöglich, durch Branchenvergleiche festzustellen, wie die Produktivität der Softwareentwicklung des eigenen Unternehmens im Vergleich zu gleichgelagerten Unternehmen einzuordnen ist. Dies muß heute nicht mehr sein. In zahlreichen Veröffentlichungen werden Kennzahlen genannt, an denen man sich vergleichen kann. So werden z.B. in "Worldwide Software Development , The Benchmark," erschienen bei International Software Benchmarking Standards Group Ltd., Australien, 1998, folgende Größen für die Produktivität in der Softwareentwicklung genannt: Aufwand in Stunden pro Function Point:
Derartige in der Literatur veröffentlichte Kennzahlen sind jedoch mit Vorsicht zu interpretieren. In der Regel fehlen eindeutige Erläuterungen für die verwendeten Bezeichnungen und die Datenbasen, auf denen die ausgewiesenen Ergebnisse beruhen. Zuverlässiger, aber wesentlich teurer, sind Benchmarkings, die von mehreren Dienstleister für ein Unternehmen erstellt werden. Die höhere Zuverlässigkeit ergibt sich aus der Tatsache, daß diese Dienstleister darauf achten, daß die Basiswerte nach einem einheitlichen Muster bei ihren Kunden ermittelt und aufbereitet werden. Als Argument gegen die Einführung einer Software Metrik ähnlich der Function Point Analysis wird meistens angeführt, daß der Aufwand für die Ermittlung der funktionalen Größe eines Softwareproduktes in keinem Verhältnis zum Nutzen stehen wird. Diese Aussage ist schlicht falsch. Auch für große Projekte von ca. fünf Mannjahren wird erfahrungsgemäß nur ein Arbeitstag benötigt, um den funktionalen Umfang nachträglich zu ermitteln. Ist der Aufwand größer, so kann davon ausgegangen werden, daß eine unvollständige Anwenderdokumentation vorliegt. Der Mehraufwand wird dann durch eine notwendige Nachdokumentation verursacht. Generell kann man feststellen, daß mit der Einführung der Function Point Analysis der Zwang zu einer vollständigen Anwenderdokumentation wächst. Die Kenntnis der Produktivität im Zusammenhang mit Entwicklungsumgebungen und Produktgruppen ist die Voraussetzung für den Aufbau und die Nutzung eines Kostenmanagements in der Softwareentwicklung. Erst die Einführung einer Software Metrik zur Bestimmung der Produktgröße und die Kenntnis der eigenen Produktivität bieten die Chance, eine zuverlässige Aufwandschätzung in der Planungsphase anstehender Projekte zu erhalten. Weil diese Werte bis heuten nicht verfügbar sind, scheint es eine Besonderheit der Softwareentwicklung zu sein, daß die Planungswerte für eine Softwareentwicklung regelmäßig und merklich überzogen werden.
4 Software Metrik im Projektmanagement 4.1 Aufwandschätzung Die Software Metrik mit der Function Point Analysis wird heute vorwiegend in der Aufwandschätzung eingesetzt. Allzu oft werden Function Point Analysis und Aufwandschätzung gleichgesetzt. Die Aufwandschätzung mit der Function Point Analysis setzt voraus, daß der Umfang der in der Aufgabenstellung enthaltenen Funktionalität in Function Points bekannt ist und Diese zwei Forderungen werden heute in den meisten Softwarebereichen nicht erfüllt. Mit dem Hinweis auf einen vermeintlichen Zeitdruck werden die Aufwandschätzungen auf der Basis eines unvollständigen Pflichtenheftes vorgenommen. Das Ergebnis ist, daß nicht falsche Aufwandschätzungen erstellt werden, sondern daß ein anderes Produkt geschätzt wird, als später abgeliefert wird. Solange in der Softwareentwicklung sich nicht die Erkenntnis durchsetzt, daß die Genauigkeit einer Schätzung vom Stand der Kenntnis von dem zu erstellenden Produkt abhängt, kann keine Verbesserung bei den Aufwandschätzungen eintreten. Erfahrungsgemäß kann man davon ausgehen, daß 5 % des späteren Gesamtaufwandes benötigt werden, um ein hinreichend genaues Pflichtenheft als Basis für eine Aufwandschätzung zu erstellen. Eine Statistik mit Produktivitätskennzahlen kann nur dann aufgebaut werden, wenn in den Berichtswesen nicht nur die Kosten und Zeiten, sondern auch die dagegen stehende Größe des erstellten Produktes ausgewiesen wird. Die heutigen Berichtswesen müssen also um die Produktgröße (Output) erweitert werden. Während in der Fertigungsindustrie die Erfassung des Outputs den Mitarbeitern keine Probleme macht, muß im Softwarebereich anscheinend eine Barriere aus dem Weg geräumt werden. Es muß darauf hingewiesen werden, daß eine stabile Kennziffer für die Produktivität nur dann gewonnen werden kann, wenn ein stabiles Entwicklungsumfeld vorliegt. Werden ständig die Arbeitsmethoden und -techniken in der Softwareentwicklung geändert, dann kann auch keine zuverlässige Kennzahl für die Produktivitätskennzahl gewonnen werden. Häufige Wechsel des Entwicklungsumfeldes bedeuten, daß sich kein Know How bei den Mitarbeiter aufbauen kann, das zu einer stetigen Verbesserung der Produktivität in der Softwareentwicklung führt.
4.2 Bewertung externer Leistungsanbieter Die Ermittlung von Function Points ist in zwei Stadien der Zusammenarbeit mit einem externen Leistungsanbieter wichtig:
In der Angebotsphase zwingt die Ermittlung der Function Points zu definieren, welche Funktionalität von der Software erbracht werden muß und in die Zählung der Function Points eingegangen ist. Dadurch wird das Angebot zwangsweise informativer als heute üblich. Die ermittelten Function Points machen die Angebote global vergleichbar. D.h., man kann erkennen, ob alle Angebote den gleichen inhaltlichen Umfang haben. Es ist dagegen keine Aussage abzuleiten, ob die Inhalte die richtigen sind. Dennoch ist das Verhältnis von Function Points zum Preis eine wichtige Kennzahl für das Preis-/Leistungsverhältnis der Angebote. Die Function Points zum Zeitpunkt der Leistungsabnahme sind ein Maß für den Umfang der abgelieferten Software. In Streitfällen schaffen die Function Points eine Vergleichsbasis für den vertraglich zugesicherten und effektiv gelieferten Umfang des Vertragsgegenstandes. Bei reinen Dienstleistungsverträgen ist die Produktivität des Leistungserbringers von Interesse. Im Angebotsstadium wird kaum ein Anbieter selber Angaben zu seiner Produktivität machen. Langfristige Bindungen zu einem Lieferanten machen jedoch dessen Produktivität transparent. Sollte es bei Dienstleistungsverträgen zum Streit wegen zu geringer Leistungserbringung kommen, so können ermittelte Produktivitätskennzahlen zur Klärung beitragen.
4.3 Standard Software zuverlässig kalkulieren. Durch den Einsatz von Standardsoftware wird beabsichtigt, Kosten zu senken, Termine zu verkürzen und Personalunabhängigkeit zu erreichen. Diese Ziele werden leider in sehr vielen Fällen zunächst nicht erreicht, weil der Anwender erst nach dem Kauf der Software eine Diskrepanz zwischen der benötigten und der gelieferten Funktionalität bemerkt. In der Praxis wird oft die Größe der Standardsoftware als eine Garantie für eine richtige Entscheidung angesehen. Die folgende Grafik zeigt beispielhaft, welche Informationen sich mit Hilfe der Function Point Analysis für einen Abgleich von Anwenderprofil und Produktprofil im Hinblick auf eine Standardsoftware gewinnen lassen.
Die erste Säule zeigt die vom Anwender geforderte Funktionalität, das Anwenderprofil, das mit 1000 Function Points angenommen wird. Eine Standardsoftware, die zur Lösung der Funktionalität vorgesehen wird, bietet in seinem Produktprofil eine Funktionalität von 1200 Function Points (brutto) (2. Säule). Der Überschuß von 200 Function Points spricht zunächst dafür, daß die Standardsoftware die Anforderungen des Anwenders mehr als voll abdeckt. Die Praxis zeigt allerdings, daß moderne komplexe Standardsoftware in den meisten Fällen mehr Funktionalität enthält als der einzelne Anwender benötigt, aber dennoch nicht alle individuellen Anforderungen abdeckt. Nehmen wir an, ein inhaltlicher Vergleich von Anwender- und Produktprofil würde ergeben, daß der Anwender aus dem Gesamtprodukt lediglich eine Funktionalität in einer Größe von 700 Function Points (netto) nutzen kann (3. Säule), dann liegen also 500 Function Points (Tara) des Softwareproduktes für den Anwender ungenutzt brach. Der Grad der Nutzung der Standardsoftware ist mit 7 zu 12 nicht gerade optimal (4. Säule). Damit der Anwender die von ihm benötigte Funktionalität erhält, ist die Standardsoftware um eine Funktionalität von 300 Function Points (Supplement) zu ergänzen. Der Grad der Erweiterung der Standardsoftware ist dann 3 zu 7 (5. Säule). Die Erweiterung der Software hat eine langwirkende Konsequenz, die die 6. Säule zeigt. Dem Wartungsballast von 500 ungenutzten Function Points stehen 1000 nutzbare Function Points gegenüber. Aus der vorstehenden Betrachtung von Anwender- und Produktprofil lassen sich u.a. folgende Fragen für die Entscheidungsfindung ableiten bzw. beantworten:
Den Aufwand für die eigenen funktionalen Ergänzungen zu ermitteln wird in der Praxis schwierig sein. Es wird daran scheitern, daß der Anwender keine Erfahrungswerte aus der Vergangenheit einbringen kann. Ein Unternehmen wird allenfalls einmal in einem Jahrzehnt eine komplexe Standardsoftware einführen, so daß es sich keine zuverlässige Erfahrungsdatenbank aufbauen kann. Kurz und mittelfristig sind solche Erfahrungen nur bei anderen Anwendern zu erhalten, die die gleiche Software mit ähnlichen Ergänzungen installierten. Ein Koordinator für eine Erfahrungsdatenbank über den Aufwand für Installationen und Ergänzungen einer Standardsoftware wäre im Idealfall der Softwarelieferant. Er müßte diese Werte bei seinen Kunden abfragen, neutralisieren und für Prognosen anbieten können. Der Lieferant müßte die Werte liefern, die sonst von einem Benchmarking Unternehmen im Rahmen eines Beratungsvertrages geliefert werden. Das Fehlen jeglicher Software Metrik macht es unmöglich einen festen Bezugspunkt zu finden, auf den sich die notwendigen Vergleiche gemeinsam beziehen. Die Unkenntnis über Inhalt und Umfang des Anwender- und Produktprofils bei der Beschaffung einer Standardsoftware hat in der Vergangenheit sehr häufig zu Schwierigkeiten bei deren Einführung geführt. Auftretende Mißerfolge sind nicht allein der Standardsoftware zuzuschreiben, sondern einer unzureichenden Entscheidungsfindung in der Angebotsphase.
4.4 Projektinhaltskontrolle Aufwandschätzungen scheitern oft daran, daß das ursprüngliche Pflichtenheft im Verlauf des Projektes geändert und erweitert wird. Bei Projekten zu Festpreisen muß dies zwangsläufig zu Streitigkeiten zwischen Auftraggeber und -nehmer führen. Derartige Spannungen können vermieden werden, wenn eine Veränderung des Projektumfanges objektiv nachgewiesen werden kann.
Es ist deswegen notwendig, zu Beginn jedes Projektes den Umfang seiner Funktionalität zu messen und zu dokumentieren. Hierzu bietet sich für die Praxis die Function Point Analysis an, da sie ausschließlich aus der Anwendersicht arbeitet und unabhängig von jeder Art der technischen Realisierung ist. An der folgenden Tabelle werden die Vorteile einer Projektinhalskontrolle dargestellt. Aus dem Vergleich der Function Points zu Beginn und Ende des Projektes wird ersichtlich, daß die abgelieferte Funktionalität um 100 Function Points größer ist als ursprünglich geplant. Diese Information wäre von Bedeutung , wenn nachträglich eine Begründung für Termin- und Kostenüberziehung gesucht wird. Wichtiger als diese Information wären jedoch rechtzeitige Hinweise, daß mit Überziehungen zu rechnen ist. In unserem Beispiel hätte man diese Hinweise bereits in der 2. Phase erhalten. Eine Ermittlung der Function Points hätte gezeigt, daß die ursprüngliche Aufgabenstellung um 23 % erweitert wurde. Zu diesem Zeitpunkt kann also bereits eine Korrektur der Planung erfolgen. Ein weiterer Mangel des heutigen Projektmanagements wird in der Tabelle sichtbar. Die schlechte Planungsqualität führt dazu, daß im Verlauf des Projektes nicht nur neue Funktionen hinzukommen, sondern auch Funktionen gestrichen werden. Wenn dies der Fall ist, ist der Verlust an Arbeit, die nicht zu einem Ergebnis im späteren Produkt führt , um so größer je später diese Korrektur erfolgt. In dem Beispiel sind ca. 8 % des Aufwandes für Funktionen aufgebracht wurden, die nicht zu Ende entwickelt wurden. Die Software Metrik ermöglicht nicht nur eine Analyse der Projektkosten. Sie liefert auch Kennzahlen zur Planungsqualität in Form von Verhältniszahlen
5 Software Metrik im Bereichsmanagement 5.1 Maßnahmenkontrolle Im Bereich der Softwareentwicklung kann man nur in wenigen Unternehmen oder Verwaltungen von einem konsequenten Management reden. Allzu stark sind die Organisationen auf die Projekte ausgerichtet. Welchen Stellenwert die Software Metrik im Prozeß der Softwareentwicklung hat, zeigt das Capability Maturity Modell von Watts Humphrey, Software Engineering Institute (SEI, USA). Erst die vierte von fünf Reifestufen des Softwareentwicklungsprozesses wird als "Management" bezeichnet. Voraussetzung dafür ist, daß Software Metriken eingeführt sind. Erst wenn ein Prozeß quantifiziert dargestellt wird, kann man von einem definierten Standpunkt aus, nachvollziehbare Ziele festlegen. Die folgende Grafik zeigt, daß das Ziel, auf der Grundlage eines neuen Tools die Produktivität zu verbessern, zwei Jahre nach dessen Einführung erreicht wurde.
Die vorstehende Grafik zeigt aber auch Folgendes: Berücksichtigt man den Trend in der Entwicklung der Produktivität vor der Einführung des Tools, so erscheint die Maßnahme jedoch als nicht sehr positiv. Stetige Veränderungen in anderen Kostentreibern, z.B. die Erfahrung der Mitarbeiter, scheinen in der Vergangenheit zu einer gleichwertigen Verbesserung der Produktivität geführt zu haben. Benchmarking Firmen wollen festgestellt haben, daß vorhandene Rationalisierungsreserven durch den schnellen Wechsel von Methoden und Tools nicht konsequent genutzt werden. Ähnliche Analysen lassen sich mit der Hilfe der Software Metrik auch im Hinblick auf andere Gesichtspunkte durchführen, z.B. Entwicklung der Qualität in Abhängigkeit von getroffenen Maßnahmen.
5.2 Wartungskosten Wartungskosten sind heute in vielen Unternehmen der Hauptposten im Softwarebudget. Sie stehen seit ca. 30 Jahren in einem festen Bezug zu den Entwicklungskosten bzw. den Lizenzgebühren. Da keine detaillierte Berichtswesen über die Ursachen, Art und Aufwand der Wartungsaktivitäten geführt werden, wird dieser Kalkulation bisher auch nicht widersprochen.
Die Anwendung der Function Point Analysis zeigt jedoch, daß der Wartungsaufwand nicht linear über die Zeit verläuft. Er hängt vielmehr von dem Alter der Software ab. Es leuchtet ein, daß z.B. im ersten Jahr nach der Installation der Aufwand für die Behebung aufgetretener Fehler größer ist als in den Folgejahren. Die folgende Tabelle zeigt den typischen Verlauf des Wartungsaufwandes pro Jahr bezogen auf ein Function Point.
In der praktischen Arbeit mit obiger Kurve ist zu beachten, daß die Grundlast der Wartung (horizontale Linie) sehr stark von der Anzahl der Anwender und nicht von dem Softwareprodukt selbst bestimmt wird.
5.3 Budgetierung Die Festsetzung der Budgets für den Softwarebereich erfolgt heute vorwiegend immer noch nicht bedarfsorientiert. Die Budgets werden vielmehr auf der Grundlage historisch stabilisierter Beträge von Jahr zu Jahr fortgeschrieben. Die bedarfsorienterte Budgetierung setzt voraus, daß sowohl der Bedarf als auch die Produktivität, mit der er realisiert werden kann, bekannt sind. D. h. erst die Nutzung der Software Metrik macht die bedarfsorientierte Budgetierung möglich. Die nachfolgende Tabelle zeigt vereinfacht, wie auf der Grundlage eines Softwareportfolios ein bedarfsorientiertes Budget aufgebaut werden kann.
Die Bewertung der Objekte eines Budgets mit Umfang (Function Points) und Produktivität lassen eine flexiblere und realistischere und damit zuverlässigere Planung gegenüber den heute üblichen Methoden zu.
5.4 Produktmanagement Die starke projektorientierte Sicht im Softwaremanagement vernachlässigt eine Sicht auf die Softwareprodukte. Die Softwareprodukte, z.B. eine Finanzbuchhaltung, werden über die Jahre durch viele ergänzende und funktionsändernde Projekte aufgebauscht und damit immer wartungsunfreundlicher. Da keine konsequente Zusammenführung der Aufwände der einzelnen Projekte zu einem Projektaufwand erfolgt, erhält man auch keine Informationen darüber, wenn ein Produkt unwirtschaftlich in sein wird. Ein Produktmanagement analog zu den Maschinen- und Gerätekarten in der Industrie, wird es transparent machen, wenn eine alte Software sinnvoll durch eine neue zu ersetzen ist. Die folgenden Tabellen zeigen die Entwicklung der kumulierten Produktkosten und des Produktwertes (Wiederbeschaffungswert) dar.
6 Zusammenfassung
Das interne Softwarecontrolling kann nur dann zu Erfolgen führen, wenn eine Software Metrik eingeführt wird. Zum heutigen Zeitpunkt sollte die Software auf einem funktionsorientierten Maßsystem beruhen. Nur ein solches System ermöglicht es, unterschiedliche Entwicklungssysteme im Hinblick auf ihre Kosten zu vergleichen. Dies ist notwendig, weil sonst die rasante technische Entwicklung keine stabilen Ausgangspunkte zur Messung von Veränderungen zuläßt. Ein chinesisches Sprichwort sagt, wenn man nicht weiß, wo man sich befindet, kann kein Kurs zur Erreichung eines Ziels vorgegeben werden. Ein wirkungsvolles internes Softwarecontrolling wird vielleicht auch Antwort auf Fragen geben, die bis heute unbeantwortet blieben. z.B. auf die folgenden drei: Warum wächst das Softwarebudget mit dem Bilanzvolumen? Warum führt die Nutzung von Standardsoftware bei der Mehrzahl der Anwender nicht zu einer merklichen Reduzierung bei den Softwarekosten? Warum sträuben sich die Softwareentwickler gegen die Nutzung von Software Metriken? Riedstadt, den 18.02.99 © Robert Hürten |
||||||||||||||||||
