DI-IPSC-82167

Software Build Plan

The Software Build Plan consists of details regarding how the software functionality or capabilities will be built up over time to reach full capability in consonance with the system integration activities.

Approval DateNovember 16, 2017

AMSC NumberN9873

Preparing ActivityAS

Project NumberIPSC-2018-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

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

2Format.The Software Build Plan shall adhere to the format described under Content.

3ContentThe 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.2Document 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.3Relationship to other plans.This paragraph shall describe the relationship, if any, to 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.3Build Strategy.This section informs the reader what the high level plan, or methodology, is for the software build(s) and, most importantly, why the build is structured the way it is. The build 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 this build, or builds, of software.

3.3.1.1Software 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 System/Software Integration Plan (SIP).

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.

3.3.1.7Defect burn-down strategy, if applicable.

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

3.3.1.9Test strategy to include any regression testing.

3.3.2Build Processes.This section defines the processes and process execution used during release(s) of software. The follow subsections shall be described:

3.3.2.1Build Planning

3.3.2.1.1Linkage of the software builds 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.2Build methodology.

3.3.2.1.3Computer Software Component (CSC) 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 build 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 built regardless of purchased or developed.

3.3.2.1.7Identification of all external systems to be utilized or interfaced with.

3.3.2.1.8Association of Build Release Indicators (i.e. the ability of the software to satisfy the functionality of each scheduled incremental build) to builds and also by capability.

3.3.2.1.9Categorization of capabilities (i.e. functional, performance, problem correction, stress, failure recovery, baseline maturity, associated to system test and associated with flight test, as applicable).

3.3.2.1.10Setup and establishment of configuration of the development and test environment(s).

3.3.2.1.11Establishment of sequence and schedule for Build Release Indicators.

3.3.2.1.12Meetings and agendas to facilitate execution.

3.3.2.1.13Record keeping and reporting.

3.3.2.2Build/Release Entrance and Exit Criteria

3.3.2.3Build/Release Execution

3.3.2.3.1Personnel management

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

3.3.2.4Build/Release Metrics

3.3.2.4.1Development Progress Profile (Percent of Work Complete).

3.3.2.4.2Software Productivity.

3.3.2.4.3Software Requirements Volatility.

3.3.2.4.4Software Defects.

3.3.2.4.5Software Size.

3.3.2.4.6Build Release Indicators.

3.3.2.4.7Test Progress Indicators.The progress made against initial plans for each formal build and tracked against test efforts leading toward the build for formal and/or qualification test.

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

3.3.2.6Testing.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.4Notes.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.5Appendices.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. Appendices may be bound as separate documents for ease in handling. Appendices 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