Kurs:Wirtschaftsinformatik SS09/SE1/Lernskript/Spiralmodell

In dem Paper „A Spiral Model of Software Development and Enhancement“ von Barry Boehm, wird das Problem der Softwareprozessmodellsituation dargestellt. Das Problem hierbei ist es, ein Modell zu entwickeln, dass eine Abfolge in der ein Software Projekt realisiert werden soll darstellt und dass dieses Modell gleichzeitig auf jeden Softwareentwicklungsprozess anwendbar sein muss.

Die Lösung dieses Problems hat Boehm mit seinem Spiralmodell erzielt. Ein wesentlicher Aspekt der Lösung besteht darin, dass Boehm mit seinem Modell die Stärken aller vorherigen Prozess Modelle vereinigt und gleichzeitig deren Probleme behebt. Sein Modell gibt eine Anleitung welches Modell bzw. welche Kombinationen von Modellen am besten zu dem jeweiligen Softwareentwicklungsprozess passt. Ein weiterer Aspekt der Lösung besteht darin Risiken im Entwicklungsprozess frühzeitig zu erkennen um diese zu umgehen oder zu beheben. Ein letzter ebenfalls wichtiger Aspekt des Spiralmodells ist es, dass mit jedem abgeschlossenen Zyklus ein Rückblick verbunden ist, in dem Entwickler, Kunden oder Wartungsfirmen untereinander kommunizieren um eventuell entstandene Fehler zu beheben.

Das Spiralmodell ist die beste Lösung für das Problem der Softwareprozessmodellsituation, weil sich dieses an den guten Merkmalen der existierenden Modelle bedient und deren Schwächen aufgrund des risikogeführten Zugriffs vermeidet. Trotzdem hat das Modell noch drei große Schwierigkeiten die es zu beheben gilt: Es passt noch nicht auf alle Softwaretypen, es verlässt sich stark auf die Fähigkeiten der Entwickler um Risiken zu erkennen und es muss noch intensiver weiterentwickelt werden.

Die wesentlichen Unterschiede zu anderen Modellen bestehen darin, dass das Spiralmodell risikogeführt ist und dass lediglich die Vorteile der anderen Modelle verwendet werden.

Mein Review

Barry Boehm - A Spiral Model of Software Development and Enhancement In dem Paper „A Spiral Model of Software Development and Enhancement“ von Barry Boehm wird das Problem der Softwareprozessmodellsituation dargestellt. Er zeigt darin, mit welchem Vorgehensmodell man die Abfolge der Software-Entwicklungsaktivitäten reihen kann mit Hilfe von Zyklen innerhalb von Spiralen. Die Einführung von spiralförmiger Arbeitszyklen hat den Vorteil beliebige Software-Entwicklungsmethodologien integrieren zu können, denn es wird nicht speziell konkretisiert, welches Software-Prozessmodell oder Software-Prozess angewandt werden soll. In diesem Sinne ist das Spiral Modell ein Metamodell, sozusagen eine Bühne für die konkreteren Lebenszyklusmodelle, Software-Prozessmodelle und Software-Prozesse.

Wir wollen die Aspekte des Spiralmodells erläutern, und zeigen, welche Probleme damit gelöst werden.. Ein wesentlicher Aspekt der Lösung besteht darin, dass Boehm mit seinem Modell die Stärken aller vorherigen Prozess Modelle vereinigt und gleichzeitig deren Probleme behebt. Denn bei unerwartet auftauchenden Schwierigkeiten, ist es immer möglich die Spirale nochmals zu durchlaufen und den Zyklus intensiver zu bearbeiten. Es können zu einem Teilproblem Mini- Spiralen durchgeführt werden, um gute Lösungen zu erzielen. Auch parallel durchlaufende Spiralen sind denkbar, um zwei voneinander unabhängige Code-Artefakte zu erzeugen. (Z.B. wenn man einen robusten Code erzeugen möchte, ist es sinnvoll zwei voneinander unabhängige Software Entwicklungsteams am selben Problem arbeiten zu lassen. Die Fehler der Teams werden sich voneinander unterscheiden und aus dem Vergleich beider Code-Artefakte erhält man einen robusteren Code.) Ein typischer Zyklus im Spiralmodell beginnt mit der Identifikation des Gegenstandes oder Teilaspekt des Produktes, das ausgearbeitet werden soll. Das ist z.B. die Performanz, die Funktionalität, Veränderbarkeit). Nachdem die Risiken identifiziert sind, können Alternativen entworfen werden, und deren Risikobelastung miteinander verglichen werden, indem die Randbedingungen wie Kosten, Arbeitsplan, Interface usw. als Bewertungsmaßstab für die Risikobelastung herangezogen werden. Sein Modell gibt eine Anleitung welches Modell bzw. welche Kombinationen von Modellen am besten zu dem jeweiligen Softwareentwicklungsprozess passt. Ein weiterer Aspekt der Lösung besteht darin, Risiken im Entwicklungsprozess frühzeitig zu erkennen, um diese zu umgehen, oder gleich ganz zu beheben. Sofort stellt sich die Frage, wie man es anstellt Risiken zu erkennen. Die Risikoidentifikation bei einem Software-Projekt ist beim Compilerbau sicherlich anders anzustellen als bei einem Social Networking Portal. Ausserdem hängt die Fähigkeit Risiken zu erkennen, stark von der Branchenerfahrung der Software-Entwickler und der Organisationskultur im Software-Betrieb ab.

Der Werkzeugkasten für die Risikoerkennung soll kurz aufgezählt werden: 1. Prototyping 2. Simulation 3. Benchmarking 4. User-generierte Fragen und Fehlermeldungen 5. Analytische Modelbildung Diese Werkzeuge können in der Praxis miteinander kombiniert werden. Insbesondere das Prototyping auf Papier ist eine geeignete Methode, um frühzeitig billig die Risikolandschaft im Bereich der Benutzerfreundlichkeit zu erschliessen. Ein letzter ebenfalls wichtiger Aspekt des Spiralmodells ist es, dass mit jedem abgeschlossenen Zyklus ein Rückblick verbunden ist, in dem Entwickler, Kunden oder Wartungsfirmen untereinander kommunizieren um eventuell entstandene Fehler zu beheben.

Das Spiralmodell ist die beste Lösung für das Problem der Softwareprozessmodellsituation, weil sich dieses an den guten Merkmalen der existierenden Modelle bedient und deren Schwächen aufgrund des risikogeführten Zugriffs vermeidet. Trotzdem hat das Modell noch große Schwierigkeiten die es zu beheben gilt: Es passt noch nicht auf alle Softwaretypen, es verlässt sich stark auf die Fähigkeiten der Entwickler um Risiken zu erkennen, und es muss noch intensiver weiterentwickelt werden.

Vier fundamentale Fragen sind nicht beantwortet worden: 1. Wie entsteht und startet man einen Zyklus in der Spirale ? 2. Wie kommt man rechtzeitig auf sinnvolle Weise aus einer Spirale ? 3. Warum müssen manchmal abrupt der Spiraldurchlauf abgebrochen werden ? 4. Was machen wir im Spiralmodell, wenn wir die Software warten oder weiterentwickeln wollen ? Die wesentlichen Unterschiede zu anderen Modellen bestehen darin, dass das Spiralmodell risikogeführt ist, und dass lediglich die Vorteile der anderen Modelle verwendet werden. Aus der Integration der anderen Modelle sind aber neue fundamentale Probleme entstanden, wie man die neu gewonnene Flexibilität und Freiheit anpasst an Terminbeschränkungen, Budgetrestriktionen, Evolutionsarbeiten und Rollen- und Zuständigkeiten: wer soll z.B. das Recht haben einen neuen Zyklus zu starten oder abzubrechen. Wie soll die Dokumentation der Software während der Entwicklung organisiert werden.

• Kein Lebenszyklusmodell an sich, sondern Metamodell
  • Beinhaltet andere Modelle und behandelt diese als Spezialfälle
• Enthält Beschreibung wie Elemente der unterschiedlichen Lebenszyklusmodelle miteinander verzahnt sind
• Iteratives und inkrementelles Modelle (vier sich wiederholende Schritte):
  • Ziele, Randbedingungen und Alternativen identifizieren
  • Risiko – Management
  • Entwicklung & Test von Teilergebnissen
  • Review (Rückblick) des Resultate und Planung der nächsten Phase

• Risiko – Management besondere Rolle: in jeder Phase Test und Suche von Alternativen um Risiken zu erkennen und frühzeitig zu umgehen

• Hauptaktivitäten:
  • 1) Ziele, Randbedingungen und Alternativen identifizieren
  • 2) Evaluieren der Alternativen, Identifizierung und Überwindung der Risiken,
  • 3) Entwicklung und Verifikation des Produktes der nächsten Generation,
  • 4) Planung der nächsten Phase (inkl. Review über vorherige Phase)

Vorteile

• Überprüfung in regelmäßigen Abständen
• Qualitätssicherung
• Festlegung des Ablaufs abhängig von Risiken
• Flexibles Modell
• Prozess – Modell nicht für gesamte Entwicklung
• Integration anderer Modelle als Spezialfälle
• Fehler und ungeeignete Alternativen frühzeitig entfernt
• Umdirigieren wesentlich einfacher

Nachteile

• Hoher Managmentaufwand
• Nicht (weniger) für kleinere bis mittlere Projekte geeignet
• Wissen über Risiken noch nicht weit genug verbreitet