Peace Corps (SDLC) System Development Lifecycle Handbook

PC-10-R-CP02 Attachment 6
Peace Corps
Systems Development Life Cycle

(SDLC) Handbook
Version 4.2
December 14, 2009

Version 4.2 Executive Summary
Executive Summary
The Peace Corps‘ Systems Development Life cycle (SDLC) Handbook is the definitive
statement of the policies, standards, and life cycle that govern information technology (IT)
systems—including infrastructure—that are built by or for the Peace Corps. This SDLC is based
on the standard SDLC used throughout industry, and has been tailored, where necessary, to meet
the needs of the Peace Corps. This handbook also incorporates best practices from the Software
Engineering Institute‘s (SEI®) Capability Maturity Model® (CMM®).
The SDLC Handbook is a Peace Corps policy that applies to all IT projects and systems
irrespective of agency sponsor, developer, project size/type, methodology, or technology. Some
adjustments and latitude must be taken into consideration when applying the SDLC guidelines to
small project and/or minor enhancements and fixes. This document reflects the Peace Corps‘s
decision to integrate the SDLC with the agency‘s Enterprise Architecture Program and the
Capital Planning and Investment Control (CPIC) process that includes the Investment Review
Board (IRB). This integration allows the agency to manage its IT investments as part of its
Portfolio Management.
All projects—regardless of size or type—must be executed using disciplined engineering
techniques, including clearly defined requirements, appropriate documentation, Quality
Assurance (QA), and approvals. The level of detail and format of deliverables for different size
or types of projects should vary. This handbook provides a tailoring and approval process that
should be sufficient to satisfy SDLC requirements for any size project.
This handbook applies to all Peace Corps work: systems in operation, projects already underway,
and new projects. Through the tailoring and approval process, management of projects already
underway and systems in operation have a mechanism to account for and document SDLC
compliance.
Application to Project Management
The SDLC follows the standard best practices of Project Management. Projects go through five
phases: Initiation, Planning, Development, Validation, and Operations. Overlaid with these
phases, are the SDLC‘s nine stages that define the process of system development, with specific
criteria and policies applicable for each stage.
Projects will use this handbook and devise a Project Plan that covers the stages, and includes
tasks, deliverables, and activities as described in this handbook. Depending on project size,
complexity, visibility, and risk, the activities and deliverables may be combined or expanded. A
library should be established as part of the IT tools repository containing templates, examples,
and procedures that projects will consult in order to take advantage of existing best practices.
Upon management approval, a Project Work Authorization should be issued and the tailored
project plan will become the project‘s SDLC-compliant road map. The Chief Architect team
will assist projects in understanding the SDLC and applying it throughout all IT activities at the
Peace Corps.
Peace Corps i
December 14, 2009
Version 4.2 Acknowledgements
Acknowledgement
The Peace Corps is indebted to the U.S. Customs Service, and in particular, to Mr. S.W. Hall, Jr.,
Assistant Commissioner and Chief Information Officer, Office of Information and Technology
(OIT), and Mr. Guy D. Taylor, Director, OIT Planning Group, for graciously allowing liberal use
and republication of the U.S. Customs Service SDLC Handbook as source material for this initial
Peace Corps SDLC Handbook.
The Peace Corps has drawn heavily from the Customs document for its insight, organization, and
detailed description of the SDLC within the federal government arena. Portions of this Peace
Corps document do not differ in material detail from certain sections, definitions, and
descriptions contained in the U.S. Customs Service document.
Peace Corps 1
December 14, 2009
Version 4.2 Table of Contents
Table of Contents
1. Introduction .................................................................................................................. 1
1.1 Applicability ..................................................................................................................1
1.2 Guidance to Management ..............................................................................................1
1.3 How to Use This Handbook ...........................................................................................2
2. The Peace Corps System Development Life Cycle ................................................... 3

2.1 Project Management Terminology ................................................................................3
2.2 Principles of Peace Corps System Development Life Cycle .........................................4
2.3 Overview of the System Development Life Cycle ........................................................6
2.4 Relationship of SDLC to the Investment Management Process ..................................10
3. Life Cycle Stages – Detailed Description ................................................................. 11

3.1 Stage 1: Concept and Business Case ...........................................................................11
3.1.1 Entry Criteria ................................................................................................11
3.1.2 Inputs.............................................................................................................11
3.1.3 Major Outputs ...............................................................................................11
3.1.4 Exit Criteria ...................................................................................................12
3.2 Stage 2: Initiation and Authorization ...........................................................................13
3.2.1 Entry Criteria ................................................................................................13
3.2.2 Inputs.............................................................................................................13
3.2.3 Major Outputs ...............................................................................................13
3.2.4 Exit Criteria ...................................................................................................13
3.2.5 Tasks and Activities ......................................................................................13
3.3 Stage 3: Project Definition ...........................................................................................14
3.3.1 Entry Criteria ................................................................................................14
3.3.2 Inputs.............................................................................................................14
3.3.3 Outputs ..........................................................................................................14
3.3.4 Exit Criteria ...................................................................................................15
3.4 Stage 4: System Design ...............................................................................................16
3.4.1 Entry Criteria ................................................................................................16
3.4.2 Inputs.............................................................................................................16
3.4.3 Outputs ..........................................................................................................16
3.4.4 Exit Criteria ...................................................................................................17
3.5 Stage 5: Construction ...................................................................................................18
3.5.1 Entry Criteria ................................................................................................18
3.5.2 Inputs.............................................................................................................18
3.5.3 Outputs ..........................................................................................................18
3.5.4 Exit Criteria ...................................................................................................19
Peace Corps 1
December 14, 2009
3.6 Stage 6: Testing and Acceptance .................................................................................21

3.6.1 Entry Criteria ................................................................................................21
3.6.2 Inputs.............................................................................................................21
3.6.3 Outputs ..........................................................................................................21
3.6.4 Exit Criteria...................................................................................................22
3.7 Stage 7: Deployment Readiness...................................................................................23
3.7.1 Entry Criteria ................................................................................................23
3.7.2 Inputs.............................................................................................................23
3.7.3 Outputs ..........................................................................................................24
3.7.4 Exit Criteria ...................................................................................................24
3.8 Stage 8: Operations ......................................................................................................25
3.8.1 Entry Criteria ................................................................................................25
3.8.2 Inputs.............................................................................................................26
3.8.3 Outputs ..........................................................................................................26
3.8.4 Exit Criteria ...................................................................................................26
Stage 9: Disposition/Disposal/Retirement ...............................................................................28
Entry Criteria ...............................................................................................................28
Inputs 28
Outputs 28
Exit Criteria ..................................................................................................................28
Tasks and Activities .....................................................................................................29
Appendix A. Recommended SDLC Policies .................................................................. 30

A.1 Requirements Management Policies ............................................................................30
A.2 Project Planning & Approval .......................................................................................31
A.3 Project Monitoring and Control Policies .....................................................................35
A.4 Quality Assurance Policies ..........................................................................................37
A.5 Configuration Management Policies............................................................................39
A.6 IT Security Requirements in the SDLC .......................................................................42
A.6.1 Introduction to IT SECURITY .....................................................................42
A.6.2 Overview of IT SECURITY in the SDLC ....................................................42
A.6.3 IT Security At Each Stage of the SDLC .......................................................44
A.7 Contract Monitoring Policies .......................................................................................58
Appendix B. Checklists of Key SDLC Policies and Elements ..................................... 60

B.1 Project Reviews ...........................................................................................................60
B.2 Project Roles ................................................................................................................61
B.3 Deliverables .................................................................................................................62
Appendix C. Acronyms ................................................................................................... 66
List of Figures & Tables
System Development Life Cycle (SDLC) - DRAFT 2

December 14, 2009
Figure 1: Overview of Peace Corps SDLC Stages ........................................................................ 9

Figure 2: Relationship of SDLC to Investment Management Process ........................................ 10
Appendix A.6 - Figure 3: IT Security throughout the SDLC ...................................................... 43
Table 1: Stages Terminology ....................................................................................................... 11

Table 2: Stage 1: Concept and Business Case Tasks/Activities .................................................. 12
Table 3: Stage 2: Initiation and Authorization Tasks/Activities .................................................. 13
Table 4: Stage 3: Project Definition Tasks/Activities.................................................................. 15
Table 5: Stage 4: System Design Tasks/Activities ...................................................................... 17
Table 6: Stage 5: Construction Tasks/Activities ......................................................................... 19
Table 7: Stage 6: Testing and Acceptance Tasks/Activities ........................................................ 22
Table 8: Stage 7: Operational Readiness Tasks/Activities .......................................................... 25
Table 9: Stage 8: Operations Tasks/Activities ............................................................................. 27
Table 10: Stage 9: Disposition/Disposal Tasks and Activities .................................................... 29
Appendix A.6 - Table 11: IT Security Tasks and Activities for the Concept and Business Case
Stage ...................................................................................................................................... 44
Appendix A.6 - Table 12: IT Security Tasks and Activities for the Initiation and Authorization
Phase ..................................................................................................................................... 46
Appendix A.6 - Table 13: IT Security Tasks and Activities for the Project Definition Stage .... 47
Appendix A.6 - Table 14: IT Security Tasks and Activities for the System Design Stage ......... 49
Appendix A.6 - Table 15: IT Security Tasks and Activities for the Construction Stage ............ 51
Appendix A.6 - Table 16: IT Security Tasks and Activities for the Testing and Acceptance Stage
............................................................................................................................................... 53
Appendix A.6 - Table 17: IT Security Tasks and Activities for the Deployment Readiness Stage
............................................................................................................................................... 56
Appendix A.6 - Table 18: IT Security Tasks and Activities for Operations Stage ..................... 57
Appendix A.6 - Table 19: IT Security Tasks and Activities for the
Disposition/Disposal/Retirement .......................................................................................... 58
Appendix B.1 - Table 20: Checklist for Project Reviews ............................................................ 60
Appendix B.2 - Table 21: Checklist of Project Roles .................................................................. 61
Appendix B.3 - Table 22: Checklist of Deliverables ................................................................... 62
System Development Life Cycle (SDLC) - DRAFT 3

December 14, 2009
Version 4.2 Introduction
1. Introduction
This Peace Corps Systems Development Life Cycle (SDLC) Handbook presents the policies,
approved life cycle, standards, and high-level processes that govern Information Technology (IT)
systems—including infrastructure—built by or for the Peace Corps. The SDLC defines
management expectations for developing and maintaining Peace Corps IT systems.
This handbook reflects the Peace Corps‘s commitment to adopting and applying the recognized
best practices and disciplined engineering methods represented in the Software Engineering
Institute (SEI®) Systems Engineering Capability Maturity Model® (SE-CMM®).1
1.1 Applicability
This handbook is an instrument of Peace Corps policy for the agency‘s SDLC. It applies to all
Peace Corps IT projects and systems regardless of sponsor, developer, project size, methodology,
or technology used. All staff and contractors involved in developing, maintaining, or
implementing systems or applications for the Peace Corps will become familiar with and follow
the guidance in this handbook.
The policies and life cycle process in this handbook apply equally to large and small projects,
including systems using Commercial Off-The-Shelf (COTS) solutions. All projects, whether
new, already underway, or systems in operation, are subject to the requirements and guidance of
this handbook. Accordingly, all Peace Corps projects must employ disciplined engineering
techniques, including clearly defined requirements, adequate documentation, QA, and approvals.
It is expected that, for projects of different size or type, there will be substantial variance in the
level of detail and format of project deliverables. This handbook provides a tailoring and
approval process that should be sufficient to satisfy SDLC requirements for any size project.
1.2 Guidance to Management

The Chief Architect owns this document, maintains it, and is responsible for bringing all projects
into compliance with this handbook. The Chief Architect will first weigh the costs and benefits,
then determine and document the appropriate level of effort to be expended, for each project
already underway and system in operation to comply with the guidance in this handbook.
Project and system managers will determine which stage of the Peace Corps SDLC governs all
projects already underway and systems in operation and will commence SDLC activities,
reviews, and deliverables from that point forward. All deliverables and reviews (from earlier life
cycle stages) that are necessary precursors to future activities will be completed. Other
deliverables must be completed to the maximum extent practicable.
Through the tailoring and approval process, the Chief Architect has a mechanism to account for
and document SDLC compliance and demonstrates a rationale for the level of effort of projects
1
The Capability Maturity Model: Guidelines for Improving the Software Process, Mark Paulk, et al. Addison-
Wesley Publishing Company, New York, 1995. ISBN: 0-201-54664-7.
Peace Corps 1
December 14, 2009
Version 4.2 Introduction
already underway and systems in operation. This tailoring and approval process is part of Stage
2 of the SDLC, Project Initiation and Authorization.
1.3 How to Use This Handbook

All projects will be governed by the Peace Corps SDLC Policies. The Peace Corps SDLC
described in Section 3 will be used to create a tailored Project Plan for every project. Where
necessary, the Peace Corps EA Core Team (EACT) will actively assist individual projects in
applying the SDLC to create a tailored Project Plan.
The Peace Corps SDLC incorporates all the activities, reviews, and deliverables for projects
from their initiation through their disposal. The document is divided into the following sections:
 Executive Summary – A high level overview of the Peace Corps SDLC purpose and
applicability.
 Section 1. Introduction – An introduction to the SDLC Handbook, its applicability,
organization and use.
 Section 2. Peace Corps System Development Life Cycle – An introduction to the Stages
of the Peace Corps SDLC, the incorporation of Project Management Best Practices into
the SDLC, the guiding principles of Peace Corps SDLC, and, the relationship of the
SDLC to Peace Corps Investment Review Process.
 Section 3. Life Cycle Stages – A detailed description of each life cycle phase, including
entry criteria, inputs, major outputs, exit criteria and stage specific tasks and activities.
 Appendix A – Recommended SDLC Policies – A cross matrix view of SDLC
requirements in terms of management, project planning & approval, project monitoring &
control, quality assurance, configuration management, IT security, and contract
monitoring.
 Appendix B – Checklist of Key SDLC Policies and Elements – A checklist of the key
elements of the SDLC to assist project management in defining tasks and deliverables
 Appendix C – Acronyms – Provides a list of Peace Corps and other related acronyms.
Peace Corps 2
December 03, 2009
Version 4.2 The Peace Corps System Development Life Cycle
2. The Peace Corps System Development Life Cycle

A life cycle is a series of ordered, repeatable activities used to develop, maintain, and retire an IT
system, product, or hardware configuration. The life cycle defines when activities will occur
during the life of the system, product, or hardware configuration.
Using a clear, well-defined life cycle provides benefits to an organization. Specifically, a well-
defined life cycle increases the probability that:
 Systems will comply with relevant standards, regulations, and Peace Corps policy
 Systems will be produced in a disciplined, repeatable, engineered manner
 Project risk will be accurately assessed and mitigated
 Management control will be applied consistently
 Resources will be efficiently controlled and applied
 Cost, schedule, and functionality will be predictable
 The system‘s performance will meet the user‘s needs
 The system‘s security posture will be in compliance with federal regulations and Peace
Corps Policy
 High-quality products will be developed and maintained within budget and on time
 The development process will produce a complete set of deliverables.
2.1 Project Management Terminology

