Table of Contents | Chapter 7 | Chapter 9

CHAPTER 8

DEVELOPMENT PHASE

8.0       OBJECTIVE

8.1       TASKS AND ACTIVITIES
            8.1.1 Code and Test Software
            8.1.2 Integrate Software
            8.1.3 Conduct Software Qualification Testing
            8.1.4 Integrate System
            8.1.5 Conduct System Qualification Testing
            8.1.6 Install Software
            8.1.7 Document Software Acceptance
            8.1.8 Revise Previous Documentation

8.2       ROLES AND RESPONSIBILITIES

8.3       DELIVERABLES
            8.3.1 Contingency Plan 
            8.3.2 Software Development Document
            8.3.3 System (Application) Software
            8.3.4 Test Files/Data
            8.3.5 Integration Document

8.4       ISSUES FOR CONSIDERATION

8.5       PHASE REVIEW ACTIVITY

8.0       OBJECTIVE

The objective of the Development Phase will be to convert the deliverables of the Design Phase into a complete information system. Although much of the activity in the Development Phase addresses the computer programs that make up the system, this phase also puts in place the hardware, software, and communications environment for the system and other important elements of the overall system.

The activities of this phase translate the system design produced in the Design Phase into a working information system capable of addressing the information system requirements. The development phase contains activities for building the system, testing the system, and conducting functional qualification testing, to ensure the system functional processes satisfy the functional process requirements in the Functional Requirements Document (FRD). At the end of this phase, the system will be ready for the activities of the Integration and Test Phase.

8.1       TASKS AND ACTIVITIES

8.1.1    Code and Test Software

Code each module according to established standards.

8.1.2    Integrate Software

Integrate the software units, components and modules. Integrate the software units and software components and test in accordance with the integration plan. Ensure that each module satisfies the requirements of the software at the conclusion of the integration activity.

8.1.3    Conduct Software Qualification Testing.

Conduct qualification testing in accordance with the qualification requirements for the software item. Ensure that the implementation of each software requirement is tested for compliance. Support audit(s) which could be conducted to ensure that:

The results of the audits shall be documented. If both hardware and software are under development or integration, the audits may be postponed until the System Qualification Testing.

Upon successful completion of the audits, if conducted, update and prepare the deliverable software product for System Integration, System Qualification Testing, Software Installation, or Software Acceptance Support as applicable. Also, establish a baseline for the design and code of the software item.

8.1.4    Integrate System

Integrate the software configuration items with hardware configuration items, manual operations, and other systems as necessary, into the system. The aggregates shall be tested, as they are developed, against their requirements. The integration and the test results shall be documented. For each qualification requirement of the system, a set of tests, test cases (inputs, outputs, test criteria), and test procedures for conducting System Qualification Testing shall be developed and documented. Ensure that the integrated system is ready for System Qualification Testing.

8.1.5    Conduct System Qualification Testing.

Conduct system qualification testing in accordance with the qualification requirements specified for the system. Ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery. The qualification testing results shall be documented.

8.1.6    Install Software

Install the software product in the target environment as designed and in accordance with the Installation Plan. The resources and information necessary to install the software product shall be determined and be available. The developer shall assist the acquirer with the set-up activities. Where the installed software product is replacing an existing system, the developer shall support any parallel running activities that are required. Ensure that the software code and databases initialize, execute, and terminate as specified in the contract. The installation events and results shall be documented.

8.1.7    Document Software Acceptance Support.

Acceptance review and testing shall consider the results of the Joint Reviews, Audits, Software Qualification Testing, and System Qualification Testing (if performed). The results of the acceptance review and testing shall be documented.

The developer shall complete and deliver the software product as specified. The developer shall provide initial and continuing training and support to the acquirer as specified.

8.1.8    Revise Previous Documentation

Review and update previous phase documentation, as needed.

8.2      ROLES AND RESPONSIBILITIES

8.3       DELIVERABLES

The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The following deliverables shall be initiated during the Development Phase:

8.3.1    Contingency Plan

The Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities. Contingency planning is essential to ensure that DOJ systems are able to recover from processing disruptions in the event of localized emergencies or large-scale disasters. It is an emergency response plan, developed in conjunction with application owners and maintained at the primary and backup computer installation to ensure that a reasonable continuity of support is provided if events occur that could prevent normal operations. Contingency plans shall be routinely reviewed, updated, and tested to enable vital operations and resources to be restored as quickly as possible and to keep system downtime to an absolute minimum. A Contingency Plan is synonymous with a disaster plan and an emergency plan. If the system/subsystem is to be located within a facility with an acceptable contingency plan, system-unique contingency requirements should be added as an annex to the existing facility contingency plan. Appendix C-26 provides a template for the Contingency Plan.

8.3.2   Software Development Document

Contains documentation pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software Appendix C-27 provides a template for the Software Development Document.

  

8.3.3   System (Application) Software

This is the actual software developed. It is used for the Test and Integration Phase and finalized before implementation of the system. Include all the disks (or other medium) used to store the information.

8.3.4   Test Files/Data

All the information used for system testing should be provided at the end of this phase. Provide the actual test data and files used.

8.3.5   Integration Document

The Integration Document explains how the software components, hardware components, or both are combined and the interaction between them. Appendix C-28 provides a template for the Integration Document.

8.4       ISSUES FOR CONSIDERATION

There are three phase prerequisites that should be completed before beginning this phase.

8.5       PHASE REVIEW ACTIVITY

Upon completion of all Development Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Development Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.

Table of Contents | Chapter 7 | Chapter 9