Marco de la arquitectura del ministerio de defensa

Department of Defense Architecture Framework (DoDAF) es un marco de la arquitectura para el Ministerio de defensa de los Estados Unidos, que proporciona la estructura a una preocupación del accionista específica a través de puntos de vista organizados por varias visiones.

DoDAF define un juego de visiones que sirven de mecanismos para visualización, entendimiento y asimilar el amplio alcance y las complejidades de una descripción de la arquitectura a través de medios tabulares, estructurales, behaviorísticos, ontológicos, ilustrados, temporales o gráficos.

Conviene sobre todo a sistemas grandes con desafíos de interoperabilidad e integración complejos y es por lo visto único en su uso de "visiones operacionales" el detallamiento de la esfera de operaciones del cliente externo en la cual el sistema de desarrollo funcionará.

Descripción

Department of Defense Architecture Framework (DoDAF) proporciona un marco foundational a desarrollar y representar descripciones de la arquitectura que aseguran un denominador común para entendimiento, comparación e integración de arquitecturas a través de organizativo, Unión y límites multinacionales. Establece definiciones del elemento de datos, reglas, y relaciones y un conjunto inicial de productos para el desarrollo consecuente de sistemas, arquitecturas integradas, o federadas. Estas descripciones de la arquitectura pueden incluir Families of Systems (FoS), Systems of Systems (SoS) y capacidades netas y céntricas de interfuncionar y relacionarse en el NCE.

Se requiere que todo el Ministerio estadounidense principal de la Defensa (DoD) armas y adquisiciones del sistema de la tecnología de la información desarrolle y documente Enterprise Architecture (EA) usando las visiones prescribidas en DoDAF. Mientras claramente se apunta a sistemas militares, DoDAF tiene la amplia aplicabilidad a través de los sectores privados, públicos y voluntarios alrededor del mundo y representa uno de un gran número de marcos de la arquitectura de sistemas.

El objetivo de:The de DoDAF es definir conceptos y modelos utilizables en los seis procesos principales de DoD:

  1. Integración de capacidades y desarrollo (JCIDS)
  2. La planificación, programando, planeando el presupuesto, y ejecución (PPBE)
  3. Sistema de adquisición (DAS)
  4. Ingeniería de sistemas (SE)
  5. Operaciones planeando
  6. Capabilities Portfolio Management (CPM)

Adición de:In, DoDAF 2.0’s los objetivos específicos eran a:

  1. Establezca la dirección para el contenido de la arquitectura ya que una función de objetivo – “cabe con el objetivo”
  2. La utilidad de aumento y la eficacia de arquitecturas vía un modelo de datos riguroso – DoDAF el Modelo (DM2) de Meta - tan las arquitecturas se pueden integrar, analizarse y evaluarse a la precisión matemática.

Historia

Note, donde el diagrama declara TBD, DoDAF V2.0 se promulgó el 28 de mayo de 2009.

La primera versión del desarrollo DoDAF se desarrolló en los años 1990 bajo el nombre C4ISR Marco de la Arquitectura arquitectónico. C4ISR significan La Orden, Control, Comunicaciones, Ordenadores, e Inteligencia, Vigilancia y Reconocimiento. En el mismo período el modelo de referencia TAFIM, que se inició en 1986, se desarrolló adelante. El primer Marco de la Arquitectura C4ISR v1.0, soltado el 7 de junio de 1996, se creó en respuesta al paso de la Acción de Clinger-Cohen. Se dirigió al Viceministro de 1995 de la directiva de Defensa que un DoD-amplio esfuerzo emprenderse para definir y desarrollar un mejor medio y proceso para asegurar que las capacidades C4ISR fueran interoperables y encotraran las necesidades del warfighter. El esfuerzo de desarrollo continuado causó el diciembre de 1997 en la segunda versión, Marco de la Arquitectura de C4ISR v2.0.