The Peace Corps SDLC includes the stages, task/activities, reviews, and deliverables that must
be accounted for by all projects. It is the foundation for building and measuring specific Peace
Corps projects and it draws heavily from the principles of Project Management.
The following key terms are crucial to the understanding and application of the SDLC:
Project Plan: Consists of a management document that describes the approach to be
taken for a project. It describes the work to be done, resources required, development
methods and management strategies to be used, constraints and assumptions, project
organization, assigned roles and responsibilities, as well as milestones to be met. The
Work Breakdown Structure (WBS) and schedule are essential parts of this plan. In its
entirety, the Project Plan represents the System Development Life Cycle for a specific
project.
Work Breakdown Structure (WBS): Consists of hierarchical levels of detail, including
phases and steps at intermediate levels. The WBS organizes, defines, and graphically
displays the work to be done to achieve the specified product. At the lowest level, it
subdivides the project into individual tasks that are defined, estimated, and tracked.
Schedule: Consists of various details, including tasks, estimates of required effort (as
modified based on assigned staff), staff availability, and critical dependencies to create
the most efficient plan of action over a specified period. It is often depicted graphically.
Completion of project activities and milestones is tracked against this timeline.
Peace Corps 3
December 14, 2009
Task: is a defined unit of work, with a measurable end, for one or more persons. The
level of effort required to complete the task is estimated and tracked.
2.2 Principles of Peace Corps System Development Life Cycle

The following principles form the foundation of the Peace Corps development processes.
User Primacy
Every system development project begins and ends with the user. Systems development focuses
on satisfying user requirements, including information systems security requirements imposed on
the user by federal regulation, through defined, documented, and mission-related performance
goals for that system. Business Sponsors and users continue this involvement until the system is
retired.
System Development Project Management Goals

Every system development project will be managed as a valuable taxpayer investment using a
disciplined engineering process with effective management controls.
Each project will adhere to prescribed discipline by:
 Repeating successes by following a framework of processes, such as the SDLC
 Mitigating the risks associated with complex programs by reusing structured activities
and artifacts.
 Well-engineered projects will:
– Document their plans
– Follow those plans
– Retain evidence of their work.
 Projects require effective management and oversight to ensure that the system is
developed on schedule, within budget, and produces the expected results. This includes
providing:
– The right people on the project team with clearly defined roles, objectives, and
responsibilities
– Adequate resources to accomplish the tasks
– A solid, effective communication mechanism for reporting progress, identifying issues,
and sharing lessons learned.
IT System Project Mandates
All Peace Corps projects will:
 Perform project planning and monitoring activities governed by a Project Plan that is
tailored to fit the project, including mandatory reviews. Note: small projects will only
require an estimated level of effort expressed in day and a target completion date.
 Have mission-related performance goals and acceptance criteria for the system (this is not
applicable for small projects)
 Have clear user requirements that are testable and traceable to the work products
produced
Peace Corps 4
December 03, 2009
 Meet information systems security requirements as mandated by federal regulations and

consistence with Peace Corps policy
 Perform QA throughout the project‘s life cycle
 Perform CM
 Establish mechanisms to capture, prioritize, and track:
– Work and change requests
– Intra-project issues
– Inter-project issues.
All Peace Corps projects will be subject to management reviews and approvals, as defined by the
SDLC. These reviews and approvals are consistent with the Peace Corps Enterprise Architecture
(EA), the Peace Corps strategic planning & budget process. They provide executive direction,
control, and management of Peace Corps IT investments.
Project Metrics
When a project begins, metrics must be defined for the system‘s contribution to Peace Corps
mission performance and business improvement. The project must also document metrics for
expected systems performance, acceptance, and information system security criteria. These
metrics are documented in the project‘s Business Case, and the acceptance criteria are
documented in the User Requirements. The metrics required for each business case should be
based on either specific function points and/or earned value analysis. This will vary from project
to project but standard metrics analysis should be developed as part of the agency‘s CPIC
process. Small projects will not require this analysis.
Once the project has been approved, the following Project Management Performance Data must
be collected, documented, and used throughout the project‘s life cycle:
 Effort for both product development and review activities
 Cost
 Work Product Size(s) and changes
 Schedule (based on Effort and Size estimates plus staff availability)
 Requirements (i.e., number of requirements) and Number of Changes
 Product Quality (i.e., number of defects, severity, and status). Whenever possible
existing tools (such as Dimensions) will be used to document quality status and issues.
 Critical Computer Resources (e.g., memory, storage, bandwidth, hardware, tools) needed
both for development and for deployment and operation.
Each of these items must be estimated during initial planning. Also, the assumptions and
constraints upon which the estimates are based should be documented. Data for each of these
metrics must be collected regularly during the project‘s life cycle.
The project compares actual accomplishments and effort with the estimates to provide objective
information on project status and trends. Corrective actions will be taken as required and
documented.
Peace Corps 5
December 03, 2009
2.3 Overview of the System Development Life Cycle

The following is a high-level description of the nine SDLC Stages.
1. Concept and Business Case: This life cycle stage begins with the business need for a
particular automated solution and ends with the release of funds to begin development
(note: small projects are exempt from this stage since they are funded). Included in this
stage are EA reviews by the EA Advisory Board (EAAB), and reviews by the Investment
Review Board (IRB), depending on the project size, relative priority to other projects, life
cycle cost, risk (both project and IT security), and funding availability. The concept and
business case are developed by the appropriate business sponsor. This process is based on a
cooperative effort between the CIO office and the users. The users build the business case
that includes the appropriate financials to justify the investment in the IT solution
requested. This can be in the form of an E-300 businesses case for new funding and/or an
Unfunded Request (UFR). Standards and templates for business case development are
provided by the CIO office. Creation of a Project Initiation Form (PIF), Business Impact
Assessment (BIA), FIPS 199 and project sizing and tailoring occurs at this stage.
2. Initiation and Authorization: This stage begins when funding is released to begin
detailed project planning. This includes developing a draft of user requirements and
infrastructure planning, a technical compliance review, an initial project plan, a preliminary
security risk assessment, and appropriate life cycle tailoring (i.e., using this SDLC
document as a guideline for developing the project standards). This stage ends with a
review process that authorizes the project to continue with development. In some cases, a
prototype to either test the business case and/or develop a basis for the project‘s end goals
may be requested. The development of a prototype can be done at any stage depending on
the complexity, reach, and timeline of the project. The SDLC regards the process of
prototyping as an interactive process requiring design, construction, review, and
acceptance. However, the process is less formal and the target users of the solution being
prototyped must be heavily involved. It should be noted here that a prototype is
distinguished from a pilot in the following manner. A prototype is a test of a concept being
developed as part of the solution to a business problem. It is done upfront so that users and
developers will agree on the selected solutions before it is being developed on a large scale.
A pilot project is a small implementation of a large effort to test an accepted solution. A
prototype may or may not be developed as part of the pilot.
3. Project Definition: During Project Definition, information created in the previous stage is
further refined until a clear set of functional requirements can be produced and certified by
the Business Sponsor. During this phase the system‘s security requirements are produced
and approved by the Chief Information Security Manager (CISM). On the basis of these
requirements, the technical planning and support area documentation are created.
4. System Design: During System Design, the development team uses all identified
requirements to create the technical design of the system under development. This stage
ends with a Design Review, in which the Business Sponsor reviews the work products and
certifies that the system design meets the business requirements as defined in previous
stages.
5. Construction: During this stage, the requirements and design developed during the
previous stages are translated into operational work products (e.g., infrastructure, source
Peace Corps 6
December 03, 2009
code, and databases). These work products and code then undergo unit and integration
testing by the development team and supporting organizations until the system is ready for
acceptance testing. Applicable system documentation, such as the system security plan,
system configuration guide, and training plan are refined or updated. Also, equipment is
received and checked to ensure proper operation and integration.
6. Testing and Acceptance: There are two types of acceptance testing that occur in this
stage. First, the system is tested to ensure that it interfaces properly with other automated
systems within the Peace Corps environment. Second, independent testers (such as the QA
team) and users test the system to ensure that the developers have delivered a system that
meets the needs stated in the user and functional requirements. Security Certification (if
needed) is obtained during this stage; certification ensures that the security controls are in
place and operating as intended based on security requirements defined in previous stages.
In addition, validation of the system against the benefits and costs outlined in the business
case occurs. The IRB participates in the stage to ensure that the project is on track, within
budget and the benefits are indeed realized.
7. Operational Readiness: At this point, the new system is moved into the Peace Corps
Production environment in preparation for operational processing. Although the system is
now in the Production environment, it has not yet been transitioned to full operation. The
implementation of the system includes site preparations; infrastructure
installation/deployment; data conversions; database and system code installation into the
production environment; and, scheduling as necessary to make the new system available to
the general users. To ensure the system will be ready for operations, field testing and
parallel operations may be conducted as required. User Documentation and Training
materials must be finalized and released, with appropriate training plans implemented.
Prior to moving into Operations, the system‘s Authorizing Official must review the
system‘s Security Certification Package to determine whether the residual risk to the system
is acceptable, and whether there is adequate protection of the system and its data for the
system to be accredited for operation. Based on this the review, the Authorizing Official
may or may not authorize the system for operations. As a final component of the
Operational Readiness phase, the project team should document the project experience and
lessons learned.
8. Operations: The system is in general use throughout the Peace Corps. This stage consists
of activating and rolling out the system plus the activities to monitor performance of the
system in production and ensure continuity of operations. This includes performance
monitoring and management feedback; tracking of system performance statistics, costs, and
resource allocations; detecting defects in the application, operation, and local systems;
assessing the system‘s efficiency and effectiveness to determine if the investment was cost
beneficial and achieved the planned functionality; managing system and infrastructure
problems (e.g., recovery) and implementing changes; and the continuous monitoring of the
system‘s security controls.
The system is reviewed while in production to ensure that it continues to meet user needs
and security accreditation requirements. Independent evaluations may also be performed
during this and other stages of the life cycle to validate compliance with project standards,
processes, and functional and security requirements. Information should be collected to:
Peace Corps 7
December 03, 2009
demonstrate the systems‘ contribution and efficiency; and validate the gains projected in the
Business Case.
9. Disposition/Disposal: When a system is no longer needed or to be replaced, it is necessary
to identify the disposal requirements and procedures. The planned disposition of a system
ensures the orderly termination of the system. Particular emphasis is given to proper
preservation of the data processed by the system, so that the data is effectively migrated to
another system, archived in accordance with applicable records management regulations and
policies, for potential future access, or disposed of in a manner appropriate for the
information type handled by the system.
Figure 1 depicts a high-level view of the Peace Corps SDLC. The following chapter explains the
life cycle stages in more detail.
Peace Corps 8
December 03, 2009
Major
Major
Reviews, Deliverables, & Activities
Stage Exit Stage 1 --
IRB Approval/Rejection
Criteria Concept & IT Concept Document
Funding Business Case Business Case
Approved Prepare Business Case
Identify Project Manager
Stage 2 --
Project Reviews
Project Work Initiation &
Authorization Authorization Initial Project Plan
Issued Draft User Requirements
Technical Compliance Reviews
Tailor the Life Cycle
Stage 3 -- Project Requirements Certification

Definition Phase Completion Review
Requirements Definition Requirements Traceability Matrix
Certified
Acquire Project Systems & Services
Prepare Support Area and Security Plans
Critical Design Review

Stage 4 -- System Review with Senior Management
System Design
Accepted Design Baselined Design Documents
Peer Reviews
Test Readiness Review

Finalize Most Project Documents
Baselined Products For Testing
Stage 5 --
Ready for Develop Code
Construction Construct Infrastructure
Independent
Testing Unit and Integration Testing
Production Readiness Review

Testing Results/Recommendations
User Acceptance Test Memo
Ready to Stage 6 --
Draft User and Training Materials
Access Acceptance Security Certification and Accreditation
Production Baseline System and Documentation
Data
Operational Readiness Review
Training Schedule
Stage 7 -- Project Lessons Learned
Production Baseline(s)
Ready to Operational
Production Notice
Become Readiness Move to Production Environment
Operational Pilot/Parallel Testing
Document Lessons Learned
Post Implementation Evaluations
Stage 8 -- Security Recertification & Reaccreditation
Capacity & Performance Reports
System Operations Updated Project & User Documents
Disposal
Activitate & Roll-out System
Approved
Ensure Continuous Operations
Upgrade Software/Hardware
Stage 9 -- Disposal Authorization
Disposal/Disposition
Media Sanitization Form
Updated System Inventory
Sanitization of System Components
Archiving of Records (as required)
Figure 1: Overview of Peace Corps SDLC Stages
Peace Corps 9
December 03, 2009
2.4 Relationship of SDLC to the Investment Management Process

The Clinger-Cohen Act of 1996 requires agencies to use a disciplined Capital Planning and
Investment Control (CPIC) process to acquire, use, maintain, and dispose of information
technology (IT). Peace Corps‘ Investment Management Process supports the CPIC
requirements. The nine stages of the SDLC uphold Peace Corps‘ Investment Management
Process, thereby the CPIC process, and include all required CPIC deliverables, reviews, and
approvals as shown in Figure 2. While these stages are depicted conceptually in a waterfall
fashion, actual projects may use iterative, parallel, or spiral time lines.
Investment Management Process
Peace Corps SDLC
Select Phase
Concept and
1 2
Business Case
Initiation &
3
Project Management Authorization
Support
(ongoing throughout
the life cycle)
Project Definition
Project Planning and
Budgeting
Program Monitoring
Requirements
System Design
Management
Configuration
Control Phase
Management
Quality Assurance
Management Construction
Reviews
Meetings and
Associated
Documents
Acceptance
Operational
Readiness
Operations 4
Evaluate Phase
Retirement
Enterprise Architecture Processes
1 Business Alignment Assessment 3 Technical Compliance Review
2 Architecture Compliance Review 4 Business Compliance Review
Figure 2: Relationship of SDLC to Investment Management Process
Peace Corps 10
December 03, 2009
Version 4.2 Life Cycle Stages – Detailed Description
3. Life Cycle Stages – Detailed Description

This section provides a detailed description of each stage in a structured format. The
conditions for entering each stage as well as the inputs to and outputs from each stage are
listed. These lists and tables are meant to be used as guidelines for the project planners who
will tailor them based on the project size, scope and requirements.
Table 1 provides definitions for the terms used in this section.
Table 1: Stages Terminology
Term Definition
Entry Criteria The conditions that must exist when the stage begins.
Inputs The work products that must be present before the activities of a specific
stage can be performed.
Outputs The work products that are generated or produced within a specific stage.
Exit Criteria The conditions under which the stage can be declared complete.
Tasks/Activities The steps involved in implementing a stage / activity:
 A task is a defined unit of work for one or more people with a measured
endpoint. Multiple tasks may be defined to complete one activity.
 An activity is the action, steps, or process taken to create or achieve a
specific product, service, or result. Activities may identify either the
“what” or the “how”
Primary Responsibility Those persons who perform hands-on activities or who have specific
approval authority. The roles listed are functional roles rather than titles.
Support Responsibility Those persons who provide assistance, reviews, and concurrence with
results/outputs. Support responsibilities also include sources that the
project can tap for expert advice. The roles listed are functional roles rather
than titles.
3.1 Stage 1: Concept and Business Case
3.1.1 Entry Criteria

 Business Sponsor expresses a general need for an IT system to support a business need.
