Ausarbeitung für Projektmanagement. Projektplanung

Transkript

1 Ausarbeitung für Projektmanagement Projektplanung Autoren: Annette Fink (AI 8) Daniel Schönle (CN 5) Christoph Wienands (AI 8)

2 Inhaltsverzeichnis EINLEITUNG...4 ALLGEMEIN...5 NOTWENDIGKEIT VON PROJEKTPLANUNG...6 SCHWIERIGKEITEN BEI DER PROJEKTPLANUNG...7 PLANUNGSVERLAUF IN DER PROJEKTPLANUNG Spezifikation Entwurfsdokumentation...7 STRUKTUR- UND ABLAUFPLAN...8 UNTERSCHEIDUNG STRUKTURPLAN UND OPERATIVE PLANUNG...8 Strukturplanung...8 Operative Planung...9 UNTERSCHIED PROJEKTSTRUKTUR OBJEKTSTRUKTUR...9 Projektstruktur...9 Objektstruktur...9 Anmerkung zur objektorientierten Projektstruktur...10 KOMPLEXE OBJEKTORIENTIERTE SYSTEME WERDEN ARCHITEKTURORIENTIERT ENTWICKELT...10 UML...11 NACHHALTIGKEIT...11 ZIELERREICHUNG...12 AUFWANDSCHÄTZUNG...13 ALLGEMEINES...13 EMPIRISCHE SCHÄTZVERFAHREN...13 Expertenbeurteilung/Analogieverfahren...13 Delphi-Methode...14 ALGORITHMISCHE SCHÄTZVERFAHREN...14 BEISPIELE ALGORITHMISCHER SCHÄTZVERFAHREN...15 COCOMO...15 Das Function Point-Verfahren...16 SONSTIGE METHODEN...20 PFLEGEKOSTEN...20 EINFLUSS DER SCHÄTZUNG AUF DEN AUFWAND...21 TERMINPLANUNG...21 TERMINLISTEN...22 BALKENDIAGRAMME...22 NETZPLANTECHNIK...22 PERSONALPLANUNG

3 RESSOURCENPLANUNG...24 KOSTENPLANUNG...26 DER PROJEKTPLAN...29 PROJEKTE PLANEN MIT EXTREME PROGRAMMING...30 PROBLEME TRADITIONELLER, SCHWERER SOFTWAREENTWICKLUNGSPROZESSE...30 XP ALS LEICHTGEWICHTIGER PROZESS...31 ABLAUF EINES PROJEKTES...32 PLANUNG DURCH GESCHICHTEN...32 VERSIONSPLANUNG...33 ITERATIONSPLANUNG...33 WEITERE BESONDERHEITEN VON XP...34 STOP, SO FUNKTIONIERT DAS ABER NICHT!...35 FAZIT...36 QUELLENANGABEN...37 GLOSSAR

4 Einleitung Um nicht im vollständigen Chaos zu versinken, geht es heutzutage nicht mehr ohne Projektplanung. Insbesondere, wenn mehrer Personen am Durchführen des Projektes, ja vielleicht sogar mehrere Projekt-Teams beteiligt sind. Termine, der Ablauf, die Kostenfrage, die Dauer, und noch weitere Faktoren müßen berücksichtigt, koordiniert und organisiert werden. Für diese Koordination gibt es verschieden Konzepte und Strukturen. Diese Ausarbeitung versucht dem Leser eine Übersicht über diese Konzepte und Strukturen zu vermitteln, und vergleicht zum Schuß die traditionelle Softwareplanung mit dem Konzept des Extreme Programming von Beck und Fowler¹. Diese vorliegende Ausarbeitung trägt den Titel Projektplanung und ist die logische Fortsetzung des Themas Projekt- und Phasenorganisation von Ebner, Geldhauser und Weber². 4

