Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung: Projektmanagement EIN PROJEKT ist eine Aufgabe mit definiertem.

Ähnliche Präsentationen


Präsentation zum Thema: "Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung: Projektmanagement EIN PROJEKT ist eine Aufgabe mit definiertem."—  Präsentation transkript:

1 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung: Projektmanagement EIN PROJEKT ist eine Aufgabe mit definiertem Anfang und Ende wobei unter Einsatz von BETRIEBSMITTEL durch einzelne voneinander abhängige TEILVORGÄNGE ein vorgegebenes AUFGABENZIEL erreicht werden soll. TECHN.LEISTUNG TERMIN AUFWAND STRUKTURIERUNG PERSONAL AUSRÖSTUNG FINANZMITTEL

2 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 2 Vorlesung: Projektmanagement Aufgabenstellung Voraussetzung ZIELSETZUNG KRISEN- PLAN PLANEN P R O J E K T A B L A U F VER- GLEICH SOLL IST aktualisieren STEUERUNG VORGABE Regelkreis ist dreischichtig: Technische Leistung, Termin, Aufwand ABWEICHUNGS- ANALYSE MAßNAHMEN PROJEKT- VERFOLGUNG BERICHTE PROJEKT- ZIEL

3 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 3 Vorlesung: Projektmanagement Mit welchem Aufwand Produktstruktur Objektstruktur Ablaufstruktur Netzplan Projektstruktur Aufwands- plan Ressourcen Womit Wann In welcher Reihenfolge Welche Tätigkeiten Welche Zwischenergebnisse Was wird geliefert Inhalte des Planungsprozesses

4 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 4 Vorlesung: Projektmanagement VORGANGS-PFEIL-NETZ NETZPLANTECHNIK DARSTELLUNGSMÖGLICHKEITEN VORGANGS-KNOTEN-NETZ VORGANG n FADFE SASE VORGANG m FADFE SASE EREIGNIS FZSZ j jj FZSZ k kk VORGANG FZ j = FA jk D SA jk FE jk SA kl EREIGNIS D kl VORGANG kl FZ k = FA kl SZ k = SE jk D Vorgangsdauer FA,FE.....frühest möglicher Anfangs-;Endzeitpunkt des Vorganges SA,SE.....spätest erlaubter Anfangs-,Endzeitpunkt des Vorganges FZ,SZ....frühester, spätester Zeitpunkt des Ereignisses

5 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 5 Vorlesung: Projektmanagement Configuration Management In großen Projekten treten üblicherweise immer wieder folgende Fragen auf: Welche Komponenten des Systems wurden für den Kunden XYZ angepaßt? Den Fehler haben wir doch schon einmal behoben! Wo finde ich die aktuelle Version des Moduls? Ab welcher Version ist der Fehler behoben? Wodurch unterscheidet sich die Version für Kuwait von der für Costa Rica? Die Antwort auf die meisten dieser oder ähnlicher Fragen gibt ein gutes Configuration Management.

6 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 6 Vorlesung: Projektmanagement Configuration Management Definition: Configuration ist die Summe von Elementen, die einer definierten Einheit angehören und untereinander in Beziehung stehen. Configuration Management ist die Regelung aller Aufgaben zur Verwaltung der im Ablauf eines Projektes anfallenden Ergebnisse bzw. die Institution, die diese Aufgabe durchführt. Ziele: Gewährleisten der Konsistenz und der Vollständigkeit der Elemente eines Systemes und zugehörigen Dokumentation über seine ganze Lebensdauer. Beherrschen der Versions-und Variantenvielfalt und des Änderungsdienstes. Erkennen der Auswirkungen von Änderungen und Korrekturen. Ermöglichen der Nachvollziehbarkeit der Systementwicklung und der Realisierungsstufen.

7 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 7 Vorlesung: Projektmanagement Warum CM ? 1 Konfigurationen bilden definitionsgemäß eine Einheit, ihre Elemente stammen aber meist nicht aus einer Hand. Zur Sicherstellung der Konsistenz ist eine Summe von Festlegungen und Maßnahmen erforderlich 2Zwischen den Elementen einer Konfiguration bestehen fast immer Beziehungen, die berücksichtigt werden müssen. Alle Beziehungen müssen definiert, festgehalten, abfragbar und überprüfbar sein 3 Bei technischen Produkten existieren oft mehrereKonfigurationen gleichzeitig, die bestimmte gemeinsame Elemente enthalten (kundenspezifische Ausführungen) Jede spezifische Konfiguration muß gezielt gebildet werden können CM !