3.1.2 Inputs
 Business Need
 Business Sponsor‘s / User Ideas / Concepts.
Initial Business Requirements
3.1.3 Major Outputs

 IT Concept Document (Includes Project Initiation Form (PIF))
 Business Case (compliant with the Peace Corps E-300 process)
Peace Corps 11
December 14, 2009
 Preliminary Cost-Benefit Analysis, if applicable (compliant with the Peace Corps E-300
process)
 System Security Categorization and Preliminary Risk Assessment
 Notification of Funding Approval, if applicable.
3.1.4 Exit Criteria

 Business Sponsor receives notification of funding amount approved by the appropriate
authority (depending on the scope and cost of project), OR
 Project is under $100K, already funded, and has received approval from either the
EAAB, or IRB as appropriate, OR
 Project was not approved by the EAAB, ITC, or IRB (Therefore, Project may not
continue).
 IT System Owners must identify preventative controls to incorporate into their IT

system‘s architecture and operations to mitigate or eliminate disruption impacts.
Examples of preventative controls include an Uninterruptible Power Supply (UPS);
frequent, scheduled backups; dual, load balanced servers with failover capability; failover
circuits; redundant data pathways; and, least-privilege access controls. (Absolute)
Table 2 shows the Stage 1 Tasks/Activities.
Table 2: Stage 1: Concept and Business Case Tasks/Activities
Stage 1 - Concept and Business Case Tasks/Activities

Task/Activity Deliverable(s)/Outputs Notes
Create Project Concept IT Concept Development (PIF) Need to develop a standard
If applicable – develop a
prototype
Identify COTS/GOTS, etc. for Preliminary COTS/GOTS, etc.,
further Application Product Evaluation Results
Evaluations
Review High-level Business Updated IT Concept
Alignment and Architecture Recommendation
EAAB Approval Process Statement of EA compliance or Need to develop a standard
Architectural Waiver Justification, if
applicable
Identify Project Manager
Create Business Case Business Case, including: Need to develop a standard
Worksheet across the agency
Operational Concept
Evaluation of Alternatives
Timeline, Costs,
Preliminary Security Risk
Assessment
System Security Categorization
IRB Approval Process Authorization Document Need to develop a standard
Peace Corps 12
December 03, 2009
Stage 1 - Concept and Business Case Tasks/Activities

Release Funding Notification of Funding Approval Need to develop a standard
3.2 Stage 2: Initiation and Authorization

 Business Sponsor receives notification of funding amount approved OR
 Project is under $100K, already funded, and has received approval from the EAAB, or
IRB as appropriate.
 Project Manager has been identified
 Resources have been planned and committed (business and technical)
3.2.2 Inputs
Outputs from Stage 1
3.2.3 Major Outputs

 Tailored Life Cycle and Deliverables Project Standard and Conventions
 Initial Project Plan
 Release Plan, if applicable
 Detailed Cost Estimates
 Detailed Cost-Benefit Analysis, if applicable
 Complete Preliminary IT Security Risk Assessment
 Draft
– User Requirements Document
– Acquisition Plan, if applicable
– Infrastructure Plan
3.2.4 Exit Criteria

 Project plans and documents have been reviewed and action items have been resolved
AND
 Management approval of the project plans has been received
3.2.5 Tasks and Activities

Table 3: Stage 2: Initiation and Authorization Tasks/Activities
Stage 2 - Initiation and Authorization Tasks/Activities
Peace Corps 13
December 03, 2009

Identify Initial Members Training Plan based on skills mix should Training Plan template/standard
of the Project Team be developed to be developed
Document User Draft of User Requirements Document, Requirements Document
Requirements Minutes of reviews with the users Standards and guidelines for
collecting requirements
Select Appropriate Life Tailored Life Cycle and Deliverables Need a pilot project to act as an
Cycle and Identify Project Standards examples for other projects
Tasks/Deliverables
Create Initial Project Initial Project Plan, Need to develop a
Plan Release Plan, if applicable standard/sample
Create Infrastructure Infrastructure Plan Need to develop a
Plan standard/sample
Develop Acquisition Plan Acquisition Plan Need to develop a
standard/sample
Create Initiation Project Cost Document, including Need to develop a
Documentation Detailed Cost Estimates standard/sample
Detailed Cost-Benefit Analysis
Conduct Project Project Review Package Need to develop a
Reviews Agenda, Minutes, and Action Items standard/sample
Management Approval
Continue Preliminary Preliminary Security Risk Assessment Need to develop a
Security Risk standard/guide
Assessment
Perform Project Initiation Project Work Authorization Memo Need to develop a
Review standard/sample
3.3 Stage 3: Project Definition

 All action items from the Project Review have been resolved
AND
 Management approval of the project has been received.
3.3.2 Inputs
 Deliverables from Stage 2
3.3.3 Outputs
 User and Functional Requirements Documents
 Baseline security control requirements identified by the sensitivity and criticality analysis
as per National Institute of Standards and Technology (NIST) Special Publication (SP)
Peace Corps 14
December 03, 2009
800-60, security categorization per Federal Information Processing Standards (FIPS) 199,
and preliminary risk assessment
 Initial Requirements Traceability Matrix (RTM)
 Finalized Acquisition Plan(s)
 Contract Award, if applicable
 Training Requirements Document
 Project Risk Management Plan.
 Draft CM Plan
 Draft QA Plan
 Draft Disaster Recovery Plan
 Draft System Test Plan
 Draft Data Management Plan
 Draft Implementation Plan
3.3.4 Exit Criteria

 Requirements validated by business users
AND
 Project plans have been approved by all related organizations and management.

Table 4: Stage 3: Project Definition Tasks/Activities
Stage 3 - Project Definition Tasks/Activities

Update User Requirements User Requirements Document
Prepare Initial Functional Functional Requirements Document Need to develop a
Requirements standard/sample
Prepare Baseline Security Baseline Security Requirements Traceability Based on security
Control Requirements Matrix for Technical, Operational, and categorization of
Managerial Security Controls system, NIST 800-53,
and Peace Corps
Policy and IT Security
Requirements
(ITSRs).
Walkthrough Functional Meeting Minutes Need to develop a
Requirements standard/sample
Certify User and Functional Requirements Certification Form with Need to develop a
Requirements signature of Business Sponsor and Project standard/sample
Manager
Peace Corps 15
December 03, 2009
Stage 3 - Project Definition Tasks/Activities

Create Requirements Initial Requirements Traceability Matrix Need to develop a
Traceability Matrix (RTM) Initial EA impact/integration document standard/sample
Acquire Project Finalized Acquisition Plan(s)
Systems/Services Contract Award
Define Test Requirements System Test Plan Need to develop a
standard/sample
Define Training Requirements Training Requirements
including security specific
training requirements
Conduct Support Organization Meeting Minutes
Interface Meeting(s)
Prepare Support Area Plains Data Management Plan Need to develop a
QA Plan standard/sample
CM Plan
Implementation Plan
Risk Management Plan
Perform Definition Phase Definition Phase Completion Review Need to develop a
Completion Review Package standard/sample
Meeting Minutes, Agenda, Action Items
Privacy Impact Assessment Privacy Impact Assessment questionnaire Confer with The
Freedom of
Information Act and
Privacy Act Office
3.4 Stage 4: System Design

 Requirements Certification is completed
AND
 Project Manager signs off on Definition Phase Completion.
3.4.2 Inputs
 Output from Stage 3
3.4.3 Outputs
 Draft Training Plan
 Memo of User Acceptance of Design
 Initial
– Project Plan, CM Plan, QA Plan
– Data Management Plan (including Data Model & Data Dictionary)
Peace Corps 16
December 03, 2009
– System Design Documents

– Security Design Document
– System Security Plan
3.4.4 Exit Criteria

 Critical Design Review is completed. The System Design is accepted by the Business
Sponsor and all affected stakeholders
AND
 All Design documents are in draft format.

Table 5: Stage 4: System Design Tasks/Activities
Stage 4 - System Design Tasks/Activities

Create Preliminary System System and Security Design Need to develop a
Design Documents standard/sample based on the
selected and approved
development methodology
Conduct Peer Reviews and Minutes and memos documenting Need to develop a
Preliminary Design Reviews the reviews standard/sample for tools used
Create Detailed System System and Security Design Need to develop a
Design Documents standard/sample
Conduct Peer Reviews and Minutes and memos documenting
Detailed Design Reviews the reviews
Create Training Plan Draft Training Plan Need to develop a
standard/sample
Conduct Critical Design Critical Design Review (CDR) This is an external review (outside
Review (CDR) Package of the design team) involving the
Agenda, Meeting Minutes, Action user community and the technical
Items support organizations. It is a
Memo of User Acceptance of prerequisite for the design
Design acceptance prior to development
Baseline Design Baseline: The CM and QA plans are

System Design Documents specific to this project and must
Security Design Document be integrated with general CM
(security related components) and QA standards (when they are
developed and put into operation)
Data Management Plan
Project CM Plan
Project QA Plan
Peace Corps 17
December 03, 2009
Stage 4 - System Design Tasks/Activities

Initiate Preparation of System Security Plan (Documents Use existing standard Security
Required Security all planned security controls for Plans per NIST SP guidance and
Deliverables system) Peace Corps ITSRs
Update Preliminary Security Risk
Assessment (as necessary)
IT Contingency Plan
Incident Response Plan
Security Assessment Test Plan
IT Security Training Plan
Data Storage, Retention, and
Disposal Plan
Plan of Actions and Milestones
IT Contingency Plan Test Plan
Conduct Project Review with Meeting Agenda and Minutes Chief Architect approval
Management & get approval Baseline Project Plan (conformance to EA and
standards) is mandatory
3.5 Stage 5: Construction

 Critical Design Review is completed. The System Design is accepted by the Business
Sponsor and all affected stakeholders
AND
 All Design documents are in draft format.
3.5.2 Inputs
Output from Stage 4
3.5.3 Outputs
 Source Code documentation (e.g., diagrams and comments depending on tool and
methodology)
 Infrastructure documentation
 Source Code
 Databases
 Procedures
 Developers‘ Test Cases / Scenarios and Results
 Draft Documents
– User Documentation and Training Materials Outlines
Peace Corps 18
December 03, 2009
– System Acceptance Test Plan

– Operations Manuals
– IT Contingency Plan
– Incident Response Plan
– IT Security Training Plan
– Data Storage, Retention, and Disposal Plan
– Plan of Actions and Milestones
– IT Contingency Plan Test Plan
– Security Assessment Test Plan
 Final Documents
– Project Plan
– Infrastructure Plan
– Data Management Plan
– Requirements Traceability Matrix (RTM)
– Training Plan
– System Test Plan
– Disaster Recovery Plan
 Project Risk Management Plan
 System and Security Design Documents.
3.5.4 Exit Criteria

 The Test Readiness Review is completed, signifying that the Work Products are ready for
independent testing
AND
 Work Products turned over for testing are validated.

Table 6: Stage 5: Construction Tasks/Activities
Stage 5 - Stage 5: Construction Tasks/Activities

Establish Working Appropriate Development, Test, Need to develop operational
Environments and Production Environments procedures, naming standards and
other conventions
Develop/Code Software Source Code Source code construction standards
Package
Construct Infrastructure Infrastructure Need to develop standards for
Databases database documentation and
conventions
Create System System Acceptance Test Plan Need to develop a standard/sample
Acceptance Plan
Peace Corps 19
December 03, 2009

Document Work Products Documentation for Source Code, Need to develop a standard/sample
database and Infrastructure
Conduct Unit/Integration Updated System and Security Need to develop a standard/sample
Testing Test Plans, for test cases and expected results.
Developer‟s Test Cases/
Scenarios
Test Results
Prepare Draft User User Documentation and Training Templates/samples should be
Documentation and Material Outlines developed
Training Material Outlines Security Features User's Guide (if
appropriate)
Prepare Operations Data Center Operations Manual Need to develop a standard/sample
Manual(s) Site Operations Manual
System Administrator‟s Guide
(All operation guides and
manuals include a section
covering security procedures or
reference a separate security
document)
Security Documentation In preparation for testing, security
documentation and test plans
must be near final during the
construction stage. These may
be updated during the testing
stage. These include:
IT Contingency Plan
IT Security Training Plan
Data Storage, Retention, and
Disposal Plan
Plan of Actions and Milestones
IT Contingency Plan Test Plan
Conduct Full Risk The Full Security Risk
Assessment Assessment begins during the
construction phase and must be
completed prior to the finish of the
testing and acceptance phase.
Conduct Review of Minutes/Results of Reviews In preparation for approval and
Deliverables with acceptance
Receivers
Conduct Technical Peer Minutes of Peer Review Results
Reviews
Finalize Project Project Plan
Deliverables Business Case
RTM
Project Risks Database,
Other documents as needed
Peace Corps 20
December 03, 2009

Conduct Testing and Meeting Agenda, Minutes and Need to develop a standard/sample
Acceptance review action items
3.6 Stage 6: Testing and Acceptance

 The Testing and Acceptance Review is completed, signifying that the deliverables are
ready for independent testing
AND
 Work Products turned over for testing are the base line.
3.6.2 Inputs
Output from Stage 5
3.6.3 Outputs
 System Acceptance
– System Acceptance Test Plan (Final)
– System Acceptance Test Cases / Scenarios and Results
– System Acceptance Test Problem Reports
– Testing Organization Recommendation
 User Acceptance
– User Acceptance Test Cases / Scenarios and Results
– User Acceptance Test Problem Reports
– User Acceptance Test Signoff memo
 Approved User Documentation and Training Materials
 System Security Certification Package, includes final
 System Security Plan
 Full Security Risk Assessment,
 Security Assessment Report
 IT Contingency Plan
 Incident Response Plan
 System Interconnection Agreements
 Plan of Actions and Milestones
 Privacy Impact Assessment,
 Certification Recommendation
 Final Documents
– Implementation Plan
– Deployment Plan
Peace Corps 21
December 03, 2009
 Initial System and Documentation
 Production Readiness Review Signoff Form
3.6.4 Exit Criteria

 Production Readiness Review is completed. QA certifies that the system is tested and
ready to access production data
AND
 System is validated.

Table 7: Stage 6: Testing and Acceptance Tasks/Activities
Stage 6 - Testing and Acceptance Tasks/Activities

Prepare/Update Test Cases Updated Test Cases/Scenarios Need to develop testing standards
and conventions in conjunction
with CM standards
Migrate Software to Test Software Moved to Test
Environment Environment
Finalize System Acceptance System Acceptance Test Plan Need to develop a
Test Plan (including security components) standard/sample
Conduct System Acceptance System Acceptance Test Problem
Test Reports
Resolve Test Problems Production-Ready Code and
Infrastructure
Prepare Production-Ready Production-Ready Infrastructure
Environment
Prepare Testing Results Test Results (including independent
reports security testing) & recommendation
Prepare System Security System Security Certification Need to develop a
Certification Package Package standard/sample
Develop/Update Initial User User Documentation
Documentation and Training Training Materials
Materials
User Acceptance Testing User Acceptance Test Results Need to develop a
Problem Reports standard/sample
Approved User Documentation and
Training Materials
User Acceptance Test Signoff
memo
Conduct Deployment Deployment Plan and Need to develop a
Meeting Action Items standard/sample
Peace Corps 22
December 03, 2009
Stage 6 - Testing and Acceptance Tasks/Activities

