Schriften zum Software-Qualitätsmanagement

Transkript

1 Software-Qualitätsmanagement: Theorie & Praxis herausgegeben von Roland Petrasch Band 3 Schriften zum Software-Qualitätsmanagement Vorgehen, Methoden und Werkzeuge für die Software-Qualitätssicherung Roland Petrasch, Stephan Höppner (Hrsg.)

2 Editorial Editorial Software-Qualitätsmanagement scheint alles und nichts zu sein: Im konstruktiven Bereich fällt so ziemlich alles darunter, was auch nur ansatzweise die Qualität (positiv) beeinflussen könnte, z. B. wäre jedes CASE-Tools oder jede höhere Programmiersprache als Qualitätssicherungsmaßnahme zu bezeichnen, womit sicherlich der Teildisziplin Software-Qualitätsmanagement nicht geholfen ist, da sie dadurch in der Beliebigkeit verschwindet. Und im analytischen Bereich? Da bliebt nur das ewig ungeliebte Wesen Testen, welches sich nur langsam vom Boden, an dem es lange Zeit lag, zu erheben vermag. An dieser Stelle müsste nun eigentlich das alt bewährte Schönreden beginnen: Es ist alles nicht so schlimm, und wenn es schlimm sein sollte, es wird sicherlich bald besser, die Menschen lernen von den Fehlern der Vergangenheit, Qualität setzt sich durch auf in der IT-Branche, die Erde ist eine Scheibe. Sie sehen, liebe Leserin, lieber Leser: Diesmal setzen wir nicht zu einer zweckoptimistischen Rede an und machen Mut im Gegenteil; nachdem wir das Maut-Debakel 1 mit Toll-Collect erlebt haben, zuschauen müssen, wie das Projekt Fiskus nach über 13 Jahren zu scheitern droht 2, sich der Web- Auftritt des Arbeitsamtes als Online-Jobsuche mit Hürden erweist 3 und sich die Handwerksverband mit seiner Portal-Pleite 4 thematisch dazu gesellte (wohl auf Kosten Ihrer Zwangsmitglieder), scheint die berechtigte Frage: Kann es überhaupt ein Software-Projektmanagement geben, welches in der Lage ist, die minimale Software-Qualität a priori und beim ersten Anlauf sicherzustellen? So langsam drängt sich der Verdacht auf, dass es gar nicht die Unfähigkeit oder Inkompetenz der Beteiligten ist, sondern eine Art Naturgesetz wirkt aber diese Behauptung ist doch zu abenteuerlich und pessimistisch, oder? 1 vgl. 2 vgl. 3 vgl. und 4 vgl. und I

3 Editorial Frustrierend auch, dass der Mensch (bzw. das Unternehmen) zuweilen die eigene Vergangenheit vergisst : Die Suche nach einem Photo und einen Artikel vom Absturz der Ariane-5-Trägrerrakete (1996) auf der ESA-Website 5 war erfolglos. Gerade für Studenten ist dieses Beispiel für die Folgen von Software-Fehlern jedoch recht interessant. Es stellt sich die Frage, warum sämtliche Informationen von der Website verschwunden oder nicht zu finden sind. Welch ein Armutszeugnis, wenn man sich nicht offen an die eigenen Fehler erinnern will. Solch eine Art Vertuschungsstrategie für die Außendarstellung stärkt nicht gerade das Vertrauen und den Glauben in die internen Verbesserungsbemühungen, die sicherlich bitter notwendig sind. Der Software-Fehler in den C65-Mobiltelefonen der Firma Siemens erregte Aufsehens: So langsam wird klar, dass selbst so etwas harmloses wie ein Handy, Gehörschäden verursachen kann, wenn eine Melodie fälschlicherweise mit voller Lautstärke direkt am Ohr abgespielt wird 6. Immerhin war der Hersteller um schnelle Schadensbegrenzung bemüht. Mittlerweile gibt es eine Entwarnung beim Akustikproblem hoffentlich kann man sich im Unternehmen (und auf der Website) auch im nächsten Jahr noch an den Vorfall erinnern und muss nicht seine eigene Geschichte bereinigen. Dennoch bleibt die Hoffnung, dass wir als Anwender, die immer stärker von der Software-Qualität abhängig sind, eine professionelle Software- Entwicklung voraussetzen können, die aus der Vergangenheit gelernt hat. Dieser Band will mit seiner Mischung einige aktuelle Themen ansprechen hier ein kurzer Überblick: Das neue V-Modell XT (Beitrag von Andreas Rausch und Stephan Höppner), welches uns sicherlich die nächsten Jahre intensiv beschäftigen wird, darf natürlich genauso wenig fehlen, wie der Dauerbrenner Anforderungen und deren Qualität (Beitrag von Christiane Gernert, Stephan Höppner). Immer wichtiger wird auch der Bereich der Formalisierung (Beitrag von Oliver Meimberg) was sich nicht zuletzt auch durch die Verbreitung von MDA (Model-Driven Architecture) zeigt. Erfreulich sind sicherlich auch die Aktivitäten für die Aus- und Weiterbildung: Während der Software-Test an Hochschulen oftmals wohl eher ein Schattendasein fristet, bildet sich das Berufsbild des Software-Testers in der Praxis heraus (Beitrag von Horst Pohlmann et al.). 5 vgl. und 6 vgl. II

