Das V Modell XT. Optimierung der IT Systementwicklung. Hong-Son Dang-Nguyen (Matrikelnr.: ) Westfälische Wilhelms-Universität Münster

Transkript

1 Westfälische Wilhelms-Universität Münster Das V Modell XT Optimierung der IT Systementwicklung Ausarbeitung im Rahmen des Blockseminars Software-Management Hong-Son Dang-Nguyen (Matrikelnr.: ) Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Susanne Gruttmann Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis Inhaltsverzeichnis... II 1 Einleitung Einführung in das V-Modell XT Überblick Entstehung Konzeptionelle Komponenten Projektspezifische Anpassung Tailoring Abgrenzung zu anderen Vorgehensmodelle Werkzeuge für das V-Modell XT Der V-Modell XT Editor Der V-Modell XT Projektassistent Werkzeuge zur Unterstützung der Managementmechanismen Das V-Modell XT am Beispielprojekt: WiBe Das Pilotprojekt WiBe Das Tailoring des WiBe-Projekt Der Ablauf des WiBe-Projekt Zusammenfassung und Ausblick Literaturverzeichnis Anhang A: Grafiken II

3 1 Einleitung 1 Einleitung IT-Entwicklungsprojekte werden immer umfangreicher. Sie werden immer mehr durch komplexere Projektstrukturen und höheren Aufwand an Koordination der Projektabläufe geprägt. Um diese Komplexität in den Griff zu bekommen und den Aufwand zu reduzieren, ist der Einsatz von Vorgehensmodellen notwendig. Zur Strukturierung und Steuerung von IT-Entwicklungsprojekten sind Vorgehensmodelle unerlässlich. Sie definieren einen allgemeinen Rahmen für die organisatorischen Entwicklungsprozesse. Dabei legen sie fest, welche Ergebnisse in einem Projekt zu erstellen sind, wer für diese verantwortlich ist und welche Aktivitäten dafür durchzuführen sind. Im Allgemeinen haben Vorgehensmodelle allerdings den Ruf, dass sie durch genaue Vorgaben der Vorgehensweise die Gestaltungsmöglichkeiten der Beteiligten bei der Projektumsetzung einschränken. Des Weiteren wird in manchen Fällen der Nutzen im Verhältnis zum Aufwand für die Einarbeitung in die Vorgehensmodelle von den Beteiligten als zu gering gesehen [Si05, S. 1]. Diese Aspekte wurden bei der Entwicklung des neuen V-Modell XT beachtet. Nach langer Entwicklungszeit wurde dieses im Februar 2005 vorgestellt. Es ist ein modulares Vorgehensmodell, das für viele Projektkonstellationen eingesetzt werden kann. Im Gegensatz zu seinem Vorgänger, dem V-Modell 97, und anderen Standards steht hier nicht mehr wie, was zu tun ist im Fokus, sondern welche Produkte, bis wann und in welcher Qualität fertigzustellen sind. Mit dem neuen V-Modell XT soll der Einstieg für die Projektbeteiligten erleichtert werden. So werden beispielsweise keine Kenntnisse über das gesamte Modell vorausgesetzt, um es anzuwenden. Weiterhin sollen Spielräume für die Beteiligten bei der Durchführung der Aktivitäten gelassen werden. Daneben wurde bei der Entwicklung des Modells der Aspekt der projektbegleitenden Werkzeugunterstützung berücksichtigt. Die Autoren des V-Modell XT erkennen frühzeitig, dass eine Werkzeugunterstützung, die die Projektbeteiligten in vieler Hinsicht unterstützen soll, für die Akzeptanz eines neuen Vorgehensmodells unerlässlich ist. Deshalb werden mit dem V-Modell XT auch zwei Open Source Werkzeuge, der V-Modell XT Editor und der V-Modell XT Projektassistent, geliefert. Diese Arbeit, welche aus drei Teilen besteht, befasst sich mit den Konzepten und Werkzeugen des V-Modell XT. Im ersten Teil wird zunächst das V-Modell XT vorgestellt. Danach wird auf die Grundlage des Modells eingegangen. Am Ende diesen Teil wird dieses zu anderen Vorgehensmodellen abgrenzt. Der zweite Teil dieser Arbeit beschäftigt sich mit den Werkzeugen, die im Zusammenhang mit dem Modell existieren. Im letzen Teil wird anhand eines Beispiels die Anwendbarkeit des V-Modell XT in der Praxis verdeutlich. 3

4 2 Einführung in das V-Modell XT 2 Einführung in das V-Modell XT 2.1 Überblick Das V-Modell XT ist ein umfassendes Vorgehensmodell für die systematische Planung und Durchführung von komplexen und umfangreichen Entwicklungsprojekten unter Berücksichtigung des gesamten Systemlebenszyklus, also von der Anforderungserstellung über den Einsatz bis zur Wartung und Weiterentwicklung des Systems [VMXT07, S. 1-6]. Dabei unterstützt es sowohl die Entwicklungsprojekte des Auftraggebers als auch des Auftragnehmers. Die Kooperation zwischen Auftraggebern und Auftragnehmern wird ebenfalls geregelt. Das V-Modell XT definiert die in einem Projekt zu erstellenden Ergebnisse, legt die Reihenfolge der Erstellung fest und beschreibt die konkreten Vorgehensweisen, mit denen die Ergebnisse erarbeitet werden. Zudem ordnet es den einzelnen Projektbeteiligten die Verantwortlichkeiten zu. Es regelt also wer, wie, was, wann in einem Projekt zu tun hat [VMXT07, S. 1-6]. Mit dem V-Modell XT als Vorgehensstandard sollen die Projektrisiken minimiert, die Projekttransparenz erhöht, die Projektqualität verbessert und gewährleitet und eine bessere Kommunikation zwischen alle Beteiligten ermöglicht werden [HH08, S. 4]. Des Weiteren zeichnet sich das V-Modell XT durch seine ziel- und ergebnisorientierte Grundphilosophie aus. Im Gegensatz zu seinem Vorgänger, welcher den Fokus auf wie etwas zu tun ist legte, steht die Beschreibung des was, bis zu welchem Zeitpunkt und in welcher Qualität fertigzustellen ist im Mittelpunkt des V-Modell XT. Die Produkte sind also die zentralen Zwischen- und Endergebnisse des Projektes. Darüber hinaus gibt es durch die Reihenfolge der Fertigstellung dieser zentralen Produkte in den Projektdurchführungsstrategien eine übergeordnete Managementstruktur des Projektverlaufs vor. Dadurch ist eine detaillierte und flexible Projektplanung durch den Projektleiter auf Basis der Bearbeitung und Fertigstellung von Produkten möglich. Mit dieser Grundphilosophie soll unnötige Tätigkeiten in einem Projekt vermieden und eine effiziente Projektabwicklung erreicht werden [HH08, S. 13]. Das V-Modell XT ist ein in Deutschland entwickeltes Vorgehensmodell. Es ist für die IT-Entwicklungsprojekte in der Bundesverwaltung eine verbindliche Vorgabe. Der Namenzusatz XT steht für extreme Tailoring (engl. to tailor = schneidern) und soll die Anpassungsfähigkeit des V-Modells an die unterschiedlichen Projektkonstellationen verdeutlichen [HH08, S. 15]. 2.2 Entstehung Um die Kosten für den Softwarelebenszyklus zu begrenzen und einen Mindeststandard für Softwarequalität zu garantieren, wurde ein Entwicklungsstandard für IT-Systeme des Bundes entwickelt. Auf Basis des existierenden Wasserfall-Modells nach Boehm 4

