Hybrid-Vorgehensmodell

Das Hybrid- Vorgehensmodell ist eine Kombination aus theoretischem Wissen des Software Project Engineerings und den praktischen Anforderungen der täglichen Entwicklungsarbeit. Da es sich um eine Vereinigung von strukturierten Vorgehensweisen wie dem V-Modell XT und agilen Praktiken wie Extreme Programming handelt, wird dieses Modell von den Verfassern auch als Vorgehensmodell zur strukturiert agilen Softwareentwicklung bezeichnet. Einer der Gründe, diese zunächst unterschiedlichen Ansätze zu vereinen, ist es, dass agile Vorgehensweisen, im Gegensatz zu den strukturierten, zu meist nur für Projekte mit geringem Human Ressource Aufwand empfohlen werden, jedoch den Entwicklern, die neben den Kunden im Mittelpunkt des Prozesses stehen (müssen), ein großes Maß an Flexibilität gewährt, welches auch bei großen Projekten unabdingbar ist. Des Weiteren zielt dieses Modell nicht auf einen strikten Fahrplan für Softwareprojekte ab, sondern bietet dem Anwender die Möglichkeit verschiedene Praktiken anzuwenden und somit auf die Rahmenbedingungen des jeweiligen Projektes und der ausführenden Organisation einzugehen.

Übrigens: Die PlusPedia ist NICHT die Wikipedia.
Wir sind ein gemeinnütziger Verein, PlusPedia ist werbefrei. Wir freuen uns daher über eine kleine Spende!

1 Geschichte

Entwickelt wurde das Vorgehensmodell im Rahmen der wissenschaftlichen Arbeit „Hybrid- Vorgehensmodelle in der Softwareentwicklung“ an der Fachhochschule Kufstein. Hier wurden verschiedenste Vorgehensweisen zur Softwareentwicklung theoretisch analysiert und auf die Möglichkeit zur Entwicklung eines einheitlichen Modells untersucht.

Der erste praktische Einsatz erfolgte in einem Team von Softwareentwicklern für ein Projekt eines Unternehmens aus der 3D-Computergrafik und Simulationsbranche. Vor allem wurde hier auf die Anpassung des Vorgehensmodells (Tailoring) auf die Rahmenbedingungen und Eigenschaften des Unternehmens Wert gelegt.

Auf dem 14. Workshop der Fachgruppe WI-VM9 der Gesellschaft für Informatik der TU München wurde das Vorgehensmodell einem Fachpublikum vorgestellt und in einer weiteren Arbeit veröffentlicht.

Derzeit wird das Vorgehensmodell von der Firma MasterSoft Software Solutions für alle Entwicklungsprojekte eingesetzt und weiterentwickelt.

2 Details

2.1 Pooling

Um den Anwendern die verschiedenen Komponenten des Vorgehensmodells zur Verfügung zu stellen werden sogenannte „Pools“ verwendet. Die verschiedenen Pools (Techniken, Rollen, Threads) beinhalten jeweils statische und optionale Komponenten. Die statischen Komponenten garantieren den strukturierten Ablauf des Projektes. Optionale Komponenten dienen dazu dem Anwender dynamische und agile Werkzeuge zu bieten.

2.1.1 Techniken-Pool

Da der Mensch im Mittelpunkt des Prozesses steht soll das Vorgehensmodell nur wenige Angaben über die jeweiligen Techniken machen die für die Realisierung der Aufgaben verwendet werden. Das Vorgehensmodell beinhaltet lediglich Vorgaben zu den Techniken, welche einen strukturierten Projektablauf ermöglichen.

Basistechniken:

Kundenintegration in allen Phasen
Programmierstandards
Nachhaltiges Tempo
Fortlaufende Integration
Schlankes Design

Aus den optionalen Techniken kann der Anwender je nach Projektgröße und Unternehmensstruktur wählen. Damit das Vorgehensmodell auch an die Rahmenbedingungen des Projektes angepasst wird, muss dieser Pool mit eigenen Techniken der jeweiligen Organisation erweitert werden.