Finalize Project Deliverables Operations Manual(s) Need to develop a
Implementation Plan standard/sample
Deployment Plan
Security Plan
Prepare System Security System Security Certification
Certification Package Package
Receive System Security System Security Certification
Certification Recommendation
Prepare Production Move Production Move Request
Request
Baseline the System System components
Prepare Production Production Readiness Review
Readiness Review) Package Package (including all work
products to date, whether draft or
final)
Conduct Production Agenda and Minutes
Readiness Review Action Items List
PRR Signoffs
3.7 Stage 7: Deployment Readiness

 Production Readiness Review (PRR) is completed. QA certifies that the system is tested
and ready to access production data
AND
 System is base lined.
AND
 System Security Certification Package is complete, reviewed by Certification Agent, and
Certification Recommendation is issued.
3.7.2 Inputs
 System Acceptance
– System Acceptance Test Plan
– System Acceptance Test Cases/Scenarios and Results
– System Acceptance Test Problem Reports
 User Acceptance
– User Acceptance Test Cases/Scenarios and Results
– User Acceptance Test Problem Reports
– User Acceptance Test Signoff memo
Peace Corps 23
December 03, 2009
 Approved User Documentation and Training Materials

 Security Certification Package and Certification Recommendation
 Final Documents
– Implementation Plan
– Deployment Plan
– Security Plan
 Baseline System and Documentation
 Production Readiness Review Signoff Form
3.7.3 Outputs
 Project Lessons Learned documents
 Prepared Operational Sites
 Prepared Support Infrastructure
 Converted Data
 System Moved to Production and Education Environments
 Databases Moved to Production and Education Environments
 Final User Documentation and Training Materials
 Finalized System Documentation
 Complete Accreditation package with Accreditation Memo from Authorizing Official
 Training Schedule (includes Operational Sites) If applicable:
– Pilot Test Report
– Parallel Operations Report
– Pilot Training Class
 Operation Readiness Review Signoff Form
 Production Baseline of System and Documentation
 Production Notice
 Updated Change Control Database.
3.7.4 Exit Criteria

 The Operational Readiness Review (ORR) is completed, signifying that the Business
Sponsor has accepted the system to become operational
AND
 The CMR is approved for the system to move into full Operations
AND
 System is base lined
AND
Peace Corps 24
December 03, 2009
 System has received an Authorization to Operate from its Authorizing Official.

Table 8: Stage 7: Operational Readiness Tasks/Activities
Stage 7 - Operational Readiness Tasks/Activities

Prepare for Installation Prepared Support Infrastructure Documentation is crucial at this
Prepared Operational Site(s) point
Convert Data Converted Data
Move to Production System Moved to Production and
Environment Training Environments
Databases Moved to Production
and Training Environments
Perform Pilot Testing Pilot Test Report(s) Need to develop a standard/sample
Complete Accreditation of System receives Authorization to
System Operate from Authorizing Official
Perform Parallel Parallel Operations Evaluation Need to develop a standard/sample
Operations Report
Finalize Training Schedule Training Schedule (includes
Operational Sites)
Conduct Training Pilot Pilot Training Class
Finalize and Produce Finalized User Documentation and
Training Materials Training Materials
Finalize Project Plans and Finalized Plans and documentation * includes all security documents
Documentation
Prepare/Document Project Lessons Learned Need to develop a standard/sample
Lessons Learned documents
Create Production Baselined System
Baseline Baselined Documentation
Conduct Operational ORR Agenda and Minutes
Readiness Review (ORR) Action Items
ORR Signoffs
Release Production Notice Production Notice
Updated Change Control Database
3.8 Stage 8: Operations

 The Operational Readiness Review (ORR) is completed, signifying that the Business
Sponsor has accepted the system to become operational
AND
Peace Corps 25
December 03, 2009
 The Authorizing Official has granted the system an Authorization to Operate, signifying
that the Authorizing Official has made the risk-based decision to approve the security
posture of the system and accepted any residual risk.
AND
 System is baselined.
3.8.2 Inputs
Output from Stage 7
3.8.3 Outputs
 System Being Used in the Field
 Capacity and Performance Monitoring Reports
 Operational Problem Reports
 Help Desk Reports
 Work Requests and System Change Requests
 Configuration Management is in place
 Upgraded/Replaced System Software/Hardware/Firmware
 Post-Implementation Review (PIR) Reports
 Evaluation Reports and Audits
 Performance Measures for System Performance and System Contribution to Peace Corps
Mission
 Trained Users
 Updated User Documentation and Training Materials
 Updated Security Documentation
– IT Contingency Test Plans and Reports
– Operational Lessons Learned documents
 Continuous Monitoring of security controls
 Security Reassessments, Re-Certification, and Re-Accreditation.
3.8.4 Exit Criteria

 A management decision is made to retire or terminate a system.

Peace Corps 26
December 03, 2009
Table 9: Stage 8: Operations Tasks/Activities
Stage 8 - Operations Tasks/Activities

Activate the System Activate the System
Train Users
Roll-out to Additional Sites
Train Users Trained users
Conduct user feedback survey
Roll Out to Additional Sites Per plan
Monitor Performance Capacity and Performance Schedule regular performance
Monitoring Reports reviews
Ensure Continuous Operational Problem Reports Need to develop a
Operations Work Requests standard/sample
Change Requests Note: conduct security vulnerability
Archived Data operations and reporting
Manage Production Change Requests

Problem Reports Operational Problem Reports
Help Desk Reports
Change Impact Analyses
CCB Agendas and Minutes
Change Management Requests
Analyze Problem Reports Work Requests
Change Requests & Problem
Reports (in Dimensions)
Capacity Planning and Re- Evaluation Reports Need to develop a
planning standard/sample
Evaluate and Upgrade Upgraded/Replaced System
Systems Software/COTS Software
Analyze and Install Upgraded/Replaced Hardware/
Hardware/Firmware Firmware
Upgrades
Document Operational Operational Lessons Learned
Lessons Learned documents
Post-Implementation Post-Implementation Review
Evaluations Reports
Evaluation Reports and Audits
Performance Measures for
System Performance
Contribution to Peace Corps
Mission
Update User Updated User Documentation and
Documentation and Training Materials
Training Materials
Peace Corps 27
December 03, 2009
Stage 8 - Operations Tasks/Activities

Update Required Security System Security Plan
Documentation Disaster Recovery Plan
IT Contingency Plan
Evaluate Disaster Disaster Recovery Test Plans and Need to develop a
Recovery Plans Reports standard/sample
Evaluate IT Contingency IT Contingency Test Plans and Based on NIST SP 800-34, Peace
Plans Reports Corps Policy and ITSR for
Contingency Planning
Continuous Monitoring of Audit Logs, Change Management Based on NIST Guidance, IT
Security Controls Requests, Self-Assessments, Scan Security Best Practices, and
Reports, Maintenance Records. applicable ITSRs.
Perform Security Re- Recertification and Reaccreditation Based on NIST 800-37, Peace
Certification and Re- Package, if applicable Corps Policy and ITSR for
Accreditation Certification, Accreditation, and
Security Assessments
Stage 9: Disposition/Disposal/Retirement
Entry Criteria
 A management decision is made to retire or terminate a system
Inputs
Output from Stage 8
Outputs
 System is officially retired
 Records requiring retention are appropriately archived (Information Preservation)
 All media is sanitized or destroyed in accordance with Peace Corps Media Sanitization
Policy and Procedures
 Record Disposition Guidelines per Peace Corps Manual Section 892, "Records
Management‖
Exit Criteria
 The system is no longer in operation and is removed from system inventory
 Records that must be retained have been identified and properly archived
Peace Corps 28
December 03, 2009
Tasks and Activities

Table 10: Stage 9: Disposition/Disposal Tasks and Activities
Stage 9 - Disposition/Disposal Tasks and Activities

Sanitization and disposal Media Sanitization Form For guidance see Peace Corps
of all media, hard drives, ITSR for Media Protection and the
or non-volatile memory Media Sanitization Procedures.
Remove system from System Inventory The System Inventory should be
System Inventory updated to accurately reflect the
removal of a system.
Peace Corps 29
December 03, 2009
Version 4.2 Appendix A. Recommneded SDLC Policies
Appendix A. Recommended SDLC Policies

The policies for the SDLC cover the implementation of tasks, deliverables, reviews, and
responsibilities for development. This section provides an explanation of the goals within the
related policies areas as well as explicit policy statements that could be adopted by the CIO
office and enforced throughout the life cycle of IT Projects. The policies are organized by the
following areas: requirements management, project planning, project monitoring, QA, CM, IT
security, Metrics, and contract management.
A.1 Requirements Management Policies

Requirements are the user and IT needs that determine the capabilities and the design of an IT
system. Requirements Management is the process of capturing, tracing, and maintaining these
requirements. The user and functional requirements are typically gathered in a requirements
traceability matrix (RTM) to ensure that each requirement can be mapped through design,
development, testing, and operations. Requirements are reflected in software, hardware,
services, and documentation for both applications and infrastructure.
Goals
The overall goals of Requirements Management are to:
 Establish a common understanding of user and IT needs
 Ensure that project plans, activities, and products are kept consistent with defined needs
 Ensure that project plans, activities, and products are kept focused on defined needs
 Establish and control approved and certified requirements in order to facilitate
engineering and management activities.
1.1 Requirements Identification and Definition
1.1.1 All requirements must be clearly defined and uniquely identified.

1.1.2 All requirements must be aligned with the goals, objectives, and strategies of the
corresponding mission area as documented in the Peace Corps Strategic Plan.
1.1.3 All requirements must be thoroughly reviewed to ensure that everyone involved in the
development, analysis, and implementation processes understands them.
1.1.4 All requirements must be testable or verifiable.
1.1.5 The Business Sponsor and the Project Manager will document their mutual understanding
of the business needs, requirements, and acceptance criteria for the system and will certify
their acceptance and approval.
1.1.6 Requirements Management processes must be reviewed in accordance with Project
Monitoring and QA policies.
1.1.7 All requirements must be incorporated in the design, testing, training, and implementation
of the system and track using a Requirements Traceability Matrix (RTM)
Peace Corps 30
December 14, 2009
1.2 Documenting Requirements
1.2.1 The requirements documentation will include the following:

User Requirements
Functional Requirements (including System and Support Requirements)
Security Requirements
1.2.2 All functional requirements must be traceable to one or more user requirements.
1.3 Requirements Change Control
1.3.1 All projects must establish and follow a formal process to control project scope, assess
impacts of changes, and incorporate approved changes in a controlled manner.
1.3.2 All changes to certified requirements must be renegotiated, documented, and re-certified.
1.3.3 Once requirements have been approved and certified, all requirements changes will fall
under the CM (CM) change control policies.
1.3.4 Changes in requirements must be fully coordinated in accordance with Project Planning
and Project Monitoring policies.
1.4 Requirements Management Training
1.4.1 The members of all affected organizations who are responsible for requirements
management will be trained in the objectives, procedures, and methods for performing their
requirements management activities.
A.2 Project Planning & Approval

Project Planning involves developing estimates and descriptions for work to be performed,
establishing necessary commitments, and defining the plan and schedule to do the work.
Effective project planning ensures that resources, capabilities, and constraints are accounted for
and traceable; and that a documented plan is produced, agreed to, and used for tracking the
project.
Goals
The goals of Project Planning are to:
 Develop and use plans for performing and managing all tasks associated with the project
(for both management and engineering tasks)
 Document estimates (and their assumptions) for planning and tracking
 Document project activities and commitments
 Obtain agreement from affected groups and individuals to their commitments.
Peace Corps 31
December 03, 2009
2. 1 Investment Management Process Considerations
2.1.1 All projects will follow the Investment Management Process.

2.1.2 The Office of CIO will support and maintain only those systems approved by the Investment
Management Process.
2.1.3 Each project will have a technical Project Manager and a business Project Manager officially
designated by Management.
2.1.4 The Project Manager and Business Sponsor are responsible for grouping project
requirements into manageable, defined chunks of functionality for project funding and
deployment.
2.1.5 The Business Sponsor, in conjunction with the Project Manager and EACT, is responsible for
approval of the Project Plan.
2.1.6 Adequate resources and funding will be provided for all project activities.
2.2 Policy Waivers
2.2.1 If waivers from any policies are required, the project must gain approval from the Chief
Information Officer (CIO).
2.2.2 If waivers of any policies from organizations outside of the CIO are required, the project must
gain approval from that organization.
2.3 Tailoring
2.3.1 Tailoring of the SDLC and deliverables to meet project needs is allowed. The Project
Manager must document the reasons for the tailoring. Chief Architect must approve the
tailoring.
2.3.2 Projects may develop documents and plans as needed in addition to those defined and
required in the SDLC.
Peace Corps 32
December 03, 2009
2.4 Project Planning Fundamentals
2.4.1 Planning will be based on identified requirements.

2.4.2 All projects must use the approved Peace Corps SDLC.
2.4.3 Plans will be created and reviewed as early in the life cycle as possible; they will be modified
as more detail is developed during the course of the project.
2.4.4 All projects must be consistent with Peace Corps information and technology architecture
and software standards, as well as information security standards and guidance.
2.4.5 Projects will plan to utilize the Peace Corps technology infrastructure in lieu of building a
project-specific solution.
2.4.6 Business Sponsors and users requesting IT services are responsible for the initiation of
projects under their business areas and for actively participating throughout the entire project
life cycle.
2.4.7 Management will provide sufficient, trained staff to perform required project planning,
estimation, and project management activities.
2.4.8 During planning, the Project Manager will identify each task and activity to ensure that
appropriate resources are identified.
2.4.9 The project planning results will be reviewed and approved as specified in the IMP.
2.4.10 The Business Sponsor and Management must approve the work products‟ readiness before
it is turned over to Production.
2.4.11 Training for end-users, to include security training, will be planned and provided in a timely
fashion.
2.5 Estimating
2.5.1 The Project Manager will use historical information from similar projects [when available] to
do initial planning.
2.5.2 The Project Manager will document the procedure used to develop estimates and schedules.
Estimates will include work product sizes, effort and cost.
2.5.3 The Project Manager will involve project team members, to the maximum extent possible, in
creating, identifying, and documenting estimates, schedules, and risks.
2.6 Defining Tasks / Activities / Schedules
2.6.1 All activities will be performed according to a documented process or procedure.

2.6.2 All project activities, including stakeholder and support organization activities, will be defined
and included in the Project Plan.
2.6.3 The Project Manager will develop a Work Breakdown Structure (WBS).
2.6.4 The Project Manager will break the job down into tasks in order to allow effective progress
monitoring and re-planning.
2.6.5 The Project Manager will break near-term tasks into WBS increments that are defined in
small enough units to track progress within each month.
Peace Corps 33
December 03, 2009
2.7 Negotiating and Approving Commitments

