Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.

Slides:



Advertisements
Ähnliche Präsentationen
Das V - Modell - Überblick
Advertisements

V - Modell Anwendung auf große Projekte
Phasen und ihre Workflows
Vorgehensmodell - Wasserfallmodell
Informatik II: Algorithmen und Datenstrukturen SS 2013
Eingebettete Systeme Qualität und Produktivität
Management großer Softwareprojekte
Modellbasierte Software-Entwicklung eingebetteter Systeme
Modellbasierte Software-Entwicklung eingebetteter Systeme
Prof. Dr. Holger Schlingloff
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Eingebettete Systeme Qualität und Produktivität
Qualitätssicherung von Software (SWQS)
Management großer Softwareprojekte
Forschungsstrategien Johannes Gutenberg Universität Mainz
Management großer Softwareprojekte
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Management großer Softwareprojekte
Management großer Softwareprojekte - Auswertung der Fragebögen - Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.
Management großer Softwareprojekte
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur.
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Management großer Softwareprojekte
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
Das V - Modell - Überblick
Rational Unified Process (RUP) - Definitionen
Professionelles Projektmanagement in der Praxis, © 2006 Dr. Harald Wehnes Universität Würzburg, FB Informatik, Prof. Dr. P.Tran-Gia 1 Professionelles Projektmanagement.
Wie Projekte verlaufen… und worin ihr Problem liegt
Einführung in die Metaanalyse
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Organisationsanalyse
Empirische Softwaretechnik
Projektmanagement.
Best of Consulting Project Excellence 2013 Klient über das Projekt.
„SAFE“ Detaillierung und Umsetzung des Referenzmodells
Best of Consulting Project Excellence 2013 Berater über das Projekt.
Modellbasierte Software-Entwicklung eingebetteter Systeme
Anleitung Top-Down Planung
Institut für Kartographie und Geoinformation Prof. Dr. Lutz Plümer Geoinformation II 6. Sem. Vorlesung Mai 2000 Konstruktion des Voronoi-Diagramms.
Agile Softwareentwicklung
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Professionelles Projektmanagement in der Praxis
Institut für Kartographie und Geoinformation Prof. Dr. Lutz Plümer Diskrete Mathematik II Vorlesung Voronoi-Diagramme.
Projektantrag für die Umsetzung von ITIL
Projektantrag für die Umsetzung von ISO :2011 Untertitel oder Sprecher.
Das sind wir! Unsere Schule:Name der Schule Unser Team:Name 1 Name 2 Name 3 Name 4 Name 5 Unsere Betreuer:Name des betreuenden Lehrers.
Bevölkerung in der 3. Welt
Pointer. Grundsätzliches: Im Arbeitsspeicher werden Daten gespeichert. Um auf die Daten eindeutig zugreifen zu können, werden diesen Daten Adressen zugeordnet.
Abstraktion Reflexion Konkretion Theorie Abstrakte Ebene Phänomen Konkrete Ebene Maturaarbeit.
Kundenprojekt Web-Technologien (SoSe 16) Marko Harasic Freie Universität Berlin Institut für Informatik Netzbasierte Informationssysteme
Teilchenbewegung im Alltag NaWi, Klasse 8. Teilchenbewegung im Alltag Ziele der Stunde: 1.Ich kann Phänomene aus dem Alltag mit der Teilchenbewegung in.
Prototyping Berlin · Seite 2 Prototyping: Was und wozu Die Zukunft ausprobieren und erfahren durch „Machen“. Einen Mikrokosmos kreieren.
 Präsentation transkript:

Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik FIRST

H. Schlingloff, Management großer Softwareprojekte2 Hausaufgabe von vorletzter Woche Beschreiben Sie Organisations- und Ablaufstruktur eines SW- Projektes, bei dem Sie mitgearbeitet haben! 3.2 Ablauforganisation

H. Schlingloff, Management großer Softwareprojekte3 Vorbereitendes Experiment Für die folgende Aufgabe haben Sie 10 Sekunden Zeit: Schätzen Sie, wie viele Geldmünzen sich in diesem Raum befinden! Notieren Sie bitte Ihr Ergebnis als (a) Für die folgende Aufgabe haben Sie 60 Sekunden Zeit: Schätzen Sie, wie viele Geldmünzen sich in diesem Raum befinden! Notieren Sie bitte Ihr Ergebnis als (b) Bilden Sie die Differenz (c) = (a) – (b)

H. Schlingloff, Management großer Softwareprojekte4 Ergebnisse

