In der Vergangenheit brachten fehlerhafte Aufwandschätzungen EDV-Projekte oft an den Rand des Scheiterns. Dennoch scheint die Diskrepanz zwischen dem Angebot an Verfahren und deren Nutzung in der Praxis auf keinem Gebiet so groß zu sein wie gerade bei der Zeit- und Aufwandschätzung von DV-Projekten. Dieser Beitrag enthält in kurzer Form eine Bestandsaufnahme. Sie basiert auf einer Querschnittsuntersuchung, in deren Mittelpunkt ein vergleichender Praxistest stand. Diese führte der Autor am Lehrstuhl für Betriebs- und Wirtschaftsinformatik an der Universität Erlangen-Nürnberg, Prof. Dr. Peter Mertens, durch.

Eine Möglichkeit der qualitativen Darstellung der Einflußgrößen

und deren Wirkung auf den Softwareerstellungsprozeß ist das sogenannte "Teufelsquadrat" (siehe Abbildung 1). Die vier Ecken stehen für die Ziele der Softwareentwicklung, Quantität, Qualität, Projektdauer und Kosten, die zusammen mit dem angestrebten Zielerfüllungsgrad entscheidenden Einfluß auf den Realisierungsaufwand ausüben. Diese Ziele konkurrieren um eine begrenzte Kapazität beziehungsweise Produktivität, die durch die Fläche des inneren Vierecks symbolisiert wird. Man kann dieses zwar in jede Richtung strecken, und man muß Einbußen auf den jeweils anderen Seiten hinnehmen.

Die Abhängigkeit des Aufwands von angestrebter Quantität und Qualität ist offensichtlich. Daß auch die Projektdauer ein entscheidendes Einflußgebiet ist begründet sich im überproportional steigenden Kommunikations- und Koordinierungsaufwand bei steigender Mitarbeiterzahl in einem Projekt.

Unter der Produktivität will Harry Sneed eine vom jeweiligen Projekt unabhängige Größe sehen, die für eine bestimmte Abteilung oder ein Entwicklungsteam ermittelt wird. Er vernachlässigt dabei allerdings eventuell auftretende Interdependenzen. So erhöht sich zum Beispiel die Produktivität eines Programmierers oder Systemanalytikers erheblich, wenn die Aufgabe aus einem ihm vertrauten Arbeitsgebiet stammt. Deswegen sollte die Produktivität für jedes neue Projekt gesondert

bestimmt werden.

Doch sind diese Einflußgebiete noch zu abstrakt, als daß man sie direkt in ein Schätzverfahren integrieren könnte. Es müssen stärker operationale und besser quantifizierbare Größen (Einflußfaktoren) gefunden werden, die den Einfluß des jeweiligen Gebiets repräsentieren können. Dabei liegt die Hauptproblematik meist weniger in der Wahl der Faktoren als in deren Quantifizierung. Für die Aufwandschätzung sind insbesondere solche Quantifizierungsansätze interessant, die bereits im frühen Stadium des Softwareerstellungsprozesses relativ genaue Werte liefern können.

Als wichtigstes Merkmal eines Programms oder Programmsystems wird häufig seine Größe angesehene die man meistens in den Maßeinheiten "Anzahl Programmzeilen" ("Lines of Code", kurz: LoC) oder "Anzahl Anweisungen ausdrückt. In ihrer Verwendung liegen allerdings einige Schwächen und Gefahren, so auch

- die unterschiedliche Anzahl Anweisungen pro LoC,

- die problematische Abgrenzung und Zählung von Anweisungen,

- die unsichere Prognose bei Projektbeginn,

- die mangelnde Vergleichbarkeit bei Verwendung verschiedener Programmiersprachen.

