EIN PROJEKT ist eine Aufgabe mit definiertem Anfang und Ende PERSONAL

Präsentation zum Thema: "EIN PROJEKT ist eine Aufgabe mit definiertem Anfang und Ende PERSONAL"—  Präsentation transkript:

1 EIN PROJEKT ist eine Aufgabe mit definiertem Anfang und Ende PERSONAL
wobei unter Einsatz von AUSRÖSTUNG BETRIEBSMITTEL FINANZMITTEL durch einzelne voneinander abhängige TEILVORGÄNGE STRUKTURIERUNG ein vorgegebenes TECHN.LEISTUNG AUFGABENZIEL TERMIN erreicht werden soll. AUFWAND

2 Aufgabenstellung Voraussetzung
ZIELSETZUNG KRISEN- PLANEN PLAN aktualisieren SOLL ABWEICHUNGS- PROJEKT- IST VER- ANALYSE VERFOLGUNG GLEICH BERICHTE MAßNAHMEN STEUERUNG P R O J E K T A B L A U F VORGABE PROJEKT- ZIEL Regelkreis ist dreischichtig: Technische Leistung, Termin, Aufwand

3 Inhalte des Planungsprozesses
Produktstruktur Was wird geliefert Objektstruktur Welche Zwischenergebnisse Projektstruktur Welche Tätigkeiten Ablaufstruktur In welcher Reihenfolge Mit welchem Aufwands- Aufwand Netzplan plan Wann Womit Ressourcen

4 VORGANGS-KNOTEN-NETZ
VORGANGS-PFEIL-NETZ EREIGNIS SA jk FE jk SA kl VORGANG VORGANG j k jk kl FZ j SZ j D jk FZ k SZ k D kl FZ j = FA jk FZ k = FA kl SZ k = SE jk VORGANGS-KNOTEN-NETZ n m EREIGNIS VORGANG VORGANG FA D FE FA D FE SA SE SA SE 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 NETZPLANTECHNIK DARSTELLUNGSMÖGLICHKEITEN

5 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 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 Warum CM ? CM ! CM ! 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 CM ! 2 Zwischen 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 CM ! 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 Warum CM ? CM ! 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 CM ! unbekannte Auswirkungen durchführbar sein CM ! 5 Für viele Produktentwicklungen gibt es Qualitätsanforderungen (z.B. Wartbarkeit) bzw. Qualitätssicherungsauflagen(z.B. NASA) Forderungen nach Wartbarkeit und Projektunter- CM ! lagenverwaltung sind zu erfüllen

9 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 Festlegen eines CM im Rahmen eines Projekts
Veranlassung: Die Festlegung eines CM muß vom jeweiligen Projektleiter verantwortet werden. Durchführung: der Projektleiter selbst (kleine Projekte) der Projektleiter und die Entwickler (typische Projekte) eine eigene CM-Gruppe (große Projekte)

11 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 Auswahl und Festlegung der Konfigurations-Elemente
Typische Konfigurations-Elemente sind: Produktbestandteile Produktdokumentationen Durchführungsanweisungen Relationen Planungsunterlagen Änderungsdokumente

13 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 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 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 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 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 Verfahren zur Behandlung von Änderungen
Typische Verfahrensschritte und Berechtigungen: Schritt Berechtigt (1) Abgabe einer Meldung Integration, Kunde (2) Diagnostizierung Diagnosestelle, der Meldung Entwicklung (3) Enscheidung über Änderung Change Control Board (4) Planung der Änderung Vertrieb/Marketing, Entw. (5) Durchführung der Änderung Entwicklungslabor (6) Übergabe der Änderung Entwicklungslabor, Integr. (7) Test der Änderung Integration, Produktion (8) Integration der Änderung Integration (9) Freigabe der Änderung Vertrieb/Marketing Systemkundendienst

19 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 Regelung des CM-Zugangs durch die Nutzer
Statusänderungen Übergaberegelungen einbringen? CM-Gruppe CM wer darf Elemente entnehmen? wer erhält Auskunft? Dokumentation der Übergaberegelung und des Ablageschemas ist erforderlich !

21 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 Zielsetzung der Software-Aufwandsschätzung
Durchführung von Wirtschaftlichkeitsuntersuchungen als Entscheidungsgrundlage für die Realisierung von Sw-Projekten Bereitstellung quantitativer Entscheidungsunterlagen für die Projektsteuerung Kalkulation des Angebotes für die Erstellung verkaufsfähiger Software Einordnung des Mitarbeiterbedarfs und -einsatzes in die Gesamtplanung des Projektes Bereitstellung einer Basis für kontinuierliche Soll/Ist-Vergleiche zur Vermeidung von Kostenüberschreitungen Systematische Datensammlung für zukünftige Aufwandsschätzungen durch Nachkalkulation bzw. durch Gegenüberstellung von geschätzten und tatsächlich angefallenen Kosten nach Projektabschluß

23 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 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 Aufwandsschätzung Merkregeln Überschaubare Projekteinheiten schätzen
Möglichst methodisch schätzen Psychologische Einflüsse berücksichtigen Schätzungen möglichst kontrollieren