5 2 Einführung in das V-Modell XT wurde 1992 die erste Version des V-Modells entwickelt [Bal08, S. 620] und unter dem Namen V-Modell 92 veröffentlicht. Eine zweite Version des V-Modells wurde im Jahr 1997 unter dem Namen V-Modell 97 vorgestellt. Seit der Fertigstellung des V-Modells 97 erfolgte keine Fortschreibung mehr. Damit repräsentiert das V-Modell 97 nicht mehr die aktuellen Methoden und Ansätze der Systementwicklung, wie zum Beispiel die komponentenbasierte Entwicklung. Deshalb wurde in den Jahren 2003 bis 2005 das V-Modell überarbeitet und weiterentwickelt [HH08, S. 3]. Im Rahmen der Weiterentwicklung wurden die Qualitätseigenschaften des V-Modells verbessert, insbesondere hinsichtlich der Anpassbarkeit, der Anwendbarkeit im Projekt, der Skalierbarkeit auf unterschiedliche Projektgrößen sowie der Änder- und Erweiterbarkeit des V-Modells selbst. Um dies zu erreichen, musste eine Umstrukturierung des V-Modells erfolgen. Im Gegensatz zu dem ehemals monolithischen V-Modell 97 wurde das gesamte Modell in einzelne Module, sog. Vorgehensbausteine zerlegt [VMXT07, S. 1-11]. Das aktualisierte V-Modell XT wurde im Februar 2005 erstmalig unter dem Namen V- Modell XT vorgestellt. Das V-Modell XT ist, wie seine Vorgänger, eine verbindliche Vorgabe für alle IT-Entwicklungsprojekte im gesamten zivilen und militärischen Bundesbereich. Mittlerweile verwenden immer mehr Unternehmen das V-Modell XT als Richtlinie für die Steuerung und Planung von Entwicklungsprojekten, u. a. da es frei verfügbar ist [HH08, S. 3]. 2.3 Konzeptionelle Komponenten Vorgehensbausteine Wie bereits erwähnt, wurden im Rahmen der Weiterentwicklung die Qualitätseigenschaften des V-Modell XT verbessert. Dabei wurde das Modell in 21 modulare, auf einander aufbauende Vorgehensbausteine unterteilt. Jeder Baustein ist eine eigenständige Einheit und unabhängig änder- bzw. erweiterbar [Bal08, S. 623]. Diese modulare Struktur ermöglicht dem Anwender, das V-Modell XT projektspezifisch anzupassen, ohne dass er vorerst mit den in den einzelnen Bausteinen erhaltenen Aktivitäten, Produkte und Rollen im Detail auseinander setzen muss. Die projektspezifische Anpassung des V-Modell XT an ein konkretes Projekt wird Tailoring genannt. In einem Vorgehensbaustein, wie in Abbildung 1 illustriert, werden für die Aufgabenstellung relevante Produkte (was), Aktivitäten (wie) und Rollen (wer) gekapselt. Als Produkte werden im V-Modell XT nicht nur die Endprodukte eines Projektes verstanden, sondern auch dessen Zwischenergebnisse. Unter den Produkten können Produktabhängigkeiten existieren, d. h. ein Produkt ist ein Bestandteil des anderen Produkts oder eine Voraussetzung für das Produkt. Die Produkte werden hierarchisch strukturiert. Dabei werden inhaltlich eng zusammengehörende Produkte zu Produktgruppen zusammengefasst. Darüber hinaus kann ein komplexes Produkt in mehrere Teilprodukten, sog. Themen, gegliedert sein [VMXT07, S. 1-14]. Themen beschreiben unterschiedliche In- 5

6 2 Einführung in das V-Modell XT halte und werden durch Teilaktivitäten bearbeitet. Eine Teilaktivität gehört genau zu einem Vorgehensbaustein und ist stets einer Aktivität zugeordnet [VMXT07, S. 8-38]. Aktivitäten geben vor, was zu tun ist um zu dem gewünschten Ergebnis, also dem zugehörigen Produkt, zu kommen. Wie die Produkte, werden die inhaltlich zusammengehörenden Aktivitäten in Aktivitätsgruppe zusammengefasst. Ein Produkt wird von genau einer Aktivität erstellt und genau eine zugehörige Rolle, welche einer Person oder Organisationseinheit zu geordnet werden kann, ist für dieses Produkt verantwortlich. Rollen beschreiben somit die Aufgaben und Verantwortlichkeiten im Rahmen eines Projekt und einer Organisation. Abbildung 1: Vorgehensbausteine und ihre Bestandteile [VMXT07] Wie oben angesprochen, sind Vorgehensbausteine aufeinander aufbauend, d.h. ein Vorgehensbaustein darf nur verwendet werden, wenn die Vorgehensbausteine, auf denen er basiert, ebenfalls eingesetzt werden. Diese Abhängigkeiten zwischen den Vorgehensbausteinen, die in der sog. Vorgehensbausteinlandkarte festgehalten sind (s. Anhang B, Abb. 13), müssen beim Tailoring streng eingehalten werden. Weiterhin sind bestimmte Vorgehensbausteine für jedes Projekt verpflichtend. Diese bilden den V-Modell-Kern. Der V-Modell-Kern legt also die Menge der Vorgehensbausteine fest, die in jedem V- Modell XT-konformen Projekt verwendet werden müssen [VMXT07, S. 1-15]. Zu diesem Kern gehören die Vorgehensbausteine Projektmangement, Qualitätssicherung, Konfigurationsmanagement sowie Problem- und Änderungsmanagement. Die Vorgehensbausteine enthalten die statischen Inhalte des V-Modell XT. Sie beschreiben, welche Produkte vom wem und wie fertiggestellt werden. Aufgrund der statischen Inhalte besitzen sie keinerlei Vorgaben oder Einschränkungen bezüglich einer möglichen Reihenfolge der Durchführung von Aktivitäten oder der Erstellung von Produkten. Hierfür stellt das V-Modell XT dem Anwender mit einer Einordnung der Vorgehensbausteine in Projekttypen und den dazugehörigen Projektdurchführungsstrategien eine Möglichkeit zur Planung und Steuerung der Projektabläufe zur Verfügung [VMXT07, S. 1-18]. Projekttypen Das V-Modell XT kann in verschiedene Projektkonstellationen für systematische Führung und Abwicklung eines Projektes eingesetzt werden. Dabei laufen die V-Modell XT-Projekte grundsätzlich verschieden ab. Abhängig von wichtigen Projektmerkmalen (Projektgegenstand und Projektrolle) lassen sich die verschiedenen Projekte 6