H. Schlingloff, Management großer Softwareprojekte5 Ergebnisse Bei höherem Schätzaufwand wird das Ergebnis genauer (genau: 427) Der Mittelwert mehrerer Schätzungen ist oft genauer als einzelne Schätzungen Hemmschwelle gegen nochmalige Schätzung des selben Gegenstands

H. Schlingloff, Management großer Softwareprojekte6 4. Aufwandsschätzung Warum ist es notwendig, zu schätzen? Grundlage für Angebot und Auftrag Grundlage für Zeit- und Kostenplanung Entscheidungsgrundlage für Vorgehen Problem: Wie kommt man zu verlässlichen Werten? frühzeitig (vor Beginn!) und akkurat (Limits!) Schätzung zu hoch kein Projekt Schätzung zu gering finanzieller Engpass (Ruin) 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte7 Problematik beim Schätzen extrem viele Parameter Personal, Projektkomplexität, Dokumentation, Methoden- und Werkzeugeinsatz, Organisationsform, Motivation, … prinzipielle Ungenauigkeit Schätzung beeinflusst den Prozess (Planung und Durchführung) Ergebnisse nicht verifizierbar keine separat messbaren Größen: schlechtes Management kann jede noch so gute Schätzung ad absurdum führen nur bedingt übertragbar Einmaligkeit der Projektbedingungen 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte8 Henne/Ei Problem des Schätzens Schätzung beruht auf einer festen Anforderungsdefinition Durch das Schätzergebnis werden die Anforderungen beeinflusst detaillierte Anforderungsanalyse kann bereits hohe Vorlaufkosten verursachen in der Praxis oft Kosten statt Anforderungen fix 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte9 Dilemma des PM beim Schätzen Projektbudget wird überschritten Firmenleitung hat Projekt geschätzt schlechtes Projektmanagement PM hat geschätzt schlechte Schätzung Projektbudget wird eingehalten Firmenleitung hat Projekt geschätzt gute Schätzung, PM wie erwartet PM hat geschätzt zu großzügig geschätzt 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte10 Negativbeispiel: Nicht-Schätzung 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte11 Softwarebeispiel Schätzen Sie bitte die Zeit d (in Minuten), die ein durchschnittlicher Programmierer braucht, um folgendes Programm zu schreiben: Aus einer Textdatei sollen alle Dubletten (d.h., doppelt vorkommende Wörter) gelöscht werden Schätzen Sie bitte die Zeit e (in Minuten), die Sie selber für dieses Programm brauchen! Schreiben Sie bitte das Programm jetzt (Zeit läuft!) Korrigieren Sie ihre ursprüngliche Schätzung! 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte12 Softwarebeispiel - Fortsetzung Wie lange brauchen Sie jetzt noch, um das einzutippen, zu debuggen und zu testen? Schätzen Sie einen Faktor f Wie stabil ist Ihr Programm (z.B. Parallelzugriff)? Wo gibt es Effizienzverbesserungen? Korrigieren Sie Ihre vorherige Schätzung unter der Annahme, dass das Programm nur ein paar Mal gebraucht wird, um einige Dateien manuell aufzubessern unter der Annahme, dass das Programm den Kern eines großen Informationssystems bildet, und ständig mit sehr großen Dateien aufgerufen wird 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte13 Ergebnisse Durchschnittszeit d, eigene Zeit e, tatsächliche Zeit t d < e : 14 d = e : 4 d > e : 12 Faktor f, Qualität f_ und f _ : f : 4, 3.5, 3, 1.3 f_ : 1, 2.5, 0.7, 1.5, f _ : 10, 12, 50, 20, 6, t * f < e : 2 t * f = e : 9 t * f > e : Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte14 Folgerungen Gefahr der Selbstüberschätzung (bzw. Überschätzung der eigenen Gruppe) Unterspezifierte Aufgabenstellung ergibt ungenaue Schätzung; Qualitätsfaktor nicht vernachlässigbar ein Programm zum Laufen zu bringen dauert etwa dreimal so lange, wie das bloße Aufschreiben 4. Aufwandschätzung

H. Schlingloff, Management großer Softwareprojekte15 Grundregeln beim Schätzen 1. Grundregel: Müll rein – Müll raus präzise Anforderungen! 2. Grundregel: Je ferner die Zukunft, desto schwieriger sind die Schätzungen kontinuierliche Neuschätzungen! 3. Grundregel: große Blöcke sind schwieriger zu schätzen als kleine, abstrakte schwieriger als konkrete Granularität, Konkretisierung 4. Grundregel: Schätzungen sind keine Weissagungen, d. h. keine verbindlichen Voraussagen (selbsterfüllende Prophezeiung) Toleranzspielraum! 4. Aufwandschätzung