Leitfaden Architekturentwicklung in Der Industrie

Architekturentwicklung in der wehrtechnischen Industrie
Impressum
Herausgeber: BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. Albrechtstrae 10 A 10117 Berlin-Mitte Tel.: 030.27576-0 Fax: 030.27576-400 bitkom@bitkom.org www.bitkom.org Ansprechpartner: Michael Barth (BITKOM) Tel.: 030.27576-102 m.barth@bitkom.org Redaktion: Friedrich W. Benz (ZVEI) Tel.: 069.6302-242 benz@zvei.org ZVEI Zentralverband Elektrotechnikund Elektronikindustrie e.V. Lyoner Strae 9 60528 Frankfurt am Main Tel.: 069.6302-0 zvei@zvei.org www.zvei.org
Christoph Reich (ESG Consulting GmbH), Oliver Burghardt (CSC Deutschland Solutions GmbH)
Redaktionsassistenz: Juliane Kukla (BITKOM) Gestaltung / Layout: Design Bureau kokliko / Anna Mller-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 Zeitpunkt der Verffentlichung wider. Obwohl die Informationen mit grtmglicher Sorgfalt erstellt wurden, besteht kein Anspruch auf sachliche Richtigkeit, Vollstndigkeit und/oder Aktualitt, insbesondere kann diese Publikation nicht den besonderen Umstnden des Einzelfalles Rechnung tragen. Eine Verwendung liegt daher in der eigenen Verantwortung des Lesers. Jegliche Haftung wird ausgeschlossen. Alle Rechte, auch der auszugsweisen Vervielfltigung, liegen beim BITKOM und ZVEI.
Inhaltsverzeichnis
1 Einleitung 1.1 Zielsetzung 1.2 Hintergrund 1.3 Zusammenfassung 1.4 Ausblick Glossar Vorgaben und Randbedingungen der Bundeswehr 3.1 Teilkonzeption Fhrungsuntersttzung und IT-System Bundeswehr 3.2 Customer Product Management (CPM) 3.3 V-Modell 3.4 NATO Architecture Framework 3.5 Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw 3.6 Existierende Konventionen der Bundeswehr 3.7 IT-Sicherheit Notwendigkeiten und Randbedingungen der Auftragnehmerseite im Verteidigungsbereich 4.1 Anforderungsmodellierung & Interessengruppen 4.2 Nutzung und Vergleichbarkeit von Architekturen 4.3 Unterschiedliche Ausprgungen von Architekturen 4.4 Auswahl von Design- und Entwicklungsmethoden 4.5 Migration von Legacy-Systemen 4.6 IT-Sicherheit Erarbeitung von IT-Architekturen 5.1 Architektur-Vorbereitung 5.2 Architektur-Entwicklung 5.3 Architektur-Anwendung 5.4 Architektur-Publikation Architektur-Management 6.1 Management Grundlagen 6.2 Architektur-Anforderungsmanagement 6.3 Architektur-Konfigurationsmanagement 6.4 Architektur-Qualittsmanagement 6.5 Architektur nderungsmanagement 6.6 Architektur Sicherheitsmanagement Referenz- und Quellenverzeichnis 3 3 3 4 4 5 6 6 8 17 23 28 29 33 34 34 37 39 40 44 50 53 53 60 67 75 77 77 79 80 80 91 92 94
2 3
1 Einleitung
1.1 Zielsetzung
Der Leitfaden hat den verbesserten Informationsaustausch zum Thema IT-Architekturen zwischen der Bundeswehr als Auftraggeber und der im wehrtechnischen Umfeld ttigen Industrie als Auftragnehmer zum Ziel. Daher soll er eine gemeinsame Wissensbasis fr Architekturentwicklungen bilden, die Vorgaben und Randbedingungen der Bundeswehr reflektieren, die Notwendigkeiten und Randbedingungen der wehrtechnischen Industrie aufzeigen; Wege zur gemeinsamen Erarbeitung von IT-Architekturen vorschlagen sowie Mglichkeiten zum Architektur-Management aufzeigen. Diese Ziele knnen durch strukturierte Zusammenarbeit und intensiven Informationsaustausch zwischen der Arbeitsgruppe (AG) Architektur des Bundesamts fr Informationsmanagement und Informationstechnik der Bundeswehr (IT-AmtBw) und dem gemeinsamen Arbeitskreis (AK) IT-Architekturen des ZVEI und des BITKOM erreicht werden. Dabei soll der Leitfaden evolutionr 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. Die Bundeswehr hat hierzu die AG Architekturen mit Vertretern aller Organisationsbereiche eingerichtet und in einem ersten Schritt die Rahmenregelung erarbeitet. Industrieseitig hat sich in den Verbnden BITKOM und ZVEI der gemeinsame AK IT-Architekturen mit der Die Bundeswehr fhrt seit Jahren zahlreiche Projekte unterschiedlichen Umfangs (Studien, F&T-Projekte, Systemintegrations- und -entwicklungsprojekte usw.) durch, die in entscheidendem Mae durch IT-Architekturen bestimmt werden. Hierbei werden unterschiedliche Anwendungsbereiche, z.B. die Erfassung der operationellen-, system- und technischen Anforderungen im Rahmen Thematik befasst und den vorliegenden Leitfaden erstellt. Beide Gremien verfolgen das Ziel, durch enge Zusammenarbeit und Informationsaustausch die Voraussetzungen dafr 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. Durch die Vielschichtigkeit und die zahlreichen Einflussfaktoren im Zusammenhang mit der Entwicklung von IT-Architekturen hat sich die Notwendigkeit ergeben, sowohl auf Auftraggeber- als auch auf Auftragnehmerseite ein gemeinsames Verstndnis herzustellen und gemeinsam abgestimmte Richtlinien fr die Planung, Erstellung und das Management von IT-Architekturen herauszugeben. Ferner sind Anforderungen an die Interoperabilitt von Systemen, die sich aus den heutigen Einsatzerfordernissen, insbesondere Einstze im internationalen Umfeld ergeben, durch Vorgaben der NATO oder EU geprgt und mssen bercksichtigt werden. Die oben aufgefhrten Aspekte beleuchten nur einen Teil der Auftraggeber-Auftragnehmer-Schnittstelle im Themenbereich IT-Architekturen. des CPMs oder die Integration von Fhrungsinformationssystemen in eine Systemlandschaft abgedeckt, die verschiedenartige Architekturtypen zum Ergebnis haben. Bei der Realisierung der Projekte auf Auftragnehmerseite ist wiederum eine Vielzahl unterschiedlicher Unternehmen involviert. Zudem steht zur Erstellung von IT-Architekturen eine groe 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 Verfgung.
1.2 Hintergrund
1.3 Zusammenfassung
Der vorliegende Leitfaden in der Version 1.0 bietet eine erste praktische Hilfestellung und Wissensbasis fr die Planung, Durchfhrung und Abwicklung von IT-Architekturen sowohl fr die Auftraggeber- als auch fr 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 bercksichtigt, ausgehend von den Randbedingungen der Bundeswehr und der Industrie ber die Entwicklung von IT-Architekturen bis hin zu den Managementaufgaben wie z.B. Qualittsmanagement, Konfigurationsmanagement, nderungsmanagement Anforderungsmanagement Rollenmanagement Vielfach werden die ausgefhrten 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 bercksichtigt werden sollten. Der Leitfaden bietet somit eine solide Grundlage fr den Weg zu einem gemeinsamen Verstndnis fr die Entwicklung von IT-Architekturen, der insgesamt zu verbesserten Ausschreibungen und Abwicklungen von Projekten sowohl auf Auftraggeber- als auch auf Auftragnehmerseite fhren kann.
1.4 Ausblick
Es wurden bereits jetzt folgende Themenfelder identifiziert, die in der nchsten Version des Leitfadens behandelt und ergnzt werden sollen: Abschtzen des Aufwandes Identifikation und Priorisierung von Modellierungsbereichen Weitere Aspekte der Modellierung Referenzarchitekturen und Brche bei Architekturwechseln Zudem werden durch die geplanten Aktivitten auf Auftrageberseite, wie u.a. die Neuerstellung eines Architekturhandbuchs in acht Bnden, die Randbedingungen (siehe Kap.3) modifiziert. Eine enge Zusammenarbeit des industrieseitigen Arbeitskreises mit der AG Architektur hat das Ziel, die Weiterentwicklung und das Wissen in der Thematik IT-Architekturen auszutauschen. Sie bildet die Grundlage, relevante neue Erkenntnisse in den Leitfaden einzuspeisen.
2 Glossar
Begriff Architektur Erluterung 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]. Qualitt 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 Zusammenhang mit Vorgehensmodellen. Testen Entsprechend des ISTQB-Standards wird unter Testen eine Menge von Testfllen und deren Abarbeitung verstanden. Validierung Gem der ISO 9000:2005, Abschnitt 3.8.5, ist "Validierung" die Besttigung durch objektiven Nachweis, dass die Anforderungen fr eine bestimmte Anwendung oder einen bestimmten Gebrauch erfllt sind. Verifizierung Die DIN EN ISO 8402 vom August 1995, Ziffer 2.17 versteht unter Verifizierung das Besttigen auf Grund einer Untersuchung und durch Bereitstellung eines Nachweises, dass festgelegte Forderungen erfllt worden sind.
3 Vorgaben und Randbedingungen der Bundeswehr

3.1 Teilkonzeption Fhrungsuntersttzung und IT-System Bundeswehr 3.1.1 Hintergrund und Zielsetzung
Die Teilkonzeption Fhrungsuntersttzung Bundeswehr und IT-System Bundeswehr (TK FUstgBw und IT-SysBw) vom 8.8.2006 bildet die konzeptionelle Handlungsgrundlage fr die Bedarfsermittlung und die Planung im Rahmen der Aufgaben der Fhrungsuntersttzung Bundeswehr (FUstgBw) sowie fr die personelle, organisatorische, infrastrukturelle und materielle Ausgestaltung des IT-System Bundeswehr (IT-SysBw). Sie regelt die Zustndigkeiten und Verantwortlichkeiten bzw. schreibt diese fort. Die TK identifiziert und beschreibt wesentliche Elemente der IT-Strategie der Bundeswehr in Einklang mit der militrischen Ausrichtung der Streitkrfte, die in der Konzeption der Bundeswehr (KdB) vom 9.8.2004 formuliert wurden. Grundbetrieb und FUstg im Heimatland Operationsfhrung (NetOpF) erlangt wird. Dabei kommt der Fhrungsuntersttzung (FUstg) bei der Erlangung einer effektiven Fhrungsfhigkeit eine besondere Bedeutung und Verantwortung zu. Fhrungsuntersttzung umfasst das Informationsmanagement, die Informationsversorgung und die Sicherheit in der Informationstechnik (IT-Sicherheit).
berlebensfhigkeit und Schutz Wirksamkeit im Einsatz Nachrichtengewinnung und Aufklrung
Einsatzbetrieb auf Basis NetOpF
Abbildung 3.1-2: Prinzipskizze IT-System der Bundeswehr, Quelle: BMVg, IT-Direktor
Fhigkeitskategorien
Fhrungsuntersttzung Mobilitt Untersttzung und Durchhaltefhigkeit
Die KdB bertrgt in diesem Zusammenhang ausdrcklich 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 FUstgBw & IT-SysBw zudem
Abbildung 3.1-1: Fhigkeitskategorien der Bundeswehr gem KdB
wesentliche Vorgaben und Rahmenbedingungen fr die Umsetzung der Fhrungsuntersttzung im IT-SysBw, die fr diesen Leitfaden von besonderer Bedeutung sind und
Die Gesamtheit der in der KdB beschriebenen Fhigkeitskategorien ist so auszugestalten, dass schrittweise und abgestuft die Befhigung zur vernetzten
in nachfolgenden Kapiteln nher beschrieben werden: Architekturen bzw. architekturbasierte Vorgehensweise
Interoperabilitt Qualittsmanagement
Die Aufgabe der Vorgehensweise / Methodik ist es sicherzustellen, dass die Ergebnistypen mit einer grtmglichen Effizienz, in einer bestmglichen Qualitt von den dafr zustndigen Personen erstellt werden. Sie stellt zudem sicher, dass keine relevanten Ergebnistypen vergessen werden.
3.1.2 Architekturen
Die TK nimmt eine Definition des Themenkomplexes Architektur vor und stellt die besondere Relevanz fr die Bundeswehr dar. In der Informatik wird das Zusammenwirken der einzelnen Elemente komplexer Systeme durch Architekturen beschrieben. Architekturen, als eine formale, international standardisierte Methode ermglichen der Bundeswehr eine detaillierte vergleichende Darstellung, Analyse und Beurteilung funktionaler operationeller Forderungen und technischer Fhigkeiten. Architekturmodellierung auf der Basis eines festgelegten Architekturrahmenwerkes dient dem Zweck, bei der Realisierung von komplexen IT-Systemanteilen grtmgliche Interoperabilitt und Effizienz zu erzielen. (TK FUstg & IT-SysBw, S. 19) Architektur wird darin als eine methodische Vorgehensweise definiert und festgeschrieben. Gleichzeitig werden die Begriffe der Methode Architektur oder Architekturmethode geprgt, die inzwischen zunehmend angewendet werden. Leider ist diese Definition im Hinblick auf die Differenzierung von Ergebnistypen, Produkten und Vorgehensweise (Methodik) etwas unscharf und entfernt sich diesbezglich von gngigen Definitionen in der zivilen Industrie. Dies kann somit leicht zu Missverstndnissen fhren.
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 ausdrckt. In Analogie zur Gebude-Architektur ist die zugrundeliegende Architektur des Gebudes 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 fr die Bundeswehr die Methode Architektur nicht nur darin bestehen kann, Ergebnistypen zu haben und anzuwenden. Es ist vielmehr mindestens ebenso wichtig eindeutig zu beschreiben, wie diese Ergebnistypen von wem und wann zu benutzen sind. Die verwendete Definition des Begriffs Architektur in dieser TK orientiert sich zunchst an Vorgaben aus der Informationstechnologie (IT). Tatschlich ist diese Definition aber weitergehender gefasst und schliet operationelle Architekturen oder gar Unternehmensarchitekturen mit ein. Dies ist konform zu entsprechenden Anstzen der Indus-
An dieser Stelle erfolgt daher eine entsprechende Differenzierung zur Klrung des Sachverhalts. Die Anwendung einer Vorgehensweise oder Methodik (Wie, Wer, Womit, Wann) fhrt zu einem oder mehreren Ergebnistypen (Was). Ein Ergebnistyp kann dabei die technische Beschreibung der Architektur oder die Liste smtlicher fachlicher oder technischer Anforderungen des zugrundeliegenden Systems bzw. Objekts sein.
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 Geschftsfelder. Operationelle Architekturen Diese werden im zivilen Umfeld oft auch als
Facharchitekturen (engl. Business Architecture) bezeichnet. Im militrischen 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 primr ein System of Systems. IT-Architektur (engl. IT Architecture) Damit werden allgemein Lsungsarchitekturen innerhalb von IT-Systemen beschrieben. Dieser Begriff wiederum besitzt vielschichtige Konkretisierungen in Abhngigkeit der technischen Aspekte, z.B. Hardware, Software, Infrastruktur. Diese grundstzliche Festschreibung von architekturbasierten Anstzen bzw. einer entsprechenden methodischen Vorgehensweise bringt eine Reihe notwendiger Fragestellungen sowie den Bedarf zustzlicher, konkreter Vorgaben in diesem Zusammenhang mit sich. Dazu wird ausdrcklich auf die existierenden Vorgehensweisen der NATO1 und anderer militrischer Partner2 verwiesen, die als konzeptionelle Grundlage fr weitere Vorgaben genutzt werden. Zudem werden zwei Folgedokumente dieser TK definiert, mit denen die Erarbeitung, Darstellung und Pflege von Architekturen fr das IT-SysBw verbindlich geregelt werden sollen: Architekturrahmenwerk IT-SysBw Architekturerarbeitung und -bearbeitung IT-SysBw
Interoperabilitt bezeichnet die Fhigkeit, in Synergie in der Erfllung von zugeteilten Aufgaben zu operieren. (TK FUstgBw & IT-SysBw, Seite 18) Die Fhigkeit zur Interoperabilitt ist eine zwingende Voraussetzung eines durchgngigen IT-SysBw. Dabei ist diese Durchgngigkeit wiederum eine Grundvoraussetzung fr die Erlangung der Fhigkeit zur vernetzten Operationsfhrung. Mit einem ganzheitlichen, architekturbasierten Ansatz kann die geforderte Durchgngigkeit im IT-SysBw erzielt werden, was damit einen Schlssel zum Erfolg bei der Befhigung zu NetOpF darstellt. Die TK stellt insbesondere fest, dass die erforderliche Fhigkeit zur Interoperabilitt einen fortwhrenden Management-Prozess verlangt und nur durch die Festlegung und Einhaltung sowohl ziviler als auch militrischer Standards zu erreichen ist. Eine mittel- und langfristig erfolgreiche Architekturmethode muss diesen Aspekten angemessen Rechnung tragen.
3.1.4 Qualittsmanagement
Die Aufgaben und Mglichkeiten des Qualittsmanagement werden detailliert im Punkt 6.4. erlutert.
3.2 Customer Product Management (CPM)

Der CPM (Customer Product Management) enthlt die Verfahrensbestimmungen fr 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
3.1.3 Interoperabilitt
Im Kontext von NetOpF wird Interoperabilitt als eine entscheidende, umfassende Teilfhigkeit identifiziert, die im Grundsatz zunchst nicht auf IT-Systeme beschrnkt ist.
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 Fhigkeiten der Bw. Hierbei sind Leistungen, Zeit und Kosten als Ganzes zu betrachten. Damit die Einsatzfhigkeit des Gesamtsystems Bundeswehr gewhrleistet wird, haben streitkrftegemeinsame Lsungen Vorrang vor Teillsungen und Systembeschaffungen Vorrang vor Komponentenbeschaffungen.
erforderlichen Interoperabilitt zwischen Sensoren, Fhrungsinformations- und Kommunikationssystemen sowie Effektoren unabdingbar. Das Beispiel Luftnahuntersttzung (Close Air Support, CAS) soll die Komplexitts- und Interoperabilittsproblematik verdeutlichen. Im Rahmen von CAS wirken Teileinheiten der Luftstreitkrfte eng mit Teileinheiten der Landstreitkrfte zusammen. Hierbei ist die Kommunikation teilstreitkraftbergreifend zwischen landbasierten Krften untereinander (der Fliegerleitoffizier/Forward Air Controller mit dem Bataillonskommandeur und mit dem Luftwaffenverbindungsoffizier/Air Liaison Officer), zwischen landbasierten und luftbasierten Krften (der Forward Air Controller und der Air Liaison Officer mit dem/den Piloten) sowie zwischen luftbasierten Krften untereinander (den Piloten) erforderlich, die ber VHFund UHF-Funk erfolgt. Neben Sprachfunk (i.d.R. formatierten Funksprchen) wird bzw. knnte auch Datenfunk (z.B. fr die Zieldaten) angewendet werden. Die Zielerfassung, Ermittlung der Zieldaten und deren bermittlung an das Luftfahrzeug sowie ggf. die (teil-)automatisierte Einspeisung der Zieldaten in das Waffensystem sind durch verfgbare Produkte untersttzbar. Werden zustzlich die Inhalte und die Struktur bzw. Formate der auszutauschenden Informationen bzw. Daten bercksichtigt zeigt sich deutlich, wie komplex eine solche Einsatzart ist und welche Herausforderungen an die Interoperabilitt bei Durchfhrung auftreten. Und hierbei ist weder das Problem der Freund-Feind-Kennung, der Abstimmung mit anderen militrischen Krften, z.B. mit der Artillerie, (Vermeidung von Ausfllen durch eigenen Beschuss/ Friendly Fire) sowie das enge Zeitfenster, das in der Regel fr die Durchfhrung solcher Einstze zur Verfgung steht, in die Betrachtung mit einbezogen. Ein solches Szenar ist ohne geeignete visuelle Darstellung in Form von standardisierten Architekturmodellen in seiner Komplexitt sehr schwer versteh-, analysier- und kommunizierbar. Das hat entsprechende Auswirkungen auf die erreichbare Qualitt bei der Bedarfsermittlung und der Bedarfsdeckung.
3.2.1 Beziehungen zwischen dem CPM und Architekturen

Die Bundeswehr sieht sich auf Grund ihres erweiterten Einsatzspektrums, des Einsatzes auftragsspezifisch aufgestellter Krfteanstze, der regelmigen Einbindung dieser Krfte in truppengattungs-, teilstreitkrafts- und nationenbergreifenden Strukturen sowie der angestrebten bzw. optimierten Fhigkeit zur vernetzten Operationsfhrung (NetOpF) einem wesentlichen Komplexittszuwachs hinsichtlich der Planung und Durchfhrung militrischer Einstze gegenbergestellt. Diese erhhte Komplexitt hat Auswirkungen auf die Bedarfsermittlung und die Bedarfsdeckung in der Bundeswehr. Architekturen stellen eine Abstraktion der Realitt dar und untersttzen bzw. vereinfachen dadurch das Analysieren und Managen komplexer Sachverhalte. Die Vorgabe standardisierter Architekturdarstellungen bzw. -modelle frdert eine gemeinsame Sprache zwischen den unterschiedlichen Bearbeitern und Nutzern von Architekturen. Eine durch standardisierte Architekturmodelle untersttzte gemeinsame Vorstellung ber vorhandene Fhigkeiten oder vorliegende Fhigkeitslcken, Lsungsmglichkeiten sowie den operativen und technischen Rahmenbedingungen, denen sich die zu beschaffenden Produkte oder Dienstleistungen anpassen mssen, ist eine Notwendigkeit im Planungsprozess zwischen Bedarfstrger, Bedarfsdecker und der gewerblicher Wirtschaft. Insbesondere unter dem Gesichtspunkt NetOpF ist eine umfassende und eindeutige Beschreibung der operativen und technischen Vorgaben fr die Herstellung der
Eine optimierte Zusammenarbeit zwischen Bedarfstrger und Bedarfsdecker sowie zwischen Auftraggeber und Auftragnehmer, die zu effektiven und effizienten Lsungen in Form von Produkten und/oder Dienstleistungen fhren soll, erfordert insofern: das Wissen und das gemeinsame Verstndnis ber die operativen und technischen Rahmenbedingungen bzw. Vorgaben, in die die Produkte und/oder Dienstleistungen integriert bzw. angepasst werden mssen, die eindeutige Kommunikation dieser operativen und technischen Rahmenbedingungen bzw. Vorgaben sowie die Kenntnis ber die finanziellen und zeitlichen Aspekte von Projekten unter Bercksichtigung von Abhngigkeiten mit anderen Projekten oder Programmen. Daher ist eine Ergnzung von Phasendokumenten mit Architekturdarstellungen bzw. -modellen (d. h. die Detailsichten/ Sub Views) ggf. unterschieden nach verbindlichen oder obligatorischen Bestandteilen dieser Phasendokumente anzustreben. Hierfr liefert beispielsweise das Architekturrahmenwerk NAF Untersttzung, indem es Detailsichten/ Sub Views auf Interessengruppen (Communities of Interest, CoI) abbildet, d.h., fr jede Detailsicht angibt, welche Interessengruppe (u.a. Fhigkeitsmanagement, Beschaffungsmanagement und Hersteller) durch sie untersttzt wird. Der CPM untersttzt die frhzeitige Bercksichtigung der durch die gewerbliche Wirtschaft hervorgebrachten Innovationen, was auch gerade die Informations- und Kommunikationstechnologie ber Jahrzehnte geprgt hat. Aber auch innovative Technologien mssen mglichst nahtlos mit etablierten Technologien zusammenwirken, da ein regelmiger und durch Innovationen getriebener Neuansatz fr smtliche, vor allem auch im Rahmen von NetOpF, zusammenwirkenden Informationsverarbeitungs- und Kommunikationssystemen, wirtschaftlich und zeitlich nicht realisierbar ist. Hier bentigt die gewerbliche Wirtschaft verbindliche, aber auch verstndliche 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-, Einfhrungsund Nutzungsphase. Die Projektierungsphase kann in Abhngigkeit vom Realisierungsrisiko bersprungen werden. Sie ist aber grundstzlich bei der Realisierung neuer Produkte zu durchlaufen. Die Einfhrungs- und Nutzungsphase knnen sich zeitlich berlappen. Einerseits knnen mit Vorliegen der Stufenentscheidung Genehmigung zur Nutzung (GeNu) Produkte schon in den Verantwortungsbereich des Nutzers bergeben bzw. bernommen werden. Andererseits endet die Einfhrungsphase aber erst nach Auslieferung des letzen Stcks bzw. Projektanteils mit dem Phasendokument Abschlussbericht (ASB). Die einzelnen Phasen des CPM werden mit Phasendokumenten abgeschlossen. Diese enthalten smtliche Forderungen und Vorgaben fr die jeweils nachfolgende Phase. Sie sind zugleich haushaltsbegrndende Unterlagen fr die in der nachfolgenden Phase erforderlichen Haushaltsmittel. Die Abschlieende funktionale Forderung (AF) beendet die Analysephase und legt den Lsungsweg fest. Die Abschlieende funktionale Forderung/Realisierungsgenehmigung (AF/ReG) beendet die Analysephase, wenn die Projektierungsphase auf Grund beherrschbaren Realisierungsrisikos entfallen kann. Die Realisierungsgenehmigung (ReG) beendet die Projektierungsphase. Der Abschlussbericht (ASB) beendet die Einfhrungsphase. Von den Phasendokumenten zu unterscheiden sind die Stufenentscheidungen. Dieses sind durch den CPM vor-
10
geschriebene Entscheidungen innerhalb einer Phase. Der CPM unterscheidet: Die Systemfhigkeitsforderung (SFF) in der Analysephase. Sie stellt fest und dokumentiert eine zu schlieende Fhigkeitslcke. Die SFF darf keine konkrete technische Lsung vorschreiben und muss Innovationen zulassen. Die Genehmigung zur Nutzung (GeNu) in der Einfhrungsphase. Sie kann bei der Beschaffung unvernderter, verfgbarer 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 herbeizufhren. Diese knnen das Projekt in vorangegangene Phasen zurckverweisen oder aber das Projekt als Ganzes abbrechen. Der wesentliche Zusammenhang zwischen den zu durchlaufenden Phasen sowie die zu erstellenden Phasendokumente und Stufenentscheidungen in Abhngigkeit von der materiellen Lsung (neue Produkte, verfgbare Produkte oder Dienstleistungen) zum Schlieen von Fhigkeitslcken und dem Risiko zur Realisierung der Lsung sind in der nachfolgenden Abbildung dargestellt.
Bedarfsermittlung
Bedarfsdeckung
Nutzung 1 2 3
3 Analysephase
Projektierungsphase
1 2 3 Einfhrungsphase
Nutzungsphase
1 2 3
1 2 3 AF AF / ReG 2 3
1 2
1 2 3
ReG
ASB Phasendokumente
SFF
GeNu Stufenentscheidungen
Phasen, Phasendokumente und Stufenentscheidungen: 1 bei Realisierung neuer Produkte 2 bei beherrschbarem Realisierungsrisiko und bei Dienstleistungen 3 bei Beschaffung unvernderter verfgbarer Produkte
Abbildung 3.2-1: Phasen, Phasendokumente und Stufenentscheidungen im CPM
11
Lsungsmglichkeiten zum Schlieen von Fhigkeitslcken sind aber nicht nur in der Planungskategorie Rstung (materielle Lsung) zu untersuchen, sondern auch in den Planungskategorien: Organisation, Personal, Betrieb und Infrastruktur. Manahmen der Bedarfsermittlung und Bedarfsdeckung entsprechend des CPM werden erforderlich, wenn eine materielle Lsung zur Schlieung der Fhigkeitslcke angestrebt wird, die Lsung also der Planungskategorie Rstung zuzuordnen ist. Im CPM werden des Weiteren bestimmten Dienstposteninhabern und Managementtrgern spezifische Verantwortlichkeiten und Zustndigkeiten sowie Mitwirkungs-, Beteiligungs- und Vertretungsrechte im Rahmen des Verfahrensablaufs zugewiesen. Darunter zhlen der Generalinspekteur (GenInsp), der Hauptabteilungsleiter Rstung (HAL R), die Inspekteure (Insp), der Abteilungsleiter Wehrverwaltung (AL WV), der IT-Direktor, der Abteilungsleiter Haushalt (AL H), die Projektleiter (PL), die Bevollmchtigten Vertreter des Materialverantwortlichen (BV MatV), die Nutzungsleiter (NL) und die Bevollmchtigten Vertreter des Bedarfsdeckers (BV BD). Arbeiten knnen auch an nachgeordnete Bereiche delegiert werden, um entsprechende Zu- und Mitarbeiten zu leisten. Auch wird an verschiedenen Stellen des CPM auf die Beitrge der gewerblichen Wirtschaft im Rahmen der Bedarfsermittlung und Bedarfsdeckung ausdrcklich hingewiesen.
Mgliche Lsungswege zum Schlieen der Fhigkeitslcken auf Grundlage der SFF sind: Verbesserung eingefhrter Produkte, Einfhrung von verfgbaren Produkten, Realisierung neuer Produkte oder Inanspruchnahme von Dienstleistungen. Es ist der Lsungsweg auszuwhlen, der unter funktionalen, 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 ausgewhlte Lsungsweg wird am Ende der Analysephase mit dem Phasendokument AF festgelegt. Bei beherrschbarem Realisierungsrisiko und bei Dienstleistungen wird zeitgleich mit der AF auch die ReG in dem Phasendokument AF/ReG erteilt. Sollen verfgbare Produkte unverndert beschafft werden, dann schliet die AF/ReG auch die Stufenentscheidung GeNu mit ein. Der GenInsp trgt die Verantwortung fr die Fhigkeitsanalyse, die Schwerpunktsetzung, die Weiterentwicklung der Bundeswehr, die daraus abgeleitete Bedarfsermittlung sowie fr die Einsatzfhigkeit der Streitkrfte. Hierbei nutzt er die Integrierte Arbeitsgruppen Fhigkeitsanalyse (IAGFA). Diese sind im BMVg angesiedelt und setzen sich zusammen aus den Bevollmchtigten Vertretern (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 stndigen Abgleich vorhandener mit erforderlichen Fhigkeiten 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 Prfen der Erfllung der Leistung unter Leistungs-, Zeit- und Kostengesichtpunkten sowie, soweit nicht delegiert, das Prfen sonstiger Phasendokumente, Stufen- und Zwischenentscheidungen und das Herbeifhren der Unterzeichnung.
Die Analysephase
In der Analysephase werden auf Grundlage konzeptioneller Vorgaben sowie Erfahrungen aus Einsatz und Betrieb Fhigkeitslcken festgestellt und Lsungsmglichkeiten in den Planungskategorien Organisation, Personal, Rstung, Betrieb und Infrastruktur untersucht. Ist die Fhigkeitslcke durch Umsetzen einer materiellen Lsung (Bereitstellung von Produkten oder Dienstleistungen) in der Planungskategorie Rstung zu schlieen, dann ist sie in der SFF zu beschreiben und der Lsungsweg festzulegen. Die Umsetzung von Lsungsmglichkeiten in den anderen Planungskategorien ist nach den Regeln der Geschftsordnung BMVg (GO-BMVg) zu veranlassen.
12
Projektierungsphase
In Abhngigkeit vom Realisierungsrisiko bei der Umsetzung des festgelegten Lsungsweges und grundstzlich bei neuen Produkten folgt der Analysephase die Projektierungsphase. Sie entfllt, wenn das Realisierungsrisiko oder der Aufwand fr die Vorbereitung der Realisierung einen unmittelbaren Eintritt in die Einfhrungsphase zulsst, oder wenn auf andere Weise das Realisierungsrisiko beherrscht werden kann, z.B. mit einem schrittweisen Vorgehen durch die Einfhrung verfgbarer 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 Erfllung der funktionalen Forderung herstellbar sind. Die Leistungsfhigkeit der vorgeschlagenen Lsungen 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 werden. Dieses Lastenheft ist die Grundlage fr die durch die gewerbliche Wirtschaft vorzuschlagenden Lsungen und enthlt auch Kriterien zur Beurteilung der Herstellbarkeit und Leistungsfhigkeit des herzustellenden Produktes. Verantwortlich fr die Projektrealisierung im vorgesehenen Leistungs-, Zeit- und Kostenrahmen sind in der Projektierungs- und Einfhrungsphase die Projektleiter (PL).
zeitgerecht zur Verfgung 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 militrischen Erfordernissen im Systemverbund. Sie wird durch Leistungsnachweise des Auftragnehmers, Einsatzprfung und die Ermittlung weiterer Betriebsparameter und Funktionsgrenzen festgestellt. Der vom Auftragnehmer zu erbringende und fr die Abnahme eines Produktes erforderliche Leistungsnachweis umfasst den Nachweis der Erfllung der vertragskonformen Leistung einschlielich der Erfllung rechtlicher Auflagen und der technischen Sicherheit fr den Betrieb. Amtseitig erfolgt ergnzend zum Leistungsnachweis durch den Bedarfsdecker, Materialverantwortlichen und Nutzer die berprfung der Eignung des Produktes fr den vorgesehenen Verwendungszweck unter einsatznahen Bedingungen (Einsatzprfung). Die Einsatzprfung wird, insbesondere bzgl. der einsatzwichtigen Funktionen, grundstzlich im Rahmen der integrierten Nachweisfhrung, unter Bercksichtigung der Projektelemente3 und unter einsatznahen Bedingungen durchgefhrt. Integrierte Nachweisfhrung bedeutet hierbei die rtliche, zeitliche oder inhaltliche Zusammenlegung von Leistungsnachweis des Auftragnehmers, Einsatzprfung und Betriebstests oder gemeinsame Durchfhrung entsprechender Prfungen/Tests zur Feststellung der Eignung eines Produktes. Erkenntnisse aus der Einsatzprfung sind in den laufenden Fertigungsprozess einzubringen und bei der Beauftragung weiterer Lieferungen zu bercksichtigen. Produkte, die bereits in Nutzung sind, mssen ggf. entsprechend nachgerstet werden. Ergibt sich aus der Einsatzprfung Anpassungsbedarf mit finanziellen und zeitlichen Auswirkungen auf die Realisierung des Produktes oder ist die Eignung des Produktes fraglich, so ist eine Zwischenentscheidung, in schwerwiegenden Fllen eine Entscheidung ber den Projektabbruch, herbeizufhren. Sofern
Einfhrungsphase
Die Einfhrungsphase umfasst smtliche Manahmen zur Herstellung neuer Produkte sowie zur Beschaffung verfgbarer oder zur Verbesserung eingefhrter Produkte und Dienstleistungen. Ziel dieser Phase ist es, geeignete Produkte oder Dienstleistungen dem Nutzer bedarfs- und
Projektelement sind die Bearbeitungsbereiche eines Projekts und umfassen: Technische und wirtschaftliche An-teile, Fhrung/Einsatz, Organisation, Personal/Ausbildung, Logistik, Infrastrukturmanahmen, Arbeitssicherheit, IT-Sicherheit, militrische Sicherheit, Verkehrssicherheit, Ergonomie, Geoinformationswesen der Bw sowie Umweltschutz.
13
vorhandene Erkenntnisse ber die Verwendungsfhigkeit verfgbarer Produkte fr die Beurteilung ausreichen, sind fr diese keine eigenen Prfungen durchzufhren. Im Rahmen der Einsatzprfung werden auch weitere Betriebsparameter und Funktionsgrenzen ermittelt, die auf die effiziente und wirtschaftliche Nutzung des Produkts zielen. Auf Grundlage der Ergebnisse der integrierten Nachweisfhrung wird die Stufenentscheidung GeNu getroffen, in der festgestellt wird, dass die Leistungsfhigkeit entsprechend den Vorgaben der AF und ReG bzw. AF/ReG gegeben ist, die Eignung fr den vorgesehenen Verwendungszweck gegeben ist, die sichere Inbetriebnahme unter Bercksichtigung der geltenden rechtlichen Auflagen erfolgen kann, die Einsatzreife hergestellt ist und die Bereitschaft des Nutzers zur bernahme besteht. Die GeNu ist Voraussetzung fr die Beauftragung weiterer Lose und ggf. nachfolgender Realisierungsschritte sowie fr die bergabe bzw. bernahme in die Nutzung. Mit bernahme geht das Produkt in den Verantwortungsbereich des Nutzers ber. Die Verantwortung des PL bis zum Abschluss der Einfhrungsphase, insbesondere fr den Abschluss aller Manahmen zur Herstellung der Einsatzreife, bleibt hiervon unberhrt. Sofern die erforderlichen Voraussetzungen fr die Nutzung oder Teilnutzung von Produkten oder Dienstleistungen erfllt sind, kann die Stufenentscheidung GeNu whrend der Einfhrungsphase herbeigefhrt werden und die Produkte oder Dienstleistungen an den Nutzer bergeben werden. Die Einfhrungsphase endet nach Abschluss smtlicher Realisierungsmanahmen mit dem ASB. Dieses Phasendokument wird vom Leiter des zustndigen Amtes des Bedarfsdeckers und dem Leiter des zustndigen Kdo/ Amtes des Materialverantwortlichen unterzeichnet und schlussgezeichnet vom PL der IAGFA zur Kenntnis vorgelegt. Mit Herausgabe des ASB endet die Realisierungsverantwortung des PL.
Nutzungsphase
Die Nutzungsphase beginnt mit der bernahme des ersten Stcks und endet mit der Aussonderung des letzten Stcks. Da einerseits die Stufenentscheidung GeNu schon whrend der Einfhrungsphase herbeigefhrt werden kann, bei der Beschaffung unvernderter verfgbarer Produkte schon nach der Analysephase als Bestandteil des Phasendokuments AR/ReG, und die Produkte oder Dienstleistungen bereits dann an den Nutzer bergeben werden knnen, aber andererseits die Einfhrungsphase erst nach Abschluss smtlicher Realisierungsmanahmen mit dem ASB endet, knnen sich Einfhrungs- und Nutzungsphase zeitlich berlappen. Die Manahmen in der Nutzungsphase dienen der Erhaltung der Einsatzreife und dem sicheren Betrieb unter einsatzorientierten Bedingungen bis zur Aussonderung. Insbesondere nachfolgende Manahmen fallen in der Nutzung an: Erfassen und Auswerten von Erkenntnissen aus bungen und Einstzen; Erfassen und Auswerten von Betriebsdaten und Strungsmeldungen; bedarfsgerechtes Anpassen/Festlegen von Vorgaben fr die Ersatzteil-Bewirtschaftung sowie fr Instandhaltung und Fertigung auf der Grundlage von Klarstandsfestlegungen; Durchfhren von Produkterhaltungsmanahmen; Veranlassen von Nachbeschaffungen, Ersatzbeschaffungen und Ergnzungsbeschaffungen. Whrend der Nutzungsphase knnen Produktnderungen, Ersatzbeschaffungen, Produktverbesserungen, Verlngerung des Nutzungszeitraumes sowie Betreuungsleistungen der gewerblichen Wirtschaft oder des Rstungsbereichs erforderlich werden. nderungen eingefhrter Produkte und Ersatzbeschaffungen sind nur zulssig zum Erhalt oder zur Wiederherstellung der Einsatzreife sowie zur Rationalisierung im Betrieb. Die Problemstellungen, die einer vorgesehenen nderung zugrunde liegen sowie die erforderlichen
14
Manahmen sind in einem Lastenheft funktional zu beschreiben. Werden fr die Vorbereitung von nderungsmanahmen Mittel fr Entwicklungstechnische Betreuung (ETB) bentigt, so hat der NL diesen Bedarf einschlielich der technisch/wirtschaftlichen Bewertung des BV BD mit der nderungsforderung (F) zu dokumentieren. Die F ist Voraussetzung fr die Bereitstellung von Haushaltsmitteln zur Untersuchung mglicher Alternativen nach Nutzen, Kosten und Risiken. Die F enthlt das Lastenheft als Bestandteil. Eine F ist nicht erforderlich, wenn die vorzunehmende nderung eindeutig ist und mit beherrschter Technologie unkritisch durchfhrbar ist. Dann kann mit der Erstellung der nderungsgenehmigung (G) unmittelbar die Realisierung der nderungsmanahme eingeleitet werden. Ist die nderungsmanahme nicht eindeutig, dann sind durch den BV BD auf Grundlage des Lastenheftes Lsungsvorschlge der gewerblichen Wirtschaft und ggf. des Rstungsbereichs einzuholen und zu bewerten. Die potentiellen Auftragnehmer haben die Realisierbarkeit ihrer Lsungsvorschlge und die zu erwartende Erfllung der funktionalen Forderungen darzustellen. Die Auswahl der technischen Lsung ist gesttzt auf einer umfassenden Risikoanalyse und Wirtschaftlichkeitsuntersuchung zu treffen und mit der G zu dokumentieren. Sofern vorliegende Erkenntnisse es erlauben, kann die Genehmigung zur Nutzung zusammen mit der nderungsgenehmigung erteilt werden (G mit GeNu). Ersatzbeschaffungen werden vom NL ber den BV BD unter Beachtung der Grundstze der Wirtschaftlichkeit veranlasst. Sofern kein geeignetes Produkt am Markt verfgbar ist, bringt der NL eine Initiative zur Schlieung der entstehenden Lcke in die zustndige IAGFA ein. Initiativen zur Produktverbesserung bzw. zur Verlngerung des Nutzungszeitraumes werden vom NL in die zustndige IAGFA eingebracht. Vorgehensweise und Ver-
antwortlichkeiten richten sich nach den Bestimmungen zur Bedarfsermittlung und Bedarfsdeckung (s.o.). Betreuungsleistungen der gewerblichen Wirtschaft oder des Rstungsbereiches sind entweder Leistungen im Rahmen der Technisch-Logistischen Betreuung (TLB) oder der Entwicklungstechnischen Betreuung (ETB). Leistungen der TLB umfassen die Erfassung, die Auswertung und die Bereitstellung produktbezogener Informationen im Rahmen der Nutzungssteuerung. Das Erfassen, Planen und berwachen von TLB-Leistungen liegt in der Zustndigkeit des NL und wird aus Materialerhaltungstiteln finanziert. Leistungen der ETB sind als Entscheidungsgrundlage fr die nderung von Produkten erforderlich. Sie werden nach Zustimmung durch den Materialverantwortlichen oder auf dessen Forderung durch die gewerbliche Wirtschaft ggf. durch den Rstungsbereich erbracht. Sie umfassen den eine nderung vorbereitenden technischen Aufwand und schlieen den Aufwand fr Software und Dokumentation mit ein. Die Vergabe von Betreuungsleistungen an die gewerbliche Wirtschaft erfolgt grundstzlich 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 vollstndiger Ausplanung des gesamten Projektes) einzeln, zeitlich versetzt oder auch parallel zu anderen Teilen realisiert werden. Die einzelnen Teile mssen dabei fr den vorgesehenen Verwendungszweck geeignet und fr sich einsatzreif sein. Die Aufteilung des Projekts kann erfolgen hinsichtlich der Leistung, der Bedarfszahlen oder auch bzgl. ausgewhlter Nutzer. Schrittweises Vorgehen ist sinnvoll um das Realisierungsrisiko von Projekten zu reduzieren oder (Teil-)Fhigkeiten
15
frhzeitig dem Nutzer bereitzustellen. Es kann in jeder Phase ausgeplant und mit einem Phasendokument bzw. einer Zwischenentscheidung entschieden werden. Die einzelnen Projektanteile sind dabei wie eigenstndige Projekte zu behandeln und untereinander zu koordinieren.
Forderungen sowie die Nutzung von Mglichkeiten zur dauerhaften Fremdvergabe oder zur Kooperation; die vorrangige Verwendung von verfgbaren Produkten und von Dienstleistungen; den grundstzlichen Verzicht auf die Anwendung Bwinterner Bauvorschriften, Normen und Prfanweisungen innerhalb des rechtlich zulssigen Rahmens; das ganzheitliche Planen von Aktivitten unter Bercksichtigung von Systemzusammenhngen sowie die Durchfhrung von Wirtschaftlichkeitsuntersuchungen mit dem Ziel der Minimierung der Lebenswegkosten (LCC: Life Cycle Costs).
3.2.4 Grundstze der Wirtschaftlichkeit