En el agosto de 2003 DoDAF v1.0 se liberó, que reestructuró el Marco C4ISR v2.0 para ofrecer dirección, descripciones del producto e información suplementaria en dos volúmenes y un Libro del Escritorio. Ensanchó la aplicabilidad de principios de la arquitectura y prácticas a todas las áreas de la Misión, más bien que sólo la comunidad C4ISR. Este documento se dirigió a uso, arquitecturas integradas, DoD y políticas federales, valor de arquitecturas, medidas de la arquitectura, procesos de apoyo de decisión de DoD, técnicas de desarrollo, técnicas analíticas y el CADM v1.01, y avanzó un enfoque basado en el depósito poniendo énfasis en elementos de datos de la arquitectura que comprenden productos de la arquitectura.

En el febrero de 2004 la documentación de la Versión 1.0 se soltó con el volumen "yo: Definiciones y Pautas", "II: Descripciones del producto" y un "Deskbook". En el abril de 2007 la Versión 1.5 se soltó con una documentación de "Definiciones y Pautas", "Descripciones del producto" y "Descripción de Datos de la Arquitectura".

El 28 de mayo de 2009 DoDAF v2.0 fue aprobado por el Ministerio de defensa.

DoDAF V2.0 se publica en un sitio web público.

Otros marcos derivados basados en DoDAF incluyen NATO Architecture Framework (NAF) y Ministerio de defensa (el Reino Unido) Marco de la Arquitectura (MODAF). Como otros enfoques de EA, por ejemplo The Open Group Architecture Framework (TOGAF), DoDAF se organiza alrededor de un depósito compartido para sostener productos de trabajo. El depósito es definido por el Modelo 2.0 de Datos de la Arquitectura Principal (CADM - esencialmente un esquema de la base de datos común) y DoD Architecture Registry System (DARS). Una característica clave de DoDAF es la interoperabilidad, que se organiza como una serie de niveles, llamados Niveles de la Interoperabilidad del Sistema de información (LISI). El sistema de desarrollo sólo no debe encontrar sus necesidades de datos internas sino también a aquellos del marco operacional en el cual se pone.

DoDAF visiones de V1.5

DoDAF V1.5 define un juego de productos, un modelo de visión, ese acto como mecanismos para visualización, entendimiento y asimilar el amplio alcance y las complejidades de una descripción de la arquitectura a través de medios gráficos, tabulares, o textuales. Estos productos se organizan bajo cuatro visiones:

Cada visión representa ciertas perspectivas de una arquitectura como descrito abajo. Sólo un subconjunto de DoDAF lleno viewset por lo general se crea para cada desarrollo del sistema. La cifra representa la información que une la visión operacional, sistemas y visión de servicios y visión de estándares técnica. Las tres visiones y sus interrelaciones – conducido por elementos de datos de la arquitectura comunes – proporcionan la base a

sacar medidas como interoperabilidad o rendimiento, y para medir el impacto de los valores de éstos métrica en misión operacional y eficacia de la tarea.

All View (AV)

Los productos de AV proporcionan descripciones que sobrearquean de la arquitectura entera y definen el alcance y el contexto de la arquitectura. DoDAF V1.5 AV productos se definen como:

Descripción de AV-1 e información sumaria

: El alcance, objetivo, quiso a usuarios, ambiente conclusiones representadas, analíticas (si aplicable)

AV-2 diccionario integrado

: Las definiciones de todos los términos usadas en todos los productos.

Operational View (OV)

Los productos de Operational View (OV) proporcionan descripciones de las tareas y actividades, elementos operacionales y cambios de información requeridos llevar a cabo misiones de DoD. El OV proporciona representaciones textuales y gráficas de nodos operacionales y elementos, tareas asignadas y actividades y flujos de información entre nodos. Define el tipo de la información intercambiada, la frecuencia de cambios, las tareas y actividades apoyadas por estos cambios y la naturaleza de los cambios. DoDAF V1.5 OV productos se definen como:

Alto nivel de OV-1 concepto operacional gráfico

: Descripción gráfica y textual de alto nivel de concepto operacional (organizaciones de alto nivel, misiones, configuración geográfica, conectividad, etc.).

OV-2 descripción de la conectividad del nodo operacional

: Nodos operacionales, las actividades funcionaron en cada nodo, y conectividades y flujo de información entre nodos.

