1. DoDAF Version 2.03 Update DoD Architecture Methodology & Tools Forum
Mr. David McDaniel (ctr)
29 August 2012

2. Agenda Re-calibrate Restructure of DoDAF v2.03
Summary of v2.03 changes
Re-writes of DoDAF model specifications
v2.03 production schedule
Challenge of architectures supporting the 6 core processes
Systems engineering and architecture integration

3. DoDAF’s Normative Parts
DoDAF Viewpoint Definitions. Conventions for the construction, interpretation and use of architecture views and associated architecture models.
DoDAF Model Specifications. Specifications from which architecture views representing a architecture are composed.
Glossary. Defines all non-demotic terms used in DoDAF and the DoDAF Meta Model.
DM2. Consists of a Conceptual Data Model (CDM) diagram and narrative description, a Logical Data Model (LDM) in an UML file adapted to IDEAS and a narrative description, and Physical Exchange Specification (PES) XML Schema Descriptions.
NOTE that introductory, tutorial, document outlining, and web navigation documentation is considered under control of the DoDAF editorial team and not subject to formal CM in scope of this plan.

4. The DM2 Has Three Levels DIV-1 (CDM) DIV-2 (LDM) DIV-3 (physical)
(This is where almost all the design and analysis work is done)
DIV-3 (physical)
(Auto-generated from the LDM)
Logical Data Model (LDM)
Reified and Formalized relationships
Conceptual Data Model (CDM)
Concepts and concept relationships
Physical Exchange Schema (PES)
XML encoding of LDM
The DM2 has several levels, each of which is important to a particular viewer of Departmental processes.
A conceptual level or Conceptual Data Model (CDM) defines concepts and relationships between them
business language of the enterprise
normative across the six core processes
A logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematically
A physical level or Physical Exchange Specification (PES)
adds required NCDS metadata for security and pedigree to the LDM
is generated from the LDM as a set of XSD’s, one schema per DoDAF-described Model

5. DM2 CDM Activity Capability Resource Performer
anything can have Measures
Condition
Guidance
is-performable-under
Rule
Activity
Capability
Standard
Agreement
constrains
requires-ability-to-perform
has
consumes-and-produces
is-performed-by
is-realized-by
Project
achieves-desired-effect (a state of a resource)
is-the-goal-of
Resource
describes-something
Information
Not shown but implied by the IDEAS Foundation:
Everything is 4-D and so has temporal parts, i.e., states
Everything has parts
Everything has subtypes
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received.
Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose.
System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture.
Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.
Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.
Condition: The state of an environment or situation in which a Performer performs.
Desired Effect: A desired state of a Resource.
Measure: The magnitude of some attribute of an individual.
Location: A point or extent in space that may be referred to physically or logically.
Guidance: An authoritative statement intended to lead or steer the execution of actions.
Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action.
Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
Project: A temporary endeavor undertaken to create Resources or Desired Effects.
Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties.
Materiel
Performer
Data
System
Organization
is-at
Location
GeoPolitical
Service
PersonRole
is-part-of

6. Six Core Processes, DoDAF Models, DM2, and IDEAS
Model (view) specifications
Operational
Capabilities
Services
Systems
Data and Information
Standards
Projects
DM2
The 52 DoDAF models and the DM2 are related via a matrix

7. Structure and contents of DoDAF v2.03
Vol. I - Normative
DM2 Conceptual Data Model (CDM) documentation
DoDAF Viewpoints & Models
Vol. II - Normative
DM2 Logical Data Model (LDM) documentation
DoDAF Model Specs
DoDAF Glossary
SparxEA .EAP DM2 LDM file
Vol. III - Normative
DM2 Physical Exchange Specification (PES) XSD file and documentation
SparxEA .EAP IDEAS Foundation file and documentation
Vol IV - Informative
DoDAF Informative material (e.g., 6-step, approximately 30 articles)
DM2 OWL-DL file and documentation
NOT under formal CM
31 July 2012 7 7