4 Ausgangssituation Nach wie vor ist die Analyse, Bewertung und Einsatzplanung von Werkzeugen für das QS ein wichtiges, aber oft unterschätztes Thema für Unternehmen (Beitrag von Svenja Lübbering). Eine wahre Renaissance erlebt das Thema Software-Ergonomie in den letzten Jahren, so dass das Thema Usability Testing (Beitrag von Hubert Vossen) hier sicherlich ein interessierten Leserkreis erreichen dürfte. Generell vom Scheitern der elearning-systeme an Hochschulen zu sprechen, wäre sicherlich unzulässig, aber der virtuelle Traum vieler Online- Studiengänge scheint ausgeträumt zu sein Qualität: Fehlanzeige (Beitrag von Roland Petrasch). Wir, die Herausgeber, bedanken uns bei den Autoren für die interessante Arbeit und freuen uns über Ihr Feedback, über Ihre Meinung und über Ihre Anregungen. Sie erreichen uns unter Roland Petrasch, Stephan Höppner im November 2004 III

5 Inhaltsverzeichnis Inhaltsverzeichnis V-Modell XT eine Einführung... 1 Andreas Rausch, Stephan Höppner Qualität von Anforderungen in IT-Projekten eine andere Perspektive Christiane Gernert, Stephan Höppner Möglichkeiten und Potentiale der Formalisierung in der Softwareentwicklung Oliver Meimberg GI-Arbeitskreis "Berufsbild Software Tester (IT-ST) Positionspapier: Empfehlungen für das Berufsbild, die Ausbildung und die Qualifikationsstufen des Software-Testers Horst Pohlmann, Michael Averstegge, Tilo Linz, Roland Petrasch, Eike Riedemann, Ina Schieferdecker, Stephanie Ulrich Analyse, Bewertung und Einsatzplanung von Werkzeugen der statischen Analyse in der Software-Qualitätssicherung Svenja Lübbering The Role of Usability Testing in Software Quality Control: Finding Mismatches, not Defects Paul Hubert Vossen Hypermedia-Anwendungen im Bereich elearning: Gedanken zur Qualität Roland Petrasch Autorenverzeichnis V

6 J.-Prof. Dr. Andreas Rausch Universität Kaiserslautern Dipl.-Ing. (FH) Stephan Höppner AIOS Consulting GmbH Managementberatung Zusammenfassung Auch erfahrene Projektmanager haben häufig mit Risiken im Projektalltag zu kämpfen, die den Erfolg ihres Projekts und die Qualität des Ergebnisses gefährden. Das neue V-Modell XT beschreibt ein Vorgehensmodell, das diese Risiken mindert und die Qualität der Projektergebnisse verbessert. Neben der überblicksartigen Vorstellung grundsätzlicher Neuerungen in Inhalt und Struktur des neuen V-Modells XT möchte der Artikel einige praktische Auswirkungen für Auftraggeber und Auftragnehmer konkreter beleuchten. Ausgewählte Neuerungen werden eingehender vorgestellt und somit das Gesamtkonzept besser verständlich. 1

7 Inhaltsverzeichnis 1 Ausgangssituation Viele Neuerungen grundsätzlicher Art Erweiterung des inhaltlichen Fokus Vorgehensbaustein die modulare Einheit Projektdurchführungsstrategien und Entscheidungspunkte Gesamtstruktur und sichtenbasierte Darstellung des V-Modells Trennung zwischen der Auftraggeber- und der Auftragnehmersicht Ziel- und ergebnisorientierte Vorgehensweise des V-Modells Leichtes und schnelles Tailoring, integrierte Projektplanung Was ändert sich für die Auftraggeber - Vorteile/Nachteile? Änderungen für Auftragnehmer Änderungen für Auftraggeber Konkretere Erhebung und Festlegung von Anforderungen Unterstützung von Ausschreibung und Vergabe Qualitätssicherung mit dem neuen V-Modell Anpassung, Einführung und Verbesserung eines organisationsweiten Vorgehensmodells Ausblick

8 1. Ausgangssituation Manche IT-Projekte misslingen völlig, andere kosten mehr Zeit und Geld als geplant. Konnte das V-Modell 97 Missstände beseitigen? Baute nicht das teilweise umständliche und zeitraubende Tailoring für viele Projektleiter zu hohe Hürden zur Anwendung des V-Modells auf? Wurde das V-Modell nicht allzu häufig formalisiert und bürokratisch angewandt, anstatt es mit Augenmaß und Angemessenheit risikomindernd und nutzbringend einzusetzen? Ursprünglich wurde das V-Modell im Auftrag des Bundes mit dem Ziel entwickelt, IT-Projekte mit größerer Erfolgswahrscheinlichkeit und Qualität abzuwickeln und nach Fertigstellung besser wartbare Produkte zu erhalten sowie die Abhängigkeit vom Auftragnehmer zu verringern. Nach ursprünglicher Anwendung in militärischen IT-Projekten und System-Entwicklungsprojekten dehnte sich nach Fertigstellung der Version 97 der Anwendungsbereich auch auf alle zivilen Bundesbehörden aus. Der Einsatz des V-Modells ist für alle IT-Projekte von Bundesbehörden im zivilen und militärischen Bereich vorgeschrieben. Mittlerweile setzen aufgrund der Vollständigkeit, Allgemeingültigkeit und freien Verfügbarkeit des V-Modells eine Vielzahl von privatwirtschaftlichen Unternehmen das V-Modell erfolgreich ein oder haben eigene, angepasste Vorgehensmodelle davon abgeleitet. In anderen Ländern, wie z. B. der Schweiz, diente das V-Modell als Vorlage, um eigene, angepasste Vorgehensmodelle (z. B. Hermes) zu erstellen. In Österreich wurde es vollständig übernommen. Das V-Modell 97 wurde 1997 veröffentlicht und seitdem kaum fortentwickelt. Dem aktuellen Stand der Informationstechnologie und eingesetzten Methoden, wie z. B. komponentenbasierte Entwicklung oder Test-First-Ansatz, entspricht das V-Modell nicht mehr in vollem Umfang. Derzeit wird das V-Modell 97 aktualisiert und erweitert, Schwächen werden ausgemerzt. Der Bund hat als Auftraggeber die TU München, die TU Kaiserslautern sowie weitere Industriepartner wie 4Soft, EADS, IABG und Siemens mit der Überarbeitung und Erweiterung des V-Modells beauftragt. Im Rahmen dieses Projekts WEIT wurden folgende Ziele verfolgt: Verbesserung der Unterstützung von Anpassbarkeit, Anwendbarkeit, Skalierbarkeit und Änder- und Erweiterbarkeit des V-Modells Berücksichtigung des neuesten Stands der Technologie und Anpassung an aktuelle Vorschriften und Normen Erweiterung des Anwendungsbereiches auf die Betrachtung des gesamten Systemlebenszyklus im Rahmen von Entwicklungsprojekten 3

