Departament Architektury Obronnej Framework - Department of Defense Architecture Framework

Struktura architektury DoD v1.5.
Struktura architektury DoDAF w wersji 2.0

Departament Obrony Architecture Framework ( DoDAF ) stanowi ramy architektury na Departament Obrony Stanów Zjednoczonych (DoD), który zapewnia infrastrukturę wizualizacji konkretne obawy interesariuszy poprzez poglądów organizowanych przez różne widoki . Widoki te są artefaktami do wizualizacji, zrozumienia i przyswojenia szerokiego zakresu i złożoności opisu architektury za pomocą środków tabelarycznych , strukturalnych , behawioralnych , ontologicznych , obrazowych , czasowych , graficznych , probabilistycznych lub alternatywnych środków koncepcyjnych . Obecna wersja to DoDAF 2.02.

Ta struktura architektury jest szczególnie odpowiednia dla dużych systemów ze złożonymi wyzwaniami w zakresie integracji i interoperacyjności i najwyraźniej jest wyjątkowa pod względem wykorzystania „widoków operacyjnych”. Widoki te oferują przegląd i szczegóły skierowane do konkretnych interesariuszy w ich domenie oraz w interakcji z innymi dziedzinami, 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 dla zrozumienia, porównywania i integracji architektur ponad granicami organizacyjnymi, wspólnymi i międzynarodowymi. Ustanawia definicje, reguły i relacje elementów danych oraz podstawowy zestaw produktów do spójnego rozwoju systemów, architektur zintegrowanych lub federacyjnych. Te opisy architektury mogą obejmować rodziny systemów (FoS), systemy systemów (SoS) oraz możliwości sieciocentryczne do 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 stopniu przy opracowywaniu architektur w Departamencie. Zgodność zapewnia, że ​​ponowne wykorzystanie informacji, artefaktów architektury, modeli i punktów widzenia może być dzielone z powszechnym zrozumieniem. Wszystkie główne przejęcia broni i systemów informatycznych Departamentu Obrony USA są wymagane do opracowania i udokumentowania architektury korporacyjnej (EA) przy użyciu widoków określonych w DoDAF. Chociaż jest wyraźnie ukierunkowany na systemy wojskowe, DoDAF ma szerokie zastosowanie w sektorach prywatnym, publicznym i wolontariackim na całym świecie i stanowi jedną z wielu struktur architektury systemów .

  • Celem DoDAF jest zdefiniowanie pojęć i modeli, które można wykorzystać 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 obrony (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 to:
    1. Ustanowienie wskazówek dotyczących zawartości architektury w funkcji celu - „nadaje się do celu”
    2. Zwiększ użyteczność i efektywność architektur dzięki rygorystycznemu modelowi danych — DoDAF Meta Model (DM2) — dzięki czemu architektury można 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 rozwojowego DoDAF została opracowana w latach 90. pod nazwą C4ISR Architecture Framework. W tym samym okresie model referencyjny TAFIM , który został zainicjowany w 1986 roku, był dalej rozwijany. Pierwszy C4ISR Architecture Framework v1.0, wydany 7 czerwca 1996, został stworzony w odpowiedzi na uchwalenie ustawy Clinger-Cohen . Odniosła się do dyrektywy zastępcy sekretarza obrony z 1995 r., Zgodnie z którą należy podjąć wysiłki w skali DoD w celu zdefiniowania i opracowania lepszych środków i procesu w celu zapewnienia interoperacyjności zdolności C4ISR i zaspokojenia potrzeb wojownika. Kontynuacja prac rozwojowych zaowocowała w grudniu 1997 drugą wersją, C4ISR Architecture Framework v2.0.

W sierpniu 2003 r. wydano DoDAF v1.0, który zrestrukturyzował C4ISR Framework v2.0, oferując wskazówki, opisy produktów i informacje uzupełniające w dwóch tomach oraz Księgę. Rozszerzył zastosowanie zasad i praktyk architektonicznych na wszystkie obszary misji, a nie tylko na społeczność C4ISR. Dokument ten dotyczył użycia, zintegrowanych architektur, polityk DoD i federalnych, wartości architektur, środków architektury, procesów wspomagania decyzji DoD, technik rozwoju, technik analitycznych i CADM v1.01, a także przeszedł w kierunku podejścia opartego na repozytorium, kładąc nacisk na elementy danych architektury, które składają się na produkty architektury. W lutym 2004 r. Ukazała się dokumentacja wersji 1.0 z tomami „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” i „Opis danych architektonicznych”.

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

Inne pochodne struktury oparte na DoDAF obejmują NATO Architecture Framework (NAF) i Ministerstwo Obrony Architecture Framework . Podobnie jak inne podejścia EA, na przykład Open Group Architecture Framework (TOGAF), DoDAF jest zorganizowany wokół wspólnego repozytorium w celu 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 seria poziomów zwanych Poziomami Interoperacyjności Systemów Informacyjnych (LISI). Rozwijający się system musi nie tylko zaspokajać swoje wewnętrzne potrzeby w zakresie danych, ale także ramy operacyjne, w których jest osadzony.

Możliwości i misja

Zobacz diagram, aby przedstawić nacisk na możliwości, powiązany z misją / przebiegiem działania, wątkami, działaniami i architekturą.

Możliwości opisane w architekturach

DoD skoncentrował się na dostarczaniu możliwości, które są powodem tworzenia systemu/usługi. Modele zdolności opisują taksonomię zdolności i ewolucję zdolności. Wątek zdolności odpowiadałby określonym czynnościom, regułom i systemom, które są powiązane z tą konkretną zdolnością.

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

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

Misja lub Kierunek Działania jest opisany przez Koncepcję Operacji (CONOPS) i jest zorganizowany przez Zdolności.

  • Możliwości są opisane przez Wątki.
  • Wątki są opisane 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

Powiązania DoDAF V1.5 wśród widoków.
Struktura DoD C4ISR

DoDAF V1.5 definiuje zestaw produktów, model widoku , które działają jako mechanizmy wizualizacji, zrozumienia i przyswojenia szerokiego zakresu i złożoności opisu architektury za pomocą środków graficznych, tabelarycznych lub tekstowych. Produkty te są podzielone na cztery widoki:

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

Każdy widok przedstawia pewne perspektywy architektury, jak opisano poniżej. Dla każdego rozwoju systemu tworzony jest zwykle 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. Trzy widoki i ich wzajemne powiązania – oparte na elementach danych o wspólnej architekturze – stanowią podstawę do wyprowadzenia miar, takich jak interoperacyjność lub wydajność, oraz do pomiaru wpływu wartości tych wskaźników na skuteczność misji operacyjnej i zadań.

Wszystkie widoki

Wszystkie produkty z widokiem (AV) dostarczają nadrzędnych opisów całej architektury oraz definiują zakres i kontekst architektury. Produkty DoDAF V1.5 AV są zdefiniowane jako:

Przegląd AV-1 i informacje podsumowujące
Zakres, cel, zamierzeni użytkownicy, przedstawione środowisko, wyniki analizy (jeśli dotyczy)
Zintegrowany słownik AV-2
Definicje wszystkich terminów używanych we wszystkich produktach.

Widok operacyjny

Produkty z widokiem operacyjnym (OV) zawierają opisy zadań i czynności, 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:

Grafika koncepcyjna operacyjna wysokiego poziomu OV-1
Graficzny i tekstowy opis koncepcji operacyjnej na wysokim poziomie (organizacje wysokiego szczebla, misje, konfiguracja geograficzna, łączność itp.).
OV-2 Opis łączności węzła operacyjnego
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 Schemat relacji organizacyjnych
Dowodzenie, 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ć koszt, działające węzły lub inne istotne informacje.
OV-6a Model reguł operacyjnych
Jeden z trzech produktów używanych do opisywania kolejności i harmonogramu działań operacyjnych, który identyfikuje reguły biznesowe ograniczające operację.
OV-6b Opis przejścia stanu operacyjnego
Jeden z trzech produktów używanych do opisywania sekwencji i harmonogramu działań operacyjnych, który identyfikuje reakcje procesu biznesowego na zdarzenia.
OV-6c Operacyjny opis śledzenia zdarzeń
Jeden z trzech produktów używanych do opisywania sekwencji działań operacyjnych i harmonogramu, który śledzi działania w scenariuszu lub krytycznej sekwencji zdarzeń.
Model danych logicznych OV-7
Dokumentacja wymagań dotyczących danych i reguł strukturalnych procesów biznesowych Widoku Operacyjnego. (W DoDAF V1.5. Odpowiada to DIV-2 w DoDAF V2.0.)

Widok systemów i usług

Widok systemów i usług (SV) to zestaw produktów graficznych i tekstowych, 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. Przykładem związku między elementami danych architektury w całym SV a OV może być zamawianie i rozmieszczanie systemów w celu wspierania organizacji i ich operacji. Produkty DoDAF V1.5 SV to:

Opis interfejsu systemów/usług SV-1
Przedstawia węzły systemów i systemy znajdujące się w tych węzłach, aby wspierać organizacje / role ludzkie reprezentowane przez węzły operacyjne OV-2. SV-1 identyfikuje również interfejsy między systemami i węzłami systemów.
Opis komunikacji systemów/usług SV-2
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 zgodnie z opisem w SV-1. W ten sposób SV-2 pokazuje szczegóły komunikacji interfejsów SV-1, które automatyzują aspekty igieł reprezentowanych w OV-2.
SV-3 Systemy-Systemy, Usługi-Systemy, Usługi-Macierze usług
zawiera szczegółowe informacje o charakterystyce interfejsu opisanej w SV-1 dla architektury, uporządkowane w formie macierzowej.
Opis funkcjonalności systemów / usług SV-4a / SV-4b
SV-4a dokumentuje hierarchie funkcjonalne systemu i funkcje systemu, a dane systemowe przepływają 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 macierz śledzenia aktywności operacyjnej systemu ( SV-5a), który zapewnia to odwzorowanie.
SV-5a, SV-5b, SV-5c Od aktywności operacyjnej do funkcji systemów, od aktywności operacyjnej do macierzy śledzenia systemów i usług
Aktywność operacyjna do SV-5a i SV-5b to specyfikacja relacji pomiędzy zbiorem czynności operacyjnych mających zastosowanie do architektury a zbiorem funkcji systemowych mających zastosowanie do tej architektury. SV-5 i rozszerzenie SV-5 z DoDAF v1.0 są 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. Ten produkt skupia się na automatycznej wymianie informacji (z OV-3), które są zaimplementowane w systemach. Nieautomatyczna wymiana informacji, taka jak zamówienia ustne, jest rejestrowana tylko w produktach OV.
SV-7 Macierz parametrów wydajności systemów/usług
Określa ilościową charakterystykę systemów i elementów sprzętu/oprogramowania systemu, ich interfejsów (dane systemowe przenoszone przez interfejs oraz szczegóły łącza komunikacyjnego implementującego 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 wydajności obejmują wszystkie techniczne charakterystyki wydajności systemów, dla których można opracować wymagania i zdefiniować specyfikację. Kompletny zestaw parametrów wydajności może nie być znany na wczesnych etapach definiowania architektury, dlatego należy oczekiwać, że produkt ten będzie aktualizowany przez cały okres specyfikacji systemu, projektowania, rozwoju, testowania, a być może nawet jego wdrożenia i cyklu życia operacji fazy.
Opis ewolucji systemów/usług SV-8
Przechwytuje plany ewolucji, które opisują, w jaki sposób system lub architektura, w której jest osadzony, będzie ewoluować w dłuższym okresie czasu. Ogólnie rzecz biorąc, kamienie milowe na osi czasu mają kluczowe znaczenie dla pomyślnego zrozumienia osi czasu ewolucji.
SV-9 Prognoza technologii systemów/usług Technology
Definiuje podstawowe bieżące i oczekiwane technologie wspomagające, które zostały ukierunkowane przy użyciu standardowych metod prognozowania. Oczekiwane technologie wspomagające to takie, które można rozsądnie przewidzieć, biorąc pod uwagę obecny stan technologii i oczekiwane ulepszenia. Nowe technologie powinny być powiązane z określonymi przedziałami czasowymi, które mogą korelować z okresami stosowanymi w kamieniach milowych SV-8.
Model reguł systemów/usług SV-10a
Opisuje zasady, zgodnie z którymi architektura lub jej systemy zachowują się w określonych warunkach.
SV-10b Opis przejścia między stanami systemów/usług
Graficzna metoda opisu reakcji systemu (lub funkcji systemu) na różne zdarzenia poprzez zmianę jego stanu. Diagram zasadniczo przedstawia zbiory zdarzeń, na które zareagują systemy w architekturze (podejmując akcję przejścia do nowego stanu) w zależności od jego aktualnego stanu. Każde przejście określa zdarzenie i akcję.
SV-10c Systemy/usługi Opis śledzenia zdarzeń Event
Zapewnia uporządkowane w czasie badanie elementów danych systemu wymienianych między uczestniczącymi systemami (zewnętrznymi i wewnętrznymi), funkcjami systemu 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.
Schemat fizyczny SV-11
Jeden z produktów architektonicznych najbardziej zbliżony do rzeczywistego projektu systemu w Framework. Produkt definiuje strukturę różnego rodzaju 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 implementacyjne, reguły biznesowe i kryteria rządzące architekturą. Produkty telewizyjne DoDAF V1.5 to:

  • Profil Standardów Technicznych StdV-1 - Wyodrębnienie standardów mających zastosowanie do danej architektury. (W DoDAF V1.5. Zmieniona na StdV-1 w DoDAF V2.0.)
  • Prognoza dotycząca standardów technicznych StdV-2 — opis pojawiających się standardów, które mają mieć zastosowanie do danej architektury w odpowiednich ramach czasowych. (W DoDAF V1.5. Zmieniona na StdV-2 w DoDAF V2.0.)

Punkty widzenia w wersji 2.0

Schemat punktów widzenia DoDAF V2.0.
Ewolucja poglądów DoDAF V1.5 do punktów widzenia DoDAF V2.0.
Mapowanie widoków DoDAF V1.5 do punktów widzenia DoDAF V2.0.

W DoDAF v2.0 punkty widzenia architektury składają się z danych, które zostały zorganizowane w celu ułatwienia zrozumienia. Aby dostosować się do norm ISO, tam gdzie to właściwe, zmieniono terminologię z Widoków na Punkt Widzenia (np. Widok Operacyjny jest teraz Punktem Widzenia Operacyjnego).

Wszystkie punkty widzenia (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 możliwości, harmonogram dostarczania i wdrożoną zdolność.
Punkt widzenia danych i informacji (DIV)
Nowość w DoDAF 2.0. Przedstawia relacje danych i struktury wyrównania w treści architektury pod kątem możliwości i wymagań operacyjnych, procesów inżynierii systemów oraz systemów i usług.
Operacyjny punkt widzenia (OV)
Obejmuje scenariusze operacyjne, działania i wymagania, które obsługują możliwości.
Punkt widzenia projektu (PV)
Nowość w DoDAF V2.0. Opisuje relacje między wymaganiami operacyjnymi i wymaganiami dotyczącymi zdolności a różnymi wdrażanymi projektami. Punkt widzenia projektu wyszczególnia również zależności między możliwościami i wymaganiami operacyjnymi, procesami inżynierii systemów, projektowaniem systemów i projektowaniem usług w ramach procesu Defense Acquisition System.
Punkt widzenia usług (SvcV)
Nowość w DoDAF 2.0. Przedstawia projekt rozwiązań dotyczących wykonawców, działań, usług i ich wymian, zapewniających lub wspierających funkcje operacyjne i zdolności.
Punkt widzenia norm (StdV)
Zmieniono nazwę z widoku standardów technicznych. Przedstawia obowiązujące zasady, standardy, wytyczne, ograniczenia i prognozy operacyjne, biznesowe, techniczne i branżowe, które mają zastosowanie do wymagań dotyczących zdolności i wymagań operacyjnych, procesów inżynierii systemów oraz systemów i usług.
Punkt widzenia systemów (SV)
Przedstawia, na potrzeby wsparcia starszego , projekt rozwiązań artykulujących systemy, ich skład, wzajemną łączność 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 teraz definiowany w ogólnym sensie zespołu komponentów - maszyny, człowieka - które wykonują czynności (ponieważ są podtypami Wykonawcy) i są oddziałujące lub współzależne. Może to być wszystko, od małych elementów wyposażenia, które mają oddziałujące lub współzależne elementy, po rodzinę systemów (FoS) i system systemów (SoS). Należy zauważyć, że systemy składają się z materiałów (np. sprzętu, samolotów i statków) oraz typów personelu.

Architektury dla DoDAF V1.0 i DoDAF V1.5 mogą być nadal używane. Gdy jest to właściwe (zazwyczaj wskazane przez politykę lub decydenta), architektury DoDAF V1.0 i V1.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 koncepcyjne (takie jak węzeł) dla nowszej architektury. Jeśli chodzi o produkty 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: Węzeł. Węzeł to złożona, logiczna koncepcja reprezentowana przez bardziej konkretne koncepcje.

Wszystkie punkty widzenia (AV)

Przegląd AV-1 i informacje podsumowujące
Opisuje wizje, cele, zamierzenia, plany, działania, zdarzenia, 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
Rozwiązuje problemy przedsiębiorstwa związane z ogólną wizją przedsięwzięć transformacyjnych, a tym samym określa kontekst strategiczny dla grupy zdolności. Celem CV-1 jest zapewnienie strategicznego kontekstu dla możliwości opisanych w Opisie Architektury.
Taksonomia zdolności CV-2
Przechwytuje taksonomie zdolności. Model przedstawia hierarchię możliwości. Te możliwości 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 Zdolność Fazowanie
Planowane osiągnięcie zdolności w różnych momentach lub w określonych okresach czasu. CV-3 pokazuje etapy zdolności w zakresie 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
Zależności zdolności CV-4
Zależności między planowanymi zdolnościami a definicją logicznych grup zdolności.
CV-5 Zdolność do mapowania rozwoju organizacyjnego
Spełnienie wymagań w zakresie zdolności pokazuje planowane rozmieszczenie zdolności i połączenia dla konkretnej 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 Zdolność do mapowania działań operacyjnych
Mapowanie między wymaganymi zdolnościami a działaniami operacyjnymi wspieranymi przez te zdolności.
CV-7 Zdolność do mapowania usług
Mapowanie między możliwościami i usługami, które umożliwiają te możliwości.

Punkt widzenia danych i informacji (DIV)

DIV-1 Koncepcyjny model danych
Wymagane koncepcje danych wysokiego poziomu i ich relacje.
DIV-2 Model danych logicznych
Dokumentacja wymagań dotyczących danych i reguł strukturalnych procesu biznesowego (działania). W DoDAF V1.5 był to OV-7.
Model danych fizycznych DIV-3
Fizyczny format implementacji encji Logicznego Modelu Danych, np. formaty komunikatów, struktury plików, schemat fizyczny. W DoDAF V1.5 był to SV-11.

Uwaga, patrz Logiczny model danych, aby omówić relacje między tymi trzema modelami danych DIV, z porównaniem modeli danych koncepcyjnych, logicznych i fizycznych.

Operacyjny punkt widzenia (OV)

Grafika koncepcyjna operacyjna wysokiego poziomu OV-1
Graficzny/tekstowy opis koncepcji operacyjnej wysokiego poziomu.
OV-2 Opis przepływu zasobów operacyjnych
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 wymian.
OV-4 Schemat relacji organizacyjnych
Kontekst organizacyjny, rola lub inne relacje między organizacjami.
OV-5a Drzewo dekompozycji działań operacyjnych
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, wkładami i wynikami; Dodatkowe dane mogą pokazywać koszty, wykonawców lub inne istotne informacje.
OV-6a Model reguł operacyjnych
Jeden z trzech modeli stosowanych do opisu działalności (działalność operacyjna). Identyfikuje reguły biznesowe, które ograniczają operacje.
Opis przejścia stanu OV-6b
Jeden z trzech modeli stosowanych do opisu działalności operacyjnej (działalności). Identyfikuje reakcje procesu biznesowego (czynności) na zdarzenia (zwykle są to bardzo krótkie czynności).
OV-6c Opis śledzenia zdarzeń
Jeden z trzech modeli stosowanych do opisu działalności (działalność operacyjna). Śledzi działania w scenariuszu lub sekwencji zdarzeń.

Punkt widzenia projektu (PV)

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

Punkt widzenia usług (SvcV)

Opis kontekstu usług SvcV-1
Identyfikacja usług, pozycji 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.
Macierz usług systemów SvcV-3a
Relacje pomiędzy lub pomiędzy systemami i usługami w danym Opisie Architektonicznym.
SvcV-3b macierz usług-usług
Relacje mię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).
Opis funkcji usług SvcV-4
Funkcje realizowane przez serwisy oraz dane serwisowe przepływają pomiędzy funkcjami serwisowymi (czynnościami).
SvcV-5 Działalność operacyjna do macierzy śledzenia usług
Mapowanie usług (działań) z powrotem na czynności operacyjne (działania).
Macierz przepływu zasobów usług SvcV-6
Zawiera szczegóły dotyczące elementów przepływu zasobów usługi wymienianych między usługami i atrybutów tej wymiany.
SvcV-7 Usługi Miary Matrycy
Miary (metryki) elementów Modelu Usług dla odpowiednich ram czasowych.
Opis ewolucji usług SvcV-8
Planowane stopniowe kroki w kierunku migracji pakietu usług do bardziej wydajnego pakietu lub ewolucji obecnych usług do przyszłej implementacji.
SvcV-9 Usługi Prognoza technologii i umiejętności Skill
Nowe technologie, oprogramowanie/produkty sprzętowe i umiejętności, które mają być dostępne w określonych ramach czasowych i które będą miały wpływ na przyszły rozwój usług.
Model zasad usług SvcV-10a
Jeden z trzech modeli używanych do opisu funkcjonalności usługi. Identyfikuje ograniczenia, które są nałożone na funkcjonalność systemu ze względu na pewien aspekt projektu lub wdrożenia systemu.
Opis przejścia stanu usług SvcV-10b
Jeden z trzech modeli używanych do opisu funkcjonalności usługi. Identyfikuje reakcje służb na zdarzenia.
Opis śledzenia zdarzeń usług SvcV-10c
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 norm (StdV)

Profil standardów StdV-1
Lista norm mających zastosowanie do elementów rozwiązania. W DoDAF V1.5 był to TV-1.
Prognoza standardów StdV-2
Opis powstających 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)

Opis interfejsu systemów SV-1
Identyfikacja systemów, elementów systemu i ich wzajemnych połączeń.
Opis przepływu zasobów w systemach SV-2
Opis przepływów zasobów wymienianych między systemami.
SV-3 Systems-Macierz systemów
Relacje między systemami w danym opisie architektonicznym. Można go zaprojektować tak, aby pokazywał interesujące relacje (np. interfejsy typu systemowego, interfejsy planowane i istniejące).
Opis funkcji systemów SV-4
Funkcje (czynności) wykonywane przez systemy oraz dane systemowe przepływają pomiędzy funkcjami (działaniami) systemowymi.
SV-5a Działalność operacyjna do macierzy śledzenia funkcji systemów
Odwzorowanie funkcji (działań) systemu z powrotem na czynności (działania) operacyjne.
SV-5b Aktywność operacyjna w odniesieniu do macierzy identyfikowalności systemów
Mapowanie systemów z powrotem na zdolności lub działania operacyjne (działania).
Macierz przepływu zasobów systemów SV-6
Zawiera szczegółowe informacje na temat elementów przepływu zasobów systemu wymienianych między systemami oraz atrybutów tej wymiany.
Matryca miar systemów SV-7
Miary (metryki) elementów Modelu Systemu dla odpowiednich ram czasowych.
Opis ewolucji systemów SV-8
Planowane stopniowe kroki w kierunku migracji pakietu systemów do pakietu bardziej wydajnego lub w kierunku przekształcenia obecnego systemu w przyszłą implementację.
SV-9 Systems Technologia i prognoza umiejętności
Pojawiające się technologie, oprogramowanie/produkty sprzętowe i umiejętności, które mają być dostępne w określonych ramach czasowych i które będą miały wpływ na przyszły rozwój systemu.
Model reguł systemowych SV-10a
Jeden z trzech modeli użytych do opisu funkcjonalności systemu. Identyfikuje ograniczenia, które są nałożone na funkcjonalność systemu ze względu na pewien aspekt projektu lub wdrożenia systemu.
Opis przejścia stanu systemów SV-10b
Jeden z trzech modeli użytych do opisu funkcjonalności systemu. Identyfikuje reakcje systemów na zdarzenia.
Opis śledzenia zdarzeń systemów SV-10c
Jeden z trzech modeli używanych do opisu funkcjonalności systemu. Identyfikuje specyficzne dla systemu udoskonalenia krytycznych sekwencji zdarzeń opisanych w Operational Viewpoint.

Tworzenie zintegrowanej architektury przy użyciu DoDAF

Ilustracja zintegrowanej architektury.

DoDAF 2,0 Architekci przewodnik powtarzane DOD dyspozycję 4630.8 definicję zintegrowanej architektury jako „architektury składającej się z wielu widoków ułatwiających integrację i promujących interoperacyjność drugiej możliwości, a wśród zintegrowanych architektur. Dla celów rozwoju architektury, termin zintegrowane oznacza, że dane wymagane w bardziej niż jeden z modeli architektonicznych jest powszechnie definiowany i rozumiany w tych modelach Architektury zintegrowane są właściwością lub zasadą projektową dla architektur na wszystkich poziomach: zdolności, komponentu, rozwiązania i przedsiębiorstwa (w kontekście architektury korporacyjnej DoD (EA) będącej federacji architektur). Mówiąc prościej, integracja jest postrzegana w związku z elementami wspólnymi wśród produktów architektury, gdzie elementy pokazane w jednym produkcie architektury (takie jak używane witryny lub systemy połączone lub świadczone usługi) powinny mieć identyczny numer, nazwa i znaczenie pojawiają się w powiązanym widoku produktu architektonicznego ws."

Istnieje wiele różnych podejść do tworzenia zintegrowanej architektury przy użyciu DoDAF i określania wymaganych produktów. Podejście zależy od wymagań i oczekiwanych rezultatów; tj. do czego będzie używana uzyskana architektura. Jako jeden przykład, DoDAF v1.0 wymienił następujące produkty jako „minimalny zestaw produktów wymagany do spełnienia definicji OV, SV i TV”. Jedna uwaga: chociaż DoDAF nie wymienia artefaktu OV-1 jako podstawowego produktu, zdecydowanie zachęca się do jego rozwoju. Sekwencja artefaktów wymienionych poniżej daje sugerowaną kolejność, w jakiej artefakty mogą być rozwijane. Rzeczywista sekwencja generowania widoków i ich potencjalne dostosowanie jest funkcją domeny aplikacji i specyficznymi potrzebami wysiłku.

  • AV-1: Przegląd i podsumowanie
  • AV-2: Zintegrowany słownik
  • OV-1: Graficzna koncepcja operacyjna wysokiego poziomu
  • OV-5: Model działalności operacyjnej
  • OV-2: Opis łączności węzła operacyjnego
  • OV-3: Macierz operacyjnej wymiany informacji
  • SV-1: Opis interfejsu systemu
  • TV-1: Profil standardów technicznych

Jedną z obaw dotyczących DoDAF jest to, jak dobrze te produkty odpowiadają na rzeczywiste obawy interesariuszy dla dowolnego systemu będącego przedmiotem zainteresowania. Produkty DoDAF lub przynajmniej 3 widoki można postrzegać jako punkty widzenia ANSI/IEEE 1471-2000 lub ISO/IEC 42010 . Jednak aby zbudować opis architektury, który odpowiada normom ANSI/IEEE 1471-2000 lub ISO/IEC 42010, konieczne jest wyraźne zidentyfikowanie interesariuszy i ich obaw, które są powiązane z każdym wybranym produktem DoDAF. W przeciwnym razie istnieje ryzyko wytwarzania produktów bez klientów.

Zestawienie produktów DoDAF V1.5

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

  • Dokument dotyczący możliwości początkowych (ICD). Dokumentuje potrzebę rozwiązania materiałowego określonej luki w możliwościach, wynikającej ze wstępnej analizy rozwiązań alternatywnych wykonanej przez użytkownika operacyjnego oraz, w razie potrzeby, niezależnej analizy rozwiązań alternatywnych. Definiuje lukę zdolności 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 nakreśla przystępny wzrost militarnie użytecznych, wspieranych logistycznie i technicznie dojrzałych zdolności.
  • Dokument produkcyjny zdolności (CPD). Dokument, który odnosi się do elementów produkcyjnych specyficznych dla pojedynczego przyrostu programu pozyskiwania.
  • Plan wsparcia informacyjnego (ISP). Identyfikacja i dokumentacja potrzeb informacyjnych, wsparcia infrastruktury, wymagań i zależności IT i interfejsu NSS, koncentrując się na problemach zorientowanych na sieć, interoperacyjności, możliwości obsługi i wystarczalności (DODI 4630.8).
  • Indywidualny plan wsparcia informacyjnego (TISP). Celem procesu TISP jest zapewnienie dynamicznego i wydajnego pojazdu dla niektórych programów (ACAT II i poniżej), aby stworzyć wymagania niezbędne 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 oznaczone jako szczególne zainteresowanie OSD przez ASD (NII) /DOD CIO, komponent podejmie ostateczną decyzję dotyczącą szczegółów dostosowanego planu z zastrzeżeniem minimum określonych w procedurach TISP połączonych ze stroną 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:

Jest UPDM (Unified profilu na DoDAF i MODAF) wysiłku w OMG ujednolicenia reprezentację produktów DoDAF gdy UML jest używany.

DoDAF ogólnie opisuje reprezentację generowanych artefaktów, ale pozwala na znaczną elastyczność w odniesieniu do określonych formatów i technik modelowania. Dokumentacja DoDAF zawiera przykłady wykorzystania tradycyjnych technik inżynierii systemów i inżynierii danych , a po drugie, formatu UML. DoDAF głosi swobodę w formatowaniu produktu pracy, nie wyznając jednej techniki tworzenia diagramów nad drugą.

Oprócz reprezentacji graficznej zazwyczaj wymagane jest dostarczenie metadanych do repozytorium portfela technologii informacyjnych w dziedzinie obronności (DITPR) lub innych repozytoriów architektonicznych.

Meta-model

DoDAF ma meta-model, na którym opiera się struktura, definiujący typy elementów modelowania, które mogą być używane w każdym widoku oraz relacje między nimi. DoDAF w wersjach od 1.0 do 1.5 wykorzystywał meta-model CADM , który został zdefiniowany w IDEF1X (później w UML) ze schematem XML pochodzącym z powstałej relacyjnej bazy danych. Począwszy od wersji 2.0, DoDAF przyjął ontologię fundacji IDEAS Group jako podstawę nowego meta-modelu. Ten nowy meta-model nazywa się „DM2”; akronim od „Meta-modelu DoDAF”. Każdy z tych trzech poziomów DM2 jest ważny dla konkretnego widza procesów departamentowych:

  1. Poziom koncepcyjny lub koncepcyjny model danych (CDM) definiuje konstrukcje danych wysokiego poziomu, na podstawie których tworzone są opisy architektury w terminach nietechnicznych, tak aby kierownictwo i menedżerowie na wszystkich poziomach mogli zrozumieć podstawę danych Opisu architektury. Reprezentowany w punkcie widzenia DoDAF V2.0 DIV-1.
  2. Logiczny model danych (LDM) dodaje informacje techniczne, takie jak atrybuty do CDM, i, w razie potrzeby, wyjaśnia relacje w jednoznaczną definicję użycia. Przedstawione 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 wygenerowanymi jako XSD. Reprezentowany w punkcie widzenia DoDAF V2.0 DIV-3.

Cele DM2 to:

  1. Ustanowić i zdefiniować ograniczone słownictwo do opisu i dyskursu na temat modeli DoDAF (dawniej „produktów”) i ich wykorzystania w 6 podstawowych procesach
  2. Określ semantykę i format sfederowanej wymiany danych EA między: narzędziami do opracowywania i analizowania architektury oraz bazami danych architektury w ramach wspólnoty zainteresowań (COI) architektury korporacyjnej DoD (EA) oraz z innymi autorytatywnymi źródłami danych
  3. Wspieraj wykrywanie i zrozumiałość danych EA:
    1. Odkrywanie danych EA przy użyciu kategorii informacji DM2
    2. Zrozumienie danych EA przy użyciu precyzyjnej semantyki DM2 rozszerzonej o identyfikowalność językową (aliasy)
  4. Zapewnij podstawę semantycznej precyzji w opisach architektonicznych, aby wspierać integrację i analizę heterogenicznych opisów architektonicznych w celu wsparcia procesu decyzyjnego.

DM2 definiuje elementy danych architektonicznych i umożliwia integrację i federację opisów architektonicznych. Ustanawia podstawę dla spójności semantycznej (tj. rozumienia) w ramach i pomiędzy Opisami Architektonicznymi. W ten sposób DM2 wspiera wymianę i ponowne wykorzystanie informacji o architekturze 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 do spełniania bieżących wymagań dotyczących danych właścicieli procesów, decydentów, architektów i nowych technologii, będzie ewoluować do zasobu, który pełniej obsługuje wymagania dotyczące danych architektonicznych, publikowanych w konsekwentnie zrozumiały sposób, i umożliwi większe łatwość odkrywania, udostępniania i ponownego wykorzystywania danych architektonicznych ponad granicami organizacyjnymi.

Aby ułatwić korzystanie z informacji w warstwie danych, DoDAF opisuje zestaw modeli do wizualizacji danych za pomocą środków graficznych, tabelarycznych lub tekstowych. Widoki te odnoszą się do wymagań interesariuszy dotyczących tworzenia opisu architektonicznego.

Związek z innymi frameworkami architektonicznymi

UPDM (Unified profilu na DoDAF i MODAF ) to inicjatywa OMG UML do standaryzacji i SysML zużycia dla USA i Wielkiej Brytanii architektury obronnej ram. Ponadto wielonarodowa grupa IDEAS , wspierana przez Australię, Kanadę, Szwecję, Wielką Brytanię, USA, wraz z obserwatorami z NATO , podjęła inicjatywę opracowania formalnej ontologii dla architektur korporacyjnych.

Zobacz też


Bibliografia

Dalsza lektura

  • Dennis E. Wisnosky i Joseph Vogel. Dodaf Wizdom: Praktyczny przewodnik po planowaniu, zarządzaniu i realizacji projektów w celu budowania architektury korporacyjnej przy użyciu struktury Departamentu Architektury Obronnej . Wizdom Systems, Inc., 2004. ISBN  1-893990-09-5 .
  • Dr Steven H. Dam (2015). DoD Architecture Framework 2.0: Przewodnik po zastosowaniu inżynierii systemów do tworzenia zintegrowanych, wykonywalnych architektur . CreateSpace Independent Publishing Platform, 2015. ISBN  1-502757-62-1 .

Linki zewnętrzne

  • Seria CJCSI 6212.01
  • Ramy Architektoniczne Europejskiej Agencji Kosmicznej (ESAAF) – ramy dla europejskich systemów systemów kosmicznych [1]