Back to Top

Defense Acquisitions Made Easy

Blog Archives

Systems Engineering

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) (MIL-STD-881C) is a tool used to define a project in discrete work elements in a Hierarchical format. It displays and defines the product, or products, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product. In other words the WBS is an organized method to breakdown a product into subproducts at lower levels of detail. It’s used for planning, cost estimating, execution and control.

WBS

Figure: WBS Sample from SMC Systems Engineering Handbook

The WBS is a means of organizing system development activities based on system and product decompositions. It is a product-oriented family tree composed of hardware, software, services, data, and facilities, which result from systems engineering efforts during the development and production of the system and its components, and which completely defines the program. The WBS is prepared from both the physical and system architectures, and identifies all necessary products and services needed for the system. This top-down structure provides a continuity of flow down for all tasks. Enough levels must be provided to properly define work packages for cost and schedule control purposes. [1]

A program WBS is established to provide the framework for program and technical planning, cost estimating, resource allocation, performance measurement, and status reporting. The WBS defines the total system of hardware, software, services, data, and facilities, and relates these elements to each other and to the end product. Program offices develop a program WBS tailoring the guidance provided in MIL-HDBK-881 and MIL-STD-881C. The WBS is also an integral part of preparation of the Cost Analysis Requirements Description (CARD).

The Program Manager (PM) usually has the responsibility to develop an overall program WBS and to initiate development of contract WBSs for each contract in accordance with common DoD practice established in Mil-HDBK 881. The program WBS is the WBS that represents the total system and, therefore, describes the system architecture. The contract WBSs are part of the program WBS and relate to deliverables and tasks on a specific contract. The PM with the support of systems engineering develops the first three levels of the program WBS, and to provide contractors with guidance for lower-level WBS development. As with most standards and handbooks, use of MIL-HDBK-881 cannot be specified as a contract requirement. Though WBS development is a systems engineering activity, it impacts costing, scheduling and budgeting professionals, as well as contracting officers. An integrated team representing these Stakeholders is needed to support WBS development. [1]

The first three Work Breakdown Structure Levels are organized as:

  • Level 1: Overall System
  • Level 2: Major Elements (Segment)
  • Level 3: Subordinate Components (Prime Items)

Contractor Work Breakdown Statement
The contract WBS is the Government – approved WBS for program reporting purposes and includes all program elements (for example, hardware, software, services, data, or facilities), which are the contractor’s responsibility. It includes the contractor’s discretionary extension to lower levels, in accordance with Government direction and the contract Statement of Work (SOW).

AcqTips:

  • Space and Missile Systems Center (SMC) located at Los Angeles Air Force Base
  • A contractor will call their WBS; Contactor Work Breakdown Structure (CWBS)

AcqLinks and References:

Updated: 7/16/2017

DoDAF Architecting

SvcV-10c Services Event-Trace Description

The SvcV-10c “Services Event-Trace Description” provides a time-ordered examination of the interactions between services functional resources. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. The SvcV-10c is valuable for moving to the next level of detail from the initial solution design, to help define a sequence of service functions and service data interfaces, and to ensure that each participating resource or Service Port role has the necessary information it needs, at the right time, to perform its assigned functionality. [1]

The intended usage of the SvcV-10c includes: [1]

  • Analysis of resource events impacting operation
  • Behavioral analysis
  • Identification of non-functional system requirements

DoDAF Architecture Framework Version 2.02 – Page 195

The SvcV-10c specifies the sequence in which Resource Flow elements are exchanged in context of a resource or Service Port. Services Event-Trace Descriptions are sometimes called sequence diagrams, event scenarios or timing diagrams. The components of a SvcV-10c include functional resources or service ports, owning performer, as well as the port which is the subject for the lifeline. [1]

Specific points in time can be identified. The Resource Flow from one resource/port to another can be labeled with events and their timing. The Service Event-Trace Description provides a time-ordered examination of the Resource Flow elements exchanged between participating resources (external and internal) or service ports. Each Event-Trace diagram should have an accompanying description that defines the particular scenario or situation.

