H Anhang

Akteure (externe Beteiligte außerhalb des Systems) sind an Anwendungs- bzw. Geschäftsfällen beteiligt. Es muss zwischen primären und sekundären Akteuren unterschieden werden. Ein primärer Akteur ist derjenige, der einen Anwendungs- bzw. Geschäftsfall auslöst (z.B. ein Kunde, der eine bestimmte Dienstleistung vom fachlichen System erwartet). Bei dem Kunden kann es sich um einen "echten" Kunden handeln oder auch z.B. um Abteilungen oder andere (fachliche) Systeme. Ein sekundärer Akteur sind Personen oder Systeme, die zur externen Unterstützung für die Umsetzung von Anwendungs- bzw. Geschäftsfällen benötigt werden.

Man unterscheidet zwischen Aktivitätstyp und Aktivitätsexemplar. Im V-Modell-Kontext bezeichnet der Begriff Aktivität im Allgemeinen einen Aktivitätstyp.

Unter einem Aktivitätsexemplar versteht man die konkrete Ausprägung eines Aktivitätstyps, zum Beispiel die Realisierung einer bestimmten Software-Einheit.

siehe Disziplin.

Unter dem Begriff Aktivitätsstruktur versteht man die Menge der Aktivitätsexemplare eines Projekts und deren Zusammenhänge.

Ein Aktivitätstyp (im Folgenden kurz als "Aktivität" bezeichnet) beschreibt Aktivitätsexemplare, die während eines Entwicklungsprozesses ausgeführt werden können.

Aktivitäten sind Bestandteil genau einer Disziplin und damit stets einem Vorgehensbaustein zugeordnet. Jedes Produkt wird einer es bearbeitenden Aktivität zugeordnet. Aktivitäten verändern also Produkte. Produkte, die in einer Aktivität nur als Eingabe dienen, werden nicht explizit einer Aktivität zugeordnet. Bei Fertigstellung eines Produkts ist dieses im Produktzustandfertig gestellt und die dem Produkt zugeordneten Fertigstellungsbedingungen gelten. Aktivitäten untergliedern sich weiter in Arbeitsschritt.

Ein Anwendungsprofil stellt die Wertbelegung der einzelnen Projektmerkmale im konkreten Projekt dar. Anhand dieses Anwendungsprofils findet ein erstes Tailoring statt.

Ein Arbeitspaket ist eine projektspezifische inhaltliche Gruppierung von Aktivitätsexemplaren.

Beispielsweise können Aktivitätsexemplare aus dem Konfigurationsmanagement zu einem Arbeitspaket zusammengefasst werden, da unter Umständen keine terminliche Planung dieser Aktivitätsexemplare im Einzelnen erfolgen muss.

Ein Arbeitsschritt gehört zu genau einem Vorgehensbaustein und ist stets einer Aktivität zugeordnet. Arbeitsschritte bearbeiten Produkte und Themen. Ein Arbeitsschritt ist eine Beschreibung, wie eine Aufgabe, die typischerweise in einem Projekt beziehungsweise in einer Organisation anfällt, durchzuführen ist. Arbeitsschritte sind also vergleichbar mit einer Arbeitsanleitung, die geschlossen auszuführen ist, um einen oder mehrere Produktbausteine zu bearbeiten.

Architektur ist der Oberbegriff für die folgenden Produkte: Systemarchitektur, Unterstützungs-Systemarchitektur und SW-Architektur

Unter einem Auftraggeber wird der Kunde im Rahmen einer Vertragssituation verstanden, also der Empfänger eines vom Auftragnehmer bereitgestellten Produkts (DIN EN ISO 8402).

Die Auftraggeber-/Auftragnehmer-Schnittstelle beschreibt explizit, welche Produkte zwischen dem Auftraggeber- und dem Aufragnehmer-V-Modell-Projekt ausgetauscht werden. Diese Produkte werden Schnittstellenprodukte genannt.

Unter einem Auftragnehmer wird der Lieferant im Rahmen einer Vertragssituation verstanden, also die Organisation, die dem Auftraggeber ein Produkt bereitstellt (DIN EN ISO 8402).

Eine Arbeitsschritt bearbeitet ein Thema, ist also an dessen Fertigstellung beteiligt.

Aufgabe des Datenschutzes ist es, den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird. (Quelle: Bundesdatenschutzgesetz)

Die Produkte und Aktivitäten des V-Modells sind hierarchisch strukturiert. Auf der obersten Ebene befinden sich Disziplinen. Eine Disziplin ist eine Gruppierung einer Menge von inhaltlich eng zusammenhängenden Produkten und der Aktivitäten, die die enthalten Produkte erstellen. In früheren Versionen des V-Modell XT wurden Disziplinen durch Produktgruppen und Aktivitätsgruppen repräsentiert. Diese Unterscheidung wird nicht mehr vorgenommen. Jedes Produkt ist genau einer Disziplin fest zugeordnet. Darüber hinaus existieren Querschnittsdisziplinen, die orthogonal zu den Disziplinen stehen und denen Produkte nur "lose" zugeordnet werden. Beispielsweise sind ist das Produkt Logistische Berechnungen und Analysen einerseits der Disziplin Systemanalyse fest zugeordnet, andererseits aber auch Teil der Querschnittsdisziplin Logistikkonzeption. Querschnittsdisziplinen finden sich ausschließlich im Kapitel Inhalte des V-Modell XT, dienen aber nicht aber nicht zur Gruppierung in den Referenzteilen.

Dynamisches Tailoring ist das Tailoring, das nach der Projektinitialisierung und damit während der Projektlaufzeit durchgeführt wird, also nach dem Entscheidungspunkt Projekt definiert. Dynamisches Tailoring kann zum Beispiel durch Tailoring-Produktabhängigkeiten initiiert werden.

In einem Entscheidungspunkt wird über das Erreichen einer Projektfortschrittsstufe entschieden. Diese Entscheidung wird auf Basis der zum Entscheidungspunkt vorzulegenden, fertig gestellten Produkte getroffen

Die Reihenfolge, in welcher die Entscheidungspunkte im Rahmen eines Projekts durchlaufen werden müssen, wird in der Projektdurchführungsstrategie festgelegt.