Ein wesentlicher Aspekt des CPM ist seine Ausrichtung an den Grundstzen der Wirtschaftlichkeit. Die Grundstze der Wirtschaftlichkeit bestimmen den gesamten Verfahrensablauf. Ihre Beachtung ist insbesondere sicherzustellen durch: das Straffen von Entscheidungsgngen und Verfahrensablufen; das Reduzieren des Verwaltungsaufwandes auf das unabdingbar Notwendige; die vertragliche Vereinbarung von Regelungen fr ein wirksames amtseitiges Controlling und die Mitwirkung des Auftraggebers; das abschlieende Formulieren von unabdingbaren Forderungen, deren Erfllung zum Zeitpunkt ihrer Billigung gesichert im vorgegebenen Leistungs-, Zeitund Kostenrahmen realisierbar sein mssen; die Vermeidung von nderungen der Forderungen whrend 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 verfgt, um die geforderte Leistung im vorgesehenen Zeit- und Kostenrahmen zu erbringen; das Absttzen auf die gewerbliche Wirtschaft im rechtlich zulssigen Rahmen durch frhzeitiges Einbeziehen ihrer Kenntnisse und Fertigkeiten, ihr eigenverantwortliches Umsetzen von funktionalen
3.2.5 Die Mitwirkung der gewerblichen Wirtschaft im Rahmen des CPM

Der CPM weist der gewerblichen Wirtschaft auf Grund ihrer hohen Innovationsgeschwindigkeit eine technologische Schrittmacherfunktion zu. Eine enge Zusammenarbeit zwischen der Bundeswehr und der gewerblichen Wirtschaft wird daher als unerlsslich fr die Erhaltung moderner und leistungsfhiger Streitkrfte angesehen. Damit ein frhzeitiges Absttzen auf die gewerbliche Wirtschaft gewhrleist ist, wird sie unter Bercksichtigung militrischer Sicherheitsaspekte im erforderlichen Umfang und im rechtlich zulssigen Rahmen vom Hauptabteilungsleiter Rstung (HAL R), IT-Direktor und vom Abteilungsleiter Wehrverwaltung (AL WV), als Trger der ministeriellen Verantwortung fr ihren jeweiligen Aufgabenbereich, ber festgestellte Fhigkeitslcken 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 Neutralittsgebot des Auftraggebers zu entsprechen.
16
Des Weiteren erfolgt die Untersttzung der Bundeswehr durch die gewerbliche Wirtschaft im Rahmen von Entwicklungs- und Betreuungsleistungen. Entwicklungsleistungen knnen whrend des gesamten Verfahrensablaufs erforderlich sein und umfassen Forschungen, Studien/Analysen, Neuentwicklungen, Herstellung von Demonstratoren/Mustern und deren Untersuchungen, Nachweis der Herstellbarkeit sowie Serien-/Produktreifmachung. Whrend der Nutzungsphase knnen Entwicklungsleistungen zum Erhalt der Einsatzreife im Rahmen der nderung eingefhrter Produkte und Dienstleistungen notwendig werden. Betreuungsleistungen dienen dem Erhalt und der Sicherstellung der Einsatzreife von Produkten. Sie werden durch den Bevollmchtigten Vertreter Bedarfsdecker (BV BD) auf Grundlage der VOL grundstzlich im Wettbewerb vergeben. Sie umfassen TechnischLogistische Betreuung (TLB), Entwicklungstechnische Betreuung (ETB) und Produktverbesserung/Verlngerung des Nutzungszeitraums. Voraussetzung fr Vertragsabschlsse mit der gewerblichen Wirtschaft in der Realisierung und Nutzung ist die Sicherstellung, dass sie ber die erforderlichen Technologien, Kenntnisse und Fertigkeiten verfgt, um die geforderte Leistung im vorgesehenen Zeit- und Kostenrahmen zu erbringen.
Forderung/Realisierungsgenehmigung (AF/ReG) folgt. Nach Abnahme der Leistungen des Projektes folgt im CPM die Einfhrungsphase. Das V-Modell stellt ein Vorgehensmodell zum Planen und Durchfhren von Projekten insbesondere im Bereich von IT-Systemen dar. Es regelt die Projektdefinition und Projektausschreibung, die Systemerstellung mit Untersttzungssystemen und plant die Logistik, den Betrieb und die Auerbetriebnahme des Systems, definiert die damit verbundenen Aktivitten (Ttigkeiten), die Verantwortlichkeiten (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 Aktivittsstrnge, mit Unterauftragnehmern sogar drei Strnge, vor. Einige Produkte wechseln zwischen diesen Strngen 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 Projektmanagement, Konfigurationsmanagement, Qualittssicherung, Problem- und nderungsmanagement und Systemerstellung. Jedes dieser Themen beinhaltet eine Reihe von Vorgehensbausteinen, die in der folgenden Abbildung dargestellt sind:
3.3 V-Modell
Im Prozess des Customer Product Managements regelt das V-Modell die projektspezifischen Inhalte der Projektierungsphase, die der abschlieenden funktionalen
17
Weiterentwicklung und Migration von Altsystemen Einfhrung und Pflege eines organisationsspezifischen Vorgenhensmodells Kaufmnnisches Projektmanagement Messung und Analyse
Benutzbarkeit und Ergonomie
Systemsicherheit
Logistikkonzeption
SW-Entwicklung HW-Entwicklung Multiprojektmanagement Vertragsschluss (AG)
Vertragsschluss (AN)
Evaluierung von Fertigprodukten
Lieferung und Abnahme (AN)
Systemerstellung
Anforderungsfestlegung
Lieferung und Abnahme (AG)
Projektmanagement
Konfigurationsmanagement
Qualittssicherung
Problem- und nderungsmanagement
Abbildung 3.3-2: Vorgehensbausteinkarte
Jeder Vorgehensbaustein hat ein Produkt als Resultat. Aktivitten und Rollen mit Verantwortlichkeiten und Zuarbeiten sind Teile des jeweiligen Vorgehensbausteins.
Die Produkte des V-Modells XT sind den Vorgehensbausteinen zugeordnet. Vorgehensbausteine knnen wiederum von anderen Vorgehensbausteinen abhngen. Die Vorgehensbausteine sind folgendermaen aufgebaut:
In der folgenden Abbildung ist die Einbettung des Vorgehensbaustein in das Gesamtmodell gezeigt.
beinhaltet untergeordnete Aktivitt 1 Aktivitt
beinhaltet untergeordnete Produkte 1 Produkt
1 bearbeitet
verantwortlich
Rolle
hat Abhngigikeiten zu anderen
Abbildung 3.3-3: Aufbau eines Vorgehensbausteins
18
Produktgruppe Produkt
Aktivittsgruppe Aktivitt
Rolle
verantwortlich
Produkt
erzeugt
Aktivitt
mitwirkend Rolle Rolle Thema Thema Thema Teilaktivitt bearbeiten
Teilaktivitt
Abbildung 3.3-4: Vorgehensbausteinbergreifende Strukturierung
Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor. Die detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbei-
Basierend auf den Vorgehensbausteinen definiert eine Projektdurchfhrungsstrategie die Reihenfolge von sog. Entscheidungspunkten (engl. Quality Gates). Um diese Entscheidungspunkte zu erreichen, muss eine definierte Menge von Produkten in definierten Zustnden vorliegen.
tung und Fertigstellung von Produkten durchgefhrt. Fr jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person. Die Produktqualitt ist berprfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der
Projektdurchfhrungsstrategie
1...* 1...* legt Reinfolge fest
Entscheidungspunkt
* bentigt
1...*
I E
Produkt
[im Zustand fertig gestellt]
Abbildung 3.3-5: Projektdurchfhrungsstrategien und Entscheidungspunkte
Abhngigkeiten zu anderen Produkten. Die Vorgehensbausteine sind die modularen Einheiten fr
Im Projektplan definiert ein Entscheidungspunkt zu einem festgelegten Zeitpunkt eine Fortschrittsentscheidung (GO/NOGO). Mit diesem Aufbau ist die zentrale Philosophie des V-Modells XT eine ziel- und ergebnisorientierte Vorgehensweise. Produkte stehen im Mittelpunkt, sie sind die Projektergebnisse. Projektdurchfhrungsstrategien und Entscheidungspunkte geben die Reihenfolge der
das Tailoring. Das Tailoring wird im V-Modell XT durch das Werkzeug Projektassistent untersttzt und weitestgehend automatisiert. Zu diesem Zweck sind einige typische Projektprofile definiert, aus denen ausgewhlt werden kann. Bei der Erstellung einer Architektur muss der ausgewhlte Projekttyp, die in den folgenden Kapiteln dargestellten Aktivitten und Produkte zur Erstellung einer
19
Architektur beinhalten. Dazu kommen alle Varianten der Systementwicklungsprojekte in Frage aber nicht der Typ Einfhrung und Pflege eines organisationsspezifischen Vorgehensmodells. Die Projektmerkmale unterscheiden wiederum den Projektgegenstand und die Projektrolle (des Projektes). Mgliche Projektgegenstnde fr eine Architekturerstellung 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 auszuwhlenden Einheiten zu einem System), Aber eher nicht: Einfhrung und Pflege eines organisationsspezifischen Vorgehensmodells. Das Projektmerkmal agiles Projektvorgehen ist ein zustzlich whlbares Merkmal. Im V-Modell XT bedeutet es nicht, dass das Projektvorgehen nach agilen Grundstzen kleine zeitlich sehr hufige Iterationen durchgefhrt wird, sondern dass frhzeitig ein Prototyp zur Risikobegrenzung und Evaluierung der Lsung oder von (Technologie-) Anstzen erstellt wird. Bei Architekturentwicklungen mit hohem Anteil von neuen Technologien oder Architekturen, die so noch nie durchgefhrt wurden, empfiehlt sich dieses Vorgehen.
3.3.2 Aktivitten zur Erstellung einer Architektur

Das V-Modell XT ist ein produktzentriertes Vorgehensmodell. Nichtsdestotrotz sind Aktivitten definiert, die das Vorgehen im Projekt beschreiben. Neben den durchgngigen Aktivitten des Auftragnehmers mit Planung und Steuerung (Projektleitung), Angebots- und Vertragswesen, Berichtswesen, Konfigurations- und nderungsmanagement und Prfung (Qualittssicherung) sind im folgenden die Aktivitten der Entwicklung aufgefhrt, die fr die Erstellung einer Architektur durchgefhrt werden mssen. Die wesentlichen Phasen fr die Erstellung einer Architektur sind: System spezifizieren System entwerfen Feinentwurf Bevor eine Architektur entwickelt und ausgelegt werden kann, mssen die Anforderungen des Auftraggebers, das Altsystem bzw. die wiederzuverwendenden Komponenten analysiert und die mglichen neu zu verwendenden Komponenten als Rahmenbedingung einer Architektur betrachtet werden. In der folgenden Tabelle sind die entsprechenden Aktivitten aufgefhrt:
Aktivitt
Anwenderaufgaben analysieren Gefhrdungs- und Systemsicherheitsanalyse durchfhren und bewerten Marktsichtung fr Fertigprodukte (AN) durchfhren Make-or-Buy-Entscheidung durchfhren
Ergebnis
Anwenderaufgabenanalyse Gefhrdungs- und Systemsicherheitsanalyse
Altsystemanalyse erstellen Altsystemanalyse Marktsichtung fr Fertigprodukte (AN) Make-or-Buy-Entscheidung
Tabelle 3.3-1: Aufgaben und Produkte der Analysephase
20
Nach Analyse der Aufgabe ist ein erstes grobes Lsungskonzept zu erstellen. Dazu wird auf Basis des Lastenheftes des Auftraggebers ein Pflichtenheft erstellt, dass die Interpretation des Auftragnehmers des Lastenheftes in Form einer Anforderungsanalyse enthlt. Wie weit die in der folgenden Tabelle aufgefhrten Aktivitten durchgefhrt werden, hngt von dem Umfang des Auftrags zur Entwicklung einer Architektur ab. Ist eine Systemarchitektur zu erstellen, so sind nur die Produkte Gesamtspezifikation und Systemspezifikation zu erstellen. Ist auch eine Software- und Hardwarearchitektur verlangt, so sind auch die weiteren Produkte zu erstellen.
Aktivitt
Ergebnis
Untersttzungs-Systemar- Untersttzungs-Systemarchitektur erstellen chitektur Styleguide fr die Mensch- Mensch-MaschineMaschine-Schnittstelle Schnittstelle (Styleguide) erstellen HW-Architektur erstellen SW-Architektur erstellen Datenbankentwurf erstellen4 HW-Architektur SW-Architektur Datenbankentwurf
Tabelle 3.3-3: Aufgaben und Produkte des Systementwurfs
Die weiteren Aktivitten der Entwicklung gehren nicht
Aktivitt
Gesamtsystemspezifikation (Pflichtenheft) erstellen Systemspezifikation erstellen Externe-Einheit-Spezifikation erstellen Externes-HW-Modul-Spezifikation erstellen SW-Spezifikation erstellen
Ergebnis
Gesamtspezifikation (Plichtenheft) Systemspezifikation Externe-Einheit-Spezifikation Externes-HW-ModulSpezifikation SW-Spezifikation
mehr zu einer Architekturentwicklung, sondern sind Teil der Realisierung, Integration und Tests sowie der Inbetriebnahme und Logistik. In der vorlufigen Rahmenregelung zur Nutzung der Methode Architektur in der Bundeswehr /8/, erstellt durch das IT-AmtBw A1, wird zwischen aufgabenorientierten und fhigkeitsorientierten Architekturen unterschieden. Auf solche Architekturanstze geht das V-Modell XT nicht ein und besitzt auch keine entsprechenden Profile. Diese mssen immer wieder projektspezifisch erarbeitet werden. Gleiches gilt fr methodische Anstze und Vorgehensweisen insbesondere mit Tooluntersttzung und Notationen, wie beispielsweise die UML /7/.
HW-Spezifikation erstellen HW-Spezifikation
Externes-SW-Modul-Spezi- Externes-SW-Modul-Spefikation erstellen zifikation

Tabelle 3.3-2: Aufgaben und Produkte der Systemspezifikation
Wie schon im vorherigen Abschnitt erwhnt, werden fr eine Systemarchitektur in dieser Phase nur die Produkte Systemarchitektur und Untersttzungs-Systemarchitektur erstellt und bei einer Software- und Hardwarearchitektur auch die folgenden Produkte.
3.3.3 V-Modell-Architekturdokumentation
Das V-Modell XT definiert neben der Realisierung der Lsung 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 Gesamtsystem, ber Teilsysteme, Segmente bis zu Software- und
Aktivitt
Systemarchitektur erstellen
Ergebnis
Systemarchitektur
Datenbankentwurf ist auf Systemebene nur bei klassischer Entwicklung oder Client Server Architekturen durch-zufhren. Bei einem Architekturansatz mit Kapselung wie die Service Orientierte Entwicklung (SOA), ist diese im Rahmen der SW-Architektur der SW-Einheiten durchzufhren.
21
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 fr das Gesamtsystem und jeweils auch fr die weiteren untergeordneten Systemteile wie Segmente erstellt. Fr 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 fr die Dokumentation von Architekturen als Standard fr die Darstellung der Sichten das Nato Architecture Framework (NAF) /6/, das im folgenden Kapitel 3.4 NATO Architecture Framework nher beschrieben ist, und fr technische und System Sichten die Unified Modelling Language (UML) /7/ durchgesetzt. Die folgende Tabelle zeigt eine empfohlene Zuordnung zwischen den wichtigsten V-Modell- XT-Architekturdokumenten und den Sichten der NAF in der Version 2:
NAFView
NAV-1 NAV-2 NOV-1 NOV-2 NOV-3 NOV-4 NOV-5
Titel (NAF)
GesamtSystemSystemsystemspezifikation architektur spezifikation

(Pflichtenheft)
Kap. 2.1 Kap. 2.2 Kap. 3.5, Kap. 4.1
Overview and Summary Information Integrated Dictionary High-Level Operational Concept Diagram Operational Node Connectivity Diagram
Operational Information Exchange Requirements Kap. 4.2, Kap. 7.1 (IER) Matrix Organisation Relationships Chart Operational Activity Models Operational Rules Model Operational State Transition Operational Event-Trace Kap. 3.1 Kap. 3.2 Kap. 3.4.1 Kap. 3.4.2 Kap. 3.4.3 Kap. 3.3 Kap. 6.2.1 Kap. 3.1 Kap. 2.1 Kap. 2.1 Kap. 2.1 Kap. 5.2 Kap. 4.1 Kap. 6.2.2 Kap. 2.2 Kap. 3.2 Kap. 7.1 Kap. 5.1 Kap. 4.2 Kap. 2.x Kap. 2.x Kap. 2.x Kap. 5.1 Kap. 5.2 x Kap. 7.1 Kap. 5.3 Kap. 7.2
NOV-6 NSV-1a NSV-1b NSV-1c NSV-1d NSV-2 NSV-3 NSV-4 NSV-5 NSV-6 NSV-7
Concept Data Model Systems Interface Description, Internodal Perspective, Edge-to-Node Systems Interface Description, Internodal Perspective, System-to-System Systems Interface Description, Intranodal Perspective Systems Interface Description, Intrasystem Perspective Systems Communications Description System-to-System Matrix (S2 Matrix) Systems Functionality Description Operational Activity to System Function Traceability Matrix Systems Information Exchange Matrix System Performance Parameters Matrix
22
NAFView
NSV-8 NSV-9
Titel (NAF)
GesamtSystemSystemsystemspezifikation architektur spezifikation

(Pflichtenheft)
Kap. 7.3 Kap. 7.4 Kap. 4.3 Kap. 4.3 Kap. 4.3 Kap. 6.1 Kap. 6.1 Kap. 2.x Kap. 2.x Kap. 3.2 Kap. 3.3 Kap. 3.4 zwischen den beteiligten Systemen der Partnernationen ein entscheidender Erfolgsfaktor. Da eine Vielzahl von Organisationen (militrische Einheiten, Industrie, Forschungsinstitute, ...) 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 zwangslufig ein hochkomplexes System of Systems ergibt, ist es zwingend erforderlich, Architekturen und untersttzende Werkzeuge zu nutzen, um einerseits zielfhrende Diskussionen zwischen den einzelnen Interessenvertretern zu fhren und um andererseits sicherzustellen, dass kohrente, konsistente und technisch sinnvolle Entscheidungen getroffen werden. Um bei der Entwicklung der Architekturen Verwirrungen zu verhindern, wurde von der NATO das NATO Architecture Framework (NAF) entwickelt, deren Verwendung eine verbindliche Vorgabe der technischen Architektur der Bundeswehr (TABw) ist und somit die Basis fr alle zuknftigen Architekturentwicklungen bilden muss. Das NAF bildet NATO-weit abgestimmte Richtlinien fr die Entwicklung und Verwendung von Architekturen innerhalb der NATO sowie die Standardisierung von Architekturmodellen und Produkten ab. Damit soll erreicht werden, dass durch die unterschiedlichen Sichtweisen und Modellierungsschritte die Komplexitt besser beherrscht wird. Im Gegensatz zu den Vorgngerversionen bercksichtigt die Version 3.0 des NAF die Umorientierung in
System Evolution Description System Technology Forecast Systems Rules Model Systems State Transition Description Systems Event-Trace Description
NSV-10 NTV-1 NTV-2 NTV-3 NTV-4 NTV-5
Physical Data Model System Standards Profile Standards Technology Forecast Technical Configuration Software Configuration Product Selection Report
Tabelle 3.3-4: Zuordnung der NAF Sichten zur V-Modell XT Dokumentation
3.4 NATO Architecture Framework 3.4.1 berblick

Hervorgerufen durch die steigende Komplexitt von Informations- und Kommunikationssystemen und die Vielfalt der Nutzerperspektiven und den daraus resultierenden vielfltigen Forderungen entstand die Notwendigkeit strukturierterer Anstze, um die Komplexitt zu visualisieren und somit besser kommunizieren zu knnen sowie die Anforderungen strukturiert dokumentieren zu knnen. Als Folge davon entwickelten sich seit dem Beginn der 90er Jahre Modellierungsverfahren fr Systeme, um deren Architekturen und Realisierungsanstze vergleichen und bewerten zu knnen. Rahmenwerke als Grundlage fr 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 Interoperabilitt
23
Richtung eines diensteorientierten und fhigkeitsbasierten Paradigmas. Derzeit wird in der TABw die Version 2 des NAF (NAFv2) genannt, von der NATO ist aber bereits die Version 3 (NAFv3) verffentlicht, die die Sichten und Teilsichten der Version 2 um weitere Elemente ergnzt. Dem Unterschied zwischen diesen beiden Versionen ist in der NAFv3 ein eigener Anhang gewidmet (Annex C).5
Bezogen auf den Verteidigungsbereich bildeten die Architekturrahmenwerke des US-Department of Defense (DoD) C4ISR / DoD Architecture Framework (DoDAF) die Ausgangsbasis fr die Erarbeitung von weiteren militrisch orientierten Architecture Frameworks. Aus der Endversion des DoDAF, die seit 2003 vorliegt, entstand in Grobritannien bereits 2004 das MoDAF (Ministry of Defence Architectural Framework). Seit 2006 existiert das fr die NATO verbindliche Rahmenwerk NAF in der Version 2, dem in 2008 die Version 3 folgte.
3.4.2 NAF-Historie
In der nachfolgenden Abbildung 3.4-1 sind die wichtigsten Rahmenwerke in einem Zeit-Einsatz-Diagramm eingeordnet, um die zeitliche Abfolge bzw. die Ableitungen und das jeweilige Einsatzgebiet (militrisch, zivil) darzustellen.
Die Version 3, die die Umorientierung in Richtung eines diensteorientierten und fhigkeitsbasierten Paradigmas bercksichtigt, hat inzwischen auch Rckwirkungen auf DoDAF und MoDAF, die nun ihrerseits in neueren Versionen diensteorientierte und fhigkeitsbasierte Aspekte aufweisen (DoDAF 1.5 und MoDAF 1.1).
Zachman 1987 EAP 1992 1992 C4ISR 1996-7
TOGAF 1995-2005
TISAF 1997 Zeit
FEAF 1999 TEAF 2000
AGATE 2003-5
DODAF 2003
MODAF
SOSAF
OMG UPMD 2005
2004-6 NATO 2003-6
zivil
Interesse
militrisch
Abbildung 3.4-1: Historie von Architektur-Rahmenwerken
Quelle der gesamten NAF-Dokumentation: www.nhqc3s.nato.int
24
Die unterschiedlichen AFs, die in dieser Abbildung referenziert sind, werden in einem separaten Band (Annex A/B) der NAF behandelt.
Vertretern der Auftraggeberseite wie beispielsweise Konzeption Nutzern Betreibern Bedarfsdeckern Wartungspersonal ... sowie Vertretern der Auftragnehmerseite wie beispielsweise Projektmanagern, Analysten, Designern, Entwicklern, Integrationspersonal, Qualittspersonal Personal der Inbetriebnahme zusammensetzt. Diese Liste ist nur ein unvollstndiger Vorschlag, der die Heterogenitt der Gruppe der Stakeholder verdeutlichen soll. Wichtig ist, smtliche Stakeholder zu Beginn der Archi-
3.4.3 NAF Komponenten

Das NATO Architecture Framework besteht neben einer Executive Summary aus zehn weiteren Bnden: 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 knnen. Die Motivation fr dieses Kapitel liegt in der Zielsetzung der NAF begrndet, sich einerseits an den Zielen und Interessen der Nutzergruppen zu orientieren und andererseits ein Kommunikationsmedium bereitzustellen, so dass die Kommunikation zwischen allen Beteiligten auf Auftraggeberseite wie auf Auftragnehmerseite vereinfacht wird. Die Auftraggeberseite bentigt nachvollziehbare Darstellungen der auftragnehmerseitigen Entwicklungen, um die Erfllung der Forderungen verfolgen zu knnen. Andererseits ist fr die Auftragnehmerseite ein architektonischer Systemberblick fr die ordnungsgeme Abwicklung der Entwicklung ein entscheidender Faktor. Daraus ergibt sich eine generische Gruppe von Stakeholdern, die sich aus
tekturarbeiten zu identifizieren und festzulegen. Empfehlenswert ist die Einrichtung eines Architekturboards, das sich aus Vertretern der (wichtigsten) Stakeholder-Gruppierungen zusammensetzt. Da im NAF die Stakeholder zwar erwhnt sind, aber Aktivitten zur Anforderungserhebung, Anforderungsmodellierung, Anforderungsverfolgung und weiteren Nutzeraspekten fehlen, wird an dieser Stelle auf das Kapitel 4.1 in dem vorliegenden Dokument hinsichtlich der Anforderungsmodellierung & Stakeholder verwiesen, das genau diesen Aspekt nher beleuchtet.
3.4.5 NAF-Architektur-Konzepte und -Elemente

