MÜNCHEN (uk) - Eine möglichst genaue und objektive Schätzung von Projekt- und Programmierzeiten ist ansicheinend sowohl beim Anwender als auch bei Softwarehäusern und EDV-Herstellern ein weitgehend ungelöstes Problem. Meist sind es firmenspezifische Eigenheiten, die den Einsatz einer allgemein gültigen Schätzmethode von vornherein unmöglich machen. So bezeichnet denn auch Klaus Kappel im "Fall 2" des CW-Forums (CW Nr. 21 vom 20. März 1977 "Zur Diskussion gestellt: Programmierzeit") die meisten EDV-Termine als nicht problemorientiert und derart unrealistisch, daß sie nicht eingehalten werden könnten. Eine erste Antwort auf bisher ungeklärte Fragen wie beispielsweise nach der durchschnittlichen Statementzahl je Mann/Tag gibt Jürgen Vedder in seinem folgenden Beitrag, in dem er seine Erfahrungen mit einer Gewichtungsfaktoren-orientierten Schätzmethode darstellt.
Die Gesamtzeit, die für ein Programmprojekt benötigt wird, setzt sich zusammen aus Programmplanung, Codieren, Dokumentieren, Testplanung und Testen. Hieran knüpfen sich eine Reihe von Fragen, weil die einzelnen Arbeitsschritte bei den Anwendern höchst unterschiedlich gehandhabt werden:
Gibt es eine klare Aufgabenverteilung zwischen Systemanalyse und Programmierung? Wie gut sind die Programmvorgaben? Gibt es Programmierstandards im Hause, eventuell normierte oder strukturierte Programmierung? Wie weit ist das Programm vom Systemanalytiker vordokumentiert? Sind automatische Dokumentationssysteme vorhanden? Werden Testdaten vorgegeben oder sind diese vom Programmierer zu erstellen? Wird im Open- oder Closed-Shop-Betrieb getestet?
Faktor 8 für schwere Prüfungen
Je nach Beantwortung dieser Fragen wird die Schätzung der Programmierzeit mit einer Reihe unterschiedlicher Faktoren zu bewerten sein. Unterstellt man der Einfachheit halber einmal, daß alle diese Faktoren positiv geregelt sind, so kann die nachfolgend geschilderte Schätzmethode als Beispiel eines guten und flexiblen Instruments zur Zeitplanung in der Programmierung angesehen werden, zumal sie den Eigenheiten des jeweiligen Unternehmens leicht angepaßt werden kann:
Die zu schätzenden Einheiten werden möglichst fein in die einzelnen Faktoren gegliedert, welche die Dauer eines Programmprojekts generell beeinflussen und entsprechend gewichtet:
Die genannten Gewichtungsfaktoren beziehen sich auf PL/1- beziehungsweise COBOL-Programme. Für Assembler-Programme sind sie mit 1,5 zu multiplizieren. Die Tabelle der Gewichtungsfaktoren kann, je nach betrieblicher Gegebenheit (Terminals, Datenbanken etc.), beliebig erweitert und abgewandelt werden, sollte jedoch in den Gewichtungsfaktoren immer die Gesamtzeit der eingangs geschilderten Elemente eines Programmprojektes berücksichtigen.
10 Prozent Aufschlag für Verlustzeiten
Besteht nun ein Programm beispielsweise aus der Eingabe zweier Dateien (Karte, Platte), der Ausgabe einer neuen Plattendatei und einer mittelschweren Liste und sind umfangreiche Plausibilitätsprüfungen erforderlich, so ergeben sich hierfür folgende Gewichtungspunkte:
Dieses Ergebnis muß noch um die Verlustzeiten korrigiert werden, die sich innerhalb eines Projektes erfahrungsgemäß ergeben können. Diese setzen sich im wesentlichen aus Zeiten für Rückfragen, Warten auf Testzeit, unvorhergesehene Testschwierigkeiten und Programmänderungen zusammen. Im Mittel ist ein Aufschlag von 10 Prozent auf die bisher errechneten Werte vorzunehmen. Der Aufschlag kann im Einzelfall auch einmal wesentlich höher ein. Für unser Beispiel ergibt sich bei einem Aufschlag von 10 Prozent eine Programmierzeit von 15 + 1,5 = 16,5 Mann-Tagen. Als Mann-Tag gilt allgemein ein 8-Stunden-Werktag. Arbeitsfreie Tage, wie Wochenenden, Feiertage, Krankheit, Urlaub, Schulung etc. werden nicht berücksichtigt. Sie erhöhen, falls sie in dieser Zeit anfallen, die Projektlaufzeit entsprechend.
Noch weiter verfeinern läßt sich diese Schätzmethode, wenn man außerdem Gewichtungsfaktoren für den Kenntnis- und Erfahrungsstand des Programmierers ansetzt:
- Senior-Programmierer 0,7
- Programmierer 1
- Junior-Programmierer 2
- Anfänger 4
Multipliziert man nun die Projektzeit von 16,5 Mann-Tagen mit dem jeweils zutreffenden Faktor, so würde ein Senior-Programmierer etwa 11,6, ein Junior-Programmierer jedoch 33 Mann-Tage zur Verfügung haben müssen.
Kommentarkarten nicht vergessen
Sollte man die Zeitvorgaben für die Programmierung auf Statementniveau abstellen, so ist es empfehlenswert, auch hier mit ähnlichen Gewichtungsfaktoren zu arbeiten wie oben geschildert. Eine Pauschalierung führt zwar möglicherweise im Durchschnitt zu richtigen Schätzungen, aber die Einzelplanung wird gewiß falsch. Bei der Beurteilung der Programmierleistung nach Statements ist es in jedem Fall zu empfehlen, außer den Vereinbarungen auch die Kommentare mit einzuschließen. Man begibt sich sonst zu leicht in die Gefahr, daß aus Zeitnot Kommentare weggelassen werden, was gerade die Klarheit und Lesbarkeit, also die Dokumentation im Programm selbst, beeinträchtigt. Dies wiederum macht sich spätestens beim Änderungsdienst der betreffenden Programme recht unliebsam bemerkbar.
Für den Änderungsdienst, der sich zwangsläufig aus äußeren Einflüssen (Fachabteilung, Gesetzgeber, Markt etc.) ergibt, sollte man zwischen 30 und 50 Prozent der insgesamt zur Verfügung stehenden Programmierkapazität einplanen.
Die geschilderte Schätzmethode ist nur dann sinnvoll einzusetzen, wenn man die Resultate laufend kontrolliert und die Gewichtungsfaktoren zumindest in der Anfangszeit ständig den jeweiligen betrieblichen Gegebenheiten anpaßt. Dadurch können im Laufe weniger Monate beachtlich gute Schätzwerte erzielt werden. Jedenfalls wird hierdurch die angenommene Programmierzeit auf eine einigermaßen realistische Basis gestellt, was sich gegenüber der Methode des dicken Daumens sehr wohltuend ausnimmt.
Jürgen Vedder ist freiberuflicher EDV-Berater.