Eine Entwicklungsstrategie, bei der zunächst das Gesamtsystem in einer Gesamtsystemspezifikation (Pflichtenheft) spezifiziert wird. Der Systementwurf wird anschließend nach dem Divide&Conquer-Prinzip immer weiter verfeinert bis SW-Spezifikationen vorliegen, die dann anhand einer SW-Architektur umgesetzt und integriert werden.

Der Auftragnehmer entwirft, realisiert und liefert das System in einzelnen Stufen, welche auch Inkrement genannt werden. Jede dieser Stufen wird einzeln vom Auftraggeber abgenommen und entweder im Vorfeld vertraglich vereinbart oder es werden zusätzliche Verträge über die Abwicklung ergänzender Inkremente abgeschlossen. Bevor ein Inkrement an den Auftraggeber ausgeliefert wird, kann der Auftragnehmer intern mehrere Iterationen durchlaufen.

Änderungen durch den Auftraggeber innerhalb eines Inkrements sind bei dieser Entwicklungsstrategie zu vermeiden und sollten über das Änderungsmanagement im folgenden Inkrement berücksichtigt werden. Wichtige Änderungen, die beispielsweise die Architektur des Systems maßgeblich beeinflussen könnten, sollten dem Auftragnehmer so früh wie möglich mitgeteilt werden. Für den Auftraggeber hat diese Vorgehensweise den Vorteil, dass er frühzeitig in den Besitz einer Vorstufe des Systems gelangt, die bereits die wichtigsten Grundfunktionalitäten des Systems realisiert.

Diese Entwicklungsstrategie eignet sich vor allem dann, wenn die Anforderungen an das System als relativ stabil eingeschätzt werden und technologische Risiken eher gering sind. Es können Fertigprodukte eingesetzt werden, der Hauptanteil des Systems wird jedoch im Rahmen des Projekts erstellt.

Der Entwicklungsstrategie komponentenbasierte Entwicklung liegt die Idee zugrunde, dass das neue System weitgehend durch Integration bestehender Systemelemente erstellt wird. Ein für die Integration vorgesehenes Systemelement (z.B. ein Segment oder eine HW/SW-Einheit) hat eine klar definierte Schnittstelle nach außen, kapselt Entwurf und Implementierung und kann mit anderen Systemelementen verbunden werden. Es ist sowohl fachlich als auch technisch unabhängig und besitzt eine gewisse Größe (im Sinne eines wirtschaftlichen Wertes).

Allgemein werden von einem Systemelement für die Integration folgende Eigenschaften verlangt:

• Verfügbarkeit klarer, sauber definierter Schnittstellen
• Kommunikation mit der Außenwelt (zum Beispiel mit anderen Komponenten) ausschließlich über die definierten Schnittstellen
• Anpassung an bestimmte Anwendungsumgebungen (Customizing) nur über die Schnittstellen
• Realisierungsspezifika bleiben dem Benutzer verborgen (Blackbox-Sichtweise)

Die prototypische Entwicklungsstrategie basiert auf der Erkenntnis, dass es oft nicht möglich ist, die Anforderungen an ein System vorab zu definieren. Außerdem stellt sie sicher, dass nichts spezifiziert wird, was sich als nicht realisierbar herausstellt. Somit wird diese Strategie insbesondere verwendet, wenn Realisierungsrisiken im Projekt vorhanden sind. Änderungen an den Anforderungen werden über das Problem- und Änderungsmanagement verwaltet.

Typisch für diese Entwicklungsstrategie ist darüber hinaus die Präsenz des Auftraggebers auf der Auftragnehmerseite während der Entwicklung. Dadurch kann der Auftraggeber Änderungswünsche sehr direkt übermitteln. Der Auftragnehmer entwirft, realisiert und liefert das System dann ähnlich wie bei der Entwicklungsstrategie inkrementelle Entwicklung in einzelnen Stufen. Diese Stufen werden jede für sich vom Auftraggeber abgenommen. Für den Auftraggeber hat diese Vorgehensweise den Vorteil, dass er bereits frühzeitig in den Besitz eines lauffähigen Systems gelangt, das die wichtigsten Grundfunktionalitäten realisiert. Ferner ermöglicht sie eine frühzeitige Rückmeldung durch den Auftraggeber, die die Entwicklungsrisiken des Auftragnehmers minimiert.

siehe V-Modell.

siehe Produktabhängigkeit, erzeugende.

Unter dem Produkt Externe Einheit versteht man Systemelemente, die nicht innerhalb des Projekts entwickelt werden. Bei einem Produkt vom Typ Externe Einheit kann es sich um ein Fertigprodukt, eine Beistellung des Auftraggebers, ein im Vorfeld entwickeltes System oder Segment, welches wiederverwendet wird, ein Nachbarsystem oder das Ergebnis eines Unterauftrags handeln. Eine Externe Einheit kann sowohl HW- als auch SW-Anteile umfassen.

siehe HW-Modul, externes.

siehe Produkt, externes.

siehe SW-Modul, externes.

Definiert einen Produktzustand eines Produkts, das fertig gestellt ist. Für diesen Begriff "fertig gestellt" wird häufig auch der Begriff "freigegeben" oder auch "gültig" verwendet. Dieser Produktzustand wird in der Produktbibliothek gesetzt.

Die Funktionssicherheit steht für die Verfahrens- oder Betriebssicherheit sowie für Zuverlässigkeit, Fehlertoleranz und Korrektheit. Dieser Zustand ergibt sich aus Maßnahmen, durch die das Risiko eines Personen-, Sach- oder immateriellen Schadens auf einen annehmbaren Wert begrenzt ist.

Der Begriff HW-Element ist ein Oberbegriff, der in der Hierarchie der Systemelemente alle Systemelemente ab der Ebene der HW-Einheit bezeichnen kann: HW-Einheit, HW-Komponente, HW-Modul und Externes HW-Modul.

Unter dem Produkt Externes HW-Modul versteht man Systemelemente (HW-Module, HW-Komponenten), die nicht innerhalb des Projekts entwickelt werden. Ein Externes HW-Modul ist ein selbständig beschreibbares Funktionselement. Dabei kann es sich um ein Fertigprodukt, eine Beistellung des Auftraggebers, eine im Vorfeld entwickelte Komponente, die wiederverwendet wird, ein Nachbarsystem oder das Ergebnis eines Unterauftrags handeln.