Grundsätzlich ist bei der Verwendung von LoC oder auch der Anzahl Anweisungen die einseitige Betonung der Codierung zu bemängeln. Alle anderen Aktivitäten werden vernachlässigt da sie zur Leistungssteigerung um so verstandenen Sinn nichts beitragen. Somit wird gegen eine Hauptforderung der Software-Engineering, nämlich der verstärkten Anstrengung bei Planung und Entwurf, verstoßen. Um diesen angeführten Problemen und Schwächen wenigstens teilweise entgegenzuwirken, ist es notwendig, mit Richtlinien und Normen für eine Vergleichbarkeit zu sorgen oder mögliche Unterschiede bei der Betrachtung zu berücksichtigen.

Gerade solche Probleme machen den Vorschlag interessant, die Größe des Programms mit seinem Funktionsumfang zu messen. Dieses Maß wird durch die im Programm realisierten Funktionen oder Teilaufgaben ausgedruckt, die sich bei der Dekomposition des zu realisierenden Projektes ergeben. Die Dekomposition ist so lange fortzuführen, bis jede Teilaufgabe nur noch eine Aktivität beinhaltet (zum Beispiel eine Plausibilitätsprüfung oder das Drucken eines Listenkopfes).

Obwohl der Funktionsumfang als Maßgröße sicher von "weicherer Natur" als die zuerst diskutierten Vorschläge ist, scheint er für die Aufwandschätzung doch geeigneter, da

- der über die eigentliche Programmierung hinausgehende Teil des Entwicklungsprozesses besser einbezogen wird,

- Entwicklungen in verschiedenen Programmiersprachen vergleichbar

werden,

- die tatsächliche Istausprägung frühzeitig feststeht und

- der Nutzen eines Softwareprodukts im Sinne des realisierten Funktionsumfangs quantifiziert werden kann.

Der Einfluß der Komplexität des zu entwickelnden Systems ist, so lautet das Ergebnis sämtlicher Untersuchungen, gravierend und darf im Rahmen der Kalkulation nicht unberücksichtigt bleiben. Für die quantitative Beurteilung wurden Komplexitätsmaße entwickelt, die lediglich nach Projektende bestimmbar sind und deren Aussagekraft stark angezweifelt wird; somit sind sie für die Aufwandschätzung nur von untergeordneter Bedeutung. Man hilft sich meist mit der qualitativen Einteilung in "leicht", "mittel" und "schwer" und mit der auf Erfahrungsbasis gewonnenen Zuordnung von Faktoren, so "leicht" = 0,8; "mittel" = 1,0; "schwer" = 1,3, wobei der jeweilige Faktor dann als Multiplikator verwendet wird. Richtlinien für die Bewertung sind in die verfahren integriert und auf diese abgestimmt.

Mit Größe und Komplexität wurden die wichtigsten Einflußfaktoren der Quantität einer Aufgabenstellung behandelt. In der Literatur werden noch einige mehr erwähnt und meist auf Erfahrungsbasis quantifiziert.

Dazu zählen die Güte der Anforderungsdefinition, die Dokumentationsanforderungen, oder auch der Neuheitsgrad der Aufgaben.

Solche und ähnliche Faktoren sind nur dann gesondert zu berücksichtigen, wenn es aufgrund des Entwicklungsprozesses nötig erscheint, das deutlich vom durchschnittlichen, gewohnten Maß abweichen.

Untersuchungen über die Quantifizierungsmöglichkeiten des Qualitätseinflusses sind höchst selten und können kaum praktikable Lösungen bieten. Gemeinsam ist fast allen die Zerlegung in erschienene Qualitätsmerkmale.

Sneed berechnet folgendermaßen: Qualitätsfaktor = Effizienz X Effektivität X Wartbarkeit

Dabei ergibt sich die gewünschte Effizienz als Mittelwert dar Subfaktoren Zeiteffizienz (= Antwortzeitverhalten) und Raumeffizienz (= Speicherauslastung). Die Effektivität stellt den Mittelwert aus Zuverlässigkeit, Sicherheit und Benutzerfreundlichkeit darf und die Wartbarkeit wird als Durchschnittswert von Ausbaufähigkeit, Übertragbarkeit und Wartungsfreundlichkeit ermittelt. Mit die ein Qualitätsfaktor soll der vorher auf der Basis der Quantität errechnete Aufwand multipliziert werden.