OV-3 información operacional cambian la matriz

: La información cambió entre nodos y los atributos relevantes de ese cambio como medios, calidad, cantidad y el nivel de interoperabilidad requerida.

OV-4 carta de relaciones organizativa

: Orden, control, coordinación y otras relaciones entre organizaciones.

OV-5 modelo de actividad operacional

: Actividades, relaciones entre actividades, entradas y salidas. Además, los revestimientos pueden mostrar el coste, realizando nodos u otra información pertinente.

OV-6a modelo de reglas operacional

: Uno de los tres productos solía describir la secuencia de actividad operacional y el cronometraje que identifica las reglas comerciales que reprimen la operación.

OV-6b descripción de transición estatal operacional

: Uno de los tres productos solía describir la secuencia de actividad operacional y el cronometraje que identifica respuestas de un proceso de negocio a acontecimientos.

OV-6c descripción del rastro del acontecimiento operacional

: Uno de los tres productos solía describir la secuencia de actividad operacional y el cronometraje que remonta las acciones en un guión o secuencia crítica de acontecimientos.

OV-7 modelo de datos lógico

: Documentación de los requisitos de datos y reglas de proceso de negocio estructurales de la Visión Operacional. (En DoDAF V1.5. Esto equivale a DIV-2 en DoDAF V2.0.)

Sistemas y Services View (SV)

SV es un juego de productos gráficos y textuales que describen aseguramiento de interconexiones y servicios y sistemas, o apoyo, funciones de DoD. Los productos de SV se concentran en sistemas físicos específicos con posiciones (geográficas) físicas específicas. La relación entre elementos de datos de la arquitectura a través del SV al OV se puede ejemplificar ya que los sistemas se consiguen y se presentan para apoyar organizaciones y sus operaciones. DoDAF V1.5 SV productos son:

Descripción del Interfaz de Sistemas/Servicios de SV-1

: Representa nodos de sistemas y el residente de sistemas en estos nodos para apoyar papeles de organizaciones/humano representados por nodos operacionales del OV-2. SV-1 también identifica los interfaces entre nodos de sistemas y sistemas.

Descripción de Comunicaciones de Sistemas/Servicios de SV-2

: Representa la información pertinente sobre sistemas de comunicaciones, canales de comunicación y redes de comunicaciones. SV-2 documenta las clases de medios de comunicaciones que apoyan los sistemas y pone en práctica sus interfaces como descrito en SV-1. Así, SV-2 muestra los detalles de comunicaciones de interfaces de SV-1 que automatizan aspectos del needlines representado en OV-2.

Sistemas de los sistemas de SV-3, sistemas de los servicios, servicios de los servicios Matrices

: proporciona el detalle de las características del interfaz descritas en SV-1 para la arquitectura, arreglada en la forma de la matriz.

SV-4a/SV-4b Descripción de Funcionalidad de Sistemas/Servicios

: El sistema de documentos SV-4a jerarquías funcionales y funciones del sistema y los flujos de datos del sistema entre ellos. El SV-4 de DoDAF v1.0 se designa como 'SV-4a' en DoDAF v1.5. Aunque haya una correlación entre OV-5 o jerarquías de proceso de negocio y el sistema la jerarquía funcional de SV-4a, no tiene que ser una correlación de uno a uno, de ahí, la necesidad de la Actividad Operacional a la Matriz de Trazabilidad de Función de Sistemas (SV-5a), que proporciona esa correlación.

SV-5a, SV-5b, SV-5c actividad operacional a función de sistemas, actividad operacional a trazabilidad de servicios y sistemas Matrices

: La Actividad operacional a SV-5a y SV-5b es una especificación de las relaciones entre el juego de actividades operacionales aplicables a una arquitectura y el juego de funciones del sistema aplicables a esa arquitectura. El SV-5 y la extensión al SV-5 de DoDAF v1.0 se designan como 'SV-5a' y ‘SV-5b’ en DoDAF v1.5 respectivamente.

Matriz de Intercambio de datos de Sistemas/Servicios de SV-6

