Suchen

Klassisch, agil, und dann? – Teil 2

Agile Ansätze im Requirements Engineering

Seite: 4/9

Crystal Methoden

Crystal-Methoden zählen ebenfalls zu den agilen Ansätzen und konzentrieren sich auf, möglicherweise auch parallele, inkrementelle Entwicklungen. Ein Inkrement kann hierbei mehrere Iterationen in Anspruch nehmen. Crystal stellt eine Methodenfamilie dar, die für jedes Projekt eine geeignete Methode als Grundlage bietet. Folgende Aspekte unterstützen die Auswahl:

1) Die Projektgröße, gemessen in der Anzahl der an der Entwicklung beteiligten Personen.
2) Die Kritikalität, d. h. die Höhe des Schadens, der bei Fehlern entstehen kann. Die Skala beginnt mit „etwas weniger Zufriedenheit über die Ergebnisse“, und geht über den „Verlust einer erträglichen Menge Geld“, den „Verlust von sehr viel Geld“ (z. B. bei Firmenbankrott) bis hin zum „Verlust von Menschenleben“.
3) Die Zielsetzung des Projekts: bessere Produktivität, schnellere Fertigstellung, Grundlagenforschung, Gesetzeserfüllung etc.
(Hruschka et al., 2009)

Bildergalerie

Zwei beispielhafte Methoden im Vergleich, siehe Abbildung 3 (Bildergalerie), sind Crystal Clear für unkritische Projekte mit ca. sechs Mitarbeitern und Crystal Orange für größere Projekte mit ca. 40 Mitarbeitern. Crystal setzt auf maximale Selbstorganisation und minimale Kontrolle. Es soll lediglich das geregelt werden, was geregelt werden muss, dies aber auf einfache und effiziente Weise.

Feature Driven Development (FDD)

Das Feature Driven Development, kurz FDD, basiert auf einem Top-Down-Ansatz. Hierbei bilden die von einem Gesamtplan ausgehende funktionale Dekomposition eines Entwicklungsvorhabens und die iterative Umsetzung das Rückgrat der Umsetzung. In Abbildung 4 (Bildergalerie) sind die Prozesse ersichtlich, auf denen FDD basiert. Die letzten beiden werden dabei je Feature iterativ durchlaufen. Die in Phase 2 entwickelte Feature Liste wird vom Team selbst priorisiert. Darüber hinaus empfiehlt FDD eine wöchentliche, ca. 30-minütige Besprechung, in der der Status der einzelnen Features diskutiert wird (Paetsch et al., 2003).

Dynamic Systems Development Method (DSDM)

Die Dynamic Systems Development Method, kurz DSDM, ist keine Methode im engeren Sinne, sondern stellt vielmehr ein Framework zur schnellen iterativen und kollaborativen Softwareentwicklung bereit. Sie eignet sich für kleine und große Projekte und setzt sich aus folgenden sieben Phasen zusammen: Machbarkeitsstudie, Vorprojekt, Business Study, Funktionsmodell, Entwurf und Bau, Durchführung und Post-Project (Qumer und Henderson-Sellers, 2008).

Während der ersten beiden Phasen werden die Basisanforderungen erarbeitet. Hierbei ist DSDM an keine Requirements-Engineering-Technik gebunden, man kann diese also frei wählen. Alle Arten von Tests werden schrittweise durch die Entwickler als auch durch die Benutzer über den gesamten Lebenszyklus durchgeführt. In DSDM-Projekten sind mehrere Teams mit jeweils zwei bis sechs Mitgliedern möglich.

Adaptive Software Development (ASD)

Adaptive Software Development, kurz ASD, ist ähnlich wie Crystal eher eine Philosophie als eine konkrete Methode. Ziel von ASD ist es, aus der Entwicklung heraus zu lernen um das gelernte stets im weiteren Projektverlauf umzusetzen. Daher ist ein ausgeklügelter Zielfindungsprozess Kernbestandteil. Im Mittelpunkt von ASD steht ein adaptiver Lebenszyklus für Softwareentwicklung, der zielorientiert, feature-basiert, iterativ mit Time-Boxing, risikogetrieben und tolerant gegenüber Änderungen ist. Hervorzuheben ist hier das Time-Boxing für jede Iteration. Damit wird gewährleistet, speziell bei Projekten mit hohen Änderungsraten sicherzustellen, dass in kurzen Abständen Ergebnisse produziert werden. Die Teams können geografisch verteilt und in unbegrenzter Größe eingesetzt werden. (Hruschka et al., 2009)

Artikelfiles und Artikellinks

(ID:42704398)