Sdlc Templates

Document Sample
Sdlc Templates Powered By Docstoc
					                                    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.

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.




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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:277
posted:8/11/2011
language:English
pages:35
Description: Sdlc Templates document sample