L4-Organisation von Softwareprojekten

Prozessparadigma

1. legt grobe, sehr allgemeine Struktur fest ohne ins detaill zu gehen (Wasserfallmodell, V-Modell, evolutionäre Entwicklung)

2. Grundprinzip eines SW Prozessmodells ohne konkrete Rollen, Zuständigkeiten oder detaillierte Abläufe

SW Prozessmodell-Rahmenwerk

1. Bereits erstellte SW Prozessmodelle sind nicht auf vollständig auf andere Organisationen übertragbar.

2. Deshalb Rahmenwerke, die organisationsspezifische Vorlagen für eigene SW Modelle liefern.

3. Auf Basis des Prozessparadigmas eine detaillierte Beschreibung zu Rollen, Zuständigkeiten, konkreten Aktivitäten und deren Abhängigkeiten (RUP, V-Modell XT, SCRUM)

4. Folgt der vorgegebenen Struktur des Prozessparadigmas

5. Berücksichtigt organisationsspezifische Bsonderheiten

6. Ist ein transparentes Artefakt für alle Beteiligten

Individuelles SW Prozessmodell

1. Auf Basis des SW Prozessmodell-Rahmenwerke werden individuelle SW Prozessmodelle erstellt.

2. Für alle Beteiligten wird die Organisation und der Ablauf transparent beschrieben.

3. Welche Aktivitäten, Reihenfolge, Rollen- und Organisationsverantwortlichkeit, Werkzeuge und Methoden, erzeugte und verarbeitete Objekte

SW Prozess

1. Konkretes SW Projekt mit individueller ausprägung des SW Prozessmodells. (z.B. Neuentwiklung des Bestandssystems)

2. Was wird von wem wann dgf.

3. Welche Objekte werden wann verarbeitet

Ist das älteste Prozessparadigma

Entspricht der schrittweisen Bearbeitung von Anforderungen, Analysen, Entwürfen, Implementierungen, Tests und dem Betrieb in einer festgelegten Reihenfolge.

Wasserfall: Reihenfolge von oben nach unten

Erst wir eine Phase vollständig abgearbeitet, dokumentiert und die Qualität sichergestelllt, bevor es weiter geht.

Benachbarte Phasen können bei gefundenen Fehlern rückgekoppelt werden.

Das Wasserfallmodell gibt den früher unstrukturierten SW Projekten eine Struktur, welche Transparenz durch klare Phasen gibt. Zuständigkeiten und Fortschritte sind damit messbar.

Die festgelegte Reihenfolge der Phasen steht allerdings im Gegensatz zur Natur des Erkenntnisgewinns von SW Projekten.

1. Problem: Die Anforderungen an das System steht nicht zu Beginn fest.

2. Die strikte Einhaltung der Phasen verhindert den Start von Nachfolgephasen bereits fertiggestellter Einzelelemente.

3. Ist ein großer Teil des Systems spezifiziert, aber nicht alles, dann darf mit der Architektur oder der Implementierung trotzdem nicht begonnen werden.

4. Die einzelnen Phasen sind erst mit der Dokumentation und Qualitätssicherung abgeschlossen und verhindern ein Weitermachen ohne diese Aspekte.

Das Wasserfallmodell ist aus moderner Sicht eine Orientierungshilfe. Eine klare Abgrenzung mit strikter Einhaltung der vollständigen Dokumentation und Qualitätssicherung sind oft in der nächsten Phase mit neuen Erkenntnissen obsolet.

Es ist ein Prozessparadigma und ist die Basis verschiedener SW Prozessmodelle im öffentlichen Sektor.

Grundgedanke ist die 1:1 Zuordnung von konstruktiven (links) und qualitätssichernden (rechts) Phasen.

Der SW Prozess durchläuft eine Reihenfolge von festgelegten Phasen.

Jeder Konstruktionsphase werden konkrete Teststufen zugeordnet

Jede Phase muss abgeschlossen sein, um die nächste Phase zu beginnen.

Allgemeines Vorgehensmodell, dessen Grundidee die Erstellung des SW Systems in mehreren sich wiederholenden Zyklen ist.

Mit jeder Version wächst der Funktionsumfang des zu erstellenden SW Systems.

Erkenntnisse des vorigen Zyklus fließen in den Folgezyklus ein.

Statt vollständiger Dokumentation und SPezifikation, steht die Version lauffähiger SW im Vordergrund.

Zyklus:

1. Welche Funktionen sollen im Zyklus umgesetzt werden

2. Umsetzen der Funktionen

3. Integration neuer Funktionen in das bestehende System

4. Testen, bewerten der aktuellen SW

Die Evolutionäre Entwicklung dreht sich im Kreis

Die SW Engeneering Kernaktivitäten werden nicht in Phasen mit einer abschließenden Dokumentation dgf, sondern verzahnen sich mit jedem Zyklus weiter ineinander. Dabei wird der Erkenntnisgewinnungsprozess berücksichtigt. Fehler und Ungenauigkeiten können schnell erkannt und behoben werden. Zusätzlich ist das System schnell verfügbar und lauffähig (zumindest in Teilen).

Da es keine definierten Phasen gibt, werden auch keine vollständigen Spezifikationen erhoben. Der Funktionsumfang wird erst in der Entwicklung festgelegt. Aus Managementperspektive ist dieses Vorgehen unstrukturiert und Ziellos.

Es besteht die Gefahr, die nötige Evolution der Systemarchitektur und Systemdokumentation zu vernachlässigen.

1. Die Architektur - Degeneriert mit jeder Änderung des Quellcodes. Je mehr Änderungen, desto unstrukturierter das Vorgehen und die Auswirkungen sind nicht mehr abschätzbar.

2. Dokumentation - unvollständig, nicht aktuell. Die Programmcodes lassen sich nachträglich im Reengeneering nur schwer herausfinden.

3. Bestehende Funktionen dürfen in der Weiterentwicklung nicht beeinträchtigt werden oder bereits behobene Fehler einbringen.