DI-MGMT-82099.pdf

DATA ITEM DESCRIPTION

Title: OPEN SYSTEMS MANAGEMENT PLAN

Number: DI-MGMT-82099 Approval Date: 20170111

AMSC Number: 9764 Limitation: None

DTIC Applicable: No GIDEP Applicable: No

Preparing Activity: MI Project Number: MGMT-2017-009

Applicable Forms: N/A

Use/relationship:

The essence of Open Systems Architecture (OSA) is an organized decomposition, using carefully defined execution boundaries, layered onto a framework of software and hardware shared services and a vibrant business model that facilitates competition. An Open Systems Management Plan (OSMP) describes the developer’s approach for using modular design, standards-based interfaces, and widely-supported, consensus-based standards to achieve these goals. The OSMP shall include a developer’s plans for a modular, open architecture, to include use of open interface standards and Technical Reference Frameworks (TRF); design and management of, and dependencies between, Computer Software Configuration Items (CSCIs); design information documentation;

technology insertion; life cycle sustainability; treatment of proprietary or vendor-unique elements;

and reuse of existing items. The OSMP includes a support plan for the Modular Open Systems Approach (MOSA) and provides the acquirer visibility into the developers’ open systems approach and implementation. This forms a basis for evaluation of a developer’s proposal and adherence to MOSA technical and business goals.

This Data Item Description (DID) contains the format, content, and intended use information for the data product resulting from the work task described in the contract Statement of Work (SOW), Performance Based SOW (PBSOW) or Statements of Objectives (SOO).

Requirements:

1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as listed on the ASSIST website, the official source for specifications and standards used by the Department of Defense, at the time of the solicitation unless as otherwise stated.

2. Format. The plan shall be in contractor’s format. The Contract Data Requirements List (CDRL) (DD 1423) will specify whether deliverable data are to be on paper or electronic media; are to be in a given electronic format (such as the American Standard Code for Information Interchange (ASCII) or compatible with a specified word processor or other support software);

can be delivered in developer format rather than in the format specified herein.

3. Content. The Open Systems Management Plan shall contain the following:

Source: https://assist.dla.mil -- Downloaded: 2018-04-20T15:07Z Check the source to verify that this is the current version before use.

DI-MGMT-82099

3.1 Scope. This section shall be divided into the following paragraphs:

3.1.1. Identification. This paragraph shall contain a full identification of the system and the software and hardware components to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

3.1.2. System overview. This paragraph shall briefly state the purpose of the system to which the plan applies and the overall system design. It shall describe the general nature of the system software and hardware; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites;

and list other relevant documents.

3.1.3. Document overview. This paragraph shall summarize the purpose and contents of this the plan and shall describe any security or privacy considerations associated with its use.

3.2 Referenced documents. This section shall list the number, title, revision, and date of all documents referenced in the plan. This section shall also identify the source for all documents not available through normal Government stocking activities.

3.3 Open Architecture Technical Approach and Processes. This section shall be divided into the following paragraphs to describe the proposed open architecture technical approach and processes to be employed in addressing and performing this contract.

3.3.1. Open Architecture Approach. This section shall describe in detail the selected approach for addressing a system architecture that incorporates appropriate considerations for reconfigurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and life cycle supportability. This section shall include identification of the open standards, interfaces and/or Technical Reference Frameworks selected for the system architecture, in addition to those required by the SOW, PBSOW or SOO. In addition, this section shall address the means for ensuring adherence or conformance to open standards and open architectural principles throughout the development process.

3.3.2. Modular Architecture. This section shall describe in detail how the proposed system architecture is robust, layered, modular, adaptable and makes maximum use of existing Government-Off-the-Shelf (GOTS) hardware and software, Commercial CSCIs including Commercial-Off-the-Shelf (COTS) software, COTS hardware, operating systems, and middleware that utilize well-defined, widely accepted and adopted open standards for the application programming interfaces (APIs). The description shall define the approach for designing a system that reduces module coupling and increases module cohesion.

