Ramy architektury Departamentu Obrony

Struktura architektury DoD v1.5.
DoDAF Architecture Framework wersja 2.0

Departamentu Obrony ( DoDAF ) to struktura architektury dla Departamentu Obrony Stanów Zjednoczonych (DoD), która zapewnia infrastrukturę wizualizacji dla określonych interesariuszy za pośrednictwem punktów widzenia zorganizowanych według różnych widoków . Te widoki są artefaktami służącymi do wizualizacji, zrozumienia i przyswojenia szerokiego zakresu i złożoności opisu architektury za pomocą tabelarycznych , strukturalnych , behawioralnych , ontologicznych , obrazowych , czasowych , graficznych , probabilistycznych lub alternatywnych środków koncepcyjnych . Bieżąca wersja to DoDAF 2.02.

Ta struktura architektury jest szczególnie dostosowana do dużych systemów ze złożonymi wyzwaniami związanymi z integracją i interoperacyjnością i najwyraźniej jest wyjątkowa w zastosowaniu „widoków operacyjnych”. Widoki te oferują przegląd i szczegóły skierowane do konkretnych interesariuszy w ich domenie oraz w interakcji z innymi domenami, w których system będzie działał.

Przegląd

DoDAF zapewnia podstawowe ramy do opracowywania i przedstawiania opisów architektury, które zapewniają wspólny mianownik do zrozumienia, porównania i integracji architektur ponad granicami organizacyjnymi, wspólnymi i międzynarodowymi. Ustanawia definicje elementów danych, reguły i relacje oraz podstawowy zestaw produktów do spójnego rozwoju systemów, zintegrowanych lub stowarzyszonych architektur. Te opisy architektury mogą obejmować rodziny systemów (FoS), systemy systemów (SoS) oraz sieciocentryczne możliwości współdziałania i interakcji w środowisku niezwiązanym z walką.

Oczekuje się, że komponenty DoD będą zgodne z DoDAF w maksymalnym możliwym zakresie przy opracowywaniu architektur w Departamencie. Zgodność gwarantuje, że ponowne wykorzystanie informacji, artefaktów architektury, modeli i punktów widzenia może być współdzielone z powszechnym zrozumieniem. Wszystkie główne przejęcia broni i systemów informatycznych Departamentu Obrony Stanów Zjednoczonych muszą opracować i udokumentować architekturę korporacyjną (EA) przy użyciu widoków określonych w DoDAF. Chociaż jest wyraźnie skierowany do systemów wojskowych, DoDAF ma szerokie zastosowanie w sektorach prywatnym, publicznym i ochotniczym na całym świecie i reprezentuje jedną z wielu ram architektury systemów .

  • Celem DoDAF jest zdefiniowanie koncepcji i modeli użytecznych w sześciu podstawowych procesach DoD:
    1. Integracja i rozwój wspólnych zdolności (JCIDS)
    2. Planowanie, programowanie, budżetowanie i wykonanie (PPBE)
    3. System pozyskiwania danych obronnych (DAS)
    4. Inżynieria systemów (SE)
    5. Planowanie operacyjne (OPLAN)
    6. Zarządzanie portfelem możliwości (CPM)
  • Ponadto szczegółowe cele DoDAF 2.0 obejmowały:
    1. Ustal wytyczne dotyczące treści architektury jako funkcji celu – „odpowiednie do celu”
    2. Zwiększ użyteczność i efektywność architektur dzięki rygorystycznemu modelowi danych — DoDAF Meta Model (DM2) — aby architektury można było integrować, analizować i oceniać z większą precyzją.

Historia

Ewolucja DoDAF od lat 90. DoDAF V2.0 został wydany w maju 2009 roku.

Pierwsza wersja rozwojowa DoDAF powstała w latach 90-tych pod nazwą C4ISR Architecture Framework. W tym samym okresie dalej rozwijany był referencyjny model TAFIM , zapoczątkowany w 1986 roku. Pierwszy C4ISR Architecture Framework v1.0, wydany 7 czerwca 1996 r., Powstał w odpowiedzi na uchwalenie ustawy Clinger-Cohen Act . Odniósł się do dyrektywy Zastępcy Sekretarza Obrony z 1995 r., mówiącej o podjęciu wysiłków w całym DoD w celu zdefiniowania i opracowania lepszych środków i procesu w celu zapewnienia interoperacyjności zdolności C4ISR i spełnienia potrzeb wojownika. Kontynuacja prac rozwojowych zaowocowała w grudniu 1997 drugą wersją, C4ISR Architecture Framework v2.0.

W sierpniu 2003 roku wydano DoDAF v1.0, który zrestrukturyzował C4ISR Framework v2.0, aby oferować wskazówki, opisy produktów i informacje uzupełniające w dwóch tomach oraz w książce Desk Book. Rozszerzyło zastosowanie zasad i praktyk architektury na wszystkie obszary misji, a nie tylko na społeczność C4ISR. Ten dokument dotyczył użycia, zintegrowanych architektur, polityk DoD i federalnych, wartości architektur, miar architektury, procesów wspomagania decyzji DoD, technik programistycznych, technik analitycznych i CADM v1.01, i przeszedł w kierunku podejścia opartego na repozytoriach, kładąc nacisk na elementy danych architektury, które składają się na produkty architektury. W lutym 2004 została wydana dokumentacja wersji 1.0 wraz z tomem "I: Definicje i wytyczne", "II: Opisy produktów" oraz "Deskbook". W kwietniu 2007 została wydana wersja 1.5 z dokumentacją „Definicje i wytyczne”, „Opisy produktów” oraz „Opis danych architektury”.

28 maja 2009 DoDAF v2.0 został zatwierdzony przez Departament Obrony. Obecna wersja to DoDAF 2.02 DoDAF V2.0 jest publikowany na ogólnodostępnej stronie internetowej.