5 Allgemein Zu welchem Zeitpunkt benötige ich Projektplanung? Für eine Antwort ist es nötig, den Begriff der Projektplanung zu definieren: In der Umgangssprache fängt Projektplanung genau dann an, wenn ich die Idee zu einem Produkt habe. Ideenfindung, Mindmapping, Brainstorming werden bereits intiuitiv dazugezählt. Im wissenschaftlichen Kontext jedoch, fängt der Bereich Projektplanung erst dann an, wenn ich bereits einen Projektleiter benannt habe. Warum? Weil dieser Projektleiter für die Projektplanung verantwortlich ist. Er plant und leitet das Projekt. Das Projekt an sich hat nun einen formellen Status. In dieser Ausarbeitung verwenden wir Projektplanung im wissenschaftlichen Kontext, um den Bereich an sich klar abzugrenzen. Wir, die diese Ausarbeitung und die dazugehörige Präsentation anfertigen, hatten zu Beginn unserer Treffen große Probleme damit, den Bereich Projektplanung einzugrenzen und in verschieden Gebiete zu untergliedern. Ein Grund dafür war unter anderem, daß die Literatur und die zahlreich dazu existierende Dokumente die Grenzen zwischen Projektmanagement und Projektplanung verwischen. Genauso wird Projektorganisation und Projektplanung nicht klar getrennt. Bereiche der Projektorganisation befinden sich unter dem Stichpunkt Projektplanung und vice versa. Wir wissen, daß es schwer ist, ein Projekt und die dazughörige Planung abzugrenzen, und in ein Schema F einzugliedern. Dies hängt von verschiedenen Faktoren ab, wie zb. welches Produkt stelle ich im Endeffekt her. Dennoch könnte man erwarten, daß man irgendwo in der Literatur ein Schema F zur Projektplanung findet, welches als allgemeiner Standard gehandhabt wird, und von welchem je nach Einsatz in der Wirtschaft, also je nach Produkt, dementsprechend abgeleitet werden kann. So einen Standard scheint es bis jetzt nicht zu geben! Es sei an dieser Stelle erwähnt, daß Pläne immer auf Schätzungen beruhen. Es ist sehr unwahrscheinlich, einen Plan zu machen, der genau so eintritt. Dies sollte sich ein Projektleiter zu Herzen nehmen, vor allem wenn es darum geht, Kosten und Dauer abzuschätzen. Er sollte möglichst alle Faktoren in diese Schätzungen miteinbeziehen, um den Schaden so gering wie möglich zu halten, und einen möglichst genauen Projektplan zu erstellen. 5

6 Notwendigkeit von Projektplanung Warum benötige ich überhaupt Projektplanung? Ein altes Sprichwort unbekannter Herkunft sagt: Planung ersetzt den Zufall durch Irrtum. Was wenn ich es positiv ausdrücke soviel heißt wie: Planung ersetzt zufälliges Glück durch geplanten Erfolg! Allerdings könnte man jedoch entgegenstellen, daß die Planung sehr viel Zeit erfordert, und daß man diese Zeit besser in die Realisierung des Projektes stecken sollte. *** *** *** ********* ########## ********* ########## ********* ########## * = Zeit für Planung + = Zeit für die Durchführung # = Zeitgewinn (Grafikquelle³ ) Diese Grafik soll aber anschaulich verdeutlichen, daß was einem zuerst als Zeitverschwendung erscheint, am Ende sozusagen ein Zeitgewinn wird. Diesen Zeitgewinn könnte ich positiv in mein Projekt einbringen, in dem ich zb. Die Funktionalität meine Produktes erweitere. Der Kunde würde begeistert sein. Eine weitere Notwendigkeit von Projektplanung ist, daß die Koordination und der Projektablauf zwischen den einzelnen Teammitgliedern und den Teams organisiert und festgelegt werden. Jeder weiß, was seine Aufgabe ist, für welchen Teil des Projektes er verantwortlich ist, und bis wann er seinen Projektteil abzuliefern hat. Man möge sich dazu ein Projekt mit 15 Menschen vorstellen, die ein Software Program entwickeln möchten. Man stelle sich weiter vor, selbst ein Programmierer in diesem Team zu sein. Und nun stelle man sich vor, es existiere kein Projektplan... der psychische Stress und die Sorgen haben schon angefangen, obwohl das Projekt noch überhaupt nicht begonnen hat. Projektplanung brauche ich auch, um festzustellen, wo ich in meinem Projektablauf stehe. Habe ich schon die Hälfte meines des mir vom Projekt übertragenen Teiles geschafft, oder schon dreiviertel? Wahrscheinlich sind es erst einviertel! Zu wissen wo man in einem Projektablauf steht, wieviel Zeit einem noch bleibt, kann einen motivieren mehr zu arbeiten, oder sich ein bißschen mehr Zeit für einen Teil zu nehmen. 6