3.3.3. Rationale for Modularization Choices. This section shall describe in detail the rationale for the modularization choices made to generate the design and isolate the functionality of the CSCIs. The description shall include the hierarchy of software and hardware configuration items and a discussion of how the modularization choices support competitive acquisition, ease of technology refresh and reuse. The description shall explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system.

3.3.4. MOSA Support Plan. This section shall describe how specific elements of the system design, including modularity choices and the selected TRFs, interfaces and open standards, support MOSA goals and objectives Details in this section should include how the modularity of the system design will:

a. Enable the system to adapt to evolving requirements and threats to maintain currency.

b. Enhance interoperability and the ability to integrate new capabilities without redesign of entire systems or large portions thereof.

c. Enable the system to survive various technical refresh strategies (e.g. insertion of COTS or GOTS CSCIs) and changes to the computing infrastructure, while limiting software changes to only integration software and requiring minimal or no changes to the application logic of the new capabilities.

d. Improve the ability to reuse capabilities with little or no modification to the capability code.

e. Facilitate systems reconfiguration and integration during technical refresh.

f. Reduce the development cycle time and total life cycle cost.

g. Maintain continued access to cutting edge technologies and products from multiple suppliers.

h. Promote identification of multiple sources of supply and support flexible business strategies that enhance subcontractor competition.

i. Mitigate the risks associated with reliance on a single source of supply over the life of the system including technology obsolescence and dependence on proprietary or vendor-unique technology.

3.3.5. Design Disclosure and Data Rights Strategy. The Government needs to have the ability to share design documentation, architecture definition, specifications, interfaces and tools. This section shall provide a detailed description of the proposed delivery and disclosure of the proposed system design and documentation. In addition, this section shall include a summary of the Technical Data Rights strategy for the data deliverables included in the RFP and subsequent contracts. This section shall address:

a. Within the constraints of contractual data rights, a description of the approach to facilitate the sharing of system or component (e.g., software, hardware, middleware) design information in support of peer reviews and the development process. In addition, description should address how information will be provided to support third party development and delivery of competitive alternatives or designs for software or other Software Units or CSCIs on an ongoing basis. This information can be used to support Integrated Product Teams (IPTs), and to facilitate competition for CSCI supplies.

b. The plan to establish and maintain a process that provides “early and often” design disclosure and making design and interface information available as soon as possible after it is defined or established.

c. The data management approach including how data will be delivered, accessed, maintained and protected, to include how the exchange of information shall be structured to protect the contractors and third party developers’ proprietary or vendor-unique rights in the information.

d. How the design shall be documented and modeled using industry standard formats (e.g., Unified Modeling Language), and how it shall use tools that are capable of exporting model information in a standard format (e.g., Extensible Markup Language Metadata Interchange (XMI) and AP233/ISO 10303), and the proposed standards and formats to be used. Specific tools shall be identified and annotated whether they are commercially available or proprietary.

e. The level of system design at which rights to technical data and computer software will be available or provided for system components. Government desire would be for the data rights to be specified to the CSCI level.

f. How the developer intends to provide licenses, source code, drawings, repair and engineering documentation to the Government and third party contractors at specified key events or at defined intervals. For Commercial CSCIs, copies of or links to license agreements related to the use of these CSCIs should be included for Government review.

g. How the data rights or licenses expected to be conveyed by the vendor and the vendor’s subcontractors will affect support of the system over its life cycle, particularly in terms of future software-centric modifications and upgrades.

3.4 Interface Design and Management. This section shall be used to describe the process for clearly defining component and system interfaces. At a minimum, this section shall address the following:

a. Describe how interfaces will be selected from existing open or Government standards with emphasis on system-level or enterprise-level (when applicable) interoperability.

b. Describe how the selection of interfaces will maximize the ability of the system to readily accommodate technology insertion (both hardware and software) and facilitate the insertion of alternative or reusable modular system elements.

c. Describe how all subsystem and configuration Item (CI) level interfaces will be defined and documented.

