Hybrid Vorgehenmodell
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.
Inhaltsverzeichnis
Ü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 e.V. 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 erfolgreich 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
4 Weblinks
http://hpm.mastersoft.at Offizielle Seite zum Hybrid Vorgehens Modell
5 Init-Quelle
Entnommen aus der:
Erster Autor: MasterSoft angelegt am 30.10.2009 um 15:34,
Alle Autoren: MasterSoft , LKD
Hast du einen Löschwunsch oder ein anderes Anliegen? Dann nutze bitte unser Kontaktformular
PlusPedia Impressum
Bitte Beachte:
Sämtliche Aussagen auf dieser Seite sind ohne Gewähr.
Für die Richtigkeit der Aussagen übernimmt die Betreiberin keine Verantwortung.
Nach Kenntnissnahme von Fehlern und Rechtsverstößens ist die Betreiberin selbstverständlich bereit,
diese zu beheben.
Verantwortlich für jede einzelne Aussage ist der jeweilige Erstautor dieser Aussage.
Mit dem Ergänzen und Weiterschreiben eines Artikels durch einen anderen Autor
werden die vorhergehenden Aussagen und Inhalte nicht zu eigenen.
Die Weiternutzung und Glaubhaftigkeit der Inhalte ist selbst gegenzurecherchieren.