8. Changes for v2.03 TECHEDITS
Normative parts separated from informative parts
Normative parts subject to formal coordination with DoD Components
Informative parts moved to DoDAF Journal
Document + Webpages
Major DM2 CR’s:
Rules and Desired Effects:
Their Descriptions are produced by rule and goal-setting authorities
They are consumed by Activities (ala Controls in IDEF0
Conforming Activities are subtypes
Information resource flow was simplified into flatter type structure so it would be logically correct and consistent with other Resource Flows, e.g.,
Aircraft 123 on my scope Î {all reports on A/C 123} Ì {TADIL-J 3.2 msg}
Capability made a subtype of Property so that it is the set of Tasks performed under Conditions that meet certain performance standards (Measures)
Makes Capability comparison and dependencies more direct (simple set operations)
Distinguished that Guidance influences Activity from Rules that control Activity
Added SoA Joint Action concept
Continued work on distinguishing Roles (within scope of EA) from types of Persons (outside scope of EA)
exists spatio-temporally
a set
usable in, e.g., SV-6 8

9. Marine Corps - Led TECHEDIT Team
Marine Corps commented on many incorrect, ambiguous, and inconsistent statements
After working on this for several meetings, the WG requested a rewrite rather than line-by-line fixes
SPAWAR noted many undefined and inconsistent terms in the DoDAF model
A long-standing CR asked for a DM2 diagram for each DoDAF model as in DoDAF 1.x documents 9

10. SV-1 Issues Identified by DoDAF WG
Name: Systems Interface Description
One liner: The identification of systems, system items, and their interconnections.
Description:
composition and interaction of Systems
links together the operational and systems architecture models -- a SV-1 may represent the realization of a requirement specified in an OV-2
there may be many alternative SV models that could realize the operational requirement.
in an “As-Is” architecture, the OV-2 may simply be a simplified, logical representation of the SV-1 to allow communication of key Resource Flows to non-technical stakeholders.
A System Resource Flow is a simplified representation of a pathway or network pattern,
Note that Resource Flows between Systems may be further specified in detail in SV-2 Systems Resource Flow Description and SV-6 Systems Resource Flow Matrix.
Sub-System assemblies
SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed
optionally overlay Operational Activities and Locations
In many cases, an operational activity and locations depicted in an OV-2 may well be the logical representation of the resource that is shown in SV-1.
The SV-1 is used in two complementary ways:
Describe the Resource Flows exchanged between resources in the architecture.
Describe a solution, or solution option, in terms of the components of capability and their physical integration on platforms and other facilities.
Detailed Description:
Systems and sub-systems
The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact with Systems.
Capability and Performers which is used to gather together systems, assets and people into a configuration, which can meet a specific capability.
A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems, performer and activities (functions) and their interactions.
SV-1 contributes to user understanding of the structural characteristics of the capability.
The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a system cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both).
Organizational aspects can now be shown on SV-1 (e.g., who uses System).
Resource structures may be identified in SV-1
DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a position relative to a structural hierarchy.
Any System may combine hardware and software or these can be treated as separate (sub) Systems. DoDAF V2.0 includes human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.
optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2
Every phrase analyzed contains problematic terms or expressions that are:
not defined
used mysteriously
inconsistent within this description or across the document
ambiguous
vague
suggest content exists elsewhere that does not exist
logically, operationally, or technically wrong
The SV-1 addresses the composition and interaction of Systems. For DoDAF V2.0, the SV-1 incorporates the human elements as types of Performers - Organizations and Personnel Types. Resources are defined in Section 2.2.1
The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and interact to realize the logical architecture specified in an OV-2 Operational Resource Flow Description. A SV-1 may represent the realization of a requirement specified in an OV-2 Operational Resource Flow Description (i.e., in a “To-Be” architecture), and so there may be many alternative SV models that could realize the operational requirement. Alternatively, in an “As-Is” architecture, the OV-2 Operational Resource Flow Description may simply be a simplified, logical representation of the SV-1 to allow communication of key Resource Flows to non-technical stakeholders.
A System Resource Flow is a simplified representation of a pathway or network pattern, usually depicted graphically as a connector (i.e., a line with possible amplifying information). The SV-1 depicts all System Resource Flows between Systems that are of interest. Note that Resource Flows between Systems may be further specified in detail in SV-2 Systems Resource Flow Description and SV-6 Systems Resource Flow Matrix.
Sub-System assemblies may be identified in SV-1 to any level (i.e., depth) of decomposition the architect sees fit. SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed, and optionally overlay Operational Activities and Locations that utilize those Resources. In many cases, an operational activity and locations depicted in an OV-2 Operational Resource Flow Description model may well be the logical representation of the resource that is shown in SV-1.
The intended usage of the SV-1 includes:
Definition of System concepts.
Definition of System options.
System Resource Flow requirements capture.
Capability integration planning.
System integration management.
Operational planning (capability and performer definition).
The SV-1 is used in two complementary ways:
Describe the Resource Flows exchanged between resources in the architecture.
Describe a solution, or solution option, in terms of the components of capability and their physical integration on platforms and other facilities.
Detailed Description:
A SV-1 can be used simply to depict Systems and sub-systems and identify the Resource Flows between them. The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact with Systems. In addition, DoDAF has the concept of Capability and Performers (see Capability Meta-model group in Section 2) which is used to gather together systems, assets and people into a configuration, which can meet a specific capability. A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems, performer and activities (functions) and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.
The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a system cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both). Organizational aspects can now be shown on SV-1 (e.g., who uses System). Resource structures may be identified in SV-1 to any level (i.e., depth) of decomposition the architect sees fit. DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a position relative to a structural hierarchy. Any System may combine hardware and software or these can be treated as separate (sub) Systems. DoDAF V2.0 includes human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.
A SV-1 can optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2 Operational Resource Flow Description model. In this way, traceability can be established from the logical OV structure to the physical System Viewpoint structure.
If possible, a SV-1 shows Systems, Physical Assets and System interfaces for the entire Architectural Description on the same diagram. If a single SV-1 is not possible, the resource of interest should be decomposed into multiple SV-1 models.
Functions (Activities):
Some Resources can carry out System Functions (Activities) as described in SV-4 Systems Functionality Description model and these functions can optionally be overlaid on a SV-1. In a sense, the SV-1 and the SV-4 Systems Functionality Description model provide complementary representations (structure and function). Either could be modeled first, but usually an iterative approach is used to model these together gradually building up the level of detail in the System description. Note that the same type (class) of resource may be used in different contexts in a given SV-1. For this reason, the tracing of functions to resources is specified in context of their usage (see DM2 for details).
Resource Flows in SV-1:
In addition to depicting Systems (Performers) and their structure, the SV-1 addresses Resource Flows. A Resource Flow, as depicted in SV-1, is an indicator that resources pass between one System and the other. In the case of Systems, this can be expanded into further detail in SV-2 Systems Resource Flow Description.
Interactions are only possible between Systems and Services. System Resource Flows provide a specification for how the operational Resource Flows Exchanges specified in Needlines (in the OV-2 Operational Resource Flow Description model) are realized with Systems. A single Needline shown in the OV-2 Operational Resource Flow Description model may translate into multiple System Resource Flows.
The actual implementation of a System Resource Flow may take more than one form (e.g., multiple physical links). Details of the physical pathways or network patterns that implement the interfaces are documented in SV-2 Systems Resource Flow Description. System Resource Flows are summarized in a SV-3b Systems-Systems Matrix. The functions performed by the resources are specified in a SV-4 System Functionality Description, but may optionally be overlaid on the Resources in a SV-1.
An Operational Viewpoint (OV) suite may specify a set of requirements – either as a specific operational plan, or a scenario for procurement. As OV-2 Operational Resource Flow Description, OV-5a Operational Activity Decomposition Tree, and OV-5b Operational Activity Model specify the logical structure and behavior, SV-1 and SV-4 Systems Functionality Description specify the physical structure and behavior (to the level of detail required by the architectural stakeholders). This separation of logical and physical presents an opportunity for carrying out architectural trade studies based on the architectural content in the DoDAF-described Models.
The structural and behavioral models in the OVs and SVs allow architects and stakeholders to quickly ascertain which functions are carried out by humans and which by Systems for each alternative specification and so carry out trade analysis based on risk, cost, reliability, etc.
Spotlight on synopsis prepared by DoDAF WG. Highlighted words were found to be problematic.