7 2 Einführung in das V-Modell XT klassifizieren und in Projekttypen einteilen [VMXT07, S. 1-12]. Abbildung 2 stellt die Projekttypen dar, die aktuell im V-Modell XT enthalten sind. Abbildung 2: Übersicht der Projekttypen [VMXT07] Mit der Auswahl eines Projekttyps wird bestimmt, was in einem Projekt zu tun ist. Darüber hinaus werden die für ein Projekt verpflichtenden und optionalen Vorgehensbausteine sowie die möglichen Projektdurchführungsstrategien, d. h. die Grundstruktur des Projektablaufs, festgelegt. Projektdurchführungsstrategien und Entscheidungspunkte Das V-Modell XT stellt dem Anwender einen Katalog von Projektdurchführungsstrategien zur Verfügung, um eine zuverlässige Planung und Steuerung des Projekts zu ermöglichen. Für jeden Projekttyp bietet das V-Modell XT mindesten eine geeignete Durchführungsstrategie, welche anhand des Projekttyps und weiterer Projektmerkmale bestimmt wird, an. Welche Projektdurchführungsstrategien für welchen Projekttyp geeignet sind, wird in Abbildung 14 im Anhang A skizziert. Eine Projektdurchführungsstrategie definiert einen organisatorischen Rahmen, der eine geordnete und nachvollziehbare Durchführung eines Projektes garantiert [HH08, S. 7]. Jede Durchführungsstrategie legt dabei die Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen fest. Eine Projektfortschrittsstufe stellt einen Abschnitt im Projektverlauf dar. Der erfolgreiche Abschluss dieses Projektabschnitts wird jeweils durch einen Entscheidungspunkt markiert. Für jeden Entscheidungspunkt ist eine Menge von Produkten definiert, die am Ende einer Projektfortschrittsstufe fertiggestellt werden muss. Abbildung 3 stellt nochmal dieses Konzept dar. Abbildung 3: Projektdurchführungsstrategien und Entscheidungspunkte [VMXT07] Ein Entscheidungspunkt ist ein Meilenstein im Projektverlauf, in dem die Entscheidung über den Projektfortschritt getroffen wird. Auf Basis der für jeden Entscheidungspunkt definierten Produkte wird entschieden, ob der Projektabschnitt erfolgreich durchgeführt wurde und der nächste Projektabschnitt freigegeben werden kann. Wird bei der Bewertung der Produkte festgestellt, dass diese nicht der vorgegebenen Qualität entsprechen, 7

8 2 Einführung in das V-Modell XT so muss der vorherige Projektabschnitt nochmal durchgeführt oder eventuell das Projektkonzept überarbeitet werden. Mit dieser kontinuierlichen Bewertung in jedem Projektabschnitt wird somit erreicht, dass die Zwischenergebnisse des Projekts kontrolliert und gegebenenfalls geändert werden können. Eine Übersicht über sämtliche Entscheidungspunkte im V-Modell XT ist im Anhang A, Abbildung 15 zu entnehmen. Die Projektdurchführungsstrategien beschreiben somit mit der Abfolge der Entscheidungspunkte die dynamischen Anteile. Zusammen mit den Entscheidungspunkten legen sie das wann und was fest, also wann welche Produkte fertiggestellt sein müssen [VMXT07, S. 1-19]. 2.4 Projektspezifische Anpassung Tailoring Das V-Modell XT ist, wie zuvor erwähnt, ein generischer Vorgehensstandard, der für verschiedene Projektkonstellationen verwendbar ist. Aus diesem Grund ist es notwendig, dass es an das konkrete Projekt angepasst werden kann. Die Anpassung wird Tailoring genannt. Das Tailoring ist eines der Kernkonzepte des V-Modell XT. Damit werden alle für das Projekt nicht notwendigen Teile des Modells ausgeblendet [HH08, S. 15]. Das Tailoring wird je nach Projektfortschritt in statisches Tailoring und dynamisches Tailoring unterschieden. Bevor das V-Modell XT in einem Projekt eingesetzt werden kann, muss das statische Tailoring durchgeführt werden. Es wird also in der Projektinitialisierungsphase durchgeführt. Dieses Konzept wird in Abbildung 4 illustriert. Abbildung 4: vereinfachte Darstellung des statischen Tailoring-Prinzips Zu Beginn wird das Projekt anhand der Projektmerkmale charakterisiert. Das Resultat dieser Charakterisierung wird in Form eines Anwendungsprofils dargestellt. Ein Anwendungsprofil listet also die Wertbelegung der einzelnen Merkmale im konkreten Projekt auf. Als Nächstes kann anhand dieses Profils das Projekt in einen bestimmten Projekttyp eingeordnet werden. Dadurch werden die Auswahl der verpflichtenden und optionalen Vorgehensbausteine sowie die möglichen Projektdurchführungsstrategien festgelegt. Darauf folgend ist zu entscheiden, welche der optionalen Bausteine verwendet 8

9 2 Einführung in das V-Modell XT bzw. gestrichen werden sollen. Zudem ist die Projektdurchführungsstrategie, die die Reihenfolge der Entscheidungspunkte festlegt, zu wählen. Mit der Auswahl der Durch- führungsstrategie wird somit die Durchführung der Vorgehensbausteine zeitlich beeinf- die wiederum in den Vorgehensbausteinen erzeugt werden. Das Resultat ist ein projektspe- zifische V-Modell XT, welches im Projekthandbuch dokumentiert wird. Ein Projekt- lusst, denn für jeden Entscheidungspunkt sind bestimmte Produkte zu erstellten, handbuch legt Art und Umfang der Anwendung des V-Modell XT im Projekt sowie organisatorische Rahmenbedingungen für alle Projektbeteiligten fest. Darüber hinaus bietet das V-Modell XT mit dem sog. dynamischen Tailoring eine Mög- oder lichkeit zur Anpassung des projektspezifischen V-Modell XT an neuee Erkenntnisse neue Projektgegebenheiten während der Projektdurchführung [HH08, S. 15]. Werden beispielsweise beim Entwurf einer Systemarchitektur bzw. bei der Erstellung des Pro- dukts Systemarchitekturr Hardware-Einheiten Modell hinzu gefügt werden, falls er beim statischen Tailo- identifiziert t, so muss der Vorgehensbaus- tein HW-Entwicklung dem ring noch nicht ausgewählt wurde. Das Hinzufügen eines neuen Vorgehensbaustein passiert dabei nicht beliebig, sondern erfolgt nach den im V-Modell XT vordefinierten Regeln, die als Tailoring-Produktabhängigkeiten bezeichnet werden. Tailowichtigen Beziehungenn von Produkten zu Vorgehensbausteinen. Die Änderung des V-Modell XT ring-produktabhängigkeiten beschreiben die für das dynamische Tailoring ist dementsprechend im Projekthandbuch zu dokumentier ren [VMXT07, S 1-24] ]. Abbil- dung 5 verdeutlicht dieses Konzept. Abbildung 5: Das dynamisches Tailoring [Me04] 2..5 Abgrenzung zu anderenn Vorgehensmodelle Wie bereits angesprochen, gehört das V-Modell XT zur Kategorie der Vorgehensmodel- die in einem Projekt durchzuführen sind. Im Gegensatz zu einer Vorgehensmethodik, die vor allem die detaillierte Beschreibung der Aktivitäten und der dafür zu verwenden- den Methodee und Techniken zum Ziel hat, steht das Managen der gesamten Abwick- lung eines Vorhabens im Vordergrund. Aus diesem Grund sind die Beschreibungen der Aktivitäten im V-Modell XT zum Großteil sehr grob detailliert. So sind beispielsweise Aktivitäten zum Festlegen und Analysieren der Anforderungen an das zu entwickelnde le. Ein Vorgehensmodell beschreibt den Ablauf und die Reihenfolge von Aktivitäten, 9

