Projektmanagement und Softwareentwicklung

Transkript

1 Projektmanagement und Softwareentwicklung Prozess und Einteilung Prof. DI Dr. Erich Gams htl ITP Theorie HTL-Wels

2 Softwareentwicklung und Projektmanagement Softwareentwicklung Projektmanagement Qualitätsmanagement Projektstart Projektende Prof. DI Dr. Erich Gams

3 Interessantes zu Risiken in Softwareentwicklungsprojekten 50% aller IT Projekte Überschreiten Budget um durchschnittlich 80% Realisieren durchschnittlich nur 60% des geplanten Leistungsumfangs im Projektzeitraum Die teuersten Fehler werden sehr früh gemacht sehr spät entdeckt Wichtigster Problemkreis: Kommunikation mit dem Kunden/Benutzer Das Problem verschärft sich Komplexere Probleme Anspruchsvollere Kunden Steigende Dynamik

4 Fehler/Kosten Zusammenhang nach Barry Boehm

5 Ablauf von Kundenprojekten (Jonas Keith)

6 Wie vermeiden? Qualität erhöhen Produktqualität

7 Qualitätskritererien für Produkte nach ISO/IEC 9126 (DIN 66272) Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit

8 Wie die Produktqualität erhöhen? Qualität des Herstellungsprozesses erhöhen Entwicklungsprozess definieren Prof. DI Dr. Erich Gams No reproduction without written permission

9 Softwarequalität Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozess bestimmt Eigenschaften und Qualität des Produktes. Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Geringe Qualität bewirkt hohe Fehlerrate hohe Wartungskosten schlechte Strukturierung/ Dokumentation hohe Änderungskosten Methoden (UML), Modelle (Use Case Diagramm)

10 Vorgehensmodelle Vorgehensmodelle (auch Prozessmodelle genannt) beschreiben den organisatorischen Rahmen für eine (System )Entwicklung. Metapher Vorgehensmodell: Was ist wann zu tun? Vorgehensmodelle sollen zu einer disziplinierten, sichtbaren und kontrollierbaren Entwicklung führen. Vorgehensmodelle legen u.a. fest: durchzuführende Aktivitäten, Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasen) Definition der Teilprodukte / Ergebnisse (Inhalt, Layout) Fertigstellungskriterien, Verantwortlichkeiten und Kompetenzen, Notwendige Mitarbeiterqualifikationen, Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge

11 Vorgehensmodell Um Systeme und Software sinnvoll entwickeln zu können wurden Vorgehensmodelle geschaffen, um Arbeit und Ergebnisse... effizienter effektiver...zu gestalten Vorgehensmodelle unterteilen sich in klassisch agil UML dient z.b. als standardisierte Modellierungssprache

12 Vorgehensmodelle Klassische Vorgehensmodelle = schwergewichtige Prozessmodelle statisch dokumentenorientiert teuer gut geeignet für große Projekte Agile Vorgehensmodelle = leichtgewichtige Methoden flexibel kundenorientiert chaotisch gut geeignet für kleine Projekte und Teams

13 Vorgehensmodelle Entstehung seit 60er Jahren Rational Unified Process (RUP) Spiralmodell V Modell Wasserfallmodell Prototyping

14 Wasserfallmodell (entnommen aus G. Pomberger)

15 Wasserfallmodell Vorteile: Phasen werden in der richtigen Reihenfolge und vollständig durchlaufen. Am Ende einer Phase steht ein Dokument (dokumentengetrieben). Entwicklungsablauf ist grundsätzlich sequentiell. Unterstützt ein Top Down Vorgehen. Ist einfach, verständlich und benötigt wenig Management Aufwand. Nachteile: Feste, sequentielle Reihenfolge und vollständiges Durchlaufen einer Phase ist nicht immer sinnvoll. Dokumentation ist gegebenenfalls wichtiger als das System selbst. Eventuell werden Risikofaktoren zu wenig berücksichtigt

16 V Modell Erweiterung des Wasserfall Modells, das Qualitätssicherung integriert Verifikation und Validation werden Bestandteile des Modells Verifikation: Überprüfung der Übereinstimmung zwischen einem Produkt und seiner Spezifikation "Funktioniert das Produkt so wie angegeben? Ist das System richtig gebaut? Validation: Eignung bzw. Wert eines Produkts bezogen auf seine Einsatzzweck Validierung in der Informatik und Softwaretechnik ist die dokumentierte Beweisführung, dass ein System die Anforderungen in der Praxis erfüllt

17 V Modell Entwickelt ab ~1990 für Bundeswehr und später für weitere Behörden (Bundesverwaltung). Submodelle für Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM). Ursprünglich für eingebettete Systeme entwickelt

