Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

PV-3 Project to Capability Mapping

The PV-3 “Project to Capability Mapping” supports the acquisition and deployment processes, including the management of dependencies between projects and the integration of all relevant project and program elements to achieve a capability. It maps programs, projects, portfolios, or initiatives to capabilities to show how the specific elements help to achieve a capability. Programs, projects, portfolios, or initiatives are mapped to the capability for a particular timeframe. Programs, projects, portfolios, or initiatives may contribute to multiple capabilities and may mature across time. The analysis can be used to identify capability redundancies and shortfalls, highlight phasing issues, expose organizational or system interoperability problems, and support program decisions, such as when to phase out a legacy system.

Guide: DoDAF Architecture Framework Version 2.02 – Page 166

The intended usage of the PV-3 includes:

  • Tracing capability requirements to projects
  • Capability audit

The PV-3 describes the mapping between capabilities and the programs, projects, portfolios, or initiatives that would support the capabilities. This model may be used to indicate that a project does or does not fulfill the requirements for a capability for a particular phase. This model is analogous to the SV-5a “Operational Activity to System Function Traceability Matrix”, but provides the interface between Capability and Project Models rather than Operational to System Models.

In principle, there could be a different PV-3 table created for each development phase of the program, project, portfolio, or initiative development, or perhaps for different phasing scenarios. In most cases, a single table can be constructed because the programs, projects, portfolios, or initiatives that are most likely relevant to this model can be relatively high level. If capabilities associated are generic (see CV-1 Vision Model), then they should have a well understood relationship with a set of programs, projects, portfolios, or initiatives and this relationship is unlikely to change over time.

The PV-3 can have a tabular presentation. The rows can be the Capabilities and the columns can be the programs, projects, portfolios, or initiatives. An X can indicate where the capability is supported by the programs, projects, portfolios, or initiatives whereas a blank can indicate that it does not. Alternatively, a date or phase can indicate when programs, projects, portfolios, or initiatives will support capabilities by the date or phase indicated.

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/27/2017

DoDAF Architecting

PV-1 Project Portfolio Relationships

The PV-1 “Project Portfolio Relationships” represents an organizational perspective on programs, projects, portfolios, or initiatives. It enables the user to model the organizational structures needed to manage programs, projects, portfolios, or initiatives. It shows dependency relationships between the actual organizations that own the programs, projects, portfolios, or initiatives. This model could be used to represent organizational relationships associated with transformation initiatives along with those who are responsible for managing programs, projects, and portfolios. The PV-1 provides a means of analyzing the main dependencies between acquisition elements or transformation elements.

Guide: DoDAF Architecture Framework Version 2.02 – Page 162

The intended usage of the PV-1 includes, but is not limited to:

  • Program management (specified acquisition program structure).
  • Project organization.
  • Cross-cutting initiatives to be tracked across portfolios.

The PV-1 describes how acquisition projects are grouped in organizational terms as a coherent portfolio of acquisition programs or projects, or initiatives related to several portfolios. The PV-1 provides a way of describing the organizational relationships between multiple acquisition projects or portfolios, each of which are responsible for delivering individual systems or capabilities. By definition, this model covers acquisition portfolios or programs consisting of multiple projects and is generally not for an individual project. In essence, PV-1 is an organizational breakdown consisting of actual organizations (see OV-4 “Organizational Relationships Chart”). The model is strongly linked with the CV-4 “Capability Dependencies” model which shows capability groupings and dependencies. The PV-1 is hierarchical in nature. Higher-level groupings of projects (the organizations that own these projects) form acquisition programs or initiatives.

The intent of a PV-1 is to show:

  • All of the acquisition projects delivering services, systems, or SoS within the acquisition programs under consideration.
  • Cross-cutting initiatives to be tracked across portfolios.
  • Other services, systems, and SoS which may have a bearing on the architecture. How the services or systems will be best integrated into an acquisition program.
  • The nesting of acquisition programs to form a hierarchy.
   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:

UpdatedL 9/27/2017

DoDAF Architecting

Physical Architecture(arch)

 

The physical architecture is the physical layout of a system and its components in a schema.  It refers to some  representation of the structure or organization of the physical elements of the system.  The physical architecture should be part of the Allocated and Product Baselines.

WBS

SMC Systems Engineering Handbook Example – Page 25