8 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 8 Vorlesung: Projektmanagement Warum CM ? unbekannte Auswirkungen durchführbar sein CM ! 4 Konfigurationen im technischen Bereich unterliegen häufig Änderungen, die durch Änderungen in den Elementen realisiert sind. Jede Änderung muß geplant sein. Sie muß ohne unbekannte Auswirkungen durchführbar sein 5Für viele Produktentwicklungen gibt es Qualitätsanforderungen (z.B. Wartbarkeit) bzw. Qualitätssicherungsauflagen(z.B. NASA) Forderungen nach Wartbarkeit und Projektunter- lagenverwaltung sind zu erfüllen CM !

9 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 9 Vorlesung: Projektmanagement Aufgaben des CM Festlegen der Konfigurationselemente Vorgabe des Bezeichnungs-und Ablageschemas Systematische Abwicklung der Verwaltung (einbringen, ablegen, ausgeben) Änderungen von Konfigurationen und deren Elementen Überwachung von Konfigurationen (Soll-Ist-Vergleich) Zustandsverfolgung von Konfigurationen

10 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 10 Vorlesung: Projektmanagement Festlegen eines CM im Rahmen eines Projekts Die Festlegung eines CM muß vom jeweiligen Projektleiter verantwortet werden. Veranlassung: Durchführung: der Projektleiter selbst der Projektleiter und die Entwickler (kleine Projekte) (typische Projekte) eine eigene CM-Gruppe (große Projekte)

11 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 11 Vorlesung: Projektmanagement Festlegen eines CM im Rahmen eines Projekts Durchführungsschritte: Auswahl und Festlegen der Verwaltungs- einheiten (Konfigurations-Elemente) Festlegung eines Bezeichnungs- und Ablageschemas für alle Verwaltungs- einheiten Festlegen eines Verfahrens zur Behand- lung von Änderungen Regelung des CM-Zugangs durch die Nutzer Festlegen der Einsatzmittel (Tools,...) Dokumentation des CM

12 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 12 Vorlesung: Projektmanagement Auswahl und Festlegung der Konfigurations-Elemente Typische Konfigurations-Elemente sind: Produktbestandteile Produktdokumentationen Durchführungsanweisungen Relationen Planungsunterlagen Änderungsdokumente

13 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 13 Vorlesung: Projektmanagement Auswahl und Festlegung der Konfigurations-Elemente Produktbestandteile SW-Komponenten (Module, Prozeduren,....) HW-Komponenten (Baugruppen,Bausteine) Korrektur-Komponenten (Patches) Produktdokumentationen evt. Lastenheft und Verträge Spezifikationen Implementierungsbeschreibungen (techn.Dokum.,Ubersetzunslisten,Pseudocode) Anwendungsbeschreibungen, Benutzer-Handbuch Lieferbeschreibungen, Abnahmeprotokoll Durchführungsanweisungen Testanweisungen(-Prozeduren) Produktionsanweisungen(-Prozeduren) Integrationsanweisungen(-Prozeduren) Bauanweisungen (HW)

14 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 14 Vorlesung: Projektmanagement Auswahl und Festlegung der Konfigurations-Elemente Relationen Aufrufrelationen Datenaustauschbeziehungen Korrekturbeziehungen Planungsunterlagen Produktstrukturpläne Projektstrukturpläne Netzpläne Versionspläne, etc. Änderungsdukumente Fehlermeldungen Change Requests

15 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 15 Vorlesung: Projektmanagement Festlegen eines Bezeichnungs- und Ablageschemas Jedes Konfigurations-Element ist mit einer eindeutigen Bezeichnung (Identifikation) zu versehen. Ein bewährtes Bezeichnunsschema ist eine mnemotechnische Bezeichnung in der Form: nnnnn vv zz. ff kk Korrektur-Version Modul-Version Kennung Variante / Ausgabe Name / Bezeichnung Später verwendete Suchkriterien müssen in der Bezeichnung auftreten.