Umgebungsspezifisch abgestimmte Kalkulationsverfahren haben den Vorteil, daß der Einfluß der Qualität dann vernachlässigt werden kann, wenn die Qualitätsanforderungen innerhalb einer Entwicklungsorganisation relativ konstant sind. Bei einem heterogenen Produktionsprogramm oder einer eventuellen Übertragung von Ergebnissen auf eine andere Organisation ist das Qualitätsniveau allerdings zu berücksichtigen.

Um eine Sachaufwand durch eine größere Zahl von Mitarbeitern in kürzerer Zeit zu erledigen, ist ein höherer Gesamtaufwand notwendig. Ab einem bestimmten Punkt ist der Leistungsbeitrag eines zusätzlichen Mitarbeiters bedingt durch die Unteilbarkeit vieler Aufgaben in der Softwareproduktion geringer als die Erhöhung des Kommunikationsaufwandes, so daß die Projektdauer sogar zunimmt.

Erste Quantifizierungsansätze versuchen, die optimale Projektdauer beziehungsweise die optimale Mitarbeiterzahl zu bestimmen. In der Literatur sehr verbreitet ist folgende auf empirischer Basis gewonnene Faustformel:

Optimale Bearbeiterzahl = errechneter Aufwand in MM

Wird diese Zahl an Mitarbeitern eingesetzt, ist es möglich, mit dem errechneten Aufwand auszukommen; werden mehr eingesetzt, sinkt zwar die Projektdauer bis zu einem bestimmten Punkt, der Gesamtaufwand erhöht sich allerdings.

Aufgrund seiner umfangreichen "Software-Lebenszyklus-Untersuchungen" gelangt Putnam zu folgender Relation:

Entwicklungszeit E4 X Entwicklungsaufwand = Const.

Der Entwicklungsaufwand wäre demnach proportional zur vierten

Potenz der Projektdauer. Die Kritik an Putnams Arbeiten richtet sich meist gegen die Annahme, die Softwareentwicklung liefe nach solch exakten mathematischen Formeln ab. Deshalb sollte die obengenannte Relation lediglich als interessanter Anhaltspunkt für die Größenordnung angesehen werden.

Unter Produktivität der Mitarbeiter ist die Erfüllung der Anforderungen an Quantität und Qualität im Rahmen einer vorgegebenen Projektdauer bezogen auf eine bestimmte Zeiteinheit zu verstehen. Deshalb ist die meist verwendete Einheit LoC/Mannmonat allenfalls für die reine Codierung akzeptabel, jedoch sonst unzureichend. Auch hier

scheint eine Orientierung am Funktionsumfang unter Berücksichtigung von Qualitäts- und Projektdaueranforderungen geeigneter.

Die der Produktivität zuzuordnenden Einflußfaktoren lassen sich grob in drei Gruppen einteilen:

- Personalqualität,

- Hardware-/Softwareverfügbarkeit,

- Organisations- und ablaufbedingte Einflüsse.

Sneed verwendet einen Produktivitätsfaktor, mit dem der aus den Produktanforderungen entstandene Sachaufwand multipliziert wird. Zur Ermittlung sind gemäß einer Tabelle Subfaktoren qualitativ zu beurteilen und die jeweils zugeordneten Werte (zwischen 0,75 und 1,4) miteinander zu multiplizieren.

Aus verschiedenen Forschungen über ihre Gewichtung geht hervor, daß sich die einzelnen Einflußfaktoren auf die Produktivität unterschiedlich stark auswirken. In allen Arbeiten jedoch wird der personalabhängige Einfluß als der wichtigste erachtet.

Man kann die existierenden Verfahren grob in drei Gruppen einteilen:

1. Die Schätzung beruht hauptsächlich auf einer durch Analyse abgeschlossener Projekte ermittelten Relation zwischen Aufwand und Systemgröße, wobei letztere in "LoC" oder "Anzahl Anweisungen" gemessen wird. Diese Meßgrößen sind lange Zeit als die einzigen angesehen worden, die für verschiedene Projekte ungefähr das gleiche aussagen und damit eine Vergleichbarkeit gewährleisten können. Dafür nahm man auch die große Unsicherheit bei ihrer Prognose in Kauf.