Definiert einen Produktzustand eines Produkts, das sich in der Bearbeitung befindet. Dieser Produktzustand wird in der Produktbibliothek gesetzt.

Informationssicherheit beschreibt den Zustand, der die Verfügbarkeit, die Integrität, die Verbindlichkeit und die Vertraulichkeit von Informationen gewährleistet. Dieser Zustand ergibt sich aus technischen Maßnahmen sowie aus Maßnahmen personeller, materieller (beinhaltet baulich-technische Maßnahmen) und organisatorischer Art.

Der Geltungsbereich eines IT-Sicherheitskonzepts wird als Informationsverbund bezeichnet und stellt detailliert den Bereich dar, für den das Sicherheitskonzept umgesetzt werden soll. Ein Informationsverbund kann sich somit auf Fachaufgaben, Geschäftsprozesse oder Organisationseinheiten beziehen. Er umfasst alle infrastrukturellen, organisatorischen, personellen und technischen Komponenten, die der Aufgabenerfüllung in diesem Anwendungsbereich der Informationsverarbeitung dienen. Der Informationsverbund muss so festgelegt sein, dass die betrachteten Geschäftsprozesse und Informationen diesem Bereich vollständig zugeordnet werden können. Die Abhängigkeiten aller sicherheitsrelevanten Prozesse sind zu berücksichtigen. Die Schnittstellen zu den anderen Bereichen müssen klar definiert werden, so dass der Informationsverbund in der Gesamtorganisation eine sinnvolle Mindestgröße einnimmt.

siehe Produktabhängigkeit, inhaltliche .

siehe Produkt, initiales.

Bei einer Projektdurchführungsstrategie AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration wird der zu erstellende SW-/HW-Gegenstand in einer stufenweisen Vorgehensweise entwickelt. Die Entwicklung findet in Iterationen statt, d.h. die Stufen werden aufeinanderfolgend entwickelt. Jedes Inkrement ist inhaltlich weitgehend unabhängig von den anderen Inkrementen, so dass mit jeder Fertigstellung eines Inkrements bei der Lieferung ein lauffähiges System zur Verfügung steht. Ein Inkrement kann Gegenstand einer Iteration sein.

siehe Entwicklung, inkrementell.

Integrität ist der Zustand, der unbefugte und unzulässige Veränderungen von Informationen und an IT-Systemen oder -Komponenten ausschließt.

Eine Iteration bezeichnet einen einzelnen Entwicklungszyklus bei der Systemerstellung. Eine iterative Vorgehensweise bringt periodisch wiederkehrende ähnliche Aufgaben der Systementwicklung mit sich, bei denen der Gegenstand in jeder Iteration entweder ein anderer ist (z.B. Entwicklung unterschiedlicher Teilsysteme in aufeinanderfolgenden Inkrementen) oder in aufeinander folgenden Iterationen überarbeitet werden (z.B. die schrittweise Verfeinerung und Ausgestaltung von Systemen).

Ein in manchen Behörden eingerichtetes Gremium zur Koordination von IT-Projekten. Im V-Modell Teil der IT-Service-Strategie-Verantwortlicher.

siehe Entwicklung, komponentenbasierte.

Die konkludente Abnahme (lat. concludere "folgern", "einen Schluss ziehen") wird oft auch "stille Abnahme" genannt und erfolgt aufgrund von schlüssigem Handeln des Auftraggebers. Hierunter fällt beispielsweise die Bezahlung oder die Nutzung des Systems.

Wenn das System aus Sachzwängen heraus trotz bestehender Mängel in Betrieb genommen werden muss, sollte zuvor sichergestellt sein, dass sich daraus keine Abnahme ableiten lässt. Die EVB-IT schließen die konkludente Abnahme explizit aus.

Ein Produkt, das in den Zustand fertig gestellt überführt werden soll, wird im Rahmen einer Eigenprüfung und gegebenenfalls einer eigenständigen Qualitätssicherungauf Konsistenz hinsichtlich seiner relevante Produktabhängigkeiten geprüft.

Konventionsabbildungen stellen den Bezug des V-Modells zu aktuellen (Quasi-)Standards, Normen und Vorschriften dar.

Eine Konventionsabbildung setzt dazu die Begriffe, die in der Konvention definiert sind, in Beziehung zu dem Begriffssystem des V-Modells.

Jeder Messdatentyp beschreibt ein Maß, das direkt ermittelt wird (z.B. durch Zählen von Fehlern, Zählen von Stunden, Messen einer Dauer), und als konkret gemessener Wert (Messdatum) in die Ermittlung einer Metrik eingeht. Synonyme für Messdatentypen sind Basisdaten bzw. Messgrößen.

Messdatentypen

• sind absolute Werte,
• werden durch Messen an Projekt, Produkt oder Prozess gewonnen,
• können sich z.B. auf Zeitpunkte, Phasen, Produkte, Organisationsbereiche beziehen.

Messdatentypen können auch "weich" sein, d.h. sie ergeben sich aus informellen Erhebungen und individuellen Einschätzungen, z.B. Risikowahrscheinlichkeit gering/mittel/hoch.

Siehe Messdatentyp.

Eine Methodenreferenz beschreibt eine Klasse von Methoden, die zur Durchführung von Aktivitäten beziehungsweise Erstellung von Produkte verwendet werden können.

Synonym: Kennzahlen

Eine Metrik beschreibt ein quantitatives Maß für eine Eigenschaft eines Projekts, eines Produkts oder eines Prozesses.

• Metriken werden aus Messdatentypen oder anderen Metriken abgeleitet (z.B. Formeln, Prozentsätzen, Gegenüberstellungen).
• Ein Messdatentyp kann auch eine Metrik sein.

Synonym für Ausbildungsplan

Mit dem Begriff Mitwirkender werden solche Rollen bezeichnet, die vom Verantwortlichen zur Bearbeitung eines Produkts einbezogen bzw. konsultiert werden sollten.

Multi-Projektmanagement bezeichnet im Allgemeinen die Koordination mehrerer Projekte innerhalb einer Organisation. Es wird meist noch feiner differenziert in strategisches und operatives Multi-Projektmanagement. Strategisches Multi-Projektmanagement beschäftigt sich mit der Auswahl und Priorisierung von Projekten und der Definition eines Projektportfolios; es wird im V-Modell durch die Rolle IT-Service-Strategie-Verantwortlicher repräsentiert. Operatives Projektmanagement beschäftigt sich mit dem projektübergreifenden Planung und Steuerung und der Ressourcenzuordnung zwischen den einzelnen Projekten; es wird im V-Modell durch die Rolle Multi-Projektkoordination repräsentiert.