11. SV-1 Content Guidance for Template and Descriptions
Several distinct pieces are currently described. They should be refactored:
SV-1a Interface Description. The SV-1a shows interfaces (Resource Flows) between Systems, Services, and/or Person Types.
SV-1b Performer Configuration Diagram. Interface Description plus composition (whole-parts) of Resources involved. If Locations are involved in the configuration, relationships to Resources.
SV-1c Functional Allocation. Activities (System Functions) performed by Systems, Services, and Person Types.
SV-1d Organizational Resources. Shows Resources that are part of (whole-part) Organizations.
SV-1e Organizational Dependencies. Shows Organizations whose Activities are reified by System Functions (Activities) performed by Performer Configurations.
All views should show traceability to higher-order reifications, other views that constitute requirements, and/or other non-view requirements. This should be restated for just about every model.
Systems relationship to Capabilities – already in SV-5.
The SV-1 addresses the composition and interaction of Systems. For DoDAF V2.0, the SV-1 incorporates the human elements as types of Performers - Organizations and Personnel Types. Resources are defined in Section 2.2.1
The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and interact to realize the logical architecture specified in an OV-2 Operational Resource Flow Description. A SV-1 may represent the realization of a requirement specified in an OV-2 Operational Resource Flow Description (i.e., in a “To-Be” architecture), and so there may be many alternative SV models that could realize the operational requirement. Alternatively, in an “As-Is” architecture, the OV-2 Operational Resource Flow Description may simply be a simplified, logical representation of the SV-1 to allow communication of key Resource Flows to non-technical stakeholders.
A System Resource Flow is a simplified representation of a pathway or network pattern, usually depicted graphically as a connector (i.e., a line with possible amplifying information). The SV-1 depicts all System Resource Flows between Systems that are of interest. Note that Resource Flows between Systems may be further specified in detail in SV-2 Systems Resource Flow Description and SV-6 Systems Resource Flow Matrix.
Sub-System assemblies may be identified in SV-1 to any level (i.e., depth) of decomposition the architect sees fit. SV-1 may also identify the Physical Assets (e.g., Platforms) at which Resources are deployed, and optionally overlay Operational Activities and Locations that utilize those Resources. In many cases, an operational activity and locations depicted in an OV-2 Operational Resource Flow Description model may well be the logical representation of the resource that is shown in SV-1.
The intended usage of the SV-1 includes:
Definition of System concepts.
Definition of System options.
System Resource Flow requirements capture.
Capability integration planning.
System integration management.
Operational planning (capability and performer definition).
The SV-1 is used in two complementary ways:
Describe the Resource Flows exchanged between resources in the architecture.
Describe a solution, or solution option, in terms of the components of capability and their physical integration on platforms and other facilities.
Detailed Description:
A SV-1 can be used simply to depict Systems and sub-systems and identify the Resource Flows between them. The real benefit of a SV-1 is its ability to show the human aspects of an architecture, and how these interact with Systems. In addition, DoDAF has the concept of Capability and Performers (see Capability Meta-model group in Section 2) which is used to gather together systems, assets and people into a configuration, which can meet a specific capability. A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems, performer and activities (functions) and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.
The physical resources contributing to a capability are either an organizational resource or a physical asset, i.e., a system cannot contribute alone (it must be hosted on a physical asset used by an organizational resource of both). Organizational aspects can now be shown on SV-1 (e.g., who uses System). Resource structures may be identified in SV-1 to any level (i.e., depth) of decomposition the architect sees fit. DoDAF does not specifically use terms such as, sub-System and component as these terms often denote a position relative to a structural hierarchy. Any System may combine hardware and software or these can be treated as separate (sub) Systems. DoDAF V2.0 includes human factors (as Personnel Types and a type of Performer). Should an architect wish to describe a System which has human elements, then Systems, Personnel Types and Performers should be used to wrap the human and system elements together.
A SV-1 can optionally be annotated with Operational Activities, Capabilities, and/or Locations originally specified in OV-2 Operational Resource Flow Description model. In this way, traceability can be established from the logical OV structure to the physical System Viewpoint structure.
If possible, a SV-1 shows Systems, Physical Assets and System interfaces for the entire Architectural Description on the same diagram. If a single SV-1 is not possible, the resource of interest should be decomposed into multiple SV-1 models.
Functions (Activities):
Some Resources can carry out System Functions (Activities) as described in SV-4 Systems Functionality Description model and these functions can optionally be overlaid on a SV-1. In a sense, the SV-1 and the SV-4 Systems Functionality Description model provide complementary representations (structure and function). Either could be modeled first, but usually an iterative approach is used to model these together gradually building up the level of detail in the System description. Note that the same type (class) of resource may be used in different contexts in a given SV-1. For this reason, the tracing of functions to resources is specified in context of their usage (see DM2 for details).
Resource Flows in SV-1:
In addition to depicting Systems (Performers) and their structure, the SV-1 addresses Resource Flows. A Resource Flow, as depicted in SV-1, is an indicator that resources pass between one System and the other. In the case of Systems, this can be expanded into further detail in SV-2 Systems Resource Flow Description.
Interactions are only possible between Systems and Services. System Resource Flows provide a specification for how the operational Resource Flows Exchanges specified in Needlines (in the OV-2 Operational Resource Flow Description model) are realized with Systems. A single Needline shown in the OV-2 Operational Resource Flow Description model may translate into multiple System Resource Flows.
The actual implementation of a System Resource Flow may take more than one form (e.g., multiple physical links). Details of the physical pathways or network patterns that implement the interfaces are documented in SV-2 Systems Resource Flow Description. System Resource Flows are summarized in a SV-3b Systems-Systems Matrix. The functions performed by the resources are specified in a SV-4 System Functionality Description, but may optionally be overlaid on the Resources in a SV-1.
An Operational Viewpoint (OV) suite may specify a set of requirements – either as a specific operational plan, or a scenario for procurement. As OV-2 Operational Resource Flow Description, OV-5a Operational Activity Decomposition Tree, and OV-5b Operational Activity Model specify the logical structure and behavior, SV-1 and SV-4 Systems Functionality Description specify the physical structure and behavior (to the level of detail required by the architectural stakeholders). This separation of logical and physical presents an opportunity for carrying out architectural trade studies based on the architectural content in the DoDAF-described Models.
The structural and behavioral models in the OVs and SVs allow architects and stakeholders to quickly ascertain which functions are carried out by humans and which by Systems for each alternative specification and so carry out trade analysis based on risk, cost, reliability, etc.