26 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 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 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 Schätzmethoden Grundlage jedes Verfahrens zur Aufwandsschätzung sind die jeweils verwendeten Methoden: Analogiemethode 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. Relationsmethode Diese Verfeinerung der Analogiemethode beruht auf einer formalisierten Vorgehensweise aufgrund von Ähnlichkeits- kriterien. Gewichtungsmethode 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 Schätzmethoden Multiplikatormethode
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. Prozentsatzmethode 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. Methode der parametrischenSchätzgleichungen 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 Software-Aufwandsschätzung
Aufwandsermittlung heißt Feststellen des Mengengerüstes ! Aufwandsermittlung muß von gesicherten Unterlagen ausgehen ! Gesichert heißt: Unterlagen sind: schriftlich formuliert Lastenheft verfügbar Pflichtenheft abgestimmt Spezifikationen bestätigt Dokumentationen Code Projektstrukturplan Personaleinsatzplan

32 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 COCOMO 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 Kurzbeschreibung des Verfahrens: 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) Organic Mode (kleine, leicht beherrschbare, in sich abgeschlossene Projekte) MM = 2,4*kLOC 1,05 Semidetached Mode (Projekte mit mittlerem Innovationsgrad, mehrere Schnittstellen) MM = 3,0*kLOC 1,12 Embedded Mode (größere innovative Projekte mit vielen Schnittstellen) MM = 3,6*kLOC 1,20 Diese Schätzgleichungen wurden mittels Regressionsanalyse aus den Daten von 63 Software-Projekten gewonnen.

34 COCOMO Der so ermittelte Grundaufwand wird dann mit 15 Aufwands-
multiplikatoren (Kostentreibern) gewichtet, welche sich in 4 Gruppen unterteilen: Produktfaktoren Required software reliability (Zuverlässigkeit) Data base size Product complexity Computerfaktoren 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) Peronalfaktoren Analyst capability Applications experience Programmer capability Virual machine experience Programming language experience Projektfaktoren Modern programming practices Use of software tools Required development scedule

35 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 ohne Einflußfaktoren (Grundmodell) Intermediate mit 15 Einflußfaktoren gewichtet (Zwischenmodell) Detailed wie Intermediate, jedoch Anwendung (Detailmodell) auf Modulebene

36 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. Abschätzung der Kosteneinflußfaktoren 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 COCOMO Einflußfaktoren
Kostentreiber Bewertung Variationsbreite niedrig hoch Produkt-Merkmale Zuverlässigkeit .75 1.40 1.87 Größe der Datenbasis .94 1.16 1.23 5.43 Kompl. d. Produktes .70 1.65 2.35 Computer-Merkmale CPU-Beschränkung 1.0 1.66 1.66 Hauptspeicher-Beschr. 1.0 1.56 1.56 5.10 instabiles HW/SW-Sys. .87 1.30 1.49 Turnaround d. Entw. .87 1.15 1.32 Personal-Merkmale Systemanalytiker fähig 1.46 .71 2.06 Anwendungserfahrung 1.29 .82 1.57 Programmiererfahrung 1.42 .70 2.03 10.4 Erfahrung mit BS 1.21 .90 1.34 Erfahrung mit Sprachen 1.14 .95 1.20 Projekt-Merkmale moderne Progr.methoden 1.24 .82 1.51 Tooleinsatz 1.24 .83 1.49 2.54 Entwicklungszeit 1.24 1.10 1.13

38 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 Prinzip der Function Point Analyse
Benutzer- Anforderungen Eingaben Funktionen Datenbestände unbewertete FP Einfluß- faktoren Ausgaben bewertete Function Points

40 Function Point Methode
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 Kurzbeschreibung des Verfahrens 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 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).

41 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 Ablauf des Function Point Verfahrens
Quelle: Noth, Aufwanschätzung von DV-Projekten PROJEKTANFORDERUNGEN Einzelfunktionen Einflußfaktoren Klassifizierung nach den Vorgaben von FUNCTION-POINT Function Points degree of influence bewertete Function Points A FP U F W A N D MM Analyse von abgeschlossenen Projekten mit Hilfe von FUNCTION POINT

43 Rechenmodell zur Function Point Methode
Eingabedaten Ausgabedaten _____einfach x 3 = _____ _____einfach x 4 = _____ _____mittel x 4 = _____ _____mittel x 5 = _____ _____komplex x 6 =_____ _____komplex x 7 = _____ Datenbestände Referenzdaten _____einfach x 7 = _____ _____einfach x 5 = _____ _____mittel x 10 = _____ _____mittel x 7 = _____ _____komplex x 15 = _____ _____komplex x 10 = _____ Abfragen _____einfach x 3 = _____ Summe = _____ (E1) _____mittel x 4 = _____ _____komplex x 6 =_____ Summe der Einflußfaktoren = _____ (E2) Faktor Einflußbewertung = E2/100 = _____ (E3) Bewertete Function Points : E1 x E3 =_____

44 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, ...