2. Die Verfähren basieren vorwiegend auf der Gewichtungsmethode. Hierbei wird vom Schätzenden verlangt, verschiedene Faktoren entsprechend ihrer projektspezifischen Ausprägung zu bewerten, zum Beispiel nach den Kriterien "leicht", "mittel" und "komplex". Der jeweiligen Bewertung sind im Verfahren Zahlen fest zugeordnet, die nach einem vorgegebenen Algorithmus verarbeitet werden. Das Ergebnis soll den zu erwartenden Aufwand darstellen.

3. Statt einer "starren Formel" erhält der Anwender eine Methodik, die er an seine spezifische Entwicklungsumgebung anpassen muß. Bei solchen Verfahren gilt es, den optimalen Kompromiß zwischen Spielraum zur individuellen Anpassung und Determinierung zu finden.

Innerhalb der Untersuchung wurden 20 Verfahren getestet, die alle drei Gruppen abdecken.* Hier soll nur das Function-Point-Verfahren grob skizziert werden. Es hat sich beim Anlegen aller, Testkriterien als das am besten geeignete erwiesen.

Man geht davon aus, daß der Aufwand für ein Projekt zum einen von seinem Schwierigkeitsgrad und zum anderen von seinem Umfang abhängt. Beide Größen werden durch die Summe von sogenannten Function-Points dargestellt, welche man gewinnt, wenn man das zu realisierende Projekt nach verschiedenen Kriterien auf bestimmte Merkmale hin untersucht. Letztere kann man weitgehend als "Geschäftsvorfälle" oder "Funktionen", die in der Anwendung verarbeitet werden sollen, bezeichnen.

Sie gliedern sich grob in Eingabedaten (zum Beispiel Buchungssätze), Ausgabedaten (Rechnungen) und Datenbestände (Stammdaten).

Wichtig ist, daß durch diese Systematik die letztendliche DV-Realisierung keine Rolle spielt und als "Black-box" betrachtet wird, lediglich die Anforderungen aus Benutzersicht sind relevant.

Die Geschäftsvorfälle werden bei jedem Auftreten nach den Kriterien ,leicht", "mittel" oder "komplex" klassifiziert. Den drei Kriterien sind für jeden Geschäftsvorfall Zahlen zwischen drei und 15 zugeordnet. Für alle auftretenden Geschäftsvorfälle addiert man die zugehörigen Zahlen (= Function-Points). Die nun erhaltene Summe von Function-Points ist allerdings noch nicht der endgültige Wert.

Dieser wird erreicht, indem man 14 Faktoren, die auf die Anwendungsentwicklung wesentlichen Einfluß besitzen, entsprechend ihrer Einwirkung nach vorgegebenen Richtlinien mit Zahlen bewertet. Das Ergebnis liegt zwischen 0 und 70 und wird als "degree of influence" bezeichnet. Es wird durch 100 dividiert und zu 0,65 addiert. Mit dem erhaltenen wert ist die zunächst ermittelte Summe von Function-Points zu multiplizieren. Das endgültige Ergebnis für die Function-Points (= bewertete Function-Points) liegt also zwischen 65 Prozent und 135 Prozent der ursprünglich aufgrund der Geschäftsvorfälle errechneten Summe. Diese Spanne begründet man bei IBM mit empirisch gewonnenen Untersuchungsergebnissen.

Die den "degree of influence" bestimmenden Einflußfaktoren sind unter anderem:

- Realtime-Verarbeitungsproblematik,

- Back-up-Funktionen-Installation,

- Berücksichtigung der Benutzerfreundlichkeit.

Auch hier sind die benötigten Angaben wieder auf die Benutzeranforderungen zugeschnitten.