7 Schwierigkeiten bei der Projektplanung Die wohl größten Schwierigkeiten bei der Projektplanung liegen darin, einen möglichst genauen Schätzfaktor für die Kosten und die Dauer des Projektes im vorneherein festzulegen. Wie wir weiter vorne im Text bereits angemerkt haben, beruhen Pläne auf Schätzungen, und es es nicht so einfach diese beiden Faktoren genau zu bestimmen. Dafür gibt es die verschiedensten Schätzverfahren, die wir in der Mitte dieser Ausarbeitung näher betrachten werden. Was bei der Projektplanung insbesonders zu beachten ist, ist daß zuerst eine Grobplanung des Projektes aufgestellt wird. Von dieser Grobplanung ausgehend wird auf eine Feinplanung hingearbeitet. Wenn nun zu früh eine Feinplanung vorgenommen wird, wird riskiert sich im Detail zu verlaufen und den Überblick über das ganze Projekt zu verlieren. Auch ist es Gang und Gebe, daß ein Plan häufig revidiert werden muß. Eine Schwierigkeit, die das Projekt eher begleitet, aber auch schon zu Beginn der Projektplanung auftreten kann, ist die Dokumentationen auf dem Laufenden zu halten. Es werden im Laufe des Projektes sehr viele Dokumente und Dokumentation produziert, und alle Teammitglieder ständig auf dem Laufenden zu halten dürfte eine Herausforderung für sich sein. Planungsverlauf in der Projektplanung 1. Spezifikation Der erste Planungsschritt ist wohl der Entwurf des Konzepts, die Spezifikation. Das Konzept ist die schematische Darstellung des künftigen Projekts. Da das Konzept möglichst realistisch wirken sollte, muß genügend Zeit für die Erstellung eingeplant werden. In diesem Konzept werden die Anforderungen an das Projekt explizit dargestellt. Der Kern des Konzepts ist die Zielsetzung. Hier werden die Ziele benannt, und die Indikatoren die anzeigen, ob ein Ziel erreicht wurde, oder nicht. Außerdem enthält ein Konzept eine Beschreibung der vorgesehenen Funktionalität der Software. Die Qualität des Projektes wird an der Erreichung der definierten Ziele, und an der realisierten Funktionalität gemessen. 2. Entwurfsdokumentation Der nächste Planungsschritt beschreibt die Produktstruktur. Die Produktstruktur ist die Antwort auf folgende Frage: Was wird geliefert? Daraufhin wird die Objektstruktur beschrieben, anschließend die Projektstruktur. Die dazugehörigen Fragen lauten: Welche zusätzlichen Anforderungen sind notwendig 7

8 und wie werden die noch anstehenden Aufgaben am besten strukturiert? (Objektstruktur) Und: Welche Tätigkeiten sind dazu erforderlich? (Projektstruktur) Auf die Projektstruktur setzt der Ablaufplan auf, welcher sich durch die Antwort auf folgende Frage am besten beschreiben läßt: In welcher Reihenfolge werden die Tätigkeiten erforderlich? Der Aufwandsplan beschreibt mit welchem Aufwand gearbeitet wird. Womit gearbeitet wird beschreibt der Ressourcenplan, und der Netzplan frägt : wann wird gearbeitet? Mit diesen Schritten sollte die Projektplanung erfolgt sein. Im Projektverlauf sind die nächsten Schritte nun die Kodierung und anschließend die Testdokumentation. Struktur- und Ablaufplan Strukturplan Der Strukturplan gliedert das Projekt graphisch oder tabellarisch in Teilprojekte. Diese Teilprojekte werden je wieder in Teilprojekte gegliedert. Dieser Teilungsprozess geschieht so oft, bis ein Teilprojekt nicht mehr aufgegliedert werden kann. Dieses Element auf der untersten Ebende heißt dann Arbeitspacket. Diese einzelnen Arbeitspackete sind für Zwischenergebnisse und (Objekt-) Dokumentationen erforderlich. Ablaufplanung Ablaufplanung ist nichts anderes, wie die Vorgänge im Projektplan in eine logische Reihenfolge anzuordnen. Unterscheidung Strukturplan und Operative Planung Am Anfang steht die Projektplanung. Die Projektplanung läßt sich unterscheiden zwischen den beiden Bereichen Strukturplanung und Operative Planung. Beide Oberpunkte lassen sich wieder in die folgenden Bereiche unterteilen: Strukturplanung Produktstruktur Projektstruktur Objektstruktur 8

9 Operative Planung Aufwand Dauer Termine Kapazitäten Kosten In dieser Ausarbeitung sehen wir uns die Objektstruktur genauer an, auf die Projektstruktur wurde in ¹ im näheren eingegangen. Die Produktstruktur wird nicht weiter erwähnt, wie im folgende Satz, da die Produktstruktur sich mit der Entwicklung von herkömmlichen Produkten beschäftigt, und nicht mit Software Produkten : Die Produktstruktur beschreibt die technische Struktur des zu entwickelnden Produktes. Der Produktstrukturplan enthält die Teile eines Produktes in hierarchischer Ordnung. Auf die operative Planung wird dann im Mittelteil genauer eingegangen. Doch zunächst die Differenzierung zwischen Projekt- und Objektstruktur, mit dem Übergang zur Beschreibung der Objektstruktur: Unterschied Projektstruktur Objektstruktur Projektstruktur Die Projektstruktur beschreibt die aufgabenbezogene Gliederung des Projektes. Der Projektstrukturplan enthält alle Aktivitäten, die in den einzelnen Projektphasen durchzuführen sind. Im folgenden die einzelnen Projektphasen als abstrakte Darstellung: Projektinitiierung Analyse Design Implementierung Test Abschluß Weiter wie diesen Abschnitt wird nicht auf die Projektstruktur eingegangen, da wie bereits erwähnt, in der Ausarbeitung ¹ darauf eingegangen wird. Objektstruktur Die Objektstruktur in einer Projektplanung beschreibt die Projektarchitektur oder die Programmarchitektur einer zu entwickelnden Software. Hierzu wird die innere Struktur und Wirkungsweise des Softwarprodukts beschrieben. 9

