SDLC Framework 03-2006.doc.doc

DRAFT

DRAFT

Office of Information Services

System Development Life Cycle

Framework Guide

VERSION 1.6MARCH 2006

DHS OFFICE OF INFORMATION SERVICES

document.doc Page 1

DRAFT

DRAFT

SDLC Framework Guide

document.doc Page 2

DRAFT

DRAFT

Table of ContentsIntroduction....................................................................................3

Objectives.................................................................................................4Key Principles of Effective Life Cycle Management..................................5

Life Cycle Phases........................................................................8Initiation..................................................................................................11System Concept Development...............................................................12Planning Phase.......................................................................................13Requirements Analysis...........................................................................14Design.....................................................................................................15Development/Construction Activity.........................................................17Integration and Testing...........................................................................18Implementation.......................................................................................19Operations and Maintenance..................................................................20Disposition..............................................................................................21

Alternative Life Cycle – COTS..................................................22Acquisition Activities...............................................................................22

SDLC Documents......................................................................25SDLC Document Development Table.....................................................25Document Description Table...................................................................28

References.................................................................................35

document.doc Page 3

DRAFT

DRAFT

Introduction

The purpose of this document is to provide a System Development Life Cycle (SDLC) framework to be used for IT application acquisition, enhancement, and development.

The SDLC framework is intended to provide controls over the processes of acquiring and maintaining application software resulting in decreased risk of project or system failure. The SDLC framework includes oversight processes to ensure that all aspects of the development lifecycle are consistently and effectively managed. The application of the framework will help ensure that projects meet State and Federal audit requirements for system development standards.

Systems Development Life Cycle (SDLC) emphasizes decision processes that influence system cost and usefulness. The primary objectives of any SDLC are to deliver quality systems that:

Meet or exceed customer expectations when promised and within cost estimates.

Work effectively and efficiently within the current and planned information technology infrastructure.

Are inexpensive 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.

The framework can be used for all OIS information systems and applications. It is applicable across all information technology (IT) environments (e.g., mainframe, client, server) and applies to commercial-off-the-shelf (COTS) and 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

document.doc Page 4

DRAFT

DRAFT

project based on cost, complexity, and criticality to the agency’s mission. Similarly, the documents called for in the guidance should be tailored based on the scope of the effort and the needs of the decision authorities.

This SDLC framework provides for a full sequential SDLC work pattern and for alternative SDLC work patterns to accommodate the acquisition and implementation of commercial-off-the-shelf (COTS) products.

This SDLC describes an overall structured approach to information management. Primary emphasis is placed on the information and systems decisions to be made and the proper timing of decisions. The guide provides a flexible framework for approaching a variety of systems projects. The framework enables system developers, project managers, program/account analysts, and system owners/users to combine activities, processes, and products, as appropriate, and to select the tools and methodologies best suited to the unique needs of each project.

The SDLC serves as the mechanism to assure that systems under development meet the established requirements and support the DHS mission functions. It provides a structured approach to managing information technology (IT) development efforts, beginning with establishing the justification for initiating a systems development or maintenance effort and concluding with system disposition.

The primary audience for this guidance are the systems developers, IT project managers, program/account analysts and system owners/users responsible for defining and delivering DHS systems, their staff, and their support contractors.

Objectives

The specific objectives expected include the following:

Move OIS towards the use of “best practices” templates and modules by providing the controls to govern all aspects and phases of the system development life cycle, which interfaces to the PMO project management framework.

document.doc Page 5

DRAFT

DRAFT

Move OIS towards industry standards for software development by laying the foundation for implementing industry standard System Development Life Cycle (SDLC) methodologies.

Move OIS towards the effective use of COTS to speed development effort and reduce cost of software development.

Increase level of service to our customers by fostering a partnership between the OIS and business staff, and ensuring that basic procedures are followed and documented.

Key Principles of Effective Life Cycle Management

This guidance document refines traditional information system life cycle management approaches to reflect the principles outlined in the following subsections. These are the foundations for life cycle management.

Each System Project must have a Program Sponsor To help ensure effective planning, management, and commitment to information systems, each project must have a clearly identified program sponsor. The program sponsor serves in a leadership role, providing guidance to the project team and securing, from senior management, the required reviews and approvals at specific points in the life cycle.

