V Modell Xt Projekthandbuch Beispiel Essay

4 Teil 5: V-Modell-Referenz Produkte

4.3 Produkte

4.3.1 Planung und Steuerung

4.3.1.3 Projekthandbuch

Sinn und Zweck

Das V-Modell ist ein generischer Vorgehensstandard, der für ein konkretes Projekt angepasst und konkretisiert werden muss. Das Projekthandbuch legt die für Management und Entwicklung notwendigen Anpassungen und Ausgestaltungen fest. Somit dokumentiert es Art und Umfang der Anwendung des V-Modells im Projekt und ist Informationsquelle und Richtlinie für alle Projektbeteiligten.

Das Projekthandbuch beinhaltet eine Kurzbeschreibung des Projekts, die Beschreibung des Tailoring-Ergebnisses, den grundlegenden Projektdurchführungsplan, die notwendige und vereinbarte Unterstützung des Auftraggebers sowie Organisation und Vorgaben für die Planung und Durchführung des Projekts und die anstehenden Entwicklungsaufgaben. Der Projektleiter muss dieses zentrale Produkt in Abstimmung mit den Schlüsselpersonen des Projekts erarbeiten.

Dabei werden im Projekthandbuch auch insbesondere Häufigkeit und Notwendigkeit der Erzeugung weiterführender Produkte, die für die Planung und Durchführung des Projekts, für das Ausschreibungs- und Vertragswesen sowie für die Prozessverbesserung notwendig sind, festgelegt, zum Beispiel Projektstatusberichte, Risikolisten, Verträge und Bewertungen von Vorgehensmodellen.

Wann ist das Produkt entscheidungsrelevant?

Wer ist beteiligt?

Womit kann das Produkt erstellt werden?

Welche Vorlagen sind verfügbar?

Vorlagen

Produktvorlage wird generiert.

