Die Berechnung von Softwareprojekten und die Schätzung des Aufwandes bereiten vielfach Immer noch Schwierigkeiten. Kritisch setzte sich Thomas Noth mit dieser Thematik auseinander (siehe CW Nr. 3/84, Seite 23, "Softwareprojektschätzung erfordert mehr als starre Formeln"). Als Erwiderung auf seinen Beitrag stellt Thomas Gebert, Leiter der Anwendungsentwicklung der Börsen-Datenzentrale GmbH aus Frankfurt, ein Aufwandsschätzverfahren vor, daß in dem Frankfurter Haus selbst entwickelt wurde. Das BDZ-Aufwands-Kostenschätzungsmodell beruht auf der Berechnung von "Lines of Code" (LOC) in Verbindung mit der CoCoMo-Formel von Barry Boehm, die an die speziellen Erfordernisse angepaßt wurde.
Die Aufwands- und Kostenschätzung in einer sehr frühen Projektphase ist als Problem hinlänglich bekannt. Aufbauend auf Informationen aus der Durchführbarkeitsstudie hat die BDZ ein Modell zur Aufwands- und Kostenschätzung entwickelt, das weit überdurchschnittlich genaue Werte für den Entwicklungsaufwand, die Durchführungszeit, den durchschnittlichen Personalbedarf und daraus abgeleitet die Projektkosten liefert.
Die meisten Kostenschätzungsmodelle basieren primär auf der zu erwartenden Projektgröße in Lines of Code. Die Ergebnisse sind um so genauer, je exakter der Begriff "Lines of Code (LOC)"definiert ist und je näher das Endprodukt diesen Schätzwert erreicht. Die eigentliche Kunst der Kostenschätzung beruht also weniger in der Anwendung komplizierter Formeln als vielmehr in der möglichst genauen Ermittlung -der Produktgröße und des Entwicklungsumfeldes.
Der Schätzvorgang vollzieht sich demnach in zwei Phasen. Zunächst wird in der Quantitätsberechnung die Anzahl Lines of Code ermittelt. Im zweiten Schritt wird über eine auf BDZ-Verhältnisse angepaßte CoCoMo-Formel (Constructive-Cost-Model, vgl. B. Boehm, Software Engineering Economics, New Jersey, 1981) der Entwicklungsaufwand in Mann-Monaten sowie die Entwicklungszeit in Zeitmonaten errechnet. Aus diesen beiden Werten lassen sich zusätzlich die Produktivität in LOC/MM sowie der durchschnittliche Personalbedarf ableiten.
Für die Qualitätsberechnung werden Angaben über die Verarbeitungsvorgänge des zu entwickelnden Systems, seine Datenobjekte sowie die E/A-Schnittstellen benötigt. Dabei verstehen wir unter einem Verarbeitungsvorgang einen aus Sicht des Sachbearbeiters abgeschlossenen Geschäftsvorfall, also einen On-line-Dialog oder ein Batch-Programm. Unter Datenobjekten werden alle Datenablagen des künftigen Systems verstanden, Bei existierenden Datenstrukturen sind dies Dateien oder Datenbanken; anderenfalls alle durch identifizierende und beschreibende Merkmale klassifizierbaren Datenmengen. E/A-Schnittstellen schließlich sind alle Druckausgaben, Bildschirmmasken und sonstigen Kommunikationsmittel. Diese Informationen sind bereits nach der Durchführbarkeitsstudie verfügbar.
Zur Ermittlung der Verarbeitungsanweisungen des Systems werden für jeden Vorgang die Anzahl und Komplexität seiner Funktionen geschätzt. Die Funktionen sollten bei Codierung in Cobol etwa einer Section entsprechen. Die Komplexität mißt sich an der Anzahl Entscheidungen, logischen oder mathematischen Gleichungen und Ausnahmeregeln. Anschließend wird jede Funktion mit einem Basiswert von 60 LOC bewertet. Je nach Komplexitätsgrad wird die ermittelte Anzahl mit 0,8 (niedrig), 1,0 (mittel) oder 1,2 (hoch) gewichtet. Die Gesamtsumme wird mit einem generellen Overhead-Faktor von 1,2 multipliziert (siehe Beispiel 1).
In der Quantitätsberechnung wird jedes Datenelement mit 2 LOC bewertet. Je nach Integrationsgrad wird die Summe mit 1,0 (niedrig), 1,2 (mittel) oder 14 (hoch) gewichtet. Der Integrationsgrad spiegelt die Anzahl der Beziehungen der Datenobjekte untereinander wider, wobei davon auszugehen ist, daß E/A-Schnittstellen immer einen niedrigen Integrationsgrad haben. Auch hier wird die Gesamtsumme mit einem generellen Overhead-Faktor von 1,2 multipliziert. In diese Berechnung dürfen vorhandene Datenobjekte , deren Beschreibung über Data-Dictionary-Systeme automatisch generiert werden können oder für die Copies gespeichert sind, nicht miteinfließen (siehe Beispiel 2).
Die Summe der Verarbeitungsanweisungen und der Datenanweisungen stellt die Produktgröße in Lines of Code dar. Lines of Code in diesem Sinne sind alle Programmanweisungen ausschließlich der Kommentare, Job-Control-Statements sowie externe Datei- und Nachrichtenformatbeschreibungen (DBDS, PSBS, MFS). Dieser Wert wird auf Kilo Lines of Code (KLOC) verdichtet und fließt im ersten Schätzansatz in die Basis CoCoMo-Formel ein. Die Formel gilt für Online- und Batch-Mischprojekte und Programmierung in Cobol:
MM = 2,8 x (KLOC) 1,05
Für ein Softwaresystem mit 32 KOLC ergibt sich daraus ein Aufwand von 106 MM. Bei der Entwicklungszeit wird folgende Formel angesetzt:
T = 2,5 x (MM) 0,38
In dem obigen Bereich errechnet sich eine Entwicklungszeit von zirka 15 Monaten bei einem durchschnittlichen Personalbedarf von 7 Mitarbeitern. Dabei wird eine Produktivität von 301 LOC/MM, oder, bei 18 MT/MM von 17 LOC/MT erzielt.
Dieser Wert erscheint zunächst sehr niedrig. Man muß jedoch berücksichtigen, daß diese Angabe für alle Projektmitarbeiter einschließlich der Fachabteilungen und für alle Projektphasen ab Fachkonzept gilt. Damit wird ein Fehler vieler Kostenmodelle vermieden, die nur den DV- oder Programmieraufwand in Ansatz bringen. Ein weiterer Vorteil der CoCoMo-Formel ist die Berücksichtigung des zunehmenden Kommunikationsaufwandes bei steigender Projektgröße, dem durch den Exponenten in der Formel Rechnung getragen wird.
Der erste Schätzansatz kann durch Einbringung weiterer Kostengrößen, wie Qualitätsorderungen und Produktivitätsfaktoren verfeinert werden. Eine regelmäßige Überprüfung und Anpassung der Berechnung parallel zum Projektfortschritt ist im Rahmen des Projektmanagements selbstverständlich. Mit zunehmender Detaillierung der Informationen über das zu entwickelnde System und tieferer Kenntnis des Projektumfelds lassen sich mit verfeinerten Formeln und Tabellen aus dem Buch "Software Engineering Economics" (Literaturangabe siehe oben) erstaunlich genaue Ergebnisse über den Restaufwand und die verbleibende Entwicklungszeit ableiten. Dieser Aufwand lohnt sich jedoch nur bei anspruchsvolleren Projekten mit Produktgrößen über 10 KLOC. Ungeeignet ist die Formel für Produkte mit einer zu erwartenden Größe von kleiner 2 KLOC. Hier haben sich Analogschätzverfahren als genauer erwiesen. Bei Produktgrößen zwischen 2 KLOC und 10 KLOC sowie reinen Batchsystemen lagen wir in der Schätzung um bis zu 30 Prozent über dem tatsächlichen Wert. Wir haben in diesen Fällen den von uns gewählten Multiplikator von 2,8 auf den Originalwert von 2,4 beziehungsweise auf 2,2 reduziert.
Zusammenfassend läßt sich sagen, daß dieses Kostenmodell nach bisherigen Erfahrungen eine recht genaue Ermittlung des Aufwandes und der Kosten für Software-Entwicklungsprojekte zuläßt. Da die erforderlichen Informationen ohnehin in der Durchführbarkeitsstudie anfallen, entsteht kein zusätzlicher Aufwand.