Managementmechanismen von Softwareprojekten

Projektspezifische Anpassung - Tailoring

Das V-Modell ist ein generischer Vorgehensstandard für Projekte, der in möglichst viele, verschiedenen Projektkonstellationen anwendbar sein soll. Daher ist es notwendig, dass das V-Modell an die konkreten Projektbedingungen angepasst werden kann. Diese Anpassung, Tailoring genannt, ist eine der ersten und kritischsten Tätigkeiten des V-Modell-Anwenders. Unter Tailoring wird im V-Modell die Festlegung des Projekttyps und damit der anzuwendenden Vorgehensbausteine und Projektdurchführungsstrategien verstanden. Die detailliertere Anpassung des V-Modells auf Ebene der zu erstellenden Produktexemplare und durchzuführenden Aktivitätsexemplare erfolgt im Rahmen der Projektplanung entsprechend den Vorgaben der erzeugenden Produktabhängigkeiten (siehe auch Abschnitt Projektplanung).

Wie in Abbildung 9 dargestellt ist, wird zunächst das Projekt anhand einer Liste mit vorgegebenen Projektmerkmalen charakterisiert. Das Ergebnis dieser Charakterisierung ist das Anwendungsprofil . Die Abbildung zeigt mit den Projektmerkmalen Projektgegenstand und Projektrolle nur einen Ausschnitt der insgesamt 9 Projektmerkmale eines Anwendungsprofils. Das komplette Anwendungsprofil legt automatisch den Projekttyp und damit die Auswahl der verpflichtend zu verwendenden Vorgehensbausteine und Projektdurchführungsstrategien fest. Liefert das Tailoring-Ergebnis mehrere Projektdurchführungsstrategien zur Auswahl, wählt der V-Modell-Anwender eine oder eine Kombination dieser Strategien aus (statisches Tailoring).

Abbildung 9 zeigt als Beispiel das Tailoring-Ergebnis eines denkbaren V-Modell-Projektes aufseiten des Auftraggebers unter Zuhilfenahme des V-Modell Projektassistenten. Der V-Modell Projektassistent ist ein Softwarewerkzeug, mit dessen Hilfe das Tailoring werkzeuggestützt durchgeführt werden kann. Durch die Charakterisierung des Projektes anhand der Projektmerkmale wurde der Projekttyp Systementwicklungsprojekt eines Auftraggebers mit sechs verpflichtenden sowie drei optionalen Vorgehensbausteinen, und eine zugehörige Projektdurchführungsstrategie ausgewählt.

vmodell tailoring

Abbildung 9: Tailoring des V-Modells mit dem V-Modell Projektassistenten

Die Auswahl der Vorgehensbausteine kann bei Bedarf manuell erweitert werden, wobei jedoch die zwischen den Vorgehensbausteinen bestehenden Vorgehensbausteinabhängigkeiten zu beachten sind. Die endgültige Festlegung des Projekttyps sowie die zugehörige Auswahl der Vorgehensbausteine und der Projektdurchführungsstrategie wird im Projekthandbuch dokumentiert. Dabei ist das erstellte Anwendungsprofil nachvollziehbar zu begründen, ebenso wie die Auswahl der Projektdurchführungsstrategie und die Verwendung zusätzlicher Vorgehensbausteine.

Durch diesen einfachen, aber effektiven Tailoring-Mechanismus werden alle für ein Projekt nicht notwendigen Teile des V-Modells ausgeblendet. Der V-Modell-Anwender muss sich also nur noch mit den für sein Projekt relevanten Vorgehensbausteinen und Projektdurchführungsstrategien auseinander setzen.

Zusätzlich können während der Projektlaufzeit weitere Vorgehensbausteine ausgewählt beziehungsweise entfernt werden. Ausnahme hierbei sind die in jedem Projekt verpflichtend zu verwendenden Vorgehensbausteine des V-Modell-Kerns. Die Regeln für dieses dynamisches Tailoring sind ebenfalls bereits im V-Modell durch speziell ausgezeichnete Produktabhängigkeiten definiert, die als Tailoring-Produktabhängigkeit bezeichnet werden (siehe V-Modell-Referenz Tailoring ).

Zum Beispiel definiert eine dieser Tailoring-Produktabhängigkeiten die folgende Regel:

Wurde im Produkt Systemarchitektur mindestens eine HW-Einheit identifiziert, so muss im Projekthandbuch der Vorgehensbaustein HW-Entwicklung ausgewählt werden.