10 2 Einführung in das V-Modell XT System im V-Modell XT enthalten. Allerdings sind keine konkreten Methoden und Werkzeuge zur Durchführung dieser Aktivitäten zu finden. Es wird zwar angesprochen, mit welchen möglichen Methoden und Werkzeugen diese Aktivitäten durchgeführt werden können, aber im Modell nicht weiter beschrieben. Damit soll eine universelle Anwendung des V-Modells XT in den Vordergrund gestellt werden. Des Weiteren soll ein hoher Detaillierungsgrad verhindert werden. Denn das Modell wäre sonst extremen Änderungen unterworfen, d.h. jeder neue methodische Trend, jeder methodische Fortschritt oder neue Werkzeugversion würde zu einer Änderung und Weiterentwicklung des Modells führen [LO05, S. 1]. Darin unterscheidet sich das V-Modell XT im Wesentlichen von anderen Vorgehensmodellen, wie z. B. RUP-Modell (Rational Unified Process) und OEP-Modell (Object Engineering Process). Das RUP-Modell beispielsweise ist ein von der Firma Rational Software parallel zur UML (Unified Modeling Language) entwickeltes Vorgehensmodell. Es ist daher sehr eng mit der UML verknüpft. Es beschreibt, wie die UML für die objektorientierte Softwareentwicklungen optimal einzusetzen ist [Bal08, S.637]. Außerdem ist das Modell auf Werkzeuge von IBM zugeschnitten. Daraus resultiert, dass die Universalität des Vorgehensmodells dadurch eingeschränkt ist. Im Vergleich dazu ist das OEP-Modell zwar werkzeugneutral, es ist aber auch kein universelles Vorgehensmodell. Es ist eine konkrete Richtlinie für Entwicklungsprozesse, welcher auf eine ganz bestimmte Architektur und Projektorganisation zugeschnitten ist. Außerdem beschreibt das OEP-Modell eine spezielle Methodik und enthält sehr konkrete Definitionen und Konzepte, z.b. was ein primärer oder ein sekundärer Anwendungsfall ist [LO05, S. 2]. Mit dem V-Modell XT lassen sich auch agile Prozesse verwirklichen. Die Grundidee bei der allgemeinen agilen Softwareentwicklung besteht darin, eine einsetzbare Software auszuliefern und in engem Kontakt mit dem Kunden auszubauen. Hierbei wird Wert auf Offenheit und Kommunikation statt Formalismen gelegt. Damit soll den Problemen des schwergewichtigen und bürokratisch angesehenen Softwareentwicklungsstandards entgegen gewirkt werden. Diese Ansätze soll mit der Projektdurchführungsstrategie Agile Systementwicklung des V-Modell XT realisierbar sein. Im Vergleich zu einem der Vertreter der agilen Methoden, dem XP (Extrem Programming), sind jedoch einige Unterschiede zu finden. So ist beispielsweise eine gute Dokumentation des Projektablaufs bei der XP, neben gute Ergebnisse, unerlässlich. Sie steht neben den Ergebnissen im Vordergrund. Im V-Modell XT dagegen steht die Dokumentation eher im Hintergrund. Im Mittelpunkt stehen hier die zu erzeugenden Produkte. Ein weiterer Punkt ist, dass die XP mehr Raum für die Gestaltung der einzelnen Phase im Projektverlauf lassen, denn sie schreibt ein bestimmtes Ergebnis für eine Phase nicht vor. Das V-Modell XT schränkt in dieser Hinsicht den Spielraum ein. Zwar bietet es eine agile Vorgehensweise an, jedoch müssen bestimmte Ergebnisse für den jeweilige Entscheidungspunkt erstellen werden [HH08, S 316]. Als Fazit lässt sich feststellen, dass das V-Modell XT nicht unbedingt als Konkurrenz zu RUP, OEP, XP oder anderen verbreiteten Vorgehensmodellen gesehen werden muss. Diese haben einfach einen anderen, deutlich speziellen Fokus und das V-Modell XT kann diese vielmehr in bestimmten Bereichen ergänzen [LO05, S. 2]. 10

11 3 Werkzeuge für das V-Modell XT 3 Werkzeuge für das V-Modell XT Das V-Modell XT als ein flexibles und konfigurierbares Vorgehensmodell, das für ganz unterschiedliche IT-Entwicklungsprojekten eingesetzt werden kann, bringt neben vielen Vorteilen auch eine hohe Komplexität [HH08, S. 407]. Um diese Komplexität in den Griff zu bekommen, werden Werkzeuge zur Unterstützung der Projektarbeit benötigt. Für das V-Modell XT existieren daher verschiedene Werkzeuge, dessen Funktionalität im folgenden Kapitel beschrieben und bewertet wird. Abbildung 6 gibt einen Überblick über die Werkzeuglandschaft des V-Modell XT. Abbildung 6: Werkzeuglandschaft des V Modell XT [HH08] Wie Abbildung 6 zeigt, existieren im Zusammenhang mit dem V-Modell XT zwei Werkzeuge, die die Bearbeitung des V-Modell XT-Standards und die projektspezifische Anpassung des Modells erleichtern sollen. Daneben existieren noch weitere Werkzeuge die während des Projekts verwendet werden können. 3.1 Der V-Modell XT Editor Der V-Modell XT Editor ist ein Werkzeug, das einerseits von den V-Modell XT-Autoren dazu verwendet wird, den V-Modell XT-Standard zu bearbeiten und weiter zu entwickeln. Andererseits bietet er den Prozessingenieuren eine Unterstützung zur Erweiterung und Anpassung des Modells an branchen- oder unternehmensspezifische Bedürfnisse an. Mit dem Editor können die Anwender bequem auf das in XML-Format (Extensible Markup Language - engl. für erweiterbare Auszeichnungssprache ) vorliegende V-Modell XT-Standard zugreifen. Die Realisierung des Standards in XML- Format ist ein neuer Ansatz, der bei der Entwicklung des Modells gewählt wurde. Dieses Format zeichnet sich dadurch aus, dass es die Inhalte und Dokumente mit ihren Zusammenhängen und Querbeziehungen formal festlegt. Das V-Modell XT in 11

12 3 Werkzeuge für das V-Modell XT XML-Format bildet die Grundlage für die Bearbeitung und Erweiterung des V-Modell XT und somit für den Editor. Damit wird gewährleistet, dass nur zu dem V-Modell XT-Standard konforme Inhalte und Dokumente von den Editor-Anwendern erstellt werden können. Funktionalität des V-Modell XT Editors (Version 3.3.0) Bei dem Editor handelt sich um ein Experten-Werkzeug, das sowohl von den V-Modell- Autoren als auch den Prozessingenieuren benutzt wird. Ihnen stellt es folgende Funktionalität zur Verfügung [HH08, S. 416]: Modellkonforme Bearbeitung der Struktur: Mit Hilfe des Editors können sämtliche Elemente des V-Modell XT und ihrer Zusammenhänge bearbeitet werden. Neue Vorgehensbausteine und Projektdurchführungsstrategien mit samt ihrer Inhalte können beispielsweise erstellt, geändert, miteinander verknüpft und wieder gelöscht werden. Dabei lässt der Editor nur Änderungen zu, die mit dem Metamodell des V-Modell XT konform sind. Konsistenzsicherung: Der Editor bietet eine Funktion zur Prüfung der Konsistenzbedingung an. Sie zeigt dem Bearbeiter an, wo bei der Bearbeitung der Vorgehensbausteine die Bedingung verletzt wurde und er noch nacharbeiten muss. WYSIWYG-Bearbeitung textuelle Inhalte: Es ist ebenfalls möglich, die Inhalte einzelner Textfelder unterschiedlich zu formatieren. Darüber hinaus lassen sich Bilder, Verweise und verschachtelte Listen einfügen. Generierung von Sichten: Zur Funktionalität des Editors gehört auch der so genannte Sichtengenerator. Dieser erzeugt anhand der ihm übergebenen Inhalte (Struktur-Informationen und formatierte textuelle Inhalte) konfigurationsgesteuert unterschiedliche inhaltliche Sichten in verschiedenen Ausgabeformaten wie HTML, LaTeX und PDF. Verteiltes Arbeiten: Der Editor bietet Möglichkeiten zur verteilten Bearbeitung des Modells. Mehrere Bearbeiter können auf derselben Datei arbeiten. Persistente Speicherung: Der Editor nutzt XML-Dateien (Extensible Markup Language - engl. für erweiterbare Auszeichnungssprache ) als Speicherformat. Bewertung des V-Modell XT Editor Mit dem Editor eine gute, aber auch derzeit eine einzige Möglichkeit gegeben ist, bequem und einfach das V-Modell XT-Standard zu bearbeiten und weiter zu entwickeln. Der Editor besitzt folgende Vorteile: + übersichtliche Darstellung des V-Modell XT in seinen gesamten Umfang 12