Die Beziehung zwischen den Function-Points und dem zu erwartenden Aufwand wird durch eine Art "Erfahrungsdatensatz" wiedergegeben, der unternehmensspezifisch zu ermitteln ist. Für eine größere Anzahl in letzter Zeit abgeschlossener Projekte aus der gleichen Entwicklungsumgebung werden die bewerteten Function-Points ermittelt. So erhält man eine Menge von Relationen von bewerteten Function Points zu angefallenem Aufwand (zum Beispiel in Mannmonaten).

Aus diesen Beziehungen ist mit Hilfe statistischer Verfahren eine Kurve zu entwickeln, die den Zusammenhang zwischen bewerteten Function-Points und dem Aufwand darstellt. Für jedes zu kalkulierende Projekt werden nun die bewerteten Function-Points ermittelt, für die man dann anhand der Kurve den wahrscheinlichen Aufwand ablesen kann.

Function-Point bietet außerdem die Möglichkeit, die Kurve ständig anzupassen. Jedesmal, wenn ein Projekt abgeschlossen wird, kann mit dessen Function-Point-Aufwand-Relation die bestehende Kurve verfeinert oder aktualisiert werden. Dem Anwender ist freigestellt, ob er dann die Anzahl der zugrundeliegenden Projekte erhöht oder ob er, nach Art eines "gleitenden Durchschnittes", das jeweils älteste Projekt nicht mehr mit einbezieht, um aktuellere Einflüsse stärker zu betonen.

Der Aufwandsinhalt und die Entwicklungsumgebung, die der Kurve zugrundeliegen, müssen genau dokumentiert werden. Für von diesen Entwicklungsvoraussetzungen abweichende Projekte sind aufgrund der Abweichungen auf das von der Kurve abgelesene Ergebnis Zu- oder Abschläge zu machen. Diese werden auf der Grundlage von Erfahrung des Schätzenden festgelegt und sollten zum Zwecke der Nachvollziehbarkeit begründet sein. Für einen effizienten Einsatz von Function-Point muß eine einheitliche Vorgehensweise sichergestellt werden. Das Verfahren muß von jedem gleich verstanden sein, eine eindeutige Abgrenzung zwischen den drei Klassen "leichtes", "mittel" und "komplex" sollte vorliegen. Dasselbe gilt für die Skala der Einflußfaktoren.

Die IBM Deutschland macht zur Bewertung und Klassifizierung der Geschäftsvorfälle und Einflußfaktoren sehr genaue Vorgaben. Diese können aber mit den entsprechenden Kenntnissen ohne Schwierigkeiten unternehmensspezifisch angepaßt werden. Sogar die Zusammenstellung der Einflußfaktoren läßt sich, falls nötig, ohne weiteres ändern. Auch kann man Function-Point dahingehend modifizieren, daß brauchbare Ansätze aus anderen Verfahren integriert werden, falls es das spezielle Problem verlangt. Hierfür eignet sich zum Beispiel die Konzeption eines "Tätigkeitstableaus", das ein Projekt in Standardaktivitäten zergliedert, denen dann ein durchschnittlicher Aufwandsanteil zugeordnet ist (realisiert im TRW-Verfähren von Wolverton).

Ziel der oben genannten Untersuchung war es zu ermitteln, ob Aufwandschätzverfahren eine geeignete Grundlage für die Planung von Softwareentwicklungen liefern können. Dazu wurde an gerade abgeschlossenen Entwicklungsprojekten der Firmen Degussa AG, Lufthansa AG und Siemens AG, deren Entwicklungsaufwand in einer Spannweite von 50 bis 160 Mannmonaten lag, überprüft, inwieweit solche Verfahren den tatsächlich angefallenen Aufwand vorhergesagt hätten. Es stand hierbei aber nicht nur die Ergebnisgenauigkeit im Mittelpunkt, sondern jedes untersuchte Verfahren wurde mittels 19 Testkriterien, die den Gebeiten

- Benutzerfreundlichkeit,

- Anforderungen des Projektmanagements,

- Ergebnisqualität