Darüber hinaus kennt das V-Modell den Vorgehensbaustein Multi-Projektmanagement. Dieser kümmert sich allerdings um die gleichzeitige Zusammenarbeit mit mehreren (organisationsfremden) Auftragnehmern und entspricht eher einer Losbildung bei der Vergabe.

Eine Rolle kann einer Rollenkategorie zugeordnet werden. Organisationsrollen sind auch außerhalb der Lebenszeit des Projektes besetzt. Es sind solche Rollen, die in der Organisation unabhängig vom konkreten Projektkontext bestehen, und einen institutionalisierten Verantwortungsbereich innehaben. Sie werden im V-Modell XT berücksichtigt, da sie Verantwortung für wichtige, projektübergreifende Produkte haben können.

siehe Vorgehensmodell, organisationsspezifisches.

Man unterscheidet zwischen Produkttyp und Produktexemplar. Welche Bedeutung der Begriff Produkt hat, ist vom jeweiligen Kontext abhängig. Nicht nur das zu erstellende System, sondern alle Dokumente, Prüfprotokolle, SW-Module, kurz: Erzeugnisse, werden im V-Modell XT als Produkttyp (häufig auch nur als Produkt) bezeichnet.

Externe Produkte sind Produkte (z.B. Externe Einheit, Externes HW-Modul oder Externes SW-Modul), die außerhalb des V-Modell-Projekts erstellt werden können. Für externe Produkte gibt das V-Modell XT verantwortliche Rollen an. Es werden aber nicht zu jedem externen Produkt Aktivitäten angegeben.

Der Begriff initiales Produkt steht für ein Produkt, das in jedem Fall und genau einmal erstellt werden muss.

Eine Produktabhängigkeit beschreibt eine Konsistenzbedingung zwischen zwei oder mehreren Produkten. Dabei kann eine Produktabhängigkeit sowohl innerhalb eines Vorgehensbausteins als auch zwischen Produkte verschiedener Vorgehensbausteine bestehen.

Man unterscheidet Tailoring-Produktabhängigkeiten, erzeugende Produktabhängigkeiten, strukturelle Produktabhängigkeiten und inhaltliche Produktabhängigkeiten. Alle diese Arten von Produktabhängigkeiten können relevante Produktabhängigkeiten sein.

Eine erzeugende Produktabhängigkeit beschreibt, dass in einem oder mehreren Ausgangsprodukten die Bedingungen beziehungsweise Regeln festgelegt werden, unter denen eines oder mehrere Zielprodukte erzeugt werden müssen.

Eine inhaltliche Produktabhängigkeit beschreibt den inhaltlichen Zusammenhang mehrerer Produkte. Eine inhaltliche Produktabhängigkeit ist beispielsweise gegeben, wenn eine Änderung an einem Produkt eine Änderung eines weiteren Produkts nach sich zieht.

Eine Produktabhängigkeit ist relevant im Bezug auf ein betrachtetes Produkt, genau dann wenn sie - in den im Rahmen des Tailoring ausgewählten Vorgehensbausteinen enthalten ist und - das betrachtete Produkt enthält und - mindestens ein anderes Produkt in der Produktabhängigkeit den Zustand fertig gestellt hat.

Strukturelle Produktabhängigkeiten gliedern Produkte und setzen sie in Beziehungen zueinander. So gibt es beispielsweise eine strukturelle Produktabhängigkeit, die aussagt, dass eine SW-Einheit aus SW-Komponenten besteht.

Tailoring-Produktabhängigkeiten beschreiben die für das Tailoring relevanten Beziehungen von Produkte zu Vorgehensbausteinen. So zieht zum Beispiel die Identifikation von Hardwareteilen im Rahmen des Systementwurfs die Verwendung des Vorgehensbausteins HW-Entwicklung nach sich.

siehe Produkt

Unter einem Produktexemplar versteht man die konkrete Ausprägung eines Produkttyps, zum Beispiel ein bestimmtes Dokument. Für ein konkretes Beispiel siehe Produkttyp.

siehe Disziplin.

Unter dem Begriff Produktstruktur versteht man die Menge der Produktexemplare eines Projekts und deren Zusammenhänge.

Ein Produkttyp beschreibt in allgemeiner Weise Produktexemplare, die während eines Entwicklungsprozesses entstehen können.

Z.B. beschreibt das Produkt (genauer: der Produkttyp) Besprechungsdokument alle im Projekt erstellten Besprechungsdokumente. Ein konkretes Besprechungsprotokoll ist ein Produktexemplar des Produkttyps Besprechungsdokument.

Eine Produktversion ist ein identifizierbarer und reproduzierbarer Bearbeitungsstand eines Produktartefaktes. Eine Produktversion hat genau einen Produktzustand.

Produkte besitzen einen Produktzustand, der durch Aktivitäten verändert werden kann. Man unterscheidet zwischen den drei Produktzuständen in Bearbeitung, vorgelegt und fertig gestellt.

Ein Produktzustandsmodell beschreibt den Zustand eines Produkts zu einem bestimmten Zeitpunkt. Jedes Produkt besitzt einen Produktzustand. Mögliche Produktzustände sind in Bearbeitung, vorgelegt und fertig gestellt. Der Zustand eines Produktes wird spätestens mit der erfolgreichen Beendigung der bearbeitenden Aktivität neu ermittelt.

Unter einem Projekt versteht man gemäß der IPMA eine einmalige Gesamtheit von koordinierten Aktivitäten mit bestimmten Anfangs- und Endpunkten, die von einer Person oder Organisation mit dem Ziel durchgeführt werden, bestimmte Termin-, Kosten- und Leistungsziele zu erreichen.

Ein Projektabschnitt bezeichnet den Zeitraum zwischen zwei aufeinander folgenden Entscheidungspunkten.

Die Projektdurchführungsstrategie legt die Reihenfolge fest, in der die für das Projekt relevanten Entscheidungspunkte durchlaufen werden müssen. Sie bestimmt sich anhand der Auswahl einer Projekttypvariante und der Belegung aller bedingter Projektmerkmale.

