Der zunehmende Engpaß in der Software-Entwicklung führt bei den Anwendern dazu, daß die Verwendung der knappen Ressource Systemanalytiker und Programmierer geplant werden muß. Leider beruhten diese Planungen in der Vergangenheit meist auf subjektiven Schätzungen. Robert Hürten* beschreibt eine Alternative.
Grundlage der Planung ist heute meist die persönliche Erfahrung. Mit der Schätzung des Aufwandes für anstehende Softwareprojekte werden vorwiegend die erfahrensten Mitarbeiter in- der Entwicklungsabteilung beauftragt. Nachdem sie die meist dürftige Beschreibung der anstehenden Entwicklung flüchtig studiert haben, suchen sie in ihrem Gedächtnis nach ähnlichen Projekten, an denen sie in der Vergangenheit mitgearbeitet hatten. Ausgehend von dem Projekt der Vergangenheit, das dem künftigen am nächsten kommt, übertragen sie den damaligen Aufwand auf die anstehende Arbeit.
Mit dieser Methode wird die Planungsgrundlage auch für sehr große Projekte in wenigen Tagen, oft sogar in wenigen Stunden ermittelt. Beauftragt man mehrere Experten mit der Schätzung desselben Projektes, so werden die Schätzungen sehr unterschiedlich ausfallen, auch wenn alle die gleichen Vorgaben hatten.
Schuld ist oft der Zeitdruck
Worin liegen die Ursachen für dieses Phänomen? Da die Schätzgrundlagen in der Reizel sehr dürftig sind, sehen sich die Schützer gezwungen, eine mögliche Lösung für die anstehende Aufgabe rein. gedanklich zu suchen. Da die Schätzergebnisse kurzfristig erwartet werden, reicht die Zeit nicht aus, um eine detaillierte Dokumentation dieser ausgedachten Lösung vorzunehmen. Es bleibt bei einem verschwommenen Bild von der künftigen Lösung, und die Schätzung basiert auf einer, imaginären Lösung.
Da die Schützer ihre eigene Kreativität einbringen, wird jeder Schätzende eine andere Lösung finden. Die Differenziere werden zunächst nicht auffallen, da für die imaginären Lösungen keine detaillierten Beschreibungen vorliegen. Beschrieben wird, das zeigt die Praxis immer wieder, nur die Grundidee der Lösung. Da diese bei Fachleuten weitgehend die gleiche sein wird, treten die wesentlichen konzeptionellen Unterschiede im Detail nicht zutage. Deutlich werden zwar Unterschiede im geschätzten Aufwand, nicht aber die unterschiedlichen Lösungsansätze.
Jeder hat seine eigene Meßlatte
Der zweite wesentliche Einfluß auf das Ergebnis der bisherigen Schätzmethoden liegt in der Auswahl desjenigen Projektes, mit dem das künftige verglichen wird. Da die Schützer unterschiedliche Berufserfahrungen haben, werden sie auch unterschiedliche Projekte als dem zu schätzenden inhaltlich entsprechend auswählen. Zum dritten genügt die Kenntnis des Aufwands bei analogen Projekten noch nicht, um den Aufwand für das künftige Projekt zu benennen. Der erfahrene Schützer wird zusätzlich noch einen Vergleich zwischen dem Leistungsniveau des damaligen und dem des heutigen Entwicklungsumfeldes anstellen. Bevor er den Aufwand für das neue Projekt nennt, bewertet er aus seiner Sicht, inwieweit das neue Entwicklungsteam in seiner Produktivität dem damaligen entspricht. Dies bedeutet, daß jeder Schützer seine eigenen Maßeinheiten für die Aufwandsschätzung hat.
Die nachgewiesene Unsicherheit von Schätzungen nach der oben geschilderten Analogiemethode hat ihre Ursache in ihrer Subjektivität. Eine zuverlässige Schätzmethode kann nur dann gefunden werden, wenn es gelingt, objektive Merkmale für die Beschreibung des Projektumfanges und für die Produktivität des Entwicklungsumfeldes zu finden.
Das Schätzen mit der Analogmethode basiert auf bekannten historischen Projekten, deren Inhalt, Verlauf und Aufwand sich der Schützer gemerkt hat.
Nochvohzlehbare Kriterien durch verbindliche Regeln
Er hat sich gedanklich seine eigene Erfahrungs-Datenbank angelegt. Der Nachteil der Analogmethode liegt darin, daß die persönlichen Datenbanken keine einheitlichen Bewertungsmaßstäbe haben. Was zum Beispiel von dem ersten Schützer aufgrund seiner langjährigen Erfahrung als einfach angesehen wird, kann für einen zweiten mit weniger Erfahrung auf diesem Anwendungsgebiet als aufwendig eingestuft werden.
Erfahrungs-Datenbanken für die Schätzung von Softwareprojekten verlangen eine Objektivierung der Kriterien, die abgespeichert werden. Es müssen Regeln vorgegeben werden, nach denen einheitlich vorgegangen wird. Vor allem sind folgende Punkte zu klären:
- die Beschreibung der Projekte,
- die Ermittlung und Bewertung des Projektumfanges,
- die Ermittlung des geleisteten Aufwandes und
- die Leistung des Entwicklungsumfeldes.
Dabei ist zu beachten, daß die Regeln aufeinander abgestimmt sind. Grundsätzlich kann jeder Anwender für seine Softwerker eigene Regeln definieren. Sobald jedoch daran gedacht wird, derartige Erfahrungs-Datenbanken für zwischenbetriebliche Vergleiche zu nutzen, müssen die Regeln für alle am Vergleich teilnehmenden Anwender Ideentisch sein.
Gemeinsame Sprochebene
Die Beschreibung einer zu schätzenden Software-Entwicklung richtet sich - im Gegensatz zu anderen Softwaredokumentationen - an zwei sehr unterschiedliche Adressaten: an DV-Anwender und an Software-Entwickler. Es muß also eine Sprachebene gefunden- werden, die von allen Adressaten gleich verstanden wird.
In der Praxis bietet sich ein semantisches Funktions- und Datenmodell an. Die zu erbringenden Funktionen werden Über die Ein- und Ausgaben der Benutzeroberflächen dargestellt, die gespeicherten Daten hingegen in ihrer logischen Gruppierung und Struktur.
Diese Darstellung muß der Sicht des Anwenders entsprechen, weil dieser sonst nicht in der Lage ist, an den Grundlagen für die Schätzung mitzuarbeiten. Außerdem ist nur auf diese Weise gewährleistet, daß die Beschreibungen unabhängig von aktuellen DV-technische Einflüssen (zum Beispiel Datenbanksystemen oder Programmiersprachen) bleiben.
Für die Erfahrungs-Datenbank ist vor allem der letzte Punkt von großer Bedeutung. Nur wenn die Beschreibung unabhängig von den technischen Entwicklungen der Datenverarbeitung ist, kann sie über lange Zeiträume vergleichbar bleiben. Welche Dokumentationstechniken für die Erstellung der Beschreibungen angewandt werden, ist nicht von entscheidender Bedeutung.
Aufwandawarte für die Gewichtung
Eine Ermittlung des Funktionsumfanges der Projekte erfolgt zum einen, um die Projekte vergleichbar zu machen, und zum anderen, um aus ihrem Umfang Aussagen über den notwendigen Realisierungsaufwand ableiten zu können. Wenn, wie oben ausgeführt, die Projekte über ihre Oberflächen und Datenbestände beschrieben wer den, dann bieten sich diese Informationen auch dafür an, den Umfang des Projektes zu messen.
Datenbestände sowie Ein- und Ausgaben lassen sich nicht als eine Einheit betrachten, da sie unterschiedlich groß sein können. Man muß zum Beispiel unterscheiden können zwischen Datenbeständen mit vielen und solchen mit wenigen Attributen sowie zwischen ein und solchen mit wenigen Attributen sowie zwischen Eingaben mit einfachen und solchen mit aufwendigen Prüfungen.
Um Datenbestände und Oberflächen nach ihren Größen differenzieren zu können, werden entweder Gruppen gebildet (einfach, mittel, schwer) oder Felder, Attribute etc. exakt ausgezählt. Gruppen, Felder und Attribute werden mit Aufwandswerten gewuchtet, um aufgrund der Summen zu Aussagen über die Größe des jeweiligen Projektes zu kommen. So kann beispielsweise ein Datenfeld den Aufwandswert 1, eine mittelschwere Eingabengruppe den Aufwandswert 4 haben.
Mit der Methode der Gruppenbildung arbeitet das Function-Point-Verfahren, mit der der Einzelzählung das Data-Point-Verfahren. Beide Verfahren sind von ihrem Ansatz her gleich zu bewerten. Das Function-Point-Verfahren ist allerdings durch seine vereinfachende Gruppierung für Schätzungen in den frühen Phasen einer Software-Entwicklung besonders geeignet.
Die Bewertung von Softwareprojekten über ihre Oberflächen und Datenbestände, die aus der Sicht der Anwender ermittelt wurden, hat gegenüber anderen Verfahren einen großen Vorteil: Mit Hilfe dieser Methode werden nur die betriebswirtschaftlichen Aufgaben und nicht deren unterschiedliche Lösungsmöglichkeiten gemessen; ein solches Bewertungsverfahren kann also auch für rein manuelle Arbeitsvorgänge genutzt werden.
Projektstunde statt Mannmonat
Die Ermittlung des geleisteten Aufwandes geschieht über das Projekt-Berichtswesen. Im Hinblick auf die sich permanent ändernden tariflichen Arbeitszeiten sollte jedoch von der heute allgemein üblichen Leistungseinheit Mannmonat (MM) auf die Einheit Projektstunde (PS) umgestellt werden. Ein PS entspricht dabei der Arbeit die ein Mitarbeiter in einer Sinde für ein bestimmtes Projekt leistet. Durch diese Umstellung wird erreicht, daß die in einer Erfahrungs-Datenbank gespeicherten Daten für abgeschlossene Projekte über lange Zeiträume vergleichbar bleiben, auch wenn sich die monatlichen Arbeitszeiten merklich ändern.
Eine Statistik auf Basis abgeschlossener Projekte
Die Produktivität eines gesamten Software-Entwicklungsumfeldes kann als Anzahl der realisierten Aufwandswerte pro Stunde definiert werden. Die Produktivität der Software-Entwicklung wird jedoch durch eine Reihe unterschiedlicher Faktoren bestimmt: durch die Programmiersprache, die Erfahrung der Mitarbeiter, die Software-Tools etc. Eine Berücksichtigung dieser vielen Einzelfaktoren würde eine Erfahrungs-Datenbank immens vergrößern.
Mit Hilfe einer Statistik auf der Grundlage abgeschlossener Projekte kann jedoch eine durchschnittliche Aufwandskurve ermittelt werden - vorausgesetzt, die Summe der Aufwandswerte und die benötigten Projektstunden sind jeweils bekannt. Diese nicht lineare Aufwandskurve basiert praktisch auf den Durchschnittswerten aller möglichen Einflußfaktoren eines Entwicklungsumfeldes.
Aus der Aufwandskurve läßt sich dann ableiten, wieviel Zeit für die Erstellung eines Softwareproduktes benötigt wird, dessen Umfang in Aufwandswerten vorliegt. Diese auf den Nachkalkulationen abgeschlossener Software-Entwicklungen basierende Aufwandskurve ist der wesentliche Bestandteil einer Erfahrungs-Datenbank für die Planung von DV-Projekten.
Subjektive Einschätzungen lassen sich ausschalten
Wenn eine Erfahrungs-Datenbank unter Beachtung der oben besprochenen Punkte eingerichtet wird, treten dokumentierte Schätzgrundlagen an die Stelle der imaginären Lösungen. Über Aufwandswerte und -kurve lassen sich subjektive Einschätzungen des Erstellungsaufwandes und des Entwicklungsumfeldes ausschalten, so daß diese beiden Faktoren innerhalb einer Organisation vergleichbar werden.
Leistungsvergleiche zwischen voneinander unabhängigen Organisationen vorzunehmen, ist allerdings nicht möglich. Die Aufwandskurven können nämlich nur solange eine zuverlässige Aussage geben, wie sie sich auf dasselbe Entwicklungsumfeld beziehen.
Die Ermittlung der Aufwandswerte für ein Softwareprojekt ist nicht nur für eine zuverlässige Schätzung im Rahmen der Planung sinnvoll. Werden die Aufwandswerte (im Phasenverlauf des Projektes neu ermittelt beziehungsweise fortgeschrieben, so tritt zutage, ob und in welchem Umfang sich der Inhalt des Projektes geändert hat. Eine Veränderung der Aufwandswerte ist ein Signal dafür, daß die bisherige Zeitplanung nicht mehr realistisch ist. Steigen die Aufwandswerte im Verlauf eines Projektes um mehr als fünf Prozent, so muß die Terminplanung überarbeitet werden.
Gute Planung verhindert Tormindruck
Die Aufwandswerte sind die Grundlage für ein Projekt-inhalts-Kontrollsystem (Piks). Spätestens zum Ende einer Projektphase ist der Projektleiter verpflichtet zu prüfen, ob sich die Summe der Aufwandswerte verändert hat. Das Berichtswesen für das Projektmanagement wird also um die Informationen ursprünglich geplante Aufwandswerte und Aufwandswerte zu Ende der n-ten Phase erweitert. Sofern die Softwareentwicklung projektbegleitend dokumentiert wird, entsteht durch das "Piks" nur ein minimaler zusätzlicher Aufwand. In allen Fällen führt es zu einer merklichen Verbesserung der Dokumentationsmethode.
Die Einrichtung eines Piks ist nicht nur für das direkte Projektmanagement wichtig. Ein solches System trägt auch indirekt zu einer Verbesserung der Softwarequalität bei. Eine gute Planung kann verhindern, daß die Mitarbeiter gegen Ende der Softwareprojekte unter einen gewaltigen Zeitdruck geraten: Die Qualität der Tests und der Dokumentation braucht dann nicht mehr der Termilntreue geopfert zu werden.