A Single Project Manager must be Selected for Each System Project

The Project Manager has responsibility for the success of the project and works through a project team and other supporting organization structures, such as working groups or user groups, to accomplish the objectives of the project.

A Project Plan is Required for Each System ProjectThe project management plan is a pivotal element in the successful solution of an information management requirement. The project management plan must describe how each life cycle phase will be accomplished to suit the specific characteristics of the project. The project management plan is a vehicle for documenting the project scope, tasks, schedule, allocated resources, and interrelationships with other projects. The plan is

document.doc Page 6

DRAFT

DRAFT

used to provide direction to the many activities of the life cycle, and must be refined and expanded throughout the life cycle.

Specific Individuals Must be Assigned to Perform Key Roles Throughout the Life Cycle

Key roles include but are not limited to, program/functional management, quality assurance, security, telecommunications management, data administration, database administration, logistics, financial, systems engineering, test and evaluation, contracts management, and configuration management.

Obtaining the Participation of Skilled Individuals is Vital to the Success of the System Project

The SDLC manual is not intended as a substitute for information management skills or experience.

Documentation of Activity Results and Decisions for Each Phase of the Life Cycle are Essential

Effective communication and coordination of activities throughout the life cycle depend on the complete and accurate documentation of decisions and the events leading up to them.

Data Management is Required Throughout the Life CycleAccurate data is critical to support organizational missions. The large volumes of data handled by DHS systems, as well as the increasing trend toward interfacing, and sharing data across systems and programs, underscores the importance of data quality. Systems life cycle activities stress the need for clear definition of data, the design and the implementation of automated and manual processes that ensure effective data management.

Each System Project Deliverable Must Undergo Formal Acceptance

The program sponsor formally accepts the system by signing an Implementation Phase Review and Approval Certification along with the developer.

Consultation With Oversight Organizations Aids in the Success of a System Project

document.doc Page 7

DRAFT

DRAFT

A number of DHS oversight bodies, as well as external organizations, have responsibility for ensuring that information systems activities are performed in accordance with DHS/State/Federal guidance and standards and available resources are used effectively. Each project team should work with these organizations, as appropriate, and encourage their participation and support as early as possible and throughout the life cycle to identify and resolve potential issues or sensitivities and thereby avoid major disruptions to the project. Assume all documentation is subject to review by oversight activities.

A System Project may not Proceed Until Resource Availability is Assured

Beginning with the approval of the project, the continuation of a system is contingent on a clear commitment from the program sponsor. This commitment is embodied in the assurance that the necessary resources will be available, not only for the next activity, but as required for the remainder of the life cycle.

Each System Project Should Comply with OIS Systems Architecture (SA).

The OIS SA provides standards to coordinate the acquisition, development, and support of information systems and use as guides for acquiring COTS information technology products. These standards and architectural objectives advance DHS’s ability to implement systems that are more interoperable and maintainable. Each project team should work with appropriate groups to identify, document and establish any new standards as needed.

Each System Project Should Comply with established Information Security Office (ISO) guidelines.

Security Managers will provide technical and business-related information security advice throughout the life of a project. Particular attention will be directed towards ensuring that all facets of information security are addressed.

document.doc Page 8

DRAFT

DRAFT

Life Cycle Phases

An important objective of the SDLC framework is to provide flexibility that allows tailoring of the work pattern to suit the characteristics of a particular system development effort. One work pattern does not fit all sizes and types of system development efforts.

The SDLC framework includes phases during which defined IT work products are created or modified, providing a full sequential SDLC work pattern. The framework also provides an alternative SDLC work pattern to accommodate the acquisition and implementation of commercial-off-the-shelf (COTS) products.

The full sequential SDLC work pattern covers the initiation, concept development, planning, requirements analysis, design, development, integration and test, implementation, operations and maintenance, and disposition of information systems within DHS.

The COTS alternative SDLC work pattern adjusts the phases for acquisition and implementation of COTS including an acquisition phase, which replaces the design and development activities.

Not every project will require all activities or require that activities be sequentially executed. However, each is interdependent. Depending upon the size and complexity of the project, activities may be combined or may

document.doc Page 9

DRAFT

DRAFT