Inne ramy pochodne oparte na DoDAF obejmują ramy architektury NATO (NAF) i ramy architektury Ministerstwa Obrony . Podobnie jak inne podejścia EA, na przykład The Open Group Architecture Framework (TOGAF), DoDAF jest zorganizowany wokół wspólnego repozytorium do przechowywania produktów pracy. Repozytorium jest zdefiniowane przez wspólny schemat bazy danych Core Architecture Data Model 2.0 i DoD Architecture Registry System (DARS). Kluczową cechą DoDAF jest interoperacyjność, która jest zorganizowana jako szereg poziomów, zwanych poziomami interoperacyjności systemów informacyjnych (LISI). Rozwijający się system musi nie tylko spełniać swoje wewnętrzne potrzeby w zakresie danych, ale także ramy operacyjne, w których jest osadzony.

Możliwości i misja

Zobacz diagram przedstawiający nacisk na możliwości, powiązany z misją/przebiegiem działania, wątkami, działaniami i architekturami.

Możliwości opisane za pomocą architektur

Departament Obrony przesunął się w kierunku skupienia się na dostarczaniu możliwości, które są powodem stworzenia systemu/usługi. Modele zdolności opisują taksonomię zdolności i ewolucję zdolności. Wątek zdolności byłby równoznaczny z określonymi działaniami, regułami i systemami, które są powiązane z tą konkretną zdolnością.

Pojęcie zdolności, zdefiniowane przez Meta-model Data Group, pozwala odpowiedzieć na pytania takie jak:

  • W jaki sposób dana zdolność lub zdolności wspierają ogólną misję/wizję?
  • Jakie wyniki mają zostać osiągnięte dzięki określonej zdolności lub zestawowi zdolności?
  • Jakie usługi są wymagane do obsługi możliwości?
  • Jaki jest zakres funkcjonalny i rozpiętość organizacyjna zdolności lub zestawu możliwości?
  • Jaki jest nasz obecny zestaw możliwości, którymi zarządzamy w ramach portfela?

Misja lub kierunek działań jest opisany przez Koncepcję Operacji (CONOPS) i jest zorganizowany według Możliwości.

  • Możliwości są opisywane przez wątki.
  • Wątki są opisywane przez Działania wykonywane szeregowo lub równolegle.
  • Działania są pogrupowane w obszary misji. Działania definiują operacje dla architektury.
  • Architektury są zorganizowane według obszarów misji. Architektury zapewniają odpowiednie zasoby zdolności wymaganych przez Misję lub Kierunek Działania.

Widoki wersji 1.5

DoDAF V1.5 Powiązania między widokami.
Ramy DoD C4ISR

DoDAF V1.5 definiuje zestaw produktów, model widoku , który działa jako mechanizm wizualizacji, zrozumienia i asymilacji szerokiego zakresu i złożoności opisu architektury za pomocą środków graficznych, tabelarycznych lub tekstowych. Te produkty są uporządkowane w czterech widokach:

  • Cały widok (AV)
  • Widok operacyjny (OV)
  • Widok systemów (SV)
  • Widok standardów technicznych (TV)

Każdy widok przedstawia określone perspektywy architektury, jak opisano poniżej. Dla każdego rozwoju systemu zwykle tworzony jest tylko podzbiór pełnego zestawu widoków DoDAF. Rysunek przedstawia informacje łączące widok operacyjny, widok systemów i usług oraz widok standardów technicznych. Te trzy widoki i ich wzajemne powiązania – sterowane elementami danych o wspólnej architekturze – stanowią podstawę do wyprowadzania miar, takich jak interoperacyjność lub wydajność, oraz do mierzenia wpływu wartości tych metryk na skuteczność misji operacyjnej i zadania.

Wszystkie widoki

Wszystkie produkty View (AV) zapewniają nadrzędne opisy całej architektury oraz definiują zakres i kontekst architektury. Produkty DoDAF V1.5 AV są zdefiniowane jako:

Informacje ogólne i podsumowujące AV-1
Zakres, cel, docelowi użytkownicy, przedstawione środowisko, wyniki analiz (jeśli dotyczy)
Zintegrowany słownik AV-2
Definicje wszystkich terminów używanych we wszystkich produktach.

Widok operacyjny

Operational View (OV) zawierają opisy zadań i działań, elementów operacyjnych i wymiany informacji wymaganych do wykonania misji DoD. OV zapewnia tekstową i graficzną reprezentację węzłów i elementów operacyjnych, przydzielonych zadań i działań oraz przepływów informacji między węzłami. Określa rodzaj wymienianych informacji, częstotliwość wymiany, zadania i działania wspierane przez te wymiany oraz charakter wymiany. Produkty DoDAF V1.5 OV są zdefiniowane jako:

Graficzna koncepcja operacyjna wysokiego poziomu OV-1
Graficzny i tekstowy opis koncepcji operacyjnej wysokiego poziomu (organizacje wysokiego szczebla, misje, konfiguracja geograficzna, łączność itp.).
OV-2 Operational Node Connectivity Opis
Węzły operacyjne, czynności wykonywane w każdym węźle oraz połączenia i przepływ informacji między węzłami.
OV-3 Macierz wymiany informacji operacyjnych
Informacje wymieniane między węzłami i odpowiednie atrybuty tej wymiany, takie jak media, jakość, ilość i wymagany poziom interoperacyjności.
OV-4 Wykres relacji organizacyjnych
Dowództwo, kontrola, koordynacja i inne relacje między organizacjami.
OV-5 Model działalności operacyjnej
Działania, relacje między działaniami, wejścia i wyjścia. Ponadto nakładki mogą pokazywać koszty, działające węzły lub inne istotne informacje.
Model reguł operacyjnych OV-6a
Jeden z trzech produktów używanych do opisu sekwencji i czasu działań operacyjnych, który identyfikuje reguły biznesowe ograniczające operację.
OV-6b Operational State Transition Description
Jeden z trzech produktów używanych do opisu sekwencji i czasu działania operacyjnego, który identyfikuje reakcje procesu biznesowego na zdarzenia.
OV-6c Operational Event-Trace Description
Jeden z trzech produktów używanych do opisywania sekwencji i czasu działań operacyjnych, który śledzi działania w scenariuszu lub krytycznej sekwencji zdarzeń.
Logiczny model danych OV-7
Dokumentacja wymagań dotyczących danych i reguł strukturalnych procesów biznesowych Widoku Operacyjnego. (W DoDAF V1.5. Odpowiada DIV-2 w DoDAF V2.0.)