16 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 16 Vorlesung: Projektmanagement Festlegen eines Bezeichnungs- und Ablageschemas Für alle Konfigurations-Elemente ist ein Ablage- schema festzulegen, damit diese jederzeit wieder aufgefunden werden können. (Schlüsselfestlegungen) Ein Ablageschema ist auch bei der nicht DV gestützten Ablage in Ordnern anzuwenden. Das verwendete Ablageschema richtet sich natürlich meist nach den Einsatzmitteln z.B. Datenbanken. Typische Ablageschemata: nach Klassifikation nach Namen

17 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 17 Vorlesung: Projektmanagement Verfahren zur Behandlung von Änderungen Das Verfahren ist dann erst festgelegt, wenn alle Schritte in Art und Reihenfolge definiert sind, die bei einer Änderung durchzuführen sind. zu jedem Schritt eine Durchführungs- berechtigung festgelegt ist. Überprüfungsschritte definiert sind.

18 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 18 Vorlesung: Projektmanagement Verfahren zur Behandlung von Änderungen Typische Verfahrensschritte und Berechtigungen : SchrittBerechtigt (1) Abgabe einer MeldungIntegration, Kunde (2) Diagnostizierung der Meldung Diagnosestelle, Entwicklung (3) Enscheidung über ÄnderungChange Control Board (4) Planung der ÄnderungVertrieb/Marketing, Entw. (5) Durchführung der ÄnderungEntwicklungslabor (6) Übergabe der ÄnderungEntwicklungslabor, Integr. (7) Test der ÄnderungIntegration, Produktion (8) Integration der ÄnderungIntegration (9) Freigabe der ÄnderungVertrieb/Marketing Systemkundendienst

19 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 19 Vorlesung: Projektmanagement Verfahren zur Behandlung von Änderungen Änderungen können verursacht werden durch: Fehler Funktionserweiterungen oder Funktionsänderungen Technische Verbesserungen oder Anpassungen (bei gleichen Funktionen) Änderungen müssen ausgelöst werden durch: Fehlermeldungen (FM) Change Requests (CR)

20 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 20 Vorlesung: Projektmanagement Regelung des CM-Zugangs durch die Nutzer einbringen? wer darf Elemente entnehmen? CM-Gruppe wer erhält Auskunft? Statusänderungen Übergaberegelungen Dokumentation der Übergaberegelung und des Ablageschemas ist erforderlich ! CM

21 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 21 Vorlesung: Projektmanagement Software-Aufwandsschätzung Die Aufwandschätzung in der Software-Entwicklung ist eine Aufgabe, die heute meist nicht for- malisiert, sondern häufig im Analogieschluß und basierend auf Erfahrungswerten gelöst wird. Obwohl Fehlschätzungen um 100% und mehr vorkommen und auch eingestanden werden, sind die Schätzpersonen oft nicht bereit,eine formalisierte Vorgehensweise zu verwenden. Nur da- durch aber ist zu erreichen, daß eine Aufwandsschätzung realitätsnahe Planungswerte liefert. Durch immer höhere Benutzeranforderungen an Qualität und Funktionsvielfalt von Software steigen auch die Entwicklungskosten. Ihre richtige Abschätzung ist ein entscheidender Faktor für eine erfolgreiche Produkt- und Unternehmenspolitik.

22 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 22 Vorlesung: Projektmanagement Zielsetzung der Software- Aufwandsschätzung Systematische Datensammlung für zukünftige Aufwandsschätzungen durch Nachkalkulation bzw. durch Gegenüberstellung von geschätzten und tatsächlich angefallenen Kosten nach Projektabschluß Bereitstellung einer Basis für kontinuierliche Soll/Ist-Vergleiche zur Vermeidung von Kostenüberschreitungen Einordnung des Mitarbeiterbedarfs und -einsatzes in die Gesamtplanung des Projektes Kalkulation des Angebotes für die Erstellung verkaufsfähiger Software Bereitstellung quantitativer Entscheidungsunterlagen für die Projektsteuerung Durchführung von Wirtschaftlichkeitsuntersuchungen als Entscheidungsgrundlage für die Realisierung von Sw-Projekten