Angenommen, in einem Projekt wurde der Vorgehensbaustein HW-Entwicklung nicht ausgewählt, beim Entwurf der Systemarchitektur werden aber HW-Einheiten identifiziert. In diesem Fall fordert die vorgestellte Tailoring-Produktabhängigkeit, dass der Vorgehensbaustein HW-Entwicklung auch gewählt werden muss. Dementsprechend muss natürlich die Dokumentation des Tailorings im Projekthandbuch angepasst werden.

Diese Art des dynamischen Tailorings während der Projektlaufzeit bietet ein hohes Maß an Flexibilität. Dabei stellt der V-Modell-Kern ein Grundpensum an Qualität sicher, das in jedem V-Modell-konformen Projekt gewährleistet ist.

Teile des Projekthandbuches können als Vertragsgegenstand vereinbart werden. Diese Festlegung erfolgt für öffentliche Auftraggeber bereits im Rahmen der Ausschreibung. Wurde im Projekt das Tailoring-Ergebnis als vertragsrelevanter Teil des Projekthandbuches vereinbart, so ist das Tailoring und insbesondere auch das dynamische Tailoring transparent für alle Projektbeteiligten.

Projektorganisation

Die Projektorganisation überlagert die bestehende Organisation des Umfeldes, in dem ein Projekt angesiedelt ist, wie zum Beispiel die Linienorganisation eines Unternehmens oder einer Behörde. Trotzdem muss die Projektorganisation klar in der umgebenden Organisation verankert sein. Darum ist eine eindeutige Kompetenzregelung, ebenso wie die Definition und Organisation der Projektkommunikation und des Berichtswesens, unerlässlich.

Ausgehend von den Aufgaben und Verantwortungen müssen die Kompetenzen festgelegt, die Mittel zugeteilt und die Rahmenbedingungen gesetzt werden. Dies wird im Rahmen der Projektfortschrittsentscheidungen dokumentiert und im Projekthandbuch sowie im QS-Handbuch ausgearbeitet.

Außerdem müssen die Rollen durch Personen besetzt werden. Diese Besetzung der Rollen ist der wichtigste Faktor für den Erfolg eines Projektes. Die einzelnen Schlüsselrollen, wie zum Beispiel Projektleiter und Systemarchitekt, müssen mit erfahrenen, kompetenten und akzeptierten Personen besetzt werden. Gleiches gilt für die Projektsteuerungsgremien, beispielsweise den Lenkungsausschuss oder die Änderungssteuerungsgruppe (Change Control Board).

Projektplanung

Nach der projektspezifischen Anpassung des V-Modells steht die zu verwendende Projektdurchführungsstrategie fest. Diese Projektdurchführungsstrategie gibt die Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen vor. Eine Projektfortschrittsstufe wird dabei durch einen Entscheidungspunkt repräsentiert.

Die konkrete Anzahl der Entscheidungspunkte und der zugehörigen Projektfortschrittsstufen hängt von den Erfordernissen des durchzuführenden Projektes ab. Die Projektdurchführungsstrategie gibt hier nur den allgemeinen Rahmen vor, der durch das Projekt entsprechend auszugestalten ist.

Beispielsweise soll im Rahmen einer Systemerstellung zuerst ein Prototyp des Systems zur Validierung der erarbeiteten Gesamtsystemspezifikation (Pflichtenheft) erstellt und dann auf der Basis der dabei gewonnenen Erfahrungen die eigentliche Systementwicklung beauftragt werden. Wie Abbildung 10 illustriert, werden dann im V-Modell-Projekt des Auftraggebers die Entscheidungspunkte Anforderungen festgelegt, Projekt ausgeschrieben , Projekt beauftragt und Abnahme erfolgt zweimal eingeplant: einmal für den Prototyp und ein weiteres Mal für das eigentliche System.

Diese projektspezifische Ausgestaltung der Projektdurchführungsstrategie erfolgt im Rahmen der Projektplanung durch den Projektleiter und wird im Projekthandbuch sowie im Projektplan festgehalten.

Projektdurchfuehrungsstrategie Beispiel

Abbildung 10: Projektspezifische Ausplanung der Projektdurchführungsstrategie

