Kurs:Wirtschaftsinformatik SS09/SE1/Lernskript/V-Modell

Aus Wikiversity

Ziele beim V-Modell[Bearbeiten]

  • Minimization of Project Risks:

Das V-Modell verbessert die Transparenz eines Projektes. Die Projektkontrolle wird durch standartisierte Ansätze geleitet, die dabei gefundenden Ergebnisse und Verantwortlichen werden beschrieben. Frühe Erkennung von Planabweichungen und Risiken helfen beim guten Projektmanagement, was am Ende sich in fallenden Projektrisiken bezahlt macht.

  • Improvement and Guarantee of Quality: As a standardized process model, the V-Model ensures that the results to be provided are complete and have the desired quality. Defined interim results can be checked at an early stage. Uniform product contents will improve readability, understandability and verifiability.

Das standartisierte Prozeßmodell ist ein Rahmen für die Vollständigkeit und die Qualitätsbeurteilung von Software. Definierte Resultate können frühzeitig überprüft werden in den ersten Phasen. Standartisierte Inhalte machen Produktinhalte lesbar, verständlich und verifizierbar.

  • Reduction of Total Cost over the Entire Project and System Life Cycle:

Die Mühe für die Entwicklung, Produktion, Betrieb und Wartung eines Systems kann vorkalkuliert werden. Die Schätzung und die Kontrolle wird ermöglicht durch standartisierte Verfahren. Die Resultate dieser Verfahren sind uniform und leicht zurückverfolgbar, dadurch wird der Software-Einkäufer unabhängiger vom Lieferanten.

  • Improvement of Communication between all Stakeholders:

Die Standartisierung der Beschreibung ist die Basis für gegenseitiges Verständnis zwischen den Anspruchsgruppen. Die Reibungsverluste zwischen den Usern, Käufern/Auftraggebern, Lieferanten und Entwicklern werden weniger, so dass die gelingende Kommunikation im Projektverlauf realistischer wird.

Allgmeine Charakterisierung[Bearbeiten]

Das V-Modell XT ist ein Lebenszyklus- bzw. Vorgehensmodell, das besonders in großen Softwareentwicklungsprojekten dazu eingesetzt wird, um eine hohe Produktqualität bei gleichzeitiger Einhaltung der Budget- und Zeitvorgaben zu gewährleisten.

Die Transparenz und die Planbarkeit von Softwareentwicklungsprojekten. Die Qualität des V-Modells XT, dem Nachfolger des V-Modells 97, wurde auch dadurch bestätigt.

Die Industrie bekundet ihr Interesse an diesem Modell. Es lohnt sich deswegen sich anzusehen, was das V-Modell eigentlich ist.

Bei dem V-Modell XT wird zwischen dem dokumentenzentrierten und den modellbasierten Entwicklungsansatz unterschieden.

Dokumentenzentrierter Ansatz[Bearbeiten]

Der dokumentenzentrierte Ansatz konzentriert sich beispielsweise durch konkrete Qualitätsmaßstäbe auf die Struktur und die Inhalte der Dokumente inklusive deren Abhängigkeiten. Der Vorteile dieses Ansatzes ist insbesondere die Transparenz. Diese Transparenz ist sogar auf projektübergreifender Ebene gegeben, was insbesondere auf die einheitliche Namensgebung und Dokumentenablagestruktur zurückzuführen ist. Durch ein zentral zugängliches Repository werden eine vollständige Dokumentenablage und ein nachvollziehbares Versionsmanagement realisiert. Die Projektdurchführung wird vereinfacht.

Allerdings hat dieser Ansatz nicht nur Vorteile: Es bedarf eines nicht zu vernachlässigenden Aufwandes, die Konsistenz innerhalb all der generierten Dokumente zu waren. Dies gilt auch, weil viele Dokumente im Projektverlauf oder auch im Zuge von Folgeprojekten und Wartungsarbeiten verändert werden müssen, was oft die Konsistenz beeinträchtigt. Bevor man sich also auf dokumentenzentrierten Ansatz als Projektgrundlage einlässt, muss man sich die Frage stellen, ob der nötige Aufwand einen Mehrwert generiert.