18 V Modell Vorteile Integrierte, detaillierte Beschreibung von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement Generisches Vorgehensmodell Gut geeignet für große Projekte Nachteile Unkritische Übernahme der Konzepte, die für eingebettete Systeme entwickelt wurden, für andere Anwendungstypen Software Bürokratie bei kleinen & mittleren Projekten Ohne CASE Unterstützung nicht handhabbar

19 Prototyping 2011 Prof. DI Dr. Erich Gams Seite 19/51

20 Prototypenmodell Prototypen Bei unklaren Anforderungen Bei alternativen Lösungen. Zur Klärung der Anforderungen, zum Experimentieren, um praktische Erfahrungen zu sammeln, als Diskussionsbasis

21 Prototypen Modell 1/2 Ein Software Prototyp ist nicht das erste Muster einer großen Serie (beliebig kopierbar, Massenfertigung)... ist keine Simulation, sondern zeigt ausgewählte Eigenschaften des Zielprodukts im praktischen Einsatz (vgl. z.b. Windkanal oder Architekturmodell)

22 Prototypen Modell 2/2... dient zum Klären von relevanten Anforderungen oder Entwicklungsproblemen.... dient als Diskussionsbasis für Entscheidungen.... dient zu experimentellen Zwecken und Sammeln von praktischen Erfahrungen Prof. DI Dr. Erich Gams Seite 22/51

23 Ziel Wegwerfprototyp Die Implementierung des Prototyps wird bei der Implementierung des Zielsystems nicht weiterverwendet. Der Prototyp dient nur als Modell. Wiederverwendbarer Prototyp Wesentliche Teile des Prototyps werden bei der Implementierung des Zielsystems übernommen 2011 Prof. DI Dr. Erich Gams Seite 23/51

24 Das Prototypen Modell Exploratives Prototyping Dazu wird auf Basis der Anwendung und Kundenvorstellungen ein Prototyp entwickelt. Beim explorativen Prototyping geht es zuvorderst um die Funktionalität des Prototyps, weniger um dessen Qualität. Experimentelles Prototyping (Pilotsystem) vollständige Definition von Teilsystemen für deren Implementierung. Mit dem experimentellen Ansatz soll die Funktion der Teilsysteme nachgewiesen werden und die Schnittstellen der Teilsysteme überprüft werden. Evolutionäres Prototyping Es geht darum, das System schrittweise nach den exakten Anwenderspezifikationen aufzubauen. Jeder Zwischenschritt dient als Grundsystem für die inkrementelle Weiterentwicklung, basierend auf weiteren Anwenderspezifikationen. Das evolutionäre Prototyping ist eine Vorgehensweise bei dem der Prototyp das fertige Produkt darstellt Prof. DI Dr. Erich Gams Seite 24/51

25 Prototypen Modell Ein fertiges Software Produkt besteht aus vielen Komponenten und Ebenen. Horizontaler Prototyp realisiert nur einen ausgewählten Bereich einer Architektur. (z.b.: GUI Prototyp) Vertikaler Prototyp Teil des Systems über alle Schichten der Architektur hinweg erstellt wird. (Komplexe Funktionalität)

26 Prototypen Modell 2011 Prof. DI Dr. Erich Gams Seite 26/51

27 Prototyping (nach G.Pomberger)

28 Prototypenmodell PLUS Prototypen reduzieren das Entwicklungsrisiko. Prototypen können in andere Vorgehensmodelle "integriert" werden. Schnelle Prototypentwicklung durch entsprechende Werkzeuge möglich. Prototypen fördern die Kreativität

29 Prototypenmodell MINUS Höherer Entwicklungsaufwand, da Prototypen zusätzlich erstellt werden. Gefahr der Weiterverwendung von (Wegwerf ) Prototypen. Grenzen von Prototypen sind oft nicht erkennbar. Bei Fremdentwicklung vertraglich schwer zu fassen Prof. DI Dr. Erich Gams Seite 29

30 Evolutionäres/Inkrementelles Modell Die Evolutionäre Entwicklung hat zum Ziel, ein Projekt in überschaubare, eigenständige Teilprojekte zu zerlegen, um frühzeitig ein funktionsfähiges Teilprodukt ausliefern zu können Ausgangspunkt sind Kernanforderungen. Diese führen zu einem Kernsystem (Nullversion). Erfahrungen mit der Version führen zu neuen, ergänzenden Anforderungen. (Evolution) Inkrementelle Vorgehensweise hat von Beginn an zum Ziel, einsetzbare Teilprodukte in der vorgegeben Qualität als Ergebnis der Systementwicklung zu erzeugen

31 Variation des evolutionären Modells Hier werden zunächst die Anforderungen vollständig erfasst. Anschließend werden wiederholt Teile der Anforderungen umgesetzt Prof. DI Dr. Erich Gams Seite 31/51