10 Innere Struktur des Softwareprodukts: Welches Objekt beinhaltet welchen (ggf. komplexen) Datentyp? Aufrufstruktur der Objekte. Welche Objekte verstehen welche Nachrichten? Funktionsgliederung und Algorithmen der Methoden. Schnittstellenbeschreibungen der Objekte. Datenorganisation. Gliederung der Daten in den Objekten. Beschreibung der Objektzustände. Nachrichten-Formatbeschreibungen. Externe Datensysteme. Wirkungsweise des Softwareprodukts: Dokumentation fachspezifischer Grundlagen (Wirkprinzipien, Vorschriften, Einschränkungen, Annahmen) Fehlerbehandlungskonzept (Maßnahmen zur Stabilität gegen Bedienungs-, Daten und Gerätefehler) Das Systemdenken und das Vorgehen vom Groben zum Detail" dienen in erster Linie der Strukturierung des zu gestaltenden Objekts. Diese Objektstruktur ist aber auch Ausgangspunkt für die Planung der Projektaktivitäten. Anmerkung zur objektorientierten Projektstruktur In der objektorientierten Gemeinde herrscht Einigkeit darüber, daß es keinen für alle objektorientierten Projekte einsetzbaren Prozeßleitfaden gibt. Es gibt aber sehr wohl generische Prozeßmodelle, die durch mehr oder minder aufwendige Modifikationen auf die Charakteristiken der verschiedenen Projekte bzw. Projekttypen zugeschnitten werden können. aus (4), Seite 22 Kapitel 3.6 Tailoring D.h. es gibt kein Schema F, nach dem ich einen Objektstrukturplan machen kann. Dies behaupten auch Goldberg und Rubin in Succeding with Objects. Hier beschreiben die Autoren, wie sie sich bei der Durchführung objektorientierter Projekte mit dem Gedanken beschäftigt haben, ein brauchbare, kochbuchartige Anleitung zu schreiben, und wie sie nach langjähriger Erfarhung mit objektorientierter Projektarbeit zur Überzeugung gekommen sind, daß dies nicht möglich ist. Komplexe objektorientierte Systeme werden architekturorientiert entwickelt Eine Softwarearchitektur ist ein Bauplan für die strukturelle Softwareorganisation des Gesamtsystems. Der Entwurf einer Softwarearchitektur kann im Projekt normalerweise nur schrittweise erfolgen. D.h. zu Beginn des Projektes wird nur eine erste grobe 10

11 Softwarearchitektur vorliegen, die im Projektablauf schrittweise zu verfeinern ist. Sie muß aber bereits in der Spezifikation die angestrebte Gesamtfunktionalität des Systems berücksichtigen. Eine solide Softwarearchitektur ist eine unverzichtbare voraussetzung dafür, daß alle Teilprodukte im Laufe der Entwicklugn zu einem einheitlichen System integriert werden können. Die Softwarearchitektur ist im Projektablauf so auszuarbeiten, daß die Anforderungen der Fachebene auf überschaubaren modulen soiwe deren Schnittstellen abgebildet werden können. Wie sieht eine Softwarearchitektur aus? Hierzu schreibt Booch: Eine gut strukturierte objektorientierte Architektur besteht aus: Einer in Hierarchien geordneten Menge von Klassen Einer Anzahl von Interaktionen wzischen diesen Klassen bzw. Objekten mit dem Ziel, ein bestimmtes Systemverhalten zu realisieren. UML Eine Objektorientierte Analyse- und Design- Notation ist UML (Unified Modelling Language), mit dazugehöriger Semantik. UML wurde von den drei Methodenspezialisten Grady Booch, Ivar Jacobson und Jim Rumbaugh formuliert. UML hat sich inzwischen zu einem Industriestandard entwickelt. UML ist eine Elementarmethode (siehe (4)), die die Frage nach dem Wie bei der Durchführung von Tätigkeiten im Prozeßmodell beantwortet. Achtung, nicht das Prozeßmodell nicht mit dem Projektmodell verwechseln! Als Prozeß stelle ich meine Software dar, also kann ich den Begriff Tätigkeiten gleich dem Begriff der Funktionalität meines Produktes setzen. UML wird u.a. in der Spezifikation der Projektplanung verwendet, da es die Beziehungen zwischen den Objekten visualisiert. Nachhaltigkeit Die Nachhaltigkeit einer Software sollte unbedingt schon bei der Projektplanung berücksichtigt werden. Der Grund der Nachhaltigkeit eine große Bedeutung zuzuordnen liegt darin, daß Projekte in der IT Branche zeitlich begrenzt sind. Deswegen sollte bei jeder Projektplanung über das Projektende hinaus gedacht und überlegt werden, wie Nachhaltigkeit erzeugt werden kann. Durch folgende Punkte kann Nachhaltigkeit erzeugt werden: Durch ständige Wartung der Software Durch das Entfernen von Bugs Durch Weiterentwicklung Durch das Hinzufügen von Funktionalitäten... 11