Widok systemów i usług

Widok systemów i usług (SV) to zestaw graficznych i tekstowych produktów, które opisują systemy i usługi oraz połączenia zapewniające lub wspierające funkcje DoD. Produkty SV koncentrują się na określonych systemach fizycznych z określonymi fizycznymi (geograficznymi) lokalizacjami. Relację między elementami danych architektury między SV a OV można zilustrować, gdy systemy są nabywane i wdrażane w celu wspierania organizacji i ich operacji. Produkty DoDAF V1.5 SV to:

SV-1 Interfejs systemów/usług Opis
Przedstawia węzły systemów i systemy rezydujące w tych węzłach w celu wspierania organizacji/roli ludzkich reprezentowanych przez węzły operacyjne OV-2. SV-1 identyfikuje również interfejsy między systemami i węzłami systemów.
SV-2 Systemy/usługi Komunikacja Opis
Przedstawia istotne informacje o systemach komunikacyjnych, łączach komunikacyjnych i sieciach komunikacyjnych. SV-2 dokumentuje rodzaje mediów komunikacyjnych, które obsługują systemy i implementuje ich interfejsy, jak opisano w SV-1. Zatem SV-2 pokazuje szczegóły komunikacji interfejsów SV-1, które automatyzują aspekty linii potrzeb reprezentowanych w OV-2.
SV-3 Systems-Systems, Services-Systems, Services-Services Matrices
zawiera szczegółowe informacje na temat charakterystyk interfejsu opisanych w SV-1 dla architektury, ułożonych w formie macierzy.
Systemy/usługi SV-4a/SV-4b Opis funkcjonalności
SV-4a dokumentuje hierarchie funkcjonalne systemu i funkcje systemowe oraz przepływ danych systemowych między nimi. SV-4 z DoDAF v1.0 jest oznaczony jako „SV-4a” w DoDAF v1.5. Chociaż istnieje korelacja między OV-5 lub hierarchiami procesów biznesowych a hierarchią funkcjonalną systemu SV-4a, nie musi to być mapowanie jeden do jednego, stąd potrzeba macierzy identyfikowalności działań operacyjnych do funkcji systemów ( SV-5a), który zapewnia to mapowanie.
SV-5a, SV-5b, SV-5c Działanie operacyjne do funkcji systemów, działanie operacyjne do systemów i matryce identyfikowalności usług Działanie
operacyjne do SV-5a i SV-5b to specyfikacja relacji między zbiorem działań operacyjnych mających zastosowanie do architekturę i zestaw funkcji systemowych mających zastosowanie do tej architektury. SV-5 i rozszerzenie SV-5 z DoDAF v1.0 jest oznaczone odpowiednio jako „SV-5a” i „SV-5b” w DoDAF v1.5.
SV-6 Macierz wymiany danych systemów/usług
Określa charakterystykę danych systemowych wymienianych między systemami. Produkt ten koncentruje się na zautomatyzowanej wymianie informacji (z OV-3), które są zaimplementowane w systemach. Niezautomatyzowana wymiana informacji, taka jak ustne polecenia, jest rejestrowana tylko w produktach OV.
SV-7 Systems/Services Performance Parameters Matrix
Określa charakterystykę ilościową systemów i elementów sprzętowych/oprogramowania systemowego, ich interfejsów (dane systemowe przenoszone przez interfejs oraz szczegóły łącza komunikacyjnego, które implementują interfejs) oraz ich funkcje. Określa bieżące parametry wydajności każdego systemu, interfejsu lub funkcji systemu oraz oczekiwane lub wymagane parametry wydajności w określonych momentach w przyszłości. Parametry eksploatacyjne obejmują wszystkie charakterystyki techniczne systemów, dla których można opracować wymagania i zdefiniować specyfikację. Kompletny zestaw parametrów wydajnościowych może nie być znany na wczesnych etapach definiowania architektury, dlatego należy się spodziewać, że ten produkt będzie aktualizowany przez cały okres specyfikacji systemu, projektowania, rozwoju, testowania, a być może nawet jego wdrażania i eksploatacji przez cały cykl życia fazy.
SV-8 Opis ewolucji systemów/usług
Przechwytuje plany ewolucji, które opisują, w jaki sposób system lub architektura, w której jest osadzony, będzie ewoluować w długim okresie czasu. Ogólnie rzecz biorąc, kamienie milowe osi czasu mają kluczowe znaczenie dla pomyślnego zrozumienia osi czasu ewolucji.
SV-9 Systems/Services Technology Forecast
Definiuje leżące u podstaw obecne i oczekiwane technologie wspierające, które zostały ukierunkowane przy użyciu standardowych metod prognozowania. Oczekiwane technologie pomocnicze to te, które można racjonalnie przewidzieć, biorąc pod uwagę obecny stan technologii i oczekiwane ulepszenia. Nowe technologie powinny być powiązane z określonymi okresami, które mogą korelować z okresami używanymi w kamieniach milowych SV-8.
SV-10a Model reguł systemów/usług
Opisuje reguły, zgodnie z którymi architektura lub jej systemy zachowują się w określonych warunkach.
SV-10b Systems/Services State Transition Description
Graficzna metoda opisu odpowiedzi systemu (lub funkcji systemu) na różne zdarzenia poprzez zmianę jego stanu. Diagram zasadniczo przedstawia zestawy zdarzeń, na które systemy w architekturze zareagują (podejmując działania w celu przejścia do nowego stanu) w zależności od ich obecnego stanu. Każde przejście określa zdarzenie i akcję.
SV-10c Systems/Services Event-Trace Description
Zapewnia uporządkowane w czasie badanie elementów danych systemowych wymienianych między uczestniczącymi systemami (zewnętrznymi i wewnętrznymi), funkcjami systemowymi lub rolami ludzkimi w wyniku określonego scenariusza. Każdy diagram śledzenia zdarzeń powinien mieć towarzyszący opis, który definiuje konkretny scenariusz lub sytuację. SV-10c w Widoku Systemów i Usług może odzwierciedlać specyficzne dla systemu aspekty lub udoskonalenia krytycznych sekwencji zdarzeń opisanych w Widoku Operacyjnym.
SV-11 Physical Schema
Jeden z produktów architektonicznych najbardziej zbliżony do rzeczywistego projektu systemu w Frameworku. Produkt definiuje strukturę różnych rodzajów danych systemowych, które są wykorzystywane przez systemy w architekturze. (W DoDAF V1.5. Odpowiada to DIV-3 w DoDAF V2.0.)

