Software Engineering 1

Größe: px

Ab Seite anzeigen:

Download "Software Engineering 1"

Oldwig Koch
vor 8 Jahren
Abrufe

1 Software Engineering 1 Vorlesung W November Projektmanagement, Teammanagement Mario Bernhart se1@inso.tuwien.ac.at INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien

2 Projektmanagement in SE Projekt planen und kontrollieren PM Voraussetzungen schaffen und Softwareentwicklungsum-gebung (SEU) bereitstellen Plandaten Istdaten SEU Plandaten Istdaten SEU SEU Plandaten Istdaten Plandaten Istdaten SEU QS- Anforderungen vorgeben SE Produkt entwickeln Produktstruktur planen QS- Ergebnis Produkte prüfen QS-Anforderung Rechte Produkt Produkte/ Rechte verwalten QS Konfigurationsstruktur KM Produkt

Plandaten Istdaten Plandaten Istdaten SEU QS- Anforderungen vorgeben SE Produkt entwickeln Produktstruktur

3 Einflussfaktor Mensch Unternehmenskultur und Projektkultur Mitarbeiter Die Persönlichkeit: Jeder Mensch ist einzigartig. Fähigkeiten: Jeder Entwickler hat unterschiedliche Stärken und Schwächen. Der kulturelle Hintergrund: Kulturell bedingte Umgangsformen. Ziele, Wünsche, Erwartungen: Bedeutung persönlicher Ziele.

Fähigkeiten: Jeder Entwickler hat unterschiedliche Stärken und Schwächen.

4 Phasen der Projektvorbereitung Machbarkeitsstudie Machbarkeit wird anhand zentraler Anforderungen evaluiert. Aufwandsschätzung Aufwand wird in Hinsicht auf Vertrag geschätzt. Vertrag Formale Vereinbarung über Leistung und Preis. Projektplan Plan zur Durchführung des vereinbarten Projekts.

Aufwandsschätzung Aufwand wird in Hinsicht auf Vertrag geschätzt.

5 Schätzung von Aufwand und Terminen Die möglichst genaue Schätzung eines Aufwandes für ein Projekt ist ein entscheidender Faktor. Aufwandschätzung zu gering hoher Zeitdruck für die Mitarbeiter höhere Kosten als Einnahmen Aufwandschätzung zu hoch veranschlagte Kosten steigen (nicht konkurrenzfähig)

Aufwandschätzung zu gering hoher Zeitdruck für die Mitarbeiter höhere

6 Möglichkeiten der Aufwandsschätzung Gar nicht Intuition Kundenvorgaben Release-Datum Erfahrungswerte (Geschätzt, Gemessen) Formales Verfahren Eine gute Aufwandschätzung ist die Grundlage für jegliche Zeitplanung und Kostenschätzung für ein Projekt.

Gemessen) Formales Verfahren Eine gute Aufwandschätzung ist

7 Probleme bei der Aufwandsschätzung unsicher und unvollständige Anforderungen bzw. Informationen geringe Erfahrungswerte unzuverlässige, weil unerprobte, Methoden im Unternehmen unvorhersehbare Einflüsse schwer einzuschätzendes Engagement seitens des Kunden wirtschaftliche Aspekte zu hohe Schätzung mindert Verkaufswahrscheinlichkeit zu geringe Schätzung mindert Gewinn unternehmensinterne Ressourcenknappheit

unvorhersehbare Einflüsse schwer einzuschätzendes Engagement seitens des Kunden wirtschaftliche

8 Aufwandsschätzung Formale Methoden Mögliche Ansätze zur Berechnung: Analogiemethode (Erfahrungen aus vergangenen/ähnlichen Projekten) Multiplikatormethode (Aufteilung in vergleichbare Einzelteile; Schätzung eines solchen Einzelteils) Gewichtungsmethode (Identifikation von Cost-Driver ; Berechnung mittels Formeln (zb COCOMO)) Prozentsatzmethode (Hochrechnung aus einer detaillierten Schätzung einer (evtl bereits vergangenen) Teilphase) Achtung nie Aufwände für Nebentätigkeiten wie Projektmanagement oder Qualitätssicherung vergessen!