The SvcV-10c is typically used in conjunction with the SvcV-10b “Services State Transition Description” to describe the dynamic behavior of resources. The data content of messages that connect Resource Flows in a SvcV-10c model may be related, in modeling terms, with Resource Flows (interactions, in SvcV-1 “Services Context Description”, SvcV-3a “Systems-Services Matrix”, and SvcV-3b “Services-Services Matrix”), Resource Flows (data, in SvcV-4 “Services Functionality Description” and SvcV-6 “Services Resource Flow Matrix”) and entities (in DIV-3 “Physical Data Model”) modeled in other models.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-10a Services Rules Model

The SvcV-10a “Services Rules Model” is to specify functional and non-functional constraints on the implementation aspects of the architecture (i.e., the structural and behavioral elements of the Services Model). The SvcV-10a describes constraints on the resources, functions, data and ports that make up the Service Model physical architecture. The constraints are specified in text and may be functional or structural (i.e., non-functional). [1]

The intended usage of the SvcV-10a includes: [1]

  • Definition of implementation logic
  • Identification of resource constraints

Guide:  DoDAF Architecture Framework Version 2.02 – Page 191

The SvcV-10a describes the rules that control, constrain or otherwise guide the implementation aspects of the architecture. Service Rules are statements that define or constrain some aspect of the business, and may be applied to: [1]

  • Performers
  • Resource Flows
  • Service Functions
  • System Ports
  • Data Elements

In contrast to the OV-6a “Operational Rules Model”, the SvcV-10a focuses physical and data constraints rather than business rules.

Constraints can be categorized as follows: [1]

  • Structural Assertions – non-functional constraints governing some physical aspect of the architecture
  • Action Assertions – functional constraints governing the behavior of resources, their interactions and Resource Flow exchanges
  • Derivations – these involve algorithms used to compute facts

Where a Service Rule is based on some standard, then that standard should be listed in the StdV-1 “Standards Profile”.
Some Service Rules can be added as annotations to other models. The SvcV-10a then should provide a listing of the complete set of rules with a reference to any models that they affect.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-9 Services Technology and Skills Forecast

See Services Viewpoint (SvcV) Overview

The SvcV-9 “Services Technology and Skills Forecast” defines the underlying current and expected supporting technologies and skills. Expected supporting technologies and skills are those that can be reasonably forecast given the current state of technology and skills, and expected improvements or trends. New technologies and skills are tied to specific time periods, which can correlate against the time periods used in SvcV-8 “Services Evolution Description” model milestones and linked to Capability Phases.

Guide: DoDAF Architecture Framework Version 2.02 – Page 189

The SvcV-9 provides a summary of emerging technologies and skills that impact the architecture. The SvcV-9 provides descriptions of relevant: [1]

  • Emerging capabilities
  • Industry trends
  • Predictions (with associated confidence factors) of the availability and readiness of specific hardware and software services
  • Current and possible future skills

In addition to providing an inventory of trends, capabilities and services, the SvcV-9 also includes an assessment of the potential impact of these items on the architecture. Given the future-oriented nature of this model, forecasts are typically made in short, mid and long-term timeframes, such as 6, 12 and 18-month intervals.

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. As technologies change, like incorporation of Representational State Transfer (REST) services in the Web Services Description Language, this model can present a timeline of technologies related services over time.

The intended usage of the SvcV-9 includes: [1]

  • Forecasting technology readiness against time
  • HR Trends Analysis
  • Recruitment Planning
  • Planning technology insertion
  • Input to options analysis
  • The SvcV-9 can be presented in a table, timeline, or a Herringbone diagram

A SvcV-9 summarizes predictions about trends in technology and personnel. Architects may produce separate SvcV-9 products for technology and human resources. The specific time periods selected (and the trends being tracked) can be coordinated with architecture transition plans (which the SvcV-8 Services Evolution Description can support). That is, insertion of new capabilities and upgrading or re-training of existing resources may depend on or be driven by the availability of new technology and associated skills. The forecast includes potential impacts on current architectures and thus influences the development of transition and target architectures. The forecast is focused on technology and human resource areas that are related to the purpose for which a given architecture is being described and identifies issues affecting that architecture.   If standards are an integral part of the technologies important to the evolution of a given architecture, then it may be convenient to combine SvcV-9 with the StdV-2 “Standards Forecast” into a composite Fit-for-Purpose View.

