institut für techn. informatik vorstand: o.univ.-prof. dr.-ing. r. weiss seite 1 vorlesung:...
Post on 06-Apr-2015
106 Views
Preview:
TRANSCRIPT
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
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 3 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 4 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: 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.
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 6 Vorlesung:Projektmanagement
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.
Institut für techn. InformatikVorstand: 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
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 !
Institut für techn. InformatikVorstand: 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ß 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 !
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 9 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: 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)
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 13 Vorlesung:Projektmanagement
Auswahl und Festlegung der Konfigurations-Elemente
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)
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 14 Vorlesung:Projektmanagement
Auswahl und Festlegung der Konfigurations-Elemente
Relationen
AufrufrelationenDatenaustauschbeziehungenKorrekturbeziehungen
Planungsunterlagen
Produktstrukturpläne
Projektstrukturpläne
Netzpläne
Versionspläne, etc.
Änderungsdukumente
Fehlermeldungen
Change Requests
Institut für techn. InformatikVorstand: 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.
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: 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.
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 18 Vorlesung:Projektmanagement
Verfahren zur Behandlung von Änderungen
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
Institut für techn. InformatikVorstand: 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)
Institut für techn. InformatikVorstand: 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 unddes Ablageschemas ist erforderlich !
CM
Institut für techn. InformatikVorstand: 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.
Institut für techn. InformatikVorstand: 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 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
Institut für techn. InformatikVorstand: 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 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.
Institut für techn. InformatikVorstand: 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 !
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: 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.
Institut für techn. InformatikVorstand: 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 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.
Institut für techn. InformatikVorstand: 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 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.
Institut für techn. InformatikVorstand: 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ä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.
Institut für techn. InformatikVorstand: 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ä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.
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: 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 !
Institut für techn. InformatikVorstand: 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/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
Institut für techn. InformatikVorstand: 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 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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 35 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: 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 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.
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 37 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 38 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: 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
Institut für techn. InformatikVorstand: 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 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
Institut für techn. InformatikVorstand: 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 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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 42 Vorlesung:Projektmanagement
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
Institut für techn. InformatikVorstand: o.Univ.-Prof. Dr.-Ing. R. Weiss
Seite 43 Vorlesung:Projektmanagement
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 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 =_____
Institut für techn. InformatikVorstand: 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, ...
top related