Eine gründliche Analyse der Software-Kosten muß neben der generellen finanziellen Einschätzung vor allem die Risiken bei Entwicklung und Wartung miteinbeziehen. Veranschlagte Vorbereitungszeit und finanzielle Auflagen bergen die Gefahr, daß die grundlegenden Eingangsgrößen Programmumfang und Produktivität der Software-Entwicklung durch die subjektiven Maßstäbe des Analytikers geprägt werden. Deshalb empfiehlt es sich, einen genauen Kriterienkatalog zu erstellen.
Neueste Untersuchungen weisen auf einen überproportionalen Anteil für Software-Wartung hin, wenn man den Aufwand für Fehlerkorrektur und Aktualisierung mit den reinen Entwicklungskosten vergleicht. Als Lösung dieses Problems gilt der Einsatz von selbstdokumentierenden, standardisierten höheren Sprachen. So strebt beispielsweise das US-Verteidigungsministerium an, bis 1990 für seine Anwendungen nur noch Cobol und Ada zu verwenden. Wenn auch der Faktor Software-Entwicklung inzwischen als kalkulierbare Größe erscheint und das Risiko hauptsächlich bei den Aufwendungen für die Wartung liegt, bleibt die Kostenanalyse letztlich doch für alle beteiligten Vertragspartner ein heißes Eisen.
Die Programmgröße abschätzen
Der erste Schritt der Kostenabschätzung besteht in der Definition des Aufgabenspektrums. Hierzu gibt es viele Methoden wie Top-down, Bottom-up, Analogie und Delphi. Jede dieser Techniken hat ihre Vor-und Nachteile. Üblicherweise werden deshalb mindestens zwei von ihnen angewendet, um eine Gegenprüfung zu gewährleisten.
Die Abschätzung der Programmgröße beginnt beim Pflichtenheft. Die Qualität dieses Dokuments ist der erste entscheidende Faktor für die Entwicklung. Eine gute und eine schlechte Spezifikation unterscheiden sich darin, wie genau die Auswirkungen jeder einzelnen Systemkomponente definiert und abgegrenzt sind.
Ein zweiter Gesichtspunkt, der die Entwicklung im Hinblick auf das Anforderungsprofil beeinflußt, ist dessen Interpretation. Oft hört man von Programmierern Äußerungen wie: "Ich habe die tatsächlichen Anforderungen noch nicht gesehen", oder: "Die an der Spitze ändern Teile der Spezifikation nach Lust und Laune". Solche Bemerkungen sollten den Projektleiter dazu veranlassen, die Fähigkeiten des Analysators in Zweifel zu ziehen und sich Gedanken darüber zu machen, ob das Problem nicht zu komplex ist. Läßt sich die Analyse einer Programmstruktur zu mindestens 70 Prozent verwirklichen, sollte sie als erfolgreich angesehen werden. Die Implementierung von Software mit einer Fehlerrate von 30 Prozent läßt sich meist eher korrigieren als ein gleich hoher Unsicherheitsfaktor.
Definition und Wirkungskreis der Programmkomponenten lassen sich genauso auf die Berechnung der Produktivität anwenden wie auf die Größe. Zusätzlich gewinnen hier Programmiererfahrung- und -fähigkeit sowie Praxis im speziellen Anwendungsfall an Bedeutung. Als Maßstab. für die Erfahrung eines Programmierers kann der Vergleich mit bewährten Team-Mitgliedern dienen.
Die Fähigkeit eines Programmierers läßt sich anhand von Beurteilungen seines Werdegangs oder von Zeugnissen feststellen. Erfahrung in speziellen Anwendungsgebieten ergibt sich im Normalfall aus dem Werdegang. Es ist meist nicht möglich, gleich nach Abschluß der Analyse Aussagen über die exakte Zusammensetzung des Teams zu machen, ausgenommen über einige Schlüsselpersonen. Große Bedeutung kommt dem vertraglich festgelegten Umfang der Dokumentation in Verbindung mit Verantwortlichkeit des Kunden und exaktem Studium von Anleitungen zu.
Beim heutigen Stand der Software-Entwicklung sollte jeder Manager wenigstens ein Minimum an Dokumentation fordern. Es muß zumindest Anforderungsprofil, Integrationspläne und Testskripten, ferner Systemtestpläne und Testprozeduren enthalten.- Aus diesen Elementen werden automatisch Programmbeschreibungen, kommentierte Listings, Testergebnisse und Daten für die Generierung von Benutzerhandbüchern bereitgestellt. Ferner ist ein erfahrener und reaktionsschneller Mitarbeiterstamm nötig, um Korrekturen in der Entwicklung und Aktualisierung der Dokumentation auszuwerten, zu verarbeiten und zu autorisieren. Anderernfalls können die Auswirkungen fatal sein.
Ein weiterer Hauptgesichtspunkt der Produktivität ist die Verfügbarkeit von Entwicklungs-Tools. Nach Möglichkeit sollten Grob- und Feindesign unter Verwendung von Workstations durchgeführt werden, die eine Kombination von Flußplansymbolik und Texten erlauben. Eine von ihnen, das Apollo-System, wurde angepaßt, um die Designeffizienz durch den Aufbau neuer Symbolbibliotheken und die Verwendung von 14 Ebenen eines CAD/CAM-Detailspeichers zu erhöhen. Der Einsatz dieses Systems vereinfacht nicht nur die Erstellung der Dokumentation, sondern auch ihre Aktualisierung und Modifikation.
Interaktive Entwicklungssysteme mit Realtime-Kompilierungs- oder Assemblierfähigkeiten sollen im Idealfall jedem Programmierer oder Testingenieur drei Stunden täglich zur Verfügung stehen. Entwicklungssysteme mit geringerer Verfügbarkeit vermindern die Produktivität. Zwei typische Vertreter dieser Kategorie sind Batch-Systeme mit 4-beziehungsweise 24-Stunden-Zyklen. Software wird nach wie vor auf solchen Systemen entwickelt. Die Produktivitätseinbuße kann hier jedoch bis zu 50 Prozent betragen. Wenn es gelingt, bei der Auswahl der Mitarbeiter Talent mit Erfahrung auf den Gebieten Design, Integration, Test und Programmierung zu verbinden, kann die Produktivität dieser Gruppe als fixer Mittelwert betrachtet werden.
Weitere Kostenfaktoren
Die Bedeutung der Kommunikation zwischen den Mitarbeitern ist schon oft angesprochen worden. Besonders hat sich dabei gezeigt, daß es nicht viel Sinn macht, weitere Mitarbeiter hinzuzuziehen, wenn ein Projekt bereits in Verzug geraden ist. Es verzögert sich dann erfahrungsgemäß nur noch mehr. Die Kommunikationsprobleme resultieren meist aus einem ungenauen Anforderungskatalog und schlechten Managementpraktiken bei der Aufgabenverteilung. Als Folge davon sind einzelne Mitarbeiter dem Team lediglich ein Klotz am Bein. Die Chefprogrammierer können noch so sehr versuchen, die Situation in den Griff zu bekommen; wenn das Management seiner Aufgabe nicht gewachsen ist, haben sie trotzdem keine Chance.
Eine Alternativmethode beruht auf dem Kontrollspannenprinzip. Dabei Werden bei der Zusammensetzung von Programmiermannschaften und Managementhierarchien Fünfergruppen gebildet.
Nachdem das Management das Ergebnis der Kostenauswertung erfahren hat, findet normalerweise ein Briefing statt. Das erste Dokument, auf das hier Bezug genommen wird, ist für gewöhnlich das Work Breakdown Statement (WBS), das in Grafik 1 für ein Autopilot-Projekt abgebildet ist. Obwohl hier für ein bestimmtes Programm dargestellt, zeigt das WBS im wesentlichen die allgemeinen Kostenelemente eines Programms.
Die Reihenfolge, in der die einzelnen Teilaufgaben durchgeführt werden müssen, ist zwar in der Entwicklungsphilosophie des Computerprogramms enthalten, jedoch sollte sie entsprechend Grafik 2 weiter aufgeschlüsselt werden. Die Netzpläne stellen eines der besten grafischen Hilfsmittel dar, um das Verhältnis von Ursache und Wirkung während der Entstehungs- und Integrationsphase des Softwareprojekts wiederzugeben. Die Darstellung zeigt nur die Beziehung der drei Hauptfunktionen des Auto-Pilotprogramms. Eigentlich sollte jedoch aus der obersten Netzplanebene ersichtlich werden, wie die Hardwareverfügbarkeit die Systemintegration von Hard-und Software vor der Endabnahme unterstützt. Die nächste Ebene bildet normalerweise die Modulintegration der Hauptprogrammfunktionen ab.
Wenn viele Elemente vorhanden sind, empfiehlt es sich, weiter zu untergliedern und Design, Kodierung, Test der Einheit und Modulintegration vor Inbetriebnahme aufzuzeigen. Da mehrere Modifikationen oder Neuanordnungen dieser Abfolge nötig sein können, um eine vollständige, ausgewogene Darstellung zu erreichen, scheint der Einsatz eines automatisierten Planungswerkzeugs angebracht. Ein Programm für die automatische Erstellung solcher Netzwerke steht für den Apple-Computer Lisa zur Verfügung. Sobald der Plan auf dieser Maschine fertiggestellt ist, werden die Wechselbeziehungen zwischen den einzelnen Knoten in Tabellen eingetragen. Ergeben sich Änderungen oder Modifikationen, so aktualisiert das System selbständig alle von der Veränderung betroffenen Folgeelemente.
Diese Methoden und Werkzeuge sollen einen reibungslosen Projektverlauf gewährleisten und dazu beitragen, daß alle Teammitglieder effektiver arbeiten können, wenn sie Grundlagen und Risiken der Kostenanalyse verstehen.
Edward L. Griffin, Progam Manager und Training Simulators, Martin Marietta Orlando Aerospace, Orlando, Florida