Prozesse und Projekte

Größe: px

Ab Seite anzeigen:

Download "Prozesse und Projekte"

Heini Kramer
vor 8 Jahren
Abrufe

1 Universität Stuttgart Prozesse und Projekte Planung unter schwierigen Randbedingungen Matthias Wetzel Abteilung Software Engineering 1 / 24

2 Agenda Inhalt der Vorlesung: Grundlagen Prozesse Kritische Punkte im Projektverlauf Lösungsansätze 2 / 24

3 Begriffsdefinition Prozess process. (1) A sequence of steps performed for a given purpose; for example, the software development process. (2) An executable unit managed by an operating system scheduler. See also: task; job. (3) To perform operations on data. software development process. The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes, installing and checking out the software for operational use. Note: These activities may overlap or be performed iteratively. See also: incremental development; rapid prototyping; spiral model; waterfall model. IEEE Std A process describes who is doing what, how, and when. Kruchten, Rational Unified Process: An Introduction 3 / 24

The process by which user needs are translated into a software product.

4 Prozess-Paradigmen Das Prozess-Paradigma bezeichnet die Vorgehensweise, die einem Prozess oder einem Prozessmodell zugrundeliegt: diese kann wasserfallartig oder iterativ sein: Wasserfall Prozess Business modelling Requirements Analyse und Design Iterativer Prozess Implementierun g Modultest Integrations- Test Produktreife Auslieferun g Configuration Management 4 / 24

Wasserfall Prozess Business modelling Requirements Analyse und Design Iterativer Prozess

5 Wasserfallmodell nach Royce (vereinfacht) 5 / 24

6 Wasserfallmodell und Phasenmodell Wasserfallmodell (aktivitätszentriert): Software-Entwicklung ist sequentielle Folge von Aktivitäten, die durch Teilergebnisse (Dokumente) gekoppelt sind. Reihenfolge der Aktivitäten ist fest definiert. Rücksprünge (möglichst) vermeiden Vom Wasserfallmodell zum Phasenmodell: Einführung von Meilensteinen (Strikt sequentielle) Phasen sind durch Meilensteine getrennt Unterschied Aktivität Phase: Phasen zeitlich begrenzt und überlappungsfrei (Evtl.) Mehrere Aktivitäten in einer Phase 6 / 24

Rücksprünge (möglichst) vermeiden Vom Wasserfallmodell zum Phasenmodell: Einführung von Meilensteinen (Strikt sequentielle) Phasen

7 Iteratives Vorgehen: Rational Unified Process Rational 7 / 24

8 Ablauf einer einzelnen Iteration Iteration n - 1 Detail Planung für Iteration n Zielfestlegung Achtung: Erfolgsmessung soll möglich sein! 2 6 Wochen Startup Meeting Evaluationsfolgen wie z.b. Nacharbeit, Fehlerbeseitigung, Iteration n Geplante Iterationen Tasks Evaluation der Zielerreichung Detail Planung für Iteration n + 1 Zeit Evaluation Meeting Evaluation / Acceptance Iteration n / 24

Nacharbeit, Fehlerbeseitigung, Iteration n Geplante Iterationen Tasks Evaluation der Zielerreichung

9 Projektfortschritt bei iterativem Vorgehen Prozessbeschreibung Evaluation GUI Prototyp Benutzer Akzeptanz Architektur- Durchstich für einen Geschäftsprozess Last-Tests, Technologie und Performance Evaluation V 0.5 Betatest... V 0.7 Betriebs-Übergabe, Pilotbetrieb V 0.8 Anwender-Training V 0.9 Probebetrieb Configuration Management 9 / 24

Last-Tests, Technologie und Performance Evaluation V 0.

10 Vergleich der Prozess-Paradigmen (1) Hauptnachteil beim Wasserfall: Vollständige, konsistente Spezifikation vor Beginn der Implementierung unrealistisch [Brooks, Balzer, Boehm, Gilb, Parnas] Das heißt aber natürlich nicht, dass man überhaupt keine Spezifikation schreiben sollte! Weitere Nachteile: [Boehm]: A prototype is worth words (IKIWISI) Review von Seiten nicht machbar Gold plating [Mills]: Projekte zu groß für intellektuelle Kapazität [Kruchten]: Umfangsänderungen schwer realisierbar 10 / 24

Spezifikation schreiben sollte! Weitere Nachteile: [Boehm]: A prototype is worth 100.000 words (IKIWISI) Review von 5.

11 Vergleich der Prozess-Paradigmen (2) Nachteile iterativen Vorgehens: [Boehm]: Inflexible point solutions High-risk downstream capabilities (z.b. Sicherheit, Fehlertoleranz etc.) Off-target initial release [Schmidberger]: Schwierigere Untervergabe an Subcontractors Schwierigere Aufwandsschätzung klassisches Festpreisprojekt auf Basis einer vollständigen Spezifikation nicht möglich [Wetzel]: Extreme Abhängigkeit vom Kunden (möglichst) 11 / 24

) Off-target initial release [Schmidberger]: Schwierigere Untervergabe an Subcontractors Schwierigere