In diesem Abschnitt des NAF werden Architektur-Konzepte und -Elemente definiert, die dann in den Sichten und untergeordneten Sichtweisen verwendet werden knnen. NAF selbst schreibt zwar keine Methode zur
25
Erstellung der Sichten und Teilsichten vor, aber durch die Verwendung von festgelegten Elementen in den Sichten untersttzt das Framework bei der Erstellung der Sichten, um kohrente, konsistente und relevante Architekturprodukte zu generieren. Dieses Kapitel beschreibt die grundlegenden NNEC Architektur-Elemente und ihre Beziehungen untereinander.
operationellen Knoten, die Rollen und ihren Aktivitten 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 Systemknoten, der Rollen auf System, der Aktivitten auf Funktionen und der Informationen auf Daten. NATO Technical View: In dieser Sichtweise werden technische Produkte und Standards festgelegt.
3.4.6 NAF-Sichten
Als Werkzeugkasten definiert die NAF einen Satz von Sichten und korrespondierenden Teilsichten, mit angepassten Diagrammen und Spezifikationen zur Untersttzung der Stakeholder und Communities of Interest. An dieser Stelle werden nur die NAF-Sichten beschrieben, auch wenn, wie sich in dem Kapitel bezglich der Architekturentwicklung herausstellen wird, dieser Werkzeugkasten nicht ausreicht und zustzliche 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 Transformationsprozesses im Hinblick auf operationelle Konzepte, Fhigkeitsplanungen und Diensteorientierung Schritt halten kann. Dies bedeutet, dass die architekturellen Aktivitten, Methoden und Werkzeuge auf kurzfristige Anforderungen reagieren und mittelfristige Planungsprozesse untersttzen knnen, 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 Technical View, die bereits aus den Vorgngerversionen bzw. DoDAF/MoDAF bernommen worden sind. Darber hinaus werden in der Version 3 des NAF noch die Capability View, die Programm View und die Service View eingefhrt. NATO All View: Diese Sichtweise enthlt eine kurze einfhrende Beschreibung der Ziele des Entwicklungsvorhabens, sowie ein Projekt-Glossar. NATO Operational View: Diese Sichtweise beschreibt die Sicht der Nutzer des Systems in Bezug auf die
Im NAFv3 sind ber die NAFv2 Sichtweisen noch drei weitere Sichtweisen definiert worden: NATO Capability View: Diese Sichtweise beschreibt die strategische Sicht, um die Entwicklung der Fhigkeiten zu berwachen und die Ausrstung zu planen. NATO Programme View: Diese Sichtweise dokumentiert Programm-Abhngigkeiten, Zeitplanungen und Statusinformationen, um das ProgrammManagement zu informieren und die Beschaffung zu synchronisieren. NATO Service View: Diese Sichtweise dokumentiert die Dienste, ihre Funktionalitten, ihre Einschrnkungen und ihre Interoperabilitt. Durch diese in NAFv3 zustzlich eingefhrte Sichtweise erfolgt eine Entkopplung zwischen der operationellen Sichtweise und der Systemsicht, denn die operationellen Aktivitten werden nicht mehr direkt Systemfunktionen, sondern Diensten im Sinne einer Serviceorientierung zugeordnet. Dienste sind eine implementierungsunabhngige Reprsentation von Funktionen. Alle genannten Sichtweisen sind in eine Vielzahl von Teilsichten unterteilt, die der entsprechenden NAF-Dokumentation zu entnehmen sind.
3.4.7 Meta-Modell & Data Exchange Specification

NAFv3 definiert ein gemeinsames standardisiertes Architektur-Meta-Modell (NMM) und Austauschmechanismen
26
fr Architekturdaten, um den Austausch und die Nutzung von Architekturprodukten zu erleichtern. Basierend auf dem Meta-Modell und den Austauschmechanismen lsst sich eine unabhngige Architektur-Datenbasis erstellen, die der Schlssel fr eine effektive Entwicklung, Nutzung und Wiederverwendung von Architekturprodukten ist. Architekturprodukte, die auf einer konsequenten Anwendung von konsistenten Architekturmodellen basieren, knnen auf einfachste Weise miteinander verbunden werden, um eine integrierte und evolutionre Beschreibung der Entwicklungsfortschritte im Umfeld NetOpF/ NNEC zu erstellen. Die Wiederverwendung von existierenden Modellen, die evolutionr entstanden sind, knnen nachfolgende Entwicklungsaktivitten beschleunigen, um somit operationelle Fhigkeiten in krzeren Zyklen verfgbar zu machen.
3.4.9 Architekturentwicklung auf der Basis NAF

In dem vorausgegangenen Abschnitt ist bereits mehrfach angedeutet worden, dass das NAF einerseits Architekturbeschreibungen spezifiziert und auch Untersttzung hinsichtlich der Architektur-Elemente liefert, aber andererseits keinerlei Vorgaben in Bezug auf das Vorgehen bzw. die Reihenfolge der Erstellung der Architekturprodukte macht. In /1/ wird eine Bearbeitungsreihenfolge als Graph dargestellt, die in mehreren Entwicklungsprojekten erfolgreich erprobt worden ist. Da zwischen den einzelnen Architekturprodukten des NAF Abhngigkeiten bestehen, die sich in dem Graph widerspiegeln, ergibt sich implizit eine Bearbeitungsreihenfolge. Wie der Abschnitt 3.3 deutlich zum Ausdruck bringt, ist
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, kohrente, vollstndige und exakte Architekturprodukte Bereitstellung der Architekturprodukte fr autorisiertes Personal Entwicklung der Architekturprodukte gem Standard (NAF und NMM) Verfgbarkeit von Kontrollinstanzen, die im Zusammenhang mit der Entwicklung, der Nutzung und der Wartung von Architekturprodukten unerwnschte Ereignisse erkennen und korrigieren Verfgbarkeit von geeigneten Werkzeugen fr die Entwicklung, Nutzung und Wartung von Architekturprodukten
das V-Modell nach wie vor eine verbindliche Vorgabe fr die Systementwicklung im Bereich der Bundeswehr. Es wird daher empfohlen, das Architektur-Rahmenwerk mit dem Vorgehensmodell zu kombinieren bzw. zu integrieren, so dass Architekturentwicklungen gem V-Modell durchgefhrt werden, aber die Aktivitten und Produkte dem NAF entnommen sind. Aktivitten hinsichtlich der Ermittlung von Anforderungen fehlen in dem NAF vollstndig, so dass fr diesen Komplex im Rahmen der Architekturentwicklung zustzliche Aktivitten einzuarbeiten sind.
3.4.10 Tailoring im NAF

Aus den Ausfhrungen zu Abschnitt 3.4.6 wird deutlich, dass im NAF eine Vielzahl von Sichten und Teilsichten in Form von Aktivitten und resultierenden Produkten definiert sind. Einige davon knnen als optional angesehen werden, andere wiederum sind zwingend erforderlich. Die endgltige Entscheidung, welche Teilsichten erarbeitet werden und welche nicht weiter betrachtet werden sollen, muss in dem Architekturboard getroffen werden.
27
Vorschlag fr einen Minimalumfang: All View 1 (AV1): Beschreibung des Kontextes All View 2 (AV2): Glossar Operational View 1 (OV1): Festlegung der organisatorischen Einheiten und deren Zusammenwirken (ber Informationskanle). Operational View 2 (OV2): Zuordnung von Aktivitten zu organisatorischen Einheiten und Rollenfestlegung. Operational View 3 (OV3): Abbildung von Daten (Inhalte und Strukturen) auf Informationskanle. Operational View 5 (OV5): Beschreibung von Aktivitten und Daten. System View 1 (SV1): Abbildung der Rollen/Aktivitten auf Systemfunktionen und Informationskanle auf Interfaces. Technical View 1 (TV1): Auflistung der in SV1 verwendeten Produkte und Standards.
eine gemeinsame Basis fr die Arbeit der AG Architektur Bundeswehr (AG ArchBw) und der verschiedenen OrgBereiche zu schaffen, die Verfahren der Architekturer-/-bearbeitung zwischen den OrgBereichen festzulegen, die Nutzung gemeinsamer Verfahren sowie die technischen Grundlagen fr die Modellierung innerhalb und fr die Bundeswehr zu regeln. Damit stellt die vorlufige Rahmenregelungen aber nicht nur eine Handlungsrichtlinie fr Stellen innerhalb der Bundeswehr dar, sondern dient auch der beteiligten Industrie als Orientierungshilfe ber die konkreten Vorstellungen der Bundeswehr bei der Vorgehensweise von Architekturer- bzw. -bearbeitung und somit bei der Durchfhrung 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 Grundstze, Rolle, Ablufe und Vorgehensweisen bei der Er- / Bearbeitung von Architekturen.
3.5 Rahmenregelung Architekturerarbeitung/-bearbeitung ITSysBw

Die vorlufige Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw (siehe /5/) ist eine wesentliche Grundlage der Bundeswehr fr die Architekturmodellierung im IT-System der Bundeswehr (IT-SysBw). Sie ist ein Folgedokument zur TK FUstgBw und IT-SysBw (siehe /4/) und orientiert sich an dieser, da diese TK derzeit die magebende Vorgabe zur Nutzung der Architekturmethode innerhalb der Bundeswehr darstellt. Unter einer Rahmenregelung ist eine Regelung zu verstehen, die die Ablufe und Verfahren zur Modellierung von Architekturen und ihrer weiteren Nutzung, die verantwortlichen und die zu beteiligenden Stellen, sowie die jeweils zu erstellenden Architekturprodukte im Grundsatz beschreibt. (siehe /5/, Seite 51)
3.5.1 Anwendungsfelder von Architekturen in der Bundeswehr

Seitens der Bundeswehr werden in der vorlufigen Rahmenregelung drei mgliche Anwendungsflle unterschieden (siehe /5/, Kapitel 3), in denen Architekturentwicklungen zum Einsatz kommen knnen: Untersttzung konzeptioneller Arbeit, Untersttzung operationeller Planung, Untersttzung der Bedarfsermittlung und -deckung nach CPM. In diesen Anwendungsfllen kommen unterschiedliche
Auf diese Weise definiert sich die Rahmenregelung Architekturer-/-bearbeitung IT-SysBw selbst. Das Ziel der Rahmenregelung ist es somit, im Rahmen von Architekturentwicklungen
Ausprgungen der Architekturtypen (Overarching (OA), Reference (RA), Target (TA) oder Baseline Architecture (BA)) zum Tragen. Whrend im Rahmen der Untersttzung konzeptioneller Arbeiten die OA und BA entwickelt/
28
bearbeitet werden, werden bei der Untersttzung der operationellen Planung und der Bedarfsermittlung und -deckung nach CPM RA/TA er-/bearbeitet und BA ggf. ergnzt. Bei der Er-/Bearbeitung von RA oder TA wird zwischen aufgabenorientierten (Untersttzung operationeller Planung) und fhigkeitsorientierten Architekturen (CPM-Untersttzung) differenziert. Diese Ausfhrungen bieten allen an einer Architekturentwicklung Beteiligten (Auftraggeber, Auftragnehmer und sonstigen Projektbeteiligten) eine Orientierungshilfe ber den erforderlichen Architekturtyp und daraus resultierend letztlich ber die erforderliche Vorgehensweise.
z.B. zu Phasen-/Stufendokumenten des CPM, werden in Einzelschritten detailliert beschrieben. Diese Ausfhrungen bieten eine Orientierungshilfe und Anleitung fr die grundstzliche Vorgehensweise im Rahmen von Architekturentwicklungen. Sie stellen zudem auch eine Art Checkliste dar, die zum Tailoring eines entsprechenden Projektes und zur berprfung der relevanten Schritte und Ergebnisse herangezogen werden knnen.
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 einfgt. Die zu entwickelnden Artefakte der Architekturen der Bundeswehr mssen nachvollziehbar, lesbar und verstndlich strukturiert gestaltet werden, um damit sowohl die Vergleichbarkeit als auch die Wiederverwendbarkeit der Architekturmodelle zu gewhrleisten. Im Sinne der NNEC ist auch davon auszugehen, dass Architekturen durch unterschiedliche Nationen entwickelt werden. Es gilt also auch eine gemeinsame national bergreifende Verstndnisbasis fr die Darstellung der Architekturen mit unterschiedlichsten Zielsetzungen aufzubauen. Um diesen Anforderungen gerecht zu werden, sind
3.5.2 Architekturmanagement
Bezglich des Architekturmanagements beschreibt die Rahmenregelung die zugrunde gelegten Grundstze, die involvierten Ebenen/Rollen und ihre Aufgabenschwerpunkte/-ausprgungen sowie die durchzufhrenden Aufgaben aus Sicht des Auftraggebers Bundeswehr (siehe /5/, Kapitel 4 und Anlage 10). Diese Ausfhrungen bieten ebenfalls eine Orientierungshilfe bzgl. der gewnschten Vorgehensweise fr die an einer Architekturentwicklung Beteiligten. Weitere Ausfhrungen ber Umsetzungsmglichkeiten sind in Kapitel 6 dargelegt.
3.5.3 Grundstze, Rollen, Ablufe und Vorgehensweisen bei der Er-/Bearbeitung von Architekturen
Der wesentliche Anteil der Rahmenregelung (siehe /5/, Kapitel 5 und Anlagen 5 9) befasst sich mit Grundstzen, involvierten Rollen sowie Ablufen und Vorgehensweisen bei der Er-/ Bearbeitung der verschiedenen Architekturtypen (OA, RA, TA, BA), die vom Auftraggeber Bundeswehr vorgesehen sind. Insbesondere vorgesehene Ablufe und Vorgehensweisen sowie Aus- und Wechselwirkungen,
Vereinbarungen festzulegen, die einen verbindlichen Rahmen fr die Erstellung der vorgesehenen Diagramme, Matrizen und Dokumente einer Architektur bereitstellen, ohne dass sie die Handlungsspielrume der Architekten, die sich ggf. aus projektspezifischen Anforderungen ergeben, unangemessen einschrnken.
29
Es muss der Grundsatz gelten: Konventionen sollten so wenig wie mglich, aber so viel wie ntig verbindlich regeln. Theoretisches Fundament fr die Ausgestaltung von Modellierungskonventionen fr Architekturen sind die Grundstze ordnungsmiger Modellierung (GoM). Die GoM stellen ein Hilfsmittel dar, um sicherzustellen, dass die Modellierungsaktivitten effizient und ausgerichtet an den tatschlichen Bedrfnissen eines Organisationsprojekts durchgefhrt werden.
des Grundsatzes der Klarheit). Bei der Entwicklung der Konventionen sind Grundstze der GoM gegeneinander abzuwgen und zu gewichten.
3.6.2 Sachstand
Zurzeit existieren noch keine einheitlichen und verbindlichen Konventionen fr die Architekturentwicklung in der Bundeswehr. In der Vorbereitungsphase zur Entwicklung von Architek-
Nachfolgende sechs Grundstze sind in den GoM enthalten und mssen in der Entwicklung der Architekturen grundstzlich bercksichtigt 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 fr die jeweilige Perspektive relevanten Sachverhalte, keine Abbildung irrelevanter Informationen Grundsatz der Wirtschaftlichkeit Bedeutet: Modellierungsaktivitten sollen in angemessenem Kosten-Nutzen Verhltnis stehen, Nutzung von Referenzmodellen, Manahmen zur Wiederverwendung Grundsatz der Klarheit Bedeutet: Strukturiertheit, bersichtlichkeit, Lesbarkeit (intuitiv) Grundsatz der Vergleichbarkeit Bedeutet: modellbergreifend konforme Anwendung der Modellierungsvorgaben, Ziel: Konsolidierung unabhngig voneinander erstellter (Teil-) Modelle Grundsatz des systematischen Aufbaus Bedeutet: definierte Schnittstellen zu korrespondierenden Modellen (z.B. Inputdaten des Prozessmodells / Referenz auf Datenmodell) Die mit den Grundstzen verbundenen Zielsetzungen stehen teilweise kontrr zueinander. (z.B. der Grundsatz der Wirtschaftlichkeit in Konflikt zur Anwendung
turen wurden bisher spezifische Notationen entwickelt, die nur fr die zu entwickelnde Architektur zur Anwendung kommen. In der folgenden Tabelle wird ein Auszug bereits entwickelter Architekturen und die in der Architektur verwendeten Konventionen aufgefhrt.
Architektur OrgBereich Verwendete Konventionen

AFEinsLuSK Luftwaffe Konventionen fr die Architekturentwicklung in der Luftwaffe Style Guide SKB Konventionen fr die RA UAV-IMINT Konventionen fr Diagramme der Zielarchitektur SAATEG
AFEinsSKB RA UAV-IMINT TA SAATEG
SKB Luftwaffe
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 fr die Architektur regelt. Inhaltlich unterscheiden sich die Konventionen massiv. Die folgende Tabelle verdeutlicht die gravierenden Unterschiede z.B. bei der Namensvergabe am Beispiel des NOV-2 Operational Node Connectivity Diagram:
30
Architektur
RA KuK EU RA KVKB RA UAV-IMINT TA SAATEG
Namenskonventionen
OV-2_[Fachlicher Bezug] RA_KVKB_OV2_[Level]_[Fachlicher Bezug]6 RA-IMINT_NOV2[Fachlicher Teil]_[OpNodes] oder RA-IMINT_NOV2[Fachlicher Teil]_[OpNode]_Activity TA-SAATEG_NOV2[Fachlicher Teil]_[OpNode]_Intranodal_Activity oder TA-SAATEG_NOV2[Fachlicher Teil]_[OpNode]_Intranodal_Internodal RA_ObjS_OV2_Mod07_[Fachlicher Bezug]
Grundlage
Konventionen fr die Architekturentwicklung in der Luftwaffe Style Guide SKB Konventionen fr die RA UAV-IMINT Konventionen fr Diagramme der Zielarchitektur SAATEG
RA ObjS
Style Guide SKB und Konventionen fr die Architekturentwicklung in der Luftwaffe
Tabelle 3.6-2: Namenskonventionen
Die Tabelle verdeutlicht, dass an dem Beispiel der Bezeichnung der Modelle der Anspruch der Wiederverwendbarkeit, Vergleichbarkeit und Klarheit als eine grundlegende Zielsetzung erschwert bzw. in Frage gestellt wird.
Es stellt sich die Frage: Was sollte in den Konventionen fr die Architekturmodellierung der Bw festgelegt bzw. beschrieben werden? Nachfolgende Auflistung stellt die wesentlichen
Die Einhaltung von bestimmten Rand- und Rahmenbedingungen im Sinne einer einheitlichen Semantik ist jedoch unerlsslich. Zuknftig werden zahlreiche auftragsbezogene Architekturen durch unterschiedliche Modellierer mit unterschiedlichem Sachbezug in unterschiedlichen Organisationsbereichen der Bundeswehr erarbeitet werden. Durch die Nutzung unterschiedlicher Werkzeuge und individueller Auffassungen und Ansichten werden damit eine Vielzahl von Gestaltungsmglichkeiten erschlossen, die u. a. zur Unbersichtlichkeit der Modelle und damit zu erschwerter Informationsgewinnung der zuknftigen Nutzer fhrt.
Aspekte dar, die in die Konventionen fr die Architekturmodellierung der Bw einflieen sollten: Kriterien fr die Einordnung der Architektur in die Architekturfamilie der Bw: Um die Entwicklung von Insellsungen auszuschlieen, mssen alle Architekturen in die Architekturfamilie der Bw einfgbar sein. Zu entwickelnde Kriterien geben Bedingungen an, wie und wo (Touch-Points) die Architektur in die Architekturhierarchie eingeordnet wird. Entwicklung eines Wertevorrates von Architekturobjekten: Der Wertevorrat bildet eine bergreifende Sammlung von Definitionen zur Vereinheitlichung der Architekturmodelle. Dieser Wertevorrat wird aus bestehenden Definitionen von einer zentralen Stelle zusammengefhrt und gepflegt. Um dem Anspruch eines bergreifenden und redundanzfreien Wertevorrates gerecht zu werden, ist die Auswahl der im Wertevorrat zu hinterlegenden Definitionen von besonderer Bedeutung. Dabei ist insbesondere die Wiederverwendbarkeit der Definitionen ein wichtiges Auswahlkriterium.
3.6.3 Empfehlung zur Entwicklung von Konventionen

Die Verwendung des NAF ist eine verbindliche Vorgabe der technischen Architektur der Bundeswehr (TABw), die Standards fr IT-Systeme der Bundeswehr definiert. Die zu entwickelnden Konventionen konkretisieren die Vorgaben von NAF und sind toolunabhngig zu gestalten.
6. Fr den [Fachlichen Bezug] wurden Wertevorrte definiert. Fr NOV-5 wird zustzlich die Diagrammart (Mod, Tree) eingefgt. 7. Diagrammart: Modell, Ebene:0
31
Vorgaben zu den Architekturelementen (NNEC): Wie bereits im Kapitel 3.6.1 vermerkt, mssen 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. Modellbergreifende Konventionen: Festlegungen zur Modellierungssprache, Verwendung von Abkrzungen, Gro-und Kleinschreibung, Konventionen zur Benennung der Enzyklopdien und Artefakte. Modellspezifische Konventionen: Namenskonventionen der im Modell zu verwendenden Definitionen, Vorgaben zur Verwendung beschreibender Attribute. Konventionen zu Qualittssicherung: Vorgaben und Vorlagen fr die syntaktische Architektur QS, Semantische Architektur-QS und Strategische Architektur QS. Konventionen zum Konfigurations-Management (KM): Die Anwendung und Durchfhrung von KM resultiert in einem Konfigurationsmanagementprozess (KMP). Der KMP regelt den Lebensprozess von Architekturen hinsichtlich der Organisation und Planung, der Konfigurationsidentifizierung, der Konfigurationsberwachung und der Konfigurationsberprfung . Ziel
8
3.6.4 Abzeichnende Vorgehensweise Bundeswehr

Konventionen, Wertevorrte und Taxonomien fr 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 -Bearbeitung wird durch die AG Architekturen Bundeswehr erstellt und fortgeschrieben. Die Verffentlichung der 1. Version des Handbuches ist fr das IV. Quartal 2009 geplant. Auf Grund sich stndig ndernder Rahmenbedingungen und Vorgaben unterliegen die innerhalb der Bundeswehr anzuwendenden Verfahren und damit verbunden auch Konventionen, Wertevorrte und Taxonomien fr die Modellierung von Architekturen einer stndigen Vernderung. Diesen Vernderungen trgt die Fortschreibung des Handbuch Architekturer- und -Bearbeitung durch die AG Architektur Bundeswehr Rechnung. Bis zur Etablierung eines entsprechenden Change Managements werden Vorschlge zur nderung des Handbuch Architekturer- und -Bearbeitung formlos auch von Seiten der Industrie ber die Bevollmchtigten Vertreter der Organisationsbereiche9 in die AG Architekturen eingebracht, von dieser abschlieend beraten und bei Bedarf als nderung der Bnde II -VIII des Handbuches verffentlicht. Die Vorgabe von Konventionen, Wertevorrten und Taxonomien fr die Modellierung von Architekturen in der Bundeswehr im Handbuch Architekturer- und -Bearbeitung beschrnkt sich auf ein fr die Wahrung organisationsbereichsbergreifender Belange unbedingt notwendiges Ma. Im Regelfall werden zustzliche Konventionen, Wertevorrte und Taxonomien fr einzelne Aufgabenbereiche durch die Organisationsbereiche10 bzw. fr einzelne Architekturen durch den Aufgabensteller vorgegeben. Diese Konventionen, Wertevorrte und Taxonomien werden im Architekturplanungsdokument Overview and
des KM ist es, den Grad der Erfllung physischer und funktionaler Anforderungen an eine Architektur zu dokumentieren und diesbezglich volle Transparenz herzustellen. Diese soll zudem dazu fhren, dass jeder an einer Architektur Interessierte die richtige und zutreffende Dokumentation verwendet. Konventionen zum nderungsmanagement: Vorgaben zur Verwaltung und Pflege von Architekturen (zu verwendende Tools, Verantwortlichkeiten).
8. Quelle: DIN - DEUTSCHES INSTITUT FR NORMUNG e.V. (Hrsg.): DIN EN ISO 10007: 1996 Qualittsmana-gement - Leitfaden fr Konfigurationsmanagement (ISO10007:1995) 9. nderungsvorschlge der Industrie sind grundstzlich ber den BV BWB bzw. IT-AmtBw einzubringen. Ergeben sich nderungsvorschlge aus Modellierungen im Rahmen von Studien u. ., sind nderungsvorschlge ber den BV des Aufgabenstellers einzubringen. 10. z. B. durch den Prsident IT-AmtBw fr die Modellierung im Rahmen der Bedarfsermittlung- und deckung im Verantwortungsbereich des IT-Direktors
32
Summary NATO All View 1 (NAV-1) der jeweiligen Architektur dokumentiert. Im Architekturrahmenwerk Bundeswehr wird zunchst zur Etablierung eines einheitlichen Verstndnisses der grundstzliche Aufbau von Architekturen beschrieben. Whrend die Architekturtypen aus dem NATO Architecture Framework in der Version 3 ohne Vernderungen bernommen wurden, wurden die Architektursichten des NATO Architecture Framework durch zustzliche, bundeswehrspezifische Elemente ergnzt. Im Folgenden werden zunchst bergreifende Konventionen dargestellt, die unabhngig von einem konkreten Diagramm, Objekt, Symbol oder Attribut immer anzuwenden sind. Dieser Teil enthlt auch eine Aufstellung der Sub-Views / Templates, die in einer Architektur unabhngig von Zielstellung und konkretem Inhalt immer zu modellieren sind. Des Weiteren werden Konventionen fr die Elemente einer Architektur dargestellt. Ergnzt wird diese Darstellung durch die Vorgabe von Wertebereichen und Taxonomien fr die Einordnung bestimmter Objekte. Die Inhalte der Konventionen sind werkzeugunabhngig. Sie orientieren sich am NAF und untersttzen den Modellierer, konsolidierte, integrierbare und redundanzfreie sowie lesbare und verstndliche Architekturen zu erarbeiten.
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 (ITSichhKProj) ist fr Architekturentwicklungen eine Pflichtvorgabe. In dem IT-SichhKProj ist die Einhaltung aller uneingeschrnkt geltenden IT-Sicherheitsanforderungen sowie weiterer spezieller IT-Sicherheitsanforderungen (z. B. anhngig von der jeweiligen Architektur) nachzuweisen. Die uneingeschrnkt geltenden IT-Sicherheitsanforderungen sind in der ZDv 54/100 aufgefhrt. 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.).
3.7 IT-Sicherheit
Zur Gewhrleistung der IT-Sicherheit von Architekturentwicklungen werden seitens der Bundeswehr verschiedene IT-Sicherheitsziele in Form von Detail- und Ergnzungsregelungen vorgegeben. Die wesentliche Durchfhrungsbestimmung ist die Zentrale Dienstvorschrift 54/100. Diese wird durch Einzelvorschriften, allgemeine Umdrucke, Weisungen und anerkannten Standards aus dem Bereich von Architekturentwicklungen ergnzt. Bei internationalen Architekturentwicklungen knnen weitere Vorgaben (z. B. der NATO) hinzukommen.
33
4 Notwendigkeiten und Randbedingungen der Auftragnehmerseite im Verteidigungsbereich

4.1 Anforderungsmodellierung & Interessengruppen 4.1.1 Einfhrung
Die Entwicklung eines Systems bzw. Produkts hat das Ziel, die Bedrfnisse mehrerer Personen, Gruppen und Institutionen zu befriedigen, wobei die Bedrfnisse und Ansprche sehr unterschiedlich, gegenlufig und sogar widersprchlich sein knnen. 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 verstanden werden knnen. Stakeholder sind die Informationslieferanten fr die Ziele, Anforderungen und Randbedingungen eines Systems. Anforderungen und Stakeholder bzw. Interessengruppen sind somit in engem Zusammenhang zu betrachten, weil Anforderungen immer die Sichtweise einzelner Stakeholder auf ein Problemfeld reprsentieren. Da die Heterogenitt der Interessengruppen mit der Komplexitt eines militrischen Systems fr den Einsatz wchst, steigt auch die Gefahr, dass Anforderungen nicht eindeutig sind und sich unter Umstnden sogar widersprechen. bersehene und vergessene Stakeholder bilden ebenfalls einen Unsicherheitsfaktor, denn vergessene Stakeholder bedeuten vergessene Anforderungen. Werden daraus resultierende Missverstndnisse und Lcken nicht rechtzeitig erkannt, steigt das Risiko kostenintensiver Um- und Nachentwicklungen. Aus Grnden der Risikominimierung besteht aus Sicht der Auftragnehmer bzw. Realisierer die Notwendigkeit, die Stakeholder und in noch strkerem Mae die AnfordeDaraus kann sich ein Kommunikationsproblem ergeben, dessen Lsung in der wechselseitigen Abstimmung der Bedrfnisse und Ansprche besteht. Anforderungen mssen daher durch Meta-Informationen, die die Perspektiven eindeutig identifizieren, konkretisiert werden. Schwerpunktmig lassen sich folgende Problemfelder identifizieren: Mehrdeutigkeiten, Redundanzen, Die verschiedenen Projektbeteiligten (Stakeholder) haben in der Regel unterschiedlich abstrakte Sichten auf ein und dasselbe Problem und formulieren konsequenterweise ihre Bedrfnisse und Ansprche aus ihrer jeweiligen Perspektive. Selbst auf triviale Begriffe gibt es unterschiedliche Sichtweisen, die zu schwerwiegenden Missverstndnissen mit all ihren Konsequenzen fhren knnen. rungsmodelle frhzeitig in der Architekturentwicklung zu verankern. Dieser Abschnitt und insbesondere der Teilabschnitt 4.1.4 verfolgen daher das Ziel, Empfehlungen zu erarbeiten, um die Missverstndnisse jeglicher Art ber den gesamten Lebenszyklus eines Systems zu minimieren, indem Stakeholder- und Anforderungsmodelle erstellt und mit der Gesamtarchitektur integriert bzw. mit ihr verknpft werden. Die Methode Architektur bietet Ankerpunkte, an denen Anforderungsmodelle festgemacht werden knnen. Insbesondere in dem Bereich der operationellen Sichtweisen, die beispielsweise um Use-Case- oder Anforderungsdiagramme ergnzt werden knnten, und in dem Bereich der technischen Sichtweisen, aus denen sich Anforderungen auf Grund verpflichtender Normen ergeben, bieten sich Ansatzpunkte fr Anforderungsanalysen.
4.1.2 Problemdarstellung
34
Widersprche und Ungenauigkeiten. Das Ziel der Anforderungsmodellierung muss es sein, ein gemeinsames Verstndnis fr die Aufgabenstellung und damit einen fr alle Stakeholder akzeptablen Anforderungskatalog zu entwickeln. Eine weitere Dimension in diesem Problemfeld ist die Anforderungsmodellierung selbst, denn es sind viele unterschiedliche Methoden und Anstze in der Literatur bekannt. Vielfach wird jedoch von unbefriedigenden Ergebnissen berichtet, z.B. bei der Erstellung von Anforderungsmodellen zur Auswahl von Werkzeugen oder zur berprfung der Gte der Informationsverarbeitung. Eine Ursache fr diese Probleme liegt in dem Fehlen eines einheitlichen Verstndnisses des Begriffs des Anforderungsmodells, sowie in der Anwendung verschiedener Methoden und Vorgehensweisen zur Erstellung des Anforderungsmodells.
fr den jeweiligen Stakeholder angepassten Abstraktion. Mechanismen zur Sicherstellung der Konsistenz ber alle Detailebenen und Abstraktionsstufen hinweg ermglichen eine homogenisierte und harmonisierte Menge von Anforderungen und verdeutlichen Widersprche, berlappungen und fehlende Vollstndigkeit.
4.1.4 Empfehlungen
In diesem Abschnitt wird versucht, eine Anforderungssicht und zugehrige Modellierungsfunktionen gewissermaen als eine Ergnzung zu den NAF-Sichten zu definieren, die eine einheitliche Anforderungsmodellierung ermglichen, fr alle Aspekte der vernetzten Operationsfhrung eingesetzt werden knnen und sowohl fr Experten wie auch fr Anwender verstndlich sind. Zur Untersttzung der Erstellung und Anwendung der Anforderungsmodelle ist auerdem geplant, eine Methodik zur Anforderungsmodellierung vorzustellen. Deren Ergebnis soll ein Anforderungsmodell sein, das dazu dient, Systemanforderungen und -informationen unmissverstndlich zwischen unterschiedlichen Stakeholdern zu kommunizieren; als Grundlage fr die Systementwicklung dient; mageblich zum Projekterfolg beitrgt und gegebenenfalls als Bestandteil von Vertrgen genutzt werden kann. Vor der Beschreibung der Methodik zur Anforderungsmodellierung sollen an dieser Stelle die verwendeten Begrifflichkeiten noch kurz erlutert werden, insbesondere die Begriffe Ziel, Anforderung, Anforderungsmodell und Anforderungsmodellierung. Ziele sind allgemeine Aussagen ber geforderte Eigenschaften eines Systems, ohne jedoch schon konkrete Anforderungen zu formulieren. Anforderungen sind konkrete, berprfbare Aussagen ber qualitative und quantitative Eigenschaften eines Systems, wobei funktionale und nicht-funktionale Anforderungen unterschieden werden.
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 reprsentieren. Es ist daher von entscheidender Bedeutung, mglichst viele (besser: alle) Stakeholder frhzeitig zu identifizieren und in den gesamten Lebenszyklus-Prozess des durch die Architektur modellierten Einsatzsystems einzubinden. Zur Frderung der Kommunikation und der Zusammenarbeit ist es darber hinaus von entscheidender Bedeutung, mit Hilfe von leistungsfhigen Modellierungsfunktionen die Anforderungen der Stakeholder, die in der Regel als Textsequenzen, Bilder und Zeichnungen vorliegen, um Anforderungsmodelle zu ergnzen, die eine Visualisierung der Forderungen darstellen und somit die Verstndlichkeit erhhen. Detailebenen und unterschiedliche Abstraktionsstufen ermglichen die Darstellung einer Anforderung in einer
35
Anforderungsmodellierung bedeutet die Deklaration von Anforderungen mit Hilfe einer (Modellierungs-) Sprache. Ein Anforderungsmodell ist das Ergebnis einer Anforderungsmodellierung. Basierend auf diesen Erluterungen wird die Methodik zur Anforderungsmodellierung in der nachfolgenden Aufzhlung 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 gewnschten Schutzbedarfs Definition von Detailebenen und Kategorisierung der Anforderungen sowie deren Zuordnung zu den Detailebenen Dokumentation und Prsentation des Modells unter Verwendung des Anforderungsdiagramms aus SysML, das Bestandteil (Teilsicht) der Architekturdokumentation 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 Stakeholdern und Verwaltung von Stakeholdern Anforderungsmodellierung mit Hilfe der SysML
bearbeitet haben. Bereits ermittelte Stakeholder knnen ebenfalls als Informationsquelle herangezogen werden, da diese in der Regel weitere relevante Stakeholder aus ihrem Umfeld kennen. Zu beachten ist, dass mglichst nur solche Stakeholder ausgewhlt werden, die przise und spezifische Kenntnisse ber den Einsatz des Systems (oder auch der Architektur) in dem durch sie reprsentierten Umfeld besitzen. Der gesamte Prozess der Stakeholderermittlung 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 Architecture Stakeholder and Community of Interests) ist eine derartige Rollenaufteilung fr den Bereich der NATO bereits vorgenommen worden (nur fr die Stakeholder der Architektur), die als Ausgangsbasis dienen kann. Eine Mglichkeit der Stakeholderverwaltung sind aufbereitete Tabellen, die die relevanten Informationen enthalten. Ebenso wichtig wie die Stakeholderermittlung ist die Stakeholderbefragung, aus der sich deren Bedarf und daraus abgeleitet die Anforderungen ergeben. Die Durchfhrung 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 vollstndigen Erfassung 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 Paradigmenwechsel von der bisherigen dokumentenzentrierten Anforderungsanalyse hin zur modellzentrierten Analyse empfohlen.
Stakeholder
Da die Vollstndigkeit des Anforderungsmodells in hohem Mae von der Vollstndigkeit der Stakeholder abhngt, kommt der Stakeholderermittlung eine ganz entscheidende Bedeutung zu. Dies gilt sowohl fr die Architektur selbst als auch fr das durch die Architektur beschriebene System. Basis fr die Stakeholderermittlung knnen Listen aus vorherigen hnlich gelagerten Projekten sein. Liegen derartige Informationen nicht vor, kann auf die Erfahrung von Projektleitern und -mitarbeitern zurckgegriffen werden, die hnliche Themen
36
UML als bekannteste Sprache untersttzt neben Anwendungsfllen (Use Cases), die als Anforderungselemente genutzt werden knnen die Anforderungsmodellierung kaum. Es wird daher empfohlen, SysML als Derivat von UML fr die Anforderungsmodellierung zu nutzen, da diese Modellierungssprache ein geeignetes Vokabular und eine eigene Diagrammart das Anforderungsdiagramm zur Verfgung stellt. Mit diesem Diagramm ist die Beschreibung der funktionalen und nicht funktionalen Anforderungen sowie deren Beziehungen untereinander mglich. Die Anforderungselemente der SysML mssen in den Textanteilen nicht zwangslufig die Anforderung selbst beschreiben, sondern knnen auf externe Quellen verweisen, so dass damit die Verankerung zwischen dem Anforderungsmodell in SysML und anderen Architektursichten bzw. Teilsichten (z.B. operationelle Sichten gem NAF) mglich ist.
11
nutzen implizit derartige Anstze durch die Einbindung von externen Partnern und deren Expertise. Es ist aber zu unterstellen, dass sich insgesamt eine Vielzahl verschiedener Konzepte, Anstze und Zielsetzungen hinsichtlich der Vorgehensweise herausgebildet haben. In einer oberflchlichen 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 unterschiedlichen semantischen Ausprgung von Arbeitsergebnissen oder zugrundeliegenden Standards. Unternehmen oder Organisationen mit eigenen Vorgaben im Bereich Architektur knnen daher bei konsequenter Anwendung den grtmglichen Nutzen realisieren. Sie sind in der Lage, eine homogene, konsistente und ineinandergreifende Systemlandschaft zu schaffen, die alle betroffenen Ebenen durchdringt und bestmglich eine Interoperabilitt gewhrleistet. Demgegenber stehen Unternehmen ohne eigene,
4.2 Nutzung und Vergleichbarkeit von Architekturen