Widok standardów technicznych

Produkty z widokiem standardów technicznych (TV) definiują standardy techniczne, konwencje implementacji, reguły biznesowe i kryteria rządzące architekturą. Produkty telewizyjne DoDAF V1.5 to:

  • Profil standardów technicznych StdV-1 — Wyodrębnianie standardów, które mają zastosowanie do danej architektury. (W DoDAF V1.5. Zmieniono nazwę na StdV-1 w DoDAF V2.0.)
  • Prognoza standardów technicznych StdV-2 — opis pojawiających się standardów, które mają mieć zastosowanie do danej architektury, w odpowiednim zestawie ram czasowych. (W DoDAF V1.5. Zmieniono nazwę na StdV-2 w DoDAF V2.0.)

Punkty widzenia wersji 2.0

Schemat punktów widzenia DoDAF V2.0.
Ewolucja widoków DoDAF V1.5 do punktów widzenia DoDAF V2.0.
Mapowanie widoków DoDAF V1.5 na punkty widzenia DoDAF V2.0.

W DoDAF V2.0 architektoniczne punkty widzenia składają się z danych uporządkowanych w celu ułatwienia zrozumienia. Aby dostosować się do norm ISO, w stosownych przypadkach zmieniono terminologię z widoków na punkt widzenia (np. widok operacyjny jest teraz punktem widzenia operacyjnym).

All Viewpoint (AV)
Opisuje nadrzędne aspekty kontekstu architektury, które odnoszą się do wszystkich punktów widzenia.
Punkt widzenia zdolności (CV)
Nowość w DoDAF V2.0. Określa wymagania dotyczące zdolności, czas dostawy i wdrożoną zdolność.
Punkt widzenia danych i informacji (DIV)
Nowość w DoDAF V2.0. Artykułuje relacje danych i struktury wyrównania w treści architektury dla możliwości i wymagań operacyjnych, procesów inżynierii systemowej oraz systemów i usług.
Operacyjny punkt widzenia (OV)
Obejmuje scenariusze operacyjne, działania i wymagania wspierające zdolności.
Punkt widzenia projektu (PV)
Nowość w DoDAF V2.0. Opisuje relacje między wymaganiami operacyjnymi i zdolnościowymi a różnymi wdrażanymi projektami. Punkt widzenia projektu wyszczególnia również zależności między wymaganiami w zakresie zdolności i operacyjnymi, procesami inżynierii systemowej, projektowaniem systemów i projektowaniem usług w ramach procesu systemu pozyskiwania obronności.
Punkt widzenia usług (SvcV)
Nowość w DoDAF V2.0. Przedstawia projekt rozwiązań obejmujących Wykonawców, Działania, Usługi i ich Wymiany, zapewniających lub wspierających funkcje operacyjne i zdolności.
Standards Viewpoint (StdV)
Zmieniono nazwę z Technical Standards View. Wyraża obowiązujące zasady operacyjne, biznesowe, techniczne i branżowe, standardy, wytyczne, ograniczenia i prognozy, które mają zastosowanie do wymagań dotyczących możliwości i operacyjnych, procesów inżynierii systemowej oraz systemów i usług.
Systems Viewpoint (SV)
Wyraża, w przypadku obsługi starszego typu , projekt rozwiązań wyrażających systemy, ich skład, wzajemne połączenia i kontekst zapewniający lub wspierający funkcje operacyjne i zdolności. Uwaga, system zmienił się w DoDAF V2.0 z DoDAF V1.5: System to nie tylko sprzęt komputerowy i oprogramowanie komputerowe. System jest obecnie definiowany w ogólnym sensie jako zespół komponentów – maszyny, człowieka – które wykonują czynności (ponieważ są podtypami Wykonawcy) i wchodzą w interakcje lub współzależności. Może to być wszystko, tj. wszystko, od małych elementów wyposażenia, które mają współdziałające lub współzależne elementy, po rodzinę systemów (FoS) i system systemów (SoS). Należy pamiętać, że Systemy składają się z Materiałów (np. sprzętu, samolotów i statków) oraz Typów Personelu.

Architektury DoDAF w wersji 1.0 i DoDAF w wersji 1.5 mogą być nadal używane. W stosownych przypadkach (zwykle wskazanych przez zasady lub decydenta) architektury DoDAF w wersji 1.0 i 1.5 będą musiały zaktualizować swoją architekturę. Porównując architekturę sprzed wersji DoDAF V2.0 z architekturą DoDAF V2.0, należy zdefiniować lub wyjaśnić różnice w koncepcjach (takie jak Node) dla nowszej architektury. W przypadku produktów DoDAF V1.5 zostały one przekształcone w części modeli DoDAF V2.0. W większości przypadków Metamodel DoDAF V2.0 obsługuje koncepcje danych DoDAF V1.5, z jednym godnym uwagi wyjątkiem: Node. Węzeł to złożona, logiczna koncepcja, która jest reprezentowana przez bardziej konkretne koncepcje.