The SvcV-9 is constructed as part of a given Architectural Description and in accordance with the its purpose. Typically, this involves starting with one or more overarching reference models or standards profiles to which the architecture is subject to using. Using these reference models or standards profiles, the architect selects the service areas and services relevant to the architecture. The SvcV-9 forecasts relate to the StdV-1 “Standards Profile” in that a timed forecast may contribute to the decision to retire or phase out the use of a certain standard in connection with a resource. Similarly, the SvcV-9 forecasts relate to the StdV-2 Standards Forecasts in that a certain standard may be adopted depending on a certain technology or skill becoming available (e.g., the availability of Java Script may influence the decision to adopt a new HTML standard).

Alternatively, the SvcV-9 may relate forecasts to Service Model elements (e.g., Services) where applicable. The list of resources potentially impacted by the forecasts can also be summarized as additional information in SvcV-9.

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-10b Services State Transition Description

The SvcV-10b “Services State Transition Description” is a graphical method of describing a resource (or function) response to various events by changing its state. The diagram basically represents the sets of events to which the resources in the Activities respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 193

The explicit time sequencing of service functions in response to external and internal events is not fully expressed in SvcV-4 Services Functionality Description. SvcV-10b can be used to describe the explicit sequencing of the service functions. Alternatively, SvcV-10b can be used to reflect explicit sequencing of the actions internal to a single service function, or the sequencing of service functions with respect to a specific resource. [1]

The intended usage of the SvcV-10b includes: [1]

  • Definition of states, events, and state transitions (behavioral modeling)
  • Identification of constraints

The SvcV-10b relates events to resource states and describes the transition from one state to another.

The SvcV-10b is based on the state chart diagram. A state machine is defined as “a specification that describes all possible behaviors of some dynamic view element. Behavior is viewed as a traversal of a graph of specific states interconnected by one or more joined transition arcs that are triggered by the dispatching of series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine.” State chart diagrams can be unambiguously converted to structured textual rules that specify timing aspects of events and the responses to these events, with no loss of meaning. However, the graphical form of the state diagrams can often allow quick analysis of the completeness of the rule set, and detection of dead ends or missing conditions. These errors, if not detected early during the solution analysis phase, can often lead to serious behavioral errors in fielded capabilities and to expensive correction efforts. [1]

The SvcV-10b models state transitions from a resource perspective, with a focus on how the resource responds to stimuli (e.g., triggers and events). As in the OV-6b “Operational State Transition Description”, these responses may differ depending upon the rule set or conditions that apply, as well as the resource’s state at the time the stimuli is received. A change of state is called a transition. Each transition specifies the response based on a specific event and the current state. Actions may be associated with a given state or with the transition between states. A state and its associated actions specify the response of a resource or service function, to events. When an event occurs, the next state may vary depending on the current state (and its associated action), the event, and the rule set or guard conditions. [1]

The SvcV-10b can be used to describe the detailed sequencing of service functions described in SvcV-4 “Services Functionality Description”. However, the relationship between the actions included in SvcV-10b and the functions in SvcV-4 depends on the purposes of the Architectural Description and the level of abstraction used in the models. The explicit sequencing of functions in response to external and internal events is not fully expressed in SvcV-4 Services Functionality Description. SvcV-10b can be used to reflect explicit sequencing of the functions, the sequencing of actions internal to a single function, or the sequencing of functions with respect to a specific resource. [1]

States in a SvcV-10b model may be nested. This enables quite complex models to be created to represent Services behavior. Depending upon the architecture project’s needs, the SvcV-10b may be used separately or in conjunction with the SvcV-10c “Services Event-Trace Description”. [1]

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-7 Services Measures Matrix

See Services Viewpoint (SvcV) Overview