Number
2.7.1 The Project Manager must identify and negotiate commitments with representatives of all
internal and external project stakeholders.
2.7.2 All project commitments must be documented.
2.7.3 Project Managers will plan for appropriate reviews with all internal and external project
stakeholders.
2.7.4 There must be a documented procedure for negotiating and changing commitments.
2.7.5 A project Kickoff Meeting will be held with all potential internal and external stakeholders to
review specifications, requirements, and impacts.
2.7.6 Management will review project commitments.
2.8 Re-planning
2.8.1 The Project Plan will be revised, reviewed, and re-approved as changes are required and
corrective actions taken.
2.8.2 Re-base lining requires Management approval.
2.8.3 If a project‟s cost, schedule, or mission-related performance varies from approved plans by
10% or more, the project will redo the formal Project Initiation Review and be re-authorized.
2.8.4 The Project Manager has the authority to negotiate changes and revise the Project Plan
accordingly for changes within the scope of the project.
2.9 Planning Documentation and Responsibilities
2.9.1 The Project Manager will explicitly assign and document responsibility for specific activities
and work products.
2.9.2 The following project roles at minimum must be assigned by name in writing:
 Project Manager (PM)
 Project QA
 Project CM
 Project Change Control Board
 Planning
Risk Management
 Computer Security Coordinator
2.9.3 If the Business Sponsor determines that major changes will occur to existing work processes
or workforce as a result of the project, the Business Sponsor will develop a plan in
coordination with labor and employee relations organizations to mitigate workforce issues.
2.9.4 The Business Sponsor is responsible for determining the duration of parallel operations, if
any, between the old and new systems.
2.9.5 Projects will comply with privacy policies throughout the life of the system.
2.9.6 During project initiation and system retirement, notifications must be placed in the Federal
Register for all systems covered by the Privacy Act of 1974 as amended.
2.9.7 Prior to implementation, all affected organizations and sites will be notified with sufficient time
Peace Corps 34
December 03, 2009
2.9 Planning Documentation and Responsibilities
to manage potential impact.
2.10 Process Assets
2.10.1 A Peace Corps-wide SDLC Library of recommended processes, procedures, examples, and
templates will be established and used as a reference.
2.10.2 Peace Corps Process Groups will be responsible for the assets in the SDLC Library
A.3 Project Monitoring and Control Policies

Project monitoring ensures that all projects track and control their progress proactively and
objectively. Project monitoring also ensures that the project‘s results, changes, and
commitments are communicated to all interested groups, especially management.
Goals
The goals of Project Monitoring are to:
 Track project results and performance against the project plans
 Take and monitor corrective actions when project results deviate significantly from the
project‘s plans
 Ensure that changes to commitments are agreed to by the affected groups or individuals
and communicated to all interested parties.
3.1 All Meetings / Oversight
3.1.1 Project Managers will hold Project Status meetings to review project and process activities
with project team members and other affected stakeholders on a regularly scheduled and
event-driven basis.
3.1.2 Management will review project and process activities on a regularly scheduled basis.
3.1.3 All meetings will be documented.
3.1.4 QA will review project activities and processes for the purpose of process improvement.
3.1.5 The Project Manager will conduct formal reviews, in accordance with a documented
procedure, with representatives of stakeholders external to the project to address the
accomplishments and results of the project at selected milestones.
3.2 Tracking
3.2.1 The Work Breakdown Structure, project cost estimate, and Schedule will be used for tracking
project activities and communicating status.
3.2.2 All project changes, issues, and problems must be identified, documented, and monitored.
Peace Corps 35
December 03, 2009
3.2 Tracking
3.2.3 The Project Manager is responsible for taking corrective actions and making changes within
the project to ensure that commitments are met.
3.2.4 All contributing groups will provide regular status reports to the Project Manager.
3.3. Risk Management
3.3.1 Each project will identify, assess, prioritize, document, mitigate, communicate, and monitor
both project and security risks on a regular basis.
3.3.2 The Project Manager is responsible for risk assessment and risk mitigation. Everyone
associated with the project is responsible for identifying and reporting potential risks to the
Project Manager to allow for assessment and mitigation.
3.4 Metrics
3.4.1 Metrics on all project activities will be gathered and reported to Management. This includes
Project Management Support activities as well as development activities.
3.4.2 Metrics will be used to provide objective information on project schedule, resources, costs,
requirements, work product sizes and changes, and product quality. Metrics will NOT be
used for motivation, punishment, or evaluation of individual or workgroup performance.
3.5 Project Repository
3.5.1 Projects must establish and maintain a repository for all project-related information in a
centralized, known, and accessible location. In the event that information from supporting
and stakeholder organizations is maintained outside the project purview, the project may
reference the required information rather than duplicate the information.
3.5.2 The project repository will contain or reference the most current project/release information
using version control.
3.5.3 All work products must be maintained or referenced in the project repository using version
control. The tracking method for referenced products will need to be negotiated with the
product owner. The project will document the referenced product tracking method.
3.5.4 Information reported for all meetings (agendas, minutes, action item lists, etc.) must be
maintained in the project repository.
3.5.5 Project lessons learned meetings will be planned and scheduled. Lessons learned will be
documented, updated, and reported for use in future projects and releases.
3.5.6 Before a system or an enhancement to a system can be moved into production, all system
documentation must be completed or amended, verified, and approved. Final user
documentation and training materials may be completed after implementation.
3.6 Project Management Training
3.6.1. The members of all affected organizations responsible for project management activities will
Peace Corps 36
December 03, 2009
3.6 Project Management Training
be trained in the objectives, procedures, and methods for performing their project planning,
estimating, tracking, and monitoring activities.
3.6.2 Project Managers will be trained in managing the technical and personnel aspects of the
project.
3.6.3 Project Team members will be provided an orientation in the technical aspects of the project.
A.4 Quality Assurance Policies

Quality Assurance (QA) is a planned and systematic methodology for assessing, monitoring, and
improving the quality of a project‘s work products. QA provides a controlled process to review
and audit independently the project work products as well as the processes and procedures used
to produce them. QA verifies that all work products, processes, and procedures, comply with
applicable, documented standards. QA staff provides project staff and senior managers with the
results of these reviews and audits.
This section establishes the grounding for the mechanisms and procedures needed to ensure that
Peace Corps can produce quality products in a repeatable manner. Everyone on the project is
responsible for the quality of the project‘s results. The specified QA Team‘s function is to
review, advice, and verify plans, processes, procedures, activities, and products to help the
project achieve its quality goals and resolve any quality concerns.
Goals
The goals of QA are to:
 Establish and implement QA plans and procedures for the project‘s work products and
processes at the project level
 Objectively review, audit, and document the project work products, processes, and
activities to ensure that they meet all applicable standards and requirements
 Provide management with visibility into the development processes used by the projects
 Ensure that both the new or changed system is compatible with and works with existing
systems.
4.1 Project QA
4.1.1 All projects will plan, perform, document, track, and measure project QA activities during the
entire life cycle of the project. All QA activities will be performed based on a documented and
approved Project QA Plan.
4.1.2 A Project QA Team within the project will be identified and will be responsible for coordinating,
implementing and verifying project QA activities. They will periodically report the results of
their activities to the Project Team.
4.1.3 The results of QA activities will not be used to evaluate the performance of individuals.
4.1.4 Peer reviews will be planned and used to review work products as early in the development life
cycle as possible.
Peace Corps 37
December 03, 2009
4.1 Project QA
4.1.5 Formal reviews and signoffs will be performed. At minimum, these will occur: to certify
requirements, to verify system design, before transition to acceptance testing, and before
moving the system to production.
4.1.6 The Project QA Team will identify and document processes and procedures in their QA Plan to
account for deviations in project activities and work products.
4.2 Organizational QA
4.2.1 There will be a QA Organization with an independent reporting chain to management.

4.2.2 The QA Organization will provide guidance to Project QA Teams for planning Project QA
activities.
4.2.3 The QA Organization will periodically monitor Project QA activities and documents. Deviations
and compliance issues identified in project products or processes will be documented and
reported first to the Project Team and escalated, if necessary, to succeeding levels of
Management.
4.2.4 Experts independent of the QA Organization will periodically review the activities and work
products of the QA Organization.
4.3 Product Testing
4.3.1 Testing will be conducted to ensure that the delivered product meets the certified requirements
and does not adversely affect existing software and systems.
4.3.2 All development teams will conduct and document unit and integration testing. Developers
must include test cases and test results for all security features and requirements.
4.3.3 The Project QA Team will monitor unit-, integration-, security-, and system-level testing.
4.4 Independent Testing
4.4.1 Systems Acceptance Testing (SAT), Security Testing, and User Acceptance Testing must be
performed independent of the development process. All independent testers will document
their test results.
4.4.2 All documentation provided to the independent testers will be clear, concise, and complete.
4.4.3 Testing will be performed in accordance with documented Test Plans.
4.4.4 The Business Sponsor must verify that the user documentation and training materials are
acceptable and accurate.
4.5 QA Training
4.5.1 Members of the QA Organization and Project QA Team will be trained in the objectives,
procedures, and methods for performing their QA activities.
Peace Corps 38
December 03, 2009
4.5 QA Training
4.5.2 Members of the Project Team will receive orientation on the role, responsibilities, authority,
and the QA Organization activities.
4.5.3 The members of all affected organizations responsible for testing will be trained in the
objectives, procedures, and methods for performing their testing activities.
A.5 Configuration Management Policies

Configuration Management (CM) establishes and maintains configuration items (CI) integrity
across the project. Configuration items are the hardware, software and documentation
components related to a project. Work product and system security posture integrity is achieved
through the identification of the configuration items and the systematic control of changes to
them. From the baseline, changes to CIs are managed via the change control and audit
procedures.
Goals
The goals of CM are to ensure that:
 CM activities are planned
 Selected work products are identified, tracked, controlled, and available from the CM
repository
 Changes to identified work products are controlled and documented. The versions of
each work products must be clearly identified so that appropriate security updates can be
applied
Affected groups and individuals are informed of the status and content of the project‘s
baselines.
Security profiles and systems‘ security is maintained throughout the changes.
5.1 General CM Precepts
5.1.1 CM will be planned and used throughout the entire life cycle. Project CM activities will be
performed in accordance with a documented and approved Project CM Plan.
5.1.2 All projects will designate an internal Project Configuration Manager who will be responsible
for planning, performing, and verifying internal Project CM activities and for coordinating
with the CM Organization.
5.1.3 All CM activities will be conducted in accordance with the appropriate Peace Corps CM
(CM) Plans.
5.1.4 Work products to be placed under CM will be identified, controlled, and base lined.
5.1.5 Products will be created from the project‟s base lined as maintained in the CM repository.
CM will control their release according to a documented procedure.
5.1.6 CM will be applied to identify work products, including all tools and components needed to
recreate the previous version of the configuration item.
5.1.7 The Project CM Team will create, maintain, and implement a Project CM Plan that defines a
Peace Corps 39
December 03, 2009
5.1 General CM Precepts
set of internal CM procedures, CM activities and specific project staff responsibilities.

5.1.8 The Project Manager, in consultation with CM is responsible for the Project CM Plan
approval and for incorporation of the CM activities into the overall Project Plan.
5.1.9 If a modeling tool is used, project CM procedures will be developed and documented to
handle versions of the same model.
5.1.10 Ramifications to the system security will be considered for all proposed changes.
5.2 Migration
5.2.1 Only properly authorized, tested, and approved hardware, system software, applications,
and application changes will be moved into the Production environment.
5.2.2 The Project CM Team is responsible for providing the QA Organization with a change
package that contains a complete list of all items to be implemented.
5.2.3 The CM Organization is the only group authorized to migrate applications and application
changes into Testing at the request of the Tester and then into the Production and the
Education environments upon approval by the Business Sponsor.
5.2.4 Projects that meet one or more of the emergency definition criteria are moved into
Production upon the approval of the Testers outside of the regularly scheduled application
migration periods.
5.2.5 Emergency project moves will follow currently established emergency procedures.
5.3 Change Control
5.3.1 A Project Change Control Board (CCB) will be established having the authority for
managing the project's baselines. The CCB will record, review, approve/disapprove,
prioritize, and track change requests and problem reports for all configuration items/units.
5.3.2 If additional functionality needs to be added, a change request will be initiated and tracked.
5.3.3 Changes to baselines will be controlled according to a documented procedure.
5.4 Audits and Status Reporting
5.4.1 The Project CM Team will record the status of project elements.
5.4.2 Each project will produce standard reports covering their CM activities and baseline
contents. Copies of these reports will be made available to all affected groups and
individuals.
5.4.3 The CM Organization will record and report status of the Production baselines.
5.4.4 Project CM will gather, collect, and report metrics to determine the status of its CM
activities.
5.4.5 A group external to the Project CM Team will periodically audit baselines and verify that
they conform to the documentation that defines them.
5.4.6 CM processes and activities will be reviewed in accordance with Project Monitoring, QA,
and security policies.
Peace Corps 40
December 03, 2009
5.5 CM Training
5.5.1 The members of all affected organizations responsible for performing CM-related activities
will be trained in the objectives, procedures, and methods for performing their CM activities.
5.5.2 Members of the CM Organization and the Project CM Team will be trained in the objectives,
procedures, and methods for performing their CM activities.
5.5.3 Members of the Project Team and other software-related groups will be trained to perform
their CM activities.
5.6 Libraries and Repositories
5.6.1 There will be separate and distinct libraries for all environments (development, test,
education, production, etc.).
5.6.2 A CM library system will be established as a repository for each project for software and
documentation baselines.
Peace Corps 41
December 03, 2009
A.6 IT Security Requirements in the SDLC

A.6.1 Introduction to IT SECURITY
Peace Corps has become increasingly reliant on IT systems to support day-to-day and critical
operations. Risks to systems and data availability, integrity, and confidentiality can impact
Peace Corps‘ ability to support its mission or to ensure the safety and security of Peace Corps
volunteers and staff. Adhering to good IT security processes—risk management—throughout
the SDLC allows Peace Corps to identify weaknesses in programs, processes, and IT systems;
take actions to prioritize and cost-effectively mitigate those weaknesses; and, continue to
monitor the Peace Corps‘ IT systems‘ environment and security controls to detect changes to the
security posture. When applied appropriately and with due diligence, risk management assists
Peace Corps in meeting the Federal Information Security Management Act (FISMA)
requirements of ―providing information security protections commensurate with the risk and
magnitude of the harm resulting from unauthorized access, use, disclosure, disruption,
modification, or destruction of information and information systems‖ collected by and used by
the federal government and ―ensuring that information security management processes are
integrated with agency strategic and operational planning processes.‖ Risk management for a
system starts with the Concept and Business Case Stage of the Peace Corps SDLC and continues
through to the Disposition/Disposal/Retirement Stage.
A.6.2 Overview of IT SECURITY in the SDLC
Peace Corps‘ IT security policies and requirements are intended to protect Peace Corps
information and IT assets from harm. These assets include the electronic data, software,
hardware, networks, people, and facilities needed to gather, store, process, and transmit Peace
Corps information in electronic form. The environment in which these IT systems operate must
provide some physical, personnel, and administrative controls. Technical controls must be
incorporated into the design and development of the IT system‘s software, architecture, and
infrastructure. The security requirements cited in this handbook are detailed in Peace Corps
Manual Section (MS) 542: Peace Corps IT Security Policies, and the supporting Information
Technology Security Requirements (ITSRs).
Goals
The overall goals of IT Security are to:
 Ensure the safety and security of Peace Corps Volunteers and Staff by protecting their