12 Zielerreichung Projektziele sagen etwas über die Funktionen aus, welche erreicht werden sollen. Sie sagen nichts darüber aus, mit welchen Massnahmen dieser Zustand erreicht werden soll. Sie beinhalten keine Vorschläge, wie das Vorhaben geplant und durchgeführt wird. Sie sagen nichts aus über die Machbarkeit! Ziele sollten smart sein, dh. : 1. spezifisch (konkret) 2. messbar (quantifizierbar oder mit Indikatoren versehen) 3. anspruchsvoll (mit Leistungen verbunden) 4. realistisch (mit den vorhandenen Ressourcen erreichbar) 5. terminorientiert (etappiert und terminiert) Indikatoren der Zielerreichung sollten im Projektplan genau dann angegeben werden, wenn die Zielformulierung selbst noch keine Beurteilung der Zielerreichung zuläßt. D.h. Wenn die Zielformulierung ungenau ist, und man am Ende eines Projektes nicht feststellen kann, ob das Projekt erfolgreich abgeschlossen wurde, oder nicht, genau dann braucht man Indikatoren für ein erfolgreiches Gelingen des Projektes. Und diese Indikatoren müssen im Projektplan schon definiert sein. Weitere Gründe von Indikatoren sind unter anderem: Indikatoren für die Projektzielerreichung machen den Projekterfolg greifbar Förderung der Motivation für die Projektarbeit Man hat den Erfolg, den man erreichen, möchte vor Augen. Allerdings wird oft schon das Zustandekommen eines Projektes, oder das Durchführen des Projektes alleine schon als Erfolg gewertet. Dies ist zb. der Fall, wenn die Finanzierung des Projektes nicht gesichert war, und nun plötzlich doch gesichert ist. Oder ein anderes Beispiel: es werden am Projekt massive finanzielle Kürzungen vorgenommen, und das Projekt hat nicht die Qualität, welche im Konzept beschrieben wurde. Ein Grund warum die Indikatoren zur Erfolgsfeststellung nicht aufgestellt werden, ist u.a. daß Zielvorstellungen nicht überprüfbar gemacht werden wollen. Somit kann vermieden werden, Rechenschaft über ein Scheitern des Projekts abzulegen. wenn der Erfolg benannt werden kann, kann er auch gebührend gefeiert werden! 12

13 Aufwandschätzung Allgemeines Wie man es nicht machen sollte: Eine erste Aufwandschätzung wird zunächst nach unten korrigiert, um den Auftrag zu bekommen. Anschließend wird die Schätzung jedes Mal dann nach oben angepasst, wenn sie von den tatsächlichen Kosten eingeholt worden ist. Die Schätzung nach sieben Monaten ist offenbar die erste, die wirklich seriös durchgeführt wurde. Sie zeigt, dass schon die erste Schätzung viel zu optimistisch war, ganz zu schweigen von der politischen Schätzung nach drei Monaten. Es gibt viele Gründe für die zum Teil krassen Fehleinschätzungen von Software- Kosten bzw. -Terminen, u.a. o Software-Erstellung ist weitgehend Kopfarbeit und daher stark von der Leistungsfähigkeit dieser Köpfe abhängig. Diese Leistungsfähigkeit kann um mehr als eine Größenordnung schwanken. o Nur ein kleiner Teil einer Software trägt die eigentliche Funktionalität. Ein großer Teil des Aufwands (und das wird oft übersehen) geht in Verwaltung, Fehlerbehandlung, Benutzerschnittstelle, etc. o Erfahrungen aus kleinen Projekten werden linear extrapoliert. o Programmierer programmieren nicht 100% ihrer Zeit. Empirische Schätzverfahren Expertenbeurteilung/Analogieverfahren Expertenbeurteilung ist eine vornehme Bezeichnung für Schätzungen über den Daumen. Die Güte der Schätzung steht und fällt mit der Erfahrung der Schätzenden. In der Regel wird aufgrund von Analogien zu bisher abgewickelten Projekten geschätzt. Dies geht bei erfahrenen Leuten in der Regel gut, wenn Erfahrungen mit analogen Projekten vorliegen. Krasse Fehler ergeben sich oft dann, wenn 13