: Especifica las características de los datos del sistema cambiados entre sistemas. Este producto se concentra en cambios de información automatizados (de OV-3) que se ponen en práctica en sistemas. Los cambios de información no automatizados, como pedidos verbales, se capturan en los productos OV sólo.

Matriz de Parámetros de Rendimiento de Sistemas/Servicios de SV-7

: Especifica las características cuantitativas de sistemas y artículos del hardware/software del sistema, sus interfaces (datos del sistema llevados por los detalles del canal de comunicación así como el interfaz que ponen en práctica el interfaz), y sus funciones. Especifica los parámetros de rendimiento corrientes de cada sistema, interfaz, o función del sistema y los parámetros de rendimiento esperados o requeridos en tiempos especificados en el futuro. Los parámetros de rendimiento incluyen todas las características de rendimiento técnicas de sistemas para los cuales los requisitos se pueden desarrollar y la especificación se define. El juego completo de parámetros de rendimiento no se puede conocer en las etapas tempranas de la definición de la arquitectura, por tanto hay que esperar que este producto se actualizará en todas partes de especificación del sistema, diseño, desarrollo, pruebas, y posiblemente hasta su despliegue y fases del ciclo vital de operaciones.

Descripción de Evolución de Sistemas/Servicios de SV-8

: Los proyectos de evolución de capturas que describen cómo el sistema o la arquitectura en la cual el sistema es introducido, evolucionará durante un período de tiempo larguísimo. Generalmente, los jalones del objetivo son críticos para un entendimiento acertado del objetivo de evolución.

Pronóstico de la Tecnología de Sistemas/Servicios de SV-9

: Define la corriente subyacente y esperó apoyar tecnologías que se han apuntado usando métodos de pronóstico estándares. Las tecnologías de apoyo esperadas son aquellos que se pueden razonablemente pronosticar dados el estado actual de tecnología y mejoras esperadas. Las nuevas tecnologías se deberían atar a períodos de tiempo específicos, que pueden guardar correlación contra los períodos de tiempo usados en jalones SV-8.

Modelo de Reglas de Sistemas/Servicios de SV-10a

: Describe las reglas según las cuales la arquitectura o sus sistemas se comportan en condiciones especificadas.

Descripción de Transición del estado de Sistemas/Servicios de SV-10b

: Un método gráfico de describir un sistema (o función del sistema) respuesta a varios acontecimientos cambiando su estado. El diagrama básicamente representa los juegos de acontecimientos a los cuales los sistemas en la arquitectura responderán (tomando una acción para moverse a un nuevo estado) como una función de su estado actual. Cada transición especifica un acontecimiento y una acción.

Descripción del rastro del Acontecimiento de Sistemas/Servicios de SV-10c

: Proporciona un examen pedido por el tiempo de los elementos de datos del sistema cambiados entre sistemas participantes (externo e interno), funciones del sistema o papeles humanos a consecuencia de un guión particular. Cada diagrama del rastro del acontecimiento debería tener una descripción acompañante que define el guión particular o situación. SV-10c en la Visión de Servicios y Sistemas puede reflejar aspectos específicos para el sistema o refinamientos de secuencias críticas de acontecimientos descritos en la Visión Operacional.

SV-11 esquema físico

: Uno de los productos de la arquitectura el más cercanos al sistema actual diseña en el Marco. El producto define la estructura de varias clases de datos del sistema que son utilizados por los sistemas en la arquitectura. (En DoDAF V1.5. Esto equivale a DIV-3 en DoDAF V2.0.)

Visión de estándares técnica (TV)

Los productos de la TV definen estándares técnicos, convenciones de realización, reglas comerciales y criterios que gobiernan la arquitectura. DoDAF productos de la TV de V1.5 son así:

DoDAF puntos de vista de V2.0

En DoDAF V2.0 los puntos de vista arquitectónicos se forman de datos que se han organizado para facilitar entender. Para alinearse con la ISO Estándares, donde apropiado, la terminología ha cambiado de Visiones al Punto de vista (p.ej, la Visión Operacional es ahora el Punto de vista Operacional).

Nota, el Sistema ha cambiado en DoDAF V2.0 de DoDAF V1.5: el Sistema no es sólo el hardware y