information
 Manage and mitigate risk to an appropriate level
 Ensure that appropriate security controls are in place and functioning as intended
 Ensure management is fully informed of the security risk mitigations and residual
security risk of their IT system
 Provide assurances that IT security features work as claimed and cannot be easily
defeated
Peace Corps 42
December 03, 2009
 Ensure that the IT system has reasonable security controls to appropriately preserve the
data‘s integrity, availability, and confidentiality.
Appendix A.6 - Figure 3: IT Security throughout the SDLC
Peace Corps 43
December 03, 2009
Security is an ongoing process, from business concept to disposal. IT security activities are
interwoven throughout the Peace Corps‘ nine SDLC stages and result in the specific security
outputs highlighted in the SDLC and required by various Peace Corps ITSRs. Figure 3, above,
depicts this relationship. Incorporating risk management activities during the appropriate stages
of the SDLC, culminating in the certification and accreditation (C&A) of the system, reduces the
duplication of effort in developing and documenting the security plans and procedures required
by both the SDLC and the IT security process. The remainder of this appendix will show the
interrelationships between the stages of the Peace Corp SDLC and IT Security, and the points
where key IT security risk management products are developed. For additional detail on Peace
Corps IT Security Requirements, please reference MS 542 and the ITSRs.
A.6.3 IT Security At Each Stage of the SDLC
Stage 1: Concept and Business Case
IT Security Objectives for the Concept and Business Case Stage

 Identify how secure the proposed concept needs to be based on the sensitivity of the
information and the importance of the system.
 Identify technology and design concepts needed to secure the system.

Appendix A.6 - Table 11: IT Security Tasks and Activities for the Concept and Business Case Stage
IT Security Tasks and Activities for the Concept and Business Case Stage
Task/Activity Document Notes
Identify security Information Type IT system and data criticality and sensitivity must be
categorization of Worksheet considered in preparation for formally describing the system‟s
IT system and its security categorization in terms of the IT system‟s
data availability, integrity, and confidentiality requirements. It is
within this stage that the impact levels defined in Federal
Information Processing Standard (FIPS) 199 are determined
and the overall security categorization of the system is
identified “based on the system‟s use, connectivity, and
aggregate information content”. The security categorization,
which can be low, moderate, or high, plays a role in
determining the levels of effort required to secure the IT
system and the information it will handle. The security
categorization aids in appropriately scoping the initial set of
minimum baseline security controls required for the system
from National Institute for Standards and Technology (NIST)
Special Publication (SP) 800-53 during the next SDLC stage
to fit the specific system security environment. The security
categorization is determined by using the Information Type
Identification Instructions and Worksheet as part of the
Project Information Form (PIF) process.
Peace Corps 44
December 03, 2009
IT Security Tasks and Activities for the Concept and Business Case Stage
Assess the Business Impact The business impact assessment incorporates what is
potential business Assessment known about the IT system; its business function; the data it
impact of the IT will process, transmit, and store; and, its proposed
system environment to identify the availability requirements of the
system, and the related recovery time objective (how quickly
a system needs to be restored after a disruption) and
recovery point objective (the amount of data loss that can be
tolerated after a disruption). The business impact
assessment process is a key input to the Agency‟s IT
disaster recovery planning process. The quick business
impact assessment incorporated into the PIF is maintained
by the IT Disaster Recovery Plan Coordinator and provides
key availability and recovery requirements information to the
IT system Project Team, which may impact design decisions,
architecture and cost analysis for the system. The business
impact assessment will also contribute to IT contingency
planning for the IT system. For additional guidance see
Peace Corps ITSR for System and Services Acquisition.
Evaluate the size Project Sizing Project Sizing Worksheet helps identify the specific SDLC
or complexity of requirements for a project. Information identified during
the project project sizing that is relevant to the IT system‟s security
posture includes: whether this is a new IT system or an
enhancement to an existing IT system; if the project involves
a Major Application or a General Support System; and, if the
project is an enhancement to a current system, whether this
will be a significant change to the system requiring re-
certification and accreditation.
Identify the Preliminary Risk The boundaries of the IT system are identified to delineate
system‟s security Assessment the accreditation boundaries for the system and the
boundary associated security responsibilities.
Identify and Preliminary Risk The Preliminary Risk Assessment is performed in the two
assess the Assessment initial stages of the SDLC, and updated during the
potential risks to subsequent two stages as more details about the IT system
the IT system are defined. This is to ensure that the security requirements
of the IT system for integrity, availability, and confidentiality
are identified along with the minimum baseline security
controls. Early identification of system specific risks and
security requirements enables the requisite security controls
to be fully integrated into the IT system‟s design and
architecture. In order to identify system-specific threats to
and vulnerabilities of a particular IT system in its
environment, a Preliminary Risk Assessment is performed
following NIST SP 800-30 and Peace Corps ITSR for Risk
Assessments. The Preliminary Risk Assessment contains a
level of detail equivalent to the system definition and what is
known about the IT system. For additional guidance see
Peace Corps ITSR for Risk Assessment.
Peace Corps 45
December 03, 2009
Stage 2: Initiation and Authorization
IT Security Objectives for the Initiation and Authorization Stage

 Identify if system security can be provided in a cost-effective manner.
 Determine if the technology and infrastructure are available to support the security
requirements of the system.
 Ensure all security costs are identified and included in funding authorization

Appendix A.6 - Table 12: IT Security Tasks and Activities for the Initiation and Authorization Phase
IT Security Tasks and Activities for the Initiation and Authorization Stage
Identification and Security Control Incorporate what is known about the system, its data, and its
scoping of Requirements proposed environment with the system‟s security
baseline security Matrix categorization and preliminary risk assessment to begin the
controls (Includes process of identifying and scoping the baseline security
managerial, controls. NIST SP 800-53 and Peace Corps ITSRs provide
operational, and guidance on the required baseline security controls; the
technical security objective of this guideline is to standardized the selection of
controls.) security controls and maintain consistency across the
Agency, while allowing flexibility for tailoring the security
controls to fit the specific IT system‟s requirements. Through
this process the baseline security controls are refined,
tailored, or augmented to fully address the protection needs
of the system.
Understanding that the security controls identified based on
an IT system‟s security categorization and NIST SP 800-53
are the minimum controls necessary for a particular system, it
should be recognized that there may be a need for additional
security controls beyond the minimum that protect against
specific, unique threats possibly exploiting system
weaknesses, or vulnerabilities.
Analyze cost of Security Control Security Control Cost Analysis is required once the
implementing Cost Analysis baseline security controls have been identified and tailored.
security controls Federal reporting requires that IT security expenditures for IT
systems be identified as a separate line item. Performing the
security control cost analysis at this stage in the SDLC
enables evaluation of the project‟s security requirements from
a security cost perspective, and facilitates early consideration
of design and architecture options that may have a dramatic
impact on project cost. The security control cost analysis is
typically requested by the EAAB.
Refine the system Preliminary Risk The boundaries of the IT system are update to reflect what is
boundary Assessment known about the system.
definition
Peace Corps 46
December 03, 2009
IT Security Tasks and Activities for the Initiation and Authorization Stage
Refine and update Preliminary Risk The Preliminary Risk Assessment is updated to ensure
Preliminary Risk Assessment that it contains a level of detail equivalent to the system
Assessment definition and what is known about the IT system. For
additional Guidance see Peace Corps ITSR for Risk
Assessment.
Stage 3: Project Definition
IT Security Objectives for the Project Definition Stage

 Identify complete set of IT Security Requirements for the system.
 Finalize system boundary to ensure clear understanding of scope of security
responsibility.
 Receive approval from the IT system‘s Accreditation Official for the IT Security
Requirements and acceptable risk level.

Appendix A.6 - Table 13: IT Security Tasks and Activities for the Project Definition Stage
IT Security Tasks and Activities for the Project Definition Stage

Approve the Authorizing While much of the security control requirements selection
baseline security Official approval and refinement process was accomplished in Stage 2,
controls (Includes of IT Security Initiation and Authorization, the set of baseline security
managerial, Requirements controls are reviewed and finalized during the Project
operational, and and Risk Level Definition stage of the SDLC. This set of controls represents
technical security the security posture of the system to which the system will be
controls.) designed. Based on the identified and scoped minimum
baseline security controls, the Security Control
Requirements for Technical Controls and Security
Control Requirements for Operational and Managerial
Controls are developed. The IT security requirements will
be used by the design team to ensure that the IT system
being developed meets its security control requirements, in
the same way that functional requirements would be used to
make certain the IT system being developed meets the user
requirements for system functionality. The Security Control
Requirements must be approved by the IT system‟s
Authorizing Official to ensure that the planned security
controls are acceptable in terms of the sensitivity of the
system, importance of the system, and acceptable risk-level.
Finalize the Preliminary Risk At this stage the system boundaries must be finalized to
system boundary Assessment enable progression to the next stage. For additional
definition Guidance see Peace Corps ITSR for Planning.
Peace Corps 47
December 03, 2009
IT Security Tasks and Activities for the Project Definition Stage

Document the System Security  Once the baseline security controls have been
planned security Plan selected for the system, and the security control
controls for the requirements for the Technical, Operational and
system Managerial controls have been certified by the
Authorizing Official, the „guide‟ to the IT system‟s
security posture is documented in the System
Security Plan (SSP). This is a major risk
management product that documents all of the
information about the system, including: its
boundaries; unique system identifier; and, system
description; identifies responsibility for the system, its
operations, and its security; IT System Owners must
identify preventative controls to incorporate into their
IT system‟s architecture and operations to mitigate or
eliminate disruption impacts. Examples of
preventative controls include an Uninterruptible
Power Supply (UPS); frequent, scheduled backups;
dual, load balanced servers with failover capability;
failover circuits; redundant data pathways; and, least-
privilege access controls. (Absolute)
 About the system; describes the hardware and
software; and, the system‟s security controls
implemented to protect the system. The early
versions of the SSP may require the documentation
of many planned controls for the system versus
implemented controls simply because the system
has not progressed far enough along its life cycle.
The SSP should be updated through the design and
development stages. Also, the content of the SSP is
scalable, similar to the risk assessment process,
based on the system‟s FIPS 199 security
categorization, size, cost, and complexity. For
additional Guidance see Peace Corps ITSR for
Planning.
Stage 4: System Design
IT Security Objectives for the System Design Stage

 Identify how each Peace Corps IT security requirement will be met.
 Demonstrate that the design will meet acceptable level of risk and security requirements.
 Identify management and operational practices needed for security.
 Determine security impact on other systems, Peace Corps security architecture.
 Develop plan for implementing security during development.
 Select security cost/benefit trade-offs.
Peace Corps 48
December 03, 2009

Appendix A.6 - Table 14: IT Security Tasks and Activities for the System Design Stage
IT Security Tasks and Activities for the System Design Stage

Incorporate System Security The stage where all of the system‟s requirements are
security Design Plans translated into concrete design plans. The security control
requirements into implementation for each control is considered to ensure that
system design the requirements of the defined security controls, based on
the requirements for technical, operational, and managerial
security controls, are fully addressed in the system design.
Potential implementations are evaluated against the security
control requirements matrix, potential conflicts with other
implementations are evaluated, and technical feasibility is
determined. The selected implementations for security
controls are then integrated into the system‟s design and are
treated as functional requirements. For additional guidance
see all applicable ITSRs.
Continue System Security The System Security Plan documents all of the information
documenting the Plan about the system, including: its boundaries; unique system
planned security identifier; system description responsibility for the system, its
controls for the operations and its security, provides identifying information
system about the system, describes the hardware and software, and,
the system‟s security controls implemented to protect the
system. The SSP should be updated through the design and
construction stages. For additional Guidance see Peace
Corps ITSR for Planning.
Initiate IT IT Contingency IT contingency planning is initiated to ensure that any
contingency Plan measures to enable appropriate availability, integrity, or
planning for the (may be a part of the confidentiality are integrated into the design or architecture of
system SSP) the system. Contingency planning also extends to
operational and managerial controls. Any events that cannot
be adequately addressed via contingency controls integrated
into the technical, operational, or managerial controls must
be addressed via the IT Contingency Plan. For additional
Guidance see Peace Corps ITSR for Contingency Planning.
Initiate IT Contingency The IT Contingency Plan is activated only when a system
development of an Plan Test Plan disruption occurs, therefore it is important to develop and
IT Contingency execute an IT Contingency Plan Test Plan to ensure that
Plan Test Plan for the IT Contingency Plan will be effective in the event of a real
the system system disruption and be capable of supporting the
availability and recovery requirements of the system.
Information and system backups, responses to adverse
events, and restoration of operations are considered at this
early stage so that should the system‟s security design need
to include additional contingency controls, they can be
incorporated into the design. The contingency plan will be
updated as the system progresses towards operational
readiness, and at least annually once the system is in
operations. For additional Guidance see Peace Corps ITSR
for Contingency Planning.
Peace Corps 49
December 03, 2009
IT Security Tasks and Activities for the System Design Stage

Initiate incident Incident In the same vein that IT contingency planning starts with the
response planning Response Plan design phase, so does the development of the IT system‟s
(may be a part of the Incident Response Plan. An incident is not limited to an
SSP) event that causes a system disruption. Incidents include
malicious code executing on the system; unauthorized use or
access of the system; accidental data disclosure; or,
data/hardware theft. The Incident Response Plan must detail
how each type of incident will be handled. For additional
Guidance see Peace Corps ITSR for Incident Response.
Develop IT IT Security The IT Security Training Plan must address the security
security training Training Plan training requirements of general system users, privileged
plan (may be a part of the users, and users with significant security responsibilities.
SSP) The training plan must include both initial training, prior to
granting system access, and annual refresher training. For
additional Guidance see Peace Corps ITSR for Awareness
and Training.
Identify Data Storage, As a part of the design process the long term storage,
requirements for Retention, archiving, and record retention requirements of the IT
preserving or Disposal Plan system must be defined. The IT system‟s requirements in
destroying system (may be a part of the terms of storage, archiving, and retention will depended on
data SSP) the type of information being processed, transmitted or stored
by the system and the federal regulations and Peace Corps
policy governing that information. For additional Guidance
see Peace Corps ITSR for Media Protection and Peace
Corps Media Sanitization procedures.
Initiate the Security The development of the Security Assessment Test Plan
development of a Assessment Test follows the Security Requirements Traceability Matrix to
security Plan ensure that all planned security controls are testable and
assessment test tested. The Security Assessment Test Plan will be used
plan during the Testing and Acceptance stage to ensure the
security control requirements are both implemented and
functioning as intended. For additional guidance see Peace
Corps ITSR for Certification, Accreditation, and Security
Assessments.
Begin to track Plan of Action The IT system‟s Plan of Action and Milestones documents
plans and and Milestones all IT security controls that are planned for the IT system, but
milestones for the that will not be implemented prior to the IT system moving to
IT system the Operations stage or within 30 days if the IT system is
already in operations. For additional guidance see Peace
Assessments.
Assess security System Security Identify alternatives for meeting each security requirement
controls and costs Plan and System and select most cost-effective. Use the selected methods in
for potential trade- Security Design the system design. Example: Encryption products, back-up
offs. Plans methods, firewall locations.
Peace Corps 50
December 03, 2009
Stage 5: Construction
IT Security Objectives for the Construction Stage

 All security requirements are implemented in hardware, software, operating procedures