13 3 Werkzeuge für das V-Modell XT + bequeme und einfache Bearbeitung des Modells + Erzeugung unterschiedlicher Ausgabeformate wie HTML, LaTeX und PDF + Verteiltes Arbeiten + Open-Source-Werkzeug + plattformunabhängig Den Vorteilen stehen folgende Nachteile gegenüber: Experten-Werkzeug, das für normale Anwender keine Anwendung findet keine intuitive Bedienung des Editors Bearbeitungsmöglichkeiten in den WYSIWYG-Texteditoren sind relativ beschränkt. Beispielsweise lassen sich Zeichen nur fett, kursiv und unterstrichen darstellen. Bedienkomfort in vielerlei Hinsicht noch verbesserbar, beispielsweise keine Funktion für das Suchen und Ersetzen von Texten und Modell-Elementen 3.2 Der V-Modell XT Projektassistent Der V-Modell XT Projektassistent ist ein Werkzeug zum Tailoring des V-Modell XT. Mit seiner Hilfe kann für ein konkretes Projekt das Modell an die konkrete Projektsituation angepasst werden, d. h. durch die Auswahl von Projektmerkmalen und Vorgehensbausteinen und die Festlegung von Projektdurchführungsstrategien generiert er ein projektspezifisches Vorgehensmodell samt der zugehörigen Vorlagen, sog. Templates, die die Erstellung der Produkte während Projektplanung und durchführung wesentlich vereinfachen. Darüber hinaus unterstützt der Projektassistent die Initialisierung eines Projektplans (s. Abbildung 6). Der Projektassistent ist im Kontext des V-Modell XT ein zentrales Werkzeug [HH08, S. 432]. Er ermöglicht dem Projektleiter schnell und auf eine einfache Art und Weise die für sein Projekt relevanten Inhalte des V-Modell XT heraus zu filtern. Funktionalität des V-Modell XT Projektassistent (Version 1.2.4) Der V-Modell XT Projektassistent wird vor allem bei der Projektinitialisierung verwendet, um ein projektspezifisches Vorgehensmodell zu erhalten. Dazu stellt er folgende Funktionalität bereit [HH08, S. 432]: Tailoring des Vorgehensmodell Der Projektassistent unterstützt die Auswahl der für ein Projekt relevanten Vorgehensbausteine und Projektdurchführungsstrategien. Veröffentlichung eines projektspezifischen Vorgehensmodells Das projektspezifische Vorgehensmodell kann nach dem Tailoring mit Hilfe des Projektassistenten in unterschiedlichen Formaten (HTML, XML, PDF) veröffentlicht und es den Projektbeteiligten zugänglich gemacht werden. 13

14 3 Werkzeuge für das V-Modell XT Erzeugung von projektspezifischen Vorlagen: Die Erstellung projektspezifische Vorlagen für die Produkte des V-Modell XT ist eine nichttriviale und sehr fehlerträchtige Aufgabe. Mit dem Projektassistent ist eine automatisierte Durchführung im Rahmen des statischen Tailorings möglich. Erzeugung eines initialen Projektplans: Das getailorte Vorgehensmodell für ein Projekt enthält neben den relevanten Vorgehensbausteinen auch mindestens eine Projektdurchführungsstrategie. Anhand dieser kann mit dem Projektassistent ein initialer Grobplan für das Projekt erstellt werden. Bewertung des V-Modell XT Projektassistenten Der V-Modell XT Projektassistent ermöglicht mit seiner einfachen und intuitiven Bedienbarkeit dem Anwender schnell und einfach ein projektspezifisches V-Modell XT samt zugehörigen Vorlagen zu generieren, ohne dass er zuvor damit gearbeitet haben muss. Darüber hinaus ermöglicht er eine grobe Planung der Projektdurchführung. Zudem bietet der Projektassistent als Open Source Werkzeug eine kostengünstige Alternative für Einsteiger. Zusammenfassend betrachtet hat er folgende Vorteile: + einfache und intuitive Bedienbarkeit + einfacher Mechanismus zum Tailoring des V-Modell XT + Erzeugung projektspezifischer Vorlagen + Möglichkeit zur Erzeugung eines initialen Projektplans + Open Source Werkzeuge + Plattformunabhängig Nachteile des Projektassistenten sind: Keine Möglichkeit zur Rollenbelegung und Ressourcenplanung Dynamisches Tailoring nicht unterstützt 3.3 Werkzeuge zur Unterstützung der Managementmechanismen Das V-Modell XT bietet verschiedene grundlegende Managementmechanismen für eine erfolgreiche Projektführung. Dabei ist das Zusammenspiel dieser Mechanismen, insbesondere von Projektmanagement, Qualitätssicherung, Konfigurationsmanagement und Problem und Änderungsmanagement, erforderlich. Wie im Abschnitt 2.3 angesprochen, beinhaltet der V-Modell-Kern diejenigen Vorgehensbausteine, die diese Managementmechanismen bereitstellen [VMXT07, S. 1-23]. Zur Unterstützung dieses Zusammenspiels der Managementmechanismen existieren unterschiedliche Werkzeuge. Das V-Modell XT schreibt dafür keine konkreten Werkzeuge vor. Um dem V-Modell XT-Anwender trotzdem bei der Auswahl der Werkzeuge 14

15 3 Werkzeuge für das V-Modell XT zu unterstützen, gibt das V-Modell XT-Autoren einige Hinweise, welche Werkzeuge eingesetzt werden können. Im Folgenden wird kurz auf diese grundlegenden Managementmechanismen des V-Modell XT und die dafür geeigneten Werkzeuge eingegangen. Projektmanagement Der Projektmanagement-Mechanismus wird in dem Vorgehensbaustein Projektmanagement bereitgestellt. In diesem wird der Entwicklungsprozess geregelt. Abbildung 7 zeigt diesen Mechanismus. Abbildung 7: Projektmanagement Regelkreis [KB05] Aus der Grafik ist zu entnehmen, dass die Projektdurchführung kontinuierlich geplant, kontrolliert und gesteuert wird. Das Ergebnis dieses Prozesses wird für die Entscheidung über den Projektfortschritt dokumentiert. Somit sollen die Risiken eines Fehlschlages minimiert und die Produktqualität erhöht werden. Die Planung, Kontrolle und Steuerung des Projekts sowie die Erstellung der Berichte im Rahmen des Berichtswesens ist bei komplexeren Projekten aufwändig. Um diese zu vereinfachen, sollen daher Werkzeuge zur Unterstützung eingesetzt werden. Das V-Modell XT macht keine konkreten Vorgaben bzgl. der Funktionalität dieser Werkzeuge. Es gibt aber an, welche Merkmale diese mindestens haben sollten, um eine reibungslose Durchführung zu gewährleisten. Folgende Leistungsmerkmale sollten die Projektmanagement-Werkzeuge mindestens aufweisen [HH08, S. 454]: Unterstützung der V-Modell-Rollen: Das Werkzeug sollte die Rollen verwalten und ihnen Bearbeiter zuweisen können. Dadurch werden die Ressourcenplanung und die Zuordnung der verantwortlichen Rollen zu Produkten vereinfacht. Planung konform zu Projektdurchführungsstrategien: Die Meilensteine im Projekt müssen gemäß der Vorgaben der Projektdurchführungsstrategie und ihrer Entscheidungspunkte angeordnet sein. Das Werkzeug muss also eine Möglichkeit bieten aus einem Tailoring-Werkzeug den Projektplan zu importieren. Generierung konformer Berichte: Das Werkzeug soll Möglichkeit zur Genierung der V-Modell XT konformen Produktvorlagen bieten. Integration mit Konfigurationsmanagement und Zeiterfassung: Ein integriertes Cockpit, in dem alle relevante Informationen über den Status der Produktbibliothek und die bisher angefallenen Aufwände übersichtlich bereitstehen, soll vorhanden sein. Damit wird die Beurteilung des Projektstatus erleichtert. 15

