Leitfaden.architekturentwicklung.in.Der.industrie

Architekturentwicklung in der wehrtechnischen Industrie

� Impressum

Herausgeber: BITKOMBundesverband Informationswirtschaft,Telekommunikation und neue Medien e. V.Albrechtstraße 10 A10117 Berlin-MitteTel.: 030.27576-0Fax: 030.27576-400bitkom@bitkom.orgwww.bitkom.org

ZVEIZentralverband Elektrotechnik- und Elektronikindustrie e.V.Lyoner Straße 960528 Frankfurt am MainTel.: 069.6302-0zvei@zvei.orgwww.zvei.org

Ansprechpartner: Michael Barth (BITKOM) Tel.: 030.27576-102 m.barth@bitkom.org

Friedrich W. Benz (ZVEI)Tel.: 069.6302-242benz@zvei.org

Redaktion: Christoph Reich (ESG Consulting GmbH), Oliver Burghardt (CSC Deutschland Solutions GmbH)

Redaktionsassistenz: Juliane Kukla (BITKOM)

Gestaltung / Layout: Design Bureau kokliko / Anna Müller-Rosenberger (BITKOM)

Copyright: BITKOM/ZVEI Dezember 2009

Diese Publikation stellt eine allgemeine unverbindliche Information dar. Die Inhalte spiegeln die Auffassung im BITKOM und ZVEI zum Zeit punkt der Veröf-fentlichung wider. Obwohl die Informationen mit größtmöglicher Sorgfalt erstellt wurden, besteht kein Anspruch auf sachliche Richtigkeit, Vollständigkeit und/oder Aktualität, insbesondere kann diese Publikation nicht den besonderen Umständen des Einzelfalles Rechnung tragen. Eine Verwendung liegt daher in der eigenen Verantwortung des Lesers. Jegliche Haftung wird ausgeschlossen. Alle Rechte, auch der auszugsweisen Vervielfältigung, liegen beim BITKOM und ZVEI.

Inhaltsverzeichnis

1 Einleitung 31.1 Zielsetzung 31.2 Hintergrund 31.3 Zusammenfassung 41.4 Ausblick 4

2 Glossar 53 Vorgaben und Randbedingungen der Bundeswehr 6

3.1 Teilkonzeption Führungsunterstützung und IT-System Bundeswehr 63.2 Customer Product Management (CPM) 83.3 V-Modell 173.4 NATO Architecture Framework 233.5 Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw 283.6 Existierende Konventionen der Bundeswehr 293.7 IT-Sicherheit 33

4 Notwendigkeiten und Randbedingungen der Auftragnehmerseite im Verteidigungsbereich 344.1 Anforderungsmodellierung & Interessengruppen 344.2 Nutzung und Vergleichbarkeit von Architekturen 374.3 Unterschiedliche Ausprägungen von Architekturen 394.4 Auswahl von Design- und Entwicklungsmethoden 404.5 Migration von Legacy-Systemen 444.6 IT-Sicherheit 50

5 Erarbeitung von IT-Architekturen 535.1 Architektur-Vorbereitung 535.2 Architektur-Entwicklung 605.3 Architektur-Anwendung 675.4 Architektur-Publikation 75

6 Architektur-Management 776.1 Management Grundlagen 776.2 Architektur-Anforderungsmanagement 796.3 Architektur-Konfigurationsmanagement 806.4 Architektur-Qualitätsmanagement 806.5 Architektur Änderungsmanagement 916.6 Architektur Sicherheitsmanagement 92

7 Referenz- und Quellenverzeichnis 94

1 Einleitung

� 1.1 Zielsetzung

Der Leitfaden hat den verbesserten Informationsaus-tausch zum Thema IT-Architekturen zwischen der Bun-deswehr als Auftraggeber und der im wehrtechnischen Umfeld tätigen Industrie als Auftragnehmer zum Ziel. Daher soll er

� eine gemeinsame Wissensbasis für Architekturent-wicklungen bilden,

� die Vorgaben und Randbedingungen der Bundeswehr reflektieren,

� die Notwendigkeiten und Randbedingungen der wehrtechnischen Industrie aufzeigen;

� Wege zur gemeinsamen Erarbeitung von IT-Architek-turen vorschlagen sowie

� Möglichkeiten zum Architektur-Management aufzeigen.

Diese Ziele können durch strukturierte Zusammenar-beit und intensiven Informationsaustausch zwischen der Arbeitsgruppe (AG) Architektur des Bundesamts für Informationsmanagement und Informationstechnik der Bundeswehr (IT-AmtBw) und dem gemeinsamen Arbeitskreis (AK) IT-Architekturen des ZVEI und des BIT-KOM erreicht werden. Dabei soll der Leitfaden evolutionär entwickelt und in entsprechenden Versionen publiziert werden. Die Ziele sind erreicht, wenn Architekturen von Seiten des Auftraggebers ausgeschrieben, von Seiten des Auftragnehmers anhand des Leitfadens entwickelt und vom öffentlichen Auftraggeber umgesetzt werden.

� 1.2 Hintergrund

Die Bundeswehr führt seit Jahren zahlreiche Projekte unterschiedlichen Umfangs (Studien, F&T-Projekte, Systemintegrations- und -entwicklungsprojekte usw.) durch, die in entscheidendem Maße durch IT-Architektu-ren bestimmt werden. Hierbei werden unterschiedliche Anwendungsbereiche, z.B. die Erfassung der operationel-len-, system- und technischen Anforderungen im Rahmen

des CPMs oder die Integration von Führungsinformations-systemen in eine Systemlandschaft abgedeckt, die ver-schiedenartige Architekturtypen zum Ergebnis haben. Bei der Realisierung der Projekte auf Auftragnehmerseite ist wiederum eine Vielzahl unterschiedlicher Unternehmen involviert. Zudem steht zur Erstellung von IT-Architektu-ren eine große Bandbreite von Rahmenwerken (z.B. NAF, MODAF, TOGAF, eTOM u.w.), Notationen (UML, SysML, IDEF u.w.) und Werkzeugen (ARIS, Rational System Architect, ISIE u.w.) zur Verfügung.

Ferner sind Anforderungen an die Interoperabilität von Systemen, die sich aus den heutigen Einsatzerfordernis-sen, insbesondere Einsätze im internationalen Umfeld ergeben, durch Vorgaben der NATO oder EU geprägt und müssen berücksichtigt werden. Die oben aufge-führten Aspekte beleuchten nur einen Teil der Auftrag-geber-Auftragnehmer-Schnittstelle im Themenbereich IT-Architekturen.

Durch die Vielschichtigkeit und die zahlreichen Einfluss-faktoren im Zusammenhang mit der Entwicklung von IT-Architekturen hat sich die Notwendigkeit ergeben, sowohl auf Auftraggeber- als auch auf Auftragnehmer-seite ein gemeinsames Verständnis herzustellen und gemeinsam abgestimmte Richtlinien für die Planung, Erstellung und das Management von IT-Architekturen herauszugeben.

Die Bundeswehr hat hierzu die AG Architekturen mit Vertretern aller Organisationsbereiche eingerichtet und in einem ersten Schritt die Rahmenregelung erarbei-tet. Industrieseitig hat sich in den Verbänden BITKOM und ZVEI der gemeinsame AK IT-Architekturen mit der Thematik befasst und den vorliegenden Leitfaden erstellt. Beide Gremien verfolgen das Ziel, durch enge Zusammen-arbeit und Informationsaustausch die Voraussetzungen dafür zu schaffen, dass der Auftraggeber klare Vorgaben (z. B. zu operationellen Sichten) erstellt, die dann durch die Auftragnehmer in die relevanten, projektspezifischen Architekturen umgesetzt werden.

� 1.3 Zusammenfassung

Der vorliegende Leitfaden in der Version 1.0 bietet eine erste praktische Hilfestellung und Wissensbasis für die Planung, Durchführung und Abwicklung von IT-Archi-tekturen sowohl für die Auftraggeber- als auch für die Auftragnehmerseite.

Die Erfahrung und das Wissen der beteiligten Firmen, die auf zahlreichen IT-Architekturprojekten basieren, wurden zusammengefasst, diskutiert und in konsolidierter Form als Leitfaden herausgegeben. Dabei wurde der gesamte Lifecycle von IT-Architekturen umfassend berücksichtigt, ausgehend von den Randbedingungen der Bundeswehr und der Industrie über die Entwicklung von IT-Architektu-ren bis hin zu den Managementaufgaben wie z.B.

� Qualitätsmanagement, � Konfigurationsmanagement, � Änderungsmanagement � Anforderungsmanagement � Rollenmanagement

Vielfach werden die ausgeführten Themenfelder durch anschauliche Beispiele verdeutlicht. Des Weiteren werden zahlreiche Hinweise auf Standards und industrieseitige Rahmenwerke oder Vorgehensmodelle gegeben, die bei der Entwicklung von IT-Architekturen berücksichtigt werden sollten.

Der Leitfaden bietet somit eine solide Grundlage für den Weg zu einem gemeinsamen Verständnis für die Entwick-lung von IT-Architekturen, der insgesamt zu verbesser-ten Ausschreibungen und Abwicklungen von Projekten sowohl auf Auftraggeber- als auch auf Auftragnehmer-seite führen kann.

� 1.4 Ausblick

Es wurden bereits jetzt folgende Themenfelder identifi-ziert, die in der nächsten Version des Leitfadens behandelt und ergänzt werden sollen:

� Abschätzen des Aufwandes � Identifikation und Priorisierung von

Modellierungsbereichen � Weitere Aspekte der Modellierung � Referenzarchitekturen und Brüche bei

Architekturwechseln

Zudem werden durch die geplanten Aktivitäten auf Auftrageberseite, wie u.a. die Neuerstellung eines Archi-tekturhandbuchs in acht Bänden, die Randbedingungen (siehe Kap.3) modifiziert.

Eine enge Zusammenarbeit des industrieseitigen Arbeits-kreises mit der AG Architektur hat das Ziel, die Weiterent-wicklung und das Wissen in der Thematik IT-Architektu-ren auszutauschen. Sie bildet die Grundlage, relevante neue Erkenntnisse in den Leitfaden einzuspeisen.

2 Glossar

Begriff Erläuterung

Architektur „The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. [IEEE 1471].

Qualität „The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations. [IEEE 610].

Tailoring Zurechtschneiden, den Anforderungen entsprechend konfigurieren, zumeist gebraucht im Zusam-menhang mit Vorgehensmodellen.

Testen Entsprechend des ISTQB-Standards wird unter Testen eine Menge von Testfällen und deren Abarbei-tung verstanden.

Validierung Gemäß der ISO 9000:2005, Abschnitt 3.8.5, ist "Validierung" die Bestätigung durch objektiven Nach-weis, dass die Anforderungen für eine bestimmte Anwendung oder einen bestimmten Gebrauch erfüllt sind.

Verifizierung Die DIN EN ISO 8402 vom August 1995, Ziffer 2.17 versteht unter Verifizierung das „Bestätigen auf Grund einer Untersuchung und durch Bereitstellung eines Nachweises, dass festgelegte Forderun-gen erfüllt worden sind.“

3 Vorgaben und Randbedingungen der Bundeswehr

� 3.1 Teilkonzeption Führungsunter-stützung und IT-System Bundeswehr

3.1.1 Hintergrund und Zielsetzung

Die Teilkonzeption Führungsunterstützung Bundeswehr und IT-System Bundeswehr (TK FüUstgBw und IT-SysBw) vom 8.8.2006 bildet die konzeptionelle Handlungs-grundlage für die Bedarfsermittlung und die Planung im Rahmen der Aufgaben der Führungsunterstützung Bundeswehr (FüUstgBw) sowie für die personelle, orga-nisatorische, infrastrukturelle und materielle Ausgestal-tung des IT-System Bundeswehr (IT-SysBw). Sie regelt die Zuständigkeiten und Verantwortlichkeiten bzw. schreibt diese fort. Die TK identifiziert und beschreibt wesentliche Elemente der IT-Strategie der Bundeswehr in Einklang mit der militärischen Ausrichtung der Streitkräfte, die in der Konzeption der Bundeswehr (KdB) vom 9.8.2004 formu-liert wurden.

Abbildung 3.1-1: Fähigkeitskategorien der Bundeswehr gemäß KdB

Die Gesamtheit der in der KdB beschriebenen Fähig-keitskategorien ist so auszugestalten, dass schritt-weise und abgestuft die Befähigung zur vernetzten

Operationsführung (NetOpFü) erlangt wird. Dabei kommt der Führungsunterstützung (FüUstg) bei der Erlangung einer effektiven Führungsfähigkeit eine besondere Bedeu-tung und Verantwortung zu. Führungsunterstützung umfasst das Informationsmanagement, die Informations-versorgung und die Sicherheit in der Informationstechnik (IT-Sicherheit).

Abbildung 3.1-2: Prinzipskizze IT-System der Bundeswehr, Quelle: BMVg, IT-Direktor

Die KdB überträgt in diesem Zusammenhang aus-drücklich dem IT-System der Bundeswehr (IT-SysBw) die Gesamtverantwortung zur Schaffung der notwendigen informationstechnischen Voraussetzungen. Damit hat das IT-SysBw strategische Bedeutung.

Als unmittelbares Folgedokument der KdB identifiziert und beschreibt die TK FüUstgBw & IT-SysBw zudem wesentliche Vorgaben und Rahmenbedingungen für die Umsetzung der Führungsunterstützung im IT-SysBw, die für diesen Leitfaden von besonderer Bedeutung sind und in nachfolgenden Kapiteln näher beschrieben werden:

� Architekturen bzw. architekturbasierte Vorgehensweise

Fähigkeitskategorien

Überlebens-fähigkeit und

Schutz

Mobilität

Führungs-unterstützung

Nachrichten-gewinnung und

Aufklärung

Unterstützungund Durchhalte-

fähigkeit

Wirksamkeitim Einsatz

Einsatzbetrieb auf Basis NetOpFü

Grundbetriebund FüUstg imHeimatland

� Interoperabilität � Qualitätsmanagement

3.1.2 Architekturen

Die TK nimmt eine Definition des Themenkomplexes Architektur vor und stellt die besondere Relevanz für die Bundeswehr dar.

„In der Informatik wird das Zusammenwirken der einzel-nen Elemente komplexer Systeme durch Architekturen beschrieben. Architekturen, als eine formale, international standardisierte Methode ermöglichen der Bundeswehr eine detaillierte vergleichende Darstellung, Analyse und Beurteilung funktionaler operationeller Forderungen und technischer Fähigkeiten. Architekturmodellierung auf der Basis eines festgelegten Architekturrahmenwerkes dient dem Zweck, bei der Realisierung von komplexen IT-Systemanteilen größtmögliche Interoperabilität und Effizienz zu erzielen.“ (TK FüUstg & IT-SysBw, S. 19)

Architektur wird darin als eine methodische Vorgehens-weise definiert und festgeschrieben. Gleichzeitig werden die Begriffe der „Methode Architektur“ oder „Architektur-methode“ geprägt, die inzwischen zunehmend angewen-det werden.

Leider ist diese Definition im Hinblick auf die Differenzie-rung von Ergebnistypen, Produkten und Vorgehensweise (Methodik) etwas unscharf und entfernt sich diesbezüg-lich von gängigen Definitionen in der zivilen Industrie. Dies kann somit leicht zu Missverständnissen führen.

An dieser Stelle erfolgt daher eine entsprechende Diffe-renzierung zur Klärung des Sachverhalts. Die Anwendung einer Vorgehensweise oder Methodik („Wie“, „Wer“, „Womit“, „Wann“) führt zu einem oder mehreren Ergebni-stypen („Was“). Ein Ergebnistyp kann dabei die technische Beschreibung der Architektur oder die Liste sämtlicher fachlicher oder technischer Anforderungen des zugrunde-liegenden Systems bzw. Objekts sein.

Die Aufgabe der Vorgehensweise / Methodik ist es sicherzustellen, dass die Ergebnistypen mit einer größt-möglichen Effizienz, in einer bestmöglichen Qualität von den dafür zuständigen Personen erstellt werden. Sie stellt zudem sicher, dass keine relevanten Ergebnistypen vergessen werden.

Aus dieser Darstellung ist zu erkennen, dass Architektur an sich somit nicht einmal ein individueller Ergebnistyp ist, sondern sich nur in einem System oder Objekt bzw. einer geeigneten Beschreibung ausdrückt.

In Analogie zur Gebäude-Architektur ist die zugrundelie-gende Architektur des Gebäudes am Objekt selbst oder an dem Bauplan erkennbar. Beides sind Ergebnistypen. Die Vorgehensweise und Methodik bestimmt erst, dass z.B. ein Bauplan durch den Architekten und / oder den Bauingenieur erstellt werden muss.

Daraus ist abzuleiten, dass für die Bundeswehr die „Methode Architektur“ nicht nur darin bestehen kann, Ergebnistypen zu haben und „anzuwenden“. Es ist viel-mehr mindestens ebenso wichtig eindeutig zu beschrei-ben, wie diese Ergebnistypen von wem und wann zu benutzen sind.

Die verwendete Definition des Begriffs „Architektur“ in dieser TK orientiert sich zunächst an Vorgaben aus der Informationstechnologie (IT). Tatsächlich ist diese Defini-tion aber weitergehender gefasst und schließt operatio-nelle Architekturen oder gar Unternehmensarchitekturen mit ein.

Dies ist konform zu entsprechenden Ansätzen der Indus-trie, die den Begriff „Architektur“ aus mehreren, teilweise sehr unterschiedlichen Aspekten heraus betrachtet, z.B.:

� Unternehmensarchitektur (englisch „Enterprise Architecture“) Sie beschreiben die strategische Ausrichtung und Aufbau eines Unternehmens bzw. einer Organisation in Bezug auf die „Geschäftsfelder“.

� Operationelle Architekturen Diese werden im zivilen Umfeld oft auch als

“Facharchitekturen” (engl. „Business Architecture“) bezeichnet. Im militärischen Kontext werden hier die konkreten oder abstrakten Einsatzsituationen und deren organisatorische, fachliche und ggf. auch technische Umsetzung betrachtet. Dabei bleibt die technische Betrachtung aber auf einem recht hohen Abstraktionsniveau und beschreibt primär ein „Sys-tem of Systems“.

� IT-Architektur (engl. “IT Architecture”) Damit werden allgemein Lösungsarchitekturen innerhalb von IT-Systemen beschrieben. Dieser Begriff wiederum besitzt vielschichtige Konkretisierungen in Abhängigkeit der technischen Aspekte, z.B. Hardware, Software, Infrastruktur.

Diese grundsätzliche Festschreibung von architekturba-sierten Ansätzen bzw. einer entsprechenden methodi-schen Vorgehensweise bringt eine Reihe notwendiger Fragestellungen sowie den Bedarf zusätzlicher, konkreter Vorgaben in diesem Zusammenhang mit sich. Dazu wird ausdrücklich auf die existierenden Vorgehensweisen der NATO1 und anderer militärischer Partner2 verwiesen, die als konzeptionelle Grundlage für weitere Vorgaben genutzt werden.

Zudem werden zwei Folgedokumente dieser TK definiert, mit denen die Erarbeitung, Darstellung und Pflege von Architekturen für das IT-SysBw verbindlich geregelt wer-den sollen:

� Architekturrahmenwerk IT-SysBw � Architekturerarbeitung und -bearbeitung IT-SysBw

3.1.3 Interoperabilität

Im Kontext von NetOpFü wird Interoperabilität als eine entscheidende, umfassende Teilfähigkeit identifiziert, die im Grundsatz zunächst nicht auf IT-Systeme beschränkt ist.

„Interoperabilität bezeichnet die Fähigkeit, in Synergie in der Erfüllung von zugeteilten Aufgaben zu operieren.“ (TK FüUstgBw & IT-SysBw, Seite 18)

Die Fähigkeit zur Interoperabilität ist eine zwingende Vor-aussetzung eines durchgängigen IT-SysBw. Dabei ist diese Durchgängigkeit wiederum eine Grundvoraussetzung für die Erlangung der Fähigkeit zur vernetzten Operations-führung. Mit einem ganzheitlichen, architekturbasierten Ansatz kann die geforderte Durchgängigkeit im IT-SysBw erzielt werden, was damit einen Schlüssel zum Erfolg bei der Befähigung zu NetOpFü darstellt.

Die TK stellt insbesondere fest, dass die erforderliche Fähigkeit zur Interoperabilität einen fortwährenden Management-Prozess verlangt und nur durch die Festle-gung und Einhaltung sowohl ziviler als auch militärischer Standards zu erreichen ist.

Eine mittel- und langfristig erfolgreiche Architekturme-thode muss diesen Aspekten angemessen Rechnung tragen.

3.1.4 Qualitätsmanagement

Die Aufgaben und Möglichkeiten des Qualitätsmanage-ment werden detailliert im Punkt 6.4. erläutert.

� 3.2 Customer Product Management (CPM)

Der CPM (Customer Product Management) enthält die Verfahrensbestimmungen für die Bedarfsermittlung und die Bedarfsdeckung in der Bundeswehr. Das Ziel des durch den CPM bestimmten Verfahrensablaufs besteht in der zeitgerechten, wirtschaftlichen und einsatzreifen Bereitstellung von Produkten und Dienstleistungen

1. NATO Architecture Framework (NAF)2. z. B. USA: DODAF (Department of Defence Architecture Framework), UK: MODAF (Ministry of Defence Architec-ture Framework)

zur Erlangung und Erhaltung notwendiger Fähigkei-ten der Bw. Hierbei sind Leistungen, Zeit und Kosten als Ganzes zu betrachten. Damit die Einsatzfähigkeit des Gesamtsystems Bundeswehr gewährleistet wird, haben streitkräftegemeinsame Lösungen Vorrang vor Teillösungen und Systembeschaffungen Vorrang vor Komponentenbeschaffungen.

3.2.1 Beziehungen zwischen dem CPM und Architekturen

Die Bundeswehr sieht sich auf Grund ihres erweiterten Einsatzspektrums, des Einsatzes auftragsspezifisch auf-gestellter Kräfteansätze, der regelmäßigen Einbindung dieser Kräfte in truppengattungs-, teilstreitkrafts- und nationenübergreifenden Strukturen sowie der angestreb-ten bzw. optimierten Fähigkeit zur vernetzten Operati-onsführung (NetOpFü) einem wesentlichen Komplexi-tätszuwachs hinsichtlich der Planung und Durchführung militärischer Einsätze gegenübergestellt. Diese erhöhte Komplexität hat Auswirkungen auf die Bedarfsermittlung und die Bedarfsdeckung in der Bundeswehr.

Architekturen stellen eine Abstraktion der Realität dar und unterstützen bzw. vereinfachen dadurch das Ana-lysieren und Managen komplexer Sachverhalte. Die Vorgabe standardisierter Architekturdarstellungen bzw. -modelle fördert eine gemeinsame Sprache zwischen den unterschiedlichen Bearbeitern und Nutzern von Archi-tekturen. Eine durch standardisierte Architekturmodelle unterstützte gemeinsame Vorstellung über vorhandene Fähigkeiten oder vorliegende Fähigkeitslücken, Lösungs-möglichkeiten sowie den operativen und technischen Rahmenbedingungen, denen sich die zu beschaffenden Produkte oder Dienstleistungen anpassen müssen, ist eine Notwendigkeit im Planungsprozess zwischen Bedarfsträ-ger, Bedarfsdecker und der gewerblicher Wirtschaft.

Insbesondere unter dem Gesichtspunkt NetOpFü ist eine umfassende und eindeutige Beschreibung der operati-ven und technischen Vorgaben für die Herstellung der

erforderlichen Interoperabilität zwischen Sensoren, Füh-rungsinformations- und Kommunikationssystemen sowie Effektoren unabdingbar.

Das Beispiel Luftnahunterstützung (Close Air Support, CAS) soll die Komplexitäts- und Interoperabilitätspro-blematik verdeutlichen. Im Rahmen von CAS wirken Teileinheiten der Luftstreitkräfte eng mit Teileinheiten der Landstreitkräfte zusammen. Hierbei ist die Kommunika-tion teilstreitkraftübergreifend zwischen landbasierten Kräften untereinander (der Fliegerleitoffizier/Forward Air Controller mit dem Bataillonskommandeur und mit dem Luftwaffenverbindungsoffizier/Air Liaison Officer), zwischen landbasierten und luftbasierten Kräften (der Forward Air Controller und der Air Liaison Officer mit dem/den Piloten) sowie zwischen luftbasierten Kräften untereinander (den Piloten) erforderlich, die über VHF- und UHF-Funk erfolgt. Neben Sprachfunk (i.d.R. forma-tierten Funksprüchen) wird bzw. könnte auch Datenfunk (z.B. für die Zieldaten) angewendet werden. Die Zielerfas-sung, Ermittlung der Zieldaten und deren Übermittlung an das Luftfahrzeug sowie ggf. die (teil-)automatisierte Einspeisung der Zieldaten in das Waffensystem sind durch verfügbare Produkte unterstützbar. Werden zusätzlich die Inhalte und die Struktur bzw. Formate der auszu-tauschenden Informationen bzw. Daten berücksichtigt zeigt sich deutlich, wie komplex eine solche Einsatzart ist und welche Herausforderungen an die Interoperabilität bei Durchführung auftreten. Und hierbei ist weder das Problem der Freund-Feind-Kennung, der Abstimmung mit anderen militärischen Kräften, z.B. mit der Artillerie, (Ver-meidung von Ausfällen durch eigenen Beschuss/ Friendly Fire) sowie das enge Zeitfenster, das in der Regel für die Durchführung solcher Einsätze zur Verfügung steht, in die Betrachtung mit einbezogen.

Ein solches Szenar ist ohne geeignete visuelle Darstellung in Form von standardisierten Architekturmodellen in seiner Komplexität sehr schwer versteh-, analysier- und kommunizierbar. Das hat entsprechende Auswirkungen auf die erreichbare Qualität bei der Bedarfsermittlung und der Bedarfsdeckung.

Eine optimierte Zusammenarbeit zwischen Bedarfsträger und Bedarfsdecker sowie zwischen Auftraggeber und Auftragnehmer, die zu effektiven und effizienten Lösungen in Form von Produkten und/oder Dienstleistungen führen soll, erfordert insofern:

� das Wissen und das gemeinsame Verständnis über die operativen und technischen Rahmenbedingungen bzw. Vorgaben, in die die Produkte und/oder Dienst-leistungen integriert bzw. angepasst werden müssen, die eindeutige Kommunikation dieser operativen und technischen Rahmenbedingungen bzw. Vorgaben sowie

� die Kenntnis über die finanziellen und zeitlichen Aspekte von Projekten unter Berücksichtigung von Abhängigkeiten mit anderen Projekten oder Programmen.

Daher ist eine Ergänzung von Phasendokumenten mit Architekturdarstellungen bzw. -modellen (d. h. die Detail-sichten/ Sub Views) ggf. unterschieden nach verbindli-chen oder obligatorischen Bestandteilen dieser Phasendo-kumente anzustreben. Hierfür liefert beispielsweise das Architekturrahmenwerk NAF Unterstützung, indem es Detailsichten/ Sub Views auf Interessengruppen (Com-munities of Interest, CoI) abbildet, d.h., für jede Detailsicht angibt, welche Interessengruppe (u.a. Fähigkeitsmanage-ment, Beschaffungsmanagement und Hersteller) durch sie unterstützt wird.

Der CPM unterstützt die frühzeitige Berücksichtigung der durch die gewerbliche Wirtschaft hervorgebrachten Innovationen, was auch gerade die Informations- und Kommunikationstechnologie über Jahrzehnte geprägt hat. Aber auch innovative Technologien müssen möglichst nahtlos mit etablierten Technologien zusammenwirken, da ein regelmäßiger und durch Innovationen getriebener Neuansatz für sämtliche, vor allem auch im Rahmen von NetOpFü, zusammenwirkenden Informationsverarbei-tungs- und Kommunikationssystemen, wirtschaftlich und zeitlich nicht realisierbar ist. Hier benötigt die gewerbli-che Wirtschaft verbindliche, aber auch verständliche und kommunizierbare Vorgaben, die geeignet sind, Produkte

und Dienstleistungen passgenau anzubieten oder herzustellen. Die Verwendung von Architekturen ist ein wesentlicher Schritt in diese Richtung.

3.2.2 Der Verfahrensablauf nach dem CPM

Der CPM unterteilt das Verfahren der Bedarfsermittlung und Bedarfsdeckung in die vier zeitlich aufeinander folgenden Phasen: Analyse-, Projektierungs-, Einführungs- und Nutzungsphase. Die Projektierungsphase kann in Abhängigkeit vom Realisierungsrisiko übersprungen wer-den. Sie ist aber grundsätzlich bei der Realisierung neuer Produkte zu durchlaufen. Die Einführungs- und Nutzungs-phase können sich zeitlich überlappen. Einerseits können mit Vorliegen der Stufenentscheidung „Genehmigung zur Nutzung (GeNu)“ Produkte schon in den Verantwor-tungsbereich des Nutzers übergeben bzw. übernommen werden. Andererseits endet die Einführungsphase aber erst nach Auslieferung des letzen Stücks bzw. Projektan-teils mit dem Phasendokument „Abschlussbericht (ASB)“.

Die einzelnen Phasen des CPM werden mit Phasendo-kumenten abgeschlossen. Diese enthalten sämtliche Forderungen und Vorgaben für die jeweils nachfolgende Phase. Sie sind zugleich haushaltsbegründende Unter-lagen für die in der nachfolgenden Phase erforderlichen Haushaltsmittel.

� Die „Abschließende funktionale Forderung (AF)“ been-det die Analysephase und legt den Lösungsweg fest.

� Die „Abschließende funktionale Forderung/Realisie-rungsgenehmigung (AF/ReG)“ beendet die Analy-sephase, wenn die Projektierungsphase auf Grund beherrschbaren Realisierungsrisikos entfallen kann.

� Die „Realisierungsgenehmigung (ReG)“ beendet die Projektierungsphase.

� Der „Abschlussbericht (ASB)“ beendet die Einführungsphase.

Von den Phasendokumenten zu unterscheiden sind die Stufenentscheidungen. Dieses sind durch den CPM vor-

geschriebene Entscheidungen innerhalb einer Phase. Der CPM unterscheidet:

� Die „Systemfähigkeitsforderung (SFF)“ in der Ana-lysephase. Sie stellt fest und dokumentiert eine zu schließende Fähigkeitslücke. Die SFF darf keine konkrete technische Lösung vorschreiben und muss Innovationen zulassen.

� Die „Genehmigung zur Nutzung (GeNu)“ in der Einführungsphase. Sie kann bei der Beschaffung unveränderter, verfügbarer Produkte schon in der Analysephase als Bestandteil der AF/ReG eingebracht werden.

Wenn Erkenntnisse vorliegen, dass das Phasenziel nicht erreicht werden kann oder zu ändern ist, so sind ggf. Zwischenentscheidungen herbeizuführen. Diese können das Projekt in vorangegangene Phasen zurückverweisen oder aber das Projekt als Ganzes abbrechen.

Der wesentliche Zusammenhang zwischen den zu durchlaufenden Phasen sowie die zu erstellenden Phasen-dokumente und Stufenentscheidungen in Abhängigkeit von der materiellen Lösung (neue Produkte, verfügbare Produkte oder Dienstleistungen) zum Schließen von Fähigkeitslücken und dem Risiko zur Realisierung der Lösung sind in der nachfolgenden Abbildung dargestellt.

BedarfsermittlungNutzung

Bedarfsdeckung

AF AF /ReG

ASBReG

Phasendokumente

Stufenentscheidungen

Analysephase Projektierungsphase Einführungs-phase

Nutzungsphase2 1111 2 2 333

Phasen, Phasendokumente und Stufenentscheidungen:

bei Realisierung neuer Produkte

1 bei beherrschbarem Realisierungsrisiko und bei Dienstleistungen

2 bei Beschaffung unveränderter verfügbarer Produkte

Abbildung 3.2-1: Phasen, Phasendokumente und Stufenentscheidungen im CPM

Lösungsmöglichkeiten zum Schließen von Fähigkeits-lücken sind aber nicht nur in der Planungskategorie Rüstung (materielle Lösung) zu untersuchen, sondern auch in den Planungskategorien: Organisation, Personal, Betrieb und Infrastruktur. Maßnahmen der Bedarfsermitt-lung und Bedarfsdeckung entsprechend des CPM werden erforderlich, wenn eine materielle Lösung zur Schließung der Fähigkeitslücke angestrebt wird, die Lösung also der Planungskategorie Rüstung zuzuordnen ist.

Im CPM werden des Weiteren bestimmten Dienstposten-inhabern und Managementträgern spezifische Verant-wortlichkeiten und Zuständigkeiten sowie Mitwirkungs-, Beteiligungs- und Vertretungsrechte im Rahmen des Verfahrensablaufs zugewiesen. Darunter zählen der Generalinspekteur (GenInsp), der Hauptabteilungsleiter Rüstung (HAL Rü), die Inspekteure (Insp), der Abtei-lungsleiter Wehrverwaltung (AL WV), der IT-Direktor, der Abteilungsleiter Haushalt (AL H), die Projektleiter (PL), die Bevollmächtigten Vertreter des Materialverantwortlichen (BV MatV), die Nutzungsleiter (NL) und die Bevollmächtig-ten Vertreter des Bedarfsdeckers (BV BD). Arbeiten können auch an nachgeordnete Bereiche delegiert werden, um entsprechende Zu- und Mitarbeiten zu leisten. Auch wird an verschiedenen Stellen des CPM auf die Beiträge der gewerblichen Wirtschaft im Rahmen der Bedarfsermitt-lung und Bedarfsdeckung ausdrücklich hingewiesen.

Die Analysephase

In der Analysephase werden auf Grundlage konzeptionel-ler Vorgaben sowie Erfahrungen aus Einsatz und Betrieb Fähigkeitslücken festgestellt und Lösungsmöglichkeiten in den Planungskategorien „Organisation“, „Personal“, „Rüstung“, „Betrieb“ und „Infrastruktur“ untersucht. Ist die Fähigkeitslücke durch Umsetzen einer materiellen Lösung (Bereitstellung von Produkten oder Dienstleistun-gen) in der Planungskategorie Rüstung zu schließen, dann ist sie in der SFF zu beschreiben und der Lösungsweg festzulegen. Die Umsetzung von Lösungsmöglichkeiten in den anderen Planungskategorien ist nach den Regeln der Geschäftsordnung BMVg (GO-BMVg) zu veranlassen.

Mögliche Lösungswege zum Schließen der Fähigkeitslü-cken auf Grundlage der SFF sind:

� Verbesserung eingeführter Produkte, � Einführung von verfügbaren Produkten, � Realisierung neuer Produkte oder � Inanspruchnahme von Dienstleistungen.

Es ist der Lösungsweg auszuwählen, der unter funktiona-len, zeitlichen und wirtschaftlichen Gesichtspunkten die beste Alternative darstellt. Hierbei ist zu entscheiden, ob bewusst geringere Leistungen gefordert werden oder ob auf Detailforderungen verzichtet werden kann. Der aus-gewählte Lösungsweg wird am Ende der Analysephase mit dem Phasendokument AF festgelegt. Bei beherrsch-barem Realisierungsrisiko und bei Dienstleistungen wird zeitgleich mit der AF auch die ReG in dem Phasendoku-ment AF/ReG erteilt. Sollen verfügbare Produkte unverän-dert beschafft werden, dann schließt die AF/ReG auch die Stufenentscheidung GeNu mit ein.

Der GenInsp trägt die Verantwortung für die Fähigkeits-analyse, die Schwerpunktsetzung, die Weiterentwicklung der Bundeswehr, die daraus abgeleitete Bedarfsermitt-lung sowie für die Einsatzfähigkeit der Streitkräfte. Hier-bei nutzt er die „Integrierte Arbeitsgruppen Fähigkeits-analyse (IAGFA)“. Diese sind im BMVg angesiedelt und setzen sich zusammen aus den Bevollmächtigten Vertre-tern (BV) des/der GenInsp, HAL Rü, Insp, AL WV, IT-Direktor sowie, in begleitender Funktion, AL H. Die Aufgaben der IAGFA umfassen im Rahmen der Bedarfsermittlung u.a. den ständigen Abgleich vorhandener mit erforderlichen Fähigkeiten der Bw, das Feststellen des Bedarfs sowie die Erarbeitung bzw. das Veranlassen der Stufenentscheidung SFF und des Phasendokuments AF bzw. AF/ReG. Über die Bedarfsermittlung hinaus beinhalten die Aufgaben der IAGFA u.a. das Prüfen der Erfüllung der Leistung unter Leistungs-, Zeit- und Kostengesichtpunkten sowie, soweit nicht delegiert, das Prüfen sonstiger Phasendokumente, Stufen- und Zwischenentscheidungen und das Herbeifüh-ren der Unterzeichnung.

Projektierungsphase

In Abhängigkeit vom Realisierungsrisiko bei der Umset-zung des festgelegten Lösungsweges und grundsätzlich bei neuen Produkten folgt der Analysephase die Projek-tierungsphase. Sie entfällt, wenn das Realisierungsrisiko oder der Aufwand für die Vorbereitung der Realisierung einen unmittelbaren Eintritt in die Einführungsphase zulässt, oder wenn auf andere Weise das Realisierungsri-siko beherrscht werden kann, z.B. mit einem schrittweisen Vorgehen durch die Einführung verfügbarer Produkte oder bei der Inanspruchnahme von Dienstleitungen.

Die Projektierungsphase dient der systematischen Begrenzung des Realisierungsrisikos hinsichtlich Leistung, Zeit und Kosten und endet mit dem Phasendokument ReG. In dieser Phase ist nachzuweisen, dass Produkte zur Erfüllung der funktionalen Forderung herstellbar sind. Die Leistungsfähigkeit der vorgeschlagenen Lösungen ist zu demonstrieren (u.a. durch den Bau und das Testen von Demonstratoren).

Im Rahmen der Projektierungsphase wird ein Lastenheft erarbeitet, mit dem die funktionalen Forderungen der AF in technisch-funktionale Leistungswerte umgesetzt wer-den. Dieses Lastenheft ist die Grundlage für die durch die gewerbliche Wirtschaft vorzuschlagenden Lösungen und enthält auch Kriterien zur Beurteilung der Herstellbarkeit und Leistungsfähigkeit des herzustellenden Produktes.

Verantwortlich für die Projektrealisierung im vorgesehe-nen Leistungs-, Zeit- und Kostenrahmen sind in der Pro-jektierungs- und Einführungsphase die Projektleiter (PL).

Einführungsphase

Die Einführungsphase umfasst sämtliche Maßnahmen zur Herstellung neuer Produkte sowie zur Beschaffung verfügbarer oder zur Verbesserung eingeführter Produkte und Dienstleistungen. Ziel dieser Phase ist es, geeignete Produkte oder Dienstleistungen dem Nutzer bedarfs- und

zeitgerecht zur Verfügung zu stellen. Die Eignung der Produkte oder Dienstleistungen wird hierbei gemessen an den funktionalen Forderungen der AF und ReG bzw. AF/ReG, den betrieblichen Erfordernissen und den militäri-schen Erfordernissen im Systemverbund. Sie wird durch Leistungsnachweise des Auftragnehmers, Einsatzprüfung und die Ermittlung weiterer Betriebsparameter und Funk-tionsgrenzen festgestellt.

Der vom Auftragnehmer zu erbringende und für die Abnahme eines Produktes erforderliche Leistungsnach-weis umfasst den Nachweis der Erfüllung der vertrags-konformen Leistung einschließlich der Erfüllung recht-licher Auflagen und der technischen Sicherheit für den Betrieb. Amtseitig erfolgt ergänzend zum Leistungsnach-weis durch den Bedarfsdecker, Materialverantwortlichen und Nutzer die Überprüfung der Eignung des Produktes für den vorgesehenen Verwendungszweck unter einsatz-nahen Bedingungen (Einsatzprüfung).

Die Einsatzprüfung wird, insbesondere bzgl. der einsatz-wichtigen Funktionen, grundsätzlich im Rahmen der integrierten Nachweisführung, unter Berücksichtigung der Projektelemente3 und unter einsatznahen Bedingun-gen durchgeführt. Integrierte Nachweisführung bedeutet hierbei die örtliche, zeitliche oder inhaltliche Zusam-menlegung von Leistungsnachweis des Auftragnehmers, Einsatzprüfung und Betriebstests oder gemeinsame Durchführung entsprechender Prüfungen/Tests zur Fest-stellung der Eignung eines Produktes.

Erkenntnisse aus der Einsatzprüfung sind in den laufen-den Fertigungsprozess einzubringen und bei der Beauftra-gung weiterer Lieferungen zu berücksichtigen. Produkte, die bereits in Nutzung sind, müssen ggf. entsprechend nachgerüstet werden. Ergibt sich aus der Einsatzprü-fung Anpassungsbedarf mit finanziellen und zeitlichen Auswirkungen auf die Realisierung des Produktes oder ist die Eignung des Produktes fraglich, so ist eine Zwischen-entscheidung, in schwerwiegenden Fällen eine Entschei-dung über den Projektabbruch, herbeizuführen. Sofern

3 Projektelement sind die Bearbeitungsbereiche eines Projekts und umfassen: Technische und wirtschaftliche An-teile, Führung/Einsatz, Organisation, Perso-nal/Ausbildung, Logistik, Infrastrukturmaßnahmen, Arbeitssicherheit, IT-Sicherheit, militärische Sicherheit, Verkehrssicherheit, Ergonomie, Geoinformati-onswesen der Bw sowie Umweltschutz.

vorhandene Erkenntnisse über die Verwendungsfähigkeit verfügbarer Produkte für die Beurteilung ausreichen, sind für diese keine eigenen Prüfungen durchzuführen. Im Rahmen der Einsatzprüfung werden auch weitere Betriebsparameter und Funktionsgrenzen ermittelt, die auf die effiziente und wirtschaftliche Nutzung des Pro-dukts zielen.

Auf Grundlage der Ergebnisse der integrierten Nachweis-führung wird die Stufenentscheidung GeNu getroffen, in der festgestellt wird, dass

� die Leistungsfähigkeit entsprechend den Vorgaben der AF und ReG bzw. AF/ReG gegeben ist,

� die Eignung für den vorgesehenen Verwendungs-zweck gegeben ist,

� die sichere Inbetriebnahme unter Berücksichtigung der geltenden rechtlichen Auflagen erfolgen kann,

� die Einsatzreife hergestellt ist und � die Bereitschaft des Nutzers zur Übernahme besteht.

Die GeNu ist Voraussetzung für die Beauftragung wei-terer Lose und ggf. nachfolgender Realisierungsschritte sowie für die Übergabe bzw. Übernahme in die Nutzung. Mit Übernahme geht das Produkt in den Verantwor-tungsbereich des Nutzers über. Die Verantwortung des PL bis zum Abschluss der Einführungsphase, insbesondere für den Abschluss aller Maßnahmen zur Herstellung der Einsatzreife, bleibt hiervon unberührt.

Sofern die erforderlichen Voraussetzungen für die Nutzung oder Teilnutzung von Produkten oder Dienstleis-tungen erfüllt sind, kann die Stufenentscheidung GeNu während der Einführungsphase herbeigeführt werden und die Produkte oder Dienstleistungen an den Nutzer übergeben werden.

Die Einführungsphase endet nach Abschluss sämtlicher Realisierungsmaßnahmen mit dem ASB. Dieses Phasen-dokument wird vom Leiter des zuständigen Amtes des Bedarfsdeckers und dem Leiter des zuständigen Kdo/Amtes des Materialverantwortlichen unterzeichnet und schlussgezeichnet vom PL der IAGFA zur Kenntnis vorge-legt. Mit Herausgabe des ASB endet die Realisierungsver-antwortung des PL.

Nutzungsphase

Die Nutzungsphase beginnt mit der Übernahme des ers-ten Stücks und endet mit der Aussonderung des letzten Stücks. Da einerseits die Stufenentscheidung GeNu schon während der Einführungsphase herbeigeführt werden kann, bei der Beschaffung unveränderter verfügbarer Pro-dukte schon nach der Analysephase als Bestandteil des Phasendokuments AR/ReG, und die Produkte oder Dienst-leistungen bereits dann an den Nutzer übergeben werden können, aber andererseits die Einführungsphase erst nach Abschluss sämtlicher Realisierungsmaßnahmen mit dem ASB endet, können sich Einführungs- und Nutzungsphase zeitlich überlappen.

Die Maßnahmen in der Nutzungsphase dienen der Erhaltung der Einsatzreife und dem sicheren Betrieb unter einsatzorientierten Bedingungen bis zur Aussonderung. Insbesondere nachfolgende Maßnahmen fallen in der Nutzung an:

� Erfassen und Auswerten von Erkenntnissen aus Übun-gen und Einsätzen;

� Erfassen und Auswerten von Betriebsdaten und Störungsmeldungen;

� bedarfsgerechtes Anpassen/Festlegen von Vorga-ben für die Ersatzteil-Bewirtschaftung sowie für Instandhaltung und Fertigung auf der Grundlage von Klarstandsfestlegungen;

� Durchführen von Produkterhaltungsmaßnahmen; � Veranlassen von Nachbeschaffungen, Ersatzbeschaf-

fungen und Ergänzungsbeschaffungen.

Während der Nutzungsphase können Produktände-rungen, Ersatzbeschaffungen, Produktverbesserungen, Verlängerung des Nutzungszeitraumes sowie Betreu-ungsleistungen der gewerblichen Wirtschaft oder des Rüstungsbereichs erforderlich werden.

Änderungen eingeführter Produkte und Ersatzbeschaf-fungen sind nur zulässig zum Erhalt oder zur Wiederher-stellung der Einsatzreife sowie zur Rationalisierung im Betrieb. Die Problemstellungen, die einer vorgesehenen Änderung zugrunde liegen sowie die erforderlichen

Maßnahmen sind in einem Lastenheft funktional zu beschreiben.

Werden für die Vorbereitung von Änderungsmaßnah-men Mittel für Entwicklungstechnische Betreuung (ETB) benötigt, so hat der NL diesen Bedarf einschließlich der technisch/wirtschaftlichen Bewertung des BV BD mit der Änderungsforderung (ÄF) zu dokumentieren. Die ÄF ist Voraussetzung für die Bereitstellung von Haushalts-mitteln zur Untersuchung möglicher Alternativen nach Nutzen, Kosten und Risiken. Die ÄF enthält das Lastenheft als Bestandteil.

Eine ÄF ist nicht erforderlich, wenn die vorzunehmende Änderung eindeutig ist und mit beherrschter Technologie unkritisch durchführbar ist. Dann kann mit der Erstellung der Änderungsgenehmigung (ÄG) unmittelbar die Reali-sierung der Änderungsmaßnahme eingeleitet werden.

Ist die Änderungsmaßnahme nicht eindeutig, dann sind durch den BV BD auf Grundlage des Lastenheftes Lösungsvorschläge der gewerblichen Wirtschaft und ggf. des Rüstungsbereichs einzuholen und zu bewerten. Die potentiellen Auftragnehmer haben die Realisierbarkeit ihrer Lösungsvorschläge und die zu erwartende Erfüllung der funktionalen Forderungen darzustellen. Die Auswahl der technischen Lösung ist gestützt auf einer umfassen-den Risikoanalyse und Wirtschaftlichkeitsuntersuchung zu treffen und mit der ÄG zu dokumentieren. Sofern vorliegende Erkenntnisse es erlauben, kann die Genehmi-gung zur Nutzung zusammen mit der Änderungsgeneh-migung erteilt werden (ÄG mit GeNu).

Ersatzbeschaffungen werden vom NL über den BV BD unter Beachtung der Grundsätze der Wirtschaftlichkeit veranlasst. Sofern kein geeignetes Produkt am Markt verfügbar ist, bringt der NL eine Initiative zur Schließung der entstehenden Lücke in die zuständige IAGFA ein.

Initiativen zur Produktverbesserung bzw. zur Verlänge-rung des Nutzungszeitraumes werden vom NL in die zuständige IAGFA eingebracht. Vorgehensweise und Ver-

antwortlichkeiten richten sich nach den Bestimmungen zur Bedarfsermittlung und Bedarfsdeckung (s.o.).

Betreuungsleistungen der gewerblichen Wirtschaft oder des Rüstungsbereiches sind entweder Leistungen im Rahmen der Technisch-Logistischen Betreuung (TLB) oder der Entwicklungstechnischen Betreuung (ETB).

Leistungen der TLB umfassen die Erfassung, die Auswer-tung und die Bereitstellung produktbezogener Informa-tionen im Rahmen der Nutzungssteuerung. Das Erfassen, Planen und Überwachen von TLB-Leistungen liegt in der Zuständigkeit des NL und wird aus Materialerhaltungs- titeln finanziert.

Leistungen der ETB sind als Entscheidungsgrundlage für die Änderung von Produkten erforderlich. Sie werden nach Zustimmung durch den Materialverantwortli-chen oder auf dessen Forderung durch die gewerbliche Wirtschaft ggf. durch den Rüstungsbereich erbracht. Sie umfassen den eine Änderung vorbereitenden technischen Aufwand und schließen den Aufwand für Software und Dokumentation mit ein.

Die Vergabe von Betreuungsleistungen an die gewerbli-che Wirtschaft erfolgt grundsätzlich im Wettbewerb und auf Grundlage der VOL und durch den BV BD.

3.2.3 Schrittweises Vorgehen

Als schrittweises Vorgehen wird ein Vorgehen bezeichnet, bei dem Anteile eines Projektes (nach vollständiger Aus-planung des gesamten Projektes) einzeln, zeitlich versetzt oder auch parallel zu anderen Teilen realisiert werden. Die einzelnen Teile müssen dabei für den vorgesehenen Verwendungszweck geeignet und für sich einsatzreif sein. Die Aufteilung des Projekts kann erfolgen hinsichtlich der Leistung, der Bedarfszahlen oder auch bzgl. ausgewählter Nutzer.

Schrittweises Vorgehen ist sinnvoll um das Realisierungs-risiko von Projekten zu reduzieren oder (Teil-)Fähigkeiten

frühzeitig dem Nutzer bereitzustellen. Es kann in jeder Phase ausgeplant und mit einem Phasendokument bzw. einer Zwischenentscheidung entschieden werden. Die einzelnen Projektanteile sind dabei wie eigen-ständige Projekte zu behandeln und untereinander zu koordinieren.

3.2.4 Grundsätze der Wirtschaftlichkeit

Ein wesentlicher Aspekt des CPM ist seine Ausrichtung an den Grundsätzen der Wirtschaftlichkeit. Die Grundsätze der Wirtschaftlichkeit bestimmen den gesamten Verfah-rensablauf. Ihre Beachtung ist insbesondere sicherzustel-len durch:

� das Straffen von Entscheidungsgängen und Verfahrensabläufen;

� das Reduzieren des Verwaltungsaufwandes auf das unabdingbar Notwendige;

� die vertragliche Vereinbarung von Regelungen für ein wirksames amtseitiges Controlling und die Mitwir-kung des Auftraggebers;

� das abschließende Formulieren von unabdingbaren Forderungen, deren Erfüllung zum Zeitpunkt ihrer Billigung gesichert im vorgegebenen Leistungs-, Zeit- und Kostenrahmen realisierbar sein müssen;

� die Vermeidung von Änderungen der Forderungen während ihrer Umsetzung;

� das Minimieren des Realisierungsrisikos durch Marktsichtung, Untersuchungen, Studien und/oder Simulationen;

� den Nachweis der Herstellbarkeit (z.B. durch Demonstratoren);

� die Sicherstellung vor Vertragsabschluss, dass der Auftragnehmer über die erforderlichen Technologien, Kenntnisse und Fertigkeiten verfügt, um die gefor-derte Leistung im vorgesehenen Zeit- und Kostenrah-men zu erbringen;

� das Abstützen auf die gewerbliche Wirtschaft im rechtlich zulässigen Rahmen durch frühzeitiges Einbeziehen ihrer Kenntnisse und Fertigkeiten, ihr eigenverantwortliches Umsetzen von funktionalen

Forderungen sowie die Nutzung von Möglichkeiten zur dauerhaften Fremdvergabe oder zur Kooperation;

� die vorrangige Verwendung von verfügbaren Produk-ten und von Dienstleistungen;

� den grundsätzlichen Verzicht auf die Anwendung Bw-interner Bauvorschriften, Normen und Prüfanweisun-gen innerhalb des rechtlich zulässigen Rahmens;

� das ganzheitliche Planen von Aktivitäten unter Berücksichtigung von Systemzusammenhängen sowie

� die Durchführung von Wirtschaftlichkeitsuntersu-chungen mit dem Ziel der Minimierung der Lebens-wegkosten (LCC: Life Cycle Costs).

3.2.5 Die Mitwirkung der gewerblichen Wirtschaft im Rahmen des CPM

Der CPM weist der gewerblichen Wirtschaft auf Grund ihrer hohen Innovationsgeschwindigkeit eine technolo-gische Schrittmacherfunktion zu. Eine enge Zusammen-arbeit zwischen der Bundeswehr und der gewerblichen Wirtschaft wird daher als unerlässlich für die Erhaltung moderner und leistungsfähiger Streitkräfte angesehen.

Damit ein frühzeitiges Abstützen auf die gewerbliche Wirtschaft gewährleist ist, wird sie unter Berücksich-tigung militärischer Sicherheitsaspekte im erforderli-chen Umfang und im rechtlich zulässigen Rahmen vom Hauptabteilungsleiter Rüstung (HAL Rü), IT-Direktor und vom Abteilungsleiter Wehrverwaltung (AL WV), als Träger der ministeriellen Verantwortung für ihren jeweiligen Aufgabenbereich, über festgestellte Fähigkeitslücken informiert.

Wird die gewerbliche Wirtschaft in der Analysephase bei der Bedarfsermittlung durch den BV HAL Rü bzw. BV IT-Direktor oder BV AL WV eingebunden, so haben diese sicherzustellen, dass den beteiligten Unternehmen daraus keine Wettbewerb verzerrenden Vorteile erwachsen, um dem vergaberechtlichen Neutralitätsgebot des Auftragge-bers zu entsprechen.

Des Weiteren erfolgt die Unterstützung der Bundeswehr durch die gewerbliche Wirtschaft im Rahmen von Entwick-lungs- und Betreuungsleistungen.

� Entwicklungsleistungen können während des gesam-ten Verfahrensablaufs erforderlich sein und umfassen Forschungen, Studien/Analysen, Neuentwicklungen, Herstellung von Demonstratoren/Mustern und deren Untersuchungen, Nachweis der Herstellbarkeit sowie Serien-/Produktreifmachung. Während der Nutzungs-phase können Entwicklungsleistungen zum Erhalt der Einsatzreife im Rahmen der Änderung eingeführter Produkte und Dienstleistungen notwendig werden.

� Betreuungsleistungen dienen dem Erhalt und der Sicherstellung der Einsatzreife von Produkten. Sie wer-den durch den Bevollmächtigten Vertreter Bedarfs-decker (BV BD) auf Grundlage der VOL grundsätzlich im Wettbewerb vergeben. Sie umfassen Technisch-Logistische Betreuung (TLB), Entwicklungstechnische Betreuung (ETB) und Produktverbesserung/Verlänge-rung des Nutzungszeitraums.

Voraussetzung für Vertragsabschlüsse mit der gewerbli-chen Wirtschaft in der Realisierung und Nutzung ist die Sicherstellung, dass sie über die erforderlichen Technolo-gien, Kenntnisse und Fertigkeiten verfügt, um die gefor-derte Leistung im vorgesehenen Zeit- und Kostenrahmen zu erbringen.

� 3.3 V-Modell

Im Prozess des Customer Product Managements regelt das V-Modell die projektspezifischen Inhalte der Pro-jektierungsphase, die der abschließenden funktionalen

Forderung/Realisierungsgenehmigung (AF/ReG) folgt. Nach Abnahme der Leistungen des Projektes folgt im CPM die Einführungsphase.

Das V-Modell stellt ein Vorgehensmodell zum Planen und Durchführen von Projekten insbesondere im Bereich von IT-Systemen dar. Es regelt die Projektdefinition und Projektausschreibung, die Systemerstellung mit Unter-stützungssystemen und plant die Logistik, den Betrieb und die Außerbetriebnahme des Systems, definiert die damit verbundenen Aktivitäten (Tätigkeiten), die Verant-wortlichkeiten (Rollen) und die entstehenden Produkte (Ergebnisse). Das V-Modell regelt verbindlich, wer, wann, was in einem Projekt zu tun hat.

Das V-Modell XT regelt die Zusammenarbeit zwischen AG und AN. Es sieht zwei Aktivitätsstränge, mit Unterauftrag-nehmern sogar drei Stränge, vor. Einige Produkte wech-seln zwischen diesen Strängen und bilden somit einen Übergang im Sinne einer Zusammenarbeit.

3.3.1 Übersicht des Inhalts des V-Modells XT

Das V-Modell XT ist gegliedert in die Themen Projektma-nagement, Konfigurationsmanagement, Qualitätssiche-rung, Problem- und Änderungsmanagement und Syste-merstellung. Jedes dieser Themen beinhaltet eine Reihe von Vorgehensbausteinen, die in der folgenden Abbildung dargestellt sind:

Abbildung 3.3-2: Vorgehensbausteinkarte

Die Produkte des V-Modells XT sind den Vorgehensbau-steinen zugeordnet. Vorgehensbausteine können wiede-rum von anderen Vorgehensbausteinen abhängen. Die Vorgehensbausteine sind folgendermaßen aufgebaut:

Abbildung 3.3-3: Aufbau eines Vorgehensbausteins

Jeder Vorgehensbaustein hat ein Produkt als Resultat. Aktivitäten und Rollen mit Verantwortlichkeiten und Zuarbeiten sind Teile des jeweiligen Vorgehensbausteins. In der folgenden Abbildung ist die Einbettung des Vorge-hensbaustein in das Gesamtmodell gezeigt.

Weiterentwicklung undMigration von Altsystemen

Benutzbarkeitund Ergonomie Systemsicherheit

Einführung undPflege einesorganisations-spezifischenVorgenhens-modells

KaufmännischesProjektmanagement

Messungund Analyse

Projekt-management

Konfigurations-management

Qualitäts-sicherung

Problem- und Änderungs-management

Logistik-konzeption

Vertrags-schluss (AN)

Lieferung undAbnahme (AN)

System-erstellung

Anforderungs-festlegung

Lieferung undAbnahme (AG)

Vertrags-schluss (AG)

Multiprojekt-management

Evaluierung vonFertigprodukten

SW-Entwicklung

HW-Entwicklung

Aktivität

beinhaltet untergeordneteAktivität

beinhaltet untergeordneteProdukte

Produkt

hat Abhängigikeitenzu anderen

bearbeitet verantwortlich Rolle

1 11 1

Abbildung 3.3-4: Vorgehensbausteinübergreifende Strukturierung

Basierend auf den Vorgehensbausteinen definiert eine Projektdurchführungsstrategie die Reihenfolge von sog. Entscheidungspunkten (engl. Quality Gates). Um diese Entscheidungspunkte zu erreichen, muss eine definierte Menge von Produkten in definierten Zuständen vorliegen.

Abbildung 3.3-5: Projektdurchführungsstrategien und Entscheidungs-punkte

Im Projektplan definiert ein Entscheidungspunkt zu einem festgelegten Zeitpunkt eine „Fortschrittsentschei-dung“ (GO/NOGO).

Mit diesem Aufbau ist die zentrale Philosophie des V-Modells XT eine ziel- und ergebnisorientierte Vorge-hensweise. Produkte stehen im Mittelpunkt, sie sind die Projektergebnisse. Projektdurchführungsstrategien und Entscheidungspunkte geben die Reihenfolge der

Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor. Die detaillierte Projekt-planung und -steuerung wird auf der Basis der Bearbei-tung und Fertigstellung von Produkten durchgeführt. Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person. Die Produktqualität ist überprüfbar durch definierte Anforde-rungen an das Produkt und explizite Beschreibungen der

Abhängigkeiten zu anderen Produkten.

Die Vorgehensbausteine sind die modularen Einheiten für das Tailoring. Das Tailoring wird im V-Modell XT durch das Werkzeug „Projektassistent“ unterstützt und weitestge-hend automatisiert. Zu diesem Zweck sind einige typische Projektprofile definiert, aus denen ausgewählt werden kann.

Bei der Erstellung einer Architektur muss der ausge-wählte Projekttyp, die in den folgenden Kapiteln darge-stellten Aktivitäten und Produkte zur Erstellung einer

Produktgruppe

Produkt

Thema Thema Thema

Aktivitätsgruppe

Aktivität

Teilaktivität

Aktivität

verantwortlich

mitwirkend

bearbeiten

erzeugt

ProduktProjektdurchführungs-

strategie benötigtEntscheidungs-

punkt1...* 1...* 1...*legt Reinfolge fest

[im Zustand „fertig gestellt“]

Architektur beinhalten. Dazu kommen alle Varianten der Systementwicklungsprojekte in Frage aber nicht der Typ „Einführung und Pflege eines organisationsspezifischen Vorgehensmodells“.

Die Projektmerkmale unterscheiden wiederum den Projektgegenstand und die Projektrolle (des Projektes). Mögliche Projektgegenstände für eine Architekturerstel-lung sind:

� Eingebettetes System (System, das über Sensoren und Effektoren mit seiner physischen Umgebung interagiert),

� HW-System, � Komplexes System (besteht im Allg. aus Hardware,

Software und eingebetteten Komponenten), � SW-System, � Systemintegration (Integration bereits existierender,

noch zu entwickelnder oder auszuwählenden Einhei-ten zu einem System),

Aber eher nicht: � Einführung und Pflege eines organisationsspezifi-

schen Vorgehensmodells.

Das Projektmerkmal „agiles Projektvorgehen“ ist ein zusätzlich wählbares Merkmal. Im V-Modell XT bedeutet es nicht, dass das Projektvorgehen nach agilen Grund-sätzen – kleine zeitlich sehr häufige Iterationen – durch-geführt wird, sondern dass frühzeitig ein Prototyp zur Risikobegrenzung und Evaluierung der Lösung oder von (Technologie-) Ansätzen erstellt wird. Bei Architekturent-wicklungen mit hohem Anteil von neuen Technologien oder Architekturen, die so noch nie durchgeführt wurden, empfiehlt sich dieses Vorgehen.

3.3.2 Aktivitäten zur Erstellung einer Architektur

Das V-Modell XT ist ein produktzentriertes Vorgehensmo-dell. Nichtsdestotrotz sind Aktivitäten definiert, die das Vorgehen im Projekt beschreiben.

Neben den durchgängigen Aktivitäten des Auftrag-nehmers mit Planung und Steuerung (Projektleitung), Angebots- und Vertragswesen, Berichtswesen, Konfi-gurations- und Änderungsmanagement und Prüfung (Qualitätssicherung) sind im folgenden die Aktivitäten der Entwicklung aufgeführt, die für die Erstellung einer Architektur durchgeführt werden müssen.

Die wesentlichen Phasen für die Erstellung einer Architek-tur sind:

� System spezifizieren � System entwerfen � Feinentwurf

Bevor eine Architektur entwickelt und ausgelegt werden kann, müssen die Anforderungen des Auftraggebers, das Altsystem bzw. die wiederzuverwendenden Komponen-ten analysiert und die möglichen neu zu verwendenden Komponenten als Rahmenbedingung einer Architektur betrachtet werden. In der folgenden Tabelle sind die ent-sprechenden Aktivitäten aufgeführt:

Aktivität ErgebnisAnwenderaufgaben analysieren

Anwenderaufgaben-analyse

Gefährdungs- und Systemsicherheitsana-lyse durchführen und bewerten

Gefährdungs- und Systemsicherheitsanalyse

Altsystemanalyse erstellen Altsystemanalyse

Marktsichtung für Fertigprodukte (AN) durchführen

Marktsichtung für Fertig-produkte (AN)

Make-or-Buy-Entschei-dung durchführen

Make-or-Buy-Entscheidung

Tabelle 3.3-1: Aufgaben und Produkte der Analysephase

Nach Analyse der Aufgabe ist ein erstes grobes Lösungs-konzept zu erstellen. Dazu wird auf Basis des Lastenhef-tes des Auftraggebers ein Pflichtenheft erstellt, dass die Interpretation des Auftragnehmers des Lastenheftes in Form einer Anforderungsanalyse enthält.

Wie weit die in der folgenden Tabelle aufgeführten Akti-vitäten durchgeführt werden, hängt von dem Umfang des Auftrags zur Entwicklung einer Architektur ab. Ist eine Systemarchitektur zu erstellen, so sind nur die Produkte Gesamtspezifikation und Systemspezifikation zu erstel-len. Ist auch eine Software- und Hardwarearchitektur verlangt, so sind auch die weiteren Produkte zu erstellen.

Aktivität ErgebnisGesamtsystemspezifi-kation (Pflichtenheft) erstellen

Gesamtspezifikation (Plichtenheft)

Systemspezifikation erstellen

Systemspezifikation

Externe-Einheit-Spezifika-tion erstellen

Externe-Einheit-Spezifi-kation

HW-Spezifikation erstellen HW-Spezifikation

Externes-HW-Modul-Spe-zifikation erstellen

Externes-HW-Modul-Spezifikation

SW-Spezifikation erstellen SW-Spezifikation

Externes-SW-Modul-Spezi-fikation erstellen

Externes-SW-Modul-Spe-zifikation

Tabelle 3.3-2: Aufgaben und Produkte der Systemspezifikation

Wie schon im vorherigen Abschnitt erwähnt, werden für eine Systemarchitektur in dieser Phase nur die Produkte Systemarchitektur und Unterstützungs-Systemarchitek-tur erstellt und bei einer Software- und Hardwarearchi-tektur auch die folgenden Produkte.

Aktivität ErgebnisSystemarchitektur erstellen

Systemarchitektur

Aktivität ErgebnisUnterstützungs-Systemar-chitektur erstellen

Unterstützungs-Systemar-chitektur

Styleguide für die Mensch-Maschine-Schnittstelle erstellen

Mensch-Maschine-Schnittstelle (Styleguide)

HW-Architektur erstellen HW-Architektur

SW-Architektur erstellen SW-Architektur

Datenbankentwurf erstellen4

Datenbankentwurf

Tabelle 3.3-3: Aufgaben und Produkte des Systementwurfs

Die weiteren Aktivitäten der Entwicklung gehören nicht mehr zu einer Architekturentwicklung, sondern sind Teil der Realisierung, Integration und Tests sowie der Inbe-triebnahme und Logistik.

In der vorläufigen „Rahmenregelung zur Nutzung der Methode Architektur in der Bundeswehr“ /8/, erstellt durch das IT-AmtBw A1, wird zwischen aufgabenori-entierten und fähigkeitsorientierten Architekturen unterschieden.

Auf solche Architekturansätze geht das V-Modell XT nicht ein und besitzt auch keine entsprechenden Profile. Diese müssen immer wieder projektspezifisch erarbeitet werden. Gleiches gilt für methodische Ansätze und Vor-gehensweisen insbesondere mit Toolunterstützung und Notationen, wie beispielsweise die UML /7/.

3.3.3 V-Modell-Architekturdokumentation

Das V-Modell XT definiert neben der Realisierung der Lösung eine Reihe von Produkten zur Dokumentation der Projektergebnisse. Diese Dokumentation ist in Form von Vorlagen (Templates) definiert. Das V-Modell XT geht dabei von einer Gliederung der logischen Architektur in Form einer Dekomposition ausgehend vom Gesamtsys-tem, über Teilsysteme, Segmente bis zu Software- und

4 Datenbankentwurf ist auf Systemebene nur bei klassischer Entwicklung oder Client Server Architekturen durch-zuführen. Bei einem Architekturansatz mit Kapselung wie die Service Orientierte Entwicklung (SOA), ist diese im Rahmen der SW-Architektur der SW-Einheiten durchzuführen.

Hardware-Einheiten aus. Entsprechend dieser Gliederung sind die Dokumente zu erstellen. Im Unterschied zur vorhergehenden Version des V-Modells XT werden die Vorlagen der Architekturdokumentation rekursive pro Architekturelement angefertigt. So wird beispielsweise das Dokument „Systemspezifikation“ für das Gesamtsys-tem und jeweils auch für die weiteren untergeordneten Systemteile wie Segmente erstellt.

Für die inhaltliche Dokumentation macht das V-Modell XT keine spezifischen Vorgaben (z.B. Sichten, Notationen, etc.), sondern definiert nur die Themen, die dokumentiert werden sollen.

Nichtsdestotrotz hat sich für die Dokumentation von Architekturen als Standard für die Darstellung der Sichten das „Nato Architecture Framework (NAF)“ /6/, das im fol-genden Kapitel „3.4 NATO Architecture Framework“ näher beschrieben ist, und für technische und System Sichten die „Unified Modelling Language (UML)“ /7/ durchgesetzt.

Die folgende Tabelle zeigt eine empfohlene Zuordnung zwischen den wichtigsten V-Modell- XT-Architekturdoku-menten und den Sichten der NAF in der Version 2:

NAF-View

Titel (NAF) Gesamt- systemspezifikation (Pflichtenheft)

System- spezifikation

System- architektur

NAV-1 Overview and Summary Information Kap. 2.1

NAV-2 Integrated Dictionary

NOV-1 High-Level Operational Concept Diagram Kap. 2.2

NOV-2 Operational Node Connectivity Diagram Kap. 3.5, Kap. 4.1

NOV-3 Operational Information Exchange Requirements (IER) Matrix

Kap. 4.2, Kap. 7.1

NOV-4 Organisation Relationships Chart Kap. 3.1

NOV-5 Operational Activity Models Kap. 3.2

Operational Rules Model Kap. 3.4.1

Operational State Transition Kap. 3.4.2

Operational Event-Trace Kap. 3.4.3

NOV-6 Concept Data Model Kap. 3.3 Kap. 3.1

NSV-1a Systems Interface Description, Internodal Perspective, Edge-to-Node

Kap. 6.2.1 Kap. 2.1

NSV-1b Systems Interface Description, Internodal Perspective, System-to-System

Kap. 2.1 Kap. 2.x

NSV-1c Systems Interface Description, Intranodal Perspective

Kap. 2.1 Kap. 2.x

NSV-1d Systems Interface Description, Intrasystem Perspective

Kap. 5.2 Kap. 2.x

NSV-2 Systems Communications Description Kap. 4.1 Kap. 5.1

NSV-3 System-to-System Matrix (S2 Matrix) Kap. 6.2.2 Kap. 2.2 Kap. 5.2

NSV-4 Systems Functionality Description Kap. 3.2 x

NSV-5 Operational Activity to System Function Tracea-bility Matrix

Kap. 7.1 Kap. 7.1

NSV-6 Systems Information Exchange Matrix Kap. 5.1 Kap. 5.3

NSV-7 System Performance Parameters Matrix Kap. 4.2 Kap. 7.2

NAF-View

Titel (NAF) Gesamt- systemspezifikation (Pflichtenheft)

System- spezifikation

System- architektur

NSV-8 System Evolution Description Kap. 7.3

NSV-9 System Technology Forecast Kap. 7.4

Systems Rules Model Kap. 4.3

Systems State Transition Description Kap. 4.3

Systems Event-Trace Description Kap. 4.3

NSV-10 Physical Data Model Kap. 6.1 Kap. 6.1

NTV-1 System Standards Profile Kap. 2.x

NTV-2 Standards Technology Forecast Kap. 2.x

NTV-3 Technical Configuration Kap. 3.2

NTV-4 Software Configuration Kap. 3.3

NTV-5 Product Selection Report Kap. 3.4

Tabelle 3.3-4: Zuordnung der NAF Sichten zur V-Modell XT Dokumenta-tion

� 3.4 NATO Architecture Framework

3.4.1 Überblick

Hervorgerufen durch die steigende Komplexität von Informations- und Kommunikationssystemen und die Vielfalt der Nutzerperspektiven und den daraus resultie-renden vielfältigen Forderungen entstand die Notwen-digkeit strukturierterer Ansätze, um die Komplexität zu visualisieren und somit besser kommunizieren zu können sowie die Anforderungen strukturiert dokumentieren zu können. Als Folge davon entwickelten sich seit dem Beginn der 90er Jahre Modellierungsverfahren für Sys-teme, um deren Architekturen und Realisierungsansätze vergleichen und bewerten zu können. Rahmenwerke als Grundlage für die Entwicklung von Architekturen (Architecture Frameworks AF) waren und sind das Ergebnis der konsequenten Weiterentwicklung dieser Modellierungsverfahren.

Im Bereich der NATO und insbesondere in Bezug auf die internationalen Missionen ist die Interoperabilität

zwischen den beteiligten Systemen der Partnernationen ein entscheidender Erfolgsfaktor. Da eine Vielzahl von Organisationen (militärische Einheiten, Industrie, For-schungsinstitute, ...) sowohl innerhalb der NATO wie auch auf nationaler Ebene bei der Umsetzung der Konzeption NetOpFü – als nationaler Beitrag zu NNEC – beteiligt sind und sich somit zwangsläufig ein hochkomplexes System of Systems ergibt, ist es zwingend erforderlich, Architekturen und unterstützende Werkzeuge zu nutzen, um einerseits zielführende Diskussionen zwischen den einzelnen Interessenvertretern zu führen und um ande-rerseits sicherzustellen, dass kohärente, konsistente und technisch sinnvolle Entscheidungen getroffen werden.

Um bei der Entwicklung der Architekturen Verwirrungen zu verhindern, wurde von der NATO das NATO Architec-ture Framework (NAF) entwickelt, deren Verwendung eine verbindliche Vorgabe der technischen Architektur der Bundeswehr (TABw) ist und somit die Basis für alle zukünftigen Architekturentwicklungen bilden muss. Das NAF bildet NATO-weit abgestimmte Richtlinien für die Entwicklung und Verwendung von Architekturen inner-halb der NATO sowie die Standardisierung von Architek-turmodellen und Produkten ab. Damit soll erreicht wer-den, dass durch die unterschiedlichen Sichtweisen und Modellierungsschritte die Komplexität besser beherrscht wird. Im Gegensatz zu den Vorgängerversionen berück-sichtigt die Version 3.0 des NAF die Umorientierung in

Richtung eines diensteorientierten und fähigkeitsbasier-ten Paradigmas.

Derzeit wird in der TABw die Version 2 des NAF (NAFv2) genannt, von der NATO ist aber bereits die Version 3 (NAFv3) veröffentlicht, die die Sichten und Teilsichten der Version 2 um weitere Elemente ergänzt. Dem Unterschied zwischen diesen beiden Versionen ist in der NAFv3 ein eigener Anhang gewidmet (Annex C).5

3.4.2 NAF-Historie

In der nachfolgenden Abbildung 3.4-1 sind die wichtigsten Rahmenwerke in einem Zeit-Einsatz-Diagramm eingeord-net, um die zeitliche Abfolge bzw. die Ableitungen und das jeweilige Einsatzgebiet (militärisch, zivil) darzustellen.

Abbildung 3.4-1: Historie von Architektur-Rahmenwerken

Bezogen auf den Verteidigungsbereich bildeten die Architekturrahmenwerke des US-Department of Defense (DoD) – C4ISR / DoD Architecture Framework (DoDAF) – die Ausgangsbasis für die Erarbeitung von weiteren militärisch orientierten Architecture Frameworks. Aus der Endversion des DoDAF, die seit 2003 vorliegt, entstand in Großbritannien bereits 2004 das MoDAF (Ministry of Defence Architectural Framework). Seit 2006 existiert das für die NATO verbindliche Rahmenwerk NAF in der Version 2, dem in 2008 die Version 3 folgte.

Die Version 3, die die Umorientierung in Richtung eines diensteorientierten und fähigkeitsbasierten Paradigmas berücksichtigt, hat inzwischen auch Rückwirkungen auf DoDAF und MoDAF, die nun ihrerseits in neueren Versi-onen diensteorientierte und fähigkeitsbasierte Aspekte aufweisen (DoDAF 1.5 und MoDAF 1.1).

militärischzivil Interesse

EAP1992

Zachman1987

TISAF1997 FEAF

TOGAF1995-2005

TEAF2000

C4ISR1996-7

AGATE2003-5

MODAFSOSAF

2004-6

DODAF2003

NATO2003-6

OMG UPMD2005

5 Quelle der gesamten NAF-Dokumentation: www.nhqc3s.nato.int

Die unterschiedlichen AFs, die in dieser Abbildung referen-ziert sind, werden in einem separaten Band (Annex A/B) der NAF behandelt.

3.4.3 NAF Komponenten

Das NATO Architecture Framework besteht neben einer Executive Summary aus zehn weiteren Bänden:

� Introduction to NATO Architecture Framework � Architecture Stakeholder � NNEC Architecture Concepts and Elements � Architecture Views and Sub Views � NAF Metamodel (NMM) and Architecture Data

Exchange Specification � Management of Architectures in NATO � Architecture Definitions, Terminology and Ontology � Annex A: Architecture Frameworks � Annex B: Architecture Methodologies � Annex C: Transition Guidance NAFv2 to NAFv3

3.4.4 NAF Stakeholder

Dieser Abschnitt in der NAF-Dokumentation behandelt die Stakeholder und die Communities of Interest (CoI), die von der Verwendung der NAF profitieren können. Die Motivation für dieses Kapitel liegt in der Zielsetzung der NAF begründet, sich einerseits an den Zielen und Interes-sen der Nutzergruppen zu orientieren und andererseits ein „Kommunikationsmedium“ bereitzustellen, so dass die Kommunikation zwischen allen Beteiligten auf Auf-traggeberseite wie auf Auftragnehmerseite vereinfacht wird. Die Auftraggeberseite benötigt nachvollziehbare Darstellungen der auftragnehmerseitigen Entwicklungen, um die Erfüllung der Forderungen verfolgen zu können. Andererseits ist für die Auftragnehmerseite ein archi-tektonischer Systemüberblick für die ordnungsgemäße Abwicklung der Entwicklung ein entscheidender Faktor.

Daraus ergibt sich eine „generische“ Gruppe von Stakehol-dern, die sich aus

� Vertretern der Auftraggeberseite wie beispielsweise � Konzeption � Nutzern � Betreibern � Bedarfsdeckern � Wartungspersonal � ...

� sowie Vertretern der Auftragnehmerseite wie beispielsweise � Projektmanagern, � Analysten, � Designern, � Entwicklern, � Integrationspersonal, � Qualitätspersonal � Personal der Inbetriebnahme

zusammensetzt. Diese Liste ist nur ein unvollständiger Vorschlag, der die Heterogenität der Gruppe der Stakehol-der verdeutlichen soll.

Wichtig ist, sämtliche Stakeholder zu Beginn der Archi-tekturarbeiten zu identifizieren und festzulegen. Empfeh-lenswert ist die Einrichtung eines Architekturboards, das sich aus Vertretern der (wichtigsten) Stakeholder-Grup-pierungen zusammensetzt.

Da im NAF die Stakeholder zwar erwähnt sind, aber Akti-vitäten zur Anforderungserhebung, Anforderungsmodel-lierung, Anforderungsverfolgung und weiteren Nutzeras-pekten fehlen, wird an dieser Stelle auf das Kapitel 4.1 in dem vorliegenden Dokument hinsichtlich der „Anforde-rungsmodellierung & Stakeholder“ verwiesen, das genau diesen Aspekt näher beleuchtet.

3.4.5 NAF-Architektur-Konzepte und -Elemente

In diesem Abschnitt des NAF werden Architektur-Kon-zepte und -Elemente definiert, die dann in den Sichten und untergeordneten Sichtweisen verwendet werden können. NAF selbst schreibt zwar keine Methode zur

Erstellung der Sichten und Teilsichten vor, aber durch die Verwendung von festgelegten Elementen in den Sichten unterstützt das Framework bei der Erstellung der Sichten, um kohärente, konsistente und relevante Architektur-produkte zu generieren. Dieses Kapitel beschreibt die grundlegenden NNEC Architektur-Elemente und ihre Beziehungen untereinander.

3.4.6 NAF-Sichten

Als Werkzeugkasten definiert die NAF einen Satz von Sich-ten und korrespondierenden Teilsichten, mit angepassten Diagrammen und Spezifikationen zur Unterstützung der Stakeholder und Communities of Interest. An dieser Stelle werden nur die NAF-Sichten beschrieben, auch wenn, wie sich in dem Kapitel bezüglich der Architekturentwicklung herausstellen wird, dieser Werkzeugkasten nicht ausreicht und zusätzliche Sichten bzw. Teilsichten notwendig und sinnvoll sind. Trotz einzelner noch fehlender Aspekte bietet das NATO Architektur-Rahmenwerk ein flexibles Instrument, das mit der Dynamik des NATO Transforma-tionsprozesses im Hinblick auf operationelle Konzepte, Fähigkeitsplanungen und Diensteorientierung Schritt halten kann. Dies bedeutet, dass die architekturellen Aktivitäten, Methoden und Werkzeuge auf kurzfristige Anforderungen reagieren und mittelfristige Planungspro-zesse unterstützen können, die durch die abgestimmten langfristigen NNEC/NetOpFü-Visionen geleitet werden.

Im NAF erfolgt eine grundlegende Trennung in die drei Sichten „Operational View“, „System View“ und „Techni-cal View“, die bereits aus den Vorgängerversionen bzw. DoDAF/MoDAF übernommen worden sind. Darüber hinaus werden in der Version 3 des NAF noch die „Capa-bility View“, die „Programm View“ und die „Service View“ eingeführt.

� NATO All View: Diese Sichtweise enthält eine kurze einführende Beschreibung der Ziele des Entwicklungs-vorhabens, sowie ein Projekt-Glossar.

� NATO Operational View: Diese Sichtweise beschreibt die Sicht der Nutzer des Systems in Bezug auf die

operationellen Knoten, die Rollen und ihren Aktivitä-ten und die Informationen.

� NATO System View: Abgeleitet aus der operationellen Sicht wird in dieser Sichtweise der konkrete Entwurf der technischen Komponenten zur Umsetzung der operationellen Sichtweise dargestellt. Dabei erfolgt eine Abbildung der operationellen Knoten auf Sys-temknoten, der Rollen auf System, der Aktivitäten auf Funktionen und der Informationen auf Daten.

� NATO Technical View: In dieser Sichtweise werden technische Produkte und Standards festgelegt.

Im NAFv3 sind über die NAFv2 Sichtweisen noch drei wei-tere Sichtweisen definiert worden:

� NATO Capability View: Diese Sichtweise beschreibt die strategische Sicht, um die Entwicklung der Fähigkei-ten zu überwachen und die Ausrüstung zu planen.

� NATO Programme View: Diese Sichtweise dokumen-tiert Programm-Abhängigkeiten, Zeitplanungen und Statusinformationen, um das Programm-Management zu informieren und die Beschaffung zu synchronisieren.

� NATO Service View: Diese Sichtweise dokumentiert die Dienste, ihre Funktionalitäten, ihre Einschränkun-gen und ihre Interoperabilität. Durch diese in NAFv3 zusätzlich eingeführte Sichtweise erfolgt eine Ent-kopplung zwischen der operationellen Sichtweise und der Systemsicht, denn die operationellen Aktivitäten werden nicht mehr direkt Systemfunktionen, sondern Diensten im Sinne einer Serviceorientierung zugeord-net. Dienste sind eine implementierungsunabhängige Repräsentation von Funktionen.

Alle genannten Sichtweisen sind in eine Vielzahl von Teilsichten unterteilt, die der entsprechenden NAF-Doku-mentation zu entnehmen sind.

3.4.7 Meta-Modell & Data Exchange Specification

NAFv3 definiert ein gemeinsames standardisiertes Archi-tektur-Meta-Modell (NMM) und Austauschmechanismen

für Architekturdaten, um den Austausch und die Nutzung von Architekturprodukten zu erleichtern. Basierend auf dem Meta-Modell und den Austauschmechanismen lässt sich eine unabhängige Architektur-Datenbasis erstellen, die der Schlüssel für eine effektive Entwicklung, Nutzung und Wiederverwendung von Architekturprodukten ist. Architekturprodukte, die auf einer konsequenten Anwen-dung von konsistenten Architekturmodellen basieren, können auf einfachste Weise miteinander verbunden werden, um eine integrierte und evolutionäre Beschrei-bung der Entwicklungsfortschritte im Umfeld NetOpFü/NNEC zu erstellen. Die Wiederverwendung von existieren-den Modellen, die evolutionär entstanden sind, können nachfolgende Entwicklungsaktivitäten beschleunigen, um somit operationelle Fähigkeiten in kürzeren Zyklen verfügbar zu machen.

3.4.8 Architekturmanagement in der NATO

Dem Management von Architekturen ist im NAF ein komplettes Kapitel mit dem Titel „General Guidelines for the Management of NAF v3 Architectures in Nations“ gewidmet. Die Ziele des Architektur-Managements sind gemäß Abschnitt 6.A des NAF:

� Die Entwicklung wartbarer Architekturprodukte � Konsistente, kohärente, vollständige und exakte

Architekturprodukte � Bereitstellung der Architekturprodukte für autorisier-

tes Personal � Entwicklung der Architekturprodukte gemäß Stan-

dard (NAF und NMM) � Verfügbarkeit von Kontrollinstanzen, die im Zusam-

menhang mit der Entwicklung, der Nutzung und der Wartung von Architekturprodukten unerwünschte Ereignisse erkennen und korrigieren

� Verfügbarkeit von geeigneten Werkzeugen für die Entwicklung, Nutzung und Wartung von Architekturprodukten

3.4.9 Architekturentwicklung auf der Basis NAF

In dem vorausgegangenen Abschnitt ist bereits mehrfach angedeutet worden, dass das NAF einerseits Architek-turbeschreibungen spezifiziert und auch Unterstützung hinsichtlich der Architektur-Elemente liefert, aber ande-rerseits keinerlei Vorgaben in Bezug auf das Vorgehen bzw. die Reihenfolge der Erstellung der Architekturpro-dukte macht. In /1/ wird eine Bearbeitungsreihenfolge als Graph dargestellt, die in mehreren Entwicklungsprojekten erfolgreich erprobt worden ist. Da zwischen den einzelnen Architekturprodukten des NAF Abhängigkeiten bestehen, die sich in dem Graph widerspiegeln, ergibt sich implizit eine Bearbeitungsreihenfolge.

Wie der Abschnitt 3.3 deutlich zum Ausdruck bringt, ist das V-Modell nach wie vor eine verbindliche Vorgabe für die Systementwicklung im Bereich der Bundeswehr. Es wird daher empfohlen, das Architektur-Rahmenwerk mit dem Vorgehensmodell zu kombinieren bzw. zu integrie-ren, so dass Architekturentwicklungen gemäß V-Modell durchgeführt werden, aber die Aktivitäten und Produkte dem NAF entnommen sind.

Aktivitäten hinsichtlich der Ermittlung von Anforderun-gen fehlen in dem NAF vollständig, so dass für diesen Komplex im Rahmen der Architekturentwicklung zusätzli-che Aktivitäten einzuarbeiten sind.

3.4.10 Tailoring im NAF

Aus den Ausführungen zu Abschnitt 3.4.6 wird deutlich, dass im NAF eine Vielzahl von Sichten und Teilsichten in Form von Aktivitäten und resultierenden Produkten defi-niert sind. Einige davon können als optional angesehen werden, andere wiederum sind zwingend erforderlich. Die endgültige Entscheidung, welche Teilsichten erarbeitet werden und welche nicht weiter betrachtet werden sollen, muss in dem Architekturboard getroffen werden.

� Vorschlag für einen Minimalumfang: � All View 1 (AV1): Beschreibung des Kontextes � All View 2 (AV2): Glossar � Operational View 1 (OV1): Festlegung der organisato-

rischen Einheiten und deren Zusammenwirken (über Informationskanäle).

� Operational View 2 (OV2): Zuordnung von Aktivitäten zu organisatorischen Einheiten und Rollenfestlegung.

� Operational View 3 (OV3): Abbildung von Daten (Inhalte und Strukturen) auf Informationskanäle.

� Operational View 5 (OV5): Beschreibung von Aktivitä-ten und Daten.

� System View 1 (SV1): Abbildung der Rollen/Aktivitäten auf Systemfunktionen und Informationskanäle auf Interfaces.

� Technical View 1 (TV1): Auflistung der in SV1 verwende-ten Produkte und Standards.

� 3.5 Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw

Die vorläufige Rahmenregelung „Architekturer-arbeitung/-bearbeitung IT-SysBw“ (siehe /5/) ist eine wesentliche Grundlage der Bundeswehr für die Architek-turmodellierung im IT-System der Bundeswehr (IT-SysBw). Sie ist ein Folgedokument zur TK FüUstgBw und IT-SysBw (siehe /4/) und orientiert sich an dieser, da diese TK derzeit die maßgebende Vorgabe zur Nutzung der Architektur-methode innerhalb der Bundeswehr darstellt.

„Unter einer Rahmenregelung ist … eine Regelung zu ver-stehen, die die Abläufe und Verfahren zur Modellierung von Architekturen und ihrer weiteren Nutzung, die ver-antwortlichen und die zu beteiligenden Stellen, sowie die jeweils zu erstellenden Architekturprodukte im Grundsatz beschreibt.“ (siehe /5/, Seite 51)

Auf diese Weise definiert sich die Rahmenregelung „Architekturer-/-bearbeitung IT-SysBw“ selbst. Das Ziel der Rahmenregelung ist es somit, im Rahmen von Architekturentwicklungen

� eine gemeinsame Basis für die Arbeit der AG Architek-tur Bundeswehr (AG ArchBw) und der verschiedenen OrgBereiche zu schaffen,

� die Verfahren der Architekturer-/-bearbeitung zwi-schen den OrgBereichen festzulegen,

� die Nutzung gemeinsamer Verfahren sowie � die technischen Grundlagen für die Modellierung

innerhalb und für die Bundeswehr zu regeln.

Damit stellt die vorläufige Rahmenregelungen aber nicht nur eine Handlungsrichtlinie für Stellen innerhalb der Bundeswehr dar, sondern dient auch der beteilig-ten Industrie als Orientierungshilfe über die konkreten Vorstellungen der Bundeswehr bei der Vorgehensweise von Architekturer- bzw. -bearbeitung und somit bei der Durchführung von Architekturentwicklungen im Auftrag oder gemeinsam mit der Bundeswehr.

Sie behandelt u. a. folgende Fragestellungen: � Anwendungsfelder von Architekturen in der

Bundeswehr, � das Architekturmanagement und insbesondere � Grundsätze, Rolle, Abläufe und Vorgehensweisen bei

der Er- / Bearbeitung von Architekturen.

3.5.1 Anwendungsfelder von Architekturen in der Bundeswehr

Seitens der Bundeswehr werden in der vorläufigen Rah-menregelung drei mögliche Anwendungsfälle unterschie-den (siehe /5/, Kapitel 3), in denen Architekturentwicklun-gen zum Einsatz kommen können:

� Unterstützung konzeptioneller Arbeit, � Unterstützung operationeller Planung, � Unterstützung der Bedarfsermittlung und -deckung

nach CPM.

In diesen Anwendungsfällen kommen unterschiedliche Ausprägungen der Architekturtypen (Overarching (OA), Reference (RA), Target (TA) oder Baseline Architecture (BA)) zum Tragen. Während im Rahmen der Unterstüt-zung konzeptioneller Arbeiten die OA und BA entwickelt/

bearbeitet werden, werden bei der Unterstützung der operationellen Planung und der Bedarfsermittlung und -deckung nach CPM RA/TA er-/bearbeitet und BA ggf. ergänzt. Bei der Er-/Bearbeitung von RA oder TA wird zwischen aufgabenorientierten (Unterstützung operatio-neller Planung) und fähigkeitsorientierten Architekturen (CPM-Unterstützung) differenziert.

Diese Ausführungen bieten allen an einer Architekturent-wicklung Beteiligten (Auftraggeber, Auftragnehmer und sonstigen Projektbeteiligten) eine Orientierungshilfe über den erforderlichen Architekturtyp und daraus resultierend letztlich über die erforderliche Vorgehensweise.

3.5.2 Architekturmanagement

Bezüglich des Architekturmanagements beschreibt die Rahmenregelung

� die zugrunde gelegten Grundsätze, � die involvierten Ebenen/Rollen und ihre

Aufgabenschwerpunkte/-ausprägungen sowie � die durchzuführenden Aufgaben

aus Sicht des Auftraggebers Bundeswehr (siehe /5/, Kapi-tel 4 und Anlage 10).

Diese Ausführungen bieten ebenfalls eine Orientierungs-hilfe bzgl. der gewünschten Vorgehensweise für die an einer Architekturentwicklung Beteiligten. Weitere Ausfüh-rungen über Umsetzungsmöglichkeiten sind in Kapitel 6 dargelegt.

3.5.3 Grundsätze, Rollen, Abläufe und Vorgehensweisen bei der Er-/Bearbeitung von Architekturen

Der wesentliche Anteil der Rahmenregelung (siehe /5/, Kapitel 5 und Anlagen 5 – 9) befasst sich mit Grundsätzen, involvierten Rollen sowie Abläufen und Vorgehensweisen bei der Er-/ Bearbeitung der verschiedenen Architektur-typen (OA, RA, TA, BA), die vom Auftraggeber Bundeswehr vorgesehen sind. Insbesondere vorgesehene Abläufe und Vorgehensweisen sowie Aus- und Wechselwirkungen,

z.B. zu Phasen-/Stufendokumenten des CPM, werden in Einzelschritten detailliert beschrieben.

Diese Ausführungen bieten eine Orientierungshilfe und Anleitung für die grundsätzliche Vorgehensweise im Rahmen von Architekturentwicklungen. Sie stellen zudem auch eine Art Checkliste dar, die zum Tailoring eines entsprechenden Projektes und zur Überprüfung der relevanten Schritte und Ergebnisse herangezogen werden können.

� 3.6 Existierende Konventionen der Bundeswehr

3.6.1 Ziel und Zweck von Konventionen

Übergeordnetes Ziel von Konventionen ist, konsolidierte, integrierte und lesbare Architektur zu entwickeln, die sich in eine vorhandene bzw. zu entwickelnde Architekturwelt der Bundeswehr einfügt.

Die zu entwickelnden Artefakte der Architekturen der Bundeswehr müssen nachvollziehbar, lesbar und ver-ständlich strukturiert gestaltet werden, um damit sowohl die Vergleichbarkeit als auch die Wiederverwendbarkeit der Architekturmodelle zu gewährleisten.

Im Sinne der NNEC ist auch davon auszugehen, dass Architekturen durch unterschiedliche Nationen entwi-ckelt werden. Es gilt also auch eine gemeinsame national übergreifende Verständnisbasis für die Darstellung der Architekturen mit unterschiedlichsten Zielsetzungen aufzubauen.

Um diesen Anforderungen gerecht zu werden, sind Vereinbarungen festzulegen, die einen verbindlichen Rahmen für die Erstellung der vorgesehenen Diagramme, Matrizen und Dokumente einer Architektur bereitstellen, ohne dass sie die Handlungsspielräume der Architekten, die sich ggf. aus projektspezifischen Anforderungen erge-ben, unangemessen einschränken.

Es muss der Grundsatz gelten: Konventionen sollten so wenig wie möglich, aber so viel wie nötig verbindlich regeln.

Theoretisches Fundament für die Ausgestaltung von Modellierungskonventionen für Architekturen sind die Grundsätze ordnungsmäßiger Modellierung (GoM). Die GoM stellen ein Hilfsmittel dar, um sicherzustellen, dass die Modellierungsaktivitäten effizient und ausgerichtet an den tatsächlichen Bedürfnissen eines Organisations-projekts durchgeführt werden.

Nachfolgende sechs Grundsätze sind in den GoM ent-halten und müssen in der Entwicklung der Architekturen grundsätzlich berücksichtigt werden:

� Grundsatz der Richtigkeit Bedeutet: Korrekte Wiedergabe des abgebildeten Sachverhaltes (semantisch: beschriebene Struktur/beschriebenes Verhalten, syntaktisch: Einhaltung von Notationsregeln)

� Grundsatz der Relevanz Bedeutet: Dokumentation, der für die jeweilige Perspektive relevanten Sachverhalte, keine Abbildung irrelevanter Informationen

� Grundsatz der Wirtschaftlichkeit Bedeutet: Modellierungsaktivitäten sollen in angemessenem Kosten-Nutzen Verhältnis stehen, Nutzung von Referenzmodellen, Maßnahmen zur Wiederverwendung

� Grundsatz der Klarheit Bedeutet: Strukturiertheit, Übersichtlichkeit, Lesbar-keit (intuitiv)

� Grundsatz der Vergleichbarkeit Bedeutet: modellübergreifend konforme Anwendung der Modellierungsvorgaben, Ziel: Konsolidierung unabhängig voneinander erstellter (Teil-) Modelle

� Grundsatz des systematischen Aufbaus Bedeutet: definierte Schnittstellen zu korrespondie-renden Modellen (z.B. Inputdaten des Prozessmodells / Referenz auf Datenmodell)

Die mit den Grundsätzen verbundenen Zielsetzungen stehen teilweise konträr zueinander. (z.B. der Grund-satz der Wirtschaftlichkeit in Konflikt zur Anwendung

des Grundsatzes der Klarheit). Bei der Entwicklung der Konventionen sind Grundsätze der GoM gegeneinander abzuwägen und zu gewichten.

3.6.2 Sachstand

Zurzeit existieren noch keine einheitlichen und verbindli-chen Konventionen für die Architekturentwicklung in der Bundeswehr.

In der Vorbereitungsphase zur Entwicklung von Architek-turen wurden bisher spezifische Notationen entwickelt, die nur für die zu entwickelnde Architektur zur Anwen-dung kommen. In der folgenden Tabelle wird ein Auszug bereits entwickelter Architekturen und die in der Architek-tur verwendeten Konventionen aufgeführt.

Architektur OrgBereich Verwendete Konventionen

AFüEinsLuSK Luftwaffe Konventionen für die Architektur-entwicklung in der Luftwaffe

AFüEinsSKB SKB Style Guide SKB

RA UAV-IMINT Luftwaffe Konventionen für die RA UAV-IMINT

TA SAATEG Konventionen für Diagramme der Zielarchitektur SAATEG

Tabelle 3.6-1: Architekturkonventionen

Die Gemeinsamkeit dieser Konventionen besteht nur in der Tatsache, dass hinsichtlich der zu modellierenden Artefakte und deren Objekte Vereinbarungen festgelegt wurden, die die Namensvergabe, die Attribute der Objekte und die Gestaltung der Objekte für die Architektur regelt. Inhaltlich unterscheiden sich die Konventionen mas-siv. Die folgende Tabelle verdeutlicht die gravierenden Unterschiede z.B. bei der Namensvergabe am Beispiel des NOV-2 „Operational Node Connectivity Diagram“:

Architektur Namenskonventionen GrundlageRA KuK EU OV-2_[Fachlicher Bezug] Konventionen für die Architektur-

entwicklung in der Luftwaffe

RA KVKB RA_KVKB_OV2_[Level]_[Fachlicher Bezug]6 Style Guide SKB

RA UAV-IMINT RA-IMINT_NOV2[Fachlicher Teil]_[OpNodes] oder RA-IMINT_NOV2[Fachlicher Teil]_[OpNode]_Activity

Konventionen für die RA UAV-IMINT

TA SAATEG TA-SAATEG_NOV2[Fachlicher Teil]_[OpNode]_Intrano-dal_Activity oder TA-SAATEG_NOV2[Fachlicher Teil]_[OpNode]_Intranodal_Internodal

Konventionen für Diagramme der Zielarchitektur SAATEG

RA ObjS RA_ObjS_OV2_Mod07_[Fachlicher Bezug] Style Guide SKB und Konventionen für die Architekturentwicklung in der Luftwaffe

Tabelle 3.6-2: Namenskonventionen

Die Tabelle verdeutlicht, dass an dem Beispiel der Bezeich-nung der Modelle der Anspruch der Wiederverwendbar-keit, Vergleichbarkeit und Klarheit als eine grundlegende Zielsetzung erschwert bzw. in Frage gestellt wird.

Die Einhaltung von bestimmten Rand- und Rahmenbedin-gungen im Sinne einer einheitlichen Semantik ist jedoch unerlässlich. Zukünftig werden zahlreiche auftragsbezo-gene Architekturen durch unterschiedliche Modellierer mit unterschiedlichem Sachbezug in unterschiedlichen Organisationsbereichen der Bundeswehr erarbeitet wer-den. Durch die Nutzung unterschiedlicher Werkzeuge und individueller Auffassungen und Ansichten werden damit eine Vielzahl von Gestaltungsmöglichkeiten erschlossen, die u. a. zur Unübersichtlichkeit der Modelle und damit zu erschwerter Informationsgewinnung der zukünftigen Nutzer führt.

3.6.3 Empfehlung zur Entwicklung von Konventionen

Die Verwendung des NAF ist eine verbindliche Vorgabe der technischen Architektur der Bundeswehr (TABw), die Standards für IT-Systeme der Bundeswehr definiert. Die zu entwickelnden Konventionen konkretisieren die Vorga-ben von NAF und sind toolunabhängig zu gestalten.

Es stellt sich die Frage: Was sollte in den Konventionen für die Architekturmodellierung der Bw festgelegt bzw. beschrieben werden?

� Nachfolgende Auflistung stellt die wesentlichen Aspekte dar, die in die Konventionen für die Architek-turmodellierung der Bw einfließen sollten:

� Kriterien für die Einordnung der Architektur in die Architekturfamilie der Bw: Um die Entwicklung von Insellösungen auszuschlie-ßen, müssen alle Architekturen in die Architekturfa-milie der Bw einfügbar sein. Zu entwickelnde Kriterien geben Bedingungen an, wie und wo (Touch-Points) die Architektur in die „Architekturhierarchie“ eingeordnet wird.

� Entwicklung eines Wertevorrates von Architekturob-jekten: Der Wertevorrat bildet eine übergreifende Sammlung von Definitionen zur Vereinheitlichung der Architek-turmodelle. Dieser Wertevorrat wird aus bestehenden Definitionen von einer zentralen Stelle zusammenge-führt und gepflegt. Um dem Anspruch eines übergrei-fenden und redundanzfreien Wertevorrates gerecht zu werden, ist die Auswahl der im Wertevorrat zu hin-terlegenden Definitionen von besonderer Bedeutung. Dabei ist insbesondere die Wiederverwendbarkeit der Definitionen ein wichtiges Auswahlkriterium.

6. Für den [Fachlichen Bezug] wurden Wertevorräte definiert. Für NOV-5 wird zusätzlich die Diagrammart (Mod, Tree) eingefügt.7. Diagrammart: Modell, Ebene:0

� Vorgaben zu den Architekturelementen (NNEC): Wie bereits im Kapitel 3.6.1 vermerkt, müssen die Architekturen der Bw in die Architekturwelt im Sinne der NNEC integrierbar sein. In Bezug auf diesen Anspruch sind Vorgaben über die Verwendung und Zuordnung der Architecture Elements (NAF) zu erarbeiten.

� Modellübergreifende Konventionen: Festlegungen zur Modellierungssprache, Verwen-dung von Abkürzungen, Groß-und Kleinschreibung, Konventionen zur Benennung der Enzyklopädien und Artefakte.

� Modellspezifische Konventionen: Namenskonventionen der im Modell zu verwenden-den Definitionen, Vorgaben zur Verwendung beschrei-bender Attribute.

� Konventionen zu Qualitätssicherung: Vorgaben und Vorlagen für die syntaktische Architek-tur QS, Semantische Architektur-QS und Strategische Architektur QS.

� Konventionen zum Konfigurations-Management (KM): Die Anwendung und Durchführung von KM resultiert in einem Konfigurationsmanagementprozess (KMP). Der KMP regelt den Lebensprozess von Architekturen hinsichtlich der Organisation und Planung, der Kon-figurationsidentifizierung, der Konfigurationsüber-wachung und der Konfigurationsüberprüfung8. Ziel des KM ist es, den Grad der Erfüllung physischer und funktionaler Anforderungen an eine Architektur zu dokumentieren und diesbezüglich volle Transparenz herzustellen. Diese soll zudem dazu führen, dass jeder an einer Architektur Interessierte die richtige und zutreffende Dokumentation verwendet.

� Konventionen zum Änderungsmanagement: Vorgaben zur Verwaltung und Pflege von Architektu-ren (zu verwendende Tools, Verantwortlichkeiten).

3.6.4 Abzeichnende Vorgehensweise Bundeswehr

Konventionen, Wertevorräte und Taxonomien für die Modellierung von Architekturen in der Bundeswehr sind im Handbuch „Architekturer- und -Bearbeitung“, hier speziell im Band 5 „Architekturrahmenwerk Bundeswehr“ enthalten. Das Handbuch „Architekturer- und -Bear-beitung“ wird durch die AG Architekturen Bundeswehr erstellt und fortgeschrieben. Die Veröffentlichung der 1. Version des Handbuches ist für das IV. Quartal 2009 geplant. Auf Grund sich ständig ändernder Rahmenbedin-gungen und Vorgaben unterliegen die innerhalb der Bun-deswehr anzuwendenden Verfahren und damit verbun-den auch Konventionen, Wertevorräte und Taxonomien für die Modellierung von Architekturen einer ständigen Veränderung. Diesen Veränderungen trägt die Fortschrei-bung des Handbuch „Architekturer- und -Bearbeitung“ durch die AG Architektur Bundeswehr Rechnung. Bis zur Etablierung eines entsprechenden Change Managements werden Vorschläge zur Änderung des Handbuch „Archi-tekturer- und -Bearbeitung“ formlos – auch von Seiten der Industrie – über die Bevollmächtigten Vertreter der Orga-nisationsbereiche9 in die AG Architekturen eingebracht, von dieser abschließend beraten und bei Bedarf als Ände-rung der Bände II -VIII des Handbuches veröffentlicht.

Die Vorgabe von Konventionen, Wertevorräten und Taxo-nomien für die Modellierung von Architekturen in der Bundeswehr im Handbuch „Architekturer- und -Bearbei-tung“ beschränkt sich auf ein für die Wahrung organisa-tionsbereichsübergreifender Belange unbedingt notwen-diges Maß. Im Regelfall werden zusätzliche Konventionen, Wertevorräte und Taxonomien für einzelne Aufgabenbe-reiche durch die Organisationsbereiche10 bzw. für einzelne Architekturen durch den Aufgabensteller vorgegeben. Diese Konventionen, Wertevorräte und Taxonomien werden im Architekturplanungsdokument ‚Overview and

8. Quelle: DIN - DEUTSCHES INSTITUT FÜR NORMUNG e.V. (Hrsg.): DIN EN ISO 10007: 1996 Qualitätsmana-gement - Leitfaden für Konfigurationsmanagement (ISO10007:1995)

9. Änderungsvorschläge der Industrie sind grundsätzlich über den BV BWB bzw. IT-AmtBw einzubringen. Ergeben sich Änderungsvorschläge aus Modellierun-gen im Rahmen von Studien u. ä ., sind Änderungsvorschläge über den BV des Aufgabenstellers einzubringen.

10. z. B. durch den Präsident IT-AmtBw für die Modellierung im Rahmen der Bedarfsermittlung- und –deckung im Verantwortungsbereich des IT-Direktors

Summary’ NATO All View 1 (NAV-1) der jeweiligen Archi-tektur dokumentiert.

Im „Architekturrahmenwerk Bundeswehr“ wird zunächst – zur Etablierung eines einheitlichen Verständnisses – der grundsätzliche Aufbau von Architekturen beschrieben. Während die Architekturtypen aus dem NATO Architec-ture Framework in der Version 3 ohne Veränderungen übernommen wurden, wurden die Architektursichten des NATO Architecture Framework durch zusätzliche, bundes-wehrspezifische Elemente ergänzt.

Im Folgenden werden zunächst übergreifende Konventi-onen dargestellt, die unabhängig von einem konkreten Diagramm, Objekt, Symbol oder Attribut immer anzu-wenden sind. Dieser Teil enthält auch eine Aufstellung der Sub-Views / Templates, die in einer Architektur – unab-hängig von Zielstellung und konkretem Inhalt – immer zu modellieren sind.

Des Weiteren werden Konventionen für die Elemente einer Architektur dargestellt. Ergänzt wird diese Darstel-lung durch die Vorgabe von Wertebereichen und Taxono-mien für die Einordnung bestimmter Objekte.

Die Inhalte der Konventionen sind werkzeugunabhän-gig. Sie orientieren sich am NAF und unterstützen den Modellierer, konsolidierte, integrierbare und redundanz-freie sowie lesbare und verständliche Architekturen zu erarbeiten.

� 3.7 IT-Sicherheit

Zur Gewährleistung der IT-Sicherheit von Architekturent-wicklungen werden seitens der Bundeswehr verschiedene IT-Sicherheitsziele in Form von Detail- und Ergänzungsre-gelungen vorgegeben. Die wesentliche Durchführungsbe-stimmung ist die Zentrale Dienstvorschrift 54/100. Diese wird durch Einzelvorschriften, allgemeine Umdrucke, Weisungen und anerkannten Standards aus dem Bereich von Architekturentwicklungen ergänzt. Bei internationa-len Architekturentwicklungen können weitere Vorgaben (z. B. der NATO) hinzukommen.

Die Sicherheitsanforderungen werden im Allgemeinen in drei Kategorien strukturiert:

� IT-Basisschutz Bundeswehr (BS), � Erweiterter IT-Basisschutz Bundeswehr (EB), � und VS-Verarbeitung.

Die entwicklungsbezogenen Vorgaben zur IT-Sicherheit sind den jeweiligen Phasen des Customer Product Managements (vgl. Kapitel 3.2) zugeordnet. Die Erstellung eines projektbezogenen IT-Sicherheitskonzepts (IT-SichhKProj) ist für Architekturentwicklungen eine Pflicht-vorgabe. In dem IT-SichhKProj ist die Einhaltung aller uneingeschränkt geltenden IT-Sicherheitsanforderungen sowie weiterer spezieller IT-Sicherheitsanforderungen (z. B. anhängig von der jeweiligen Architektur) nachzuwei-sen. Die uneingeschränkt geltenden IT-Sicherheitsanfor-derungen sind in der ZDv 54/100 aufgeführt. Die weiteren speziellen IT-Sicherheitsanforderungen ergeben sich auf Grund einer projektspezifischen Risikoanalyse sowie ggf. projektspezifischer Vorgaben (z. B. aus dem Bereich NATO, Abstrahlsicherheit, Datenschutz, Applikationssicherheit, usw.).

4 Notwendigkeiten und Randbedingungen der Auftragnehmerseite im Verteidigungsbereich

� 4.1 Anforderungsmodellierung & Interessengruppen

4.1.1 Einführung

Die Entwicklung eines Systems bzw. Produkts hat das Ziel, die Bedürfnisse mehrerer Personen, Gruppen und Institutionen zu befriedigen, wobei die Bedürfnisse und Ansprüche sehr unterschiedlich, gegenläufig und sogar widersprüchlich sein können. Die von dem Entwurf, der Entwicklung, der Inbetriebnahme, dem Einsatz und dem Betrieb bis hin zur Wartung, Pflege und Entsorgung Betroffenen werden als Stakeholder bezeichnet, unter denen aber nicht nur Personen / Gruppen / Institutionen, sondern auch Standards, Normen und Richtlinien verstan-den werden können. Stakeholder sind die Informationslie-feranten für die Ziele, Anforderungen und Randbedingun-gen eines Systems.

Anforderungen und Stakeholder bzw. Interessengruppen sind somit in engem Zusammenhang zu betrachten, weil Anforderungen immer die Sichtweise einzelner Stakehol-der auf ein Problemfeld repräsentieren. Da die Heteroge-nität der Interessengruppen mit der Komplexität eines militärischen Systems für den Einsatz wächst, steigt auch die Gefahr, dass Anforderungen nicht eindeutig sind und sich unter Umständen sogar widersprechen. Übersehene und vergessene Stakeholder bilden ebenfalls einen Unsicherheitsfaktor, denn vergessene Stakeholder bedeuten vergessene Anforderungen. Werden daraus resultierende Missverständnisse und Lücken nicht recht-zeitig erkannt, steigt das Risiko kostenintensiver Um- und Nachentwicklungen.

Aus Gründen der Risikominimierung besteht aus Sicht der Auftragnehmer bzw. Realisierer die Notwendigkeit, die Stakeholder und in noch stärkerem Maße die Anforde-

rungsmodelle frühzeitig in der Architekturentwicklung zu verankern.

Dieser Abschnitt und insbesondere der Teilabschnitt 4.1.4 verfolgen daher das Ziel, Empfehlungen zu erarbeiten, um die Missverständnisse jeglicher Art über den gesam-ten Lebenszyklus eines Systems zu minimieren, indem Stakeholder- und Anforderungsmodelle erstellt und mit der Gesamtarchitektur integriert bzw. mit ihr verknüpft werden. Die Methode Architektur bietet Ankerpunkte, an denen Anforderungsmodelle festgemacht werden können. Insbesondere in dem Bereich der operationel-len Sichtweisen, die beispielsweise um Use-Case- oder Anforderungsdiagramme ergänzt werden könnten, und in dem Bereich der technischen Sichtweisen, aus denen sich Anforderungen auf Grund verpflichtender Normen erge-ben, bieten sich Ansatzpunkte für Anforderungsanalysen.

4.1.2 Problemdarstellung

Die verschiedenen Projektbeteiligten (Stakeholder) haben in der Regel unterschiedlich abstrakte Sichten auf ein und dasselbe Problem und formulieren konsequenterweise ihre Bedürfnisse und Ansprüche aus ihrer jeweiligen Per-spektive. Selbst auf triviale Begriffe gibt es unterschiedli-che Sichtweisen, die zu schwerwiegenden Missverständ-nissen mit all ihren Konsequenzen führen können.

Daraus kann sich ein Kommunikationsproblem ergeben, dessen Lösung in der wechselseitigen Abstimmung der Bedürfnisse und Ansprüche besteht. Anforderungen müs-sen daher durch Meta-Informationen, die die Perspektiven eindeutig identifizieren, konkretisiert werden.

Schwerpunktmäßig lassen sich folgende Problemfelder identifizieren:

� Mehrdeutigkeiten, � Redundanzen,

� Widersprüche und � Ungenauigkeiten.

Das Ziel der Anforderungsmodellierung muss es sein, ein gemeinsames Verständnis für die Aufgabenstellung und damit einen für alle Stakeholder akzeptablen Anforde-rungskatalog zu entwickeln.

Eine weitere Dimension in diesem Problemfeld ist die Anforderungsmodellierung selbst, denn es sind viele unterschiedliche Methoden und Ansätze in der Literatur bekannt. Vielfach wird jedoch von unbefriedigenden Ergebnissen berichtet, z.B. bei der Erstellung von Anfor-derungsmodellen zur Auswahl von Werkzeugen oder zur Überprüfung der Güte der Informationsverarbeitung. Eine Ursache für diese Probleme liegt in dem Fehlen eines einheitlichen Verständnisses des Begriffs des Anforde-rungsmodells, sowie in der Anwendung verschiedener Methoden und Vorgehensweisen zur Erstellung des Anforderungsmodells.

4.1.3 Bewertung

In den vorausgegangenen Abschnitten 4.1.1 und 4.1.2 ist bereits angedeutet worden, dass Anforderungen und Stakeholder in engem Zusammenhang zu betrachten sind, und Anforderungen immer die Sichtweise einzelner Stakeholder auf ein Problemfeld repräsentieren. Es ist daher von entscheidender Bedeutung, möglichst viele (besser: alle) Stakeholder frühzeitig zu identifizieren und in den gesamten Lebenszyklus-Prozess des durch die Architektur modellierten Einsatzsystems einzubinden. Zur Förderung der Kommunikation und der Zusammenarbeit ist es darüber hinaus von entscheidender Bedeutung, mit Hilfe von leistungsfähigen Modellierungsfunktionen die Anforderungen der Stakeholder, die in der Regel als Textsequenzen, Bilder und Zeichnungen vorliegen, um Anforderungsmodelle zu ergänzen, die eine Visualisierung der Forderungen darstellen und somit die Verständlich-keit erhöhen.

Detailebenen und unterschiedliche Abstraktionsstufen ermöglichen die Darstellung einer Anforderung in einer

für den jeweiligen Stakeholder angepassten Abstraktion. Mechanismen zur Sicherstellung der Konsistenz über alle Detailebenen und Abstraktionsstufen hinweg ermög-lichen eine homogenisierte und harmonisierte Menge von Anforderungen und verdeutlichen Widersprüche, Überlappungen und fehlende Vollständigkeit.

4.1.4 Empfehlungen

In diesem Abschnitt wird versucht, eine Anforderungs-sicht und zugehörige Modellierungsfunktionen – gewis-sermaßen als eine Ergänzung zu den NAF-Sichten – zu definieren, die eine einheitliche Anforderungsmodellie-rung ermöglichen, für alle Aspekte der vernetzten Opera-tionsführung eingesetzt werden können und sowohl für Experten wie auch für Anwender verständlich sind.

Zur Unterstützung der Erstellung und Anwendung der Anforderungsmodelle ist außerdem geplant, eine Metho-dik zur Anforderungsmodellierung vorzustellen. Deren Ergebnis soll ein Anforderungsmodell sein, das

� dazu dient, Systemanforderungen und -informatio-nen unmissverständlich zwischen unterschiedlichen Stakeholdern zu kommunizieren;

� als Grundlage für die Systementwicklung dient; � maßgeblich zum Projekterfolg beiträgt und � gegebenenfalls als Bestandteil von Verträgen genutzt

werden kann.

Vor der Beschreibung der Methodik zur Anforderungs-modellierung sollen an dieser Stelle die verwendeten Begrifflichkeiten noch kurz erläutert werden, insbesondere die Begriffe „Ziel“, „Anforderung“, „Anforderungsmodell“ und „Anforderungsmodellierung“.

� Ziele sind allgemeine Aussagen über geforderte Eigenschaften eines Systems, ohne jedoch schon kon-krete Anforderungen zu formulieren.

� Anforderungen sind konkrete, überprüfbare Aussagen über qualitative und quantitative Eigenschaften eines Systems, wobei funktionale und nicht-funktionale Anforderungen unterschieden werden.

� Anforderungsmodellierung bedeutet die Deklaration von Anforderungen mit Hilfe einer (Modellierungs-)Sprache.

� Ein Anforderungsmodell ist das Ergebnis einer Anforderungsmodellierung.

Basierend auf diesen Erläuterungen wird die Methodik zur Anforderungsmodellierung in der nachfolgenden Aufzäh-lung dargestellt:

� Das Problem verstehen � Ermitteln der Interessengruppen / Stakeholder � Ziele ermitteln � Systemgrenzen festlegen � Erfassen und Auswerten der Anforderungen aus den

operationellen Sichten, Befragen der Stakeholder, Analyse der technischen Sichten, Festlegung des gewünschten Schutzbedarfs

� Definition von Detailebenen und Kategorisierung der Anforderungen sowie deren Zuordnung zu den Detailebenen

� Dokumentation und Präsentation des Modells unter Verwendung des Anforderungsdiagramms aus SysML, das Bestandteil (Teilsicht) der Architekturdokumenta-tion wird

Zwei Aspekte aus dieser Methodik sollen in den beiden nachfolgenden Teilabschnitten noch verfeinert werden:

� Stakeholder-Management mit den Teilaspekten: Ermittlung von Stakeholdern, Befragung von Stake-holdern und Verwaltung von Stakeholdern

� Anforderungsmodellierung mit Hilfe der SysML

Stakeholder

Da die Vollständigkeit des Anforderungsmodells in hohem Maße von der Vollständigkeit der Stakeholder abhängt, kommt der Stakeholderermittlung eine ganz entscheidende Bedeutung zu. Dies gilt sowohl für die Architektur selbst als auch für das durch die Architektur beschriebene System. Basis für die Stakeholderermitt-lung können Listen aus vorherigen ähnlich gelagerten Projekten sein. Liegen derartige Informationen nicht vor, kann auf die Erfahrung von Projektleitern und -mitar-beitern zurückgegriffen werden, die ähnliche Themen

bearbeitet haben. Bereits ermittelte Stakeholder können ebenfalls als Informationsquelle herangezogen werden, da diese in der Regel weitere relevante Stakeholder aus ihrem Umfeld kennen. Zu beachten ist, dass möglichst nur solche Stakeholder ausgewählt werden, die präzise und spezifische Kenntnisse über den Einsatz des Systems (oder auch der Architektur) in dem durch sie repräsentierten Umfeld besitzen. Der gesamte Prozess der Stakeholder-ermittlung muss in einem Stakeholder-Modell detailliert dokumentiert werden, aus dem auch die Beziehungen zwischen Stakeholdern und auch deren Rollen bezogen auf das System (oder die Architektur selbst) dargestellt werden. In der NAF-Dokumentation (Band 2 – Architec-ture Stakeholder and Community of Interests) ist eine derartige Rollenaufteilung für den Bereich der NATO bereits vorgenommen worden (nur für die Stakeholder der Architektur), die als Ausgangsbasis dienen kann. Eine Möglichkeit der Stakeholderverwaltung sind aufbereitete Tabellen, die die relevanten Informationen enthalten.

Ebenso wichtig wie die Stakeholderermittlung ist die Sta-keholderbefragung, aus der sich deren Bedarf und daraus abgeleitet die Anforderungen ergeben. Die Durchführung der Befragung ist im Einzelfall abzustimmen. Workshops, in denen Gruppen von Stakeholdern zusammenkommen und gemeinsam Ziele und Anforderungen erarbeiten, ist eine bevorzugte Form der Befragung.

Anforderungsmodell

Das Anforderungsmodell dokumentiert die Ergebnisse der Anforderungsmodellierung und steht am Ende der Methodik zur systematischen und vollständigen Erfas-sung der Ziele und Anforderungen aller identifizierten Stakeholder. Anforderungsmodelle sind nicht neu, jedoch waren sie bisher dokumentenzentriert und lagen in Form von Texten, Bildern, Zeichnungen ohne Beziehungen untereinander vor.

Um die Anforderungen als festen Bestandteil in die Architektur aufzunehmen, wird daher ein Paradigmen-wechsel von der bisherigen dokumentenzentrierten Anforderungsanalyse hin zur modellzentrierten Analyse empfohlen.

UML als bekannteste Sprache unterstützt – neben Anwendungsfällen (Use Cases), die als Anforderungsele-mente genutzt werden können – die Anforderungsmodel-lierung kaum. Es wird daher empfohlen, SysML als Derivat von UML für die Anforderungsmodellierung zu nutzen, da diese Modellierungssprache ein geeignetes Vokabular und eine eigene Diagrammart – das Anforderungsdia-gramm – zur Verfügung stellt. Mit diesem Diagramm ist die Beschreibung der funktionalen und nicht funktionalen Anforderungen sowie deren Beziehungen untereinander möglich.

Die Anforderungselemente der SysML müssen in den Textanteilen nicht zwangsläufig die Anforderung selbst beschreiben, sondern können auf externe Quellen ver-weisen, so dass damit die Verankerung zwischen dem Anforderungsmodell in SysML und anderen Architektur-sichten bzw. Teilsichten (z.B. operationelle Sichten gemäß NAF) möglich ist.11

� 4.2 Nutzung und Vergleichbarkeit von Architekturen

Die in diesem Dokument dargestellten Rahmenbedin-gungen im Verteidigungsbereich stellen eindeutig die allgemeine Notwendigkeit einer architekturbasierten Vor-gehensweise in Projekten und Vorhaben fest und fordern eine entsprechende Umsetzung.

Allerdings sind derzeit eine Reihe von Fragen hinsichtlich der konkreten Ausprägung und der Nutzung im Kern unbeantwortet.

4.2.1 Nutzung in der zivilen Industrie

In der zivilen Industrie gehört die Nutzung von architek-turbasierten Vorgehensweisen weitgehend zum Alltag im Projektgeschäft der Unternehmen. Viele Unternehmen haben eigene Architekturmethoden entwickelt, andere

nutzen implizit derartige Ansätze durch die Einbindung von externen Partnern und deren Expertise.

Es ist aber zu unterstellen, dass sich insgesamt eine Viel-zahl verschiedener Konzepte, Ansätze und Zielsetzungen hinsichtlich der Vorgehensweise herausgebildet haben. In einer oberflächlichen Betrachtung werden sich diese wohl nur relativ wenig voneinander unterscheiden, sowohl auf Ebene der methodischen Vorgehensweise als auch im Bereich der inhaltlichen Ausgestaltung, jedoch lassen sich in einer Detailbetrachtung z.T. deutliche Unterschiede erkennen. Sie liegen beispielsweise in der unterschiedli-chen semantischen Ausprägung von Arbeitsergebnissen oder zugrundeliegenden Standards.

Unternehmen oder Organisationen mit eigenen Vorgaben im Bereich Architektur können daher – bei konsequenter Anwendung – den größtmöglichen Nutzen realisieren. Sie sind in der Lage, eine homogene, konsistente und inei-nandergreifende Systemlandschaft zu schaffen, die alle betroffenen Ebenen durchdringt und bestmöglich eine Interoperabilität gewährleistet.

Demgegenüber stehen Unternehmen ohne eigene, bindende Vorgaben einem bedeutenden strukturellen Problem gegenüber, welches sich negativ auf die System-landschaft auswirken kann.

Abbildung 4.2-1: Notwendigkeit eines Anforderungsmanagement bei „System of Systems“

11. Die aktuellen Spezifikationen und Dokumente sind auf der offiziellen SysML-Homepage der OMG zu finden (www.omgsysml.org) zu finden.

In den Projekten dieser Unternehmen bilden sich – im Prinzip zufallsgesteuert – verschiedenenartige Ansätze und Umsetzungen hinsichtlich Architektur aus. Dieser Effekt wird dann weiter verstärkt, wenn sich die Rea-lisierungspartner bzw. Auftragnehmer dieser Projekte häufig ändern und im Projektauftrag keine oder unpräzise Anforderungen im Bereich methodischer Vorgehensweise und geforderter Ergebnistypen inklusive semantischer Spezifikationen enthalten sind. Die Arbeitsergebnisse derartiger Projekte können, für sich genommen, durchaus vollständig und korrekt sein.

Allerdings besteht die deutlich erhöhte Gefahr, dass sich die Ergebnisse mehrerer Projekte nicht oder nur einge-schränkt zusammenfügen lassen und somit ein nicht optimales Gesamtsystem („System of Systems“) entsteht, was durch die überzeichnete Illustration in Abbildung 4.2-1 veranschaulicht wird. An diesem plakativen Beispiel wird die Notwendigkeit eines übergreifenden Anfor-derungsmanagements auf der Ebene des „System of Systems“ deutlich.

Empfehlungen

Ein hohes Maß an Parallelität von Projekten und Vorha-ben ohne geeignete, ebenengerechte Kontrolle erhöht das Risiko von negativen Effekten auf das übergeord-nete Gesamtsystem. Dieses Risiko kann mittels der Definition von Kontroll-strukturen (e.g. Governance), z.B. durch eindeutige, verbindliche Vorgaben für die Nutzung von bzw. den Umgang mit Architekturen sowie einem übergreifen-den Anforderungsmanagement auf der Ebene des „System of Systems“ (im Kontext der Bundeswehr: IT-SysBw) minimiert werden.

4.2.2 Vergleichbarkeit

Im Verteidigungsbereich zeichnen sich die verfügbaren und notwendigen Systeme sehr häufig durch einen hohen Grad an Komplexität aus. Darüber hinaus ist die Entwick-lung und Erstellung häufig durch die Forderung nach einer umfassenden Modularität bestimmt. Das Gesamt-system besteht aus einzelnen, teilweise sehr unabhän-gigen Bausteinen in Form von technischen Modulen und

Komponenten, die zu einem Ganzen zusammengefügt bzw. integriert werden. Das daraus entstehende Gesamt-system wird oft auch als „System of Systems“ bezeichnet.

Die Beschreibung der Architektur derartiger Systeme in entsprechenden Ergebnistypen ist ein wichtiges Hilfsmit-tel zur formalen Beurteilung der Leistungsfähigkeit, ohne aufwendige Teststellungen und Experimente durchführen zu müssen.

In diesem Zusammenhang ist es jedoch dringend ange-raten, klare und eindeutige semantische und strukturelle Vorgaben hinsichtlich der Ergebnistypen und ihrer Inhalte zu tätigen.

Es geht – bildlich gesprochen – um die Definition und Vereinbarung einer angemessenen, gemeinsamen „Spra-che“, und eines „Vokabulars“, so dass jeder Teilnehmer die „Bedeutung“ der Elemente dieser Sprache kennt bzw. sich dieses Wissen relativ leicht aneignen kann.

Mit solchen Vorgaben werden Ergebnistypen und letzten Endes auch die resultierenden Systeme insgesamt besser vergleichbar, die (teilweise zwangsläufige) Komplexität wird greifbar und besser erfassbar. Die Beurteilung der Leistungsfähigkeit von derartig beschriebenen Systemen ist mit z.T. deutlich weniger Aufwand durchführbar.

Häufig ist bei der Betrachtung der Architekturen unter-schiedlicher Systeme ein nahezu babylonisches Sprach-gewirr anzutreffen. Jedes System bedient sich auf Grund der eingangs geschilderten Problematik „Nutzung in der zivilen Industrie“ einer anderen ggf. gänzlich anderen Sprache oder zumindest eines„weit entfernten Dialektes“. Selbst innerhalb eines einzelnen Systems kann dieses Pro-blem auf Grund der bereits angesprochenen Komplexität und der Komponentisierung anzutreffen sein.

Es gibt im Verteidigungsbereich und in der zivilen Indust-rie verschiedene Ansätze und Lösungen, um eine derar-tige Sprachreglung vorzunehmen. Dazu zählt z.B. das NAF.

Allen Ansätzen und Lösungen ist aber eines gemein: Sie sind naturgemäß inhaltlich begrenzt bzw. lückenhaft.

Eine voll umfassende Lösung ist mit einem einzelnen, derartigen Verfahren, wie z.B. NAF, wahrscheinlich nicht möglich. Es bedarf zusätzlicher Regelwerke.

Das Vorgehensmodell in der Systementwicklung wird im gesamten öffentlichen Sektor, insbesondere im Vertei-digungsbereich, über das Grundprinzip der Trennung zwischen Bedarfsträger und Bedarfsdecker getrieben. Die dazu relevanten Verfahrensbestimmungen sind im CPM12 abgebildet. Die Bedarfsdeckung wiederum erfolgt unter der starken Einbeziehung der Industrie im Rahmen z.B. einer spezifischen Produkt(neu)entwicklung bzw. dem Einkauf verfügbarer Standardprodukte (auch bekannt als COTS, MOTS oder GOTS13).

Im Zusammenspiel mit den Vergaberichtlinien bei öffent-lichen Auftraggebern (ÖAG) begünstigt dieser Ansatz die in Kapitel „Unterschiedliche Ausprägungen von Architek-turen“ dargelegte Vielfältigkeit von Architekturansätzen und die daraus resultierenden Lösungen. Auf Grund des Vergaberechts ist der ÖAG grundsätzlich gezwungen, im Wettbewerb über den jeweiligen Realisierungspartner für eine konkrete Bedarfsanforderung zu entscheiden.

Empfehlungen

Unter den gegebenen Rahmenbedingungen des CPM und des öffentlichen Vergaberechts ist es daher ratsam, dass der ÖAG seinerseits eindeutige Rahmenbedin-gungen hinsichtlich Architektur schafft und in diesem Bereich die bisher vakante Federführung übernimmt. Dies beinhaltet z.B.

� Vorgaben auf struktureller und organisatorischer Basis wie beispielsweise � Aufbau von Governance-Strukturen zur

permanenten Qualitätssicherung der Arbeits-ergebnisse vor, während und nach einer Systementwicklung � Definition erwarteter Architektur-Ergebnistypen

und -Produkte während eines Projekts bzw. Vorhabens

� Vorgaben auf inhaltlicher Basis, z.B. � Semantische Definitionen � Definition von Referenz-Architekturen

Die potentielle Vielzahl der Anbieter und deren jeweilige Ansätze bedeutet ein hohes Risiko bzgl. der Forderungen nach einheitlichen, konsistenten und durchgängigen Architekturen.

� 4.3 Unterschiedliche Ausprägungen von Architekturen

Die unterschiedlichen Zielstellungen und Rahmenbedin-gungen bei der Erstellung und Weiterentwicklung einer Architektur führen zu unterschiedlichen Ausprägungen der Architekturen.

Eine grobe Klassifizierung von Architekturen kann anhand der Zielstellung vorgenommen werden. So erfordern fol-gende Zielstellungen die Modellierung unterschiedlicher Architektursichten und ergänzen sich z.T. im Sinne einer System-of-Systems-Betrachtungsweise:

� Architekturen für eingebettete Systeme (Embedded Systems) im Verbund von Sensoren, IT und Effektoren,

� HW-Architektur, � SW-Architektur, � IT-Sicherheitsarchitektur, � IT-Servicemanagement-Architektur nach ITIL, � IT-Landschaftsplanung eines Organisationsbereiches

bzw. einer größeren Organisationseinheit, � Integration bestehender, einzuführender und zu

entwickelnder Systeme und Komponenten zu einem Gesamtsystem (Integrationsarchitektur).

Weiterhin können Architekturen auf Grund des zeitli-chen und organisatorischen Gültigkeitsbereichs (Scope) vielseitig und unterschiedlich ausgeprägt sein, was zu einer Differenzierung in Unternehmensarchitekturen und Projektarchitekturen führt.

Im Bereich der operationellen Planung und Bedarfser-mittlung bzw. -deckung der Bundeswehr wird zwischen aufgabenorientierten Architekturen (detaillierte Beschrei-bung von Einsätzen und Aufgaben anhand von Szenaren)

12. Customer Procurement Management, siehe auch Kapitel ‘Customer Product Management (CPM)’.13. COTS=Commercial-off-the-shelf, MOTS=Military-off-the-shelf, GOTS=Government-off-the-shelf

und fähigkeitsorientierten Architekturen (zur Schließung von Fähigkeitslücken) unterschieden.

Auf die Unterscheidung nach dem zeitlichen Betrach-tungshorizont und dem Detaillierungsgrad in ‚Übergeord-nete Architekturen’ (Overarching Architectures), ‚Ist-Archi-tekturen’ (Baseline Architectures), Referenzarchitekuren (Reference Architectures) und Zielarchitekturen (Target Architectures) wurde bereits im vorhergehenden Kapitel eingegangen.

Die Ausprägung der Architekturen beeinflusst die Vorge-hensweise in der Architekturmodellierung in folgenden Bereichen:

� Auswahl und „Customizing“ des Architekturrahmen-werkes (Architecture frameworks),

� Auswahl der Architektursichten und -modelle inner-halb des Frameworks,

� Beschreibungsmethoden und Ergebnisaufbereitung, � Abstraktionsgrad und Beschreibungstiefe, � Auswahl und Kombination von Modellierungstools, � Stakeholder und deren Rollen im Prozess der

Architekturentwicklung

Die sich aus den o.g. Ausprägungen ergebenden Anfor-derungen werden im Folgenden näher erläutert und Empfehlungen für die Vorgehensweise in der Zusammen-arbeit zwischen Bundeswehr und Industrie gegeben.

� 4.4 Auswahl von Design- und Entwicklungsmethoden

Die Auswahl von Design- und Entwicklungsmethoden zur Architekturentwicklung hängt von unterschiedlichen Faktoren ab. Auf die unterschiedlichen Ausprägungen von Architekturen und der damit verbundenen Notwendigkei-ten zum Teil unterschiedliche Design- und Entwicklungs-methoden anzuwenden, wurde bereits im vorherigen Kapitel eingegangen. Dennoch ist das zu modellierende System oder Unternehmen und der damit verbundene Verwendungszweck der Architektur nur ein, wenn auch wesentlicher Faktor für die Auswahl, der um folgende Betrachtungspunkte zu ergänzen ist:

� Unternehmensstrategie und Vorgehensmodelle zur Systementwicklung,

� IT-Strategie zur Verwendung von Software-Werkzeu-gen innerhalb eines Unternehmens,

� verfügbare IT-Infrastruktur und verfügbare Know-how-Träger,

� Erfahrungswerte bzw. Risikobewertung bei der Ver-wendung von Design- und Entwicklungsmethoden,

� Auftrag und vorgegebene Randbedingungen, � Kosten und Nutzen.

Diese Betrachtungspunkte werden im Weiteren erläutert und für die Auswahl von Design- und Entwicklungsme-thoden beurteilt. Abschließend werden in diesem Kapitel Empfehlungen, für den Umgang mit den Notwendigkei-ten und Randbedingungen der wehrtechnischen Indus-trie hinsichtlich der Auswahl entsprechender Methoden gegeben.

4.4.1 Unternehmensstrategie und Vorgehensmodelle zur Systementwicklung

In Unternehmensstrategien und Vorgehensmodellen zur Systementwicklung des Auftragnehmers sind üblicher-weise bereits generelle oder spezifische Vorgaben zu Design- und Entwicklungsmethoden für Systementwick-lungen festgelegt, die im Rahmen einer Architekturent-wicklung zu berücksichtigen sind. In der Unternehmens-strategie werden außerdem unternehmenspolitische Besonderheiten dargestellt, die in der Geschäftsdurchfüh-rung zu berücksichtigen sind.

In der Regel werden allgemeine Regelungen und Vor-gaben der Unternehmensstrategie durch ein unter-nehmensspezifisches Vorgehensmodell detailliert und konkretisiert. Dieses Vorgehensmodell berücksichtigt Vor-gaben und Randbedingungen aller Branchen, für die der Auftragnehmer tätig ist, und ist ggf. nicht spezifisch auf den wehrtechnischen Auftraggeber ausgerichtet. Diese Vorgaben und die generelle Ausrichtung können und dür-fen nicht ignoriert werden, da sie u.a. auch dazu dienen, Systementwicklungen kompatibel und vergleichbar zu machen, sowie durch wiederholten Einsatz Know-How

und Erfahrungen aufzubauen und somit Fehler und Kosten zu reduzieren. Sie können sich außerdem in den Vorgehensweisen und Ergebnissen einer Architekturmo-dellierung widerspiegeln.

Bei der Auswahl von Design- und Entwicklungsmethoden im Rahmen einer Architekturentwicklung ist daher im Vorfeld der Entwicklungsarbeiten zu prüfen,

� ob und welche Design- und Entwicklungsmethoden beim Auftragnehmer festgelegt sind,

� welche dieser Methoden auftraggeberbezogen ver-wendet werden können und anzuwenden sind,

� inwieweit die Vorgaben an Forderungen des Auftrag-gebers angepasst werden können oder müssen.

Bei der Auswahl der Design- und Entwicklungsmethoden ist damit zu rechnen, dass die vom Auftraggeber üblicher-weise verwendeten und eingesetzten Methoden nicht immer vollständig angewendet bzw. durch die Unterneh-mensvorgaben umgesetzt werden können.

4.4.2 IT-Strategie zur Verwendung von Software-Werkzeugen innerhalb eines Unternehmens

In der IT-Strategie eines Unternehmens sind Rahmenbe-dingungen für das Management der Informationstech-nologie festgelegt. Sie zeigt ausgehend von der aktuellen IT-Situation den Umfang und die Richtung zukünftigen Handelns auf, um somit langfristige Unternehmensziele zu erreichen. Bestandteile einer IT-Strategie, die Randbe-dingungen für die Architekturentwicklung enthalten, sind u.a. die Strategie bzgl.

� IT-Infrastruktur (Hardware, Betriebssysteme und Netzwerke),

� Applikationen zur Unterstützung einer effizienten Geschäftsdurchführung,

� Informationssicherheit zum Schutz der entwickelten Systeme und verarbeiteten Daten und

� IT-Innovationen (neue Technologien, die die Geschäfts-durchführung zukünftig noch besser unterstützen können).

Die in diesen IT-Strategiebereichen festgelegten Randbe-dingungen bestimmen die Möglichkeiten an IT-Infrastruk-tur (z.B. HW-Voraussetzungen) und Applikationen (z.B. Lizenzfragen, Sicherheitsanforderungen), aus denen im Rahmen der Architekturentwicklung geschöpft werden kann. Verbunden hiermit sind nicht nur entsprechende Investitionen in „technische“ Ressourcen, sondern auch Investitionen in die Ausbildung der erforderlichen und verfügbaren Know-How-Träger.

Architekturentwicklungen sind häufig Projekte, die mit einer Kernzelle beginnen und die im Laufe der Zeit durch Erweiterungen und Detaillierungen an Komplexität zunehmen. Dieser Komplexitätszuwachs kann dazu führen, dass auch die Auswahl von Design-, Entwick-lungsmethoden und -werkzeugen angepasst werden muss. Hierfür muss die IT-Strategie die aktuelle Situation der vorhandenen IT-Landschaft und -Werkzeuge ana-lysieren und Strategien für deren Weiterentwicklung festlegen. Im Rahmen dieser Strategien sind Innovationen im Applikations-/Werkzeugumfeld zu berücksichtigen, wobei hier besonderes Augenmerk darauf gelegt werden sollte, inwieweit bereits durchgeführte Architekturent-wicklungen auf eine neue Applikation portiert und dort weiterbearbeitet werden können. Eine solche Portierung erleichtert nicht nur die Fortführung bereits bestehender Arbeiten, sondern stellt auch eine erhebliche Kostener-sparnis dar, wenn bestehende Projekte weitergeführt werden.

Die Vorgaben der unternehmensinternen IT-Strategie berücksichtigen keine spezifischen Forderungen des wehrtechnischen Auftraggebers. Wenn diese zusätzlich im Rahmen einer Architekturentwicklung umzusetzen sind, hat dies deutliche Auswirkungen auf erforderliche Investitionen, Ausbildung von Know-How-Trägern und damit auf die Kosten des Projektes.

4.4.3 Verfügbare IT-Infrastruktur und verfügbare Know-how-Träger

Die verfügbare IT-Infrastruktur und das verfügbare Know-How der Architekturentwickler bzw. der mit der Architekturentwicklung betrauten Personen sowohl beim Auftraggeber als auch beim Auftragnehmer beeinflussen die Auswahl der Design- und Entwicklungsmethoden deutlich.

Grundsätzlich könnte eine Architekturentwicklung auch mit Hilfe der üblichen Office-Werkzeuge (z.B. Excel, Power-Point, Access) durchgeführt werden, die überall verfügbar sind. Sie ermöglichen die Erfassung und Zuordnung von Daten und Informationen (in mehr oder weniger über-sichtlicher Form) und deren graphische Aufbereitung. Außerdem ist deren Handhabung den meisten PC-Nutzern vertraut, so dass kein großer zusätzlicher Know-How-Auf-bau erforderlich ist. Solch „einfache“ Tools haben jedoch einige entscheidende Nachteile:

� Eine Verknüpfung von Informationen und Daten zwi-schen unterschiedlichen Anwendungen ist nicht oder nur mit erheblichem Aufwand möglich.

� Ab einem bestimmten Daten-/Informationsvolu-men ist dieses mit diesen Werkzeugen nicht mehr handhabbar.

� Änderungen an Informationen müssen manuell an allen relevanten Stellen nachgezogen werden, da eine automatische Verknüpfung der Daten fehlt, was eine starke Fehleranfälligkeit bedeutet und zu Inkonsistenz der Daten führen kann.

Da Architekturentwicklungen in der Regel sehr schnell komplexe und umfangreiche Systeme und Datenbanken entstehen lassen, empfiehlt es sich, hierfür auf Werkzeuge zurückzugreifen, die eigens für Architekturmodellierungs-aufgaben entwickelt wurden. Diese Werkzeuge unterstüt-zen in der Regel auch die Architekturentwicklung gemäß bestimmter Rahmenwerke (z.B. gemäß NAF). Bei der Auswahl solcher Werkzeuge sind einige Randbedingungen zu hinterfragen, da sie Auswirkungen auf Entwicklungsar-beiten selbst und auf Kosten haben. Dies sind z.B.:

� Welche Abhängigkeiten bestehen zwischen Hard-ware, Netzwerken und zu verwendender Applikation?

� Wird eine Architektur von einer einzelnen Person oder von einem Team entwickelt?

� Wie können die Arbeitsergebnisse bei einer Teament-wicklung an unterschiedlichen Standorten effizient zusammengeführt werden?

� …

Generell gilt: Je komplexer die Applikation ist, umso größer muss die Hardware- und Netzwerkumgebung kon-zipiert werden, um ein akzeptables Antwortzeitverhalten bei der Bearbeitung und Verwendung von Architekturen zu gewährleisten. Die verfügbare IT-Infrastruktur ist dies-bezüglich regelmäßig zu überprüfen und ggf. anzupassen.

Bei einer Architekturentwicklung in einem Team stellt sich die Problematik, dass parallel an unterschiedlichen Bereichen der Architektur gearbeitet wird. Solange diese Arbeiten auf einer gemeinsamen Datenbank erfolgen und der parallele Zugriff auf Daten gesperrt wird, stellt dies kein größeres Problem bei den Entwicklungsar-beiten dar. Sobald jedoch mit getrennten Datenbasen gearbeitet wird, stellt sich das Problem, wie die Daten effizient wieder zusammengeführt werden können, ohne Informationen zu verlieren. Hierfür bieten unterschied-liche Werkzeuge verschiedene Möglichkeiten an, z.B. des Auscheckens von Informationen/Daten, die das Zusam-menführen erleichtern können. Derartige Randbedingun-gen und Notwendigkeiten im Rahmen einer konkreten Architekturentwicklung können die Auswahl eines Entwicklungswerkzeuges maßgeblich beeinflussen.

Diese Problematik zeigt jedoch auch, dass Auswahl und Festlegung der Entwicklungsmethodik nicht nur durch ein geeignetes Werkzeug festgelegt werden, sondern auch durch werkzeugübergreifende und -unabhängige Festle-gungen der Vorgehensweisen geregelt werden müssen. Dies bedeutet zudem, dass die Know-How-Träger einer Architekturentwicklung nicht nur in den Design- und Entwicklungsmethodiken des jeweils zu verwendenden Entwicklungstools geschult sein müssen, sondern auch über die Kenntnis geeigneter und festgelegter Vorge-hensweisen außerhalb des Werkzeuges verfügen müssen. Dieses Know-How ist kontinuierlich aufzubauen und zu pflegen.

4.4.4 Erfahrungswerte bzw. Risikobewertung bei der Verwendung von Design- und Entwicklungsmethoden

Für das Erreichen eines definierten Ziels kann es Design- und Entwicklungsmethoden geben, die sich durch Faktoren unterscheiden, die in ihrer Summe sich auf die Wahrscheinlichkeit der Zielerreichung auswirken. Dazu gehören Faktoren wie:

� Möglichkeiten zur Präsentation von Ergebnissen � Strukturiertheit der Methoden � Komplexität der Methoden /

Fehlerwahrscheinlichkeiten � Validierungs- und Verifikationsmöglichkeiten

Selbst wenn unterschiedliche Methoden zum gleichen Ziel führen, werden bei der Auswahl der Design- und Entwicklungsmethoden von Auftragnehmerseite in der Regel eine Risikobewertung hinsichtlich des Projekter-folgs durchgeführt und eine Auswahl zu Gunsten einer Methode getroffen, die die Risiken minimieren.

4.4.5 Auftrag und vorgegebene Randbedingungen

Immer häufiger werden vom Auftraggeber Vorgaben hinsichtlich der zu verwendenden Entwicklungs- und Designmethoden gemacht. Hintergrund sind die aus Auftraggebersicht entstehenden Vorteile hinsichtlich des Nutzens und der Qualitätssicherung. Viele der Vorteile sind im Kapitel 3 bereits ersichtlich. Für einen Auftragneh-mer ergeben sich aus diesen Vorgaben grundsätzlich zwei Möglichkeiten. Zum Einen lässt sich der Auftragnehmer im vollen Umfang auf die Randbedingungen ein und zum Anderen werden die Randbedingungen lediglich an der AG/AN Schnittstelle eingehalten.

Ein Beispiel für den zweiten Fall ist, dass der Auftragge-ber eine Lieferung im Format A haben möchte und die Lieferung auch im Format A erhält. Hergestellt wird aber ein Produkt vom Auftragnehmer im Format B und zur Lieferung lediglich in das Format A konvertiert.

4.4.6 Kosten und Nutzen

Letztendlich richtet sich die Auswahl von Entwicklungs- und Designmethoden nach dem Kosten-Nutzen-Prinzip. Unter Berücksichtigung der im Kapitel 4.4 beschriebenen Einflussfaktoren ist die Frage zu stellen, welcher Aufwand betrieben werden muss bzw. sollte, um das Ziel unter Berücksichtigung des Faktors Kosten optimal zu erreichen.

Grundsätzlich gilt jedoch: Die Entwicklung einer Archi-tektur im Vorfeld einer Systementwicklung ist neben der Vorgabe aus dem V-Modell XT, dass eine Architektur ent-wickelt werden muss, zwingend erforderlich, um letztend-lich die Kosten der Systementwicklung zu reduzieren.

� Jedes System hat eine Architektur, besser ist man, plant sie vorher!

4.4.7 Empfehlungen

Es ist vorteilhaft für den Auftraggeber und zudem für einen fairen Wettbewerb, Vorgaben hinsichtlich der Auswahl von Design- und Entwicklungsmethoden in Ausschreibungen zu treffen. Dabei sollten die Vorgaben die hier dargestellten Randbedingungen der Industrie berücksichtigen. Eine Möglichkeit dies zu tun, ist die Entwicklung und Abstimmung eines Systems zur Auswahl von Vorgaben.

Zur Illustration eines solchen Systems dient die folgende Tabelle:

Projekt-typ

Rahmen-werk

Metho-den

Werk-zeuge

A - - Office

B - Methode 4711

Tool X

C NAF Methode 2,7,20

Tool Y

D NAF Methode 1..n

Tool Z

Tabelle 4.4-1: Vorgabenmatrix nach Projekttyp

Hier besteht also die Aufgabe der Klassifizierung von Pro-jekten sowie die der Festlegung von Vorgaben für diese Projekttypen.

� 4.5 Migration von Legacy-Systemen

Ziel dieses Abschnitts ist es, den Zusammenhang zwischen Evolution von Systemen und deren Architektur aufzuzei-gen. Dieser Abschnitt erhebt keinesfalls Anspruch auf Voll-ständigkeit, sondern kann und will nur auf Evolutionsas-pekte aufmerksam machen, welche auf den folgenden grundsätzlichen praktischen Erfahrungen basieren.Wandel ist unvermeidlich, wenn Systeme nützlich bleiben sollen. Dies sollte in die Architekturüberlegungen bereits einfließen.

� Es existieren verschiedene Arten von Evolution, die wesentlichen Einfluss auf den Entwicklungsprozess haben, denn Systeme können instand gehalten und erweitert werden, re-engineert oder ersetzt werden.

� Wandel betrifft insbesondere auch die Architektur eines Systems und dessen Kontext.

� Alle wesentlichen Entscheidungen werden auf Grund von entweder expliziten Architekturen oder impliziten Architekturannahmen getroffen.

4.5.1 Evolution

Die Erfahrung zeigt, dass die einzige Konstante die Veränderung ist. Von Systemen wird Flexibilität erwartet, also die Anpassbarkeit an neue Anforderungen. Moderne agile und iterative Entwicklungsprozesse tragen dazu bei. Feedback aus dem operativen Einsatz ermöglicht es, Sys-teme an neue Bedingungen anzupassen, Anforderungen zu validieren. Diese Flexibilität bedeutet aber auch, dass die Architekturbeschreibungen dieser Systeme aktuell gehalten werden sollten.

Jede Änderung eines Systems hat Auswirkungen, oft nicht nur erwünschte. Mit Änderungen geht ein Anstieg der Komplexität einher. Deshalb ist der explizite Umgang

mit Änderungen und Flexibilitätsanforderungen in einer vollständigen Architekturbeschreibung durch eine Evolu-tionsperspektive dargestellt.

Die Rahmenregelung Architekturbearbeitung versteht unter einer Architektur eine Abbildung der grundlegen-den Strukturen eines komplexen Sachverhaltes. Diese Abbildung hält semi-formal einige Aspekte des Sachver-haltes fest. Diese Aspekte umfassen sowohl Basisprinzi-pien wie Meta-Modelle als auch verschiedenste Perspekti-ven wie Sicherheit, Leistung, Verfügbarkeit und Evolution, die in mehreren, voneinander abhängigen und sich ergän-zenden Sichten (Views), wie beispielsweise funktionelle Sichten, Informationssichten, Realisierungssichten oder operationelle Sichten, dargestellt sind. Ziel einer Architek-tur ist der effektive Entwurf, die Beschreibung, die Analyse und auch insbesondere die Evolution immer komplexer werdender Systeme.

Legacy-Systeme sind etablierte, historisch gewachsene Systeme. Sie sind Vermächtnisse, Hinterlassenschaften oder auch Altlasten innerhalb einer Systemlandschaft. Oft sind es Individualentwicklungen, die sich durch unzurei-chende Dokumentation, veraltete Konzeptionen, ältere Betriebs- und Entwicklungsumgebungen, zahlreiche Schnittstellen und hohe Komplexität auszeichnen. Und genau diese Merkmale sind der Grund dafür, dass sich die Ablösung solcher Systeme oft deutlich über ein erwünsch-tes Lebensende hinauszieht, denn die mit einer Ablösung verbundenen hohen Ausfallrisiken bzw. Umstellkosten lassen sich schwer abschätzen.

Grundsätzliches Problem bei der Ablösung von Legacy-Systemen ist der gewachsene Funktionsumfang. Auch wenn recht häufig ein weiträumiger Ersatz durch Standards stattfindet, verbleiben meist nicht abgedeckte und oft nicht in einer Architektur festgehaltene Zusatz-funktionen. Das sind manchmal Alleinstellungsmerkmale der gewachsenen und über Jahre entwickelten Systeme. Der Einsatz serviceorientierter Architekturen bietet hier sinnvolle Ansätze, die Komplexität durch Kapselung zu handhaben. Diese Ansätze basieren auf einer Vervollstän-digung, Einbettung oder Aktualisierung der Architektur.

Migration ist die Änderung oder Erneuerung eines wesentlichen Teils eines eingesetzten Systems und damit auch der Architektur, beispielsweise unter Ver-wendung neuerer Technologien beziehungsweise neuer Infrastrukturen.

Analyse und Dokumentation von Evolutionsaspekten sind deshalb wesentliche Bestandteile einer Architektur, die effektive Migrationsentscheidungen und effiziente Weiterentwicklungen ermöglichen.

Die Evolutionsperspektive einer Architektur fokussiert die Flexibilität eines Systems. Diese Perspektive ist insbeson-dere für Systeme mit langen Lebenszeiten wichtig. Dabei spielen Faktoren wir Fortschritt, Häufigkeit der Änderun-gen, Art der zu erwartenden Änderungen, die Zeitskala und die zu erwartenden beziehungsweise aufgetretenen Änderungskomplexitäten eine wesentliche Rolle.

Es ist unerlässlich, zu erwartende Evolutionsbedürfnisse bereits beim ersten Entwurf und auch bei der Fortschrei-bung einer Architektur zu berücksichtigen und über die Evolutionspfade eines Systems kontinuierlich weiterzu-führen und immer wieder neu zu bewerten, um geeignete Migrationsstrategien ableiten zu können. Das erfordert insbesondere eine kontinuierliche Pflege, Überarbeitung und Kommunikation der Architektur.

4.5.2 Migrationsstrategien

Legacy-Systeme haben den Ruf, potenziell problematisch zu sein. Sie sind oft veraltet, in der Regel langsam, funk-tionell weit hinter dem Stand der Technik, haben meist schlechten Support und weisen grobe Sicherheitsmängel auf. Jedes operative Softwaresystem unterliegt jedoch Änderungen, um nützlich zu bleiben.

Legacy Systeme sind schwer zu erhalten, zu verbessern, zu erweitern und abzusichern, da oft ein profundes Verständ-nis des Systems fehlt – keine dokumentierte Architektur – oder diese aufwendig zu erarbeiten ist – unvollständige oder unverständliche Architektur. Trotz dieser Probleme

gibt es auch Argumente für die Beibehaltung eines Legacy-Systems, wie beispielsweise:

� Die Kosten für die Neugestaltung des Systems sind untragbar.

� Das System erfordert eine hohe Verfügbarkeit. � Es bestehen Defizite beim Verständnis der

Funktionalität. � Das System arbeitet zufriedenstellend, und man sieht

keinen Grund für einen Wechsel.

Wenn ein Legacy-System nicht ersetzt werden kann, ist es noch immer möglich, es im Rahmen der von der Umge-bung definierten Grenzen zu verbessern. Die Verbesse-rung wie auch die Umgebung unterliegt wieder einer Evolution, die eine vollständige Architektur berücksichtigt.

Die Integration von sich unter einem Veränderungspro-zess befindlichen Legacy-Komponenten ist komplex. Oft werden deshalb Virtualisierungs-Technologien oder andere Architektur-Maßnahmen vorgesehen, die es ermöglichen, ein Legacy-System in einer veränderlichen Umgebung zu betreiben. Viele andere der nicht-funk-tionellen Eigenschaften lassen sich durch Architektur-Maßnahmen erfüllen. Umgekehrt erschweren gerade bei Legacy-Systemen einige Architektureigenschaften das Erfüllen nicht-funktionaler Anforderungen.

Eine interessante Fragestellung bei einem Legacy-System ist die Reflexion darüber, was es zu einem Legacy-System macht und warum es so langlebig ist. Trend-Technologien sind oft flüchtig. Architekturelle Prinzipien sind dauer-hafter. Die Beantwortung, warum eine solide Architektur, wie die eines Legacy-Systems, längere Zeit bestanden hat, hilft kostspielige und risikoreiche Fehlinvestitionen zu ver-meiden. Häufig sind Legacy-Systeme gerade diejenigen, die für einen Anwendungsfall wesentliche Architektur-Prinzipien stringent und methodisch realisieren.

Systeme sind Betriebsvermögen; Organisationen investieren in die Anpassung und Änderung dieser Systeme, um ihren Wert zu erhalten. Ein Großteil eines Software-Haushalts geht deshalb in der Aufrechterhal-tung bestehender Legacy-Systeme auf. Wenn eine einzige Organisation verantwortlich für die Entwicklung ist,

wird Evolution berücksichtigt. Bei Individualentwicklung geht diese Verantwortung zumindest teilweise auf den Kunden über, der sich dessen bewusst sein sollte, denn die Fähigkeit zur Evolution ist oft eine Architektureigenschaft, die am Anfang des Lebenszyklus festgelegt wird. Eine die Evolutionsperspektive berücksichtigende Architekturbe-schreibung ist dann klärend. Das gilt insbesondere wenn mehrere Parteien für die Evolution verantwortlich sind.

Häufig kommen Diskontinuitäten in der Evolution von langlebigen Systemen vor, da Architekturbeschreibungen nicht weitergegeben werden und sich die betroffenen Parteien restrukturieren. Unternehmen können fusionie-ren oder umstrukturieren etc.

Abbildung 4.5-1: Entwicklungsspirale

Software-Pflege und -Änderung

Software-Pflege und -Änderung oder auch Software-War-tung ist der allgemeine Prozess der Veränderung eines Sys-tems, nachdem es ausgeliefert wurde. Änderungen kön-nen einfache Korrekturen, umfangreichere Änderungen, wie Re-Designs, oder erhebliche Verbesserungen sein, wie das Korrigieren der Spezifikation oder das stete Einbringen neuer Anforderungen. Änderungen werden durch Ände-rung bestehender Komponenten und, soweit erforderlich, durch Hinzufügen neuer Komponenten durchgeführt. Es gibt drei verschiedene Arten von Wartung:

� Korrektur von funktionalen und sicherheitstechni-schen Software-Fehlern,

� Anpassung der Software an eine andere Umgebung, � Ergänzen oder Ändern von Funktionalität.

Alle Arten erfordern ein konsistentes Weiterführen der Architektur. Wartungsaktivitäten sind im Vergleich zu Entwicklungsaktivitäten aufwendig. Das Hinzufügen weiterer Funktionen, nachdem das System in Betrieb ist, birgt mehr Kosten als die Umsetzung der gleichen Funktionalität während der Entwicklungsphase. Das Weiterführen der Architektur reduziert die Kosten, indem die strukturelle Komplexität fokussiert und ein profundes Verständnis des Systems begünstigt wird.

Re-Engineering und Reverse Engineering

Entwicklungs-Prozesse unterscheiden sich erheblich durch die Verfahren, die in einer Organisation etabliert sind und den Menschen, die in den Prozess eingebunden sind. Evolution kann ein Prozess sein, bei den Ände-rungsaufträgen aus Gesprächen zwischen Nutzern und Entwicklern resultieren, die wiederum in der Architektur formalisiert werden.

Abbildung 4.5-2: Entwicklungszyklus

Der Entwicklungsprozess umfasst die in den Abbildungen dargestellten grundlegenden Aktivitäten für alle Lebens-phasen eines Systems.

Specification Implemention

ValidationOperation

Release 1

Release 2

Release 3

Change proposalNew system

Change indentificationprocess

Software evolutionprocess

Releaseplanning

Changeimplementation

Systemrelease

Impactanalysis

Changerequest

Platformadaptation

SystemenhancementFault repair

Abbildung 4.5-3: Evolutionsprozess

Viele Systeme, insbesondere ältere Legacy-Systeme, sind prinzipiell schwer zu verstehen, schwer in moderne Architekturen einzubetten oder schwer zu ändern. Oft sind diese Systeme meist auf Kosten der Verständlich-keit optimiert. Häufig haben sie im Laufe der Zeit eine Reihe von architekturzerstörenden Änderungen erfah-ren. Wird die Architektur gepflegt, so bleibt das System weiterentwicklungsfähig.

Ist die Architektur nicht mehr verfügbar, kann ein Legacy-System zur Änderung, zur Analyse und zur Verbesserung der Struktur und Verständlichkeit re-engineered werden. Re-Engineering bezeichnet eine Anpassung eines Soft-waresystems bei meist gleichbleibender Funktionalität, oft unter Verbesserung der Softwarequalität. Eine typi-sche Motivation bei Durchführung eines Re-Engineering ist die Eliminierung von Schwachstellen mit dem Ziel, die Umsetzung neuer Anforderungen zu ermöglichen. Die Funktionalität der Software wird dabei im Allge-meinen nicht verändert, jedoch wird eine Architektur dokumentiert.

Der Begriff Re-Engineering ist auch ein Konzept für die durchgreifende Änderung von Geschäftsprozessen. Das Resultat sind Verbesserungen in entscheidenden mess-baren Leistungsgrößen in den Bereichen Kosten, Qualität, Service, Zeit oder Sicherheit.

Abbildung 4.5-4: Forward Engineering vs. Re-Engineering

Für den Fall, dass nur eine unzureichende Architekturdo-kumentation verfügbar ist oder diese aus der Implemen-tierung selbst abgeleitet werden muss, bezeichnet man diesen Prozess als Reverse Engineering, der somit den anfänglichen Teil eines Re-Engineering darstellen kann. Der Begriff Re-Factoring hat eine ähnliche Bedeutung wie Re-Engineering, bezeichnet aber im Gegensatz dazu qualitätsverbessernde Anpassungen auf niedrigerem Abs-traktionsniveau, die sich teilweise automatisieren lassen. Ein Re-Factoring kann somit Teil eines Re-Engineering sein.

Re-Engineering zur Verbesserung der Softwarequalität ist oft erforderlich, um die Qualität und Wartbarkeit von Soft-ware langfristig zu gewährleisten, da in vielen Fällen im

Re-engineeredsystem

Understanding and transformation

Existingsoftware

systemSoftware re-engineering

Newsystem

Design andimplementation

Systemspecification

Forward engineering

Laufe der Zeit die Softwarequalität auf Grund vieler durch-geführter funktioneller Anpassungen schwindet. Dies wird auch "Aging" genannt. Re-Engineering eines Systems hat zwei wesentliche Vorteile gegenüber radikaleren Ansätzen wie Neuimplementierung

� Es besteht kein hohes Risiko durch fehlerhafte Spezi-fikation oder unvorhersehbare Verzögerungen bei der Wiederherstellung von Software.

� Die Kosten für Re-Engineering sind oft erheblich klei-ner als die Kosten für eine Neuentwicklung.

Die kritische Entscheidung zwischen Re-Engineering und Neuentwicklung ist eine typische architekturbasierte Entscheidung.

Damit ein re-engineertes System mit neuer Soft-ware interagieren kann, ist oft die Entwicklung von

Komponenten-Adaptern erforderlich. Die Adapter haben die Aufgabe, das Legacy-System funktionell zu abstra-hieren und in die neue umgebende Architektur durch adäquat strukturierte Schnittstellen einzubetten.

Die Kosten für Re-Engineering hängen von dem Ausmaß der erforderlichen Arbeit ab, die durchgeführt werden muss. Leider ist dieses Ausmaß schwer schätzbar und unterliegt vielen Faktoren, wie Verfügbarkeit von Know-how Trägern, der verwendeten Technologie und deren Fortschritt, Änderung der Umgebung insbesondere der Infrastruktur, Historie der Erweiterungen etc. Es existiert ein Spektrum möglicher Ansätze zum Re-Engineering. Die Kosten steigen in der Grafik von links nach rechts. Quellcode-Übersetzung ist die günstigste Option. Re-Engineering ist die teuerste.

Reverseengineering

Programdocumenation

Data re-engineering

Original data

Program structureimprovement

Programmodularisation

Structuredprogram

Re-engineereddata

ModularisedprogramOriginal program

Source codetranslation

Automated restructuringwith manual changes

Automated sourcecode conversion

Restructuring plusarchitectural chnages

Automated programrestructuring

Program and datarestructuring

Increased costs

Abbildung 4.5-5: Ein Engineering-Prozess

Abbildung 4.5-6: Re-Engineering Spektrum

Der größte Nachteil von Re-Engineering ist, dass es für Verbesserungen praktische Grenzen gibt. Es ist nicht möglich, beispielsweise ein System mit einer funktionalen Architektur oder einer logikbasierten Architektur in ein objektorientiertes System zu konvertieren.

Unternehmenskritische Legacy-Systeme werden jedoch verwendet, erweitert und an die sich verändernden Geschäftsprozesse angepasst. Organisationen, die ein begrenztes Budget für die Erhaltung und Modernisie-rung ihrer Legacy-Systeme haben, sind mit der Aufgabe konfrontiert, zu entscheiden, wie man die Investition in die Legacy-Systeme erhält. Dies bedeutet, dass sie zu einer realistischen Einschätzung ihrer Legacy-Systeme kommen müssen, um dann zu entscheiden, welches die am besten geeignete Strategie für die Weiterentwicklung dieser Sys-teme ist. Die Alternativen lassen sich in vier wesentliche strategische Optionen unterteilen:

� Das System außer Betrieb nehmen. Diese Option sollte gewählt werden, wenn das System keinen oder nur geringe Beiträge zu Geschäftsprozessen leistet. Dies geschieht, wenn sich Geschäftsprozesse geän-dert haben und das System sich nicht mehr an die geänderten Umstände anpassen lässt.

� Das System unverändert lassen und die Wartung fort-setzen. Diese Option sollte gewählt werden, wenn das System zur Aufrechterhaltung von Geschäftsprozes-sen erforderlich ist und relativ stabil ist. Ein Indikator für diese Option ist, dass die Nutzer wenig Kritik äußern und kaum Änderungswünsche haben.

� Re-Engineering zur Verbesserung der Wartbarkeit. Diese Option sollte gewählt werden, wenn die Qua-lität des Systems degradiert ist, wie beispielsweise durch regelmäßige Veränderungen. Regelmäßige Anpassungen des Systems werden nach wie vor erforderlich sein, diese werden jedoch nach dem Re-Engineering einfacher.

� Ersetzen des ganzen Systems oder von Teilen des Systems durch ein neues System. Diese Option sollte gewählt werden, wenn andere Faktoren, wie neue Architekturen, es erfordern, das System tiefgreifend zu ändern und eine Neuentwicklung einfacher und kostengünstiger ist oder wenn das alte System nicht mehr den Betrieb sichern kann. In vielen Fällen ist

eine evolutionäre Strategie möglich, bei der wichtige Komponenten wiederverwendet werden.

Bei der Beurteilung eines Legacy-Systems ist es erforder-lich, zumindest eine Geschäftsprozess-Perspektive und eine technische Perspektive der Architektur zu konsul-tieren. Die Kombination aus geschäftlichem Wert und der Qualität des Systems ist die Basis einer fundierten Entscheidung darüber, was mit dem Altsystem geschehen soll. Zur Veranschaulichung kann die Qualität und der geschäftliche Wert eines Systems in einem Diagramm visualisiert werden.

Abbildung 4.5-7: Qualität vs. geschäftlicher Nutzen

In der Abbildung kann man sehen, dass es vier Quadranten gibt:

� Niedrige Qualität, niedriger geschäftlicher Nutzen: Solche Systeme in Betrieb zu halten ist teuer. Diese Systeme sollten außer Betrieb genommen werden.

� Niedrige Qualität, hoher Geschäftswert: Diese Sys-teme leisten einen wichtigen Beitrag. Sie sollten nicht außer Betrieb genommen werden. Dennoch bedeutet ihre niedrige Qualität, dass es teuer ist, sie zu erhalten. Diese Systeme sollten re-engineert werden.

� Hohe Qualität, niedriger geschäftlicher Nutzen: Das sind Systeme, die nicht viel beitragen, und es ist nicht

System quality

High business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality

sehr teuer sie zu warten. Normale Wartungsarbeiten an solchen Systemen können fortgesetzt werden, solange keine teuren Änderungen erforderlich sind.

� Hohe Qualität, hoher Geschäftswert: Diese Systeme müssen in Betrieb bleiben und ihre hohe Qualität bedeutet, dass sich Investitionen in die Umgestaltung rechnen. Normale Wartungsarbeiten am System soll-ten fortgesetzt werden.

Zur Beurteilung des geschäftlichen Nutzens eines Systems sollte identifiziert werden, wie die Anwender das System konkret benutzen. Zur Beurteilung, ob ein Software-System aus technischer Perspektive noch ver-tretbar ist, ist es erforderlich, sowohl das System selbst als auch die Umgebung, in der das System betrieben wird, zu betrachten.

Die Beantwortung dieser Fragen sollte durch objektive Beobachtungen des Systems, der Instandhaltungspro-zesse und nicht zuletzt der Architektur belegt sein.

Im Idealfall führt eine objektive Bewertung zu einer begründeten Entscheidung, was mit einem Legacy-Sys-tem geschehen soll. In die letztendlichen Entscheidungen fließen auch organisatorische oder politische Erwägun-gen mit ein.

4.5.3 Résumé

Architektur subsumiert eine Struktur oder Strukturen, die es erlauben, von außen sichtbare Eigenschaften zu planen, siehe www.sei.cmu.edu/architecture/definitions.html

Es gibt verschiedene Arten von Evolution mit unter-schiedlicher Tiefe. Bei individuellen Systemen übersteigen die Kosten für die Wartung in der Regel die Kosten der Software-Entwicklung. Als investitionsschützende Maß-nahme sollte Evolution in der Architektur berücksichtigt werden und die Architektur sollte fortgeführt werden.

Der Prozess der Software-Entwicklung hat durch Feed-backschleifen einen evolutionären Charakter. Manchmal

rechnet sich Reverse-Engineering, um Architekturdoku-mentationen zu erarbeiten, die Legacy-Systeme ver-ständlicher machen und um sie dann leichter ändern zu können. Der geschäftliche Nutzen eines Legacy-Systems und seine Qualität hängen stark von der Umgebung ab. Qualitäten werden durch eine Architekturbeschreibung objektiviert und messbar.

4.5.4 Literatur

Systematische Evolutionsansätze findet man unter dem Begriff "Refactoring" beispielsweise in Fowler et al., Refac-toring. Die Evolution unterstützende Meta-Model basierte Architekturen werden beispielsweise in Buschmann et al., Pattern oriented Software Engineering, beschrieben. Bass et al., Software Architecture in Practis, bietet Evolution unterstützende Tactics an. Architekturen für Produktlinien findet man dort ebenfalls. Clements et al., Evaluating Software Architectures, gibt Anleitung zur Evaluation von Architekturen auch bezüglich Evolution (dort Main-tenance). Seacord et al., Modernizing Legacy Systems, beschreibt Architekturkriterien für einen Evolutionspro-zess speziell für Legacy-Systeme.

� http://www.kbst.bund.de/nn_836802/Content/Soft-ware/Migration/migration__node.html__nnn=true

� http://esj.com/news/article.aspx?EditorialsID=1529 � http://en.wikipedia.org/wiki/Legacy_system � http://de.wikipedia.org/wiki/

Kategorie:Softwarearchitektur � http://scholar.google.de/scholar?hl=de&lr=&q=archit

ecture+migration+legacy&btnG=Suche&lr= � http://www.comp.lancs.ac.uk/computing/resources/

IanS/SE7/Presentations/index.html

� 4.6 IT-Sicherheit

Aus Sicht der Auftragnehmerseite werden Architektur-entwicklungen im Allgemeinen nach etablierten Standards / Modellen durchgeführt (z. B. Engineering Standards, Vorgehensmodell, Zertifizierungsstandards, usw.). Jeder Entwicklungsstandard besitzt grundsätzlich mindestens ein Referenzmodell für die IT-Sicherheit, in

dem Prozessschritte für die Prüfung und Bewertung der IT-Sicherheit definiert sind (siehe z. B. V-Modell-XT). In diesen Prüfungen und Bewertungen erfolgen Systemtests, Sicher-heitsaudits, Evaluationen, Vertrauenswürdigkeitsnach-weise sowie Dokumentationen zur Erfüllung der IT-Sicher-heitsanforderungen aus dem IT-SichhKProj. Der Gebrauch von Referenzmodellen trägt zur Nachvollziehbarkeit und Objektivität bei, ist aber für sich allein in Bundeswehr-Entwicklungsprojekten nicht ausreichend. In der Regel wird seitens der Bundeswehr eine unabhängige Analyse des Architekturkonzepts sowie der zu erstellenden Hard- und Software gefordert. In dieser unabhängigen Analyse erfolgen neben dem Nachweis der funktionalen Erfüllung der IT-Sicherheitsanforderungen auch eine Bewertung der erforderlichen Vertrauenswürdigkeit sowie ein Wirksam-keitsnachweis zum Schutz von Werten vor Bedrohungen. Grundsätzlich sind hier alle Arten von Bedrohungen zu berücksichtigen (Bedrohungen, die in der Architektur über-sehen wurden, können im daraus resultierenden System zu Schwachstellen werden). Die Wirksamkeit der vorge-sehenen Schutzmaßnahmen ist dabei nachzuweisen. Dies kann beispielsweise in Form von Zertifizierungen auf organisatorischer Ebene (z.B. ISO27001) oder technischer Ebene (z. B. ÖNORM A 7700) geschehen. Die Untersu-chungsschwerpunkte bei Architekturentwicklungen liegen im Allgemeinen in den Bereichen:

� Sicherstellung der Vertraulichkeit, Verfügbarkeit und Integrität von Informationen und Daten,

� Berechtigungskonzept und � Zugriffskontrollfunktionen.

Neben diesen Nachweisen sind im Verteidigungsbereich ggf. verschiedene Abnahmeprüfungen (z. B. Einsatzprü-fungen, Sicherheitsaudits, Prüfungen im Einsatzumfeld, usw.) bis zur Freigabe zur Nutzung vorgesehen. Dabei sind im Allgemeinen unterschiedliche Zuständigkeiten und Verantwortlichkeiten zu beachten. Zulassungen werden durch Zulassungsbehörden erteilt. Zulassungsbehörde der NATO ist das „NATO Military Committee (MC)“ mit der „Military Committee Communications and Information Systems Security and Evaluation Agency (SECAN)“ als Evaluierungsstelle. Bei nationalen Zulassungen ist das Bundesamt für Sicherheit in der Informationstechnik (BSI) zuständig.

Sicherheit von Webapplikationen

Schwachstellen in Webanwendungen stellen laut der international anerkannten SANS Top-20-Liste über Sicher-heitsrisiken (Stand 9. März 2009) mit Abstand die größte Server-seitige Bedrohung dar. Die Ursache liegt dabei meist in der unsicheren Architektur und Umsetzung von Webanwendungen. Dass mit Angriffen wirklich gerechnet werden muss, zeigen zahlreiche Vorfälle, wie beispiels-weise der im April 2007 durchgeführte großflächige Angriff auf Estland, bei dem die Seiten der estnischen Regierung, verschiedener Parteien, Banken und Zeitun-gen über längere Zeit offline gingen, der im August 2008 erfolgte Angriff auf Georgien oder der im Januar 2009 durchgeführte Angriff auf drei von vier Providern des Landes Kirgistan.

Um Schwachstellen vorzubeugen, muss der Aspekt Sicherheit bereits in die Architektur der Webanwendung integriert werden. Standards, die in dieser Phase unter-stützen, sind die BSI-Schriftenreihe zur Internetsicherheit (ISi-Reihe) und die ÖNORM A 7700 mit Anforderungen an sichere Webanwendungen. Das Ziel der ISi-Reihe ist es, Behörden und Unternehmen aktuelle und umfassende Informationen zum Thema Internetsicherheit bereitzu-stellen. Für die Entwicklung von Webanwendungen sind vor allem die beiden Module „Sicheres Bereitstellen von Web-Angeboten (ISi-Web-Server)“ und „Sichere Nutzung von Web-Angeboten (ISi-Web-Client)“ von Bedeutung. Ein Modul besteht jeweils aus einer ISi-Studie, welche die detaillierte Ausarbeitung des Moduls enthält, einer ISi-Leitlinie, welche die Studie in groben Zügen zusam-menfasst und ISi-Check Checklisten zur Kontrolle der Umsetzung einzelner Punkte. Die Module beschreiben die Architektur, die sichere Konfiguration und den sicheren Betrieb von Webanwendungen, inklusive einer Auflis-tung von verschiedenen möglichen Gefahren sowohl für normalen, als auch für hohen Schutzbedarf. Ergänzend zur ISi-Reihe stellt die ÖNORM A 7700 eine zertifizier-bare Norm für die Sicherheit von Webanwendungen im EU-Raum dar. Die Norm stellt verschiedenste Anforde-rungen an sichere Webapplikationen, um bestmögliche Sicherheit der Anwendungen nach dem Stand der Technik zu garantieren. Diese Anforderungen sind bereits bei

der Architektur von Applikationen zu beachten, um den Anforderungen der Bundeswehr gerecht zu werden. Der Einsatz der ÖNORM A 7700 wird jedoch nicht nur bei der Architektur von einfachen Webanwendungen, sondern auch für Web Services empfohlen. Besonders beim Einsatz von serviceorientierten Architekturen (SOA) wird vermehrt auf Web Services gesetzt, welche ebenfalls ent-sprechend der Sicherheitsvorgaben der ÖNORM A 7700 abzusichern sind. Nur so kann den strengen Richtlinien für Umgebungen mit hohem Schutzbedarf entsprochen werden.

Die ÖNORM A 7700 beinhaltet folgende Kapitel, welche alle entsprechend in die Planung und Entwicklung von Webanwendungen oder Web Services einfließen müssen:

� Architektur der Webapplikation � Datenspeicherung und Datentransport � Konfigurationsdaten � Authentifizierung � Authentifizierungsmethoden � Passwörter � Autorisierung � Sitzungen � Separierung durch Sitzungen � Qualitätskriterien für Sitzungen � Behandlung von Benutzereingaben � Dateigenerierung � Speichermanagement � Einbinden von Ressourcen � Behandlung von Datenausgaben � Hintergrundsysteme � System- und Fehlermeldungen � Kryptographie

Es ist wichtig diese Punkte bereits bei der Entwicklung des Architekturkonzeptes zu besprechen, um zum einen Sicherheit bereits vollständig in die Anwendung integrie-ren zu können und zum anderen, um eventuell alternative Architekturvarianten, wie beispielsweise einzelne Kom-ponenten zu zentralisieren, besprechen zu können. Diese Varianten müssen wieder hinsichtlich ihrer Sicherheitsan-forderung und ihres Schutzbedarfs evaluiert werden.

Ist bereits ein Standard zum Management von Infor-mationssicherheit, wie z.B. ISO 27001, etabliert, so stellt die ÖNORM A 7700 eine wertvolle Ergänzung zu diesem Standard dar. So verlangen beispielsweise die Controls „A10.4.1 – Controls against malicous Code“, „A12.2.1 – Input data validation“ und „A10.5.4 – Information Leakage“ nach effektiven Maßnahmen zur Absicherung der Web-anwendung, welche durch die ÖNORM A 7700 abgedeckt werden. Zudem wird in der ISO 27001 per Control „A10.2.2. – Monitoring and review of third party services“ nach eine Überprüfung von Diensten von Drittherstellern verlangt. Durch die Definition von Anforderungen an sichere Webanwendungen und Web Services und die mögliche Zertifizierung ist eine Überprüfung nach ÖNORM A 7700 bereits bei der Beschaffung für Applikationen mit norma-lem Schutzbedarf empfohlen und mit hohem Schutzbe-darf vorgeschrieben. Der Anbieter muss dabei Nachweise erbringen, die Anforderungen, die durch die Norm gestellt werden, zu erfüllen.

5 Erarbeitung von IT-Architekturen

� 5.1 Architektur-Vorbereitung

5.1.1 Ermitteln der Verwendungsabsicht

Warum soll eine Architektur entwickelt werden? Es wurde bereits festgestellt, dass ein System immer eine Architek-tur hat und im Sinne einer systematischen Systement-wicklung die IT-Architektur im Vorfeld einer Realisierung geplant sein sollte. Nun ist die Planung einer IT-Architek-tur nicht immer das Ziel einer Architekturentwicklung. Dazu sind bereits Ausführungen im Kapitel 3 und im Kapi-tel 4 enthalten. Hier bietet sich eine Unterstützung der Vorbereitung zur Architekturentwicklung in Form einer Checkliste an. Dafür ist es notwendig die möglichen Ziele der Architekturentwicklung zu kategorisieren.

Eine Kategorisierung könnte im einfachsten Fall wie folgt aussehen, um daraus Festlegungen für die Architekturent-wicklung abzuleiten:

� BereichA. Unterstützung konzeptioneller Arbeit, B. Unterstützung operationeller Planung,C. Unterstützung der Bedarfsermittlung und

-deckung nach CPM. � Teilbereich

1. Dokumentation2 Identifikation von Anforderungen3. Ableitung von Forderungen4. Machbarkeitsuntersuchung5. Problemanalyse6. Interoperabilitätsplanung7. Systemplanung8. Migrationsplanung 9. Überwachung von Strategien10. Überwachung von Kosten

5.1.2 Ermitteln der Ausgangsbasis

Im nächsten Schritt muss die Ausgangsbasis für die Architekturentwicklung festgelegt werden. Warum? Zunächst einmal wird die Architektur für ein bestimm-tes Ziel entwickelt. Um das Ziel zu erreichen, muss man die Ausgangssituation (Basiszustand) definiert haben. Die Ausgangsbasis enthält alle inhaltlichen Anforderun-gen an die Architektur und wird für die Bewertung der Architektur benötigt. In einem Critical Design Review wird gemessen an einer Menge von Anforderungen die Architektur bewertet.

Je besser die Ausgangsbasis ermittelt wird, desto besser ist die Planbarkeit der Architekturentwicklung und desto wahrscheinlicher ist es, dass das Ziel der Architekturent-wicklung auch erreicht wird.

Was heißt nun Ermitteln der Ausgangsbasis, und wie sollte man vorgehen? Das Ermitteln der Ausgangsbasis ist die Erstellung einer inhaltlichen Anforderungsliste an die Architektur. Diese Anforderungsliste enthält Anfor-derungen über die Informationen, die verarbeitet bzw. berücksichtigt werden müssen. Hier kann ebenfalls eine Checkliste helfen, um diesen Prozess zu unterstützen.

Eine Checkliste könnte im einfachsten Fall eine Frageliste sein: 1. Setzt die Architekturentwicklung auf eine bestehende

Architektur auf?i. Wie heißt die Architektur?ii. Ist diese Architektur verfügbar?iii. Soll die Architektur weiterentwickelt werden?iv. Sollen die Inhalte der Architektur in der neuen

Architektur berücksichtigt werden?v. Warum setzt die Architekturentwicklung auf einer

bestehenden Architektur auf?

2. Setzt die Architekturentwicklung auf ein bestehendes Dokument auf? [Fragen i. bis v. analog zu 1) für Dokument]

3. Gibt es Schnittstellen zu bestehenden Architekturen?i. Wie heißen die Architekturen?ii. Stehen diese Architekturen zur Verfügung?iii. Sollen die Schnittstellen berücksichtigt werden?iv. Warum sollen die Schnittstellen berücksichtigt

werden?4. Gibt es Dokumente die inhaltlich zur Architekturent-

wicklung beitragen können? [Fragen i. bis v. analog zu 3) für Dokument]

5. Müssen Personen befragt werden, um Informationen für die Architekturentwicklung zu erhalten?i. Welche Personen sind das?ii. Welche Personen können Informationen

bereitstellen?iii. Müssen Fragebögen erstellt werden?iv. Müssen Interviews geführt werden?v. Müssen Workshops durchgeführt werden?vi. Muss ein integriertes Entwicklungsteam gebildet

werden?6. Muss ein System oder eine Technik untersucht wer-

den, um Informationen für die Architekturentwick-lung zu erhalten?i. Muss Hardware untersucht werden?ii. Muss Software untersucht werden?iii. Muss ein Protokoll untersucht werden?iv. Muss ein Standard untersucht werden?v. Muss ein COTS, MOTS oder GOTS untersucht

werden?

vi. Sind Eigenentwicklungen zu untersuchen? [Hier sind noch weitere Fragen bzgl. der Komplexi-tät notwendig]

7. Müssen Daten, Datenmodelle oder Funktionen bzw. Services ausgewertet werden, um Informationen für die Architekturentwicklung zu erhalten? [Hier müssen Fragen bzgl. der Komplexität gestellt werden]

5.1.3 Festlegen des Abstraktionsgrades

Zur Festlegung des Abstraktionsgrades muss zunächst eine Kategorisierung erfolgen. Dann wiederum kann durch die Checklisten aus den Kapiteln 5.1.1 Ermitteln der Verwendungsabsicht und 5.1.2 Ermitteln der Ausgangs-basis eine Festlegung des Abstraktionsgrades durch Zuordnung der Ergebnisse zu den Kategorie in einer Matrix erfolgen.

In der Praxis hat sich gezeigt, dass Abstraktionsgrade wie „Overarching“, „Reference“ und „Target“ nur bedingt geeignet sind, um Festlegungen zu treffen. Dies liegt in erster Linie daran, dass mit diesen Kategorien nur ein Ver-ständnis vermittelt wird, aber keine expliziten Anforde-rungen an die Architekturentwicklung. Diese Festlegung ist aber notwendig, um ein einheitliches Ergebnisbild bezogen auf eine Kategorie zu erhalten. Da einige Begriffe aber belegt sind, ohne konkrete Anforderungen zu erhal-ten, werden hier neue Begriffe vorgeschlagen, zu denen dann eine Zuordnung zu bestehenden Begriffen erfolgen kann.

Abstraktionsgrad Architekturtyp nach NAF

Anforderungen

Big Picture Architecture - Darstellung der Zielvorstellung in einer Grafik.

Full Scope Architecture Overarching Architecture Die operationelle Sicht beschreibt alle operationellen- / Geschäftsprozesse einer Organisation in den ausgewählten Aspekten bis auf 1. Gliederungsebene. (z.B. Wenn der Scope ein Bataillon umfasst, dann sind alle Kompanien und der Bataillonsstab zu betrachten).Abzubildende Systeme werden bis auf Ebene von Systemen (siehe V-Modell XT <<System>>) modelliert.

Spotlight Architecture Reference Architecture - (keine Vorgaben)

System Type Architecture Reference Architecture Das abzubildende System muss bis auf Ebene von Segmen-ten (siehe V-Modell XT <<Segment>>) modelliert sein. Jedes Segment kann nur einmal als Typ vorkommen. D.h. Konkrete Ausprägungen spielen keine Rolle.Die operationelle Sicht muss alle operationellen- / Geschäfts-prozesse in den ausgewählten Aspekten abbilden, die das System unterstützen soll.

System Architecture Target Architecture Das abzubildende System muss bis auf Ebene von Kompo-nenten (siehe V-Modell XT, z.B. <<SWK>>) modelliert sein.Die operationelle Sicht muss das Rollen und Nutzungskon-zept abbilden.

Tabelle 5.1-1: Abstraktionsgrade von Architekturen

5.1.4 Festlegen der Methodik (Methodische Vorgehensweise)

Wie bereits erläutert wurde, spezifiziert das Architektur-rahmenwerk NAF eine Organisationsstruktur von Archi-tekturinformationen und liefert damit einen Rahmen für das Beschreiben von Architekturen.

Die Festlegung der Methodik für das Entwickeln von IT-Architekturen wird durch diesen Rahmen beeinflusst, ist aber nicht notwendigerweise ein Teil dieses Rahmens.

Die Methodik als die „Lehre über die Vorgehensweise“ von wissenschaftlichen Methoden, stellt die Vorgehensweise dar, die von den Architekten angewandt werden, um Architekturen pragmatisch zu entwickeln. Zur Methodik gehören bewährte Praktiken, idealtypische Verfahren, die teilweise wissenschaftlich erarbeitet wurden, teilweise durch praktische Erfahrungen entstanden sind.

Es existiert eine Anzahl unterschiedlichster Vorgehens-weisen, um Architekturen effizient und effektiv im Sinne ihres Verwendungszwecks zu entwickeln.

Die fünf bekanntesten und meist angewendeten metho-dischen Vorgehensweisen für Architekturentwicklung sind neben dem NATO Architecture Framework folgende:

� TOGAF ADM (Open Group Architecture Framework Architecture Development Method) Das TOGAF ADM definiert eine Reihenfolge von acht Prozessphasen, die in den Architekturentwicklungs-prozess integriert werden. Die ADM stellt einen iterativen Prozess dar. Durch die Wiederholung der Prozessschritte werden Detaillierungstiefe erhöht, Produkte und Informationen hinzugefügt.

� Boeing/Openwings Die Openwings-Methodologie unterstützt insbe-sondere einen serviceorientierten Architekturansatz. Openwings fokussiert hauptsächlich die Integra-tion von zukünftigen Systemkomponenten und

unterstützt damit ausdrücklich das Wachstum der Interoperabilität eines Systemverbundes.

� META Group and Gartner process model Es handelt sich hier um ein mehrphasiges, iteratives und nichtlineares Modell, das sich auf die Phasen Entwicklung, Weiterentwicklung und Migration, Kont-rolle, Organisation und Management beschränkt.

� DoDAF‘s 6 Step model Ausgehend von dem geplanten Nutzen der Architek-tur, der übergreifenden Zielsetzungen, Rahmenbedin-gungen, Wechselbeziehungen zu anderen Architek-turen wird in einer zweiten Entwicklungsphase der Umfang der Architektur, d.h. der inhaltliche, organi-satorische und zeitliche Rahmen der Architektur fest-gelegt. Nach der Festlegung erforderlicher Informati-onen, dem Sammeln, Abgleichen und Speichern der Architekturdaten wird die Architektur-Qualität gesi-chert. Werden in dieser Entwicklungsphase formale oder inhaltliche Nachbesserung bzw. Ergänzung der Architektur identifiziert, so werden die Prozesse 3-4 (vgl. Abbildung unten) erneut durchlaufen. Am Ende des Entwicklungsprozesses steht die Dokumentation und Publikation der Ergebnisse.

� NC3A/AEM Eine an Zielsetzung und Zeitrahmen orientierte Vorge-hensweise zur Architekturentwicklung ist die Architec-ture Engineering Methodology (AEM). Die AEM wird in erster Linie von Architekten unterschiedlicher Natio-nen angewendet, die im Sinne der NNEC Architekturen für die Entwicklung militärischer Fähigkeiten erarbei-ten. Die AEM unterscheidet Architekturaspekte aus der Perspektive Mission Space, Information Application, Security, Governance und Architecture Engineering Levels (AEL), die durch den Zweck der zu entwickelnden Architektur bestimmt werden. AELs stellen u.a. die Fragen: Welche Aktivitäten müssen durchgeführt wer-den? Welche Strukturen sind dafür erforderlich und welche Systemunterstützung muss dafür implemen-tiert werden? Mittels Kombination aus Architekturas-pekt und AEL werden als erstes Modellierungsraum in den Dimensionen Betrachtungsgegenstand sowie Detail-/Abstraktionsebene festgelegt. Daraus abgelei-tet werden weitere Vorgehensweisen und Methoden festgelegt, die dafür geeignet sind, den Betrachtungs-gegenstand und die gewählte Abstraktionsebene der Architektur abzubilden.

Festlegung der erforderlichen Informationen

Festlegung des geplanten

Nutzens derArchitektur

Festlegung des Umfangs der

Architektur

Sammlung, Organisation,Abgleich und

Speicherung derArchitekturdaten

Qualitäts-sicherung

Dokumentationund Publikationder Ergebnisse

2 3 4 5 6

Abbildung 5.1-1: Six Step Approach.

Die folgende Grafik versinnbildlicht die schematische Zuordnung von Architekturaspekt und AEL:

Abbildung 5.1-2: Architekturaspekt und AEL

5.1.5 Auswahl der Methoden

Nach der Festlegung der Methodik für die Entwicklung der Architektur stellt sich die Frage: Welche Methoden sind geeignet unter gesetzten Rahmenbedingungen, wie z.B. einem begrenzten Zeitrahmen, verfügbarer personel-ler Ressourcen und der vorhandenen Ausgangsbasis (vgl. Kapitel 5.1.2), die gesetzten Architekturziele zu erreichen:

Es gilt also zweckmäßige Methoden einzusetzen, die es ermöglichen, die zu entwickelnden relevanten Architek-turprodukte im Kontext ihrer Verwendungsabsicht unter Berücksichtigung der vorgegebenen Randbedingungen in einer hohen Qualität zu entwickeln. Eine Architek-tur stellt eine Wissensbasis dar. Dieses Wissen muss in den Entwicklungsphasen der angewendeten Methodik generiert, verteilt, genutzt und repräsentiert werden. Die Anwendung entsprechender Methoden unterstützen diese Prozesse.

Bei der Auswahl der Methoden sind insbesondere die Aspekte des Wissenserwerbes, die Darstellung der Inhalte und die Art und Weise der Kommunikation zwischen Architekten und Auftraggebern zu berücksichtigen.

Die nachfolgende Grafik verdeutlicht diese drei grundle-genden Aspekte und ordnet diesen einen Auszug an mög-lichen Methoden zu, die bei der Entwicklung einer Archi-tektur angewendet werden können. Die in der Tabelle aufgeführten Methoden erheben keinen Anspruch auf Vollständigkeit.

Abbildung 5.1-3: Methoden-Informationserfassung-Publizierung

Der Zweck bestimmt die Methode!

5.1.6 Auswahl und Einrichten der Toolunterstützung

Die Auswahl und Einrichtung der Toolunterstützung steht in engem Kontext mit den Zielen, dem Aufbau, den Anfor-derungen und der Umsetzung des sog. Gemeinsamen Werkzeug unabhängigen Repository (GWR) wie sie in der vorläufigen Rahmenregelung zur Architekturerarbeitung und –bearbeitung formuliert sind.

Die Ziele der Nutzung eines Repository zur Erfassung aller Architekturmodelle sind gemäß der Rahmenregelung

� die Weiter- und Wiederverwendung von Architekturen und ihrer Bestandteile;

Functio-nality ?

Construc-tion ?

Implemen-tation ?

Mission Space Information Application

Infrastructure

Security / Governance

RepräsetationInhalte Wissenserwerb Kommunikation

Subviews NAV

Subviews NOV

Subviews NSV

Subviews NSOV

Subviews NCV

Subviews NTV

Interviews

Workshops

Checklisten

Subviews NSOV

Fragenkatalog

Selbststudium

Subviews NPV …

Portal

Protokoll

Workshop

� der Vergleich von Architekturen und ihrer Bestandteile;

� die Nutzung von Erkenntnissen aus Architekturen für nicht-architekturgebundene Anwendungsfälle.

Hieraus abgeleitet ergeben sich die nachfolgenden Anfor-derungen an Modellierungswerkzeuge:

� Der Export und Import aller Inhalte einer Architektur, inklusive der Metadaten, muss möglich sein; dabei ist der Umfang der auszutauschenden Metadaten sowohl für die Architektur als auch für die einzel-nen Objekte einer Architektur noch abschließend festzulegen. Solange eine derartige Festlegung noch nicht erfolgt ist, kommen nur Werkzeuge mit einem flexiblen Datenmodell für die Modellierung in Frage, um mit der Festlegung das Werkzeug anpassen zu können.

� Das im Modellierungswerkzeug eingesetzte Daten-modell muss dem Metamodell des Frameworks grundsätzlich entsprechen, ansonsten ist eine Bereit-stellung der Daten für das Repository nicht werk-zeugunabhängig möglich. Das bedeutet u. a., dass unterschiedliche Objekte einer Architektur im inter-nen, werkzeugabhängigen Repository tatsächlich als unterschiedliche Objekte verwaltet werden müssen.

� Der Export und Import muss über eine standardisierte Schnittstelle erfolgen; die Verwendung einer oder mehrerer möglicher Schnittstellen ist verbindlich festzulegen.

Entsprechend dieser Anforderungen sowie ggf. sich zukünftig ergebendem weiteren Bedarf ist im Kontext der Architekturvorbereitung die Toolunterstützung auszu-wählen und einzurichten.

5.1.7 Festlegen der Konventionen

Im Kapitel 3.6 wurde festgestellt, dass es unabdingbar ist, ein Mindestmaß an übergeordneten Konventionen für eine Architekturfamilie der Bundeswehr festzulegen, um insbesondere Vergleichbarkeit und Wiederverwendbar-keit der Architekturmodelle zu gewährleisten.

Stellt sich die Frage: Warum sollten weitere Konventionen, nachfolgend genannt als Rahmenregelungen Architek-tur für die Entwicklung einer Architektur fixiert werden? Die Beantwortung dieser Frage begründet sich auf zwei wesentlichen Argumenten: 1. Architekturen werden mit unterschiedlichen Ziel-

setzungen, mit unterschiedlichem Sachbezug, mit unterschiedlichen Verwendungsabsichten und Voraussetzungen entwickelt. Die Rahmenregelungen Architektur müssen die Grenzen des Betrachtungs-gegenstandes und die betroffene OrgElemente der Architektur verdeutlichen, bestimmte Sachverhalte und Zusammenhänge müssen im Sinne der Zielset-zung der Architektur durch bestimmte Notationen hervorgehoben werden.

2. Wenn an der Entwicklung der Architektur mehrere Architekten arbeiten, dann bedeutet dies, dass indi-viduelle Auffassungen und Ansichten die Architektur prägen werden. Es werden individuelle Gestaltungs-möglichkeiten erschlossen, die zur Unübersichtlichkeit der Modelle, zu Informationsverschleierung –und verlusten und letztendlich zur Verminderung der Akzeptanz der Methodik führen können.

Aus diesen zwei genannten Aspekten gilt es, Rahmenrege-lungen für die Architektur festzulegen, die

� so wenig wie möglich aber so viel wie nötig verbind-lich regeln,

� die Handlungsspielräume der Architekten nicht unan-gemessen einschränken,

� den Sachbezug und Ziele der Architektur besser verdeutlichen,

� zukünftigen Nutzern helfen, die Inhalte intuitiv und schnell zu erfassen und

� nicht die Konventionen der Bundeswehr verletzen.

Folgende Frageliste leistet bei der Aufstellung von Rah-menregelungen für die Architektur Hilfestellung:

� Welche Sachverhalte, Problemstellungen müssen visuell verdeutlicht werden?

� Welche gestalterischen Mittel sollen eingesetzt werden?

� Wird der Betrachtungsumfang der Architektur visuell verdeutlicht?

� Werden die zu erarbeitenden Architekturprodukte ausreichend durch die Konventionen Bw beschrieben?

� Welche beschreibenden Attribute müssen den Objek-ten zugeordnet werden?

Mit der Beantwortung dieser Fragen wird ein Rahmen abgesteckt, auf dessen Grundlage konkrete Normen für die Architektur festgelegt werden. Diese Rahmenregelun-gen werden in einem Qualitätssicherungsplan dokumen-tiert und stellen zusammen mit den Konventionen der Bw die zu erfüllenden Qualitätskriterien der Architektur dar. Der QS-Plan enthält neben der Darstellung der Vorgehensweise der Qualitätssicherung der Architek-tur und Zuständigkeiten auch die konkreten formalen Qualitätsziele, die sich einerseits aus den Konventionen der Architekturmodellierung der Bw und andererseits aus den spezifischen Vorgaben für eine bestimmte Architektur ergeben. Das Ergebnis der Qualitätssicherung wird in dem NAV-3a Architecture Compliance Statement aufgezeichnet.

5.1.8 Initiieren des Architektur-Managements

Gemäß Rahmenregelung zur Architekturerarbeitung/ -bearbeitung verfolgt Architektur Management das Ziel, praktisch handhabbare Architekturprodukte zu entwi-ckeln, die konsistent, kohärent, vollständig, aktuell und für den jeweiligen Benutzerkreis verständlich sind.

Weitere strategische Ziele, die mit der Etablierung von Architektur Management erzielt werden können, sind:

� Ausrichtung der Unternehmens-IT an den Geschäftsaufgaben,

� Unterstützung des Aufbaus und Umsetzung einer IT-Strategie,

� Darstellung einzelnen Architekturen und deren Zusammenhänge, um die Komplexität beherrschbar zu machen,

� Förderung der Agilität einer Organisation, � Unterstützung bei der Bewertung von IT-Investitionen

um unnötige Investitionen zu vermeiden und

� Hilfe bei der Aus- und Weiterbildung von Personal

Gemäß der Rahmenregelung umfasst Architektur Management alle Aufgaben der zentralen Koordinierung der Modellierung von IT-Architekturen in der Bundeswehr, einschließlich der Auswahl und Regelung der Nutzung der benötigten Werkzeuge. Es besteht dabei aus mehreren Teilaufgaben:

Das organisatorische Architekturmanagement umfasst alle Aktivitäten, die auf die Schaffung allgemeiner Grundlagen und Rahmenbedingungen für die Anwen-dung architekturbasierter Verfahren in der Bundeswehr/im IT-SysBw im nationalen und internationalen Kontext gerichtet sind.

Methodenmanagement umfasst alle Aktivitäten, die die Anwendung des NAF, eventueller nationaler Ergänzungen sowie dieser Rahmenregelung betreffen.

Inhaltsmanagement umfasst alle Aktivitäten, die die Erfassung von Informationen für Architekturen und deren Nutzung – dies schließt die im GWR enthaltenen Informa-tionen ein – betreffen.

Das technisch-betriebliche Architekturmanagement umfasst alle Aktivitäten, die die Steuerung der Bereitstel-lung und Nutzung technischer Unterstützungsleistungen (Repository, Tools) zur Anwendung architekturbasierter Verfahren in der Bundeswehr / im IT-SysBw im nationalen und internationalen Kontext ermöglichen.

Kapitel 6 des vorliegenden Dokuments konkretisiert die Aufgaben des Architektur Managements wie folgt:

� Festlegen der Rollen und der Organisation � Festlegen und Verteilen von Aufgaben � Festlegung der Verfahren der Zusammenarbeit � Anforderungsmanagement � Konfigurationsmanagement � Qualitätsmanagement � Änderungsmanagement � Sicherheitsmanagement

Auf Grundlage der übrigen im Kontext der Architektur-Vorbereitung erzielten Ergebnisse,

� ermittelte Verwendungsabsicht, � ermittelte Ausgangsbasis, � festgelegter Abstraktionsgrad, � festgelegte Methodik � ausgewählter Methoden, � der ausgewählten Toolunterstützung und � festgelegter Konventionen

sind die oben beschriebenen Aufgaben durchzuführen. Hierbei ist zu beachten, dass alle diese Aufgaben strikt am Zweck der Architektur auszurichten sind und entspre-chend architekturspezifisch anzupassen sind.

Die nachstehende Grafik zeigt im Überblick die Eingangs-größen, die Aufgaben und den Kontext der Architektur-Vorbereitung durchzuführenden Aufgaben des Architek-tur Managements:

Abbildung 5.1-4: Initiierung Architektur Management

� 5.2 Architektur-Entwicklung

Eine Architektur lässt sich durch die Beschreibung der verwendeten Komponenten sowie deren Beziehungen zueinander und zur Umgebung darstellen. Ebenso sind die Prinzipien, die den Entwurf und die Evolution des Systems bestimmen, Teil der Architektur. Architekturelle Betrachtungen, Beschreibungen und Vorgaben spielen eine bedeutende Rolle hinsichtlich System Design und Integration, denn die frühzeitigen Architekturarbeiten und -aktivitäten helfen entscheidend bei späteren Inte-grationsarbeiten. Hochgradig komplexe Systeme oder Systems of Systems können nicht nur durch eine Archi-tekturdarstellung repräsentiert werden. Vielmehr hängen die Strukturierungseigenschaften und ihre Darstellung maßgeblich davon ab, welche Interessen ein Nutzer einer Architektur verfolgt. In Abhängigkeit von den „Interes-senvertretern“ ergeben sich somit auch unterschiedliche Sichtweisen auf ein System, die sich aus den einzelnen

Abschnitten dieses Kapitels ergeben. Allein aus dieser Aufstellung wird deutlich, dass die Views und Sub-Views des NAF nicht ausreichen, sondern zusätzliche Sichtwei-sen definiert werden müssen.

Verwendungs-absicht

Ausgangs-basis

FestgelegterAbstraktionsgrad

FestgelegteMethodik

AusgewählteMethode

AusgewählteToolunterstützung

FestgelegteKonventionen

Rollen und Organisation festlegen

Aufgaben festlegen und verteilen

Zusammenarbeit festlegen

Anforderungsmanagement initiieren

Konfigurationsmanagement initiieren

Sicherheitsmanagement initiieren

Änderungsmanagement initiieren

Zuordnungrelevanter Rollen

Festlegungrelevanter Aufgaben

Zusammenarbeitsregeln

VorgehensweiseAnforderungsMgnt

VorgehensweiseKonfigurationsMgnt

VorgehensweiseÄnderungsMgnt

VorgehensweiseSicherheitsMgnt

Darüber hinaus muss beachtet werden, dass eine Architektur in einem Zusammenhang steht und nicht als unabhängiges abstraktes Gebilde anzusehen ist. Um die grundlegenden Eigenschaften eines Systems zu verste-hen, muss die Beziehung des Systems zu seiner Umge-bung bekannt sein und verstanden werden.

Das bedeutet aber letztlich, dass die Entwicklung einer Architektur nicht nur Systemplanungs- und -implemen-tierungsaktivitäten im klassischen Sinne unterstützt, sondern auch bei der Unterstützung von Prototyping und Experimentalsystemen an Bedeutung gewinnt. Denn gerade bei den experimentellen Arbeiten ist es wichtig, architekturelle Informationen über das Gesamtsystem und die Teilkomponenten zu haben, mit denen die Proto-typen in einer NetOpFü- oder NNEC-Umgebung zusam-men arbeiten müssen, um diese Experimentalsysteme geeignet zu entwerfen.

Eine Architektur dient aber nicht nur als Basis für nachfol-gendes System Engineering und Entwicklungs-Prozesse, sondern kann in ihrer Rolle als Abstraktion der realen Welt auch für Analyse-Prozesse herangezogen werden, um Fragen und kritische Sachverhalte, die sich aus den Anforderungen ergeben, zu untersuchen und zu klären. Diese Analysen werden in der Regel mittels spezieller Werkzeuge durchgeführt, jedoch nutzen sie die Modelle und Sichtweisen der Architektur. Umgekehrt beeinflussen die Analyseergebnisse wiederum die Weiterentwicklung der Architektur.

NAF-Annex B enthält einen Überblick über einige Architek-tur-Methodiken, die nicht im Fokus dieses Kapitels liegen:

� NC3A’s Architecture Engineering Methodology (AEM), � TOGAF ADM, � Boeing/Openwings, � META Group and Gartner process model, � DoDAF’s 6 step model

Modellieren des Aspekts Rollen & Nutzer

Ein Nutzer (bisweilen auch Benutzer genannt) ist in der Regel eine Person oder eine Gruppe von Personen, die im weitesten Sinn Systeme nutzt, um mit der Hilfe der systeminhärenten Funktionen und Dienste Aktionen durchzuführen, die zur Erreichung eines definierten Zieles beitragen.

Demgegenüber wird eine Rolle durch eine Menge von Aktivitäten, Berechtigungen und Verantwortlichkeiten definiert, um innerhalb eines Prozesses bzw. einer opera-tionellen Aktivität Funktionen im Sinne einer definierten Aufgabe auszuführen. Darüber hinaus werden die not-wendigen Kenntnisse, Erfahrungen und Qualitätsmerk-male, die für die Ausübung der Aktivitäten erforderlich sind, durch die Rolle beschrieben. Die exakte Definition einer Rolle erfolgt durch eine Rollenbeschreibung (bis-weilen auch Rollendefinition genannt) innerhalb eines Rollenmodells.

In der Rollenbeschreibung erfolgt die Festlegung von Inhalt und Umfang einer Rolle mittels mehrerer Kriterien und sollte mindestens aus den folgenden Komponenten bestehen:

� einer Bezeichnung für die Rolle, � einer Auflistung der wichtigsten Aufgaben und ggf.

Ergebnisse, � den Qualifikationsanforderungen, � den erforderlichen Ausprägungen der

Qualifikationsmerkmale.

Die Gesamtheit und die Strukturierung der durch Rol-lenbeschreibungen definierten Rollen ergibt das Rollen-modell, bei deren Erstellung besonders zu beachten ist, dass Rollen vollständig und überschneidungsfrei definiert sind, um bei der operationellen Nutzung des Gesamt-systems Kompetenzüberschneidungen zu verhindern. Nachvollziehbarkeit und Verständlichkeit sind weitere

Charakteristiken der Definitionen. Auch wenn das Ziel bei der Modellierung der Rollen ist, die Anzahl möglichst gering zu halten, kann aus Gründen der Übersichtlichkeit das Modell mehrstufig angelegt sein, die durch eine Typi-sierung der Rollen und eine daraus resultierende Gruppie-rung unterstützt wird.

In Abhängigkeit von der Zielsetzung der zu entwickelnden Architektur ist ein weiterer Teilaspekt der Nutzer-/Rollen-modellierung von Bedeutung. Aus der Perspektive eines Systemdesigns, für das die zu entwickelnde Architektur die grundlegenden Vorlagen liefert, sind die späteren Nutzer von untergeordneter Bedeutung und nur die Rollen als integrale Bestandteile von Anwendungsfällen und korrespondierenden Diagrammen wichtige Modell-komponenten. Dient demgegenüber die zu entwickelnde Architektur als unterstützendes Werkzeug für konkrete Missionen, so treten die Nutzer und ihre Relation zu den Rollen wesentlich stärker in den Vordergrund. Das Rollen-management als Organisationsaufgabe übernimmt in diesem Kontext eine zentrale Position, denn die Verant-wortlichen für den jeweiligen Einsatz müssen konkret entscheiden, welche Rechte und operationellen Aktivitä-ten den definierten Rollen zugeordnet werden. Darüber hinaus muss entschieden werden, welche Personen den Rollen zugewiesen werden. Dieser Prozess basiert auf der Korrelation der in der Rollenbeschreibung niedergelegten Qualifikationsanforderungen mit den Qualifikationspro-filen der Nutzer. Ein Nutzer gemäß obiger Definition kann mehrere Rollen innehaben, aber ebenso können mehrere Nutzer jeweils die gleiche Rolle innehaben. Gerade vor diesem Hintergrund ist es wichtig, dass die Rollen und das übergeordnete Rollenmodell mit geringem Aufwand an unterschiedliche Missionen angepasst werden können.

Die Modellierung des Nutzer-/Rollen-Aspektes kann jedoch nicht isoliert betrachtet werden, sondern ist in engem Zusammenhang mit operationellen Aktivitä-ten (operationellen Prozessen) zu sehen. Die logische Einheit, die operationelle Aktivitäten durchführt, wird als operationeller Knoten definiert, der sich aus der Symbiose von Rollen und systeminhärenten Funktionalitäten und Diensten ergibt. Daraus folgt, dass die Ermittlung und

Erfassung von Rollen und deren Charakteristiken sich im Verlauf der Definition der operationellen Aktivitäten ergibt, die als orchestrierte Sequenz von Anwendungsfäl-len definiert sind.

Empfehlungen

� Ermitteln der Rollen als Ergebnis der Definition der Anwendungsfälle --> Aufstellen eines Rollenmo-dells (Klassendiagramm aus UML)

� Erstellen der Rollendefinitionen � Erstellen einer generischen Nutzerklasse (als Vorbe-

reitung für das Rollenmanagement) � Berücksichtigung der Zuordnung von Nutzern zu

Rollen bereits bei der Modellierung der Rollen � Anlegen von generischen Nutzern in der

Modellrepräsentation � Ermittlung der möglichen Nutzer (insbesondere

Qualifikationsprofile) und Erstellung des Nutzer-modells durch Instanziierung der generischen Nutzerklasse

Modellieren des Aspekts Anwendungsfälle

Mit Hilfe von Anwendungsfällen wird eine abgeschlos-sene, ununterbrochene Abfolge von Aktionen eines Akteurs am System beschrieben, um ein bestimmtes Ziel zu erreichen. Zielsetzung der Methode ist die Erfassung und Darstellung der aus Sicht von externen Bedienungs-einheiten („Aktoren“) an ein System gestellten funktiona-len Anforderungen.

Es werden nur die Aktionen bzw. Ereignisse spezifiziert, die aus der Sicht der Bedienungseinheit erkennbar sind, nicht aber Details, die beschreiben, wie das System intern arbeiten soll. Die für ein System spezifizierten Anwen-dungsfälle repräsentieren in ihrer Gesamtheit eine Menge anwendungsorientierter, funktionaler Anforderungen an das System. Um ihre Vollständigkeit zu erreichen, sollten möglichst alle erkannten Anwendungsfälle modelliert werden.

Zur Modellierung der Anwendungsfälle haben sich ins-besondere Use Cases und Aktivitätsdiagramme der UML bewährt, die es ermöglichen, transparente Spezifikation zu erstellen und abzustimmen.

Die Granularität kann verschieden sein. Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwen-dungsfall-Schreibens kann jedoch bis auf Ebene von IT-Prozessen verfeinert werden, so dass das Verhalten einer Anwendung detailliert beschrieben wird.

Zusätzlich werden die definierten Anwendungsfälle und ihre Beziehungen zu Bedienungseinheiten in Übersichts-diagrammen graphisch dargestellt und benannt. Es stehen Symbole zur Repräsentation der Anwendungsfälle, der Bedienungseinheiten und deren Beziehungen zur Ver-fügung. Es können Beziehungen zwischen Anwendungs-fällen und Bedienungseinheiten sowie Beziehungen zwischen Anwendungsfällen untereinander dargestellt werden.

Empfehlungen

Die „Use Case“-Modellierung wird zweckmäßigerweise in folgenden Schritten durchgeführt:

� Festlegung der logischen Systemgrenzen, da aus der Sicht eines Anwendungsfalls das System als Blackbox betrachtet wird.

� Ermittlung der Bedienungseinheiten (Rollen), die mit dem System arbeiten bzw. mit ihm kommunizieren.

� Ermittlung der Nutzung des Systems durch die relevanten Bedienungseinheiten. Jede Nutzungsart wird als ein Anwendungsfall modelliert.

� Identifikation des Anfangsereignisses bzw. der Aktion, wodurch ein Anwendungsfall angestoßen wird.

� Beschreibung der Abfolge von Interaktionen innerhalb des Anwendungsfalls, die notwendig ist, um jene Dienste zu realisieren, die der aktuelle Benutzer benötigt.

� Festlegung der Bedingungen, durch die ein Anwen-dungsfall beendet wird, sowie Beschreibungen von Ausnahmesituationen und Alternativen zum vordefinierten Ablauf.

� Die ermittelten Bedienungseinheiten, die definier-ten Anwendungsfälle und ihre Beziehungen sind in Übersichtsdiagrammen zusammenzufassen.

Use-Case Modelle bilden eine strukturierte Beschrei-bung der funktionellen Anforderungen eines Systems und somit auch die beste Basis für das Testen von Softwaresystemen.

Modellieren des Aspekts Informationsaustausch

Die Zielsetzung bei der Modellierung dieses Aspektes ist die Identifikation und Beschreibung aller Informations-austauschketten zwischen operationellen Knoten auf der Basis von Informationsanforderungen, in denen spezi-fiziert wird, welche Informationen von einem operatio-nellen Knoten benötigt werden, um seine operationellen Aktivitäten durchführen zu können. Die Informationsob-jekte, die als Medium dieses Austausches eine korrekte, vollständige und eindeutige Darstellung von Fakten über bestimmte operationelle Objekte beinhalten, werden als Informationsprodukte ausgetauscht. Informationspro-dukte repräsentieren Informationsobjekte in einem für eine Weiterverarbeitung (z.B. Berechnungen, Vergleiche, Verknüpfungen) korrekten Format. Dieses Modell setzt somit die drei Entitäten

� operationeller Knoten � operationelle Aktivität und � Informationsobjekt

in eine Beziehung zueinander, indem es darstellt: � wer tauscht Informationen aus, � mit wem werden Informationen ausgetauscht, � welche Informationen werden ausgetauscht, � warum ist diese Information notwendig, � welche Qualität der Information ist notwendig.

Empfehlungen

� Der Ausgangspunkt für die Modellierung dieses Aspektes ist die Festlegung der Attribute, die den Informationsaustausch spezifizieren. Diese Festlegung ist abhängig von der Verwendung dieses Modells. Um auf der Basis dieses Modells in nachfolgenden Schritten den Datenaustausch auf einer Systemebene korrekt spezifizieren zu können, ist eine detaillierte Ausprägung hinsichtlich Infor-mationsgehalt, betroffenen Knoten, Medien sowie qualitative und quantitative Aussagen hinsichtlich der auszutauschenden Informationen erforderlich.

� Für die Modellierung des Informationsaustausches ist die Verwendung von Tabellen ein zielführender Ansatz, in dem sich das oben erwähnte Bezie-hungsgeflecht zwischen operationellen Knoten, operationellen Aktivitäten und Informationsobjek-ten widerspiegelt. Jede Zeile dieser Tabelle könnte somit den Austausch eines Informationsobjek-tes zwischen einem Paar operationeller Knoten repräsentierten.

� Die Gesamtheit des Informationsaustausches, die in dieser Tabellenstruktur dargestellt wird, teilt sich in zwei Gruppen auf – automatischer und nicht automatischer Informationsaustausch (z.B. münd-liche Befehle). Während der nicht automatische Informationsaustausch sich nur auf operationelle Aspekte bezieht, wird der automatische Informa-tionsaustausch auf der Ebene der System weiter-verfolgt und führt dort zu einem Datenaustausch-modell, das – ebenfalls in tabellarischer Form – den Datenaustausch zwischen Systemen darstellt.

Modellieren des Aspekts Nicht Funktionale Anforderungen

Aus der Tatsache heraus, dass jedes System in der Regel nicht isoliert zu betrachten ist, sondern meist in ein größeres System eingebettet ist, entstehen Rahmenbedin-gungen, die nicht unerheblichen Einfluss auf die Anfor-derungen und insbesondere auf die nicht funktionalen Anforderungen haben. Nichtfunktionale Anforderungen sind allgemeine Qualitätsattribute des zu betrachten-den Systems, die in folgende vier Bereiche untergliedert werden [Partsch H 1991], wobei es durchaus auch andere Möglichkeiten der Klassifizierung gibt:

� Qualitätsattribute einzelner Funktionen: z.B. Ausfüh-rungsverhalten, Wartbarkeit, Zuverlässigkeit.

� Anforderungen an das Gesamtsystem: z.B. Einfachheit, Verfügbarkeit von Schnittstellen, Qualität der Doku-mentation, Sicherheit, Benutzerfreundlichkeit.

� Anforderungen an die Systementwicklung: z.B. Projek-tumfang, Prioritäten, Vorgehensweisen,

� verfügbare Ressourcen, Kosten der Entwicklung. Anforderungen an Einführung: z.B. Testdurchfüh-rung, Abnahme, Betriebsbeschränkungen, Wartung, Schulung.

Es besteht die Gefahr, dass nicht-funktionale Anforderun-gen gegenüber den funktionalen Anforderungen häufig vernachlässigt werden, obwohl sie wichtiger Bestandteil jeder Anforderungsdefinition sind.

Während funktionale Anforderungen in UML mit Hilfe von Anwendungsfällen modelliert werden können, unter-stützt UML die Modellierung nicht funktionaler Anforde-rungen nicht.

Empfehlungen

Da die Anforderungsermittlung ein wesentlicher Be-standteil des Systems Engineering ist, gibt es in SysML (abgeleitet aus UML) geeignete Vokabeln und sogar eine eigene Diagrammart: das Anforderungsdiagramm.Das Anforderungselement der SysML enthält:

� Name, � ID und � eine textuelle Beschreibung

der Anforderung. Anforderungshierarchien werden mit der ‚Enthältbezie-hung’ modelliert. Die übergeordnete Anforderung gilt als erfüllt, wenn alle ihre untergeordneten Anforderun-gen erfüllt sind.Das Anforderungsdiagramm ermöglicht eine neue Art der Dokumentation von Anforderungen. Als Ergänzung zur bisherigen Methode, die Anforderungen in einem Anforderungswerkzeug zu dokumentieren, können die Anforderungen nun in Diagrammen modelliert werden. Diese Diagramme stellen nicht nur die Anforderungen an sich, sondern auch deren Beziehungen zu anderen Anforderungen oder Elementen aus anderen Diszipli-nen dar, wie Architektur oder Test.Partsch H (1991). Requirements Engineering. München, Oldenbourg.

Modellieren des Aspekts IT-Sicherheit

Bei der Modellierung von IT-Sicherheitsaspekten in Bezug auf Architekturentwicklungen bedient man sich im Allge-meinen formaler oder semiformaler Sicherheitsmodelle. Gängige Sicherheitsmodelle aus dem Verteidigungs-bereich sind das Biba-Sicherheitsmodell, welches der Kontrolle von Lese- und Schreibzugriffen in Computersys-temen dient sowie das Bell-LaPadula-Sicherheitsmodell, welches vor allem die Vertraulichkeit von Datenzugriffen adressiert.

Der aus Sicht der Architekturentwicklung bedeutendste Sicherheitsaspekt sind die IT-Sicherheitsfunktionen, mit denen die funktionalen IT-Sicherheitsanforderungen erfüllt werden sollen. Diese sollten bereits in einem Grobkonzept niedergelegt und abgestimmt werden, welches als Grundlage für weiterführende Konzepte dient (z.B. Systemanforderungen, Systemarchitektur, Schnitt-stellenbeschreibung, Technische Anforderungen, usw.). Eine genaue Beschreibung des Zusammenwirkens der IT-Sicherheitsfunktionen im Hinblick auf einzelne Architek-tur-Komponenten oder -Teilsysteme ist unerlässlich (z. B. Beschreibung von IT-Komponenten, die bei einem Ausfall die Gesamtverfügbarkeit herbeiführen).

Die Modellierung der IT-Sicherheitsaspekte sollte grundsätzlich auch zur Festlegung des Hardware- und Softwarekonfigurationszustandes aller eingesetzten Komponenten dienen. Je nach vom Auftraggeber festge-legtem Schutzbedarf ist der Konfigurationsstand dem IT-SichhKProj als Nachweis beizufügen.

Die Systemarchitektur und das Realisierungskonzept sind dahingehend zu untersuchen, ob Schwachstellen in den verwendeten Komponenten und Produkten zu bestimm-ten Bedrohungen führen. Die Erstellung von Wirkungs-ketten für alle Restrisiken ist im Verteidigungsbereich eine grundsätzliche Forderung aus der ZDv 54/100. Bei der Festlegung der Wirkungsbereiche bedient man sich im Allgemeinen einer Bestimmung des maximalen Schadens, der durch die modellierten Gefährdungen eintreten kann sowie der Bestimmung von Folgeschäden. Eine mögliche

Vorgehensweise zur Bewertung der Risiken findet sich im internationalen Standard ISO 27005.

Im Rahmen der Modellierung muss ferner eine Katego-risierung der Restrisiken in die Gruppen „tolerierbare Risiken“ und „nicht tolerierbare Risiken“ vorgenommen werden.

Modellieren des Aspekts Funktionale Sicherheit

Die in der Anforderungsanalyse geforderten Systemfunk-tionen sollen durch die gewählte Architektur vollständig abgebildet werden. Unter dem Aspekt der „Funktionalen Sicherheit“ ist jede mit der Architektur realisierte Funk-tion unter der Annahme ihres potentiellen Fehlerverhal-tens zu betrachten. Es ist zu analysieren, ob das fehler-hafte Ausführen einer Funktion zu einem Systemzustand führen kann, bei dem Menschen oder Material gefährdet werden können.

Hierzu wird zunächst auf der „Systemebene“ eine soge-nannte „Gefährdungsanalyse“ durchgeführt. Die dabei erkannten Gefahren werden hinsichtlich der „Schwere der Gefahr“ bewertet, d.h. es muss bewertet werden, welcher „Schaden“ bzw. Unfall entstehen kann (Verletzungen, Tod einzelner oder vieler Personen). Darüber hinaus werden weitere Randbedingungen, wie z.B. die „Aufenthaltswahr-scheinlichkeit von Personen im gefährlichen Bereich“ und die „Vermeidbarkeit eines Unfalls“, z.B. durch Ausweichen, berücksichtigt. Ein gängiges standardisiertes Verfahren ist die FMEA (Failure Mode & Effect Analysis) bzw. FMECA (Failure Mode & Effect Criticality Analysis).

Die Gefährdungsanalyse wird in mehreren Stufen durch-geführt. Beginnend auf der Systemebene wird anschlie-ßend z.B. über eine Fehlerbaumanalyse der Einfluss einzelner Systemkomponenten auf ein Ereignis analysiert und bis auf Modulebene immer weiter verfeinert.

Grundsätzlich ist das Entstehen von Unfällen auf Grund der identifizierten Gefahren soweit, wie möglich zu verhindern, bzw. die Eintrittswahrscheinlichkeit gering zu halten. Der Auftraggeber sollte hierzu ein für ihn „akzep-tables Restrisikos“ festlegen.

Werden im Rahmen der Gefährdungsanalyse poten-tielle Gefahren ermittelt, gilt zunächst der Grundsatz, diese Gefahren konstruktiv, d.h. durch Änderung der Architektur, zu vermeiden. Sollte dies nicht möglich sein, z.B. weil eine geforderte Systemfunktion potentiell gefährlich ist (z.B. das Stanzen von Blechteilen), sollen zur Vermeindung von Unfällen geeignete „Sicherheitsein-richtungen“ eingebracht werden (z.B. Schutzgitter und Zweihandbedienung).

Für Systemkomponenten mit sicherheitsbezogenen Funk-tionen gelten im Entwicklungs- und Qualifizierungspro-zess besonderer Randbedingungen, die im Detail in den einschlägigen Normen und Standards beschrieben sind. Im internationalen militärischen Umfeld wird z.B. oft auf die Anwendung des Mil-Std 882 „System Safety Program Requirements“ verwiesen.

Für Systeme mit sicherheitsrelevanten Aufgaben, die im europäischen Wirtschaftsraum in Verkehr gebracht wer-den, ist die Anwendung der DIN EN 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer / elektroni-scher / programmierbarer elektronischer Systeme“ (oder eine aus dieser Grundnorm z.B. für Bahntechnik, Land-wirtschaft oder Automotive spezialisierte Norm) verbind-lich vorgeschrieben.

Für jedes Projekt sind die vom Auftraggeber akzeptierte Vorgehensweise und die anzuwendenden Standards möglichst frühzeitig festzuschreiben. Idealerweise liegt auch bereits vor dem ersten Entwurf einer Architektur eine vorläufige Gefährdungsanalyse auf Systemebene vor, so dass die sicherheitsrelevanten Randbedingungen sehr früh in ein Systemkonzept einfließen werden können.

Für das BWB ist das Referat T8.3 der zentrale Ansprech-partner zum Thema „Funktionale Sicherheit“.

Modellieren des Aspekts Datenmodell

Die Herausforderungen bei der Integration unterschied-lichster heterogener Systeme sind nicht nur technischer Natur, sondern sind darüber hinaus auch im semanti-schen (eindeutiges Verständnis) und organisatorischen

Bereich angesiedelt. Um einen effizienten Datenaus-tausch zwischen den beteiligten Organisationen sicher zu stellen, ist es für den Informationsaustausch zwingend erforderlich, ein zwischen allen Beteiligten abgestimmtes Datenmodell zu entwerfen, dessen vorrangige Zielset-zung die Spezifikation der auszutauschenden Daten ist. In einem logischen Datenmodell wird die Struktur der domänenspezifischen Information ebenso beschrieben wie der organisatorische Prozess der Informationsbe-handlung. Dieses Datenmodell umfasst somit die Defini-tion der Architekturdomänen spezifischen Informationen, ihre Attribute oder Charakteristiken und ihre Beziehung untereinander. Basis für ein derartiges Modell ist das von der Multilateral Interoperability Programme (MIP) Organi-sation vorgeschlagene Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM). Da dieses Datenmodell einen querschnittlichen Charakter hat und erheblichen Lücken hinsichtlich Kontext spezi-fischer Informationen aufweist, muss es erweitert und angepasst werden, um einen kompletten Definitionssatz zu erhalten und ein gemeinsames Verständnis zwischen allen Beteiligten durch Verwendung einer eindeutigen Sprache zu erreichen.

Empfehlungen

Es wird empfohlen, unter Verwendung von UML Klas-sendiagrammen ein Datenmodell aufzustellen, dessen Klassen die Informationselemente und deren Meta-Informationen enthalten. Auch die Beziehungen unter-einander lassen sich mit Hilfe der Klassendiagramme darstellen. Da es zunehmend schwieriger wird, unter-schiedliche Datenmodelle im Verteidigungsbereich zu steuern und zu überwachen, ist davon auszugehen, dass neue Mechanismen zur Informationsbeschreibung und Informationsbeziehung entwickelt werden, die dann in das bestehende Modell eingearbeitet werden müssen. Abgeleitet aus diesem Klassendiagramm lässt sich ein Datenaustauschmodell – dargestellt in tabellarischer Form – ableiten, wobei jede Zeile dieser Tabelle genau einen Datenaustausch zwischen zwei Systemen oder funktionalen Einheiten repräsentiert. Diese Tabelle wird erweitert um austauschrelevante Informationen wie Häufigkeit des Austausches, Durchsatz, Größe, Infor-mationssicherheit und Genauigkeit, um nur einige zu nennen.

Modellieren des Aspekts Kommunikationsschnittstellen

Der Aspekt Kommunikation muss über mehrere Model-lierungsebenen hinweg betrachtet werden. Die oberste Ebene leitet sich dabei direkt aus den Informations- und Datenaustauschmodellen ab, denn darin werden die operationellen Knoten bzw. die Systeme, die Informati-onen bzw. Daten austauschen, in Beziehung gesetzt, so dass sich daraus direkt Kommunikationsmatrizen ableiten lassen. Die unterste Ebene dieses Modellstacks betrachtet die Ports einzelner Systeme hinsichtlich ihrer Hardware- und Protokolleigenschaften. Das Ziel dieser Modellkette ist eine umfangreiche Spezifikation bis auf die detaillierte Infrastrukturebene, die beschreibt, wie Systeme in dem Gesamtkontext miteinander verbunden sind.

Um diesen komplexen Sachverhalt zu behandeln, ist ein hybrider Modellierungsansatz zu bevorzugen. Dabei wird einerseits von der sich aus den operationellen Anforde-rungen bzw. aus dem Informationsaustauschmodell erge-benden System-Konnektivität ausgegangen, die bereits zu erwartende Kommunikationsanforderungen andeutet. Andererseits sind einzusetzende Systemkomponenten bereits mit Kommunikationsports ausgestattet, die in der Regel noch konfektioniert und konfiguriert werden kön-nen, so dass die Herausforderung darin besteht, mit den gegebenen Komponenten das operationell geforderte System zu modellieren.

Empfehlungen

� Abgeleitet aus dem Informationsaustauschmodell wird eine System-to-System-Matrix generiert, aus der hervorgeht, welche Knoten Informationen/Daten miteinander austauschen müssen und somit eine Kommunikationsverbindung benötigen.

� In einem zweiten Schritt werden diese logischen Knotenverbindungen in einzelne Systemverbindun-gen aufgebrochen. Für jede logische Verbindung wird dargestellt, welche Systeme in den Knoten beteiligt sind, über welche Ports diese Systeme verbunden sind und welche Qualitätsanforderun-gen bestehen.

� In einem weiteren Schritt wird für jede identi-fizierte Schnittestelle zwischen Systemen ein Diagramm erstellt, das die Verbindung zwischen den Ports der beteiligten Systeme darstellt. Im einzelnen sollte jedes Diagramm zeigen, welche Kommunikationsports verbunden sind, zu welchen Systemen diese Ports gehören, die Eigenschaften der Verbindung (Hardware, Protokolle) und die Qualitätsanforderungen an die Verbindung.

� Ein viertes Modell beschreibt detailliert die Kom-munikationsprotokolle aller Ports eines Systems. Dazu wird in der Architektur für jedes System ein Diagramm erstellt, in dem alle Ports mit ihren Cha-rakteristiken aufgeführt sind.

� 5.3 Architektur-Anwendung

Eine wesentliche Frage im Rahmen der Architekturent-wicklung ist die Frage, wozu die zu entwickelnde Archi-tektur verwendet bzw. worauf sie angewendet werden soll. Diese Frage stellt sich bereits zu Beginn der Architek-turmodellierung, sollte jedoch im gesamten Modellie-rungsverlauf nicht aus den Augen verloren werden, da sie wesentlich auch die Inhalte einer Architektur bestimmt.

Eine Architektur kann z.B. herangezogen werden, um Systeme (organisatorische und technische) zu entwickeln, weiterzuentwickeln oder umzustrukturieren oder um Zusammenhänge, Schnittstellen und offene Punkte zwi-schen unterschiedlichen Strukturen/Systemen aufzuzei-gen und zu analysieren. Die unterschiedlichen Zielsetzun-gen einer Architektur haben Auswirkungen auf

� Auswahl und Anwendung von Analyseverfahren, � Bewertung der Architektur selbst,

� Umsetzung der Architektur in technische Implemen-tierungen und

� Dokumentation der Ergebnisse.

Problematiken, Auswirkungen und der Umgang mit diesen Aspekten werden in den nachfolgenden Unterka-piteln kurz dargestellt.

5.3.1 Anwenden von Analyseverfahren

Die Möglichkeiten zur Analyse einer Architektur sind min-destens so zahlreich, wie der zu Beginn festgelegte Zweck einer Architektur. Bereits die Erstellung einer Architektur ist ein strukturiertes Analyseverfahren, da bereits hier ein System „zerlegt“, „geordnet“ und einzelne Bestandteile in Beziehung gebracht werden.

Beispiele für Analyseverfahren: � Anforderungsanalyse � Artefaktanalyse � Gap-Analyse � Datenflussanalyse � Fähigkeitsanalyse � Simulationsanalyse � Informationsanalyse � Funktionale-Analyse

Der volle Nutzen einer Architektur ergibt sich nur durch das Anwenden von Analyseverfahren auf die Architektur. Nicht jedes Analyseverfahren ist auf jede Architektur anwendbar. Daher sollte im Vorfeld einer Architektur-entwicklung oder -weiterentwicklung die anzuwen-dende Methode feststehen. Dies hilft bereits in der Ausschreibung und Definition der Arbeitspakete für die Architekturentwicklung.

Sollte beispielsweise eine Gap-Analyse durchgeführt wer-den, benötigt man in den meisten Fällen zwei Architektu-ren. Die eine beschreibt den Ist-Zustand und die andere den Soll-Zustand. Dadurch lassen sich Lücken leicht

identifizieren und eine Planung zur Migration entwickeln. („Wie kommt man vom Ist zum Soll?“).

Ein anderes Beispiel für die Anwendung einer Architektur ist die „Informationsanalyse“. Gerade im Hinblick auf das Ziel zur Vernetzten Operationsführung (NetOpFü) kommt der Informationsanalyse eine besondere Rolle zu. Hier ist die Frage „Welche Information benötigt der Einzelne und was muss mit einer Informationen (z.B. schneller, sicherer) getan werden, damit dieser seine Aufgabe besser erfüllen kann?“.

5.3.2 Bewerten der Architektur

Wann ist eine Architektur eine gute Architektur? Die Bewertung einer Architektur ist nicht trivial aber notwen-dig. Auch stehen zurzeit keine abgestimmten Bewer-tungskriterien für Architekturen fest. Ist die Architektur gut, wenn eine Summe X gegenüber einem Aufwand Y eingespart werden kann? Ist die Architektur gut, wenn eine Zerlegung von Elementen nicht mehr möglich ist? Ist eine Architektur gut, wenn das Ziel erreicht wurde?

Sollte die Entwicklung einer Architektur beauftragt werden, muss der Auftraggeber eine Möglichkeit haben, die Leistung zu bewerten, um festzustellen ob der Auftrag erfolgreich oder nicht erfolgreich durchgeführt wurde.

Üblicherweise wird in der Systementwicklung ein „Critical Design Review“ durchgeführt, um zu entscheiden, ob auf Basis dieser Architektur ein System entwickelt wird oder ob Nachbesserungen erforderlich sind. Bezogen auf die Systementwicklung ist eine Architektur nichts anderes als ein Plan, und Pläne müssen sich auf Basis neuer Erkennt-nisse ändern dürfen.

Die Methode des Critical Design Reviews (CDR) ist mit Sicherheit eine der besten Methoden, um eine Architektur zu bewerten. Es kommt jedoch darauf an, dass die Krite-rien für ein CDR zu Beginn der Architekturentwicklung

abgestimmt wurden. Dies betrifft natürlich in erster Linie die Frage der Qualitätssicherung (siehe Kapitel 6.4) aber eben auch die Frage der Architekturentwicklung.

� Ein vernünftiges Kriterium für die Bewertung einer Architektur ist die Vollständigkeit und Nachvollziehbarkeit der zu erfüllenden Anforderungen. Damit kann inhaltlich im CDR geprüft werden, ob und wie die Anforderungen in der Architektur berücksichtigt wurden.

5.3.3 Umsetzen der Architektur in technische Implementierungen

Die Umsetzung einer entweder impliziten oder expliziten Architektur ist die Transformation von Ideen, Vorgaben und Erwartungen in ein reales System:

� Dazu werden identifizierte Anforderungen, die in der Architekturbeschreibung festgehalten sind, realisiert.

� Im Rahmen der Realisierung können sich Erkenntnisse offenbaren, die zur Architektur im Widerspruch stehen können. Deshalb erweist sich manchmal eine initiale Architektur als nicht realisierbar.

� Im Rahmen der Umsetzung wird ein System immer konkreter. Das erweiterte Verständnis kann dazu beitragen, die Architektur zu korrigieren, Anforde-rungen zu revidieren. Es ist ebenso möglich, dass die Realisierung und die Architektur divergieren. Jeder hat schon einmal die Erfahrung gemacht, dass es leichter ist, zu entscheiden was man braucht, wenn man das Ergebnis vor sich hat (I know it when I see it).

Dieses Kapitel behandelt einige Aspekte, wie man diesen immer wiederkehrenden Problemen mit Architekturen und agilen Realisierungsprozessen begegnen kann.

Architektur

Beim Entwurf der Architektur können bereits sehr früh kritische Teile eines Systems identifiziert werden, die komplex oder aufwendig zu realisieren sind. Diese Teile

können als Herausforderungen in einer technischen Per-spektive liegen (Ist das System durch die identifizierten Technologien realisierbar?) oder auch in einer operativen oder funktionalen Perspektive (Wird durch das System die beabsichtigte Fähigkeit erreicht? Können die Benutzer wie intendiert mit dem System umgehen?).

Zur Risikominimierung haben sich prototypische Realisie-rungen von horizontalen oder auch vertikalen Facetten bewährt, die die Umsetzung der Architektur verifizierbar machen. Bereits Prüfungen der Konsistenz und Integrität gegen ein Meta-Model bei der Erstellung der Architektur können das Realisierungsrisiko minimieren. Ausführbare Architekturen wie beispielsweise Simulationen oder Prototypen können helfen, in frühen Entwicklungsphasen Defekte oder Fehler zu identifizieren.

Bei der Umsetzung wurde wiederholt die Erfahrung gemacht, dass selbst durch eine profunde Architektur nicht alle Erwartungen an ein System erfasst werden.

Die Industrie trägt dieser Erfahrung insoweit Rechnung, als dass inkrementelle oder agile Entwicklungsprozesse Anwendung finden. In diesem Zusammenhang ist auch bei der Realisierung eine enge Zusammenarbeit mit dem Kunden vorteilhaft, um möglichst früh Feedback zu erhalten und gegebenenfalls die Architektur und deren Umsetzung an das Feedback anzugleichen.

In einer profunden Architektur sind die Abhängigkeiten zwischen Komponenten, die in den übergeordneten, operationellen, systembezogenen oder technologiebe-zogenen Views erscheinen, deutlich zu erkennen. Diese Abhängigkeiten sind für die Planung eines Realisierungs-prozesses essentiell. Insgesamt lässt sich sagen, dass sich der Entwicklungsprozess von einer umfassenden Architekturbeschreibung ableiten lässt wie beispiels-weise beim Rational Unified Process oder dem Open Unified Process, siehe http://en.wikipedia.org/wiki/Category:Software_development_process

In der Literatur findet man den Begriff „Separations of Concerns“ (http://en.wikipedia.org/wiki/Separation_of_concerns). Er umfasst Taktiken, um Abhängigkeiten zu

reduzieren und so mehr Freiheitsgrade bei der Realisierung und dem Realisierungsprozess zu erhalten. Diese Tatsache lässt sich in der Praxis sowohl an der Architektur als auch am Realisierungsprozess exemplarisch beobachten, z.B. mittels:

� Separation von Interaktionen des Systems mit den Benutzern und den umgebenden Systemen,

� Validieren von Interaktionen, � Separation von Realisierungsmethodik und

Domänenwissen, � Dekomposition des Systems in handhabbare unab-

hängige Komponenten, � Inkrementelles Integrieren der Komponenten und des

Systems, � Design by Contract, d.h. die Vereinbarung von Funktio-

nalitäten und nicht von Implementierungen, � …

Natürlich ist die Einhaltung von Architekturvorgaben bei einer während der Realisierung gepflegten Architektur unerlässlich und erfordert entsprechende Überprüfungs-maßnahmen, wie kontinuierliche Reviews und Change Control Management. Sind Abweichungen von der Architektur notwendig, so sollten diese als Rationale fest-gehalten werden. Diese Rationalen dienen der Nachvoll-ziehbarkeit und der Evolution der Architektur und damit des Systems.

Als bewährtes Konzept hat sich Occam‘s Razor heraus-gestellt: Von mehreren Architekturen, die den gleichen Sachverhalt erklären, ist die einfachste zu bevorzugen.

Generell wird in der Architektur und auch bei der Realisie-rung das Verwenden einer Evolutionsperspektive empfoh-len, um insbesondere flexible generische Realisierungen zu erhalten.

Nichtfunktionale und Funktionale Anforderungen

Bei der Realisierung stellen die nichtfunktionalen Aspekte insoweit eine Herausforderung dar, als dass sie sehr früh berücksichtigt werden müssen, aber erst sehr spät in der Realisierung verifizierbar werden.

Oft können diese Anforderungen durch die Wahl einer geeigneten technischen Architektur erfüllt werden.

Häufig werden die funktionalen Sichten einer Architektur betont, da zur Beschreibung von Daten und Abläufen etablierte Notationen existieren. Die Denotationen für nichtfunktionale Anforderungen wie Performance, Verfügbarkeit, Flexibilität, Zuverlässigkeit, Skalierbarkeit etc. sind leider nicht so eingängig und finden in der Praxis selten Anwendung.

Bei der Realisierung stellen die nichtfunktionalen Aspekte insoweit eine Herausforderung dar, als dass sie sehr früh berücksichtigt werden müssen, aber erst sehr spät in der Realisierung verifizierbar werden.

Agiles Realisieren

Zeitpunkte für die Reviews sollten an wesentlichen Entscheidungspunkten gesetzt werden. Diese Reviews können und sollen sich auf den Sachverhalt der Entschei-dung unter Berücksichtigung der abhängigen Teile der Architektur fokussieren. Generelle umfassende Reviews über Gesamtsysteme behindern in der Regel eine agile Vorgehensweise durch Binden von Ressourcen. Reviews haben sich als nützliches Instrument herausgestellt, das Realisierungsrisiko zu minimieren und die Erwartungen zu justieren.

Abbildung 5.3-1: Adaptive Realisierung eines Systems

5.3.4 Dokumentieren der Ergebnisse

Dieses Kapitel behandelt einige Aspekte der Erstellung und Pflege einer Architekturdokumentation. Architek-turdokumentationen sollen Sachverhalte eineindeutig zwischen Autoren und Lesern kommunizieren. Viele Archi-tekturdokumentationen lassen die Fragen offen wie

� Wer ist der Leser der Architekturdokumentation? � Für welchen Zweck wurde die Dokumentation

erstellt? � Welche Sichten und Perspektiven der Architektur sind

dokumentiert? � Welche Notation findet Anwendung und welche

Semantik? � Was ist dokumentiert: Soll oder Ist? � Wie verändert sich die Architekturdokumentation im

Laufe der Zeit?

Wie vermeidet man diese und andere Missverständnisse zwischen den Lesern/Autoren und verbessert die Kommu-

nikation? Die Antwort liegt in an den Zweck angepassten Dokumentationen. Generell gilt:

� Die Dokumentation einer Architektur besteht aus mehreren Sichten, die Aspekte der Architektur beschreiben.

� Durch eine für den Adressaten und den Zweck angemessene Auswahl der Sichten reduziert sich die Darstellungskomplexität.

� Durch unterschiedliche Perspektiven lassen sich unterschiedliche Informationsbedürfnisse und Prob-lemstellungen bearbeiten.

Adressaten

Die Architekturdokumentation ist das Informationsme-dium zwischen allen Projektbeteiligten. Rollen im Rahmen eines Projektes haben unterschiedliche Informations-bedürfnisse. Diese spiegeln sich in der Auswahl geeig-neter Sichten wieder. Beispielsweise sind die folgenden Zielgruppen an dem angeführten Informationsaustausch interessiert.

Lösung am Projektende

Geplante Lösung

Unschärfeabnehmen

Verifikation des aktuellen Standes

Mögliche Lösung

Zielgruppe Art des InformationsaustauschesArchitekt und Anforderungsfachmann (repräsentiert den Kunden)

Forum für das Verhandeln und Abwägen von konkurrierenden bzw. widersprechenden Anforderungen

Architekt und Designer Auflösen und Zuordnen von nichtfunktionalen Anforderungen

Entwickler Festlegen der Randbedingungen und Freiheiten in der Entwicklung

Tester und Integrierer Festlegung des Blackbox Verhaltens

Softwarepflege und -änderung Bereiche die voraussichtlich geändert/angepasst werden

Entwickler anderer Systeme Operationen und Protokolle an Schnittstellen

Qualitätssicherung Divergenz der Implementierung

Produktlinienverantwortlicher Divergenz der Architektur von einer Produktlinienarchitektur

IT-Sicherheitsverantwortlicher Festlegen der Sicherheitsanforderungen an die Architektur und Prüfung der Divergenz der Implementierung zur Planung

Tabelle 5.3-1: Zielgruppen für Architekturdokumentationen

Detaillierungsgrad

Die Frage nach dem Detaillierungsgrad lässt sich einfach beantworten: So abstrakt wie möglich und so konkret und detailliert wie nötig für den entsprechenden Adressaten.

Die Erfahrung zeigt, dass Architekturdokumente mit mehr als 200 Seiten in der Regel von keinem Beteiligten wirklich gelesen werden. Solche Dokumente sind in der Regel Alibidokumente, deren Wert anzuzweifeln ist. Der Umfang einer Dokumentation sollte in Relation zum beschriebenen System stehen und einen vertretbaren Umfang nicht überschreiten. Durch navigierbare Doku-mentation kann der Detaillierungsgrad variabel gehalten werden. Für geschlossene dokumentartige Formen hat sich ein Hauptdokument, das den Kontext beschreibt, als vorteilhaft erwiesen.

Der Kontext definiert Ziele, Aufgabenstellungen, Betei-ligte und deren Interessen. Randbedingungen sollten angeführt werden, seien diese technischer Art, oder organisatorischer. Ein logischer Kontext sollte das Sys-tem durch seine Hauptelemente und deren Beziehung untereinander sowie die Systemgrenzen beschreiben. Ebenso sollten Prozeduren zur Architekturentwicklung und -bewertung beschrieben sein. Das Hauptdokument

sollte verschiedene Dokumente referenzieren, in welchen jeweils eine Architektursicht beschrieben ist.

Ein weiteres Architekturdokument sollte grundlegende Aspekte der Architektur in sogenannten Perspektiven festhalten. Solche Aspekte können sein:

� Sicherheit, � Performanz und Skalierbarkeit , � Verfügbarkeit und Ausfallsicherheit, � Evolution, � Zugänglichkeit und Verteilung, � Regulierungen, � Benutzbarkeit � etc.

Syntax und Semantik

Die Detailtiefe, der Erklärungsbedarf, die Notation, und die Bedeutung einzelner Teile der Architekturdokumenta-tion hängen stark vom Adressaten ab. Kann der Adressat den dokumentierten Sachverhalt wiedergeben, so hat die Dokumentation ihr Ziel erreicht: Je kompakter umso besser. Das kann einerseits durch einheitliche ausdrucks-starke Semantik, beispielsweise Prädikatenlogik, erreicht werden und andererseits durch graphische Notatio-nen wie die Unified Modelling Language. Je höher der Informationsgehalt ist und je verständlicher er für den Adressaten bleibt, desto besser.

Fragen, die die Diagramme in der Architekturdokumenta-tion beantworten müssen, sind:

� Welche Bedeutung haben die dargestellten Elemente? � Welche davon sind vorhanden, zu verändern oder zu

realisieren? � In welchem Kontext muss die Dokumentation

betrachtet werden? � Wo sind die Systemgrenzen? � Welche Bedeutung hat die Anordnung? � Was kann aus über das Verhalten ausgesagt werden?

Nicht alle Fragen können von einem Diagramm allein beantwortet werden. Aber die Architekturdokumentation sollte die Fragen beantworten – auch noch nach Jahren.

Sichten

Welche Sichten nun in eine Architekturdokumentation aufgenommen werden, leitet sich einerseits aus dem Adressaten als auch aus Absprachen her. Folgende Sichten werden als das Minimum angesehen:

� Logische Kontextsicht Die Logische Kontextsicht liefert einen Überblick und stellt das System in seiner logischen Umgebung dar. Dargestellt werden Benutzer und angrenzende Sys-teme, soweit diese relevant sind.

� Technische Kontextsicht Diese Sicht beschreibt die technische Anbindung des Systems an andere Systeme, dies beinhaltet auch die technische Auslegung der Schnittestellen. Sie kann die Infrastruktur darstellen.

� Implementierungssicht Diese Sicht stellt Interna dar, sie gliedert das System in realisierbare Teile.

� Laufzeitsicht Diese Sicht beschreibt dynamische Aspekte des Systems.

� Datensicht Diese Sicht beschreibt Daten- und Informationsflüsse.

� Sicherheitssicht Diese Sicht beschreibt die sicherheitstechnischen Anforderungen und die Erfüllung derer in den einzel-nen Teilen der Architektur.

Für die Erstellung der Sichten hat man die Erfahrun-gen gemacht, dass die Auswahl der Sichten und deren Beschreibungstiefe für einen reibungslosen Projektverlauf wichtig sind. Es ist essentiell, dabei den Adressatenkreis zu berücksichtigen. Risikobehaftete Teile der Architektur sollten eine größere Beschreibungstiefe aufweisen.

Die Erstellung der Sichten ist ein iterativer und interak-tiver Prozess. Erkenntnisse aus einer Sicht haben oft Ein-fluss auf andere Sichten. Die Verwendung von Modellie-rungsumgebungen, das Prüfen gegen Meta-Modelle und der Austausch von Modellen bzw. das verteilte Erstellen von Modellen hat sich als vorteilhaft erwiesen. Dokumen-tationen sollten immer der Versionskontrolle unterliegen. Die Erstellung bzw. Generierung eines Dokuments, falls gefordert bzw. benötigt, sollte auf Basis eines Modells erfolgen.

Logische Kontextsicht

Diese Sicht liefert einen Überblick auf das System in seiner logischen Umgebung. Dargestellt werden Benutzer und angrenzende Systeme, soweit diese relevant sind. Hier bietet sich die NOV-1 Sicht aus dem NAF an.

Technische Kontextsicht

Diese Sicht beschreibt die technische Anbindung an andere Systeme, dies beinhaltet auch die technischen Anforderungen an die Schnittestellen. Für Einschränkun-gen an den entsprechenden Schnittstellen können z.B. SysML Elemente (Constraints) zur Darstellung benutzt werden.

Die Technische Kontextsicht beschreibt die Infrastruktur ggf. als Netztopologie, die Hardwarekomponenten sowie weitere Bestandteile der Systemumgebung. Sie stellt das System aus der Sicht eines Betreibers dar.

Implementierungssicht

Diese Sicht dient der Kontrolle des Engineeringprozes-ses. Schnittstellen zwischen internen Teilen und deren

Funktionalität werden definiert. Diese Sicht beantwortet beispielsweise:

� wie das System in Subsysteme, Komponenten etc. aufgeteilt ist,

� welche Dienste der Systeme, Betriebssysteme oder Hardware benötigt werden,

� welche Abhängigkeiten sich ergeben.

Im Rahmen der Systementwicklung können zur Notation dieser Sicht z.B. SysML und UML14 verwendet werden, je nach Detaillierungsgrad der aktuellen Ansicht (System, Subsystem, Hard- oder Software). Im Idealfall werden die konzeptionellen Bausteine auf die Implementierungs-komponente abgebildet, um Strukturbrüche zwischen diesen Sichten zu minimieren.

Laufzeitsicht

Diese Sicht beschreibt den dynamischen Aspekt des Sys-tems, z.B. welche Elemente zur Laufzeit existieren und wie diese zusammenwirken. Die Dokumentation dieser Sicht sollte sich an den Informationsbedürfnissen der Betreiber und Administratoren des Systems ausrichten.

Zur Darstellung sollten Sequenzdiagramme, Aktivitätsdia-gramme, Kollaborationsdiagramme oder Verteilungsdia-gramme genutzt werden.

Datensicht

Die Datensicht beschreibt die Struktur von Datenelemen-ten und ihre Beziehung zu anderen Bestandteilen der Architektur. Dabei können folgende Aspekte interessant sein:

� welche Daten wo benötigt oder bearbeitet werden, � wo Daten gespeichert oder bearbeitet werden, � wie Daten transportiert werden.

Diese Sicht entspricht der NOV-7 und wird durch die NSV-11 verfeinert. Das NSV-11b entspricht dann den Objekten im System bzw. deren Entsprechung in den Datenbanken. Als Darstellungsform können UML15-Klassendiagramme

verwendet werden. Entity Relationship Diagramme werden von UML Tools in der Regel schlecht bzw. gar nicht unterstützt.

Um über die gesamte Dokumentation ein einheitliches Verständnis des Systems der verwendeten Terminologie zu haben, empfiehlt sich ein Glossar. Ein solches Glossar sollte nicht nur eine einfache Beschreibung der einge-setzten Begriffe beinhalten, sondern auch die Philosophie hinter den Begriffen erläutern. Ebenfalls sollten immer wieder auftretende Begriffe wie Auftrag oder Nutzer wirklich detailliert beschrieben werden.

Sicherheitssicht

Die bei der Planung der Architektur erarbeiteten Sicher-heitsanforderungen werden in dieser Sicht den umge-setzten Maßnahmen gegenüber gestellt und so eine Sicht auf den derzeitigen Sicherheitsstand der Architektur ermöglicht.

Dies kann beispielsweise in Tabellenform geschehen. Dabei wird für jeden auftretenden Risikotyp eine Zeile angelegt. Die Spalten werden mit den Architekturteilen überschrieben. In den Zellen der Tabelle können so die auftretenden Risiken identifiziert und ihre Behandlung näher beschrieben werden. Wird ein Risiko nicht behan-delt, so muss ein entsprechender Grund dafür angege-ben werden. Dabei sind die Nachvollziehbarkeit und die Angabe des entsprechenden Restrisikos von großer Wichtigkeit.

Aus dieser Sicht kann somit der aktuelle Stand der Sicher-heitsmaßnahmen abgeleitet und eine entsprechende Risikoanalyse zur Bewertung der Risiken im Gesamtkon-text des Einsatzszenarios durchgeführt werden.

Evolution der Architekturdokumentation

Im Rahmen der Projektdefinition sollte ein Auftragge-ber seine Sicht des Systems in den NAF Sichten NOV-1 bis NOV-7 dargelegt haben. Der Auftragnehmer hat

14. Für Schnittstellen zwischen Softwarekomponenten eignet sich im weiteren Verlauf z.B. CORBA IDL, auch wenn CORBA nicht als Middleware zum Einsatz kommt.

daraufhin in der Regel die Sichten NSV-1 bis NSV-11 erstellt. Ggfs. haben sich beide Parteien darauf geeinigt, dass die eine oder andere Sicht nicht benötigt wird. Diese Infor-mationen sollten in einem Modell abgelegt werden, um dann in der weiteren Verfeinerung und/oder Entwicklung in Ansichten und Modellelemente für das Systemengi-neering überführt bzw. weiterentwickelt zu werden. Die folgende Grafik soll das veranschaulichen:

Abbildung 5.3-2: Weiterentwicklung der NAF Sichten

Im System Engineering Modell erfolgt dann die weitere Ausarbeitung des Systems, welche nicht nur ein Schritt in der Realisierung eines Systems oder der Durchführung eines Projektes ist. Die Erstellung der Architekturdoku-mentation ist vielmehr ein iterativer Prozess, der im Sys-temdesign beginnt, in der Entwicklung fortgeführt wird.

Die Architekturdokumentation sollte den Soll-Zustand des Systems beschreiben und als Vorgabe bzw. Leitlinie für Projektbeteiligte dienen. Die Architekturdokumenta-tion sollte auch den Ist-Zustand des Systems festhalten, d.h. die Architekturdokumentation sollte konsistent mit der Realisierung sein.

Eine Architekturdokumentation, die Veränderung, Beweg-gründe und Alternativen beinhaltet ist nachvollziehbar. Des Weiteren bietet eine solche Architekturdokumenta-tion Möglichkeiten zur Diskussion, Lösungsfindung und zur Retrospektive. Nur so lassen sich Entscheidungen

bewerten, um daraus zu lernen. Aus diesen Bewertungen können Empfehlungen entwickelt werden, um in ähnli-chen Situationen schneller und fundierter entscheiden zu können.

� 5.4 Architektur-Publikation

5.4.1 Veröffentlichen von Architekturergebnissen

Die Veröffentlichung von Architekturergebnissen ist ein wesentlicher Aspekt der Nutzung der Architektur und soll zur Mehrfachnutzung der Architektur bei-tragen. Die Publikation ist zugleich ein Beitrag zum Akzeptanzmanagement.

Ständige Aktualisierung, Ergänzung und Vervollständi-gung der Inhalte und der Nutzungseigenschaften von Architekturen sind ein wesentliches Merkmal „lebender“ bzw. „gelebter“ Architekturen.

Im Bereich der Bundeswehr und der wehrtechnischen Industrie sind bisher Architekturen eher vorhabens-, projekt- und bereichsbezogen verwaltet und veröffentlicht worden. Hier können durch Festlegungen zur Veröffent-lichung und deren technische Unterstützung zusätzliche Nutzeffekte erzielt werden.

� Beispiele erfolgreicher Publikationen in großen Unter-nehmen können dabei als Anregung genutzt werden.

� Erfolgreiches Architekturmanagement in großen Unternehmen bzw. Organisationen wird durch die Art und Weise der Veröffentlichung nachhaltig unter-stützt. Typischerweise sollte dabei folgendes sicherge-stellt werden:

� Zielgruppen-, ebenen- und rollengerechte Veröffentlichung,

� Beachtung von Sicherheits- und Geheimschutzaspekten,

� Beachtung des Urheberrechts, � Feedback-Möglichkeiten zur Initiierung von

Änderungen,

NAF Modell

NOVNSV NTV

System Engineering Modell

Auftragnehmer

� Etablierung eines Entwicklungskreislaufes der Archi-tekturentwicklung - Release-Cycle-Management,

� Verwaltung und Veröffentlichung von Arbeitsver-sionen, QS-gesicherten Freigabeversionen und Archivständen,

� weitestgehender Onlinezugang (Intranet, Extranet, Internet) mit der Möglichkeit zu Offline-Nutzung,

� Möglichkeiten des Exports oder anderer Ausgaben zur Unterstützung der Weiternutzung.

Ein in der Praxis bewährtes Rollenmodell unterscheidet beispielweise zwischen folgenden Rollen im IT-Archi-tekturmanagement und leitet daraus auch spezifische Sichten und Rechte für die Rolleninhaber ab:

� IT-Bebauungsplaner, � IT-Architekten, � IT-Architektur-Management, � IT-Sicherheitsverantwortliche, � Administratoren, � System Owner, � Systementwickler/-anwender, � Leser = Fachabteilungen/Verantwortliche.

5.4.2 Schulungen von Architekturergebnissen

Die Vermittlung von Wissen zu Architekturergebnissen ist neben der Veröffentlichung ein wesentlicher Aspekt der Nutzung der Architektur und soll zur Mehrfachnutzung der Architektur beitragen und ist zugleich ein Beitrag zum Akzeptanzmanagement.

Die Schulungen sind zielgruppengerecht (vgl. Rollenmo-dell in Kap 5.4.1) anzubieten und aufzubereiten.

Die Schulungen können als Online-Tutorial (WebEx, Webcast, eLearning-Kurs) bzw. ergänzend als Präsenz-veranstaltung durch/mit den Architekturentwicklern entwickelt und angeboten werden.

Die Schulung von Architekturergebnissen setzt entweder auf vorhandene Kenntnisse zum Architekturframework, dem eingesetzten Modellierungstool und dem Anwen-dungsgebiet auf oder vermittelt diese ergänzend in Schulungsverlauf.

Die Planung und Entwicklung von heutigen IT- und Kommunikationssystemen, militärischen Plattformen und Systemkonstellationen, insbesondere mit dem Ziel eine ‚Vernetzte Operationsführung‘ auch im Rahmen multi-nationaler Einsätze zu realisieren, ist geprägt von hoher Komplexität. Es erfordert das Management von enormen Datenmengen, seinen Abhängigkeiten und Beziehun-gen, um alle relevanten Komponenten und Faktoren zu analysieren und zu dokumentieren. Insbesondere die vielschichtigen Aspekte, wie beteiligte Organisationen, Akteure und Rollen, Systeme, Schnittstellen, Standorte, Technologien und Standards etc., erfordern einen umfas-senden Ansatz zur Berücksichtigung aller Planungsdaten und ihrer Abhängigkeiten.

Die Verteidigungsministerien verschiedener Länder als auch die Institutionen der NATO und der EU wenden heutzutage die Architekturmethode basierend auf unter-schiedlichen Architekturrahmenwerken (Department of Defence Architecture Framework (DODAF), Ministry of Defence Architecture Framework (MODAF) oder dem NATO Architecture Framework (NAF)) an, um ihre „Com-mand, Control and Consultation (C3)“ Ausstattungen zu planen und zu entwickeln (s. hierzu z.B. auch Kapitel 3.4). Zahlreiche militärische Projekte wurden bis heute bereits erfolgreich unter Nutzung der Architekturmethode reali-siert. Dabei wurden und werden die Architekturen inzwi-schen für ganz unterschiedliche Zwecke entwickelt, z.B. für die Planung von EU Battlegroups oder die Analyse und Planung der maritimen Aufklärungslage, um nur zwei Bei-spiele zu nennen. Auf Grund des erfolgreichen Einsatzes der Architekturmethode werden viele zukünftige Projekte dieser Methodik folgen.

Der Architekturentwicklungsprozess beginnt im Allgemei-nen mit einer genauen Definition von Zweck, Geltungsbe-reich, Grenzen und Abhängigkeiten, um ein zielgerichte-tes Architekturmodell zu erzeugen. Zudem sind Modelle überaus umfangreich und bestehen üblicherweise aus einigen zehntausend Entitäten, die wiederum in unter-schiedlichen Sichten (Views) verwendet werden. Daraus

resultiert, dass der initiale Entwicklungsprozess, bis zu einem ersten Basisstatus (Baseline) häufig sehr zeitinten-siv ist. Konsequenterweise ist das endgültige Modell in einer Weise zu planen, dass die Architektur langfristig für verschiedene Anwendungsgebiete und Nutzer geeignet ist.

Der komplexe Entwicklungsprozess, als auch die nach-folgenden Aktivitäten zur Nutzung der Architektur erfordern, wie oben angedeutet, sowohl in der Erstel-lungsphase als auch nach der Fertigstellung des ers-ten Grundstatus einer Architektur ein sachkundiges Architekturmanagement.

Im vorliegenden Leitfaden werden � Grundlagen, � das Anforderungs-, � Konfigurations-, � Qualitäts-, � Änderungs- und � Sicherheitsmanagement,

das im Rahmen der Entwicklung und Verwendung zwingend notwendig ist, erläutert und Empfehlungen abgegeben, wie diese Managementaufgaben geplant und implementiert werden können.

� 6.1 Management Grundlagen

6.1.1 Festlegen der Rollen und Organisation

Der Architekturerstellungsprozess ist komplex und erfordert die Bewältigung einer Vielzahl ganz unter-schiedlicher Aufgaben, die durch verschiedene Rollen und Organisationen wahrgenommen werden müssen. Die klare Definition und verantwortliche Übernahme der jeweiligen Rollen ist die Voraussetzung für die erfolgrei-che Entwicklung einer Architektur.

6 Architektur-Management

Die Bundeswehr hat ihrerseits in der Erarbeitung ihrer ‚Rahmenregelung zur Architekturerarbeitung und -bearbeitung‘ Rollen und Organisationen, wie z.B. die AG Architektur Bundeswehr (AG ArchBw), die Bevollmäch-tigten (BV) der Organisationsbereiche (OrgBer), die Rolle des Moderator/Methodenspezialist sowie die Rolle des Modellierers definiert.

Im Folgenden werden die erforderlichen Rollen und Organisationen für die Architekturentwicklung und das Architekturmanagement definiert, erläutert und an den Definitionen der Bw Rahmenregelung gespiegelt, u.a.:

� Architektur Management Board Das Architektur Management Board bildet sich aus Entscheidungsträgern des Auftragnehmers und des Auftraggebers. Es hat die gleichen Aufgaben wie ein Lenkungsausschuss und eine Änderungssteuergruppe gem. V-Modell XT bezogen auf die Planung und Steue-rung von Architekturentwicklungen.

� Chef-Architekt Der Chef-Architekt ist vergleichbar mit dem Projekt-leiter gem. V-Modell XT sowohl auf Auftragnehmer als auch auf Auftraggeberseite. Er hat die Aufgabe das Architekturmanagement durchzuführen und trägt dem Architektur Management Board vor.

� Architekt Der Architekt ist der Modellierer und Methodenspe-zialist und entspricht dem Systemarchitekten gem.

V-Modell XT. Zudem nimmt der Architekt auch die Aufgaben eines Businessarchitekten wahr, der die abzubildenden Prozesse ermittelt und die Vorgaben für die Anforderungsanalytiker gibt.

� Analyst Der Analyst ist der Wissensträger und gleichzeitig ein spezifischer Anwender der Architektur

� Konfigurationsmanager Entspricht dem Konfigurationsmanager gem. V-Modell XT für die Modelle der Architektur

� Qualitätsmanager Entspricht dem Qualitätsmanager gem. V-Modell XT für die Modelle der Architektur

� IT-Sicherheitsverantwortlicher Entspricht dem Systemsicherheitsbeauftragten gem. V-Modell XT

6.1.2 Festlegen und Verteilen von Aufgaben

Im Folgenden werden die jeweiligen Aufgaben definiert und den in Kapitel 6.1.1 definierten Rollen und Organisati-onen zugeordnet, u.a.:

Aktivität Rollen BeschreibungInitialisieren eines Architekturprojektes Architektur Management Board,

EntscheidungsträgerSiehe Kapitel 5.1

Entwickeln/Modellieren einer Architektur Architekt, Analyst, Wissensträger Siehe Kapitel 5.2

Anwenden der Architektur Analyst, Anwender Siehe Kapitel 5.3.1

Bewerten und Freigeben der Architektur Chef-Architekt Siehe Kapitel 5.3.2

Publizieren/Vermarkten der Architektur Architektur Management Board Siehe Kapitel 5.4

Durchführen des Anforderungsmanagements Chef-Architekt Siehe Kapitel 6.2

Durchführen des Konfigurationsmanagements Konfigurationsmanager Siehe Kapitel 6.3

Durchführen des Qualitätsmanagements Qualitätsmanager Siehe Kapitel 6.4

Durchführen des Änderungsmanagements Architektur Management Board Siehe Kapitel 6.5

Durchführen des Sicherheitsmanagements IT-Sicherheitsverantwortlicher Siehe Kapitel 6.6

Tabelle 6.1-1: Aufgabenzuordnung

6.1.3 Festlegen von Verfahren zur Zusammenarbeit

Die Entwicklung einer Architektur impliziert die Beteili-gung zahlreicher ‚Stakeholder‘ und erfordert die Bear-beitung durch bzw. Beiträge von Fachspezialisten in den jeweiligen Architekturprodukten der ‚Operationellen Sicht‘, der ‚System Sicht‘, der ‚Service Orientierten Sicht‘, der ‚Technischen Sicht‘ und weiterer Sichten. Das Zusam-menwirken der unterschiedlichen Fachspezialisten mit dem Architekturentwicklungsteam ist aber nur ein Aspekt der in diesem Kapitel erläutert wird. Darüber hinaus werden die Zusammenarbeit innerhalb eines Architek-turentwicklungsteams, insbesondere die Erstellung einer Architektur durch Architekturteams mehrerer Firmen sowie die Zusammenarbeit zwischen Auftraggeber (AG) und Auftragnehmer (AN) reflektiert.

� 6.2 Architektur-Anforderungsmanagement

Wie bereits in vorangegangenen Kapiteln ausführlich erläutert, wird mit der Erstellung einer Architektur immer ein Zweck verfolgt, der zuvor genau definiert und im Rahmen der Architekturplanung, z.B. im „Overview & Summary“ dokumentiert wird. In den meisten Projekten wird mit der Erstellung der Architektur gleichzeitig die Ermittlung von Anforderungen für neue Systeme, den Informationsaustausch, neue Fähigkeiten, die Weiterent-wicklung einer Organisation oder dergleichen beabsich-tigt. Diese Anforderungen können allgemein gesprochen operationeller, systemtechnischer, technischer, nicht-funk-tionaler oder organisatorischer Natur sein.

Projekten liegt daher häufig eine umfangreiche Liste von diversen Anforderungen bzgl. Systemen, Informations-austausch, Interoperabilität oder Fähigkeiten in Form von Konzepten, Richtlinien, ersten Planungen, ‚Lessons Learnt’ usw. vor. Diese Anforderungen werden zunächst extra-hiert und durch die Modellierung in Form von Diagram-men, Tabellen und Listen in der Architektur dokumentiert. Im Rahmen der strukturierten Analyse während des

Architekturentwicklungsprozesses werden zudem weitere Anforderungen identifiziert.

Im Verlauf eines Projektes entsteht auf diese Art und Weise eine sehr große Anzahl an Anforderungen, die verwaltet werden müssen. Hierbei ist eine bidirektionale Verknüpfung von modellierten Entitäten (Anforderun-gen in graphischer Darstellung) in der Architektur und den textuellen Anforderungen in einem Anforderungs-management-Tool unerlässlich, damit Inkonsistenzen vermieden werden. Zudem können bereits identifizierte Anforderungen aus der Architektur, die in ein Anfor-derungsmanagementwerkzeug überführt wurden, in diesem weiter detailliert werden.

Die industrielle Praxis zeigt, dass dieser Prozess am besten gemanagt werden kann unter Anwendung von Applika-tionen der Informationstechnologie. Eine breite Palette von Tools ist bereits heute verfügbar und Schnittstellen zwischen Architekturentwicklung und Anforderungsma-nagement, wie z.B. System Architect und DOORS, werden in der industriellen Praxis erfolgreich eingesetzt. Dabei ist der Architekt in der Lage jede Anforderung mit all ihren Abhängigkeiten zuerst innerhalb der Anforderungsdaten-bank und darüber hinaus in der Architekturdatenbank zu verfolgen.

Das folgende Beispiel zeigt die Wertschöpfung, die durch die Anwendung eines umfassenden Prozesses erzielt werden kann:

Ein militärisches Konzept fordert:„Jeder Soldat sollte in der Lage sein, Meldungen an die nächst höhere Kommandoebene zu senden.“

Diese Feststellung ist sehr allgemein und gibt viele Frei-heitsgrade, um die Anforderung zu realisieren. Innerhalb des Planungsprozesses (Architekturentwicklung) müssen die folgenden Entitäten jedoch berücksichtigt werden:

� Soldat, � Meldung (Typ der Information), � Übertragungsmittel (Funk, PDA etc.), � höhere Kommandoebene (z.B. Task Force HQ), � …

Im Zuge der Abwägung von Optionen und Lösungen, wie die Anforderung technisch realisiert wird, treten gegebe-nenfalls folgende weitere Anforderungen auf:

� Das Tool muss mindestens eine Verschlüsselung bis geheim gewährleisten.

� Das Kommunikationsinterface muss den militärischen Standard ADatP XYZ unterstützen.

� …

Solche zusätzlichen Anforderungen müssen im Anforde-rungsmanagementwerkzeug erfasst werden. Jede Anfor-derung ist dabei sinnvollerweise mit ihrer relevanten Entität im Architekturmodell verknüpft und umgekehrt. Diese Methode gewährleistet den Erhalt von Konsistenz, Vollständigkeit und belastbaren Ergebnissen für die Planung, Realisierung und Anpassung von komplexen Systemen/Systemlandschaften.

Eine Wertschöpfung wird durch die Anwendung von IT-Tools erreicht, indem gewährleistet wird, dass Anfor-derungen in einer überschaubaren Weise identifiziert, verfolgt und priorisiert werden können, insbesondere bei großen Projekten. Abhängigkeiten von Architekturentitä-ten und Anforderungen werden automatisch identifiziert und Toolfunktionen erlauben die ausführliche Traceability, wie Risikoanalyse, Simulationsfähigkeit, Reifetests.

� 6.3 Architektur-Konfigurationsmanagement

Die Architekturentwicklung erfordert zwingend die Anwendung des Konfigurationsmanagements. Der Modellierungsprozess impliziert, dass sich Architektur-modelle ausgehend von einzelnen Entitäten entwickeln und zu Datenbasen von zehntausenden von Entitäten, Diagrammen, Modellen, Tabellen und Berichten anwach-sen. In Folge dessen muss jede entwickelte Version des Architekturmodells, Diagramme oder Matrizen eindeutig identifizierbar sein. Deshalb muss das Architekturma-nagement einen Architekturkonfigurationsprozess pla-nen, festlegen und einrichten, der klare Rollen und deren Verantwortlichkeiten definiert.

Dieser Prozess hat folgende Aspekte abzudecken: � Steuerung von Änderungen und deren

Dokumentation, � Versionskontrolle (Master Datenbank,

Arbeits-Datenbanken), � Mittel zur Identifikation der Architektur Entität, � Modellierungswerkzeug Konfiguration (Eigenschaf-

ten, Rahmenbedingungen), � Erzeugung und Gebrauch der Masterdatenbasis/

Ablage/Glossar, � Dateiformate (z.B. MDF, BAK, XML Export & Files), � Erzeugung von Baselines, � Toolunterstützung und Gebrauch, � Erfassung und Verwaltung der Architekturergebnisse, � Verfügbarmachen der Architekturen, � Administrierung der Gesamtglossars.

Der Konfigurationsmanagementprozess hat nicht nur den Entwicklungsprozess einzubeziehen, sondern auch den Lebenszyklusprozess nach dem Release der ersten Base-line, weiterer folgender Nachträge und Modifikationen des Architektur-Repositories.

� 6.4 Architektur-Qualitätsmanagement

Die zielgerichtete Entwicklung, Pflege und Anpassung von Architekturen kann in qualitativ unterschiedlichen Ausprägungen erfolgen. Werden die unterschiedlichen Aktivitäten im Bereich der Architektur-Entscheidungen als Prozesskette aufgefasst, so entscheidet die Ergebnisqua-lität einer Aktivität die Eingangsqualität und gleichzeitig Endqualität der Folgeaktivität. Die Gesamtqualität der Architekturentwicklung kann damit nicht besser sein, als die schlechteste Qualität aller Zwischenergebnisse.

Damit kommt der Sicherstellung der Architekturqualität, im Folgenden als Architektur-Qualitätsmanagement bezeichnet, eine besondere und vor allen Dingen mög-lichst früh zu startende und kontinuierliche Rolle zu:

Formative Definition von Charakteristika, die möglichst früh in dieser Prozesskette einer hohen Qualität der Architektur dienlich sind. Hier ist insbesondere darauf

zu achten, dass diese Anforderungen ganzheitlich und prüfbar sind.

Summatives Vorgehen zur Prüfung, inwieweit gewünschte Anforderungen an die Architektur eingehal-ten worden sind. Auch diese summativen Vorgehen sind in der Prozesskette möglichst frühzeitig anwendbar, sind aber jeweils einer formativen Definition nachgelagert.

Um diese beiden Aufgaben möglichst detailliert zu beschreiben, wird im folgenden Qualität als grundle-gendes Konzept erläutert, um darauf aufbauend jeweils separat die formativen als auch summativen Schritte vorzustellen.

6.4.1 Qualität von Architekturen

Grundlage der Beschäftigung mit der Qualität von Architekturen ist ein präzises Verständnis von Qualität. Die visuelle Modellierung dieser Definition hilft dabei, die Anforderungen an ein ganzheitliches Qualitätsmanage-ment von Architekturen abzuleiten:

Abbildung 6.4-1: Qualität von Architekturen

Qualität ist demnach genau dann gegeben, � wenn jedes Erfordernis (Erf.i in der Abbildung) durch

die Betrachtungseinheit gegeben ist, � wenn jedes Merkmal (Mi in der Abbildung) der

Betrachtungseinheit auch zu einer Erfordernis passt. Diese Minimalität resultiert aus der grundsätzlichen Wirtschaftlichkeitsbetrachtung von Software-Projek-ten, die überflüssige Funktionalität ausschließt, da hierdurch Kosten ohne Nutzen erzeugt wird.

Im Folgenden soll dieses Modell von Qualität für eine Präzisierung des Architektur-Qualitätsmanagements verwendet werden, indem die Architektur-Betrachtungs-einheiten, die Erfordernisse sowie die damit notwendigen QS-Aktivitäten erläutert werden.

Architektur-Betrachtungseinheiten

Das Qualitätsmanagement von Architekturen adressiert die Betrachtungseinheit „Architektur“. Für die Ermittlung der Anforderungen für ein effektives Qualitätsmanage-ment ist das Kriterium wichtig, nach dem ein System in Komponenten und deren Abhängigkeiten zerfällt

Betrachtungseinheit

Mn ...

ErfordernisseQualit

(s. Architekturdefinition im Glossar) und die Synchroni-sierung der möglichen unterschiedlichen Sichten auf ein System. Die Vielschichtigkeit dieser Kriterien führt dazu, dass es unterschiedliche Architekturen gibt.

Häufig verwendete Architekturen, die jeweils einzeln, zusammen mit dem System oder im gesamten Architek-turverbund für das Qualitätsmanagement zu betrachten sind, sind:

� Funktionale Architektur. Diese besteht aus der Dekomposition der System-Software in ihre funktio-nalen Bestandteile. Typische Komponenten einer sol-chen funktionalen Architektur sind „Business-Logik“, „Datenbank“ oder „Graphical User Interface (GUI)“.

� Prozessorientierte bzw. prozessorale Architektur: Diese besteht aus der Dekomposition der System-Software bzgl. ihrer prozessoralen Bausteine. Typische Kom-ponenten einer solchen prozessorientierten Archi-tektur sind „Dateneingabe“, „Datenverarbeitung“, „Datenausgabe“.

� Hardware-Architektur: Diese besteht aus der Dekom-position der System-Hardware bzgl. der zur Ent-wicklung und/oder Betrieb notwendigen Hardware-Infrastruktur. Typische Komponenten einer solchen Hardware-Architektur sind Load-Balancer, Netzwerk-kabel und Server-Clouds.

� Sicherheits-Architektur: Diese besteht aus der Dekomposition der Hard- und Software bzgl. ihrer sicherheitsrelevanten Komponenten und Fähigkeiten. Typische Komponenten einer solchen Sicherheitsar-chitektur sind Firewalls, Verschlüsselungsroutinen und Spam-Filter.

� Softwaretechnische Architektur: Diese besteht aus der Dekomposition der System-Software in ihre soft-waretechnischen Teile. Typische Komponenten einer solchen funktionalen Architektur sind spezifische Libraries, Frameworks oder auch systemspezifische Schichtenarchitekturen.

Das Architektur-Qualitätsmanagement hat entsprechend diesem Architekturverständnis die folgenden Betrach-tungsgegenstände zu bearbeiten, in denen die einzelne Architektur jeweils unterschiedlich kontextsensitiv betrachtet wird:

� Die Architektur an und für sich. Jede Architektur muss unabhängig des verwendeten Kriteriums und des Zusammenhangs zum System bestimmte Anforderungen erfüllen, um überhaupt einen Wert darzustellen.

� Eine Architektur und ihr Zusammenspiel mit dem System entlang des gewählten Kriteriums.

� Mehrere Architekturen und ihre Synchronisierbar-keit sowie der Grad der Unterstützung spezifischer Geschäftsstrategien damit.

Erfordernisse an Architekturen

Erfordernisse werden in der Regel von Nutzern formuliert. Auf Grund der Vielschichtigkeit von Architekturen ist für das Architektur-Qualitätsmanagement eine Vielzahl von Schlüsselpersonen eines Projektes relevant.

Typische Bedarfsträger von Architekturen sind (s. hierzu auch die unterschiedlichen Rollen im Architekturkontext unter 6.1.2 oben):

� Endanwender: Für diesen besonders relevant ist die funktionale Architektur (in jeweils allen drei Architektur-Kontexten), da diese üblicherweise auch die Usability mitbestimmt. So befinden sich Formatie-rungsanweisungen von Textverarbeitungssystemen zusammenhängend in einer Formatierungskompo-nente, wohingegen die grafischen Möglichkeiten häu-fig in einer Grafikkomponente zusammenhängend angeboten werden.

� Betrieb: Für diesen besonders relevant ist die Hard-ware-Architektur (in jeweils allen drei Architektur-Kontexten), da sich hieraus Herausforderungen und Probleme für den Betrieb ableiten lassen. Typische Fragestellungen des „was passiert, wenn diese

Hardware-Komponente im Betrieb ausfällt“, müssen vom Betrieb selbst beantwortet werden, so dass die Anforderungen vom Betrieb u.a. Transparenz, Redun-danz und Wiederherstellbarkeit sind.

� Tester: Für diesen ist ebenso wie für den Betrieb häufig die Hardware-Architektur besonders interes-sant (in jeweils allen drei Architektur-Kontexten), da das Testen eines Systems im Idealfall auf separater Hardware stattfindet, die keinerlei Einfluss auf das Produktivsystem besitzt und einfache Schnittstellen für die Testdatenbereitstellung aufweist. Nur so kann sichergestellt werden, dass Testen und Betrieb los-gelöst voneinander stattfinden können und der Test maximal offensiv und effizient durchgeführt werden kann.

Jede dieser Rollen hat entlang der Qualitätsdefi-nition spezifische Anforderungen an spezifische Architektur-Betrachtungseinheiten in allen drei Architektur-Kontexten.

QS-Aktivitäten für Architekturen

Die Vielschichtigkeit � von Architektur entlang der drei aufgezeigten

Architektur-Kontexte, � der Architekturen bildenden Kriterien � sowie der involvierten Bedarfsträger

gilt es beim Architektur-Qualitätsmanagement entspre-chend mit QS-Aktivitäten zu berücksichtigen. Dies führt bei den unterschiedlichen Architekturkontexten zu einer möglichen Klassifizierung der Architektur-QS-Aktivitäten eines Architektur-Qualitätsmanagements.

� Syntaktische Architektur-QS: Diese Aktivitäten adres-sieren den kleinsten Architekturkontext, nämlich die einzelne Dekomposition und ihre explizite Darstel-lung, unabhängig vom Kriterium und dem System. Der Betrachtungsfokus der entsprechenden QS ist ebenfalls sehr eng und stellt daher lediglich typische Anforderungen an explizite Architekturen. Typische Beispiele sind

� Verständlichkeit und Konsistenz der verwendeten Notation (bestenfalls der Verweis auf einen etab-lierten Standard wie UML). � Wartbarkeit der Architekturdokumentation, d.h.

die Möglichkeit, Änderungen an ihr vorzunehmen und sie werkzeugbasiert weiterzuverwenden. � Portierbarkeit der Architekturdokumentation, d.h.

die Möglichkeit, die Architekturbeschreibung mit unterschiedlichen Werkzeugen anschauen und weiterentwickeln zu können.

Bis auf die beiden Anforderungen Effizienz und Zuverlässigkeit sind alle typischen Anforderungen an Produktqualität, wie sie in der ISO 9126, heutige ISO25000 hinterlegt sind, unabhängig des Projekt-kontextes anzuwenden. Ein Beispielrisiko ist eine semi-formale Architekturbeschreibung mit unklarer Legende in Paint.

� Semantische Architektur-QS: Diese Aktivitäten adres-sieren eine einzelne Architektur und ihr Zusammen-spiel mit dem realen System entlang des Kriteriums. Wesentliche Anforderungen, die sich auf dieser Ebene der Qualitätssicherung ergeben sind: � Korrektheit der Architekturbeschreibung: Stimmt

die Architekturexplizierung mit dem realen Sys-tem überein, d.h. existiert entlang des Dekompo-sitionskriteriums für jedes Objekt der Architektur ein entsprechendes Objekt im realen System und umgekehrt? � Wert der Architektur: Hilft die konkrete Architek-

tur, die Geschäftsstrategie, die mit dem System und der dahinterliegenden konkreten Architektur verbunden werden, zu erfüllen bzw. strategie-relevante Fragen zu beantworten? � Ein Beispielrisiko der semantischen Architektur

ist eine objekt-orientierte Modellierung der Geschäftslogik (z.B. mittels Klassendiagrammen) und eine funktionale, nicht-objektorientierte Implementierung.

� Strategische Architektur-QS: Diese Aktivitäten adres-sieren die gesamtheitliche und damit kontextsensi-tivste Sicht auf die Gesamtarchitektur, bestehend aus einer Vielzahl explizit gemachter Teilarchitekturen,

den jeweiligen Kriterien und dem System selbst. Eine wesentliche Anforderung dieser QS besteht darin, dass die unterschiedlichen Architekturen aufeinan-der abbildbar sind und die so entstehende Kombi-nation die Gesamt-Geschäftsstrategie unterstützt. Ein Beispielsrisiko dieser Sicht ist eine auf maximale Redundanz ausgelegte Software-Architektur sowie eine monolithische Hardware-Architektur: Hier lässt sich die Software-Architektur nur schwierig auf die Hardware-Architektur abbilden (indem nämlich jede Komponente der SW-Architektur auf die eine Kompo-nente der Hardware-Architektur abgebildet wird).

Die beiden folgenden Kapitel müssen für jede dieser QS-Aktivitäten, die jeweils spezifische Erfordernisse für spezifische Architekturen adressieren, separat durchge-arbeitet werden. Es gehört zu den größten Herausforde-rungen für das Architektur-Qualitätsmanagement, diese Ganzheitlichkeit fortwährend zu berücksichtigen und die unterschiedlichen, teilweise konkurrierenden Aktivitäten projektspezifisch optimal zu synchronisieren und aus-zutarieren. Das Architektur-Qualitätsmanagement hat fortwährend sicherzustellen, dass

� syntaktische QS für alle relevanten Architekturen separat entlang den Anforderungen aller Schlüssel-personen durchgeführt wird.

� semantische QS für alle relevanten Architekturen separat entlang den Anforderungen aller Schlüssel-personen durchgeführt wird.

� strategische QS für alle relevanten Architektur-Men-gen entlang den Anforderungen aller Schlüsselperso-nen durchgeführt wird.

Die grundsätzlichen Mittel dafür werden im Folgenden aufgeführt und können für alle drei Architektur-QS-Ebe-nen gleichermaßen angewendet werden.

6.4.2 Formatives Qualitätsmanagement

Ein wesentliches Mittel des formativen Qualitätsmanage-ments für Architekturen sind Vorgaben, die während des gesamten Projektes und aller darin enthaltenen Aktivitä-ten (s.o.) berücksichtigt werden sollen. Eine wesentliche

Best-Practice an diese Architektur-Vorgaben, damit diese nicht nur als Papierware existieren, sondern tatsächliche formative Kraft auf die Projektdurchführung besitzen, ist die Anwendung des S.M.A.R.T.E.R.-Konzepts. Dies bedeutet für alle Vorgaben die folgenden Charakteristika:

� Specific: Jede Vorgabe, die sich aus der ganzheitlichen Betrachtung von Architektur-Qualität ergibt, sollte bestmöglich soweit operationalisiert werden, dass sie möglichst feingranular spezifiziert ist: Hierbei ist häufig das Konzept „Divide et impera“ anzuwenden, d.h. durch schrittweise Verfeinerung (häufig mittels des klassischen Konzept der Hierarchie) entstehen konkrete Handlungsanweisungen, die in Summe dem übergeordneten Ziel dienlich sind. So sollte die syntaktische QS sehr spezifische Vorgaben z.B. an die zu verwendete Notation, an das zu verwendende Architektur-Werkzeug als auch an das Format für die anschließende Weitervergabe machen.

� Measurable: Eng verbunden mit der Spezifität ist die Anforderung nach Messbarkeit: Die Messbarkeit bedeutet in diesem Kontext die messtheoretisch konforme Anwendung von Abbildungen aus Modellen der realen Welt auf quantitative Größen. Eine etwaige im Kontext der semantischen Architektur QS spezi-fisch formulierte Vorgabe, die Kommunikation mit der Business-Logik dürfe nur über einen Verschlüsse-lungsalgorithmus erfolgen, lässt sich durch Zählen derjenigen Kommunikationskanäle, die sich an diese Vorgabe halten und das Zählen solcher Kommunikati-onskanäle, die unverschlüsselt mit der Business-Logik kommunizieren, messbar und damit für das Architek-turmanagement steuerbar machen.

� Eine Vielzahl hochwertiger Konstrukte lässt sich allerdings nicht so direkt messen. So lässt sich z.B. die Zukunftsfähigkeit einer Softwarearchitektur im Kontext der semantischen Architektur-QS nicht direkt messen, solange keine spezifischeren Vorgaben (s. vorheriger Schritt: Specific) existieren. Ein häufiges Hilfsmittel für die Meßbarmachung schwieriger Konstrukte ist die Verwendung von Indikatoren, die Indikationen für die positive Einhaltung oder negative Verletzung von Konventionen liefern. Dieses Konzept ist in der folgenden Abbildung dargestellt:

Abbildung 6.4-4: Indikatorenzuordnung

� Die Zukunftsfähigkeit einer Architektur z.B. lässt sich nur schwer messen. Allerdings existiert eine Vielzahl von möglichen Indikatoren, die Indizien auf eine schlechte Architektur bzgl. Zukunftsfähigkeit liefern. So ist z.B. die Messung der Aufrufe von Windows-spe-zifischen APIs ein guter Indikator dafür, dass sehr stark proprietäre Schnittstellen verwendet werden, die eine geringe Zukunftsfähigkeit besitzen. Auch das kom-plette Fehlen von notwendigen Dokumenten einer Software-Lieferung lässt sich zählen und als Indikator für eine schlechte Zukunftsfähigkeit deuten.

� Achievable: Gerade Vorgaben aus dem Architektur-bereich müssen die grundsätzliche Erreichbarkeit berücksichtigen. Da Architekturvorgaben leider häufig sehr allgemein gehalten sind und die notwendige Spezifität vermissen lassen, fällt häufig die Nicht-Erreichbarkeit der Vorgaben nicht auf. Die notwendige Operationalisierung zum Identifizieren möglichst spezifischer Vorgaben hilft dabei, die Erreichbarkeit des übergeordneten Ziels zu überprüfen. Da architek-tonische Vorgaben auf formativer Ebene häufig stark visionären Charakter haben, helfen bei Unklarheiten insbesondere Machbarkeitsstudien, die Erreichbarkeit des Ziels grundsätzlich zu überprüfen.

� Realistic: Auch wenn Vorgaben primär das „Was“ adressieren, das es zu erreichen gilt, müssen Vorgaben ebenfalls die operative Umsetzung präjudizieren. So ist die Vorgabe, jede objektorientierte Klasse eines Systems müsse in einem Architekturdiagramm repräsentiert sein, sicherlich empfehlenswert, wenn

es um die Zukunftsfähigkeit geht (z.B. als Indikator); allerdings muss eine derartige Vorgabe auch die dafür notwendigen Aufwände und Ressourcen in einem Projekt berücksichtigen. Sind diese nicht beschaffbar bzw. nicht realistisch, so ist die Schärfe der Vorgabe entsprechend zu reduzieren (z.B. nur die Klassen, die für die Business-Logik relevant sind). Erreichbarkeit muss neben menschlichen Ressourcen auch Zeit, Netzanbindung, Hardware-Performance, Software-Lizenzen u.ä. berücksichtigen.

� Terminated: Auch wenn Vorgaben per se kontinu-ierlich auf alle Prozessschritte wirken, muss eine Terminierungsbedingung formuliert werden, ab wann die Vorgabe als erfüllt bzw. nicht erfüllt einzustufen ist. Im Testbereich wird dies häufig als sogenanntes Testende-Kriterium bezeichnet. Die Terminierungs-bedingung macht hierbei intensiv Gebrauch von der Messbarkeit, in dem hier spezifische Grenzwerte und Toleranzen formuliert werden. Terminierbare Vorgaben können in diesem Kontext als Quality-Gate betrachtet werden.

� Ethical: Da die architektonischen Vorgaben die grundsätzliche Richtung bzgl. eines Aspektes (z.B. Security oder Usability) für ein Projekt adressieren, müssen hier auch ethische Vorgaben als übergeord-nete Maßgaben berücksichtigt werden. Hierzu zählen grundsätzliche Aspekte des Menschenrechts, militä-rische Konventionen wie die Genfer-Konventionen sowie arbeitsrechtliche Konventionen wie z.B. der Datenschutz. All diese Vorgaben müssen kompatibel zu den projektspezifischen Vorgaben des Architektur-managements sein.

� Recorded: Sämtliche Architekturvorgaben müssen explizit dokumentiert und kommuniziert sein. Nur bekannte Vorgaben können auch explizit und vor allen Dingen systematisch eingehalten werden (und dann auch entsprechend geprüft werden). Auch die Über-prüfung von Vorgaben (s. summatives Qualitätsma-nagement) muss entsprechend dokumentiert werden, um bei aufgedeckten Abweichungen Gegenmaß-nahmen systematisch identifizieren und deren Erfolg nachhalten zu können.

Vorgabe 3

Vorgabe 2

Metrik 1

Metrik 2

Metrik 3

Indikator 1

Indikator 2

Vorgabe 1

Die Aufgabe des formativen Qualitätsmanagements ist es, Architekturvorgaben ganzheitlich bzgl. relevanter Anforderungen so zu formulieren (und zu dokumentie-ren, vgl. „R“ oben), dass sie dem S.M.A.R.T.E.R.-Konzept genügen. In der folgenden Tabelle ist dies für die drei unterschiedlichen QS-Aktivitäten noch einmal beispiel-haft aufgeführt:

Architektur-QS-Bereich

Formative Beispielanforderungen entlang des S.M.A.R.T.E.R-Konzeptes

Syntaktische Architektur-QS

� Vorgabe der Notation � Vorgabe der Tools und Austauschformate � Liste der zu liefernden expliziten Architekturen und der anzuwendenden Kriterien � Vorgabe für typische Darstellungsdetails wie Mindest-Fontgröße, mögliche Farbvielfalt, etc.). � Medium für Architekturübergabe (gedruckt, elektronisch, etc.)

Semantische Architektur-QS

� Vorgabe des Systemteils, bzgl. dessen die Architektur zu erstellen ist (z.B. Gesamtsystem, nur Datenbank, nur Teile einer Datenbank usw.)

� Vorgabe des architekturbildenden Kriteriums sowie der konkreten Abbildungsfunktion, wie welche Objekte des zu betrachtenden Systems in die Architektur überführt werden.

� Vorgabe von Meßpunkten, wie die Kongruenz zwischen Architektur und System gemessen und bewertet wird.

� Vorgabe von spezifischen Zielen, für die eine Architektur ausgelegt sein soll. � Vorgabe von Nachweisen, wie Angemessenheit einer Architektur belegt werden kann (siehe

hierzu auch weiter unten).

Strategische Architektur-QS

� Vorgabe von strategischen Zielen, die für alle Architekturen und ihr Zusammenspiel verbind-lich gelten.

� Vorgabe von Meßpunkten, wie die Synchronisationsfähigkeit der Architekturen gemessen und bewertet wird.

� Vorgabe, anhand welcher Architekturen die Einhaltung der strategischen Ziele belegt werden kann.

Tabelle 6.4-1: Architektur-QS-Bereiche

Zusammen mit einer intensiven, alle Projektbeteiligten umfassenden Kommunikation kann auf diese Art und Weise sichergestellt werden, dass architektonische Vorgaben während aller Prozessschritte kontinuierlich berücksichtigt und eingehalten werden. Formatives Archi-tekturqualitätsmanagement ist in diesem Sinn maximal konstruktiv.

6.4.3 Summatives Qualitätsmanagement

Aufgabe des summativen Qualitätsmanagements ist es, nach Abschluss einer Aktivität die qualitative Ausprägung

der Vorgaben in einer Architektur oder einem Architek-turentwurf zu prüfen (auf jeweils allen drei aufgezeigten Architekturkontexten). Grundsätzlich gibt es zwei ver-schiedene Arten, dies zu tun:

� Verifizierende Verfahren: Die summative, d.h. ex post betriebene Bestätigung im Nachhinein, ob vorhan-dene Abläufe die gewünschten Ergebnisse erzielen. Umgangssprachlich beantworten die verifizierenden Verfahren die Frage: „Wird das System richtig entspre-chend der Vorgaben gebaut?“.

� Validierende Verfahren: Im Gegensatz zu verifizieren-den Verfahren wird im Bereich der Softwarequalitäts-sicherung unter Validierung die Prüfung der Eignung

beziehungsweise der Wert eines Systems bezogen auf seinen Einsatzzweck verstanden. Umgangssprachlich beantworten die validierenden Verfahren also die Frage: „Wird das richtige System für einen konkreten Kontext gebaut?“

Beide Verfahren lassen sich grundsätzlich auf allen drei QS-Bereichen – syntaktische, semantische und strategi-sche Architektur-QS – anwenden; es liegt allerdings in der Natur der Sache, dass mit zunehmender Kontexterweite-rung die Verifikation zunehmend schwieriger wird. Von daher zeigt die Erfahrung die in der folgenden Abbildung dargestellten Anwendungsschwerpunkte verifizierender und validierender Tätigkeiten:

Abbildung 6.4-5: Verifizierende u. Validierende QS-Tätigkeiten

Beide Verfahren des summativen Qualitätsmanagements werden im Folgenden detailliert erläutert.

Verifizierende Verfahren

Das bekannteste und universell einsetzbare verifizierende Verfahren des Architektur-Qualitätsmanagements ist das Testen.

Wichtige Bestandteile der Beschreibung eines Testfalls sind (vgl. ISTQB):

� die Vorbedingungen, die vor der Testausführung hergestellt werden müssen (z.B. muss eine Architektur explizit als Testobjekt vorliegen),

� die Eingaben/Handlungen, die zur Durchführung des Testfalls notwendig sind (hier fließen die Anforderun-gen und Kriterien ein),

� die erwarteten Ausgaben/Reaktionen des Testobjek-tes auf die Eingaben (hier wird direkt auf Ergebnisse der S.M.A.R.T.E.R.-Anwendung verwiesen),

� die erwarteten Nachbedingungen, die als Ergebnis der Durchführung des Testfalls erzielt werden (diese sind für Architektur-QS-Aktivitäten meist irrelevant, da die Prüfungen nicht invasiv sind).

� die Prüfanweisungen, d. h. wie Eingaben an das Test-objekt zu übergeben sind und wie Sollwerte abzule-sen sind (z.B. manuelle Checklisten oder automatische Architektur-Verifikatoren).

Die Ermittlung der Testfälle zur Verifikation von Archi-tekturen sollte bereits bestmöglich im Kontext der S.M.A.R.T.E.R.-Konzept-Anwendung vorbereitet sein. Insbesondere die Spezifikation und die Terminierung sind eine gute Grundlage, Testfälle konzeptuell zu erstellen.

Für die Test-Durchführung, d.h. das Anlegen der Testfälle an die zu testende Architektur mit dem spezifizierten Architekturkontext, müssen die Testfälle allerdings noch mit konkreten Testdaten angefüllt werden. Ein Beispiel für einen Testfall ist die Prüfung, ob eine explizite Architektur eine Standard-Notation verwendet. Ein konkretes Testda-tum bedeutet eine spezifische Architektur eines Projektes (z.B. eine Deployment-Architektur) sowie die Vorgabe, UML 2.0 verwendet zu haben.

Es ist an dieser Stelle wichtig darauf hinzuweisen, dass das Testen von Architekturen fast das Ausführen des zugrundeliegenden Systems benötigt. Tests können auch simuliert (z.B. mittels eines „Walkthroughs“) werden, was insbesondere hilft, Tests vor einer Implementierung durchzuführen. Wichtig ist auch noch, dass Testen kei-neswegs nur für funktionale Architekturaspekte relevant ist: Auch Hardware-Architekturen lassen sich gut testen, indem eine geplante Hardware-Landschaft auf Überein-stimmung zu einer tatsächlichen Hardware-Landschaft geprüft wird (semantische Architektur-QS).

SyntaktischeArchitektur-QS

SemantischeArchitektur-QS

StrategischeArchitektur-QS

Validierende Verfahren

Jede Vorgabe des formativen Qualitätsmanagements sollte nach dem Abschluss eines Prozessschrittes durch einen Test geprüft werden. Wird eine Vorgabe nicht ent-sprechend geprüft, besteht das Risiko, dass Fehlentwick-lungen erst später erkannt werden und dann nur noch mit deutlich überhöhten Kosten und Aufwänden behoben werden können.

Im Folgenden werden für die jeweiligen QS-Aktivitäten einige Beispiele für validierende Verfahren aufgezeigt:

QS-Aktivität BeispielverfahrenSyntaktische Architektur QS

Checklisten für Existenz der expliziten Architektur, korrekte Notationen, korrektes Format, Versionsangaben der Architektur, Datumsangaben der Architektur, Autorinformationen

Semantische Architektur QS

Werkzeugbasierte Architektur-Checker wie CAST, Software-Tomograph und Bauhaus: Hier wird eine explizit gemachte Architektur (z.B. in UML) im Werkzeug hinterlegt. Gleichzei-tig erstellt das Werkzeug auf Basis desselben Dekompositi-onskriteriums eine Ist-Analyse des Systems. Der Abgleich liefert automatisch das Testergebnis.

Strategische Architektur QS

Checkliste zur Sicherstellung, dass mehrere zu synchronisie-rende Architekturen zum selben System in derselben Version passen.

Tabelle 6.4-2: QS-Aktivitäten - Beispielverfahren

Validierende Verfahren

Die validierenden Verfahren haben die Aufgabe, den Wert einer Architektur (inkl. des jeweiligen Architekturkontex-tes) hinsichtlich der Zielrelevanz und der Geschäftsstrate-gien grundsätzlich zu prüfen. Während die verifizierenden Verfahren obligatorisch nach jedem Prozessschritt durch-zuführen sind, werden die validierenden Verfahren meist erst bei speziellem Verdacht angewendet (s. hierzu später am Ende dieses Abschnittes). Dies gilt insbesondere dann,

wenn der Verdacht aufkommt, dass sich unterschiedliche Parameter des Systems und damit der Architekturen so stark geändert haben, dass selbst bei maximaler Erfül-lung der Vorgaben (verifizierende Verfahren) das System am Ende keine hohe Qualität aufweist. In einem solchen Fall können validierende Verfahren eine gute Möglichkeit liefern, eine bzgl. des späteren Einsatzszenarios wertende Aussage zu erhalten.

Das bekannteste Architektur-Validierungsverfahren ist das sogenannte ATAM-Verfahren. ATAM steht hierbei für Architecture Tradeoff Analysis Method [Kazman00]. ATAM selbst ist eine Weiterentwicklung der Software Architec-ture Analysis Method (SAAM), welche ebenfalls am SEI entwickelt wurde.

ATAM ist ein sogenanntes szenariobasiertes Architektur-bewertungsverfahren. Es nähert sich der Aufgabe, eine Softwarearchitektur zu bewerten (im Kontext des validie-renden Konzeptes), mittels unterschiedlicher Szenarien an. Die ursprüngliche Idee von ATAM adressiert klar die semantische Architektur QS, die im Folgenden auch für die Einführung von ATAM fokussiert wird. Die Grundzüge sind aber durchaus auch für syntaktische, insbesondere aber für strategische Architektur-QS anwendbar (s. hierzu weiter unten).

ATAM selbst unterscheidet grundsätzlich drei unterschied-liche Arten von Aktivitäten:

� Direkte Nutzungsszenarios (use case scenarios): Benutzungsszenarien beschreiben eine typische Interaktion eines Users mit dem System. Benutzer können hierbei ebenso vielfältig sein, wie dies bereits bei der Betrachtung der Qualität von Architekturen (s. unterschiedliche Architekturkriterien oben) erarbeitet wurde.

� Wachstumsszenarios (growth scenarios): Wachstums-szenarien beschreiben Vorgänge, die eine zukünftige Entwicklung des Systems simulieren, wie zum Beispiel eine Migration des Gesamtsystems auf eine andere Plattform, neue Technologien, neue Performance-Anforderungen o.ä. Solche Szenarien versuchen, die Zukunft vorauszuahnen. Da Architekturen i.d.R. eine lange Gültigkeit haben, ist dies eine wichtige

Möglichkeit, um den Wert einer Architektur auch für die Zukunft sicherzustellen.

� Extremszenarios (Exploratory scenarios): Explorative Szenarien sind solche, die Situationen beschreiben, bei denen das System speziell gefordert wird. Ziel ist es, die Limits eines Systems in Szenarios zu formulieren. Typische Fragestellungen solcher Szenarios sind „Was wäre wenn…“.

Diese Szenarien werden systematisch mit relevanten Schlüsselpersonen, die mit Architekturen in Kontakt kommen (s.o.) erhoben. Die Szenarien werden dabei einzeln auf ihre Auswirkung auf Geschäftsziele und Qualitätsattribute hin untersucht. Damit ist sichergestellt, dass die Architekturentscheidung nicht auf Basis von Szenarien basiert, die nur eine geringe Relevanz für die Geschäftsziele haben.

Jedes dieser Szenarien wird anschließend bzgl. aller Archi-tekturentscheidungen einer Architektur evaluiert. Die Grundfrage jeder einzelnen Analyse ist hierbei:

Wird das konkrete Szenario durch die konkrete Architek-turentscheidung unterstützt oder behindert?

Abbildung 6.4-6: ATAM-Analyse

Die grundsätzliche Struktur einer ATAM-Analyse ist in der folgenden Abbildung noch einmal dargestellt:

Das Ergebnis dieser Menge von Analysen mündet entlang von ATAM wie dargestellt in die folgenden 4 Ergebnismengen:

� Sensitivity points: Hierunter werden bestimmte Komponenten oder Aspekte der Architektur verstan-den, deren Gestaltung zur Erfüllung eines spezifischen Qualitätsmerkmals als erfolgskritischer Faktor bei-trägt (ermittelt durch die Analyse eines oder mehre-rer entsprechender Szenarien). Zum Beispiel ist die Verfügbarkeit eines Services in einem Client/Server-System positiv abhängig von der Anzahl eingesetzter Server.

� Tradeoff points: An diesen Architekturentscheidun-gen sind mehrere, teilweise konkurrierende Quali-tätsmerkmale gleichzeitig betroffen. So kann eine Entscheidung zu Gunsten des einen Merkmals sich negativ auf ein anderes auswirken. Tradeoffpunkte sind somit verschärfte und kritischere Sensitivitäts-punkte. Zum Beispiel ist die Sicherheit negativ von der Anzahl Server in einem System abhängig, d.h. die Anzahl Server ist ein Tradeoffpunkt zwischen Sicher-heit und Verfügbarkeit.

verdichtet zu

Qualitätsattribute

Architektur Ansätze

Szenarien

Architektur Entscheidung

Geschäftsziele

Architektur

Maßnahmen und Planung

ATAMAnalyse

Sensitivity points

Tradeoffs

Non-Risks

� Risiko-Punkte: An diesen Architekturentscheidungen ist ein definitives Risiko erkennbar, d.h. geschäftsrele-vante Szenarien werden durch spezifische Architek-turentscheidungen maßgeblich behindert. Hier muss durch geänderte Vorgaben gegengesteuert werden, die anschließend von verifizierenden Verfahren nach einem Prozessschritt kontinuierlich geprüft werden.

� Non-Risks: Alle Szenarien mit positivem Analyse-Ergebnis werden als Non-Risk subsumiert.

Als Ergebnis des validierendenden Verfahrens ist beson-ders die Liste der Risiken interessant, da sie Aufschluss darüber gibt, inwieweit eine aktuelle Architektur geschäftskritische Anwendungen unterstützt oder behin-dert. Die Risiko-Liste und deren Umfang korreliert daher direkt mit der Qualität, dem eigentlichen Thema des Architektur-Qualitätsmanagement.

Der Fokus einer ATAM-Analyse ist klar die semantische Architektur-QS. Eine untergeordnete Rolle spielt sie für die syntaktische Architektur-QS. Hier kann im Wesent-lichen evaluiert werden, ob rein syntaktische Vorgaben an die Architektur selbst zielführend bzgl. allgemeiner Anforderungen sind. Eine allgemeine Anforderung könnte beispielsweise die Anwendung einer proprietären Notation sein. Während verifizierende Verfahren evtl. die Korrektheit dieser Anforderung bestätigen, würde bei der ATAM-Analyse evtl. aufgedeckt werden können, dass diese proprietäre Notation im Unternehmen kaum noch Verwendung und insbesondere keinerlei Werkzeugunter-stützung erfährt.

Für die strategische Architektur QS ist ATAM allerdings das Verfahren schlechthin. Der wesentliche Unterschied zur oben formulierten Erläuterung besteht darin, dass Architekturentscheidungen unterschiedlicher Archi-tekturen für dieselben Use-Cases evaluiert werden. Der Use-Case „Datenbackup durchführen“ wird folglich nicht gegen die funktionale Architektur gespiegelt, sondern z.B. auch gegen die Security-Architektur, die Hardware-Architektur sowie die Rechte-Architektur. Der einzelne Evaluationsschritt evaluiert damit gleichzeitig die Syn-chronisationsfähigkeit unterschiedlicher Architekturen.

Im Ergebnis unterscheidet sich die Anwendung von ATAM für das strategische Architektur-QS nicht vom beschriebe-nen Verfahren.

Eine ATAM-Analyse als validierende Technik sollte immer angewendet werden, wenn

� sich relevante Parameter eines Systems oder eines Projektes geändert haben, um sicherzustellen, dass die verifizierenden Verfahren noch gegen die korrek-ten Vorgaben prüfen,

� im Kontext eines allgemeinen Risikomanagements als Teil eines Projektcontrollings die Architektur als risikobehaftet wahrgenommen wird,

� verifizierende Verfahren grundsätzlich und über einen längeren Zeitraum (ca. 12 Monate) Abweichungen identifizieren, die nicht behoben werden.

6.4.4 Empfehlungen

Aus den vorgestellten Überlegungen zum Thema Archi-tektur-Qualitätsmanagement lassen sich folgende direkt umsetzbare Empfehlungen ableiten:

� Die Architektur als solches ist ein dem Qualitätsma-nagement anzuvertrauendes Objekt. Auf Grund seiner frühen Präsenz im Software-Lebenszyklus können Abweichungen vom Qualitätsmanagement damit früh erkannt werden und bei Bedarf gegengesteuert werden.

� Unterschiedliche Bedarfsträger haben unterschied-liche Architektursichten mit jeweils assoziierten Anforderungen. Es ist Aufgabe des Qualitätsmanage-ments diese ganzheitlich zu dokumentieren, um keine Anforderungen zu vergessen.

� Architekturen treten in unterschiedlichen Kontex-ten auf, die jeweils unterschiedliche Anforderungen hervorrufen, die jeweils durch separate QS-Aktivitäten konterkariert werden müssen.

� Alle Anforderungen müssen konstruktiv mit Hilfe formativer Vorgaben definiert werden. Diese müssen dem S.M.A.R.T.E.R.-Konzept gehorchen, um tatsächlich konstruktiv im Projekt eingesetzt werden zu können.

� Alle Anforderungen müssen analytisch mit Hilfe sum-mativer Qualitätstechniken geprüft werden. Hierzu gehören verifizierende Verfahren, die prüfen, ob etwas richtig erstellt wurde (ob z.B. eine modellierte Archi-tektur zur tatsächlich umgesetzten passt) wie validie-rende Verfahren, die prüfen, ob die richtige Architektur für spezifische Anforderungen gewählt wurde.

Mit diesen Möglichkeiten, formativ Architekturen ganz-heitlich steuern zu können, und summativ möglichst frühzeitig Abweichungen zu identifizieren, ist ein effizi-entes und effektives Architektur-Qualitätsmanagement möglich.

� 6.5 Architektur Änderungsmanagement

Das Produkt der Architekturentwicklung, die Architektur/Architekturdatenbank, ist eine ‚lebende‘ Dokumenta-tion, die der stetigen Änderung ihrer Grundlagen (neue Anforderungen, neue Technologien und Standards etc.) Rechnung tragen muss.

Es kann sein, dass die Architektur in allen Sichtweisen noch nicht vollständig ist oder geringfügige Lücken bei Darstellungen, Definitionen oder Zuordnungen aufweist. Ferner können Änderungen von Abläufen, Organisations-strukturen, Technologien die Architekten zwingen, die Architektur anzupassen. Deshalb muss ein Änderungsma-nagement eingerichtet werden.

Es sollte folgende Gesichtspunkte abdecken: � Einreichung von Änderungsvorschlägen, � Review der Änderungsvorschläge, � Entscheidung der Änderungsvorschläge, � Anpassung der Architektur oder Einleitung eines

neuen Entwicklungszyklus basierend auf dem ange-nommenen Änderungsvorschlag.

Jede Architektur sollte durch eine Vielzahl von Stakehol-dern überprüft werden, um die Vollständigkeit und Rich-tigkeit zu erhöhen und die Qualität zu verbessern. Folglich sollte das Änderungsvorschlagswesen leicht zugänglich

sein und jedem Nutzer (ggfs. unter Berücksichtigung von Zugriffsrechten) erlauben die Architektur zu nutzen und zu überprüfen, um Änderungsvorschläge einzureichen. Die folgenden Informationen sollten (vorzugsweise automa-tisch) angefügt sein, um Änderungsvorschläge effizient handhaben zu können.

� Autor des Änderungsvorschlags, � Kontaktdaten (für mögliche Rückfragen), � Gegenstand des Änderungsvorschlags, � Referenz zur Architektur (z.B. Diagramm, Entität,

Matrix etc.), � Beschreibung/Grund, � Vorschläge, � Bezugsdokumente, Verweise, � Anhänge.

Die Verwaltung von Änderungsvorschlägen sollte inner-halb eines Anforderungsmanagementwerkzeugs realisiert werden. Somit könnten Anforderungen und Architektu-rinhalte, auf die sich ein Änderungsvorschlag auswirkt, parallel und konsistent bearbeitet werden. Die folgende Auflistung stellt zusätzliche administrative Informatio-nen dar, die zur Handhabung der Änderungsvorschläge erforderlich sind:

� Identifikationsnummer, � Status (erhalten, geprüft, angenommen, abgelehnt), � Kategorie (inhaltsbezogen, Design, Zusatz, Löschung,

Korrektur), � Priorität (hoch, mittel, niedrig), � Kommentar (Beschreibung von Einflüssen/Auswirkun-

gen, falls die Änderung angenommen wird), � Empfehlungen.

Eingehende Änderungsvorschläge werden für die weitere Bearbeitung bewertet und priorisiert. Zudem müssen die Implikationen eines Änderungsvorschlags untersucht werden. Nach dem Entscheidungsprozess in Bezug darauf, ob der Änderungsvorschlag angenommen wird oder nicht, wird der Status angepasst und daraus resultierende Aktivitäten eingeleitet. Der Initiator des Änderungs-vorschlags sollte eine Rückantwort über die getroffene Entscheidung erhalten.

� 6.6 Architektur Sicherheitsmanagement

Sicherheit muss in den gesamten Architekturerstellungs-prozess, aber auch in den kompletten Lebenszyklus der resultierenden Systeme, Organisationen und Anwen-dungen eingebunden werden. Um dies zu ermöglichen, bieten internationale Standards, wie die ISO 27001 ein Framework, welches das Management der Sicherheit für die einzelnen Phasen ermöglicht und in einem ganzheitli-chen Gesamtkonzept vereint.

Der Ablauf zur Entwicklung eines sicheren Architektur-konzepts ist allgemein nach ISO 27001 in Abbildung 6.6-1 dargestellt.

Abbildung 6.6-1: PDCA nach ISO 27001

Die in Abbildung 6.6-1 abgebildeten vier Schritte Plan, Do, Check und Act (kurz PDCA) werden im Folgenden erläutert.

� Plan Um die sicherheitstechnischen Anforderungen an die Architektur festlegen zu können, bedarf es einer Risikoanalyse. Dabei werden die möglichen Risiken des Systems, welches durch die Architektur umgesetzt werden sollte, analysiert, bewertet und dokumentiert. Die Architektur wird dahingehend angepasst, so dass

alle Risiken einen von der Führungsebene definierter Risikolevel erreichen oder unterschreiten. Die Restri-siken müssen von der Führungsebene akzeptiert und das Architekturkonzept an den Organisationszielen ausgerichtet werden.

� Do Im nächsten Schritt wird das Architekturkonzept entsprechend den erarbeiteten Anforderungen entwi-ckelt und zum Review bereitgestellt. Dabei sollten die geplanten Maßnahmen zur Einhaltung des Risikole-vels bestmöglich umgesetzt werden.

� Check In dieser Phase erfolgt die Überprüfung der Umset-zung, der in der Plan-Phase, erarbeiteten Sicherheits-anforderungen und ob die jeweiligen akzeptieren Risi-

kolevel eingehalten werden konnten. Die Ergebnisse müssen wieder an die Führungsebene kommuniziert werden.

� Act Wurden die Ziele nicht gänzlich erreicht, so wird das Architekturkonzept entsprechend angepasst, um die gestellten Sicherheitsanforderungen zu erfüllen. Änderungen zum Erreichen des Risikolevels werden in einem erneuten PDCA Lebenszyklus umgesetzt.

Sicherheit sollte jedoch nicht nach der Erstellung des Architekturkonzeptes enden, sondern muss in den

Establish ISMS

Monitor andreview the ISMS

Implement andthe ISMS

Maintain andthe ISMS

Interested Parties Interested Parties

Information securityrequirements and

expectations

Managed information security

gesamten Lebenszyklus der daraus resultierenden Anwendung oder des daraus resultierenden Systems miteinbezogen werden, um einen optimalen Grad an Sicherheit für die jeweilige Organisation und das jewei-lige Projekt zu erzielen.

7 Referenz- und Quellenverzeichnis

/1/ Anstand e.V.: „V-Modell 97“, (http://www.ansstand.de/downloads.html#vm97)

/2/ KBSt: „V-Modell XT”, (http://www.v-modell-xt.de)

/3/ Wikipedia: „Agile Softwareentwicklung”, (http://de.wikipedia.org/wiki/Agile_Softwareentwicklung)

/4/ Teilkonzeption Führungsunterstützung Bundeswehr und IT-System der Bundeswehr (TK FüUstgBw und IT-SysBw), Stand: 08.08.2006, VS-NfD

/5/ AG Architektur Bundeswehr: Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw; ämterseitig mitgezeich-nete Vorlageversion zur ministeriellen Billigung; Stand: 02.06.2008

/6/ NATO C3 System Architecture Framework, Document AC/322-D(2004)0041, 13 September 2004

/7/ Object Management Group (OMG), Unified Modeling Language: Superstructure version 2.1.2 formal/2007-11-02 (UML Version 2.1.2), November 2007 http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

/8/ Architekurrahmenwerk IT-SysBw.

/9/ Architekturerarbeitung und -bearbeitung IT-SysBw.

/10/ http://v-modell.iabg.de/index.php?option=com_content&task=view&id=25&Itemid=46

/11/ http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.2/ (ftp Site mit Material)

/12/ http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.2/Schulungsmaterial/Lerntour/lerntour-online/ (Lerntour zum V-Modell XT der TU Kaiserslautern)

/13/ http://www.microtool.de/instep/de/index.asp (Hersteller des Tools in-Step)

Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. vertritt mehr als 1.300 Unternehmen, davon 950 Direktmitglieder mit etwa 135 Milliarden Euro Umsatz und 700.000 Beschäftigten. Hierzu zählen Anbieter von Software, IT-Services und Telekommunikationsdiensten, Hersteller von Hardware und Consumer Electronics sowie Unternehmen der digitalen Medien. Der BITKOM setzt sich insbesondere für bessere ordnungspolitische Rahmenbedingungen, eine Modernisierung des Bildungssystems und eine innova-tionsorientierte Wirtschaftspolitik ein.

Der Zentralverband Elektrotechnik- und Elektronikindustrie e.V. vertritt die wirtschafts-, technologie- und umweltpolitischen Interessen der deutschen Elektroindustrie auf nationaler, europäischer und internationaler Ebene. Er informiert gezielt über die wirtschaftlichen, technischen und rechtlichen Rahmenbedingungen für die Elektroindustrie in Deutschland. Der Fachverband Wehrtechnik des ZVEI versteht sich als Dialogplattform Bundeswehr / Industrie und will Wege aufzeigen, wie der vom zivilen Markt her bestimmte technologische Fortschritt insbesondere auf dem Gebiet der Informations- und Kommunikationstechnik für die Bundeswehr genutzt werden kann.

Bundesverband Informationswirtschaft,Telekommunikation und neue Medien e. V.

Albrechtstraße 10 A10117 Berlin-MitteTel.: 03o.27576-0Fax: 030.27576-400bitkom@bitkom.orgwww.bitkom.org

Zentralverband Elektrotechnik- und Elektronikindustrie e.V.

Lyoner Straße 960528 Frankfurt am MainTel.: 069.6302-0

zvei@zvei.orgwww.zvei.org

Der vorliegende Leitfaden ist mit der Unterstützung folgender Unternehmen entstanden:

Leitfaden.architekturentwicklung.in.Der.industrie

Documents

Transcript of Leitfaden.architekturentwicklung.in.Der.industrie

Kress SpareParts 600PX_liste

Contribution to Design and Scale-Up of Packed Columns

Wulff

Ram

Silverado 2500 hd diesel bob jass chevy elburn, il

culori vw

Sanyo_Q40

C3_manual_01

32LXW82

Lucas

Ägyptische Lesestücke - Sethe - Intef hijo de Senet.

Blue Screen

Stress als hormoneller Vorgang

Die v Lkerwanderung Europa Zwischen Antike Und Mittelalter

Cruz_Diss_2012

Kostenpflichtige iPhone Apps | Eine Empfehlung

045_Titanflex-Fassungen

Bei Mir Bist Du Schon

katalog

C172 D Flughandbuch