or by other means.
 Complete information is known to allow construction of the full system security plan and
risk assessment.
 QA process (code review, peer reviews, walk-throughs, change management, version
management) ensure the integrity of the system and its data.
 A Security Assessment Test Plan is developed that can prove the security requirements
have been met.

Appendix A.6 - Table 15: IT Security Tasks and Activities for the Construction Stage
IT Security Tasks and Activities for Construction Stage

Continue System Security The System Security Plan should be updated throughout
documenting the Plan the design and construction stages. The System Security
planned security Plan should reflect technical, operational, and managerial
controls for the controls. For additional guidance see Peace Corps ITSR for
system Planning.
Initiate full Full Risk The full Risk Assessment is an evolution of the Preliminary
assessment of Assessment Risk Assessment; however, the full Risk Assessment is
risks evaluating the implemented security controls. The non-full
Risk Assessment is performed in accordance with the
guidelines in NIST SP 800-30 and Peace Corps ITSR for
Risk Assessments.
Continue IT IT Contingency IT Contingency Planning is initiated to ensure that any
contingency Plan measures to enable appropriate availability, integrity, or
planning for the (may be a part of the confidentiality are integrated into the design or architecture of
system SSP) the system. Contingency planning also extends to
operational and managerial controls. Any events that can not
be adequately addressed via contingency controls integrated
into the technical, operational, or managerial controls must
be addressed via the IT Contingency Plan. For additional
guidance see Peace Corps ITSR for Contingency Planning.
Continue IT Contingency The IT Contingency Plan is activated only when a system
developing an IT Plan Test Plan disruption occurs, therefore it is important to develop and
Contingency Plan execute an IT Contingency Plan Test Plan to ensure that
Test Plan for the the IT Contingency Plan will be effective in the event of a real
system system disruption and be capable of supporting the
availability and recovery requirements of the system. For
additional guidance see Peace Corps ITSR for Contingency
Planning.
Peace Corps 51
December 03, 2009

Initiate testing of IT Contingency Beginning the testing of the IT Contingency Plan during the
the IT Plan Test Report System Design Phase enables adjustments to the system
Contingency Plan design based on any corrective actions, lessons learned,
revisions, or recommendations identified through the test
activity. For additional Guidance see Peace Corps ITSR for
Contingency Planning.
Begin testing and IT Contingency Following the IT Contingency Plan Test Plan test the IT
evaluating the IT Plan Test Report Contingency Plan to ensure that it will be effective in the
Contingency Plan event of a real system disruption and be capable of
supporting the availability and recovery requirements of the
system. While conducting the test and after the test, capture
in the IT Contingency Test Plan Report all corrective
actions, lessons learned, revisions, or recommendations
identified through the test activity. For additional guidance
see Peace Corps ITSR for Contingency Planning.
Continue incident Incident In the same vein that IT contingency planning starts with the
response planning Response Plan design phase, so does the development of the IT system‟s
(may be a part of the Incident Response Plan. An incident is not limited to an
SSP) event that causes a system disruption. Incidents include
malicious code executing on the system, unauthorized use,
or access of the system, accidental data disclosure, or
data/hardware theft. For additional guidance see Peace
Corps ITSR for Incident Response.
Develop IT IT Security The IT Security Training Plan must address the security
security training Training Plan training requirements of general system users, privileged
plan (may be a part of the users, and users with significant security responsibilities. For
SSP) additional guidance see Peace Corps ITSR for Awareness
and Training.
Document System Security The long term storage, archiving, and record retention
requirements for Plan requirements of the IT system must be defined and
preserving or documented in the system‟s SSP. The IT system‟s
destroying system requirements in terms of storage, archiving, and retention will
data depended on the type of information being processed,
transmitted or stored by the system and the federal
regulations and Peace Corps policy governing that
information. For additional guidance see Peace Corps ITSR
for Planning.
Continue Security As the system progresses through the construction phase,
development of a Assessment Test the Security Assessment Test Plan will evolve to ensure the
security Plan security assessment test scripts will effectively test that
assessment test planned security controls are both implemented and
plan functioning as intended. For additional Guidance see Peace
Assessments.
Peace Corps 52
December 03, 2009

Continue to track Plan of Action The IT system‟s Plan of Action and Milestones documents
plans and and Milestones all IT security controls that are planned for the IT system, but
milestones for the that will not be implemented prior to the IT system moving to
IT system the Operations stage or within 30 days if the IT system is
already in operations. For additional guidance see Peace
Assessments.
Stage 6: Testing and Acceptance
IT Security Objectives for the Testing and Acceptance Stage

 The Security Assessment Test shows that the security requirements have been met.
 The Certification Agent may perform additional testing to validate the Security
Assessment Test results and verify that the desired risk level has been achieved.
 The Plan of Action and Milestones is updated to address remaining weaknesses.
 The System Security Plan and full Risk assessment are updated based the results from the
Security Assessment Test and any additional testing.
 The Certification Agent certifies to the Authorizing Official that all security documents
are complete and accurate and that the desired risk level has, or has not, been reached.

Appendix A.6 - Table 16: IT Security Tasks and Activities for the Testing and Acceptance Stage
IT Security Tasks and Activities for the Testing and Acceptance Stage
Finalize the System Security The System Security Plan documents all of the information
planned security Plan about the system, including: its boundaries; unique system
controls for the identifier; system description responsibility for the system, its
system operations and its security, provides identifying information
about the system, describes the hardware and software, and,
the system‟s security controls implemented to protect the
system. The SSP should be updated throughout the life of
the system. For additional guidance see Peace Corps ITSR
for Planning.
Finalize the IT IT Contingency The IT Contingency Plan Test Plan will test the
contingency plan Plan Test Plan effectiveness of the IT Contingency Plan in supporting the
test plan for the availability and recovery requirements of the system. The
system Test Plan must be finalized so that it can be executed during
this stage. For additional guidance see Peace Corps ITSR
for Contingency Planning.
Peace Corps 53
December 03, 2009
Conduct the IT IT Contingency Follow the IT Contingency Plan Test Plan to test the IT
Contingency Plan Plan Test Report Contingency Plan and ensure that it will be effective in the
Test Plan event of a real system disruption and be capable of
supporting the availability and recovery requirements of the
system. While conducting the test and after the test, capture
in the IT Contingency Test Plan Report all corrective
see Peace Corps ITSR for Contingency Planning.
Update IT IT Contingency The updated IT Contingency Plan should incorporate or
contingency plan Plan address all corrective actions, lessons learned, revisions, or
for the system (may be a part of the recommendations identified through the test activity. For
SSP) additional guidance see Peace Corps ITSR for Contingency
Planning.
Finalize incident Incident Before moving through testing, the system‟s Incident
response plan Response Plan Response Plan must be complete. For additional guidance
(may be a part of the see Peace Corps ITSR for Incident Response.
SSP)
Finalize IT security IT Security The IT Security Training Plan must be finalized to address
training plan Training Plan the security training requirements of general system users,
(may be a part of the privileged users, and users with significant security
SSP) responsibilities before the system can move to the
Operational Ready Stage, when the training must begin to be
delivered. For additional guidance see Peace Corps ITSR for
Awareness and Training.
Document System Security The long term storage, archiving, and record retention
requirements for Plan requirements of the IT system must be defined and
preserving or documented in the system‟s SSP along with media
destroying system sanitization procedures. For additional guidance see Peace
data Corps ITSR for Planning and Media Protection. For System
of Records information refer to the Freedom of Information
Act and Privacy Act Office.
Complete and Security The complete Security Assessment Test Plan should have
conduct the Assessment Test a test case to test every security requirement in the Security
security Plan Requirements Traceability Matrix. It should be noted that
assessment test testing of security controls during this stage includes review
plan of system and security documentation, such as the SSP, risk
assessment, IT contingency plan, and security training plans.
For additional guidance see Peace Corps ITSR for
Certification, Accreditation, and Security Assessments.
Prepare security Security The Security Assessment Report provides verification if all
assessment report Assessment planned security controls are implemented and functioning as
Report intended. Corrective actions recommended in the Security
Assessment Report must be implemented, added to the
POA&M, or determined to be an acceptable risk. For
additional guidance see Peace Corps ITSR for Certification,
Accreditation, and Security Assessments.
Peace Corps 54
December 03, 2009
Continue to track Plan of Action The IT system‟s Plan of Action and Milestones (POA&M)
plans and and Milestones should reflect all corrective actions identified during testing to
milestones for the ensure that mitigation of these corrective actions is
IT system appropriately managed. For additional guidance see Peace
Assessments.
Complete full Full Risk The full Risk Assessment documents the security posture of
assessment of Assessment the system in terms of implemented security controls,
risks acceptable risk, and residual risk.
Prepare the Certification The system‟s certification is prepared for review by the
Certification Package Certification Agent. The package must include: System
Package Security Plan, Full Security Risk Assessment, Security
Assessment Report, IT Contingency Plan, Incident Response
Plan, System Interconnection Agreements, Plan of Actions
and Milestones, and Privacy Impact Assessment. For
additional guidance see Peace Corps ITSR for Certification,
Accreditation, and Security Assessments.
Document Certification The Certification Agent must document their recommendation
certification Recommendation for the Authorizing Official. Recommendation can be to
recommendation authorize, deny, or interim authorize the system for
operations. This recommendation is included with the
Certification package. For additional guidance see Peace
Assessments.
Stage 7: Deployment Readiness
IT Security Objectives for the Deployment Readiness Stage

 The Authorizing Official must receive certification of whether the system has met
security requirements.
 The Authorizing Official makes a risk-based decision that the system is ‗secure enough‘,
and takes personal responsibility for allowing the system to operate.
 An Authorization to Operate (ATO) is issued if the Authorizing Official is satisfied with
the security posture of the system; or an Interim ATO is issued if there are significant
issues to be addressed before the system is considered ‗secure enough‘.
 If the system is not granted an ATO or an Interim ATO, under federal regulation and
Peace Corps policy the system may not be put into operations.
Peace Corps 55
December 03, 2009

Appendix A.6 - Table 17: IT Security Tasks and Activities for the Deployment Readiness Stage
IT Security Tasks and Activities for the Deployment Readiness Stage

Ensure funding is System Budget The system‟s budget must have a security line item that
secured for includes any products, procedures, or personnel (federal
system security employees and contractors) that are primarily dedicated to or
during operations used for the provision of IT security.
Provide IT IT Security All IT system users must receive IT security training before
Security Training Training Plan being granted access to the system. IT security training will
must occur prior to carrying out security duties or using any
security features. For additional guidance see Peace Corps
ITSR for Awareness and Training.
Review Accreditation The Authorizing Official for the system must review the
Certification Memo Certification Package and the Certification Recommendation
Package and in order to make a risk-based decision on whether the system
make decision on is „secure enough‟‟. The Authorizing Officials decision is
authorization to documented in the Accreditation Memo. The Accreditation
operate memo documents the official management decision given by
a senior agency official to authorize operation of a 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 the
certified security controls. For additional guidance see
Peace Corps ITSR for Certification, Accreditation, and
Security Assessments.
Stage 8: Operations
I T Security Objectives for the Operations Stage

 Continuous monitoring of the system, its environment, the threat environment, and
technology to verify that it is maintaining the desired security posture.
 Periodic tests and audits to verify that the security controls are working, being followed,
and that no vulnerabilities have crept into the system
 A detailed re-examination of the system every three years for re-accreditation
 Quarterly and annual reporting to demonstrate to Congress that Peace Corps is meeting
its security obligations
Peace Corps 56
December 03, 2009

Appendix A.6 - Table 18: IT Security Tasks and Activities for Operations Stage
IT Security Tasks and Activities for Operations Stage

Perform Audit Logs, As part of continuous monitoring there should be monitoring
continuous Change for intrusions and unauthorized access attempts; patching
monitoring Management and updates as necessary; review of change requests for
Requests, and security impact; and, periodic self-assessments and
other Reports vulnerability scans. For additional guidance see Peace
impacting Corps ITSR for Audit and Accountability, Incident Response,
security and other relevant ITSRs.
At least annually System Security System security documentation must be kept current to
review and update Plan, IT accurately reflect the current state of the system. Security
applicable system Contingency documents must be reviewed at least annually or with any
security Plan, Incident significant change to the system and updated to reflect any
documentation Response Plan, changes. The SSP is a living document and should be
etc. updated periodically, as needed, to maintain a current and
accurate picture of the system‟s security posture. For
additional guidance see applicable Peace Corps ITSRs.
Provide annual IT Record of IT security refresher training must occur at least annually.
Security refresher Security Training For additional guidance see Peace Corps ITSR for
Training Awareness and Training.
Follow Media From the security perspective, media such as tapes, disks,
requirements for Sanitization Form and paper may be disposed of during the operations phase.
media sanitization Portions of a system may also require disposal during
upgrades or due to a component failure. For additional
guidance see Peace Corps ITSR for Media Protection and
the Media Sanitization Procedures.
Test IT IT Contingency Annually an IT Contingency Plan test exercise must be
Contingency Plan Plan Test Plan conducted, including an after action report and the
incorporation into the IT Contingency Plan of corrective
see Peace Corps ITSR Contingency Planning.
Update system Plan of Action & The system‟s Plan of Action and Milestones (POA&M)
POA&M Milestones must be updated to ensure that it accurately reflects all
corrective actions planned for the system. POA&M reporting
requirements are quarterly. For additional guidance see
Peace Corps ITSR for Certification, Accreditation, and
Security Assessments.
Re-certification of Certification The System must be re-certified at least every three years.
the system Package and This requires the review and update of all component
Certification documents and reports, and a re-assessment of the system‟s
Recommendation security controls. For additional guidance see Peace Corps
ITSR for Certification, Accreditation, and Security
Assessments.
Peace Corps 57
December 03, 2009
Stage 9: Disposition/Disposal/Retirement
IT Security Objectives for the Disposition/Disposal/Retirement Stage

 Sensitive information has been identified and properly made unreadable
 Records that must be retained have been identified and properly archived, including
identification of how they may be retrieved
 Documentation on the final disposition of all information and acquisitions

Appendix A.6 - Table 19: IT Security Tasks and Activities for the Disposition/Disposal/Retirement
IT Security Tasks and Activities for the Disposition/Disposal/Retirement Stage

Sanitize all system Media When a system is retired or disposed of, the information that
media Sanitization Form was processed by the system may still remain on the
system‟s fixed, non-removable media, such as hard drives or
non-volatile memory. This information must be made non-
retrievable by the appropriate method of sanitization. For
additional guidance see Peace Corps ITSR for Media
Protection and the Media Sanitization Procedures.
Remove system System Inventory The System Inventory should be updated to accurately reflect
from System the removal of a system. For additional guidance see Peace
Inventory Corps ITSR for Configuration Management
A.7 Contract Monitoring Policies