23 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 23 Vorlesung: Projektmanagement Aufwandsschätzung Untersuchungen zeigen, daß die Aufwandsschätzung zu den schwierigsten Aufgaben des Managements von Softwareprojekten gehört. Die besondere Problematik ergibt sich dadurch, daß zu einem frühen Zeitpunkt des Projektes der Aufwand geschätzt werden soll, obwohl nur wenige bzw. unsichere Informationen über aufwandbeeinflussende Faktoren zur Verfügung stehen. Zudem wird bei der Software-Produktion die Kostenschätzung durch das Fehlen eindeutiger Bezugsgrößen für den Umfang und die Qualität eines Software-Produktes erschwert. So legt man für den Umfang je nach Verfahren die Anweisungen im Programm die Programmverzweigungen die Anzahl der Ein- oder Ausgabedateien die Programmfuntionen als Basiswert zugrunde. Notwendigerweise jedoch muß eine Reihe von Faktoren berücksichtigt werden, um den zu erwartenden Aufwand bestimmen zu können.

24 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 24 Vorlesung: Projektmanagement Aufwandsermittlungsmethoden Berechnungen Messungen Schätzungen N u r s c h ä t z e n, w o n i c h t b e r e c h n e t o d e r g e m e s s e n w e r d e n k a n n !

25 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 25 Vorlesung: Projektmanagement Aufwandsschätzung Merkregeln Überschaubare Projekteinheiten schätzen Möglichst methodisch schätzen Psychologische Einflüsse berücksichtigen Schätzungen möglichst kontrollieren

26 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 26 Vorlesung: Projektmanagement Kalkulationsprobleme Auszug aus dem Bericht "Verträge zur Entwicklung von Software" des General Accounting Office in USA: 50% aller Verträge überzogen den Aufwand. 60% aller Verträge überzogen den Termin. 45% aller Verträge brachten unbrauchbare Ergebnisse. 29% aller Verträge brachten kein Ergebnis. 19% aller Verträge brachten Ergebnisse, die überarbeitet werden mußten. 3% aller Verträge brachten Ergebnisse, die modifiziert werden mußten. 2% aller Verträge brachten Ergebnisse, die so verwendet werden konnten, wie sie geliefert wurden.

27 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 27 Vorlesung: Projektmanagement Kalkulationsprobleme Es gibt eine ganze Reihe von Aspekten, die es erschweren, eine zuverlässige Kalkulation aufzustellen, so daß der Gesamt- aufwand immer nur p r o g n o s t i z i e r t werden kann: Innovation der Anwendung und der SW-Entwicklungstechnik Eine der Besonderheiten von Software ist, daß die Herstellung im Sinne der "Stückzahlproduktion" in der Regel kein Problem ist und nur einen Kopiervorgang von wenigen Minuten darstellt. Innovativ und damit schwierig ist dagegen die Entwicklung des "1.Stücks", also die ablauffähige Urversion. Die Wiederholrate der Arbeiten ist deshalb gering und man kann auch nur sehr bedingt von dem Ist-Aufwand für ein abgelaufenes Projekt auf ein neues Projekt schließen, wie das in anderen Industriezweigen möglich ist. Abhängigkeit von der Mitarbeiter-Qualifikation Es besteht eine sehr starke Wechselwirkung zwischen Mitarbeiterqualifikation und SW-Produktionstechnik Qualität der Lösung Bedarf an Resourcen Projektführung.

28 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 28 Vorlesung: Projektmanagement Kalkulationsprobleme Projekteinflußfaktoren verändern sich oder bilden sich neu Es gibt zahlreiche Einflußfaktoren auf ein SW-Projekt, von denen jeder in der Lage ist, den Gesamtaufwand stark zu verändern falls er falsch eingeschätzt, übersehen oder unvorhersehbar wirksam wird. Beispiel für einen Einfluß- faktor, der den Projektaufwand verdoppeln kann, ist folgende geänderte Prämisse: "Die durchschnittliche Response-Zeit muß von 5 auf 0,8 Sekunden gesenkt werden." Kalkulationstechniken fehlen oder werden nicht angewandt Es gibt noch keine Standard-Kalkulationstechniken, die sich allgemein durchgesetzt haben und akzeptiert werden. Es fehlt noch die konsequente Anwendung definierter Techniken und deren systematische Weiterentwicklung. Kalkulationszeitpunkte werden sehr früh gelegt Es werden zu einem sehr frühen Zeitpunkt - noch vor dem eigentlichen Projektbeginn - Aussagen über den genauen Aufwand über alle Phasen verlangt, zu dem nur wenige Informationen über das Projekt vorliegen.