9 Einführung eines organisationsspezifischen Verbesserungsprozesses für Vorgehensmodelle Der Einsatz des V-Modells XT in Projekten fokussiert auf folgende Ziele: Minimierung der Projektrisiken Verbesserung und Gewährleistung der Qualität Eindämmung der Gesamtkosten über den gesamten Systemlebenszyklus Verbesserung der Kommunikation zwischen allen Beteiligten. Auftraggeber, die hierin Ziele erkennen, die für die eigene Organisation wichtig sind, sollten den Einsatz des V-Modells XT in der eigenen Organisation zumindest prüfen. Das V-Modell XT (exreme Tailoring) ist ein umfassendes Vorgehensprozessmodell bzw. eine Projektmanagementmethode für die Planung und Durchführung der Systementwicklung in IT-Projekten, also eine modellhafte Abbildung aller erforderlichen Tätigkeiten und Ergebnisse eines IT-Projekts. Es richtet sich besonders an alle Projektleiter und Führungskräfte, die Vorhaben beabsichtigen, durchführen oder begleiten. Erfolgreiche Projekte erfordern eine zielgerichtete Führung, Abwicklung und Kontrolle, was durch grundlegende Managementmechanismen im V-Modell abgesichert werden kann. Das V-Modell ist frei verfügbar, flexibel anpassbar, leicht erlernbar und schnell einsetzbar just do it! 2. Viele Neuerungen grundsätzlicher Art Bei der Weiterentwicklung des V-Modells wurde die monolithische Struktur aufgebrochen und durch eine flexible, komponentenbasierte Architektur ersetzt. Die grundlegenden Konzepte und Ansätze des V-Modells XT werden im folgenden kurz dargestellt Erweiterung des inhaltlichen Fokus Bisher unterstützte das V-Modell die Durchführungsphase von Softwareentwicklungsprojekten. Das überarbeitete V-Modell XT unterstützt zukünftig neben den sehr häufig auftretenden Migrationen auch die Entwicklung von komplexen Systemen (bestehend aus Hard- und Software). Darüber hinaus bietet das V-Modell XT eine ganzheitliche Sicht auf alle Phasen der Systementwicklung. Es bildet somit nicht mehr nur die reine Durchführungsphase von IT-Projekten ab, sondern: 4

10 Das V-Modell XT unterstützt erstmals und ganz hervorragend die frühen Planungs- und Vorbereitungsphasen. Das V-Modell XT unterstützt während der Entwicklung auch die Planung der Inbetriebnahmephase, der Betriebsphase, Wartung und Pflege, etc. bis hin zur Außerbetriebnahme, so dass der komplette Systemlebenszyklus abgebildet ist. Dabei ist jedoch nur die Planung und Vorbereitung des Betriebs, der Wartung und Pflege usw. abgedeckt, nicht jedoch die konkrete Durchführung dieser Phasen Vorgehensbaustein die modulare Einheit Um die angesprochenen Qualitätseigenschaften des V-Modells zu verbessern, besteht das V-Modell XT aus modularen, aufeinander aufbauenden Vorgehensbausteinen. Der Vorgehensbaustein ist die zentrale Einheit im neuen V-Modell XT. Ein Vorgehensbaustein deckt eine konkrete Aufgabenstellung ab, die im Projekt vorkommen kann wie beispielsweise das Projektmanagement oder die Softwareentwicklung und enthält die erforderlichen Ergebnisse (Produkte), Aktivitäten, und Rollen. Angeleitet durch eine Art Bauplan kann der V-Modell-Anwender aus diesen Vorgehensbausteinen sein projektspezifisches V-Modell zusammenstellen. Dabei kann ein V-Modell- Anwender das V-Modell projektspezifisch anpassen, ohne dass er die in den einzelnen Bausteinen enthaltenen Aktivitäten, Produkte und Rollen bereits im Detail verstanden haben muss. Die projektspezifische Anpassung des V-Modells wird im Folgenden als Tailoring bezeichnet. Vorgehensbaustein beinhaltet untergeordnete Aktivitäten beinhaltet untergeordnete Produkte 1 * 1 1 bearbeitet Aktivität * Produkt * * * verantwortlich 1 * * hat Abhängigkeiten zu anderen Rolle Abb. 1: Vorgehensbausteine und ihre Bestandteile Dementsprechend kapselt ein Vorgehensbaustein diejenigen Produkte, Aktivitäten und Rollen, die unter Tailoring-Gesichtspunkten inhaltlich zusammen- 5