14 Erfahrungen fehlen oder Erfahrungen mit kleinen Projekten auf große Projekte extrapoliert werden (Bild 1.7). FESTSTELLUNG: Expertenbeurteilung ist ein einfaches und billiges Schätzverfahren, das dann recht gut funktioniert, wenn die Schätzenden Erfahrungen mit gleichartigen Projekten haben. Andernfalls können die Prognosen sehr ungenau sein. Delphi-Methode Die Delphi-Methode versucht, Expertenschätzungen zu objektivieren. Mehrere Personen geben unabhängig voneinander eine begründete Schätzung ab. In einer nächsten Runde erhält jede(r) Beteiligte eine Zusammenfassung der ersten Schätzungen. Alle erstellen daraufhin eine neue Schätzung, wobei Abweichungen vom Mittelwert der vorhergehenden Runde zu begründen sind. Dies geht über mehrere Runden, bis alle Schätzungen einigermaßen beieinander liegen. FESTSTELLUNG: Die Delphi-Methode liefert zuverlässigere Schätzungen als die Expertenbeurteilung, weil sie Ausreißer eliminiert. Als Nachteil muss ein erheblich höherer Schätzaufwand in Kauf genommen werden. Algorithmische Schätzverfahren Algorithmische Methoden bestehen aus einem oder mehreren Algorithmen zur Berechnung einer Kosten- bzw. Durchlaufzeit-Funktion aus einer Reihe von Variablen. Bei hinreichend genauen Eingaben ergeben sich erstaunlich präzise Prognosen. Genauigkeit von COCOMO-Schätzungen Die Genauigkeit aller algorithmischen Methoden hängt jedoch entscheidend von zwei Dingen ab: 14

15 die Eingangsgrößen der Kostenfunktion (z.b. Anzahl Instruktionen) müssen einigermaßen zutreffend geschätzt werden das Modell muss kalibriert werden, d.h. der Wert der einzelnen Kostenattribute muss an die jeweilige Entwicklungsumgebung angepasst werden. Eine solche Kalibrierung ist nur möglich, wenn genügend Messwerte von durchgeführten Projekten vorliegen. FESTSTELLUNG: Algorithmische Methoden liefern die besten Schätzungen. Sie können aber nur nach entsprechenden Vorarbeiten (Kalibrierung) überhaupt eingesetzt werden. Außerdem sind sie stark abhängig von der Genauigkeit, mit der die Eingangsgrößen bestimmt werden können (garbage-in-garbage-out-problem). Beispiele algorithmischer Schätzverfahren Die zwei wichtigsten algorithmischen Schätzverfahren, COCOMO und Function Point, werden in den folgenden beiden Unterkapiteln vorgestellt. COCOMO COCOMO (Constructive Cost Model) ist das Kostenschätzverfahren von Boehm (1981). Es geht aus von einer Schätzung der Produktgröße in KDSI (Kilo lines of delivered source instructions). Aus diesem Grundwert und einer Reihe von Kosten- Multiplikatoren werden Kosten und Durchlaufzeit berechnet. Die Grundgleichungen lauten: (A) MM = 2.4 KDSI 1.05 (MM = man month) (B) TDEV = 2.5 MM 0.38 (TDEV = time to develop) Aufwandsschätzung nach COCOMO Diese Gleichungen gelten für einfache Anwendungsprogramme (organic mode). Für Programmsysteme (semidetached mode), bei denen ein erheblicher Anteil an 15