Eine Projektfortschrittsstufe kennzeichnet einen Zeitpunkt im Projekt, an dem eine gewisse Entscheidung getroffen wird und somit ein Projektabschnitt beendet wird. Eine Projektfortschrittsstufe wird daher immer erreicht, wenn ein Entscheidungspunkt erfolgreich durchlaufen wird.

Ein Projekt wird durch mehrere Projektmerkmale charakterisiert. Jedes Projektmerkmal wird zur Erstellung eines Anwendungsprofils mit einem Wert belegt, der aus einer Menge von möglichen Wertbelegungen ausgewählt werden muss. Beispiele für Projektmerkmale sind Systemsicherheit (AG) oder Projektgegenstand. Ob ein Projektmerkmal im Tailoring vom V-Modell-Anwender belegt werden muss, hängt davon ab, ob es durch den gewählten Projekttyp oder die gewählte Projekttypvariante bedingt ist.

Eine Rolle kann einer Rollenkategorie zugeordnet werden. Projektrollen sind nur zur Lebenszeit des Projektes besetzt. Es sind alle Rollen, die im Projekt sind und dort (inhaltlich) arbeiten. Sie übernehmen Verantwortung für V-Modell Produkte, i.d.R. auf Anweisung des Projektleiters oder wirken bei der Erstellung verschiedener Produkte mit, bzw. sind an Entscheidungsprozessen beteiligt.

siehe Tailoring.

siehe Tailoring-Ergebnis.

Als Projektsponsor (engl. Project Sponsor) wird im engeren Sinne diejenige Person oder Entität verstanden, die die finanziellen Mittel für das Projekt zur Verfügung stellt. Im weiteren Sinne werden alle Personen als Projektsponsor bezeichnet, die den Projekt positiv gegenüber stehen und dieses unterstützen. Die Art der Unterstützung kann dabei ganz unterschiedlich sein, beispielsweise politische Unterstützung, Bereitstellung von Mitarbeitern und Ressourcen oder auch durch positive Berichterstattung in der Presse.

Projektstakeholder sind alle Personen oder Gruppen, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Projekts besitzen. Dabei ist es unerheblich, ob dieses Interesse positiv oder negativ ist, ob die Personen/Gruppen also ein Interesse am Gelingen oder am Scheitern des Projekts haben. Typische Stakeholder (Aufzählung nicht abschließend) sind der Projektleiter und die Projektteammitglieder, die Anwender des erstellten Systems, der Projektauftraggeber sowie die Projektsponsoren und Multiplikatoren.

Eine Projektstufe bezeichnet die Zeitspanne zwischen zwei (Teil-)Lieferungen eines Auftragnehmers.

Im V-Modell wird im Wesentlichen zwischen vier unterschiedlichen Projekttypen unterschieden:

• Systementwicklungsprojekt eines Auftraggebers,
• Systementwicklungsprojekt eines Auftragnehmers,
• Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in der gleichen Organisation (ohne Vertrag),
• Einführung und Pflege eines organisationsspezifischen Vorgehensmodells.

Ein Projekttyp legt grob fest, welche Vorgehensbausteine, Projektmerkmale und Anforderungen an die Projektdurchführungsstrategie für alle Projekte dieses Typs gelten. Für jeden dieser Projekttypen bietet das V-Modell mindestens eine Projekttypvariante an.

Der Projekttyp legt auch eine Mindestmenge an Projektmerkmalen fest, die im Tailoring mit einem Wert belegt werden müssen.

Eine Projekttypvariante gestaltet einen Projekttyp aus. Die Wahl der Projekttypvariante bestimmt im Tailoring letztlich die Auswahl der Vorgehensbausteine, Projektmerkmale und Abläufe (Bestandteile der Projektdurchführungsstrategie), die ergänzend zum Projekttyp hinzugenommen werden.

siehe Entwicklung, prototypische.

siehe Disziplin

Das V-Modell XT Referenzmodell definiert die für die Konformität erforderlichen Inhalte und Beziehungen, die in einem konformen Prozess mindestens abgedeckt sein müssen.

siehe Produktabhängigkeit, relevante.

Im Risikomanagement bezeichnet man das nach Umsetzung entsprechender Gegenmaßnahmen verbleibende Risiko als Restrisiko.

Risikoklassen ermöglichen eine Priorisierung der potentiellen Risiken. Sie werden individuell in einer Organisation oder in einem Projekt festgelegt. Risikoklassen erleichtern die Entscheidung darüber, ob und welche Maßnahmen als Reaktion auf Risiken auszuwählen sind. Im Bereich des Risikomanagements orientieren sich Risikoklassen häufig an dem Risikomaß und dem Projektvolumen.Typische Risikoklassen sind z. B.

• Tolerierbar: das Risikomaß ist geringer als 0,1% des Projektvolumens,
• Unerwünscht: das Risikomaß ist größer als 0,1% und geringer als 1% des Projektvolumens,
• Kritisch: das Risikomaß ist größer als 1% und geringer als 10% des Projektvolumens,
• Katastrophal: das Risikomaß ist größer als 10% des Projektvolumens.

Im Risikomanagement bezeichnet das Risikomaß den mit der Risikowahrscheinlichkeit gewichteten Risikoschaden.

Risikomaß = Risikowahrscheinlichkeit * Risikoschaden

Der Risikoschaden ist der geschätzte Schaden, der im Schadensfall mit einem Risiko im Projekt verbunden ist. Die möglichen Schäden werden in Geldeinheiten (z.B. in T) dargestellt. Nicht in Geldeinheiten zu beziffernde Schäden (z.B. Imageverlust) sind über Hilfsgrößen weitestgehend zu monetarisieren, z.B. Imageverlust führt zu einem Umsatzverlust in Geldeinheiten.

Die Risikowahrscheinlichkeit ist die geschätzte oder berechnete Wahrscheinlichkeit, mit der ein Risiko eintritt.

Eine Rolle ist die Beschreibung einer Menge von Aufgaben und Verantwortlichkeiten im Rahmen eines Projekts und einer Organisation.

Durch die Festlegung von Rollen wird die Unabhängigkeit des V-Modells von organisatorischen und projektspezifischen Rahmenbedingungen erreicht. Die Zuordnung von Organisationseinheiten und Personen zu den Rollen erfolgt zu Beginn eines Projekts. Dabei kann eine Person mehrere Rollen besetzen, es kann aber auch eine Rolle durch mehrere Personen besetzt werden.