Cały punkt widzenia (AV)

AV-1 Informacje ogólne i podsumowujące
Opisują wizje projektu, cele, zadania, plany, działania, wydarzenia, warunki, środki, efekty (wyniki) i wytworzone obiekty.
Zintegrowany słownik AV-2
Repozytorium danych architektonicznych z definicjami wszystkich terminów używanych w całym tekście

Punkt widzenia zdolności (CV)

Wizja CV-1
Odnosi się do obaw przedsiębiorstwa związanych z ogólną wizją przedsięwzięć transformacyjnych, a tym samym definiuje kontekst strategiczny dla grupy zdolności. Celem CV-1 jest zapewnienie strategicznego kontekstu dla możliwości opisanych w Opisie architektury.
CV-2 Capability Taxonomy
Przechwytuje taksonomie możliwości. Model przedstawia hierarchię możliwości. Możliwości te można przedstawić w kontekście osi czasu. CV-2 określa wszystkie możliwości, do których odwołuje się jedna lub więcej architektur.
CV-3 Capability Phases
Planowane osiągnięcie zdolności w różnych punktach w czasie lub w określonych okresach czasu. CV-3 pokazuje fazowanie zdolności pod względem działań, warunków, pożądanych efektów, przestrzeganych zasad, zużycia zasobów i produkcji oraz środków, bez względu na wykonawcę i rozwiązania lokalizacyjne. CV-4 Zależności od zdolności Zależności między planowanymi
zdolnościami
a definicja logicznego grupowania zdolności.
CV-5 Mapowanie zdolności do rozwoju organizacji
Spełnienie wymagań dotyczących zdolności pokazuje planowane rozmieszczenie zdolności i wzajemne połączenia dla określonej fazy zdolności. CV-5 pokazuje planowane rozwiązanie dla fazy pod względem wykonawców i lokalizacji oraz związanych z nimi koncepcji.
CV-6 Mapowanie zdolności do działań operacyjnych
Mapowanie pomiędzy wymaganymi zdolnościami a działaniami operacyjnymi wspieranymi przez te zdolności.
CV-7 Mapowanie zdolności do usług
Mapowanie między możliwościami a usługami, które te możliwości umożliwiają.

Punkt widzenia danych i informacji (DIV)

DIV-1 Conceptual Data Model
Wymagane koncepcje danych wysokiego poziomu i ich relacje.
DIV-2 Logiczny Model Danych
Dokumentacja wymagań dotyczących danych i reguł strukturalnych procesów biznesowych (działań). W DoDAF V1.5 był to OV-7.
DIV-3 Fizyczny model danych
Fizyczny format implementacji jednostek Logicznego Modelu Danych, np. formaty komunikatów, struktury plików, schemat fizyczny. W DoDAF V1.5 był to SV-11.

Uwaga, zobacz Logiczny model danych , aby zapoznać się z omówieniem relacji między tymi trzema modelami danych DIV, z porównaniem koncepcyjnego, logicznego i fizycznego modelu danych.

Operacyjny punkt widzenia (OV)

OV-1 Grafika koncepcji operacyjnej wysokiego poziomu
Graficzny/tekstowy opis koncepcji operacyjnej wysokiego poziomu.
Opis przepływów zasobów operacyjnych OV-2
Opis przepływów zasobów wymienianych między działaniami operacyjnymi.
OV-3 Macierz przepływu zasobów operacyjnych
Opis wymienianych zasobów i odpowiednich atrybutów wymiany.
OV-4 Wykres relacji organizacyjnych
Kontekst organizacyjny, rola lub inne relacje między organizacjami.
OV-5a Drzewo dekompozycji działalności operacyjnej
Zdolności i czynności (działania operacyjne) zorganizowane w strukturę hierarchiczną.
OV-5b Model działalności operacyjnej
Kontekst zdolności i działań (działań operacyjnych) oraz ich relacje między działaniami, wejściami i wyjściami; Dodatkowe dane mogą pokazywać koszty, wykonawców lub inne istotne informacje.
OV-6a Model zasad operacyjnych
Jeden z trzech modeli służących do opisu działalności (działalności operacyjnej). Identyfikuje reguły biznesowe, które ograniczają operacje.
OV-6b State Transition Description
Jeden z trzech modeli służących do opisu czynności (aktywności) operacyjnej. Identyfikuje reakcje procesów biznesowych (działań) na zdarzenia (zwykle bardzo krótkie czynności).
OV-6c Event-Trace Description
Jeden z trzech modeli używanych do opisu aktywności (aktywności operacyjnej). Śledzi działania w scenariuszu lub sekwencji zdarzeń.

Punkt widzenia projektu (PV)

PV-1 Relacje portfela projektów
Opisuje relacje zależności między organizacjami i projektami oraz struktury organizacyjne potrzebne do zarządzania portfelem projektów.
Osie czasowe projektu PV-2
Perspektywa osi czasu dotycząca programów lub projektów, z kluczowymi kamieniami milowymi i współzależnościami.
PV-3 Odwzorowanie projektu na możliwości
Odwzorowanie programów i projektów na możliwości, aby pokazać, w jaki sposób poszczególne projekty i elementy programu pomagają osiągnąć zdolność.

Punkt widzenia usług (SvcV)

