DI-SESS-82380

Model Based Systems Engineering (MBSE) Development Plan (MDP)

Describes the contractor's technical approach and plan for the conduct, management, and control of the integrated Model Based Systems Engineering (MBSE) effort, reflecting scope, purpose, and life cycle phases of the program.

Approval DateMarch 24, 2022

AMSC NumberF10309

Preparing Activity19

Project NumberSESS-2022-001

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Model Based Systems Engineering (MBSE) Development Plan (MDP) describes the contractor's technical approach and proposed plan for the conduct, management, and control of the integrated MBSE effort. It reflects the scope, purpose, and life cycle phase(s) of the program. The MDP provides insight into: the contractor's processes to be followed for model development and maintenance; the tools to be used; the framework and methodology to be used; the approach to be followed for each activity; the reporting and review artifacts; the linkage to lower level designs and design artifacts; and the project schedule, resources, and progress monitoring and tracking. It supports the system engineering activities; therefore, a program's MDP is expected to be consistent with its Systems Engineering Management Plan (SEMP). Additional guidance on the content of the MDP is available in Aerospace Technical Report, ATR-2020-02088, Guidance for Model Based Systems Engineering Development Plan (Copies of the report can be obtained from: SSC/ZAE, 483 N. Aviation Blvd, El Segundo, CA 90245-2808 or via e-mail to: SSC/ZAE Workflow ([email protected]). Distribution is authorized to U.S. Government agencies and their contractors; Administrative or Operational Use.)

This DID contains the format, content, and intended use information for the data deliverable resulting from the work task described in the solicitation.

Preparation Instructions

1Reference DocumentsThe applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.

2FormatThe MDP shall be in the contractor's format.

3ContentThe MDP shall address all MBSE modeling topics and topics where modeling can be used for the benefit of the government in the system development. The MDP shall be consistent with the government Systems Engineering Plan (SEP) and the contractor's SEMP, if available. (Refer to DI-SESS-81785, Systems Engineering Management Plan (SEMP) for guidance.) The MDP shall include:

3.1Contractor's MBSE ApproachThis subsection shall describe the contractor's planned engineering approach to meeting the program's contract, objectives, and overall technical and management approach for the model development effort, including new development, modification, reuse, integration, and all other activities resulting in model work products. The MDP shall include:

3.1.1PurposeThis subsection shall describe the purpose of the MDP for conducting an MBSE model development effort.

3.1.2Scope and ObjectivesThis subsection shall describe the high-level scope and objectives for the MDP.

3.1.3Assumptions and ConstraintsThis subsection shall describe the assumptions and constraints of the model development, such as: schedule, budget, tools, framework, or technology.

3.1.4Plan EvolutionThis subsection shall describe the approach to updating the MDP and keeping it current with other program acquisition documents, such as the SEMP.

3.2MBSE Roles and ResponsibilitiesThis subsection shall identify and describe the MBSE-specific roles and responsibilities of model stakeholders and model development team members. The stakeholders shall be shown in three groups: Customer, Organizational, and Internal, as follows:

3.2.1Customer StakeholdersCustomers shall include direct customers, customer representatives, and customer support personnel. Example customer stakeholders are:

3.2.1.1Program Manager(Responsible for cost, schedule, and technical performance of the program requiring a model to be developed.)

3.2.1.2Program Chief Engineer

3.2.1.3Program Systems Engineering and Technical Assistance (SETA), Program Systems Engineering and Integration (SE&I)

3.2.1.4Program Federally Funded Research and Development Center (FFRDC)

3.2.2Organizational StakeholdersOrganizational stakeholders shall include those who are not part of the model development team, but who are within the same organization or company (or contractor team). Example organizational stakeholders are:

3.2.2.1Modeling Manager

3.2.2.2Chief Engineer

3.2.2.3Chief Architect

3.2.2.4Systems Engineering Manager

3.2.2.5Integrated Product Team Leaders

3.2.2.6Configuration Manager

3.2.2.7Data Manager

3.2.2.8Project Manager

3.2.2.9Program Manager(Responsible for all aspects of the program requiring a model to be developed. Company interface to the customer program manager.)

3.2.2.10Contracts Representative

3.2.2.11Chief Information Officer

3.2.2.12Chief Data Officer