Jede Rolle kann einer Rollenkategorie zugeordnet sein: entweder Projektrolle oder Organisationsrolle. Das Ordnungskriterium ist somit die Projektlebenszeit.

Siehe Funktionssicherheit.

Als Schnittstellenprodukt bezeichnet man ein Produkt, welches zwischen den V-Modell-Projekten von Auftraggeber und Auftragnehmer ausgetauscht wird. Die Schnittstellenprodukte sind in der Auftraggeber-/Auftragnehmer-Schnittstelle festgelegt. Für die Erstellung des Produkte ist entweder der Auftraggeber oder der Auftragnehmer verantwortlich. Im V-Modell-Projekt des jeweils anderen Projektpartners taucht das Produkt dann unter gleichem Namen, allerdings mit dem Zusatz "(von AG)" bzw. "(von AN)" auf.

siehe Auftraggeber-/Auftragnehmer-Schnittstelle .

Siehe Informationssicherheit .

Ein Segment ist ein wesentlicher Teil eines Systems und stellt eine Hierarchie-Ebene unterhalb des Systems dar. Es ist die Realisierung eines Teils des Systems. Segmente können hierarchisch in weitere Segmente unterteilt werden.

Die Sicherheit umfasst die Begriffe Funktionssicherheit (Safety), Informationssicherheit (Security) und Datenschutz.

Funktionssicherheit steht hierbei für die Verfahrens- oder Betriebssicherheit. Dieser Zustand ergibt sich aus Maßnahmen, durch die das Risiko eines Personen-, Sach- oder immateriellen Schadens auf einen annehmbaren Wert begrenzt ist.

Informationssicherheit beschreibt hingegen den Zustand, der die Verfügbarkeit, die Integrität, die Verbindlichkeit und die Vertraulichkeit von Informationen beim Einsatz von IT gewährleistet. Dieser Zustand ergibt sich aus Maßnahmen in der Informationstechnik sowie aus Maßnahmen personeller, materieller und organisatorischer Art. Dabei ist

• Verfügbarkeit der Zustand, der die erforderliche Nutzbarkeit von Informationen sowie IT-Systemen und -Komponenten sicherstellt;
• Integrität der Zustand, der unbefugte und unzulässige Veränderungen von Informationen und an IT-Systemen oder Komponenten ausschließt;
• Verbindlichkeit der Zustand, in dem geforderte oder zugesicherte Eigenschaften oder Merkmale von Informationen und Übertragungsstrecken sowohl für die Nutzer verbindlich feststellbar als auch Dritten gegenüber beweisbar sind;
• Vertraulichkeit der Zustand, der unbefugte Informationsgewinnung/-beschaffung ausschließt.

Die Aufgabe des Datenschutzes ist es, den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird. (Quelle: BDSG)

Eine Sicherheitsstufe bezeichnet eine Stufe, die den Betrachtungseinheiten (physikalisch System / -elemente bzw. logisch Funktionen / -ketten) zugeordnet wird und die ein diskretes Maß darstellt

• für die potentielle Gefährdung (nach außen) von Personen, Umwelt oder Gütern beim Betrieb oder bei Verlust der Verfügbarkeit (Ausfall, Nichterreichbarkeit etc.) bzw. Fehlverhalten eben dieser Betrachtungseinheit und
• für die Bedrohung des Systems (von außen) während des Betriebes durch Angriffe auf diese Betrachtungseinheit mit der Zielrichtung Spionage, Sabotage, Manipulation etc. in Kombination mit der Sensitivität (dem Wert) der zu schützenden Informationen, mit denen die Betrachtungseinheit umgeht (be- / verarbeiten, übertragen, speichern).

Neben den bekannten Gefahren, die von Ausfall bzw. Fehlverhalten ausgehen, kann alleine schon der Betrieb eines Systems eine Gefährdung hervorrufen: Sowohl ein Kraftfahrzeug als auch ein Raketenwerfer oder ein Röntgengerät gefährden aufgrund von Bauprinzip und Funktionsweise schon beim fehlerfreien Betrieb Bedienpersonal, unbeteiligte Dritte und Umwelt.

Die Sensitivität von Informationen kann sowohl von Gesetzen (Datenschutzgesetz etc.) oder amtlichen Regelungen (Geheimschutz u. a.) festgelegt sein, als sich auch aus dem Geschäftsbetrieb ergeben (z. B. Kontodaten bei Banken oder Versicherungen, Patentverwaltung bei einem Forschungsunternehmen). Es geht dabei immer um den Schutz (hoher) materieller oder immaterieller Werte gegen (signifikante) Risiken (Manipulation, Missbrauch, Spionage etc.).

Akronym für Specific (spezifisch), Measurable (messbar), Accepted (akzeptiert), Realistic (realisierbar), Timely (terminierbar). Im Projektmanagement ist SMART ein Kriterium zur eindeutigen Definition von Zielen.

Statisches Tailoring ist das Tailoring, das im Rahmen der Projektinitialisierung durchgeführt wird, also bis zum Entscheidungspunkt Projekt definiert.

Eine Aktivität stellt ein Produkt fertig. Ein Aktivitätsexemplar ist erst dann abgeschlossen, wenn sich das zugehörige Produktexemplar im Produktzustand fertig gestellt befindet.

siehe Produktabhängigkeit, strukturelle .

Der Begriff SW-Element ist ein Oberbegriff, der in der Hierarchie der Systemelemente alle Systemelemente ab der Ebene der SW-Einheit bezeichnen kann: SW-Einheit, SW-Komponente, SW-Modul und Externes SW-Modul.

Unter dem Produkt Externes SW-Modul versteht man Systemelemente (SW-Module, SW-Komponenten), die nicht innerhalb des Projekts entwickelt werden. Ein Externes SW-Modul ist ein selbständig beschreibbares Funktionselement. Dabei kann es sich um ein Fertigprodukt, eine Beistellung des Auftraggebers, eine im Vorfeld entwickelte Komponente, die wiederverwendet wird, ein Nachbarsystem oder das Ergebnis eines Unterauftrags handeln.

