DI-SESS-82044

System/Software Integration Plan

This DID specifies the format and content for a System/Software Integration Plan (SIP), detailing how software components integrate with target hardware to achieve full capability, including schedules, milestones, dependencies, and necessary resources.

Approval DateMay 25, 2016

AMSC NumberN9666

Preparing ActivityAS

Project NumberSESS-2016-026

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 System/Software Integration Plan (SIP) consists of details regarding how the software will be built up over time to reach full capability in consonance with the target hardware. The SIP captures the evolution of software component to software component integration, Computer Software Configuration Item (CSCI) to CSCI integration, CSCI to Hardware Configuration Item (HWCI) integration and subsystem integration. The SIP includes an integration schedule with milestones and dependencies. The SIP specifies the staffing and facility resources needed to successfully execute the plan. This Data Item Description contains the format, content, and intended use information for the data product resulting from the work task described by the contract.

Preparation Instructions

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

2Format.Contractor's format acceptable. The SIP shall adhere to the format described under Content.

3Content:The content shall contain the following:

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

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

3.1.2System overview.This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; 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.3Document overview.This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

3.1.4Relationship to other plans.This paragraph shall describe the relationship, if any, of the Software Development Plan or to other project management plans.

3.2Overview of required work.This section shall be divided into paragraphs as needed to establish the context for the planning described in later sections. It shall include, as applicable, an overview of:

3.2.1Requirements and constraints of the system and software to be developed.

3.2.2Requirements and constraints of the project documentation.

3.2.3Position of the project in the lifecycle.

3.2.4Requirements and constraints of the selected development strategy.

3.2.5Requirements and constraints on project resources and schedules.

3.2.6Other requirements and constraints, such as security, safety, methods, standards, interdependencies, etc.

3.3Integration Strategy.This section informs the reader what the high level plan, or methodology, is for integration and, most importantly, why the integration is structured the way it is. The integration is dependent on many factors which will change during execution and will require this plan to be actively updated and managed.

3.3.1Factors:Each of the following subsections shall describe the factors required for integration of software.

3.3.1.1Integration team construct by personnel to facilitate discovery, analysis and correction of problems.

3.3.1.2Detail incremental capability buildup through the use of use cases and sequence diagrams used to describe functional mission and support threads (from basic infrastructure to full mission capability).

3.3.1.3Interface evaluation as described by use cases and activity data flow.

3.3.1.4Interaction and dependencies of the Software Build Plan.

3.3.1.5Interaction and dependencies with the ground/flight test plan of capability releases that can only be tested on a target platform.

3.3.1.6Maturity definition(s) and criteria for a capability to exit integration (i.e. specification compliance).

3.3.1.7Defect burn-down strategy.

3.3.1.8Detail the integration facility to include: simulations, stimulations, hardware hosts, data collection, analysis tools and any specialized test equipment.

3.3.1.9Regression test strategy.

3.3.2Integration Processes.This section defines the processes and process execution used during integration of software. The follow subsections shall be described:

3.3.2.1Integration Planning

3.3.2.1.1Linkage of the integration in the Integrated Master Schedule (IMS) and other applicable program plans for all relevant activities (i.e. flight test, formal testing, etc.).Include expected software delivery dates for the integrators and test teams.

3.3.2.1.2Integration methodology.

3.3.2.1.3CSC integration and testing with special focus on the completeness (via coverage analysis of requirements-based testing) and the testing of the software cybersecurity requirements:

3.3.2.1.3.1Common Vulnerabilities and Exposure (CVE) List for the selection of security test tool(s).

3.3.2.1.3.2Penetration testing.

3.3.2.1.3.3Modified condition and decision coverage testing.

3.3.2.1.4Identification of integration artifacts.

3.3.2.1.5Identification of required activities and/or resources.

3.3.2.1.6Identification of project functions, components and subsystems to be integrated regardless of purchased or developed.

3.3.2.1.7Identification of all external systems to be integrated.

3.3.2.1.8Association of integration points to builds.

3.3.2.1.9Association of integration points by capability.

3.3.2.1.10Categorization of integration points, i.e. functional, performance, problem correction, stress, failure recovery, baseline maturity, associated to system test and associated with flight test.

3.3.2.1.11Setup and establishment of configuration of test environment.

3.3.2.1.12Establishment of sequence and schedule for integration points.

3.3.2.1.13Meetings and agendas to facilitate execution.

3.3.2.1.14Record keeping and reporting.

3.3.2.2Integration Entrance and Exit Criteria

3.3.2.3Integration Execution

3.3.2.3.1Personnel management

3.3.2.3.2Lab Utilization (Shift planning, prioritization and de-confliction)

3.3.2.4Integration Metrics

3.3.2.4.1Integration points: Plan versus Actual by build and subsystem

3.3.2.4.2Capability Progress:

3.3.2.4.2.1Percent ( included complexity of integration points) -Complete / Attempted / Remaining

3.3.2.4.2.2Count (integration points)- Complete / Attempted / Remaining

3.3.2.4.2.3Corrections to defects required to continue integration (Closed / Verifying / In Work by Capability)

3.3.2.5Problem Report Management.Include Configuration Control Board (CCB) participants and participation.

3.3.2.6Regression testing.This section should include:

3.3.2.6.1Scope determination.

3.3.2.6.2Testing strategy assure that no changes have affected previously successfully tested functionality.

3.3.2.6.3Unit, component and CSCI level test procedures to be used.

3.4Integration Points.This section shall provide the total integration points required for each capability.

3.4.1Each integration point shall highlight the functions required and the interfaces needed to support the execution of the integration steps.

3.4.2The integration points shall provide coverage of all use cases, sequence diagrams and activity data flow as captured in the requirements and design phases.

3.4.3Integration points may have more than one integration step.

3.4.4Integration points shall be assigned a complexity value.

3.5Notes.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.6Appendices.Appendices may 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. Appendixes may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabetically (A, B, etc.).

References

—

Schema v3.0Community-maintained · Verify against ASSIST

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