Management von Softwareprojekten - Universität Ulm · 20% 25% 30% 35% bis 20% 21-50% 51-100% 101-200% 201-400% über 400% Grad der Kostenüberschreitung Anteil Projekte 0% 5% 10%

© 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


Kapitel 1

Einleitung und Grundlagen


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)


„Sag mir, wie Dein Projekt anfängt,und ich sage Dir, wie es endet“

1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)


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




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


Chaos Report, The Standish Group, 1995


49%

46%

33%

53%

28%

40%

31%

23%


Quelle: CHAOS Report, The Standish Group International, Inc.


28%

26%

27%

16%1994

1996

1998

2000

Succeeded

FailedChallenged

0% 20% 40% 60% 80% 100%



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%)


Chaos Report, The Standish Group, 1995 Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen

Legende


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


Quelle: Interne Untersuchung bei Bosch


Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen

Legende

Kein Bezug zu Vorlesungsthemen



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


Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen

Legende

Kein Bezug zu Vorlesungsthemen


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]



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“)



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



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)


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



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



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



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



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)



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


Dr. Frank Houdek

Michael Stupperich


Web-Site der Vorlesung



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.



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)


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



Spannungsfeld eines Projekts

Kosten

Qualität(Funktionalität)

Zeit(Termin)



Spannungsfeld eines Projekt (erweitert)

Kosten Termin

Qualität Umfang

KonstanteFläche


„Teufelsquadrat“ nach Sneed


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)


„Teufelsquadrat“ nach Sneed


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



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



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



Unterschied SW-Projekt zu anderen Projekten (1)

Viele Gemeinsamkeiten mit anderen(Entwicklungs-) Projekten, aber ...


Projekte

Abwicklungsprojekte Entwicklungsprojekte

Softwareprojekte

Z.B. Bau eines Hauses



... 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?




... 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



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




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


RequirementsManagement

Anforderungen



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



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



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)


Aufgaben des Projektmanagements (1)

Ziele setzen undplanen

Koordinieren

Kontrollieren Entscheiden

DelegierenOrganisieren


MotivierenInformieren und Kommunizieren

Steuern



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




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




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)




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)



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, ...)



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)



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




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



Einfaches Vorgehensmodell (1)

Analyse undDefinition

Entwurf

Implemen-tierung

Test

Einsatz undWartung

Qualitätssicherung



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)



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



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



Das V-Modell des Bundes 1997 (3): Begriffe

PM - ProjektmanagementQS - QualitätssicherungKM - KonfigurationsmanagementSE - SystemerstellungSEU - Softwareentwicklungsumgebung



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



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



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


Legende:

Prüfaktivitäten(siehe QS)

Schnittstellenübersicht

Schnittstellenbeschreibung

Kosten-/NutzenanalyseAngebotsbewertung

SchnittstellenübersichtNicht-IT-Anteile

SW-Einheit

Protokoll

Funktionsüberblickzum SubmodellSE (Systemerstellung)



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.



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.


Quelle: Andreas Rausch


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


Vorgehensbaustein


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


Quelle: Andreas Rausch


Überblick: Entscheidungspunkte im V-Modell XT


Entscheidungspunkte für die Projekttypen:Systementwicklungsprojekt AuftraggeberSystementwicklungsprojekt AuftragnehmerSystementwicklungsprojekt Auftraggeber/AuftragnehmerEinführung und Pflege eines organisationsspezifischenVorgehensmodells


Überblick: Entscheidungspunkte im V-Modell XT



Überblick: Vorgehensbausteine des V-Modell XT



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





Spiralmodell von BoehmIterative Entwicklung mitexpliziterRisikobewertung vorjeder IterationReduzierung vonRisiken in großenProjekten



Rational UnifiedProcess

Objekt-orientierteSoftware-EntwicklungUML alsNotation fürProdukte


#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



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…)




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


Documents

Management von Softwareprojekten - Universität Ulm · 20% 25% 30% 35% bis 20% 21-50% 51-100% 101-200% 201-400% über 400% Grad der Kostenüberschreitung Anteil Projekte 0% 5% 10%