Das Grundgerüst für eine detaillierte Projektplanung und -organisation ist damit vorgegeben. Die Entscheidungspunkte der Projektdurchführungsstrategie geben die Reihenfolge der fertig zu stellenden Produkte vor. Ein Produkt, das in jedem Projekt genau einmal zu erstellen ist, wird im V-Modell als initiales Produkt bezeichnet. Diese und die von den Entscheidungspunkten vorgegebenen Produkte können sofort mit den zugehörigen Aktivitäten eingeplant werden.

So genannte erzeugende Produktabhängigkeiten bestimmen weitere einzuplanende Produkte und Aktivitäten. Eine erzeugende Produktabhängigkeit besagt, dass bestimmte Inhalte in einem bereits erstellten Produkt verbindlich die Erstellung weiterer Produkte nach sich zieht. Dabei ist nicht festgelegt, wann diese Produkte fertig gestellt sein müssen. Das V-Modell beinhaltet beispielsweise eine erzeugende Produktabhängigkeit, die festlegt, dass für jede HW-Einheit, die in der Systemarchitektur identifiziert wurde, eine zugehörige HW-Spezifikation erstellt werden muss. Detailliert beschrieben sind die erzeugenden Produktabhängigkeiten in der V-Modell-Referenz Produkte.

Gemäß diesen erzeugenden Produktabhängigkeiten muss der Projektplan also gegebenenfalls um weitere Produkte und Aktivitäten ergänzt werden. Darüber hinaus können natürlich zusätzliche Produkte und damit auch Aktivitäten eingeplant werden, wobei immer die definierten erzeugenden Produktabhängigkeiten zu berücksichtigen sind.

Risikominimierende Projektsteuerung

Im Projektverlauf müssen der Projektfortschritt und die Projektrisiken kontinuierlich und systematisch überprüft und auf Schwierigkeiten muss entsprechend steuernd reagiert werden. Der Vorgehensbaustein Projektmanagement legt die hierfür notwendigen Verfahren fest. Auf übergeordneter Ebene wird mit Hilfe der Entscheidungspunkte der Projektfortschritt überwacht und das Gesamtrisiko für den Projekterfolg entsprechend reduziert.

Abbildung 11: Entscheidungspunkte und Projektfortschrittsentscheidung

Die Entscheidungspunkte markieren dabei Qualitätsmesspunkte (engl. Quality Gates) zur Entscheidung über den Projektfortschritt und die weitere Projektdurchführung auf Basis der im Entscheidungspunkt vorzulegenden Produkte. Diese Entscheidung liegt in der Verantwortung des Projektmanagers und wird im Rahmen des Lenkungsausschusses, dem alle Schlüsselpersonen des Projektes angehören, getroffen, wie Abbildung 11 illustriert.

Die Entscheidung wird im Produkt Projektfortschrittsentscheidung dokumentiert. Hier werden das Budget und die Ressourcen für den nächsten Projektabschnitt freigegeben. Es können auch Auflagen für den nächsten Abschnitt des Projektes formuliert werden. Sollte die Entscheidung über den Projektfortschritt negativ ausfallen, kann im Einzelfall festgelegt werden, ob der Entscheidungspunkt nach Verbesserung erneut vorgelegt, das Projekt grundsätzlich neu aufgesetzt oder sogar ganz abgebrochen wird.

Die konsequente Anwendung der Projektdurchführungsstrategie mit den Entscheidungspunkten führt zu einer risikominimierenden Projektsteuerung. Fehlentwicklungen werden frühzeitig in den Projektfortschrittsstufen erkannt, so dass früh entsprechende Gegenmaßnahmen ergriffen werden können.

Qualitätssicherung und Produktzustandsmodell

Die Qualität des Projektergebnisses ist sowohl konstruktiv als auch analytisch in der Entwicklung sicher zu stellen. Es ist essentiell, die analytische Qualitätssicherung parallel zum und unabhängig vom konstruktiven Entstehungsprozess durchzuführen. Für die Durchführung der Qualitätssicherung im Projekt ist eine einheitliche und abgestimmte Vorgehensweise, die von allen Projektbeteiligten verstanden, getragen und gelebt wird, notwendig.