16 Interaktion mit Betriebssystem, Gerätetreibern, etc. hinzukommt und für eingebettete Systeme (embedded mode), deren Erstellung nochmals erheblich schwieriger ist, gelten andere Faktoren. COCOMO-Grundgleichungen für Programmsysteme (C) MM = 3.0 KDSI 1.12 (D) TDEV = 2.5 MM 0.35 COCOMO-Grundgleichungen für eingebettete Systeme (E) MM = 3.6 KDSI 1.2 (F) TDEV = 2.5 MM 0.32 Im Bild Aufwandsschätzung nach COCOMO wird eine graphische Veranschaulichung der Kosten über der Produktgröße gezeigt. Die mit den Grundgleichungen ermittelten Nominalwerte können nun noch erheblich genauer gemacht werden, indem man sie mit einer Reihe von Kostenfaktoren multipliziert. Die aktuellen Werte aller Kostenfaktoren für ein Projekt werden unabhängig voneinander geschätzt und anschließend alle miteinander multipliziert. Der Nominalwert für den Projektaufwand in Personenmonaten wird dann mit diesem Produktfaktor multipliziert. (G) MM Korr = Produkt der Kostenfaktoren x MM nominal Eine ausführliche Beschreibung von COCOMO, inklusive der Definition, was bei ihm ein Personenmonat und eine Zeile gelieferter Code ist, findet sich in Boehm (1981). Das Function Point-Verfahren Function Points sind ein relatives Maß zur Bewertung der Funktionalität, d.h. des Leistungsumfangs eines Systems. Verfügt ein Unternehmen über Erfahrungszahlen, wieviel Aufwand pro Function Point im Mittel benötigt wird, um Software zu entwickeln bzw. zu pflegen, so können Function Points zur Aufwandschätzung herangezogen werden. Wird in laufenden oder abgeschlossenen Projekten der mittlere Zeitbedarf pro Function Point bestimmt, so bekommt man ein Produktivitätsmaß. Das Function Point-Verfahren wurde von Albrecht (1979) bei IBM entwickelt und seither von verschiedenen Autoren bzw. Gremien ergänzt und weiterentwickelt (Seibt 1987, Symons 1988, IFPUG 1994). Das Verfahren basiert auf der Idee, die folgenden Größen eines Software-Systems in geeigneter Weise zu zählen und zu bewerten (in Klammern die Terminologie von Albrecht): o Dateneingaben (External input) o Datenausgaben (External output) o Anfragen (External inquiry) o Schnittstellen zu externen Datenbeständen (External interface file) o Interne Datenbestände (Logical internal file) Dateneingaben, Datenausgaben und Anfragen werden an Hand der logischen Transaktionen, die das untersuchte System ausführen soll, gezählt. Tauchen die gleichen Eingabe- bzw. Ausgabedaten in verschiedenen Transaktionen mit unterschiedlicher Verarbeitungslogik auf, werden sie mehrmals gezählt. Bei den 16