software. El sistema se define ahora en el sentido general de un ensamblaje de componentes - máquina, humano - que realizan actividades (ya que son subtipos del Ejecutante) y se relacionan o interdependientes. Esto podría ser algo, es decir, algo de chiringos de equipos que tienen interacción o elementos interdependientes, a Family of Systems (FoS) y System of Systems (SoS). Note que los Sistemas se arreglan del Material bélico (p.ej, equipo, avión y buques) y Tipos del Personal.

Relación de DoDAF visiones de V1.5 con DoDAF puntos de vista de V2.0

La primera cifra muestra la evolución total de DoDAF Visiones de V1.5 a DoDAF Puntos de vista de V2.0.

La segunda cifra muestra la correlación específica de DoDAF individual Visiones de V1.5 a DoDAF correspondiente Puntos de vista de V2.0.

DoDAF Apoyo de V1.5. Las arquitecturas para DoDAF V1.0 y DoDAF V1.5 pueden seguir usándose. Cuando apropiado (por lo general indicado por la política o por el funcionario con poder de decisión), DoDAF V1.0 y las arquitecturas V1.5 tendrán que actualizar su arquitectura. Cuando pre-DoDAF V2.0 arquitectura es comparado con DoDAF la arquitectura de V2.0, las diferencias del concepto (como el Nodo) se deben definir o explicarse para la arquitectura más nueva.

En cuanto a DoDAF productos de V1.5, se han transformado en partes de los modelos DoDAF V2.0. En mayoría de los casos, DoDAF Meta-modelo de V2.0 apoya DoDAF conceptos de datos de V1.5, con una excepción notable: Nodo. El nodo es un concepto complejo, lógico que se representa con conceptos más concretos. La mesa abajo indica la correlación de DoDAF productos de V1.5 a modelos DoDAF V2.0.

La creación de una utilización de la arquitectura integrada DoDAF

Hay muchos enfoques diferentes para crear una utilización de la arquitectura integrada DoDAF, y para determinar qué productos se requieren. El enfoque depende de los requisitos y los resultados esperados; es decir, para qué la arquitectura que resulta se usará.

Como un ejemplo, DoDAF v1.0 puso los productos siguientes en una lista como el “juego mínimo de productos requeridos satisfacer la definición de un OV, SV y TV.” Una nota: mientras DoDAF no pone el artefacto OV-1 en una lista como un producto principal, su desarrollo fuertemente se anima. La secuencia de los artefactos puestos en una lista abajo da un pedido sugerido en el cual los artefactos se podrían desarrollar. La secuencia actual de la generación de visión y su personalización potencial es una función de la esfera de aplicación y las necesidades específicas del esfuerzo.

Una preocupación por DoDAF es cómo bien estos productos encuentran preocupaciones del accionista actuales por cualquier sistema dado del interés. Uno puede ver productos de DoDAF, o al menos las 3 visiones, como ANSI/IEEE 1471-2000 o ISO/IEC 42010 puntos de vista. Pero construir una descripción de la arquitectura que equivale a ANSI/IEEE 1471-2000 o ISO/IEC 42010, es necesario identificar claramente a los accionistas y sus preocupaciones que trazan un mapa a cada uno seleccionó el producto de DoDAF. Por otra parte hay riesgo (visto en al menos algunos esfuerzos de la arquitectura de DoDAF) de producir productos sin clientes.

La cifra "DoDAF que la Matriz de productos de V1.5" muestra cómo el Presidente de la Junta de Jefes de Estado Mayor de DoD Instrucción (CJCSI) 6212.01E especifica que DoDAF productos de V1.5 se requieren para cada tipo del análisis, en el contexto del Parámetro de Rendimiento Clave Neto y listo (número-KPP):

Representación

Las representaciones para los productos de DoDAF se pueden dibujar de muchas técnicas que hacen el diagrama incluso:

y otras técnicas de encargo según el producto, instrumento usado, y preferencias del contratista/cliente. Hay un UPDM (Perfil unificado para DoDAF y MODAF) el esfuerzo dentro del OMG para estandarizar la representación de productos de DoDAF cuando UML se usa.