overlap. The guidance provided by this framework should be tailored to the individual project based on the scope of the effort and the needs of the decision authorities.

During the Planning Phase, the Project Manager, along with Executive Management evaluates the system concept definition documentation and uses criteria for selecting an SDLC work pattern. Examples of criteria that may be considered when selecting a work pattern include:

The type of system development- New development- Modification or enhancement of existing system- Procurement of a COTS system

The cost of the system development project using the guidelines below: - Very large projects with estimated development or life cycle costs of more than $20 million- Large projects with estimated development or life cycle costs of between $10 million and $20 million- Mid-size projects with estimated development or life cycle costs of between $2.5 million and $10 million- Small projects with estimated development or life cycle costs of between $500,000 and $2.5 million- O&M enhancement with estimated life cycle costs of less than $500,000.

The mission-criticality of system development – from most critical to non-mission critical.

The risk of inability to achieve the project objectives, based on one or more of the following: - Risk due to high uncertainty associated with the system’s requirements, the technology that the system will employ, or the way that the system will affect DHS business process- Risk due to high visibility due to public or political attention or requirements- Risk due to highly compressed development time (low turnaround time) because of an emergency or legal, business or political requirements

document.doc Page 10

DRAFT

DRAFT

The complexity of the system development effort, based on one or more of the following: - The project affects many organizations or functional areas within DHS, thus adding a level of difficulty regarding the definition of requirements.- The project results from business process reengineering, dramatically altering the use of information technology.- The project requires new or rapidly advancing technology.- The project requires a long time for development.


DRAFT

DRAFT

Initiation

The initiation of a system (or project) begins when a business case has been developed, approved and the project funding has been made available. The purposes of the Initiation Phase are to:

Clarify and validate an opportunity to improve business accomplishments of the organization or a deficiency related to a business need,

Identify significant assumptions and constraints on solutions to that need, and

Recommend the exploration of alternative concepts and methods to satisfy the need.

A Sponsor is identified and a Project Manager should be appointed to manage the project.

Pre-Initiation activities include development of the initial Business Case, which is reviewed and approved by Program authority. The Business Case identifies why a business process is necessary and what business benefits can be expected by implementing this improvement. A business scenario and context are established in which a business problem is clearly expressed in purely business terms without offering or predetermining any specific automated solution, tool, or product.

Phase activities include performing Project Initiation using established project management methodology. Project Management Process Guide and document templates are available on the PMO web site. http://www.oregon.gov/DHS/admin/pmo/index.shtmlDocument resulting from Initiation will be an approved and signed Project Charter.

After the Project Charter has been approved, the System Concept Development Phase begins.


http://www.oregon.gov/DHS/admin/pmo/index.shtml

DRAFT

DRAFT

System Concept Development

Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The project team, supplemented by system architects or other technical experts (P&P, CRM, DRM, ISO, etc.), should analyze all feasible technical, business process, and commercial alternatives to meeting the business need. Planning activities include:

Developing initial high-level estimates of schedule, cost, and performance measures,

Forming acquisition strategies (staff, contractors, available and projected technologies, COTS, contract types)

Analyzing the risks. Developing detailed estimates at the task level.

The results of the phase activities are documented in the Cost Benefit Analysis, Feasibility Study (occurs during the planning phase, prior to detailed planning on larger/complex projects), and Risk Analysis.

The results of these activities are presented to project stakeholders and decision makers together with a recommendation to (1) proceed into the next life-cycle phase, (2) continue additional conceptual phase activities, or (3) terminate the project.

Recommendation to proceed into the Planning phase requires Executive Management approval and funding before beginning the Planning Phase.


DRAFT

DRAFT

Planning Phase

Many of the plans essential to the success of the entire project are created in this phase. The created plans are then reviewed and updated throughout the remaining project phases. 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, system security requirements, and reviews are defined.

During the Planning Phase, the Project Manager, in conjunction with OIS Executive Management, evaluates the documentation of the system concept, as contained in supporting documentation, and determines what SDLC work pattern/template should be used and whether full sequential or an alternative work pattern such as for COTS be implemented.