3.2.3Internal StakeholdersInternal stakeholders shall include members of the model development team. The model development team shall be identified including their relationship to the organizational stakeholders in 3.2.2 (e.g., Chief Engineer, Chief Architect, Systems Engineering Manager, or Modeling Manager). Example internal stakeholders are:

3.2.3.1Model Developer(s)

3.2.3.2Model Architect

3.2.3.3Model Tool Developer(s)

3.2.3.4Model Tool Administrator(s)

3.2.3.5Integrated Digital Environment (IDE) Developer(s) and Maintainer(s)

3.3MBSE ProcessesThis subsection shall describe the modeling framework, methodology, and development process to be used to perform various model development activities, such as: defining requirements, establishing model structure and environment, implementing, integrating, verifying and validating, and releasing the model and model work products. The MDP shall include:

3.3.1Technical BaselineThis subsection shall describe the plan and approach for capturing and establishing the engineering technical baseline of the system as a MBSE model. It shall identify and describe the technical baseline information that the modeling development effort depends on and a plan for updating and synchronizing the technical baseline information throughout the acquisition lifecycle, including for technical reviews. Examples of technical baseline information are:

3.3.1.1Concept of Operations (CONOPs) Document

3.3.1.2Capability Development Document (CDD)

3.3.1.3Technical Requirements Document (TRD)

3.3.1.4Interface Control Document (ICD)

3.3.1.5System Segment or Element Requirements Document

3.3.1.6Statement of Work (SOW)

3.3.1.7Statement of Objectives (SOO)

3.3.1.8Technical Proposal (negotiated)

3.3.2Model Objectives and Stakeholder RequirementsThis subsection shall describe the plan and approach for capturing the modeling objectives and stakeholder requirements. Examples of model objectives and stakeholder requirements are:

3.3.2.1The model will address the following concerns1) concern A; 2) concern B; 3) concern C; etc.

3.3.2.2The model will answer the following questions1) question A; 2) question B; 3) question C; etc.

3.3.2.3As stakeholder one, I want to seethe requirements traceability between the CDD and the TRD for completeness and consistency, where all lower level requirements have a parent system requirement and there are no orphan requirements.

3.3.2.4As stakeholder two, I want to knowthe allocation of system requirements into system and subsystem architecture components for completeness.

3.3.2.5As stakeholder three, I want to addressinterface concerns between system A and system B. The interface concerns to be addressed are: message format, message error handling, and interface pin.

3.3.3Model Framework and MethodologyThis subsection shall describe the modeling framework and methodology to be used. Modeling profiles to be used in model construction shall be identified, as well. Examples of modeling frameworks and methodologies are:

3.3.3.1Defense Architecture Frameworkssuch as: United States (US) Department of Defense Architecture Framework (DODAF), United Kingdom (UK) Ministry of Defense Architecture Framework (MODAF), North Atlantic Treaty Organization (NATO) Architecture Framework (NAF)

3.3.3.2Unified Architecture Framework (UAF)

3.3.3.3Unified Architecture Framework Profile (UAFP) or Unified Architecture Framework Modeling Language (UAFML) for modeling architectures consistent with DoDAF, MODAF, NAF, or UAF

3.3.3.4Unified Profile for DODAF and MODAF (UPDM) for modeling architectures consistent with DoDAF or MODAF

3.3.3.5The Open Group Architecture Framework (TOGAF)

3.3.3.6Object Oriented Systems Engineering Methodology (OOSEM)

3.3.3.7MagicGrid Framework for Systems Modeling Language (SysML) by NoMagic

3.3.3.8Custom Architectural Framework (AF) based on SysML, explicitly or implicitly

3.3.4MBSE Style GuideThis subsection shall describe the modeling style guide to be followed. The MBSE style guide shall provide a set of rules for the model developers to follow for standardized definitions and looks of the model elements, model views, and generated documents. Examples of content to be included in the MBSE style guide are:

3.3.4.1General style guidelines for model organization, naming convention, style and layout, documentation, and use of relationships

3.3.4.2Model view specifics guidelines for modeling requirements, structures, behaviors, and interfaces

3.3.4.3Any modeling patterns to use