12 Inkrementelles Vorgehen / Treppenmodell Inkrementelles Vorgehen: Realisierung in Ausbaustufen Erste Stufe ist Kernsystem Ausbaustufen erweitern das System i.d.r. eigene Projekte; Vorgehen iterativ oder wasserfallartig Treppenmodell: Hauptunterschied Inkrementelles Vorgehen Treppenmodell: Treppenmodell: parallele Entwicklung durch Teilteams Inkrementelles Vorgehen: sequentielle Entwicklung durch 1 Team 12 / 24

13 Gruppenarbeit Sie sollen als Projektleiter ein 12-Personen- Projekt planen. Die vorgesehene Dauer ist ein Jahr, nach 5 Monaten muss ein erstes Release mit reduzierter Funktionalität aber in Produktqualität bereitstehen. Welche Vor- und Nachteile hat ein Inkrementelles Vorgehen vs. ein Vorgehen nach dem Treppenmodell? Bearbeitung in 3er-Teams, 5min Bearbeitungszeit anschließend Diskussion 13 / 24

Funktionalität aber in Produktqualität bereitstehen.

14 Kritische Punkte im Projektverlauf (1) Anforderungserhebung: Entwurf: ausreichend detailliert für Diskussion mit Kunden genau genug für Definition von Arbeitspaketen Auswahl geeigneter Technologie Entwurf einer tragfähigen Architektur, Erweiterungsmöglichkeiten Implementierung: Parallelisierung nötig <OpenConf> Termindruck: 1. Release (robust, sicher) bis Mitte September Release (komplette Funktionalität) bis Ende März / 24

tragfähigen Architektur, Erweiterungsmöglichkeiten Implementierung: Parallelisierung nötig <OpenConf>

15 Kritische Punkte im Projektverlauf (2) Test / QS allgemein: Sicherstellung einer ausreichenden Qualität für Produktiveinsatz Definition allgemeiner Richtlinien zur QS Auslieferung: Definierter, getesteter Programmstand Konfigurationsverwaltung Betrieb: Wartung: Richtlinien für HelpDesk und Support Nachführung von Änderungen Konfigurationsverwaltung Kommunikation, Risikomanagement, Ressourcenplanung etc. 15 / 24

Programmstand Konfigurationsverwaltung Betrieb: Wartung: Richtlinien für HelpDesk und Support

16 Anforderungserhebung Ideen? Notation: Erhebung: Use Cases User Stories Benutzerhandbuch Kundenbefragungen Widersprüchliche Anforderungen verschiedener Kunden? Prototyping 16 / 24

17 Entwurf Ideen? Notation: UML-Komponentendiagramm UML-Klassendiagramme Erstellung einer Architektur: Frameworks: Musterarchitekturen Entwurfsmuster 17 / 24

18 Implementierung Ideen? Arbeitsverteilung: Codierung: Parallelisierung auf Basis des Entwurfs (z.b. GUI, Datenmodell) Java-Code HTML-Seiten Pair Programming? 18 / 24

19 Test Ideen? Test: Testplattform? Modul-/Integrations-/Systemtest Vorbereitung / Dokumentation von Tests QS allgemein: Spezifikationsreviews, Code-Reviews... Prüfplan? 19 / 24

20 Auslieferung Ideen? Auslieferung: <OpenConf> Harte Deadline Definierter und getesteter Versionsstand Verfügbarkeit des Zielsystems Akzeptanzkriterien / Vorgehen bei Abnahme 20 / 24

21 Betrieb Ideen? Verantwortlichkeiten: Schulungen? Ansprechpartner im Projekt für auftretende Probleme: Hotline Incident Management Datensicherheit: Durchführung von Backups 21 / 24

22 Wartung Ideen? Wartungsaktivitäten: Fehlerdatenbank Workflow für Aufspielen von Patches Nachziehen von Änderungen in Endversion Berücksichtigung neuer Anforderungen 22 / 24

23 Weitere kritische Punkte Ideen? Sonstiges:... Kommunikation: Regelmäßige Treffen, Chats, , Wikis... Risikomanagement: Ausfall von Mitarbeitern, Hardware Ressourcenplanung: Prüfungszeiten, Urlaub Rollenverteilung: Projektleiter, QS, Technologiespezialisten 23 / 24

24 Diskussion Vielen Dank für Ihre Aufmerksamkeit! Gibt es Fragen oder Anmerkungen? 24 / 24

Ähnliche Dokumente

Projektmanagement iterativer Projekte

Projektmanagement iterativer Projekte Übersicht Motivation zum iterativen Vorgehen Anleitung zur U Ca getriebenen Vorgehenswei Praktische Tipps Zusammenfassung Projektmanagement iterativer Rainer Schmidberger Universität Stuttgart Institut