IT-Projektmanagement Vorlesung 3: Aufwandsschätzung WS 2024/25 PDF

BSc. WIN / MSc. DLM Management von IT-Projekten Vorlesung 3: Aufwandsschätzung WS 2024/25 Prof. Dr. Michael Fellmann Professur für Wirtschaftsinformatik,...

BSc. WIN / MSc. DLM Management von IT-Projekten Vorlesung 3: Aufwandsschätzung WS 2024/25 Prof. Dr. Michael Fellmann Professur für Wirtschaftsinformatik, insbes. Betriebliche Informationssysteme WS24/25 UNIVERSITÄT ROSTOCK | FAKULTÄT FÜR INFORMATIK UND ELEKTRONIK IT-Management: Themen WS 24/25 ITM PM Information als Ressource Organisation Organisation Führungsaufgaben Strategische, taktische, operative Ebene Vorgehensmodelle Qualitätsmanagement Termin- und Ressourcenplanung Risikomanagement Projektcontrolling Datenschutz vs. Datensicherheit Informationslogistik Qualitätsmanagement IT Sourcing Risikomanagement IT Portfoliomanagement Teambuilding Best Practises Agile Entwicklung WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 2 Fragen der letzten Vorlesung Welche Phasen hat ein Projekt? Welche Informationen enthält ein Projektantrag? Wie lässt sich ein Projekt zu Planungszwecken strukturieren? Was macht eine gute Projektstruktur aus? WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 3  Aufwandsschätzung WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 4  Glass: Software Runaways. Lessons Learned from Massive Software Project Failures, 1998] Fragen der heutigen Vorlesung Welche Ansätze zur Bestimmung des Aufwands gibt es? Welche Einflussfaktoren auf den Aufwand gibt es? Wo liegen Vorteile/Nachteile der einzelnen Verfahren? [DeMarco: Controlling Software Projects, 1982; Wofür werden die Ergebnisse der Aufwandsschätzung verwendet? DeMarco-Glass law: „Most cost estimates tend to be too low.“ WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 5 Phasenmodell IT-Projektmanagement Steuerung (Controlling) Initialisierung Planung Durchführung Abschluss Planung Technisch Wir sind hier! Wirtschaftlich Qualität WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 6  **Aufwände** sind die **Zeit und Ressourcen**, die für eine Aufgabe oder ein Projekt Aufwands“schätzung“ benötigt werden. Sie umfassen zum Beispiel die Arbeitszeit von Menschen, die Kosten für Materialien oder Software, und auch die Zeit für Planung, Entwicklung und Testen. Einfach gesagt: Es ist alles, was man aufbringen muss, um etwas fertigzustellen. „… die genäherte Bestimmung von Zahlenwerten, Größen oder Parametern durch Augenschein, Erfahrung oder statistisch-mathematische Methoden.“ (Wikipedia) Gute schätzung „… ist eine Vorhersage, bei der die Wahrscheinlichkeit, dass sie eintritt, gleichermaßen über und unter dem tatsächlichen Ergebnis liegt.“ (DeMarco: Was man nicht messen kann …, 2. Aufl., 2004) Schätzung vs. Plan (Page-Jones: Praktisches DV-Projektmanagement, 1991) WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 7 Warum entstehen falsche Schätzungen? Menschen tendieren dazu, das eigene Wissen, die eigenen Fähigkeiten und die eigene Belastbarkeit zu überschätzen Bei schwierigen Aufgaben wird dadurch die benötigte Zeit unterschätzt Fehlende Erfahrungen mit ähnlichen Projekten Wunschdenken Knappe Schätzungen oft politisch gewollt „Price-to-Win“, man plant Entwicklung zu einem Preis, von dem man vermutet, dass man damit den Kundenauftrag erhält Ein Projekt von der Firmenleitung genehmigt zu bekommen WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 8 Detailliertere Gründe für Schätzfehler (1) Kennen Sie die Situation? Sie fragen einen Programmierer-Kollegen, wie lange er für eine definierte Aufgabe benötigt und bekommen die Antwort: "Höchstens ein paar Stunden." Nach einigen Tagen fragen Sie nach und stellen fest, dass der Kollege immer noch nicht fertig ist. Schlussfolgerung: Bei Aufwandsschätzungen sind Entwickler hoffnungslos optimistische Menschen, oder? Blogger Swizec (aka "A geek with a hat") geht sogar soweit zu sagen, dass Optimismus ein Charakterzug von Entwicklern sein muss, um in der komplexen Welt der IT zurecht zu kommen. Langjährige Erfahrung habe gezeigt, dass Entwickler die Art von Leuten seien, die: in ein Projekt mit einer Spezifikation einsteigen, die sich garantiert noch ändern wird. eine Reihe unbekannter Tools hernehmen, diese auf eine unbekannte Domäne anwenden – und damit Erfolg haben. mit jedem Projekt in ein neues Universum eintauchen. jede paar Jahre all ihre Tools wechseln. WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 9 Detailliertere Gründe für Schätzfehler (2) Selbstüberzeugung: Viele Menschen tendieren dazu, das eigene Wissen zu http://it-republik.de/jaxenter/news/Warum-Entwickler-hoffnungslose-Optimisten-sind-063095.html überschätzen. Sagen beispielsweise Teilnehmer an einer Quizshow, sie seien zu 90 Prozent sicher, die Antwort zu wissen, so zeigen Studien, dass sie tatsächlich nur in 40 Prozent der Fälle richtig liegen. Fehlplanung: Besonders bei langen und schwierigen Aufgaben tendieren Menschen dazu, die Zeit, die sie dafür benötigen, zu unterschätzen. Je kleiner die zu lösende Aufgabe, desto weniger unterliegt man dieser Selbsttäuschung. Illusion der Kontrolle: Bekannt ist auch die Tendenz von Menschen so zu handeln, als hätten sie über etwas Kontrolle - auch wenn sie diese Kontrolle tatsächlich nicht haben. Wunschdenken: Weniger häufig anzutreffen, aber dennoch mitunter relevant, ist die Neigung von Menschen, die Wahrscheinlichkeit eines Ereignisses zu überschätzen, weil sie sich das Eintreten dieses Ereignisses besonders stark wünschen. WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 10 Aufwandsschätzung Einstimmung Welche Ressourcen sind in Aufwandsschätzung einzubeziehen? Was sind notwendige/ geeignete Zeitpunkt(e) für Schätzung(en)? Praktische Hinweise zur Aufwandsschätzung Schätzung mehrfach, mit unterschiedlichen Schätzverfahren durchführen einheitliche Einheiten verwenden Schätzung nachprüfbar und dokumentiert gestalten Welche Faktoren beeinflussen den Aufwand? Quantität Qualität Projektdauer Produktivität WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 11 Teufelsquadrat nach Harry Sneed Quantität Qualität (Leistungsumfang) Die gebildete Fläche beschreibt + + die Produktivität des Projekts Zielgrößen auf den Diagonalen durch eine - - Besseres Ergebnis nach außengroße Fläche Plus bei Produktmerkmalen + heißt höhere Qualität bzw. + Quantität Minus bei den Ressourcen - - heißt geringere Entwicklungsdauer bzw. Zeit Kosten (Projektdauer) (Aufwand) Kosten eine höhere Produktivität durch eine Steigerung der Qualität und Quantität bei gleichzeitiger Reduzierung von Zeit und Kosten erreicht werden kann. WS16/17 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 12 Teufelsquadrat nach Harry Sneed Quantität Qualität (Leistungsumfang) + + Die Fläche (Produktivität) eines Projekts ist invariant - - Wenn ein Projekt z. B. in weniger Zeit, aber mit mehr + + Qualität abgeschlossen werden soll, steigen die Kosten und der Leistungsumfang muss sinken - - Wenn eine Dimension (zum Beispiel die Zeit) verkürzt wird, muss eine andere (wie die Kosten oder der Leistungsumfang) angepasst werden, um die Zeit Kosten gleiche Produktivität beizubehalten. (Projektdauer) (Aufwand) WS16/17 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektrotechnik 13 Einflussfaktor Quantität Quantität = Umfang/Größe des Softwareprodukts Basisgrößen der Aufwandsschätzung a) Anzahl implementierte Programmzeilen, (LOC - Lines of Code) b) Anzahl Programmfunktionen c) Kompliziertheit (Komplexität) des Systems, abgeleitet aus den Mengen Anzahl und Zusammensetzung der Instruktionen Anzahl und Zusammensetzung der Daten Anzahl der Verzweigungsanweisungen Anzahl der Schnittstellen und –parameter Quantität ist Grundlage für Metriken sind messbare Größen, die zur Bewertung, Analyse und Verbesserung von Prozessen, Produkten oder Systemen verwendet werden. Sie helfen, Leistung, Qualität oder Fortschritt objektiv zu quantifizieren, z. B. Codezeilen, Fehlerdichte oder Durchlaufzeit. WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 14 Einflussfaktor Qualität Qualität = Produktgüte, durch Merkmale bestimmbar Produkt der Qualitätsmerkmale → Qualitätsfaktor Effizienz (Antwortzeitverhalten, Speicherauslastung) Effektivität (Zuverlässigkeit, Sicherheit, Benutzerfreundlichkeit) Wartbarkeit (Ausbaufähigkeit, Übertragbarkeit, Wartungsfreundlichkeit) warum multiplikation * , da wenn eine fällt, dann 0 -> ergebnis 0 x y -> ohne eine dieser z Faktoren keine Q.f. Qualitätsfaktor =  Effizienzi *  Effektivität j * Wartbarkeit k i =1 j =1 k =1 Beispiel: Erfahrungswerte zur Berücksichtigung der Effizienz (bzgl. Antwortzeitverhalten) Bewertung Teilfaktor eher unwichtig 0,9 mäßig 1,0 (nach H. Sneed) wichtig 1,2 maßgebend 1,5 WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 15 Einflussfaktor Projektdauer Mitarbeiter Mitarbeiter 20 identisch ? 10 nein, es ist ineffizienter -> vieler mitarbeiter in kurze Zeit als wenige mitarbeiter längere zeit 6 Monate Zeit 12 Monate Zeit Frederick P. Brooks: The Mythical Man-Month (dt.: Vom Mythos des Mann- Monats): Kritik am ‘Personen-Monat‘ als Maßstab für den Umfang des Arbeitseinsatzes; Diskussion Arbeitszeit vs. Arbeitskräfte; unteilbare Aufgaben; Belastung durch Kommunikation Brooks‘ law: “Adding manpower to a late project makes it later.“ Das Hinzufügen von mehr Mitarbeitern zu einem späten Projekt verzögert es noch mehr. WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 16 zeigt, dass es einen Punkt gibt, an dem der gewünschte Zeitrahmen so knapp wird, dass ein vernünftiger Aufwand nicht mehr ausreicht, um das Projekt in dieser Zeit erfolgreich abzuschließen. Zone des Unmöglichen (McConnell: Aufwandschätzung bei Softwareprojekten, 2006) WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 17 Einflussfaktor Produktivität Was ist Produktivität in der Softwareentwicklung? Produktivitätseinheiten Produktivitätsmerkmale und Produktivitätsfaktor (PF) x y z PF =  Hardwarei *  Software j *  Personalk i =1 j =1 k =1 Beispiel: Anwendungserfahrung der Entwickler Bewertung Teilfaktor sehr gut 0,8 mittel 1,0 (nach H. Sneed) wenig 1,2 WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 18 Boehm‘s „Konus der Ungewissheit“ (Boehm et al.: COCOMO II, 2000, S.10) WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 19 Die Schätzung basiert auf verschiedenen Faktoren und Methoden, um den Aufwand für ein Projekt zu berechnen. Aufwandschätzung beeinflussen den Aufwand zusammenhang codzeilen Metrische/Algorithmische Methoden: Korrelation zwischen Metrik und Aufwand Heuristische Methoden: Erfahrungsanalogien, für typische SW-Entwicklung sind dieselben Basisaktivitäten auszuführen, diese haben einen bestimmbaren Anteil am Aufwand WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 20 Algorithmische Methode Korrelation zwischen Metrik und Aufwand Voraussicht Einflussparameter schlecht -licher Aufwand mittel gut Metrik Produktgröße (z.B. kloc, Funktionen) Lineares Modell: Aufwand = a0 + a1 x1 +... + an xn Aufwand = a0 * a1 1 *...* an n x x Multiplikatives Modell: Analytisches Modell: Aufwand = f ( x1 ,..., xn ) WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 21 Aufwandschätzung durch Analogiemethode Erfahrungswerte aus ähnlichen Projekten oder Arbeitspaketen sind Vorlage für die Schätzung Gewinnung der notwendigen Schätzwerte daraus Besonders erfolgreich, wenn auf eigene Erfahrungen aus zuvor selbst durchgeführten Projekten zurückgriffen werden kann. Relationsmethode: Erweiterung der Analogie-Methode, zusätzlich Berücksichtigung unternehmensspezifische Faktoren wie Erfahrung und Effizienz der Entwickler Zielumgebung / Programmiersprache Organisationsstruktur … Um eine Anpassung an konkrete Gegebenheiten zu erreichen WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 22 Analogiemethode Erfahrungswerte ähnlicher Projekte als Grundlage für die Schätzung nutzen. Daten früherer Projekte Vergleich mit Zusammen- Schätzob- Zerlegen jekt ähnlichen setzen der in Teile Teilen Teilergebnisse voraus- sichtlicher Aufwand WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 23 Kennzahlenmethode z.B. Programm- größe (loc) Umfang / lines of codes Einfluss- Größe des parameter Schätzob- jektes voraus- produktspezi- Kennzahl Multiplikation sichtlicher fische Messdaten Aufwand zb wie viele lines of code geschwindigkeit ? z.B. 3h/loc WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 24 Prozentsatzmethode Die prozentuale Verteilung des Aufwands auf Projektphasen empirische Daten zu Aufwand Implemen- Inte- System- Analyse Spezif. Entwurf Erprobung gration test tierung (15%) (10%) (25%) (15%) (10%) (5%) (20%) WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 25 Top-Down/Bottom-Up Methode Top-Down Produkt/Prozess in elementare Teile/Teilaufgaben zerlegen Aufwandsschätzung für Teile/Teilaufgaben durchführen Gesamtaufwand =  Aufwand _ Teile / Teilaufgaben setzt detailliertes Design voraus Bottom-Up Produkt/Prozess in elementare Teile/Teilaufgaben zerlegen Stichprobe zu Teilen/Teilaufgaben wählen, deren Aufwand schätzen Gesamtaufwand = hochgerechneter Aufwand der Stichprobe setzt detaillierte Spezifikation und in Teilen auch Design voraus Problem: Bestimmen der repräsentativen Stichprobe WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 26 Methode Expertenschätzung und Delphi-Methode Eine repräsentative Expertengruppe muss anonym bleiben. ein Moderator repräsentative Expertengruppe Vorgehen: Analyse-/Spezifikationsdokumente verteilen Experten schätzen Aufwand Expertenschätzungen zusammen fassen Argumentation für Abweichungen sammeln Ergebnisse unter Experten verteilen wiederholter Durchlauf Ende: wenn Konsens erreicht wichtige Randbedingungen Experte keine Kritik Anonymität wahren WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 27 Fragen der heutigen Vorlesung Welche Ansätze zur Bestimmung des Aufwands gibt es? Welche Einflussfaktoren auf den auf den Aufwand gibt es? Wo liegen Vorteile/Nachteile der einzelnen Verfahren? Wofür werden die Ergebnisse der Aufwandsschätzung verwendet? WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 28 Literatur 1. Balzert, Helmut: Lehrbuch der Softwaretechnik: Softwaremanagement. Spektrum Akademischer Verlag; Auflage: 2 (2008) 2. Henrich; Andreas: Management von Softwareprojekten, Wien, Oldenbourg, 2002 3. Hughes, Bob; Cotterell, Mike: Software Project Management, London, McGraw-Hill, 2009 4. Burghardt, Manfred: Projektmanagement - Leitfaden für die Planung, Überwachung und Steuerung von Projekten, Erlangen, Publicis, 10. Aufl., 2017 (4.-9. Aufl. ist ebenfalls geeignet) 5. Wieczorrek, Hans; Mertens, Peter: Management von IT-Projekten: Von der Planung zur Realisierung. Berlin Heidelberg etc., Springer, 4. Aufl., 2011 (über Uni-Biblio-System online erreichbar) 6. DeMarco, Tom: Der Termin – Ein Roman über Projektmanagement, München, Hanser, 1998 Hinweise: - 1 und 2 sind Lehrbücher, 3 Lehrbuch in Englisch; 4 ist ein umfassendes Nachschlagewerk; 6 ist interessant und kurzweilig zu lesen.) - 1, 2 und 5 sind in der Rostocker Universitätsbibliothek vorhanden WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik Und Elektronik 29 Weiterführende Literatur Dirk Voigt: Das Projektmanagementhandbuch, 2011, http://www.projektmanagementhandbuch.de/, Weitere Weblinks zur Thema: http://www.infforum.de/themen/projektmanagement/pm-aufwandsschaetzung.htm https://jaxenter.de/warum-entwickler-hoffnungslose-optimisten-sind-486 WS24/25 UNIVERSITÄT ROSTOCK | Fakultät für Informatik und Elektronik 30  Nächste Vorlesung: Aufwandsschätzung mit CoCoMo und Function Point 31