16 3 Werkzeuge für das V-Modell XT Intergration mit Problem- und Änderungsmanagement: Die entsprechenden Informationen für das Projektmanagement-System sollten sichtbar dargestellt werden, um die Auswirkungen von Problemen und Änderungen abschätzen und einplanen zu können. Qualitätssicherung Im Laufe eines V-Modell XT Projekts ist eine Menge von Produkten zu erstellen. Diese müssen für ein erfolgreiches Projekt in einer bestimmten Qualität vorliegen. Um sicher zu stellen, dass die Qualität der Produkte zu jeder Zeit im Projektverlauf den im V-Modell XT für jedes Produkt definierten Vorgaben entspricht, ist eine einheitliche und abgestimmte Vorgehensweise für die Prüfung der Produkte notwendig. Dafür ist im V-Modell XT der Managementmechanismus Qualitätssicherung, welcher im Vorgehensbaustein Qualitätssicherung bereitgestellt wird, vorhanden. In diesem Vorgehensbaustein wird festgelegt, welche Produkte und Aktivitäten für einheitliche Vorgehensweise der Prüfung erforderlich sind. Der Ablauf einer Prüfung wird in Abbildung 8 dargestellt. Abbildung 8: Vorgehensweise bei Prüfungen[VMXT07] Zur Werkzeugunterstützung für die Qualitätssicherung macht das V-Modell XT keine konkreten Angaben über die Mindestanforderungen. Es wird lediglich auf die auf dem Markt existierenden Werkzeuge verwiesen. Konfigurationsmanagement-Werkzeuge Wie zuvor erwähnt, entstehen im Projektverlauf zahlreiche Produkte. Zudem können diese in verschiedene Versionen vorliegen. Um einen Überblick über die gesamten Produkte und Ergebnisse zu haben, stellt das V-Modell XT das Konfigurationsmanagement zur Verfügung. Das Konfigurationsmanagement verwaltet alle Produkte und die Produktkonfigurationen, die Informationen über eine Menge zusammengehöriger Produkte in einer bestimmten Version und den Bearbeitungszustand dieser Produkte enthalten, in einer Produktbibliothek. Damit soll gewährleistet werden, dass jederzeit während des gesamten Systemlebenszyklus die volle Transparenz über die Produkte gegeben ist [VMXT07, 1-31]. 16

17 3 Werkzeuge für das V-Modell XT Zur Unterstützung des Konfigurationsmanagement sollen daher folgende Funktionalitäten in den Konfigurationsmanagement-Werkzeugen mindestens verfügbar sein [HH08, S 456]: Verwaltung der Produktbibliothek: Das Werkzeug muss sämtliche Produktinformationen verwalten und diese jederzeit zur Verfügung stellen können. Verteilte Zusammenarbeit: Diese Informationen sollen für alle Beteiligten verfügbar gemacht werden. Verwaltung der Produktstatus: Die Status der einzelnen Produkte müssen verwaltet und dem Projektleiter zugänglich gemacht werden. Damit soll ein Überblick über den Projektfortschritt verschafft werden. Verwaltung der Produktabhängigkeit: Das Werkzeug sollte die Produktabhängigkeiten kennen und verwalten können, um die Prüfung des Konsistenzzustands zu erleichtern. Problem- und Änderungsmanagement Wie bereits angesprochen, wird auf Basis der Produkte über die Projektfortschritte entschieden. Die Produkte müssen also gegebenenfalls überarbeitet und geändert werden, falls die Entscheidung negativ ausfällt. Jedoch ist es ab einem gewissen Fertigstellungsgrad notwendig, die Änderungen an Produkten durch ein formales Verfahren zu verfolgen und nachzuvollziehen. Dieses formale Verfahren wird im Problem- und Änderungsmanagement, welches im Vorgehensbaustein Problem- und Änderungsmanagement bereitgestellt wird, geregelt. Die Vorgaben des Problem- und Änderungsmanagements, wie z. B. für welche Art von Änderungen das Management angewendet werden soll, sind dabei im Projekthandbuch festgelegt [VMXT07, S. 1-31]. Abbildung 9 illustriert den Ablauf im Rahmen des formalen Problem- und Änderungsmanagement. Abbildung 9: Ablauf im Problem- und Änderungsmanagement [KB05] Es existieren verschiedene Werkzeuge zur Unterstützung dieses Verfahren. Das V-Modell XT stellt ebenfalls für diese Werkzeuge keine besonderen Anforderungen. Es sollte aber mindestens folgende Funktionalität bieten [HH08, S. 455]: 17

18 3 Werkzeuge für das V-Modell XT Verwaltung der Problem- und Änderungsinformationen: Das System muss die relevanten Informationen verwalten und anderen Beteiligten zugänglich machen. Generierung konformer Berichte: wie beim Projektmanagement-Werkzeug sollten auch hier Möglichkeiten zur Genierung der V-Modell XT konformen Produktvorlagen angeboten werden. Workflow-Unterstützung: Um den Projektleiter zu entlasten, sollte das Werkzeug die vom V-Modell XT in Aktivitäten vorgegebenen Abläufe über Workflows automatisieren können. Beispielweise könnte der Projektleiter automatisch gewarnt werden, wenn eine Problemmeldung nicht in einer bestimmten Zeit bearbeitet wird. Integration mit Konfigurations- und Projektmanagement: Um eine Analyse der Auswirkung einer Änderungen zu erleichtern, ist eine Integration der Konfiguration- und Projektmanagement-Systemen hilfreich. Zusammenfassend lässt sich also Folgendes sagen: das V-Modell XT verfolgt den Ansatz, dass keine allgemeingültige und vollständige Anforderungen für die eine, ideale V-Modell-Werkzeugumgebung spezifiziert werden muss. Damit soll verhindert werden, dass der Spielraum der Anbieter bei der Werkzeugerstellung von vorne herein eingeschränkt wird. Es ist den Werkzeuganbietern selbst überlassen, möglichst optimale Lösungen für die Erarbeitung der Produkte und die Projektdurchführung bereitzustellen [HH08, S. 452]. 18