29 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 29 Vorlesung: Projektmanagement Schätzmethoden Analogiemethode Relationsmethode Gewichtungsmethode Grundlage jedes Verfahrens zur Aufwandsschätzung sind die jeweils verwendeten Methoden: Bei der Analogiemethode wird der Aufwand für das zu schätzende Projekt durch Vergleich mit ähnlichen, bereits abgeschlossenen Projekten gewonnen. Sie kann früher als andere Methoden im Projektablauf benutzt werden, liefert aber nur Anhaltspunkte. Diese Verfeinerung der Analogiemethode beruht auf einer formalisierten Vorgehensweise aufgrund von Ähnlichkeits- kriterien. Hier werden objektive (z.B. Art der Eingabe) und subjektive (z.B. Komplexität der Tests) Einflußfaktoren für das Schätz- objekt bewertet und unter Zuhilfenahme mathematischer Operationen zur Ermittlung des Aufwandes verwendet.

30 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 30 Vorlesung: Projektmanagement Schätzmethoden Multiplikatormethode Prozentsatzmethode Methode der parametrischenSchätzgleichungen Sie wird auch als Aufwand-pro-Einheit-Methode bezeichnet, weil hier die Anzahl der der Einheiten des zu schätzenden Objektes, z.B. Lines of Code, mit dem festgelegten Aufwand pro Einheit multipliziert wird. Bei der Prozentsatzmethode wird, abgeleitet von früheren Projekten, die durchschnittliche prozentuale Aufwandsver- teilung auf die einzelnen Phasen als Schätzgrundlage ver- wendet. Dabei wird eine Phase detailliert geschätzt und von diesem Teilaufwand auf den zu erwartenden Gesamtaufwand geschlossen. Bei parametrischen Schätzverfahren wird mittels statistischer Analyseverfahren versucht, aus vorhandenen Projektdaten Einflußfaktoren zu gewinnen, deren wertmäßige Ausprägung in engem Zusammenhang mit dem angefallenen Aufwand steht. Aus diesen Faktoren werden die Schätzgleichungen zusammen- gestellt, wobei der zugehörige Koeffizient die Stärke des Einflusses des jeweiligen Faktors repräsentiert.

31 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 31 Vorlesung: Projektmanagement Software-Aufwandsschätzung Aufwandsermittlung heißt Feststellen des Mengengerüstes ! Aufwandsermittlung muß von gesicherten Unterlagen ausgehen ! Gesichert heißt: schriftlich formuliert verfügbar abgestimmt bestätigt Unterlagen sind: Lastenheft Pflichtenheft Spezifikationen Dokumentationen Code Projektstrukturplan Personaleinsatzplan

32 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 32 Vorlesung: Projektmanagement Teilung der Aufwandsermittlung nach Aufwandsarten Wichtige Aufwandsarten Personalaufwand Betriebsmittelaufwand Reiseaufwand Material-und Lohnaufwand Werkstattaufwand sonstiger Aufwand (z.B. Schulung etc.) K e i n e A u f w ä n d e v e r g e s s e n !

33 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 33 Vorlesung: Projektmanagement COCOMO Kurzbeschreibung des Verfahrens: Entwickelt wurde das Verfahren von Barry W. Boehm, Direktor des Softwarehauses TRW (Thompson-Ramo-Wooldridge) in den Jahren 1980/1981 Literatur: B.W.Boehm, Software Engineering Economics, 1981 Das Verfahren COCOMO (Constructive Cost Model) gehört zu den parametrischen Schätzverfahren, die den Personalaufwand für ein Softwareprojekt aus der geschätzten Anzahl der Lines of Code (LOC) ableiten. Boehm unterscheidet abhängig von der Entwicklungs- und Systemumgebung drei Typen von Software- Projekten mit entsprechenden Schätzgleichungen (z.B. für das Grundmodell) Diese Schätzgleichungen wurden mittels Regressionsanalyse aus den Daten von 63 Software-Projekten gewonnen. Organic Mode (kleine, leicht beherrschbare, in sich abgeschlossene Projekte) MM = 2,4*kLOC Semidetached Mode (Projekte mit mittlerem Innovationsgrad, mehrere Schnittstellen) MM = 3,0*kLOC Embedded Mode (größere innovative Projekte mit vielen Schnittstellen) MM = 3,6*kLOC 1,05 1,12 1,20

