The developer shall prepare for software transition in accordance with the following requirements.
Note: If software is developed in multiple builds, the developer's planning should identify what software, if any, is to be transitioned to the support agency in each build. Preparing for software transition in each build should be interpreted to include those activities necessary to carry out the transition plans for that build.
The developer shall prepare the executable software to be transitioned to the support site, including any batch files, command files, data files, or other software files needed to install and operate the software on its target computer(s). The result shall include all applicable items in the executable software section of the Software Product Specification (SPS) DID (see 6.2).
The developer shall prepare the source files to be transitioned to the support site, including any batch files, command files, data files, or other files needed to regenerate the executable software. The result shall include all applicable items in the source file section of the Software Product Specification (SPS) DID (see 6.2).
The developer shall identify and record the exact version of software prepared for the support site. The information shall include all applicable items in the Software Version Description (SVD) DID (see 6.2).
The developer shall update the design description of each CSCI to match the "as built" software and shall define and record: the methods to be used to verify copies of the software, the measured computer hardware resource utilization for the CSCI, other information needed to support the software, and traceability between the CSCI's source files and software units and between the computer hardware resource utilization measurements and the CSCI requirements concerning them. The result shall include all applicable items in the qualification, software support, and traceability sections of the Software Product Specification (SPS) DID (see 6.2).
Note: In hardware development, the final product is an approved design from which hardware items can be manufactured. This design is presented in the product specification. In software development, by contrast, the final product is the software, not its design, and "manufacturing" consists of electronically duplicating the software, not recreating it from the design. The "as built" design is included in the software product specification not as the product but as information that may help the support agency understand the software in order to modify, enhance, and otherwise support it.
The developer shall participate in updating the system design description to match the "as built" system. The result shall include all applicable items in the System/Subsystem Design Description (SSDD) DID (see 6.2).
The developer shall prepare support manuals in accordance with the following requirements.
Note: Not all systems will need the manuals in this section. The intent is for the acquirer, with input from the developer, to determine which manuals are appropriate for a given system and to require the development of only those manuals. All DIDs permit substitution of commercial or other manuals that contain the required information. The manuals in this section supplement the system/subsystem design description (SSDD) and the software product specifications (SPSs), which serve as the primary sources of information for software support. The user manuals cited in 5.12.3 are also useful to support personnel.
The developer shall identify and record information needed to program the computers on which the software was developed or on which it will run. The information shall include all applicable items in the Computer Programming Manual (CPM) DID (see 6.2).
The developer shall identify and record information needed to program and reprogram any firmware devices in which the software will be installed. The information shall include all applicable items in the Firmware Support Manual (FSM) DID (see 6.2).
The developer shall:
a. Install and check out the deliverable software in the support environment designated in the contract.
b. Demonstrate to the acquirer that the deliverable software can be regenerated (compiled/linked/loaded into an executable product) and maintained using commercially available, acquirer-owned, or contractually deliverable software and hardware designated in the contract or approved by the acquirer.
c. Provide training to the support agency as specified in the contract.
d. Provide other assistance to the support agency as specified in the contract.
Translator: Simon Wright simon@pogner.demon.co.uk
Last updated: 22.iii.99