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. Das Vorgehensmodell macht mit diesem Basis- Thread lediglich Basis- Vorgaben welche in einem Entwicklungsprojekten ein Minimum an Projektdurchführungsqualität gewährleisten.

BeI großen Entwicklungsprojekten müssen diese Threads entsprechend erweitert werden. Bei er Durchführung eines Großprojektes mit erhöhtem Formalisierungsgrad könnte beispielsweise der Projektmanagement Thread ähnlich dem Vorgehensbaustein Projektmanagement aus dem V-Modell XT realisiert werden.

Da die Qualitätssicherung der erzeugten Softwareprodukte durch ständige Testphasen als integraler Bestandteil des Vorgehensmodells realisiert ist, wurde dieser Vorgehensbaustein nicht als Thread mit in das Vorgehensmodell aufgenommen.

Die Aktivitäten des Problem und Anderungsmanagement werden ebenfalls implizit in jeder „Requirement Specification“ Phase des Projektes durchgeführt, da der Kunde seine Anforderungen an das System weiter konkretisieren kann, wodurch Änderungen der Anforderungen identifiziert und realisiert sowie Probleme des Systems eliminiert werden können.

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 Basis- Threads des Hybridvorgehensmodells sind:

• Projektmanagement – Thread
• Konfigurationsmanagement – Thread
• Bug tracking – Thread

Im folgenden sind diese Threads noch einmal kurz beschrieben:

Der Projektmanagement – Thread

Im Projektmanagement Thread werden die Tasks, welche im Hauptprozess des Vorgehensmodells in der Design- Phase sowie in den einzelnen „Requirement- Specification“ Phasen aus den Anforderungen abgeleitet wurden, aufgenommen und an freie Ressourcen innerhalb der Organisation verteilt. Daher werden die einzelnen Iterationen des Projektes geplant. Auf dieser Basis können Projekt- Meilensteine in diesem Thread gebildet werden, welche einen zeitlichten Rahmen für das Projekt bilden. Wenn neue Anforderungen hinzukommen oder sich Anforderungen während des Projektes ändern, müssen diese Meilensteine natürlich adjustiert werden, damit diese auf realistischen Angaben basieren.

Der Konfigurationsmanagement – Thread

Das Konfigurationsmanagement ist im V-Modell XT für die Produktkonfiguration zuständig. Im Hybridvorgehensmodell wurde der Aufgabenbereich für diesen Thread um die Projektkonfiguration erweitert. Daher definiert dieser Thread neben den Aktivitäten zur Pflege und Wartung von Versionierungssystemen und Produktbibliotheken, Aktivitäten zur Sicherstellung des Supports des Entwicklungsprozesses durch die benötigten Hardwarekomponenten sowie Softwarewerkzeuge. Da sich durch Änderungen der Anforderungen die Meilensteine eines Projektes in deren chronologischen Ordnung verschieben können, müssen dementsprechend die Release- Pläne für das Softwaresystem angepasst werden. Dies ist die letzte der Aktivitäten in diesem Basis- Thread.

Der Bug tracking – Thread

Die Softwareentwicklung ist mit dem heutigen Stand der Technik, gleich wie vor 10 Jahren, immer noch eine Aktivität welche durch den Menschen ausgeführt wird. Dabei versucht ein Mensch einen Zusammenhang zu verstehen, diesen Zusammenhang in ein logisches Modell zu transformieren und dieses logische Modell in realen Sourcecode zu überführen. Es liegt in der Natur des Menschen, dass dieser Fehler begeht und aus diesen Fehlern neues Wissen generiert, indem der Mensch, auf der Basis des Ursachewirkungsprinzips, den Fehler identifiziert und analysiert. Wenn der Fehler vollständig erfasst wurde, wird der Mensch diesen Fehler eliminieren und die Ursache des Fehlers speichern, daher sich den Auslöser für den Fehler merken, damit der Mensch diesen Fehler in der Zukunft vermeiden kann.

Da die Softwareentwicklung eine menschliche Aktivität ist, sollte dieses einfache aber effektive Schema des Menschen zur Identifikation, Terminierung und Wissensgenerierung aus diesem Fehler auch in der Softwareentwicklung zu Anwendung kommen.

Daher definiert das Vorgehensmodell den „Bug tracking Thread“. Das Prinzip ist einfach und basiert auf dem zuvor genannten Schema des Menschen. Es werden Fehler im Gesamtsystem gezielt gesucht. Wenn durch diese Suche erfolgreich ein Fehler gefunden wurde oder wenn Fehler bei den verschiedenen Produkttests oder in einer anderen Phase des Projektes gefunden werden, dann müssen diese festgehalten, daher gespeichert werden. Dabei sollte die Ursache sowie der Kontext, in dem der Fehler auftritt, beschrieben werden, damit dieser Fehler auch durch andere Entwickler nachvollziehbar wird. Auf dieser Grundlage kann das Problem gelöst und damit der Bug erfolgreich aus dem Gesamtsystem eliminiert werden. Damit das generierte Wissen nicht nur für die Person zugänglich ist, welche den Fehler aus dem System eliminiert hat, sollte dieser gesamte Prozess dokumentiert werden. Hierfür sollten so genannte

Bug- Tracking- Systeme eingesetzt werden, damit dieser Zyklus von der Meldung des Fehlers bis zu dessen Eliminierung einfach und kostengünstig realisiert werden kann.

Die einzelnen Bugs werden dabei durch die inzelnen Entwickler gelöst, welche für den jeweiligen Sourcecode zuständig sind. Sollte die Technik der gemeinsamen Verantwortlichkeit eingesetzt werden, so können alle Entwickler des Teams diesen Fehler eliminieren. Wenn der Fehler längere Zeit nicht aus dem System eliminiert wurde, oder wenn der gefundene Fehler Auswirkungen auf das restliche Gesamtsystem nach sich zieht, muss aus dem gemeldeten Fehler ein wirklicher Task zur Eliminierung des Fehlers gebildet werden.