3.0 DEVELOP SYSTEM

Overview

The Develop System activity includes all software development activities, as well as some system engineering activities in which the software developer may participate during the project life cycle. It does not cover management or planning activities.

Roles and Responsibilities

The system engineering group includes a collection of individuals, both managers and technical staff, who have the responsibility for specifying system requirements; allocating the system requirements to the hardware, software, and other components; specifying the interfaces between the hardware, software, and other components; and monitoring the design and development of these components to ensure conformance with their specifications [SEI, 1993]. The system engineering group is also responsible for performing the integration and integration testing of the various components.

The system test group develops the system qualification test cases and performs the system qualification testing.

The software engineering group develops the software products.

Note: while this volume focuses on the software developer’s activities, software developers also may serve as members of the systems engineering group and/or the system test group.

Controls

The LaRC Systems Engineering Handbook for In-House Space Flight Projects [LHB 7122.1, Langley Research Center, Hampton, VA, August, 1994], providing an overview of the systems engineering process for LaRC projects.

MIL-STD-498 for Software Development and Documentation, describing the software products to be produced. A subset of the MIL-STD-498 Data Item Descriptions (DID) are included in Appendix E of this Guidebook.

MIL-STD-498 Software Development Plan (SDP) (see Appendix E) and MIL-STD-498 Software Test Plan (STP) (see Appendix E) completed specifically for the project.

Inputs

The Preliminary Mission Needs Statement which establishes the justification for undertaking an agency objective or effectively pursuing an opportunity pertaining to an agency objective.

Approved SCRs/Deviations and Waivers that document needed changes to software products (see activity 2.0 Perform Configuration Management).

Procedures

The SDP and STP have been specifically tailored for the project, and are used by the software engineering group to guide the development effort. The following subactivities are not necessarily performed sequentially. Subactivity 3.3 Participate In System Integration And System Qualification Testing may be started as soon as the system requirements start to be defined. In fact, it is recommended that the system qualification test cases be developed (see activity 3.3.2.1 Develop System Qualification Test Cases And Procedures) concurrently with the system requirements to ensure the requirements are verifiable. While the subactivities may not be started sequentially, they must be completed sequentially, because subactivity 3.2 Perform Software Development cannot be started until some subset of the system requirements is allocated to software, and subactivity 3.3 Participate In System Integration And System Qualification Testing cannot be completed until some subset of subactivity 3.2 Perform Software Development is completed. The project’s system life cycle may not follow the traditional "waterfall" life cycle. In some cases, the system may be iteratively developed: some system requirements are defined, software development is performed, some system integration testing may be done, and then more requirements are identified. Additional information on various system life cycles is in the System Development Life Cycle section (pp. 3-1 to 3-32) of the System Engineering Process course material [CSM, 1994] .

Throughout the project, metrics are collected as planned in the SDP (see activity 1.1.1.5 Determine Metrics To Be Collected) and analyzed (see activity 1.2.1.3 Analyze Software Project Metrics). This analysis may indicate areas that could be improved. In addition, at any point during software development, SCRs may be received which may cause the software engineering group to iterate previously completed activities. Due to necessary changes, deviations and waivers from the standard process may be granted. The process for requesting a change to software products is documented in the Configuration Control section of the project’s Software Configuration Management Plan (SCMP).

The following activities are performed by the software engineering group to produce the software products:

1) 3.1 Participate In Systems Requirements And Design. This subactivity describes the software developer’s participation in the system’s requirements analysis and design process. This process is "owned" by the systems engineering group, and the software developer participates as a systems engineering group member. When starting a new project, the software developer should begin by reviewing the Preliminary Mission Needs statement (when available). The LaRC Systems Engineering Handbook for In-House Space Flight Projects (pp. 4-1 through 4-15) provides a good, high-level overview of the standard NASA project life cycle and processes.

2) 3.2 Perform Software Development. This subactivity describes developing the software products (i.e., code and all documentation) and covers all software development activities from software requirements analysis to software qualification testing. The SDP and STP provide the structure and guidance for all subactivities in this subactivity. It is based on the software development activities described in MIL-STD-498 and the DIDs provided by the military standard. All documentation created and/or completed in this subactivity is placed under configuration management (CM).

3) 3.3 Participate in System Integration And System Qualification Testing. This subactivity describes the software developer’s participation in system integration and qualification testing. This process is "owned" by the system test group, and the software developer participates as a group member. This subactivity produces an integrated, working, qualified system that successfully completed system qualification testing.

Outputs

A "qualified" system that passed system qualification testing.

Development metrics.

Approved software products placed under Software Configuration Management (SCM).