12. SV-1 Variant a

13. SV-1 Variant b

14. To-Be SV-1 Re-Write Refocused to be a model of system interfaces
(SV-1a)

15. DoDAF v2.03 Production Schedule
31 July 2012 15

16. DoDAF Focus Remains on the Six Core Processes
Periodic (annual):
PPBE
CPM
DoD
PPBE
CPM
White House
Military Staff HQ (JCS)
JCIDS
Combatant Commands
Doctrine Commands
Training Commands
Legend:
BES — Budget Estimate Submission
COCOM — Combatant Commander
CPA — Chairman’s Program Assessment
DAWG — Deputies Advisory Working Group
FYDP — Future Years Defense Program
MBI — Major Budget Issues Program ManagerPB — President’s Budget
PEO/PM — Program Executive Officer/Program Manager 
POM — Program Objectives Memorandum
RMDs — Resource Management Decisions
Event Driven:
JCIDS
DAS SE
OPS
Presidential Cabinet Civilians
OPS
DAS SE
Acquisition Organizations

17. The Systems Engineering “vee” is a way to organizeRD
CBA
System
O & M
DoDAF Viewpoints
All (AV)
Capabilities (CV)
Operational (OV)
Data / Information (DIV)
Systems (SV)
Services (SvcV)
Standards (StdV) CV
Validation &
VAL
Acquisition Model Decisions & Milestones
MS-C
TEMPcapabilities
MSA
System Validation
CPD
Capabilities Based Assessment (CBA)
Material Solutions Analysis (MSA) OV
Verification
Technology Development (TD)
MS-A
DIV1
SVR
JCIDS Documents
Initial Capabilities Doc (ICD)
Capabilities Design Doc (CDD)
Capabilities Production Doc (CPD)
Information Support Plan (ISP)
ICD
TEMPoperational
Engineering &
Manufacturing Development (E&MD)
Prototyping
System Verification
REQM
SRR
VER
SRD
System Engineering Technical Reviews
System Requirements Reviews (SRR)
System Functional Reviews (SFR)
Preliminary Design Reviews (PDR)
Critical Design Reviews (CDR)
Test Readiness Review (TRR)
System Verification Review (SVR) SV
SvcV
DIV2
StdV
TRR
TEMPsystem
SFR
System Design
Subsystem Verification
CDDprelim; ISPprelim
Typical Systems Engineering Work Products
System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS)
System Design Document (SDD) / System Segment Design Document (SSDD)
Software Requirements Specification (SwRS)
Software Design Document (SwDD)
Interface Requirements Specification (IRS)
Interface Control Document (ICD) / Interface Design Document (IDD)
Data Base Design Document (DBDD)
Test and Evaluation Master Plan (TEMP)
SDD
MS-B SV
SvcV
DIV2
StdV
Component Design
Component Verification
PDR
CDDfinal; ISPfinal
SwRS; IRS
CMMI
Process Areas
Requirements Development (RD)
Requirements Management (REQM
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
CDR
DIV3
SwDD; IDD; DBDD TS PI
Build
Unit Test
Notional Systems Development “V”

18. Summary
V2.03 is the first major re-write of the DoDAF models since conceived
They will, for the first time, align terminologically with the meta-model
The meta-model serves as the glossary of terms for DoDAF
The DM2’s ontologic foundation establishes all of DoDAF with well-defined concepts

19. Questions?