The development of the physical architecture consists of one or more logical models or views of the physical solution. The logical models or views may consist of conceptual design drawings, schematics, and block diagrams that define the systems form and the arrangement of the system components and associated interfaces. The development of a physical architecture is an iterative and recursive process and will evolve together with the requirements and functional architecture. Development of the physical architecture is complete when the system has been decomposed down to lowest system element or configuration item level, and it is critical that this process identify the design drivers as early as possible. Therefore, it is imperative that the driving requirements be identified and the combined processes—Stakeholder Requirements Definition, Requirements Analysis, and Architecture Design—will provide key insights to risk early in the development life cycle, allowing for mitigating strategies. [1]

Key activities performed when developing a physical architecture and design include:

  • Analysis and synthesis of the physical architecture and the appropriate allocation,
  • Analysis of the constraint requirements,
  • Identify and define physical interfaces and components, and
  • Identify and define critical attributes of the physical components, including design budgets (e.g., weight, reliability) and open system principles.

AcqLinks and References:

DoDAF Architecting

Project Viewpoints

The Project Viewpoint (PV) describe how programs, projects, portfolios, or initiatives deliver capabilities and the organizations contributing to them and the dependencies between them. These models expand the usability of the DoDAF by including information about programs, projects, portfolios, or initiatives and relating that information to capabilities and other programs, projects, portfolios, or initiatives. This expands DoDAF’s support to include the portfolio management process. Different levels of cost data can be captured in the architecture based on the process-owners requirements.

There are three (3) PV are:

  1. PV-1 Project Portfolio Relationship
  2. PV-2 Project Timelines
  3. PV-3 Project to Capability Mapping

These models are especially applicable to the Programming Phase of the PPBE Process and it’s within this phase that the Program Objective Memorandum (POM) is developed. The POM seeks to construct a balanced set of programs that respond to the guidance and priorities of the Joint Programming Guidance (JPG) within fiscal constraints. When completed, the POM provides a fairly detailed and comprehensive description of the proposed programs. The information captured within the Project models can be used within the PPBE process to develop the POM.

The Project Models can be used to answer questions such as:

  • What capabilities are delivered as part of this project?
  • Are there other projects that either affect or are affected by this project?
  • To what portfolios do the projects or projects belong?
  • What are the important milestones relative to this project?
  • When can I expect capabilities to be rendered by this project to be in place?

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/27/2017

DoDAF Architecting

PV-2 Project Timelines

The PV-2 “Project Timelines” provides a timeline perspective on programs. The PV-2 is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of DoD Directive 5000.1 “Defense Acquisition System” policies to achieve a successfully integrated capability. The PV-2 is not limited to the acquisition and fielding processes.

Guide: DoDAF Architecture Framework Version 2.02 – Page 164

The intended usage of the PV-2 includes:

  • Project management and control (including delivery timescales)
  • Project dependency risk identification
  • Management of dependencies
  • Portfolio management

The PV-2 provides an overview of a program or portfolio of individual projects, or initiatives, based on a timeline. Portfolios, Programs, Projects, and Initiatives may be broken into work streams to show the dependencies at a lower-level. For capability-based procurement, these work streams might conveniently be equated with JCA. Sometimes, however, it is more appropriate to consider these acquisition projects in their own right.

Where appropriate, the PV-2 may also summarize, for each of the projects illustrated, the level of maturity achieved across the DoDD 5000.1 policies at each stage of the Defense Acquisition System lifecycle, and the interdependencies between the project stages.

The PV-2 is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of DoDD 5000.1 policy to achieve a successfully integrated capability. However, the PV-2 is not limited to the acquisition and fielding processes. The information provided by the Model can be used to determine the impact of either planned or unplanned programmatic changes, and highlight opportunities for optimization across the delivery program. The inclusion of the DoDD 5000.1 policy information allows areas of concern that are outside the immediate scope being considered. Areas of concern identified across the DoDD 5000.1 Defense Acquisition System policies, e.g., a shortfall in training resource, can be coordinated across a program or group of projects, each of which require additional activity to be initiated for successfully delivery according to the project/program schedule.

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/27/2017

DoDAF Architecting

OV-6b State Transition Description

The OV-6b “State Transition Description” is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which 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.

Guide: DoDAF Architecture Framework Version 2.02 – Page 156

An OV-6b can be used to describe the detailed sequencing of activities or work flow in the business process. The OV-6b is particularly useful for describing critical sequencing of behaviors and timing of operational activities that cannot be adequately described in the OV-5b Operational Activity Model. The OV-6b relates events and states. A change of state is called a transition. Actions may be associated with a given state or with the transition between states in response to stimuli (e.g., triggers and events).