DoDAF genéricamente describe en la representación de los artefactos para generarse, pero permite la flexibilidad considerable en cuanto a los formatos específicos y modelado de técnicas. DoDAF deskbook proporciona ejemplos en la utilización de ingeniería de sistemas tradicional e ingenierías mecánicas de datos, y en segundo lugar, formato de UML. DoDAF proclama la latitud en el formato del producto de trabajo, sin profesar una técnica que hace el diagrama sobre el otro.

Además de la representación gráfica, hay típicamente un requisito para proporcionar metadata a Defense Information Technology Portfolio Repository (DITPR) u otros depósitos arquitectónicos.

Meta-modelo

DoDAF siempre ha tenido alguna forma del Meta-modelo que sostiene el marco. El meta-modelo define los tipos de modelado de elementos que se pueden usar en cada visión y las relaciones entre ellos.

Las versiones de DoDAF 1.0 a 1.5 usaron el meta-modelo CADM, que se definió en IDEF1X (entonces más tarde en UML) con un Esquema XML sacado de la base de datos relacional que resulta.

De la versión 2.0, DoDAF ha adoptado la ontología de la fundación de IDEAS Group como la base para su nuevo meta-modelo. Este nuevo meta-modelo se llama "DM2"; una sigla para "Meta-modelo de Defensa".

Diagrama de DoDAF V2.0 el modelo DM2's de Meta tres niveles.

DM2 metamodel 2.02 (Archivo del Arquitecto de la empresa)

Cada uno de estos tres niveles del DM2 es importante para un espectador particular de procesos Departamentales:

  1. El nivel conceptual o Conceptual Data Model (CDM) definen las construcciones de datos de alto nivel de las cuales las Descripciones Arquitectónicas se crean en no términos técnicos, de modo que los ejecutivos y los gerentes a todos los niveles puedan entender la base de datos de la Descripción Arquitectónica. Representado en DoDAF V2.0 DIV-1 Punto de vista.
  2. Logical Data Model (LDM) añade la información técnica, como atributos al CDM y, cuando necesario, clarifica relaciones en una definición de uso inequívoca. Representado en DoDAF V2.0 DIV-2 Punto de vista.
  3. Physical Exchange Specification (PES) consiste en el LDM con tipos de datos generales especificados y atributos de realización (p.ej, fuente, fecha) añadido, y luego generado como un XSD. Representado en DoDAF V2.0 DIV-3 Punto de vista.

Los objetivos del DM2 son:

  1. Establezca y defina el vocabulario reprimido para descripción y discurso sobre modelos DoDAF (antes "productos") y su uso en el 6 corazón trata
  2. Especifique la semántica y formato para el intercambio de datos EA federado between:architecture desarrollo e instrumentos de análisis y bases de datos de la arquitectura a través de DoD Comunidad de interés (COI) de Enterprise Architecture (EA) y con otras fuentes de datos autoritarias
  3. Descubrimiento de apoyo y understandability de datos EA:
  4. Descubrimiento de datos EA usando categorías de DM2 de la información
  5. Understandability de datos EA usando DM2’s semántica precisa aumentó con la trazabilidad lingüística (alias)
  6. Proporcione una base a la precisión semántica en descripciones arquitectónicas para apoyar la integración de la descripción arquitectónica heterogénea y el análisis en apoyo de la toma de decisiones de proceso principal.

El DM2 define elementos de datos arquitectónicos y permite la integración y la federación de Descripciones Arquitectónicas. Establece una base para el semántico (es decir, entendiendo) consecuencia dentro de y a través de Descripciones Arquitectónicas. En esta manera, el DM2 apoya el cambio y la reutilización de la información arquitectónica entre JCAs, Componentes, y federal y compañeros de la Coalición, así facilitando el entendimiento y la realización de la interoperabilidad de procesos y sistemas. Como el DM2 madura para cumplir con los requisitos de datos en curso de dueños de proceso, personas que toman decisiones, arquitectos y nuevas tecnologías, va a un recurso que más completamente apoya los requisitos para datos arquitectónicos, publicados de un modo consecuentemente comprensible, y permitirá la mayor facilidad para descubrimiento, compartimiento y reutilización de datos arquitectónicos a través de límites organizativos.

