Acq Notes

The System View (SV)-9 “Systems 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 as well as the expected improvements or trends. New technologies and skills are tied to specific […]

The System View (SV)-10a “Systems Rules Mode” specifies functional and non-functional constraints on the implementation aspects of the architecture (i.e., the structural and behavioral elements of the Systems Viewpoint). Guide: DoDAF Architecture Framework Version 2.02 – Page 225 The SV-10a DoDAF-described Model describes constraints on the resources, functions, data, and ports that make up the

The System View (SV)-8 “Systems Evolution Description” presents a whole lifecycle view of resources (systems), describing how they change over time. It shows the structure of several resources mapped against a timeline. The intended usage of the SV-8 includes: Development of incremental acquisition strategy. Planning technology insertion. Guide: DoDAF Architecture Framework Version 2.02 – Page

The System View (SV)-7 “Systems Measures Matrix” depicts the measures (metrics) of resources. The Systems Measures Matrix expands on the information presented in a SV-1 “Systems Interface Description” by depicting the characteristics of the resources in the SV-1. The intended usage of the SV-7 includes: Definition of performance characteristics and measures (metrics). Identification of non-functional

The System View (SV)-5b “Operational Activity to Systems Traceability Matrix” addresses the linkage between described in SV-1 “Systems Interface Description” and Operational Activities specified in OV-5a “Operational Activity Decomposition Tree” or OV-5b “Operational Activity Model”. The SV-5b depicts the mapping of systems and, optionally, the capabilities and performers that provide them to operational activities. The

The System View (SV)-6 “Systems Resources Flow Matrix” specifies the characteristics of the System Resource Flows exchanged between systems with emphasis on resources crossing the system boundary. It focuses on the specific aspects of the system Resource Flow and the system Resource Flow content in a tabular format. The intended usage of the SV-6 includes:

The System View (SV)-5a “Operational Activity to Systems Function Traceability Matrix” addresses the linkage between System Functions described in SV-4 “Systems Functionality Description” and Operational Activities specified in OV-5a “Operational Activity Decomposition Tree” or OV-5b “Operational Activity Model”. The SV-5a depicts the mapping of system functions and, optionally, the capabilities and performers that provide them

The System View (SV)-4 “Systems Functionality Description” addresses human and system functionality. The primary purposes of SV-4 are to: Develop a clear description of the necessary data flows that are input (consumed) by an output (produced) by each resource. Ensure that the functional connectivity is complete (i.e., that a resource’s required inputs are all satisfied).

A System View (SV)-3 “Systems-Systems Matrix” enables a quick overview of all the system resource interactions specified in one or more SV-1 Systems Interface Description models. The SV-3 provides a tabular summary of the system interactions specified in the SV-1 Systems Interface Description model for the Architectural Description. The matrix format supports a rapid assessment

A System View (SV)-2 “Systems Resource Flow Description” specifies the System Resource Flows between Systems and may also list the protocol stacks used in connections. It’s used to give a precise specification of a connection between Systems. This may be an existing connection, or a specification for a connection that is to be made. Guide:

The System View (SV)-1 “Systems Interface Description” addresses the composition and interaction of Systems. The SV-1 incorporates the human elements as types of Performers – Organizations and Personnel Types. Guide: DoDAF Architecture Framework Version 2.02 – Page 204 The SV-1 links together the operational and systems architecture models by depicting how Resources are structured and

DoDAF Services Viewpoint (SvcV) describes services and their interconnections providing or supporting DoD functions. DoD functions include both warfighting and business functions. The Service Models associate service resources to operational and capability requirements. These resources support the operational activities and facilitate the exchange of information. The relationship between architectural data elements across the Services Viewpoint

The Standards Viewpoint (StdV) StdV-2 contains expected changes in technology-related standards, operational standards, or business standards and conventions, which are documented in the StdV-1 model. The forecast for evolutionary changes in the standards need to be correlated against the time periods mentioned in the: SV-8 Systems Evolution Description SvcV-8 Services Evolution Description SV-9 Systems Technology

The Standards Viewpoint (StdV) StdV-1 defines the technical, operational, and business standards, guidance, and policy applicable to the architecture being described. It also documents the policies and standards that apply to the operational or business context. The intended usage of the StdV-1 includes: Application of standards (informing project strategy). Standards compliance. Guide: DoDAF Architecture Framework

The Standards Viewpoint (StdV) is the set of rules governing the arrangement, interaction, and interdependence of parts or elements of the Architectural Description. These sets of rules can be captured at the enterprise level and applied to each solution. Its purpose is to ensure that a solution satisfies a specified set of operational or capability

A Reference Architecture guides and constrains the development of Solution Architectures. There may be multiple Reference Architectures within a subject area where each represents a different emphasis or viewpoint. They can be defined at many levels of detail and abstraction (from specific to generalized) and for many different purposes. They help provide: [1] A common

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,

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

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

  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. SMC Systems Engineering Handbook Example – Page 25 The

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

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

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 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

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 –