EIN PROJEKT

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 STRUKTURIERUNG TEILVORGÄNGE TECHN.LEISTUNG ein vorgegebenes TERMIN AUFGABENZIEL AUFWAND erreicht werden soll.

2. AufgabenstellungVoraussetzung ZIELSETZUNG KRISEN- PLANEN PLAN aktualisieren SOLL ABWEICHUNGS- PROJEKT- IST VER- VERFOLGUNG ANALYSE 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- Netzplan Aufwand plan Wann Ressourcen Womit

4. VORGANGS-PFEIL-NETZ EREIGNIS SA FE SA jk jk kl VORGANG VORGANG j k jk kl FZ SZ D FZ SZ D j j jk k k kl FZ = FA FZ = FA SZ = SE j jk k kl k 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 ? 1 Konfigurationen bilden definitionsgemäß eine Einheit, ihre Elemente stammen aber meist nicht aus einer Hand. Zur Sicherstellung der Konsistenz ist eine Summe von CM ! Festlegungen und Maßnahmen erforderlich 2 Zwischen den Elementen einer Konfiguration bestehen fast immer Beziehungen, die berücksichtigt werden müssen. Alle Beziehungen müssen definiert, festgehalten, CM ! 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 CM ! werden können

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

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

38. 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 Function Point Analysezur Ermittlung des Funktionsumfangs

39. Datenbestände Prinzip der Function Point Analyse Benutzer- Anforderungen Eingaben Funktionen 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. 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. Notwendige Voraussetzungen: Erfahrungsdatensatz (am besten von ähnlichen Projekten) Projekt-Pflichten-(Lasten)heft muß vorliegen hohes Maß an Schätzerfahrung der Anwender Function Point Methode

42. Ablauf des Function Point Verfahrens Quelle: Noth, Aufwanschätzung von DV-Projekten PROJEKTANFORDERUNGEN Einzelfunktionen Einflußfaktoren Klassifizierung nach den Vorgaben von FUNCTION-POINT degree of influence Function Points 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 = .65 + E2/100 = _____ (E3) Bewertete Function Points : E1 x E3 =_____

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