The SvcV-7 Services Measures Matrix depicts the measures (metrics) of resources. The Services Measures Matrix expands on the information presented in a SvcV-1 “Services Interface Description” by depicting the characteristics of the resources in the SvcV-1 Services Context Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 185

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. Service measures for Service Level Agreements for each service and may include number of service consumers, service usage by consumers, and the minimum, average and maximum response times, allowed down time, etc. Measures of interest for a Chief Information Office or Program manager (PM) may include measures that assess service reuse, process efficiency, and business agility.

The intended usage of the SvcV-7 includes: [1]

  • Definition of performance characteristics and measures (metrics)
  • Identification of non-functional requirements

The SvcV-7 specifies qualitative and quantitative measures (metrics) of resources. It specifies all of the measures. The measures are selected by the end user community and described by the architect.

Performance parameters include all performance characteristics for which requirements can be developed and specifications defined. The complete set of performance parameters may not be known at the early stages of Architectural Description, so it is to be expected that this model is updated throughout the specification, design, development, testing, and possibly even its deployment and operations lifecycle phases. The performance characteristics are captured in the Measures Meta-model group.

One of the primary purposes of SvcV-7 is to communicate which measures are considered most crucial for the successful achievement of the mission goals assigned. These particular measures can often be the deciding factors in acquisition and deployment decisions, and figure strongly in services analysis and simulations done to support the acquisition decision processes and system design refinement and be input or may impact decisions about Service Level Agreement content. Measures of Effectiveness (MOE) and Measures of Performers (MOP) are measures that can be captured and presented in the Services Measures Matrix model.

SvcV-7 is typically a table, listing user defined measures (metrics) with a time period association. It is sometimes useful to analyze evolution by comparing measures (metrics) for current and future resources. For this reason, a hybrid SvcV-7 Model which spans architectures across multiple phases may be useful.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-8 Services Evolution Description

See Services Viewpoint (SvcV) Overview

The SvcV-8 “Services Evolution Description” presents a whole lifecycle view of resources (services), describing how it changes over time. It shows the structure of several resources mapped against a timeline. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 187

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. This model can present a timeline of services evolve or are replaced over time, including services that are internal and external to the scope of the architecture. [1]

The intended usage of the SvcV-8 includes: [1]

The SvcV-8, when linked together with other evolution Models such as CV-2 “Capability Taxonomy”, CV-3 “Capability Phasing” and StdV-2 “Standards Forecast”, provides a rich definition of how the Enterprise and its capabilities are expected to evolve over time. In this manner, the model can be used to support an architecture evolution project plan or transition plan. [1]

A SvcV-8 can describe historical (legacy), current, and future capabilities against a timeline. The model shows the structure of each resource, using similar modeling elements as those used in SvcV-1 “Service Interface Description”. Interactions which take place within the resource may also be shown. The changes depicted in the SvcV-8 DoDAF-described Model are derived from the project milestones that are shown in a PV-2 “Project Timelines” model. When the PV-2 Project Timelines model is used for capability acquisition projects, there is likely to be a close relationship between these two models. [1]

DoDAF Viewpoint Matrix
AV 1 2
CV 1 2 3 4 5 6 7
DIV 1 2 3
OV 1 2 3 4 5a 5b 6a 6b 6c
PV 1 2 3
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

SvcV-4 Services Functionality Description

See Services Viewpoint (SvcV) Overview

Within an Architectural Description, the SvcV-4 “Services Functionality Description” documents service functions, the Resource Flows between those service functions, the internal system data repositories or service data stores, and the external sources and sinks for the service data flows, but not external to the Architectural Description’s scope. They may also show how users behave in relation to those services.  The primary purpose of SvcV-4 is to: [1]

  • Develop a clear description of the necessary data flows that are input (consumed) by and output (produced) by each resource
  • Ensure that the service functional connectivity is complete (i.e., that a resource’s required inputs are all satisfied)
  • Ensure that the functional decomposition reaches an appropriate level of detail

Guide: DoDAF Architecture Framework Version 2.02 – Page 179

The Services Functionality Description provides detailed information regarding the: [1]

The intended usage of the SvcV-4 includes: [1]

  • Description of task workflow
  • Identification of functional service requirements
  • Functional decomposition of Services
  • Relate human and service functions