Contract Monitoring includes IT participation in selecting an IT contractor/subcontractor,
establishing commitments, and monitoring the contractor/subcontractor's performance and
results. These practices cover the management of a software-only contract as well as the
management of a contract that includes software, hardware, and possibly system components.
Goals
The goals of Contract Monitoring are to:
 Select qualified contractors and/or subcontractors
 Ensure that the contractor and subcontractors agree to their commitments to each other
 Maintain ongoing communications through the life of the contract
 Track and monitor the contractor/subcontractor‘s actual results and performance against
the agreed upon commitments.
7.1 Monitoring Procurement
7.1.1 The Statement of Work (SOW) will be written with particular attention to defining the critical
success factors and measures of performance.
7.1.2 Any changes to the SOW must be approved according to the procedure defined by the
Peace Corps 58
December 03, 2009
7.1 Monitoring Procurement
Contracting office.
7.2 Monitoring Performance
7.2.1 Regular meetings with the contractor/subcontractor management will be scheduled in the
Project Plan. Results will be documented and distributed.
7.2.2 Technical work to be performed by the contractor/subcontractor will be tracked and formally
reviewed on a regular basis.
7.3 Monitoring Quality
7.3.1 QA and CM activities will be performed, monitored, and documented.

7.3.2 Periodic QA reviews of contractor/subcontractor technical activities will be defined within the
SOW and performed as indicated.
Peace Corps 59
December 03, 2009
Appendix B. Checklists of Key SDLC Policies and Elements

This appendix presents quick checklists of the key Peace Corps SDLC policies and elements.
This series of checklists covers the reviews, deliverables, and roles that a project must include in
its tailored Project Plan. It also presents information on metrics and processes that must be
performed to manage the project.
It should be noted here that projects size and scope will determine the extent of documentation
required but standards must exist for all project sizes.
Currently the CIO office defines projects as small enhancements and bug fixes requiring less
then one person month work that do not require database changes; medium as projects requiring
less then three months efforts and large – anything bigger then three months efforts. This SDLC
is geared towards larger projects while smaller projects would take advantage of standards
developed for larger projects.
The checklists below include a required column to aid project managers and approval boards in
determining the extent to which they need to tailor the project documentation. It is also intended
to help the planning and cost estimates activities in order to determine whether projects should
be developed in-house or externally.
B.1 Project Reviews

All Peace Corps projects, regardless of size, must successfully complete and document the
reviews presented in Table B-1.
Appendix B.1 - Table 20: Checklist for Project Reviews
SDLC Checklist: Reviews

Required? Review Time for Review Who Signs Off
Yes Initial Investment At the start of the project. IRB, EAAB
(not for small Management Process
projects)
Reviews
Yes Project Tailoring Reviews  During Project Initiation  Project Manager
 Anytime that the project  Management of
baseline documentation  Support Organizations
is to be tailored.
Yes Project Initiation Review  The end of Project  IRB, EACT
Initiation
 Whenever the project‟s
cost, schedule, or scope
is modified by 10% or
more.
Yes Requirements Walkthrough During the Project  Business Sponsor
and acceptance, the Definition stage  Project Manager, EAAB
requirements include (EAAB signoff not needed
security related for small projects)
requirements  Security Organization
Peace Corps 60
December 14, 2009
Version 4.2 Checklists of Key SDLC Policies and Elements
SDLC Checklist: Reviews

Required? Review Time for Review Who Signs Off
Yes Critical Design Review During the System Design  Business Sponsor
(CDR) stage  Project Manager, EAAB
(EAAB signoff not needed
for small projects)
 Support Organizations
Yes Test Readiness Review At the end of the  Project Manager
Construction stage  Testing Organization
 Data Management
Organization
 Security Organization
Yes System and User During the Acceptance  Business Sponsor
Acceptance stage  Users
 Testing Organization
Yes Security Certification During the Acceptance IT Security
(not for small stage
projects)
No Security Accreditation During the Acceptance Designated Approval
(not for small stage Authority
projects)
Yes Production Readiness At the end of the  Project Manager
Review (PRR) Acceptance stage  Management (Mgmt
Yes Operational Readiness At the end of the signoff not needed for
Review (ORR) Operational Readiness small projects)
stage  Business Sponsor
Yes Regularly scheduled Project Ongoing throughout the  Project Manager
(optional for Team and Management entire life cycle  Management
small projects)
Reviews
In addition to project status, both project risks and security risks will be monitored and
reassessed regularly, particularly at major milestones and when the schedule is under revision.
All certifications, signoffs, meeting minutes, and decisions will be maintained in the project
repository.
B.2 Project Roles

The following project roles, at a minimum, must be assigned by name in writing in the Project
Plan.
Appendix B.2 - Table 21: Checklist of Project Roles
SDLC Checklist: Project Roles

Required? Role Assigned By Notes
Yes Project Manager (technical) Management in Office of Both managers are
Business Sponsor Project the CIO and Business responsible for project
Manager Office success.
Yes Project QA (QA) Manager CIO  Depending on project
and QA Team size and complexity,
Peace Corps 61
December 03, 2009
SDLC Checklist: Project Roles

Required? Role Assigned By Notes
Yes Project Configuration CIO these roles could range
Manager and Configuration from part-time tasks for
Management (CM) Team one person to full time
tasks for several
people.
 One person may fill
more than one role.
Yes Project Change Control  Management in Membership includes
Board Business Office representation for all users
 Business Sponsor(s) of the system.
 Project Manager
Yes IT Security Officer CIO See IT Security Policy and
Procedures Handbook.
No Team Leads and Teams Project Manager As required. Must include
(depends on identified start to perform
size)
Planning and
Requirements
Management activities.
B.3 Deliverables
All projects regardless of size must consider and determine each of the following deliverables /
information for applicability. The results of that determination must be documented. While
most of the information noted below is required, the documents may be combined with each
other or with one of the required project deliverables as documented in the project‘s tailoring
rationale. The approval is done via the appropriate reviews of these deliverables.
Appendix B.3 - Table 22: Checklist of Deliverables
SDLC Checklist: Deliverables

Required? Document Description Notes
Yes IT Concept Document and As defined by the Investment
(not for small Business Case documents Management Process and Chief
projects)
Architect
Yes Project Plan Summarizes cost, schedule, This specific
(not for small resource information, life cycle document is
projects)
methodologies selected, and mandatory; it may also
management strategies for the include some of the
project. information identified
below as additional
sections in this plan.
Yes Data Management Plan Identifies the data requirements,
(full or partial data models, database design,
depending on
scope)
and data management activities.
Peace Corps 62
December 03, 2009

Yes CM Plan or CM Plan Defines the CM procedures to General plan for all
changes be used and specific applications. Only
configuration items for the need to document
project changes from the
standard.
Yes QA Plan or QA Plan Identifies the project‟s personnel General plan for all
changes and activities to ensure the applications. Only
quality of the work products need to document
being developed and to verify changes from the
compliance with standards, standard.
procedures, and plans.
Yes Security Plan & Security Identifies all security-related
Risk Assessment activities
Yes System Test Plan Identifies how the system will be
tested, criteria for success, and
testing resource needs
Yes System Acceptance Test Defines the testing activities to .
Plan be performed, test data and
acceptance criteria, and testing
resource needs. Also includes
security acceptance testing
verifications as needed.
Yes Training Requirements Identifies the training needs of
(not for small the business organization and
projects)
end-users.
Yes Training Plan Identifies the training that will be
(not for small developed and provided based
projects)
on the approved Training
Requirements.
Yes User and Functional A precise description of the  For small projects,
Requirements and requirements of the system the requirements
Requirements Traceability including detailed user, system, may be entered in
Matrix and support requirements. Dimensions without
a matrix
No Infrastructure Plan Defines the architecture,
(only if hardware, communications, and
applicable)
other infrastructure support
needs of the project.
No Acquisition Plan(s) Developed with the Acquisition
Organization to define and
acquire products and services
for completing the project.
Yes System Design Provides a detailed description
(not for small Document(s) of how the system will work,
projects)
including technical approach,
databases, interfaces, security
and module specifications
Peace Corps 63
December 03, 2009

Yes Implementation Plan Identifies the configuration items
(not for small and sequence of work that
projects)
needs to be performed to
migrate an application to
production environments.
Yes Deployment Plan Describes the strategies and
(not for small schedule to field test and roll out
projects)
the system
Yes Test Cases / Scenarios Describes the test cases and May be combined. A
(not for small expected results. System Test will be
projects)
developed for the
Yes Test Results Actual results from the unit, overall system and
(not for small integration, security, systems, can be run through to
projects)
and acceptance testing test after a small
performed. project is completed.
Some are Documents to Operate As appropriate. Can include: Update only if
required and and Maintain the System  Program specification or procedures have
some are not changed due to
(depending on modifications log
scope)  Operations Manual(s) for project.
system and sites
 User documentation and
training materials
 Test cases/scenarios for
regression testing
No Risk Management Outputs Includes: The risk management
(can be
combined in
 Project risk management plan strategy may be
project plan) or strategy included in the Project
 Prioritized list or database of Plan. Risk data
project risks (formally updated (including prioritization
in every stage or more and mitigation) may be
frequently) maintained as part of
a risk management
plan or in a database
for ease of update.
Yes Lessons Learned Documents the lessons learned, Concerns technical,
(not for small both good and bad, during the project, operational,
projects)
project‟s life. and process-related
issues.
No (when Security Certification and Specific documents and signoffs Includes Contingency
applicable) Accreditation Packages are necessary before the system Plan, Disaster
can move to production or use Recovery Plan, and
production data. Trusted Facility
Manual in addition to
those Security
documents listed
previously.
Once a system moves into the Operations stage, the following documents are mandatory:
Peace Corps 64
December 03, 2009

Yes A documented change Defines the change control This will be a standard
control process procedures to be used for document/process for
application changes and for all applications, so
hardware/system change only need to document
management. changes from the
standard.
NO Post-Implementation Includes Contingency Test Plan
security documents as and Test Reports, Application
required Security Audit Reports,
System/Infrastructure Security
Audit Reports, and Security
Incident Reports.
Yes Operational System QA QA standard plans with updates
and CM Plans as required for new / changed
systems.
Yes Business Impact Analysis Documents the business impact This information is
priorities and Continuity of and the contingency plans maintained by each
Operations Plan (COOP) business area. Each
project will provide
information for
updates in their
Disaster Recovery
Plans.
Peace Corps 65
December 03, 2009
Version 4.2 Appendix D. Acronyms
Appendix C. Acronyms
AR ..................Account Representatives
AS ..................Applications Systems
ATO ...............Authorization to Operate
CMM® ...........Capability Maturity Model®
CPIC ...............Capital Planning and Investment Control
CPIC ...............Capital Planning and Investment Control
C&A ...............certification and accreditation
CCB................Change Control Board
CIO .................Chief Information Officer
CISM ..............Chief Information Security Manager
COTS .............Commercial Off-The-Shelf
CI....................configuration items
COOP .............Continuity of Operations Plan
CDR ...............Critical Design Review
EAAB .............EA Advisory Board
EFR ................Emergency Fix Requests
EA ..................Enterprise Architecture
FIPS................Federal Information Processing Standards
FISMA ...........Federal Information Security Management Act
HT ..................High-Throughput
IT ....................information technology
IRB .................Investment Review Board
IRB .................Investment Review Board
ITSRs .............IT Security Requirements
MS ..................Manual Section
NIST ...............National Institute of Standards and Technology
OIT .................Office of Information and Technology
ORR ...............Operational Readiness Review
POA&M .........Plan of Action and Milestones
PRR ................Production Readiness Review
PIF ..................Project Information Form
QA ..................Quality Assurance
RTM ...............Requirements Traceability Matrix
SEI® ..............Software Engineering Institute‘s
SP ...................Special Publication
SOW...............Statement of Work
SSP .................System Security Plan
SDLC .............Systems Development Life cycle
SE-CMM® .....Systems Engineering Capability Maturity Model®
UFR ................Unfunded Request
WBS ...............Work Breakdown Structure
Peace Corps 66
December 14, 2009

Peace Corps (SDLC) System Development Lifecycle Handbook

Hochgeladen von

Dokumentinformationen

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Peace Corps (SDLC) System Development Lifecycle Handbook

Hochgeladen von

Copyright:

PC-10-R-CP02 Attachment 6

Systems Development Life Cycle

December 14, 2009

2. The Peace Corps System Development Life Cycle ................................................... 3

3. Life Cycle Stages – Detailed Description ................................................................. 11

3.6 Stage 6: Testing and Acceptance .................................................................................21

Appendix A. Recommended SDLC Policies .................................................................. 30

Appendix B. Checklists of Key SDLC Policies and Elements ..................................... 60

Appendix C. Acronyms ................................................................................................... 66

List of Figures & Tables

System Development Life Cycle (SDLC) - DRAFT 2

Figure 1: Overview of Peace Corps SDLC Stages ........................................................................ 9

Table 1: Stages Terminology ....................................................................................................... 11

System Development Life Cycle (SDLC) - DRAFT 3

1.2 Guidance to Management

1.3 How to Use This Handbook

2. The Peace Corps System Development Life Cycle

2.1 Project Management Terminology

2.2 Principles of Peace Corps System Development Life Cycle

System Development Project Management Goals

 Meet information systems security requirements as mandated by federal regulations and

2.3 Overview of the System Development Life Cycle

Stage 3 -- Project Requirements Certification

Critical Design Review

Test Readiness Review

Production Readiness Review

Figure 1: Overview of Peace Corps SDLC Stages

2.4 Relationship of SDLC to the Investment Management Process

Investment Management Process

Peace Corps SDLC

Enterprise Architecture Processes

1 Business Alignment Assessment 3 Technical Compliance Review

2 Architecture Compliance Review 4 Business Compliance Review

Figure 2: Relationship of SDLC to Investment Management Process

3. Life Cycle Stages – Detailed Description

3.1 Stage 1: Concept and Business Case

3.1.1 Entry Criteria

3.1.3 Major Outputs

3.1.4 Exit Criteria

 IT System Owners must identify preventative controls to incorporate into their IT

Stage 1 - Concept and Business Case Tasks/Activities

Stage 1 - Concept and Business Case Tasks/Activities

3.2 Stage 2: Initiation and Authorization

3.2.1 Entry Criteria

3.2.3 Major Outputs

3.2.4 Exit Criteria

3.2.5 Tasks and Activities

Stage 2 - Initiation and Authorization Tasks/Activities

Task/Activity Deliverable(s)/Outputs Notes

3.3 Stage 3: Project Definition

3.3.1 Entry Criteria

3.3.4 Exit Criteria

3.3.5 Tasks and Activities

Stage 3 - Project Definition Tasks/Activities

Stage 3 - Project Definition Tasks/Activities

3.4 Stage 4: System Design

3.4.1 Entry Criteria

– System Design Documents

3.4.4 Exit Criteria

3.4.5 Tasks and Activities

Stage 4 - System Design Tasks/Activities

Baseline Design Baseline: The CM and QA plans are

Stage 4 - System Design Tasks/Activities

3.5 Stage 5: Construction

3.5.1 Entry Criteria

– System Acceptance Test Plan

3.5.4 Exit Criteria