Documents resulting from Planning may include development of a Change Management Plan, Risk Management Plan, Communication Plan, Quality Management Plan, Issue Management Plan, Contracts and Procurement Management Plan, Requirements Management Plan, and an Integrated Project Plan using established project management methodology. Project Management Process Guide and document templates are available on the PMO web site at: http://www.oregon.gov/DHS/admin/pmo/pmo_overview.shtml

The Project Manager reports on phase activities as part of the Project Status Review Process. The review should address phase activities status, planning status for subsequent life-cycle phases, and confirmation of phase activities documentation.


http://www.oregon.gov/DHS/admin/pmo/pmo_overview.shtml

DRAFT

DRAFT

Requirements Analysis

The Requirements Analysis activity begins when the previous documentation has been approved or by Executive Management direction. Documentation related to user requirements from the Planning Phase is used, as the basis for further user needs analysis and the development of detailed user requirements. The analysis may reveal new insights into the overall information systems requirements, and, in such instances, deliverables and the project plan should be revised to reflect this analysis.

During Requirements Analysis, the system is defined in more detail with regard to system inputs, processes, outputs, and interfaces. This definition process occurs at the functional level. Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. Requirements are defined to a level of detail sufficient for systems design to proceed. The system is described in terms of the functions to be performed, not in terms of computer programs, files, and data streams. The emphasis in requirements gathering is on determining what functions must be performed rather than how to perform those functions. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.

Another activity of requirements gathering is establishing test criteria and beginning test planning. This includes identifying what areas need to be involved in testing, identifying what tests will be performed, defining test procedures, begin building test scripts and use cases to be used in testing, and traceability back to the requirements. The Test Plan should ensure that all aspects of the system are adequately tested and can be implemented. It documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.

The results of these activities are documented in the Requirements Document and the Test Plan, and presented to project stakeholders and decision makers for review and approval. The Project Manager reports on requirements activities as part of the Project Status Review Process. The review should address phase activities status, planning status for subsequent life-cycle phases, and confirmation of activities documentation.


DRAFT

DRAFT

Design

The objective of Design activities is to transform the detailed, defined requirements into complete, detailed specifications for the system to guide the work of Development. The decisions made in this activity address, in detail, how the system will meet the defined functional, physical, interface, and data requirements. Design activities may be conducted in an iterative fashion, producing first a general system design that emphasizes the functional features of the system, then a more detailed system design that expands the general design by providing all the technical detail. The physical characteristics of the system are designed during this activity. 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, reviewed and formally approved by the user. Test scripts and use cases are updated and revalidated.

The decisions of this activity re-examine in greater detail many of the parameters addressed in previous activities. The design prepared will be the basis for the Development activities. The overall objective is to establish a complete design for the system.

The pre-requisites for this activity are the Project Plan, Requirements Document, and Test Plan. A number of project approach, project execution, and project continuation decisions are made in this activity.Project approach decisions include:

Identifying existing or COTS components that can be used, or economically modified, to satisfy validated functional requirements.

Using appropriate prototyping to refine requirements and enhance user and developer understanding and interpretation of requirements.

Selecting specific methodologies and tools to be used in the later life cycle phases, especially the Development and Implementation Phases.

Determining how user support will be provided, how the remaining life cycle phases will be integrated, and newly identified risks and issues handled.

The documents resulting from this activity may vary depending on the size, scope and complexity of the development effort. Documents may include


DRAFT

DRAFT

System Design, Implementation Plan, Conversion Plan, Maintenance Manual, System Administration Manual, Training Plan, and User Manual.

The Project Manager reports on activities as part of the Project Status Review Process. The review should address activities status, planning status for subsequent life-cycle phases, and confirmation of Design activities documentation.


DRAFT

DRAFT

Development/Construction Activity

The development activity 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 Requirements Document. The detailed specifications produced during the design activity are translated into hardware, communications, and executable software. Test scripts and use cases are updated and revalidated. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested. The results of testing and acceptance reviews results should be documented. At the end of this activity, the system will be ready for the Integration and Test Activity.

The documents resulting from this activity may vary depending on the size, scope and complexity of the development effort. Documents of this activity may include a Contingency Plan, a Software Development Document and an Integration Document. The information used for system testing should be provided at the end of this effort including the actual test data and files used.

The results of the activities are presented to project stakeholders and decision makers for formal approval to proceed into the next life-cycle phase. Recommendation to proceed into the Integration and Testing activities requires Executive Management approval.

