Post on 18-Sep-2018
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 1
Vorlesung
Management von Softwareprojekten
Fakultät für Ingenieurwissenschaften und InformatikUniversität Ulm
WS 2010/11Dr. Frank Houdek, Michael Stupperich
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 2
Kapitel 1
Einleitung und Grundlagen
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 3
Aufbau der Vorlesung (Kapitel 1)Kapitel 1: Einleitung und Grundlagen
1.1 MotivationWarum SoftwaremanagementWas ist Softwaremanagement
1.2 Überblick über die Vorlesung1.3 Grundbegriffe
Was ist ein ProjektWas ist ein SoftwareprojektUnterschiede zu anderen Projekten
1.4 Ziele und Aufgaben des SoftwaremanagementZiele des ProjektmanagementsAufgaben des Projektmanagements
1.5 Vorgehensmodelle für die SoftwareentwicklungKlassisches WasserfallmodellV-Modell des Bundes
Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 4
„Sag mir, wie Dein Projekt anfängt,und ich sage Dir, wie es endet“
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 5
Motivation: Warum Management? (1)
Situation in der Software-Entwicklung:Wie werden Softwareprojekte abgeschlossen?
Typ 116%
Typ 253%
Typ 331%
Typ 1: Succeeded; Projekt abgeschlossen- Im Zeitrahmen- Im Kostenrahmen- Mit geforderter Qualität
Typ 2: Challenged; Projekt abgeschlossen, aber- Teurer als geplant oder- Länger als geplant oder- Geringere Qualität als gefordert
Typ 3: Failed; Projekt abgebrochen
Chaos Report, The Standish Group, 1995
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 6
Motivation: Warum Management? (2)
0%
5%
10%
15%
20%
25%
30%
35%
bis 20% 21-50% 51-100% 101-200% 201-400% über 400%
Grad der Kostenüberschreitung
Ante
il Pr
ojek
te
0%
5%
10%
15%
20%
25%
30%
35%
40%
bis 20% 21-50% 51-100% 101-200% 201-400% über 400%
Grad der Zeitüberschreitung
Ante
il Pr
ojek
te
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Chaos Report, The Standish Group, 1995
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 7
49%
46%
33%
53%
28%
40%
31%
23%
Motivation: Warum Management? (3)
Quelle: CHAOS Report, The Standish Group International, Inc.
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
28%
26%
27%
16%1994
1996
1998
2000
Succeeded
FailedChallenged
0% 20% 40% 60% 80% 100%
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 8
Motivation: Warum Management? (4)
Erfolgsfaktoren für ProjekteEinbeziehung der Benutzer (aller Stakeholder, 16%)Unterstützung durch das Management (14%)Klar beschriebene Anforderungen (13%)Geeignete Planung (10%)Realistische Erwartungen (8%)Genügend feine Meilensteine (8%)Gut ausgebildete Mitarbeiter (7%)Ownership (5%)Klare Vision und Ziele (3%)Motivierte, hart arbeitende Mitarbeiter (2%)Sonstiges (13%)
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Chaos Report, The Standish Group, 1995 Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen
Legende
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 9
Klassische Fehler in der Software-Entwicklung:Es wird direkt mit der Codierung angefangenDas Vorgehensmodell fehlt bzw. wird nicht befolgtDie Terminvorgaben sind unrealistischDie Weiterbildung der Mitarbeiter ist nicht zielgerichtetAuswahl und Einsatz der Werkzeuge bzw. Methoden ist unzureichendvorbereitetEin Risikomanagement wird nicht betriebenEine Abnahme der Phasenergebnisse erfolgt nichtEs wird nicht systematisch bzw. unzureichend getestetDie Anforderungen und Qualitätsmerkmale werden nicht festgelegt
Motivation: Warum Management? (5)
Quelle: Interne Untersuchung bei Bosch
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen
Legende
Kein Bezug zu Vorlesungsthemen
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 10
Motivation: Warum Management? (6)
Klassische Fehler in der Software-Entwicklung (Fortsetzung):Es fehlen eindeutige BegriffsdefinitionenDie Systemarchitektur ist gar nicht oder nur mit großem AufwanderweiterbarDas System ist nicht modular aufgebaut, die Daten sind nichtgekapseltProgrammier-Standards bzw. -Richtlinien werden nicht beachtetDie Namensvergabe ist ungünstigDie Dokumentation fehlt ganz, ist veraltet oder nicht adäquatDie Schulung der Anwender wird vernachlässigtDas Konfigurationsmanagement ist unzureichend
Quelle: Interne Untersuchung bei Bosch
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen
Legende
Kein Bezug zu Vorlesungsthemen
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 11
Was bedeutet überhaupt Management?
Begriffsdefinitionen
managen von lat. manus agere (die Hand führen); leiten, zustandebringen, geschickt bewerkstelligen, organisieren [Duden]
Projektmanagement ist die Gesamtheit aller Führungsaufgaben,-techniken und -mittel für die Abwicklung eines Projekts[nach DIN 69901]
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 12
Was brauche ich für ein Softwareprojekt?
SoftwaretechnikPrinzipien, Methoden, Techniken zur Entwicklung großerSoftwaresysteme, z.B.
AnalysemethodenDesign, ArchitekturTestverfahren
Software-QualitätssicherungTätigkeiten, die dazu dienen, den Nachweis zu erbringen, dass dieQualitätsanforderungen an die Software erfüllt sind, z.B. durch
Testfallermittlung
Software-ProjektmanagementPlanen und Steuern eines Projekt („Klassische Managementaufgaben“)
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 13
Begriffsabgrenzung SW-Projektmanagement
Planung &Steuerung
Aufbau-organisation Aufwands-
schätzung
Vorgehens-modelle
Analyse-Methoden
Design-Methoden
Implenetierungs-techniken
Modul-test
Bestimmung vonTestumfängen
Integration-techniken
Testfall-ermittlung
Qualitäts-management
Review-techniken
Mitarbeiter-führung
…
…
…
Software-technik
Software-Projektmanagement
Software-Qualitäts-Sicherung
Quelle: Henrich, Management von Softwareprojekten, 2001
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 14
Inhalte der Vorlesung (1/6)Kapitel 1: Einleitung und Grundlagen
1.1 Motivation1.2 Überblick über die Vorlesung1.3 Grundbegriffe1.4 Ziele und Aufgaben des Softwaremanagement1.5 Vorgehensmodelle für die Softwareentwicklung
Kapitel 2: Projektplanung2.1 Ziele und Inhalte der Planung2.2 Das Projektziel2.3 Organisatorische Aspekte von Projekten2.4 Projektstrukturplan2.5 Netzplantechnik2.6 Ressourcenplanung2.7 Werkzeugunterstützung: Microsoft Project2.8 Der Projektmanagement-Plan
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 15
Inhalte der Vorlesung (2/6)Kapitel 3: Aufwands- und Kostenschätzung
3.1 Motivation3.2 Überblick über Kostenschätzungsverfahren3.3 Function Point Methode3.4 COCOMO
Kapitel 4: Projektkontrolle und -steuerung4.1 Berichtswesen und Projektdokumentation4.2 Projektsteuerung4.3 Entscheidung4.4 Besprechungen und Präsentationen4.5 Kreativitätstechniken4.6 Projektabschluss
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 16
Inhalte der Vorlesung (3/6)Kapitel 5: Messen und Bewerten von Software und Softwareprojekten
5.1 Ein bisschen „Messtheorie“5.2 GQM5.3 Softwaremaße5.4 Messprogramme5.5 Systematische Softwareprozessverbesserung
Kapitel 6: Risikomanagement6.1 Motivation6.2 Definition6.3 Risikokategorien6.4 Techniken des Risikomanagements6.5 Anforderungen an Risikomanagement gem. Assessment6.6 Ausprägungen von Risikomanagement
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 17
Inhalte der Vorlesung (4/6)Kapitel 7: Konfigurationsmanagement
7.1 Motivation7.2 Begriffe7.3 Änderungs- und Fehlermanagement7.4 Versions- und Variantenmanagement7.5 Auswertungen im Rahmen des Konfigurationsmanagements7.5 Werkzeugunterstützung für Konfigurationsmanagement7.6 Der Konfigurationsmanagement-Plan
Kapitel 8: Requirements Management8.1 Requirements Engineering vs. Requirements Management8.2 Aktivitäten des Requirements Management8.3 Requirements Management Systeme8.4 Beispiel eines Requirements Management-Systems: DOORS
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 18
Inhalte der Vorlesung (5/6)Kapitel 9: Qualitätsmanagement
9.1 Motivation und Überblick9.2 Systematisches Testen9.3 Reviews und Inspektionen9.4 Formale Verfahren9.5 Konstruktive Qualitätssicherung
Kapitel 10: Die Menschliche Komponente10.1 Leistung und Motivation10.2 Zusammenarbeit in der Gruppe
Kapitel 11: Einführung von Prozessen11.1 Motivation und Definition11.2 Organisationsentwicklung11.3 Ausgewählte Aspekte von Veränderungen11.4 Modell zur Einführung von Prozessen
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 19
Kapitel 12: Herausforderungen aus der PraxisVerteilte Software-Entwicklung
12.1 Motivation und Grundbegriffe12.2. Vorteile12.3. Herausforderungen12.4. Kooperationsmodelle12.5. Best Practices12.6 Aktuelle Forschungsthemen
Sicherheit und Zuverlässigkeit12.7 Einleitung und Motivation12.8 Grundlagen und Begriffe12.9 Grundlagen der Zuverlässigkeitstechnik12.10 Grundlagen der Sicherheitstechnik12.11 Überblick neuer Automotive-Standard zur funktionalen Sicherheit12.12 Sicherheits- und Zuverlässigkeitsmaßnahmen12.13 Sicherheitsanalyse-Methoden
Inhalte der Vorlesung (6/6)
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 20
ReferentenKapitel 1: Einleitung und GrundlagenKapitel 2: ProjektplanungKapitel 3: Projektkontrolle und -steuerungKapitel 4: Aufwands- und KostenschätzungKapitel 5: Messen und Bewerten von SoftwareKapitel 6: RisikomanagementKapitel 7: KonfigurationsmanagementKapitel 8: Requirements ManagementKapitel 9: QualitätsmanagementKapitel 10: Die menschliche KomponenteKapitel 11: Einführung von ProzessenKapitel 12: Herausforderungen aus der Praxis
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
Dr. Frank Houdek
Michael Stupperich
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 21
Web-Site der Vorlesung
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 22
LiteraturH. Balzert. Lehrbuch der Softwaretechnik. Band 1 und 2, Spektrum Akademischer Verlag, 2000,2008.K. Schneider. Abenteuer Software-Qualität. dpunkt.Verlag, 2007.K. Frühauf, J. Ludewig, H. Sandmayr. Software-Projektmanagement und –Qualitätssicherung. vdfHochschulverlag AG an der ETH Zürich, 4. Aufl., 2001.K. Frühauf, J. Ludewig, H. Sandmayr. Software-Prüfung. vdf Hochschulverlag AG an der ETHZürich, 6. Aufl., 2006.K. Wiegers. Software Requirements. Microsoft Press, 2nd Edition, 2003.J. Schäuffele, T. Zurawka. Automotive Software Engineering. 3. Aufl., Vieweg Verlag, 2006.B. Jenny. Projektmanagement in der Wirtschaftsinformatik. vdf Hochschulverlag AG an der ETHZürich; Auflage: 5. Aufl., 2001.N.E. Fenton, S.L. Pfleeger. Software Metrics – A Rigorous & Practical Approach. ThomsonComputer Press, 1997.H. Henrich. Management von Softwareprojekten. Vorlesungsscript Fern-Uni Hagen, 2001.M.B. Chrissis, M. Konrad, S. Shrum. CMMI for Development, Version 1.2. Addison Wesley, 2001.D. Thomas, A. Hunt. Versionsverwaltung mit CVS. Hanser Verlag, 2004.B. Poensgen, B. Bock. Function-Point-Analyse — Ein Praxisbuch. dpunkt Verlag, 2005.
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 23
Was ist ein Projekt? (1)
Folgende Eigenschaften sind charakteristisch für ein ProjektZeitliche Begrenzung
Definierter Anfangs- und Endzeitpunkt.Es handelt sich nicht um eine permanente Aufgabe
Klare AufgabendefinitionDas Ziel des Projekts (das Ergebnis) ist klar vorgegeben.
Hohe Komplexität / Unsicherheit des Ausgangs / RisikoGewisse Neuartigkeit oder Einzigartigkeit.Keine bloße Wiederholung früherer Tätigkeiten.
Vorgegebener KostenrahmenKonkurrenz um begrenzte Mittel
Personal, Finanzmittel, Sachmittel, etc.Mehrere beteiligte Stellen
Lässt sich nicht mit existierender Organisation bewältigen
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 24
Was ist ein Projekt? (2)
„Ein Projekt ist ein Unternehmen auf Zeit“
Ein Projekt wird durch 3 Ecksäulen bestimmtQualität und Funktionalität
Wichtig: Qualität hängt von den Erwartungen des Kunden abSpezifikation des erwarteten Produkts (Extern vorgegebene Ziele)
KostenVergleich Soll-/Ist-KostenBudgetplanung
ZeitTerminplanung
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 25
Spannungsfeld eines Projekts
Kosten
Qualität(Funktionalität)
Zeit(Termin)
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 26
Spannungsfeld eines Projekt (erweitert)
Kosten Termin
Qualität Umfang
KonstanteFläche
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
„Teufelsquadrat“ nach Sneed
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 27
Spannungsfeld eines Projekt (erweitert)
Kosten Termin
Qualität Umfang
(weiter außen =schneller)
(weiter außen =billiger)
(weiter außen =besser)
(weiter außen =mehr Funktionalität)
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
„Teufelsquadrat“ nach Sneed
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 28
Was ist ein Softwareprojekt?
Grundsätzlich: Ein Projekt, in dem hauptsächlich oder ausschließlichSoftware entwickelt wird.
Verschiedene Arten von SoftwareprojektenProjektart, z.B.
NeuentwicklungWeiterentwicklung
Art der Software, z.B.Kaufmännische AnwendungTechnische AnwendungEchtzeitanwendung
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 29
Arten von Software-Projekten
Art der Software
Projektart
Neuentwicklung
Wartung
Weiterentwicklung
Prozessanalyse
Integration COTS
Kaufmännische
Anwendung
TechnischeAnw
endung
Echtzeitsystem
System
naheAnw
endung
InternetApplikation
Wissensm
gmt.
System
Softwareprojekt A
Softwareprojekt B
Softwareprojekt C
Softwareprojekt D
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 30
Wesentlicher Einflussfaktor für Projektart: Kunde
Projektarten: Auftragsprojekt, Internes Projekt, EntwicklungsprojektAuftragsprojekte
externer (spezifischer) KundeVertraglich geregelte EntwicklungBeispiel: Steuerung eines Presswerks
Internes ProjekteKunde ist internBezahlung mit ”Scheingeld“Beispiel: neues Vertriebssystem in einer Versicherung
Entwicklungsprojekte für den anonymen Marktexterner (anonymer) KundeRepräsentant des Kunden ist MarketingBeispiel: Word
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 31
Unterschied SW-Projekt zu anderen Projekten (1)
Viele Gemeinsamkeiten mit anderen(Entwicklungs-) Projekten, aber ...
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
Projekte
Abwicklungsprojekte Entwicklungsprojekte
Softwareprojekte
Z.B. Bau eines Hauses
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 32
Unterschied SW-Projekt zu anderen Projekten (2)
... Software ist immateriellSoftware und ihre Eigenschaften sind schwer messbar/beurteilbar,Fortschrittskontrolle ist schwierig
... Ergebnisse/Zwischenergebnisse für IT-Laien oft schwer beurteilbarExterne Fortschrittskontrolle schwierigErschwerte KommunikationAnalogie: Beurteilung einer Skizze für ein Haus und eine SW-Architektur
... Software ist ”nicht stetig“Geringe Änderungen haben oft gravierende Auswirkungen
... Umfeldabhängigkeiten sind wenig erforschtAnalogie: Hausbau in Europa, Antarktis, SaharaD.h. Umfeldspezifische Anpassung der Vorgehensweise notwendig
... Wenig gesichertes Wissen über VorgehensmodelleWelches Vorgehensmodell für welches Projekt in welchem Umfeld?
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 33
Unterschied SW-Projekt zu anderen Projekten (3)
... Zusammenhang zwischen Anforderungen und Kosten istAnwendern schwer vermittelbar
Änderungen, die Anwender als „gering“ einschätzt, haben oftgravierende Konsequenzen ( Architektur)
... „Unteilbarkeit“ der Arbeit bei der SoftwareentwicklungZeit kann nicht beliebig über mehr „Manpower“ kompensiert werden
... In der Regel: Mehr AnforderungsänderungenKonsequenz aus schweren (Vorab-) Beurteilbarkeit von Software
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 34
Umfeld und Bestandteile eines Projekts (1)
Unternehmensleitung
Anwender/K
unde
Projektleiter
Projektmitarbeiter
Vorgaben BerichteZiele Ist-Werte
Vorgaben BerichteZiele Ist-Werte
Anforderungen,WünscheZusagen,
Versprechen
Anforderungen,Änderungs-wünsche
(Zwischen-)ProdukteProjekt
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 35
Umfeld und Bestandteile eines Projekts (2)
ProjektManagement
SoftwareEntwicklung
Qualitäts-Management
Konfigurations-Management
Änderungs-wünsche
Anf.
VorgabenZiele
BerichteArbeit-
anweisungVorl.
Ergebnisse
Anforderungen
[nicht ok]
[ok]
Zwischenprodukte
(Zwischen-)Produkte
Fehler, Probleme, Änderungsanträge
Status und Fortschrittsbericht
Entschei-dungen
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
RequirementsManagement
Anforderungen
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 36
Umfeld und Bestandteile eines Projekts (3)
ProjektmanagementTätigkeiten zur Planung, Organisation, Überwachung und Steuerungvon Projekten
KonfigurationsmanagementIdentifikation und Verwaltung von Konfigurationseinheiten(z.B. Dateien), Verwalten von ¨Änderungen
Requirements ManagementBehandelt Änderungen an Anforderungen und sorgt für derenBerücksichtigung im Entwicklungsprozess
Risiko ManagementRisiken (potentielle Gefahren) bewerten, verfolgen und geeigneteGegenmaßnahmen einleiten
QualitätsmanagementTätigkeiten, um die Qualität von Prozessen und Produktensicherzustellen
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 37
Rollen in Softwareprojekten
Hersteller — entwickelt SoftwareProjekteigentümer
der Repräsentant des Herstellers, unter dessen Aufsicht und Verantwortungdas Projekt durchgeführt wird
Projektleiterleitet das Softwareprojekt
EntwicklerAnalytiker, SW-Architekt, Tester, Programmierer, Designer, ...
Kunde — kauft und nutzt die SoftwareAuftraggeber
vertritt Anwender, Management, Beschaffungsstelle, Anwender, usw. desKunden
Wichtig: Abbildung der Rollen auf aktuelles Projekt; interne undexterne Kunden
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 38
Ziele des Managements von Softwareprojekten
GrundsätzlichTermine einhaltenKostenrahmen einhaltenErforderliche Qualität sicherstellen
Dazu notwendig ist eine Mitarbeit beiRealistischen Termin- und KostenplänenSinnvollen Qualitätszielen
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 39
Aufgaben des Projektmanagements (1)
Ziele setzen undplanen
Koordinieren
Kontrollieren Entscheiden
DelegierenOrganisieren
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
MotivierenInformieren und Kommunizieren
Steuern
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 40
Aufgaben des Projektmanagements (2)
Ziele setzen und Planen„Wo kein Ziel ist, ist auch kein Weg“Ziele:
EindeutigWiderspruchsfreiRealistischVerständlich
EntscheidenIn Projekten gibt es viel Entscheidungsbedarf
Initiale Entscheidung über ProjektdurchführungAnalyse-Entscheidungenetc.
Häufiger Fehler:Entscheidungen werden nicht oder zu spät getroffenEntscheidungen sind nicht nachvollziehbar
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 41
Aufgaben des Projektmanagements (3)
DelegierenEiner kann nicht alles machenWichtig: Gleichgewicht von
Funktion/Pflichten/AufgabenVerantwortungMacht/Befugnisse/Rechte
Oft: Nur Aufgabe und Verantwortung, nicht aber RechteKoordinieren
Abstimmen von TätigkeitenZentral: Organisation und Mitarbeiterführung
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 42
Aufgaben des Projektmanagements (4)
OrganisierenFestlegen von Abläufen und ZuständigkeitenStichwort „Projektorganisation“Ablauforganisation: Vorgehen zur Erfüllung bestimmter FunktionenAufbauorganisation: Zuständigkeiten und GliederungDaneben: „Kleinere Organisationsobjekte“, z.B:
MeetingsProjektarchiv
Kontrollieren„Planung ohne Kontrolle ist sinnlos“Ein Projekt ist eine Regelschleife
Frühzeitiges Erkennen von Fehlentwicklungen oder unrealistischenPlanungen
Oft negatives Image (Überwachung)
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 43
Aufgaben des Projektmanagements (5)
MotivierenZentral für den Erfolg des ProjektsAnnahme: Mensch wird durch Streben nach Befriedigung vonGrundbedürfnissen motiviert (Maslow‘sche Bedürfnispyramide)
Informieren und KommunizierenMangelnde Transparenz ist oft Ursache für fehlgeschlagene ProjekteEssentiell: Zielgerichtetes Berichtswesen
Notwendige Informationen kompakt und übersichtlichAber auch: Informelle Kontakte
SteuernVerschiedene Formen des Steuerns, z.B.
Management by Objectives (Führung durch messbare Zielvorgaben)Management by Exception (Routine wird selbständig erledigt)Management by Motivation (Verbinden der individuellen Interessen mitUnternehmenszielen)
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 44
Maslow‘sche Bedürfnispyramide
Entwicklungs-bedürfnisse
(Selbstverwirklichung)
Wertschätzungs-bedürfnisse
(Anerkennung undBestätigung)
Soziale Bedürfnisse (SozialeKontakte, Leben in Gemeinschaft,
Geselligkeit)
Sicherheitsbedürfnisse(Sicherung der Grundbedürfnisse)
Physiologische Bedürfnisse (Essen, Verlangen nachSchlaf, Unterkunft, Sexualität, ...)
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 45
Vorgehensmodelle für die Softwareentwicklung (1)
Ein kurzer Rückblick ...In den 50ern
Kleine, spezialisierte AnwendungHäufig: Programmierer = NutzerKeine Notwendigkeit für explizites Projektmanagement
In den 60ernAnwendungen werden umfangreicher und komplexerSoftwareentwicklung nun in Teams (Arbeitsteilung)Aber: Keine Hilfen zur Strukturierung der Arbeit
1968 NATO Konferenz in Garmisch-Partenkirchen:Begriff Software Engineering
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 46
Vorgehensmodelle für die Softwareentwicklung (2)
Zielsetzung von VorgehensmodellenStrukturierung des Ablaufs von SoftwareprojektenDamit:
Ermöglichen von TeamarbeitGrundlage für qualitativ hochwertiges Endergebnis
Vorgehensmodell zerlegt Softwareentwicklung in Aufgaben
Spezifikation einer Aufgabe
Vor-bedingung
(Entry)
Aufgabe(Task)
Ergebnisse(Exit)
Ausgaben(Output)
Eingaben(Input)
Rückkopplung
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 47
Vorgehensmodelle für die Softwareentwicklung (3)
Folgende Fragen sollten durch ein Vorgehensmodell beantwortetwerden
Wer? VerantwortungWas? AufgabeWarum? Begründung und ZielWann? ZeitpunktWo? Ort, Funktion oder ProduktWie? Art und Weise, AblaufWomit? ArbeitsmittelWonach? Methoden, Normen, StandardsWofür? Zielgruppe
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 48
Einfaches Vorgehensmodell (1)
Analyse undDefinition
Entwurf
Implemen-tierung
Test
Einsatz undWartung
Qualitätssicherung
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 49
Einfaches Vorgehensmodell (2)
Lineare Abfolge mit RücksprüngenGutes Gedankenmodell (Separation of Concerns)In Reinform selten anwendbar
Probleme:Kontrolle des Projektfortschritts nach wie vor schwierigZusammenhänge zwischen Phasen wird leicht vernachlässigtTestaktivitäten werden zu sehr als (späte) Phase betrachtetIn großen Projekten vergeht viel Zeit bis das erste Produkt vorliegt
Viele Varianten des Wasserfallmodells, z.B.Mit PrototypingMehrere „Wasserfälle“ hintereinander (Evolutionäre SW-Entwicklung)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 50
Das V-Modell des Bundes 1997 (1)
Entwicklungsstandard für IT Systeme des Bundes
Entwickelt von IABG (Industrieanlagen- und Betriebsgesellschaft inOttobrunn) und BWB (Bundesamt für Wehrtechnik und Beschaffung)
Ausprägungen für militärische und zivile Anwendungen
Fokus: Systeme (Hardware und Software)
Grundidee:Tailoring, d.h. Anpassung des Standards innerhalb vorgegebenerGrenzen für ein konkretes Projekt
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 51
Das V-Modell des Bundes 1997 (2): Submodelle
Konfigurations-struktur
Projekt planenund kontrollieren
PM
SE
QS KM
Plandaten Istdaten SEU
SEU
QS-Ergebnis
Ist-daten
QS-Anforderung
Produkt
Produktentwickeln
QS-Anforderungen
vorgeben
Produkteprüfen
Produkte/Rechte
verwalten
Produktstrukturplanen
Plan-daten SEU SEUPlan-
datenPlan-daten
Ist-daten
Ist-daten
Produkt
Rechte
Voraussetzungen schaffenund Softwareentwicklungs-
umgebung (SEU) bereitstellen
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 52
Das V-Modell des Bundes 1997 (3): Begriffe
PM - ProjektmanagementQS - QualitätssicherungKM - KonfigurationsmanagementSE - SystemerstellungSEU - Softwareentwicklungsumgebung
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 53
Das V-Modell des Bundes 1997 (4)IT-System/Segment
SE AnwenderforderungenSystemarchitekturTechnische AnforderungenSchnittstellenübersichtSchnittstellenbeschreibungIntegrationsplanSWPÄ-KonzeptBetriebsinformationen
QS System-PrüfspezifikationSystem-PrüfprozedurPrüfprotokoll
SW-KomponenteSE SW-Entwurf
(SW-Komponente)DatenkatalogImplementierungsdokumente(Komponente)
QS Komponenten-PrüfspezifikationKomponenten-PrüfprozedurPrüfprotokoll
SW-ModulSE SW-Entwurf (SW-Modul)
DatenkatalogImplementierungsdokumente (SW-Modul)
QS Modul-PrüfspezifikationModul-PrüfprozedurPrüfprotokoll
Übergreifende ProduktePM Projekthandbuch
ProjektplanAngebotsbewertungKosten-/NutzenanalyseArbeitsauftragBerichtsdokumente
KM KM-PlanKonfigurations-IdentifikationsdokumentDatenkatalogÄnderungsantrag/ProblemmeldungÄnderungsvorschlagÄnderungsauftragÄnderungsmitteilungÄnderungsstatuslisteProjekthistorie
QS QS-PlanPrüfplan
HW-EinheitSE Technische Anforderungen
HW-ArchitekturZeichnungssatzRealisierungsdokumenteAnalysebericht
SW-EinheitSE Technische Anforderungen
SW-ArchitekturBetriebsinformationenImplementierungsdokumente (SW-Einheit)Integrationsplan
QS SW-PrüfspezifikationSW-PrüfprozedurPrüfprotokoll
DatenbankSE SW-Entwurf (Datenbank)
DatenkatalogImplementierungsdokumente(Datenbank)
QS Datenbank-PrüfspezifikationDatenbank-PrüfprozedurPrüfprotokoll
Produkte desV-Modells
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 54
Das V-Modell des Bundes 1997 (5)
Produktinformationen
SE 7-SWSW-Integration
SE 7.1-SW bisSE 7.4-SW
SE 1System-Anforderungs-
analyseSE 1.1 bis SE 1.8
SE 3SW-/HW-Anforde-
rungsanalyseSE 3.1 bis SE 3.5
SE 4-SWSW-Grobentwurf
SE 4.1-SW bis SE 4.3-SW
SE 5-SWSW-Feinentwurf
SE 5.1-SW und SE 5.2-SW
SE 8System-Integration
SE 8.1 bis SE 8.3
System-Ebene
SE 2System-EntwurfSE 2.1 bis SE 2.6
HW-Einheit
Anwenderforderungen
SW-Architektur
Datenkatalog
Integrationsplan
Betriebsinformationen
Schnittstellenbeschreibung
SW-Einheits-/HW-Einheits-
Ebene
Modul-/Datenbank-Ebene
SW-Kompo-nenten-
Ebene
Externe Vorgaben (AG)
Implementierungsdoku-mente (SW-Komponente)
Datenbank
Rahmenbedingungen (für SE 1.7)
SWPÄ-Konzept
Betriebsinformationen
Betriebsinformationen
SW-Entwurf
SW-ModulImplementierungsdokumente
(SW-Modul, Datenbank)
Implementierungsdokumente(SW-Einheit)
SW-Komponente
BetriebsinformationenSystem (installierbar)
Technische Anforderungen
Systemarchitektur
Technische Anforderungen
SE 6-SWSW-ImplementierungSE 6.1-SW bis SE 6.3-SW
System(installiert und in Betrieb)
SE 9Überleitung
in die NutzungSE 9.1 bis 9.3
Betriebsinformationen
Legende:
Prüfaktivitäten(siehe QS)
Schnittstellenübersicht
Schnittstellenbeschreibung
Kosten-/NutzenanalyseAngebotsbewertung
SchnittstellenübersichtNicht-IT-Anteile
SW-Einheit
Protokoll
Funktionsüberblickzum SubmodellSE (Systemerstellung)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 55
Das V-Modell des Bundes 1997 (6): Beschreibung einer AktivitätSE 4.2-SW: SW-interne und -externe Schnittstellen entwerfen
Produktfluß
von nachAktivität Zustand Produkt Aktivität Zustand
SE 1 akzeptiert Anwenderforderungen — —
SE 2 akzeptiert Systemarchitektur — —
SE 3 akzeptiert Technische Anforderungen — —
SE 4.1-SW akzeptiert SW-Architektur — —
SE 4.1-SW akzeptiert Schnittstellenübersicht — —
SE 2 in Bearb. Schnittstellenbeschreibung SE 4.3-SW, SE 5-SW,KM 4.3
vorgelegt
AbwicklungDie beim Entwurf der SW-Architektur in der Schnittstellenübersicht identifizierten Schnittstellen sindin der Schnittstellenbeschreibung im einzelnen detailliert darzustellen. Bereits beschriebeneSchnittstellen sind gegebenenfalls weiter zu präzisieren.IT-Sicherheitsaspekte wie sie bereits bei der Identifikation der Schnittstellen eine Rolle spielten sindhier weiter und mit besonderer Sorgfalt zu verfolgen. Alle Schnittstellen der IT-sicherheitsspezifischenund IT-sicherheitsrelevanten SW-Komponenten/SW-Module müssen mit ihrem Zweck und ihrenParametern beschrieben werden. Die Separierung vom nicht IT-sicherheitsrelevanten Teil mußsichtbar sein.
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 56
V-Modell XT Philosophie: Ziel- und ErgebnisorientierteVorgehensweise
Produkte stehen im MittelpunktProjektdurchführungsstrategien undEntscheidungspunkte geben die Reihenfolge derProduktfertigstellung und somit die grundlegendeStruktur des Projektverlaufs vor.Die detaillierte Projektplanung und -steuerung wird aufder Basis der Bearbeitung und Fertigstellung vonProdukten durchgeführt.Für jedes Produkt ist eindeutig eine Rolle verantwortlichund im Projekt dann eine der Rolle zugeordnete Person.Die Produktqualität ist überprüfbar durch definierteAnforderungen an das Produkt und expliziteBeschreibungen der Abhängigkeiten zu anderenProdukten.
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Quelle: Andreas Rausch
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 57
V-Modell XT: Vorgehensbausteine als modulare Elemente
Vorgehensbausteine sind die modularen Bausteine, aus denen dasV-Modell aufgebaut ist
Ein Vorgehensbausteinkapselt Rollen, Produkte und Aktivitätenist eine Einheit, die eigenständig verwendet werden kannist eine Einheit, die unabhängig veränder- und weiterentwickelbar ist
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Vorgehensbaustein
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 58
V-Modell XT: Projektdurchführungsstrategien undEntscheidungspunkte
Eine Projektdurchführungsstrategie definiert die Reihenfolge derim Projekt zu erreichenden ProjektfortschrittsstufenEin Entscheidungspunkt
definiert einen im Projektplan festzulegenden Zeitpunkt, an dem eine„Fortschrittsentscheidung“ (GO/NO-GO) getroffen wirdlegt eine Menge von Produkten fest, die zum Entscheidungspunkt fertiggestellt sein müssen, damit auf dieser Basis dieFortschrittsentscheidung getroffen werden kann
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Quelle: Andreas Rausch
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 59
Überblick: Entscheidungspunkte im V-Modell XT
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Entscheidungspunkte für die Projekttypen:Systementwicklungsprojekt AuftraggeberSystementwicklungsprojekt AuftragnehmerSystementwicklungsprojekt Auftraggeber/AuftragnehmerEinführung und Pflege eines organisationsspezifischenVorgehensmodells
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 60
Überblick: Entscheidungspunkte im V-Modell XT
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 61
Überblick: Vorgehensbausteine des V-Modell XT
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 62
Beispiele weiterer Vorgehensmodelle
Spiralmodell von BoehmInkrementelle Entwicklung mit expliziter Risikobewertung vor jederIteration
Rational Unified ProcessEntwicklung in IterationenObjektorientierte Software-Entwicklung
Extreme ProgrammingEvolutionäre EntwicklungFunktionalität als wesentliche „Stellschraube“Kombination verschiedener, sich ergänzender Praktiken, z.B.
Pair ProgrammingPlanning GameTest FirstKontinuierliche Code-Integration und Regressionstest
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 63
Beispiele weiterer Vorgehensmodelle
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Spiralmodell von BoehmIterative Entwicklung mitexpliziterRisikobewertung vorjeder IterationReduzierung vonRisiken in großenProjekten
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 64
Beispiele weiterer Vorgehensmodelle
Rational UnifiedProcess
Objekt-orientierteSoftware-EntwicklungUML alsNotation fürProdukte
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
#1 #2 #3 #4 #5 #6 #7 #8
PhasesInception Elaboration Construction Transition
DevelopmentActivities:
Business Modeling
Requirements
Analysis & Design
Implementation
Deployment
Test
Configuration &Change Management
Project Management
Environment
Iteration
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 65
Beispiele weiterer Vorgehensmodelle
Agile Prozesse (XP, Crystal, Scrum, Adaptive SW Development,…)Agile Prinzipien („Agiles Manifest“)
Individuen und Interaktionen wichtiger als Prozesse und WerkzeugeFunktionierende SW wichtiger als umfangreiche DokumentationZusammenarbeit mit Kunden wichtiger als VertragsverhandlungenReagieren auf Änderungen wichtiger als Verfolgung eines Plans
Extreme ProgrammingEvolutionäre EntwicklungFunktionalität als wesentliche „Stellschraube“Kombination verschiedener, sich ergänzender Praktiken, z.B.
Pair ProgrammingPlanning GameTest FirstKontinuierliche Code-Integration und Regressionstest
Skalierungsproblem (Größe, Kritikalität…)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
© 2002-2010, Dr. Frank Houdek, Michael Stupperich, Vorlesung „Management von Softwareprojekten“, Folien Nr. 66
Beispiele weiterer Vorgehensmodelle
CrystalAgile Methodenfamilie (Crystal Clear / Yellow / Orange / Red / ...)Projektspezifische MethodenauswahlAuswahl basierend auf Projektrandbedingungen
# beteiligte Personen KommunikationsformenKritikalität von SW-Defekten Formalität der benutzen Methoden
Adressiert das Problem der SkalierungWeniger “dogmatisch” als XP
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)