Das V-Modell enthält formale und inhaltliche Vorgaben an die Produkte, die im Laufe eines V-Modell-Projektes erstellt werden. In der V-Modell-Referenz Produkte werden diese Vorgaben für jedes Produkt beschrieben. Darüber hinaus legen die so genannten Produktabhängigkeiten zusätzlich Regeln für die produktübergreifende inhaltliche Konsistenz fest. Dabei werden im V-Modell vier Arten von Produktabhängigkeiten unterschieden: inhaltliche Produktabhängigkeiten, erzeugende Produktabhängigkeiten, strukturelle Produktabhängigkeiten und Tailoring-Produktabhängigkeiten (siehe V-Modell-Referenz Tailoring und V-Modell-Referenz Produkte).

Jedes Produkt besitzt einen Bearbeitungszustand. Mögliche Bearbeitungszustände sind in Bearbeitung, vorgelegt und fertig gestellt, wie in Abbildung 12 dargestellt ist. Der Zustand eines Produktes wird spätestens mit der erfolgreichen Beendigung der bearbeitenden Aktivität neu ermittelt.

Produktzustandsmodell Automat

Abbildung 12: Bearbeitungszustandsmodell von Produkten

Um eine Aktivität erfolgreich zu beenden, muss das erzeugte Produkt entsprechend geprüft werden. Der Ablauf einer Prüfung ist in Abbildung 13 dargestellt. Bei jeder Prüfung durch eine eigenständige Qualitätssicherung oder in Form einer Eigenprüfung wird dabei das Produkt formal und inhaltlich entsprechend der V-Modell-Vorgaben überprüft. Darüber hinaus erfolgt im Rahmen der Prüfung die Überprüfung der inhaltlichen Konsistenz mit anderen Produkten. Hierbei werden alle relevante Produktabhängigkeiten überprüft. Dabei sind relevante Produktabhängigkeiten alle Produktabhängigkeiten zwischen dem zu überprüfenden Produkt und den Produkten, die bereits im Zustand fertig gestellt sind.

Produktzustandsmodell Pruefvorgang

Abbildung 13: Vorgehensweise bei Prüfungen

Wie Abbildung 12 zeigt, erfolgt zuerst immer eine Eigenprüfung. Im Rahmen einer Eigenprüfung wird, wie oben beschrieben, das Produkt selbst und seine inhaltliche Konsistenz zu bereits fertig gestellten Produkten überprüft. Allerdings muss Umfang und Ergebnis der Eigenprüfung nicht zwingend entsprechend dem V-Modell dokumentiert werden.

Darüber hinaus wird im QS-Handbuch und in den zugehörigen Implementierungs-, Integrations- und Prüfkonzept Systemen im Vorfeld festgelegt, ob eine Prüfung durch eine zusätzliche eigenständige Qualitätssicherung durchgeführt werden muss. Im Rahmen einer eigenständigen Qualitätssicherung wird, wie oben dargestellt, sowohl das Produkt selbst, als auch seine inhaltliche Konsistenz zu bereits fertig gestellten Produkten überprüft. Im Gegensatz zur Eigenprüfung werden aber entsprechende Prüfspezifikation Systemelementen und Prüfprotokoll Systemelemente zur Vorbereitung und Dokumentation der durchgeführten Prüfungen erstellt.

Ist eine eigenständige Qualitätssicherung notwendig, so wechselt das Produkt zuerst in den Zustand vorgelegt und nach der erfolgreichen Prüfung in den Zustand fertig gestellt. Andernfalls geht das Produkt sofort nach der erfolgreichen Eigenprüfung in den Zustand fertig gestellt über.

Ist eine Prüfung nicht erfolgreich, so muss das Produkt entsprechend überarbeitet und erneut qualitätsgesichert werden. Sind dabei relevante Produktabhängigkeiten verletzt, so sind die Produktverantwortlichen der beteiligten Produkte für die Beseitigung der Inkonsistenz verantwortlich. Dies kann auch dazu führen, dass die verantwortlichen Rollen (Verantwortlicher) entscheiden, dass ein bereits fertig gestelltes Produkt wieder in den Zustand in Bearbeitung gesetzt wird, um die notwendigen Korrekturen durchzuführen.

Wie Abbildung 12 zu entnehmen ist, kann ein Produkt, das im Zustand fertig gestellt ist, auch durch andere Ereignisse, die nicht durch die Qualitätssicherung hervorgerufen wurden, wieder in den Zustand in Bearbeitung übergehen. So werden Produkte beispielsweise durch im Rahmen des Änderungsmanagements beschlossene durchzuführende Änderungen oder erneute Bearbeitung von Produkten in nachfolgenden Fertigstellungsstufen des Projektes überarbeitet und damit in den Zustand in Bearbeitung versetzt.