34 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 34 Vorlesung: Projektmanagement COCOMO Produktfaktoren Computerfaktoren Peronalfaktoren Projektfaktoren Execution time constraint (Anforderung bzgl.CPU-Bedarf) Main storage constraint (Anforderung bzgl. Speicherbedarf) Virtual machine volatility (Unsicherheit der HW/SW-Basis) Computer turnaround time (Entwicklungszykluszeit) Analyst capability Applications experience Programmer capability Virual machine experience Programming language experience Required software reliability (Zuverlässigkeit) Data base size Product complexity Der so ermittelte Grundaufwand wird dann mit 15 Aufwands- multiplikatoren (Kostentreibern) gewichtet, welche sich in 4 Gruppen unterteilen: Modern programming practices Use of software tools Required development scedule

35 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 35 Vorlesung: Projektmanagement COCOMO Jedem dieser Faktoren kann ausgehend vom Nominalwert 1 ein bestimmter Wert über oder unter eins zugewiesen werden. Der Grundaufwand, multipliziert mit dem Produkt der Aufwandsmultiplikatoren, ergibt dann den geschätzten Projektaufwand in Mannmonaten (MM). Auf der Basis des so errechneten Aufwandes ermöglicht das COCOMO-Verfahren eine Abschätzung der Projektdauer und der Anzahl der pro Phase einzusetzenden Mitarbeiter. Das COCOMO-Verfahren wird in drei Varianten eingesetzt, abhängig vom gewünschten bzw. möglichen Detaillierungs- grad der Einflußfaktoren: Basic (Grundmodell) Intermediate (Zwischenmodell) Detailed (Detailmodell) ohne Einflußfaktoren mit 15 Einflußfaktoren gewichtet wie Intermediate, jedoch Anwendung auf Modulebene

36 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 36 Vorlesung: Projektmanagement COCOMO Abschätzung der LOC Abschätzung der Kosteneinflußfaktoren Wesentliche Voraussetzung für den Einsatz von COCOMO ist die Schätzung der zu erwartenden DSI (delivered source instructions) oder LOC (Lines of code). Diese wird entsprechend der Anzahl der Objekte und Phasentätigkeiten, sowie deren Komplexität geschätzt. Dazu ist allerdings eine einigermaßen detaillierte Spezifikation (Produktstruktur) notwendig. Jedoch können auch im Falle einer noch wenig gegliederten Produktstruktur Schätzungen mittels der Grundvariante durchgeführt werden. Die Aufwandsmultiplikatoren können erst dann einbezogen werden, wenn das Entwicklungsumfeld bekannt ist. Hier ist die Benutzung einer Erfahrungsdatenbank, wo Daten abgeschlossener Projekte hinterlegt worden sind, von großem Nutzen.

37 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 37 Vorlesung: Projektmanagement COCOMO Einflußfaktoren KostentreiberVariationsbreite Produkt-Merkmale Bewertung niedrighoch Zuverlässigkeit Größe der Datenbasis Kompl. d. Produktes Computer-Merkmale CPU-Beschränkung Hauptspeicher-Beschr. instabiles HW/SW-Sys. Turnaround d. Entw. Personal-Merkmale Systemanalytiker fähig Anwendungserfahrung Programmiererfahrung Erfahrung mit BS Erfahrung mit Sprachen Projekt-Merkmale moderne Progr.methoden Tooleinsatz Entwicklungszeit

38 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 38 Vorlesung: Projektmanagement Function Point Analyse zur Ermittlung des Funktionsumfangs Aufwandschätzung aus der Sicht des Benutzers aufbauend auf Erfahrungen aus dem eigenen Umfeld nachvollziehbar und unbeeinflußt von Vorgaben gemäß Analyse-Fortschritt verfeinerbar  als Argumentationshilfe gegenüber Kunden möglich Metriken Produktivität (FP/Mh) Qualität (Fehler/FP) Wartungsumfang....  unabhängig von Design und Implementierung  international genormt und vergleichbar

39 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 39 Vorlesung: Projektmanagement Prinzip der Function Point Analyse Datenbestände Funktionen Eingaben Ausgaben unbewertete FP Einfluß- faktoren bewertete Function Points Benutzer- Anforderungen