Die in diesem Dokument dargestellten Rahmenbedingungen im Verteidigungsbereich stellen eindeutig die allgemeine Notwendigkeit einer architekturbasierten Vorgehensweise in Projekten und Vorhaben fest und fordern eine entsprechende Umsetzung. Allerdings sind derzeit eine Reihe von Fragen hinsichtlich der konkreten Ausprgung und der Nutzung im Kern unbeantwortet.
bindende Vorgaben einem bedeutenden strukturellen Problem gegenber, welches sich negativ auf die Systemlandschaft auswirken kann.
4.2.1 Nutzung in der zivilen Industrie

In der zivilen Industrie gehrt die Nutzung von architekturbasierten Vorgehensweisen weitgehend zum Alltag im Projektgeschft der Unternehmen. Viele Unternehmen haben eigene Architekturmethoden entwickelt, andere
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.
37
In den Projekten dieser Unternehmen bilden sich im Prinzip zufallsgesteuert verschiedenenartige Anstze und Umsetzungen hinsichtlich Architektur aus. Dieser Effekt wird dann weiter verstrkt, wenn sich die Realisierungspartner bzw. Auftragnehmer dieser Projekte hufig ndern und im Projektauftrag keine oder unprzise Anforderungen im Bereich methodischer Vorgehensweise und geforderter Ergebnistypen inklusive semantischer Spezifikationen enthalten sind. Die Arbeitsergebnisse derartiger Projekte knnen, fr sich genommen, durchaus vollstndig und korrekt sein. Allerdings besteht die deutlich erhhte Gefahr, dass sich die Ergebnisse mehrerer Projekte nicht oder nur eingeschrnkt zusammenfgen 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 Anforderungsmanagements auf der Ebene des System of Systems deutlich.
Komponenten, die zu einem Ganzen zusammengefgt bzw. integriert werden. Das daraus entstehende Gesamtsystem wird oft auch als System of Systems bezeichnet. Die Beschreibung der Architektur derartiger Systeme in entsprechenden Ergebnistypen ist ein wichtiges Hilfsmittel zur formalen Beurteilung der Leistungsfhigkeit, ohne aufwendige Teststellungen und Experimente durchfhren zu mssen. In diesem Zusammenhang ist es jedoch dringend angeraten, klare und eindeutige semantische und strukturelle Vorgaben hinsichtlich der Ergebnistypen und ihrer Inhalte zu ttigen. Es geht bildlich gesprochen um die Definition und Vereinbarung einer angemessenen, gemeinsamen Sprache, 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
Empfehlungen
Ein hohes Ma an Parallelitt von Projekten und Vorhaben ohne geeignete, ebenengerechte Kontrolle erhht das Risiko von negativen Effekten auf das bergeordnete Gesamtsystem. Dieses Risiko kann mittels der Definition von Kontrollstrukturen (e.g. Governance), z.B. durch eindeutige, verbindliche Vorgaben fr die Nutzung von bzw. den Umgang mit Architekturen sowie einem bergreifenden Anforderungsmanagement auf der Ebene des System of Systems (im Kontext der Bundeswehr: IT-SysBw) minimiert werden.
Endes auch die resultierenden Systeme insgesamt besser vergleichbar, die (teilweise zwangslufige) Komplexitt wird greifbar und besser erfassbar. Die Beurteilung der Leistungsfhigkeit von derartig beschriebenen Systemen ist mit z.T. deutlich weniger Aufwand durchfhrbar. Hufig ist bei der Betrachtung der Architekturen unterschiedlicher Systeme ein nahezu babylonisches Sprachgewirr anzutreffen. Jedes System bedient sich auf Grund der eingangs geschilderten Problematik Nutzung in der zivilen Industrie einer anderen ggf. gnzlich anderen Sprache oder zumindest einesweit entfernten Dialektes. Selbst innerhalb eines einzelnen Systems kann dieses Problem auf Grund der bereits angesprochenen Komplexitt und der Komponentisierung anzutreffen sein.
4.2.2 Vergleichbarkeit
Im Verteidigungsbereich zeichnen sich die verfgbaren und notwendigen Systeme sehr hufig durch einen hohen Grad an Komplexitt aus. Darber hinaus ist die Entwicklung und Erstellung hufig durch die Forderung nach einer umfassenden Modularitt bestimmt. Das Gesamtsystem besteht aus einzelnen, teilweise sehr unabhngigen Bausteinen in Form von technischen Modulen und
Es gibt im Verteidigungsbereich und in der zivilen Industrie verschiedene Anstze und Lsungen, um eine derartige Sprachreglung vorzunehmen. Dazu zhlt z.B. das NAF. Allen Anstzen und Lsungen ist aber eines gemein: Sie sind naturgem inhaltlich begrenzt bzw. lckenhaft.
38
Eine voll umfassende Lsung ist mit einem einzelnen, derartigen Verfahren, wie z.B. NAF, wahrscheinlich nicht mglich. Es bedarf zustzlicher Regelwerke. Das Vorgehensmodell in der Systementwicklung wird im gesamten ffentlichen Sektor, insbesondere im Verteidigungsbereich, ber das Grundprinzip der Trennung zwischen Bedarfstrger 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 verfgbarer Standardprodukte (auch bekannt als COTS, MOTS oder GOTS ).
13
Die potentielle Vielzahl der Anbieter und deren jeweilige Anstze bedeutet ein hohes Risiko bzgl. der Forderungen nach einheitlichen, konsistenten und durchgngigen Architekturen.
4.3 Unterschiedliche Ausprgungen von Architekturen

Die unterschiedlichen Zielstellungen und Rahmenbedingungen bei der Erstellung und Weiterentwicklung einer Architektur fhren zu unterschiedlichen Ausprgungen der Architekturen. Eine grobe Klassifizierung von Architekturen kann anhand
Im Zusammenspiel mit den Vergaberichtlinien bei ffentlichen Auftraggebern (AG) begnstigt dieser Ansatz die in Kapitel Unterschiedliche Ausprgungen von Architekturen dargelegte Vielfltigkeit von Architekturanstzen und die daraus resultierenden Lsungen. Auf Grund des Vergaberechts ist der AG grundstzlich gezwungen, im Wettbewerb ber den jeweiligen Realisierungspartner fr eine konkrete Bedarfsanforderung zu entscheiden.
der Zielstellung vorgenommen werden. So erfordern folgende Zielstellungen die Modellierung unterschiedlicher Architektursichten und ergnzen sich z.T. im Sinne einer System-of-Systems-Betrachtungsweise: Architekturen fr 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 greren Organisationseinheit, Integration bestehender, einzufhrender und zu entwickelnder Systeme und Komponenten zu einem Gesamtsystem (Integrationsarchitektur). Weiterhin knnen Architekturen auf Grund des zeitlichen und organisatorischen Gltigkeitsbereichs (Scope) vielseitig und unterschiedlich ausgeprgt sein, was zu einer Differenzierung in Unternehmensarchitekturen und Projektarchitekturen fhrt. Im Bereich der operationellen Planung und Bedarfsermittlung bzw. -deckung der Bundeswehr wird zwischen aufgabenorientierten Architekturen (detaillierte Beschreibung von Einstzen und Aufgaben anhand von Szenaren)
Empfehlungen
Unter den gegebenen Rahmenbedingungen des CPM und des ffentlichen Vergaberechts ist es daher ratsam, dass der AG seinerseits eindeutige Rahmenbedingungen hinsichtlich Architektur schafft und in diesem Bereich die bisher vakante Federfhrung bernimmt. Dies beinhaltet z.B. Vorgaben auf struktureller und organisatorischer Basis wie beispielsweise Aufbau von Governance-Strukturen zur permanenten Qualittssicherung der Arbeitsergebnisse vor, whrend und nach einer Systementwicklung Definition erwarteter Architektur-Ergebnistypen und -Produkte whrend eines Projekts bzw. Vorhabens Vorgaben auf inhaltlicher Basis, z.B. Semantische Definitionen Definition von Referenz-Architekturen
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
39
und fhigkeitsorientierten Architekturen (zur Schlieung von Fhigkeitslcken) unterschieden. Auf die Unterscheidung nach dem zeitlichen Betrachtungshorizont und dem Detaillierungsgrad in bergeordnete Architekturen (Overarching Architectures), Ist-Architekturen (Baseline Architectures), Referenzarchitekuren (Reference Architectures) und Zielarchitekturen (Target Architectures) wurde bereits im vorhergehenden Kapitel eingegangen. Die Ausprgung der Architekturen beeinflusst die Vorgehensweise in der Architekturmodellierung in folgenden Bereichen: Auswahl und Customizing des Architekturrahmenwerkes (Architecture frameworks), Auswahl der Architektursichten und -modelle innerhalb des Frameworks, Beschreibungsmethoden und Ergebnisaufbereitung, Abstraktionsgrad und Beschreibungstiefe, Auswahl und Kombination von Modellierungstools, Stakeholder und deren Rollen im Prozess der Architekturentwicklung
Unternehmensstrategie und Vorgehensmodelle zur Systementwicklung, IT-Strategie zur Verwendung von Software-Werkzeugen innerhalb eines Unternehmens, verfgbare IT-Infrastruktur und verfgbare Know-how-Trger, Erfahrungswerte bzw. Risikobewertung bei der Verwendung von Design- und Entwicklungsmethoden, Auftrag und vorgegebene Randbedingungen, Kosten und Nutzen. Diese Betrachtungspunkte werden im Weiteren erlutert und fr die Auswahl von Design- und Entwicklungsmethoden beurteilt. Abschlieend werden in diesem Kapitel Empfehlungen, fr den Umgang mit den Notwendigkeiten und Randbedingungen der wehrtechnischen Industrie hinsichtlich der Auswahl entsprechender Methoden gegeben.
4.4.1 Unternehmensstrategie und Vorgehensmodelle zur Systementwicklung

In Unternehmensstrategien und Vorgehensmodellen zur Systementwicklung des Auftragnehmers sind blicherweise bereits generelle oder spezifische Vorgaben zu Design- und Entwicklungsmethoden fr Systementwicklungen festgelegt, die im Rahmen einer Architekturentwicklung zu bercksichtigen sind. In der Unternehmensstrategie werden auerdem unternehmenspolitische Besonderheiten dargestellt, die in der Geschftsdurchfhrung zu bercksichtigen sind. In der Regel werden allgemeine Regelungen und Vorgaben der Unternehmensstrategie durch ein unternehmensspezifisches Vorgehensmodell detailliert und konkretisiert. Dieses Vorgehensmodell bercksichtigt Vorgaben und Randbedingungen aller Branchen, fr die der Auftragnehmer ttig ist, und ist ggf. nicht spezifisch auf den wehrtechnischen Auftraggeber ausgerichtet. Diese Vorgaben und die generelle Ausrichtung knnen und drfen nicht ignoriert werden, da sie u.a. auch dazu dienen, Systementwicklungen kompatibel und vergleichbar zu machen, sowie durch wiederholten Einsatz Know-How
Die sich aus den o.g. Ausprgungen ergebenden Anforderungen werden im Folgenden nher erlutert und Empfehlungen fr die Vorgehensweise in der Zusammenarbeit zwischen Bundeswehr und Industrie gegeben.
4.4 Auswahl von Design- und Entwicklungsmethoden

Die Auswahl von Design- und Entwicklungsmethoden zur Architekturentwicklung hngt von unterschiedlichen Faktoren ab. Auf die unterschiedlichen Ausprgungen von Architekturen und der damit verbundenen Notwendigkeiten zum Teil unterschiedliche Design- und Entwicklungsmethoden 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 fr die Auswahl, der um folgende Betrachtungspunkte zu ergnzen ist:
40
und Erfahrungen aufzubauen und somit Fehler und Kosten zu reduzieren. Sie knnen sich auerdem in den Vorgehensweisen und Ergebnissen einer Architekturmodellierung widerspiegeln. Bei der Auswahl von Design- und Entwicklungsmethoden im Rahmen einer Architekturentwicklung ist daher im Vorfeld der Entwicklungsarbeiten zu prfen, ob und welche Design- und Entwicklungsmethoden beim Auftragnehmer festgelegt sind, welche dieser Methoden auftraggeberbezogen verwendet werden knnen und anzuwenden sind, inwieweit die Vorgaben an Forderungen des Auftraggebers angepasst werden knnen oder mssen. Bei der Auswahl der Design- und Entwicklungsmethoden ist damit zu rechnen, dass die vom Auftraggeber blicherweise verwendeten und eingesetzten Methoden nicht immer vollstndig angewendet bzw. durch die Unternehmensvorgaben umgesetzt werden knnen.
Die in diesen IT-Strategiebereichen festgelegten Randbedingungen bestimmen die Mglichkeiten an IT-Infrastruktur (z.B. HW-Voraussetzungen) und Applikationen (z.B. Lizenzfragen, Sicherheitsanforderungen), aus denen im Rahmen der Architekturentwicklung geschpft werden kann. Verbunden hiermit sind nicht nur entsprechende Investitionen in technische Ressourcen, sondern auch Investitionen in die Ausbildung der erforderlichen und verfgbaren Know-How-Trger. Architekturentwicklungen sind hufig Projekte, die mit einer Kernzelle beginnen und die im Laufe der Zeit durch Erweiterungen und Detaillierungen an Komplexitt zunehmen. Dieser Komplexittszuwachs kann dazu fhren, dass auch die Auswahl von Design-, Entwicklungsmethoden und -werkzeugen angepasst werden muss. Hierfr muss die IT-Strategie die aktuelle Situation der vorhandenen IT-Landschaft und -Werkzeuge analysieren und Strategien fr deren Weiterentwicklung festlegen. Im Rahmen dieser Strategien sind Innovationen im Applikations-/Werkzeugumfeld zu bercksichtigen, wobei hier besonderes Augenmerk darauf gelegt werden sollte, inwieweit bereits durchgefhrte Architekturentwicklungen auf eine neue Applikation portiert und dort weiterbearbeitet werden knnen. Eine solche Portierung erleichtert nicht nur die Fortfhrung bereits bestehender Arbeiten, sondern stellt auch eine erhebliche Kostenersparnis dar, wenn bestehende Projekte weitergefhrt werden. Die Vorgaben der unternehmensinternen IT-Strategie bercksichtigen keine spezifischen Forderungen des wehrtechnischen Auftraggebers. Wenn diese zustzlich im Rahmen einer Architekturentwicklung umzusetzen sind, hat dies deutliche Auswirkungen auf erforderliche Investitionen, Ausbildung von Know-How-Trgern und damit auf die Kosten des Projektes.
4.4.2 IT-Strategie zur Verwendung von Software-Werkzeugen innerhalb eines Unternehmens

In der IT-Strategie eines Unternehmens sind Rahmenbedingungen fr das Management der Informationstechnologie festgelegt. Sie zeigt ausgehend von der aktuellen IT-Situation den Umfang und die Richtung zuknftigen Handelns auf, um somit langfristige Unternehmensziele zu erreichen. Bestandteile einer IT-Strategie, die Randbedingungen fr die Architekturentwicklung enthalten, sind u.a. die Strategie bzgl. IT-Infrastruktur (Hardware, Betriebssysteme und Netzwerke), Applikationen zur Untersttzung einer effizienten Geschftsdurchfhrung, Informationssicherheit zum Schutz der entwickelten Systeme und verarbeiteten Daten und IT-Innovationen (neue Technologien, die die Geschftsdurchfhrung zuknftig noch besser untersttzen knnen).
41
4.4.3 Verfgbare IT-Infrastruktur und verfgbare Know-how-Trger

Die verfgbare IT-Infrastruktur und das verfgbare 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. Grundstzlich knnte eine Architekturentwicklung auch mit Hilfe der blichen Office-Werkzeuge (z.B. Excel, PowerPoint, Access) durchgefhrt werden, die berall verfgbar sind. Sie ermglichen die Erfassung und Zuordnung von Daten und Informationen (in mehr oder weniger bersichtlicher Form) und deren graphische Aufbereitung. Auerdem ist deren Handhabung den meisten PC-Nutzern vertraut, so dass kein groer zustzlicher Know-How-Aufbau erforderlich ist. Solch einfache Tools haben jedoch einige entscheidende Nachteile: Eine Verknpfung von Informationen und Daten zwischen unterschiedlichen Anwendungen ist nicht oder nur mit erheblichem Aufwand mglich. Ab einem bestimmten Daten-/Informationsvolumen ist dieses mit diesen Werkzeugen nicht mehr handhabbar. nderungen an Informationen mssen manuell an allen relevanten Stellen nachgezogen werden, da eine automatische Verknpfung der Daten fehlt, was eine starke Fehleranflligkeit bedeutet und zu Inkonsistenz der Daten fhren kann.
Wird eine Architektur von einer einzelnen Person oder von einem Team entwickelt? Wie knnen die Arbeitsergebnisse bei einer Teamentwicklung an unterschiedlichen Standorten effizient zusammengefhrt werden? Generell gilt: Je komplexer die Applikation ist, umso grer muss die Hardware- und Netzwerkumgebung konzipiert werden, um ein akzeptables Antwortzeitverhalten bei der Bearbeitung und Verwendung von Architekturen zu gewhrleisten. Die verfgbare IT-Infrastruktur ist diesbezglich regelmig zu berprfen 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 greres Problem bei den Entwicklungsarbeiten dar. Sobald jedoch mit getrennten Datenbasen gearbeitet wird, stellt sich das Problem, wie die Daten effizient wieder zusammengefhrt werden knnen, ohne Informationen zu verlieren. Hierfr bieten unterschiedliche Werkzeuge verschiedene Mglichkeiten an, z.B. des Auscheckens von Informationen/Daten, die das Zusammenfhren erleichtern knnen. Derartige Randbedingungen und Notwendigkeiten im Rahmen einer konkreten Architekturentwicklung knnen die Auswahl eines Entwicklungswerkzeuges mageblich beeinflussen. Diese Problematik zeigt jedoch auch, dass Auswahl und
Da Architekturentwicklungen in der Regel sehr schnell komplexe und umfangreiche Systeme und Datenbanken entstehen lassen, empfiehlt es sich, hierfr auf Werkzeuge zurckzugreifen, die eigens fr Architekturmodellierungsaufgaben entwickelt wurden. Diese Werkzeuge untersttzen 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 Entwicklungsarbeiten selbst und auf Kosten haben. Dies sind z.B.: Welche Abhngigkeiten bestehen zwischen Hardware, Netzwerken und zu verwendender Applikation?
Festlegung der Entwicklungsmethodik nicht nur durch ein geeignetes Werkzeug festgelegt werden, sondern auch durch werkzeugbergreifende und -unabhngige Festlegungen der Vorgehensweisen geregelt werden mssen. Dies bedeutet zudem, dass die Know-How-Trger einer Architekturentwicklung nicht nur in den Design- und Entwicklungsmethodiken des jeweils zu verwendenden Entwicklungstools geschult sein mssen, sondern auch ber die Kenntnis geeigneter und festgelegter Vorgehensweisen auerhalb des Werkzeuges verfgen mssen. Dieses Know-How ist kontinuierlich aufzubauen und zu pflegen.
42
4.4.4 Erfahrungswerte bzw. Risikobewertung bei der Verwendung von Design- und Entwicklungsmethoden
Fr das Erreichen eines definierten Ziels kann es Designund Entwicklungsmethoden geben, die sich durch Faktoren unterscheiden, die in ihrer Summe sich auf die Wahrscheinlichkeit der Zielerreichung auswirken. Dazu gehren Faktoren wie: Mglichkeiten zur Prsentation von Ergebnissen Strukturiertheit der Methoden Komplexitt der Methoden / Fehlerwahrscheinlichkeiten Validierungs- und Verifikationsmglichkeiten Selbst wenn unterschiedliche Methoden zum gleichen Ziel fhren, werden bei der Auswahl der Design- und Entwicklungsmethoden von Auftragnehmerseite in der Regel eine Risikobewertung hinsichtlich des Projekterfolgs durchgefhrt und eine Auswahl zu Gunsten einer Methode getroffen, die die Risiken minimieren.
4.4.6 Kosten und Nutzen

Letztendlich richtet sich die Auswahl von Entwicklungsund Designmethoden nach dem Kosten-Nutzen-Prinzip. Unter Bercksichtigung der im Kapitel 4.4 beschriebenen Einflussfaktoren ist die Frage zu stellen, welcher Aufwand betrieben werden muss bzw. sollte, um das Ziel unter Bercksichtigung des Faktors Kosten optimal zu erreichen. Grundstzlich gilt jedoch: Die Entwicklung einer Architektur im Vorfeld einer Systementwicklung ist neben der Vorgabe aus dem V-Modell XT, dass eine Architektur entwickelt werden muss, zwingend erforderlich, um letztendlich die Kosten der Systementwicklung zu reduzieren.
Jedes System hat eine Architektur, besser ist man, plant sie vorher! 4.4.7 Empfehlungen
Es ist vorteilhaft fr den Auftraggeber und zudem fr 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 bercksichtigen. Eine Mglichkeit dies zu tun, ist die Entwicklung und Abstimmung eines Systems zur Auswahl von Vorgaben. Zur Illustration eines solchen Systems dient die folgende Tabelle:
4.4.5 Auftrag und vorgegebene Randbedingungen

Immer hufiger werden vom Auftraggeber Vorgaben hinsichtlich der zu verwendenden Entwicklungs- und Designmethoden gemacht. Hintergrund sind die aus Auftraggebersicht entstehenden Vorteile hinsichtlich des Nutzens und der Qualittssicherung. Viele der Vorteile sind im Kapitel 3 bereits ersichtlich. Fr einen Auftragnehmer ergeben sich aus diesen Vorgaben grundstzlich zwei Mglichkeiten. Zum Einen lsst 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 fr den zweiten Fall ist, dass der Auftraggeber eine Lieferung im Format A haben mchte und die Lieferung auch im Format A erhlt. Hergestellt wird aber ein Produkt vom Auftragnehmer im Format B und zur Lieferung lediglich in das Format A konvertiert.
Projekttyp
A B C D
Rahmen- Methowerk den

NAF NAF Methode 4711 Methode 2,7,20 Methode 1..n
Werkzeuge
Office Tool X Tool Y Tool Z
Tabelle 4.4-1: Vorgabenmatrix nach Projekttyp
43
Hier besteht also die Aufgabe der Klassifizierung von Projekten sowie die der Festlegung von Vorgaben fr diese Projekttypen.
mit nderungen und Flexibilittsanforderungen in einer vollstndigen Architekturbeschreibung durch eine Evolutionsperspektive dargestellt. Die Rahmenregelung Architekturbearbeitung versteht unter einer Architektur eine Abbildung der grundlegenden Strukturen eines komplexen Sachverhaltes. Diese Abbildung hlt semi-formal einige Aspekte des Sachverhaltes fest. Diese Aspekte umfassen sowohl Basisprinzipien wie Meta-Modelle als auch verschiedenste Perspektiven wie Sicherheit, Leistung, Verfgbarkeit und Evolution, die in mehreren, voneinander abhngigen und sich ergnzenden Sichten (Views), wie beispielsweise funktionelle Sichten, Informationssichten, Realisierungssichten oder operationelle Sichten, dargestellt sind. Ziel einer Architektur 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 Vermchtnisse, Hinterlassenschaften oder auch Altlasten innerhalb einer Systemlandschaft. Oft sind es Individualentwicklungen, die sich durch unzureichende Dokumentation, veraltete Konzeptionen, ltere Betriebs- und Entwicklungsumgebungen, zahlreiche Schnittstellen und hohe Komplexitt auszeichnen. Und genau diese Merkmale sind der Grund dafr, dass sich die Ablsung solcher Systeme oft deutlich ber ein erwnschtes Lebensende hinauszieht, denn die mit einer Ablsung verbundenen hohen Ausfallrisiken bzw. Umstellkosten lassen sich schwer abschtzen. Grundstzliches Problem bei der Ablsung von LegacySystemen ist der gewachsene Funktionsumfang. Auch wenn recht hufig ein weitrumiger Ersatz durch Standards stattfindet, verbleiben meist nicht abgedeckte und oft nicht in einer Architektur festgehaltene Zusatzfunktionen. Das sind manchmal Alleinstellungsmerkmale der gewachsenen und ber Jahre entwickelten Systeme. Der Einsatz serviceorientierter Architekturen bietet hier sinnvolle Anstze, die Komplexitt durch Kapselung zu handhaben. Diese Anstze basieren auf einer Vervollstndigung, Einbettung oder Aktualisierung der Architektur.
4.5 Migration von Legacy-Systemen

Ziel dieses Abschnitts ist es, den Zusammenhang zwischen Evolution von Systemen und deren Architektur aufzuzeigen. Dieser Abschnitt erhebt keinesfalls Anspruch auf Vollstndigkeit, sondern kann und will nur auf Evolutionsaspekte aufmerksam machen, welche auf den folgenden grundstzlichen praktischen Erfahrungen basieren. Wandel ist unvermeidlich, wenn Systeme ntzlich bleiben sollen. Dies sollte in die Architekturberlegungen bereits einflieen. Es existieren verschiedene Arten von Evolution, die wesentlichen Einfluss auf den Entwicklungsprozess haben, denn Systeme knnen 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 Vernderung ist. Von Systemen wird Flexibilitt erwartet, also die Anpassbarkeit an neue Anforderungen. Moderne agile und iterative Entwicklungsprozesse tragen dazu bei. Feedback aus dem operativen Einsatz ermglicht es, Systeme an neue Bedingungen anzupassen, Anforderungen zu validieren. Diese Flexibilitt bedeutet aber auch, dass die Architekturbeschreibungen dieser Systeme aktuell gehalten werden sollten. Jede nderung eines Systems hat Auswirkungen, oft nicht nur erwnschte. Mit nderungen geht ein Anstieg der Komplexitt einher. Deshalb ist der explizite Umgang
44
Migration ist die nderung oder Erneuerung eines wesentlichen Teils eines eingesetzten Systems und damit auch der Architektur, beispielsweise unter Verwendung neuerer Technologien beziehungsweise neuer Infrastrukturen. Analyse und Dokumentation von Evolutionsaspekten sind deshalb wesentliche Bestandteile einer Architektur, die effektive Migrationsentscheidungen und effiziente Weiterentwicklungen ermglichen.
gibt es auch Argumente fr die Beibehaltung eines LegacySystems, wie beispielsweise: Die Kosten fr die Neugestaltung des Systems sind untragbar. Das System erfordert eine hohe Verfgbarkeit. Es bestehen Defizite beim Verstndnis der Funktionalitt. Das System arbeitet zufriedenstellend, und man sieht keinen Grund fr einen Wechsel. Wenn ein Legacy-System nicht ersetzt werden kann, ist es
Die Evolutionsperspektive einer Architektur fokussiert die Flexibilitt eines Systems. Diese Perspektive ist insbesondere fr Systeme mit langen Lebenszeiten wichtig. Dabei spielen Faktoren wir Fortschritt, Hufigkeit der nderungen, Art der zu erwartenden nderungen, die Zeitskala und die zu erwartenden beziehungsweise aufgetretenen nderungskomplexitten eine wesentliche Rolle. Es ist unerlsslich, zu erwartende Evolutionsbedrfnisse bereits beim ersten Entwurf und auch bei der Fortschreibung einer Architektur zu bercksichtigen und ber die Evolutionspfade eines Systems kontinuierlich weiterzufhren und immer wieder neu zu bewerten, um geeignete Migrationsstrategien ableiten zu knnen. Das erfordert insbesondere eine kontinuierliche Pflege, berarbeitung und Kommunikation der Architektur.
noch immer mglich, es im Rahmen der von der Umgebung definierten Grenzen zu verbessern. Die Verbesserung wie auch die Umgebung unterliegt wieder einer Evolution, die eine vollstndige Architektur bercksichtigt. Die Integration von sich unter einem Vernderungsprozess befindlichen Legacy-Komponenten ist komplex. Oft werden deshalb Virtualisierungs-Technologien oder andere Architektur-Manahmen vorgesehen, die es ermglichen, ein Legacy-System in einer vernderlichen Umgebung zu betreiben. Viele andere der nicht-funktionellen Eigenschaften lassen sich durch ArchitekturManahmen erfllen. Umgekehrt erschweren gerade bei Legacy-Systemen einige Architektureigenschaften das Erfllen nicht-funktionaler Anforderungen. Eine interessante Fragestellung bei einem Legacy-System
4.5.2 Migrationsstrategien
Legacy-Systeme haben den Ruf, potenziell problematisch zu sein. Sie sind oft veraltet, in der Regel langsam, funktionell weit hinter dem Stand der Technik, haben meist schlechten Support und weisen grobe Sicherheitsmngel auf. Jedes operative Softwaresystem unterliegt jedoch nderungen, um ntzlich zu bleiben. Legacy Systeme sind schwer zu erhalten, zu verbessern, zu erweitern und abzusichern, da oft ein profundes Verstndnis des Systems fehlt keine dokumentierte Architektur oder diese aufwendig zu erarbeiten ist unvollstndige oder unverstndliche Architektur. Trotz dieser Probleme
ist die Reflexion darber, was es zu einem Legacy-System macht und warum es so langlebig ist. Trend-Technologien sind oft flchtig. Architekturelle Prinzipien sind dauerhafter. Die Beantwortung, warum eine solide Architektur, wie die eines Legacy-Systems, lngere Zeit bestanden hat, hilft kostspielige und risikoreiche Fehlinvestitionen zu vermeiden. Hufig sind Legacy-Systeme gerade diejenigen, die fr einen Anwendungsfall wesentliche ArchitekturPrinzipien stringent und methodisch realisieren. Systeme sind Betriebsvermgen; Organisationen investieren in die Anpassung und nderung dieser Systeme, um ihren Wert zu erhalten. Ein Groteil eines Software-Haushalts geht deshalb in der Aufrechterhaltung bestehender Legacy-Systeme auf. Wenn eine einzige Organisation verantwortlich fr die Entwicklung ist,
45
wird Evolution bercksichtigt. Bei Individualentwicklung geht diese Verantwortung zumindest teilweise auf den Kunden ber, der sich dessen bewusst sein sollte, denn die Fhigkeit zur Evolution ist oft eine Architektureigenschaft, die am Anfang des Lebenszyklus festgelegt wird. Eine die Evolutionsperspektive bercksichtigende Architekturbeschreibung ist dann klrend. Das gilt insbesondere wenn mehrere Parteien fr die Evolution verantwortlich sind. Hufig kommen Diskontinuitten in der Evolution von langlebigen Systemen vor, da Architekturbeschreibungen nicht weitergegeben werden und sich die betroffenen Parteien restrukturieren. Unternehmen knnen fusionieren oder umstrukturieren etc.
Korrektur von funktionalen und sicherheitstechnischen Software-Fehlern, Anpassung der Software an eine andere Umgebung, Ergnzen oder ndern von Funktionalitt. Alle Arten erfordern ein konsistentes Weiterfhren der Architektur. Wartungsaktivitten sind im Vergleich zu Entwicklungsaktivitten aufwendig. Das Hinzufgen weiterer Funktionen, nachdem das System in Betrieb ist, birgt mehr Kosten als die Umsetzung der gleichen Funktionalitt whrend der Entwicklungsphase. Das Weiterfhren der Architektur reduziert die Kosten, indem die strukturelle Komplexitt fokussiert und ein profundes Verstndnis des Systems begnstigt wird.
Re-Engineering und Reverse Engineering

Entwicklungs-Prozesse unterscheiden sich erheblich Specification Start Release 1 Operation Release 2 Release 3 Change indentification process Validation Implemention 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 nderungsauftrgen aus Gesprchen zwischen Nutzern und Entwicklern resultieren, die wiederum in der Architektur formalisiert werden.
Abbildung 4.5-1: Entwicklungsspirale
Software-Pflege und -nderung

