U.S. Environmental Protection Agency
ATTACHMENTS TO THE
SYSTEM LIFE CYCLE MANAGEMENT
(SLCM) PROCEDURE
(GUIDANCE)
Document Number XXX.X
January 10, 2007
OFFICE OF
ENVIRONMENTAL!
INFORMATION
-------
Table of Contents
SLCM Phase Descriptions:
Attachment 1: Definition Phase 2
A. Concept Exploration Subphase 2
B. System Planning Subphase 7
C. Requirements Subphase and Control Gate # 1 - EA Compliance Certification Review and
System Selection 14
Attachment 2: Acquisition/Development Phase 18
A. Acquisition Subphase 18
B. Design Subphase and Control Gate # 2 - EA Compliance Certification Review 22
C. Development Subphase 30
D. Test Subphase and Control Gate # 3 - Authorization to Operate 34
Attachment 3: Implementation Phase 38
Attachment 4: Operations & Maintenance Phase and Control Gate # 4 - Modify or
Terminate 42
Attachment 5: Termination Phase 50
Guidance on Control Gate Reviews:
Gate 1 - EA Compliance Certification and System Selection Review 54
Gate 2 - EA Compliance Certification Review 54
Gate 3 - Authorization to Operate Review 55
Gate 4 -Modify or Terminate Review 55
SLCM Tools:
Supporting Document Checklist for System Life Cycle Management 57
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page i
Updated: 1/10/07
-------
Concept
Exploration
Attachment 1: Definition Phase
A. Concept Exploration Subphase
Process The Concept Exploration Subphase begins when management determines
Description: the need to enhance a business process through the application of
information technology. The purposes of the Concept Exploration
Subphase are to:
• Identify 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
relative to that need
• Recommend the exploration of alternative concepts and
methods to satisfy the need
During this initial phase the System Sponsor designates a System Manager
who prepares a Concept Proposal. Projects may be initiated as a result of
business process improvement activities, changes in business functions,
advances in information technology, or may arise from external sources,
such as public law or the general public. When an opportunity to improve
business/mission accomplishments or to address a deficiency is identified,
the System Manager documents these opportunities in the Concept
Proposal.
Procedure The following activities are performed as part of the Concept Exploration
Description: Subphase:
• Identify and establish the business justification for the
proposed system
• Establish the project sponsorship/ownership
• Consider the project team needs
• Document the exploration activities
• Review and approve to proceed to the next phase
• Initiate security planning activities
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 2
-------
Concept
Exploration
Every project must have a responsible organization and sufficient
resources to execute the project. The Concept Proposal should identify
why a business process is necessary and what business benefits can be
expected by implementing this improvement. It is important to state the
needs or opportunities in business terms. Avoid identifying a specific
product or vendor as the solution. The Concept Proposal should be
approximately 2-5 pages in length. The background information provided
should be at a level of detail sufficient to familiarize senior managers with
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.
The System Sponsor is the principal authority on matters regarding the
expression of business needs, the interpretation of functional requirements
language, and the mediation of issues regarding the priority, scope and
domain of business requirement. The System Sponsor must understand
what constitutes a requirement and must take ownership of the
requirements and input and output.
This activity involves the appointment of a System Manager who carries
both the responsibility and accountability for project execution. For small
efforts, this may only involve assigning a project to a manager within an
existing organization that already has an inherent support structure. For
new, major projects, a completely new organizational element may be
formed - requiring the hiring and reassignment of technical and business
specialists.
To provide a management structure for the project, the System Manager
should adapt, adopt, or create written processes and procedures for
recurring project activities. These include requirements management,
project tracking, contractor management, verification and validation,
quality assurance, change management, and risk management.
The results of the efforts of this phase are documented in the Concept
Proposal and the Mission Need Statement. The approval of the Concept
Proposal identifies the end of the Concept Exploration subphase.
Approval should be annotated on the Concept Proposal by the System
Sponsor and/or the Chief Information Officer (CIO).
Once approval to proceed has been given within EPA, a core project team
with participation of the System Manager must be established in order to
move on to the System Planning Subphase.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 3
-------
Concept
Exploration
Responsibilities:
System Sponsor: The System Sponsor is the senior spokesperson for the
project, and is responsible for ensuring that the needs and
accomplishments within the business area are widely known and
understood. The System Sponsor is also responsible for ensuring that
adequate financial and business process resources to address the business
area needs are made available in a timely manner.
System Manager: The appointed System Manager is charged with
leading the efforts to ensure that all business aspects of the process
improvement effort are identified in the Concept Proposal. This includes
establishing detailed project plans and schedules.
Information Security Officer (ISO): The ISO is responsible for
coordinating the Change Impact Assessments.
Project Level
Reviews:
The Initiation Phase Review is performed at the end of this phase which
ensures that the Concept Proposal is approved before proceeding to the
next phase. The review ensures that the Concept Proposal is sound, does
not conflict with the Enterprise Architecture and is a good investment.
This is the first key decision required in the SDLC and IT Investment
Management process.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Acquisition Strategy
Documents the framework for planning, organizing, staffing, controlling, and
leading a program. It provides a master schedule for research, development,
test, production, and other activities essential for program success, and for
formulating functional strategies and plans.
Status
D
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 4
-------
Concept
Exploration
Work Product
Approvals (Decision Papers) (SMP)
Document decisions presented to management. Summarize those aspects of the
analysis and decisions of a given phase or subphase that are important to
program management and requests approval to continue the project. The EPA
life cycle model provides for decision papers to be prepared at the beginning of
the Definition, Development or Acquisition, Implementation, and Retirement
Phases and at the end of the Requirements Subphase. The level of detail for
decision papers should be appropriate to the category of the system.
Business Case
The compelling business rationale and justification for developing or
modernizing a system. It describes current business processes, possibly using
activity and data models. Current costs and performance are also associated
with the models. Gaps between current and desired outcomes are identified and
analyzed. Alternatives for improving the business are developed and evaluated
based on readily available information. This is a document that is a component
of SMP.
Change Directive
Documents the formal Change Control Document to implement an approved
change.
Change Tracking Log
Log that records the status of all changes proposed to the SMP, including a
description of the proposed change, the status history, and final disposition.
Concept of Operations
Describes Business process and how system is used in support of the process.
Concept Proposal
Describes the need or opportunity to improve business functions. It identifies
where strategic goals are not being met or mission performance needs to be
improved.
Cost-Benefit Analysis
Documents costs and proposed benefits of alternatives.
Information Categorization
Types of information that will be collected and processed should be identified
and categorized in accordance with FIPS 199 and NIST SP 800-60, to the extent
known, including Privacy Act type information. Further refinement will be
needed throughout the life cycle.
IT Project Request
Serves as the formal budget request for the project. Most of the information
required for the IT Project Request is obtained from the Business Case and the
Project Risk Management Plan.
Mission Need Statement
Documents the results of a mission analysis, serves as the decision document
for the mission need decision, and after final approval, serves as the basis for
investment analysis. It provides a clear, unambiguous, and quantitative
description of the mission area, current capability, capability shortfall or
technology opportunity, required operational capability, impact of disapproval,
benefits, time frame, critically, and resource estimate. This product is a
component of the SMP.
Privacy Impact Assessment
Based on the initial FIP 199 categorization and the identification of the need or
potential to collect Privacy Act data/information, the assessment required by the
Status
B
D
^
^
B
B
D
D
B
B
B
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 5
-------
Concept
Exploration
Work Product
Status
Privacy Act and/or E-Government Act of 2002 to conduct assessments on
investments before developing or procuring information technology that
collects, maintains, or disseminates information that is in an identifiable form.
Project Plan
Documents the schedule and time frame for system development activities to
occur based on the estimates developed in the previous phases, as well as task
dependencies, organization priorities, and resource availability.
D
Project Risk Management Plan (SMP)
Identifies and categorizes risks to the successful completion of the project.
Lists each identified risk, describing its probability of occurrence, potential
consequences, and degree to which it can be controlled. Strategies for
eliminating or mitigating each risk are documented.
D
Security Concept
Documents a preliminary analysis of security considerations for the new
system. It provides the first look at the information that might be included in
the Security Plan. Areas considered include risks from theft, disclosure,
unauthorized access, eavesdropping, programmed attacks, incorrect routing,
misplacement, erasure, and accidental damage. Includes an initial analysis of
FIPS 199/NIST 800-60 categories and impact levels of the data and resulting
information system. Based on this information, an initial baseline of security
controls will be identified from FIPS 201 and NIST SP 800-53.
D
Security Risk Assessment
Begins assembling and analyzing threat, and vulnerability information drafting
an initial qualitative determination of risk to a collection of sensitive data and
the people, information systems, and installations involved in transmitting,
accessing and processing that data. Its purpose is to inform the selection or
modification of required controls from FIPS 201 and NIST SP 800-53 based on
the information's FIPS 199 impact levels to provide cost-effective and adequate
security.
D
Solution Architecture
Describes how an individual information management system, or information
acquisition, will comply with the requirements of the Target Architecture,
which is the set of products that portrays the future state of the Agency. A
Solution Architecture is a comprehensive architectural response to a business
problem. Solutions address all layers of Enterprise Architecture - strategy,
business, data, applications and technology/security.
B
System Concept Document
Describes the results of all significant functional analyses conducted during this
subphase, including definition of high level requirements, assessment of
pertinent existing information processing capabilities, complete formulation of
alternative system functional concepts, assessment of the alternatives, and
rationale for the selection of the recommended concept. The data portion
describes high-level data requirements for the recommended system concept,
provides definitions of these requirements, charts the logical structure of the
data requirements, and describes sources, uses, and distribution of data. It
defines the system concept, and includes, if applicable, a feasibility study,
alternatives analysis, and acquisition strategy.
B
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 6
-------
System Planning
Attachment 1: Definition Phase
B. System Planning Subphase
Process Description:
The System Planning Subphase begins when the Concept Proposal
has been formally approved and funded. This phase requires study
and analysis that may lead to system development activities.
Following review and approval of the Concept Proposal, some form
of EPA approval (tasking directive) should be issued to begin the
formal studies and analyses of the need. The issuing of the tasking
directive initiates the System Planning Subphase and begins the life
cycle of an identifiable project. This subphase is also the start of the
System Management Plan.
Procedure
Description:
The following activities are performed as part of the System Planning
Subphase. The results of these activities are captured in the System
Management Plan, the Business Case and the Project Risk
Management Plan and their underlying institutional processes and
procedures.
The System Management Plan (SMP) is the primary managerial
documentation in the life cycle of an information system. The
various components of this document can be tailored to the project's
classification and may include:
Change Tracking Log
Mission Need Statement
Business Case
System Operations and Maintenance Concept
Responsibilities
Cost-Benefit Analysis Summary
Schedule
Project Risk Management Plan
Security Plan and Security Categorization
Quality Assurance Plan
Configuration Management Plan
Review Sections
o Data Standards
o Enterprise Architecture (EA) Alignment
o Capital Planning and Investment Control (CPIC)
Approvals (Decision Papers)
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 7
-------
System Planning
• Waivers
• Work Breakdown Structure
• Application Deployment Checklist
The project team, supplemented by enterprise architecture experts if
needed, determines the acquisition strategy by analyzing all feasible
technical, business process, and commercial alternatives to meeting
the business need. These alternatives are analyzed from a life cycle
cost perspective. The results of these studies show a range of feasible
alternatives based on life cycle cost, technical capability, operational
feasibility and scheduled availability. Typically, these studies narrow
the system technical approaches to only a few potential, desirable
solutions that then proceed into the subsequent life cycle phases.
Caution is needed to ensure new and/or creative design concepts are
not eliminated from consideration.
The project team plans the subsequent phases to allow development
of the project schedule and budget requirements, and to define the
expected performance benefits. The Business Case summarizes the
high level requirements for the project and justifies the need.
The project team identifies all alternatives that may address the need
and any programmatic or technical risks. The risks associated with
further development are also studied. The results of these
assessments are summarized in the Business Case and documented in
the Project Risk Management Plan.
The results of the phase efforts are presented to project stakeholders
and decision makers together with a recommendation to do one of the
following:
• Proceed into the next life cycle phase
• Continue additional conceptual phase activities
• Terminate the project
The emphasis of the review is on:
• The successful accomplishment of the phase objectives
• The plans for the next life cycle phase
• The risks associated with moving into the next life cycle
phase
The review also addresses the availability of resources to execute the
subsequent life cycle phases. The results of the review are
documented reflecting the decision on the recommended action.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 8
-------
System Planning
Responsibilities:
System Manager: The System Manager is responsible and
accountable for the successful execution of the System Planning
Subphase. The System Manager is responsible for leading the team
that accomplishes the tasks shown above, and is ultimately
responsible for the quality of the finished product.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Procurement Officer: The Procurement Officer is responsible and
accountable for preparing solicitation documents under the guidance
of the System Manager.
System Sponsor: The System Sponsor is responsible for authorizing
and ensuring that the funding and resources are in place to support
the system.
Oversight Stakeholders: The oversight stakeholders provide
oversight, advice and counsel to the System Manager on the conduct
and requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations
to the EPA decision makers during project reviews and in support of
project decision milestones.
System Owner: The System Owner is designated at an appropriate
level within the EPA as the project decision authority (may or may
not be the same individual designated as the sponsor in the previous
phase). This individual is charged with assessing the:
• Completeness of the planning phase activities
• Robustness of the plans for the next life cycle phase
• Availability of resources to execute the next phase
• Acceptability of the acquisition risk of entering the next phase
For applicable projects, this assessment also includes the readiness to
award any major contracting efforts needed to execute the next phase.
During the end of phase review process, the decision maker does one
of the following:
• Directs the project to move forward into the next life cycle
phase (including awarding contracts)
• Directs the project to remain in the planning phase pending
completion of delayed activities or additional risk reduction
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 9
-------
System Planning
efforts
Terminates the project
Project Level
Reviews:
A review is performed at the end of the System Planning Subphase.
The review ensures that the goals and objectives of the system are
identified and that the feasibility of the system is established.
Products of the System Planning Subphase are reviewed including the
budget, risk, and user requirements. This review is organized,
planned, and led by the System Manager and/or representative.
Approval of the Business Case by the SIO grants approval to proceed
to the Requirements Phase of the SLC. It is important in this effort
not to eliminate new and creative approaches. Emphasis should be on
the total cost of ownership and not just a single system concept.
Support and training issues may become very important from this
perspective.
After the Business Case is approved and a recommendation is
accepted by the SIO and System Sponsor, the system project planning
can begin.
As identified in the Definition Phase., each project has an individual
designated to lead the effort. The individual selected has appropriate
skills, experience, credibility, and availability to lead the project.
Clearly defined authority and responsibility must be provided to the
System Manager.
The System Manager works with the SIO and System Sponsor to
verify the scope of the proposed program, participation of the key
organizations, and potential individuals who can participate in the
formal reviews of the project. This decision addresses both
programmatic and information management-oriented participation as
well as technical interests in the project that are known at this time.
In view of the nature and scope of the proposed program, the key
individuals and oversight stakeholders who are the approval
authorities for the project should be identified, including the sign-off
for quality assurance.
The System Manager and System Sponsor determine if any
particularly unusual programmatic, technical, or information
management skills or experience are needed. Organizations not
participating directly in the project may be notified, if appropriate,
including external organizations. Whenever the concept is shared
among multiple organizations, data administration plays a strong role.
Management approval to commit resources to the proposed program
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 10
-------
System Planning
marks the beginning of the subsequent system development life cycle
phases.
The feasibility analysis and cost benefit analysis confirm that the
defined information management concept is significant enough to
warrant an IT project with life cycle management activities.
The feasibility study analysis confirm that the information
management need or opportunity is beyond the capabilities of existing
systems and that developing a new system is a promising approach.
The Cost-Benefits Analysis confirms that the projected benefits of the
proposed approach justify the projected resources required.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Acquisition Strategy
Application Deployment Checklist - (SMP)
The expected or projected platform(s) and locations on which an application
will reside, requires knowledge of the requirements for deployment on that
platform. Application deployment checklists should be obtained and
requirements identified and factored into the system planning as soon as
possible.
Approvals (Decision Papers) - (SMP)
Business Case - (SMP)
Change Directive
Change Tracking Log - (SMP)
Configuration Management Plan - (SMP)
Describes the overall plan for identifying and controlling the parts of the system
to ensure its proper functioning according to its requirements.
Contract Security Requirements
Requirements for contractor background checks, and controls to protect any
data used in development, non-disclosures, and separation of duties or "need-to-
know" controls need to be spelled out for inclusion in any contracts in the next
phase.
Cost Benefit Analysis - (SMP)
Data Standards - (SMP)
Technical specifications for the defining, naming, and using of data within the
Status
B
D
B
B
^
^
B
B
B
D
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 11
-------
System Planning
Work Product
Status
system.
Feasibility Study
Analyzes whether the information management need or opportunity is beyond
the capabilities of existing systems and that developing a new system is a
promising approach.
B
Mission Need Statement - (SMP)
U
Project Plan
B
Project Quality Assurance Plan - (SMP)
Describes the planned and systematic pattern of all actions necessary to provide
adequate confidence that the system optimally fulfils the organization's
expectations.
B
Project Risk Management Plan - (SMP)
B
Records Management Disposition Schedule
Documents length of time that all SLCM records are retained and when inactive material
is moved to storage.
D
Responsibilities - (SMP)
Describes roles and responsibilities of the key participants in the system life
cycle development process. It identifies, by name, the System Sponsor, System
Owner, System Manager, and other points-of-contact. It lists the
organization(s) supporting the system and delineates organizational
responsibilities.
B
Schedule - (SMP)
Documents the time frame for system development activities to occur based on
the estimates developed in the previous phases, as well as task dependencies,
organization priorities, and resource availability. Adjustments are made
throughout the life cycle based on enterprise goals, objectives, and priorities.
Schedule adjustments also take into account task dependencies and resource
availability.
B
Security Plan - (SMP)
Begins the development of the security plan which describes the plan to meet
security and privacy protection requirements. It addresses what is known to
date about the impact levels, conceptual information system architecture, risks,
required controls, contingency or continuity of support needs, laws and
penalties that may apply to breach of confidentiality, etc."
D
Security Categorization
B
Solution Architecture
U
System Operations and Maintenance Concept - (SMP)
Describes the general manner in which the system will be managed to include
the level of operational support required. Identifies whether the system will be
distributed to the Regions or operated from a central location. Describes how
the system will be extended to a user's desktop, i.e., whether it requires a
support person to install a client component or the system is Web-based with no
client footprint required. Identifies the number and locations of required
servers. Estimates the number of operational support personnel and provides an
estimate of the number of hours per user required to support the system
annually. Identifies the number of users expected by organization and location.
Waivers (SMP)
Written justification for deviating from the system life cycle process or for
D
B
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 12
-------
System Planning
Work Product
omitting sections of documents from the SMP. Waiver may be considered
based on the requirements of the system and needs of the developing office.
Any waivers for major applications and general support systems and systems
considered to be major investments in the CPIC process must receive
concurrence from the System Owner and applicable IMO and be approved y the
Director of the Office of Environmental Information's Office of Technology
Operations and Planning. Waivers for any other applications and / or systems
must receive concurrence from the System Owner and be approved by the
applicable IMO. Waivers must be documented as part of the SMP. .
Work Breakdown Structure (SMP)
Status
B
System Life Cycle Management Guidance - DPvAFT - Not for Distribution
Updated: 1/10/07
Page 13
-------
Requirements
Attachment 1: Definition Phase
C. Requirements Subphase and
Control Gate # 1 - EA Compliance Certification Review and
System Selection
Process
Description:
The Requirements Subphase begins when the previous phase
documentation has been approved or by management direction.
Documentation related to user requirements from the System Planning
Subphase 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. In
such instances, all work products are revised to reflect this analysis.
During the Requirements Subphase., the system is defined in more
detail with regard to system inputs, processes, outputs, and interfaces
(both internal and external). This definition process occurs at the
functional level. 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, and ensuring
data quality should be considered. This is best done through first
identifying outputs, inputs, and processes. During the Requirements
Subphase, the project team:
• Further defines and refines functional and data requirements
• Completes business process engineering of the functions to be
supported
• Develops detailed data and process models
• Defines functional and system requirements that are not easily
expressed in data and process models. Functional and system
requirements also include the requirements of the business
process, the user requirements, and operational requirements
• Refines the high level architecture and logical design to support
the system and functional requirements
• Continues to identify and mitigate risk that the technology can be
phased-in and coordinated with the business.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 14
-------
Requirements
Procedure
Description:
The tasks described below are performed during the Requirements
Subphase.
The business needs are consolidated and affirmed. The functional
requirements and the data requirements are then consolidated. The
functional requirements are connected to the data requirements.
The Functional Requirements Document (FRD) is a record of the above
requirements. This can be established as a matrix and tracked for
satisfaction of every module of the system as development progresses.
The Functional and Data Requirements Review is conducted in the
Requirements Subphase by the SIO and System Sponsor to ensure that
the business requirements have been accurately linked to functional and
data requirements.
The Concept Exploration Subphase documentation may need to be
revised or updated. The System Planning Subphase documentation may
also need to be updated in this phase.
Responsibilities:
System Manager: The System Manager is responsible and
accountable for the successful execution of the Requirements subphase.
The System Manager is responsible for leading the team that
accomplishes the tasks shown above.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Procurement Officer: The Procurement Officer is responsible and
accountable for preparing solicitation documents under the guidance of
the program manager.
Quality Assurance Staff: The Quality Assurance Staff is responsible
for continually reviewing the state of the product so the rest of the team
can focus on their tasks. Quality Assurance's goal is to support the
product development processes.
Oversight Stakeholders: The oversight stakeholders provide oversight,
advice and counsel to the System Manager on the conduct and
requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations to
the EPA decision makers during project reviews and in support of
project decision milestones.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 15
-------
Requirements
Control Gate 1
System Selection:
At the end of the Definition Phase is the EA Compliance Certification
Review and System Selection Control Gate. This ensures the business
justification is accurate and complete and approves the IT Investment
Business Case for inclusion in the EPA IT Portfolio. The system
selection decision process is described in EPA Order 2100.3, Capital
Planning and Investment Control (CPIC) Program Policy for
Management of Information Technology (IT) Investments..
Upon completion of all Requirements Subphase tasks and receipt of
resources for the next phase, the System Manager, together with the
project team, prepares and presents a project status review for the SIO,
IIS, System Sponsor, and other stakeholders. The review addresses:
• Requirements Subphase required work products, which
must be complete, approved, and verified
• Planning status for all subsequent life cycle phases (with
significant detail on the next phase, to include the status
of pending contract actions)
• Resource availability status
• Acquisition risk assessments of subsequent life cycle
phases given the planned acquisition strategy
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Acquisition Strategy
Approvals (Decision Papers) - (SMP)
Change Directive
Change Tracking Log
Concept of Operations
Contract Security Requirements
Cost Benefit Analysis
Status
U
B
•/
^
U
B
U
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 16
-------
Requirements
Work Product
Functional Requirements Document
Serves as the foundation for system design and development; captures user
requirements to be implemented in a new or enhanced system; the systems subject
matter experts document these requirements into the requirements trace ability
matrix, which shows mapping of each detailed functional requirement to its source.
Hardware Requirements Specification
Information Categorization
Interface Requirements Specification
Specifies the requirements imposed on one or more systems, subsystems, Hardware
Configuration Items, Computer Software Configuration Items, manual operations,
or other system components to achieve one or more interfaces among these entities.
Project Plan
Records Management Disposition Schedule
Security Concept
Documents a preliminary analysis of security considerations for the new system. It
provides the first look at the information that might be included in the Security
Plan. Areas considered include risks from theft, disclosure, unauthorized access,
eavesdropping, programmed attacks, incorrect routing, misplacement, erasure, and
accidental damage. Includes an initial analysis of FIPS 199/NIST 800-60 categories
and impact levels of the data and resulting information system. Based on this
information, an initial baseline of security controls will be identified from FIPS 201
and NISTSP 800-53.
Security Plan - (SMP)
Begins the development of the security plan which describes the plan to meet
security and privacy protection requirements. It addresses what is known to date
about the impact levels, conceptual information system architecture, risks, required
controls, contingency or continuity of support needs, laws and penalties that may
apply to breach of confidentiality, etc." Establishes the security requirements and
formalizes security process for system. Required for every system.
Preliminary Security Risk Assessment
Software Requirements Specification
Solution Architecture
System Engineering Management Plan
Documents the plan, articulation, and approval of the strategy to execute the
technical management aspects of the project (SEMP).
System Test Plan
Describes the specific tests and test cases to be used to evaluate the system at
appropriate points in the system's SLC consistent with the TEMP. Security testing
comes primarily from NIST SP 800-53a which will correspond to each security
control. Additionally, usability and other programmatic acceptance criteria testing
should be planned for that will contribute to system acceptance and authorizations.
Test and Evaluation Master Plan (TEMP)
Defines the overall strategy for ensuring that the developed and implemented
system conforms to all requirements. The TEMP describes the types of testing that
will be acceptable for use at various points in the system's SLC and what
constitutes "successful" testing.
Status
B
B
B
B
U
B
B
B
B
B
U
D
D
B
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 17
-------
I
I
Operations and
Pciinterisince
Attachment 2: Acquisition/Development Phase
A. Acquisition Subphase
Process
Description:
The purpose of acquisition planning is to allocate the requirements
among development segments, research and apply lessons learned from
previous projects, identify potential product and service providers, and
secure funding.
The Acquisition Subphase describes how all government human
resources, hardware, software, and telecommunications capabilities,
along with contractor support services, are acquired during the life
cycle of the project. The Acquisition Subphase helps ensure that
needed resources can be obtained and are available at the time they are
needed. The Acquisition Subphase includes a schedule that lists
activities for completion and work products to be produced with
appropriate estimated completion dates.
Procedure
Description:
The following activities are performed as part of the Acquisition
Subphase. The results of these activities are captured in the
Acquisition Plan and the Acquisition Strategy document and their
underlying institutional processes and procedures.
• Requirements Analysis
• Analysis of Alternatives
• Full Security Risk Assessment
• Procurement of Government Human Resources and
Services
• Procurement Plan
• Acquisition of Contractor Services
• Solicitation of Services
• Technical Evaluation Report
• Source Selection Recommendation
• Contract Award
• Adjustment of Funds
• Contract Performance
The applicable elements of the outline to complete the Acquisition
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 18
-------
Subphase are followed. The information in the plan is as follows:
• Adequate information for making management decisions
concerning procurement of government human resources
and services, contractor services procurement, including
ensuring the availability of funding
• Adequate information for performing a technical analysis
and evaluation of vendor proposals
• Adequate information for vendors to prepare bids
• Adequate information for the source selection official to
base a selection
The following are considered when submitting a request for hardware,
software, and/or related services:
• Resources are consistent with applicable laws, regulations,
policy/procedural guidance from central management
agencies, Congress, and senior Agency management
• Acquisitions are consistent with Agency objectives and
initiatives as defined in the EPA EA
• Resources are obtained only in direct support of the EPA
missions and programs of the acquiring office/organization
• Acquisitions are not redundant or duplicative efforts
resulting in wasted money, time, and resources
• Resources represent the most efficient and cost-effective
means of providing automated support
Caution is needed to ensure new and/or creative design concepts are
considered. The Acquisition Subphase typically has its own mini-life
cycle of pre-solicitation, solicitation and award, and post award. The
life cycle model varies according to the system development effort; this
means that the activities in each differ significantly. The model
Acquisition Plan includes a milestone schedule, with estimated
completion dates.
The Acquisition Subphase becomes critical after the Functional
Requirements Document has been approved. Several acquisitions may
be needed to procure an entire system and are a continuous part of the
life cycle. The Acquisition Plan is continuously updated with the
active involvement of the System Manager.
Responsibilities:
System Manager: The System Manager works directly with
acquisitions personnel to ensure the timely award of the needed
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 19
-------
Operations and
Pciinterisince
resources. The Acquisition Subphase is developed as required by the
Federal Acquisition Regulation (FAR) 7.103. The System Manager is
responsible and accountable for the successful execution of the
Acquisition Subphase. The System Manager is responsible for leading
the team that accomplishes the tasks shown above.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager. May
include Program Analysts or Programmers who interpret user
requirements, designs and writes the code for specialized programs.
Procurement Officer: The Procurement Officer is responsible and
accountable for preparing solicitation documents under the guidance of
the System Manager.
Oversight Stakeholders: The oversight stakeholders provide oversight,
advice and counsel to the System Manager on the conduct and
requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations to
the EPA decision makers during project reviews and in support of
project decision milestones.
System Owner: At an appropriate level within the EPA, an individual
is designated as the project decision and quality authority (may or may
not be the same individual designated as the sponsor in the previous
phase). This individual is charged with assessing:
• The completeness of the Acquisition Subphase activities
• The robustness of the plans for the next life cycle phase
• The availability of resources to execute the next phase
• The acceptability of the risk of entering the next phase
• The quality of the products produced in each phase
For applicable projects, this assessment also includes the readiness to
award any major contracting efforts needed to execute the next phase.
At the end of phase review process, the decision maker does one of the
following:
• Directs the project to move forward into the next life cycle
phase (including awarding contracts)
• Directs the project to remain in the acquisition subphase
pending completion of delayed activities or additional risk
reduction efforts
• Terminates the project
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 20
-------
Operations and
Pciinterisince
Project Level
Reviews:
A review is performed at the end of the Acquisition Subphase. The
review ensures that the requirements of the system are identified and
that the feasibility of the system is established. Products of the
Acquisition Subphase are reviewed including the Acquisition Plan and
the requirements specifications. This review is organized, planned, and
led by the System Manager and/or representative. Approval of the
Contract for Services by the Procurement Officer grants approval to
proceed to the Design Subphase.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
-S = Always Required
Work Product
Acquisition Package
Documents allocation of the requirements among development segments,
research and applies lessons learned from previous projects; identifies potential
product and service providers, and secures funding.
Acquisition Strategy
Approvals (Decision Papers) (SMP)
Bidders List
List of eligible and interested bidders, bidding on a contract.
Change Directive
Change Tracking Log
Contract
Document that establishes an offer and consideration for goods and/or services.
Full Security Risk Assessment
Project Plan
Request for Proposal
Solution Architecture
Status
B
U
B
B
^
•/
B
B
U
B
U
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 21
-------
Design
Operations and
flBintertanee
Attachment 2: Acquisition/Development Phase
B. Design Subphase and
Control Gate # 2 - EA Compliance Certification Review
Process
Description:
The objective of the Design Subphase is to transform the detailed,
defined requirements into complete, detailed specifications for the
system that will guide the work of the Development Subphase. The
decisions made in this phase address, in detail, how the system will
meet the defined functional, physical, interface, and data requirements.
Design Subphase 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.
For Commercial Off-the-Shelf (COTS) products, some tasks and
activities may have been performed by the vendor and vendor
documentation may be appropriate to meet some documentation
requirements. This is acceptable as long as each task and activity is
performed and each document is available.
Procedure
Description:
The following tasks are performed during the Design Subphase.
The System Design Document is developed by the System Manager
and project team, identifying the steps used in the design of the
application/system. The prerequisites for this phase are the Business
Case, Project Plan, and Functional Requirements Document (FRD).
The System Manager and project team identify/specify the target
environment, the development environment and the design
environment. The business organization, roles and procedures for
designing this system/application are articulated. The System Design
Document is a work product in the Design Subphase. Documents from
the previous phases are revised during the Design Subphase. The
updates are signed off by the System Manager with significant changes
approved by the System Sponsor and CIO.
In the system design, first the general system characteristics are
defined. The data storage and access for the database layer are
designed. The user interface at the desktop layer is designed. The
business rules layer or the application logic is designed. The interfaces
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 22
-------
Design
Operations and
flBintertanee
from application to application and application to database also are
designed and documented.
A security risk assessment is conducted by addressing the following
components: assets, threats, vulnerabilities, probability of risk
occurence, consequences and safeguards. The risk assessment
evaluates compliance with baseline security requirements, identifies
threats and vulnerabilities, and assesses alternatives for mitigating or
accepting residual risks. A Contingency Plan/COOP is developed
containing emergency response procedures; backup arrangements,
procedures and responsibilities; and post-disaster recovery procedures
and responsibilities. It is included in this phase because many of these
factors will affect the design of the system. The developer obtains the
requirements from the Security Risk Assessment and the FRD and
allocates them to the specific modules within the design for
enforcement purposes. For example, if a requirement exists to audit a
specific set of user actions, the developer may have to add a workflow
module into the design to accomplish the auditing. Security operating
procedures are guidance documents that provide users and
administrators with detailed requirements on how to operate and
maintain the system securely. They should address all applicable
computer and telecommunications security requirements, including:
system access controls; marking, handling, and disposing of magnetic
media and hard copies; computer room access; account creation,
access, protection, and capabilities; operational procedures; audit trail
requirements; configuration management; processing area security;
employee check-out; and emergency procedures. Security operating
procedures may be created as separate documents or added as sections
or appendices to the user and operations manuals. This activity should
be conducted during the Design Subphase.
The system user community is included in Design Subphase actions as
needed. New or further requirements might be discovered that are
necessary to accommodate individuals with disabilities. If so, these
requirements are added to the FRD.
Development of the following system documents is started in this
phase:
• Maintenance Manual: to ensure continued operation of the system
once it is completed. This manual is completed as a work product
in the Development Subphase.
• Operations Manual for mainframe systems/applications and the
System Administrators Manual for client/server
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 23
-------
Design
Operations and
flBintertanee
systems/applications. These manuals are completed as work
products in the Development Subphase.
• Training Plan and the User Manual are begun during the Design
Subphase. This will be completed as a work product in the
Development Subphase.
• Conversion Plan, if current information needs to be
converted/migrated/transitioned to the new system. The Conversion
Plan is needed especially if processes are re- engineered.
• Implementation Plan and Contingency Plan/COOP are designed in
this phase and are work products in the Development Subphase.
• Training Plan outlining the objectives, needs, strategy, and
curriculum to be addressed when training users on the new or
enhanced information system. The plan presents the activities
needed to support the development of training materials,
coordination of training schedules, reservation of personnel and
facilities, planning for training needs, and other training-related
tasks. Training activities are developed to teach user personnel the
use of the system as specified in the training criteria. The Training
Plan includes a description of the target audience and topics on
which training must be conducted on the list of training needs. It
includes 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.
The decisions of this phase re-examine in greater detail many of the
parameters addressed in previous phases. The design prepared in this
phase is the basis for the activities of the Development Subphase. The
overall objective is to establish a complete design for the system. A
number of project approach, project execution, and project continuation
decisions are made in this phase.
Project approach decisions include:
• Identification of existing or COTS components that can be
used, or economically modified, to satisfy validated
functional requirements
• Use of appropriate prototyping to refine requirements and
enhance user and developer understanding and
interpretation of requirements
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 24
-------
Design
Operations and
flBintertanee
• Selection of specific methodologies and tools to be used
in the later life cycle phases, especially the Development
and Implementation Phases
• Determination of how user support will be provided, how
the remaining life cycle phases will be integrated, and
newly identified risks and issues handled
Project execution decisions include:
• Modifications that must be made to the initial information
system
• Modifications that will be made to current procedures
• Modifications that will be made to current
systems/databases or to other systems/databases under
development
• How conversion of existing data will occur
Project continuation decisions include:
• The continued need for the information system to exist
• The continued development activities based on the needs
addressed by the design
• Availability of sufficient funding and other required
resources for the remainder of the system's life cycle
There is an ongoing interim review of the system design as it evolves
through the Design Subphase. Detailed objective system functions,
performance requirements, security requirements, and system platform
characteristics are reviewed. The System Manager conducts the final
design review with approval or disapproval by the SIO and the System
Sponsor. This review is conducted as the end of the Design Subphase
and confirms that modifications prompted by earlier reviews are
incorporated.
Responsibilities:
System Manager: The System Manager is responsible and
accountable for the successful execution of the Design Subphase. The
System Manager is responsible for leading the team that accomplishes
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 25
-------
Design
Operations and
flBintertanee
the tasks shown above.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Procurement Officer: The Procurement Officer is responsible and
accountable for preparing solicitation documents under the guidance of
the program manager.
Oversight Stakeholders: The oversight stakeholders provide oversight,
advice and counsel to the System Manager on the conduct and
requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations to
the EPA decision makers during project reviews and in support of
project decision milestones.
Chief Architect: The Chief Architect is responsible for certifying EA
compliance of the Solution Architecture to complete Control Gate #2.
System Sponsor: The System Sponsor participates in the final design
review and gives approval or disapproval with the SIO.
Senior Information Official (SIO): The SIO participates in the final
design review and gives approval or disapproval with the System
Sponsor.
Gate 2 - EA The purpose of the EA Compliance Certification Review is to Ensure
COMPLIANCE the system's design conforms to the planned Solution Architecture and
CERTIFICATION continues to address the business need while remaining in alignment
REVIEW: with the Agency EA.
The EA Compliance Certification Review is conducted by the Chief
Architect who is responsible for certifying that Solution Architectures
are compliant with the Enterprise Architecture. The SIO or designee
conducts the EA Compliance Certification Review and certifies
architecture compliance for non-major and small or other systems. The
Solution Architecture is certified as architecturally compliant prior to
project development unless the appropriate waiver is obtained.
During the Control Gate #2 Review, all Acquisition and Design
Subphase required work products must be complete, approved, and
verified to satisfy the Control Gate requirement.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 26
-------
Design
Operations and
flBintertanee
Joint Management
Reviews:
Joint management reviews are required when the project is being
managed and/or funded by multiple offices. The determination of who
should participate in joint management reviews is made during the
initial tailoring process. Joint management reviews for both
requirements and design are held during the Design Subphase. Prior to
the design reviews, the acquirer shall have reviewed the work products
initiated, updated, or completed during the Design Subphase.
System/subsystem and software requirements reviews are held at the
beginning of the Design Subphase to resolve open issues regarding the
specified requirements for a software system or subsystem.
A system/subsystem design review is held at the end of the Design
Subphase to resolve open issues regarding any of the following:
• The system-wide or sub system-wide design decisions
• The architectural design of a software system or
subsystem
A software design review is held at the end of the Design Subphase to
resolve open issues regarding one or more of the following:
• The software-wide design decisions
• The architectural design of a software item
• The detailed design of a software item or portion thereof
(such as a database)
Upon completion of all Design Subphase tasks and receipt of resources
for the next phase, the System Manager, together with the project team
should prepare and present a project status review for the SIO, System
Sponsor, and other stakeholders. The review should address:
• Design Subphase required work products, which must be
complete, approved, and verified
• Planning status for all subsequent life cycle phases (with
significant detail on the next phase, to include the status of
pending contract actions)
• Resource availability status
Acquisition risk assessments of subsequent life cycle phases given the
planned acquisition strategy.
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 27
-------
Design
Operations and
flBintertanee
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Application Deployment Checklist (SMP)
Approvals (Decision Papers) (SMP)
Change Directive
Change Tracking Log
Contingency Plan/COOP
Contains emergency response procedures; backup arrangements, procedures,
and responsibilities; and post-disaster recovery procedures and responsibilities.
Contingency planning is essential to ensure that systems are able to recover from
processing disruptions in the event of localized emergencies or large-scale
disasters. It is an emergency response plan, developed in conjunction with
application owners and maintained at the primary and backup computer
installation to ensure that a reasonable continuity of support is provided if events
occur that could prevent normal operations.
Data Conversion Plan
Describes the strategies involved in converting data from an existing system to
another hardware or software environment. It is appropriate to re-examine the
original system's functional requirements for the condition of the system before
conversion to determine if the original requirements are still valid.
Functional Requirements Document
Hardware Requirements Specification
Interface Requirements Specification
Maintenance 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.
Operations Manual
Provides system administrators/computer control personnel/computer operators
with a detailed operational description of the information system and its
associated environments, such as machine room operations and procedures.
Project Plan
Requirements Traceability Matrix
Graphically depicts the relationship between requirements, design modules, and
tests used to establish that all requirements have been addressed within the system
and that the tests planned for the system will both test all of the components and
demonstrate that the requirements have been met.
Solution Architecture
Status
B
B
V
S
B
B
U
U
U
D
D
U
B
U
System Life Cycle Management Guidance - DPvAFT - Not for Distribution
Updated: 1/10/07
Page 28
-------
Design
Operations and
flBintertanee
Work Product
Status
System Design Document
Describes the system requirements, operating environment, system and
subsystem architecture, files and database design, input formats, output layouts,
human-machine interface, detailed design, processing logic, and external
interfaces. It is used in conjunction with the Functional Requirements
Document, which is finalized in this phase, to provide a complete system
specification of all user requirements for the system and reflects the user's
perspective of the system design. Will include Database Models -
Logical/Physical and Physical Network Topologies - Logical/Physical
B
System Implementation Plan (SMP)
Describes how the information system will be 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.
D
System Test Plan (SMP)
B
User Manual
Contains all essential information for the user to make full use of the
information system. This manual includes a description of the system functions
and capabilities, contingencies and alternate modes of operation, and step-by-
step procedures for system access and use.
D
User Training Plan
Outlines the objectives, needs, strategy, and curriculum to be addressed when
training users on the new or enhanced information system. The plan presents
the activities needed to support the development of training materials,
coordination of training schedules, reservation of personnel and facilities,
planning for training needs, and other training-related tasks.
D
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 29
-------
Development
Attachment 2: Acquisition/Development Phase
C. Development Subphase
Process
Description:
The objective of the Development Subphase is to convert the work
products of the Design Subphase into a complete information system.
Although much of the activity in the Development Subphase
addresses the computer programs that make up the system, this phase
also puts in place the hardware, software, and communications
environment for the system and other important elements of the
overall system.
The activities of this phase translate the system design produced in the
Design Subphase into a working information system capable of
addressing the information system requirements. The Development
Subphase contains activities for integration and installation and
acceptance related to software products. At the end of this phase, the
system is ready for the activities of the Test Subphase.
For COTS products, some tasks and activities may have been
performed by the developer and developer documentation may be
appropriate to meet some documentation requirements. This is
acceptable as long as each task and activity is performed and each
document is available.
Procedure
Description:
This activity consists of several tasks that are the responsibility of the
developer. The developer places the outputs under configuration
control and performs change control. The developer also documents
and resolves problems and non-conformances found in the software
products and tasks.
The developer selects, tailors, and uses those standards, methods,
tools, and computer programming languages that are documented,
appropriate, and established by the organization for performing the
activities in the Development Subphase.
Plans for conducting the activities of the Development Subphase are
developed, documented and executed. The plans include specific
standards, methods, tools, actions, and responsibility associated with
the development and qualification of all requirements including safety
and security. Separate plans may be developed. The detailed project
Work Breakdown Structure (WBS) developed during the Planning
Subphase should be expanded to incorporate the WBS structure into
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 30
-------
Development
each module or software configuration item to be developed.
Responsibilities:
System Manager: The System Manager is responsible and
accountable for the successful execution of the Development
Subphase. The System Manager is responsible for leading the team
that accomplishes the tasks shown above.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Procurement Officer: The Procurement Officer is responsible and
accountable for preparing solicitation documents under the guidance
of the program manager.
Oversight Stakeholders: The oversight stakeholders provide
oversight, advice and counsel to the System Manager on the conduct
and requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations
to the EPA decision makers during project reviews and in support of
project decision milestones.
Project Level
Reviews:
Upon completion of all Development Subphase tasks and receipt of
resources for the next phase, the System Manager, together with the
project team prepares and presents a project status review for the
SIO, Program Sponsor, and other stakeholders. The review should
address:
Development subphase activities status
Planning status for all subsequent life cycle phases (with
significant detail on the next subphase, to include the
status of pending contract actions)
Resource availability status
Acquisition risk assessments of subsequent life cycle
phases given the planned acquisition strategy
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 31
-------
Development
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Acquisition Package
Application Deployment Checklist
Change Directive
Change Tracking Log
Contingency Plan/COOP
Data Conversion Plan
Hardware Requirements Specification
Integration Document
Explains how the software components, hardware components, or both are
combined and the interaction between them.
Maintenance Manual
Operations Manual
Project Plan
Requirements Traceability Matrix
System Design Document
Security Risk Assessment
Software Development Document
Contains documentation pertaining to the development of each unit or module,
including the test cases, software, test results, approvals, and any other items
that will help explain the functionality of the software.
Solution Architecture
System (Application) Software
Entails the disks (or other media) used to store the application software used for
the Test Phase and finalized in this phase before implementation of the system.
System Implementation Plan
System Modules (Code, Test, Implementation, and Operational)
Includes development units such as the source code modules, object code
modules, load modules, and job control streams developed to automate the
required business functions. Although these modules are not typically
documents but files that reside on the developed system, source code and job
control listings can be printed and included in system documentation for each
unit / module.
System Security Plan
System Test Plan
Status
U
U
s
s
U
U
U
B
B
B
U
U
U
U
B
U
D
U
D
B
U
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 32
-------
Development I Test
Work Product
Test Analysis Report
Documents the formal documentation of the software testing.
Test Files / Data
Provide the actual test data and files used for system testing.
User Manual
User Training Plan
Status
B
B
B
B
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 33
-------
Attachment 2: Acquisition/Development Phase
C. Test Subphase and
Control Gate # 3 - Authorization to Operate
Process
Description:
The objective of the Test Subphase is to prove that the developed system
satisfies the requirements defined in the Functional Requirements
Document (FRD). Another purpose is to perform an integrated system
test function as specified by the design parameters. This function is the
responsibility of the system testers and heavily supported by the user
participants.
Prerequisites of this phase are the FRD, project management plan and
schedule, system baseline software and documents, and a test plan
containing all test requirements and schedules.
Several types of tests are conducted in this phase. First, subsystem
integration tests are executed and evaluated by the development team to
prove that the program components integrate properly into the
subsystems and that the subsystems integrate properly into an
application. Next, the testing team conducts and evaluates system tests
to ensure the developed system meets all technical requirements,
including performance requirements. Next, the testing team and the
Security Manager conduct security tests to validate that the access and
data security requirements are met. Finally, users participate in
acceptance testing to confirm that the developed system meets all user
requirements as stated in the FRD. Acceptance testing is performed in a
simulated "real" user environment with the users using simulated or real
target platforms and infrastructures.
Procedure
Description:
The following tasks are completed during the Test Subphase.
The test and evaluation team is responsible for establishing the test team
and creating the Test Files/Data.
The test and evaluation team is responsible for creating/loading the test
database(s) and executing the system test(s). All results are documented
on the Test Analysis Report, Test Problem Report, and on the Test
Analysis Approval Determination. Any failed components are migrated
back to the Development Subphase for rework, and the passed
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 34
-------
components migrated ahead for security testing.
The test and evaluation team create or load the test database(s) and
execute security (penetration) test(s). All tests are documented, similar
to those above. Failed components are migrated back to the
Development Subphase for rework, and passed components will be
migrated ahead for acceptance testing.
The test and evaluation team create/load the test database(s) and execute
the acceptance test(s). All tests are documented similar to those above.
Failed components are migrated back to the Development subphase for
rework, and passed components migrate ahead for implementation.
During this phase, the documentation from all previous phases is
finalized to align it with the delivered system. The System Manager
coordinates these update activities and is responsible for ensuring that
the functionality of the systems meets all quality requirements specified
in the Quality Assurance Plan.
Responsibilities:
System Manager: The System Manager is responsible and accountable
for the successful execution of the Test subphase. The System Manager
is responsible for leading the team that accomplishes the tasks shown
above.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Oversight Stakeholders: The oversight stakeholders provide oversight,
advice and counsel to the System Manager on the conduct and
requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations to
the EPA decision makers during project reviews and in support of
project decision milestones.
Gate 3 -
AUTHORIZ-
ATION TO
OPERATE:
The purpose of the Authorization to Operate Review is to ensure that
the system is ready to move into an operational state.
The Authorization to Operate Review is conducted by the designated
approving authority, who uses the certification package to make a
determination as to the appropriateness of allowing the system to
function. The system must be accredited for operations prior to the
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 3 5
-------
system being moved into an operational state. The approving authority
can provide full authorization to operate or denial of authorization to
operate.
Upon completion of all integration and the Test Subphase tasks and the
receipt of resources for the next phase, the System Manager, together
with the project team prepares and presents a project status review for
the SIO, System Sponsor, and other stakeholders. The review should
address:
• Test Subphase required work products, which must be
complete, approved, and verified
• Planning status for all subsequent life cycle phases (with
significant detail on the next phase, to include the status of
pending contract actions)
• Resource availability status
• Acquisition risk assessments of subsequent life cycle phases
given the planned acquisition strategy
• Completion of quality assurance and quality control
activities for this phase
The final statement of Authorization to Operate is issued by the
Information Management Officer. (IMO)
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
-S = Always Required
Work Product
Change Directive
Change Tracking Log
Project Plan
Solution Architecture
System Implementation Plan
Status
^
^
U
U
U
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 36
-------
System Modules (Code, Test, Implementation, and Operational)
System Test Plan
Test Analysis Approval Determination
Summary of the perceived readiness for migration of the software; attached to
the Test Analysis Report as a final result of the test reviews and testing levels
above the integration test.
Test Analysis Report
Test Problem Report
U
U
B
B
S
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 37
-------
Implementation
Attachment 3: Implementation Phase
Process
Description:
In the Implementation Phase., the system or system modifications are
installed and made operational in a production environment. The phase
is initiated after the system has been tested and accepted by the user.
Activities in this phase include notification of implementation to end
users, execution of the previously defined training plan, data entry or
conversion, completion of security certification and accreditation and
post implementation evaluation. This phase continues until the system
is operating in production in accordance with the defined user
requirements.
The new system being implemented can fall into three categories:
replacement of a manual process, replacement of a legacy system, or
upgrade to an existing system Regardless of the type of system, all
aspects of the implementation phase should be followed. This
ensures the smoothest possible transition to the organization's desired
goal.
Procedure
Description:
The following activities are performed as part of the Implementation
Phase. A description of these tasks and activities is provided below.
The implementation notice is sent to all users and organizations affected
by the implementation. Additionally, it is good policy to make internal
organizations not directly affected by the implementation aware of the
schedule so that allowances can be made for a disruption in the normal
activities of that section. The notice should include:
• The schedule of the implementation
• A brief synopsis of the benefits of the new system
• The difference between the old and new system
• Responsibilities of end user affected by the implementation
during this phase
• The process to obtain system support, including contact names
and phone numbers
Typically, implementation includes converting existing data for use in
the new system. The tasks for this effort are two-fold: data input and
data verification. When replacing a manual system, hard copy data is
entered into the automated system. Some sort of verification that the
data is being entered correctly should be conducted throughout this
process. This is also the case in data transfer, where data fields in the
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 3 8
-------
Implementation
old system may have been entered inconsistently and therefore affect the
integrity of the new database. Verification of the old data becomes
imperative to a useful computer system.
One of the ways verification of both system operation and data integrity
can be accomplished is through parallel operations. Parallel operations
consist of running the old process or system and the new system
simultaneously until the new system is certified. In this way if the new
system fails in any way, the operation can proceed on the old system
while the bugs are worked out.
To ensure that the system is fully operational, install the system in a
production environment.
After the system has been fielded, a post-implementation evaluation is
conducted to determine the success of the project through its
implementation phase. The purpose of this evaluation is to document
implementation experiences to recommend system enhancements and
provide guidance for future projects.
In addition, Change Implementation Notices are utilized to document
user requests for fixes to problems that may have been recognized
during this phase. It is important to document any user request for a
change to a system to limit misunderstandings between the end user and
the system programmers.
During this phase, the documentation from all previous phases is
finalized to align it with the delivered system. The System Manager
coordinates these update activities.
Responsibilities: System Manager: The System Manager is responsible and accountable
for the successful execution of the Implementation Phase. The System
Manager is responsible for leading the team that accomplishes the tasks
shown above and finalizing all of the documentation from previous
phases.
Project Team: The project team members (regardless of the
organization of permanent assignment) are responsible for
accomplishing assigned tasks as directed by the System Manager.
Oversight Stakeholders: The oversight stakeholders provide oversight,
advice and counsel to the System Manager on the conduct and
requirements of the planning effort. Additionally, oversight
stakeholders provide information, judgments, and recommendations to
the EPA decision makers during project reviews and in support of
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 3 9
Updated: 1/10/07
-------
Project Level
Reviews:
Implementation
project decision milestones.
A post-implementation review is conducted to ensure that the system
functions as planned and expected; to verify that the system cost is
within the estimated amount; and to verify that the intended benefits are
derived as projected. Normally, this is a one-time review, and it occurs
after a major implementation; it may also occur after a major
enhancement to the system. The results of an unacceptable review are
submitted to the SIO for review and follow-up actions. The SIO may
decide it is necessary to return the deficient system to the responsible
system development System Manager for correction of deficiencies.
During the Implementation Phase review, recommendations may be
made to correct errors, improve user satisfaction or improve system
performance. For contractor development, analysis is performed to
determine if additional activity is within the scope of the statement of
work or within the original contract.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
•S = Always Required
Work Product
Acquisition Package
Application Deployment Checklist
Approvals (Decision Papers)
Authorization to Operate
The official management decision given by a senior agency official to
authorize operation of an information system and to explicitly accept the
risk to agency operations (including mission, functions, image, or
reputation), agency assets, or individuals, based on the implementation of
an agreed-upon set of security controls. Also referred to as Authorization
to Process or Accreditation. Addressed during Control Gate #3.
Change Directive
Change Implementation Notice
Documents a formal request and approval document for changes made
during the Implementation Phase.
Change Tracking Log
Post Implementation Review Report
Documents the review that is conducted to ensure that the system functions
Status
U
U
B
B
^
B
^
B
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 40
-------
Implementation
Work Product
as planned and expected, to verify that the system cost is within the
estimated amount, and to verify that the intended benefits are derived as
projected. This report is created at the end of the fmplementation Phase.
Project Plan
Security Certification and Accreditation
Certification results in a security assessment report that results in findings
and recommendations. These are used to revise and approve the security
plan any develop any Plans of Action and Milestones (POA&Ms) to correct
deficiencies. The approved security plan, security assessment report and
POA&Ms are components of an Accreditation package. From this the
approving authority will develop the "Accreditation" which contains their
decision to accredit, decision rationale and any terms and conditions. The
term "No accreditation" signifies identified deficiencies must be corrected
before the system can move to production/implementation, interim
accreditation allows for implementation based on mission exigencies and
risk acceptance, but does not consider the system accredited for purposes of
OMB reporting. Full accreditation allows for implementation in the
production environment. There may be POA&Ms that must be fulfilled,
but these do not represent a significant security risk, (see NIST SP 800-37
for further details). The Security Accreditation Package includes the
Certifier's Statement.
Solution Architecture
System Modules (Code, Test, Implementation, and Operational)
Version Description Document
Serves as the primary configuration control document used to track and
control versions of software released to the operational environment. It is a
summary of the features and contents for the software development, and
identifies and describes the version of the software to be delivered.
Status
U
B
U
B
B
System Life Cycle Management Guidance - DPxAFT - Not for Distribution
Updated: 1/10/07
Page 41
-------
Operations and
Maintenance
Attachment 4: Operations & Maintenance Phase
Control Gate # 4 — Modify or Terminate
Process
Description:
More than half of the life cycle cost of a system can be attributed to its
operation and maintenance. In this phase, it is essential that all facets of
operation and maintenance are performed. The system is being used and
scrutinized to ensure that it meets the needs initially defined during
planning. Problems may be detected and new needs arise that may
require modification to existing code, new code to be developed, and/or
hardware configuration changes. Providing user support such as
providing training to new users is an ongoing activity. The emphasis of
this phase is to ensure that the users' needs are met and the system
continues to perform as specified in the operational environment.
Additionally, as operations and maintenance personnel monitor the
current system, they may become aware of ways to improve the system
and therefore make recommendations. Changes will be required to fix
problems, possibly add features, and make improvements to the system.
This phase continues for as long as the system is in use.
Procedure Operations support is an integral part of the day-to-day operation of a
Description: system. In small systems, all or part of each task may be done by the
same person. But in large systems, each function may be done by
separate individuals or even separate areas. The Operations Manual was
developed in previous phases. This document defines tasks, activities,
and responsible parties and needs to be updated as changes occur.
Systems operations activities and tasks need to be scheduled, on a
recurring basis, to ensure that the production environment is fully
functional and is performing as specified. The following is a checklist of
systems operations key tasks and activities:
• Ensure that systems and networks are running and available
during the defined hours of operation
• Ensure all processes, manual and automated, are documented
in the operating procedures. These processes should comply
with the system documentation
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 42
-------
Operations and
Maintenance
• Acquisition and storage of supplies, e.g., paper, toner, tapes,
removable disks
• Perform and test backups (day-to-day protection,
contingency)
• Perform the physical security functions including ensuring
adequate uninterruptible power supply and ensuring that
personnel have proper clearances and proper access
privileges, etc.
• Ensure contingency planning for disaster recovery is current,
tested, and funded according to the Contingency Plan/COOP
• Ensure users are trained on current processes and new
processes. Provide periodic refresher training and ensure
funding
• Ensure that service level objectives are kept accurate and are
monitored
• Maintain performance measurements, statistics, and system
logs. Examples of performance measures include volume and
frequency of data to be processed in each mode, order and
type of operations
• Monitor security controls and performance statistics, report
the results, and escalate problems when they occur
Data/software administration is needed to ensure that input data and
output data and databases are correct and continually checked for
accuracy and completeness. This includes ensuring that any regularly
scheduled jobs are submitted and completed correctly. Software and
databases should be maintained at (or near) the current maintenance
level. The backup and recovery processes for databases are normally
different than the day-to-day data/software administration volume
backups. The backup and recovery process of the databases should be
performed as a data/software administration task. A checklist of
data/software administration tasks and activities includes the following:
• Performing production control and quality control functions
(job submission, checking and corrections)
• Interfacing with other functional areas for day-to-day
checking/corrections
• Installing, configuring, upgrading and maintaining
database(s). This includes updating processes, data flows, and
objects (usually shown in diagrams)
• Developing and performing data/database backup and
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 43
Updated: 1/10/07
-------
Operations and
Maintenance
recovery routines for data integrity and recoverability
• Ensuring all processes are properly documented properly in
the Operations Manual
• Developing and maintaining a performance plan for online
process and databases
• Performing configuration, security and design reviews/audits
to ensure software, system, parameter, and configuration are
correct
• Perform patching of software for the system if and when
required
• Manage and control configuration and changes to the system
One fact of life with any system is that change is inevitable. Users need
an avenue to suggest changes and identified problems. A User
Satisfaction Review which can include a Customer Satisfaction Survey
can be designed and distributed to obtain feedback on operational
systems to help determine if the systems are accurate and reliable.
Systems administrators and operators need to be able to make
recommendations for upgrades to hardware, architecture and
streamlining processes. For small in-house systems, modification
requests can be handled by an in-house process. For large integrated
systems, modification requests may be addressed in the requirements
document and may take the form of a change package or a formal
Change Implementation Notice and may require justification and cost
benefits analysis for approval by a review board. The requirements
document for the project may call for a modification cut-off and rollout
of the system as a first version and all subsequent changes addressed as a
new or enhanced version of the system. A request for modifications to a
system may also generate a new project and require a new project
initiation plan.
Daily operations of the system/software may necessitate that
maintenance personnel identify potential modifications needed to ensure
that the system continues to operate as intended and produces quality
data. Daily maintenance activities for the system must take place to
ensure that any previously undetected errors are fixed. Maintenance
personnel may determine that modifications to the system and databases
are needed to resolve errors or performance problems. Also,
modifications may be needed to provide new capabilities or to take
advantage of hardware upgrades or new releases of system software and
application software used to operate the system. New capabilities may
take the form of routine maintenance or may constitute enhancements to
the system or database as a response to user requests for new/improved
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 44
Updated: 1/10/07
-------
Operations and
Maintenance
capabilities. New capability needs may begin a new problem
modification process described above.
At the beginning of this phase any outstanding security-related Plans of
Action and Milestones (POA&Ms) must be completed. Throughout the
phase, continuous security monitoring of selected controls must be
conducted. In addition, periodic reviews of controls, periodic re-
evaluation of information categorization and re-certifications and
revision of risk assessments and security plans, and re-certification and
re-authorizations to process (re-accreditation) are conducted as required.
Because systems undergo periodic maintenance, enhancements and
improvement, mini life cycles may be required throughout this stage.
Continuous vigilance should be given to virus and intruder detection.
The System Manager must be sure that security operating procedures are
kept updated accordingly.
Review and update system documentation including the operations from
the previous phases. In particular, the Operations Manual, Business
Case, and Contingency Plan/COOP (including results of tests during this
phase), as required, need to be updated and finalized during the
Operations and Maintenance Phase. The System Manager must report
on any security incidents related to the system during this phase.
Responsibilities: System Manager: The System Manager develops documents and
executes plans and procedures for conducting activities and tasks of the
maintenance period and conducts quality assurance activities on those
documents. To provide for an avenue of problem reporting and customer
satisfaction, the Systems Manager should create and discuss
communications instructions with the systems customers. Systems
Managers should keep the Help Desk personnel informed of all changes
to the system especially those requiring new instructions to users, and
must report on all security incidents.
Technical Support: Personnel which provide technical support to the
program. This support may involve granting access rights to the
program, setup of workstations or terminals to access the system, and
maintenance of the operating system for both server and workstation.
Technical support personnel may be involved with issuing user IDs or
login names and passwords. In a client-server environment, technical
support may perform systems scheduled backups and operating system
maintenance during downtime.
Vendor Support: The technical support and maintenance on some
programs are provided through vendor support. A contract is established
outlining the contracted systems administration, operators, and
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 45
Updated: 1/10/07
-------
Operations and
Maintenance
maintenance personnel duties and responsibilities. One responsibility
which should be included in the contract is that all changes to the system
will be thoroughly documented.
Help Desk: Help Desk personnel provide the day-to-day users help for
the system. Help desk personnel should be kept informed of all changes
or modifications to the system. Help Desk personnel are contacted by
the user when questions or problems occur with the daily operations of
the system. Help Desk personnel need to maintain a level of proficiency
with the system.
Operations or Operators (turn on/off systems, start tasks, backup
etc): For many mainframe systems, an operator provides technical
support for a program. The operator performs scheduled backup,
performs maintenance during downtime and is responsible to ensure the
system is online and available for users. Operators may be involved
with issuing user IDs or login names and passwords for the system.
Customers: The customer needs to be able to share with the systems
manager the need for improvements or the existence of problems. Some
users live with a situation or problem because they feel they must.
Customers may feel that change will be slow or disruptive. Some feel
the need to create work-arounds. A customer has the responsibility to
report problems or make recommendations for changes to a system.
Program Analysts or Programmer: Interprets user requirements,
designs and writes the code for specialized programs. User changes,
improvements, enhancements may be discussed in Joint Application
Design sessions. Analyzes programs for errors, debugs the program and
tests program design.
Process Improvement Review Board: A board of individuals may be
convened to approve recommendations for changes and improvements to
the system. This group may be chartered. The charter should outline
what should be brought before the group for consideration and approval.
The board may issue a Change Directive.
Users Group or Team: A group of computer users who share
knowledge they have gained concerning a program or system. They
usually meet to exchange information, share programs and can provide
expert knowledge for a system under consideration for change.
Contract Manager: The Contract Manager has many responsibilities
when a contract has been awarded for maintenance of a program. The
Contract Manager should have a certificate of training for completion of
a Contracting Officer's Technical Representative (COTR) course. The
Contract Manager's main role is to make sure that the interests of the
Procurement Office are protected and that no modifications are made to
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 46
Updated: 1/10/07
-------
Operations and
Maintenance
the contract without permission from the Procurement Office.
Data Administrator: Performs tasks which ensure that accurate and
valid data are entered into the system. Sometimes this person creates the
information systems database, maintains the databases security and
develops plans for disaster recovery. The data administrator may be
called upon to create queries and reports for a variety of user requests.
The data administrator responsibilities include maintaining the databases
data dictionary. The data dictionary provides a description of each field
in the database, the field characteristics and what data is maintained with
the field.
Telecommunications Analyst and Network System Analyst: Plans,
installs, configures, upgrades, and maintains networks as needed. If the
system requires it, they ensure that external communications and
connectivity are available.
Information Security Officer (ISO): The ISO has a requirement to
review system change requests, review and in some cases coordinate the
Change Impact Assessments, participate in the Configuration Control
Board process, and conduct and report changes that may be made that
affect the security posture of the system. The ISO is also responsible for
ensuring that all POA&Ms are tracked appropriately.
Gate 4 -
MODIFY OR
TERMINATE
REVIEW:
The purpose of the Modify or Terminate Review is to determine if the IT
Investment should continue, be modified or terminated.
The Modify or Terminate Review is coordinated by OEI, who ensures the
IT Investment Business Case is accurate and complete. The package is
then forwarded to the QIC, who relies on the IIS to provide a through
Business Case review in accordance with the EPA's CPIC Evaluation
Phase criteria, determining if it can optimally continue to support
mission/user requirements and the EPA's strategic direction. The IIS
develops recommendations for the QIC to make a decision on whether to
keep this investment as part of the EPA's IT Investment Portfolio as is,
modify or terminate the investment.
Review activities occur several times throughout this phase. Each time
the system is reviewed, one of three of the following decisions will be
made:
• The system is operating as intended and meeting
performance expectations
• The system is not operating as intended and needs
corrections or modifications
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 47
-------
Operations and
Maintenance
• The users are/are not satisfied with the operation and
performance of the system
During the Control Gate #4 Review, all Implementation and Operations
& Maintenance Phase required work products must be complete,
approved, and verified to satisfy the Control Gate requirement.
The In-Process Reviews (conducted at least annually) are conducted in
this phase. An In-Process Review is performed to evaluate system
performance, user satisfaction with the system, adaptability to changing
business needs, and new technologies that might improve the system.
This review is diagnostic in nature and can lead to development or
maintenance activities. Any major system modifications needed after the
system has been implemented follow the life cycle process from planning
through implementation. A project management plan, including a
feasibility study, is developed to identify modifications to existing
system documentation (change pages) rather than new system
documentation (for example, a functional requirements document, a
system design document, etc.). The appropriate reviews and testing are
conducted based on the scope of the modification.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
-S = Always Required
Work Product
Acquisition Strategy
Change Control
Depending on the type and magnitude of changes made during O&M,
modifications to the system may have to cycle through some or all of the
development phases with attention paid to the security requirements and impacts
of the required changes.
Change Directive
Change Tracking Log
Cost-Benefit Analysis
Functional Requirements Document
Hardware Requirements Specification
Status
U
U
^
^
U
U
U
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 48
-------
Operations and
Maintenance
Work Product
In-Process Review
Documents the In-Process Review which occurs at predetermined milestones;
usually quarterly, but at least once a year. The performance measure should be
reviewed along with the health of the system. Performance measures should be
measured against the baseline measures. Ad hoc reviews should be performed
when deemed to be necessary.
Project Plan
Re-Certification and Re-Accreditation
Records Management Disposition Schedule
Requirements Traceability Matrix
Solution Architecture
System Design Document
System Modules (Code, Test, Implementation, and Operational)
User Satisfaction Review
Documents User Satisfaction Reviews which can be used as a tool to determine
the need to proceed with a Process Improvement Review Board meeting or
initiate a proposal for a new system. This review can be used as input to the In-
Process Review
Status
B
U
B
U
U
U
U
U
B
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 49
-------
Termination (Retirement)
Attachment 5: Termination Phase
Process Description:
Procedure
Description:
The Termination Phase is implemented to either eliminate a large part
of a system or, in most cases, close down a system and end the life
cycle process. At this point, the system has been declared surplus
and/or obsolete and will be scheduled for retirement and shutdown.
The emphasis of this phase is to ensure that data, procedures, and
documentation are packaged and archived in an orderly fashion, making
it possible to reinstall and bring the system back to an operational
status, if necessary, and to retain all data records in accordance with
policies regarding retention of electronic records. The Termination
Phase represents the end of a system's life cycle. A Retirement Plan is
prepared to address all facets of archiving, transferring, and disposing
of the system and data. Particular emphasis is given to proper
preservation of the data processed by the system do that it is effectively
migrated to another system or archived in accordance with applicable
records management regulations and policies for potential future access.
The system retirement activities preserve information not only about the
current production system but also about the evolution of the system
through its life cycle.
The objectives for all tasks identified in this phase are to retire the
system, software, hardware and data. The tasks and activities actually
performed are dependent on the nature of the project. The retirement
activities are performed at the end of the systems life cycle. The
retirement activities ensure the orderly retirement of the system and
preserve vital information about the system so that some or all of it may
be reactivated in the future if necessary. These activities may be
expanded, combined or deleted, depending on the size of the system.
The Retirement Plan must be developed and implemented. The
Retirement Plan identifies how the retirement of the system/data will be
conducted, and when, as well as the system retirement date, software
components to be preserved, data to be preserved, retirement of
remaining equipment, and archiving of life cycle products.
The data from the old system is implemented into the new system or if
it is obsolete, the data is archived.
Similar to the data that is archived or transferred, the software
components will need to be transferred to the new system, or if that is
not feasible, dispositioned appropriately.
The documentation that resulted from the development of the
application or system needs to be archived, where it can be referenced,
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 50
-------
Termination (Retirement)
if needed, at a later date.
Follow the Retirement Plan for the orderly breakdown of the system, its
components and the data within.
If the equipment can be used elsewhere in the organization, it should be
recycled. If it is obsolete, notify the property management/Facilities
Office to dispose of all hardware components.
This review is performed at the end of the Termination Phase and again
within six months after retirement of the system.
Responsibilities: System Manager: Authors the Retirement Plan and ensures that all
aspects of the Retirement Plan are followed. The Retirement Plan
should outline all roles and responsibilities for all actions related to the
close down and archive of the system. Prepares Post-Retirement
Review Report. Ensure that the Retirement Plan is followed.
Technical Support or Vendor Support: The Retirement Plan may
call for the Technical Support Personnel to send system related
hardware to a warehouse or may reassign equipment to a new or
replacement system. Technical Support Personnel or Operators may
perform the cutoff of users' access per instructions from the Security
Manager. Technical Support personnel may assist with the archive of
the Information Systems data. They would perform the actual archive
process.
Data Administrator: The Retirement Plan may direct that only certain
systems data be archived. The Data Administrator would identify the
data and assist technical personnel with the actual archive process. The
Data Administrator may be involved with identifying data which due to
its sensitive nature must be destroyed. They would also be involved
with identifying and migrating data to a new or replacement system.
User Services (Training & Help Desk): User Services includes
training, telecommunications, and Help Desk personnel. The training
component coordinates and schedules the development and delivery of
all training and facilitates the development of systems training methods
and materials. In this phase, User Services may assist with the
retraining of users to facilitate the transfer to a new or replacement
system.
Operations: (turn off systems, start tasks, backup etc) Operations
interfaces with the computer facility that hosts the system being
terminated. This group also schedules, executes, and verifies
production job streams; distributes specified outputs; handles other
production control activities; and maintains and monitors centralized
mainframe database management system software and runtime
environments. It also acquires, maintains, customizes and tunes
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 51
Updated: 1/10/07
-------
Termination (Retirement)
operating system software, assesses the affect of new or changed
systems upon the operational environments, manages system software
capacities, and advises on or arranges accommodation of new
application systems. In this phase, the Operators would assist
Technical Support, the Security Manager, Data Administrators, and the
Quality Manager with the actual archive process.
Program Manager/Analysts: Program Managers need to plan and
schedule a smooth shutdown. They also should be sure that all
documentation is accumulated to be archived with the system.
Customers (User Groups): The user group ensures the active
participation of users at all levels in the definition, design, and
development of a re-engineered automation system for the capture,
processing, tracking, and reporting. The purpose of the user group is to
provide a forum for end users' input, coordination, and validation of
their automation requirements. The group provides a consistent work
force responsible for initiating and resolving issues relating to system
development efforts and expeditiously resolves issues relating to the
identification and documentation of requirements.
Security Managers: The security managers need to make sure that all
access authority has been eliminated for the users. Any users that only
use the application should be removed from the system while others
that use other applications as well as this one may still need access to
the overall system, but not the application being shutdown.
Project Level
Reviews:
The Post-Retirement Review shall be performed after the end of this
final phase. This phase-end review shall be conducted within six
months after retirement of the system and is intended to notify all parties
that the final shut-down of the system has occurred. The Post-Retirement
Review Report also documents the lessons learned from the shutdown
and archiving of the terminated system.
Work Products:
D = Draft: Preliminary version of work product/working copy
B = Baseline: Completed version of work product (with signoff if applicable)
U = Update: Completed version showing changes made to the baseline version
S = Required
Work Product
Approvals (Decision Papers)
Status
B
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 52
-------
Termination (Retirement)
Work Product
Archive/Incorporate Data and Software
The packaged set of data and documentation containing the archived application.
Change Directive
Change Tracking Log
Close-Out Certification
Documents the verification that all procedures and steps were successfully carried out in
the termination of a system
Post Retirement Review Report
Documents the detailed findings of the Termination Phase review. It includes
details of where to find all products and documentation that has been archived.
Retirement Decision Paper
Documents the decision to retire, or terminate the life cycle of, the system.
Retirement Plan
Documents the plan to end the operation of the system in a planned, orderly
manner and to ensure that system components and data are properly archived or
incorporated into other systems. This will include removing the active support by
the operations and maintenance organizations.
Solution Architecture
System Disposition Report
Describes the rationale for ceasing system operations, documents the plan for
ceasing operations and effectively archiving the various components of the
system, including hardware, and provides information about the location of
archived materials. This report is vital to ensure that information about the
system can be accessed to support reactivation of the system, or future reuse of
portions of the current system by other systems.
Transition Plan (as appropriate)
Status
B
S
s
B
B
B
B
U
B
B
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 53
-------
Control Gate Reviews
This section contains information on each of the required Control Gate Reviews. The
descriptions of these reviews as presented here represent the most complete set of requirements
that could be imposed on a system during the SLCM process. Depending on the system's
tailoring methodology, some of these Control Gate requirements may not be applicable.
Further guidance on tailoring your system's SLCM process will be made available in a separate
guidance package which is currently under development.
Gate 1 - EA Compliance Certification and System Selection Review
Purpose
The purpose of the System Selection Review is to approve the IT Investment Business Case for
inclusion in the Agency's IT Investment portfolio. An initial EA Compliance Certification
review is also performed at the Control Gate (see Control Gate 2 for official definition of EA
Compliance Certification).
Scope
The System Selection Review is coordinated by the Office of Environmental Information
(OEI), who ensures the IT Investment Business Case is accurate and complete. The package is
then forwarded to the Quality and Information Council (QIC), who relies on the Information
Investment Subcommittee (IIS) to provide a thorough Business Case review in accordance with
the Agency's CPIC Select Phase criteria. The IIS then forwards its investment recommendation
to the QIC for its final decision.
Work Products
All work products required during the SLCM Definition Phase must be complete, approved,
and verified during the Control Gate 1 review. These products include but are not limited to:
• Business justification for the investment
• Established performance goals and quantifiable performance measures
• Project plan
• Identified costs, schedule, benefits, and risks
• Established security, and architecture goals and measures
• Privacy Impact Assessment
• Solution Architecture
Gate 2 - EA Compliance Certification Review
Purpose
The purpose of the EA Compliance Certification Review is to ensure the system's design
conforms to the planned Solution Architecture and continues to address the business need while
remaining in alignment with the Agency EA.
Scope
The EA Compliance Certification Review will be conducted by the Chief Architect who is
responsible for certifying that Solution Architectures developed for information management
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 54
Updated: 1/10/07
-------
and technology development, modernization, and enhancement, are compliant with the
Enterprise Architecture. The SIO or designee conducts the EA Compliance Certification
Review and certifies architecture compliance for non-major and small or other systems. The
Solution Architectures are certified as architecturally compliant prior to project development
unless the appropriate wavier is obtained.
Work Products
All work products required during the SLCM Acquisition and Design Subphases must be
complete, approved, and verified during the Control Gate 2 review. In addition, s Solution
Architecture which describes how an individual information management system or information
acquisition complies with the requirements of the Target Architecture must be presented.
Gate 3 - Authorization to Operate Review
Purpose
For general support systems and major applications, the Authorization to Operate Review is to
ensure that the system is ready to move into an operational state.
Scope
The details of what is required for this Gate depends on whether the information system is
subject to FISMA as a general support system, major application, or whether it is considered a
minor application residing on a general support system. The Authorization to Operate Review is
conducted by the Information Management Officer (IMO) who uses the certification package to
make a determination as to the appropriateness of allowing the system to function. The system
must be accredited for operations prior to the system being moved into an operational state.
The IMO can provide full authorization to operate or denial of authorization to operate. Minor
applications generally have their security proved as part of the general support system; therefore
each general support system will have application deployment requirements to ensure integrity
of their security and consideration in their maintenance scheme.
Work Products
All work products required during the SLCM Development and Test Subphases must be
complete, approved, and verified during the Control Gate 3 review. In addition, a certification
package including system security plan, security assessment report (risk assessment and system
test and evaluation), and Plan of Action and Milestones (POA&M) must be presented.
Gate 4 - Modify or Terminate Review
Purpose
The purpose of the Modify or Terminate Review is to determine if the IT Investment should
continue, be modified or terminated.
Scope
The Modify or Terminate Review will be coordinated by OEI, who ensures the IT Investment
Business Case is accurate and complete. The package is then forwarded to the QIC, who relies
on the IIS to provide a through Business Case review in accordance with the Agency's CPIC
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 5 5
Updated: 1/10/07
-------
Evaluation Phase criteria, determining if it can optimally continue to support mission/user
requirements and the Agency's strategic direction. The IIS develops recommendations for the
QIC to make a decision on whether to keep this investment as part of the Agency's IT
Investment Portfolio as is, modify or terminate the investment.
Work Products
All work products required during the SLCM Implementation and Operations & Maintenance
Phases must be complete, approved, and verified during the Control Gate 4 review. These
products include but are not limited to:
• Updated Business Case
• Post-Implementation Review (PIR) Results
• Operational Analysis Report
System Life Cycle Management Guidance - DRAFT - Not for Distribution Page 56
Updated: 1/10/07
-------
Supporting Document Checklist for System Life Cycle Management
The following matrix lists potential work products generated during the system life cycle. Work
products in bold must be included for every system and serve as the basis for control gate
reviews. Senior managers must ensure that these work products are properly in place and
approved to manage a system through the life cycle phases. Although products are listed in
sequential order, it is not the intent of this checklist to mandate that all systems follow a
sequential (waterfall) methodology for system development.
SLC Phase
Definition
Work Products
System Categorization
Initiation Decision Paper
Concept Proposal
Change Impact Assessment/Change Directive
IT Project Request
Project Plan
Security Risk Assessment
Change Tracking Log
Si
/stem Management Plan
Mission Need Statement
Solution Architecture
Security Plan
IT Investment Business Case
Business Justification
System Concept Document
Cost-Benefit Analysis
Schedule/Responsibilities
Project Risk Management Plan
Functional Requirements Document
Project Quality Assurance Plan
Configuration Management Plan
Approvals (Decision Papers)
Waivers
Work Breakdown Structure
Application Deployment Checklist
Privacy Impact Assessment
Feasibility Study
Acquisition Strategy
Records Management Disposition Schedule
Concept of Operations
Requirements Specifications (Hardware and Software)
System Engineering Management Plan
Test and Evaluation Master Plan (Baseline)
Acquisition/Development
Development Decision Paper
Acquisition Package
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 57
-------
SLC Phase
Implementation
Work Products
System and Software Design Documents
Requirements Traceability Matrix
Data Conversion Plan
User/System Documentation
System Implementation Plan
User Training Plan
Contingency Plan/COOP
System and Security Test Plan
Software Development Document
Test Files/Data
Integration Document
Test Analysis and Test Problem Report
System (Application) Software
Test Analysis Approval Determination
Certifier's Statement
Implementation Decision Paper
Authorization to Operate
Security Accreditation Package
Delivered System & Modified Software
Change Implementation Notice
Version Description Document
Post Implementation Review Report
Operations & Maintenance
Retirement
Re-Authorization to Operate
Security Configuration Management and Control
In Process Review
User Satisfaction Review
Retirement Decision Paper
Archive/Incorporate Data and Software
System Disposition Report
Retirement Plan
Post Retirement Review Report
[Security] Information Preservation/Media Sanitation
Close-Out Certification
Deactivation Plan
[Security] Hardware and Software Disposal
System Life Cycle Management Guidance - DRAFT - Not for Distribution
Updated: 1/10/07
Page 58
------- |