The intended usage of the OV-6b includes:

  • Analysis of business events
  • Behavioral analysis.
  • Identification of constraints
   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/27/2017

DoDAF Architecting

OV-6c Event-Trace Description

The OV-6c “Event-Trace Description” provides a time-ordered examination of the Resource Flows as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. Operational Event/Trace Descriptions, sometimes called sequence diagrams, event scenarios, or timing diagrams, allow the tracing of actions in a scenario or critical sequence of events.

Guide: DoDAF Architecture Framework Version 2.02 – Page 158

The OV-6c can be used by itself or in conjunction with an OV-6b State Transition Description to describe the dynamic behavior of activities.

The intended usage of the OV-6c includes:

  • Analysis of operational events.
  • Behavioral analysis.
  • Identification of non-functional user requirements.
  • Operational test scenarios
   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/27/2017

DoDAF Architecting

OV-5b Operational Activity Model

The OV-5a and the OV-5b “Operational Activity Model” describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 152

The OV-5a and OV-5b describes the operational activities that are being conducted within the mission or scenario. The OV-5a and OV-5b can be used to:

The OV-5b describes the operational, business, and defense portion of the intelligence community activities associated with the Architectural Description, as well as the:

  • Relationships or dependencies among the activities.
  • Resources exchanged between activities.
  • External interchanges (from/to business activities that are outside the scope of the model).

An Operational Activity is what work is required, specified independently of how it is carried out. To maintain this independence from implementation, logical activities and locations in OV-2 “Operational Resource Flow Description” are used to represent the structure which carries out the Operational Activities. Operational Activities are realized as System Functions (described in SV-4 “Systems Functionality Description”) or Service Functions (described in SvcV-4 Services Functionality Description) which are the how to the Operational Activities what, i.e., they are specified in terms of the resources that carry them out.

The intended usage of the OV-5a and OV-5b includes:

  • Description of activities and workflows
  • Requirements capture
  • Definition of roles and responsibilities
  • Support task analysis to determine training needs
  • Problem space definition
  • Operational planning
  • Logistic support analysis
  • Information flow analysis
   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/27/2017

DoDAF Architecting

OV-5a Operational Activity Decomposition Tree

The OV-5a “Operational Activity Model” and the OV-5b describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 152

The OV-5a and OV-5b describes the operational activities that are being conducted within the mission or scenario. The OV-5a and OV-5b can be used to:

An Operational Activity is what work is required, specified independently of how it is carried out. To maintain this independence from implementation, logical activities and locations in OV-2 “Operational Resource Flow Description” are used to represent the structure which carries out the Operational Activities. Operational Activities are realized as System Functions (described in SV-4 “Systems Functionality Description”) or Service Functions (described in SvcV-4 Services Functionality Description) which are the how to the Operational Activities what, i.e., they are specified in terms of the resources that carry them out.

The intended usage of the OV-5a and OV-5b includes:

  • Description of activities and workflows
  • Requirements capture
  • Definition of roles and responsibilities
  • Support task analysis to determine training needs
  • Problem space definition
  • Operational planning
  • Logistic support analysis
  • Information flow analysis
   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/27/2017

DoDAF Architecting

OV-6a Operational Rules Model

An OV-6a “Operational Rules Model” specifies operational or business rules that are constraints on the way that business is done in the enterprise. At a top-level, rules should at least embody the concepts of operations defined in OV-1 “High Level Operational Concept Graphic” and provide guidelines for the development and definition of more detailed rules and behavioral definitions that should occur later in the Architectural definition process.

Guide: DoDAF Architecture Framework Version 2.02 – Page 154

The intended usage of the OV-6a includes:

  • Definition of doctrinally correct operational procedures
  • Definition of business rules
  • Identification of operational constraints

At the mission-level, OV-6a may be based on business rules contained in doctrine, guidance, rules of engagement, etc. At lower levels, OV-6a describes the rules under which the architecture behave under specified conditions. Such rules can be expressed in a textual form. These rules are contrasted with the business or doctrinal standards themselves, which provide authoritative references and provenance for the rules (see StdV-1 Standards Profile). Operational Rules are statements that constrain some aspect of the mission or the architecture. Rules may be expressed in natural language (English) in one of two forms:

  • Imperative – a statement of what shall be under all conditions, e.g., “Battle Damage Assessment” (BDA) shall only be carried out under fair weather conditions.”
  • Conditional Imperative – a statement of what shall be, in the event of another condition being met. If battle damage assessment shows incomplete strike, then a restrike shall be carried out.
   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/27/2017