Projektorganigramm (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.1-1_Projektorganigramm_detailliert_v1.0.ppt

Kommunikationsplanung (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.3-2_Kommunikationsplan_v1.0.ppt

Projekthandbuch (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.3-6_Projekthandbuch_v1.0.doc

Beistellungsliste (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_7.1-2_Beistellungsliste_v1.0.xls

Änderungsverfahren (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_7.2-1_Aenderungsverfahren.ppt

Beispielprodukte

InfoMaPa:Projekthandbuch

WiBe:Projekthandbuch

ToSA:Projekthandbuch

Wie erstellt man das Produkt?

Aktivität

Projekthandbuch erstellen

Mit dem Projekthandbuch werden die organisatorischen Rahmenbedingungen für alle Projektbeteiligten festgelegt. Insbesondere neuen Teammitgliedern dient das Projekthandbuch als Einstiegspunkt und Informationsquelle. Wichtiger Bestandteil des Projekthandbuchs ist die Festlegung der Art und Weise, in der das V-Modell im Projekt zur Anwendung kommt.

Die Erstellung des Projekthandbuches ist Teil der Projektinitialisierung. Ändern sich jedoch im Projektverlauf die Rahmenbedingungen des Projektes, dann muss das Projekthandbuch fortgeschrieben werden.

Bei der Erstellung ist zunächst das Anwendungsprofil festzulegen und auszuwerten. Projektspezifische Anpassungen sind vorzunehmen, um auf diese Weise eine geeignete Projektdurchführungsstrategie zu ermitteln. Daraufhin ist die Projektdurchführung zu planen und mit allen Projektbeteiligten abzustimmen. Dieses Vorgehen kann solange wiederholt werden, bis die Abstimmung erfolgt ist. Erst dann erfolgt der Kick-Off des Projekts.

Folgende Teilschritte sind dabei enthalten:

  • Anwendungsprofil erstellen und auswerten
  • Projekthandbuch mit allen Projektbeteiligten abstimmen
  • Projektdurchführung planen
  • Projekt-Kick-Off vorbereiten und durchführen
  • Projektspezifische Anpassung durchführen
  • Projektspezifische Anpassung zur Projektlaufzeit durchführen

Welche Abhängigkeiten hat das Produkt?

4.3.1.3.1 Projektüberblick, Projektziele und Erfolgsfaktoren

Das Projekthandbuch ist eine unverzichtbare Informationsquelle und Richtlinie für alle Projektbeteiligten. In diesem Thema wird kurz, prägnant und möglichst plastisch das gemeinsame Projektleitbild dargestellt.

4.3.1.3.2 Teilprojekte

Auf der Basis einer Skizze des Lebenszyklus und der Gesamtsystemarchitektur, den Funktionale Anforderungen und den Nicht-Funktionale Anforderungen des Gesamtprojektes werden die Teilprojekte festgelegt. Die Festlegung der Teilprojekte enthält die Anzahl der Teilprojekte, eine Kurzbeschreibung der Teilprojekte, die wichtigsten Teilprojekt-Entscheidungspunkte, die Zuordnung der funktionalen und nicht-funktionalen Anforderungen zu den Teilprojekten und die Abdeckung der Elemente der Gesamtsystemarchitektur durch die Teilprojekte.

Dabei wird auch ein Teilprojekt Integration festgelegt, das die Ergebnisse aller anderen Teilprojekte zum Gesamtprojekt integriert.

Das Teilprojekt Integration beschreibt die Reihenfolge der zu integrierenden Teilprojekte, die besonderen Verfahren oder Methoden zur Integration der Teilprojektergebnisse, die Termine, Aufwände, Verantwortliche und Ressourcen.

4.3.1.3.3 Projektspezifisches V-Modell

Das V-Modell ist ein generisches Vorgehensmodell. Die projektspezifische Anpassung - das so genannte Tailoring - wird in diesem Thema dokumentiert. Das dabei zu erstellende Anwendungsprofil, der resultierende Projekttyp, die zu verwendenden und zusätzlich ausgewählten Vorgehensbausteine sowie die ausgewählten Projektdurchführungsstrategien sind dabei festzuhalten. Im Rahmen dieses Themas können auch die Umstände und Konsequenzen von bereits vorhersehbarem, dynamischem Tailoring festgehalten werden. Alle diese Festlegungen sind entsprechend den Vorgaben des V-Modells zu begründen (siehe dazu auch Abschnitt Projektspezifische Anpassung - Tailoring im Teil 1: Grundlagen des V-Modells).

4.3.1.3.4 Abweichungen vom V-Modell

Sämtliche Abweichungen von den Vorgaben des V-Modells, wie Streichungen einzelner Produkte, Aktivitäten und Abweichung vom Tailoring-Verfahren, müssen unter Angabe von Gründen dokumentiert werden. Die Änderungen sind in diesem Thema aufzuführen.

4.3.1.3.5 Projektdurchführungsplan

Das V-Modell macht durch die Festlegung von Entscheidungspunkten Vorgaben zur groben Strukturierung des Projekts. Dieses Thema enthält die planerische Ausgestaltung dieser Entscheidungspunkte in Form eines Projektdurchführungsplans. Hierbei sind zumindest der Projektanfang, das Projektende und alle wichtigen Entscheidungspunkte während des Projekts einzuplanen.

Darüber hinaus können noch weitere projektspezifische Meilensteine festgelegt werden, soweit diese für alle Projektbeteiligten relevant sind. Meilensteine, die nur projektintern relevant sind, werden im Projektplan dokumentiert.

4.3.1.3.6 Organisation und Vorgaben zum Projektmanagement

In diesem Thema werden die Vorgaben des V-Modells zum Projektmanagement angepasst und konkretisiert. Es werden alle internen und externen Projektbeteiligten aufgeführt. Die verantwortlichen Ansprechpartner sind dabei namentlich zu benennen. Darüber hinaus werden die Schlüsselrollen des V-Modells, wie Projektleiter, QS-Verantwortlicher und Systemarchitekt, mit Personen besetzt und deren Aufgaben und Verantwortlichkeiten entsprechend den V-Modell-Vorgaben ausgestaltet.

Die grundlegende Organisation und Durchführung der Zusammenarbeit zwischen allen Projektbeteiligten wird definiert. Dabei werden beispielsweise Besprechungen, das Vorgehen für Abstimmungsrunden, das Konfliktmanagement, die Eskalationsstrategie, die Bedingungen für die Durchführung eines formalen Entscheidungsprozesses festgelegt und dokumentiert. Zusätzlich werden Schwellenwerte definiert, deren Überschreitung zur Einleitung von Steuerungsmaßnahmen führt. Ein Beispiel dafür ist die Überschreitung von Sollwerten für die Planung um mehr als 15%. Organisationsweite Vorgaben müssen dabei berücksichtigt werden.

Für die im Rahmen des Projektmanagements zu erstellenden V-Modell-Produkte, wie Projektplan, Aufgabenliste und Projekttagebuch, wird festgelegt, ob und wann diese zu erstellen sind, nach welchen Methoden, Richtlinien und Standards diese Produkte auszuarbeiten sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie bearbeitet werden (siehe dazu auch Abschnitt Erzeugende Produktabhängigkeiten).

Projektorganigramm

Das Projektorganigramm verbildlicht die aufbauorganisatorische Projektstruktur, beispielsweise die Untergliederung eines Projekts in Teilprojekte bzw. die Zusammensetzung des Projekts aus einzelnen Teams. Dabei sollte auch die Auftraggeber/Auftragnehmer-Konstellation beachtet werden. Außerdem sollte das Projektorganigramm die Beziehungen der Führungs- und Managementrollen (beispielsweise Lenkungsausschuss, Projekteigner, Projektleiter, Projektmanagementbüro) aufzeigen.

In großen Projekten enthält es die Aufteilung des Gesamtprojekts in Verantwortungsbereiche und Teilprojekte (einschließlich Aufgabenabgrenzung zwischen den Teilprojekten) und dokumentiert, wer für welche Teile verantwortlich ist. Ggf. kann für einzelne Rollen auch deren konkrete Besetzung im Projektorganigramm dargestellt werden.

Die im Projektorganigramm dokumentierte Struktur ist unabhängig von den Aufbauorganisationen der beteiligten Behörden oder Unternehmen. Die Aufteilung auf Verantwortungsbereiche und Teilprojekte orientiert sich an Projektinhalten, die in der Definition des Projektumfangs und letztendlich im Projektstrukturplan beschrieben sind und ist Basis für den Ressourcen- und Organisationsplan . Das Projektorganigramm bleibt im Projektverlauf meist relativ stabil, kann aber jederzeit an aktuelle Entwicklungen angepasst werden.

Rollenbeschreibungen

Die Rollenbeschreibungen machen deutlich, welche Projektrolle welche Aufgaben wahrnimmt, welche Kompetenzen ihr zugeordnet sind und welche Verantwortung sie im Projektkontext hat. Die Rollenbeschreibungen stellen sicher, dass alle benötigten Aufgaben wahrgenommen werden und keine Aufgaben doppelt oder mit unklarer Verantwortung vergeben werden. Entspricht das Rollenmodell des Projekts dem Rollenmodell im V-Modell, so reichen hier meist Verweise auf die V-Modell-Dokumentation. Weicht das Rollenmodell im Projekt vom V-Modell-Rollenmodell ab, so sollte zumindest versucht werden, eine entsprechende Zuordnung zu finden.

Projektmitarbeiter und Rollenbesetzung

Im Projekthandbuch werden alle Projektmitarbeiter nebst ihrer Kontaktdaten aufgelistet. Außerdem wird für jeden Mitarbeiter festgelegt, welche Rollen er im Projekt einnimmt oder einnehmen kann und in welchen Teilprojekten oder Teams er eingesetzt wird.

4.3.1.3.7 Organisation und Vorgaben zum Risikomanagement

Damit die Einschätzungen der Risiken innerhalb des Projekts nach denselben Maßstäben erfolgen, wird das im V-Modell bereits vorgesehene Risikomanagement in diesem Thema ausgestaltet und konkretisiert. Dabei ist die generelle Entscheidung zu treffen, ob neben Risiken auch Chancen betrachtet werden sollen. Für Chancen wird das gleiche Verfahren wie für Risiken angewendet, deshalb wird im Folgenden nicht mehr zwischen den Begriffen Chance und Risiko unterschieden.

Hier erfolgt die Festlegung, wann und nach welchen Kriterien Risiken in einer Risikoliste dokumentiert werden. Zusätzlich muss definiert werden, mit welchen Methoden, Richtlinien und Standards und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur das Risikomanagement durchzuführen ist.

Dabei sind im Einzelnen die folgenden Punkte festzulegen:

  • Risikoklassen zur Einstufung von Risiken
  • Kriterien zur Risikoakzeptanz
  • Eskalationsstufen basierend auf den definierten Risikoklassen, entsprechend den Vorgaben des Themas Organisation und Vorgaben zum Projektmanagement
  • Verfahren für die Dokumentation der identifizierten Risiken und der geplanten Maßnahmen
  • Zeitpunkte und Vorgehen bei der Risikoidentifizierung
  • Zeitpunkte für die Neubewertung von Risiken
  • Zeitpunkte und Verfahren für die Planung und Durchführung von Gegenmaßnahmen
4.3.1.3.8 Organisation und Vorgaben zum Problem- und Änderungsmanagement

In diesem Thema wird das im V-Modell bereits vorgesehene Problem- und Änderungsmanagement ausgestaltet und konkretisiert. Es erfolgt die Festlegung, ob, wann und welche Problemmeldungen und Änderungsanträge erstellt werden müssen, nach welchen Methoden, Richtlinien und Standards diese zu bearbeiten sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie weiterverarbeitet werden.

Dies beinhaltet beispielsweise die Definition der vorgesehenen Status von Problemmeldungen und Änderungsanträgen (erstellt, genehmigt und abgelehnt) die Besetzung der Änderungssteuerungsgruppe (Change Control Board) sowie das Konfliktmanagement und die Eskalationsstrategie. Dabei kann es erforderlich sein, mehrere Änderungsverantwortliche und Änderungssteuerungsgruppen (Change Control Boards) mit unterschiedlicher Entscheidungskompetenz und Zusammensetzung einzurichten.

Bei unterschiedlichen Auffassungen in einer Änderungssteuerungsgruppe (Change Control Board) werden Eskalationsstufen definiert. Beispielsweise kann eine mit größerer Entscheidungskompetenz ausgestattete Änderungssteuerungsgruppe (Change Control Board) oder ein Lenkungsausschuss als Eskalationsinstanz festgelegt werden.

4.3.1.3.9 Organisation und Vorgaben zum Konfigurationsmanagement

In diesem Thema wird das im V-Modell bereits vorgesehene Konfigurationsmanagement ausgestaltet und konkretisiert. Es erfolgt die Festlegung, welche Produktexemplare wann nach welchen Methoden, Richtlinien und Standards vom Konfigurationsmanagement zu verwalten sind, sowie wann und in welchen Abständen Produktkonfigurationen und Releases zu erstellen sind. Zu Anzahl und Umfang der Produktkonfigurationen sind mindestens die Vorgaben zum Konfigurationsmanagement einzuhalten.

Alle Produkte, die im Rahmen eines V-Modell Projektes erstellt werden, werden entsprechend den Vorgaben im Projekthandbuch in die Produktbibliothek eingestellt und verwaltet. Hierzu muss festgelegt werden, welche Dateiablagestruktur und Namenskonventionen in der Produktbibliothek einzuhalten sind, wie die Produkte im Konfigurationsmanagement eindeutig zu bezeichnen sind, wie die Fortschreibung von Versionen und Releases erfolgt und welche Produktzustände ein Produktexemplar aus Sicht des Konfigurationsmanagements durchläuft. Die Produktzustände müssen mindestens die im Kapitel Qualitätssicherung und Produktzustandsmodell definierten Zustände umfassen.

Neben der Verwaltung der Produktbibliothek ist im Rahmen dieses Themas ein Konzept zur Datensicherung und Archivierung der Exemplare in der Produktbibliothek zu erstellen. Es werden die Verantwortlichkeiten, Termine und Verfahren zur Datensicherung festgelegt, sowie Konzepte zur Archivierung und Aufbewahrung der Daten über längere Zeiträume erstellt.

Das Konfigurationsmanagement liefert zudem einen Beitrag zum Projektstatusbericht, welcher zur Fortschrittskontrolle der Produktexemplare und Produktkonfigurationen dient. Es ist festzulegen, wann, in welcher Form und an welche Personen eine KM-Auswertung zu übergeben ist.

Ferner wird in diesem Kapitel beschrieben, wie Eintragungen in das Änderungs- und Prüfverzeichnis von Produkten vorzunehmen sind, d.h. z.B. Häufigkeit von Einträgen und welche Einträge bei der Bearbeitung vorgenommen werden und unter welchen Bedingungen.

4.3.1.3.10 Organisation und Vorgaben zum Projektcontrolling

In diesem Thema wird das im V-Modell bereits vorgesehene Vorgehen zum Projektcontrolling ausgestaltet und konkretisiert. Hierfür werden die Projektziele, die durch Projektkennzahlen verfolgt werden sollen, die Kennzahlen selbst und die dazugehörigen Messdatentypen zusammengestellt. Die Projektkennzahlen werden dabei den Projektzielen zugeordnet. Damit ist eine quantitative oder qualitative Verfolgung dieser Ziele möglich.

Abschließend erfolgt die Festlegung, ob, wann, welche und durch wen Messdaten zu erfassen und Kennzahlenauswertungen zu erstellen sind. Zusätzlich muss definiert werden, mit welchen Methoden, Richtlinien und Standards und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur dabei vorgegangen werden soll. Dabei ist insbesondere die projektspezifische Ablagestruktur der Messdaten festzulegen.

4.3.1.3.11 Organisation und Vorgaben zum Anforderungsmanagement

Dieses Thema beschreibt die im Rahmen des Anforderungsmanagements anzuwendenden Verfahren. Dies beinhaltet Festlegungen zu folgenden Bereichen zu treffen:

  • Ermittlung von Anforderungen
  • Dokumentation von Anforderungen
  • Identifikation von Anforderungen
  • Stakeholder

Insbesondere sind auch die Verantwortlichen für die Produkte (insb. das Produkt Anforderungen (Lastenheft)) der Anforderungserhebung zu benennen, sowohl für die Durchführung im Projekt als auch für die Betriebsphase. Zu berücksichtigen sind bei den Festlegungen auch, ob und welche Werkzeuge für die Anforderungserhebung zu verwenden sind, wie die Statuskontrolle der Anforderungen erfolgen soll und welche Metriken dafür zu verwenden sind. Eine angemessene Regelung dafür ist insbesondere für die Erstellung des Produkts Anforderungsbewertung erforderlich, dessen Erstellung ebenfalls hier zu regeln ist. Abschließend ist hier zu dokumentieren, wie die Anforderungserhebung in das Berichtswesen eingebunden werden soll.

Es lassen sich drei Arten von Anforderungen unterscheiden:

  • Funktionale Anforderungen definieren die jeweilige Funktion, die von einem System zur Verfügung gestellt werden muss und vom Benutzer erwartet wird.
  • Nicht-Funktionale Anforderungen definieren die Qualitätsmerkmale für ein System und seine Funktionalität, zu denen in der Regel auch Anforderungen aus dem Bereich des IT-Betriebs zählen.
  • Randbedingungen leiten sich aus Rahmenbedingungen (z.B. organisatorische und technische Vorgaben) ab. Sie sind in der Regel projektextern und schränken die Art und Weise der Systemrealisierung ein bzw. geben konkrete Vorgaben für diese.

Für jede dieser Anforderungsarten sind hier Festlegungen zu den oben aufgeführten Punkten zu treffen. Darüber hinaus ist auch die frühzeitige Einbindung des Betriebs zu regeln, um die spätere Inbetriebnahme des Systems zu erleichtern.

Ermittlung von Anforderungen

Eine Anforderung im Allgemeinen stellt eine Bedingung oder Fähigkeit dar, die von einem Benutzer zur Problemlösung oder Zielerreichung benötigt wird und die ein (Teil-)System erfüllen oder besitzen muss, um bestimmte Vorgaben (z.B. Normen, Spezifikationen) zu erfüllen. Außerdem ist die Anforderung die Dokumentation dieser Bedingung bzw. Fähigkeit.

Zur Ermittlung von Anforderungen können verschiedene Techniken zum Einsatz kommen, wie z.B.:

  • Kreativitätstechniken (z.B. Brainstorming, Mind-Mapping etc.) für die Sammlung erster Ideen
  • Beobachtungstechniken (z.B. Feldbeobachtung) zur Ableitung von Details für die Anforderungen abzuleiten und für das Erkennen impliziter Anforderungen
  • Befragungstechniken (z.B. Fragebogen, Interview) zur Erfragung von Anforderungen in beliebigem Detaillierungsgrad
  • Vergangenheitsorientierte Techniken (z.B. Analyse bestehender Lösungen) zur Wiederverwendung der bei früheren Systementwicklungen bereits gemachten Erfahrungen und zur Überprüfung, ob tatsächlich alle Anforderungen ermittelt wurden

Der Einsatz der Techniken, die für die Anforderungsfestlegung verwendet werden ist hier zu dokumentieren.

Dokumentation von Anforderungen

Funktionale Anforderungen können sowohl natürlichsprachlich als auch modellbasiert erfasst werden. Nicht-Funktionale Anforderungen werden dabei ausschließlich in Textform dokumentiert. Anforderungen sollen stets so beschrieben sein, dass ihre Erfüllung prüfbar und entscheidbar ist. Bei einer textuellen Beschreibung ist daher auf hinreichende Präzision zu achten. Bei der modellbasierten Dokumentation von Anforderungen sind insbesondere die Perspektiven zu berücksichtigen, die zur Dokumentation verwendet werden, da sie einen Einfluss auf die Art der Interpretation der Anforderungen haben. Folgende Perspektiven sind dabei üblich:

  • Strukturperspektive: Mit ihr lassen sich z.B. Abhängigkeitsbeziehungen im Systemkontext abbilden. Hierfür können z.B. UML-Klassendiagramme oder Entity-Relationship-Diagramme verwendet werden.
  • Funktionsperspektive: Sie ist die Darstellungsform zur Erläuterung der Informations- / Datenflüsse. D.h., welche Informationen / Daten bekommt das System als Input, wie verarbeitet das System diese und welche Informationen / Daten liefert das System als Output. Hierfür können z.B. UML-Aktivitätsdiagramme oder Datenflussdiagramme verwendet werden.
  • Verhaltensperspektive: Mit ihr lässt sich beschreiben, wie ein System auf Ereignisse reagiert und was die Bedingungen für einen Zustandswechsel des Systems sind. Hierfür können z.B. UML-Zustandsdiagramme oder Statecharts verwendet werden.

Die Festlegungen, wie in einem Projekt Anforderung erfasst werden, welche technischen und methodischen Hilfsmittel für die Dokumentation Verwendung finden ist hier zu dokumentieren.

Identifikation von Anforderungen

Anforderungen müssen eindeutig identifizierbar sein, um eine verlässliche Anforderungsverfolgung zu ermöglichen. In diesem Thema sind daher die Festlegungen zu dokumentieren, wie die Identifikation, z.B. durch Nummerierung, im Projekt erfolgen soll.

Stakeholder

In diesem Thema sind alle an der Anforderungserhebung beteiligten Personen (Stakeholder) zu benennen. Dies umfasst nicht nur den Anforderungsanalytiker (AG) sondern auch weitere Personen, wie z.B. Anwendervertreter, die ein Interesse am IT-System haben. Insbesondere die Ansprechpartner des IT-Betriebs (z.B. die Rolle IT-Service-Design-Verantwortlicher) ist hier einzubinden.

4.3.1.3.12 Organisation und Vorgaben zur Systemerstellung

In diesem Thema wird das im V-Modell bereits vorgesehene Vorgehen zur Systemerstellung ausgestaltet und konkretisiert. Es erfolgt die Festlegung, wann und welche Produkte für die Systemerstellung zu verwenden sind, nach welchen Methoden, Richtlinien und Standards diese zu erstellen sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie zu bearbeiten sind.

Dies beinhaltet zumindest die Festlegung der anzuwendenden Entwicklungsmethoden, Entwicklungsumgebung, Technologien sowie Konfliktmanagement und Eskalationsstrategie.

4.3.1.3.13 Abstimmung mit IT-Organisation und Betrieb

Soll ein beauftragtes/erstelltes System nach dem Projektende in den Betrieb überführt werden, ist der IT-Betrieb frühzeitig in das Projekt einzubeziehen. Ist eine Übergabe in den Betrieb geplant, müssen hier die für das Projekt relevanten Regelungen zur Erstellung des Produkts Betriebliche Freigabeerklärung getroffen werden. Das Thema beschreibt ebenfalls, wie die IT-Organisation und der IT-Betrieb, insbesondere die Rollen IT-Service-Design-Verantwortlicher, IT-Service-Transition-Verantwortlicher und IT-Service-Operation-Verantwortlicher ins Projekt eingebunden werden.

Darüber hinaus beschriebt das Thema die grundlegende Konstellation nach Projektende und insbesondere zwischen welchen Parteien eine Leistungsvereinbarung (SLA/OLA/UC) zu schließen ist. Die konkreten Inhalte finden sich dann in den einzelnen Leistungsvereinbarungen.

Sind weiterhin die Vorgehensbausteine IT-Sicherheit und Datenschutz für das Projekt relevant, so enthält das Thema außerdem die projektinternen Regelungen zur IT-Sicherheit und zum Datenschutz, sowie die Abstimmung mit der umgebenden IT-Organisation. Dies umfasst im Detail die Regelungen, wer, wann wie den Beitrag zum IT-Sicherheitskonzept und den Beitrag zum Datenschutzkonzept erstellt und wie die Abstimmung mit den Rollen Informationssicherheitsverantwortlicher und Datenschutzverantwortlicher erfolgt.

4.3.1.3.14 Vorgaben für das Projekthandbuch der Auftragnehmer

In diesem Thema kann der Auftraggeber die unterschiedlichsten Vorgaben für die Planung und Durchführung des Projektes beim Auftragnehmer festlegen. Sie werden hier dokumentiert und dann in alle Ausschreibungen übernommen und gegebenenfalls angepasst. Die Vorgaben können beispielsweise den zu verwendenden Entwicklungsprozess, das Tailoring, die zu verwendende Infrastruktur und das Vorgehen bzgl. der Sicherheit umfassen.

4.3.1.3.15 Berichtswesen und Kommunikationswege

In den vorhergehenden Themen wurden die Organisation und Vorgaben für die unterschiedlichen Aufgaben der Planung und Durchführung von Projekten festgelegt. In diesem Thema wird ein Überblick über das dabei festgelegte Berichtswesen und die Kommunikationswege dargestellt. Dies beinhaltet beispielsweise die getroffenen Festlegungen, wer wann welche Informationen in welcher Form an wen zu liefern hat.

Das Thema beschreibt sowohl die projektinterne als auch die projektexterne Kommunikation. Die Ziele des Kommunikationsmanagements werden dabei in der Zielgruppenübersicht definiert, die Umsetzung wird im Kommunikationsplan beschrieben.

Zielgruppenübersicht

Die Zielgruppenübersicht beschreibt, welche Personen und Personenkreise welche Informationen über das Projekt erhalten müssen, sollen oder möchten. Kommunikationszielgruppen sind oft deckungsgleich mit Projektstakeholdern, und umfassen beispielsweise die Projektmitarbeiter, Lenkungsausschuss, Leitung, Anwender, aber auch Öffentlichkeit oder Medien. Ziel des Kommunikationsmanagements ist es, das Informationsbedürfnis der einzelnen Zielgruppen durch geeignete Maßnahmen zu bedienen.

Kommunikationsplan

Der Kommunikationsplan beschreibt, wie die in der Zielgruppenübersicht definierten Informationsbedürfnisse der Kommunikationszielgruppen befriedigt werden sollen. Er legt fest, welche Information (z.B. Projektfortschritt), wann (z.B. jeweils zum Monatsende) in welcher Form und über welches Medium (z.B. schriftlicher Projektstatusbericht via E-Mail) an welche Kommunikationszielgruppe (z.B. Lenkungsausschuss und Leitung) kommuniziert wird und wer dafür verantwortlich ist (z.B. Projektleiter). Auch die projektinterne Kommunikation wird hier geplant und organisiert, beispielsweise dass alle Besprechungen protokolliert werden und an wen das Protokoll im Anschluss verteilt wird.


Vorgehensmodelle zum Softwareentwicklungsprozess empfehlen Richtlinien für Rollen (Verantwortlichkeiten), Phasen, Aufgaben, Aktivitäten, Methoden und Dokumente (Artefakte, Arbeitsergebnisse).



Inhalt

  1. Vorbemerkungen
  2. Sechs Qualitätsmerkmale für Softwareprodukte nach ISO 9126 (DIN 66272)
  3. Softwarearchitekturrelevante Aufgaben bei XP, Scrum, RUP und beim V-Modell
  4. Wasserfallmodell
  5. Scrum
  6. XP
  7. RUP
  8. V-Modell [XT]
  9. OEP
  10. Links auf weiterführende Informationen



Vorbemerkungen

Nach Untersuchungen von Standish Group, Gartner Group, Cutter Consortium und Center for Project Management sind im Durchschnitt:

  • ca. 23 % aller Softwareprojekte erfolgreich,
  • ca. 53 % aller Softwareprojekte über Budget und/oder über Zeit und
  • ca. 24 % aller Softwareprojekte abgebrochen.

Softwareentwicklung ist in besonderem Maße geprägt von Fehleinschätzungen. Sehr häufig wird der Zeitbedarf zu kurz geschätzt, sowohl für die Projektorganisation als auch für den Kommunikationsbedarf und die Programmierdauer. Im Endergebnis produziert ein Programmierer im längerfristigen Durchschnitt:

Kaum ein Programmierer wird dies glauben, da kurzfristig natürlich wesentlich mehr Codezeilen erstellt werden, aber wenn Sie nach einem halben Jahr Projektlaufzeit den effektiven Produktivcode zusammenzählen, werden Sie ähnliche Zahlen bestätigt finden. Dies gilt zumindest für Team-geeigneten, dokumentierten, zuverlässigen, test- und wartbaren Code. Für technische Code Reviews werden übrigens 1200 Codezeilen pro Tag angesetzt.

Auf Grund des erhöhten Organisations- und Kommunikationsbedarfs lässt sich die Projektdauer nicht einfach durch weitere Mitarbeiter verkürzen. Nach Brooks, Rausch-Schott und Retschitzegger gilt folgende Näherungsformel für die optimale Teamgröße:

  • OptimaleMitarbeiterZahl = Wurzel aus ( ProjektdauerInPersonenMonaten )

Wenn also ein Projekt auf 16 Personenmonate geschätzt wird, wäre die optimale Teamgröße 4 Personen. Dies beinhaltet allerdings lediglich einen Vorschlag für die optimale Gruppengröße. Die sich ergebende Projektlaufzeit ist auf Grund des Kommunikationsbedarfs länger als 'ProjektdauerInPersonenMonaten' geteilt durch die 'MitarbeiterZahl'!

Die Meinungen zur optimalen Vorgehensweise in Softwareentwicklungsprojekten sind sehr konträr. Einige häufig wiederzufindende Praktiken bzw. Forderungen sind:

  • Klare schriftlich fixierte "Vision" des Projektziels
  • Erwarte das Unerwartete: von vornherein Änderungen der Anforderungen einplanen
  • Design und Architektur möglichst einfach, gut strukturiert und änderbar
  • Intensive kontinuierliche Kundeneinbindung
  • Iterativ-inkrementelle Entwicklung mit möglichst kurzen Zyklen, aber inklusive häufigen Integrationstests (möglichst automatisiert)
  • Frühe Prototypen
  • Frühes und häufiges Testen, eventuell sogar zuerst Testfälle und dann Entwicklung
  • Nicht zuviel, aber auch nicht zuwenig Dokumentation


Sechs Qualitätsmerkmale für Softwareprodukte nach ISO 9126 (DIN 66272)

  • Functionality / Funktionalität:
    Korrektheit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit
  • Reliability / Zuverlässigkeit:
    Reife, Fehlertoleranz, Wiederherstellbarkeit
  • Usability / Benutzbarkeit:
    Verständlichkeit, Bedienbarkeit, Erlernbarkeit, Robustheit
  • Efficiency / Effizienz:
    Wirtschaftlichkeit, Zeitverhalten, Verbrauchsverhalten
  • Maintainability / Wartungsfreundlichkeit:
    Analysierbarkeit, Änderbarkeit, Stabilität, Testbarkeit
  • Portability / Übertragbarkeit:
    Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit


Softwarearchitekturrelevante Aufgaben bei XP, Scrum, RUP und beim V-Modell

Die folgende Tabelle vergleicht in stark vereinfachender Weise XP, Scrum, RUP und das V-Modell aus Sicht des Softwarearchitekten:


 XPScrumRUPV-Modell
Fokus des ModellsEntwicklungsprozessEntwicklungsprozessProjektprozessUnternehmensprozess
Wichtige RollenKunde, SoftwareentwicklerProduct Owner, ScrumMaster, TeamSoftwarearchitektSystemdesigner, Softwareentwickler,
technischer Autor
Machbarkeit,
Risiko
Alle BeteiligteProduct Owner (zus. mit Team)ArchitektPM (Projektmanagement)
Priorisierung,
Iterationsplanung
"Stories" zus. mit Kunde vor jeder IterationProduct Owner (zus. mit Team)ArchitektSystemdesigner, Projektleiter
ArchitekturkonzeptEntwickler,
aber nur gerade benötigte Architektur
Team (zus. mit Product Owner)ArchitektEntwickler
TestplanungEntwicklerTeamwenig Unterstützung
durch Architekt
QS (Qualitätssicherung)
ÄnderungenEntwicklerProduct OwnerArchitektKM (Konfigurationsmanagement)
Statusberichte,
Dokumentation
Alle Beteiligte,
aber möglichst wenig Dokumentation
Product Owner, ScrumMasterArchitektMehrere Rollen
Bewertungleichtgewichtige Methodologie,
wenig Dokumentation/Overhead,
agil, iterativ,
Architektur wird von allen definiert,
geringer Einführungsaufwand,
aber funktioniert nur mit homogenem Team
leichtgewichtige Methodologie,
wenig Overhead,
agil, iterativ,
Sprint-Timeboxing,
geringer Einführungsaufwand
schwergewichtige Methodologie,
formalisierter strukturierter Prozess,
Use-Case-getrieben, iterativ,
architekturzentriert,
Rolle des Architekten klar definiert,
hoher Einführungsaufwand
sehr formalisiert und dokumentenzentriert,
Architektenaufgaben auf mehrere Rollen verteilt,
hoher Einführungsaufwand

Solche und ähnliche Vergleiche werden gerne angestellt, obwohl es eigentlich nicht ganz korrekt ist, die Modelle in dieser Form zu vergleichen, da der Fokus auf unterschiedlichen aufeinander aufbauenden Prozessebenen liegt. Zum Beispiel kann das Projektprozessmodell RUP um ein Plug-in für das Entwicklungsprozessmodell XP erweitert werden. Auch dX von Robert Martin zeigt, wie XP mit RUP aussehen kann ("dX" ist ironischerweise ein auf den Kopf gestelltes "XP").

Weiteres zu Softwarearchitekturen und den Aufgaben des Softwarearchitekten finden Sie unter Softwarearchitekt.



Wasserfallmodell

Das klassische Wasserfallmodell erlaubt Iterationen nur zwischen zwei aufeinanderfolgenden Phasen und durchläuft relativ starr sequentiell folgende Phasen:


Zielerforschung, Anforderungen<-┐ | | └->Analyse, Lastenheft, Auftrag<-┐ | | └->Pflichtenheft, Design <-┐ | | └->Implementierung <-┐ | | └->Test, Verifikation<-┐ | | └->Abnahme, Betrieb, Wartung

Scrum

Eine Zusammenfassung zu Scrum finden Sie unter scrum.htm.



XP

XP (Extreme Programming) beschreibt eine agile iterative Vorgehensweise beim Softwareentwicklungsprozess mit leichtgewichtiger Methodologie und wenig Dokumentation und Overhead.

Schwerpunkte sind:

  • User Stories: Die Anforderungen an die zu erstellende Software werden nicht wie beim RUP in Use Cases, sondern in User Stories erfasst. User Stories beschreiben GUIs, Funktionalitäten und Testszenarien.
  • On-site Customer: Ein kompetenter Vertreter des Kunden ist während der gesamten Entwicklungszeit bei den Entwicklern anwesend (dürfte nur selten realisierbar sein).
  • Pair Programming: An den Entwicklungsrechnern sitzen jeweils zwei Entwickler und entwickeln gemeinsam.
  • Testing: Vor der Entwicklung eines Moduls werden automatisierbare Testfälle (Unit Tests) programmiert.
  • Simple Design: Es werden keine unnötigen Features implementiert.
  • Small Releases: Es werden häufige Iterationen durchgeführt mit lauffähigen Programmen als Ergebnis, welche der Kunde begutachtet.
  • Refactoring: Der Sourcecode wird eher früh restrukturiert (falls erforderlich).
  • Continuous Integration: Von verschiedenen Teammitgliedern produzierter Code wird sehr häufig zusammengeführt.
  • Collective Ownership: Der entwickelte Sourcecode gehört dem gesamten Team, jeder ist für jeden Code verantwortlich. Die Teams rotieren zyklisch.
  • Coding Standards: Es werden Konventionen zum Aufbau des Codes erstellt, um Lesbarkeit zu erleichtern.

Weiteres siehe http://www.extremeprogramming.org und http://www.xprogramming.com.



RUP

RUP (Rational Unified Process) ist eine Vorgehensweise beim Softwareentwicklungsprozess mit eher schwergewichtiger Methodologie, vielen formalen Definitionen und Dokumenten, iterativ, architekturzentriert, Use-Case-getrieben, wohldefiniert und sehr strukturiert.

RUP teilt das Projekt in vier Phasen:

  • Inception Phase (Projektsetup, Konzeptualisierung)
  • Elaboration Phase (Ausarbeitung, Entwurf)
  • Construction Phase (Implementierung)
  • Transition Phase (Übertragung, Inbetriebnahme)

RUP definiert Workflows für neun Kernaufgaben (Disciplines):

  • Business Modeling (Geschäftsprozessmodellierung)
  • Requirements (Anforderungsanalyse)
  • Analysis & Design (Analyse & Design)
  • Implementation (Implementierung)
  • Test
  • Deployment (Softwareverteilung)
  • Configuration & Change Management (Konfigurations- und Änderungsmanagement)
  • Project Management (Projektmanagement)
  • Environment (Umgebung)

Innerhalb der Phasen gibt es inkrementelle Iterationen über die Workflows, die teilweise ähnlich dem Wasserfallmodell abgearbeitet werden. Zu jedem Zeitpunkt bietet RUP Planungshilfen, Leitlinien, Checklisten und Best Practices.

Die konsequente und komplette Nutzung von RUP macht erst bei Teams mit über 10 Personen Sinn. Es sind über 30 Rollen für über 130 Aktivitäten vorgesehen und es werden über 100 verschiedene Artefakttypen (Arbeitsergebnistypen) vorgeschlagen, die erzeugt, dokumentiert und verwaltet werden müssen.

Allerdings kann RUP sehr weitgehend reduziert und angepasst werden ("Tailoring"). Es gibt sogar ein RUP-Plug-in für das XP-Vorgehensmodell.

Zu den zu erstellenden Artefakten gehören unter anderem folgende Dokumenttypen:

  • Vision (grober Überblick ohne Details): Stakeholder (Beteiligte, Benutzer), Problemdefinition, Produkteigenschaften, grobe Anforderungen, Risiken, Glossar
  • Requirements Management Plan: Business Cases (Geschäftsprozesse), Use Cases (Anwendungsfälle, Verhalten des Produkts), Priorisierung der Use Cases, Dokumentation der Anforderungen
  • SRS, Software Requirements Specification (Pflichtenheft): Anforderungen, Use Cases, Priorisierungen
  • SDP, Software Development Plan (Projektplan): Organisation, Ressourcen, Aktivitäten, Monitoring, Meilensteine, Risikomanagement
  • SAD, Software Architecture Document: Überblick zur Architektur des Systems
  • Design Model: Komponenten, Schnittstellen, wichtige Klassen, Datenmodell
  • Implementation Model: Packaging, Integration, Deployment
  • CM, Configuration Management: Konfiguration, Versionskontrolle, Change Requests (CR)
  • Test Model: Akzeptanzkriterien, Testfälle, Ausführung
  • Deployment Plan: Umgebung, Hardware, Softwarekomponenten, Dokumentation, Wartung, Schulung

Weiteres siehe http://www.ibm.com/software/awdtools/rup.



V-Modell [XT]

V-Modell ist ein Vorgehensmodell zum Softwareentwicklungsprozess, also eine Richtschnur für die Organisation und Durchführung von IT-Vorhaben. Das "V-Modell 97", auch EstdIT (Entwicklungsstandard für IT-Systeme des Bundes) genannt, bzw. der Nachfolger "V-Modell XT" ist bei vielen zivilen und militärischen Vorhaben des Bundes verbindlich vorgeschrieben. Es ist ein wenig mit dem Wasserfallmodell vergleichbar, aber frühe Phasen werden mit späten über Testdaten verbunden (V-förmig, siehe Abbildung). Es ist auch iterativ anwendbar und kann mit OOAD und UML eingesetzt werden. Phasen und zeitliche Abläufe stehen nicht im Vordergrund. Es ist sehr stark formalisiert und dokumentenzentriert und muss vor der Anwendung angepasst werden ("Tailoring").

Zum "V-Modell 97" sind in drei Bänden drei Standardisierungsebenen beschrieben:

  • Vorgehensmodell:
    beschreibt durchzuführende Aktivitäten (Tätigkeiten) und zu erstellende Produkte (Ergebnisse)
  • Methodenzuordnung:
    legt fest, mit welchen Methoden die Aktivitäten des Vorgehensmodells durchzuführen und welche Darstellungsmittel in den Ergebnissen zu verwenden sind
  • Werkzeuganforderungen:
    legen fest, welche funktionalen Eigenschaften die Software-Tools aufweisen müssen

Das V-Modell ist in vier Submodelle gegliedert:

  • PM: Projektmanagement
  • QS: Qualitätssicherung
  • SE: Softwareentwicklung/Systemerstellung
  • KM: Konfigurationsmanagement

Seit 2005 gibt es mit "V-Modell XT" (eXtreme Tailoring) einen Nachfolger des "V-Modells 97". Es ist organisationsneutral, flexibel nach dem Baukastenprinzip anpassbar und wird durch Dokumentvorlagen wie beispielsweise Plan- oder Angebotsbausteine unterstützt. Es unterliegt keiner Einschränkung durch Nutzungsrechte und kann lizenzfrei beliebig adaptiert und eingesetzt werden.

Das V-Modell XT sieht sowohl "Auftraggeber-Projekte" als auch "Auftragnehmer-Projekte" vor. Der Auftraggeber ist normalerweise für die Definition der Anforderungen im "Lastenheft", für die "Ausschreibung" und für die "Prüfspezifikation Lieferung" für die Abnahme verantwortlich. Die Rolle des Auftraggebers kann bei internen Projekten natürlich auch durch die Fachabteilung besetzt werden. Der Auftragnehmer führt die Systemerstellung durch, begleitet durch weitere Dokumente.

Das nach dem Tailoring entstandene projektspezifische V-Modell enthält "Vorgehensbausteine" (z.B. SW-Entwicklung) mit "Produkttypen" (z.B. SW-Architektur), "Aktivitätstypen" (z.B. SW-Architektur erstellen) und "Rollen" (z.B. SW-Architekt). In der "Projektdurchführungsstrategie" (z.B. inkrementelle Systementwicklung) werden Meilensteine, Entscheidungspunkte und der zeitliche Ablauf vorgegeben, die Ausführung wird in "Projektfortschrittsentscheidungen" dokumentiert.

Das V-Modell XT erwartet als Minimum folgende Ergebnisprodukte:

  • Projekthandbuch:
    Vom Projektleiter erstellte Kurzbeschreibung des Projekts, Beschreibung des Tailoring-Ergebnisses, grundlegender Projektdurchführungsplan, vereinbarte Unterstützung des Auftraggebers, Organisation und Vorgaben für die Planung und Durchführung des Projekts und die anstehenden Entwicklungsaufgaben sowie Vorgaben für Projektstatusberichte, Risikolisten und Verträge
  • Projektplan:
    Vom Projektleiter erstellte Basis für die Kontrolle und Steuerung des Projektes, beschreibt die gewählte Vorgehensweise des Projekts und legt detailliert fest, was wann und von wem zu tun ist
  • QS-Handbuch:
    Vom QS-Verantwortlichen erstellte Kurzbeschreibung der Qualitätsziele im Projekt, Festlegung der zu prüfenden Produkte und Prozesse, Organisation und Vorgaben für die Planung und Durchführung der Qualitätssicherung sowie Vorgaben für externe Zulieferer
  • Produktbibliothek:
    Alle zu erstellenden Produkte (auch Dokumentationen)

Insbesondere für Softwareentwicklung interessant sind:

  • Gesamtsystemspezifikation (Pflichtenheft):
    Die im Lastenheft definierten Kundenanforderungen werden im Pflichtenheft vom Anforderungsanalytiker präzisiert und durch weitere funktionale und nicht-funktionale Anforderungen ergänzt. Die Grobarchitektur des Systems wird beschrieben, zu entwickelnde Unterstützungssysteme werden identifiziert und eine Schnittstellenübersicht erstellt. Lieferumfang, Abnahme- und Akzeptanzkriterien werden festgelegt.
  • Systemspezifikation:
    Konkrete Beschreibung der Schnittstellen und der funktionalen und nicht-funktionalen Anforderungen an einzelne Systemelemente (System, Unterstützungssystem oder Segment) durch den Systemarchitekt.
  • Systemarchitektur:
    Der Systemarchitekt führt eine Zerlegung (Dekomposition) des Systems in Segmente, HW-, SW- und externe Einheiten durch, identifiziert Beziehungen und Schnittstellen zwischen den Elementen und zur Umgebung, legt querschnittliche Systemeigenschaften wie Sicherheitskonzept, Transaktionskonzept oder Loggingkonzept fest und dokumentiert Entwurfsentscheidungen.
  • Prüfspezifikationen:
    Zu verschiedenen Themen werden Prüfspezifikationen erstellt, z.B. Systemelement, Integration, Lieferung.

Genauere Beschreibungen und Templates zu den genannten Dokumenten erhalten Sie unter:
http://www.v-modell-xt.de, http://www.v-modell.iabg.de und http://www.kbst.bund.de.



OEP

OEP (Object Engineering Process) ist ein von Bernd Oestereich entwickeltes auf OOAD (objektorientierte Analyse und Design), UML und UP (Unified Process) basierendes Vorgehensmodell zur objektorientierten Softwareentwicklung. OEP ist ein iterativ-inkrementeller, agiler, anwendungsfallgetriebener, architekturzentrierter Entwicklungsprozess. OEP ist zugeschnitten auf die Entwicklung betrieblicher Informationssysteme als mehrschichtige objektorientierte Client-Server-Architektur und weniger gut geeignet für die Entwicklung technischer Systeme.

Weiteres siehe http://www.oose.de/oep.

Es folgt eine vereinfachte Kurzübersicht zu den von Oestereich für die objektorientierte Analyse (OOA) vorgeschlagenen Schritten (anders als hier dargestellt teilweise iterativ; ausführliche Beschreibung siehe Buch: Oestereich, Objektorientierte Softwareentwicklung, 2001, 3486255738):

  1. Systemidee und Zielsetzung entwickeln:
    Was soll erreicht werden, Ideen, Visionen, Absichtsbekundungen und Wünsche. Freitext, ca. halbe Seite.
  2. Anforderungsbeitragende (Stakeholder) identifizieren:
    Auftraggeber, Gesetzgeber, Projektbetroffene, Systembetroffene, Anwender, Kunden, Support, Vertrieb und Projektgegner. Tabellarische Unterscheidung in: Fachexperten, Anforderungsverantwortliche und Systembetroffene/Akteure.
  3. Geschäftsprozesse identifizieren:
    Systemidee mit UML-Anwendungsfalldiagramm (Use Case Diagram, «workflow») visualisieren. Geschäftsprozesse mit jeweils einem UML-Aktivitätsdiagramm (Ablaufdiagramm mit zeitlich aufeinander folgenden Schritten) abstrakt beschreiben. Fachliche und am Geschäft beteiligte Akteure abstrakt beschreiben.
    Ein Anwendungsfall (Use Case) beschreibt eine zeitlich ununterbrochene Interaktion eines oder mehrerer Akteure mit einem System.
    Ein Geschäftsprozess kann aus mehreren Anwendungsfällen bestehen und stellt eine Zusammenfassung von fachlich zusammenhängenden Aktivitäten dar, die durchgeführt werden, um einen Geschäftsvorfall ergebnisorientiert zu bearbeiten.
    Ein Geschäftsvorfall (z.B. Antrag) entsteht durch ein Ereignis (z.B. Antragseingang) und hat fachliche Ergebnisse (z.B. Vertrag).

  4. Interessen der Anforderungsbeitragenden (Stakeholder) identifizieren:
    Beschreibung der Ziele und Interessen, Aufzählung wichtiger geforderter Systemeigenschaften und Identifizierung von Problemen und Schwachstellen, alles aus Sicht der Anforderungsbeitragenden.
  5. Geschäftsanwendungsfälle (Business Use Case) identifizieren:
    Identifizierung der Geschäftsanwendungsfälle («business») (eventuell in Form von Stories) und deren Auslöser und Ergebnisse sowie Identifizierung auszuschließender Geschäftsanwendungsfälle («business» {excluded}).
    Ein Geschäftsanwendungsfall (Geschäftsfall, Business Use Case) beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders.

  6. Anwendungsfälle essenziell beschreiben:
    Beschreibung der geschäftlichen Intentionen der Geschäftsanwendungsfälle («essential»). Definition der Auslöser, Vorbedingungen und eingehenden Informationen sowie der Ergebnisse, Nachbedingungen und ausgehenden Informationen. Entkopplung der Anwendungsfälle zu einzelnen kohärenten fachlichen Sachverhalten (eventuell mit «include» und «extend»).
  7. Systemanwendungsfälle identifizieren:
    Konkretisierung der essenziellen Anwendungsfallbeschreibungen unter Berücksichtigung konkreter Umgebungsbedingungen, Anforderungen und technischer Gegebenheiten. Eventuell Aufteilung eines essenziellen Geschäftsfalls in mehrere Systemanwendungsfälle, wenn unterschiedliche technische Systeme verwendet werden (z.B. Telefon, Fax, E-Mail, Web).
  8. Materialsammlung und -studie:
    Untersuchung von bestehenden Materialien, Gegenständen, Beispielen, Muster, Formulare, Vordrucke, Korrespondenzen und Beschreibungen.
  9. Anforderungen (Requirements) beschreiben:
    Funktionale Anforderungen (Anwendungsfälle), Benutzbarkeit (Usability), Effizienz (Performance), Zuverlässigkeit (Reliability), Änderbarkeit / Erweiterbarkeit / Wartbarkeit / Administrierbarkeit (Supportability), Gesetze, Standards und Testanforderungen. Unterscheidung in Pflichtanforderungen, optionale Anforderungen, Absichten, Vorschläge und Kommentare.
  10. Geschäftsklassen identifizieren:
    Identifizierung der fachlichen Gegenstände/Konzepte und Modellierung der strukturellen fachlichen Zusammenhänge in einem einfachen Analyse-Klassenmodell, ohne zu viele Details, aber mit Assoziationen, Assoziationsrollen und Multiplizitäten. Das Analyse-Klassenmodell soll für den Auftraggeber oder die Fachabteilung verständlich sein.
  11. Fachliches Glossar anlegen:
    Definition und Begriffskonsolidierung aller fachlichen Begriffe, aller Klassen des Analyse-Klassenmodells und aller Assoziationsrollen.
  12. Anwendungsfall-Ablaufmodell entwickeln:
    Modellierung aller Anwendungsfälle sowohl des Standardablaufs als auch des vollständigen Ablaufs inklusive aller fachlichen Ausnahmen und Varianten in UML-Aktivitätsdiagrammen. Für alle elementaren Aktivitäten Modellierung sowohl aller eingehenden als auch aller resultierenden Objekte und Daten in zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen.
  13. Systemschnittstelle beschreiben:
    Schnittstellenbeschreibungen zu allen ein- und ausgehenden Daten, Objekten und Ereignissen. Beschreibung der Dialoge, Ausgabeerzeugnisse, Daten-Schnittstellen und funktionalen Schnittstellen.
  14. Exploratives Schnittstellen-Prototyping:
    Häufig lauffähige und benutzbare Sequenzen von Dialogentwurfprototypen. Eventuell auch Auswertungen, Formulare, Simulationen oder Berechnungen.

Das objektorientierte Design (OOD) könnte folgendermaßen ablaufen:

  1. Anwendungsarchitektur definieren:
    Systemdesign bezieht sich auf bestimmte Anwendungsarchitektur, die zuerst definiert werden muss. Eine übliche Anwendungsarchitektur wäre eine komponentenbasierte Three-Tier-Architektur mit einer Präsentationsschicht auf den Clients (Dialog-Steuerung), einer Geschäftslogikschicht auf Servern (Dialog-Agent, Workflow-Steuerung, Anwendungsfallsteuerung, fachliche Komponente, externe Komponenten) und einer zentralen Datenhaltung (Datenbankserver).
  2. Fachliche Komponenten identifizieren:
    Definition eines ersten fachlichen Komponentenmodells auf Basis des Analyse-Klassenmodells, von Workflow-Komponenten («workflow») zu jedem Geschäftsprozess und von Anwendungsfallsteuerungskomponenten («use-case-control») zu jedem Anwendungsfall.
  3. Komponentenspezifische Klassenmodelle entwickeln:
    Entwicklung von lösungsorientierten komponentenspezifischen Design-Klassenmodellen für jede Komponente. Auflösung komponentenübergreifender Klassenbeziehungen und Ersetzung durch komponentengerechte Schnittstellen (Factory-, Observer-, Object-Interface).
  4. Zustandsmodelle (weiter-)entwickeln:
    Identifizierung der fachlichen Zustände, der Zustandsänderungen verursachenden Operationen, der zustandsabhängigen Operationen und der Nachfolgezustände im UML-Zustandsdiagramm. Zustandsmodellierung z.B. mit Zustandsautomat, Zusicherungen, Zustandsattributen oder Zustands-Entwurfsmuster.
  5. Komponentenabhängigkeiten identifizieren und ggf. restrukturieren:
    Überprüfung sowohl der strukturellen als auch der dynamischen Zusammenhänge und Abhängigkeiten zwischen den Komponenten mit dem Ziel der Minimierung der Kopplungen und Abhängigkeiten. Per zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen (oder alternativ per UML-Sequenz- oder -Kollaborationsdiagramm) werden separierbare Verantwortlichkeitsbereiche (swim lanes) ermittelt.
  6. Komponentenschnittstellen entwerfen:
    Aus Aktivitäten (z.B. der Anwendungsfallsteuerungskomponente und der fachlichen Komponenten) werden Schnittstellenbeschreibungen («interface») und Datentransferobjekte («structure») abgeleitet.
  7. Zusammenarbeitsmodelle entwickeln:
    UML-Sequenz- oder -Kollaborationsdiagramme für alle Anwendungsfälle sowohl für den Standardablauf als auch die wichtigsten Ablaufvarianten entwerfen. In der Regel dienen diese Diagramme nur zur Ermittlung von Erkenntnissen über die benötigten Operationen und Datentransferobjekte und werden im weiteren Verlauf nicht mehr benötigt.
  8. Ablauforientierte Komponententests entwickeln:
    Entwurf von Tests für alle Anwendungsfälle und Schnittstellen, möglichst automatisierbar (z.B. mit JUnit).
  9. Klassentests entwickeln:
    Entwurf von Tests für alle Operationen unter Berücksichtigung aller möglichen Zustände/Umgebungsbedingungen, möglichst automatisierbar (z.B. mit JUnit).
  10. Attribute definieren:
    Überprüfung aller Klassenattribute (z.B. Klassenzuordnung, eventuell eigene Klasse, Enumeration, Zusicherungen).
  11. Dialoge spezifizieren:
    Zuordnung der Dialogkontexte und Dialogkomponenten zu Aktivitäten der UML-Aktivitätsdiagramme und zu Subsystemen. Spezifizierung der Dialogkomponenten und Definition von clientseitig auszuführenden Vorabüberprüfungen.
  12. Überprüfung des Designs:
    Prinzipien der Objektorientierung, Design Patterns, Architektur, Namenskonventionen, Konsistenz, Effizienz, Erweiterbarkeit, Flexibilität, Testbarkeit, Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit, Korrektheit, Vollständigkeit, Widerspruchsfreiheit, Überprüfbarkeit, Nachvollziehbarkeit, Übersichtlichkeit, ...


Links auf weiterführende Informationen

  • Websites
  • Scrum: scrum.htm
  • Agil: http://www.agilealliance.org
  • XP: http://www.extremeprogramming.org, http://www.xprogramming.com
  • RUP: http://www.ibm.com/software/awdtools/rup, http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.html
  • V-Modell: http://www.v-modell-xt.de, http://www.v-modell.iabg.de und http://www.kbst.bund.de
  • OEP: http://www.oose.de/oep
  • Vorgehensmodelle: http://wwwai.wu-wien.ac.at/~bernroid/lehre/gzmod/ws03/e4-vorgehensmodelle.pdf, http://www3.informatik.uni-erlangen.de/Lehre/UML-Seminar/SS2002/StateOfTheArt.pdf
  • Architecture and Architecture Modeling Techniques (UML, MDA, EUP): http://www.agiledata.org/essays/enterpriseArchitectureTechniques.html
  • Testen objekt-orientierter Systeme: http://www.glenesoft.com/fhdw/OOTest/PrintAll.shtml
  • Zeitschriftenartikel
  • Wagner: Gut gelaufen, Agile Software-Entwicklung führt flott zu Resultaten, c't 13/2008, S. 216
  • Klingenberg: Entwickeln nach dem V-Modell XT, Tante Emma behält den Überblick, Javamagazin 2006.05, S. 87
  • Lux: Angewandte Prozessmodelle, Rational Unified Process (RUP) und Extreme Programming (XP) im Vergleich, Javamagazin 2002.12, S. 73
  • Bücher
  • Kruchten, The Rational Unified Process, 2000, 0201707101: Amazon.de
  • Versteegen/Kruchten/Boehm, Projektmanagement mit dem Rational Unified Process, 2000, 3540667555: Amazon.de
  • Oestereich, Objektorientierte Softwareentwicklung (OEP), 2004, 3486272667: http://www.oose.de/publikationen.htm, Javamagazin, Amazon.de
  • Beck, Extreme Programming, 2000, 3827317096: Amazon.de
  • Pichler, Scrum - Agiles Projektmanagement erfolgreich einsetzen, 2008, 3898644782: Rezension, Amazon.de
  • Mayr, Projekt Engineering, 2005, 3446400702: Rezension, Amazon.de
  • Ludewig/Lichter, Software Engineering, 2006, 3898642682: Rezension, Amazon.de
  • Starke, Effektive Software-Architekturen, 2009, 3446420088: Rezension, Amazon.de
  • Wunderlich, Software-Architekturen in Java, 2005, 3826615379: Rezension, Amazon.de
  • Bien, Enterprise Architekturen, 2006, 393504299X: Rezension, Amazon.de
  • Siedersleben, Moderne Software-Architektur - Umsichtig planen, robust bauen mit Quasar, 2004, 3898642925: Rezension, Amazon.de



Weitere Themen: andere TechDocs | UML, MDA | Patterns
© 2001-2007 Torsten Horn, Aachen

0 thoughts on “V Modell Xt Projekthandbuch Beispiel Essay

Leave a Reply

Your email address will not be published. Required fields are marked *