Table of Contents | Forward | Chapter 2

CHAPTER 1

INTRODUCTION

1.0       BACKGROUND

1.1       PURPOSE, SCOPE, AND APPLICABILITY
            1.1.1 Purpose
            1.1.2 Scope
            1.1.3 Applicability

1.2       INTRODUCTION TO SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
            1.2.1 Initiation Phase
            1.2.2 System Concept Development Phase
            1.2.3 Planning Phase
            1.2.4 Requirements Analysis Phase
            1.2.5 Design Phase
            1.2.6 Development Phase
            1.2.7 Integration and Test Phase
            1.2.8 Implementation Phase
            1.2.9 Operations and Maintenance Phase
            1.2.10 Disposition Phase

1.3       CONTROLS/ASSUMPTIONS

1.4       DOCUMENTATION

1.0      BACKGROUND

The DOJ spends millions of dollars each year on the acquisition, design, development, implementation, and maintenance of information systems vital to mission programs and administrative functions. The need for safe, secure, and reliable system solutions is heightened by the increasing dependence on computer systems and technology to provide services and develop products, administer daily activities, and perform short- and long-term management functions. There is also a need to ensure privacy and security when developing information systems, to establish uniform privacy and protection practices, and to develop acceptable implementation strategies for these practices.

The DOJ needs a systematic and uniform methodology for information systems development. Using this SDLC will ensure that systems developed by the Department meet IT mission objectives; are compliant with the current and planned Information Technology Architecture (ITA); and are easy to maintain and cost-effective to enhance. Sound life cycle management practices include planning and evaluation in each phase of the information system life cycle. The appropriate level of planning and evaluation is commensurate with the cost of the system, the stability and maturity of the technology under consideration, how well defined the user requirements are, the level of stability of program and user requirements and security considerations.

1.1      PURPOSE, SCOPE, AND APPLICABILITY

1.1.1      Purpose

This SDLC methodology establishes procedures, practices, and guidelines governing the initiation, concept development, planning, requirements analysis, design, development, integration and test, implementation, and operations, maintenance and disposition of information systems (IS) within the DOJ. It should be used in conjunction with existing policy and guidelines for acquisition and procurement, as these areas are not discussed in the SDLC.

1.1.2      Scope

This methodology should be used for all DOJ information systems and applications. It is applicable across all information technology (IT) environments (e.g., mainframe, client, server) and applies to contractually developed as well as in-house developed applications. The specific participants in the life cycle process, and the necessary reviews and approvals, vary from project to project. The guidance provided in this document should be tailored to the individual project based on cost, complexity, and criticality to the agency’s mission. See Chapter 13 for Alternate SDLC Work Patterns if a formal SDLC is not feasible. Similarly, the documents called for in the guidance and shown in Appendix C should be tailored based on the scope of the effort and the needs of the decision authorities.

1.1.3      Applicability

This methodology can be applied to all DOJ Offices, Boards, Divisions and Bureaus (OBDB) who are responsible for information systems development. All Project Managers and development teams involved in system development projects represent the primary audience for the DJ SDLC, version 2.0.

1.2      INTRODUCTION TO SDLC

The SDLC includes ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap. See Figure 1-1.


Figure 1-1 Systems Development Life-Cycle, Life-Cycle Phases Chart

[D]

The DOJ SDLC encompasses ten phases:

1.2.1      Initiation Phase

The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.

1.2.2      System Concept Development Phase

Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.

1.2.3      Planning Phase

The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.

1.2.4      Requirements Analysis Phase

Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.

1.2.5      Design Phase

The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.

1.2.6      Development Phase

The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.

1.2.7      Integration and Test Phase

The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.

1.2.8      Implementation Phase

The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.

1.2.9      Operations and Maintenance Phase

The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.

1.2.10      Disposition Phase

The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.

1.3      CONTROLS/ASSUMPTIONS

The DOJ FY 2002 - FY 2006 IT Strategic Plan defines the strategic vision for using IT to meet business needs of the Department. The DOJ Technical Reference Model (TRM) standards guidance, version 2.0, provides standards for all IT systems funded by DOJ. It applies to both the development of new systems and the enhancements of existing systems. This document is available on the DOJ Intranet at http://dojnet.doj.gov/jmd/irm/imss/enterprisearchitecture/enterarchhome.html (available to DOJ Employees only).

This SDLC calls for a series of comprehensive management controls. These include:

All DOJ components shall adhere to IRM Order 2880.1A which provides general policy on Information Resources Management, to include roles and responsibilities for information collection, resource management and privacy act requirements. DOJ orders are located at http://dojnet.doj.gov/dojorders/dojorders.html.

