5 Web Projekt Management

Größe: px

Ab Seite anzeigen:

Download "5 Web Projekt Management"

Lorenz Wagner
vor 8 Jahren
Abrufe

1 5 Web Projekt Management Projektmanagement grundsätzlich: Führung: Organisieren, steuern, Personal, informieren Entwicklung: Ziele, Planung, Entscheidungen Kontrolle: Tracking, Reporting Unterschiede zwischen SW / Web-Projekten: SW Web Ziele Qualitätsprodukt, geringe Kosten Schnell was Brauchbares Personal < 10 Laufzeit 1 Jahr 1 Q Kosten XX Mio XXX Tsd Ansatz / Prozess Produkt anforderungsgetrieben, dokumentenzentrisch, Phasen+Inkremente Individueller Code, kaum Wiederverwendung, Komplex Skills SW-Entwickler (OS nah) mit viel Erfahrung + IT Architekt agil, Prototyping, test-driven Hohe Wiederverwendung, Standardkomponenten MM-Designer, Web- Programmierer (Java), Marketing Design GUI + Funktionen + Daten Präsentation + Hypertext (Nav+Struktur) + Content Herausforderungen: Wiederverwendung, keine Einmaligkeit nicht so techniklastig, andere Problemfelder Planung Web Programmierer = Künstler Zahl der Lösungsalternativen fortwährender technologischer Fortschritt Entwicklung Novität (Benutzerkreis, Lösung,...) Dynamik (Time-To-Market Druck) Parallelität kontinuierliche Weiterentwicklung Juvenil Immaturität / Unreife Produkt vermeintliche Simplizität 1

anforderungsgetrieben, dokumentenzentrisch, Phasen+Inkremente Individueller Code, kaum Wiederverwendung, Komplex Skills SW-Entwickler (OS nah) mit viel Erfahrung + IT Architekt agil, Prototyping,

2 Ästhetik Spontanität vs Loyalität der Benutzer Ubiquität Kompatibilität Stabilität + Verfügbarkeit Skalierbarkeit Web-PM: diverse goldene Regeln Agiles Manifest 97 Things Every Project Manager Should Know PM Prozesse (ref. PM-BOK = Body of Knowledge ): Initiation Process Project Charter Identify Stakeholder Planning Process Requirements Scope PrjPlan/Activities/WBS/Schedule QM-Plan Budget / Procurement Risks Communications HR Executing Process build / develop /manage Team Manage Execution QA Verify Scope Procurement Manage Stakeholder Expectations Info Distribution Controlling Process Scope / Schedule / Costs / Risks / Quality / Work / Performance Closing Process Procurements / Project 2

PM-BOK = Body of Knowledge ): Initiation Process Project Charter Identify Stakeholder Planning Process Requirements Scope PrjPlan/Activities/WBS/Schedule QM-Plan Budget /

3 Fortschrittsmessung? Risiken: unklare Zieldefinition falsches Zielpublikum entwicklungsorientierte Site mangelnde Konsitenz fehlendes Budget für Wartung und Pflege Content Recycling schlechte Verlinkung Vermischung von Intranet und Internet Verwechselung von Marktforschung und Usability-Studien Unterschätzung der strategischen Bedeutung des Webs Vorgehensmodelle Wichtige Vorgehensmodelle: 1. Wasserfallmodell 2. Spiralmodell 3. RUP 4. V-Modell 5. Extreme Programming 6. Scrum 7. Model Driven Developement Wasserfallmodell: Phasen: 1. Initialisierung 2. Definition / Analyse 3. Entwurf / Design 4. Implementierung 5. Testing 6. Maintenance Vorteile: klare Phasen, einfaches Management, Kosten gut kalkulierbar Nachteile: nur für stabile Anforderungen, Phasenabgrenzung, ungeeignet für komplexe Projekte, unflexibel, spätes ROI Spiralmodell Weiterentwicklung des Wasserfallmodells zum iterativen Prozess Quadranten: Planung / Ziele festlegen / Alternativen/Risiko beurteilen / Entwickelung+ Test 3

Intranet und Internet Verwechselung von Marktforschung und Usability-Studien Unterschätzung der strategischen Bedeutung des Webs Vorgehensmodelle Wichtige Vorgehensmodelle: 1. Wasserfallmodell 2.