d. Identify the processes for specifying the lowest level, i.e. subsystem or component, at or below which it intends to control and define interfaces by proprietary, vendor-unique standards, as well as the impact of those standards on the proposed modularity and logistics approach.

e. Identify the interface and data exchange standards between component, module, or system and the interconnecting or underlying information exchange medium.

f. Describe how the system interfaces will allow for:

i. Quickly interconnecting, reconfiguring and assembling existing systems, subsystems and components

ii. Interchanging and using information, services, and/or physical items among components with a system

iii. Supporting reuse of software and the common use of components across various product lines

iv. Transferring a system, component, or data, from one hardware or software environment to another.

g. Describe the process to address migration of proprietary, vendor-unique or closed system equipment or interfaces to a modular open systems design when technological advances are available or when operational capability is upgraded.

3.5 Treatment of Proprietary or Vendor-Unique Elements. This section shall be divided into the following paragraphs to identify, describe and justify any use of proprietary, vendor-unique, or closed CSCIs, including Commercial CSCIs including COTS, and interfaces in current or future designs. It shall describe the process for identifying and justifying proprietary, vendor-unique or closed interfaces, code modules, hardware, firmware, or software to be used in current or future designs. This Section shall be divided into the following paragraphs:

a. Partitioning of Proprietary or Vendor-Unique Elements. Describe decisions to employ partitioning or other design techniques to isolate all proprietary, vendor-unique portions of interfaces, hardware, firmware, and Software Unit or CSCI level.

b. Interfacing to Proprietary or Vendor-Unique Elements. Describe how the integration of closed or proprietary, vendor-unique equipment, interfaces, data systems or functions due to a unique or specific system requirement shall not preclude or hinder other Software Unit or CSCI developers from interfacing with or otherwise developing, replacing, or upgrading open parts of the system.

c. Segregation of Proprietary or Vendor-Unique Elements. Identify the steps to prevent the open elements of the system from intertwining with proprietary or vendor-unique elements in a manner that restricts or limits the ability to replace or upgrade the open elements using an open competitive selection process.

d. Modularity. Describe the modularity of the system design that promotes identification of multiple sources of supply and supports flexible business strategies that enhance subcontractor competition.

e. Licensing. Describe how the developer intends to provide all non-proprietary licenses, source code, drawings, repair and engineering documentation to the Government and third party contractors at specified key events or at defined intervals. The data rights shall be specified to the CSCI level.

f. Third Party Development. Describe how the developer shall provide information needed to support third party development and delivery of competitive alternatives or designs for software or other Software Units or CSCIs on an ongoing basis. This information can be used as part of peer review processes, to support Integrated Product Teams (IPTs), and to facilitate competition for CSCI supplies. In addition, this paragraph shall provide a list of those proprietary or vendor-unique elements the developer requests be exempt from this review.

3.6 Life Cycle Management and Open Systems. This section shall describe the selected strategy for reducing product, system and associated supportability costs through insertion of GOTS and Commercial CSCIs. The description shall cover the following:

a. Identify how open architecture requirements will enhance lifecycle supportability.

b. Identify and describe a strategy to insert hardware and software including COTS and

GOTS into the system and describe how these are logistically supported throughout the system’s life cycle.

c. Identify what hardware and software is planned for reuse, their functionality and the associated licenses and Technical data rights.

d. Identify specific hardware/software of the subsystem designs that are planned for

COTS and GOTS replacement and the supportability plans.

e. Describe how the subsystem is designed to allow timely and cost-effective replacement of software and hardware.

f. Address the selection processes for commercial components including COTS and documentation of the decisions leading to the selection of the COTS product.

g. Provide a description of processes that shall be established to ensure that software including COTS and GOTS products are logistically supported.

h. Describe the availability of commercial repair parts and repair services, facilities and manpower required for life cycle support to ensure long term support for CSCIs including COTS and GOTS products.

i. Provide the proposed methodology for pass-through of software warranties to the

Government.

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

3.8 Appendices. Appendices can be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendices can be bound as separate documents for ease in handling. Appendices shall be lettered alphabetically (A, B, etc.).

End of DI-MGMT-82099