 |
 |
 |
|
| 3 Allgemeine Regelungen |
 Contents
|
|
|---|
3.1 Projektspezifisches V-Modell und Tailoring
Die in den Submodellen beschriebenen Aktivitäten und Produkte sind für die Verwendung sowohl in kleinen als auch großen IT-Systementwicklungsprojekten bzw. Pflege- und Änderungsprojekten vorgesehen. Entsprechend dem Entwicklungsgegenstand, dessen Anforderungen an Funktionalität, an Komplexität der Funktionen und Daten und an die Qualitätsmerkmale, wie z. B. Wartbarkeit, sind im konkreten Projekt das Vorhandensein eines (Teil-) Produkts und die Durchführung einer (Teil-) Aktivität festzulegen. Produkte und Aktivitäten können in einem bestimmten Projekt gegenüber dem generischen V-Modell wegfallen. Das Ergebnis dieses Planungsschritts wird "projektspezifisches V-Modell" genannt.
Die Festlegung des projektspezifischen V-Modells wird durch zwei Anpassungsschritte unterstützt:
- das Ausschreibungsrelevante Tailoring und
- das Technische Tailoring.
3.2 Projektorganisation und Rollen
Die Einsatzplanung von Projektmitarbeitern, d. h. die Zuordnung von Aufgaben zu den einzelnen Mitarbeitern des Projekts, erfolgt über Rollen. Das V-Modell nennt für jedes Submodell eine Menge von Rollen, deren Rolleninhaber entsprechend fest definierter Rollen/Aktivitäten-Zuordnungen Aktivitäten bearbeiten. Es werden verschiedene Bearbeitungstypen unterschieden: "verantwortlich (im Sinne der Ausführung)", "mitwirkend" und "beratend". Zu jeder Rolle sind Kenntnisse und Fähigkeiten genannt, die für die Bearbeitung der zugeordneten Aktivitäten gefordert werden.
Bei der Einsatzplanung erfolgt nun die Festlegung der Mitarbeiter oder anderer Organisationseinheiten zu den Aktivitäten über die Rollendefinitionen. Eine Rolle kann von einem oder mehreren Mitarbeitern eingenommen werden. Der Mitarbeiter hat die Kenntnisse und Fähigkeiten der Rolle zu besitzen und kann dann für die Bearbeitung der Aktivitäten, die der Rolle zugeordnet sind, entsprechend den Beteiligungstypen eingeplant werden. Eine Person kann z. B. bei kleineren Projekten mehrere Rollen innehaben, wobei jedoch gewisse Regeln einzuhalten sind. So darf kein Entwickler seine Ergebnisse im Rahmen der QS selbst prüfen.
Durch dieses Rollenkonzept bleibt das V-Modell organisationsneutral. Eine generelle Zuordnung der in einer Organisation existierenden Stellen zu Rollen erleichtert zwar die Organisation in jedem Einzelprojekt und wird daher empfohlen. Sie wird jedoch durch das V-Modell nicht vorgeschrieben.
Eine erfolgreiche Entwicklung verlangt, daß die nachstehenden Abstimmprozesse geregelt ablaufen:
- Zwischen Anwender, Aufgabensteller und Realisierer
Dies gewährleistet, daß die realisierte Lösung tatsächlich die Bedürfnisse des Anwenders erfüllt. - Zwischen SW- und HW-Entwicklung sowie zwischen der Entwicklung von IT-Anteilen und Nicht-IT-Anteilen
Dies dient in erster Linie der Klärung von Schnittstellen, der Untersuchung der Realisierbarkeit von Anforderungen und Konzepten sowie gemeinsamen Prüfaktivitäten. - Zwischen der Systementwicklung und dem organisatorischen Umfeld
Dies gewährleistet die Ablauffähigkeit und Wirksamkeit der realisierten Lösung im gegebenen Umfeld. - Die Aufgabe des Projektverantwortlichen es, eine geeignete Rollenbelegung sicherzustellen.
3.3 Anwendung der Szenarien
Das V-Modell beschreibt die Systementwicklung im Regelungsteil (Abschnitt 4 ff.) als logisch verknüpftes Netz von Aktivitäten und Produkten. Die Abhängigkeiten sind dabei dadurch gegeben, daß für die Ausführung einer bestimmten Aktivität genau definierte Eingangsprodukte in einem ebenfalls definierten Zustand vorliegen müssen. In der konkreten Projektabwicklung müssen nun alle Entwicklungsaktivitäten auf ein Lebenszyklusmodell abgebildet und damit in einen zeitlichen Ablauf eingebunden werden. Basis der Ablaufplanung sind dabei die gewählte Entwicklungsstrategie und die sich daraus ergebenden statischen Abhängigkeiten, d. h. die Abhängigkeit jeder Aktivität von der Verfügbarkeit der erforderlichen Eingangsprodukte.
In der Praxis erfolgt eine Systementwicklung in Ausbaustufen. Dabei wird ein System in seiner Gesamtheit geplant, aber in Teilen realisiert. Die Funktionalität wächst ständig. Im Regelfall soll an den Nutzer frühzeitig eine erste Systemversion ausgeliefert werden, die die Basisfunktionalität unter Einhaltung der grundlegenden Qualitätsanforderungen besitzt. Spätere Systemteile erweitern im wesentlichen diese Funktionalität.
Diese stufenweise Vorgehensweise wird als "Inkrementelle Entwicklung" bezeichnet. Sie stellt den Regelfall der Anwendung des V-Modells dar.
Für die Anwendung des V-Modells bedarf es der Planung der Ausbaustufen. Für jede Ausbaustufe ist die zu realisierende Funktionalität samt ihrer Qualitätsforderungen festzulegen. Die Aktivitäten und Produkte einer Ausbaustufe sind entsprechend den in den Produktflüssen definierten logischen Bedingungen zeitlich zu planen. Bereits existierende Produkte werden den Entwicklungsstufen entsprechend fortgeschrieben. Für die Produkte, die infolge der stufenweisen Entwicklung einem dynamischen Bearbeitungsprozeß unterliegen (z. B. Anwenderforderungen), ist insbesondere der geplante Bearbeitungsstand der entsprechenden Produkte für jede Ausbaustufe festzuschreiben.
In Teil 3 - Handbuchsammlung (Handbuch Szenarien) ist die Anwendung des V-Modells für verschiedene Vorgehensweisen bei der Systementwicklung anhand der folgenden Szenarien beispielhaft dargestellt:
- Inkrementelle Entwicklung,
- Grand Design (Traditionelles Vorgehen),
- Einsatz von Fertigprodukten,
- Objektorientierte Entwicklung,
- Entwicklung wissensbasierter Systeme,
- SW-Pflege und Änderung,
- Reverse Engineering.
(daVinci Graph Visualization Tool v2.0)
Abbildung 3.1: Planung einer Systementwicklung
Abbildung 3.1: Planung einer Systementwicklung skizziert die Planung einer IT-Systementwicklung. Die Planung der Aktivitäten und ihrer Produkte erfolgt anhand der im Projekthandbuch festgelegten Entwicklungsstrategie und dem projektspezifischen V-Modell. Die Szenarien der Handbuchsammlung bieten Hilfestellung bei der Festlegung der Entwicklungsstrategie durch die Vorgabe von Auswahlkriterien.
Für unterschiedliche Systemanteile können unterschiedliche Strategien ausgewählt werden, was zur Folge haben kann, daß auch unterschiedliche Ausprägungen des projektspezifischen V-Modells notwendig werden.
3.4 Operative Module
Neben den im Regelungsteil des V-Modells (Teil 1, Abschnitt 4 ff.) genannten Submodellen enthält Teil 3 - Handbuchsammlung verschiedene Ergänzungen bzw. Ersetzungen der Submodelle, die als "operative Module" bezeichnet werden. Ihr Einsatz hängt vom Entwicklungsgegenstand ab.
Fordert die Entwicklung des geplanten IT-Systems neben der Entwicklung von SW-Einheiten auch die Entwicklung von HW-Einheiten, so wird die Ergänzung des Submodells SE um die Hardwareerstellung notwendig. Das operative Modul "Hardwareerstellung" behandelt die Entwicklung von HW-Einheiten (Aktivitäten SE4-HW - HW-Grobentwurf bis SE7-HW - HW-Integration).
Handelt es sich um ein Reverse-Engineering-Projekt, so kann das gesamte Submodell SE durch das operative Modul Reverse Engineering ausgetauscht werden.
3.5 Behandlung fortzuschreibender Produkte
Das V-Modell behandelt die Bearbeitung von Produkten im Regelfall in folgender Art und Weise:
- Erstellung eines Produkts (Zustand "in Bearb.") in einer Teilaktivität oder mehreren Teilaktivitäten einer Hauptaktivität und
- Übergabe des Produkts an QS (Zustand "vorgelegt"), nachdem alle Teilprodukte erstellt wurden.
Dennoch erfordern die Besonderheiten einer IT-Systementwicklung für einige Produkte ein hiervon abweichendes Vorgehen: Versionen können (u. a. im Rahmen einer inkrementellen Vorgehensweise) in den Zustand "vorgelegt" gehen, obwohl sie nur vollständig in bezug auf die geplante Version sind.
Zu den Produkten, für die diese modifizierte Vorgehensweise zur Fortschreibung erforderlich sein kann, gehören:
- Anwenderforderungen,
- Systemarchitektur,
- Technische Anforderungen,
- Betriebsinformationen
- Schnittstellenübersicht and Schnittstellenbeschreibung,
- Datenkatalog,
- Konfigurations-Identifikationsdokument,
- Änderungsstatusliste and Projekthistorie,
- Projektplan and
- Integrationsplan.
- "Anwenderforderungen"
Die Fortschreibung des Produkts Anwenderforderungen erfährt unter dem Gesichtspunkt einer inkrementellen Vorgehensweise eine besondere Behandlung.
Die grobe Systembeschreibung enthält den Kern und den Gesamthorizont für die Funktionalität des Systems. Aufgrund einer Priorisierung werden Bereiche identifiziert, die zeitlich versetzt realisiert werden. Dazu muß klar sein, in welchen (bereichsspezifischen) Ausbaustufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden. Dies fordert weiterhin, daß alle relevanten fachlichen Bereiche benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt sein müssen. Mit der vollständigen Beschreibung mindestens eines Bereichs kann die erste Version der Anwenderforderungen abgeschlossen werden. Diese unterliegt der QS.
Die weitere Fortschreibung der Anwenderforderungen basiert auf der Detaillierung der identifizierten Bereiche. Bevor ein neuer Bereich weiter entwickelt wird, sind die Anwenderforderungen für diesen Bereich festzuschreiben und qualitätszusichern. Die QS hat besonders darauf zu achten, daß die Fortschreibung keinen bestehenden Anwenderforderungen widerspricht. Änderungen des vereinbarten Gesamthorizonts für die Funktionalität während der Entwicklung sind über Aktivität KM3 - Änderungsmanagement (Konfigurationssteuerung) abzuwicklen. Teilentwicklungen sind gegebenfalls davon betroffen, was aus vertragsrechtlichen Gründen zu Problemen führen kann.
- "Systemarchitektur"
Die Systemarchitektur beschreibt die Zerlegung des Systems bis zur Ebene der SW-Einheiten und HW-Einheiten. Sie befindet sich daher während ihrer Erstellung in Aktivität SE2 - System-Entwurf im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen.
- "Technische Anforderungen"
Das Produkt Technische Anforderungen enthält technische Anforderungen an das Gesamtsystem, an Segmente und an SW-Einheiten/HW-Einheiten. Das Produkt befindet sich daher während seiner Erstellung in den Aktivitäten SE2 - System-Entwurf und SE3 - SW-/HW-Anforderungsanalyse im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jeder Ergänzung technischer Anforderungen bezüglich einzelner Elemente der Systemarchitektur die neu hinzugekommenen Teile von QS prüfen zu lassen.
Aufgrund des Umfangs dieses Produkts (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheiten oder Segmenten vorzunehmen.
- "Betriebsinformationen"
Bei den hierunter zusammengefaßten Produkten "Informationen zum Anwendungshandbuch", "Informationen zum Diagnosehandbuch", "Informationen zum Betriebshandbuch" und "Sonstige Einsatzinformationen" handelt es sich um Informationen zur Anwenderdokumentation, die im Laufe der Systemerstellung aus den SE-Produkten abgeleitet und erarbeitet, sukzessive gesammelt und in Aktivität SE 8 "System-Integration" vervollständigt werden. Eine QS-Prüfung findet daher erst beim Abschluß der Entwicklungsarbeiten, d. h. nach Aktivität SE8 - System-Integration, statt. Aufgrund des Umfangs dieser Produkte (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheit oder Segmenten vorzunehmen, die dann auch einzeln und gegebenenfalls auch früher einer QS-Prüfung unterzogen werden können.
- "Schnittstellenübersicht" and "Schnittstellenbeschreibung"
Bei der Schnittstellenübersicht handelt es sich um ein Produkt, welches aus den Überlegungen und Entscheidungen bzgl. der Systemarchitektur und SW-Architektur resultiert. Es befindet sich daher während seiner Erstellung in den Aktivitäten SE2 - System-Entwurf und SE4-SW - SW-Grobentwurf im Zustand "in Bearb.", daran anschließend wird es an QS übergeben. Ungeachtet dessen kann es bei Systemen mit einer hohen Schnittstellenkomplexität sinnvoll sein, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen. Prinzipiell liegt bei der Schnittstellenbeschreibung der gleiche Sachverhalt vor. Da es sich hier jedoch um ein Produkt handelt, das nachfolgende Entwurfsschritte in entscheidendem Maß beeinflußt, wird für die Schnittstellenbeschreibung eine QS-Prüfung nach jeder Bearbeitungsaktivität (Aktivitäten SE2 - System-Entwurf, SE4-SW - SW-Grobentwurf) empfohlen. Die neu hinzugekommenen bzw. veränderten Teile sind dabei zu prüfen.
- "Datenkatalog"
Der projektspezifische Datenkatalog wird über die projektübergreifende Datenadministration des KM (falls vorhanden) auf der Basis eines projektübergreifenden Datenkatalogs (falls vorhanden) initialisiert. Als projektumfassendes Dokument wird der Datenkatalog mit Aktivität SE5.1-SW - SW-Komponente/-Modul/Datenbank beschreiben sukzessive um Inhalte erweitert, welche von der projektübergreifenden Datenadministration zu genehmigen sind. Die an Aktivität SE5-SW - SW-Feinentwurf anschließende QS-Prüfung behandelt diese Ergänzungen.
- "Konfigurations-Identifikationsdokument" (KID)
Das KID ist ein über die Aktivität KM2 - Produkt- und Konfigurationsverwaltung geführtes Produkt. Aktivität KM 2 ist eine projektbegleitende Aktivität, d. h. sie ist parallel zu den SE-Aktivitäten permanent "aktiv". Auslöser der Aktivität sind die im Projekt erstellten Produkte. Ein KID bezieht sich auf ein System, eine SW-Einheit bzw. eine HW-Einheit. In Abhängigkeit von dem jeweiligen Bezugsobjekt muß das KID solange im Zustand "in Bearb." bleiben, solange sich auch das Bezugsobjekt in diesem Zustand befindet.
- "Änderungsstatusliste" and "Projekthistorie"
Hier handelt es sich um Produkte, die über die gesamte Projektlaufzeit und gegebenenfalls über Folgeprojekte hinweg fortgeschrieben werden müssen. Da sie in erster Linie der projektinternen Dokumentation dienen, wird für sie keine QS-Prüfung vorgeschrieben. - "Projektplan"
Der Projektplan befindet sich während des gesamten Projektes "in Bearb.". Eine zu bestimmten Zeitpunkten im Projektfortschritt verbindlich vorgeschriebene QS-Prüfung würde die Planung und Steuerung des Projektmanagements behindern. Dennoch ist auch der Projektplan zu prüfen, was beispielsweise im Rahmen von Durchführungsentscheidungen erfolgen kann. (Siehe dazu auch den Produktfluß von Aktivität PM4 - Feinplanung.)
- "Integrationsplan"
Der Integrationsplan beschreibt die Integration des Systems ausgehend von SW-Modulen, SW-Komponenten, SW-Einheiten/HW-Einheiten und Segmenten. Er befindet sich während der Erstellung in Aktivität SE2 - System-Entwurf und Aktivität SE4-SW - SW-Grobentwurf im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Verfeinerungsschritt die Ergänzungen von QS prüfen zu lassen.
Der Vollständigkeit halber seien hier noch weitere Sonderfälle von Produkten aufgeführt:
- QS-Plan
Dieses Produkt wird von QS erstellt. Eine Prüfung mit Vergabe des Zustands "akzeptiert" sollte durch die Projektleitung bzw. durch Institutionen außerhalb des Projekts (z. B. QS-Beauftragter) erfolgen. (Siehe dazu auch die Abwicklungsregelung von Aktivität QS1.1 - QS-Plan erstellen.). - Änderungsvorschlag, Änderungsauftrag, Änderungsmitteilung
Diese Produkte werden ohne Zustand geführt. Entscheidend für deren Behandlung ist der Status der betreffenden Änderung. - Arbeitsauftrag and "Berichtsdokumente"
Diese Produkte unterliegen keiner QS-Prüfung und werden im V-Modell ohne Zustände geführt.
Empfehlung:
Zur Absicherung der Ergebnisse der Entwicklungsarbeiten sollten Produkte gegebenenfalls schon vor der im V-Modell vorgeschriebenen abschließenden Produktprüfung einer (Teil-) Prüfung durch QS unterzogen werden. Dieser Weg sollte mindestens dann eingeschlagen werden, wenn- die Komplexität des Systems und damit der Umfang eines Produktes eine effektive Gesamtprüfung unverhältnismäßig erschwert oder
- Teilprojekte definiert wurden, die einen gesicherten Produktstand voraussetzen.
Diese Maßnahme bietet sich beispielsweise an für eine Schnittstellenbeschreibung je Schnittstelle oder für Handbücher je Segment oder SW-Einheit bzw. HW-Einheit.
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|