Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung:...

Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss

Seite 1 Vorlesung:Projektmanagement

EIN PROJEKTist 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



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



Mit welchem Aufwand

Produktstruktur

Objektstruktur

Ablaufstruktur

Netzplan

Projektstruktur

Aufwands-plan

RessourcenWomit

Wann

In welcher

Reihenfolge

Welche Tätigkeiten

Welche Zwischenergebnisse

Was wird geliefert

Inhalte des Planungsprozesses



VORGANGS-PFEIL-NETZ

NETZPLANTECHNIKDARSTELLUNGSMÖGLICHKEITEN

VORGANGS-KNOTEN-NETZ

VORGANG

n

FA D FESA SE

VORGANG

m

FA D FESA SE

EREIGNIS

FZ SZ

j

j j FZ SZ

k

k k

VORGANG

FZ j = FA jk

D jk

jk

SA jk FE jk SA kl

EREIGNIS

D kl

VORGANGkl

FZ k = FA kl SZ k = SE jk

D............VorgangsdauerFA,FE.....frühest möglicher Anfangs-;Endzeitpunkt des VorgangesSA,SE.....spätest erlaubter Anfangs-,Endzeitpunkt des VorgangesFZ,SZ ....frühester, spätester Zeitpunkt des Ereignisses



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.



Configuration ManagementDefinition:

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.



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

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

3 Bei technischen Produkten existieren oft

mehrereKonfigurationen gleichzeitig, die

bestimmte gemeinsame Elemente enthalten

(kundenspezifische Ausführungen)

Jede spezifische Konfiguration muß gezielt gebildetwerden können

CM !

CM !

CM !



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ß ohneunbekannte Auswirkungen durchführbar sein

5 Fü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 !

CM !



Aufgaben des CMFestlegen 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



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)



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



Auswahl und Festlegung der Konfigurations-Elemente

Typische Konfigurations-Elemente sind:

Produktbestandteile

Produktdokumentationen

Durchführungsanweisungen

Relationen

Planungsunterlagen

Änderungsdokumente




ProduktbestandteileSW-Komponenten(Module, Prozeduren,....)HW-Komponenten(Baugruppen,Bausteine)Korrektur-Komponenten(Patches)

Produktdokumentationen

evt. Lastenheft und VerträgeSpezifikationenImplementierungsbeschreibungen(techn.Dokum.,Ubersetzunslisten,Pseudocode)Anwendungsbeschreibungen, Benutzer-HandbuchLieferbeschreibungen, Abnahmeprotokoll

DurchführungsanweisungenTestanweisungen(-Prozeduren)Produktionsanweisungen(-Prozeduren)Integrationsanweisungen(-Prozeduren)Bauanweisungen (HW)




Relationen

AufrufrelationenDatenaustauschbeziehungenKorrekturbeziehungen

Planungsunterlagen

Produktstrukturpläne

Projektstrukturpläne

Netzpläne

Versionspläne, etc.

Änderungsdukumente

Fehlermeldungen

Change Requests



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.



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



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.




Typische Verfahrensschritte und Berechtigungen:

Schritt Berechtigt

(1) Abgabe einer Meldung Integration, Kunde

(2) Diagnostizierung

der Meldung

Diagnosestelle,

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/MarketingSystemkundendienst




Ä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)



Regelung des CM-Zugangs durch die Nutzer

einbringen?

wer darf Elemente

entnehmen?

CM-Gruppe

wer erhält Auskunft?

Statusänderungen

Übergaberegelungen

Dokumentation der Übergaberegelung unddes Ablageschemas ist erforderlich !

CM



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.



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 Kostennach Projektabschluß

Bereitstellung einer Basis für kontinuierliche Soll/Ist-Vergleichezur 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



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 zurVerfü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 Programmverzweigungendie 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.



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 !



Aufwandsschätzung

Merkregeln

Überschaubare Projekteinheiten schätzen

Möglichst methodisch schätzen

Psychologische Einflüsse berücksichtigen

Schätzungen möglichst kontrollieren



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.


modifiziert werden mußten.


so verwendet werden konnten, wie