entstammen, umfassend bewertet. Außerdem sollten Abweichungsanalysen bei anfangs weniger geeigneten Verfahren ermitteln, ob sie durch entsprechende Modifikation verbesserungsfähig sind.

Bei dem Test ist festgestellt worden, daß die meisten herkömmlichen Verfahren den Ansprüchen mehr oder weniger nicht genügen können. Meist traten beim Praxistest Ergebnisabweichungen von über 300 Prozent auf, die auch durch Verfahrensmodifikationen nicht abbaubar waren. Das Problem der Verfahren, die eine Relation zwischen Aufwand und LoC oder Anweisungen zugrundelegen, ist, daß lediglich während der Codierung, die nur zirka 15 Prozent des Gesamtaufwands entspricht, LoC oder Anweisungen erstellt werden. Somit wäre eine Schätzung auf deren Basis auch höchstens für die Phasen Feinentwurf bis Modultest akzeptabel. Der größte Teil der wesentlichen Einflüsse auf das Gesamtprojekt ist durch solche Vorgehensweisen allerdings nicht zu erfassen.

Bei einigen Verfahren wird versucht, diesen Mißstand durch Korrekturfaktoren zu mildern, die aber waren nicht in der Lage, die falsche Grundrelation auszugleichen. Das alles erklärt, daß die Verfahren in ihrer ursprünglichen Entwicklungsumgebung wegen der Konstanz vieler Einflüsse gute Ergebnisse liefern können, bei dem vorgenommenen Test jedoch so schlecht abgeschnitten haben. Diesen Mangel könnte man durch eine stärkere Orientierung am Funktionsumfang anstelle der LoC oder der Anweisungen mildern.

Die hauptsächlich auf der Gewichtungsmethode basierenden Verfahren hätten in der Entwicklungsumgebung, in der sie entstanden sind, wahrscheinlich nicht solche unbrauchbaren Ergebnisse wie im Test geliefert. Zusätzlich war aber zu kritisieren, daß

- benötigte Eingabedaten zum Schätzzeitpunkt noch nicht oder nur unsicher quantifiziert werden können,

- oft eindeutige Normen und Richtlinien zur qualitativen Bewertung fehlen,

- eine Anpassung an geänderte Entwicklungsbedingungen mit größten Schwierigkeiten verbunden ist,

- die Schätzung durch den wachsenden Erfahrungsschatz nicht genauer wird, weil die Erfahrungsfakten nicht direkt ausgewertet werden können, und

- die Qualität der Schätzung wegen prozentualer Zuschläge für den größten Teil des Aufwands stark gemindert wird.

Ein generelles Problem beider Verfahrensgruppen ist die Integration des Testaufwands. Modernes Software-Engineering versteht unter dem Test die parallele Entwicklung eines "Antiprodukts", gegen das das System zu prüfen ist. Einer solchen Tätigkeit wird nicht mit globalen Zuschlagsätzen Rechnung getragen, weil sie einen von Projekt zu Projekt unterschiedlich großen Anteil am Gesamtaufwand ausmachen kann und außerdem in den Unternehmen spezifisch gehandhabt wird.

Die bisher beschriebenen Erkenntnisse lassen folgenden. Schluß zu: Aufwandschätzung von Softwareprojekten ist ein Problem von hoher Komplexität, das durch starre Lehrbuchformeln nicht zu lösen ist. Vielmehr verlangt es nach einer umfangreichen Unterstützung des Anwenders durch ein variables Schema bei der Konzipierung eines individuellen Modells. Das variable Quantifizierungsschema dient dazu, sämtliche jeweils wichtigen Einflüsse zu integrieren.

Eine solche Methode erscheint zwar etwas ungenauer als "starre" Verfahren aber ein exakt festgelegtes Vorgehen kann die Objektivität in gleichem Maße sichern. Jedoch gerade in diesem Punkt scheiterten bisher die meisten Verfahren aus dieser Gruppe. Aber selbst bei den wenigen akzeptablen Verfahren verlangt die unternehmensspezifische Anpassung vom Anwender natürlich eingehende Kenntnis der oben angerissenen Problematik einer Erfassung und Quantifizierung von Einflußgrößen.