Software-Pflege und -nderung oder auch Software-Wartung ist der allgemeine Prozess der Vernderung eines Systems, nachdem es ausgeliefert wurde. nderungen knnen 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 nderung bestehender Komponenten und, soweit erforderlich, durch Hinzufgen neuer Komponenten durchgefhrt. Es gibt drei verschiedene Arten von Wartung:
New system
Change proposal
Software evolution process
Abbildung 4.5-2: Entwicklungszyklus
Der Entwicklungsprozess umfasst die in den Abbildungen dargestellten grundlegenden Aktivitten fr alle Lebensphasen eines Systems.
46
Change request
Impact analysis
Release planning
Change implementation
System release
Fault repair
Platform adaptation
System enhancement
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 Verstndlichkeit optimiert. Hufig haben sie im Laufe der Zeit eine Reihe von architekturzerstrenden nderungen erfahren. Wird die Architektur gepflegt, so bleibt das System weiterentwicklungsfhig. Ist die Architektur nicht mehr verfgbar, kann ein LegacySystem zur nderung, zur Analyse und zur Verbesserung der Struktur und Verstndlichkeit re-engineered werden. Re-Engineering bezeichnet eine Anpassung eines Softwaresystems bei meist gleichbleibender Funktionalitt, oft unter Verbesserung der Softwarequalitt. Eine typische Motivation bei Durchfhrung eines Re-Engineering ist die Eliminierung von Schwachstellen mit dem Ziel, die Umsetzung neuer Anforderungen zu ermglichen. Die Funktionalitt der Software wird dabei im Allgemeinen nicht verndert, jedoch wird eine Architektur dokumentiert. Der Begriff Re-Engineering ist auch ein Konzept fr die durchgreifende nderung von Geschftsprozessen. Das Resultat sind Verbesserungen in entscheidenden messbaren Leistungsgren in den Bereichen Kosten, Qualitt, Service, Zeit oder Sicherheit.
System specification Forward engineering Existing software system
Design and implementation
New system
Understanding and transformation
Re-engineered system
Software re-engineering
Abbildung 4.5-4: Forward Engineering vs. Re-Engineering
Fr den Fall, dass nur eine unzureichende Architekturdokumentation verfgbar ist oder diese aus der Implementierung selbst abgeleitet werden muss, bezeichnet man diesen Prozess als Reverse Engineering, der somit den anfnglichen Teil eines Re-Engineering darstellen kann. Der Begriff Re-Factoring hat eine hnliche Bedeutung wie Re-Engineering, bezeichnet aber im Gegensatz dazu qualittsverbessernde Anpassungen auf niedrigerem Abstraktionsniveau, die sich teilweise automatisieren lassen. Ein Re-Factoring kann somit Teil eines Re-Engineering sein. Re-Engineering zur Verbesserung der Softwarequalitt ist oft erforderlich, um die Qualitt und Wartbarkeit von Software langfristig zu gewhrleisten, da in vielen Fllen im
47
Laufe der Zeit die Softwarequalitt auf Grund vieler durchgefhrter funktioneller Anpassungen schwindet. Dies wird auch "Aging" genannt. Re-Engineering eines Systems hat zwei wesentliche Vorteile gegenber radikaleren Anstzen wie Neuimplementierung Es besteht kein hohes Risiko durch fehlerhafte Spezifikation oder unvorhersehbare Verzgerungen bei der Wiederherstellung von Software. Die Kosten fr Re-Engineering sind oft erheblich kleiner als die Kosten fr eine Neuentwicklung. Die kritische Entscheidung zwischen Re-Engineering und Neuentwicklung ist eine typische architekturbasierte Entscheidung. Damit ein re-engineertes System mit neuer Software interagieren kann, ist oft die Entwicklung von
Komponenten-Adaptern erforderlich. Die Adapter haben die Aufgabe, das Legacy-System funktionell zu abstrahieren und in die neue umgebende Architektur durch adquat strukturierte Schnittstellen einzubetten. Die Kosten fr Re-Engineering hngen von dem Ausma der erforderlichen Arbeit ab, die durchgefhrt werden muss. Leider ist dieses Ausma schwer schtzbar und unterliegt vielen Faktoren, wie Verfgbarkeit von Knowhow Trgern, der verwendeten Technologie und deren Fortschritt, nderung der Umgebung insbesondere der Infrastruktur, Historie der Erweiterungen etc. Es existiert ein Spektrum mglicher Anstze zum Re-Engineering. Die Kosten steigen in der Grafik von links nach rechts. Quellcode-bersetzung ist die gnstigste Option. ReEngineering ist die teuerste.
Original program Reverse engineering Source code translation Program structure improvement
Program documenation
Modularised program
Original data
Program modularisation
Data re-engineering
Structured program
Abbildung 4.5-5: Ein Engineering-Prozess
Re-engineered data
Automated program restructuring
Program and data restructuring
Automated source code conversion
Automated restructuring with manual changes
Restructuring plus architectural chnages Increased costs
Abbildung 4.5-6: Re-Engineering Spektrum
48
Der grte Nachteil von Re-Engineering ist, dass es fr Verbesserungen praktische Grenzen gibt. Es ist nicht mglich, 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 verndernden Geschftsprozesse angepasst. Organisationen, die ein begrenztes Budget fr die Erhaltung und Modernisierung ihrer Legacy-Systeme haben, sind mit der Aufgabe konfrontiert, zu entscheiden, wie man die Investition in die Legacy-Systeme erhlt. Dies bedeutet, dass sie zu einer realistischen Einschtzung ihrer Legacy-Systeme kommen mssen, um dann zu entscheiden, welches die am besten geeignete Strategie fr die Weiterentwicklung dieser Systeme ist. Die Alternativen lassen sich in vier wesentliche strategische Optionen unterteilen: Das System auer Betrieb nehmen. Diese Option sollte gewhlt werden, wenn das System keinen oder nur geringe Beitrge zu Geschftsprozessen leistet. Dies geschieht, wenn sich Geschftsprozesse gendert haben und das System sich nicht mehr an die genderten Umstnde anpassen lsst. Das System unverndert lassen und die Wartung fortsetzen. Diese Option sollte gewhlt werden, wenn das System zur Aufrechterhaltung von Geschftsprozessen erforderlich ist und relativ stabil ist. Ein Indikator fr diese Option ist, dass die Nutzer wenig Kritik uern und kaum nderungswnsche haben. Re-Engineering zur Verbesserung der Wartbarkeit. Diese Option sollte gewhlt werden, wenn die Qualitt des Systems degradiert ist, wie beispielsweise durch regelmige Vernderungen. Regelmige Anpassungen des Systems werden nach wie vor erforderlich sein, diese werden jedoch nach dem ReEngineering einfacher. Ersetzen des ganzen Systems oder von Teilen des Systems durch ein neues System. Diese Option sollte gewhlt werden, wenn andere Faktoren, wie neue Architekturen, es erfordern, das System tiefgreifend zu ndern und eine Neuentwicklung einfacher und kostengnstiger ist oder wenn das alte System nicht mehr den Betrieb sichern kann. In vielen Fllen ist
eine evolutionre Strategie mglich, bei der wichtige Komponenten wiederverwendet werden. Bei der Beurteilung eines Legacy-Systems ist es erforderlich, zumindest eine Geschftsprozess-Perspektive und eine technische Perspektive der Architektur zu konsultieren. Die Kombination aus geschftlichem Wert und der Qualitt des Systems ist die Basis einer fundierten Entscheidung darber, was mit dem Altsystem geschehen soll. Zur Veranschaulichung kann die Qualitt und der geschftliche Wert eines Systems in einem Diagramm visualisiert werden.
High business value Low quality 9 10
High business value High quality 6 7 8
Low business value Low quality 2 1 3
Low business value High quality 5
System quality
Abbildung 4.5-7: Qualitt vs. geschftlicher Nutzen
In der Abbildung kann man sehen, dass es vier Quadranten gibt: Niedrige Qualitt, niedriger geschftlicher Nutzen: Solche Systeme in Betrieb zu halten ist teuer. Diese Systeme sollten auer Betrieb genommen werden. Niedrige Qualitt, hoher Geschftswert: Diese Systeme leisten einen wichtigen Beitrag. Sie sollten nicht auer Betrieb genommen werden. Dennoch bedeutet ihre niedrige Qualitt, dass es teuer ist, sie zu erhalten. Diese Systeme sollten re-engineert werden. Hohe Qualitt, niedriger geschftlicher Nutzen: Das sind Systeme, die nicht viel beitragen, und es ist nicht
49
sehr teuer sie zu warten. Normale Wartungsarbeiten an solchen Systemen knnen fortgesetzt werden, solange keine teuren nderungen erforderlich sind. Hohe Qualitt, hoher Geschftswert: Diese Systeme mssen in Betrieb bleiben und ihre hohe Qualitt bedeutet, dass sich Investitionen in die Umgestaltung rechnen. Normale Wartungsarbeiten am System sollten fortgesetzt werden. Zur Beurteilung des geschftlichen Nutzens eines Systems sollte identifiziert werden, wie die Anwender das System konkret benutzen. Zur Beurteilung, ob ein Software-System aus technischer Perspektive noch vertretbar 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 Instandhaltungsprozesse und nicht zuletzt der Architektur belegt sein. Im Idealfall fhrt eine objektive Bewertung zu einer begrndeten Entscheidung, was mit einem Legacy-System geschehen soll. In die letztendlichen Entscheidungen flieen auch organisatorische oder politische Erwgungen mit ein.
rechnet sich Reverse-Engineering, um Architekturdokumentationen zu erarbeiten, die Legacy-Systeme verstndlicher machen und um sie dann leichter ndern zu knnen. Der geschftliche Nutzen eines Legacy-Systems und seine Qualitt hngen stark von der Umgebung ab. Qualitten werden durch eine Architekturbeschreibung objektiviert und messbar.
4.5.4 Literatur
Systematische Evolutionsanstze findet man unter dem Begriff "Refactoring" beispielsweise in Fowler et al., Refactoring. Die Evolution untersttzende Meta-Model basierte Architekturen werden beispielsweise in Buschmann et al., Pattern oriented Software Engineering, beschrieben. Bass et al., Software Architecture in Practis, bietet Evolution untersttzende Tactics an. Architekturen fr Produktlinien findet man dort ebenfalls. Clements et al., Evaluating Software Architectures, gibt Anleitung zur Evaluation von Architekturen auch bezglich Evolution (dort Maintenance). Seacord et al., Modernizing Legacy Systems, beschreibt Architekturkriterien fr einen Evolutionsprozess speziell fr Legacy-Systeme. http://www.kbst.bund.de/nn_836802/Content/Software/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.5.3 Rsum
Architektur subsumiert eine Struktur oder Strukturen, die es erlauben, von auen sichtbare Eigenschaften zu planen, siehe www.sei.cmu.edu/architecture/definitions. html Es gibt verschiedene Arten von Evolution mit unterschiedlicher Tiefe. Bei individuellen Systemen bersteigen die Kosten fr die Wartung in der Regel die Kosten der Software-Entwicklung. Als investitionsschtzende Manahme sollte Evolution in der Architektur bercksichtigt werden und die Architektur sollte fortgefhrt werden. Der Prozess der Software-Entwicklung hat durch Feedbackschleifen einen evolutionren Charakter. Manchmal
4.6 IT-Sicherheit
Aus Sicht der Auftragnehmerseite werden Architekturentwicklungen im Allgemeinen nach etablierten Standards / Modellen durchgefhrt (z. B. Engineering Standards, Vorgehensmodell, Zertifizierungsstandards, usw.). Jeder Entwicklungsstandard besitzt grundstzlich mindestens ein Referenzmodell fr die IT-Sicherheit, in
50
dem Prozessschritte fr die Prfung und Bewertung der ITSicherheit definiert sind (siehe z. B. V-Modell-XT). In diesen Prfungen und Bewertungen erfolgen Systemtests, Sicherheitsaudits, Evaluationen, Vertrauenswrdigkeitsnachweise sowie Dokumentationen zur Erfllung der IT-Sicherheitsanforderungen aus dem IT-SichhKProj. Der Gebrauch von Referenzmodellen trgt zur Nachvollziehbarkeit und Objektivitt bei, ist aber fr sich allein in BundeswehrEntwicklungsprojekten nicht ausreichend. In der Regel wird seitens der Bundeswehr eine unabhngige Analyse des Architekturkonzepts sowie der zu erstellenden Hardund Software gefordert. In dieser unabhngigen Analyse erfolgen neben dem Nachweis der funktionalen Erfllung der IT-Sicherheitsanforderungen auch eine Bewertung der erforderlichen Vertrauenswrdigkeit sowie ein Wirksamkeitsnachweis zum Schutz von Werten vor Bedrohungen. Grundstzlich sind hier alle Arten von Bedrohungen zu bercksichtigen (Bedrohungen, die in der Architektur bersehen wurden, knnen im daraus resultierenden System zu Schwachstellen werden). Die Wirksamkeit der vorgesehenen Schutzmanahmen 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 Untersuchungsschwerpunkte bei Architekturentwicklungen liegen im Allgemeinen in den Bereichen: Sicherstellung der Vertraulichkeit, Verfgbarkeit und Integritt von Informationen und Daten, Berechtigungskonzept und Zugriffskontrollfunktionen. Neben diesen Nachweisen sind im Verteidigungsbereich ggf. verschiedene Abnahmeprfungen (z. B. Einsatzprfungen, Sicherheitsaudits, Prfungen im Einsatzumfeld, usw.) bis zur Freigabe zur Nutzung vorgesehen. Dabei sind im Allgemeinen unterschiedliche Zustndigkeiten und Verantwortlichkeiten zu beachten. Zulassungen werden durch Zulassungsbehrden erteilt. Zulassungsbehrde 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 fr Sicherheit in der Informationstechnik (BSI) zustndig.
Sicherheit von Webapplikationen

Schwachstellen in Webanwendungen stellen laut der international anerkannten SANS Top-20-Liste ber Sicherheitsrisiken (Stand 9. Mrz 2009) mit Abstand die grte 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 Vorflle, wie beispielsweise der im April 2007 durchgefhrte groflchige Angriff auf Estland, bei dem die Seiten der estnischen Regierung, verschiedener Parteien, Banken und Zeitungen ber lngere Zeit offline gingen, der im August 2008 erfolgte Angriff auf Georgien oder der im Januar 2009 durchgefhrte 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 untersttzen, 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, Behrden und Unternehmen aktuelle und umfassende Informationen zum Thema Internetsicherheit bereitzustellen. Fr 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 enthlt, einer ISi-Leitlinie, welche die Studie in groben Zgen zusammenfasst 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 Auflistung von verschiedenen mglichen Gefahren sowohl fr normalen, als auch fr hohen Schutzbedarf. Ergnzend zur ISi-Reihe stellt die NORM A 7700 eine zertifizierbare Norm fr die Sicherheit von Webanwendungen im EU-Raum dar. Die Norm stellt verschiedenste Anforderungen an sichere Webapplikationen, um bestmgliche Sicherheit der Anwendungen nach dem Stand der Technik zu garantieren. Diese Anforderungen sind bereits bei
51
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 fr Web Services empfohlen. Besonders beim Einsatz von serviceorientierten Architekturen (SOA) wird vermehrt auf Web Services gesetzt, welche ebenfalls entsprechend der Sicherheitsvorgaben der NORM A 7700 abzusichern sind. Nur so kann den strengen Richtlinien fr 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 einflieen mssen: Architektur der Webapplikation Datenspeicherung und Datentransport Konfigurationsdaten Authentifizierung Authentifizierungsmethoden Passwrter Autorisierung Sitzungen Separierung durch Sitzungen Qualittskriterien fr 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 vollstndig in die Anwendung integrieren zu knnen und zum anderen, um eventuell alternative Architekturvarianten, wie beispielsweise einzelne Komponenten zu zentralisieren, besprechen zu knnen. Diese Varianten mssen wieder hinsichtlich ihrer Sicherheitsanforderung und ihres Schutzbedarfs evaluiert werden. Ist bereits ein Standard zum Management von Informationssicherheit, wie z.B. ISO 27001, etabliert, so stellt die NORM A 7700 eine wertvolle Ergnzung 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 Manahmen zur Absicherung der Webanwendung, 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 berprfung von Diensten von Drittherstellern verlangt. Durch die Definition von Anforderungen an sichere Webanwendungen und Web Services und die mgliche Zertifizierung ist eine berprfung nach NORM A 7700 bereits bei der Beschaffung fr Applikationen mit normalem Schutzbedarf empfohlen und mit hohem Schutzbedarf vorgeschrieben. Der Anbieter muss dabei Nachweise erbringen, die Anforderungen, die durch die Norm gestellt werden, zu erfllen.
52
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 Architektur hat und im Sinne einer systematischen Systementwicklung die IT-Architektur im Vorfeld einer Realisierung geplant sein sollte. Nun ist die Planung einer IT-Architektur nicht immer das Ziel einer Architekturentwicklung. Dazu sind bereits Ausfhrungen im Kapitel 3 und im Kapitel 4 enthalten. Hier bietet sich eine Untersttzung der Vorbereitung zur Architekturentwicklung in Form einer Checkliste an. Dafr ist es notwendig die mglichen Ziele der Architekturentwicklung zu kategorisieren. Eine Kategorisierung knnte im einfachsten Fall wie folgt aussehen, um daraus Festlegungen fr die Architekturentwicklung abzuleiten: Bereich A. Untersttzung konzeptioneller Arbeit, B. Untersttzung operationeller Planung, C. Untersttzung der Bedarfsermittlung und -deckung nach CPM. Teilbereich 1. 2 Dokumentation Identifikation von Anforderungen Eine Checkliste knnte im einfachsten Fall eine Frageliste sein: 1. Setzt die Architekturentwicklung auf eine bestehende Architektur auf? i. Wie heit die Architektur? ii. Ist diese Architektur verfgbar? iii. Soll die Architektur weiterentwickelt werden? iv. Sollen die Inhalte der Architektur in der neuen Architektur bercksichtigt werden? v. Warum setzt die Architekturentwicklung auf einer bestehenden Architektur auf? Was heit nun Ermitteln der Ausgangsbasis, und wie sollte man vorgehen? Das Ermitteln der Ausgangsbasis ist die Erstellung einer inhaltlichen Anforderungsliste an die Architektur. Diese Anforderungsliste enthlt Anforderungen ber die Informationen, die verarbeitet bzw. bercksichtigt werden mssen. Hier kann ebenfalls eine Checkliste helfen, um diesen Prozess zu untersttzen. Je besser die Ausgangsbasis ermittelt wird, desto besser ist die Planbarkeit der Architekturentwicklung und desto wahrscheinlicher ist es, dass das Ziel der Architekturentwicklung auch erreicht wird.
5.1.2 Ermitteln der Ausgangsbasis

Im nchsten Schritt muss die Ausgangsbasis fr die Architekturentwicklung festgelegt werden. Warum? Zunchst einmal wird die Architektur fr ein bestimmtes Ziel entwickelt. Um das Ziel zu erreichen, muss man die Ausgangssituation (Basiszustand) definiert haben. Die Ausgangsbasis enthlt alle inhaltlichen Anforderungen an die Architektur und wird fr die Bewertung der Architektur bentigt. In einem Critical Design Review wird gemessen an einer Menge von Anforderungen die Architektur bewertet.
3. Ableitung von Forderungen 4. Machbarkeitsuntersuchung 5. Problemanalyse 6. Interoperabilittsplanung 7. Systemplanung 8. Migrationsplanung 9. berwachung von Strategien 10. berwachung von Kosten
53
2. Setzt die Architekturentwicklung auf ein bestehendes Dokument auf? [Fragen i. bis v. analog zu 1) fr Dokument] 3. Gibt es Schnittstellen zu bestehenden Architekturen? i. Wie heien die Architekturen? ii. Stehen diese Architekturen zur Verfgung? iii. Sollen die Schnittstellen bercksichtigt werden? iv. Warum sollen die Schnittstellen bercksichtigt werden? 4. Gibt es Dokumente die inhaltlich zur Architekturentwicklung beitragen knnen? [Fragen i. bis v. analog zu 3) fr Dokument] 5. Mssen Personen befragt werden, um Informationen fr die Architekturentwicklung zu erhalten? i. Welche Personen sind das? bereitstellen? iii. Mssen Fragebgen erstellt werden? iv. Mssen Interviews gefhrt werden? v. Mssen Workshops durchgefhrt werden? vi. Muss ein integriertes Entwicklungsteam gebildet werden? 6. Muss ein System oder eine Technik untersucht werden, um Informationen fr die Architekturentwicklung 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? ii. Welche Personen knnen Informationen
vi. Sind Eigenentwicklungen zu untersuchen? [Hier sind noch weitere Fragen bzgl. der Komplexitt notwendig] 7. Mssen Daten, Datenmodelle oder Funktionen bzw. Services ausgewertet werden, um Informationen fr die Architekturentwicklung zu erhalten? [Hier mssen Fragen bzgl. der Komplexitt gestellt werden]
5.1.3 Festlegen des Abstraktionsgrades

Zur Festlegung des Abstraktionsgrades muss zunchst eine Kategorisierung erfolgen. Dann wiederum kann durch die Checklisten aus den Kapiteln 5.1.1 Ermitteln der Verwendungsabsicht und 5.1.2 Ermitteln der Ausgangsbasis 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 Verstndnis vermittelt wird, aber keine expliziten Anforderungen 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 erhalten, werden hier neue Begriffe vorgeschlagen, zu denen dann eine Zuordnung zu bestehenden Begriffen erfolgen kann.
54
Abstraktionsgrad
Big Picture Architecture Full Scope Architecture
Architekturtyp nach Anforderungen NAF

Overarching Architecture Darstellung der Zielvorstellung in einer Grafik. Die operationelle Sicht beschreibt alle operationellen- / Geschftsprozesse einer Organisation in den ausgewhlten 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. - (keine Vorgaben) Das abzubildende System muss bis auf Ebene von Segmenten (siehe V-Modell XT <<Segment>>) modelliert sein. Jedes Segment kann nur einmal als Typ vorkommen. D.h. Konkrete Ausprgungen spielen keine Rolle. Die operationelle Sicht muss alle operationellen- / Geschftsprozesse in den ausgewhlten Aspekten abbilden, die das System untersttzen soll. Das abzubildende System muss bis auf Ebene von Komponenten (siehe V-Modell XT, z.B. <<SWK>>) modelliert sein. Die operationelle Sicht muss das Rollen und Nutzungskonzept abbilden.
Spotlight Architecture System Type Architecture
Reference Architecture Reference Architecture
System Architecture
Target Architecture
Tabelle 5.1-1: Abstraktionsgrade von Architekturen
5.1.4 Festlegen der Methodik (Methodische Vorgehensweise)

Wie bereits erlutert wurde, spezifiziert das Architekturrahmenwerk NAF eine Organisationsstruktur von Architekturinformationen und liefert damit einen Rahmen fr das Beschreiben von Architekturen. Die Festlegung der Methodik fr das Entwickeln von ITArchitekturen 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 gehren bewhrte Praktiken, idealtypische Verfahren, die teilweise wissenschaftlich erarbeitet wurden, teilweise durch praktische Erfahrungen entstanden sind.
Es existiert eine Anzahl unterschiedlichster Vorgehensweisen, um Architekturen effizient und effektiv im Sinne ihres Verwendungszwecks zu entwickeln. Die fnf bekanntesten und meist angewendeten methodischen Vorgehensweisen fr 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 Architekturentwicklungsprozess integriert werden. Die ADM stellt einen iterativen Prozess dar. Durch die Wiederholung der Prozessschritte werden Detaillierungstiefe erhht, Produkte und Informationen hinzugefgt. Boeing/Openwings Die Openwings-Methodologie untersttzt insbesondere einen serviceorientierten Architekturansatz. Openwings fokussiert hauptschlich die Integration von zuknftigen Systemkomponenten und
55
untersttzt damit ausdrcklich das Wachstum der Interoperabilitt 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, Kontrolle, Organisation und Management beschrnkt. DoDAFs 6 Step model Ausgehend von dem geplanten Nutzen der Architektur, der bergreifenden Zielsetzungen, Rahmenbedingungen, Wechselbeziehungen zu anderen Architekturen wird in einer zweiten Entwicklungsphase der Umfang der Architektur, d.h. der inhaltliche, organisatorische und zeitliche Rahmen der Architektur festgelegt. Nach der Festlegung erforderlicher Informationen, dem Sammeln, Abgleichen und Speichern der Architekturdaten wird die Architektur-Qualitt gesichert. Werden in dieser Entwicklungsphase formale oder inhaltliche Nachbesserung bzw. Ergnzung 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 Vorgehensweise zur Architekturentwicklung ist die Architecture Engineering Methodology (AEM). Die AEM wird in erster Linie von Architekten unterschiedlicher Nationen angewendet, die im Sinne der NNEC Architekturen fr die Entwicklung militrischer Fhigkeiten erarbeiten. 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 Aktivitten mssen durchgefhrt werden? Welche Strukturen sind dafr erforderlich und welche Systemuntersttzung muss dafr implementiert werden? Mittels Kombination aus Architekturaspekt und AEL werden als erstes Modellierungsraum in den Dimensionen Betrachtungsgegenstand sowie Detail-/Abstraktionsebene festgelegt. Daraus abgeleitet werden weitere Vorgehensweisen und Methoden festgelegt, die dafr geeignet sind, den Betrachtungsgegenstand und die gewhlte Abstraktionsebene der Architektur abzubilden.
1 Festlegung des geplanten Nutzens der Architektur
2 Festlegung des Umfangs der Architektur
3 Festlegung der erforderlichen Informationen
4 Sammlung, Organisation, Abgleich und Speicherung der Architekturdaten
5 Qualittssicherung
6 Dokumentation und Publikation der Ergebnisse
Abbildung 5.1-1: Six Step Approach.
56
Die folgende Grafik versinnbildlicht die schematische Zuordnung von Architekturaspekt und AEL:
Die nachfolgende Grafik verdeutlicht diese drei grundlegenden Aspekte und ordnet diesen einen Auszug an mglichen Methoden zu, die bei der Entwicklung einer Architektur angewendet werden knnen. Die in der Tabelle aufgefhrten Methoden erheben keinen Anspruch auf Vollstndigkeit.
Mission Space Functionality ? Construction ? Implementation ?
Information
Application Infrastructure
Reprsetation Inhalte
Wissenserwerb
Kommunikation
Subviews NAV
Security / Governance
Interviews Workshops Checklisten Subviews NSOV Fragenkatalog Selbststudium
Portal eMail Protokoll Workshop
Subviews NOV Subviews NSV
Abbildung 5.1-2: Architekturaspekt und AEL
Subviews NSOV Subviews NCV
5.1.5 Auswahl der Methoden

Nach der Festlegung der Methodik fr die Entwicklung der Architektur stellt sich die Frage: Welche Methoden sind geeignet unter gesetzten Rahmenbedingungen, wie z.B. einem begrenzten Zeitrahmen, verfgbarer personeller Ressourcen und der vorhandenen Ausgangsbasis (vgl. Kapitel 5.1.2), die gesetzten Architekturziele zu erreichen:
Subviews NTV Subviews NPV
Abbildung 5.1-3: Methoden-Informationserfassung-Publizierung
Der Zweck bestimmt die Methode! Es gilt also zweckmige Methoden einzusetzen, die es ermglichen, die zu entwickelnden relevanten Architekturprodukte im Kontext ihrer Verwendungsabsicht unter Bercksichtigung der vorgegebenen Randbedingungen in einer hohen Qualitt zu entwickeln. Eine Architektur stellt eine Wissensbasis dar. Dieses Wissen muss in den Entwicklungsphasen der angewendeten Methodik generiert, verteilt, genutzt und reprsentiert werden. Die Anwendung entsprechender Methoden untersttzen 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 bercksichtigen. Die Ziele der Nutzung eines Repository zur Erfassung aller Architekturmodelle sind gem der Rahmenregelung die Weiter- und Wiederverwendung von Architekturen und ihrer Bestandteile; Die Auswahl und Einrichtung der Tooluntersttzung steht in engem Kontext mit den Zielen, dem Aufbau, den Anforderungen und der Umsetzung des sog. Gemeinsamen Werkzeug unabhngigen Repository (GWR) wie sie in der vorlufigen Rahmenregelung zur Architekturerarbeitung und bearbeitung formuliert sind.
5.1.6 Auswahl und Einrichten der Tooluntersttzung
57
der Vergleich von Architekturen und ihrer Bestandteile; die Nutzung von Erkenntnissen aus Architekturen fr nicht-architekturgebundene Anwendungsflle. Hieraus abgeleitet ergeben sich die nachfolgenden Anforderungen an Modellierungswerkzeuge: Der Export und Import aller Inhalte einer Architektur, inklusive der Metadaten, muss mglich sein; dabei ist der Umfang der auszutauschenden Metadaten sowohl fr die Architektur als auch fr die einzelnen Objekte einer Architektur noch abschlieend festzulegen. Solange eine derartige Festlegung noch nicht erfolgt ist, kommen nur Werkzeuge mit einem flexiblen Datenmodell fr die Modellierung in Frage, um mit der Festlegung das Werkzeug anpassen zu knnen. Das im Modellierungswerkzeug eingesetzte Datenmodell muss dem Metamodell des Frameworks grundstzlich entsprechen, ansonsten ist eine Bereitstellung der Daten fr das Repository nicht werkzeugunabhngig mglich. Das bedeutet u. a., dass unterschiedliche Objekte einer Architektur im internen, werkzeugabhngigen Repository tatschlich als unterschiedliche Objekte verwaltet werden mssen. Der Export und Import muss ber eine standardisierte Schnittstelle erfolgen; die Verwendung einer oder mehrerer mglicher Schnittstellen ist verbindlich festzulegen. Entsprechend dieser Anforderungen sowie ggf. sich zuknftig ergebendem weiteren Bedarf ist im Kontext der Architekturvorbereitung die Tooluntersttzung auszuwhlen und einzurichten.
Stellt sich die Frage: Warum sollten weitere Konventionen, nachfolgend genannt als Rahmenregelungen Architektur fr die Entwicklung einer Architektur fixiert werden? Die Beantwortung dieser Frage begrndet sich auf zwei wesentlichen Argumenten: 1. Architekturen werden mit unterschiedlichen Zielsetzungen, mit unterschiedlichem Sachbezug, mit unterschiedlichen Verwendungsabsichten und Voraussetzungen entwickelt. Die Rahmenregelungen Architektur mssen die Grenzen des Betrachtungsgegenstandes und die betroffene OrgElemente der Architektur verdeutlichen, bestimmte Sachverhalte und Zusammenhnge mssen im Sinne der Zielsetzung der Architektur durch bestimmte Notationen hervorgehoben werden. 2. Wenn an der Entwicklung der Architektur mehrere Architekten arbeiten, dann bedeutet dies, dass individuelle Auffassungen und Ansichten die Architektur prgen werden. Es werden individuelle Gestaltungsmglichkeiten erschlossen, die zur Unbersichtlichkeit der Modelle, zu Informationsverschleierung und verlusten und letztendlich zur Verminderung der Akzeptanz der Methodik fhren knnen. Aus diesen zwei genannten Aspekten gilt es, Rahmenregelungen fr die Architektur festzulegen, die so wenig wie mglich aber so viel wie ntig verbindlich regeln, die Handlungsspielrume der Architekten nicht unangemessen einschrnken, den Sachbezug und Ziele der Architektur besser verdeutlichen, zuknftigen Nutzern helfen, die Inhalte intuitiv und schnell zu erfassen und nicht die Konventionen der Bundeswehr verletzen.
5.1.7 Festlegen der Konventionen

Im Kapitel 3.6 wurde festgestellt, dass es unabdingbar ist, ein Mindestma an bergeordneten Konventionen fr eine Architekturfamilie der Bundeswehr festzulegen, um insbesondere Vergleichbarkeit und Wiederverwendbarkeit der Architekturmodelle zu gewhrleisten.
Folgende Frageliste leistet bei der Aufstellung von Rahmenregelungen fr die Architektur Hilfestellung: Welche Sachverhalte, Problemstellungen mssen visuell verdeutlicht werden? Welche gestalterischen Mittel sollen eingesetzt werden? Wird der Betrachtungsumfang der Architektur visuell verdeutlicht?
58
Werden die zu erarbeitenden Architekturprodukte ausreichend durch die Konventionen Bw beschrieben? Welche beschreibenden Attribute mssen den Objekten zugeordnet werden? Mit der Beantwortung dieser Fragen wird ein Rahmen abgesteckt, auf dessen Grundlage konkrete Normen fr die Architektur festgelegt werden. Diese Rahmenregelungen werden in einem Qualittssicherungsplan dokumentiert und stellen zusammen mit den Konventionen der Bw die zu erfllenden Qualittskriterien der Architektur dar. Der QS-Plan enthlt neben der Darstellung der Vorgehensweise der Qualittssicherung der Architektur und Zustndigkeiten auch die konkreten formalen Qualittsziele, die sich einerseits aus den Konventionen der Architekturmodellierung der Bw und andererseits aus den spezifischen Vorgaben fr eine bestimmte Architektur ergeben. Das Ergebnis der Qualittssicherung wird in dem NAV-3a Architecture Compliance Statement aufgezeichnet.
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, einschlielich der Auswahl und Regelung der Nutzung der bentigten Werkzeuge. Es besteht dabei aus mehreren Teilaufgaben: Das organisatorische Architekturmanagement umfasst alle Aktivitten, die auf die Schaffung allgemeiner Grundlagen und Rahmenbedingungen fr die Anwendung architekturbasierter Verfahren in der Bundeswehr/ im IT-SysBw im nationalen und internationalen Kontext gerichtet sind. Methodenmanagement umfasst alle Aktivitten, die die Anwendung des NAF, eventueller nationaler Ergnzungen sowie dieser Rahmenregelung betreffen. Inhaltsmanagement umfasst alle Aktivitten, die die
5.1.8 Initiieren des ArchitekturManagements