1.4      DOCUMENTATION

This life cycle methodology specifies which documentation shall be generated during each phase.

Some documentation remains unchanged throughout the systems life cycle while others evolve continuously during the life cycle. Other documents are revised to reflect the results of analyses performed in later phases. Each of the documents produced are collected and stored in a project file. Care should be taken, however, when processes are automated. Specifically, components are encouraged to incorporate a long-term retention and access policy for electronic processes. Be aware of legal concerns that implicate effectiveness of or impose restrictions on electronic data or records. Contact your Records Management Office for specific retention requirements and procedures. Recommended documents and their project phase are shown in Table 1.


Table 1
Planning Document
 Initiation Phase System Concept Development Planning Requirement Analysis Design Development Integration and Test Implementation Operations and Maintenance Disposition
Concept Proposal
 C/F
 
 
 
 
 
 
 
 
 
System Boundary Document
 
 C/F
 *
 *
 *
 *
 *
 *
 
 
Cost-Benefit Analysis
 
C 
R 
R 
R 
 R
F 
 
 
 
Feasibility Study
 
C 
R 
F 
 
 
 
 
 
 
Risk Management Plan
 
C 
R
R
R
R
F
 
* 
* 
Acquisition Plan
 
 
C 
R 
F 
* 
 
 
 
 
Configuration Managment Plan
 
 
C 
R 
R 
R 
F 
* 
* 
 
Quality Assurance Plan
 
 
C 
R 
R 
R 
F 
* 
* 
 
Concept of Operations
 
 
C 
R 
R 
R 
R 
F 
* 
* 
System Security Plan
 
 
C 
R 
R 
R 
F 
* 
* 
 
Project Management Plan
 
 
C 
R 
R 
R 
F 
* 
 
 
Verification and Validation Plan
 
 
C 
R 
R 
R 
F 
 
 
 
System Engineering Management Plan
 
 
C/F 
* 
* 
* 
* 
* 
* 
* 
Functional Requirements Document
 
 
 
C 
F 
 
 
 
 
 
Test and Evaluation Master Plan
 
 
 
C 
R 
R 
F 
* 
* 
 
Interface Contraol Document
 
 
 
C 
R 
F 
* 
* 
* 
 
Privacy Act Notice/Privacy Impact Assessment
 
 
 
C 
F 
 
 
 
 
 
Security Risk Assessment
 
 
 
 
C 
R 
F 
 
 
 
Conversion Plan
 
 
 
 
C 
R 
F 
* 
 
 
System Design Document
 
 
 
 
C 
F 
 
 
* 
 
Implementation Plan
 
 
 
 
C 
R 
F 
 
 
 
Maintenance Manual
 
 
 
 
C 
R 
F 
* 
* 
 
Operations Manual (System Administration Manual)
 
 
 
 
C 
R 
F 
* 
* 
 
Training Plan
 
 
 
 
C 
R 
F 
* 
* 
 
User Manual
 
 
 
 
C 
R 
F 
* 
* 
 
Contingency Plan
 
 
 
 
 
C
F
*
*
 
Software Development Document
 
 
 
 
 
C 
R 
F 
* 
 
System Software
 
 
 
 
 
C 
F 
* 
* 
 
Test Files/Data
 
 
 
 
 
C 
F 
 
* 
 
Integration Document
 
 
 
 
 
C 
F 
* 
* 
 
Test Analysis Report
 
 
 
 
 
 
C/F
 
 
 
Test Analysis Approval Determination
 
 
 
 
 
 
C/F 
 
 
 
Test Problem Report
 
 
 
 
 
 
C 
 
 
 
IT Systems Security Certification & Accreditation
 
 
 
 
 
 
C/F 
 
 
 
Delivered System
 
 
 
 
 
 
 
C/F
*
 
Change Implemention Notice
 
 
 
 
 
 
 
C 
C 
 
Version Description Document
 
 
 
 
 
 
 
C/F 
* 
 
Post-Implementation Review
 
 
 
 
 
 
 
C 
 
 
In-Process Review Report
 
 
 
 
 
 
 
 
C 
 
User Satisfaction Report
 
 
 
 
 
 
 
 
C 
 
Disposition Plan
 
 
 
 
 
 
 
 
 
C/F 
Post-termination Review Report
 
 
 
 
 
 
 
 
 
C/F 
 KEY: C=Created        R-Revised         F=Finalized         *=Updated if needed

Table of Contents | Forward | Chapter 2