Nur zwei Verfahren waren während der Untersuchung in der Lage, die formulierten Ansprüche zu erfüllen. Zum einen ist es das oben beschriebene Function-Point-Verfahren und zum anderen das "Integrierte Verfahren zur Aufwandschätzung" (Invas), das in Kooperation an der Universität Köln und bei der Siemens AG entstand. Invas eignet sich hauptsächlich für Hersteller, große Softwarehäuser und große EDV-Abteilungen, da für den lohnenswerten Einsatz eine große Zahl von Projekten aus der jeweiligen Entwicklungsumgebung analysiert werden muß. Zusätzlich sind umfangreiche Faktoren- und Maßgrößenuntersuchungen durchzufahren. Mit Invas steht dann aber nicht nur ein Aufwandschätzverfahren zur Verfügung, sondern ein weitergehendes Instrument zur Kostenrechnung, das den Entscheidungs- und Informationsprozeß innerhalb der Softwareproduktion und damit auch wieder die Aufwandschätzung verbessert.

Für kleinere Anwender, aber auch für die potentiellen Invas-Benutzer dürfte Function-Point bezüglich der reinen Aufwandschätzung die bessere Nutzen-Kosten-Relation bieten, da es mit weniger Aufwand verbunden in den meisten Fällen wesentlich schneller einsetzbar ist.

Denn als großer Vorteil von Function-Point ergab sich im praktischen Test, daß die von der IBM Deutschland ermittelte Kurve zur Umrechnung von Function-Points in Mannmonate als Ausgangsfunktion verwendbar ist. Somit kann man das Verfahren unter geringen Einbußen sofort einsetzen, was Abweichungen von maximal + 15 Prozent beweisen. Eine Plausibilitätskontrolle und eventuell folgende geringfügige Kalibrierung an zwei oder drei abgeschlossenen Projekten aus der jeweiligen Entwicklungsumgebung sind als Vorarbeiten völlig ausreichend. Ein Aspekt, der Function-Point gerade für kleine Anwender noch interessanter macht. Sukzessive kann die "IBM-Kurve" dann in eine unternehmensspezifische umgewandelt werden, indem man immer wieder Projekte der IBM durch eigene inzwischen abgeschlossene ersetzt und die Kurve neu berechnet. Zu diesem Zweck sind in dem Buch die Entwicklungsumgebung der "IBM-Kurve" und die zugrundeliegenden Projekte beschrieben.

Zusammenfassend läßt sich feststellen, daß ein Hauptvorteil von Function-Point in der Orientierung am Funktionsumfang liegt. Das ermöglicht eine

- "Black-box-Betrachtung" aus der Sicht der Benutzeranforderungen,

- Nutzen-Kosten-Bestimmung für einzelne Funktionen,

- erhöhte Transparenz der Kalkulation und

- frühere und sichere Bestimmung der Systemgröße.

Zum anderen ermöglicht die unternehmensspezifische Anpassung des Verfahrens, viele Umgebungseinflüsse als konstant anzusehen, und es müssen nur noch projektbedingte Einflüsse nach unternehmenseigenen Kriterien quantifiziert werden.

Function-Point stellt somit einen entscheidenden Fortschritt auf dem Gebiet der Aufwandschätzung dar. Man kann durchaus von einem Verfahren einer neuen Generation sprechen, das in der Lage ist, den schlechten Ruf wettzumachen, den Schätzverfahren bei DV-Praktikern noch besitzen.

*Thomas Noth ist Mitarbeiter des Lehrstuhls für Betriebs- und Wirtschaftsinformatik an der Universität Erlangen-Nürnberg. Unter Mitwirkung von Dr. Mathias Kretzschmar, Assistent des Vorstandes der M.A.N. AG, verfasste er das Buch "Aufwandschätzung von DV-Projekten - Darstellung und Praxisvergleich der wichtigsten Verfahren", Springel-Verlag Berlin-Heidelberg-New York-Tokio 1984, das in Kürze erscheint.