Gem Rahmenregelung zur Architekturerarbeitung/ -bearbeitung verfolgt Architektur Management das Ziel, praktisch handhabbare Architekturprodukte zu entwickeln, die konsistent, kohrent, vollstndig, aktuell und fr den jeweiligen Benutzerkreis verstndlich sind. Weitere strategische Ziele, die mit der Etablierung von Architektur Management erzielt werden knnen, sind: Ausrichtung der Unternehmens-IT an den Geschftsaufgaben, Untersttzung des Aufbaus und Umsetzung einer IT-Strategie, Darstellung einzelnen Architekturen und deren Zusammenhnge, um die Komplexitt beherrschbar zu machen, Frderung der Agilitt einer Organisation, Untersttzung bei der Bewertung von IT-Investitionen um unntige Investitionen zu vermeiden und
Erfassung von Informationen fr Architekturen und deren Nutzung dies schliet die im GWR enthaltenen Informationen ein betreffen. Das technisch-betriebliche Architekturmanagement umfasst alle Aktivitten, die die Steuerung der Bereitstellung und Nutzung technischer Untersttzungsleistungen (Repository, Tools) zur Anwendung architekturbasierter Verfahren in der Bundeswehr / im IT-SysBw im nationalen und internationalen Kontext ermglichen. 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 Qualittsmanagement nderungsmanagement Sicherheitsmanagement
59
Auf Grundlage der brigen im Kontext der ArchitekturVorbereitung erzielten Ergebnisse, ermittelte Verwendungsabsicht, ermittelte Ausgangsbasis, festgelegter Abstraktionsgrad, festgelegte Methodik ausgewhlter Methoden, der ausgewhlten Tooluntersttzung und festgelegter Konventionen sind die oben beschriebenen Aufgaben durchzufhren. Hierbei ist zu beachten, dass alle diese Aufgaben strikt am Zweck der Architektur auszurichten sind und entsprechend architekturspezifisch anzupassen sind. Die nachstehende Grafik zeigt im berblick die Eingangsgren, die Aufgaben und den Kontext der ArchitekturVorbereitung durchzufhrenden Aufgaben des Architektur Managements:
5.2 Architektur-Entwicklung
Eine Architektur lsst 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 frhzeitigen Architekturarbeiten und -aktivitten helfen entscheidend bei spteren Integrationsarbeiten. Hochgradig komplexe Systeme oder Systems of Systems knnen nicht nur durch eine Architekturdarstellung reprsentiert werden. Vielmehr hngen die Strukturierungseigenschaften und ihre Darstellung mageblich davon ab, welche Interessen ein Nutzer einer Architektur verfolgt. In Abhngigkeit von den Interessenvertretern ergeben sich somit auch unterschiedliche Sichtweisen auf ein System, die sich aus den einzelnen
Verwendungsabsicht Ausgangsbasis Festgelegter Abstraktionsgrad Festgelegte Methodik Ausgewhlte Methode Ausgewhlte Tooluntersttzung Festgelegte Konventionen
Rollen und Organisation festlegen Aufgaben festlegen und verteilen Zusammenarbeit festlegen Anforderungsmanagement initiieren Konfigurationsmanagement initiieren nderungsmanagement initiieren Sicherheitsmanagement initiieren
Zuordnung relevanter Rollen Festlegung relevanter Aufgaben Zusammen arbeitsregeln Vorgehensweise AnforderungsMgnt Vorgehensweise KonfigurationsMgnt Vorgehensweise nderungsMgnt Vorgehensweise SicherheitsMgnt
Abbildung 5.1-4: Initiierung Architektur Management
Abschnitten dieses Kapitels ergeben. Allein aus dieser Aufstellung wird deutlich, dass die Views und Sub-Views des NAF nicht ausreichen, sondern zustzliche Sichtweisen definiert werden mssen.
60
Darber hinaus muss beachtet werden, dass eine Architektur in einem Zusammenhang steht und nicht als unabhngiges abstraktes Gebilde anzusehen ist. Um die grundlegenden Eigenschaften eines Systems zu verstehen, muss die Beziehung des Systems zu seiner Umgebung bekannt sein und verstanden werden. Das bedeutet aber letztlich, dass die Entwicklung einer Architektur nicht nur Systemplanungs- und -implementierungsaktivitten im klassischen Sinne untersttzt, sondern auch bei der Untersttzung 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 Prototypen in einer NetOpF- oder NNEC-Umgebung zusammen arbeiten mssen, um diese Experimentalsysteme geeignet zu entwerfen. Eine Architektur dient aber nicht nur als Basis fr nachfolgendes System Engineering und Entwicklungs-Prozesse, sondern kann in ihrer Rolle als Abstraktion der realen Welt auch fr Analyse-Prozesse herangezogen werden, um Fragen und kritische Sachverhalte, die sich aus den Anforderungen ergeben, zu untersuchen und zu klren. Diese Analysen werden in der Regel mittels spezieller Werkzeuge durchgefhrt, jedoch nutzen sie die Modelle und Sichtweisen der Architektur. Umgekehrt beeinflussen die Analyseergebnisse wiederum die Weiterentwicklung der Architektur. NAF-Annex B enthlt einen berblick ber einige Architektur-Methodiken, die nicht im Fokus dieses Kapitels liegen: NC3As Architecture Engineering Methodology (AEM), TOGAF ADM, Boeing/Openwings, META Group and Gartner process model, DoDAFs 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 systeminhrenten Funktionen und Dienste Aktionen durchzufhren, die zur Erreichung eines definierten Zieles beitragen. Demgegenber wird eine Rolle durch eine Menge von Aktivitten, Berechtigungen und Verantwortlichkeiten definiert, um innerhalb eines Prozesses bzw. einer operationellen Aktivitt Funktionen im Sinne einer definierten Aufgabe auszufhren. Darber hinaus werden die notwendigen Kenntnisse, Erfahrungen und Qualittsmerkmale, die fr die Ausbung der Aktivitten erforderlich sind, durch die Rolle beschrieben. Die exakte Definition einer Rolle erfolgt durch eine Rollenbeschreibung (bisweilen 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 fr die Rolle, einer Auflistung der wichtigsten Aufgaben und ggf. Ergebnisse, den Qualifikationsanforderungen, den erforderlichen Ausprgungen der Qualifikationsmerkmale. Die Gesamtheit und die Strukturierung der durch Rollenbeschreibungen definierten Rollen ergibt das Rollenmodell, bei deren Erstellung besonders zu beachten ist, dass Rollen vollstndig und berschneidungsfrei definiert sind, um bei der operationellen Nutzung des Gesamtsystems Kompetenzberschneidungen zu verhindern. Nachvollziehbarkeit und Verstndlichkeit sind weitere
61
Charakteristiken der Definitionen. Auch wenn das Ziel bei der Modellierung der Rollen ist, die Anzahl mglichst gering zu halten, kann aus Grnden der bersichtlichkeit das Modell mehrstufig angelegt sein, die durch eine Typisierung der Rollen und eine daraus resultierende Gruppierung untersttzt wird. In Abhngigkeit von der Zielsetzung der zu entwickelnden Architektur ist ein weiterer Teilaspekt der Nutzer-/Rollenmodellierung von Bedeutung. Aus der Perspektive eines Systemdesigns, fr das die zu entwickelnde Architektur die grundlegenden Vorlagen liefert, sind die spteren Nutzer von untergeordneter Bedeutung und nur die Rollen als integrale Bestandteile von Anwendungsfllen und korrespondierenden Diagrammen wichtige Modellkomponenten. Dient demgegenber die zu entwickelnde Architektur als untersttzendes Werkzeug fr konkrete Missionen, so treten die Nutzer und ihre Relation zu den Rollen wesentlich strker in den Vordergrund. Das Rollenmanagement als Organisationsaufgabe bernimmt in diesem Kontext eine zentrale Position, denn die Verantwortlichen fr den jeweiligen Einsatz mssen konkret entscheiden, welche Rechte und operationellen Aktivitten den definierten Rollen zugeordnet werden. Darber hinaus muss entschieden werden, welche Personen den Rollen zugewiesen werden. Dieser Prozess basiert auf der Korrelation der in der Rollenbeschreibung niedergelegten Qualifikationsanforderungen mit den Qualifikationsprofilen der Nutzer. Ein Nutzer gem obiger Definition kann mehrere Rollen innehaben, aber ebenso knnen 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 knnen. Die Modellierung des Nutzer-/Rollen-Aspektes kann jedoch nicht isoliert betrachtet werden, sondern ist in engem Zusammenhang mit operationellen Aktivitten (operationellen Prozessen) zu sehen. Die logische Einheit, die operationelle Aktivitten durchfhrt, wird als operationeller Knoten definiert, der sich aus der Symbiose von Rollen und systeminhrenten Funktionalitten und Diensten ergibt. Daraus folgt, dass die Ermittlung und
Erfassung von Rollen und deren Charakteristiken sich im Verlauf der Definition der operationellen Aktivitten ergibt, die als orchestrierte Sequenz von Anwendungsfllen definiert sind.
Empfehlungen
Ermitteln der Rollen als Ergebnis der Definition der Anwendungsflle --> Aufstellen eines Rollenmodells (Klassendiagramm aus UML) Erstellen der Rollendefinitionen Erstellen einer generischen Nutzerklasse (als Vorbereitung fr das Rollenmanagement) Bercksichtigung der Zuordnung von Nutzern zu Rollen bereits bei der Modellierung der Rollen Anlegen von generischen Nutzern in der Modellreprsentation Ermittlung der mglichen Nutzer (insbesondere Qualifikationsprofile) und Erstellung des Nutzermodells durch Instanziierung der generischen Nutzerklasse
Modellieren des Aspekts Anwendungsflle

Mit Hilfe von Anwendungsfllen wird eine abgeschlossene, 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 Bedienungseinheiten (Aktoren) an ein System gestellten funktionalen 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 fr ein System spezifizierten Anwendungsflle reprsentieren in ihrer Gesamtheit eine Menge anwendungsorientierter, funktionaler Anforderungen an das System. Um ihre Vollstndigkeit zu erreichen, sollten mglichst alle erkannten Anwendungsflle modelliert werden. Zur Modellierung der Anwendungsflle haben sich insbesondere Use Cases und Aktivittsdiagramme der UML bewhrt, die es ermglichen, transparente Spezifikation zu erstellen und abzustimmen.
62
Die Granularitt kann verschieden sein. Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwendungsfall-Schreibens kann jedoch bis auf Ebene von ITProzessen verfeinert werden, so dass das Verhalten einer Anwendung detailliert beschrieben wird. Zustzlich werden die definierten Anwendungsflle und ihre Beziehungen zu Bedienungseinheiten in bersichtsdiagrammen graphisch dargestellt und benannt. Es stehen Symbole zur Reprsentation der Anwendungsflle, der Bedienungseinheiten und deren Beziehungen zur Verfgung. Es knnen Beziehungen zwischen Anwendungsfllen und Bedienungseinheiten sowie Beziehungen zwischen Anwendungsfllen untereinander dargestellt werden.
Modellieren des Aspekts Informationsaustausch

Die Zielsetzung bei der Modellierung dieses Aspektes ist die Identifikation und Beschreibung aller Informationsaustauschketten zwischen operationellen Knoten auf der Basis von Informationsanforderungen, in denen spezifiziert wird, welche Informationen von einem operationellen Knoten bentigt werden, um seine operationellen Aktivitten durchfhren zu knnen. Die Informationsobjekte, die als Medium dieses Austausches eine korrekte, vollstndige und eindeutige Darstellung von Fakten ber bestimmte operationelle Objekte beinhalten, werden als Informationsprodukte ausgetauscht. Informationsprodukte reprsentieren Informationsobjekte in einem fr eine Weiterverarbeitung (z.B. Berechnungen, Vergleiche, Verknpfungen) korrekten Format. Dieses Modell setzt somit die drei Entitten operationeller Knoten operationelle Aktivitt 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 Qualitt der Information ist notwendig.
Empfehlungen
Die Use Case-Modellierung wird zweckmigerweise in folgenden Schritten durchgefhrt: 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 angestoen wird. Beschreibung der Abfolge von Interaktionen innerhalb des Anwendungsfalls, die notwendig ist, um jene Dienste zu realisieren, die der aktuelle Benutzer bentigt. Festlegung der Bedingungen, durch die ein Anwendungsfall beendet wird, sowie Beschreibungen von Ausnahmesituationen und Alternativen zum vordefinierten Ablauf. Die ermittelten Bedienungseinheiten, die definierten Anwendungsflle und ihre Beziehungen sind in bersichtsdiagrammen zusammenzufassen. Use-Case Modelle bilden eine strukturierte Beschreibung der funktionellen Anforderungen eines Systems und somit auch die beste Basis fr das Testen von Softwaresystemen.
63
Empfehlungen
Der Ausgangspunkt fr die Modellierung dieses Aspektes ist die Festlegung der Attribute, die den Informationsaustausch spezifizieren. Diese Festlegung ist abhngig von der Verwendung dieses Modells. Um auf der Basis dieses Modells in nachfolgenden Schritten den Datenaustausch auf einer Systemebene korrekt spezifizieren zu knnen, ist eine detaillierte Ausprgung hinsichtlich Informationsgehalt, betroffenen Knoten, Medien sowie qualitative und quantitative Aussagen hinsichtlich der auszutauschenden Informationen erforderlich. Fr die Modellierung des Informationsaustausches ist die Verwendung von Tabellen ein zielfhrender Ansatz, in dem sich das oben erwhnte Beziehungsgeflecht zwischen operationellen Knoten, operationellen Aktivitten und Informationsobjekten widerspiegelt. Jede Zeile dieser Tabelle knnte somit den Austausch eines Informationsobjektes zwischen einem Paar operationeller Knoten reprsentierten. Die Gesamtheit des Informationsaustausches, die in dieser Tabellenstruktur dargestellt wird, teilt sich in zwei Gruppen auf automatischer und nicht automatischer Informationsaustausch (z.B. mndliche Befehle). Whrend der nicht automatische Informationsaustausch sich nur auf operationelle Aspekte bezieht, wird der automatische Informationsaustausch auf der Ebene der System weiterverfolgt und fhrt dort zu einem Datenaustauschmodell, das ebenfalls in tabellarischer Form den Datenaustausch zwischen Systemen darstellt.
Anforderungen an das Gesamtsystem: z.B. Einfachheit, Verfgbarkeit von Schnittstellen, Qualitt der Dokumentation, Sicherheit, Benutzerfreundlichkeit. Anforderungen an die Systementwicklung: z.B. Projektumfang, Prioritten, Vorgehensweisen, verfgbare Ressourcen, Kosten der Entwicklung. Anforderungen an Einfhrung: z.B. Testdurchfhrung, Abnahme, Betriebsbeschrnkungen, Wartung, Schulung. Es besteht die Gefahr, dass nicht-funktionale Anforderungen gegenber den funktionalen Anforderungen hufig vernachlssigt werden, obwohl sie wichtiger Bestandteil jeder Anforderungsdefinition sind. Whrend funktionale Anforderungen in UML mit Hilfe von Anwendungsfllen modelliert werden knnen, untersttzt UML die Modellierung nicht funktionaler Anforderungen nicht.
Empfehlungen
Da die Anforderungsermittlung ein wesentlicher Bestandteil des Systems Engineering ist, gibt es in SysML (abgeleitet aus UML) geeignete Vokabeln und sogar eine eigene Diagrammart: das Anforderungsdiagramm. Das Anforderungselement der SysML enthlt: Name, ID und eine textuelle Beschreibung der Anforderung. Anforderungshierarchien werden mit der Enthltbeziehung modelliert. Die bergeordnete Anforderung gilt als erfllt, wenn alle ihre untergeordneten Anforderungen erfllt sind. Das Anforderungsdiagramm ermglicht eine neue Art der Dokumentation von Anforderungen. Als Ergnzung zur bisherigen Methode, die Anforderungen in einem Anforderungswerkzeug zu dokumentieren, knnen 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 Disziplinen dar, wie Architektur oder Test. Partsch H (1991). Requirements Engineering. Mnchen, Oldenbourg.
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 greres System eingebettet ist, entstehen Rahmenbedingungen, die nicht unerheblichen Einfluss auf die Anforderungen und insbesondere auf die nicht funktionalen Anforderungen haben. Nichtfunktionale Anforderungen sind allgemeine Qualittsattribute des zu betrachtenden Systems, die in folgende vier Bereiche untergliedert werden [Partsch H 1991], wobei es durchaus auch andere Mglichkeiten der Klassifizierung gibt: Qualittsattribute einzelner Funktionen: z.B. Ausfhrungsverhalten, Wartbarkeit, Zuverlssigkeit.
64
Modellieren des Aspekts IT-Sicherheit

Bei der Modellierung von IT-Sicherheitsaspekten in Bezug auf Architekturentwicklungen bedient man sich im Allgemeinen formaler oder semiformaler Sicherheitsmodelle. Gngige Sicherheitsmodelle aus dem Verteidigungsbereich sind das Biba-Sicherheitsmodell, welches der Kontrolle von Lese- und Schreibzugriffen in Computersystemen 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 erfllt werden sollen. Diese sollten bereits in einem Grobkonzept niedergelegt und abgestimmt werden, welches als Grundlage fr weiterfhrende Konzepte dient (z.B. Systemanforderungen, Systemarchitektur, Schnittstellenbeschreibung, Technische Anforderungen, usw.). Eine genaue Beschreibung des Zusammenwirkens der ITSicherheitsfunktionen im Hinblick auf einzelne Architektur-Komponenten oder -Teilsysteme ist unerlsslich (z. B. Beschreibung von IT-Komponenten, die bei einem Ausfall die Gesamtverfgbarkeit herbeifhren). Die Modellierung der IT-Sicherheitsaspekte sollte grundstzlich auch zur Festlegung des Hardware- und Softwarekonfigurationszustandes aller eingesetzten Komponenten dienen. Je nach vom Auftraggeber festgelegtem Schutzbedarf ist der Konfigurationsstand dem IT-SichhKProj als Nachweis beizufgen. Die Systemarchitektur und das Realisierungskonzept sind dahingehend zu untersuchen, ob Schwachstellen in den verwendeten Komponenten und Produkten zu bestimmten Bedrohungen fhren. Die Erstellung von Wirkungsketten fr alle Restrisiken ist im Verteidigungsbereich eine grundstzliche 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 Gefhrdungen eintreten kann sowie der Bestimmung von Folgeschden. Eine mgliche
Vorgehensweise zur Bewertung der Risiken findet sich im internationalen Standard ISO 27005. Im Rahmen der Modellierung muss ferner eine Kategorisierung der Restrisiken in die Gruppen tolerierbare Risiken und nicht tolerierbare Risiken vorgenommen werden.
Modellieren des Aspekts Funktionale Sicherheit

Die in der Anforderungsanalyse geforderten Systemfunktionen sollen durch die gewhlte Architektur vollstndig abgebildet werden. Unter dem Aspekt der Funktionalen Sicherheit ist jede mit der Architektur realisierte Funktion unter der Annahme ihres potentiellen Fehlerverhaltens zu betrachten. Es ist zu analysieren, ob das fehlerhafte Ausfhren einer Funktion zu einem Systemzustand fhren kann, bei dem Menschen oder Material gefhrdet werden knnen. Hierzu wird zunchst auf der Systemebene eine sogenannte Gefhrdungsanalyse durchgefhrt. 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). Darber hinaus werden weitere Randbedingungen, wie z.B. die Aufenthaltswahrscheinlichkeit von Personen im gefhrlichen Bereich und die Vermeidbarkeit eines Unfalls, z.B. durch Ausweichen, bercksichtigt. Ein gngiges standardisiertes Verfahren ist die FMEA (Failure Mode & Effect Analysis) bzw. FMECA (Failure Mode & Effect Criticality Analysis). Die Gefhrdungsanalyse wird in mehreren Stufen durchgefhrt. Beginnend auf der Systemebene wird anschlieend z.B. ber eine Fehlerbaumanalyse der Einfluss einzelner Systemkomponenten auf ein Ereignis analysiert und bis auf Modulebene immer weiter verfeinert. Grundstzlich ist das Entstehen von Unfllen auf Grund der identifizierten Gefahren soweit, wie mglich zu verhindern, bzw. die Eintrittswahrscheinlichkeit gering zu halten. Der Auftraggeber sollte hierzu ein fr ihn akzeptables Restrisikos festlegen.
65
Werden im Rahmen der Gefhrdungsanalyse potentielle Gefahren ermittelt, gilt zunchst der Grundsatz, diese Gefahren konstruktiv, d.h. durch nderung der Architektur, zu vermeiden. Sollte dies nicht mglich sein, z.B. weil eine geforderte Systemfunktion potentiell gefhrlich ist (z.B. das Stanzen von Blechteilen), sollen zur Vermeindung von Unfllen geeignete Sicherheitseinrichtungen eingebracht werden (z.B. Schutzgitter und Zweihandbedienung). Fr Systemkomponenten mit sicherheitsbezogenen Funktionen gelten im Entwicklungs- und Qualifizierungsprozess besonderer Randbedingungen, die im Detail in den einschlgigen Normen und Standards beschrieben sind. Im internationalen militrischen Umfeld wird z.B. oft auf die Anwendung des Mil-Std 882 System Safety Program Requirements verwiesen. Fr Systeme mit sicherheitsrelevanten Aufgaben, die im europischen Wirtschaftsraum in Verkehr gebracht werden, ist die Anwendung der DIN EN 61508 Funktionale Sicherheit sicherheitsbezogener elektrischer / elektronischer / programmierbarer elektronischer Systeme (oder eine aus dieser Grundnorm z.B. fr Bahntechnik, Landwirtschaft oder Automotive spezialisierte Norm) verbindlich vorgeschrieben. Fr jedes Projekt sind die vom Auftraggeber akzeptierte Vorgehensweise und die anzuwendenden Standards mglichst frhzeitig festzuschreiben. Idealerweise liegt auch bereits vor dem ersten Entwurf einer Architektur eine vorlufige Gefhrdungsanalyse auf Systemebene vor, so dass die sicherheitsrelevanten Randbedingungen sehr frh in ein Systemkonzept einflieen werden knnen. Fr das BWB ist das Referat T8.3 der zentrale Ansprechpartner zum Thema Funktionale Sicherheit.
Bereich angesiedelt. Um einen effizienten Datenaustausch zwischen den beteiligten Organisationen sicher zu stellen, ist es fr den Informationsaustausch zwingend erforderlich, ein zwischen allen Beteiligten abgestimmtes Datenmodell zu entwerfen, dessen vorrangige Zielsetzung die Spezifikation der auszutauschenden Daten ist. In einem logischen Datenmodell wird die Struktur der domnenspezifischen Information ebenso beschrieben wie der organisatorische Prozess der Informationsbehandlung. Dieses Datenmodell umfasst somit die Definition der Architekturdomnen spezifischen Informationen, ihre Attribute oder Charakteristiken und ihre Beziehung untereinander. Basis fr ein derartiges Modell ist das von der Multilateral Interoperability Programme (MIP) Organisation vorgeschlagene Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM). Da dieses Datenmodell einen querschnittlichen Charakter hat und erheblichen Lcken hinsichtlich Kontext spezifischer Informationen aufweist, muss es erweitert und angepasst werden, um einen kompletten Definitionssatz zu erhalten und ein gemeinsames Verstndnis zwischen allen Beteiligten durch Verwendung einer eindeutigen Sprache zu erreichen.
Empfehlungen
Es wird empfohlen, unter Verwendung von UML Klassendiagrammen ein Datenmodell aufzustellen, dessen Klassen die Informationselemente und deren MetaInformationen enthalten. Auch die Beziehungen untereinander lassen sich mit Hilfe der Klassendiagramme darstellen. Da es zunehmend schwieriger wird, unterschiedliche 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 mssen. Abgeleitet aus diesem Klassendiagramm lsst sich ein Datenaustauschmodell dargestellt in tabellarischer Form ableiten, wobei jede Zeile dieser Tabelle genau einen Datenaustausch zwischen zwei Systemen oder funktionalen Einheiten reprsentiert. Diese Tabelle wird erweitert um austauschrelevante Informationen wie Hufigkeit des Austausches, Durchsatz, Gre, Informationssicherheit und Genauigkeit, um nur einige zu nennen.
Modellieren des Aspekts Datenmodell

Die Herausforderungen bei der Integration unterschiedlichster heterogener Systeme sind nicht nur technischer Natur, sondern sind darber hinaus auch im semantischen (eindeutiges Verstndnis) und organisatorischen
66
Modellieren des Aspekts Kommunikationsschnittstellen

Der Aspekt Kommunikation muss ber mehrere Modellierungsebenen 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 Informationen 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 Hardwareund 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 Anforderungen bzw. aus dem Informationsaustauschmodell ergebenden System-Konnektivitt ausgegangen, die bereits zu erwartende Kommunikationsanforderungen andeutet. Andererseits sind einzusetzende Systemkomponenten bereits mit Kommunikationsports ausgestattet, die in der Regel noch konfektioniert und konfiguriert werden knnen, 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 mssen und somit eine Kommunikationsverbindung bentigen. In einem zweiten Schritt werden diese logischen Knotenverbindungen in einzelne Systemverbindungen aufgebrochen. Fr jede logische Verbindung wird dargestellt, welche Systeme in den Knoten beteiligt sind, ber welche Ports diese Systeme verbunden sind und welche Qualittsanforderungen bestehen. In einem weiteren Schritt wird fr jede identifizierte 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 gehren, die Eigenschaften der Verbindung (Hardware, Protokolle) und die Qualittsanforderungen an die Verbindung. Ein viertes Modell beschreibt detailliert die Kommunikationsprotokolle aller Ports eines Systems. Dazu wird in der Architektur fr jedes System ein Diagramm erstellt, in dem alle Ports mit ihren Charakteristiken aufgefhrt sind.
5.3 Architektur-Anwendung
Eine wesentliche Frage im Rahmen der Architekturentwicklung ist die Frage, wozu die zu entwickelnde Architektur verwendet bzw. worauf sie angewendet werden soll. Diese Frage stellt sich bereits zu Beginn der Architekturmodellierung, sollte jedoch im gesamten Modellierungsverlauf 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 Zusammenhnge, Schnittstellen und offene Punkte zwischen unterschiedlichen Strukturen/Systemen aufzuzeigen und zu analysieren. Die unterschiedlichen Zielsetzungen einer Architektur haben Auswirkungen auf Auswahl und Anwendung von Analyseverfahren, Bewertung der Architektur selbst,
67
Umsetzung der Architektur in technische Implementierungen und Dokumentation der Ergebnisse.
identifizieren und eine Planung zur Migration entwickeln. (Wie kommt man vom Ist zum Soll?). Ein anderes Beispiel fr die Anwendung einer Architektur
Problematiken, Auswirkungen und der Umgang mit diesen Aspekten werden in den nachfolgenden Unterkapiteln kurz dargestellt.
ist die Informationsanalyse. Gerade im Hinblick auf das Ziel zur Vernetzten Operationsfhrung (NetOpF) kommt der Informationsanalyse eine besondere Rolle zu. Hier ist die Frage Welche Information bentigt der Einzelne und was muss mit einer Informationen (z.B. schneller, sicherer) getan werden, damit dieser seine Aufgabe besser erfllen kann?.
5.3.1 Anwenden von Analyseverfahren

Die Mglichkeiten zur Analyse einer Architektur sind mindestens 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 fr Analyseverfahren: Anforderungsanalyse Artefaktanalyse Gap-Analyse Datenflussanalyse Fhigkeitsanalyse 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 Architekturentwicklung oder -weiterentwicklung die anzuwendende Methode feststehen. Dies hilft bereits in der Ausschreibung und Definition der Arbeitspakete fr die Architekturentwicklung. Sollte beispielsweise eine Gap-Analyse durchgefhrt werden, bentigt man in den meisten Fllen zwei Architekturen. Die eine beschreibt den Ist-Zustand und die andere den Soll-Zustand. Dadurch lassen sich Lcken leicht
5.3.2 Bewerten der Architektur

Wann ist eine Architektur eine gute Architektur? Die Bewertung einer Architektur ist nicht trivial aber notwendig. Auch stehen zurzeit keine abgestimmten Bewertungskriterien fr Architekturen fest. Ist die Architektur gut, wenn eine Summe X gegenber einem Aufwand Y eingespart werden kann? Ist die Architektur gut, wenn eine Zerlegung von Elementen nicht mehr mglich ist? Ist eine Architektur gut, wenn das Ziel erreicht wurde? Sollte die Entwicklung einer Architektur beauftragt werden, muss der Auftraggeber eine Mglichkeit haben, die Leistung zu bewerten, um festzustellen ob der Auftrag erfolgreich oder nicht erfolgreich durchgefhrt wurde. blicherweise wird in der Systementwicklung ein Critical Design Review durchgefhrt, 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 Plne mssen sich auf Basis neuer Erkenntnisse ndern drfen. 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 Kriterien fr ein CDR zu Beginn der Architekturentwicklung
68
abgestimmt wurden. Dies betrifft natrlich in erster Linie die Frage der Qualittssicherung (siehe Kapitel 6.4) aber eben auch die Frage der Architekturentwicklung.
knnen als Herausforderungen in einer technischen Perspektive liegen (Ist das System durch die identifizierten Technologien realisierbar?) oder auch in einer operativen oder funktionalen Perspektive (Wird durch das System die beabsichtigte Fhigkeit erreicht? Knnen die Benutzer wie intendiert mit dem System umgehen?). Zur Risikominimierung haben sich prototypische Realisierungen von horizontalen oder auch vertikalen Facetten bewhrt, die die Umsetzung der Architektur verifizierbar machen. Bereits Prfungen der Konsistenz und Integritt gegen ein Meta-Model bei der Erstellung der Architektur knnen das Realisierungsrisiko minimieren. Ausfhrbare Architekturen wie beispielsweise Simulationen oder Prototypen knnen helfen, in frhen 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 trgt 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 mglichst frh Feedback zu erhalten und gegebenenfalls die Architektur und deren Umsetzung an das Feedback anzugleichen. In einer profunden Architektur sind die Abhngigkeiten zwischen Komponenten, die in den bergeordneten, operationellen, systembezogenen oder technologiebezogenen Views erscheinen, deutlich zu erkennen. Diese Abhngigkeiten sind fr die Planung eines Realisierungsprozesses essentiell. Insgesamt lsst sich sagen, dass sich der Entwicklungsprozess von einer umfassenden Architekturbeschreibung ableiten lsst wie beispielsweise 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 Abhngigkeiten zu
Ein vernnftiges Kriterium fr die Bewertung einer Architektur ist die Vollstndigkeit und Nachvollziehbarkeit der zu erfllenden Anforderungen. Damit kann inhaltlich im CDR geprft werden, ob und wie die Anforderungen in der Architektur bercksichtigt 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 knnen sich Erkenntnisse offenbaren, die zur Architektur im Widerspruch stehen knnen. Deshalb erweist sich manchmal eine initiale Architektur als nicht realisierbar. Im Rahmen der Umsetzung wird ein System immer konkreter. Das erweiterte Verstndnis kann dazu beitragen, die Architektur zu korrigieren, Anforderungen zu revidieren. Es ist ebenso mglich, 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 knnen bereits sehr frh kritische Teile eines Systems identifiziert werden, die komplex oder aufwendig zu realisieren sind. Diese Teile
69
reduzieren und so mehr Freiheitsgrade bei der Realisierung und dem Realisierungsprozess zu erhalten. Diese Tatsache lsst 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 Domnenwissen, Dekomposition des Systems in handhabbare unabhngige Komponenten, Inkrementelles Integrieren der Komponenten und des Systems, Design by Contract, d.h. die Vereinbarung von Funktionalitten und nicht von Implementierungen, Natrlich ist die Einhaltung von Architekturvorgaben bei einer whrend der Realisierung gepflegten Architektur unerlsslich und erfordert entsprechende berprfungsmanahmen, wie kontinuierliche Reviews und Change Control Management. Sind Abweichungen von der Architektur notwendig, so sollten diese als Rationale festgehalten werden. Diese Rationalen dienen der Nachvollziehbarkeit und der Evolution der Architektur und damit des Systems. Als bewhrtes Konzept hat sich Occams Razor herausgestellt: Von mehreren Architekturen, die den gleichen Sachverhalt erklren, ist die einfachste zu bevorzugen. Generell wird in der Architektur und auch bei der Realisierung das Verwenden einer Evolutionsperspektive empfohlen, 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 frh bercksichtigt werden mssen, aber erst sehr spt in der Realisierung verifizierbar werden. Oft knnen diese Anforderungen durch die Wahl einer geeigneten technischen Architektur erfllt werden. Hufig werden die funktionalen Sichten einer Architektur betont, da zur Beschreibung von Daten und Ablufen etablierte Notationen existieren. Die Denotationen fr nichtfunktionale Anforderungen wie Performance, Verfgbarkeit, Flexibilitt, Zuverlssigkeit, Skalierbarkeit etc. sind leider nicht so eingngig und finden in der Praxis selten Anwendung. Bei der Realisierung stellen die nichtfunktionalen Aspekte insoweit eine Herausforderung dar, als dass sie sehr frh bercksichtigt werden mssen, aber erst sehr spt in der Realisierung verifizierbar werden.
Agiles Realisieren
Zeitpunkte fr die Reviews sollten an wesentlichen Entscheidungspunkten gesetzt werden. Diese Reviews knnen und sollen sich auf den Sachverhalt der Entscheidung unter Bercksichtigung der abhngigen Teile der Architektur fokussieren. Generelle umfassende Reviews ber Gesamtsysteme behindern in der Regel eine agile Vorgehensweise durch Binden von Ressourcen. Reviews haben sich als ntzliches Instrument herausgestellt, das Realisierungsrisiko zu minimieren und die Erwartungen zu justieren.
70
Lsung am Projektende
Verifikation des aktuellen Standes
Unschrfe abnehmen
Mgliche Lsung
Geplante Lsung
Abbildung 5.3-1: Adaptive Realisierung eines Systems
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 fr den Adressaten und den Zweck angemessene Auswahl der Sichten reduziert sich die Darstellungskomplexitt. Durch unterschiedliche Perspektiven lassen sich unterschiedliche Informationsbedrfnisse und Problemstellungen bearbeiten.
5.3.4 Dokumentieren der Ergebnisse

Dieses Kapitel behandelt einige Aspekte der Erstellung und Pflege einer Architekturdokumentation. Architekturdokumentationen sollen Sachverhalte eineindeutig zwischen Autoren und Lesern kommunizieren. Viele Architekturdokumentationen lassen die Fragen offen wie Wer ist der Leser der Architekturdokumentation? Fr 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 verndert sich die Architekturdokumentation im Laufe der Zeit? Wie vermeidet man diese und andere Missverstndnisse zwischen den Lesern/Autoren und verbessert die Kommu-
Adressaten
Die Architekturdokumentation ist das Informationsmedium zwischen allen Projektbeteiligten. Rollen im Rahmen eines Projektes haben unterschiedliche Informationsbedrfnisse. Diese spiegeln sich in der Auswahl geeigneter Sichten wieder. Beispielsweise sind die folgenden Zielgruppen an dem angefhrten Informationsaustausch interessiert.
71
Zielgruppe
Architekt und Anforderungsfachmann (reprsentiert den Kunden) Architekt und Designer Entwickler Tester und Integrierer Softwarepflege und -nderung Entwickler anderer Systeme Qualittssicherung Produktlinienverantwortlicher IT-Sicherheitsverantwortlicher
Art des Informationsaustausches