19 4 Das V-Modell XT am Beispielprojekt: WiBe Das V-Modell XT am Beispielprojekt: WiBe 4.0 Um die praktische Anwendbarkeit des V-Modell XT zu verdeutlichen, wird in diesem Kapitel der Einsatz des V-Modells XT im Rahmen eines konkreten Beispielprojektes gezeigt. Es handelt sich dabei um das Beispielprojekt WiBe 4.0, das auf einem real durchgeführten Pilotprojekt basiert. 4.1 Das Pilotprojekt WiBe 4.0 Das Projekt WiBe 4.0 ist ein Pilotprojekt, das von der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) in Zusammenarbeit mit der TU München und TU Kaiserslautern durchgeführt wurde. Ziel des Pilotprojekts war die Neuentwicklung einer Software zur Unterstützung von Wirtschaftlichkeitsbetrachtung [KBSt08]. Unter Wirtschaftlichkeitsbetrachtung wird ein Verfahren zur Beurteilung der Wirtschaftlichkeit von Investitionen innerhalb der Bundesverwaltung verstanden. Sie ist durchzuführen, immer wenn ein Projekt der öffentlichen Hand ein bestimmtes Budget überschreitet. Die Wirtschaftlichkeitsbetrachtung basiert auf einem von KBSt veröffentlichten - umfassenden Fachkonzept, das bis dahin durch die Software-Reihe WiBe1.0 bis WiBe 3.0 unterstützt wurde. Dieses Fachkonzept wurde jedoch nach einer Aktualisierung nicht mehr von der Software vollständig abgebildet. Darüber hinaus ist sie nicht mehr auf den aktuellen Stand der Technik [KBSt08]. Nach Beschluss der KBSt wurde die Neuentwicklung nach dem V-Modell XT initiiert. Bei der Neuentwicklung wurden die Aspekte Integration des neuen Fachkonzepts, Netzwerk- und Mehrbenutzerfähigkeit und Unverträglichkeiten mit moderner Software und Überarbeitung der technischen Architektur sowie Verbesserung ergonomischer Aspekte berücksichtigt. Das Projekt WiBe 4.0 war das erste Pilotprojekt, das nach dem V-Modell XT abgewickelt wurde. Es handelte sich um ein Systementwicklungsprojekt, an dem sowohl Auftraggeber als auch Auftragnehmer beteiligt waren. Nach der Durchführung des Pilotprojekts im Jahre 2005, hat die TU München den Projektablauf in dem Dokument V-Modell XT - Praxisbericht aus dem Pilotprojekt IT-WiBe zusammengefasst und diesen dann publiziert. Dabei wurde das Pilotprojekt anonymisiert. Angelehnt an diesem Bericht, wird im folgenden Abschnitt zunächst das Tailoring- Konzept mit Hilfe der Software V-Modell-XT-Projektassistent näher betrachtet. In dem darauf folgenden Abschnitt wird der Ablauf eines V-Modell XT-Projektes beschrieben. Dabei wird ausschließlich das Systementwicklungsprojekt des Auftraggebers betrachtet. 19

20 4 Das V-Modell XT am Beispielprojekt: WiBe Das Tailoring des WiBe-Projekt Wie in Abschnitt 2.4 bereits erläutert, ist das Tailoring eines der Kernkonzepte des V-Modells XT. Es erlaubt eine projektspezifische Anpassung des Modells. Bevor im nächsten Abschnitt auf den Projektablauf eingegangen wird, wird in diesem Abschnitt das statische Tailoring-Konzept an einem konkreten Projekt betrachtet. Das Tailoring eines Projektes kann sowohl computergestützt als auch manuell durchgeführt werden. Die manuelle Durchführung des Tailoring ist allerdings nicht zu empfehlen, da es sich um eine sehr fehlerträchtige Aufgabe handelt. Wie bereits erwähnt, bietet das V-Modell XT zur Unterstützung des Tailorings ein Open Source Werkzeug, den V-Modell XT-Projektassistent, an. Mit Hilfe dieses Werkzeugs wird im Folgenden das Tailoring für das WiBe-Projekt durchgeführt, um einen Überblick über diesen Vorgang zu zeigen. Der V-Modell XT-Projektassistent kann nach der Installation sofort gestartet werden. Nach dem Start und der Auswahl neues Projekt erzeugen öffnet sich das Dialogfenster Projekteigenschaft. Der Anwender wird aufgefordert den Projektname, in diesem Fall ist es WiBe-Projekt, und das Quellenverzeichnis, in denen das komplette V-Modell XT als XML-Format abgelegt ist, anzugeben. Nach der Betätigung der Angaben wird ein neues Projekt angelegt. Das Tailoring des Projekts kann nun begonnen werden. Der erste Schritt des Tailoring ist die Auswahl des Projekttyps. Dies kann direkt durch Wahl des Typen erfolgen. Ein anderes Vorgehen ist die Bestimmung des Typs anhand der Projektmerkmale. Dazu müssen die Projektmerkmale Projektgegenstand und Projektrolle festgelegt werden. Abbildung 10 zeigt den Auswahldialog zu diesem Vorgang. Abbildung 10: Bestimmung des Projekttyps 20

21 4 Das V-Modell XT am Beispielprojekt: WiBe 4.0 Beim WiBe-Projekt handelt es sich um ein Systementwicklungsprojekt, da eine neue Software für die Wirtschaftlichkeitsbetrachtung zu entwickeln ist (vgl. Abschnitt 4.1). Als Projektgegenstand kann also SW-System gewählt werden. Darüber hinaus wird in dieser Arbeit die Systementwicklung auf der Seite des Auftraggebers betrachtet. Der Auftraggeber ist in diesem Fall die KBSt, die die Entwicklung per Ausschreibung an einen Auftragnehmer aufgibt. Somit ist die Projektrolle mit dem Wert Auftraggeber (AG) mit einem Auftragnehmer (AN) zu belegen. Aus der Belegung der Projektmerkmale wählt der Projektassistent automatisch den Projekttyp und den daraus resultierenden verpflichtenden und optionalen Vorgehensbaustein sowie mögliche Projektdurchführungsstrategien aus. Der nächste Schritt des Tailorings ist die Vervollständigung des Anwendungsprofils. Dazu werden weitere Projektmerkmale wie kaufmännisches Projektmanagement, Safety and Security, etc. betrachtet. Dies geschieht unter dem Tab Anwendungsprofil. Tabelle 1 stellt das Anwendungsprofil des WiBe-Projekts dar. Projektmerkmal Wertbelegung Begründung Projektgegenstand SW-System s.o. Projektrolle AG mit einem AN s.o. Systemlebenszyklusausschnitt Kaufmännisches Projektmanagement Quantitative Projektkennzahlen Fertige Produkte Benutzerschnittstelle Entwicklung Nein Nein Nein Nein Das bestehende Softwaresystem zur Wirtschaftlichkeitsbetrachtung wird abgelöst. Der bestehende Quellcode kann aus rechtlichen Gründen nicht weiterverwendet werden. Die ausgeschriebene Neu-Software wird komplett neu entwickelt. Das Projektvolumen und der Realisierungszeitraum sind begrenzt. Die Anwendung eines kaufmännischen Projektmanagements, das über die üblichen gesetzlichen Vorgaben hinausgeht, ist daher nicht erforderlich. Das Projektvolumen und der Realisierungszeitraum sind begrenzt. Die Effektivität des Entwicklungsprozesses soll nicht gemessen werden. Quantitative Projektkennzahlen sind daher nicht zu erstellen. Safety und Security Nein Die zu erstellende Software unterliegt keinen besonderen Datenschutzaspekten. Eine Gefährdung von Personen durch den Betrieb oder Ausfall der Software ist nicht gegeben. Spezielle Vorkehrungen für Safety und Security sind aus diesem Grund nicht vorzusehen; eine Einbettung in verbindliche IT-Rahmenkonzepte ist zu gegebener Zeit durch den Nutzer zu gewährleisten und ist für das Auftraggeberprojekt zunächst nicht relevant. Hohe Realisierungsrisiken Nein Die Problemstellung ist klar definierbar, die potenziell einsetzbaren Technologien sind weitgehend standardisiert und die Projektlaufzeit ist begrenzt. Ein hohes Realisierungsrisiko ist daher nicht gegeben Tabelle 1: Anwendungsprofil aus Projektmerkmalen [vgl. PHB05] 21