sie geliefert wurden.




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 Herstellungim Sinne der "Stückzahlproduktion" in der Regel kein Problem ist und nur einen Kopiervorgang von wenigen Minutendarstellt.Innovativ und damit schwierig ist dagegen die Entwicklung des"1.Stücks", also die ablauffähige Urversion.Die Wiederholrate der Arbeiten ist deshalb gering undman kann auch nur sehr bedingt von dem Ist-Aufwand fürein 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 zwischenMitarbeiterqualifikation und SW-Produktionstechnik Qualität der Lösung Bedarf an Resourcen Projektführung.




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 starkzu verändern falls er falsch eingeschätzt, übersehen oderunvorhersehbar wirksam wird. Beispiel für einen Einfluß-faktor, der den Projektaufwand verdoppeln kann, ist folgendegeänderte Prämisse: "Die durchschnittliche Response-Zeitmuß von 5 auf 0,8 Sekunden gesenkt werden."

Kalkulationstechniken fehlen oder werden nicht angewandt

Es gibt noch keine Standard-Kalkulationstechniken, die sichallgemein durchgesetzt haben und akzeptiert werden. Esfehlt noch die konsequente Anwendung definierter Technikenund deren systematische Weiterentwicklung.

Kalkulationszeitpunkte werden sehr früh gelegt

Es werden zu einem sehr frühen Zeitpunkt - noch vor demeigentlichen Projektbeginn - Aussagen über den genauenAufwand über alle Phasen verlangt, zu dem nur wenigeInformationen über das Projekt vorliegen.



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ätzendeProjekt durch Vergleich mit ähnlichen, bereits abgeschlossenenProjekten 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.



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ätzendenObjektes, z.B. Lines of Code, mit dem festgelegten Aufwandpro Einheit multipliziert wird.

Bei der Prozentsatzmethode wird, abgeleitet von früherenProjekten, die durchschnittliche prozentuale Aufwandsver-teilung auf die einzelnen Phasen als Schätzgrundlage ver-wendet. Dabei wird eine Phase detailliert geschätzt und vondiesem Teilaufwand auf den zu erwartenden Gesamtaufwandgeschlossen.

Bei parametrischen Schätzverfahren wird mittels statistischerAnalyseverfahren versucht, aus vorhandenen Projektdaten Einflußfaktoren zu gewinnen, deren wertmäßige Ausprägungin engem Zusammenhang mit dem angefallenen Aufwand steht.Aus diesen Faktoren werden die Schätzgleichungen zusammen-gestellt, wobei der zugehörige Koeffizient die Stärke desEinflusses des jeweiligen Faktors repräsentiert.



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



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 !



COCOMO

Kurzbeschreibung des Verfahrens:

Entwickelt wurde das Verfahren von Barry W. Boehm,Direktor des Softwarehauses TRW (Thompson-Ramo-Wooldridge)in den Jahren 1980/1981Literatur: B.W.Boehm, Software Engineering Economics, 1981

Das Verfahren COCOMO (Constructive Cost Model) gehört zu den parametrischen Schätzverfahren, die den Personalaufwandfür ein Softwareprojekt aus der geschätzten Anzahl der Linesof Code (LOC) ableiten. Boehm unterscheidet abhängig von derEntwicklungs- und Systemumgebung drei Typen von Software-Projekten mit entsprechenden Schätzgleichungen(z.B. für das Grundmodell)

Diese Schätzgleichungen wurden mittels Regressionsanalyseaus 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



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 capabilityApplications experienceProgrammer capabilityVirual machine experienceProgramming language experience

Required software reliability (Zuverlässigkeit)Data base sizeProduct complexity

Der so ermittelte Grundaufwand wird dann mit 15 Aufwands-multiplikatoren (Kostentreibern) gewichtet, welche sichin 4 Gruppen unterteilen:

Modern programming practicesUse of software toolsRequired development scedule



COCOMO

Jedem dieser Faktoren kann ausgehend vom Nominalwert 1ein bestimmter Wert über oder unter eins zugewiesen werden.Der Grundaufwand, multipliziert mit dem Produkt der Aufwandsmultiplikatoren, ergibt dann den geschätztenProjektaufwand in Mannmonaten (MM).Auf der Basis des so errechneten Aufwandes ermöglicht dasCOCOMO-Verfahren eine Abschätzung der Projektdauerund 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 Anwendungauf Modulebene



COCOMO

Abschätzung der LOC

Abschätzung der Kosteneinflußfaktoren