Das System ist ein einheitliches Ganzes mit der Fähigkeit, vorgegebene Forderungen oder Ziele zu befriedigen und stellt den zwischen Auftraggeber und Auftragnehmer vereinbarten Auftragsgegenstand dar. Das System besteht aus Beschreibungen und/oder Realisierungen von Hardware, Software und/oder logistischen Elementen.

Der Begriff Systemelement ist ein Oberbegriff, der alle Elemente, die im Rahmen der Systemerstellung zu realisieren sind, bezeichnen kann. Im Einzelnen sind dies System, Unterstützungssystem, Segment, Externe Einheit, HW-Einheit, SW-Einheit, HW-Komponente, SW-Komponente, HW-Modul und SW-Modul.

Über die wörtliche Bedeutung des englischen Begriffs hinaus bedeutet Tailoring im Kontext des V-Modells nicht nur das "Wegschneiden" von Teilen, sondern auch das "Anpassen" des V-Modells. Die Anpassung des V-Modells an ein konkretes Projekt erfolgt im Normalfall über Hinzunehmen von Vorgehensbausteinen. Anpassungen innerhalb von Vorgehensbausteinen sind als Ausnahmefall anzusehen. Zusätzlich zur Auswahl der Vorgehensbausteine werden dabei die Projektdurchführungsstrategien ermittelt. Die Basis für die Auswahl der Vorgehensbausteine und der Projektdurchführungsstrategie bildet die Festlegung des Projekttyps und die Auswahl einer Projekttypvariante.

Je nach Projektfortschritt wird zwischen

• statisches Tailoring, das heißt Tailoring während der Projektinitialisierung und
• dynamisches Tailoring, das heißt Tailoring im weiteren Projektverlauf

unterschieden.

Das Tailoring-Ergebnis legt den Projekttyp, die im Projekt zu verwendenden Vorgehensbausteine und die Projektdurchführungsstrategien sowie deren Kombination fest. Das Tailoring-Ergebnis ist das Resultat des Tailorings (statisches Tailoring, oder dynamisches Tailoring).

siehe Produktabhängigkeit, Tailoring.

Testen wird als spezielle Form der Prüfung verstanden, bei der das Ausführungsverhalten von SW-Elementen einer Prüfung unterzogen wird.

Ein Testfall ist die spezielle Form eines Prüffalls, mit dem das Ausführungsverhalten von SW-Elementen geprüft werden soll.

Ein Thema ist eindeutig einem Produkt zugeordnet, das seinerseits aus beliebig vielen Themen bestehen kann. Ein Thema ist inhaltlicher Natur und in sich abgeschlossen. Die Themen eines Produkts sind als eine Aufzählung der wesentlichen Inhalte des Produkts zu verstehen. Themen werden durch Arbeitsschritt bearbeitet.

Siehe Thema.

Ein Trigger beschreibt ein Ereignis, das eine Aktivität auslöst. Trigger werden beispielsweise im Rahmen der Planung und Durchführung von Maßnahmen zur Risikovermeidung und -minderung verwendet.

Ein Auftragnehmer wird als Unterauftraggeber bezeichnet, wenn er Teile des Vertragsgegenstands selbst als Auftraggeber weiter an einen Unterauftragnehmer vergibt, um den Vertrag mit seinem Auftraggeber zu erfüllen.

Unter einem Unterauftragnehmer ist der Lieferant im Rahmen einer Vertragssituation bezeichnet, also die Organisation, die dem Unterauftraggeber ein Systemelement bzw. Teilsystem bereitstellt (DIN EN ISO 8402).

Die Validierung erbringt anhand des Systems (oder eines Prototyps) den Nachweis, dass die definierten Anforderungen die Anwenderwünsche korrekt wiedergeben. Die Validierung kann negativ verlaufen, selbst wenn das System den gestellten Anforderungen entspricht: In diesem Fall haben sich entweder die Wünsche der Anwender in der Zwischenzeit verändert oder die Anforderungsdefinition war fehlerhaft.

Mit dem Begriff Verantwortlicher werden solche Rollen bezeichnet, die für die Inhalte eines Produkts verantwortlich sind und dort festgehaltene Entscheidungen zu tragen haben. Bei der Erstellung übernimmt der Verantwortliche die tragende Rolle bei der Koordination und Verteilung der Arbeit und bei der Verfolgung des Produktzustands.

Verantwortlich für ein externes Produkt ist jene Rolle, die es in Empfang nimmt, sowie für die Distribution zur weiteren Verwendung im Rahmen des Projekts zuständig ist.

Die Verifizierung erbringt den Nachweis, dass ein System eine bestehende Spezifikation erfüllt. Meist wird das System "im aufsteigenden Ast des Vs" durch einen Test gegen die bestehende Spezifikation verifiziert.

Das V-Modell ist ein Leitfaden zum Planen und Durchführen von Entwicklungsprojekten unter Berücksichtigung des gesamten Systemlebenszyklus. Dabei definiert das V-Modell die in einem Projekt zu erstellenden Ergebnisse und beschreibt die konkreten Vorgehensweisen, mittels derer diese Ergebnisse erarbeitet werden. Darüber hinaus legt das V-Modell die Verantwortlichkeiten der einzelnen Projektbeteiligten fest.

Für die Pflege und Weiterentwicklung des V-Modells wird ein zweistufiges Verfahren definiert. In vergleichsweise kurzen Abständen, die den Innovationszyklen der Informationstechnologie gerecht werden, kann das V-Modell geändert und erweitert werden.

Dazu wird entsprechend der Erstellung eines organisationsspezifischen Vorgehensmodells ein weiterentwickeltes V-Modell, beziehungsweise Teile eines weiterentwickelten V-Modells, erarbeitet. Diese Änderungs- und Weiterentwicklungsvorschläge werden der Änderungskonferenz des V-Modells (Äko) vorgelegt. Die Äko entscheidet dann über die Übernahme der Änderungen in das V-Modell. Änderungen und Erweiterungen können dabei nur Vorgehensbausteine, Projektdurchführungsstrategien, Entscheidungspunkte, Projektmerkmale und Konventionsabbildungen betreffen.

Änderungen, die über diesen Rahmen hinausgehen, wie zum Beispiel Änderungen an den vorliegenden Grundkonzepten des V-Modell XT, fallen in die zweite Stufe des Verfahrens. Derartige Änderungen müssen durch einen gesonderten Review- und Abstimmungsprozess mit den V-Modell-Anwendern im Rahmen eines Fortschreibungsprojektes durchgeführt werden.

