CC-REPRINT. unction-points aus historischer Perspektive. Harry M. Sneed CC GmbH, Wiesbaden

Transkript

1 CC-REPRINT unction-points aus historischer Perspektive Harry M. Sneed CC GmbH, Wiesbaden Published in: Gesellschaft für Informatik, achausschuß 5.1 Management der Anwendungsentwicklung und -wartung im achbereich 5 Wirtschaftsinformatik

2 Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved

3 Harry M. Sneed CC GmbH, Wiesbaden unction-points aus historischer Perspektive unction-points werden gebraucht, um den Aufwand für eine Softwareentwicklung bzw. um die Größe eines Systems zu schätzen. Sie werden auch gelegentlich mißbraucht, um Softwaresysteme miteinander zu vergleichen. Die große Gefahr dabei besteht darin, daß unction-points unterschiedlich gezählt werden. Es gibt zwar eine herrschende Norm von der internationalen unction-point-user-group (I PUG), aber auch sie wird unterschiedlich ausgelegt. Besonders schwierig wird es, unction-points zu zählen, wenn es darum geht, verteilte objektorientierte Anwendungen damit zu messen. Der Grund dafür liegt vor allem in dem Ursprung des Konzeptes. Ursprünglich war es gedacht, unction-points aus der Entwurfsdokumentation abzuleiten. Als Alan Albrecht von der IBM die unction-points Ende der 70er Jahre erfand, herrschte die hierarchische Input-Processing-Output-Entwurfsmethode, bekannt als HIPO. Nach dieser Methode gab es zunächst eine Hierarchie bzw. einen Baum der fachlichen unktionen. Angefangen mit der Systemfunktion an der Spitze des Baumes, wurden die unktionen immer weiter verfeinert bis zu den elementaren unktionen wie z. B. Zinsberechnung oder Kontospeichern an den Wurzeln des Baumes. Anschließend ging man daran, für jeden Baumknoten ein Input-Processing-Output-Diagramm zu zeichnen. Dieses bestand aus einem vorgedruckten Blatt mit drei Säulen, die man handschriftlich ausfüllte. In der linken Säule trug man die Eingabedaten ein, in der rechten die Ausgabedaten und in der Mitte die Verarbeitungsschritte. Unter der Processing-Spalte kam eine Schachtel für die Stammdaten. Daher der Name Input-Processing-Output. Manche, besonders eifrige Analytiker haben einzelne Datenfelder eingetragen, aber in der Regel beschränkte man sich auf Datengruppen wie Adreßdaten oder Bestellposten. Die Verarbeitungsschritte waren auch keine Programmierungsanweisungen, sondern verbale Texte, mit denen Grundfunktionen und deren Verarbeitungslogik beschrieben wurden. Manchmal gab es Verweise zu Pseudocodeblättern oder Entscheidungstabellen. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 1

4 Die Erstellung der HIPO-Diagramme war die Aufgabe der Systemanalytiker und gehörte zur Entwurfsphase. Anschließend dienten sie als Programmiervorgabe. Zu dem Zeitpunkt, wo Albrecht die Methode erfand, hatte IBM begonnen, die ersten estpreisprojekte anzubieten. Der estpreis galt aber nur für Programmierung und Test. Analyse und Entwurf wurden nach wie vor nach Aufwand berechnet, d. h. bis zur Erstellung der Programmiervorgabe wurde nach Time and Material bezahlt und erst nachher nach Ergebnis. Es kam also für den Auftraggeber darauf an, möglichst viel in die Analyse und Entwurfsphasen hinein zu packen, um den Aufwand für die Realisierung in Grenzen zu halten. Es kam weiter darauf an, eine möglichst detaillierte Entwurfsdokumentation zu erarbeiten, um den Programmieraufwand kalkulierbar zu machen. Keiner wäre auf die Idee gekommen, den Aufwand vor dem Ende der Entwurfsphase zu schätzen. Der Erfinder der unction-points-methode hatte die Aufgabe, Programmieraufwände anhand der HIPO-Diagramme für den festen Teil des Projektes zu schätzen. Bis dahin war mindestens ein Drittel des Aufwandes schon verbraucht. In Anbetracht der Gestaltung der HIPO-Diagramme lag nichts näher als die Eingaben, die Ausgaben und die Stammdaten zu zählen und zu gewichten. Man hätte auch die Verarbeitungsschritte zählen können, aber dies erwies sich als zu unstabil. Es war schon immer schwer, unktionalität zu beschreiben. Daten sind stabiler. Deshalb wurde auf die eigentliche unktionalität verzichtet und statt dessen nur die Daten gezählt. Albrecht wies den Eingaben ein Gewicht von 3 bis 6, den Ausgaben ein Gewicht von 4 bis 7 und den Stammdateien ein Gewicht von 7 bis 15 zu. Und so ist es bis zum heutigen Tag geblieben, auch im I PUG 4 Standard. Später wurde den Ausgaben für fremde Systeme ein Gewicht von 5 bis 10 zugewiesen und es kamen 14 Einflußfaktoren dazu, um die unction-point- Zahl um 35 % nach oben oder nach unten zu justieren, aber die Grundzählung blieb unangetastet. Solche Einflußfaktoren wie Online-Wartung und Wiederverwendung klingen heute recht seltsam aber das ist ein anderes Thema. Nach einigen Projekten konnte Albrecht eine Produktivitätstabelle für das mittlere Verhältnis zwischen unction-points und Aufwand errechnen und kalibrieren. Je mehr Projekte der gleichen Art auf die gleiche Art und Weise geschätzt wurden, desto stabiler wurde die Produktivitätstabelle. Heute liegt der Durchschnitt bei circa 20 unction-points per Mannmonat. ür die Schätzung von Hostrechneranwendungen in der damaligen Zeit mit einer konstanten Umgebung - OS, VSAM, IMS, CICS - hatte diese Methode durchaus ihre Berechtigung. Es mußte aber allen klar sein, daß diese Schätzmethode auf eine Entwicklungsmethode für eine bestimmte Umgebung Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 2

5 zugeschnitten war. Ob sie in einer verteilten, vernetzten, objektorientierten und komponentenbasierten Umgebung noch brauchbar ist, ist mehr als fraglich. Wie ist eine HIPO-basierte Schätzmethode auf eine UML-basierte Entwicklungsmethode anzuwenden? Zwischen diesen beiden Methoden liegen Lichtjahre. Was wichtig wäre für die heutigen Internet-Anwendungen, wäre ein Maßstab, der den vielen Schnittstellen, Objekten und Nutzungsfällen gerecht wird. Es würde auch niemand versuchen, die Geschwindigkeit einer Rakete mit einer Sanduhr zu messen. Die Produktionsmittel ändern sich und mit ihnen die Produktions- und Planungsmethoden. Das Objekt - in diesem alle das Projekt - bestimmt die Sichten auf das Objekt - hier die Größenmessung. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 3