Durch dieses Verfahren ist aber stets gewährleistet, dass alle Produkte im Zustand fertig gestellt nicht nur für sich gesehen korrekt sind, sondern auch Produkt-übergreifend inhaltlich konsistent und damit in ihrer Gesamtheit korrekt sind. Dabei ist dies unabhängig, in welcher Reihenfolge die einzelnen Produkte fertig gestellt wurden.

Konfigurationsmanagement

Das Konfigurationsmanagement verwaltet entsprechend dem Projektplan alle Produkte sowie die Produktkonfigurationen. Eine Produktkonfiguration identifiziert eine Menge zusammengehöriger Produkte aus der Produktbibliothek in einer bestimmten Version und in ihrem jeweiligen Bearbeitungszustand - so genannte Produktversionen.

Das Ziel des Konfigurationsmanagements ist folglich, die gegenwärtige und vergangene Produktkonfiguration eines Systems sowie den Stand der Erfüllung seiner physischen und funktionalen Anforderungen zu dokumentieren und jederzeit während des gesamten Systemlebenszyklus volle Transparenz darüber herzustellen.

Mit jedem geplanten Entscheidungspunkt wird eine Produktkonfiguration – wie sie die Abbildung 14 beispielhaft darstellt – erzeugt und damit der Projektfortschritt dokumentiert sowie eine nachvollziehbare Qualitätssicherung sichergestellt.

Produktbibliothek Grafik

Abbildung 14: Entscheidungspunkte und Produktkonfigurationen

Problem- und Änderungsmanagement

Während der gesamten Projektlaufzeit werden Produkte überarbeitet und geändert. Ab einem gewissen Fertigstellungsgrad ist es notwendig die Änderungen an Produkten auch formal zu verfolgen und nachzuvollziehen. Dieses formale Problem- und Änderungsmanagement ist im Vorgehensbaustein Problem- und Änderungsmanagement festgelegt. Dieses Verfahren wird im Projekthandbuch projektspezifisch ausgestaltet. Hierbei wird insbesondere auch festgelegt, für welche Arten von Änderungen das formale Problem- und Änderungsmanagement angewendet werden muss. Dabei ist zu beachten, dass Produkte erst im Zustand fertig gestellt Gegenstand des formalen Problem- und Änderungsmanagements sein können.

Im Rahmen des formalen Problem- und Änderungsmanagements werden alle Fehler, Probleme und Änderungswünsche dokumentiert, bewertet und über das weitere Vorgehen im Projekt entschieden. Entsprechende Problemmeldungen und Änderungsanträge (siehe Problemmeldung/Änderungsantrag) können während der gesamten Projektlaufzeit und während des gesamten Systemlebenszyklus auftreten und von allen Betroffenen, wie zum Beispiel SW-Entwickler, Anwender oder Ergonomieverantwortlicher, erstellt werden.

Es gibt die unterschiedlichsten Gründe für Problemmeldungen und Änderungsanträge. Zum Beispiel Fehlverhalten des Systems, aufgeschobene Fehlerbehebung, fehlende und zusätzliche Systemfunktionalität, Veränderungen des Umfelds bei Auftraggeber oder Auftragnehmer, Probleme mit externen Zulieferungen, Missverständnisse im Auftrag und neu erkannte Abhängigkeiten. Diese Problemmeldungen und Änderungsanträge werden zentral über eine Änderungsstatusliste dokumentiert und verfolgt. Diese Liste gibt Auskunft über Art und Status einer Änderung, über den Stand der Entscheidungen und über die zeitliche Planung.

Das Änderungsverfahren selbst, also die Erfassung, Bewertung und Entscheidung, ist ein in sich abgeschlossener und nachvollziehbarer Prozess. Gesteuert wird dieser Prozess von der Rolle Änderungsverantwortlicher. Verbindliche Entscheidungen werden von der Änderungssteuerungsgruppe (Change Control Board) getroffen, deren personelle Zusammensetzung und Entscheidungskompetenz im Projekthandbuch festgelegt wird und sich an den Auswirkungen von Änderungen orientieren sollte.

Das V-Modell® XT ist urheberrechtlich geschützt. © Bundesrepublik Deutschland 2004. Alle Rechte vorbehalten Diese Seite wurde mit Hilfe des V-Modell XT Editors erstellt. Grundlage ist das V-Modell XT.