SvcV-1 Opis kontekstu usług
Identyfikacja usług, elementów usług i ich wzajemnych połączeń.
Opis przepływu zasobów usług SvcV-2
Opis przepływów zasobów wymienianych między usługami.
SvcV-3a Systems-Services Matrix
Relacje między systemami i usługami w danym Opisie Architektonicznym.
SvcV-3b Macierz Usługi-Usługi
Relacje pomiędzy usługami w danym Opisie Architektonicznym. Można go zaprojektować tak, aby pokazywał interesujące relacje (np. interfejsy typu usługi, interfejsy planowane i istniejące).
SvcV-4 Usługi Opis funkcjonalności
Funkcje wykonywane przez usługi oraz przepływ danych usługi pomiędzy funkcjami (czynnościami) usługi.
SvcV-5 Macierz identyfikowalności działań operacyjnych do usług
Mapowanie usług (działań) z powrotem do działań operacyjnych (działań).
SvcV-6 Macierz przepływu zasobów usług
Zawiera szczegółowe informacje na temat elementów przepływu zasobów usług wymienianych między usługami oraz atrybutów tej wymiany.
SvcV-7 Macierz miar usług Miary
(metryki) elementów modelu usług dla odpowiednich ram czasowych.
SvcV-8 Ewolucja usług Opis
Planowane stopniowe kroki w kierunku migracji pakietu usług do bardziej wydajnego pakietu lub w kierunku ewolucji obecnych usług do przyszłej implementacji.
SvcV-9 Usługi Prognoza dotycząca technologii i umiejętności
Pojawiające się technologie, oprogramowanie/sprzęt oraz umiejętności, które mają być dostępne w określonych ramach czasowych i które wpłyną na przyszły rozwój usług.
SvcV-10a Model reguł usług
Jeden z trzech modeli używanych do opisu funkcjonalności usług. Identyfikuje ograniczenia nałożone na funkcjonalność systemów ze względu na niektóre aspekty projektowania lub wdrażania systemu.
SvcV-10b Opis przejścia stanu usług
Jeden z trzech modeli używanych do opisu funkcjonalności usługi. Identyfikuje reakcje służb na zdarzenia.
SvcV-10c Services Event-Trace Description
Jeden z trzech modeli używanych do opisu funkcjonalności usługi. Identyfikuje specyficzne dla usługi udoskonalenia krytycznych sekwencji zdarzeń opisanych w operacyjnym punkcie widzenia.

Punkt widzenia standardów (StdV)

Profil standardów StdV-1
Lista standardów, które mają zastosowanie do elementów rozwiązania. W DoDAF V1.5 był to TV-1.
Prognoza standardów StdV-2
Opis pojawiających się standardów i potencjalnego wpływu na obecne elementy rozwiązania, w określonych ramach czasowych. W DoDAF V1.5 był to TV-2.

Punkt widzenia systemów (SV)

SV-1 Systems Interface Opis
Identyfikacja systemów, elementów systemu i ich wzajemnych połączeń.
Systemy SV-2 Opis przepływu zasobów
Opis przepływów zasobów wymienianych między systemami.
SV-3 Macierz Systemów-Systemów
Relacje pomiędzy systemami w danym Opisie Architektonicznym. Można go zaprojektować tak, aby pokazywał interesujące relacje (np. interfejsy systemowe, interfejsy planowane i istniejące).
SV-4 Opis funkcjonalności systemów
Funkcje (czynności) wykonywane przez systemy oraz przepływ danych systemowych pomiędzy funkcjami (czynnościami) systemu.
SV-5a Macierz identyfikowalności działań operacyjnych do funkcji systemów
Odwzorowanie funkcji (działań) systemu z powrotem do działań (działań) operacyjnych.
SV-5b Macierz identyfikowalności działań operacyjnych do systemów
Odwzorowanie systemów z powrotem do zdolności lub działań operacyjnych (działań).
SV-6 Macierz przepływu zasobów systemowych
Zawiera szczegółowe informacje o elementach przepływu zasobów systemowych wymienianych między systemami oraz atrybuty tej wymiany.
SV-7 Macierz miar systemów Miary
(metryki) elementów modelu systemów dla odpowiednich ram czasowych.
SV-8 Systems Evolution Opis
Planowane stopniowe kroki w kierunku migracji pakietu systemów do bardziej wydajnego pakietu lub w kierunku ewolucji obecnego systemu do przyszłej implementacji.
SV-9 Systems Technology & Skills Prognoza
Pojawiające się technologie, oprogramowanie/sprzęt oraz umiejętności, które mają być dostępne w określonych ramach czasowych i które wpłyną na przyszły rozwój systemu.
SV-10a Model reguł systemowych
Jeden z trzech modeli używanych do opisu funkcjonalności systemu. Identyfikuje ograniczenia nałożone na funkcjonalność systemów ze względu na niektóre aspekty projektowania lub wdrażania systemu.
SV-10b Systems State Transition Description
Jeden z trzech modeli używanych do opisu funkcjonalności systemu. Identyfikuje reakcje systemów na zdarzenia.
SV-10c Systems Event-Trace Description
Jeden z trzech modeli używanych do opisu funkcjonalności systemu. Identyfikuje specyficzne dla systemu udoskonalenia krytycznych sekwencji zdarzeń opisanych w operacyjnym punkcie widzenia.

Tworzenie zintegrowanej architektury z wykorzystaniem DoDAF

Ilustracja zintegrowanej architektury.