22 4 Das V-Modell XT am Beispielprojekt: WiBe 4.0 Anhand des Anwendungsprofils grenzt der Projektassistent im letzten Schritt des Tailorings weiter die optionalen Vorgehensbausteine ein. Der Anwender kann nun die benötigten Bausteine auswählen. Anschließend kann er aus einer durch den Projekttyp eingeschränkten Liste der möglichen Projektdurchführungsstrategien die gewünschte auswählen. Abbildung 11 verdeutlicht diesen Schritt. Abbildung 11: Vorgehensbausteine und Projektdurchführungsstrategien im Projektassistenten Für das WiBe-Projekt sind keine weiteren optionalen Vorgehensbausteine zu wählen, da die meisten Projektmerkmale mit dem Wert Nein belegt wurden. Darüber hinaus ist nur die Durchführungsstrategie Vergabe und Durchführung von Systementwicklungsprojekten (AG) für dieses Projekt möglich. Nachdem alle relevanten Tailoring-Information eingeben wurden, kann die Dokumentation dieses angepassten V-Modells anschließend im PDF-Format oder andere Formate ausgegeben werden. Der ebenso illustrierte Vorgang zeigt, wieso das Tailoring-Konzept eines der wichtigsten Konzepte des V-Modell XT ist. Das Tailoring als projektspezifische Anpassung ermöglicht dem Anwender die nötigen und relevanten Inhalte des V-Modell XT für ein Projekt schnell und unkompliziert zu ermitteln. Über das gerade geschriebene statische Tailoring des Projekts hinaus existiert das dynamische Tailoring. Wie bereits angesprochen, ist eine Anpassung der Projektplanung an neue Erkenntnisse oder neue Projektgegebenheiten jederzeit möglich. In dieser Arbeit wird jedoch nicht näher auf dieses Konzept eingegangen. 22

23 4 Das V-Modell XT am Beispielprojekt: WiBe Der Ablauf des WiBe-Projekt Im Abschnitt 4.2 wurde die für das WiBe-Projekt relevante Projektdurchführungsstrategie bestimmt. Diese muss nun projektspezifisch ausgeplant werden. Die Aufgabe der Ausplanung übernimmt in diesem Beispielprojekt die TU München. Sie gibt die Erstellung des zu realisierenden Systems anhand der von der KBSt festgelegten Vorgaben in Auftrag. Das fertiggestellte System wird anschließend an die KBSt übergeben. Das WiBe-Projekt wird in drei Iterationen durchgeführt. Es wird zunächst nur ein Teil der WiBe-Software erstellt und geliefert. Erst bei Bedarf der zweiten und dritten Lieferung werden die Iterationsschritte zwei und drei durchgeführt. Um den Ablauf des Wi- Be-Projekts nun etwas genau zu betrachten, werden im Weiteren nur der Projektanfang und der erste Iterationsschritt beschrieben. Abbildung 12: Projektanfang und 1. Iteration [vgl. PHB05] Wie bereits erwähnt, müssen für die einzelnen Entscheidungspunkte bestimmte Produkte angefertigt werden. Welche Produkte für welchen Entscheidungspunkt benötigt werden, wird in [VMXT07] genau beschrieben. Abbildung 12 zeigt die relevanten Produkte für den Projektanfang und den ersten Iterationsschritt des WiBe-Projekts Im Folgenden wird betrachtet, wie die Entscheidungspunkte in Abbildung 12 im Einzelnen erreicht werden können. Projekt genehmigt Zu Beginn eines jeden Projektes muss zunächst die Projektidee konkretisiert und ein Projektvorschlag ausgearbeitet werden. In einem Projektvorschlag werden die Informationen und Daten, die die Notwendigkeit eines Projekt deutlich machen, systematisch dargestellt. Darüber hinaus werden in ihm die Qualitäts- und Terminziele und das benötigte Budget beschrieben [VMXT07, S. 5-87]. Nach der Fertigstellung dieses Produkt muss es dem Lenkungsausschuss vorgelegt werden. Dieser entscheidet auf Grundlage des Produkts über die Fortführung des Projektes. Fällt die Entscheidung positiv aus, wird im nächsten Projektabschnitt das Projekt geplant. Im Falle des WiBe-Projekts ist es die Erkenntnis der Notwendigkeit einer Neu- und Weiterentwicklung der Altsoftware zur Wirtschaftlichkeitsbetrachtung. Der Projektvor- 23

24 4 Das V-Modell XT am Beispielprojekt: WiBe 4.0 schlag ist in diesem Beispielprojekt ein Beschaffungsauftrag der KBSt. Daher ist eine Entscheidung über Projektdurchführung nicht erforderlich und der Entscheidungspunkt Projekt genehmigt kann als erfolgreich durchlaufen betrachtet werden [Ku05, S. 13]. Projekt definiert Im diesem Projektabschnitt, der zum Entscheidungspunkt Projekt definiert führt, werden die Projektvorgaben definiert. Darüber hinaus werden die Planung und Organisation des Projektes festgelegt und die Qualitätsziele, die in dem Projektvorschlag grob beschrieben wurden, erweitert und verfeinert [VMXT07, S.3-55]. Im WiBe-Projekt bedeutet es konkret, dass die Vorgaben des Projekts vom KBSt genannt werden. Diese werden dann von der TU München erweitert und verfeinert. Um die Planung und Organisation festzulegen, werden als nächstes das V-Modell XT projektspezifisch angepasst (s. Abs. 4.2) und die Projektbeteiligten bestimmt. Die Ergebnisse der Durchführungen werden im Projekthandbuch und Projektplan dokumentiert. Anschließend müssen noch das QS-Handbuch, das eine Kurzbeschreibung der Qualitätsziele im Projekt und die Vorgehensweise zur Qualitätssicherung beinhaltet, erstellt werden. Auf Grundlage der erstellten Produkte wird im Projektstatusbericht über den Projektverlauf entschieden. Das V-Modell XT sieht eigentlich für die Entscheidung das Produkt Projektfortschrittentscheidung vor. Dieses wird in WiBe-Projekt jedoch nicht als eigenständiges Produkt erstellt. Somit wird eine Vereinfachung des Berichtswesens erwartet [Ku05, S. 72]. Anforderungen festgelegt Nachdem der Entscheidungspunkt Projekt definiert erfolgreich absolviert wurde, müssen in diesem Projektabschnitt die Anforderungen an das WiBe-Projekt analysiert und dokumentiert werden. Dieser erste Entwurf der Anforderungen wird dann hinsichtlich seiner Machbarkeit, Finanzierbarkeit, Wirtschaftlichkeit und Wichtigkeit überprüft. Das Ergebnis der Überprüfung wird in dem Produkt Anforderungsbewertung dokumentiert [VMXT07, S. 6-68]. Wenn keine Änderung an dem Entwurf vorgenommen werden muss, wird dieses zum Produkt Anforderungen (Lastenheft) weiter verarbeitet. Das Produkt enthält somit alle an das zu entwickelnde System verbindlich gestellten Anforderungen. Es ist Grundlage für Ausschreibung und Vertragsgestaltung und damit wichtigste Vorgabe für die Angebotserstellung [VMXT07, S. 5-92]. Des Weiteren muss der Projektplan und der Projektstatusbericht an die aktuelle Situation angepasst werden, um diesen Entscheidungspunkt zu absolvieren. Projekt ausgeschrieben Der Abschluss des Projektabschnitts Anforderung festlegen ist die Freigabe des nächsten Projektabschnitts Projekt ausgeschrieben. In diesem Abschnitt erstellt der Auftraggeber, also die TU München, einen Kriterienkatalog, mit dem die eingegangen Angebote der potentiellen Auftragnehmer bewertet werden. Gleichzeitig dazu wird die Aus- 24