Kapitel 6 - Prozessmodelle
|
Inhalt
|
- Softwarekrise
- Code-and-Fix-Modell, Wasserfallmodell
- Evolutionäres Modell, Inkrementelles Modell
- Transformationsmodell, Prototyping und Spiralmodell
- Vergleich der verschiedenen "Live Cycle Modelle"
|
Probleme der industriellen Softwareproduktion
- Softwareentwicklung ist ein Prozess von Planung und Management
- Implementierung wird begonnen, nachdem das Problem verstanden wurde
- Problem ist Softwareentwicklung vergeht nicht linear (Feedback Loops notwendig)
Lebenszyklus eines Softwareprodukts
... - Aufgabenstellung - Entwicklung - Nutzung - Aufgabenstellung - ...
Deailiert z.B. durch Phasen des Wasserfallmodells
- Analyse
- Entwurf
- Implementierung
- Integration
- Installation
- Wartung
Software Produktionsprozess - Prozessmodelle
Code-and-Fix-Modell, Wasserfallmodell
Code-and-Fix-Modell und Softwarekrise
- Früher ein Person pro Softwareprojekt
- Problem was gut verständlich und einfach
- Softwareentwicklung bestand nur im Coding
- 2 Phasen: Programmierung und Fehler entfernen
- Probleme des Code and Fix Modells:
- Nach mehreren Änderungen am Code wird Struktur unübersichtlich und schlecht
- Es wird immer schwerer neue Änderungen einzubauen
Software Krise
- 1960 startet Entwicklung großer Software Systeme
- Grundproblem überall: overbuget und Zeitverzug
- Zu lösende Probleme wurden nicht gut erkannt und verstanden
- Mitarbeiter verbrachten mehr Zeit mit gegenseitiger Kommunikation als mit Codieren
- Änderungen von ursprünglichen Systemanforderungen
- Entwickler verliesen Projekte
- Original System Anforderungen wurden nachträglich geändert
Software Engineering wurde geboren, um nach einem Ausweg aus diesen Problemen zu suchen
Softwarekrise:
"In verschiedenen Erscheinungsformen uns ständig begleitende
Erscheinung, die ausdrückt, dass der zu leistende Aufwand für
Softwareherstellung und -betrieb die dafür zur Verfügung
stehenden Kräfte übersteigt oder in Kürze übersteigen wird."
Wasserfallmodell
- Machbarkeitsstudie
- Anforderungsspezifikation und -analyse
- Entwurf
- Coding und Modultests
- Implementation und System Tests
- Übergabe und Wartung
Nachteil ist der streng sequentielle Ablauf der Phasen.
Machbarkeitstudie
Kosten abschätzen und alternative Lösungen suchen.
Ziel:
- Problemdefinition
- Alternative Lösungsvorschläge
- Benötigte Ressourcen und Kosten
Spezifikation und Analyse der Anforderungen
Notwendige Qualitätsmerkmale spezifizieren:
- Funktionalität
- Performance
- Benutzbarkeit
- Portabilität...
Beschreibt das "Was" umzusetzen ist, nicht das "Wie"!
Ziel: Anforderungsspezifikation (Pflichtenheft)
Entwurf
Hier erfolgt die Dekomposition des Systems in Module. Die Entwurfsspezifikation beinhaltet
- Beschreibung der Softwarearchitktur (Module, Beziehungen)
- Abstraktionslevel (Uses, Is-Component Of...)
- Detailierte Modulschnittstellen
Codieren und Testen
- Programmierung der Module
- Module Testen und Debuggen
- System Tests nach Implementation
- Alpha-Tests (reelle Umstände aber vorgegebene Benutzer)
- Beta-Tests (reelle Umstände und ausgewählte Kunden als Nutzer)
Lieferung und Wartung
Wartung macht über 60% der Produktkosten aus:
- Korrigierende Wartung (errors)
- Perfektionierende Wartung (Performance)
- Adaptive Wartung (Erweiterungen oder Änderungen) -> Evolution
Vor- und Nachteile des Wasserfallmodels
- Kein Feedback zu Vorgängerphasen
- Starrheit der Phasen
- Frühe Fehler haben schwere Folgen
- Anforderungsspezifikation meistens unvollständig
- Nur limitierte Informationen verfügbar
- Kostenabschätzung und Planung kann nur nach einer gewissen Analysestattfinden
- Benutzer wissen oft nicht die genauen Anforderungen einer Applikation
- Wasserfallmodell bezieht nicht Anticipation Of Changes ein
- Dokumentbehafteter Prozess, da jede Phase tipparbeit voraussetzt
Evolutionäres Modell
- "Machs doppelt" Prinzip
- Erstversion eines Produktes ist ein Wegwerfprototyp
- Wird als Versuch betrachtet, um Machbarkeit und Anforderungen zu analysieren und zu verifizieren
- Problem ist das Zeitloch zwischen Anforderungsdefintion und finaler Delivery des Produktes bleibt
- Lösung des Problems: Inkrementelles Vorgehen
Inkrementelles Modell für die Implementierung
- Wasserfallmodell wird bis zum Entwurf angewendet
- Dann wird schrittweise vorgangen
- Schnittstellen, welche späteres Hinzufügen von Subsystemen erlauben
- Code-And-Tests + Integrate+Tests
- Jeder inkrementelle Schritt wird separat entworfen, codiert, getestet und integriert
- Die Schritte werden einer nach dem anderen entworfen
- Erst nach Feedback mit Kunden implementiert
Prototyping
- Evolutionäres Prinzip um den Lebenszyklus zu strukturieren
- Display bzw. GUI enthalten
- Dummy Funktionen
- Gutes Werkzeug, um Anforderungen des Kunden zu verfeinern
Transformationsmodell
Softwareentwicklung hier eine Folge von Schritten, welche Spezfifikation in Implementation überführt.
Die Transformationenen erfolgen Manuell oder Semi-automatisch.
Zwei Hauptschritte:
- Anforderungsanalyse (und Verifikation dieser)
- Optimierung (und Tuning an dieser)
Spiralmodell
- Ist ein Metamodell welches auf alle Modelle angewandt werden kann
- Identifizieren und Entfernen von Risiken schon beim Entwurf
- Es ist zyklisch und nicht linear wie das Wasserfallmodell
- Es findet also in jedem Druchlauf erneut eine Risikoanalyse statt
- Bei jedem Durchlauf entsteht neuer Prototyp
- Stage 1: Ziele, Anforderungen und Alternativen identifizieren
- Stage 2: Alterativen untersuchen, Prototyping und Simulationen
- Stage 3: Entwicklung und Verifikation
- Stage 4: Ergebnisse untersuchen und nächste Iteration planen
Bewertung von Prozessmodellen
- Wasserfallmodell: Dokumentationsbasiert
- Evolutionäres Modell: Inkrementell
- Transformationsmodell: Spezifikationsbasierend
- Spiralmodell: Risikobasierend
- Prototyping: Endnutzerbezogen
Prototyping:
- Unterstützt GUI Design
- Vermindert Risiken wie Aufhalt an unnötigen Aspekten
- Hift sich auf relevanten Probleme zu konzentrieren
- 40 % weniger Entwicklungszeit und Quellinstruktionen
Softwaremethodologien - Vorteile, Nachteile
- Methode = ein Weg etwas zu tun
- Methologie = ein System von Methoden, unterstützt von einem Werkzeug
- Standarts: Methologien werden zu firmenweiten wiederverwendbaren Packeten zusammengefaßt
Vorteile:
- Führt den Programmierer durch alle Phasen
- Lernt Unerfahrene an (Wie Problem systematisch Lösen?)
- Standartisierte Problemlösungsstrategien
Nachteile:
- Fehlende formelle Untersuchungen
- Verbrauchen viel Personal - aufwendig
- Es braucht manchmal mehr zeit die Methologie zu verstehen, als das Problem
Comparison of Life Cycle Models
| Comparison of Life Cycle Models |
| Build-and-Fix |
Fine for small programs that do not require much maintenance |
Totally unsatisfactorily for nontrivial programs |
| Waterfall |
Disciplined approach
Document driven |
Delivered product may not meet client's needs |
| Rapid Prototyping |
Ensures that delivered product meets client's needs |
A need to build twice. Cannot always be used |
| Incremental |
Maximizes early return on investment.
Promotes maintainability |
Requires open architecture. May degenerate into buildand-fix. |
| Synchronize and stabilize |
Future user's needs are met.
Ensures components can be successfully integrated |
Has not been widely used other than in Microsoft. |
| Spiral |
Incorporates features of all the above models |
Can be used only for largescale products.
Developers have to be competent at riskanalysis |
| Quelle: University Of California |
Strukturierte Analyse und Entwurf
- Funktionsmodellierung: Datenflussdiagramme, Data Dictionary,Prozessspezifikationen
- Datenmodellierung: ER-Modell
- Ereignismodellierung: Endliche Automaten, Petri-Netze
Qualitätskriterien für Entwicklung
Integration, Einsetzbarkeit, Adäquatheit, Erlernbarkeit
Wiederverwendbarkeit , Werkzeugunterstützung und Wirtschaftlichkeit
Jacksons strukturierte Programmierung
- Jackson Program Design Methodology oder Jackson Structured Programming (JSP)
- Methode für Entwurf und Modellierung "im Kleinen"
- Entwurf beginnt mit Untersuchung von dem was bekannt ist
- In mehreren Iterationen wird ein Modell basierend auf Data-Structured Methoden erstellt
- aus der Beschreibung der Ein-/Ausgabe-Datenstrukturen und ihren Beziehungen zueinander wird direkt die Feinstruktur des Kontrollflusses abgeleitet
|
|
|
|
|
| Kapitel 1 | Einleitung |
|
Einführung, Geschichte...
|
| Kapitel 2 | Eigenschaften |
|
Filtern und Trennen, Modularisierung...
|
| Kapitel 3 | Strukturierte Analyse |
|
Strukturierte und OO-Analyse, Petri-Netze
|
| Kapitel 4 | Spezifikation |
|
Risikoanalyse, Modellierungshilfen, Spezifikationen
|
| Kapitel 5 | Entwurfsprozess |
|
Entwurf, DFD, Tests, UI...
|
| Kapitel 6 | Prozessmodelle |
|
Softwarekrise, Lebenszyklusmodelle...
|
| Kapitel 7 | CASE und PM |
|
CASE, Projektmanagement...
|
| Kapitel 8 | Software-Metriken |
|
Softwarequalität, Entwurfsmetriken...
|
| Kapitel 9 | Programmierungskonzepte |
|
Legacy Systeme, Reengineering...
|
|
|
|
|
|
|
Quellen:
|
Petr Kroha
Softwaretechnologie
|
Prof. Kroha
Vorlesungsskript
|
L. Rosenhainer
Vorlesungsskript
|
Word Wide Web
Verschiedenste Seiten
|
|
|
|
|
|
|