Przewodnik architektów DODAF 2.0 powtórzył instrukcję DOD 4630.8, definiując architekturę zintegrowaną jako „Architekturę składającą się z wielu widoków ułatwiających integrację i promującą interoperacyjność w zakresie możliwości i architektur zintegrowanych. Dla celów rozwoju architektury termin zintegrowany oznacza, że ​​dane wymagane w bardziej niż jeden z modeli architektonicznych jest powszechnie zdefiniowany i rozumiany w ramach tych modeli.Zintegrowane architektury są właściwością lub zasadą projektową dla architektur na wszystkich poziomach: możliwości, komponentu, rozwiązania i przedsiębiorstwa (w kontekście DoD Enterprise Architecture (EA) federacja architektur. Mówiąc prościej, integracja jest postrzegana jako połączenie elementów wspólnych dla produktów architektonicznych, gdzie elementy pokazane w jednym produkcie architektonicznym (takie jak używane witryny lub połączone systemy lub świadczone usługi) powinny mieć identyczny numer, nazwa i znaczenie pojawiają się w powiązanych widokach produktów związanych z architekturą”.

Istnieje wiele różnych podejść do tworzenia zintegrowanej architektury przy użyciu DoDAF i określania, które produkty są wymagane. Podejście zależy od wymagań i oczekiwanych rezultatów; tj. do czego będzie używana wynikowa architektura. Jako przykład, DoDAF v1.0 wymienił następujące produkty jako „minimalny zestaw produktów wymaganych do spełnienia definicji OV, SV i TV”. Jedna uwaga: chociaż DoDAF nie wymienia artefaktu OV-1 jako podstawowego produktu, zdecydowanie zaleca się jego rozwój. Kolejność artefaktów wymienionych poniżej daje sugerowaną kolejność, w jakiej artefakty mogą zostać opracowane. Rzeczywista kolejność generowania widoków i ich ewentualnego dostosowywania jest funkcją domeny aplikacji i specyficznych potrzeb nakładu.

  • AV-1: Informacje ogólne i podsumowujące
  • AV-2: zintegrowany słownik
  • OV-1: Grafika koncepcyjna wysokiego poziomu operacyjnego
  • OV-5: Model działalności operacyjnej
  • OV-2: Opis połączenia węzła operacyjnego
  • OV-3: Matryca wymiany informacji operacyjnych
  • SV-1: Opis interfejsu systemowego
  • TV-1: Profil standardów technicznych

Jedną z obaw związanych z DoDAF jest to, jak dobrze te produkty spełniają rzeczywiste obawy interesariuszy dla dowolnego systemu będącego przedmiotem zainteresowania. Można przeglądać produkty DoDAF lub przynajmniej 3 widoki jako punkty widzenia ANSI/IEEE 1471-2000 lub ISO/IEC 42010 . Aby jednak zbudować opis architektury zgodny z normą ANSI/IEEE 1471-2000 lub ISO/IEC 42010, konieczne jest jasne zidentyfikowanie interesariuszy i ich obaw związanych z każdym wybranym produktem DoDAF. W przeciwnym razie istnieje ryzyko wytwarzania produktów bez klientów.

Matryca produktów DoDAF V1.5

Rysunek „Matryca produktów DoDAF V1.5” pokazuje, w jaki sposób przewodniczący DoD w instrukcji Połączonych Szefów Sztabów (CJCSI) 6212.01E określa, które produkty DoDAF V1.5 są wymagane dla każdego typu analizy, w kontekście Net-Ready Kluczowy parametr wydajności (NR-KPP):

  • Wstępny dokument zdolności (ICD). Dokumentuje potrzebę rozwiązania materiałowego dla określonej luki w zdolnościach, wynikającej ze wstępnej analizy alternatyw przeprowadzonej przez użytkownika operacyjnego i, w razie potrzeby, z niezależnej analizy alternatyw. Określa lukę zdolnościową w zakresie obszaru funkcjonalnego, odpowiedniego zasięgu operacji wojskowych, pożądanych efektów i czasu.
  • Dokument rozwoju zdolności (CDD). Dokument, który zawiera informacje niezbędne do opracowania proponowanego programu (programów), zwykle przy użyciu ewolucyjnej strategii pozyskiwania. CDD przedstawia przystępny cenowo przyrost użytecznych militarnie, logistycznie wspieranych i technicznie dojrzałych zdolności.
  • Dokument produkcji zdolności (CPD). Dokument odnoszący się do elementów produkcji specyficznych dla pojedynczego przyrostu programu akwizycji.
  • Plan wsparcia informacyjnego (ISP). Identyfikacja i dokumentacja potrzeb informacyjnych, wsparcia infrastruktury, wymagań i zależności interfejsów IT i NSS, koncentrując się na problemach sieciocentrycznych, interoperacyjności, obsługi technicznej i wystarczalności (DODI 4630.8).
  • Dostosowany plan wsparcia informacyjnego (TISP). Celem procesu TISP jest zapewnienie dynamicznego i wydajnego narzędzia dla niektórych programów (ACAT II i niższych) w celu stworzenia wymagań niezbędnych do certyfikacji I&S. Wybrani menedżerowie programów mogą poprosić o dostosowanie treści swojego dostawcy usług internetowych (ref ss). W przypadku programów, które nie zostały określone przez ASD (NII) /DOD CIO jako szczególnie interesujące OSD, komponent podejmie ostateczną decyzję w sprawie szczegółów dostosowanego planu z zastrzeżeniem minimum określonego w procedurach TISP, do których łącza znajdują się na stronie zasobów CJCSI 6212, oraz wszelkich specjalnych potrzeb zidentyfikowanych przez J-6 dla procesu certyfikacji I&S.

Reprezentacja

Reprezentacje produktów DoDAF można czerpać z wielu technik tworzenia diagramów, w tym:

OMG podejmowane są działania UPDM (Unified Profile for DoDAF and MODAF) mające na celu standaryzację reprezentacji produktów DoDAF, gdy używany jest język UML.

DoDAF ogólnie opisuje w reprezentacji artefaktów, które mają zostać wygenerowane, ale pozwala na znaczną elastyczność w odniesieniu do określonych formatów i technik modelowania. Podręcznik DoDAF zawiera przykłady wykorzystania tradycyjnych inżynierii systemów i inżynierii danych , a po drugie formatu UML. DoDAF głosi swobodę w formacie produktu roboczego, bez wyznawania jednej techniki tworzenia diagramów nad drugą.

Oprócz reprezentacji graficznej zazwyczaj wymagane jest dostarczenie metadanych do Repozytorium Portfela Technologii Obronnych (DITPR) lub innych repozytoriów architektury.

Meta-model

DoDAF ma metamodel leżący u podstaw struktury, definiujący typy elementów modelowania, które można wykorzystać w każdym widoku, oraz relacje między nimi. Wersje DoDAF od 1.0 do 1.5 wykorzystywały metamodel CADM , który został zdefiniowany w IDEF1X (później w UML) ze schematem XML pochodzącym z wynikowej relacyjnej bazy danych. Od wersji 2.0 firma DoDAF przyjęła IDEAS Group jako podstawę swojego nowego meta-modelu. Ten nowy meta-model nosi nazwę „DM2”; skrót od „Meta-modelu DoDAF”. Każdy z tych trzech poziomów DM2 jest ważny dla konkretnego obserwatora procesów departamentalnych:

  1. Poziom koncepcyjny lub koncepcyjny model danych (CDM) definiuje konstrukcje danych wysokiego poziomu, z których tworzone są opisy architektoniczne w kategoriach nietechnicznych, dzięki czemu dyrektorzy i menedżerowie na wszystkich poziomach mogą zrozumieć podstawę danych opisu architektonicznego. Reprezentowane w punkcie widzenia DoDAF V2.0 DIV-1.
  2. Logiczny model danych (LDM) dodaje informacje techniczne, takie jak atrybuty do CDM i, jeśli to konieczne, wyjaśnia relacje w jednoznacznej definicji użytkowania. Reprezentowane w punkcie widzenia DoDAF V2.0 DIV-2.
  3. Specyfikacja Wymiany Fizycznej (PES) składa się z LDM z określonymi ogólnymi typami danych i dodanymi atrybutami implementacji (np. źródło, data), a następnie wygenerowany jako XSD. Reprezentowane w punkcie widzenia DoDAF V2.0 DIV-3.

Celem DM2 jest:

  1. Ustal i zdefiniuj ograniczone słownictwo do opisu i dyskusji na temat modeli DoDAF (dawniej „produkty”) i ich wykorzystania w 6 podstawowych procesach
  2. Określ semantykę i format federacyjnej wymiany danych EA między: narzędziami do opracowywania i analizowania architektury oraz bazami danych architektury w ramach społeczności zainteresowań (COI) DoD Enterprise Architecture (EA) oraz z innymi autorytatywnymi źródłami danych
  3. Wsparcie w wykrywaniu i zrozumiałości danych EA:
    1. Odkrywanie danych EA przy użyciu kategorii informacji DM2
    2. Zrozumiałość danych EA przy użyciu precyzyjnej semantyki DM2, uzupełnionej o identyfikowalność językową (aliasy)
  4. Zapewnij podstawę semantycznej precyzji w opisach architektury, aby wspierać heterogeniczną integrację opisów architektury i analizę wspierającą podejmowanie kluczowych decyzji procesowych.

DM2 definiuje elementy danych architektonicznych i umożliwia integrację i federację opisów architektonicznych. Ustanawia podstawę dla semantycznej (tj. rozumienia) spójności wewnątrz i pomiędzy Opisami Architektonicznymi. W ten sposób DM2 wspiera wymianę i ponowne wykorzystanie informacji architektonicznych między JCA, komponentami oraz partnerami federalnymi i koalicyjnymi, ułatwiając w ten sposób zrozumienie i wdrożenie interoperacyjności procesów i systemów. W miarę dojrzewania DM2, aby sprostać bieżącym wymaganiom właścicieli procesów, decydentów, architektów i nowych technologii, ewoluuje do zasobu, który pełniej obsługuje wymagania dotyczące danych architektonicznych, publikowanych w konsekwentnie zrozumiały sposób i umożliwi większą łatwość odkrywania, udostępniania i ponownego wykorzystywania danych architektonicznych ponad granicami organizacji.

Aby ułatwić korzystanie z informacji w warstwie danych, DoDAF opisuje zestaw modeli do wizualizacji danych za pomocą środków graficznych, tabelarycznych lub tekstowych. Poglądy te odnoszą się do wymagań interesariuszy dotyczących sporządzenia Opisu Architektonicznego.

Związek z innymi frameworkami architektury

UPDM (Unified Profile for DoDAF and MODAF ) to inicjatywa OMG mająca na celu standaryzację użycia UML i SysML w ramach architektury obronnej USA i Wielkiej Brytanii . Ponadto wielonarodowa grupa IDEAS , wspierana przez Australię, Kanadę, Szwecję, Wielką Brytanię, USA oraz obserwatorów z NATO , podjęła inicjatywę opracowania formalnej ontologii dla architektur korporacyjnych.

Zobacz też


Dalsza lektura

  •   Dennis E. Wisnosky i Joseph Vogel. Dodaf Wizdom: praktyczny przewodnik po planowaniu, zarządzaniu i wykonywaniu projektów budowania architektur korporacyjnych przy użyciu struktury architektury Departamentu Obrony . Wizdom Systems, Inc., 2004. ISBN 1-893990-09-5 .
  •   Dr Steven H. Dam (2015). DoD Architecture Framework 2.0: przewodnik po stosowaniu inżynierii systemów do tworzenia zintegrowanych, wykonywalnych architektur . Niezależna platforma wydawnicza CreateSpace, 2015. ISBN 1-502757-62-1 .

Linki zewnętrzne

  • CJCSI 6212.01 Seria
  • Ramy architektoniczne Europejskiej Agencji Kosmicznej (ESAAF) - ramy dla europejskich kosmicznych systemów systemów [1]
Pobrano z „ https://en.wikipedia.org/w/index.php?title=Department_of_Defense_Architecture_Framework&oldid=1121090334 ”