The Project Manager reports on development activities as part of the Project Status Review Process. The review should address activities status, planning status for subsequent life-cycle phases, and confirmation of activities documentation.


DRAFT

DRAFT

Integration and Testing

The objective of these activities is to prove that the developed system satisfies the requirements defined in the Requirements Document. Several types of tests will be conducted in this phase. The various components of the system are integrated and systematically tested. The testing team conducts and evaluates system tests to ensure the developed system meets all technical requirements, including performance requirements and security. Using the test scripts and Use Cases, users participate in acceptance testing to confirm that the developed system meets user requirements as stated in the Requirements Document.

Prior to installing and operating the system in a production environment, the system must undergo any required State and/or Federal certification and accreditation activities.

Tests and test results are documented in a Test Analysis Report. The Test Analysis Report documents each test – unit, integration, system, user acceptance and security.

The results of these activities are presented to project stakeholders and decision makers for formal approval to proceed into the next life-cycle phase. Recommendation to proceed into the Implementation phase requires Executive Management approval.

The Project Manager reports on these activities as part of the Project Status Review Process. The review should address activities status, planning status for subsequent life-cycle phases, and confirmation of activities documentation.


DRAFT

DRAFT

Implementation

The system or system modifications are installed and made operational in a production environment. Implementation is initiated after the system has been tested and accepted by the user. Activities include notification of implementation to users and others affected by the implementation, execution of the previously defined training plan, data entry or conversion, and post implementation review. This continues until the system is operating in production in accordance with the defined user requirements.

A post-implementation review is conducted to determine the success of the project through its implementation. The purpose of this review is to document implementation experiences to recommend system enhancements and provide guidance for future projects. The results are documented in a Post-Implementation Review Document.

The results of Implementation activities are presented to project stakeholders and decision makers for formal approval to proceed into the next life-cycle phase. Recommendation to proceed into the Operations and Maintenance phase requires Executive Management approval.

The Project Manager reports on activities as part of the Project Status Review Process. The review should address activities status, planning status for subsequent life-cycle phases, and confirmation of activities documentation.


DRAFT

DRAFT

Operations and Maintenance

The Operations Manual developed in previous activities defines tasks, activities and responsible parties. The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. When modifications or changes are identified as necessary, the system may reenter the planning phase. User support and training are ongoing activities.

Project closing activities are conducted. Lessons learned activities are performed and documented in a Lessons Learned Report.


DRAFT

DRAFT

Disposition

The Disposition activity will be implemented to eliminate a large part of a system or as in most cases, close down a system and end the life cycle process. The system has been declared surplus and/or obsolete and will be scheduled for shutdown. 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.

The Disposition Plan must be developed and implemented. The Disposition Plan will identify how the termination of the system/data will be conducted, and when, as well as the system termination date, software components to be preserved, data to be preserved, disposition of remaining equipment, and archiving of life-cycle products.

A Post-Termination Review Report is conducted at the end of the Disposition. The report details the findings of this activity, reviews and documents the lessons learned from the shutdown and archiving of the terminated system. It includes details of where to find all products and documentation that has been archived.


DRAFT

DRAFT

Alternative Life Cycle – COTS

The alternative SDLC work pattern adjusts life cycle phases for acquisition and implementation of commercial-off-the-shelf (COTS). The Acquisition Phase replaces the Design and Development Phases.

Acquisition ActivitiesThe purpose of the Acquisition activities is to obtain the product and/or service that satisfy the need expressed by the customer. The activity begins with the identification of a customer need and ends with the acceptance of the product and/or service needed by the customer.

Activities include defining acquisition needs, goals, product and/or service acceptance criteria and acquisition strategies. An agreement is developed that clearly expresses the expectation, responsibilities and liabilities of both the customer and the supplier. A product and/or service are acquired that satisfies the customer’s stated need. The acquisition is monitored so that specified constraints such as cost, schedule and quality, are met. Supplier deliverables are accepted. Any identified open items have a satisfactory conclusion as agreed to by the customer and the supplier.

The Acquisition Activities includes but are not limited to the following processes:

Acquisition Preparation Supplier Selection Supplier Monitoring Customer Acceptance