17 Datenbeständen werden logische Dateien bzw. logische Datengruppen (Entitätstypen, Relationen) in Datenbanken gezählt. Die Werte können alle bereits in der Anforderungsspezifikation gezählt werden, sofern diese hinreichend vollständig und detailliert ist. Jede Dateneingabe, Datenausgabe, Anfrage, etc. wird als einfach, mittel oder komplex bewertet und mit einem entsprechenden Gewicht versehen. Die Tabelle Gewichtungskriterien für Dateneingaben zeigt als Beispiel die Gewichtungskriterien für Dateneingaben; Schema zur Berechnung des Function Point Rohwerts zeigt ein Schema für die Berechnung des Function Point-Rohwerts (unadjusted Function Points, UFP). Hat also beispielsweise ein System 37 logische Transaktionen mit Dateneingaben, von denen 12 als einfach, 16 als mittel und 9 als komplex bewertet werden, so ergibt sich ein Wert von 12x3+16x4+9x6 = 154 als Wert für die Dateneingaben. Anzahl bearbeiteter Datenbestände Anzahl unterscheidbarer Datenelemente in der Eingabe >15 einfach einfach mittel mittel mittel komplex >2 mittel komplex komplex Gewichtungskriterien für Dateneingaben (IFPUG 1994) Schema zur Berechnung des Function Point Rohwerts UFP (IFPUG 1994) Der Rohwert wird mit Gewichtungsfaktoren multipliziert, welche die technische Komplexität des Systems reflektieren. Der sogenannte Wertkorrekturfaktor (VAF, value adjustment factor (auch TCF (Technical Complexity Factor)) berechnet sich nach der Formel (H) VAF = 0,65 + 0,01 x TDI TDI ist der total degree of influence, der gemäß dem Schema zur Bestimmung der Einflussfaktoren (IFPUG 1994) berechnet wird. Die Formel ist so konstruiert, dass VAF in einem Bereich zwischen 0,65 und 1,35 liegt. Die Function Points FP eines Systems berechnen sich dann zu (I) FP = UFP x VAF Sollen Function Points zur Aufwandschätzung verwendet werden, so muss der zu erwartende Aufwand pro Function Point bekannt sein. Entsprechende Kurven oder Tabellen sind im Umlauf, sind aber mit Vorsicht zu genießen. Der Aufwand pro Function Point ist stark von projektspezifischen und unternehmensspezifischen Faktoren abhängig, beispielsweise vom Können der Leute im betreffenden Unternehmen, der verwendeten Entwicklungsumgebung und dem Stellenwert von 17

18 Qualität (z.b. Umfang der verlangten Dokumente, mittlerer Testaufwand). Ferner muss geklärt werden, welche Aufgaben in der Aufwandschätzung enthalten sind (beispielsweise, ob der Aufwand für die Anforderungsspezifikation eingeschlossen ist oder nicht). Jones (1996) gibt Faustregeln zur Berechnung des Aufwands aus Function Points an. Faustregeln von Jones zur Aufwandberechnung. A. Durchlaufzeit [in Monaten] = FP 0.4 B. Anzahl Mitarbeiter = FP / 150 C. Aufwand = Durchlaufzeit x Anzahl Mitarbeiter = FP 0.4 x FP / 150 Sollen projektspezifische Faktoren (zum Beispiel die Fähigkeit der beteiligten Personen, ihre Vertrautheit mit Problemstellung und die Vertrautheit mit der Lösungsplattform) berücksichtigt werden, so müssen bei der Umrechnung von Function Points in Personenmonate zusätzliche Korrekturfaktoren zur Anwendung kommen. Das Function Point-Verfahren muss folglich wie jedes andere algorithmische Verfahren kalibriert werden, wenn damit brauchbare Prognosen erzielt werden sollen. Das bedeutet, dass abgeschlossene Projekte nachkalkuliert werden müssen. Aus diesen Daten müssen unternehmens- und eventuell auch projektartspezifisch die Zusammenhänge zwischen Function Points und Aufwendungen hergeleitet werden. Es gibt unterschiedliche Zählregeln für Function Points. In diesem Text werden die Regeln der International Function Point Users Group (IFPUG 1994) verwendet. In IBM (1983) und Seibt (1987) werden andere Gewichtungskriterien und nur sieben Einflussfaktoren zur Berechnung des Wertkorrekturfaktors herangezogen. Noth und Kretzschmar (1984) verwenden wie IFPUG vierzehn Einflussfaktoren, gewichten aber den Faktor 9 (technische 18

19 Komplexität) mit 0-50 statt nur mit 0-5. Symons (1988) kritisiert das Albrechtsche Zählverfahren und schlägt ein Zählverfahren vor, das statt kompletter Ein- und Ausgaben die einzelnen Datenfelder zählt (Mark II Function Points). Bestimmung des Aufwand aus den Function Points Hier ist auch zu sehen, wie schon innerhalb desselben Unternehmens signifikant unterschiedliche Umrechnungskurven resultieren können. Jones (1995) gibt Erfahrungswerte für die Umrechnung von Function Points in Codezeilen an. Die Codezeilen verstehen sich ohne Leerzeilen und ohne Kommentar. Das Function Point-Verfahren hat den großen Vorteil, dass die benötigten Eingangsgrößen sich in den frühen Phasen eines Projekts leichter bestimmen lassen als beispielsweise die Größe des erwarteten Resultats bei COCOMO. Zudem sind mit Function Points Produktivitätsmessungen möglich, die weniger leicht verfälschbar sind als Messungen auf der Grundlage der erzeugten Programmzeilen. Allerdings ist das Verfahren auf Informationssysteme zugeschnitten und daher auf andere Arten von Software (zum Beispiel Prozessautomatisierung) nur beschränkt anwendbar. Ein weiterer Nachteil ist, dass das Function Point-Maß nicht additiv ist: Die Summe der Function Points von n logisch zusammenhängenden Teilsystemen ist größer als die Anzahl der Function Points des Gesamtsystems. Dies liegt daran, dass die Schnittstellen zwischen je zwei Teilsystemen auf beiden Seiten als 19

20 Schnittstellen zu externen Datenbeständen gezählt werden, während diese Daten bei Betrachtung des Gesamtsystems als ein interner Datenbestand gezählt werden. Es ist daher nicht möglich, bei einem großen System die Function Points pro Teilsystem zu bestimmen und diese zu addieren. Sonstige Methoden Es gibt eine Reihe weiterer gängiger Methoden zur Kostenschätzung, z.b. so schätzen, dass man auf jeden Fall den Auftrag bekommt, so viel schätzen, wie der Auftraggeber zu zahlen bereit ist, Schätzung nach dem Parkinson schen Gesetz: Das Projekt kostet soviel Arbeitskapazität wie vorhanden ist, usw. Pflegekosten Aus Messungen über Entwicklungs- und Pflegekosten von Software ergeben sich die folgenden beiden Faustregeln für Pflegekosten. Faustregel 1 Das Kostenverhältnis zwischen Entwicklung und Pflege eines Software-Produkts liegt im Bereich von 30:70 bis 50:50. Je länger ein Produkt lebt und je schlechter seine Qualität ist, desto höher ist der Kostenanteil für die Pflege. Faustregel 2 Die Kosten für die Pflege eines Software-Produkts verteilen sich etwa wie folgt: 60% Verbesserungen, 20% Anpassungen und 20% Fehlerbehebung. Das untere Bild zeigt verschiedene Schätzwerte für die Anzahl Codezeilen, die ein Vollzeit-Pflege-Programmierer betreuen kann. Die Aussage 20 KDSI/FSPM (KDSI/FSP M steht für kilo delivered source instructions per full-time software person (for maintenance).) bedeutet beispielsweise, dass zur Pflege eines Programms mit Codezeilen die volle Arbeitskraft einer Person (über das ganze Jahr hinweg) erforderlich ist. 20