Forum fr das Verhandeln und Abwgen von konkurrierenden bzw. widersprechenden Anforderungen Auflsen und Zuordnen von nichtfunktionalen Anforderungen Festlegen der Randbedingungen und Freiheiten in der Entwicklung Festlegung des Blackbox Verhaltens Bereiche die voraussichtlich gendert/angepasst werden Operationen und Protokolle an Schnittstellen Divergenz der Implementierung Divergenz der Architektur von einer Produktlinienarchitektur Festlegen der Sicherheitsanforderungen an die Architektur und Prfung der Divergenz der Implementierung zur Planung
Tabelle 5.3-1: Zielgruppen fr Architekturdokumentationen
sollte verschiedene Dokumente referenzieren, in welchen jeweils eine Architektursicht beschrieben ist.
Detaillierungsgrad
Die Frage nach dem Detaillierungsgrad lsst sich einfach beantworten: So abstrakt wie mglich und so konkret und detailliert wie ntig fr 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 Dokumentation kann der Detaillierungsgrad variabel gehalten werden. Fr geschlossene dokumentartige Formen hat sich ein Hauptdokument, das den Kontext beschreibt, als vorteilhaft erwiesen. Der Kontext definiert Ziele, Aufgabenstellungen, Beteiligte und deren Interessen. Randbedingungen sollten angefhrt werden, seien diese technischer Art, oder organisatorischer. Ein logischer Kontext sollte das System durch seine Hauptelemente und deren Beziehung untereinander sowie die Systemgrenzen beschreiben. Ebenso sollten Prozeduren zur Architekturentwicklung und -bewertung beschrieben sein. Das Hauptdokument
Ein weiteres Architekturdokument sollte grundlegende Aspekte der Architektur in sogenannten Perspektiven festhalten. Solche Aspekte knnen sein: Sicherheit, Performanz und Skalierbarkeit , Verfgbarkeit und Ausfallsicherheit, Evolution, Zugnglichkeit und Verteilung, Regulierungen, Benutzbarkeit etc.
Syntax und Semantik

Die Detailtiefe, der Erklrungsbedarf, die Notation, und die Bedeutung einzelner Teile der Architekturdokumentation hngen 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 ausdrucksstarke Semantik, beispielsweise Prdikatenlogik, erreicht werden und andererseits durch graphische Notationen wie die Unified Modelling Language. Je hher der Informationsgehalt ist und je verstndlicher er fr den Adressaten bleibt, desto besser.
72
Fragen, die die Diagramme in der Architekturdokumentation beantworten mssen, sind: Welche Bedeutung haben die dargestellten Elemente? Welche davon sind vorhanden, zu verndern 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 knnen von einem Diagramm allein beantwortet werden. Aber die Architekturdokumentation sollte die Fragen beantworten auch noch nach Jahren.
Fr die Erstellung der Sichten hat man die Erfahrungen gemacht, dass die Auswahl der Sichten und deren Beschreibungstiefe fr einen reibungslosen Projektverlauf wichtig sind. Es ist essentiell, dabei den Adressatenkreis zu bercksichtigen. Risikobehaftete Teile der Architektur sollten eine grere Beschreibungstiefe aufweisen. Die Erstellung der Sichten ist ein iterativer und interaktiver Prozess. Erkenntnisse aus einer Sicht haben oft Einfluss auf andere Sichten. Die Verwendung von Modellierungsumgebungen, das Prfen gegen Meta-Modelle und der Austausch von Modellen bzw. das verteilte Erstellen von Modellen hat sich als vorteilhaft erwiesen. Dokumentationen sollten immer der Versionskontrolle unterliegen. Die Erstellung bzw. Generierung eines Dokuments, falls gefordert bzw. bentigt, sollte auf Basis eines Modells erfolgen.
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 Systeme, 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 Informationsflsse. Sicherheitssicht Diese Sicht beschreibt die sicherheitstechnischen Anforderungen und die Erfllung derer in den einzelnen Teilen der Architektur.
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. Fr Einschrnkungen an den entsprechenden Schnittstellen knnen 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 Engineeringprozesses. Schnittstellen zwischen internen Teilen und deren
73
Funktionalitt werden definiert. Diese Sicht beantwortet beispielsweise: wie das System in Subsysteme, Komponenten etc. aufgeteilt ist, welche Dienste der Systeme, Betriebssysteme oder Hardware bentigt werden, welche Abhngigkeiten sich ergeben. Im Rahmen der Systementwicklung knnen zur Notation dieser Sicht z.B. SysML und UML verwendet werden, je
14
verwendet werden. Entity Relationship Diagramme werden von UML Tools in der Regel schlecht bzw. gar nicht untersttzt. Um ber die gesamte Dokumentation ein einheitliches Verstndnis des Systems der verwendeten Terminologie zu haben, empfiehlt sich ein Glossar. Ein solches Glossar sollte nicht nur eine einfache Beschreibung der eingesetzten Begriffe beinhalten, sondern auch die Philosophie hinter den Begriffen erlutern. Ebenfalls sollten immer wieder auftretende Begriffe wie Auftrag oder Nutzer wirklich detailliert beschrieben werden.
nach Detaillierungsgrad der aktuellen Ansicht (System, Subsystem, Hard- oder Software). Im Idealfall werden die konzeptionellen Bausteine auf die Implementierungskomponente abgebildet, um Strukturbrche zwischen diesen Sichten zu minimieren.
Sicherheitssicht
Die bei der Planung der Architektur erarbeiteten Sicher-
Laufzeitsicht
Diese Sicht beschreibt den dynamischen Aspekt des Systems, z.B. welche Elemente zur Laufzeit existieren und wie diese zusammenwirken. Die Dokumentation dieser Sicht sollte sich an den Informationsbedrfnissen der Betreiber und Administratoren des Systems ausrichten. Zur Darstellung sollten Sequenzdiagramme, Aktivittsdiagramme, Kollaborationsdiagramme oder Verteilungsdiagramme genutzt werden.
heitsanforderungen werden in dieser Sicht den umgesetzten Manahmen gegenber gestellt und so eine Sicht auf den derzeitigen Sicherheitsstand der Architektur ermglicht. Dies kann beispielsweise in Tabellenform geschehen. Dabei wird fr jeden auftretenden Risikotyp eine Zeile angelegt. Die Spalten werden mit den Architekturteilen berschrieben. In den Zellen der Tabelle knnen so die auftretenden Risiken identifiziert und ihre Behandlung nher beschrieben werden. Wird ein Risiko nicht behandelt, so muss ein entsprechender Grund dafr angegeben werden. Dabei sind die Nachvollziehbarkeit und die Angabe des entsprechenden Restrisikos von groer Wichtigkeit. Aus dieser Sicht kann somit der aktuelle Stand der Sicherheitsmanahmen abgeleitet und eine entsprechende Risikoanalyse zur Bewertung der Risiken im Gesamtkontext des Einsatzszenarios durchgefhrt werden.
Datensicht
Die Datensicht beschreibt die Struktur von Datenelementen und ihre Beziehung zu anderen Bestandteilen der Architektur. Dabei knnen folgende Aspekte interessant sein: welche Daten wo bentigt oder bearbeitet werden, wo Daten gespeichert oder bearbeitet werden, wie Daten transportiert werden.
Evolution der Architekturdokumentation

Diese Sicht entspricht der NOV-7 und wird durch die NSV11 verfeinert. Das NSV-11b entspricht dann den Objekten im System bzw. deren Entsprechung in den Datenbanken. Als Darstellungsform knnen UML15-Klassendiagramme Im Rahmen der Projektdefinition sollte ein Auftraggeber seine Sicht des Systems in den NAF Sichten NOV-1 bis NOV-7 dargelegt haben. Der Auftragnehmer hat
14. Fr Schnittstellen zwischen Softwarekomponenten eignet sich im weiteren Verlauf z.B. CORBA IDL, auch wenn CORBA nicht als Middleware zum Einsatz kommt.
74
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 bentigt wird. Diese Informationen sollten in einem Modell abgelegt werden, um dann in der weiteren Verfeinerung und/oder Entwicklung in Ansichten und Modellelemente fr das Systemengineering berfhrt bzw. weiterentwickelt zu werden. Die folgende Grafik soll das veranschaulichen:
bewerten, um daraus zu lernen. Aus diesen Bewertungen knnen Empfehlungen entwickelt werden, um in hnlichen Situationen schneller und fundierter entscheiden zu knnen.
5.4 Architektur-Publikation 5.4.1 Verffentlichen von Architekturergebnissen

Die Verffentlichung von Architekturergebnissen ist ein wesentlicher Aspekt der Nutzung der Architektur und soll zur Mehrfachnutzung der Architektur beitragen. Die Publikation ist zugleich ein Beitrag zum Akzeptanzmanagement.
NAF Modell NOV
Kunde NTV Auftragnehmer
NSV
System Engineering Modell Auftragnehmer
Stndige Aktualisierung, Ergnzung und Vervollstndigung der Inhalte und der Nutzungseigenschaften von Architekturen sind ein wesentliches Merkmal lebender bzw. gelebter Architekturen.
Abbildung 5.3-2: Weiterentwicklung der NAF Sichten
Im Bereich der Bundeswehr und der wehrtechnischen Industrie sind bisher Architekturen eher vorhabens-, Im System Engineering Modell erfolgt dann die weitere Ausarbeitung des Systems, welche nicht nur ein Schritt in der Realisierung eines Systems oder der Durchfhrung eines Projektes ist. Die Erstellung der Architekturdokumentation ist vielmehr ein iterativer Prozess, der im Systemdesign beginnt, in der Entwicklung fortgefhrt wird. Die Architekturdokumentation sollte den Soll-Zustand des Systems beschreiben und als Vorgabe bzw. Leitlinie fr Projektbeteiligte dienen. Die Architekturdokumentation sollte auch den Ist-Zustand des Systems festhalten, d.h. die Architekturdokumentation sollte konsistent mit der Realisierung sein. Eine Architekturdokumentation, die Vernderung, Beweggrnde und Alternativen beinhaltet ist nachvollziehbar. Des Weiteren bietet eine solche Architekturdokumentation Mglichkeiten zur Diskussion, Lsungsfindung und zur Retrospektive. Nur so lassen sich Entscheidungen projekt- und bereichsbezogen verwaltet und verffentlicht worden. Hier knnen durch Festlegungen zur Verffentlichung und deren technische Untersttzung zustzliche Nutzeffekte erzielt werden. Beispiele erfolgreicher Publikationen in groen Unternehmen knnen dabei als Anregung genutzt werden. Erfolgreiches Architekturmanagement in groen Unternehmen bzw. Organisationen wird durch die Art und Weise der Verffentlichung nachhaltig untersttzt. Typischerweise sollte dabei folgendes sichergestellt werden: Zielgruppen-, ebenen- und rollengerechte Verffentlichung, Beachtung von Sicherheits- und Geheimschutzaspekten, Beachtung des Urheberrechts, Feedback-Mglichkeiten zur Initiierung von nderungen,
75
Etablierung eines Entwicklungskreislaufes der Architekturentwicklung - Release-Cycle-Management, Verwaltung und Verffentlichung von Arbeitsversionen, QS-gesicherten Freigabeversionen und Archivstnden, weitestgehender Onlinezugang (Intranet, Extranet, Internet) mit der Mglichkeit zu Offline-Nutzung, Mglichkeiten des Exports oder anderer Ausgaben zur Untersttzung der Weiternutzung.
5.4.2 Schulungen von Architekturergebnissen

Die Vermittlung von Wissen zu Architekturergebnissen ist neben der Verffentlichung 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-
Ein in der Praxis bewhrtes Rollenmodell unterscheidet beispielweise zwischen folgenden Rollen im IT-Architekturmanagement und leitet daraus auch spezifische Sichten und Rechte fr die Rolleninhaber ab: IT-Bebauungsplaner, IT-Architekten, IT-Architektur-Management, IT-Sicherheitsverantwortliche, Administratoren, System Owner, Systementwickler/-anwender, Leser = Fachabteilungen/Verantwortliche.
dell in Kap 5.4.1) anzubieten und aufzubereiten. Die Schulungen knnen als Online-Tutorial (WebEx, Webcast, eLearning-Kurs) bzw. ergnzend als Prsenzveranstaltung durch/mit den Architekturentwicklern entwickelt und angeboten werden. Die Schulung von Architekturergebnissen setzt entweder auf vorhandene Kenntnisse zum Architekturframework, dem eingesetzten Modellierungstool und dem Anwendungsgebiet auf oder vermittelt diese ergnzend in Schulungsverlauf.
76
6 Architektur-Management
Die Planung und Entwicklung von heutigen IT- und Kommunikationssystemen, militrischen Plattformen und Systemkonstellationen, insbesondere mit dem Ziel eine Vernetzte Operationsfhrung auch im Rahmen multinationaler Einstze zu realisieren, ist geprgt von hoher Komplexitt. Es erfordert das Management von enormen Datenmengen, seinen Abhngigkeiten und Beziehungen, 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 umfassenden Ansatz zur Bercksichtigung aller Planungsdaten und ihrer Abhngigkeiten. Im vorliegenden Leitfaden werden Die Verteidigungsministerien verschiedener Lnder als auch die Institutionen der NATO und der EU wenden heutzutage die Architekturmethode basierend auf unterschiedlichen Architekturrahmenwerken (Department of Defence Architecture Framework (DODAF), Ministry of Defence Architecture Framework (MODAF) oder dem NATO Architecture Framework (NAF)) an, um ihre Command, Control and Consultation (C3) Ausstattungen zu planen und zu entwickeln (s. hierzu z.B. auch Kapitel 3.4). Zahlreiche militrische Projekte wurden bis heute bereits erfolgreich unter Nutzung der Architekturmethode realisiert. Dabei wurden und werden die Architekturen inzwischen fr ganz unterschiedliche Zwecke entwickelt, z.B. fr die Planung von EU Battlegroups oder die Analyse und Planung der maritimen Aufklrungslage, um nur zwei Beispiele zu nennen. Auf Grund des erfolgreichen Einsatzes der Architekturmethode werden viele zuknftige Projekte dieser Methodik folgen. Der Architekturerstellungsprozess ist komplex und Der Architekturentwicklungsprozess beginnt im Allgemeinen mit einer genauen Definition von Zweck, Geltungsbereich, Grenzen und Abhngigkeiten, um ein zielgerichtetes Architekturmodell zu erzeugen. Zudem sind Modelle beraus umfangreich und bestehen blicherweise aus einigen zehntausend Entitten, die wiederum in unterschiedlichen Sichten (Views) verwendet werden. Daraus erfordert die Bewltigung einer Vielzahl ganz unterschiedlicher Aufgaben, die durch verschiedene Rollen und Organisationen wahrgenommen werden mssen. Die klare Definition und verantwortliche bernahme der jeweiligen Rollen ist die Voraussetzung fr die erfolgreiche Entwicklung einer Architektur. Grundlagen, das Anforderungs-, Konfigurations-, Qualitts-, nderungs- und Sicherheitsmanagement, das im Rahmen der Entwicklung und Verwendung zwingend notwendig ist, erlutert und Empfehlungen abgegeben, wie diese Managementaufgaben geplant und implementiert werden knnen. Der komplexe Entwicklungsprozess, als auch die nachfolgenden Aktivitten zur Nutzung der Architektur erfordern, wie oben angedeutet, sowohl in der Erstellungsphase als auch nach der Fertigstellung des ersten Grundstatus einer Architektur ein sachkundiges Architekturmanagement. resultiert, dass der initiale Entwicklungsprozess, bis zu einem ersten Basisstatus (Baseline) hufig sehr zeitintensiv ist. Konsequenterweise ist das endgltige Modell in einer Weise zu planen, dass die Architektur langfristig fr verschiedene Anwendungsgebiete und Nutzer geeignet ist.
6.1 Management Grundlagen 6.1.1 Festlegen der Rollen und Organisation
77
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 Bevollmchtigten (BV) der Organisationsbereiche (OrgBer), die Rolle des Moderator/Methodenspezialist sowie die Rolle des Modellierers definiert. Im Folgenden werden die erforderlichen Rollen und Organisationen fr die Architekturentwicklung und das Architekturmanagement definiert, erlutert und an den Definitionen der Bw Rahmenregelung gespiegelt, u.a.: Architektur Management Board Das Architektur Management Board bildet sich aus Entscheidungstrgern 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 Steuerung von Architekturentwicklungen. Chef-Architekt Der Chef-Architekt ist vergleichbar mit dem Projektleiter gem. V-Modell XT sowohl auf Auftragnehmer als auch auf Auftraggeberseite. Er hat die Aufgabe das Architekturmanagement durchzufhren und trgt dem Architektur Management Board vor. Architekt Der Architekt ist der Modellierer und Methodenspezialist 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 fr die Anforderungsanalytiker gibt. Analyst Der Analyst ist der Wissenstrger und gleichzeitig ein spezifischer Anwender der Architektur Konfigurationsmanager Entspricht dem Konfigurationsmanager gem. V-Modell XT fr die Modelle der Architektur Qualittsmanager Entspricht dem Qualittsmanager gem. V-Modell XT fr 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 Organisationen zugeordnet, u.a.:
Aktivitt
Initialisieren eines Architekturprojektes Entwickeln/Modellieren einer Architektur Anwenden der Architektur Bewerten und Freigeben der Architektur Publizieren/Vermarkten der Architektur Durchfhren des Anforderungsmanagements Durchfhren des Konfigurationsmanagements Durchfhren des Qualittsmanagements Durchfhren des nderungsmanagements Durchfhren des Sicherheitsmanagements
Tabelle 6.1-1: Aufgabenzuordnung
Rollen
Architektur Management Board, Entscheidungstrger Architekt, Analyst, Wissenstrger Analyst, Anwender Chef-Architekt Architektur Management Board Chef-Architekt Konfigurationsmanager Qualittsmanager Architektur Management Board IT-Sicherheitsverantwortlicher
Beschreibung
Siehe Kapitel 5.1 Siehe Kapitel 5.2 Siehe Kapitel 5.3.1 Siehe Kapitel 5.3.2 Siehe Kapitel 5.4 Siehe Kapitel 6.2 Siehe Kapitel 6.3 Siehe Kapitel 6.4 Siehe Kapitel 6.5 Siehe Kapitel 6.6
78
6.1.3 Festlegen von Verfahren zur Zusammenarbeit

Die Entwicklung einer Architektur impliziert die Beteiligung zahlreicher Stakeholder und erfordert die Bearbeitung durch bzw. Beitrge von Fachspezialisten in den jeweiligen Architekturprodukten der Operationellen Sicht, der System Sicht, der Service Orientierten Sicht, der Technischen Sicht und weiterer Sichten. Das Zusammenwirken der unterschiedlichen Fachspezialisten mit dem Architekturentwicklungsteam ist aber nur ein Aspekt der in diesem Kapitel erlutert wird. Darber hinaus werden die Zusammenarbeit innerhalb eines Architekturentwicklungsteams, insbesondere die Erstellung einer Architektur durch Architekturteams mehrerer Firmen sowie die Zusammenarbeit zwischen Auftraggeber (AG) und Auftragnehmer (AN) reflektiert.
Architekturentwicklungsprozesses werden zudem weitere Anforderungen identifiziert. Im Verlauf eines Projektes entsteht auf diese Art und Weise eine sehr groe Anzahl an Anforderungen, die verwaltet werden mssen. Hierbei ist eine bidirektionale Verknpfung von modellierten Entitten (Anforderungen in graphischer Darstellung) in der Architektur und den textuellen Anforderungen in einem Anforderungsmanagement-Tool unerlsslich, damit Inkonsistenzen vermieden werden. Zudem knnen bereits identifizierte Anforderungen aus der Architektur, die in ein Anforderungsmanagementwerkzeug berfhrt wurden, in diesem weiter detailliert werden. Die industrielle Praxis zeigt, dass dieser Prozess am besten gemanagt werden kann unter Anwendung von Applikationen der Informationstechnologie. Eine breite Palette von Tools ist bereits heute verfgbar und Schnittstellen zwischen Architekturentwicklung und Anforderungsmanagement, 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 Abhngigkeiten zuerst innerhalb der Anforderungsdatenbank und darber hinaus in der Architekturdatenbank zu verfolgen. Das folgende Beispiel zeigt die Wertschpfung, die durch die Anwendung eines umfassenden Prozesses erzielt werden kann: Ein militrisches Konzept fordert: Jeder Soldat sollte in der Lage sein, Meldungen an die nchst hhere Kommandoebene zu senden. Diese Feststellung ist sehr allgemein und gibt viele Freiheitsgrade, um die Anforderung zu realisieren. Innerhalb des Planungsprozesses (Architekturentwicklung) mssen die folgenden Entitten jedoch bercksichtigt werden: Soldat, Meldung (Typ der Information), bertragungsmittel (Funk, PDA etc.), hhere Kommandoebene (z.B. Task Force HQ),
6.2 ArchitekturAnforderungsmanagement
Wie bereits in vorangegangenen Kapiteln ausfhrlich erlutert, 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 fr neue Systeme, den Informationsaustausch, neue Fhigkeiten, die Weiterentwicklung einer Organisation oder dergleichen beabsichtigt. Diese Anforderungen knnen allgemein gesprochen operationeller, systemtechnischer, technischer, nicht-funktionaler oder organisatorischer Natur sein. Projekten liegt daher hufig eine umfangreiche Liste von diversen Anforderungen bzgl. Systemen, Informationsaustausch, Interoperabilitt oder Fhigkeiten in Form von Konzepten, Richtlinien, ersten Planungen, Lessons Learnt usw. vor. Diese Anforderungen werden zunchst extrahiert und durch die Modellierung in Form von Diagrammen, Tabellen und Listen in der Architektur dokumentiert. Im Rahmen der strukturierten Analyse whrend des
79
Im Zuge der Abwgung von Optionen und Lsungen, wie die Anforderung technisch realisiert wird, treten gegebenenfalls folgende weitere Anforderungen auf: Das Tool muss mindestens eine Verschlsselung bis geheim gewhrleisten. Das Kommunikationsinterface muss den militrischen Standard ADatP XYZ untersttzen. Solche zustzlichen Anforderungen mssen im Anforderungsmanagementwerkzeug erfasst werden. Jede Anforderung ist dabei sinnvollerweise mit ihrer relevanten Entitt im Architekturmodell verknpft und umgekehrt. Diese Methode gewhrleistet den Erhalt von Konsistenz, Vollstndigkeit und belastbaren Ergebnissen fr die Planung, Realisierung und Anpassung von komplexen Systemen/Systemlandschaften.
Dieser Prozess hat folgende Aspekte abzudecken: Steuerung von nderungen und deren Dokumentation, Versionskontrolle (Master Datenbank, Arbeits-Datenbanken), Mittel zur Identifikation der Architektur Entitt, Modellierungswerkzeug Konfiguration (Eigenschaften, Rahmenbedingungen), Erzeugung und Gebrauch der Masterdatenbasis/ Ablage/Glossar, Dateiformate (z.B. MDF, BAK, XML Export & Files), Erzeugung von Baselines, Tooluntersttzung und Gebrauch, Erfassung und Verwaltung der Architekturergebnisse, Verfgbarmachen der Architekturen, Administrierung der Gesamtglossars. Der Konfigurationsmanagementprozess hat nicht nur den
Eine Wertschpfung wird durch die Anwendung von IT-Tools erreicht, indem gewhrleistet wird, dass Anforderungen in einer berschaubaren Weise identifiziert, verfolgt und priorisiert werden knnen, insbesondere bei groen Projekten. Abhngigkeiten von Architekturentitten und Anforderungen werden automatisch identifiziert und Toolfunktionen erlauben die ausfhrliche Traceability, wie Risikoanalyse, Simulationsfhigkeit, Reifetests.
Entwicklungsprozess einzubeziehen, sondern auch den Lebenszyklusprozess nach dem Release der ersten Baseline, weiterer folgender Nachtrge und Modifikationen des Architektur-Repositories.
6.4 Architektur-Qualittsmanagement
Die zielgerichtete Entwicklung, Pflege und Anpassung von Architekturen kann in qualitativ unterschiedlichen Ausprgungen erfolgen. Werden die unterschiedlichen Aktivitten im Bereich der Architektur-Entscheidungen als Prozesskette aufgefasst, so entscheidet die Ergebnisqualitt einer Aktivitt die Eingangsqualitt und gleichzeitig Endqualitt der Folgeaktivitt. Die Gesamtqualitt der Architekturentwicklung kann damit nicht besser sein, als die schlechteste Qualitt aller Zwischenergebnisse. Damit kommt der Sicherstellung der Architekturqualitt, im Folgenden als Architektur-Qualittsmanagement bezeichnet, eine besondere und vor allen Dingen mglichst frh zu startende und kontinuierliche Rolle zu: Formative Definition von Charakteristika, die mglichst frh in dieser Prozesskette einer hohen Qualitt der Architektur dienlich sind. Hier ist insbesondere darauf
6.3 ArchitekturKonfigurationsmanagement
Die Architekturentwicklung erfordert zwingend die Anwendung des Konfigurationsmanagements. Der Modellierungsprozess impliziert, dass sich Architekturmodelle ausgehend von einzelnen Entitten entwickeln und zu Datenbasen von zehntausenden von Entitten, Diagrammen, Modellen, Tabellen und Berichten anwachsen. In Folge dessen muss jede entwickelte Version des Architekturmodells, Diagramme oder Matrizen eindeutig identifizierbar sein. Deshalb muss das Architekturmanagement einen Architekturkonfigurationsprozess planen, festlegen und einrichten, der klare Rollen und deren Verantwortlichkeiten definiert.
80
zu achten, dass diese Anforderungen ganzheitlich und prfbar sind. Summatives Vorgehen zur Prfung, inwieweit gewnschte Anforderungen an die Architektur eingehalten worden sind. Auch diese summativen Vorgehen sind in der Prozesskette mglichst frhzeitig anwendbar, sind aber jeweils einer formativen Definition nachgelagert. Um diese beiden Aufgaben mglichst detailliert zu beschreiben, wird im folgenden Qualitt als grundlegendes Konzept erlutert, um darauf aufbauend jeweils separat die formativen als auch summativen Schritte vorzustellen.
Qualitt 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 Minimalitt resultiert aus der grundstzlichen Wirtschaftlichkeitsbetrachtung von Software-Projekten, die berflssige Funktionalitt ausschliet, da hierdurch Kosten ohne Nutzen erzeugt wird. Im Folgenden soll dieses Modell von Qualitt fr eine Przisierung des Architektur-Qualittsmanagements verwendet werden, indem die Architektur-Betrachtungseinheiten, die Erfordernisse sowie die damit notwendigen QS-Aktivitten erlutert werden.
6.4.1 Qualitt von Architekturen