Als V-Modell-Anwender werden Personen bezeichnet, die sich mit der Durchführung von V-Modell-Projekten beschäftigen, also in V-Modell-Projekten involviert sind.

Der V-Modell-Kern bildet die Basis jedes Anwendungsprofils. Er legt eine Menge von Vorgehensbausteinen fest, die in jedem V-Modell-konformes Projekt Projekt verwendet werden müssen.

Ein Prozess wird als V-Modell-konform bezeichnet, wenn er bzgl. Beschreibungstechniken, Ergebnissen und Abläufen den Qualitätsansprüchen des V-Modell XT entspricht. Die erwarteten Ergebnisse und die Anforderungen an die Abläufe werden durch das V-Modell XT Referenzmodell bestimmt. Der Nachweis der V-Modell®XT Konformität erfolgt im Rahmen einer V-Modell XT Konformitätsprüfung.

Ein Projekt wird als V-Modell-konform bezeichnet, wenn es mindestens die Vorgehensbausteine und Produkte des V-Modell-Kerns beinhaltet sowie jede relevante Produktabhängigkeit im Rahmen der Entwicklung berücksichtigt.

Unter einem V-Modell-Projekt versteht man ein Projekt, das V-Modell-konformes Projekt durchgeführt wird.

Eine V-Modell-Referenz definiert eine bestimmte Gruppierung der Inhalte des V-Modells. Die Beschreibungen und Beziehungen der einzelnen Produkte, Aktivitäten, Rollen usw. ändern sich nicht. Sie werden jedoch im Rahmen ihrer Abhängigkeiten neu gruppiert und bei Bedarf verkürzt dargestellt. Für verschiedene Anwendungszwecke und Anwender können so angepasste Darstellungen der gleichen Inhalte bereitgestellt werden.

V-Modell-Referenzen werden in der Druckversion des V-Modells in den unterschiedlichen Teilen des V-Modells umgesetzt.

Der Namenszusatz "XT" zu V-Modell steht für "extreme tailoring", oder aber für "extendable".

Das V-Modell XT Assessment überprüft, ob ein V-Modell-konformer Prozess einer Organisation auch wirklich angewendet wird. Es liefert damit den bei einer V-Modell XT Konformitätsprüfung fehlenden Praxisteil. Nach erfolgreichem Abschluss eines Assessments wird das Zertifikat "V-Modell XT Pur" (vgl. Zertifizierungsprogramm) vergeben.

Das Ziel einer V-Modell XT Konformitätsprüfung ist es, die V-Modell®XT Konformität eines vom (Standard-)V-Modell XT abweichenden Prozesses zu überprüfen. Falls der Prozess V-Modell XT konform ist, darf er in Absprache mit dem Auftraggeber an Stelle des V-Modell XT in Projekten eingesetzt werden, in denen V-Modell XT gefordert ist.

Bei der Konformitätsprüfung wird anhand eines Fragenkatalogs überprüft, ob der betrachtete Prozess bzgl. Beschreibungstechniken, Ergebnissen und Abläufen den Qualitätsansprüchen des V-Modell XT entspricht. Die erwarteten Ergebnisse und die Anforderungen an die Abläufe werden durch das V-Modell XT Referenzmodell bestimmt.

Die modulare Einheit des V-Modells. Das V-Modell ist aus Vorgehensbausteinen zusammengesetzt. Auch wird mithilfe von Vorgehensbausteinen ein projektspezifisches oder organisationsspezifisches Vorgehensmodell erstellt.

Ein Vorgehensbaustein fasst unterschiedliche Aktivitätsbausteine zu einer modularen Einheit zusammen. Indirekt sind ihm somit auch Produkte zugeordnet, da diese wiederum eindeutig fortlaufenden Aktivitäten beziehungsweise fertig stellenden Aktivitäten zugeordnet sind.

In der Vorgehensbausteinlandkarte sind die Abhängigkeiten der einzelnen Vorgehensbausteine grafisch visualisiert, um dem Anwender einen schnellen Überblick zu verschaffen.

Das organisationsspezifische Vorgehensmodell dient dazu, ein Verfahren zur Prozessverbesserung in einer Organisation einzuführen, zu etablieren und kontinuierlich zu verbessern. Das hier definierte Vorgehen wird in zwei Einsatzfällen angewandt:

• Bei der erstmaligen Einführung organisationsweiter Prozessbeschreibungen und deren Umsetzung.
• Bei der wiederholten Durchführung eines organisationsweiten Prozessverbesserungsprogramms.

Grundlage für den kontinuierlichen Verbesserungsprozess ist das V-Modell mit all seinen Teilprozessen, Produkten und Aktivitäten. Im Rahmen der Einführung eines organisationsspezifischen Vorgehensmodells kann das V-Modell an die Organisation angepasst und auch durch organisationseigene Prozesse ergänzt werden. Welche Einheiten dabei zur Organisation gehören, muss am Anfang des Verbesserungsprojekts festgelegt werden.

Definiert einen Produktzustand eines Produkts, das zur Prüfung durch unabhängige Qualitätssicherung vorgelegt wird. Je nach Ergebnis der Prüfung wird der nachfolgende Produktzustand in der Produktbibliothek gesetzt.

Bei großen Projekten wird oft vor der eigentlichen Projektdurchführung eine Projektvorstudie durchgeführt, die ggf. so umfangreich sein kann, dass sie selbst im Rahmen eines Projekts durchgeführt wird. Dieses vorgeschaltete Vorstudien-Projekt wird oft auch einfach als Vorprojekt bezeichnet.

Der Weit e.V. ist ein eingetragener Verein, dessen Hauptanliegen die Pflege und Weiterentwicklung des V-Modells ist. Der Weit e.V. ist direkt aus dem V-Modell XT Entwicklungsprojekt "Weit" hervorgegangen und 2008 gegründet worden. In diesem Verein sind Vertreter der Behörden, der Industrie sowie der Hochschulen vertreten.

siehe V-Modell, weiterentwickeltes.

Eine Werkzeugreferenz beschreibt eine Klasse von Werkzeugen, die zur Durchführung von Aktivitäten beziehungsweise Erstellung von Produkte verwendet werden können.