Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.02.1990 - 

Auch diffizile Berechnungen liefern nur Näherungswerte

Aufwand für komplexe Projekte läßt sich kaum exakt schätzen

Bei Aufwandsschätzungen von DV-Großprojekten beobachtet man immer wieder zu optimistische Erwartungen. Die Folge ist eine ständige Verschiebung der noch ausstehenden Meilensteine und sinkendes Vertrauen in die DV/Org.-Abteilung. Willy Wittstadt* hat versucht, eine Formel für erste Näherungsschätzungen bei Dialogapplikationen zu entwickeln.

Ohne Planung geht es nicht. Vor allem nicht ohne Zeitplanung. Personalkosten sind im Dienstleistungsbereich der Hauptausgabeposten. Trotzdem geht man bei Zeitschätzungen für DV-Projekte oft zu planlos, ja intuitiv vor. Dafür gibt es zwei Gründe: Zum einen ist der Zeitaufwand bei entsprechendem Detaillierungsgrad relativ hoch (etwa drei Prozent der Gesamtprojektdauer); zum anderen fällt das Ergebnis bei indifferenter Anwendung oft genauso schlecht aus wie das einer "Daumenpeilung".

Simple Dreisatz-Rechnung gilt nicht für DV-Projekte

Bei Zeitüberschreitungen unterstellt man zu gerne, daß es sich um eine Ausnahme, um ungünstige Randbedingungen oder ähnliches gehandelt haben muß, und bleibt optimistisch - bis zur nächsten Terminüberschreitung beim nächsten Projekt. Die Ursache liegt vermutlich unter anderem an der vertrauten Dreisatz-Rechnung, die bei DV-Projekten wegen steigendem Koordinationsaufwand bei wachsender Teamgröße jedoch nicht anwendbar ist.

Haben relationale Datenbanken und strukturierte, normierte, modularisierte, objektorientierte oder 4GL-Programmierung uns schon wesentlich zum Durchbruch hinsichtlich der Entwicklungsgeschwindigkeit verholfen? Was die 4GL anbelangt, so ist diese Frage zu bejahen (unter Inkaufnahme anderer Nachteile, wie zum Beispiel fehlender Norm). Was die objektorientierte Programmierung anbelangt, so ist festzustellen, daß solche Programmiersprachen nur selten von DB/DC-Anbietern unterstützt werden, also ein eventueller Vorteil nicht zum Tragen kommen kann.

Die am weitesten verbreitete Schätzmethode für die Projektdauer dürfte das Function-point-Verfahren (FPV) sein, bei dem einzelne Programmfunktionen (zum Beispiel Ein- und Ausgaben) mit Punktzahlen belegt werden. Je schwieriger die Funktionen, umso höher die Punktzahlen (Function points). Die Zwischensumme der so ermittelten Function points wird abschließend über 14 vorgegebene Einflußfaktoren gewichtet.

In einer unternehmensspezifischen, nicht linearen Kurve (mit den Achsen Function points und Mannmonate) kann dann der Aufwand abgelesen werden. Da eine solche Kurve zumeist nicht vorliegt, wird häufig Bezug auf die sogenannte IBM-Kurve genommen, die von IBM für interne Projekte erstellt worden ist. Der Aufwandsschätzer sollte im Laufe der Zeit ein Gespür dafür bekommen, ob seine Entwicklungsmannschaften auf oberhalb oder unterhalb dieser Kurve "landen" und daraus seine unternehmensspezifische Kurve ableiten.

Dieses Verfahren ist jedoch relativ aufwendig und verlangt viel Erfahrung und Fingerspitzengefühl bei der Beurteilung der Einzelkomponenten. Die Frage wird hier vor allem danach gestellt, was, nicht wie es zu realisieren ist. Es wird also nicht festgelegt, ob aus einer Dialogapplikation zehn oder 100 Bildschirmmasken resultieren, wenngleich bei der Schätzung diese Information ableitbar wäre.