Beispiele für optionale Techniken sind:

Kurze Releasezyklen
Standup- Meetings
Retrospektiven
Gemeinsame Verantwortlichkeit
Team- Verantwortlichkeit
Metapher
Programmieren in Paaren
Modelle
Code- Reviews (Analyse von Sourcecode in einem Team von Entwicklern)

2.1.2 Rollen-Pool

Um auch für kleine Entwicklungsprojekte geeignet zu sein sind diese Techniken wieder in statische und optionale Bestandteile gegliedert. Die Basis-Rollen stellen einen gemeinsam Nenner für alle Projekte dar.

Basis Rollen:

Kunden
Entwickler
Business Owner

Optionale Rollen:

Tester
Terminmanager
Projekt- Coach
Berater
Team- Coordinator
Team- Leader

Dem Anwender steht es wie immer frei eigene optionale Rollen für das jeweilige Projekt einzuführen.

2.1.3 Thread-Pool

Die einzelnen Threads werden dabei über die gesamte Projektlaufzeit ausgeführt. wobei jedem Thread 1 bis n Rollen als ausführende Instanzen zugeordnet sind. Je nach Projektgröße kann eine Rolle nur einem Thread oder auch mehreren Threads zugeordnet werden. Das Vorgehensmodell definiert dabei keinerlei Regeln welche Rolle einem bestimmten Thread zugeordnet ist, da sich das Rollenkonzept mit der Größe des Projektes verändert, wenn neue Rollen hinzugefügt werden. Die Zuteilung der einzelnen Threads zu bestimmten Rollen muss während der Projekt- Analyse erfolgen, wenn die Threads für das Projekt geplant werden.

Die Basisthreads aus dem Threadpool des Vorgehensmodells bilden ein Framework, welches, ähnlich dem V-Modell Kern, ein Minimum an Projektdurchführungsqualität gewährleisten soll. Dabei müssen diese Basis- Threads an die Größe des Projektes angepasst werden

Basis-Threads:

Projektmanagement – Thread
Konfigurationsmanagement – Thread
Bug tracking – Thread

Als optionale Threads definiert das Vorgehensmodell lediglich 2 Threads:

Der Qualitätsoptimierungs- Thread
Der Projektcontrolling – Thread

2.2 Entwicklungsprozess

Das Hybrid- Vorgehensmodell definiert eine Projektdurchführungsstrategie, welche als Hauptprozess des Entwicklungsprojektes angesehen werden kann. Das primäre Endprodukt dieses Entwicklungsprozesses sollte dabei ein fehlerfreies Softwareprodukt sein. Dabei sollte der Hauptprozess Threads beinhalten, welche für die Unterstützung, Anpassung und Optimierung des Vorgehens in einem Projekt eingesetzt werden können. Diese Projektdurchführungsstrategie sollte dabei wieder eine Anpassung des Vorgehensmodells auf die Projektgröße unterstützen.

Der Entwicklungsprozess gliedert sich in die Phasen:

Analyse
Design
Implementierung
Nachbearbeitung

2.3 Iteration X

Die Phase „Implementierung“ des Entwicklungsprozesses beinhaltet 1-x Iterationen, wobei eine Iteration der Implementierung einer bestimmten Anforderung (Feature ) entspricht. Eine Iteration gliedert sich in die Phasen:

Analyse
Design
Implementierung
Testen
Refactoring
Intergation

Rückkoppelungen zwischen den einzelnen Phasen sind möglich.

3 Weiterführende Literatur

Kleinheinz. Christian: Hybrid- Vorgehensmodelle in der Softwareentwicklung - Diplomarbeit, Austria: FH- Kufstein, 2006
Reinhard Höhn, Marco Kuhrmann, Roland Petrasch, Stephan Höppner: Vorgehensmodelle und Projektmanagement - Assessment, Zertifizierung, Akkreditierung (14. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.V.(GI)), Shaker Verlag, 2007