SWT - 3 Prozessmodelle

• Sehr detailliert
• Anpassbarkeit durch Maßschneidern der Lösung
• Sehr strukturiertes Vorgehen
• Geeignet für große Projekte
• Berücksichtigung der Hardware

• für kleine/mittlere Entwicklungen: zu große Bürokratie
• hohe Komplexität: CASE Unterstützung notwendig
• hohe Einarbeitungszeit
• wenig Trennung von Daten und Funktionen

1. Systemerstellung (SE)
2. Projektmanagement (PM)
3. Qualitätssicherung (QS)
4. Konfigurationsmanagement (KM)

Gründe dafür:

• Fehlende Vorstellung von Lösungswunsch oder fehlendes Wissen, was möglich ist beim Auftraggeber
• Auftragnehmer weiß nicht, ob Produkt technisch realisierbar
• Auftragsvergabe erleichtert durch Präsentation der Technik
• Zeitliche Vorteile (Geschwindigkeit) ???

• Reduzierung des Entwicklungsrisikos,
• „schnell“ erstellbar (geeignete Werkzeuge)
• Unterstützen Kreativität für Alternativlösungen
• Benutzer-und Auftraggeber-kommunikativ
• Können sinnvoll in andere Prozessmodelle integriert werden
• Erfahrungsunterstützend

• Höherer Entwicklungsaufwand (meist zusätzlich)
• Gefahr, „Wegwerf-Prototyp“ = Endprodukt
• Prototyp = Ersatz für (fehlende) Dokumentation

• Auftraggeber kann seine Anforderungen häufig nicht vollständig am Anfang formulieren
• Die Benutzer können sich noch nicht vorstellen, was auf sie zukommt und was sie wollen
• Während der Entwicklung ergeben sich „Zusatzwünsche“
• Nach Produkteinsatz werden Veränderungen gewünscht

• Sich aufbauendes lauffähiges Produkt
• Einsatzfähige Zwischenstadien
• Benutzerbeteiligung
• „schnelle“ Verbesserung / Ausbesserung des Produktes

• Produktkern muss evtl. bei neuer Version neu angepasst werden (wenn Kernanforderungen „übersehen“ wurden)
• (eventuell) mehr Kosten und mehr Zeit

= stufenweise Entwicklung mit ständigen Rücksprungmöglichkeiten

Vorgehensweise:

• Implementierung eines Produktkerns (Kern- oder Mussanforderungen) nach Minimalanforderungen vom Auftraggeber
• Test der „Nullversion“
• Ermittlung von neuen Anforderungen nach Erfahrungen mit der letzten Version“
• Entwicklung einer neuen Version und erneutes Testen

• Hin zu wiederverwendbaren Software – Komponenten (aus früheren Entwicklungen, Einkauf von vorhandene Lösungen)
• Anwendung von objektorientierten Methoden
• OO-Software-Entwicklung auf allen Ebenen anwendbar (Definieren, Entwerfen, Implementieren)
• Gut kombinierbar mit evolutionären und Prototypen – Modell
• Management und Verwaltung sehr wichtig
• Zeit- und Kostenersparnis bei richtiger Anwendung

• Produktivitäts- und Qualitätsverbesserung
• Wiederverwendung und „Zukauf“ vorhandener Komponenten

• Optimale Zeitausnutzung (Parallele Entwicklung, Minimierung von trial and error, Beachtung arbeitsorganisatorischer Aktivitäten)
• Frühes Erkennen und Eliminieren von Problemen

• Einsatz von objektorientierte Methoden für volle Nutzung des Modells Voraussetzung
• Verwaltung und Verwendung des Wiederverwendungsarchivs

• Parallelisierung von Aktivitäten
• Ab Beginn Zusammenarbeit aller Entwicklungsteams (inkl. Fertigung, Marketing und Verkauf)
• Genaue Klärung aller Anforderungen
• Management sehr wichtig
• Minimale Entwicklungszeit

• Erfordern viele organisatorische und technische Maßnahmen
• Hoher Planungs- und Personalaufwand
• Wenn zu späte Entscheidungen, dann Iterationen notwendig
• Empfehlenswert nur für „sichere“ Entwicklungen

Metamodell (Boehm) Risikogetriebenes Modell (Minimierung Risiko als Ziel) Zielbestimmung beinhalten auch Qualitätsziele

iterative Vorgehensweise - mehrmaliges Durchlaufen eines Zyklus

• Schritt 1: Ziele, Alternativen, Randbedingungen
• Schritt 2: Evaluierung Alternativen, kosteneffektive Strategie
• Schritt 3: Wahl des geeigneten Prozessmodells oder Kombinationen dessen
• Schritt 4: Überprüfung Schritte 1 – 3, Planung nächster Zyklus

Fläche der Spirale stellt Kosten und Winkel Entwicklungs-fortschritt dar -> Spirale so eng wie möglich halten

• Überprüfung und erneute Festlegung des Prozessablaufs in periodischen Intervallen
• Frühzeitiges Eliminieren von Fehlern und ungeeigneten Alternativen
• Flexibles Modell (keine Festlegung auf ein Prozess – Modell)
• Einfache Umstrukturierung der Entwicklung bei auftretenden Risiken

• Hoher Managementaufwand
• Für kleine und mittlere Projekte nicht empfehlenswert
• Keine Trennung zwischen Entwicklung und Wartung