Die Ermittlung von Function points fällt bei reinen Dialogapplikationen und den zunehmend mächtigeren Informations- und Datenbanksystemen sehr schwer, da die unterschiedlichen Datenbankkonzepte, aber auch die Möglichkeiten von feld- und blockorientierten Interaktionen zu gänzlich unterschiedlicher Programmstruktur führen können und somit die klassische Bewertung von Ein- und Ausgaben zu einem Glücksspiel wird.

Neben dem FPV gibt es noch eine Reihe weiterer Verfahren, die nicht selten im Ergebnis zu stark voneinander abweichen. Dabei kann im Einzelfall das Verhältnis von eins zu fünf erreicht werden. Für Schätzverfahren sind in der Literatur über 1000 Einflußfaktoren bekannt, die sich oft gegenseitig neutralisieren. Ist also vielleicht bei all den Imponderabilien nicht ein einfaches Verfahren gefragt, wenigstens für die erste Näherung? Dies war meine Ausgangsfrage.

Zu schön wäre natürlich, wenn es ein einziges Kriterium gäbe, welches mit dem Gesamtaufwand gut korreliert, weshalb der Gesamtaufwand unmittelbar daraus abgeleitet werden könnte. Bei Dialogapplikationen liegt als solches Kriterium die "Anzahl Bildschirmmasken" nahe. Doch haben Dialogapplikationen nur Bildschirmmasken? Sind da nicht auch Listen zu drucken? Sind die Bildschirmmasken überhaupt vergleichbar? Wenn diese Fragen beantwortet werden können, dann ist der Rest auch lösbar.

Dieser Bezug käme vor allem auch dem Vorstellungsvermögen des Schätzers entgegen, der mit einer losgelösten Zahl von beispielsweise 760 Function points nur schwerlich eine Definition dessen abgeben kann, was eigentlich dahinterstecken könnte.

Iterative Verfahren bilden einen Kompromiß

Nach dem Phasenmodell können für die Phase 1 (Bedarfsanalyse und Lösungsentwurf) etwa zehn Prozent der Gesamtprojektzeit angesetzt werden. Die überwiegende Mehrheit der Anwender verwendet Schätzverfahren erst nach dieser Phase ein. Modelle, die früher einsetzen, können wegen zu vieler Unbekannter kaum zu realistischen Ergebnissen führen. Modelle, die später einsetzen, liefern zwar möglicherweise bessere Ergebnisse, jedoch zu einem Zeitpunkt, zu dem die Kosten-/Nutzen-Analyse längst in die Planung hätte Eingang finden müssen. Als Kompromiß sind häufig iterative Verfahren zu finden, die frühestens nach der ersten Phase eingesetzt werden können und in späteren Phasen eine Überarbeitung - nach Gegenüberstellung von Soll und Ist sowie neuer Erkenntnisse - ermöglichen.

Programme enthalten nicht nur Masken

Das hier vorgestellte "Masken-Basis-Verfahren" (MBV) geht nun von der Annahme aus, daß nach der Projektphase bei Dialoganwendungen annähernd gut abschätzbar ist, wie viele Bildschirmmasken das Gesamtprojekt umfassen wird. Diese Annahme ist insofern plausibel, da auch beim FTV die Funktionen bereits festgelegt sind, so daß hier nur noch die Funktionen zu Masken zusammengefaßt werden müssen.

Wie oben bereits erwähnt wurde, sind außer Masken auch andere Funktionen, (zum Beispiel Listen) in Programmen enthalten. Diese anderen Funktionen müssen anteilmäßig auf die Masken verteilt werden. Dies kann nur gelingen, wenn es möglich ist, eine Charakteristik für Dialogapplikationen zu definieren. Dazu ist eine Beschränkung auf kommerzielle/administrative Dialogapplikationen notwendig, da hierzu gute Erfahrungswerte vorliegen.

Was also ist einer typischen Bildschirmmaske zuzuordnen? Eine durchschnittliche Bildschirmmaske ist mit mindestens 30 Eingabe- und zehn Ausgabefeldern ausgestattet, die wechselseitige Abhängigkeiten mit mehreren Dateien, Segmenten oder Relationen (je nach Datenbank) aufweisen. Sollten mehrere Zeilen in einer Maske den gleichen Aufbau haben, so zählen nur die Felder von zwei Zeilen. Menümasken zählen nicht.

