Sdlc Templates

Report as inappropriate Your report has been received

Description

Sdlc Templates document sample

Shared by: tdq15532

Tags

Stats

views:: 168
posted:: 8/11/2011
language:: English
pages:: 35

Public Domain

Document Sample

DRAFT

Office of Information Services

System Development
Life Cycle
Framework Guide

VERSION 1.6
MARCH 2006
DHS OFFICE OF INFORMATION SERVICES
SDLC Framework Guide

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 1
DRAFT

Table of Contents
Introduction ................................................................................. 3
Objectives ............................................................................................... 4
Key Principles of Effective Life Cycle Management ................................. 5
Life Cycle Phases ........................................................................ 8
Initiation................................................................................................. 11
System Concept Development .............................................................. 12
Planning Phase ..................................................................................... 13
Requirements Analysis .......................................................................... 14
Design ................................................................................................... 15
Development/Construction Activity ........................................................ 17
Integration and Testing .......................................................................... 18
Implementation...................................................................................... 19
Operations and Maintenance ................................................................ 20
Disposition ............................................................................................ 21
Alternative Life Cycle – COTS .................................................. 22
Acquisition Activities .............................................................................. 22
SDLC Documents ...................................................................... 25
SDLC Document Development Table .................................................... 25
Document Description Table ................................................................. 28
References ................................................................................. 35

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 2
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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 3
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 4
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 Project
The 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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 5
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 Cycle
Accurate 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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 6
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 7
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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 8
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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 9
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 10
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.shtml
Document resulting from Initiation will be an approved and signed Project
Charter.

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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 11
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 12
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 13
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 14
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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 15
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 16
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 17
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 18
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 19
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 20
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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 21
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 Activities
The 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 Preparation
The 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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 22
DRAFT
Supplier Selection
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 Monitoring
The 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 Acceptance
The 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 Plan
A 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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 23
DRAFT
spreadsheets), the degree of detail of requirements definition is roughly the
same as it is for a development project.

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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 24
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

Integration and Test
System Concept

Operations and
Implementation
Initiation Phase

Requirements
Development

Development

Maintenance
Disposition
Planning

Analysis
Design

Business Case C R F
Product C/F
Description
Executive C/F
Summary
Charter C/F

Cost-Benefit C R R R R F
Analysis
Feasibility C R F
Study
Risk C R R R R F
Management
Plan

Change C R R R F * *
Management

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 25
DRAFT

Integration and Test
System Concept

Operations and
Implementation
Initiation Phase

Requirements
Development

Development

Maintenance
Disposition
Planning

Analysis
Design
Plan
Communication C R R R F
Management
Plan
Quality C R R R F * *
Management
Plan
Issues C R R R F * *
Management
Plan
Contracts & C R F *
Procurement
Management
Plan
Requirements C R F
Management
Plan
Integrated C R R R F *
Project Plan

Test Plan C R R F * *

System Design C F
Implementation C R F
Plan
Conversion C R F *
Plan
Maintenance C R F * *
Manual

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 26
DRAFT

Integration and Test
System Concept

Operations and
Implementation
Initiation Phase

Requirements
Development

Development

Maintenance
Disposition
Planning

Analysis
Design
System C R F * *
Administration
Manual
Training Plan C R F * *
User Manual C R F * *

Contingency C F * *
Plan
Software C R F *
Development
Integration C F * *

Test Analysis C
Report

Post- C
Implementation
Review

Lessons C
Learned Report

Disposition C/F
Plan
Post- C/F
Termination
Review Report

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 27
DRAFT
Document Description Table

Business Identify why a business process is necessary and what
Case 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.

Change The purpose of the Change Management Plan is to
Management coordinate changes across the entire project. The plan
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.

Communication The purpose of the Communication Plan is to determine
Plan 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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 28
DRAFT

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

Contracts The Contracts and Procurement Management Plan
And describes how all the procurements/contracts will be
Procurement managed, including solicitation planning, solicitation,
Management and source selection, to contract administration and
Plan 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.

Conversion If current information needs to be
Plan 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.

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

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

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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 29
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.

Integrated The Integrated Project Plan is developed using the
Project outputs of the Project’s Plans to create a consistent,
Plan 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.

Issue The purpose of the Issue Management Plan is to outline
Management the recommended approach for identifying outstanding
Plan 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.

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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 30
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.

Quality The Quality Management Plan addresses how quality
Management assurance and control for the project will be conducted.
Plan 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.

Requirements The purpose of the Requirements Management Plan is
Management to establish and maintain an agreement with the
Plan 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.

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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 31
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.

Risk Project risks are identified and the plans to reduce or
Analysis mitigate the risks are documented.
Document
Risk The Risk Management Plan specifies the plans to
Management reduce or mitigate the risks. Risk planning involves
Plan determining and defining:
Which risks are likely to affect the project,
Evaluating the risks to assess range of possible
outcomes, and
How 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.

Software The Software Development document Contains
Development 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.

System The System Design document describes the system
Design 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.

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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 32
DRAFT

Test The Test Plan should ensure that all aspects of the
Plan 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.

Test The Test Analysis Report documents each test – unit,
Analysis integration, system, user acceptance and security.
Report
Training The Training Plan outlines the objectives, needs,
Plan 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.

User The User Manual contains all essential information for
Manual 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.

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 33
DRAFT

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 34
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

47bdc207-207f-46a1-b25a-f63ec4e52d53.doc Page 35