It is important to note that one usage of the SvcV-4 can support a net-centric (service oriented) implementation in describing the producing services and consuming services. The Services Functionality Description information can support the registration of services in netcentric (service-oriented) implementation.

The SvcV-4 is used to specify the service functionality of resources in the architecture. The SvcV-4 is the behavioral counterpart to the SvcV-1 “Services Context Description” (in the same way that OV-5b Operational Activity Model is the behavioral counterpart to OV-2 “Operational Resource Flow Description”).

The scope of this model may be capability wide, without regard to which resources perform which service functions, or it may be resource-specific. Variations may focus on intra- or inter-resource data flows, or may simply allocate service functions to resources.

There are two basic ways to depict a SvcV-4: [1]

  1. The Taxonomic Service Functional Hierarchy shows a decomposition of service functions depicted in a tree structure and is typically used where tasks are concurrent but dependent, such as a production line, for example.
  2. The Data Flow Diagram shows service functions connected by data flow arrows and data stores
   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/28/2017

DoDAF Architecting

SvcV-6 Services Resource Flow Matrix

See Services Viewpoint (SvcV) Overview

The SvcV-6 “Services Resource Flow Matrix” specifies the characteristics of the Service Resource Flows exchanged between Services. The focus is on resource crossing the service boundary. The SvcV-6 focuses on the specific aspects of the Service Resource Flow and the Service Resource Flow content in a tabular format. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 183

In addition, this model is useful in support of net-centric (service-oriented) implementation of services. According to the Net-Centric Data Strategy, a net-centric implementation needs to focus in on the data in the Service Resource Flow, as well as the services that produce or consume the data of the Service Resource Flow. In a net-centric implementation, not all the consumers are known and this model emphasizes the focus on the producer and Service Resource Flow. [1]

The intended usage of the SvcV-6 includes: [1]

  • Detailed definition of Resource Flows

The SvcV-6 specifies the characteristics of Service Resource Flow exchanges between Services. The SvcV-6 is the physical equivalent of the logical OV-3 “Operational Resource Flow Matrix” and provides detailed information on the service connections which implement the Resource Flow exchanges specified in OV-3 “Operational Resource Flow Matrix”. Resource flow exchange solutions, whether automated or not, e.g., such as verbal orders, are also captured.

Service Resource Flow exchanges express the relationship across the three basic architectural data elements of a SvcV (Services, service functions, and Service Resource Flows) and focus on the specific aspects of the Service Resource Flow and the service resource content. These aspects of the service Resource Flow exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation such as security policy and communications and logistics limitations.

The focus of SvcV-6 is on how the Service Resource Flow exchange is affected, in service specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the resource exchange. In addition, for Service Resource Flow of data, their format and media type, accuracy, units of measurement, applicable system data standards, and any DIV-3 “Physical Data Models” are also described or referenced in the matrix.
Modeling discipline is needed to ensure that the architecture models are coherent. Each Service Resource Flow exchange listed in the SvcV-6 table should be traceable to at least one Operational Resource Flow exchanged listed in the corresponding OV-3 Operational Resource Flow Matrix and these in turn trace to OV-2 “Operational Resource Flow Description”.

It should be noted that each resource exchanged may relate to a known service function (from SvcV-4 “Sevice Functionality Description”) that produces or consumes it. However, there need not be a one-to-one correlation between data elements listed in the SvcV-6 matrix and the Resource Flows (inputs and outputs) that are produced or consumed in a related SvcV-4 because the SvcV-4 is more a logical solution, whereas the SvcV-6 is a more physical solution. In addition, Resource flows between known service functions performed by the same Services may not be shown in the SvcV-6 matrix. The SvcV-6 is about showing flows across service boundaries or a service boundary. If the Resource Flow is information, it may need to be reflected in the Data and Information Models.

The SvcV-7 “Services Measures Matrix” builds on the SvcV-6 and should be developed at the same time.

DoDAF does not prescribe the column headings in a SvcV-6 Matrix. Identifiers of the OV-3 “Operational Resource Flow Matrix” that are implemented by the Service Resource Flow Exchanges may be included in the table. All elements carried by the Resource Flow exchanges may be shown. [1]

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018