PAULAS PRAGMATISCHE PROJEKTFÜHRUNG

Transkript

1 fachartikel mehr zum thema: vmxt.blogspot.com die autoren DAS V-MODELL XT IM KLEINEN: PAULAS PRAGMATISCHE PROJEKTFÜHRUNG Das V-Modell XT mit seinen knapp 800 Seiten Dokumentation eignet sich nicht für kleine Projekte! Wirklich nicht? Weit verbreitet ist die Vorstellung, dass der Einsatz von Vorgehensmodellen mit einem deutlichen Zusatzaufwand einhergeht und sich somit erst ab einer nennenswerten Projektgröße rechnet. Daher verzichten gerade kleine Projekte häufig auf ein standardisiertes Vorgehen oft mit negativen Konsequenzen für den Projekterfolg. Dieser Artikel zeigt anhand eines einfachen Beispiels die Anpassung des Standards V-Modell XT speziell für kleine Projekte. Dabei steht weniger das Tailoring im Mittelpunkt als vielmehr die diversen oft unbekannten Stellschrauben, die der Standard außerdem bietet. Jan Friedrich ( ist IT-Berater bei der 4Soft GmbH. Er ist einer der Autoren des V-Modell XT und hat das Vorgehensmodell angewandt und angepasst. Projektleiterin Paula steht im Folgenden stellvertretend für die Zielgruppe dieses Artikels. Paula ist verantwortlich für die Entwicklung eines firmeninternen Zeitbuchungssystems, dessen Entwicklungsaufwand mit etwa fünf Personenmonaten veranschlagt wurde. Sie hat sich in die Grundkonzepte des V-Modell XT (vgl. [KBSt]) eingearbeitet und will den Standard einsetzen, um davon im Projekt zu profitieren, etwa durch höhere Effizienz, größere Termintreue und gesteigerte Qualität. Ihr geht es ausdrücklich nicht darum, dass bei Projektabschluss eine umfassende und penibel erstellte Dokumentation vorliegt, mit Hilfe derer sie alle getroffenen Projektund Entwurfsentscheidungen nachvollziehen kann. Paula ist somit in einer angenehmen Ausgangslage: Das V-Modell XT bietet ihr viele Best Practices zur erfolgreichen Projektdurchführung, die sie in ihrem kleinen Projekt flexibel nutzen und anpassen kann. Trotzdem will sie auf Standardkonformität achten (siehe Kasten 1). So kann sie Erfahrungen für zukünftige Projekte sammeln, bei denen ein Auftraggeber die Anwendung des V-Modell XT vorschreibt. Die Anwendung des V-Modell XT im Projekt beginnt mit dem so genannten Tailoring, also der standardkonformen Anpassung des Vorgehensmodells an projektspezifische Bedürfnisse. Der Vorgang als solcher ist denkbar einfach, bereits in vielen Publikationen beschrieben (siehe etwa [Rau05]) und soll daher hier nur überblicksartig erläutert werden. Paula entscheidet anhand bestimmter Charakteristika ihres Projekts, welche Teilprozesse des Standards in ihrem Projekt Anwendung finden sollen und welche nicht. Mit dem Werkzeug V-Modell XT Projektassistent wählt sie eine minimale Menge an Vorgehensbausteinen und erzeugt eine projektspezifische Ausgestaltung des V- Modell XT als PDF-Dokument. Reichlich enttäuscht stellt sie am Ende fest, dass das Dokument immer noch über 500 Seiten hat und 19 Rollen sowie 66 unterschiedliche Produkttypen für ihr Projekt vorsieht. Hinzu kommt, dass ein Produkttyp für eine Gruppe gleichartiger Produkte steht (beispielsweise werden zu dem Produkttyp Besprechungsdokument viele einzelne Dokumente erstellt). Kein Wunder, denkt sie, dass der Standard von vielen als bürokratisch angesehen wird. Elementar für die Anwendung in kleinen Projekten ist daher das Fein-Tuning dieser Vorgaben, also die pragmatische Ausgestaltung hin zu einem notwendigen Minimum. Paula nimmt sich deshalb in der Initialisierungsphase des Projekts vor, zwar die wichtigen Kernkonzepte des V-Modell XT zu übernehmen, aber an den Stellen Einschränkungen vorzunehmen, die für ihr Projekt mit unnötigem Aufwand verbunden wären. Gegenspieler für Paula Ein Blick hinter die Kulissen des V-Modell XT offenbart einige wenige Grundkonzepte, die für Projekte jeder Größenordnung relevant sind. Eines dieser Grundkonzepte ist das Etablieren von Gegenspielern, die gegenläufige Projektziele vertreten. Paula als Projektleiterin sieht sich gemäß V-Modell XT gleich zwei solchen Gegenspieler-Rollen gegenüber: 1. dem QS-Verantwortlichen und 2. dem Lenkungsausschuss. Erstere Rolle besetzt sie mit ihrem Kollegen Quentin, dessen Hauptaufgabe darin Dr. Marc Sihling ( ist Gründer und Geschäftsführer der 4Soft GmbH in München. Er berät Unternehmen im Bereich Softwarearchitektur und -methodik und war bei der Erstellung des V-Modell XT verantwortlich für die Konzeption und Realisierung der Referenzwerkzeuge. besteht, die Anforderungen an die Qualität des Systems konstruktiv und analytisch zu gewährleisten. Der Lenkungsausschuss als weiterer Gegenspieler ist mit Gerhard besetzt, dem Geschäftsführer ihres Unternehmens. Gerhard stellt das Budget zur Verfügung und erwartet regelmäßige Berichte über den Projektfortschritt. Über diese passive Funktion hinaus sieht das V- Modell XT vor, dass der Lenkungsausschuss anhand dieser Berichte explizite Entscheidungen über die Zukunft des Projekts trifft im Idealfall sind dies die Freigaben des jeweils nächsten Projektabschnitts. Aus diesem Grund heißen die entsprechenden Meilensteine im Standard Entscheidungspunkte und die zugehörige Dokumentation Projektfortschrittsentscheidung. Paula ist zunächst über diese kontinuierliche Berichterstattung nicht sonderlich begeistert. Dann wird ihr aber klar, dass ihr Geschäftsführer durch regelmäßige positive Projektfortschrittsentscheidungen selbst Verantwortung für den Projekterfolg übernimmt, sodass diese nicht allein auf Paulas Schultern liegt. Gerhard füllt zudem die 54 55

2 fachartikel Das V-Modell XT unterstützt die Anwendung des gesunden Menschenverstands im Projekt, indem es weitreichende Anpassungen der Vorgaben gestattet, soweit diese ausreichend motiviert und dokumentiert sind. Oft genug wird jedoch die Einhaltung des V- Modell XT vertraglich festgeschrieben, um Mindestanforderungen an die Projektdurchführung zu stellen. In diesen Fällen stellt sich dem Projektleiter die Frage, wann eine organisations- bzw. projektspezifische Anpassung des V-Modell XT im Sinne des Standards und mithin zu diesem konform ist. Der Standard selbst bietet dazu derzeit lediglich eine Reihe von Vorgaben, wie beispielsweise eine Grundmenge an Vorgehensbausteinen (den Kern), einige Regeln zur Rollenbesetzung und eine Mindestmenge an (initialen) Produkten, die in jedem Fall zu erarbeiten sind. Diese Richtlinien sind einerseits recht ungenau und helfen andererseits nicht bei der Beantwortung der Frage, ob ein Vorgehensmodell, das überhaupt nicht auf dem Standard aufsetzt, zum V-Modell XT konform ist. Aus diesem Grund erarbeiten derzeit die Autoren des V-Modell XT ein Konzept zur Konformität. Mit diesem wird es möglich sein, jedes andere Modell auf Konformität zu untersuchen und die Anpassung des Standards in Einzelschritte aufzuteilen, deren Abfolge die Konformität erhält und gewährleistet. Quasi nebenbei wird dabei eine Lösung erarbeitet, die die Migration eines angepassten V-Modell XT auf neue Versionen des Standards auf einfache Weise ermöglicht. Der aktuelle Stand der Arbeiten zur Konformität im Umfeld V-Modell XT wird auf der kommenden Konferenz SEE 2008 (vgl. [SEE]) vorgestellt. Kasten 1: Begrenzte Freiheit. Rolle des Projektmanagers aus, die einen direkten Ansprechpartner für den Projektleiter bei Problemen darstellt und in kleinen Projekten oft mit dem Lenkungsausschuss zusammenfällt. Mit dieser Maßnahme ist sichergestellt, dass das Projekt einerseits Rückendeckung genießt, andererseits aber möglichst wenig Management-Overhead erzeugt. Mit jeder Rolle ist eine klare Zuordnung von Verantwortlichkeiten für einzelne Produkte im Projekt verbunden ein weiteres zentrales Merkmal des produktzentrierten Vorgehensmodells V-Modell XT. Paula kennt dieses Grundprinzip bereits von einer Schulung über PRINCE2, einem vor allem im englischsprachigen Raum verbreiteten Projektmanagement-Standard (vgl. [OGC]): Vor der Vorgabe, wie etwas getan werden soll, steht die genaue Definition dessen, was erarbeitet wird und wer dafür verantwortlich ist. Auch in kleinen Projekten wird somit klar geregelt, wer für die Anforderungen zuständig ist und wer für deren Umsetzung. Gerade für Paulas Kollegen Eric, der als Softwareentwickler die Hauptentwicklungsarbeit im Projekt übernehmen wird, ist dieses Prinzip wichtig: Er muss seine gewohnte Arbeitsweise nicht umstellen, gerade weil das Wie nicht vorgegeben ist. Somit sind keine Produktivitätseinbußen zu erwarten. Nach kurzer Überlegung besetzt Paula die verbleibenden Rollen im Projekt: Quentin wird neben seiner Aufgabe als QS- Verantwortlicher auch noch Verantwortlicher und Administrator des Konfigurationsmanagements. Bei der Besetzung der Rollen Systemarchitekt bzw. Softwarearchitekt fällt auf, dass weder Paula, noch Quentin oder Eric die benötigten Fähigkeiten hierfür besitzen. So kann frühzeitig im Projektverlauf ein weiterer Ressourcenbedarf erkannt und der Kollege Achim in der firmenweiten Ressourcenplanung eingeplant werden. Nach Achims Hinzunahme sind alle benötigten Fähigkeiten im Projekt vorhanden. Insgesamt werden alle weiteren der 19 V-Modell- Rollen durch diese fünf Personen besetzt: Paula, Gerhard, Quentin, Eric und Achim. Manche Rollen sind dabei mehrfach besetzt: So kann im Projekt jeder Beteiligte zu jeder Zeit in die Rolle eines Prüfers schlüpfen. Paulas Spielregeln Nachdem die Rollen besetzt sind, wendet sich Paula der Frage zu, welche Produkte im Verlauf des Projekts erarbeitet werden sollen und in welcher Form. Sie weiß, dass der Standard nur eine vergleichsweise kleine Gruppe an initialen Produkten vorsieht, die in jedem Projekt erarbeitet werden müssen und die sie daher auch für ihr Projekt einplant: Projekthandbuch QS-Handbuch Projektplan Produktbibliothek. Die Erfahrung zeigt, dass diese vier Produkte für jedes Projekt essenziell sind und dass ihre Erstellung die Klärung der wichtigsten Fragen im Projekt beinhaltet. Projekthandbuch und QS-Handbuch definieren jeweils die Ausgestaltung des Projektmanagements und der Qualitätssicherung im Projekt. Dass es hierzu zwei Dokumente gibt, manifestiert die beiden beteiligten Rollen Projektleiterin (Paula) und QS-Verantwortlicher (Quentin) als Gegenspieler im Projekt: Während Paula im Projekthandbuch die Spielregeln für den Projektablauf bestimmt, dokumentiert Quentin, durch welche Maßnahmen er gute Ergebnisqualität sicherstellen will. Erfahrungen belegen, dass weder Projekthandbuch noch QS-Handbuch im Umfang ausufern müssen innerhalb von jeweils zehn bis dreißig Seiten können die zentralen Abläufe und Vorgaben im Projekt ebenso knapp wie präzise ausformuliert werden. Beide Produkte profitieren darüber hinaus besonders von einer hohen Wiederverwendungsrate, wenn die Managementvorgaben in der Organisation standardisiert sind oder zumindest von Projekt zu Projekt ähnlich umgesetzt werden. Paula verweist im Projekthandbuch auf firmeninterne Standards und kann sich dadurch beispielsweise Ausführungen zum Thema Organisation und Vorgaben zum Konfigurationsmanagement ersparen. Der Projektplan terminiert die Meilensteine und Aktivitäten im Projekt. Außerdem fasst er zusammengehörige Aktivitäten zu Arbeitspaketen zusammen und legt Verantwortlichkeiten sowie geplante Aufwände und Ressourcen fest. Paula als Projektleiterin ist dafür verantwortlich, den Projektplan immer wieder mit den Gegebenheiten und neuen Schätzungen abzugleichen, um möglichst realitätsnahe Planungen zu erhalten. Spätestens wenn Paula dem Lenkungsausschuss (Gerhard) den Projektfortschritt präsentiert, muss sie auch einen aktuellen Plan vorlegen. Die Produktbibliothek legt fest, in welcher Struktur die zu erarbeitenden Produkte abgelegt werden. Diese ist je nach Projekt frei wählbar. Das V-Modell XT verlangt aber, dass sämtliche im Projekt erzeugten Produktversionen darin bei Bedarf wiederherstellbar sein müssen. Paula gleicht die Anforderungen zum Konfigurationsmanagement mit der Leistungsfähigkeit des in ihrer Firma eingesetzten Open-Source- Werkzeugs Subversion ab und sieht, dass damit alle Anforderungen erfüllt werden. 2/2008

3 fachartikel Bugtracking-System Mantis vorsieht, sind damit die Informationen aus den geforderten Produkten Problemmeldung, Problembewertung, Änderungsstatusliste und Änderungsentscheidung abgedeckt. Arbeitsaufträge (oft auch Action-Item-Liste, Offene-Punkte-Liste oder To-Do-Liste genannt) und Projektrisiken dagegen verwaltet das Projektteam einfach in Excel-Tabellen. Demgegenüber sind Projektstatusbericht und Besprechungsdokumente als klassische WordDokumente eingeplant (hier wäre grundsätzlich auch denkbar). Den Projektabschlussbericht wird Paula in Form einer PowerPoint-Präsentation halten. Mit der Festlegung, dass Aufwandsschätzungen im Projektplan vermerkt werden und ihr Projekt keine Notwendigkeit für ein Projekttagebuch hat, schließt Paula die Ausgestaltung der Managementprodukte im Projekt ab. Qualität ja bitte, aber wo? Abb. 1: Einige Repräsentationsformen für Produkte, die in Paulas Projekt vorkommen. Dabei ist natürlich vorausgesetzt, dass das Projektteam seine Ergebnisse regelmäßig in das zentrale Repository einstellt. Das V-Modell schreibt nur die Ausarbeitung der initialen Produkte zwingend vor. In ihnen legt das Projektteam selbst fest, ob und wann im Projektverlauf weitere Produkte erstellt werden. Diese können dann ihrerseits die Erstellung weiterer Produkte nach sich ziehen. Bei der Erarbeitung des Projekthandbuchs berücksichtigt Paula die korrespondierenden erzeugenden Produktabhängigkeiten aus dem V-Modell XT und legt die Ausgestaltung weiterer Produkte fest. Der Standard schreibt hier keinesfalls vor, dass alle Produkte zwangsläufig als Dokumente vorliegen müssen (siehe Abb. 1). Da Paula für das Problem- und Änderungsmanagement die Unterstützung durch das Für Quentin, den QS-Verantwortlichen, besteht die Aufgabe in der Erarbeitung eines QS-Handbuchs. Darin muss er hauptsächlich festlegen, welche Produkte im Projektverlauf vom jeweiligen Bearbeiter ohne Weiteres abgeschlossen werden dürfen und welche erst durch eine weitere Person nach dem Vier-Augen-Prinzip geprüft werden müssen. Für die letzteren Produkte sieht das V-Modell XT jeweils eine Prüfspezifikation vor, in der vor der Prüfung festgelegt wird, was wie zu prüfen ist. Für jede durchgeführte Prüfung wird dann ein Protokoll erstellt. Auch hier gilt es wie bei den Managementprodukten eine pragmatische und günstige Darstellungsform zu finden. Prüfspezifikationen können durchaus als knappe formuliert werden. Mit dem Text Bitte prüfe Version 1.2 des Projekthandbuchs hinsichtlich Aufbau und Vollständigkeit, aber nicht hinsichtlich der sprachlichen Gestaltung sind sowohl Prüfobjekt als auch Prüfkriterien eindeutig festgelegt. Als Prüfprotokoll für ein Word-Dokument kann z.b. auch das Dokument selbst mit hinzugefügten Kommentarblöcken gelten. Quentin weiß, dass das V-Modell XT nicht die eigenständige Prüfung aller Dokumente fordert. Er entscheidet sich, lediglich das Lastenheft, das Pflichtenheft und die Systemarchitektur vor deren Fertigstellung prüfen und validieren zu lassen. Die Entscheidung resultiert aus seinem

4 fachartikel Abb. 2: Projektdurchführungsstrategie und Paulas Projektdurchführungsplan. Wissen, dass Fehler gerade in diesen Produkten weitreichende und teure Konsequenzen haben können. Außerdem will er, dass Paula ihm regelmäßig den Projektplan vorlegt, weil dieser die Aufwandsschätzungen für den weiteren Projektverlauf enthält. Sein QS-Handbuch gibt Aufschluss darüber, mit welchen Methoden (z. B. Review) diese analytischen QS-Maßnahmen durchzuführen sind. Zudem gibt es durch konstruktive Maßnahmen Techniken vor, die zu möglichst hoher Produktqualität führen sollen. Da die Firma in der Vergangenheit oft Probleme mit unvollständigen Anforderungen hatte, sucht Quentin für und mit der Anforderungsanalytikerin Paula ein Buch zum Requirements-Engineering aus und fordert im QSHandbuch die Befolgung der darin enthaltenen Methode zur Anforderungsermittlung. Um Aufwand zu vermeiden, legt Quentin im QS-Handbuch ebenfalls noch fest, dass keine Nachweisakte geführt 2/2008 wird und er neben den Qualitätsaussagen in Paulas Projektstatus-Berichten keine gesonderten QS-Berichte erstellen wird. Kein blinder Gehorsam Als nächstes macht sich Paula an die Erstellung eines ersten Projektplans. Grundlage hierfür ist die im Rahmen des Tailorings festgelegte Projektdurchführungsstrategie. Diese legt im V-Modell XT den zeitlichen Ablauf der Entscheidungspunkte des Projekts fest (siehe Abb. 2 oben) und gibt damit vor, wann welche Produkte erarbeitet werden. Paula hat sich für die so genannte inkrementelle Systementwicklung entschieden. Diese Strategie ist für relativ risikoarme Entwicklungen geeignet und basiert auf dem klassischen Vförmigen Vorgehen, sieht aber explizit auch die Möglichkeit für Iterationen vor. Der erste Entscheidungspunkt Projekt genehmigt wurde bereits durchlaufen, bevor Paula als Projektleiterin berufen war. Mit der Erstellung der Handbücher, des Projektplans und der Produktbibliothek ist das Projekt bereits gut vorbereitet für den Entscheidungspunkt Projekt definiert. Paula geht die verbleibenden Entscheidungspunkte durch und überlegt sich dabei, welche Produkte erarbeitet werden sollen. Für den Entscheidungspunkt Anforderungen festgelegt sieht das V-Modell XT die Erarbeitung der Produkte Lastenheft und Anforderungsbewertung vor. Im Lastenheft werden die Anforderungen an das zu erstellende System möglichst technikunabhängig beschrieben. Die Anforderungsfestlegung umfasst dabei sowohl die funktionalen als auch die nicht-funktionalen Anforderungen, dazu Abnahmekriterien und den gewünschten Lieferumfang. Damit entspricht es exakt dem, was Paula auch in diversen Büchern zum Thema Software-Engineering gelesen hat. Darüber hinaus fordert das V-Modell XT zwingend eine so genannte Anforderungs-

5 Aus zwei mach eins Das V-Modell sieht einen zweistufigen Prozess des Systementwurfs vor: Zunächst soll das System (also das Zeitbuchungsprogramm) durch eine Systemarchitektur in Softwareeinheiten (z. B. Client- und Server-Anteile) zerlegt werden; danach werfachartikel den diese Softwareeinheiten durch Softwarearchitekturen bis auf die Ebene von Softwaremodulen (also z. B. Java-Klassen) zerteilt. Da im Projekt ein relativ kleines Softwaresystem ohne Hardwarebestandteile entwickelt werden soll, beschließt Achim, diesen zweistufigen Prozess in einem Entwurfsschritt zusammenzufassen. Dazu werden die entsprechenden Architekturen und auch die dazugehörigen Implementierungs-, Integrations- und Prüfkonzepte (IIPK) jeweils zu einem Produkt zusammengelegt, was im V- Modell XT durchaus zulässig ist. Damit geht auch eine Zusammenlegung der Entscheidungspunkte System entworfen und Feinentwurf abgeschlossen zu Softwaresystem entworfen einher, was eine erneute Reduzierung des Management-Overheads bedeutet. Achim muss also im Wesentlichen die Produkte Software-Systemarchitektur und IIPK Softwaresystem erarbeiten, die jeweils zwei V-Modell-Produkte zusammenfassen. Als Architekt im Projekt entscheidet er mittels dieser Produkte, welcher Aufwand für Spezifikation und Prüfung des Systems benötigt wird. Die Software-Systemarchitektur bestimmt zunächst die grundsätzlichen Architekturprinzipien. Beispielsweise könnte hier beschrieben sein, warum eine Client/Server- Architektur gewählt wird, welche Frameworks benutzt werden und wie im Systementwurf das Model/View/Controller-Entwurfsmuster angewandt wird. Des Weiteren beschreibt das Produkt den Aufbau des Systems und identifiziert alle Softwarekomponenten sowie die wichtigsten Softwaremodule (Klassen). Achim legt in der Software-Systemarchitektur außerdem querschnittliche Systemeigenschaften, wie z. B. Persistenz von Daten oder Logging-Mechanismen fest. Aus der Software-Systemarchitektur sind zudem alle internen Schnittstellen und Datenstrukturen mit Attributen und Datentypen ersichtlich, die Achim in einem abstrakten Datenmodell mit einem CASE-Tool modelliert. Schließlich legt die Software-Systemarchitektur auch fest, welche der zu entwickelnden Softwareelemente vor der Entwicklung noch genauer spezifiziert werden müssen; gegebenenfalls beinhaltet sie schon konkrete Java-Interface-Deklarationen. Achim lässt in der Ausgestaltung dieses Produkts wiederum Pragmatismus erkennen. Es gibt nicht ein integriertes Dokument, sondern die Software-Systembewertung. Diese soll vor allem die Wünsch-dir-was-Mentalität verhindern also den Fehler, alle nur denkbaren Anforderungen zu spezifizieren und das Projekt dadurch zu verkomplizieren und zu verteuern. Da im konkreten Projekt sowohl die Anforderungsfestlegung als auch die Entwicklung durch das gleiche Team geleistet werden, sieht Paula diese Gefahr nicht und ist so frei, an dieser Stelle bewusst vom V-Modell XT abzuweichen und keine Anforderungsbewertung durchzuführen. Sie dokumentiert diese Entscheidung im Projekthandbuch im dafür vorgesehenen Thema Abweichungen vom V-Modell. Im weiteren Projektverlauf sieht das V- Modell XT die Erstellung eines Pflichtenhefts vor. In kleinen Projekten kann dieses typischerweise einfach erstellt werden, indem das Lastenheft um technische Details angereichert wird, vor allem um die genaue Spezifikation der Schnittstellen zur Systemumgebung. Außerdem gibt das Pflichtenheft vor, welche Dokumentation zum System (Ausbildungsunterlagen und Nutzungsdokumentation) erstellt wird. Paula entscheidet sich an dieser Stelle für ein zunächst sehr rudimentäres Benutzerhandbuch in Form einer Online-Dokumentation, da innerhalb der eigenen Firma ein direkter Kontakt zu den Produktentwicklern besteht. Die bislang noch nicht betrachteten Produkttypen aus dem V-Modell XT betreffen hauptsächlich die Systementwicklung. Hier kann noch weiter unterschieden werden zwischen Systementwurf und Systemelementen. Ein Systemelement ist ein konkreter Bestandteil des Systems und umfasst sowohl Quellcode als auch Bibliotheken, Konfigurationsdateien usw. Paula erscheint die verwendete Nomenklatur etwas gewöhnungsbedürftig: Statt den Entwicklern bekannten Begriffen wie Programm, Paket und Klasse ist hier von Segment, Einheit, Komponente und Modul die Rede. Sie beauftragt Achim, eine Abbildung zwischen den beiden Begriffswelten zu erstellen und diese im Projekthandbuch unter Organisation und Vorgaben zur Systemerstellung zu hinterlegen. architektur ist im konkreten Projekt ein Dateiordner, in dem sich Dokumente, aber auch Modelle und Bilder befinden (siehe Abb. 2 und Abb. 3). Wichtig ist, dass sich alle geforderten Inhalte in dem beschriebenen Ordner befinden, und nicht, in welcher Weise sie repräsentiert sind. Mit Maven und JUnit Dokumente vermeiden Beim IIPK (siehe oben) hält der Inhalt, was der Name verspricht: Das Produkt gibt vor, wie das System implementiert, integriert, installiert und geprüft wird, und legt dabei vor allem fest, welche Systemelemente geprüft werden. Im Projekt wird das Build- Management-Tool Maven eingesetzt und der Systemarchitekt Achim erkennt, dass viele der geforderten Inhalte des V- Modell-Produkts durch eine konkrete Konfiguration des Werkzeugs abgedeckt werden. Maven bietet beispielsweise die Möglichkeit, das Vorgehen zur Integration und den Integrationsbauplan mittels einer XML-Datei zu spezifizieren (pom.xml, siehe Abb. 3). Er verzichtet deshalb darauf, die Inhalte nochmals in natürlicher Sprache auszuformulieren. Er legt außerdem fest, welche Systemelemente geprüft werden sollen. Dazu gibt er vor, für welche Elemente JUnit-Tests geschrieben werden. Bevor der Meilenstein Softwaresystem entworfen erreicht werden kann, muss der Entwickler Eric noch die Softwarespezifikationen und Prüfspezifikationen gemäß Achims Vorgaben erstellen. Da es sich bei dem System um eine pure Java-Entwicklung handelt, entschließt er sich, die Softwarespezifikationen in Form von Java- Interfaces zu repräsentieren. Die Prüfspezifikationen bzw. -prozeduren repräsentiert Eric als JUnit-Testklassen. Dabei werden der JavaDoc-Kommentar und die Implementierung der Klasse als Prüfspezifikation und -prozedur angesehen. Eric folgt damit dem Ansatz der testgetriebenen Entwicklung, die er von agilen Methoden wie extreme Programming (XP) schon kennt und in einem schwergewichtigen Standard wie dem V-Modell XT nicht vermutet hätte. Nach Erreichen des Entscheidungspunkts Softwaresystem entworfen arbeitet Eric ausschließlich an der Implementierung des Systems. Das impliziert, dass es ihm auch schon zuvor erlaubt war, mit der Implementierung zu beginnen. Das V-Modell XT kennt ausdrücklich keinen 58 59

6 fachartikel Abb. 3: Produktbibliothek im Projekt: Grundsätzliche Aufteilung in Management- und Entwicklungsteil, V-Modell-Produktgruppen dienen zur weiteren Strukturierung. Phasenbegriff und macht keine Aussagen darüber, wann welche Aktivitäten begonnen werden dürfen. Es schreibt im konkreten Fall bei der gewählten Projektdurchführungsstrategie nur vor, dass der Entwurf des Systems fertig sein muss, bevor das System fertig implementiert und integriert ist. (siehe Abb. 1). Im Übrigen sieht das V-Modell XT explizit auch eine iterativ-inkrementelle Entwicklung vor: Achim und Eric könnten in belieb vielen Iterationen die Architektur und die Implementierung Schritt für Schritt weiter ausbauen. Während die Systementwicklung läuft, definiert Anforderungsanalytikerin Paula, wie die Anforderungen aus dem Lastenheft am fertigen System überprüft werden sollen. Sie erstellt daher die Prüfspezifikation Lieferung, anhand derer dann die Abnahme durchgeführt wird. Dabei wählt sie auch Testanwender aus, die sie bei den Abnahmetests unterstützen werden. Diese entscheiden dann bei den Abnahmetests, ob Achim und Eric die gestellten Anforderungen korrekt umgesetzt haben. Paula fasst die Testergebnisse und Kommentare zusammen. Das Ergebnis dient als Prüfprotokoll der Lieferung bzw. als Abnahmeerklärung. Bei Erfolg (oder geringen Mängeln) soll das System in die Wartungs- und Pflegephase überstellt und das Projekt abgeschlossen werden. Bei größeren Mängeln kann der Entscheidungspunkt Abnahme erfolgt nicht erreicht werden und Achim und Eric müssen in weiteren Entwicklungsschritten zunächst die Mängel beseitigen. Am Ende des Projekts sieht das V-Modell XT einen formalen Projektabschluss und eine Auflösung des Projekts durch den Lenkungsausschuss vor. Paula hat im Projekthandbuch vorgegeben, dass ein Projektabschlussbericht zu erstellen ist. Sie wählt dafür die Form einer PowerPoint- Präsentation und stellt darin nochmals vor, wie die Ausgangslage des Projekts war und welche Projektergebnisse erzielt wurden. Quentin gibt zudem eine Qualitätsbewertung der Ergebnisse ab. Schließlich werden die Projekterfahrungen zusammengetragen und bewertet Zusammenfassung Paula und ihre Mannschaft haben das V- Modell mit Augenmaß angewandt und in die Praxis umgesetzt. Sie haben den Vorgehensstandard nicht als Gängelung verstanden, sondern geschickt eingesetzt, um an den wichtigen Punkten des Projekts nichts Entscheidendes zu vergessen. In einem begründeten Ausnahmefall haben sie sich sogar über die Vorgaben des Vorgehensmodells hinweggesetzt, um unnötige Aufwände zu vermeiden. Bei der Erarbeitung der Produkte ging es ihnen nicht darum, möglichst viele perfekte Dokumente zu erzeugen, sondern sie haben pragmatisch immer die jeweils günstigste Darstellungsform für Produkte gefunden. Dabei haben sie auch bemerkt, dass das V- Modell XT und agile Methoden sich nicht grundsätzlich ausschließen, sondern teilweise sogar vereinen lassen. Mit solch einer pragmatischen Projektdurchführung kann das V-Modell XT auch für kleine Projekte einen enormen Mehrwert darstellen. Literatur & Links [KBSt] Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung, Das V-Modell XT, siehe: [OGC] Office of Government Commerce, Managing Successful Projects with PRINCE2, TSO, London, 2002 [Rau05] A. Rausch, D. Niebuhr, Erfolgreiche IT-Projekte mit dem V-Modell XT, in: OBJEKTspektrum 3/05 [SEE] Konferenz Software & Systems Engineering Essentials, siehe: 2/2008