Acquisition PreparationThe purpose of Acquisition preparation is to establish the needs and goals of the acquisition and to communicate these with the potential suppliers.

As a result of successful implementation of Acquisition preparation:The concept or the need for the acquisition, development, or enhancement is established. The needed acquisition requirements defining the project needs are defined and validated. The customer’s known requirements are defined and validated. An acquisition strategy is developed and supplier selection criteria are defined.

Supplier Selection


DRAFT

DRAFT

The purpose of Supplier selection is to choose the organization that is to be responsible for the delivery of the requirements of the project.

As a result of successful implementation of Supplier selection:The supplier selection criteria are established and used to evaluate potential suppliers. The supplier is selected based upon the evaluation of the supplier’s proposals, process capabilities, and other factors. An agreement is established and negotiated between the customer and the supplier.

Supplier MonitoringThe purpose of Supplier monitoring is to track and assess performance of the supplier against agreed requirements.

As a result of successful implementation of Supplier monitoring:Joint activities between the customer and the supplier are performed as needed. Information on technical progress is exchanged regularly with the supplier. Performance of the supplier is monitored against the agreed requirements. Agreement changes, if needed, are negotiated between the acquirer and the supplier and documented in the agreement.

Customer AcceptanceThe purpose of Customer acceptance is to approve the supplier's deliverable when all acceptance criteria are satisfied.

As a result of successful implementation of Customer acceptance:The delivered software product and/or service are evaluated with regard to the agreement. The customer’s acceptance is based on the agreed acceptance criteria. The customer accepts the software product and/or service.

Acquisition PlanA formal document showing how all hardware, software, and telecommunications capabilities, along with resources, is to be obtained during the life of the project.

When acquiring specialized (e.g., payroll package) application software (as opposed to generic applications such as word processors or spreadsheets), the degree of detail of requirements definition is roughly the same as it is for a development project.


DRAFT

DRAFT

Other types of tasks include performing market surveys and evaluating products, preparing Statement of Work and Requests for Proposal (RFP) or Requests for Information (RFI). Established contract management methodology is available on the Contracts Process web site. http://www.oregon.gov/DHS/admin/pmo/contracts/contracts_overview.shtml

Other documents that may be developed include User Manual, training Plan, Conversion Plan, and an Implementation Plan. The plan for implementation will need to be adapted if the development/and maintenance is intended to be performed off-site. All or part of the specifications for modifications, capacity impact, support, etc., referred to in this phase may be determined as part of the selection process.

A Test Plan will need to be developed for stress testing, network load testing, user acceptance testing, and security testing.

A detailed Application Software Acquisition Life Cycle is available on the PMO web site under Executing. http://www.oregon.gov/DHS/admin/pmo/publications/pmo_templates.shtml

The results of the phase activities are presented to project stakeholders and decision makers for formal approval to proceed into the next life-cycle phase.

The Project Manager reports on phase activities as part of the SSI Project Status Review Process. The review should address phase activities status, planning status for subsequent life-cycle phases, and confirmation of phase activities documentation.


http://www.oregon.gov/DHS/admin/pmo/publications/pmo_templates.shtml

http://www.oregon.gov/DHS/admin/pmo/contracts/contracts_overview.shtml

DRAFT

DRAFT

SDLC Documents

This life cycle framework specifies which documentation may 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 library. Recommended documents and their project phase are shown in the SDLC Document Table.

SDLC Document Development Table

Key: C=Created R=Revised F=Finalized *=Updated as needed

Initi

atio

n P

hase

Sys

tem

Con

cept

D

evel

opm

ent

Pla

nnin

g

Req

uire

men

ts

Ana

lysi

sD

esig

n

Dev

elop

men

t

Inte

grat

ion

and

Tes

t

Impl

emen

tatio

n

Ope

ratio

ns a

nd

Mai

nten

ance

Dis

posi

tion

Business Case C R FProduct Description

C/F

Executive Summary

C/F

Charter 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

Change Management

C R R R F * *


DRAFT

DRAFT

Initi

atio

n P

hase

Sys

tem

Con

cept

D

evel

opm

ent

Pla

nnin

g

Req

uire

men

ts

Ana

lysi

sD

esig

n

Dev

elop

men

t

Inte

grat

ion

and

Tes

t

Impl