Für die Eingabefelder sind entsprechende (durchschnittlich umfangreiche) Plausibilitätsprüfungen gefordert. Referentielle Integrität ist Programmsache. Die einzelnen Felder können mit umfangreichen Attributen belegt werden. In einer Bildschirmmaske dürfen bei diesem Bewertungsverfahren höchstens zwei der vier Grundfunktionen anzeigen", "erfassen", "ändern" und "löschen" enthalten sein.

Im Einzelfall ist das ganze Umfeld zu beachten

Analog zu dieser Einschränkung zählt eine Maske, die alle vier Funktionen enthält, doppelt. Weniger umfangreiche Masken zählen weniger als eins. Alle Funktionen müssen multiusing-fähig und transaktionsorientiert bezüglich des DB- und DC-Teils sein.

Es wird von einem durchschnittlichen Listenoutput von mindestens einer komplexen Liste pro fünf Bildschirmmasken ausgegangen. Ein kleiner Teil (etwa zehn Prozent) der Gesamtprogrammierung geht in der Batch-Programmierung auf (periodische Datenübernahme, Brückenprogramme für periodische Datenintegration von dateninkompatiblen Nachbarbereichen, Testdatenerstellung etc.). Bei komplexen Abhängigkeiten zu Nachbarbereichen oder Altapplikationen ist hier mit erheblichen Zuschlägen zu rechnen. Der Zeitaufwand des Datenbankadministrators, des Systemverwalters und des Netzwerkspezialisten ist in der Schätzmethode berücksichtigt, ebenso die aufgewendete Zeit der Fachabteilungen.

Natürlich ist jede Berechnung dieser Art mit vielen Randbedingungen und Prämissen beladen, die teilweise schon definiert wurden. Tatsache ist, daß der Produktivitätsgrad von Programmierern im Verhältnis von eins zu 20 schwanken kann, daß unterschiedliche Unternehmen einen stark abweichenden Produktivitätsgrad haben (abhängig von Branche, Größe etc.) und daß auch Systemanalytiker sehr unterschiedliche Durchsatzraten aufweisen. So leistet die hier angegebene Formel gute Dienste zur ersten Näherungsschätzung; zur Beurteilung der genaueren Zeitschätzung im Einzelfall muß jedoch das gesamte technische, organisatorische und personelle Umfeld starke Beachtung finden (was sich in einer entsprechenden Parametrisierung widerspiegeln wird).

Die Formel für die Masken-Basis-Verfahren lautet:

MM = Anz x 6 x (1 + Anz x2/SGrd + Anz)2 / P

MM = Anz. 6

Dabei gilt:

MM = Mannmonate (1 Mannjahr = 10 MM a 150 Stunden)

Anz = Anzahl der Bildschirmmasken

SGrad = relativer Schwierigkeitsgrad im Verhältnis zu anderen kommerziellen/administrativen Projekten; wird mit 300 (Durchschnitt) angesetzt, liegt für den Großteil der Applikationen zwischen 200 (relativ schwierig) und 400 (relativ einfach);

P = Produktivitätsfaktor, wird bei den Beispielen mit 4 (durchschnittliche Entwicklungs-Tools) angesetzt. Normalerweise liegt P zwischen 3 und 5 kann jedoch, beispielsweise bei Verwendung von 4GLs, noch günstiger liegen. Auch der unternehmensspezifische Produktivitätsfaktor ist hier zu bewerten. Höhere Produktivität läßt auf kleine Teams und/oder ein problemloses Umfeld und/oder ein Projekt schließen, über das bereits ausreichend Wissen im Team vorhanden ist. Die Bestimmung von P fällt leichter, wenn bereits Vergleichsprojekte unter ähnlichen Bedingungen und Voraussetzungen durchgeführt worden sind.

Das hier vorgestellte Verfahren ist auch iterativ einsetzbar. Durch ständige Anpassung des Produktivitätsfaktors aufgrund des Projekt-Ist-Zustandes kann schnell ein Durchgangspunkt für die unternehmensspezifische Produktivitätskurve (und somit die gesamte Kurve) abgeleitet werden.