3.3.5Model Development EnvironmentThis subsection shall describe the approach to be followed for establishing, controlling, and maintaining a MBSE model development environment. A model development environment is a collection of tools to be used by the model developer to build model elements, views, and other work products. In general, the model development environment includes modeling tool, modeling language, configuration management tool, and other non-MBSE tools used to support the MBSE development effort (e.g., digital collaboration tools, workflows, file management schema, and configuration control processes). Versions of tools, plug-ins, macros, scripts, and libraries being used shall be included.

3.3.6Model Development ActivitiesThis subsection shall describe the plan and approach for performing the MBSE development activities, which shall include the following:

3.3.6.1Define Model RequirementsThis subsection shall describe the process, steps, and procedures the contractor follows for analyzing, defining, and capturing the model requirements. The model requirement activity starts with analyzing and capturing the stakeholders' concerns into stakeholders' objectives and requirements, with acceptance criteria. This activity defines the process for decomposing the stakeholders' objectives and requirements into the model requirements that are non-compound and verifiable. This subsection shall also include definition of the fidelity of the models needed to meet the stakeholders' acceptance criteria. It shall also describe how all model requirements are to be verified, validated, and traced to the model elements, views, and other model work products. For example, this subsection includes processes, such as: the review and approval of model requirements by the stakeholders who provided their modeling objectives and requirements and, for iterative model development, determination and prioritization of the model requirements incrementally at each iteration or release.

3.3.6.2Establish Model Structure and EnvironmentThis subsection shall describe the process, steps, and procedures the contractor follows for analyzing the modeling needs, organizing the model structure, and establishing model boundaries and constraints. For example, this subsection includes processes, such as: selection of modeling tools and definition of the model style guides, establishment of the infrastructure and foundation for the model developers, and, for iterative model development, analysis of model needs and requirements, and updates to the model structure and style guide at each iteration or release.

3.3.6.3Implement ModelThis subsection shall describe the processes, steps, and procedures the contractor follows to build the model elements, views, and other required model work products to satisfy the model requirements within the constraints identified by the model structure, environment, and style guide. This subsection shall identify the model work products to be created during this phase of activity and describe the internal verification process to ensure that the implemented models satisfy the model requirements. For example, the description of internal verification processes includes: peer review, automated scripts, and, for iterative model development, models that are built incrementally at each iteration. Activities and tasks for implementing models of the architecture are further described in International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) / Institute of Electrical and Electronics Engineers (IEEE) 42020, Architecture Processes (Copies of ISO/IEC/IEEE 42020 can be obtained at: https://standards.ieee.org).

3.3.6.4Verify and Validate ModelThis subsection shall describe the processes, steps, and procedures the contractor follows to formally verify and validate the model requirements. This subsection shall also identify model work products to be created during this activity to show results of the verification and validation process. For example, the verification activities ensure that the created model elements, views, and other model work products fulfill the model requirements. Model verification is often performed by an independent person or team outside of the MBSE development team. The validation activities ensure that the model views and other model work products meet the stakeholder objectives and requirements and address their concerns. Model validation is performed by the stakeholders outside of the MBSE development team. For iterative model development, verification and validation can be executed incrementally at each iteration or release.

3.3.6.5Release ModelThis subsection shall describe the plan and approach the contractor follows for configuration management and release of the model project files, model views, and other model work products, including reports and documentation. This subsection shall identify the expected contents of each model release, when the release will occur, and who will perform the release.

3.3.6.6Update ModelThis subsection shall describe the plan and approach the contractor follows for updating the model to incorporate changes, including such items as: changes in model requirements, model structure, model environment, model style guide, and technical baseline documents.

3.3.6.7Model LibraryThis subsection shall identify and describe the plan and approach the contractor follows for reusing the reference model libraries specified in the contract, if any.

3.3.6.8External Model IntegrationThis subsection shall identify and describe the plan and approach the contractor follows for integrating the model with external models (e.g., government-provided models, models provided by other contractors) and tools. This subsection shall identify external models and tools for which integration is to be performed and describe the integration approach for each model and tool.

3.4NotesThis section shall contain any general information that aids in the understanding of the MDP (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in the MDP and a list of any terms and definitions needed to understand the MDP.

References

ISO/IEC/IEEE 42020, Architecture Processes https://standards.ieee.org

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer