In diesem Artikel zeige ich, wie man die Auswahl eines Vorgehensmodells argumentativ untermauern kann und so das passende und richtige Vorgehensmodell für das spezielle Softwareentwicklungsprojekt findet.

 

Agile Softwareentwicklung

Agile Softwareentwicklung im Allgemeinen ist für unser Vorgehensmodell im Projekt nicht sinnvoll. Die Gründe dafür sind Folgende: Bedingt durch die abzuliefernden Teilleistungen steht in unserem Projekt die Dokumentation in der Wichtigkeit höher als die funktionierende Software. Dies bedeutet zwar nicht, dass die Software nicht funktionieren sollte, jedoch würde eine funktionierende Software ohne Abgabe der hier von der Priorität nicht so hoch eingestuften Planungsdokumente (PSP, PAP, Aufwandsschätzung, Kostenplanung, Risikoliste) mit dem geforderten Detaillierungsgrad zu einer schlechten Bewertung führen. Weiterhin ist zwar eine Rückkopplung mit der Auftraggeberin zwar ausdrücklich in unserem Projekt angestrebt, jedoch ist nicht zu erwarten, dass hier Änderungswünsche “on the fly” umgesetzt werden müssen. Zu guter Letzt streben wir an, zum Beginn der Softwareentwicklung ein stabiles Fachkonzept zu haben. Somit ist es nicht erforderlich, dass wir schnell auf Veränderungen reagieren müssen.

Extreme Programming

Um im Speziellen Extreme Programming auszuschließen wird angeführt, dass wir nicht anstreben viele Releases zu produzieren. Es ist somit kein „Planing-Game“ mit Zuordnung des „User-Stories“ zu einem Release erforderlich.

Scrum

Aufgrund der Projekttätigkeit neben der normalen Arbeit und der dadurch relativ kurzen Projektdauer, ist es nicht praktikabel alle 30 Tage (oder in einem kürzeren Rhytmus) Sprints durchzuführen. Auch ist es aufgrund der virtuellen Teams und der persönlichen Zeiteinteilung der Entwickler nicht möglich, tägliche Stand-Up-Meetings durchzuführen, daher kommt Scrum nicht in Frage.

V-Modell XT

Aufgrund unserer geringen Projektgröße mit sechs Personen ist das V-Modell XT nicht praktikabel. Es wäre hier erforderlich, dass eine Person gleichzeitig mehrere Rollen übernehmen müsste. Weiterhin ist es aufgrund der Projektgröße schwer von der Kapazität zu bewältigen, wenn wir alle im V-Modell XT zu erstellenden Dokumente (dokumentenorientierter Ansatz) erstellen müssen. Es wäre zu befürchten, dass aufgrund des Overheads am Ende keine lauffähige Software, die von der Auftraggeberin gefordert wird, herauskommt. Zudem haben bisher in unserem Team noch nicht alle Personen mit dem V-Modell XT gearbeitet. Dies würde also für einige eine tiefere Einarbeitung bedeuten, damit alle Prozesse richtig umgesetzt werden können.

Rational Unified Process

Beim Rational Unified Process spricht zum einen gegen den Einsatz, dass unser Team in diesem Vorgehensmodell nicht flächendeckend geschult ist. Unser Projekt ist jedoch auch nicht in der Zielgruppe des Vorgehensmodells, da es für eine industrielle Softwareentwicklung entwickelt wurde, welche in diesem Projekt jedoch nicht angestrebt wird.

Spiralmodell / Prototype

Das Spiralmodell ist iterativ und inkrementell, wobei mehrere Prototypen erstellt werden. In unserem Projekt wird es jedoch aufgrund des vollständigen Lastenhefts und des überschaubaren Projektumfangs keine Iterationen geben. Wir haben lediglich am Anfang einen Prototyp erstellt, der im Rahmen des Softwareentwicklungsprozesses zur fertigen Anwendung weiterentwickelt wird.

Entscheidung zwischen Wasserfallmodell und V-Modell

Wir haben nun alle Vorgehensmodelle bis auf zwei verbleibende ausgeschlossen, das Wasserfallmodell und das V-Modell. Um uns zwischen diesen zu entscheiden, haben wir die Argumente für das eine oder andere erörtert.

Argumente für das Wasserfallmodell

Für das Wasserfallmodell spricht, dass wir eine kurze Projektdauer haben und ein kleines Projektteam. Weiterhin sind vor Beginn des Entwicklungsprozesses alle Anforderungen bekannt und es ist nicht mit Änderungen im Fachkonzept zu rechnen. Auch die Risiken können wir sehr gut von Anfang an überblicken. Die Termine (Meilensteine) stehen wie die für die Teilleistungen zu erstellenden Dokumente von Anfang an fest. Wegen unserer nebenberuflichen Projektarbeit ist es für uns wichtig ein Einfaches uns überschaubares Vorgehensmodell zu haben, welches für unser kleines Team gut handhabbar ist.

Argumente für das V-Modell

Auf der anderen Seite spricht jedoch für das V-Modell, dass in Erweiterung zum Wasserfallmodell in diesem die Qualitätssicherung durch Verifikation und Validierung fest einbezogen wird. Gerade der Part Qualitätssicherung wird in unserem Projekt durch zwei Personen begleitet, womit dieser bei unserer kleinen Projektgröße ein relativ großes Gewicht hat. Wir werden mit Ausnahme der Entwicklung der Komponente “Karteikartenrückseite anzeigen” im Bereich Realisierung mehr das Web-CMS Drupal und die dort verwendeten PHP-Module konfigurieren. Somit sind keine umfangreichen Komponententests durchzuführen. Der geplante Komponententest der Komponente “Karteikartenrückseite anzeigen” verdeutlich jedoch unser Bestreben durch Validierung innerhalb des V die Qualitätssicherung zu berücksichtigen. Es ist auch ein kleiner Integrationstest der Komponente in das PHP-Template angedacht. Weiterhin macht die Realisierung einen ersten Systemtest, um eine abnahmefähige Software sicherzustellen. Der Abnahmetest wird dann durch das ganze Team in Verantwortung der zwei für Qualitätssicherung zuständigen Personen durchgeführt. Man sieht jedoch hier, dass durch die Betonung der Qualitätssicherung eher das V-Modell geeignet ist.
Auch bei der Dekomposition des Lastenhefts in einen fachlichen und technischen Systementwurf bzw. eine Komponentenspezifikation ist bei uns im Projekt geplant. Es ist vorgesehen im Projektverlauf aus dem Fachkonzept eine funktionalen Systementwurf und eine Komponentenspezifikation für die jQuery-Komponente zu erstellen. Da im Bereich des CMS vorhandener Code konfiguriert wird, wird auf das technische Design von Drupal verwiesen. Dieses Vorgehen würde auch für eine Anwendung des V-Modells sprechen. Weiterhin haben wir im Projekt ein Risikomanagement initiiert. Dies ist auch mit dem V-Modell möglich.

Unter Betrachtung aller Argumente für das Wasserfallmodell und das V-Modell haben wir uns im Team für das V-Modell entschieden.

siehe auch: http://www.elektronikpraxis.vogel.de