emen

tatio

n

Ope

ratio

ns a

nd

Mai

nten

ance

Dis

posi

tion

PlanCommunication Management Plan

C R R R F

Quality Management Plan

C R R R F * *

Issues Management Plan

C R R R F * *

Contracts & Procurement Management Plan

C R F *

Requirements Management Plan

C R F

Integrated Project Plan

C R R R F *

Test Plan C R R F * *

System Design C FImplementation Plan

C R F

Conversion Plan

C R F *

Maintenance Manual

C R F * *

System Administration

C R F * *


DRAFT

DRAFT

Initi

atio

n P

hase

Sys

tem

Con

cept

D

evel

opm

ent

Pla

nnin

g

Req

uire

men

ts

Ana

lysi

sD

esig

n

Dev

elop

men

t

Inte

grat

ion

and

Tes

t

Impl

emen

tatio

n

Ope

ratio

ns a

nd

Mai

nten

ance

Dis

posi

tion

ManualTraining Plan C R F * *User Manual C R F * *

Contingency Plan

C F * *

Software Development

C R F *

Integration C F * *

Test Analysis Report

C

Post-Implementation Review

C

Lessons Learned Report

C

Disposition Plan

C/F

Post-Termination Review Report

C/F


DRAFT

DRAFT

Document Description Table

BusinessCase

Identify why a business process is necessary and what business benefits can be expected by implementing this improvement. A business scenario and context must be established in which a business problem is clearly expressed in purely business terms. Provide background information at a level of detail sufficient to familiarize senior managers to the history, issues and customer service opportunities that can be realized through improvements to business processes with the potential support of IT. This background information must not offer or predetermine any specific automated solution, tool, or product.

ChangeManagementPlan

The purpose of the Change Management Plan is to coordinate changes across the entire project. The plan will address how the project will ensure that the changes are beneficial, determine how the change will occur, and manage the changes as they occur.

Charter A project charter formally recognizes the existence of a project. It provides the project manager and project team with clear guidance on how the project should be planned and managed. It describes primary roles, responsibilities, and authority. The Project Charter is developed with the Sponsor to obtain agreement on how the project should be planned and managed. The Sponsor approves the Project Charter and provides approval to proceed. After the Project Charter is approved, the System Concept Development Phase begins.

CommunicationPlan

The purpose of the Communication Plan is to determine communication needs of all people within the organization and possibly external to the organization that will be affected by the project: who needs what information, when will they need it, and how will it be given to them.


DRAFT

DRAFT

ContingencyPlan

The Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities.

ContractsAndProcurementManagementPlan

The Contracts and Procurement Management Plan describes how all the procurements/contracts will be managed, including solicitation planning, solicitation, and source selection, to contract administration and contract closeout. The Contracts and Procurement Management Plan identifies which project needs can be best met by procuring products or services outside the project’s organization. The questions to be answered in the plan are whether to procure, how to procure, what to procure, how much to procure, and when to procure it.

ConversionPlan

If current information needs to be converted/migrated/transitioned to the new system, a Conversion Plan needs to be designed for those purposes, especially if converting means re-engineering existing processes.

CostBenefitAnalysis

The Cost Benefit Analysis provides cost or benefit information for analyzing and evaluating alternative solutions to a problem and for making decisions about initiating, as well as continuing, the development of information technology systems.

FeasibilityStudy

The Feasibility Study provides an overview of a business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed.

ImplementationPlan

The purpose of the Implementation Plan is to describe the agreements on the implementation timetable, activities, and work responsibilities. The Implementation Plan describes how the information system will be


DRAFT

DRAFT

deployed and installed into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements.

IntegratedProjectPlan

The Integrated Project Plan is developed using the outputs of the Project’s Plans to create a consistent, coherent document that can be used to guide both project execution and project control. It is required to ensure that the various elements of the project are properly coordinated. It is a document or collection of documents, which communicate the project’s plan. The integrated plan should be expected to change over time, as more information becomes available to the project. The amount of planning performed should be commensurate with the scope of the project and the usefulness of the information developed.

Integration The Integration document explains how the software components, hardware components, or both are combined and the interaction between them.

IssueManagementPlan