Wesentliche Voraussetzung für den Einsatz von COCOMOist die Schätzung der zu erwartenden DSI (delivered sourceinstructions) oder LOC (Lines of code). Diese wird entsprechendder Anzahl der Objekte und Phasentätigkeiten, sowie derenKomplexität geschätzt. Dazu ist allerdings eine einigermaßendetaillierte Spezifikation (Produktstruktur) notwendig. Jedochkönnen auch im Falle einer noch wenig gegliedertenProduktstruktur Schätzungen mittels der Grundvariantedurchgeführt werden.

Die Aufwandsmultiplikatoren können erst dann einbezogenwerden, wenn das Entwicklungsumfeld bekannt ist. Hier ist die Benutzung einer Erfahrungsdatenbank, wo Datenabgeschlossener Projekte hinterlegt worden sind, vongroßem Nutzen.



COCOMO Einflußfaktoren

Kostentreiber Variationsbreite

Produkt-Merkmale

Bewertungniedrig hoch

5.43

5.10

10.4

2.54

.75 .94 .70

1.01.0 .87 .87

1.461.291.421.211.14

1.241.241.24

1.401.161.65

1.661.561.301.15

.71 .82 .70 .90 .95

.82 .831.10

1.871.232.35

1.661.561.491.32

2.061.572.031.341.20

1.511.491.13

ZuverlässigkeitGröße der DatenbasisKompl. d. Produktes

Computer-MerkmaleCPU-BeschränkungHauptspeicher-Beschr.instabiles HW/SW-Sys.Turnaround d. Entw.

Personal-MerkmaleSystemanalytiker fähigAnwendungserfahrungProgrammiererfahrungErfahrung mit BSErfahrung mit Sprachen

Projekt-Merkmalemoderne Progr.methodenTooleinsatzEntwicklungszeit



Function Point Analysezur 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



Prinzip der Function Point Analyse

Datenbestände Funktionen

Eingaben

Ausgaben

unbewertete FP

Einfluß-faktoren

bewertete Function Points

Benutzer-Anforderungen



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 Kriterienleicht, mittel, komplex klassifiziert, indem jeder Funktion eineZahl zwischen 3 und 15 zugeordnet wird. Für alle auftretendenFunktionen werden die so gewonnenen Zahlen addiert und ergeben als Summe die "Function Points" (brutto).

Bei diesem Verfahren wird davon ausgegangen, daß derAufwand für ein Projekt von zwei maßgeblichen Größen abhängt:

von seinem Funktionsumfangvon dem Einfluß der Programmierumgebung

Um diese beiden Größen abschätzen zu können, wird das zu realisierende Projekt auf die vom Programm zu leistendenFunktionen hin untersucht. Darunter versteht man:

Behandlung der EingabedatenBehandlung der AusgabedatenBehandlung der DatenbeständeAbfragen



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 Zahlenzwischen 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 Gewichtsfaktorzwischen 0.65 und 1.35 erhält.Mit diesem Gewichtsfaktor werden die Brutto-Function-Pointsmultipliziert. Als Ergebnis erhält man die sogenanntenbewerteten Function-Points.

Die Beziehung zwischen dem zu erwartenden Aufwand in MMund den Function-Points wird durch einen Erfahrungsdatensatzwiedergegeben, der unternehmensspezifisch aus den Dateneiner größeren Anzahl abgeschlossener Projekte zu ermitteln ist.

Erfahrungsdatensatz (am besten von ähnlichen Projekten)Projekt-Pflichten-(Lasten)heft muß vorliegenhohes Maß an Schätzerfahrung der Anwender



Ablauf des Function Point Verfahrens

PROJEKTANFORDERUNGEN

Klassifizierung nach den Vorgaben vonFUNCTION-POINT

bewertete Function Points

Einzelfunktionen Einflußfaktoren

Function Points degree of influence

FP

MM

AUFWAND

Analyse von abgeschlossenen Projektenmit Hilfe von

FUNCTION POINT

Quelle: Noth, Aufwanschätzung von DV-Projekten



Rechenmodell zur Function Point Methode

Eingabedaten Ausgabedaten

Datenbestände Referenzdaten

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 3 = __________mittel x 4 = __________komplex x 6 =_____



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

Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung:...

Documents

Transcript of Institut für techn. Informatik Vorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss Seite 1 Vorlesung:...