(Identifikation von Cost-Driver ; Berechnung mittels Formeln (zb COCOMO)) Prozentsatzmethode (Hochrechnung aus einer detaillierten

9 Vertrag Sofern die positive Entscheidung zur Umsetzung eines Projektes gefallen ist, gilt es sofort getroffene Annahmen vertraglich zu fixieren. Pflichtenheft Leistung Dokumentation Abnahme Pflichten des Kunden Gewährleistung bei Problemen Pflege und Wartung Vertragsbeendigung Ansprechpartner, Kompetenzen, Eskalationsprozeduren Vergütung

Pflichtenheft Leistung Dokumentation Abnahme Pflichten des Kunden Gewährleistung bei

10 Phasenpläne Grober Zeitablauf des Projektes. Geschätzte Termine aller Meilensteine. Ungefähre Anzahl der Iterationen. Geschätzte Dauer der jeweiligen Iteration. Verfügbarkeit von Mitarbeitern und Ressourcen. Keine Details der Iterationen.

11 Phasenplan Beispiel

12 Iterationspläne Abfolge der konkreten Aktivitäten aktuelle Iteration. folgende Iteration. Zuteilung von Aktivitäten zu Personen. Zuteilung von Ressourcen. Unterschiedliche Sichten -> unterschiedliche Darstellungsweisen: Zur Analyse der notwendigen Aktivitäten zur Erfüllung eines vorgegebenen Ziels eignen sich Abhängigkeitsdiagramme und eine Work-Breakdown-Structure. Zur Darstellung von Abhängigkeiten zwischen Aktivitäten (und z.b. der Identifizierung des kritischen Pfades) eignen sich Netzpläne. Zur Darstellung der zeitlichen Planung in Iterationsplänen eignen sich Balkendiagramme.

Unterschiedliche Sichten -> unterschiedliche Darstellungsweisen: Zur Analyse der notwendigen Aktivitäten zur Erfüllung eines vorgegebenen Ziels

13 Bsp. Wasserfall

14 Bsp. Iterativ/Inkrementell

15 Realistische Projektpläne Der Projektplan sollte niemals das Team hetzen oder es demoralisieren. Projektpläne sollen erfüllbar sein, aber auch knapp genug, um stetigen Fortschritt zu garantieren. Ein Produkt sollte niemals zugunsten eines möglicherweise willkürlichen Projektplans gefährdet werden. Längere Vorhaben sollten in kürzere, klar abgegrenzte Teilprojekte aufgeteilt werden. Jedes Teilprojekt sollte ein befriedigendes und motivierendes Ergebnis haben.

Ein Produkt sollte niemals zugunsten eines möglicherweise willkürlichen Projektplans gefährdet werden.

16 Projektkontrolle Projekttagebuch und Aufwandserfassung Besprechungsprotokolle Berichte Meilenstein-Trendanalyse (MTA)

17 Meilensteintrendanalyse initial Schätzung am... offener Meilenstein erledigter Meilenstein 4/04 3/04 2/04 1/04 A D C I T AT Meilenstein geschätzt für... 1/04 2/04 3/04 4/04

18 Meilensteintrendanalyse final

19 Sammlung der gefährlichsten PM-Praktiken Verwenden eines knappen Zeitplans als Grund für den Einsatz neuer Technologien. Festlegen der Technologien in den Anforderungen. Einsetzen von neuartigen Wundermitteln. Annahme, auch starke Projektverspätungen ohne entsprechende Reduktion der Anforderungen wieder aufholen zu können.

Festlegen der Technologien in den Anforderungen.

20 Sammlung der gefährlichsten PM-Praktiken Plazieren von Aufgaben am kritischen Pfad, die nicht der Kontrolle des Projektteams unterliegen. Erwarten von großen Leistungssteigerungen über 10% der bisher beobachteten Zahlen. Lösen aller Komplexitätsfaktoren der Aufgabe mit Hilfe des Software-Anteils. Erwarten, daß formale Reviews mit möglichst vielen Teilnehmern ein korrektes Bild der Vorgänge im Projekt ergeben.

Erwarten von großen Leistungssteigerungen über 10% der bisher beobachteten Zahlen.

21 Empfehlenswerte PM-Praktiken Geordnetes Risikomanagement. Als Anwenderanleitung lesbare Spezifikation. Regelmäßige Reviews und Code-Inspektionen. Planen und Verfolgen von Zeitplänen mit eindeutigen quantitativen Vorgaben. Projektweite Sichtbarkeit des Projektplans und des Fortschritt gegenüber dem Plan. Verfolgen des Fehlertrends gegenüber Qualitätszielen. Teamorientiertes verantwortliches Management.

22 Rechte und Pflichten Der Kunde hat das Recht,... Ziele festzulegen und darf erwarten, dass diese eingehalten werden. zu wissen, wie lange das Projekt aus aktueller Sicht dauern wird und wie viel es kosten wird. zu entscheiden, welche Anforderungen das Projekt erfüllen soll und welche nicht. Anforderungen während des Projekts in vertretbarem Ausmaß zu ändern und eine Prognose zu erhalten, welche finanziellen Auswirkungen diese Änderungen haben werden. über den Projektstatus verständlich, rechtzeitig und zuverlässig informiert zu werden. über Risiken regelmäßig verständigt zu werden, welche die Kosten, den Projektplan oder die Qualität beeinflussen können, und über Optionen informiert zu werden, wie diese Probleme zu lösen sind. während der gesamten Projektdauer Zugang zu allen Produkten zu haben. Das Projektteam hat das Recht,... die Projektziele und Prioritäten zu erfahren. zu wissen, welche Produkte erzeugt werden sollen, und eine Klarstellung zu deren Inhalten zu erhalten. mit jenen Personen des Kunden in Kontakt treten zu können, die Entscheidungen in Bezug auf die Funktionalität bzw. Qualität treffen können. in jeder Phase des Projekts technisch verantwortungsvoll arbeiten zu können und nicht gezwungen zu werden, die Implementierung zu früh zu starten. Aufwand und Zeitplan für jede Tätigkeit überprüfen zu können, welche durchgeführt werden muss. Weiters müssen nur jene Schätzungen abgegeben werden, welche zu einem bestimmten Zeitpunkt im Projekt möglich sind. Schätzungen dürfen bei jeder Anforderungsänderung abgeändert werden.

23 Team-Management-Kreis

24 Struktur einer Chefprogrammierer-Gruppe

25 Eine moderne Gruppenstruktur

26 Kommunikationsbeziehungsdiagramm

27 Gruppenleistung versus Teamleistung

28 Die Teamuhr: Prozessphasen der Teamentwicklung

29 Harte Teamfaktoren Teamziele Teamführung Zeit- und Projektplanung Qualifikations- und Aufgabenverteilung Entscheidungskompetenz Einbindung im Unternehmen

30 Weiche Teamfaktoren Vision Kommunikation und Interaktion sachliche und emotionale Offenheit gegenseitige Unterstützung konstruktive Konkurrenz Partizipation und Engagement Interesse, Vertrauen und Akzeptanz Übernahme von Verantwortung konstruktive Unzufriedenheit Arbeitsklima Effizienz, Dynamik, Teamgeist

31 Entscheidungsspielräume

32 Modell der situationsbezogenen Führung

Ähnliche Dokumente

Führungsgrundsätze im Haus Graz

;) :) Führungsgrundsätze im Haus Graz 1.0 Präambel 2.0 Zweck und Verwendung Führungskräfte des Hauses Graz haben eine spezielle Verantwortung, weil ihre Arbeit und Entscheidungen wesentliche Rahmenbedingungen