The purpose of the Issue Management Plan is to outline the recommended approach for identifying outstanding issues, tracking the progress of the resolutions, and documenting the solutions. The plan includes (1) a method to identify and analyze issues impacting project progress and (2) a means to achieve and document the planned resolution and decisions. Issues that the Project Manager cannot resolve will go to the Steering Committee and ultimately the Sponsor for a final resolution or decision.

MaintenanceManual

The Maintenance Manual is prepared to ensure continued operation of the system once it is completed. The Maintenance Manual provides maintenance personnel with the information necessary to maintain the


DRAFT

DRAFT

system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures.

QualityManagementPlan

The Quality Management Plan addresses how quality assurance and control for the project will be conducted. The purpose of the Quality Management Plan is to ensure that the project will satisfy the needs for which it was undertaken. The Quality Management Plan includes activities of the overall management function that determine the quality policy, quality standards, and responsibilities and implements them by means such as quality planning, quality control, quality assurance and quality improvement.

RequirementsManagementPlan

The purpose of the Requirements Management Plan is to establish and maintain an agreement with the customer and the project on the requirements, which represent the product scope that will be addressed by the project. The requirements will be the basis for estimating, planning, executing and controlling the activities throughout the duration of the project. The plan addresses how the project will manage requirement development and change to ensure that the initial business needs and project objectives are allocated into the technical and non-technical requirements needed to deliver the solution. It details the process, assigns responsibilities, identifies the techniques to be used, associated tools, and documentation needs. It is the responsibility of the project manager to ensure that the project team is aware of and follows the plan; it’s process and associated responsibilities.

RequirementsDocument

Using documentation related to user requirements from the Planning Phase, the system is defined in more detail


DRAFT

DRAFT

with regard to system inputs, processes, outputs, and interfaces. The system is described in terms of the functions to be performed, not in terms of computer programs, files, and data streams. The emphasis in this phase is on determining what functions must be performed rather than how to perform those functions. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.

RiskAnalysisDocument

Project risks are identified and the plans to reduce or mitigate the risks are documented.

RiskManagementPlan

The Risk Management Plan specifies the plans to reduce or mitigate the risks. Risk planning involves determining and defining:Which risks are likely to affect the project, Evaluating the risks to assess range of possible outcomes, andHow the risks will be mediated if they occur or defining how the planned work activities will be modified and at what cost to avoid selected risks from occurring.

SoftwareDevelopment

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

SystemDesign

The System Design document describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interface, detailed design, processing logic, and external interfaces.

SystemAdministrationManual

The System Administration Manual is developed to provide computer operators with a detailed operational description of the information system and its associated environments, operations and procedures.


DRAFT

DRAFT

TestPlan

The Test Plan should ensure that all aspects of the system are adequately tested and can be implemented. It documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. This includes identifying what areas need to be involved in testing, identifying what tests will be performed, defining test procedures, begin building test scripts and use cases to be used in testing, and traceability back to the requirements. The Test Plan identifies the test scripts or scenarios, responsible tester, expected results, and test results.

TestAnalysisReport

The Test Analysis Report documents each test – unit, integration, system, user acceptance and security.

TrainingPlan

The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the activities needed to support the development of training materials, coordination of training schedules, reservation of personnel and facilities, planning for training needs, and other training-related tasks. Training activities are developed to teach user personnel the use of the system as specified in the training criteria. Includes the target audience and topics on which training must be conducted on the list of training needs. It includes, in the training strategy, how the topics will be addressed and the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules.

UserManual

The User Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.


DRAFT

DRAFT


DRAFT

DRAFT

References

Information used in the development of this document came from the following sources:

1. The U.S Department of Justice, System Development Life Cycle Guidance Document: http://www.usdoj.gov/jmd/irm/lifecycle/table.htm

2. The State of Oregon Information Resources Management Division (IRMD) SDLC methodology: http://egov.oregon.gov/DAS/IRMD/docs/doc/ sd_large_development_process.doc


http://egov.oregon.gov/DAS/IRMD/docs/doc/%20sd_large_development_process.doc

http://egov.oregon.gov/DAS/IRMD/docs/doc/%20sd_large_development_process.doc

http://www.usdoj.gov/jmd/irm/lifecycle/table.htm

SDLC Framework 03-2006.doc.doc

Technology