40 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 40 Vorlesung: Projektmanagement Function Point Methode Kurzbeschreibung des Verfahrens Die Function Point Methode wurde von Allen J.Albrecht bei der IBM Corporation in White Plains, New York, im Jahr 1979 entwickelt. Literatur: Die Function Point Methode, IBM Deutschland (Hrsg) Stuttgart 1984 Die Funktionen werden bei jedem Auftreten nach den Kriterien leicht, mittel, komplex klassifiziert, indem jeder Funktion eine Zahl zwischen 3 und 15 zugeordnet wird. Für alle auftretenden Funktionen werden die so gewonnenen Zahlen addiert und ergeben als Summe die "Function Points" (brutto). Bei diesem Verfahren wird davon ausgegangen, daß der Aufwand für ein Projekt von zwei maßgeblichen Größen abhängt: von seinem Funktionsumfang von dem Einfluß der Programmierumgebung Um diese beiden Größen abschätzen zu können, wird das zu realisierende Projekt auf die vom Programm zu leistenden Funktionen hin untersucht. Darunter versteht man: Behandlung der Eingabedaten Behandlung der Ausgabedaten Behandlung der Datenbestände Abfragen

41 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 41 Vorlesung: Projektmanagement Function Point Methode Notwendige Voraussetzungen: Um die Einflüsse der Entwicklungsumgebung zu berücksichtigen, werden die Function-Points noch mit Einflußfaktoren gewichtet. 14 solcher Einflußfaktoren werden betrachtet und mit Zahlen zwischen 0 und 5 bewertet. Darunter sind z.B. Datenkommunikation Verarbeitungskomplexität Benutzungsfreundlichkeit usw. Zur der Einflußfaktorenwerte wird 65 addiert und die Gesamt- summe durch 100 dividiert, wodurch man einen Gewichtsfaktor zwischen 0.65 und 1.35 erhält. Mit diesem Gewichtsfaktor werden die Brutto-Function-Points multipliziert. Als Ergebnis erhält man die sogenannten bewerteten Function-Points. Die Beziehung zwischen dem zu erwartenden Aufwand in MM und den Function-Points wird durch einen Erfahrungsdatensatz wiedergegeben, der unternehmensspezifisch aus den Daten einer größeren Anzahl abgeschlossener Projekte zu ermitteln ist. Erfahrungsdatensatz (am besten von ähnlichen Projekten) Projekt-Pflichten-(Lasten)heft muß vorliegen hohes Maß an Schätzerfahrung der Anwender

42 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 42 Vorlesung: Projektmanagement Ablauf des Function Point Verfahrens PROJEKTANFORDERUNGEN Klassifizierung nach den Vorgaben von FUNCTION-POINT bewertete Function Points EinzelfunktionenEinflußfaktoren Function Points degree of influence FP MM A U F W A N D Analyse von abgeschlossenen Projekten mit Hilfe von FUNCTION POINT Quelle: Noth, Aufwanschätzung von DV-Projekten

43 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 43 Vorlesung: Projektmanagement Rechenmodell zur Function Point Methode EingabedatenAusgabedaten DatenbeständeReferenzdaten Abfragen Summe = _____ (E1) Summe der Einflußfaktoren = _____ (E2) Faktor Einflußbewertung =.65 + E2/100 = _____ (E3) Bewertete Function Points : E1 x E3 =_____ _____einfach x 3 = _____ _____mittel x 4 = _____ _____komplex x 6 =_____ _____einfach x 4 = _____ _____mittel x 5 = _____ _____komplex x 7 = _____ _____einfach x 7 = _____ _____mittel x 10 = _____ _____komplex x 15 = _____ _____einfach x 5 = _____ _____mittel x 7 = _____ _____komplex x 10 = _____ _____einfach x 3 = _____ _____mittel x 4 = _____ _____komplex x 6 =_____

44 Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 44 Vorlesung: Projektmanagement Function Points Maßzahl für den Leistungsumfang aus der Sicht des Benutzers – Basis-Maß für Produktivitäts- u. Qualitätsmetriken – Grundlage für Aufwandsschätzung Bewertung der Datenbestände und Schnittstellen – Datenbestände des Systems aus Benutzersicht – Eingaben/Ausgaben/Abfragen jeder Funktion Bewertung von 14 zusätzlichen Einflußfaktoren – Datenkommunikation, verteilte Verarbeitung, Transaktionsraten, Benutzerfreundlichkeit, Komplexität, Wiederverwendbarkeit,...


Herunterladen ppt "Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung: Projektmanagement EIN PROJEKT ist eine Aufgabe mit definiertem."

Ähnliche Präsentationen


Google-Anzeigen