Bei dieser Formel ist folgendes zu beachten: Der Restaufwand ist der Gesamtaufwand nach der Phase 1, also inklusive Feinkonzept, Datenmodellierung, Programmierung, Test, Integrationstest, Schnittstellen zu Altprogrammen, Abnahme, Probebetrieb und Einführungsschulung sowie einschließlich der Dokumentation aller Projekt-Phasen für Benutzer, Programmierer und Arbeitsvorbereitung, der Datensicherungskonzepte, Sicherheitsvorkehrungen und aller Programmänderungen bis zur Stabilisierungsphase beziehungsweise Akzeptanzschwelle, jedoch maximal bis zu einem halben Jahr nach erstem Echteinsatz.

Nach Ableistung des Restaufwandes geht das Produkt in die Wartungsphase über. Vom Restaufwand kann die Restlaufzeit mittels einfacher Division durch eine plausible Mitarbeiterzahl abgeleitet werden. Unterstellt ist stets eine annähernd optimale Teamgröße (zum Beispiel die Wurzel aus der ermittelten MM-Zahl) bei durchschnittlichem Kommunikationsbedarf.

Dazu zwei Beispiele:

Bei einer Parametrisierung von P= 4 und SGrad = 300 läßt sich für ein Projekt mit 100 Bildschirmmasken ein Restaufwand von 34 Mannjahren (337,5 MM) ermitteln:

MM = 100 x 6 x (1 + 2 x 100 / 300 + 100)2 / 4 = 337,5 MM.

MM = 10 x 6 x (1 + 2 x 10 / 300 + 10)2 / 4 = 17 MM.

Ein Projekt mit 10 Bildschirmmasken führt zu einem Restaufwand von rund 17 MM (1,7 MJ): Selbstverständlich ist bei kleineren Projekten die Streuung wesentlich größer, da hier die Produktivität eines einzelnen stärker zu Buche schlägt. Je kleiner das Projekt, desto wichtiger wird die Frage, wer das Projekt realisiert. Man beachte auch, daß zu den 100 Bildschirmmasken per definitionem auch 20 komplexe Listen gehören.

Schwer zu beantworten ist die Frage, wie eine Erweiterung einer fertiggestellten Dialogapplikation um zusätzliche Masken zeitlich zu bewerten ist. Die Zeitschätzung nach dem "Spitzensatz" könnte zu hoch ausfallen, da das Erkennen von fehlenden Masken bereits eine gewisse Kenntnis im Sinne einer Feinspezifikation unterstellt.

Im Zweifelsfall wird deshalb hier empfohlen, den Teilprojektwert mit ca. 30 Prozent der Differenz zum "delta Spitzensatz" zu beaufschlagen.

Beispiel: Die Grundapplikation hat 100 Masken; eine Erweiterung nach Fertigstellung auf 101 Masken ist erforderlich nach der Methode "Teilprojekt" gilt:

MM = MB (Anz = 1) = 1,5 MM. Die Methode "delta Spitzensatz" ergibt:

MM = MB (Anz = 101) - MB (Anz = 100)

= 342,6 - 337,5 = 5,1 MM

Ergebnis: Eine Erweiterung nach Fertigstellung von 100 auf 101 Bildschirmmasken ist mit 1,5 + 30 Prozent aus der Differenz von 5,1 und 1,5 MM Restaufwand zu bewerten, also mit 2,6 MM.

Anmerkung: Man beachte jedoch, daß bei zu kleinen Zahlen die unterstellte Charakteristik bei kommerziellen/administrativen Projekten stark abweichen kann .

Progressiver Zeitverlauf bei steigender Größe

Die Frage, wie groß ein einzelnes EDV-Projekt eigentlich sein kann, ohne in Teilprojekte zu zerfallen, läßt sich tatsächlich in der Praxis nur sehr schwer beantworten. Ist ein EDV-Reorganisationsprojekt mit insgesamt 300 Bildschirmmasken ein einziges Projekt, oder zerfällt es in viele Teilprojekte? Diese Frage ist insofern relevant, weil grundsätzlich von einem progressiven Zeitverlauf bei steigender Projektgröße ausgegangen werden muß.