4 Ergebnisse: Grobentwurf -> Prototyp / Feinentwurf -> betriebsfähige Lösung Rational Unified Process (RUP) Grady Booch, Ivar Jacobson und James Rumbaugh ( Die drei Amigos ) -> UML / OMG Orthogonal (iterative) Phasen: Inception Vision Elaboration Baseline Architektur Construction Beta Release Transition Final Release Iteration -> Milestones Engineering Disciplines: Business Modeling Requirement Analysis + Design Implementation Test Deployment Support Disciplines: Configuration + Change Management PM Environment Management UML Modell: Diagramme (ref: Use Case Component Class Object Deployment Activity State chart Collaboration Sequence V-Modell (Militärischer Ursprung: Deutsches Verteidigungsministerium) Projektdefinition: 4

Requirement Analysis + Design Implementation Test Deployment Support Disciplines: Configuration + Change Management PM Environment Management UML Modell: Diagramme (ref: http://www.oose.

5 Req Analyse Systemdesign Architektur Design Implementierung Validierung Unit Testing Integration Testing System Testing User Acceptance Testing Extreme Programming Req zu Projektbeginn nicht alle bekannt -> viele Iterationen -> Kunde ist die gesamte Zeit einbezogen Team arbeitet gemeinsam an Aufwandsschätzung und Reviews Releases -> User Stories -> Risko/Nutzen -> FeatureExistenz/Kundenzufriedenheit -> Tasks Aufwand in Story Points (Planning Game) Proaktives Risikomanagement Neue Funktionalität wird permanent entwickelt, integriert und getestet. Prototyping steht im Vordergrund YAGNI Paradigma Daily Standup Meetings (Was wurde geleistet / Probleme / Tagesplanung ) Paradigmen: Pair-Programming / Test Driven Development / Refactoring / Keep it simple Scrum Agiles vorgehen, gut mit XP kombinierbar Rollen: Owner Team Scrum Master Sprint Planung: Product Backlog Verteilung Sprint Backlog Sprint = eine Iteration: 1-4 Wochen Team organisiert sich selbst Daily Scrum Impediment Backlog Review nach Sprint Retrospektive 5

FeatureExistenz/Kundenzufriedenheit -> Tasks Aufwand in Story Points (Planning Game) Proaktives Risikomanagement Neue Funktionalität wird permanent entwickelt, integriert und getestet.

6 Burn Down Chart Requirements Engineering (UML, etc) Vorgehen: 1. Stakeholder identifizieren 2. Stakeholder interviewen 3. Contract Software Anforderungsspezifikation: Hilfsmittel: Volere oder DIN IEEE Kap. 4.3 definiert 8 Charakteristika guter SRS: Korrekt Unzweideutig Vollständig Atomar und Identifizierbar Konsistent Bewertet nach Wichtigkeit und/oder Stabilität Verifizierbar Modifizierbar Rückverfolgbar (Traceable) Abnahmekriterien einheitlich Dokumentiert Dokumentation: Kunde: Lastenheft Entwicklung: Pflichtenheft Ziel: Ergebnis der Art 1. Big Picture 2. Allgemeine Beschreibung (des Softwareprodukts) Produktperspektive (zu anderen Softwareprodukten) Produktfunktionen (eine Zusammenfassung und Übersicht) Benutzermerkmale (Informationen zu erwarteten Nutzern, z.b. Bildung, Erfahrung, Sachkenntnis) Einschränkungen (für den Entwickler) Annahmen und Abhängigkeiten (nicht Realisierbares und auf spätere Versionen verschobene Eigenschaften) 3. Spezifische Anforderungen (im Gegensatz zu 2.) funktionale Anforderungen -> Was soll die Lösung tun? 6

3 definiert 8 Charakteristika guter SRS: Korrekt Unzweideutig Vollständig Atomar und Identifizierbar Konsistent Bewertet nach Wichtigkeit und/oder Stabilität Verifizierbar Modifizierbar

7 nicht-funktionale Anforderungen externe Schnittstellen Design Constraints Anforderungen an Performance Qualitätsanforderungen Sonstige Anforderungen Anhang: Erläuterungen von Fachbegriffen und Abkürzungen Verweise auf Quellen Vier unterschiedliche Beschreibungsformen von Anforderungen: 1. Freitext (Web: typischerweise User Stories) 2. Anforderungslisten -> Welche Eigenschaften soll die Lösung haben? IETF Standard: MUST (Verpflichtung), MUST NOT, SHOULD (Empfehlung), SHOULD NOT, MAY (Optional) 3. Formatierte Spezifikation (Use Cases, Volere Shell, RDD-100 Req Spec Language) 4. formale Spezifikation (Sprachen VDM, Larch, Z) Beispiel für Use Case Modellierung: Studenten Support Seite: Studenten können Anfragen und Probleme zu ausgewählten Themen als Tickets einstellen und geben eine -Adresse für Rückantworten an. Die Probleme sollen vom Support Team bearbeitet werden und die Lösung an das Ticket gehängt werden. Der Student bekommt eine mit dem Hinweis auf die Lösung. Es soll eine FAQ zu häufige Fragen und Antworten zu den Hauptthemen abrufbar sein. Die FAQ stellen die Support-Mitarbeiter zusammen. Akteure? Use Cases? Präzision Prüfung Aufwand Eignung f. Nicht-Experten Skalierbarkeit User Stories Anf-Listen formatierte Spec formale Spec Besonderheiten des Anforderungsmanagements: Multidisziplinarität Wer sind die Stakeholder? Dynamik und Randbedingungen Einsatzplanung 7

Anforderungslisten -> Welche Eigenschaften soll die Lösung haben? IETF Standard: MUST (Verpflichtung), MUST NOT, SHOULD (Empfehlung), SHOULD NOT, MAY (Optional) 3.

8 Legacy SW (Altanwendungen) Bedeutung der Qualität Benutzerschnittstelle Content fehlende Erfahrung (techn) fixe Termine Prozesse + fachliche Datenmodelle -> CRUD Funktionen + komplexe Funktionen 8

Ähnliche Dokumente

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das