32 Evolutionäres/Inkrementelles Modell enge Zusammenarbeit Auftraggeber und Auftragnehmer Dies bringt auch entsprechende Konsequenzen für die vertraglichen Abmachungen, das Projektmanagement und die Verrechnung der Leistungen mit sich Prof. DI Dr. Erich Gams Seite 32/51

33 Evolutionäres/Inkrementelles Modell Vorteile: Einsatzfähige Produkte in kürzeren Zeitabständen. Kombinierbar mit Prototypen Modell. Auswirkungen des Produkteinsatzes lassen sich untersuchen. Die Richtung der Entwicklung ist leichter steuerbar. Statt einem Ergebnis gibt es mehrere (Zwischen) Ergebnisse. Nachteile: Falls Kernanforderungen übersehen werden, muss ggf. die Systemarchitektur überarbeitet werden. Sind die Zwischenergebnisse an die Anforderungen ungeplanter Evolutionspfade leicht anpassbar?

34 Spiralmodell Das Spiralmodell [Boehm 1988] ist es ein risikogetriebenes Vorgehensmodell für die Entwicklung. Das Prinzip des Spiralmodells ist das wiederholte Durchlaufen (in Iterationen) von vier Schritten: 1. Risikoanalyse Beschreibung von Rahmenbedingungen, Zielen und (Lösungs )Alternativen 2. Evaluierung der (Lösungs )Alternativen und auf dieser Basis Erkennen von Risiken und Ausarbeiten adäquater Strategien zur Minderung/Vermeidung etc. 3. Planung: In Abhängigkeit von den identifizierten Risiken, wird das Vorgehen für die nächste Iteration festgelegt. 4. Review:der vorangegangenen Schritte und Planung der nächsten Iteration 2011 Prof. DI Dr. Erich Gams Seite 34/51

35

36 Spiralmodell Zentral beim Spiralmodell ist die Erstellung von Prototypen zur kontinuierlichen Prüfbarkeit des Systems > Risikoerkennung und Reaktion. Die stetige Weiterentwicklung der Prototypen profitiert vom Wissenszuwachs, sodass davon ausgegangen wird, dass der Prototyp bis zum finalen, betriebsbereiten System wächst Prof. DI Dr. Erich Gams Seite 36/51

37 Spiralmodell Das Vorgehen, insbesondere für die Entwicklung der Software, kann in den einzelnen Iterationen variieren. Die Variation ist abhängig von den erkannten bzw. verbleibenden Risiken und muss im 3. Schritt für das weitere Vorgehen ausgewählt werden. Spiralmodell ist ein Rahmen, der in Abhängigkeit der Kritikalität mit konkreten Vorgehensweisen (Methoden) auszugestalten ist. Dabei kann der Fokus auf der Prototyprealisierung verbleiben oder aber auch ein Wasserfall artiges Vorgehen zum Einsatz kommen Prof. DI Dr. Erich Gams Seite 37/51

38 Agile Methoden Einige der bisher entstandenen Methoden: Adaptive Software Development (ASD) Crystal Dynamic System Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Lean Development (LD) Pragmatic Programming Scrum Prof. DI Dr. Erich Gams No reproduction without written permission

39 Phasen der Software Entwicklung Analyse Problemanalyse, Ist Situation erheben, Planung, Definition der Ziele, Ressourcenplanung, Lastenheft Definition/Spezifikation Anforderungsdefinition, (Anforderungen ermitteln, festlegen, beschreiben, validieren) Prämissen für die Realisierung, Pflichtenheft Entwurf Architektur, Komponenten, Schnittstellen Implementierung / Test Codierung / Generierung Test / Abnahme / Einführung Übergabe, Abnahmetest, Installation, Schulung, Inbetriebnahme Wartung Fehlerbeseitigung, Änderungen, Optimierung

40 Begleitende Phasen Projektmanagement Laufendes Controlling Qualitätsmanagement Konfigurationsmanagement Dokumentation Prof. DI Dr. Erich Gams No reproduction without written permission

41 Softwareentwicklungsprozess Wasserfallmodell 2011 Prof. DI Dr. Erich Gams Seite 41/51

42 Projektmanagementprozess 2010 Prof. DI Dr. Erich Gams Seite 42/51

43 Softwareentwicklung und Projektmanagement Softwareentwicklung Projektmanagement Qualitätsmanagement Projektstart Projektende Prof. DI Dr. Erich Gams No reproduction without written permission

44 Projektmanagementprozess Pflichtenheft Projektauftrag Kick-Off-Meeting 2010 Prof. DI Dr. Erich Gams Seite 44/51

45 Projektmanagementprozess aus 2011 Prof. DI Dr. Erich Gams Seite 45/51