Sollte also das 300 Masken-Projekt in sechs Teilprojekte a 50 Masken aufgeteilt werden können, dann ergibt sich folgender Aufwand:

Zeitschätzung a:

6 x MB (Anz = 50) = 6 x 124 = 744 MM.

Handelt es sich um ein nicht aufteilbares Großprojekt, dann ergibt sich:

Zeitschätzung b:

MB (Anz = 300) = 1800 MM.

Hier könnte vielleicht die Antwort auf die Frage, wie groß Dialogprojekte im kommerziellen/administrativen Bereich üblicherweise sind, weiterhelfen. Der größte Teil der Dialogapplikationen dürfte zwischen fünf und 60 Bildschirmmasken umfassen. Einzelprojekte mit über 100 Bildschirmmasken sind sehr selten, so daß die Annahme nahe liegt, daß es sich bei Projekten mit mehr als 100 Bildschirmmasken um mehrere Teilprojekte handelt, die durch Schnittstellen mit den Nachbar-Teilprojekten gekennzeichnet sind.

Doch sind diese Schnittstellen vor allem bei paralleler Bearbeitung der Teilprojekte zeitintensiver zu bewerten als bei chronologischer Abarbeitung der Teilprojekte. Hier dürfte ein Aufschlag von 40 Prozent (je nach Abhängigkeitsgrad der Teilprojekte untereinander) der Differenz zwischen Zeitschätzung b und a nicht zu hoch gewählt sein. Es folgt:

MB (Anz - 6 x 50) = 744 + 0,4 x (1800 - 744)= 1166 MM.

Produktivität ist nicht erlernbar

Schwer zu bewerten sind auch die Fähigkeiten des Teams. Doch gerade die sind von überragender Bedeutung. Produktivität scheint eine Eigenschaft zu sein, die nicht

erlernbar ist. Zwar läßt sich in Schulungen Wissen vermitteln, jedoch nicht die produktive

Anwendung dieses Wissens. Aufwandsschätzungen, das sollte hier gezeigt werden, kommen an der Beurteilungsfähigkeit des Schätzenden nicht vorbei. Die Frage nach der Auswirkung unterschiedlicher Entwicklungsumgebungen darf nicht unbeachtet bleiben. Läßt sich MVS (Betriebssystem-Umgebung für IMS) mit Unix (-Derivaten) vergleichen? Oder etwa die 4GL "Natural" mit C? Ist ein fehlender Debugger bei "Natural" ein Handicap? Bringt die Trigger- Technik von Oracle auch bei Großprojekten Vorteile? Hier sind im Einzelfall

Differenzierungen notwendig, die nur nach genauer Kenntnis des Software-Umfeldes möglich sind (Faktor P in MB-Formel anpassen).

Noch deutlicher scheint es daß neue Maskentechniken programmtechnischen Aufwand verursachen. Zu denken ist hier an Pull-down- und Pop-up-Techniken, die je nach Maskengenerierungs-Software zu einem erheblichen Mehraufwand führen können. Solange diese Technik nicht eine gewisse Verbreitung bei Großprojekten gefunden hat, sind hier kaum allgemeine gültige Aussagen möglich.

Schätzungen werden künftig noch schwieriger

Wie es scheint, wird eine Aufwandsschätzung in Zukunft eher schwieriger als bisher. Zu denken ist an verteilte Datenhaltung, mit all den damit verbundenen technischen Möglichkeiten (Fragmentierung, Replikation, Unikate). Natürlich sollte das hier kurz vorgestellte Verfahren nicht als einziges Instrument bei einer Projektkalkulation herangezogen werden. Dazu fehlt ein tieferer Detaillierungsgrad. Als Zweit- oder

Abgleichmethode kann es im Verhältnis zum damit verbundenen Aufwand jedoch sicher gute Dienste leisten. +

*Willy Wittstadt ist Unternehmensberater in München