Para facilitar el uso de la información en la capa de datos, DoDAF describe un juego de modelos para visualizar datos a través de medios gráficos, tabulares, o textuales. Estas visiones están relacionadas con requisitos del accionista para producir una Descripción Arquitectónica.

Relación a otros marcos de la arquitectura

El UPDM (Perfil unificado para DoDAF y MODAF) es una iniciativa OMG de estandarizar UML y uso de SysML para marcos de la arquitectura de defensa del Reino Unido y los EE. UU. Además, IDEAS Group multinacional, que es apoyada por Australia, Canadá, Suecia, el Reino Unido, los EE. UU, con observadores de la OTAN, ha lanzado una iniciativa de desarrollar una ontología formal para arquitecturas de la empresa.

Véase también

Apoyo de productos comercial

Varios productos comerciales tienen el apoyo a DODAF, incluso el siguiente.

http://www.atego.com/products/artisan-studio-architect-enterprise-edition/

Adelante lectura

DoDAF recursos de V2.0

Dirección, Evaluaciones de impacto de Intimidad, el inventario de sistemas MC/ME/MS y el registro para sistemas bajo DoDI

5000.2. Los Sistemas metadata de la Arquitectura pueden ser usados para poblar DITPR con la información nueva o actualizada. DITPR también puede poblar los Sistemas de la arquitectura metadata, en particular en sistemas que conectan con sistemas descritos en la arquitectura, pero no son la parte del alcance de la arquitectura.

funcionalidad de sistemas/servicio que apoya capacidad conjunta. El JCSFL se proporciona a trazar un mapa de funciones a actividades apoyadas y los sistemas o servicios que los reciben. La Instrucción del presidente de la Junta de Jefes de Estado Mayor (CJCSI) 6212.01E prescribe el JCSFL para el uso en el desarrollo de un vocabulario común para el desarrollo de la arquitectura. Use la taxonomía para alinear o ampliar funciones del sistema dentro de la arquitectura desarrollada

los documentos que son necesarios para Decisiones del Jalón tienen la información de la arquitectura. Como el desarrollo de la arquitectura

progresos, la información de la arquitectura tranquila se puede extraer y relatarse en los documentos requeridos.

tablas de datos de la referencia e información metadata relacionada Los Flujos del Recurso y Esquemas Físicos de la Arquitectura

puede ser usado para poblar el Registro Metadata.

acuerdo y estandarización para una arquitectura integrada. Comprenden el léxico para las tres visiones del marco de la arquitectura, el operacional (OV), sistema (SV) y estándares técnicos (TV) visiones. El uso de crítico

el taxonomies es un paso al contrato de un seguro de la integración de sistemas dentro de un sistema de sistemas y la alineación de la información

tecnología (ESTO) funcionalidad a misión y necesidades operacionales. Los datos contenidos en cada elemento del

La lista de la arquitectura se debe usar para el desarrollo del marco de la arquitectura total, programmatic investigación,

desarrollo, y actividades de adquisición y evaluaciones de capacidad e interoperabilidad e integración relacionadas. Se actualizará a través de períodos de revisión para apoyar a DON esfuerzos de Program Objective Memorandum (POM) y reflejar

cambios encomendados por DoD, mejoras de la tecnología y otros factores.

el metadata del esfuerzo de la Arquitectura puede ser usado para poblar el Registro del Servicio en el proceso de desarrollar el

solución.

el sistema de la referencia común para comandantes de la fuerza conjuntos, agencias de apoyo de combate, planificadores operacionales, combate a reveladores y entrenadores para comunicar requisitos de la misión. Es la lengua básica para el desarrollo de una misión conjunta lista de la tarea esencial (JMETL) o misión de la agencia lista de la tarea esencial (AMETL) que identifica capacidades requeridas del éxito de la misión. Use la taxonomía para alinear o ampliar actividades operacionales dentro de la arquitectura desarrollada.

Enlaces externos



Buscar