11 gehören (vgl. Abbildung 1). Der Vorgehensbaustein ist die zentrale Einheit des Tailoring. Er kann eigenständig verwendet werden und ist einzeln änderund erweiterbar. Da Vorgehensbausteine aufeinander aufbauen, sind dabei Abhängigkeiten zu anderen Vorgehensbausteinen, auf denen dieser Vorgehensbaustein basiert, zu beachten. Abbildung 1 veranschaulicht, dass ein Vorgehensbaustein hierarchisch strukturierte Aktivitäten und Produkte sowie zugehörige Rollen beinhaltet. Aktivitäten und Produkte sind dabei jeweils in drei Hierarchieebenen unterteilt: Aktivitätsgruppen, Aktivitäten und Teilaktivitäten und analog dazu Produktgruppen, Produkte und Themen. Jedes Produkt wird von genau einer Aktivität erstellt. Für jedes Produkt ist genau eine Rolle verantwortlich. Die einzelnen Produkte können voneinander abhängig sein. Eine solche Produktabhängigkeit beschreibt eine Konsistenzbedingung zwischen zwei oder mehreren Produkten. Dabei kann eine Produktabhängigkeit sowohl innerhalb eines Vorgehensbausteins als auch zwischen Produkten verschiedener Vorgehensbausteine bestehen Projektdurchführungsstrategien und Entscheidungspunkte Im V-Modell 97 werden die für die Durchführung einer Aktivität erforderlichen Eingangsprodukte explizit festgelegt, beispielsweise mittels des Produktflusses. Eine vergleichbare Einschränkung existiert im V-Modell XT nicht. Vorgehensbausteine und die darin enthaltenen Produkte und Aktivitäten machen auch bewusst keinerlei Vorgaben und Einschränkungen bezüglich einer möglichen Reihenfolge der Durchführung von Aktivitäten oder der Erstellung von Produkten. Der inhaltliche und zeitliche Ablauf eines Projektes ist in der Regel komplex. Um eine zuverlässige Planung und Steuerung des Projektes zu ermöglichen, muss ein geordneter Projektablauf entwickelt werden. Hierfür stellt das V-Modell dem Anwender einen Katalog mit so genannten Projektdurchführungsstrategien zur Verfügung. Eine Projektdurchführungsstrategie definiert einen grundlegenden Rahmen für die geordnete und nachvollziehbare Durchführung eines Projektes. Jede Projektdurchführungsstrategie gibt eine Reihenfolge von im Projekt zu erreichenden Projektfortschrittsstufen vor. Das Erreichen einer Projektfortschrittsstufe wird im V-Modell durch einen Entscheidungspunkt markiert. Für jeden 6

12 Entscheidungspunkt ist im V-Modell eine Menge von Produkten definiert, die am Ende der Projektfortschrittsstufe fertig gestellt sein müssen. Auf der Basis dieser Produkte entscheidet das projektübergeordnete Management, ob die Projektfortschrittsstufe erreicht wurde und ob der nächste Projektabschnitt freigegeben wird Gesamtstruktur und sichtenbasierte Darstellung des V-Modells Nachfolgende Abbildung 2 illustriert die Gesamtstruktur des V-Modells. Abb. 2: Gesamtstruktur und sichtenbasierte Darstellung des V-Modells Projekttypen legen die einzusetzenden Vorgehensbausteine sowie die Projektdurchführungsstrategie fest. Der passende Projekttyp wird aus Projektmerkmalen insbesondere aus Projektrolle und Projektgegenstand abgeleitet. Die Sichten von Auftraggeberseite und Auftragnehmerseite werden im V- Modell XT getrennt. Das V-Modell XT unterstützt wesentlich stärker als bisher die Auftraggebersicht. Das V-Modell 97 legte sich hier nicht fest, sondern überließ die Festlegungen dem planenden Projektleiter. Die Projektdurchführungsstrategien legen die möglichen Durchführungsreihenfolgen der Entscheidungspunkte fest. Die Inhalte des V-Modells sind in den modularen, aufeinander aufbauenden Vorgehensbausteinen enthalten. 7

13 Abb. 3: Vorgehensbaustein-Landkarte 8

14 Ergänzt werden die V-Modell-Inhalte durch Konventionsabbildungen. Eine Konventionsabbildung beinhaltet eine Abbildung von einem Standard, einer Norm oder einer Vorschrift auf die Inhalte des V-Modells. So sind beispielsweise die Konventionsabbildungen für den CMMI und die ISO-Norm zum Systemlebenszyklus im V-Modell enthalten. Im Laufe eines Projektes müssen sich unterschiedliche Personen und Personengruppen mit diesen V-Modell-Inhalten befassen. So steht beispielsweise für den Projektleiter zu Beginn des Projektes das Tailoring im Vordergrund. Später, während des Projektablaufs, sind für ihn und das Projektteam das Vorgehen und die anstehenden Aufgaben wichtig. Für die Qualitätssicherung sind hingegen die vom V-Modell gestellten Anforderungen an zu überprüfende Produkte essenziell. Diese unterschiedlichen V-Modell-Anwendergruppen haben verschiedene Sichten auf das V-Modell. Eine V-Modell-Referenz stellt eine bestimmte Sicht auf das V-Modell dar. Sie dient den unterschiedlichen Projektmitwirkenden als Einstieg, Arbeitsgrundlage und Nachschlagewerk. Die in Abbildung 2 dargestellten V-Modell-Referenzen stellen die Inhalte des V-Modells angepasst auf die spezifischen Bedürfnisse der unterschiedlichen Anwendergruppen dar. Jede V-Modell-Referenz ist somit ein eigenes Nachschlagewerk mit einer speziellen Sicht auf das V-Modell. So ist beispielsweise die V-Modell-Referenz Tailoring auf die Erstellung eines projektspezifischen V-Modells zugeschnitten. Weitere V-Modell-Referenzen existieren für Produkte, Aktivitäten und Rollen Trennung zwischen der Auftraggeber- und der Auftragnehmersicht Für Auftraggeber und Auftragnehmer bietet das V-Modell vorbereitete Vorgehensbausteine an und zeigt klar die Schnittstellen in der Zusammenarbeit für beide Seiten auf. Beide Seiten planen ihr Projekt mit den für sie selbst relevanten Vorgehensbausteinen. Beide V-Modell-Projekte wirken dann über die definierten Schnittstellen-Prozesse zusammen. 9

15 Abb. 4: Zusammenwirken zwischen den Projekten auf Auftraggeber- und Auftragnehmer-Seite 10

16 2.6. Ziel- und ergebnisorientierte Vorgehensweise des V-Modells Ein wesentliches Merkmal des V-Modells ist die ziel- und ergebnisorientierte Vorgehensweise. Diese Grundphilosophie ist an vielen Stellen im V-Modell sichtbar: Projektdurchführungsstrategien und Entscheidungspunkte geben die Reihenfolge der Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor. Die detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt. Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person. Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten. Die im V-Modell definierten Produkte sind somit die zentralen Zwischen- und Endergebnisse des Projektes. Ausgehend von den Projektzielen werden diese Ergebnisse bei der Projektkonzeption und -planung definiert und im Zuge einer professionellen Vorgehensweise während des Projektverlaufs bearbeitet und fertig gestellt. Die Ziel- und Ergebnisorientierung des V-Modells vermeidet unnötige, nicht an Ergebnissen ausgerichtete Tätigkeiten. Aktivitäten und Teilaktivitäten, die keinen Beitrag zur Ergebniserstellung liefern, werden im V-Modell nicht beschrieben. Diese Fokussierung des V-Modells stellt eine wesentliche Steigerung einer effizienten Projektabwicklung dar Leichtes und schnelles Tailoring, integrierte Projektplanung Das V-Modell XT bietet durch die beschriebenen Änderungen in Aufbau und Struktur eine ganzheitliche Sicht auf die Systementwicklung und löst den Widerspruch zwischen Mächtigkeit und Einfachheit beim Tailoring eines Projekts perfekt. Das V-Modell soll in möglichst verschiedenen Projektkonstellationen einsetzbar sein. Die erforderliche Anpassung, Tailoring genannt, ist eine der ersten und kritischsten Tätigkeiten des V-Modell-Anwenders. Im V- Modell 97 wurde auf der Ebene der Produkte und Aktivitäten getailort und 11

17 geplant. Die Konsistenz musste über vordefinierte Produktflüsse sichergestellt werden. Das neue V-Modell bietet demgegenüber ein einfach anwendbares, äußerst schnelles Tailoring sowie Klarheit von Beginn an. Im neuen V-Modell wird unter dem Tailoring die Festlegung eines Projekttyps und der damit anzuwendenden Vorgehensbausteine sowie der Projektdurchführungsstrategie verstanden. Die Auswahl der durchzuführenden Produkte und Aktivitäten erfolgt dabei über die Auswahl und Festlegung der Vorgehensbausteine. Für jeden Projekttyp ist vorgegeben, welche Vorgehensbausteine verpflichtend sind und welche optional eingesetzt werden können. Ein Tailoring auf Aktivitäts- und Produktebene ist nicht notwendig. Durch diesen einfachen, aber effektiven Tailoringmechanismus werden alle für ein Projekt nicht notwendigen Teile ausgeblendet. Die Projektleitung wird von unnötigen Details entlastet. Mit dem Tailoring werden die relevanten Vorgehensbausteine ausgeschüttet und die hierin enthaltenen Produkte, Aktivitäten und Rollen für das Projekt eingeplant. Dabei entstehen ein integrierter Projektplan sowie das Projekthandbuch. Schon nach etwa zwei Stunden Projektplanung/-tailoring kann das neue V-Modell den Weg durch das Labyrinth des weiteren Projektablaufes aufzeigen. Die Namensgebung des V-Modells XT (extreme Tailoring) beschreibt die neuen Eigenschaften beim Tailoring. Es bietet ein leicht beherrschbares, einfach anwendbares sowie schnelles Tailoring nach dem Motto: KISS (keep it stupid and simple). Einfachheit und Klarheit entsteht durch die Verwendung des neuen V-Modells! Über das initiale Tailoring und die erste Planung des Projekts hinaus ist eine Anpassung an neue Erkenntnisse oder neue Projektgegebenheiten jederzeit möglich. Ein solches dynamisches Tailoring unterliegt kaum Einschränkungen, so dass das neue V-Modell sehr flexibel die Projektrealität unterstützen kann. Neben den beschriebenen inhaltlichen Neuerungen bietet das V-Modell erstmals auch eine integrierte Softwareunterstützung, die als Open Source veröffentlicht wird. Mit Hilfe dieser Tools kann das V-Modell verstärkt auch für kleine und mittlere Projekte eingesetzt werden. Daneben werden kommerzielle Tools ihre Berechtigung für größere Projekte haben (s. Abb. 5). 12

18 Abb. 5: OpenSourceTool-gestütztes Tailoring 3. Was ändert sich für die Auftraggeber - Vorteile/Nachteile? 3.1. Änderungen für Auftragnehmer Neben der inhaltlichen Erweiterung, den neuen Mechanismen und Konzepten ändert sich für die Auftragnehmerseite die Projektplanung und -durchführung vor allem durch die Nutzung der Vorgehensbausteine und Produkte, die die Auftraggeber-Auftragnehmer-Schnittstelle definieren, beispielsweise: Vorgehensbaustein Angebotserstellung und Vertragserfüllung (Auftragnehmer) Produkte aus dem Vorgehensbaustein Projektmanagement Definierte Lieferungs- und Abnahmeprozesse. 13

19 Abb. 6: Vorgehensbaustein-Landkarte für Auftragnehmer Nach dem V-Modell 97 sollte die Planung und das Tailoring für das gesamte Projekt eigentlich vom Auftraggeber zu leisten sein bzw. wäre während oder 14

20 nach der Ausschreibung durch den Auftragnehmer anzupassen. Nach dem V- Modell XT wird jede Seite das eigene Projekt planen und der Auftraggeber einige Vorgaben an den Auftragnehmer definieren. Wesentlich interessanter noch als diese Änderungen dürften für die Auftragnehmer Änderungen auf der Auftraggeberseite sein, da diese erhebliche Auswirkungen auch auf der Auftragnehmerseite haben. So dürfen sich Auftragnehmer zukünftig verstärkt auf vollständige und umfassend beschriebene Anforderungen verlassen. Ausschreibungen, die auf 1-2 Seiten unscharfe Projektziele und -ergebnisse vorgeben und die Leistungen nicht beschreiben, dürfte es nicht mehr geben. Eine Planung und Kalkulation auf derart unsicherem Fundament ist nicht mehr nötig. Zum Einen entfallen damit oder sinken zumindest die bisher häufig einkalkulierten Risikozuschläge, zum Anderen entfallen unkalkulierbare Risiken für den Auftragnehmer. Das Erkennen fehlender oder allzu unscharfer Anforderungen dürfte zukünftig zu Vertragsänderungen und entsprechenden zusätzlichen Umsätzen führen wobei diese offen ausgewiesen werden und nicht mehr in Risikozuschlägen versteckt sind. Beide Seiten werden zukünftig also eine sicherere Kalkulationsbasis haben wobei diese Aussage für den Auftraggeber nur dann gilt, wenn er hinsichtlich der Festlegung seiner Anforderungen seine Hausaufgaben gemacht hat Änderungen für Auftraggeber Die Neuerungen des V-Modells betreffen neben der Anforderungsfestlegung vor allem die Vorgehensbausteine und Produkte, die die Auftraggeber- Auftragnehmer-Schnittstelle definieren: Anforderungsfestlegung Auftragsvergabe, Projektbegleitung und Abnahme (AG) Produkte der Vorgehensbausteine Projektmanagement und Qualitätssicherung. 15

21 Abb. 7: Vorgehensbaustein-Landkarte für Auftraggeber Vorteile für den Auftraggeber sind insbesondere: Trennung der Sichten Auftraggeber und Auftragnehmer und damit mehr Klarheit in der Projektplanung und -abwicklung 16

22 Der Auftraggeber hat weniger Planungsaufwand bei der Planung des Gesamtprojekts, da er lediglich seine eigenen Aufgaben und die Prozesse an der Schnittstelle in der Zusammenarbeit für beide Seiten vorausplant sowie für den Auftragnehmer Vorgaben definiert. Der Auftragnehmer wickelt sein Projekt ebenfalls nach V-Modell ab und führt die Planung und das Tailoring für sein Projekt selbst durch Durch die Trennung dieser Sichten und die separate Planung und Steuerung entstehen für den Auftraggeber niedrigere Kosten und ein geringerer Steuerungsaufwand im Vergleich zur Anwendung des bisherigen V- Modells Das V-Modell definiert damit ein neues Verhältnis zwischen Auftraggeber und Auftragnehmer und klare Regeln für die Zusammenarbeit, die auf bewährten Managementmethoden und -praktiken aufbauen. V-Modell-Projekte beginnen zukünftig nach einer initialen Projektplanung und -vorbereitung mit einer umfassenden Erhebung, Analyse und Beschreibung der Anforderungen. Die Anforderungen werden vom Auftraggeber festgelegt und sind damit Basis für die spätere Ausschreibung. Ausschreibung und Vergabe werden für private wie öffentliche Auftraggeber durch das neue V-Modell XT umfassend unterstützt. Im Bereich Projektplanung und Tailoring wird der Auftraggeber deutlich entlastet, da nur noch Aspekte geplant und getailort werden müssen, die ihn als Auftraggeber wirklich betreffen. So hat er hier mehr Zeit für die wesentlichen Dinge, z. B. die gewünschten Projektziele und -ergebnisse genauer zu definieren oder Alternativen zu vergleichen, wie: Soll erst ein Prototyp in einem Vorprojekt entwickelt werden? Soll zunächst nur die Erstellung des Pflichtenheftes als Auftrag vergeben werden, was meist den Vorteil einer höheren Sicherheit für den Auftraggeber hat, aber Zeit kostet? Soll die Realisierung vom Pflichtenheft getrennt von einem anderen Anbieter durchgeführt werden oder optional durch den Anbieter, der auch das Pflichtenheft erstellt hat und sich somit in die Materie bereits eingearbeitet hat? Soll das System intern betrieben werden oder soll der Betrieb outgesourct werden? Sollen die Betriebsprozesse im Projekt vollständig vorgeplant und ITILkonform abgebildet werden? 17

23 Soll das System web-basiert sein oder auf Client-Server-Technologien aufsetzen? Konkretere Erhebung und Festlegung von Anforderungen Für die Auftraggeberseite existieren zwei Vorgehensbausteine, die die typischen Aktivitäten eines Auftraggebers unterstützen: Anforderungsfestlegung Auftragsvergabe, Projektbegleitung und Abnahme (Auftraggeber). Durch diese Neuerung soll eine neue Qualität der Anforderungen in IT- Projekten und damit neue Qualität des Lastenheftes erreicht werden. Das Lastenheft soll alle identifizierten Anforderungen enthalten. Es ist Grundlage für Ausschreibung, Angebotserstellung und Vertragsgestaltung. Daher werden sich für den Auftraggeber die Aktivitäten in Vorbereitung eines Projektes verstärkt auf den Bereich der Anforderungsfestlegung richten. Sollte dies nicht oder in nicht ausreichendem Maße geschehen, ist im weiteren Projektablauf mit entsprechenden Zusatzkosten und Vertragsänderungen zu rechnen. Bei der Festlegung der Anforderungen sind beispielsweise zu erheben und zu definieren: Ausgangssituation und Zielsetzung (wesentliche Eckdaten des Projekts) sowie die organisatorische und technische Prozessunterstützung und die Prozesseinbettung (Geschäftsprozessanalyse), zeitliche Entwicklungshorizonte (wo soll bzw. kann das System in zehn Jahren stehen?) Altsystemanalyse, inkl. Schnittstellen- und Abhängigkeitsanalyse funktionale Anforderungen sogenannte nicht-funktionale Anforderungen (z. B. Qualitätsanforderungen und Randbedingungen) Risikoakzeptanz / Systemsicherheit Skizze des Systemlebenszyklus und der Gesamtsystemarchitektur Lieferumfang Abnahmekriterien. Diejenigen Auftraggeber, die bereits in der Vergangenheit so umfassend und vorbildlich ihre Anforderungen analysiert haben, brauchen sich wegen des neuen V-Modells XT nicht zu sorgen. Alle anderen Auftraggeber bräuchten dies eigentlich auch nicht, denn das V-Modell unterstützt diese Erhebungen sehr gut. Über den hierzu entstehenden Aufwand sowie das benötigte Know- 18

24 How sollten sie sich allerdings im Klaren sein und dieses Know-How rechtzeitig aufbauen Unterstützung von Ausschreibung und Vergabe Im Vorgehensbaustein Auftragsvergabe, Projektbegleitung und Abnahme (AG) wird die Auftraggeberseite der Auftraggeber-Auftragnehmer- Schnittstelle definiert. Das V-Modell bietet sowohl eine Unterstützung für private Auftraggeber, die hohe Freiheitsgrade in der Wahl ihres Lieferanten haben, als auch für öffentliche Auftraggeber, die durch das öffentliche Vergaberecht gebunden sind. Das V-Modell unterstützt mit vielen Hinweisen und Verweisen auf die entsprechenden Vergaberegeln eine korrekte, rechtssichere Ausschreibung und Vergabe. Im Projekthandbuch wird beim Tailoring oder auch später nach einer Make- Or-Buy-Entscheidung festgelegt, ob Aufträge vergeben werden. In diesem Fall wird der Vorgehensbaustein Auftragsvergabe, Projektbegleitung und Abnahme (AG) in das projektspezifische Vorgehen aufgenommen. Zu diesem Vorgehensbaustein gehören die Produkte: Ausschreibungskonzept Im Ausschreibungskonzept wird eine konkrete Vergabeart, zum Beispiel eine öffentliche Ausschreibung, ausgewählt und die Begründung für die Auswahl dokumentiert. Ausschreibung Auf der Grundlage der Anforderungen (Lastenheft) wird eine Ausschreibung erstellt und gemäß Ausschreibungskonzept veröffentlicht oder an geeignete Bieter verschickt. Kriterienkatalog für die Angebotsbewertung Geeignete Bewertungskriterien und die Bewertungsmethode, z. B. die Nutzwertanalyse, werden ausgewählt und dokumentiert. Angebot (vom AN) Angebotsbewertung Die Bewertung der Angebote und die Zuschlagsentscheidung erfolgen auf der Basis des Produkts Kriterienkatalog für die Angebotsbewertung und werden in dem Produkt Angebotsbewertung festgehalten. Bei dieser Entscheidung wird ein konkretes Angebot ausgewählt. Vertrag Bei öffentlichen Auftraggebern wird häufig kein separater Vertrag geschlossen, sondern dieser entsteht durch Ausschreibung und Angebot, die 19

25 zusammen den Vertrag bilden. Hierzu gehört auch die Vereinbarung der Gültigkeit von allgemeinen Vertragsbedingungen oder den BVB bzw. EVB-IT, die bei Ausschreibungen öffentlicher Auftraggeber angewendet werden. Vertragszusatz Das V-Modell sieht keine Änderungen des ursprünglichen Vertrags vor. Dies wird über Vertragszusätze geregelt. Lieferung (vom AN) Lieferungen werden explizit geprüft und die Prüfergebnisse dokumentiert. Abnahmeerklärung Auf Basis der Prüfergebnisse kann der Auftraggeber die Abnahme erklären oder aufgrund festgestellter Mängel die Lieferung an den Auftragnehmer zur Nachbesserung zurückweisen. Ggf. ist nach erfolgter Nachbesserung die Lieferung erneut zu prüfen und die Abnahme zu erklären. 4. Qualitätssicherung mit dem neuen V-Modell Das neue V-Modell enthält einen Vorgehensbaustein QS, in dem die Kernprozesse zur Planung und Durchführung qualitätssichernder Maßnahmen definiert sind. Die Test- und Prüfaktivitäten werden nicht mehr in einem monolithischen Submodell bzw. Vorgehensbaustein QS gehalten sondern sind in den jeweiligen Vorgehensbausteinen der Systemerstellung, SW-/HW- Entwicklung über Produktabhängigkeiten zum zu prüfenden Produkt definiert. Sind keine entsprechenden Entwicklungsaktivitäten und Produkte eingeplant, so entfallen auch die über definierte Produktabhängigkeiten zugehörigen Prüfaktivitäten. Die Planung und Durchführung der QS-Aktivitäten wird durch die definierten Produktabhängigkeiten und die integrierte Betrachtung innerhalb der Systemerstellungsbausteine im Vergleich zum alten V-Modell 97 deutlich erleichtert. Selbstverständlich kennt auch das V-Modell XT das Grundkonzept der Bearbeitungszustände (in Bearbeitung, vorgelegt, fertiggestellt). Neu eingeführt wird darüber hinaus das Konzept der Konsistenzzustände, durch das immer die Konsistenz der definierten Produktabhängigkeiten sichergestellt werden soll. Neu ist ebenfalls, dass im V-Modell Abnahmeprozesse und erforderliche Prüfungen explizit definiert werden. Insbesondere über die Qualität der im Lastenheft eingeforderten und der darüber hinausgehend im Pflichtenheft definierten Abnahmekriterien wird sich die gewünschte Qualität der Projekter- 20

26 gebnisse realisieren lassen. Auftraggeber, die in den frühen Projektphasen den so wichtigen Aspekten Festlegung von Anforderungen und Definition von Abnahmekriterien nicht genügend Aufmerksamkeit schenken, werden bei Abnahmeprozessen so manches Aha-Erlebnis erfahren. 5. Anpassung, Einführung und Verbesserung eines organisationsweiten Vorgehensmodells Um ein auf V-Modell XT basierendes Vorgehensmodell einzuführen oder ein bereits bestehendes Vorgehensmodell zu verbessern, sind im V-Modell XT ein spezieller Projekttyp, der Vorgehensbaustein Einführung und Pflege eines organisationsspezifischen Vorgehensmodells sowie hierzu gehörige Produkte und Aktivitäten vorgesehen (s. Abb. 8). Die Konzepte und das Vorgehen bauen auf Prozessbewertungen, z. B. nach CMMI und SPICE auf. Die Prozessverbesserungen leiten sich aus den Ergebnissen der Prozessbewertung ab und münden in ein Verbesserungskonzept für das Vorgehensmodell. Da mit dem V-Modell ein Software-Tool ausgeliefert wird, in dem das V-Modell selbst systematisiert hinterlegt ist, kann mit diesem Tool auch eine Überarbeitung, Änderung und Ergänzung des Vorgehensmodells erfolgen. Die Referenzen, die ja nur unterschiedliche Sichten auf die dahinter liegenden, strukturierten Daten darstellen, können mit Hilfe dieses Werkzeuges erzeugt werden. Auf dieser Basis wird während der Umsetzungsphase die V-Modell-Anpassung, die Pilotierung und die Breiteneinführung durchgeführt. 21

27 Abb. 8: Vorgehensbaustein-Landkarte zur Einführung und Verbesserung eines V-Modells 22

28 6. Ausblick Die neue Version XT des V-Modells erneuert die gesamte Struktur und verbessert damit die Anwendbarkeit massiv. Gleichzeitig wird auch Bewährtes vom V-Modell 97 übernommen. Mit dem neuen V-Modell ist ein großer Wurf gelungen und es wird mit Sicherheit eine größere Akzeptanz und eine höhere Marktdurchdringung erzielen. Es wird ein großer Durchbruch, denn diese Best Practices stehen jedermann kostenlos zur Verfügung und können problemlos an eigene Bedürfnisse angepasst werden. Ob Auftraggeber, Projektleiter, Entwickler oder Qualitätsmanager im V- Modell dieser kompakten Sammlung von Best Practices findet jeder eine Antwort. Und das Beste keine Paperware ist entstanden, sondern eine sofort einsetzbare Projektmanagementumgebung unterstützt durch Open Source Tools. 23