Modellbasierter Ansatz[Bearbeiten]

Genau an dieser Stelle setzt der modellbasierten Entwicklungsansatz an, nämlich bei Konsistenzerhaltung trotz langlebiger und ständig weiterentwickelter Software.

Bei diesem Ansatz werden sämtliche wichtigen Informationen also zum Beispiel die Anforderungen und die Architektur zu einem integrierten Modell verarbeitet, wobei auch Beschreibungsstandards wie UML Verwendung finden können. Somit kann der Konsistenz leichter Rechnung getragen werden, weil wichtige Informationen nicht über viele Dokumente verteilt sind, sondern in eben diesem integrierten Modell konzentriert sind. Darüber hinaus gibt es spezielle Werkzeuge (CASE- Tools), die die Projektverantwortlichen bei der Konsistenzwahrung aber auch bei anderen projektspezifischen Aufgaben unterstützen. Fernerhin können spezielle Transformatoren automatisiert aus dem V-Modell XT ein anderes Modell konstruieren oder auch bestimmte Dokumente und einige Codeelemente generieren. Die sorgt für Zeiteinsparungen.

Zu den Nachteilen des modellbasierten Ansatzes zählt hingegen der nötige Mehraufwand, um eine vollständige Projektdokumentation zu erhalten, sodass das Erhalten eines Gesamtüberblickes erschwert wird. Auch die weiteren Nachteile hängen mit diesen Werkzeugen zusammen: Werden mehrere inhomogene Werkzeuge eingesetzt, lassen sich die Zusammenhänge zwischen den unterschiedlichen Modellen nur schwer erkennen. Auch ändert sich die Spezifikationsmethodik je nach Werkzeug. Um an bestimmte Informationen zu gelangen, muss man in der Praxis häufig mit mehreren Werkzeugen arbeiten, was die genannten Nachteile umso schwerwiegender macht. Deswegen ist es nicht verwunderlich, wenn man bei diesen Werkzeugen und deren Herstellern ansetzt, wenn man die Vorteile des dokumentenzentrierten und des modellbasierten Entwicklungsansatzes bei gleichzeitiger Umgehung der Nachteile vereinen will. Zu diesem Zweck wurden die Entwickler dieser Werkzeuge bei der Entwicklung des V-Modells XT integriert. Dies sorgte auch dafür, dass diese Werkzeuge von nun an zum V-Modell XT kompatible Dokumente erzeugen. Selbst den Zusatzaufwand zum Aufbau einer geeigneten Infrastruktur können die neuen Tools den Zuständigen abnehmen.

Die Vereinigung beider Ansätze ermöglicht folglich modellbasiert zu entwickeln und gleichzeitig die standardisierten Dokumentationen nutzen zu können.

Beschreibung der 4 Submodelle[Bearbeiten]

Prozess in vier Tätigkeitsbereiche untergliedert:

  • Systemerstellung: Produkt entwickeln
  • Projektmanagement: Projekt planen und kontrollieren, Voraussetzungen und Software

Entwicklungs-Umgebung bereitstellen

  • Qualitätssicherung: QS-Anforderungen vorgeben, Produkte prüfen
  • Konfigurationsmanagement: Produktstruktur planen, Produkte und Rechte verwalten

Grundlegende Aspekte:[Bearbeiten]

  • Probleme, die es zu vermeiden gilt: zu viele, nutzlose Dokumente, Fehlen wichtiger Doku-

mente

  • Lösung Tailoring: stellt sicher, dass der betriebene Aufwand dem Nutzen entspricht, Reduk-

tion des generischen V-Modells auf die Elemente, die zur Durchführung des Projektes benö- tigt werden, Resultat: spezifisches V-Modell


SEU = Software-Entwicklungs-Umgebung[Bearbeiten]

Zusammenwirken der vier Submodelle:[Bearbeiten]

Funktionsübersicht Submodell SE (dies ist nicht das V – Modell):[Bearbeiten]