Grundlage der Beschftigung mit der Qualitt von Architekturen ist ein przises Verstndnis von Qualitt. Die visuelle Modellierung dieser Definition hilft dabei, die Anforderungen an ein ganzheitliches Qualittsmanagement von Architekturen abzuleiten:
Architektur-Betrachtungseinheiten
Das Qualittsmanagement von Architekturen adressiert die Betrachtungseinheit Architektur. Fr die Ermittlung der Anforderungen fr ein effektives Qualittsmanagement ist das Kriterium wichtig, nach dem ein System in Komponenten und deren Abhngigkeiten zerfllt
Betrachtungseinheit
Qualit
Erfordernisse
M1 M2 M3 M4 M5 Mn ...
Erf.1
Erf.2
Erf.3
Abbildung 6.4-1: Qualitt von Architekturen
81
(s. Architekturdefinition im Glossar) und die Synchronisierung der mglichen unterschiedlichen Sichten auf ein System. Die Vielschichtigkeit dieser Kriterien fhrt dazu, dass es unterschiedliche Architekturen gibt. Hufig verwendete Architekturen, die jeweils einzeln, zusammen mit dem System oder im gesamten Architekturverbund fr das Qualittsmanagement zu betrachten sind, sind: Funktionale Architektur. Diese besteht aus der Dekomposition der System-Software in ihre funktionalen Bestandteile. Typische Komponenten einer solchen 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 Komponenten einer solchen prozessorientierten Architektur sind Dateneingabe, Datenverarbeitung, Datenausgabe. Hardware-Architektur: Diese besteht aus der Dekomposition der System-Hardware bzgl. der zur Entwicklung und/oder Betrieb notwendigen HardwareInfrastruktur. Typische Komponenten einer solchen Hardware-Architektur sind Load-Balancer, Netzwerkkabel und Server-Clouds. Sicherheits-Architektur: Diese besteht aus der Dekomposition der Hard- und Software bzgl. ihrer sicherheitsrelevanten Komponenten und Fhigkeiten. Typische Komponenten einer solchen Sicherheitsarchitektur sind Firewalls, Verschlsselungsroutinen und Spam-Filter. Softwaretechnische Architektur: Diese besteht aus der Dekomposition der System-Software in ihre softwaretechnischen Teile. Typische Komponenten einer solchen funktionalen Architektur sind spezifische Libraries, Frameworks oder auch systemspezifische Schichtenarchitekturen.
Das Architektur-Qualittsmanagement hat entsprechend diesem Architekturverstndnis die folgenden Betrachtungsgegenstnde zu bearbeiten, in denen die einzelne Architektur jeweils unterschiedlich kontextsensitiv betrachtet wird: Die Architektur an und fr sich. Jede Architektur muss unabhngig des verwendeten Kriteriums und des Zusammenhangs zum System bestimmte Anforderungen erfllen, um berhaupt einen Wert darzustellen. Eine Architektur und ihr Zusammenspiel mit dem System entlang des gewhlten Kriteriums. Mehrere Architekturen und ihre Synchronisierbarkeit sowie der Grad der Untersttzung spezifischer Geschftsstrategien damit.
Erfordernisse an Architekturen
Erfordernisse werden in der Regel von Nutzern formuliert. Auf Grund der Vielschichtigkeit von Architekturen ist fr das Architektur-Qualittsmanagement eine Vielzahl von Schlsselpersonen eines Projektes relevant. Typische Bedarfstrger von Architekturen sind (s. hierzu auch die unterschiedlichen Rollen im Architekturkontext unter 6.1.2 oben): Endanwender: Fr diesen besonders relevant ist die funktionale Architektur (in jeweils allen drei Architektur-Kontexten), da diese blicherweise auch die Usability mitbestimmt. So befinden sich Formatierungsanweisungen von Textverarbeitungssystemen zusammenhngend in einer Formatierungskomponente, wohingegen die grafischen Mglichkeiten hufig in einer Grafikkomponente zusammenhngend angeboten werden. Betrieb: Fr diesen besonders relevant ist die Hardware-Architektur (in jeweils allen drei ArchitekturKontexten), da sich hieraus Herausforderungen und Probleme fr den Betrieb ableiten lassen. Typische Fragestellungen des was passiert, wenn diese
82
Hardware-Komponente im Betrieb ausfllt, mssen vom Betrieb selbst beantwortet werden, so dass die Anforderungen vom Betrieb u.a. Transparenz, Redundanz und Wiederherstellbarkeit sind. Tester: Fr diesen ist ebenso wie fr den Betrieb hufig die Hardware-Architektur besonders interessant (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 fr die Testdatenbereitstellung aufweist. Nur so kann sichergestellt werden, dass Testen und Betrieb losgelst voneinander stattfinden knnen und der Test maximal offensiv und effizient durchgefhrt werden kann. Jede dieser Rollen hat entlang der Qualittsdefinition spezifische Anforderungen an spezifische Architektur-Betrachtungseinheiten in allen drei Architektur-Kontexten.
Verstndlichkeit und Konsistenz der verwendeten Notation (bestenfalls der Verweis auf einen etablierten Standard wie UML). Wartbarkeit der Architekturdokumentation, d.h. die Mglichkeit, nderungen an ihr vorzunehmen und sie werkzeugbasiert weiterzuverwenden. Portierbarkeit der Architekturdokumentation, d.h. die Mglichkeit, die Architekturbeschreibung mit unterschiedlichen Werkzeugen anschauen und weiterentwickeln zu knnen. Bis auf die beiden Anforderungen Effizienz und Zuverlssigkeit sind alle typischen Anforderungen an Produktqualitt, wie sie in der ISO 9126, heutige ISO25000 hinterlegt sind, unabhngig des Projektkontextes anzuwenden. Ein Beispielrisiko ist eine semi-formale Architekturbeschreibung mit unklarer Legende in Paint. Semantische Architektur-QS: Diese Aktivitten adressieren eine einzelne Architektur und ihr Zusammenspiel mit dem realen System entlang des Kriteriums. Wesentliche Anforderungen, die sich auf dieser Ebene der Qualittssicherung ergeben sind: Korrektheit der Architekturbeschreibung: Stimmt die Architekturexplizierung mit dem realen System berein, d.h. existiert entlang des Dekompositionskriteriums fr jedes Objekt der Architektur ein entsprechendes Objekt im realen System und umgekehrt? Wert der Architektur: Hilft die konkrete Architektur, die Geschftsstrategie, die mit dem System und der dahinterliegenden konkreten Architektur verbunden werden, zu erfllen bzw. strategierelevante Fragen zu beantworten? Ein Beispielrisiko der semantischen Architektur ist eine objekt-orientierte Modellierung der Geschftslogik (z.B. mittels Klassendiagrammen) und eine funktionale, nicht-objektorientierte Implementierung. Strategische Architektur-QS: Diese Aktivitten adressieren die gesamtheitliche und damit kontextsensitivste Sicht auf die Gesamtarchitektur, bestehend aus einer Vielzahl explizit gemachter Teilarchitekturen,
QS-Aktivitten fr Architekturen
Die Vielschichtigkeit von Architektur entlang der drei aufgezeigten Architektur-Kontexte, der Architekturen bildenden Kriterien sowie der involvierten Bedarfstrger gilt es beim Architektur-Qualittsmanagement entsprechend mit QS-Aktivitten zu bercksichtigen. Dies fhrt bei den unterschiedlichen Architekturkontexten zu einer mglichen Klassifizierung der Architektur-QS-Aktivitten eines Architektur-Qualittsmanagements. Syntaktische Architektur-QS: Diese Aktivitten adressieren den kleinsten Architekturkontext, nmlich die einzelne Dekomposition und ihre explizite Darstellung, unabhngig 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
83
den jeweiligen Kriterien und dem System selbst. Eine wesentliche Anforderung dieser QS besteht darin, dass die unterschiedlichen Architekturen aufeinander abbildbar sind und die so entstehende Kombination die Gesamt-Geschftsstrategie untersttzt. Ein Beispielsrisiko dieser Sicht ist eine auf maximale Redundanz ausgelegte Software-Architektur sowie eine monolithische Hardware-Architektur: Hier lsst sich die Software-Architektur nur schwierig auf die Hardware-Architektur abbilden (indem nmlich jede Komponente der SW-Architektur auf die eine Komponente der Hardware-Architektur abgebildet wird). Die beiden folgenden Kapitel mssen fr jede dieser QS-Aktivitten, die jeweils spezifische Erfordernisse fr spezifische Architekturen adressieren, separat durchgearbeitet werden. Es gehrt zu den grten Herausforderungen fr das Architektur-Qualittsmanagement, diese Ganzheitlichkeit fortwhrend zu bercksichtigen und die unterschiedlichen, teilweise konkurrierenden Aktivitten projektspezifisch optimal zu synchronisieren und auszutarieren. Das Architektur-Qualittsmanagement hat fortwhrend sicherzustellen, dass syntaktische QS fr alle relevanten Architekturen separat entlang den Anforderungen aller Schlsselpersonen durchgefhrt wird. semantische QS fr alle relevanten Architekturen separat entlang den Anforderungen aller Schlsselpersonen durchgefhrt wird. strategische QS fr alle relevanten Architektur-Mengen entlang den Anforderungen aller Schlsselpersonen durchgefhrt wird. Die grundstzlichen Mittel dafr werden im Folgenden aufgefhrt und knnen fr alle drei Architektur-QS-Ebenen gleichermaen angewendet werden.
Best-Practice an diese Architektur-Vorgaben, damit diese nicht nur als Papierware existieren, sondern tatschliche formative Kraft auf die Projektdurchfhrung besitzen, ist die Anwendung des S.M.A.R.T.E.R.-Konzepts. Dies bedeutet fr alle Vorgaben die folgenden Charakteristika: Specific: Jede Vorgabe, die sich aus der ganzheitlichen Betrachtung von Architektur-Qualitt ergibt, sollte bestmglich soweit operationalisiert werden, dass sie mglichst feingranular spezifiziert ist: Hierbei ist hufig das Konzept Divide et impera anzuwenden, d.h. durch schrittweise Verfeinerung (hufig 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 fr die anschlieende Weitervergabe machen. Measurable: Eng verbunden mit der Spezifitt ist die Anforderung nach Messbarkeit: Die Messbarkeit bedeutet in diesem Kontext die messtheoretisch konforme Anwendung von Abbildungen aus Modellen der realen Welt auf quantitative Gren. Eine etwaige im Kontext der semantischen Architektur QS spezifisch formulierte Vorgabe, die Kommunikation mit der Business-Logik drfe nur ber einen Verschlsselungsalgorithmus erfolgen, lsst sich durch Zhlen derjenigen Kommunikationskanle, die sich an diese Vorgabe halten und das Zhlen solcher Kommunikationskanle, die unverschlsselt mit der Business-Logik kommunizieren, messbar und damit fr das Architekturmanagement steuerbar machen. Eine Vielzahl hochwertiger Konstrukte lsst sich allerdings nicht so direkt messen. So lsst sich z.B. die Zukunftsfhigkeit einer Softwarearchitektur im Kontext der semantischen Architektur-QS nicht direkt messen, solange keine spezifischeren Vorgaben (s. vorheriger Schritt: Specific) existieren. Ein hufiges Hilfsmittel fr die Mebarmachung schwieriger Konstrukte ist die Verwendung von Indikatoren, die Indikationen fr die positive Einhaltung oder negative Verletzung von Konventionen liefern. Dieses Konzept ist in der folgenden Abbildung dargestellt:
6.4.2 Formatives Qualittsmanagement

Ein wesentliches Mittel des formativen Qualittsmanagements fr Architekturen sind Vorgaben, die whrend des gesamten Projektes und aller darin enthaltenen Aktivitten (s.o.) bercksichtigt werden sollen. Eine wesentliche
84
Vorgabe 1 Indikator 1 Vorgabe 2 Indikator 2 Vorgabe 3
Metrik 1
es um die Zukunftsfhigkeit geht (z.B. als Indikator); allerdings muss eine derartige Vorgabe auch die dafr notwendigen Aufwnde und Ressourcen in einem Projekt bercksichtigen. Sind diese nicht beschaffbar bzw. nicht realistisch, so ist die Schrfe der Vorgabe entsprechend zu reduzieren (z.B. nur die Klassen, die fr die Business-Logik relevant sind). Erreichbarkeit
Metrik 2
Metrik 3
muss neben menschlichen Ressourcen auch Zeit, Netzanbindung, Hardware-Performance, SoftwareLizenzen u.. bercksichtigen.
Abbildung 6.4-4: Indikatorenzuordnung
Terminated: Auch wenn Vorgaben per se kontinuierlich auf alle Prozessschritte wirken, muss eine Terminierungsbedingung formuliert werden, ab wann
Die Zukunftsfhigkeit einer Architektur z.B. lsst sich nur schwer messen. Allerdings existiert eine Vielzahl von mglichen Indikatoren, die Indizien auf eine schlechte Architektur bzgl. Zukunftsfhigkeit liefern. So ist z.B. die Messung der Aufrufe von Windows-spezifischen APIs ein guter Indikator dafr, dass sehr stark proprietre Schnittstellen verwendet werden, die eine geringe Zukunftsfhigkeit besitzen. Auch das komplette Fehlen von notwendigen Dokumenten einer Software-Lieferung lsst sich zhlen und als Indikator fr eine schlechte Zukunftsfhigkeit deuten. Achievable: Gerade Vorgaben aus dem Architekturbereich mssen die grundstzliche Erreichbarkeit bercksichtigen. Da Architekturvorgaben leider hufig sehr allgemein gehalten sind und die notwendige Spezifitt vermissen lassen, fllt hufig die NichtErreichbarkeit der Vorgaben nicht auf. Die notwendige Operationalisierung zum Identifizieren mglichst spezifischer Vorgaben hilft dabei, die Erreichbarkeit des bergeordneten Ziels zu berprfen. Da architektonische Vorgaben auf formativer Ebene hufig stark visionren Charakter haben, helfen bei Unklarheiten insbesondere Machbarkeitsstudien, die Erreichbarkeit des Ziels grundstzlich zu berprfen. Realistic: Auch wenn Vorgaben primr das Was adressieren, das es zu erreichen gilt, mssen Vorgaben ebenfalls die operative Umsetzung prjudizieren. So ist die Vorgabe, jede objektorientierte Klasse eines Systems msse in einem Architekturdiagramm reprsentiert sein, sicherlich empfehlenswert, wenn
die Vorgabe als erfllt bzw. nicht erfllt einzustufen ist. Im Testbereich wird dies hufig als sogenanntes Testende-Kriterium bezeichnet. Die Terminierungsbedingung macht hierbei intensiv Gebrauch von der Messbarkeit, in dem hier spezifische Grenzwerte und Toleranzen formuliert werden. Terminierbare Vorgaben knnen in diesem Kontext als Quality-Gate betrachtet werden. Ethical: Da die architektonischen Vorgaben die grundstzliche Richtung bzgl. eines Aspektes (z.B. Security oder Usability) fr ein Projekt adressieren, mssen hier auch ethische Vorgaben als bergeordnete Magaben bercksichtigt werden. Hierzu zhlen grundstzliche Aspekte des Menschenrechts, militrische Konventionen wie die Genfer-Konventionen sowie arbeitsrechtliche Konventionen wie z.B. der Datenschutz. All diese Vorgaben mssen kompatibel zu den projektspezifischen Vorgaben des Architekturmanagements sein. Recorded: Smtliche Architekturvorgaben mssen explizit dokumentiert und kommuniziert sein. Nur bekannte Vorgaben knnen auch explizit und vor allen Dingen systematisch eingehalten werden (und dann auch entsprechend geprft werden). Auch die berprfung von Vorgaben (s. summatives Qualittsmanagement) muss entsprechend dokumentiert werden, um bei aufgedeckten Abweichungen Gegenmanahmen systematisch identifizieren und deren Erfolg nachhalten zu knnen.
85
Die Aufgabe des formativen Qualittsmanagements ist es, Architekturvorgaben ganzheitlich bzgl. relevanter Anforderungen so zu formulieren (und zu dokumentieren, vgl. R oben), dass sie dem S.M.A.R.T.E.R.-Konzept gengen. In der folgenden Tabelle ist dies fr die drei unterschiedlichen QS-Aktivitten noch einmal beispielhaft aufgefhrt:
ArchitekturQS-Bereich
Syntaktische Architektur-QS
Formative Beispielanforderungen entlang des S.M.A.R.T.E.R-Konzeptes

Vorgabe der Notation Vorgabe der Tools und Austauschformate Liste der zu liefernden expliziten Architekturen und der anzuwendenden Kriterien Vorgabe fr typische Darstellungsdetails wie Mindest-Fontgre, mgliche Farbvielfalt, etc.). Medium fr Architekturbergabe (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 berfhrt werden. Vorgabe von Mepunkten, wie die Kongruenz zwischen Architektur und System gemessen und bewertet wird. Vorgabe von spezifischen Zielen, fr die eine Architektur ausgelegt sein soll. Vorgabe von Nachweisen, wie Angemessenheit einer Architektur belegt werden kann (siehe hierzu auch weiter unten). Vorgabe von strategischen Zielen, die fr alle Architekturen und ihr Zusammenspiel verbindlich gelten. Vorgabe von Mepunkten, wie die Synchronisationsfhigkeit der Architekturen gemessen und bewertet wird. Vorgabe, anhand welcher Architekturen die Einhaltung der strategischen Ziele belegt werden kann.
Strategische Architektur-QS
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 whrend aller Prozessschritte kontinuierlich bercksichtigt und eingehalten werden. Formatives Architekturqualittsmanagement ist in diesem Sinn maximal konstruktiv.
der Vorgaben in einer Architektur oder einem Architekturentwurf zu prfen (auf jeweils allen drei aufgezeigten Architekturkontexten). Grundstzlich gibt es zwei verschiedene Arten, dies zu tun: Verifizierende Verfahren: Die summative, d.h. ex post betriebene Besttigung im Nachhinein, ob vorhandene Ablufe die gewnschten Ergebnisse erzielen. Umgangssprachlich beantworten die verifizierenden Verfahren die Frage: Wird das System richtig entsprechend der Vorgaben gebaut?. Validierende Verfahren: Im Gegensatz zu verifizierenden Verfahren wird im Bereich der Softwarequalittssicherung unter Validierung die Prfung der Eignung
6.4.3 Summatives Qualittsmanagement

Aufgabe des summativen Qualittsmanagements ist es, nach Abschluss einer Aktivitt die qualitative Ausprgung
86
beziehungsweise der Wert eines Systems bezogen auf seinen Einsatzzweck verstanden. Umgangssprachlich beantworten die validierenden Verfahren also die Frage: Wird das richtige System fr einen konkreten Kontext gebaut? Beide Verfahren lassen sich grundstzlich auf allen drei QS-Bereichen syntaktische, semantische und strategische Architektur-QS anwenden; es liegt allerdings in der Natur der Sache, dass mit zunehmender Kontexterweiterung die Verifikation zunehmend schwieriger wird. Von daher zeigt die Erfahrung die in der folgenden Abbildung dargestellten Anwendungsschwerpunkte verifizierender und validierender Ttigkeiten:
die Eingaben/Handlungen, die zur Durchfhrung des Testfalls notwendig sind (hier flieen die Anforderungen und Kriterien ein), die erwarteten Ausgaben/Reaktionen des Testobjektes 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 Durchfhrung des Testfalls erzielt werden (diese sind fr Architektur-QS-Aktivitten meist irrelevant, da die Prfungen nicht invasiv sind). die Prfanweisungen, d. h. wie Eingaben an das Testobjekt zu bergeben sind und wie Sollwerte abzulesen sind (z.B. manuelle Checklisten oder automatische Architektur-Verifikatoren). Die Ermittlung der Testflle zur Verifikation von Architekturen sollte bereits bestmglich im Kontext der S.M.A.R.T.E.R.-Konzept-Anwendung vorbereitet sein. Insbesondere die Spezifikation und die Terminierung sind eine gute Grundlage, Testflle konzeptuell zu erstellen. Fr die Test-Durchfhrung, d.h. das Anlegen der Testflle an die zu testende Architektur mit dem spezifizierten Architekturkontext, mssen die Testflle allerdings noch mit konkreten Testdaten angefllt werden. Ein Beispiel fr einen Testfall ist die Prfung, ob eine explizite Architektur eine Standard-Notation verwendet. Ein konkretes Testdatum bedeutet eine spezifische Architektur eines Projektes (z.B. eine Deployment-Architektur) sowie die Vorgabe,
Verifizierende Verfahren Strategische Architektur-QS Semantische Architektur-QS Syntaktische Architektur-QS
+
Validierende Verfahren
Abbildung 6.4-5: Verifizierende u. Validierende QS-Ttigkeiten
Beide Verfahren des summativen Qualittsmanagements werden im Folgenden detailliert erlutert.
UML 2.0 verwendet zu haben. Es ist an dieser Stelle wichtig darauf hinzuweisen, dass
Verifizierende Verfahren
Das bekannteste und universell einsetzbare verifizierende Verfahren des Architektur-Qualittsmanagements ist das Testen. Wichtige Bestandteile der Beschreibung eines Testfalls sind (vgl. ISTQB): die Vorbedingungen, die vor der Testausfhrung hergestellt werden mssen (z.B. muss eine Architektur explizit als Testobjekt vorliegen),
das Testen von Architekturen fast das Ausfhren des zugrundeliegenden Systems bentigt. Tests knnen auch simuliert (z.B. mittels eines Walkthroughs) werden, was insbesondere hilft, Tests vor einer Implementierung durchzufhren. Wichtig ist auch noch, dass Testen keineswegs nur fr funktionale Architekturaspekte relevant ist: Auch Hardware-Architekturen lassen sich gut testen, indem eine geplante Hardware-Landschaft auf bereinstimmung zu einer tatschlichen Hardware-Landschaft geprft wird (semantische Architektur-QS).
87
Jede Vorgabe des formativen Qualittsmanagements sollte nach dem Abschluss eines Prozessschrittes durch einen Test geprft werden. Wird eine Vorgabe nicht entsprechend geprft, besteht das Risiko, dass Fehlentwicklungen erst spter erkannt werden und dann nur noch mit deutlich berhhten Kosten und Aufwnden behoben werden knnen. Im Folgenden werden fr die jeweiligen QS-Aktivitten einige Beispiele fr validierende Verfahren aufgezeigt:
wenn der Verdacht aufkommt, dass sich unterschiedliche Parameter des Systems und damit der Architekturen so stark gendert haben, dass selbst bei maximaler Erfllung der Vorgaben (verifizierende Verfahren) das System am Ende keine hohe Qualitt aufweist. In einem solchen Fall knnen validierende Verfahren eine gute Mglichkeit liefern, eine bzgl. des spteren Einsatzszenarios wertende Aussage zu erhalten. Das bekannteste Architektur-Validierungsverfahren ist das sogenannte ATAM-Verfahren. ATAM steht hierbei fr Architecture Tradeoff Analysis Method [Kazman00]. ATAM selbst ist eine Weiterentwicklung der Software Architecture Analysis Method (SAAM), welche ebenfalls am SEI entwickelt wurde. ATAM ist ein sogenanntes szenariobasiertes Architekturbewertungsverfahren. Es nhert sich der Aufgabe, eine Softwarearchitektur zu bewerten (im Kontext des validierenden Konzeptes), mittels unterschiedlicher Szenarien an. Die ursprngliche Idee von ATAM adressiert klar die semantische Architektur QS, die im Folgenden auch fr die Einfhrung von ATAM fokussiert wird. Die Grundzge sind aber durchaus auch fr syntaktische, insbesondere aber fr strategische Architektur-QS anwendbar (s. hierzu weiter unten). ATAM selbst unterscheidet grundstzlich drei unterschiedliche Arten von Aktivitten: Direkte Nutzungsszenarios (use case scenarios): Benutzungsszenarien beschreiben eine typische Interaktion eines Users mit dem System. Benutzer knnen hierbei ebenso vielfltig sein, wie dies bereits bei der Betrachtung der Qualitt von Architekturen (s.
QS-Aktivitt
Syntaktische Architektur QS
Beispielverfahren
Checklisten fr Existenz der expliziten Architektur, korrekte Notationen, korrektes Format, Versionsangaben der Architektur, Datumsangaben der Architektur, Autorinformationen Werkzeugbasierte ArchitekturChecker wie CAST, SoftwareTomograph und Bauhaus: Hier wird eine explizit gemachte Architektur (z.B. in UML) im Werkzeug hinterlegt. Gleichzeitig erstellt das Werkzeug auf Basis desselben Dekompositionskriteriums eine Ist-Analyse des Systems. Der Abgleich liefert automatisch das Testergebnis. Checkliste zur Sicherstellung, dass mehrere zu synchronisierende Architekturen zum selben System in derselben Version passen.
Semantische Architektur QS
Strategische Architektur QS
Tabelle 6.4-2: QS-Aktivitten - Beispielverfahren
Validierende Verfahren
Die validierenden Verfahren haben die Aufgabe, den Wert einer Architektur (inkl. des jeweiligen Architekturkontextes) hinsichtlich der Zielrelevanz und der Geschftsstrategien grundstzlich zu prfen. Whrend die verifizierenden Verfahren obligatorisch nach jedem Prozessschritt durchzufhren sind, werden die validierenden Verfahren meist erst bei speziellem Verdacht angewendet (s. hierzu spter am Ende dieses Abschnittes). Dies gilt insbesondere dann,
unterschiedliche Architekturkriterien oben) erarbeitet wurde. Wachstumsszenarios (growth scenarios): Wachstumsszenarien beschreiben Vorgnge, die eine zuknftige Entwicklung des Systems simulieren, wie zum Beispiel eine Migration des Gesamtsystems auf eine andere Plattform, neue Technologien, neue PerformanceAnforderungen o.. Solche Szenarien versuchen, die Zukunft vorauszuahnen. Da Architekturen i.d.R. eine lange Gltigkeit haben, ist dies eine wichtige
88
Mglichkeit, um den Wert einer Architektur auch fr 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 wre wenn. Diese Szenarien werden systematisch mit relevanten Schlsselpersonen, die mit Architekturen in Kontakt kommen (s.o.) erhoben. Die Szenarien werden dabei einzeln auf ihre Auswirkung auf Geschftsziele und Qualittsattribute hin untersucht. Damit ist sichergestellt, dass die Architekturentscheidung nicht auf Basis von Szenarien basiert, die nur eine geringe Relevanz fr die Geschftsziele haben. Jedes dieser Szenarien wird anschlieend bzgl. aller Architekturentscheidungen einer Architektur evaluiert. Die Grundfrage jeder einzelnen Analyse ist hierbei: Wird das konkrete Szenario durch die konkrete Architekturentscheidung untersttzt oder behindert?
Die grundstzliche Struktur einer ATAM-Analyse ist in der folgenden Abbildung noch einmal dargestellt: Das Ergebnis dieser Menge von Analysen mndet entlang von ATAM wie dargestellt in die folgenden 4 Ergebnismengen: Sensitivity points: Hierunter werden bestimmte Komponenten oder Aspekte der Architektur verstanden, deren Gestaltung zur Erfllung eines spezifischen Qualittsmerkmals als erfolgskritischer Faktor beitrgt (ermittelt durch die Analyse eines oder mehrerer entsprechender Szenarien). Zum Beispiel ist die Verfgbarkeit eines Services in einem Client/ServerSystem positiv abhngig von der Anzahl eingesetzter Server. Tradeoff points: An diesen Architekturentscheidungen sind mehrere, teilweise konkurrierende Qualittsmerkmale gleichzeitig betroffen. So kann eine Entscheidung zu Gunsten des einen Merkmals sich negativ auf ein anderes auswirken. Tradeoffpunkte sind somit verschrfte und kritischere Sensitivittspunkte. Zum Beispiel ist die Sicherheit negativ von der Anzahl Server in einem System abhngig, d.h. die Anzahl Server ist ein Tradeoffpunkt zwischen Sicherheit und Verfgbarkeit.
Geschftsziele
Qualittsattribute
Szenarien ATAM Analyse
Architektur
Architektur Anstze
Architektur Entscheidung
beeinflusst
Risks Manahmen und Planung Tradeoffs verdichtet zu Sensitivity points Non-Risks
Abbildung 6.4-6: ATAM-Analyse
89
Risiko-Punkte: An diesen Architekturentscheidungen ist ein definitives Risiko erkennbar, d.h. geschftsrelevante Szenarien werden durch spezifische Architekturentscheidungen mageblich behindert. Hier muss durch genderte Vorgaben gegengesteuert werden, die anschlieend von verifizierenden Verfahren nach einem Prozessschritt kontinuierlich geprft werden. Non-Risks: Alle Szenarien mit positivem AnalyseErgebnis werden als Non-Risk subsumiert. Als Ergebnis des validierendenden Verfahrens ist besonders die Liste der Risiken interessant, da sie Aufschluss darber gibt, inwieweit eine aktuelle Architektur geschftskritische Anwendungen untersttzt oder behindert. Die Risiko-Liste und deren Umfang korreliert daher direkt mit der Qualitt, dem eigentlichen Thema des Architektur-Qualittsmanagement. Der Fokus einer ATAM-Analyse ist klar die semantische Architektur-QS. Eine untergeordnete Rolle spielt sie fr die syntaktische Architektur-QS. Hier kann im Wesentlichen evaluiert werden, ob rein syntaktische Vorgaben an die Architektur selbst zielfhrend bzgl. allgemeiner Anforderungen sind. Eine allgemeine Anforderung knnte beispielsweise die Anwendung einer proprietren Notation sein. Whrend verifizierende Verfahren evtl. die Korrektheit dieser Anforderung besttigen, wrde bei der ATAM-Analyse evtl. aufgedeckt werden knnen, dass diese proprietre Notation im Unternehmen kaum noch Verwendung und insbesondere keinerlei Werkzeuguntersttzung erfhrt. Fr die strategische Architektur QS ist ATAM allerdings das Verfahren schlechthin. Der wesentliche Unterschied zur oben formulierten Erluterung besteht darin, dass Architekturentscheidungen unterschiedlicher Architekturen fr dieselben Use-Cases evaluiert werden. Der Use-Case Datenbackup durchfhren wird folglich nicht gegen die funktionale Architektur gespiegelt, sondern z.B. auch gegen die Security-Architektur, die HardwareArchitektur sowie die Rechte-Architektur. Der einzelne Evaluationsschritt evaluiert damit gleichzeitig die Synchronisationsfhigkeit unterschiedlicher Architekturen.
Im Ergebnis unterscheidet sich die Anwendung von ATAM fr das strategische Architektur-QS nicht vom beschriebenen Verfahren. Eine ATAM-Analyse als validierende Technik sollte immer angewendet werden, wenn sich relevante Parameter eines Systems oder eines Projektes gendert haben, um sicherzustellen, dass die verifizierenden Verfahren noch gegen die korrekten Vorgaben prfen, im Kontext eines allgemeinen Risikomanagements als Teil eines Projektcontrollings die Architektur als risikobehaftet wahrgenommen wird, verifizierende Verfahren grundstzlich und ber einen lngeren Zeitraum (ca. 12 Monate) Abweichungen identifizieren, die nicht behoben werden.
6.4.4 Empfehlungen
Aus den vorgestellten berlegungen zum Thema Architektur-Qualittsmanagement lassen sich folgende direkt umsetzbare Empfehlungen ableiten: Die Architektur als solches ist ein dem Qualittsmanagement anzuvertrauendes Objekt. Auf Grund seiner frhen Prsenz im Software-Lebenszyklus knnen Abweichungen vom Qualittsmanagement damit frh erkannt werden und bei Bedarf gegengesteuert werden. Unterschiedliche Bedarfstrger haben unterschiedliche Architektursichten mit jeweils assoziierten Anforderungen. Es ist Aufgabe des Qualittsmanagements diese ganzheitlich zu dokumentieren, um keine Anforderungen zu vergessen. Architekturen treten in unterschiedlichen Kontexten auf, die jeweils unterschiedliche Anforderungen hervorrufen, die jeweils durch separate QS-Aktivitten konterkariert werden mssen. Alle Anforderungen mssen konstruktiv mit Hilfe formativer Vorgaben definiert werden. Diese mssen dem S.M.A.R.T.E.R.-Konzept gehorchen, um tatschlich konstruktiv im Projekt eingesetzt werden zu knnen.
90
Alle Anforderungen mssen analytisch mit Hilfe summativer Qualittstechniken geprft werden. Hierzu gehren verifizierende Verfahren, die prfen, ob etwas richtig erstellt wurde (ob z.B. eine modellierte Architektur zur tatschlich umgesetzten passt) wie validierende Verfahren, die prfen, ob die richtige Architektur fr spezifische Anforderungen gewhlt wurde. Mit diesen Mglichkeiten, formativ Architekturen ganzheitlich steuern zu knnen, und summativ mglichst frhzeitig Abweichungen zu identifizieren, ist ein effizientes und effektives Architektur-Qualittsmanagement mglich.
sein und jedem Nutzer (ggfs. unter Bercksichtigung von Zugriffsrechten) erlauben die Architektur zu nutzen und zu berprfen, um nderungsvorschlge einzureichen. Die folgenden Informationen sollten (vorzugsweise automatisch) angefgt sein, um nderungsvorschlge effizient handhaben zu knnen. Autor des nderungsvorschlags, Kontaktdaten (fr mgliche Rckfragen), Gegenstand des nderungsvorschlags, Referenz zur Architektur (z.B. Diagramm, Entitt, Matrix etc.), Beschreibung/Grund, Vorschlge, Bezugsdokumente, Verweise, Anhnge. Die Verwaltung von nderungsvorschlgen sollte inner-
6.5 Architektur nderungsmanagement

Das Produkt der Architekturentwicklung, die Architektur/ Architekturdatenbank, ist eine lebende Dokumentation, 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 vollstndig ist oder geringfgige Lcken bei Darstellungen, Definitionen oder Zuordnungen aufweist. Ferner knnen nderungen von Ablufen, Organisationsstrukturen, Technologien die Architekten zwingen, die Architektur anzupassen. Deshalb muss ein nderungsmanagement eingerichtet werden. Es sollte folgende Gesichtspunkte abdecken: Einreichung von nderungsvorschlgen, Review der nderungsvorschlge, Entscheidung der nderungsvorschlge, Anpassung der Architektur oder Einleitung eines neuen Entwicklungszyklus basierend auf dem angenommenen nderungsvorschlag. Jede Architektur sollte durch eine Vielzahl von Stakeholdern berprft werden, um die Vollstndigkeit und Richtigkeit zu erhhen und die Qualitt zu verbessern. Folglich sollte das nderungsvorschlagswesen leicht zugnglich
halb eines Anforderungsmanagementwerkzeugs realisiert werden. Somit knnten Anforderungen und Architekturinhalte, auf die sich ein nderungsvorschlag auswirkt, parallel und konsistent bearbeitet werden. Die folgende Auflistung stellt zustzliche administrative Informationen dar, die zur Handhabung der nderungsvorschlge erforderlich sind: Identifikationsnummer, Status (erhalten, geprft, angenommen, abgelehnt), Kategorie (inhaltsbezogen, Design, Zusatz, Lschung, Korrektur), Prioritt (hoch, mittel, niedrig), Kommentar (Beschreibung von Einflssen/Auswirkungen, falls die nderung angenommen wird), Empfehlungen. Eingehende nderungsvorschlge werden fr die weitere Bearbeitung bewertet und priorisiert. Zudem mssen 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 Aktivitten eingeleitet. Der Initiator des nderungsvorschlags sollte eine Rckantwort ber die getroffene Entscheidung erhalten.
91
6.6 Architektur Sicherheitsmanagement

Sicherheit muss in den gesamten Architekturerstellungsprozess, aber auch in den kompletten Lebenszyklus der resultierenden Systeme, Organisationen und Anwendungen eingebunden werden. Um dies zu ermglichen, bieten internationale Standards, wie die ISO 27001 ein Framework, welches das Management der Sicherheit fr die einzelnen Phasen ermglicht und in einem ganzheitlichen Gesamtkonzept vereint. Der Ablauf zur Entwicklung eines sicheren Architekturkonzepts ist allgemein nach ISO 27001 in Abbildung 6.6-1 dargestellt.
alle Risiken einen von der Fhrungsebene definierter Risikolevel erreichen oder unterschreiten. Die Restrisiken mssen von der Fhrungsebene akzeptiert und das Architekturkonzept an den Organisationszielen ausgerichtet werden. Do Im nchsten Schritt wird das Architekturkonzept entsprechend den erarbeiteten Anforderungen entwickelt und zum Review bereitgestellt. Dabei sollten die geplanten Manahmen zur Einhaltung des Risikolevels bestmglich umgesetzt werden. Check In dieser Phase erfolgt die berprfung der Umsetzung, der in der Plan-Phase, erarbeiteten Sicherheitsanforderungen und ob die jeweiligen akzeptieren Risi-
Interested Parties
Plan Establish ISMS
Interested Parties
Do
Implement and the ISMS Monitor and review the ISMS Check
Maintain and the ISMS
Act
Information security requirements and expectations
Managed information security
Abbildung 6.6-1: PDCA nach ISO 27001
kolevel eingehalten werden konnten. Die Ergebnisse mssen wieder an die Fhrungsebene kommuniziert werden.
Die in Abbildung 6.6-1 abgebildeten vier Schritte Plan, Do, Check und Act (kurz PDCA) werden im Folgenden erlutert. Plan Um die sicherheitstechnischen Anforderungen an die Architektur festlegen zu knnen, bedarf es einer Risikoanalyse. Dabei werden die mglichen Risiken des Systems, welches durch die Architektur umgesetzt werden sollte, analysiert, bewertet und dokumentiert. Die Architektur wird dahingehend angepasst, so dass
Act Wurden die Ziele nicht gnzlich erreicht, so wird das Architekturkonzept entsprechend angepasst, um die gestellten Sicherheitsanforderungen zu erfllen. 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
92
gesamten Lebenszyklus der daraus resultierenden Anwendung oder des daraus resultierenden Systems miteinbezogen werden, um einen optimalen Grad an Sicherheit fr die jeweilige Organisation und das jeweilige Projekt zu erzielen.
93
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 Fhrungsuntersttzung Bundeswehr und IT-System der Bundeswehr (TK FUstgBw und IT-SysBw), Stand: 08.08.2006, VS-NfD /5/ AG Architektur Bundeswehr: Rahmenregelung Architekturerarbeitung/-bearbeitung IT-SysBw; mterseitig mitgezeichnete 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)
94
95
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 Beschftigten. Hierzu zhlen Anbieter von Software, IT-Services und Telekommunikationsdiensten, Hersteller von Hardware und Consumer Electronics sowie Unternehmen der digitalen Medien. Der BITKOM setzt sich insbesondere fr bessere ordnungspolitische Rahmenbedingungen, eine Modernisierung des Bildungssystems und eine innovationsorientierte Wirtschaftspolitik ein. Der Zentralverband Elektrotechnik- und Elektronikindustrie e.V. vertritt die wirtschafts-, technologie- und umweltpolitischen Interessen der deutschen Elektroindustrie auf nationaler, europischer und internationaler Ebene. Er informiert gezielt ber die wirtschaftlichen, technischen und rechtlichen Rahmenbedingungen fr 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 fr die Bundeswehr genutzt werden kann.
Der vorliegende Leitfaden ist mit der Untersttzung folgender Unternehmen entstanden:
Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. Albrechtstrae 10 A 10117 Berlin-Mitte Tel.: 03o.27576-0 Fax: 030.27576-400 bitkom@bitkom.org www.bitkom.org
Zentralverband Elektrotechnikund Elektronikindustrie e.V. Lyoner Strae 9 60528 Frankfurt am Main Tel.: 069.6302-0 zvei@zvei.org www.zvei.org

Leitfaden Architekturentwicklung in Der Industrie

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Leitfaden Architekturentwicklung in Der Industrie

Originaltitel:

Hochgeladen von

Copyright:

Verfügbare Formate

Architekturentwicklung in der wehrtechnischen Industrie

Architekturentwicklung in der wehrtechnischen Industrie

Architekturentwicklung in der wehrtechnischen Industrie

Architekturentwicklung in der wehrtechnischen Industrie

Architekturentwicklung in der wehrtechnischen Industrie

3 Vorgaben und Randbedingungen der Bundeswehr

berlebensfhigkeit und Schutz Wirksamkeit im Einsatz Nachrichtengewinnung und Aufklrung

Einsatzbetrieb auf Basis NetOpF

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

Abbildung 3.1-1: Fhigkeitskategorien der Bundeswehr gem KdB

in nachfolgenden Kapiteln nher beschrieben werden: Architekturen bzw. architekturbasierte Vorgehensweise

Architekturentwicklung in der wehrtechnischen Industrie

3.2 Customer Product Management (CPM)

Architekturentwicklung in der wehrtechnischen Industrie

3.2.1 Beziehungen zwischen dem CPM und Architekturen

3.2.2 Der Verfahrensablauf nach dem CPM

Architekturentwicklung in der wehrtechnischen Industrie

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

Architekturentwicklung in der wehrtechnischen Industrie

Architekturentwicklung in der wehrtechnischen Industrie

3.2.3 Schrittweises Vorgehen

3.2.4 Grundstze der Wirtschaftlichkeit

3.2.5 Die Mitwirkung der gewerblichen Wirtschaft im Rahmen des CPM

Architekturentwicklung in der wehrtechnischen Industrie

3.3.1 bersicht des Inhalts des V-Modells XT

Benutzbarkeit und Ergonomie

SW-Entwicklung HW-Entwicklung Multiprojektmanagement Vertragsschluss (AG)

Evaluierung von Fertigprodukten

Lieferung und Abnahme (AN)

Lieferung und Abnahme (AG)

Problem- und nderungsmanagement

Abbildung 3.3-2: Vorgehensbausteinkarte

beinhaltet untergeordnete Aktivitt 1 Aktivitt

beinhaltet untergeordnete Produkte 1 Produkt

hat Abhngigikeiten zu anderen

Abbildung 3.3-3: Aufbau eines Vorgehensbausteins

Architekturentwicklung in der wehrtechnischen Industrie

mitwirkend Rolle Rolle Thema Thema Thema Teilaktivitt bearbeiten

Abbildung 3.3-4: Vorgehensbausteinbergreifende Strukturierung

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

[im Zustand fertig gestellt]

Abbildung 3.3-5: Projektdurchfhrungsstrategien und Entscheidungspunkte

Abhngigkeiten zu anderen Produkten. Die Vorgehensbausteine sind die modularen Einheiten fr

3.3.2 Aktivitten zur Erstellung einer Architektur

Altsystemanalyse erstellen Altsystemanalyse Marktsichtung fr Fertigprodukte (AN) Make-or-Buy-Entscheidung

Tabelle 3.3-1: Aufgaben und Produkte der Analysephase

Architekturentwicklung in der wehrtechnischen Industrie

Tabelle 3.3-3: Aufgaben und Produkte des Systementwurfs

Die weiteren Aktivitten der Entwicklung gehren nicht

HW-Spezifikation erstellen HW-Spezifikation

Externes-SW-Modul-Spezi- Externes-SW-Modul-Spefikation erstellen zifikation

GesamtSystemSystemsystemspezifikation architektur spezifikation

Architekturentwicklung in der wehrtechnischen Industrie

GesamtSystemSystemsystemspezifikation architektur spezifikation

NSV-10 NTV-1 NTV-2 NTV-3 NTV-4 NTV-5

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

3.4 NATO Architecture Framework 3.4.1 berblick

Zachman 1987 EAP 1992 1992 C4ISR 1996-7

TISAF 1997 Zeit

FEAF 1999 TEAF 2000

OMG UPMD 2005

2004-6 NATO 2003-6