Klassisch, agil, und dann? - Teil 3

Beyond Agile - Die Zukunft des Requirements Engineering

< zurück

Seite: 3/8

Anbieter zum Thema

RE-GSD: Requirements Elicitation for Global Software Development Projects

In der wissenschaftlichen Literatur finden sich spannende Lösungsansätze, die die genannten Herausforderungen adressieren. Z.B. beschäftigen sich Arenda et al (2010) in ihrer Arbeit mit den kognitiven Unterschieden der verschiedenen Stakeholder sowie den speziellen Charakteristika globaler Softwareentwicklungsprojekte. Angelehnt an die Methode von Christel und Kang (1992) schlagen sie ein erweitertes Framework vor, das die speziellen Rahmenbedingungen globaler Entwicklungsteams adressiert.

Abb. 3: Evaluierung projektkritischer Faktoren in RE-GSD. Durch ihre Identifikation können geeignete Gegenstrategien entwickelt werden.(Quelle:  Eigendarstellung, angelehnt an Aranda et al., 2010)
Abb. 3: Evaluierung projektkritischer Faktoren in RE-GSD. Durch ihre Identifikation können geeignete Gegenstrategien entwickelt werden.
(Quelle: Eigendarstellung, angelehnt an Aranda et al., 2010)

RE-GSD (Requirements Elicitation for Global Software Development Projects) ergänzt Christel und Kang insbesondere um Strategien, die die Kommunikation in verteilten Umgebungen unterstützen sollen. Kurz zusammengefasst konzentriert sich Phase 1 auf die Sammlung von Daten zu Personen, Standorten und Organisationen, die in den Prozess der Anforderungserhebung involviert sind. Hierzu zählen kulturelle Aspekte, Erfahrungshorizont, vertraute Technologien, genutzte Groupware. Phase 2 dient der Identifikation potenzieller Probleme sowie der Erarbeitung geeigneter Strategien. Welche Erkenntnisse aus Phase 2 konkret gezogen werden können, verdeutlicht Abbildung 3. Z.B. lässt sich durch die Erhebung von Zeitunterschieden errechnen, wie viel gemeinsame Arbeitszeit zur Verfügung steht.

Drei weitere Strategien, die RE-GSD charakterisieren, sind zu nennen: Hierzu zählen kulturelle Trainings und die Verwendung von Ontologien zur Verbesserung der Kommunikation. Der dritte Ansatz schlägt die Erhebung und Berücksichtigung verschiedener kognitiver Profile der Stakeholder vor mit dem Ziel, die geeignetste Toolunterstützung zu finden.

DisIR – verteiltes, internetbasiertes Requirements-Engineering

Einen Ansatz für verteiltes, internetbasiertes Requirements-Engineering stellt DisIRE dar (Geisser et al., 2007). Der Fokus liegt auf einer effizienten Einbindung aller Beteiligten auf Basis von Internettechnologien, wodurch die Anzahl an persönlichen Treffen reduziert wird. Gleichzeitig soll durch den intensiven, technologiegestützten Austausch aller Interessenvertreter die Qualität der Anforderungsspezifikation erhöht werden.

Abb. 4: Rollen mit den zugehörigen Aufgaben bei der Anforderungserhebung und -Analyse mit DisIRE (Quelle:  Geisser et al., 2007)
Abb. 4: Rollen mit den zugehörigen Aufgaben bei der Anforderungserhebung und -Analyse mit DisIRE
(Quelle: Geisser et al., 2007)

Ein drittes Ziel von DisIRE liegt in der methodischen Unterstützung für alle RE-Phasen. Nach einem initialen Treffen erfolgt eine asynchrone Anforderungserhebung- und Analyse gefolgt von den klassischen Phasen Anforderunsspezifikation und Anforderungsmanagement. Die Rollen und zugehörigen Aufgaben in DisIRE sind in Abbildung 4 dargestellt. DisIRE nutzt im Verlauf dieser Phasen Kommentarfunktionen, Glossare, Wikis, ein integriertes Versionierungssystem, grafische Analysen sowie Use-Case-Templates.

Wiener und Stephan (2010) identifizieren in ihrer Arbeit insbesondere eine Forschungslücke bei der Anforderungsvalidierung in OSE-Projekten und stellen mit Reverse Presentations (RPM) eine Methode vor, die diese Lücke adressiert. Hauptziel von RPM ist es, ein fundiertes, gemeinsames Verständnis auf Kunden- und Dienstleisterseite zu schaffen und so den Transfer von Wissen und die Validierung von Anforderungen über räumliche, zeitliche und kulturelle Hürden hinweg zu optimieren.

Abb. 5: Iterativer RPM-Prozess (Quelle:  Wiener und Stephan, 2010)
Abb. 5: Iterativer RPM-Prozess
(Quelle: Wiener und Stephan, 2010)

Der iterative RPM-Prozess ist in Abbildung 5 dargestellt. Wesentlich ist, dass der Offshore-Partner die Anforderungen seines externen/internen Kunden iterativ erhebt. Dabei wird den klassischen RE-Phasen Erhebung, Spezifizierung und Validierung eine initiale Zielerklärungsphase voran gestellt. Im Laufe jeder Iterationen erfolgt ein Rollentausch zwischen Kunde und Anbieter, der den gegenseitigen Verständnisgrad erhöhen soll: Während in der Zielerklärungsphase der externe oder interne Kunde seine Anwendungsfälle dem Offshore-Partner übergibt, präsentiert dieser diese nach einer genaueren Spezifikation im Rahmen einer „Reverse Presentation“. Ergänzend kombiniert der Ansatz die Konzepte des persönlichen und verteilten RE, um die Vorteile beider Methoden zu kombinieren (Carmel und Tjia, 2005).

Artikelfiles und Artikellinks

(ID:42709892)

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung