System Development Lifecycle (SDLC) Guide Appendix C DDR Task Order #1 FNS SDLC

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 65

August 31, 2017
Version 2.0
National Office – Park Office Center
3101 Park Office Drive
Alexandria, VA 22012
SYSTEMS DEVELOPMENT LIFECYCLE (SDLC)
GUIDE
U.S. Department of Agriculture, Food and Nutrition Service
Office of Information Technology
System Development Lifecycle (SDLC) Guide
2
APPROVAL
OFFICE OF INFORMATION TECHNOLOGY
This document was approved by: ____________________________________________________
Kristin Ruiz Date
Director, Portfolio Management Division, Office of Information
Technology
___________________________________________________
Kevin Russ Date
IT Governance Manager, Portfolio Management Division, Office of
Information Technology
APPLICABILITY
This document applies to the IT Governance Branch under the Portfolio Management Division (PMD) of
the Office of Information Technology (OIT) at the Food, Nutrition, and Consumer Services (FNCS). This
document is approved for internal release.
EFFECTIVE DATE
This document is effective immediately upon approval.
KEVIN RUSS
Digitally signed by KEVIN RUSS
DN: c=US, o=U.S. Government, ou=Department of
Agriculture, cn=KEVIN RUSS,
0.9.2342.19200300.100.1.1=12001000057111
Date: 2017.09.06 15:03:09 -04'00'
KRISTIN RUIZ
Digitally signed by KRISTIN RUIZ
DN: c=US, o=U.S. Government, ou=Department
of Agriculture, cn=KRISTIN RUIZ,
0.9.2342.19200300.100.1.1=12001002520586
Date: 2017.09.06 17:03:24 -04'00'
System Development Lifecycle (SDLC) Guide
3
DOCUMENT REVISION HISTORY
VERSION
AUTHOR
CHANGE DESCRIPTION
1.0 09-12-2012 Catherine Howard Created the document
1.1 02-25-2013 Syed Jaffery Updated deliverable list and added
modular/iterative development information.
1.2 03-08-2013 Kevin Russ Updated figure 1 and added stakeholders
1.3 11-06-2013 Kevin Russ Updated Deliverable list and footnotes.
1.4 12-24-2013 Panum Group Updated SDLC High-Level Governance
Diagram
2.0 8/31/2017 Panum Group Added additional detail from USDA IT
Governance Guidebook and Agile Hybrid
Scrum Approach used by FNCS.
CONTACT INFORMATION
AREA OF CONCERN CONTACT PERSON
IT Governance Lead
Kevin Russ
SDLC Coordinator Syed Jaffery
ITIRB Coordinator
Sunny Dilawari
Portfolio Management Division
Kristin Ruiz
Program Management Branch Vance Parker
System Development Lifecycle (SDLC) Guide
4
TABLE OF CONTENTS
1 PURPOSE AND SCOPE ................................................................................................................ 8
2 SDLC OVERVIEW ........................................................................................................................ 8
2.1. Waterfall SDLC.............................................................................................................................. 9
2.1.1. Phase 1: Initiation ....................................................................................................................... 10
2.1.2. Phase 2: Requirements Gathering and Analysis ......................................................................... 11
2.1.3. Phase 3: Design ........................................................................................................................... 13
2.1.4. Phase 4: Development ................................................................................................................. 14
2.1.5. Phase 5: Integration & Testing .................................................................................................... 14
2.1.6. Phase 6: Implementation ............................................................................................................. 16
2.1.7. Phase 7: Operations & Maintenance ........................................................................................... 17
2.1.8. Phase 8: Disposition .................................................................................................................... 18
2.2. Hybrid Agile Scrum SDLC .......................................................................................................... 19
2.2.1. Phase 1. Initiation ........................................................................................................................ 21
2.2.2. Phases 2-5. Hybrid Agile Scrum Sprint Cycles .......................................................................... 21
2.2.3. Phase 6. Implementation ............................................................................................................. 28
2.2.4. Phase 7. Operations and Maintenance ........................................................................................ 28
2.2.5. Phase 8. Disposition .................................................................................................................... 28
3 CONTROLS / ASSUMPTIONS .................................................................................................. 28
4 DOCUMENTATION .................................................................................................................... 29
5 APPENDIX .................................................................................................................................... 29
6 ADDENDUM ................................................................................................................................. 29
APPENDIX A – SYSTEM CATEGORY – PROJECT SIZES ............................................................... 1
APPENDIX B – SDLC PHASE REQUIREMENTS................................................................................ 2
APPENDIX C – SDLC PROJECT PROCESS FLOW ........................................................................... 1
APPENDIX D – STAGE GATE AND PROJECT REVIEWS ............................................................... 8
APPENDIX E – STAKEHOLDERS DEFINED .................................................................................... 15
APPENDIX F – SDLC EXECUTIVE COMMITTEE CHARTER ..................................................... 17
ADDENDUM A – NON-SDLC PROJECTS .......................................................................................... 19
System Development Lifecycle (SDLC) Guide
5
TABLE OF FIGURES
Figure 1. Waterfall SDLC Overview ............................................................................................................. 10
Figure 2. Initiation Phase Deliverables ........................................................................................................ 10
Figure 3. Initiation Phase Overview ............................................................................................................ 11
Figure 4. Requirements Gathering & Analysis Phase Deliverables ............................................................. 11
Figure 5. Requirements Gathering and Analysis Phase Overview .............................................................. 12
Figure 6. Design Phase Deliverables ........................................................................................................... 13
Figure 7. Design Phase Overview ................................................................................................................ 13
Figure 8. Development Phase Deliverables ................................................................................................ 14
Figure 9. Development Phase Overview ..................................................................................................... 14
Figure 10. Integration & Testing Phase Deliverables .................................................................................. 15
Figure 11. Integration & Testing Phase Overview ...................................................................................... 16
Figure 12. Implementation Phase Deliverables .......................................................................................... 16
Figure 13. Implementation Phase Overview ............................................................................................... 17
Figure 14. Operations & Maintenance Phase Deliverables ........................................................................ 17
Figure 15. Operations & Maintenance Phase Overview ............................................................................. 18
Figure 16. Disposition Phase Deliverables .................................................................................................. 19
Figure 17. Disposition Phase Overview ....................................................................................................... 19
Figure 18. Hybrid Agile Scrum SDLC Overview ........................................................................................... 21
Figure 19. Hybrid Agile Scrum Sprint Cycles Deliverables .......................................................................... 22
Figure 20. Hybrid Agile Scrum Phase Overview .......................................................................................... 23
Figure 21. Roles and Responsibilities for Hybrid Agile Scrum .................................................................... 24
Figure 22. Hybrid Agile Scum Methodology ............................................................................................... 25
Figure 23. Non-SDLC Project Process .......................................................................................................... 20
System Development Lifecycle (SDLC) Guide
6
ACRONYM LIST
REFERENCE DEFINITION
A&A Assessment and Authorization
AAR
Acquisition Approval Request
ADB
Application Development Branch
AO
Authorizing Official
CIO Chief Information Officer
CONOPS Concept of Operations
COR
Contracting Officer’s Representative
COTR
Contracting Officer’s Technical Representative
EVM
Earned Value Management
Fibonacci sequence
A set of numbers that starts with a one or a zero, followed by a one, and
proceeds based on the rule that each number is equal to the sum of the
preceding two numbers. F (0) = 0, 1, 1, 2, 3, 5, 8, 13, 21, 34
FIPS 199
Standards for Security Categorization of Federal Information and
Information Systems
FNCS
Food, Nutrition and Consumer Services
FNS Food and Nutrition Service
IBR Integrated Baseline Review
IPT
Integrated Project Team
IRR
Implementation Readiness Review
ISO
Information Security Office
IT Information Technology
ITG Information Technology Support Group
IV&V
Independent Verification and Validation
JIRA
Issue and project management software tool developed by Atlassian
Kano Model
A theory of product development and customer satisfaction developed in
the 1980s by Professor Noriaki Kano, which classifies customer preferences
into five categories: Must Be Quality, One-dimensional Quality, Attactive
Quality, Indifferent Quality, Reverse Quality
MoSCoW
Must haves, Should haves, Could haves, Won't haves
O&M Operations and Maintenance
O&MB Operations and Maintenance Branch
OA Operational Analysis
OCIO
Office of the Chief Information Officer
OIT
Office of Information Technology
OMB Office of Management and Budget
ORR Operational Readiness Review
PDR Preliminary Design Review
PERT
Program Evaluation & Review Technique
PIA
Privacy Impact Assessment
System Development Lifecycle (SDLC) Guide
7
PIR
Post Implementation Review
PM Project Manager
PMB Program Management Branch
PMD
Portfolio Management Division
PPA
Project Process Agreement
PSR
Project Selection Review
PTA Privacy Threshold Analysis
PWS Performance Work Statement
SDLC
Systems Development Lifecycle
SME
Subject Matter Expert
SOO
Statement of Objectives
SORN System of Records Notices
SOW Statement of Work
SRS
System Requirements Specification
TD
Technology Division
UAT
User Acceptance Testing
USDA United States Department of Agriculture
VPAT Voluntary Product Accessibility Template
VRR
Validation Readiness Review
Walking Skeleton
A minimal initial implementation of an application's architecture that
includes and connects the basic components of the system. With Agile
story
mapping, the first horizontal row represents a "walking skeleton", a
barebones but usable version of the product
System Development Lifecycle (SDLC) Guide
8
1 PURPOSE AND SCOPE
This document details the United States Department of Agriculture (USDA) Food and Nutrition
Service (FNS) systems development lifecycle (SDLC). This process is used for all USDA FNS
Office of Information Technology (OIT) projects related to information system and application
development, developed either contractually or in-house. The SDLC is applicable across all FNS
environments (e.g., workstation, server, mobile, etc.).
The SDLC is used in conjunction with policy and guidelines for the security SDLC, records
management, and acquisition and procurement. It is important to note that no system can go live
unless it goes through the security assessment process. Further, while all phases of the SDLC are
applicable to all software development projects, the specific steps, participants, and reviews and
approvals vary depending upon project size (as a function of cost). Information on project size as a
determinant of SDLC project categorization is detailed in Appendix A.
For projects that do not involve software development and do not follow the SDLC process, a non-
SDLC process has been established that will provide a review of possible impact on systems,
applications, and users; and alignment with overall goals and strategic plan. The non-SDLC process
is much simpler than the SDLC process, and ensures a structure and set of governance, and the
guidance required to ensure predictability and consistency across all projects. The process for non-
SDLC projects is shown in Addendum A.
2 SDLC OVERVIEW
The SDLC guides the process for custom software development projects and requires various
documents and deliverables for each phase. It is the Information Technology (IT) business process
for the delivery of custom software development projects. The SDLC provides a structure and set of
governance for FNS software development efforts. It provides the guidance required to ensure
predictability and consistency across software development projects. The FNS SDLC framework
allows for tailoring of the process to include customizing, waiving or combining particular SDLC
phases, activities, deliverables or project reviews based on the specific project requirements or
specific business needs. Tailoring is completed during the Requirements Gathering & Analysis phase
of the project and is documented in the Project Process Agreement (PPA). Project Managers (PM)
document the reason why specific phases, activities, deliverables or reviews were adjusted.
The SDLC has eight phases (Initiation, Requirements Gathering & Analysis, Design, Development,
Integration & Testing, Implementation, Operations & Maintenance, and Disposition) that serve as
checkpoints for managing OIT projects from cradle to grave. Benefits of the SDLC include:
• Improved system integration and alignment to organizational objectives
• Increased compliance with current and planned enterprise architecture
• Improved assurance that systems are maintainable
• Reduced system redundancies and improved cost-effectiveness
• Reduced project scope creep through enhanced up-front needs analysis
• Improved consistency, repeatability, flexibility, and transparency
• Strengthened controls and accountability
• Enhanced user, manager, and stakeholder involvement
System Development Lifecycle (SDLC) Guide
9
FNS utilizes two different approaches when implementing SDLC projects: the Waterfall method and
the Hybrid Agile Scrum method. The Waterfall method moves through the eight phases in sequential
order with each successive phase leveraging the documentation and knowledge gained from the
previous phases. The Hybrid Agile Scrum method incorporates all eight phases, but moves through
several phases using Sprint cycles to meet the expectations and satisfy the needs of all stakeholders
and department standards. Key success factors include the transparent and consistent practical
application of the industry best Agile practices throughout the project. The Hybrid Agile Scrum
approach does not take the place of the Waterfall, but instead combines several phases to allow for
incorporation into the existing SDLC. Both the Waterfall and Hybrid Agile Scrum approaches share
the Initiation, Implementation, Operations & Maintenance (O&M), and Disposition phases. The
Program Management Branch (PMB) leads the project throughout the first six phases of the SDLC
(Initiation, Requirements Gathering & Analysis, Design, Development, Integration & Testing, and
Implementation) and transitions it over to the Operations and Maintenance Branch (O&MB) for the
last two phases (O&M and Disposition).
The processes for both the Waterfall and Hybrid Agile Scrum approaches are discussed in detail in
the following subsections.
2.1. Waterfall SDLC
The Waterfall approach encompasses eight phases: Initiation, Requirements Gathering and
Analysis, Design, Development, Integration and Testing, Implementation, O&M, and
Disposition. The progress moves steadily through each phase with the next phase beginning
upon the completion of the prior phase. Required phase deliverables, reviews, and approvals
can differ depending upon project size1 and stakeholders2 involved.
A graphic diagram of the Waterfall model is depicted below in Figure 1.
1 Project size is detailed in Appendix A
2 Stakeholders are defined in Appendix E
System Development Lifecycle (SDLC) Guide
10
Figure 1. Waterfall SDLC Overview
2.1.1. Phase 1: Initiation
The Initiation phase begins once the Customer Intake process has been completed. Once
the Initiation phase begins, it follows the SDLC process throughout the entire project
lifecycle from Initiation through Disposition.
From the Customer Intake process, an initial assessment of the potential OIT
system/application development effort has been completed and approved, with the PM
assigned to the project. Once this is completed and the project moves into the Initiation
phase, a framework is established for project success, including establishing processes
for defining, planning, controlling and communicating about the project.
Deliverables3 due in this phase includes:
Figure 2. Initiation Phase Deliverables
Phase 1: Initiation Deliverables
• Business Case (FNS758; FNS755)
• Acquisition Plan / Strategy
3 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
11
• Acquisition Approval Request
• Alternative Analysis
• Cost Benefit Analysis
• Procurement Documents with Information Security Office (ISO) input (e.g.,
Statement of Work (SOW) / Performance Work Statement (PWS) / Statement of
Objectives (SOO)
The Initiation phase includes activities, reviews and approvals as identified in the
flowchart below.
Figure 3. Initiation Phase Overview
Upon successful completion of Step 7. “Approve to Next Phase”, the project progresses
to the Requirements Gathering and Analysis phase.
2.1.2. Phase 2: Requirements Gathering and Analysis
This phase transforms the needs and high-level requirements specified in earlier phases
into measurable, testable, traceable, complete, consistent, and stakeholder-approved
requirements. Defining requirements helps ensure development of the required capability
on time and within budget.
Deliverables4 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 4. Requirements Gathering & Analysis Phase Deliverables
Phase 2: Requirements Gathering and Analysis Deliverables
• Privacy Threshold Analysis (PTA)
• Privacy Impact Analysis (PIA)
• Project Process Agreement (PPA)
4 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
12
Phase 2: Requirements Gathering and Analysis Deliverables
• Project Management Plan (includes Quality Control Plan, Risk Management Plan,
WBS/Schedule, Change Management Plan, Communication Management Plan,
Procurement Management Plan, Staff Management Plan and Cost Management
Plan)
• Integrated Project Team Charter
• System of Records Notices (SORN)
•
Electronic Information System Questionnaire for Records Management Scheduling
• System Requirements Specification (SRS)
• Concept of Operations
• Requirements Traceability Matrix
• FIPS 199 - Standards for Security Categorization of Federal Information and
Information Systems
A critical governance body is established in this phase: the Integrated Project Team
(IPT). The IPT should consist of the following core members: Project Lead, Developers,
Business Leads, Technical Representative, Security Representative, and Contracting
Officer’s Technical Representative (COTR). Associate members should include
representatives from Governance, Network, Telecommunications, Records, O&M, and
the Contracting Office. The IPT is documented in this phase and functions through the
Implementation phase.
The Requirements Gathering and Analysis phase includes activities, reviews and
approvals as identified in the flowchart below.
Figure 5. Requirements Gathering and Analysis Phase Overview
Upon successful completion of Step 5. “Approve to Next Phase”, the project progresses
to the Design phase.
System Development Lifecycle (SDLC) Guide
13
2.1.3. Phase 3: Design
The purpose of the Design phase is to transform requirements into complete and detailed
system design specifications. During this phase, the physical characteristics of the
system are designed, the operating environment is established, major subsystems and
their inputs and outputs are defined, and processes are allocated to resources. The project
concept is further developed to describe how the business will operate once the approved
project is implemented (i.e., becomes a “system”), and to assess the impact on employee
and customer privacy. Additionally, security certification and assessment activities begin
with the identification of security requirements and the completion of a high-level
vulnerability assessment.
Deliverables5 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 6. Design Phase Deliverables
Phase 3: Design Deliverables
• System Design Document
• Configuration Management Plan/Change Control Board Charter
• Contingency Plan (includes Security Business Impact Assessment and Disaster
Recovery Plan)
• Domain Name Request
The Design phase includes activities, reviews and approvals as identified in the
flowchart below.
Figure 7. Design Phase Overview
Upon successful completion of Step 5. “Approve to Next Phase”, the project progresses
to the Development phase.
5 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
14
2.1.4. Phase 4: Development
The purpose of the Development phase is to convert the system design prototyped in the
Design phase into a working system that addresses all documented system requirements.
Further, everything requiring user input or approval must be documented in this phase.
Deliverables6 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 8. Development Phase Deliverables
Phase 4: Development Deliverables
• Test Plan
• Data Conversion Strategy (if applicable)
• Earned Value Management (EVM) Report
• Configure Development, Testing & Training Environments (if applicable)
• Develop Software/System
The Development phase includes activities, reviews and approvals as identified in the
flowchart below.
Figure 9. Development Phase Overview
Upon successful completion of Step 5. “Approve to Next Phase”, the project progresses
to the Integration & Testing phase.
2.1.5. Phase 5: Integration & Testing
The purpose of the Integration & Testing phase is to lay the foundation for a smooth and
successful implementation. Key activities in this phase include:
• Attaining user input or approval as defined in the prior phase (Development)
• Preparing detailed logic specifications for each system module
• Testing and integrating units into larger components
6 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
15
• Preparing the technical environment for the system
This phase focuses on achieving proof that the system meets all requirements; functions
according to design parameters; and satisfies all business, technical, and management
stakeholders. Additionally, prior to installing and operating the system in a production
environment, the system must undergo security authorization activities, as necessary.
Deliverables7 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 10. Integration & Testing Phase Deliverables
Phase 5: Integration & Testing Deliverables
• Transition Plan
• Operations & Maintenance Manual
• User Acceptance Testing (UAT) Sign-off
• System Security Plan
• Interconnection Security Agreement(s) (if applicable)
• Contingency Plan Test (CPT) Report
• Security Assessment Plan (also known as Security Test & Evaluation Plan)
• Security Assessment Report (includes Security Requirements Traceability Matrix)
• Plan of Action & Milestones (POA&Ms)
• Vulnerability/App Scan Results
• Release Management Plan
• Training Manual
• User Manual
• Test Results
• Section 508 Voluntary Product Accessibility Template (VPAT) and/or
Certification
The Integration & Testing phase includes activities, reviews and approvals as identified
in the flowchart below.
7 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
16
Figure 11. Integration & Testing Phase Overview
Upon successful completion of Step 5. “Approve to Next Phase”, the project progresses
to the Implementation phase.
2.1.6. Phase 6: Implementation
The purpose of the Implementation phase is to deploy and enable operations of the new
information system in the production environment. Successful completion of the
Implementation phase should comprise both system deployment and training on the
system.
Deliverables8 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 12. Implementation Phase Deliverables
Phase 6: Implementation Deliverables
• Installation Document
• Concurrency Review Memo
• Operations Readiness
• Life Cycle Cost
• Project Closeout
• Performance Measures
• Authority to Operate
• Application Guide
• Source Code
The Implementation phase includes activities, reviews and approvals as identified in the
flowchart below.
8 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
17
Figure 13. Implementation Phase Overview
Upon successful completion of Step 4. “Approve to Next Phase”, the project progresses
to the O&M phase.
2.1.7. Phase 7: Operations & Maintenance
The purpose of the O&M phase is to ensure the information system is fully functional
and performs optimally until the system reaches its end of life. The system is monitored
for continued performance in accordance with user requirements, and needed system
modifications are incorporated. The operational system is periodically assessed through
In-Process Reviews to determine how the system can be made more efficient and
effective. Operations continue as long as the system can be effectively adapted to
respond to an organization’s needs. At the point when modifications or changes are
identified as necessary, the system may re-enter the Initiation phase.
During this phase, the project is transitioned from PMB to O&MB to maintain and
ensure continued functionality and optimal performance for the remainder of the project
lifecycle.
Deliverables9 due in this phase (and could be started earlier in the lifecycle) includes:
Figure 14. Operations & Maintenance Phase Deliverables
Phase 7: Operations & Maintenance Deliverables
• System Post Implementation Review Report
• Operational Analysis (including Operational & Performance Metrics)
• Annual Review/Updates Required:
o Systems Security Plan
o Contingency Plan (includes Disaster Recovery Plan)
o
System Risk Management Plan
9 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
18
Phase 7: Operations & Maintenance Deliverables
o Configuration Management Plan/Change Control Board Charter
o Life Cycle Cost
o Concurrency Review Memo
• Routine Maintenance
• Authority to Operate (Every 3 Years)
The O&M phase includes activities, reviews and approvals as identified in the flowchart
below.
Figure 15. Operations & Maintenance Phase Overview
Upon advancement to Step 4. “Continue in O&M Phase or Approve to Next Phase”, the
project is determined by the team and stakeholders to either continue operating or
advance to the Disposition phase.
2.1.8. Phase 8: Disposition
The purpose of the Disposition phase is to shut down the operational system in a
controlled manner. The disposition activities allow for the orderly termination of the
system and preserve the vital information about the system so that some or all of the
information may be retrieved in the future, if necessary. Particular emphasis is given to
proper preservation of the data processed by the system, so that the data is effectively
migrated to another system or archived in accordance with applicable records
management regulations and policies for potential future access.
Deliverables10 due in this phase (and could be started earlier in the lifecycle) includes:
10 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
19
Figure 16. Disposition Phase Deliverables
Phase 8: Disposition Deliverables
• System Disposition Plan
• System Disposition Checklist
• Post-Termination Review Report
• Disposition Memo
The Disposition phase includes activities, reviews and approvals as identified in the
flowchart below.
Figure 17. Disposition Phase Overview
Upon successful completion of Step 4. “Retire System”, the system is discontinued from
service.
2.2. Hybrid Agile Scrum SDLC
The Hybrid Agile Scrum approach follows the eight phases shown in the Waterfall method, but
it replaces the Requirements Gathering & Analysis phase with Sprint Zero and combines the
Design, Development, Integration & Testing phases into one phase with one or more iterative
Sprints.
The purpose of the Hybrid Agile Scrum approach is to use an iterative approach to perform
planning, requirements, analysis, design, development and testing phases. It does not replace
these phases, but performs them in short iterations. The Hybrid Agile Scrum approach guides
the process for agile software development projects and requires various documents and
deliverables. FNS allows freedom for incorporating agile associated industry-leading practices;
however, requests a minimum structure to ensure consistency and predictability across projects.
Industry best practices applicable to Hybrid Agile Scrum projects include:
• Agreed to baseline effort (total story points) established during Sprint Zero planning, and
prior to proceeding with development efforts.
System Development Lifecycle (SDLC) Guide
20
• Value-based decomposition and prioritization utilized as a planning tool in which
requirements are progressively elaborated and prioritized so they can be pulled into the
development process.
• Incremental delivery of the simplest solution that will work (a “plain vanilla” version) and
then incremental addition of more features until the final product is built. At a minimum,
applying a quarterly release schedule.
• Generally a two to four weeks Sprint/iteration length. This timeframe is short enough to
allow the team to hear about changes frequently, yet long enough to allow time for work to
get done and to produce new functionality without being so frequent that it is disruptive to
the business.
• Use of products and tools that take a minimal amount of time to update and keep current. As
a result of the frequent reprioritization of work and high rates of changes, tools like work
breakdown structures and Program Evaluation Review Technique (PERT) charts are not
recommended (but can still work on agile projects). Instead, FNS allows Agile teams to use
tools like Product Roadmaps (as a release planning technique), osmotic communication, tacit
knowledge, face-to-face conversation, and other more interactive communication methods.
• Address spikes as early as possible, with the intention of eliminating or reducing risks to
minimize the project’s risk profile or reaching fast failure. If the project is too risky or it is
proven through spikes that a successful outcome is unattainable, it is better to know as early
as possible so that funds can be redirected toward other initiatives that are more likely to
succeed.
A graphic diagram of the Hybrid Agile Scrum model is depicted below in Figure 18.
System Development Lifecycle (SDLC) Guide
21
Figure 18. Hybrid Agile Scrum SDLC Overview
2.2.1. Phase 1. Initiation
The Initiation phase for the Hybrid Agile Scrum approach follows the same steps and
requires the same deliverables as the Waterfall Initiation phase. Please refer to that
section of the document for additional details.
Upon successful completion of Step 7. “Approve to Next Phase”, the project begins
following the Hybrid Agile Scrum Sprint Cycles, which combine phases two through
five (Requirements Gathering & Analysis, Design, Development, and Integration &
Testing) into iterative Sprint cycles.
2.2.2. Phases 2-5. Hybrid Agile Scrum Sprint Cycles
Deliverables11 in these phases include:
11 A comprehensive deliverables list by project size is shown in Appendix B
System Development Lifecycle (SDLC) Guide
22
Figure 19. Hybrid Agile Scrum Sprint Cycles Deliverables
Hybrid Agile Scrum Sprint Cycles Deliverables
• Retrospective Meeting Minutes
• Release Management Plan
• Product Roadmap
• Product Backlog
• Release Burndown Chart
• Sprint Burndown Chart
• Privacy Threshold Analysis (PTA)
• Privacy Impact Analysis (PIA)
• Project Process Agreement (PPA)
• Project Management Plan (includes Quality Control Plan, Risk Management Plan,
WBS/Schedule, Change Management Plan, Communication Management Plan,
Procurement Management Plan, Staff Management Plan and Cost Management
Plan)
• Integrated Project Team (IPT) Charter
• System of Records Notices (SORN)
• Electronic Information System Questionnaire for Records Management Scheduling
• FIPS 199 - Standards for Security Categorization of Federal Information and
Information Systems
• Configuration Management Plan/Change Control Board Charter
• Contingency Plan (includes Security Business Impact Assessment and Disaster
Recovery Plan)
• Domain Name Request
• Configure Development, Testing & Training Environment (if applicable)
• Data Conversion Strategy (if applicable)
• Earned Value Management (EVM) Report
• Transition Plan
• Operations/Maintenance Manual
• System Security Plan
• Interconnection Security Agreement(s) (if applicable)
• Contingency Plan Test (CPT) Report
• Security Assessment Plan (also known as Security Test & Evaluation Plan)
• Security Assessment Report (includes Security Requirements Traceability Matrix)
• Plan of Action & Milestones (POA&Ms)
• UAT Sign-Off
• Vulnerability / App Scan Results
• Training Manual
• Test Results
• Section 508 VPAT and/or Certification
• User Manual
System Development Lifecycle (SDLC) Guide
23
The Hybrid Agile Scrum includes activities, reviews and approvals as identified in the
flowchart below.
Figure 20. Hybrid Agile Scrum Phase Overview
Upon successful completion of Step 9. “Approve to Next Phase”, the project progresses
to the Implementation phase.
The JIRA automated tool shall be utilized to keep historic records of all Sprint-related
activities and FNS provides projects with the option to use FNS JIRA licenses if they do
not retain the software. JIRA is the tool for tracking the Product Backlog, Sprint
Backlog, Velocity Charts, Burndown Charts, Bugs/Issues, and Risks. There are specific
stakeholders considered vital to a successful agile project and at least one individual
must be designated as responsible for each key role shown in Figure 21.
System Development Lifecycle (SDLC) Guide
24
Figure 21. Roles and Responsibilities for Hybrid Agile Scrum
Role
Responsibility
Project Sponsor – Champions and
sponsors the project within their
organization
• Ensures accountability for the realization of project
benefits
• Ensures oversight of the project management function
• Manages senior stakeholders
Product/Business Owner –
Represents the business or user
community and is responsible for
determining what features will be in
the product release
• Serves as liason between the development team and
customers
• Defines and prioritizes the features of the application,
and adjusts features and priority
• Accepts or rejects work results and has final say on
product functionality
• Keeps users/stakeholders apprised of status and
obtains their feedback
USDA FNS Program Manager –
Responsible for providing
management and oversight of all the
projects within the Release/Sprint
• Serves as liason between the project sponsor and
senior management
• Manages the Scrum Master/PM to ensure that the
requirements and timelines promised to the Project
Sponsor and Product/Business Owner are met
Scrum Master/PM – Responsible for
ensuring that the solution that the
team builds meets requirements and
timelines delivers the most value
• Facilitates all meetings
• Supports the Product/Business Owner
• Ensures the team has what is needed to deliver the
work in each Sprint
Sprint Team - Responsible for
translating the business requirements
into technical requirements and for
building the solution based on the
business requirements
• Develops the user stories, test cases and project
documentation
• Works with the development team to support testing.
• Supports the Scrum Master/PM
• Designs, develops, integrates, tests and documents the
work completed during the Sprint
System Development Lifecycle (SDLC) Guide
25
Figure 22 provides an overview of the Hybrid Agile Scrum process.
Figure 22. Hybrid Agile Scum Methodology
Sprint Zero 2.2.2.1.
Sprint Zero replaces the Requirements phase of the SDLC. Prior to the project
entering a Sprint, the Scrum Master/PM begins planning the upcoming Sprint
cycle and begins the development of the project management plan, the project
schedule, scope statement and the project charter. The Scrum Master/PM meets
with the Product/Business Owner for the Project Kick-Off Meeting and
discusses the Agile process, sets expectations and discusses the high-level
project release strategy, and populates the product backlog. The
Product/Business Owner and Scrum Master/PM also develops a plan for UAT,
Training and Deployment. The Scrum Master/PM begins planning for the
requirements and builds the timeline into the project schedule.
The Scrum Master/PM, Product/Business Owner, and ISO meets to discuss
initial high-level system requirements as it relates to security controls and data
management. The Scrum Master/PM and ISO work closely to ensure
information required during the Security Review is provided in the System
Security Plan that the Sprint Team prepares. ISO studies and analyzes the
System Development Lifecycle (SDLC) Guide
26
security implications of the technical alternatives to ensure the alternatives
address all aspects or constraints imposed by security requirements.
Once the Scrum Master/PM and the Product/Business Owner have had their
kick-off meeting, the Scrum Master/PM schedules between two to four sessions
with the Product/Business Owner, Stakeholders, and the Sprint Team to gather
the User Stories and acceptance criteria in the Product Backlog. They group the
User Stories into Themes and Epics, and the stakeholders are encouraged to
identify all user stories pertinent to the task at hand. However, the cumulative
total of these user stories cannot exceed the baseline effort accepted by the
Government as part of the contractor’s proposal. This is where Sprint Zero
plays a vital role in setting expectations for the project.
The Product/Business Owner prioritizes each user story by assigning an
appropriate Business Value utilizing the Fibonacci sequence, and the Scrum
Master/PM captures the agreed upon acceptance criteria for each user story.
The Sprint Team evaluates and assigns story size estimates (i.e., story points) to
each user story in the Product Backlog, utilizing an Agile estimation technique
(Fibonacci sequence) to reach a Cumulative Amount of Story Points for the
project.
By associating the baseline effort of story-points from the accepted Sprint
Team to the now prioritized and risk-adjusted Product Backlog, the
Product/Business Owner can now ascertain which user stories will meet the
baseline effort and be completed as part of the effort. The Product/Business
Owner may elect to reprioritize user stories to ensure the most important are
included as part of the baseline effort, or the Product/Business Owner may elect
to perform other tradeoff and reprioritization techniques (such as the MoSCoW
method, Kano Model, and Walking Skeleton).
Each project is tailored to the specific needs of the project. During Sprint Zero,
the Scrum Master/PM works with the Sprint Team and the Product/Business
Owner to plan the schedule based on the anticipated level of effort and scope of
the project to be delivered and create a Product Roadmap. The Product
Roadmap provides a high to mid-level view of how the product or solution
develops over time and shall encompass the anticipated Sprint Velocity of the
Sprint Team, and the Sprint Cadence (normally within a 4-week duration)
spread over the life of the project.
Sprint Cycles 2.2.2.2.
An Agile Hybrid Scrum project may contain one or more sprints based on the
Product Roadmap developed during Sprint Zero where the number of required
Sprints are determined. The Product Backlog is the location where all
requirements (i.e., technical functionality for the system, System Change
Requests) reside. Through the backlog grooming process, each user story
receives documented acceptance criteria, which is clarified and understood by
System Development Lifecycle (SDLC) Guide
27
both the Government and Sprint Team throughout the life of the project. The
Government Product/Business Owner prioritizes all user stories, and the user
stories with the highest priority are assigned to the next Sprint (iteration), from
this risk-adjusted Product Backlog. The entire Product Backlog is maintained in
the JIRA automated tracking tool.
The Sprint is a two to four weeks iteration where user stories from the Sprint
Backlog are analyzed, designed, developed, and tested creating a piece of the
system that is functional and implementable code. On the first day of every
Sprint, a Sprint Planning Session is conducted and results in a Sprint Backlog
containing user stories that have been reviewed, analyzed, and selected by the
Sprint Team (based on Product/Business Owner prioritization) to be worked on
during a Sprint. During the Sprint on a daily basis, the Sprint Team and Scrum
Master meet to provide updates on progress on commitments made by the team
called the “Daily Stand-up Meeting”. Risks or issues that are affecting the
successful completion of the Sprint are also identified, documented, and
managed based on the Risk Management Plan. During the Daily Stand-up
Meeting (which normally lasts for 15 minutes), the Sprint Team will discuss:
(a) what has been completed, (b) what will be completed today, and (c) what
obstacles or impediments are currently being experienced/faced by the team.
This allows the Scrum Master to play an active servant-leadership role and
remove impediments impacting the team’s progress.
On the last day of the Sprint, the functional and implementable product is
presented at a Demonstration Meeting to the stakeholders and Product/Business
Owner. During this meeting, each user story in the Sprint is presented to the
Product/Business Owner, and he/she either “Accepts” or “Rejects” the changes.
Any user stories that are accepted by the Product/Business Owner are staged for
release. Any user stories that are “rejected” by the Product/Business Owner are
placed back into the Product Backlog for future analysis and prioritization
during a Backlog Grooming Session.
At the end of each sprint, the Sprint Team conducts a retrospective that is used
as the primary learning, reflection, and readjustment events on agile projects.
The Sprint Team discusses what went well, what can be done better in future
Sprints, and ways to improve the execution of future Sprints. The purpose of
this is to foster continuous improvement and efficiencies. Documenting and
subsequently implementing the Lessons Learned at the end of each Sprint
(Retrospective) offers a number of benefits for the team and project, including:
• Improved productivity
• Improved capability
• Improved quality
• Improved capacity
The Scrum Master/PM documents (via Meeting Minutes) each Sprint
Retrospective, and deliver to the Contracting Officer’s Representative (COR)
System Development Lifecycle (SDLC) Guide
28
for review and acceptance within 3 business days of each Sprint/Iteration
ending based on contractual requirements of each individual project.
At the end of each Sprint, the accepted code is ready for production, but is
usually held or bundled into a larger software release. A Software
Configuration Management repository tool should be used to hold the product
generated during each Sprint. Strict Software Configuration Management
practices are to be followed to ensure proper baseline management and version
control. Accepted user stories are then staged for release based on the approved
release strategy.
Release Management 2.2.2.3.
Planning for releases is conducted during Sprint Zero and documented within
the Product Roadmap. Releases may contain one or more Sprints based on
many factors that are specific to each project. The product (source code)
created by each Sprint grouped into one release must be merged and installed
into a test environment. The Sprint Team shall perform a regression test to
ensure that all integration activities were performed successfully. The Scrum
Master/PM then hands off the application to the User Acceptance stakeholders
for final testing and acceptance. Once a successful UAT is performed and the
Government formally accepts the release, the project moves to the
Implementation phase.
2.2.3. Phase 6. Implementation
The Implementation phase for the Hybrid Agile Scrum approach follows the same steps
and requires the same deliverables as the Waterfall Implementation phase. Please review
that section of the document for additional details.
2.2.4. Phase 7. Operations and Maintenance
The O&M phase for the Hybrid Agile Scrum approach follows the same steps and
requires the same deliverables as the Waterfall O&M phase. Please review that section
of the document for additional details.
2.2.5. Phase 8. Disposition
The Disposition phase for the Hybrid Agile Scrum follows the same steps and requires
the same deliverables as the Waterfall Disposition phase. Please review that section of
the document for additional details.
3 CONTROLS / ASSUMPTIONS
Both the Waterfall and Hybrid Agile Scrum approaches calls for a series of comprehensive
management controls. These include:
• Lifecycle management should be used to ensure a structured approach to information systems
development and operation.
System Development Lifecycle (SDLC) Guide
29
• Each project must have an accountable sponsor.
• A project manager must be appointed for each system project. A system project can include both a
FNS project manager and a vendor project manager, if applicable.
• A comprehensive project management plan is required for each system project.
• Data Management and security must be emphasized throughout the lifecycle.
• A project may not proceed until resource availability is assured.
4 DOCUMENTATION
This lifecycle methodology specifies which documentation shall be generated during each phase.
Some documentation remains unchanged throughout the systems lifecycle while others evolve or are
revised to reflect results from analyses performed in later phases. Each of the documents produced
are collected and stored per OIT policy.
5 APPENDIX
System Category – Project Sizes
SDLC Phase Requirements – Waterfall and Hybrid Agile Scrum
SDLC Project Process Flow – Waterfall and Hybrid Agile Scrum
Stage Gate and Project Reviews
Stakeholders – Defined
Executive Committee Charter
6 ADDENDUM
Non-SDLC Projects
SDLC Guide
SDLC Guide May 12, 2017 Page 1
APPENDIX A – SYSTEM CATEGORY – PROJECT SIZES
Select from following categories to determine a project’s appropriate SDLC process:
i. Small Project
a. Expected cost is less than $25,000
b. Project Management methodology is required
c. Risk and complexity are low
d. An individual unit is involved
e. Expected duration is less than 4 months
ii. Medium Project
a. Expected cost is $25,000 to $500,000
b. Project Management methodology is required
c. Complexity is medium to high
d. Multiple people/departments are involved
e. Expected duration is less than a year
iii. Large Project
a. Expected cost is greater than $500,000
b. Full Project Management methodology is required
c. Expense, risk, or complexity are high
d. Large number of people/departments are involved
e. Anticipated lifecycle is long
If a project does not meet the list of criteria for any one specific project size listed above, the exact project
size will be determined by the SDLC Committee during the Requirements Gathering & Analysis phase
when the Project Process Agreement (PPA) is documented.
System Development Lifecycle (SDLC) Guide
2
APPENDIX B – SDLC PHASE REQUIREMENTS
Waterfall Phase Requirements
Phase 1 - Initiation
Phase 1 – Initiation
Inputs • N/A
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
Business Case: FNS758
Business Case: FNS755
Acquisition Plan / Strategy
Acquisition Approval Request
Alternative Analysis
Cost Benefit Analysis
Procurement Documents –
SOW/PWS, SOO (with ISO
input)
Stakeholders • Project Sponsor
• Office of Information Technology Project Manager (OIT PM)
System Development Lifecycle (SDLC) Guide
3
Phase 1 – Initiation
• Subject Matter Experts (SMEs)
Phase 2 – Requirements Gathering and Analysis
Phase 2 - Requirements Gathering and Analysis
Inputs • Business Case
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
Privacy Threshold Analysis (PTA)
Privacy Impact Analysis (PIA)
Project Process Agreement (PPA)
Project Management Plan (includes
Quality Control Plan, Risk Management
Plan, WBS/Schedule, Change Management
Plan, Communication Management Plan,
Procurement Management Plan, Staff
Management Plan and Cost Management
Plan)
Integrated Project Team Charter
System of Records Notices (SORN)
Electronic Information System
Questionnaire for Records Management
System Development Lifecycle (SDLC) Guide
4
Phase 2 - Requirements Gathering and Analysis
Scheduling
High-Level System Requirements
Specification (SRS)
System Requirements Specification
(SRS)
Concept of Operations12
Requirements Traceability Matrix
FIPS 199 - Standards for Security
Categorization of Federal Information
and Information Systems13
Stakeholders • Project Sponsor
• SMEs
• OIT PM
• Business Analyst
• IPT
12 Concept of Operations is optional for large projects.
13 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
5
Phase 3 - Design
Phase 3 – Design
Inputs • Business Case
• Project Management Plan
• System Requirements Document
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
System Design Document
Configuration Management Plan/Change
Control Board Charter14 15
Contingency Plan16
(Includes Security Business Impact
Assessment and Disaster Recovery Plan)
Domain Name Request
Stakeholders
• Project Sponsor
• SMEs
• OIT PM
• Business Analyst
• Network Managers
• Developers
• End Users
• IPT
14 Configuration Management Plan is optional for small projects.
15 As required by Information Security Office (ISO)
16 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
6
Phase 4 - Development
Phase 4 – Development
Inputs • System Requirements Document
• System Design Document
Outputs/
Deliverables
Outputs/ Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
Test Plan
Data Conversion Strategy
EVM Report
Development, Testing & Training
Environments
Stakeholders • OIT PM
• Business Analyst
• Developers
• Testers
• IPT
System Development Lifecycle (SDLC) Guide
7
Phase 5 – Integration and Testing
Phase 5 - Integration and Testing
Input • System Requirements Document
• System Design Document
• Project Plan
• Test Plan
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
Transition Plan
Operations/Maintenance Manual
UAT Sign-Off
System Security Plan17
Interconnection Security Agreement(s) (if
applicable) 18
Contingency Plan Test (CPT) Report19
Security Assessment Plan (also known as
Security Test & Evaluation Plan) 20
Security Assessment Report (includes
Security Requirements Traceability
Matrix) 21
17 As required by Information Security Office (ISO)
18 As required by Information Security Office (ISO)
19 As required by Information Security Office (ISO)
20 As required by Information Security Office (ISO)
21 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
8
Plan of Action & Milestones (POA&Ms) 22
Vulnerability / App Scan Results
Release Management Plan
Training Manual
User Manual
Test Results
Section 508 VPAT and/or Certification
Stakeholders
• OIT PM
• Business Analyst
• Developers
• SMEs
• OIT PM
• Testers
• IPT
22 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
9
Phase 6 – Implementation
Phase 6 – Implementation
Inputs
• Project Management Plan
• System Requirements Document
• System Design Document
• Test Plan
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark Denotes required)
Small Medium Large
Installation Document23
Concurrency Review Memo24
Operations Readiness
Life Cycle Cost
Project Closeout
Performance Measures
Authority to Operate25
Application Guide26
Source Code
23 Installation document is optional for small projects
24 As required by Information Security Office (ISO)
25 As required by Information Security Office (ISO)
26 Application guide is optional for medium and large projects
System Development Lifecycle (SDLC) Guide
10
Phase 6 – Implementation
Stakeholders
• OIT PM
• Business Analyst
• Project Sponsor
• SMEs
• Network Managers
• Developers
• Contractors
• IPT
• IT Governance Support Group (ITG)
System Development Lifecycle (SDLC) Guide
11
Phase 7 – Operations & Maintenance
Phase 7 – Operations & Maintenance
Inputs • Project Management Plan
• System Requirements Document
• System Design Document
• Test Plan
• Test Results
• Installation Document
• Application Guide
Outputs /
Deliverables Output / Deliverables
Project Size
(Checkmark Denotes required)
Small Medium Large
System Post Implementation Review Report
Operational Analysis (includes Operational
and Performance Metrics)
Annual Updates Required:
• Systems Security Plan27
• Contingency Plan (includes
Disaster Recovery Plan) 28
• System Risk Management Plan29
• Configuration Management
Plan/Change Control Board
Charter30
• Life Cycle Cost
• Concurrency Review Memo31
Routine Maintenance
27 As required by Information Security Office (ISO)
28 As required by Information Security Office (ISO)
29 As required by Information Security Office (ISO)
30 As required by Information Security Office (ISO)
31 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
12
Authority to Operate (Every 3 Years) 32
Stakeholders
• ITG
• O&MB
Phase 8 – Disposition
Phase 8 – Disposition
Inputs • Project Management Plan
• System Requirements Specification
• System Design Document
• Test Plan
• Test Results
• Installation Document
• Application Guide
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
System Disposition Plan
System Disposition Checklist
Post Termination Review Report
Disposition Memo33
Stakeholders
• ITG
O&MB
32 As required by Information Security Office (ISO)
33 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
13
Hybrid Agile Scrum Phase Requirements
Phase 1 – Initiation
The Initiation phase for the Hybrid Agile Scrum appraoch follows the same requirements as the Waterfall
Initiation phase. Please review that section of the document for additional details.
Phases 2 through 5 – Requirements Gathering through Integration & Testing
SDLC Hybrid Agile Scrum
Inputs • Performance Work Statement
• Project Objectives
• Requirements
• Procurement Documents
Outputs /
Deliverables Outputs / Deliverables
Project Size
(Checkmark denotes required)
Small Medium Large
Retrospective Meeting Minutes
Release Management Plan
Product Roadmap
Product Backlog
Release Burndown Chart
Sprint Burndown Chart
Privacy Threshold Analysis (PTA)
System Development Lifecycle (SDLC) Guide
14
Privacy Impact Analysis (PIA)
Project Process Agreement (PPA)
Project Management Plan (includes
Quality Control Plan, Risk Management
Plan, WBS/Schedule, Change Management
Plan, Communication Management Plan,
Procurement Management Plan, Staff
Management Plan and Cost Management
Plan)
Integrated Project Team Charter
System of Records Notices (SORN)
Electronic Information System
Questionnaire for Records Management
Scheduling
FIPS 199 - Standards for Security
Categorization of Federal Information
and Information Systems 34
Configuration Management Plan /
Change Control Board Charter35 36
Contingency Plan (includes Security
Business Impact Assessment and
Disaster Recovery Plan)37
Domain Name Request
Configure Development, Testing,
Training Environments
Data Conversion Strategy (if applicable)
34 As required by Information Security Office (ISO)
35 Configuration Management Plan is optional for small projects
36 As required by Information Security Office (ISO)
37 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
15
EVM Report
Transition Plan
Operation/Maintenance Manual
System Security Plan38
Interconnection Security Agreement(s)
(if applicable) 39
Contingency Plan Test (CPT) Report40
Security Assessment Plan (also known
as Security Test & Evaluation Plan) 41
Security Assessment Report (includes
Security Requirements Traceability
Matrix) 42
Plan of Action & Milestones
(POA&Ms) 43
UAT Sign-Off
Vulnerability / App Scan Results
Training Manual
Test Results
Section 508 VPAT and/or Certification
38 As required by Information Security Office (ISO)
39 As required by Information Security Office (ISO)
40 As required by Information Security Office (ISO)
41 As required by Information Security Office (ISO)
42 As required by Information Security Office (ISO)
43 As required by Information Security Office (ISO)
System Development Lifecycle (SDLC) Guide
16
User Manual
Stakeholders
• ITG
• O&MB
• Sprint Team
• Scrum Master/PM
• Product/Business Owner
• USDA FNS PM
• Project Sponsor
Phase 6 – Implementation
The Implementation phase for the Hybrid Agile Scrum approach follows the same requirements as the
Waterfall Implementation phase. Please review that section of the document for additional details.
Phase 7 – Operations & Maintenance
The O&M phase for the Hybrid Agile Scrum approach follows the same requirements as the Waterfall
O&M phase. Please review that section of the document for additional details.
Phase 8 – Disposition
The Disposition phase for the Hybrid Agile Scrum approach follows the same requirements as the
Waterfall Disposition phase. Please review that section of the document for additional details.
SDLC Guide
SDLC Guide May 12, 2017 Page 1
APPENDIX C – SDLC PROJECT PROCESS FLOW
Waterfall Method Process Flow
System Development Lifecycle (SDLC) Guide
2
System Development Lifecycle (SDLC) Guide
3
System Development Lifecycle (SDLC) Guide
4
System Development Lifecycle (SDLC) Guide
5
Agile Hybrid Scrum Method Process Flow
System Development Lifecycle (SDLC) Guide
6
System Development Lifecycle (SDLC) Guide
7
SDLC Guide
SDLC Guide May 12, 2017 Page 8
APPENDIX D – STAGE GATE AND PROJECT REVIEWS
A high-level overview of the Stage Gate Review process (i.e., High-Level SDLC Governance) is in The
Systems Development Lifecycle (SDLC) Stage Gate Review Practice Guide.
Stage Gate Reviews underlie the SDLC methodology from project management and governance
perspectives. The SDLC, divided into phases, requires satisfying Stage Gate requirements (see Appendix
B for more detail) in order to advance along the lifecycle process.
The Stage Gate Review evaluates and authorizes a project to progress from one lifecycle stage to the next.
It is a collaborative practice in which all participants play an important role in assessing the project’s
status and quality. This collaborative process enables the IPT, SDLC Executive Committee, Project
Sponsor and Portfolio Management to make informed decisions about project readiness for the next stage
of lifecycle development. It provides the Project Manager/Lead and the Product/Business Owner with an
independent body to confirm that deliverables comply with project requirements and align with Agency
policies, OMB regulations, and Federal laws.
Stage Gate reviews verify that the agreed upon deliverables have been satisfactorily produced for a given
SDLC stage in order to approve advancement to the next phase. If any project milestones have not been
met, the IPT documents the actions required to address noted concerns. The emphasis of the Stage Gate
Review is:
• The successful accomplishment of lifecycle objectives per stage
• Informing IPTs of plans for the next life cycle stage
• Informing IPTs of the risks associated with moving into the next life cycle phase
Since each project, product, and investment is different, the Stage Gate Review(s) will incorporate and
address individual project characteristics. Each Stage Gate Review is conducted according to the project
tailoring defined in the Project Process Agreement (PPA) deliverable. Additionally, a Stage Gate Review
Checklist document and Phase Review Presentation is completed for each Stage Gate.
For continuity and convenience, the following tables contain brief descriptions of the Stage Gate Reviews
and Project Reviews for both Waterfall and Hybrid Agile Scrum.
Stage Gate Reviews
Waterfall SDLC
Initiation Stage Gate Review
The Initiation Stage Gate Review considers whether the Business
Case(s) and other deliverables such as the Acquisition
Strategy/Plan, initial Alternatives Analysis, Cost Benefit Analysis
and initial Acquisition Approval Request (AAR) approval from the
USDA OCIO justifies proceeding to the Requirements Gathering &
Analysis Phase. Project Reviews under this phase includes the
Architecture/Technical Review.
Requirements Gathering &
The Requirements Gathering & Analysis Stage Gate Review
System Development Lifecycle (SDLC) Guide
9
Analysis Stage Gate Review
considers whether the project should proceed to the Design Phase.
The objective is to determine if the project requirements have been
defined sufficiently to be translated into the system/application.
Project Reviews under this phase includes the Integrated Baseline
Review, Architecture/Technical Review, and Requirements
Review.
Design Stage Gate Review
The Design Stage Gate Review considers whether the project
should proceed to the Development Phase. The objective is to
determine if the project has finalized project planning and defined
initial baselines and requirements to permit outside validation.
Project Reviews under this phase includes the Architecture Review
and Design Review.
Development Stage Gate Review
The Development Stage Gate Review evaluates whether the project
should proceed to the Test Phase. The objective is to determine if
the code and/or other deliverables needed to build the
system/application have been completed within cost, schedule, and
scope guidelines. Project Reviews under this phase includes the
Validation Readiness Review and Independent Verification &
Validation Assessment.
Integration & Testing Stage Gate
Review
The Integration & Testing Stage Gate Review evaluates whether the
project should proceed to the Implementation Phase. The objective
is to determine if the test processes have been executed according to
plan and whether the tests verify that the implementation of the
system/application will be successful. Project Reviews under this
phase includes the Implementation Readiness Review and Security
Assessment & Authorization.
Implementation Stage Gate Review
The Implementation Stage Gate Review evaluates whether the
project should proceed to the O&M Phase. The objective is to
determine if the project has completed all required activities and
finalized implementation. Project Reviews under this phase
includes the Operational Readiness Review, Post Implementation
Review, and Security Assessment & Authorization.
A Stage Gate Review for a Go/No-Go decision is conducted for
initial release for new projects and all major releases.
Operations & Maintenance Stage
Gate Review
The O&M Stage Gate Review evaluates whether the project should
be released into the full-scale production environment for sustained
use and operations/maintenance support. The objective is to verify
that the system/application is managed and supported in a robust
production environment and to determine whether the
system/application is still cost-effective to operate or if it should be
System Development Lifecycle (SDLC) Guide
10
retired. Project Reviews under this phase includes the Operational
Analysis.
Disposition Stage Gate Review
A Disposition Review is conducted to ensure that a
system/application or any IT situation has been completely and
appropriately disposed, thereby ending the lifecycle of the IT
project. This phase-end review shall be conducted again within six
months after retirement of the system. The Disposition Review
Report also documents the lessons learned from the shutdown and
archiving of the terminated system. The objective is to have an
orderly shutdown of the system/application operation.
Hybrid Agile Scrum SDLC
Sprint Zero Stage Gate Review
With the Hybrid Agile Scrum approach, a Sprint Zero Stage Gate
Review is conducted after Sprint Zero to ensure that the project has
successfully completed the Initiation, Requirements Gathering &
Analysis, and Design phases.
The Pre-Development Stage Gate Review consists of completing
Sprint Zero and creating a sufficient Product Backlog that is
reviewed and prioritized by the Product/Business Owner. The
Product Backlog is dynamic and will be reviewed iteratively by the
Product/Business Owner during the course of the project. The
objectives are to determine if the project requirements have been
defined sufficiently to be translated into the system/application, and
to determine if the project has finalized project planning and
defined initial baselines and requirements to permit outside
validation.
Integration & Testing Stage Gate
Review
The Implementation & Testing Stage Gate Review for the Hybrid
Agile Scrum approach occurs when all development and system
testing has been completed and evaluates whether the project
should proceed to the Testing Phase, specifically UAT and
Independent Verification & Validation (IV&V) testing (if
applicable). The objective is to determine if the code and/or other
deliverables needed to develop the system/application have been
completed within cost, schedule, and scope guidelines. No separate
Project Reviews are required.
Implementation Stage Gate Review
The Implementation Stage Gate Review for the Hybrid Agile
Scrum approach occurs when all system testing has been
completed, evaluated, and approved, including UAT and IV&V
testing (if applicable), and the system is ready for a Go or No-Go
decision to be implemented. The objective is to determine if the
project has completed all required activities and finalized
System Development Lifecycle (SDLC) Guide
11
implementation. A Stage Gate Review for a Go/No-Go decision is
conducted for initial release for new projects and all major releases.
The only Project Reviews required for the Implementation Stage
Gate Review for the Hybrid Agile Scrum approach is the Security
Assessment & Authorization.
Operations & Maintenance Stage
Gate Review
The O&M Stage Gate Review for the Hybrid Agile Scrum approach
follows the same steps and requires the same deliverables as the
O&M Stage Gate Review for the Waterfall approach. Refer to the
Waterfall O&M State Gate Review section for more information.
Disposition Stage Gate Review
The Disposition Stage Gate Review for the Hybrid Agile Scrum
approach follows the same steps and requires the same deliverables
as the Disposition Stage Gate Review for the Waterfall approach.
Refer to the Waterfall Disposition State Gate Review section for
more information.
In addition to the Stage Gate Reviews, Management and Project Reviews are also conducted.
Management Reviews are conducted to provide project status updates to the Management team as needed
or requested. Various project reviews are conducted by the PM throughout the lifecycle of a project prior
to the Stage Gate and Management Reviews. Below are brief descriptions of each project review.
Project Reviews
Architecture/Technical Review
The purpose of the Architecture/Technical Review is to evaluate the
technical feasibility of the proposed allocation of functional
requirements to the system components (hardware, software, and
processes). The review also confirms that the system is being
completed in accordance with previous plans and includes
modifications prompted by earlier reviews. Once this review is
completed successfully, the preliminary design work can begin.
Integrated Baseline Review
The Integrated Baseline Review (IBR) is a formal inspection of the
entire project and performance measurement baseline initially
developed for the IT project. The IBR is conducted to obtain
management approval that the established scope, cost and schedule
that have been established for the project are adequately
documented and that the project management strategy is appropriate
for moving the project forward in the life cycle. Upon successful
completion of this review, the Project Management Plan is
officially baselined.
The IBR includes review of the budget, risk, and user requirements
for the investment. Emphasis should be on the total cost of
System Development Lifecycle (SDLC) Guide
12
ownership and not just development or acquisition costs.
Requirements Review
The Requirements Review is to ascertain if the functional
requirements are complete and attainable, and are based on and
traceable to prior documentation of high-level business
requirements or needs.
Design Review
The Design Review is a formal inspection of the architectural
design of an automated system and its software and external
interfaces. ensure design satisfies the functional and non-functional
requirements and is in conformance with the enterprise architecture.
Overall project status, proposed technical solutions, evolving
software products, associated documentation, and capacity
estimates are reviewed to determine completeness and consistency
with design standards, and to raise and resolve any technical and/or
project-related issues. The purpose of the Design Review is to
confirm that the design meets all functional requirements, the
design of each system component is complete, and the design is
ready for development. The review also confirms that the system
design was completed in accordance with previous plans and
includes modifications prompted by earlier reviews.
Validation/Test Readiness Review
A formal Validation Readiness Review (VRR), commonly known
as a Test Readiness Review, shall be conducted prior to each formal
test for each system release (excluding emergency releases). The
purpose of a VRR is to reach a technical understanding of previous
test results, and review the validity and degree of completeness of
the results of previous system testing and any updates to system
documentation. The VRR also determines whether the system test
procedures are complete and assures that the contractor is prepared
for formal system testing. VRRs will occur prior to system and user
acceptance testing. System test procedures are evaluated for
compliance with system test plans and descriptions, and for
adequacy in accomplishing test requirements.
Independent Verification &
Validation Review
The Independent Verification & Validation Review (IV&V) is a
highly recommended review and should be conducted to provide
assurance that the system meets the needs of the Product/Business
Owner and other identified stakeholders as well as to verify that the
system complies with all appropriate regulations, requirements,
specifications and any imposed conditions.
An IV&V is often conducted by an independent third party and
does not occur at FNS.
System Development Lifecycle (SDLC) Guide
13
Implementation Readiness Review
The Implementation Readiness Review (IRR) is performed at the
end of the system and user acceptance testing when the system is
ready to be released to production. The purpose of the IRR is to
determine that the system is ready to be released fully to the
production environment for user operation and subsequent
operation and maintenance activities. The review confirms that the
system performs its required functions in the production
environment, problems encountered during the UAT are adequately
addressed, user training can be successfully conducted and the data-
conversion process has been validated.
Operational Readiness Review
The Operational Readiness Review (ORR) is a formal inspection
conducted to determine if the final IT solution or automated
system/application that has been developed or acquired, tested, and
implemented is ready for release into the production environment
for sustained operations and maintenance support. The IT
governance organization cannot delegate this review.
Post Implementation Review
A Post-Implementation Review (PIR) shall be conducted to ensure
that the system functions as planned and expected; to verify that the
system cost is within the estimated amount; and to verify that the
intended benefits are derived as projected. Normally, this shall be a
one-time review that occurs after a major implementation. It may
also occur after a major enhancement to the system. The results of
an unacceptable review are submitted to the System Owner for
review and follow-up actions.
Note: PIRs may also be conducted prior to full implementation (for
example, after a pilot or in support of the go|no-go decision to full-
scale development or implementation).
Security Assessment &
Authorization
The Security Assessment & Authorization process ensures that
security and privacy controls are documented and evaluated to
determine the extent to which the controls are implemented
correctly, operating as intended, and producing the desired
outcome. It provides system stakeholders a view of security risks
associated with the system and the agency's business mission.
All USDA IT systems require an authorization prior to the system
becoming operational. Afterwards, each system will go through
Continuous Monitoring every year where 1/3 of their controls will
be tested.
Operational Analysis
The Operational Analysis (OA) is conducted on an annual basis to
determine: an investment’s continued effectiveness in supporting
mission and stakeholder requirements, evaluate the cost of
System Development Lifecycle (SDLC) Guide
14
continued maintenance support, manage risk, assess technology
opportunities, and consider potential retirement or replacement. The
results of this analysis are recommendations to the asset’s continued
use, modification, or termination/replacement.
System Development Lifecycle (SDLC) Guide
15
APPENDIX E – STAKEHOLDERS DEFINED
Stakeholders will vary depending on project size and needs. The Project Lead plays a key role in
determining stakeholders. An overview of stakeholders that may be involved in the SDLC is listed below.
Stakeholder
Definition
Business Analyst
Identifies business needs and determines solutions to
business problems. Solutions often include a software-
systems development component, but may also consist of
process improvement, organizational change or strategic
planning and policy development
Contractor
Independent entity that agrees to furnish a certain number
or quantity of goods, material, equipment, personnel,
and/or services that meet or exceed stated requirements or
specifications, at a mutually agreed upon price and within
a specified timeframe to another independent entity (FNS)
Developers
Concerned with facets of the software development
process, including the research, design, programming, and
testing of computer software
End Users
Ultimately uses or is intended to ultimately use a product
ICCB: Integrated
Configuration
Control Board
A group of project stakeholders responsible for evaluating
and approving or disapproving proposed changes to a
system; prioritizing the incorporation of approved
changes; and scheduling the changes for forthcoming
releases
IPT: Integrated
Project Team
A multidisciplinary group of people who are collectively
responsible for delivering a defined product or process
ISO: Information
Security Office
Responsible for the development and delivery of a
comprehensive information and privacy program at FNS
ITG: IT
Governance
Support Group
Responsible for the processes that ensure the effective and
efficient use of IT in enabling FNS to achieve its goals
Network Managers
Oversee the design, installation and running of IT, data
and telephony systems within FNS
O&MB:
Operations and
Maintenance
Branch
Provides support for a system once it is deployed in its
operational environment, monitors for satisfactory
performance, and modifies as necessary to correct
problems or to respond to changing requirements
OIT PM: Office of
Information
Technology Project
Responsible for leading a project from its inception to
execution. This includes planning, execution and
System Development Lifecycle (SDLC) Guide
16
Stakeholder
Definition
Manager
managing the people, resources and scope of the project
Project Sponsor
In charge of driving the project towards directions that
will bring the project to successful realization of expected
benefits. Finances project initiatives and approved ideas,
takes care of engagement processes, facilitates the
development of initial scope and the project charter, and
participates in processes of communications management
TRB: Technical
Review Board
An internal technical OIT group that reviews IT project
development at critical stages for conformance with FNS
standards and guidance
SDLC Executive
Committee
The entity responsible for developing and updating the
SDLC framework and guidance at FNS. Responsible for
reviewing the project upon the completion of each phase
throughout the lifecycle and approving it to move on to
the next phase
System Development Lifecycle (SDLC) Guide
17
APPENDIX F – SDLC EXECUTIVE COMMITTEE CHARTER
Introduction
This document establishes the purpose, organizational structure, roles, responsibilities, activities, and
meeting expectations of the SDLC Executive Committee at the US Department of Agriculture (USDA)
Food and Nutrition Service (FNS), Office of Information Technology (OIT).
Purpose of the Executive Committee
The Executive Committee is the entity responsible for SDLC stewardship at FNS. The Executive
Committee is critical to an effective SDLC in that it has the authority to: (1) oversee and make
adjustments to the SDLC and CONOPS process / methodology; (2) oversee and adjust the SDLC
supporting guidelines, procedures, and standards; and (3) advocate the SDLC at FNS. An effective SDLC
helps ensure the development of quality systems that meet user needs in an efficient manner.
Organizational Structure of the Executive Committee
The SDLC Executive Committee consists of OIT’s Division Directors, Branch Chiefs, and the SDLC
Program Manager. The composition of the Executive Committee is subject to change to meet evolving
organizational needs. The group functions in a collaborative, team-oriented manner aimed to collectively
overcome issues and make improvements to the SDLC and CONOPS. The table below outlines the
composition of the Executive Committee.
Organizational Role
Executive Committee Role
Responsibility
PMD Division Director
Executive Committee Director
Authority on final decisions
TD Director, ISO Chief, IRB,
& Branch Chiefs
Executive Committee
Members
Advocate for member’s specific
division/branch/support area consisting
of TD, ISO, ADB, PMB, O&MB, ITG,
TB, CSB, NOEB, and IRB
IT Governance Manager
Executive Committee Member
Advocate and provide expertise on
SDLC methodology
Activities of the Executive Committee
In support of achieving its objectives, the Executive Committee undertakes the following activities:
Objective
Activities
Oversee and adjust the SDLC
process / methodology
• Analyze SDLC performance measures
• Determine SDLC issues
• Identify issue prioritization and mitigation strategies
• Initiate performance improvement strategies
• Define project management roles / responsibilities, as
needed
System Development Lifecycle (SDLC) Guide
18
• Review emerging trends and best practices
• Refine SDLC goals, objectives and values, as necessary
• Update the SDLC, as needed
•
Communicate updates to external stakeholders, as necessary
Oversee and adjust guidelines,
procedures, and standards
• Assess needs related to guidance, procedures, and standards
• Authorize and modify SDLC guidelines, procedures, and
standards (such as Control Gate materials), as needed
Advocate the SDLC at FNS
• Develop, implement, and monitor a SDLC communications,
learning, and knowledge-sharing plan
• Participate in and approve Stage Gate Reviews for SDLC
projects
Executive Committee Meeting Expectations
Regular touch-points are critical for Executive Committee success. The Executive Committee will meet
quarterly unless otherwise determined by the Executive Committee Director. The Executive Committee
will also meet should urgent needs arise, as determined by the Executive Committee Director.
System Development Lifecycle (SDLC) Guide
19
ADDENDUM A – NON-SDLC PROJECTS
The non-SDLC process establishes a framework for projects that do not involve software development.
While these projects have previously been handled on an ad-hoc basis, they will now be handled within a
framework requiring review, analysis, documentation and approvals, but on a simpler scale than a
standard SDLC process. While non-SDLC projects are considered by many as simple projects not
requiring a process, these projects do still need management of scope, quality, time, cost, and risk. By
establishing and following a set process, this will allow for a review of possible impact on systems,
applications, and users; and alignment with overall goals and strategic plan. The non-SDLC process
provides a structure and set of governance, and the guidance required to ensure predictability and
consistency across all projects.
Benefits of the non-SDLC process include:
• Improved consistency, repeatability, flexibility, and transparency
• Strengthened controls and accountability
• Enhanced user, manager, and stakeholder involvement
• Improved integration and alignment to organizational objectives
• Reduced redundancies and improved cost-effectiveness
• Reduced project scope creep through enhanced up front needs analysis
• Increased compliance with current and planned enterprise architecture
As with SDLC projects, the Intake process must be inititiated by completing an Intake Process
Application Questionnaire and submitting it to the Program Management Branch (PMB). Once a request
has been approved as a project, the specific steps, reviews, approvals, and deliverables will be determined
and documented in the Project Process Agreement (PPA).
Recognizing the variety of non-SDLC projects, this process allows for tailoring of the process to include
customizing, waiving or combining activities, deliverables or project reviews based on the specific project
requirements or business needs. Tailoring is completed during the Initiation phase of the project and is
documented in the PPA. Although the PPA allows for tailoring of project requirements based on project
scope and size, all non-SDLC projects have general requirements of:
• Project Process Agreement
• Acquisition Approval Request (AAR) if project budget is over $25,000; if under $25,000, Chief
Information Officer (CIO) approval is needed
• Business Case
• High level requirements
• Streamlined Project Plan that includes a schedule and Communications Plan
• Project Reporting Application (PRA) entry
• Management Reviews (frequency will vary based on project scope and size and will be determined
through the PPA)
• Performance Work Statement (PWS) or Statement of Work (SOW) if vendor support is used
• Cost-Benefit Analysis
• Project Closing documentation (e.g., after action report, close-out checklist, lessons learned).
System Development Lifecycle (SDLC) Guide
20
Additional documentation and requirements may be needed depending upon the project scope and size,
which will be determined through the PPA, but the list above are general, basic requirements for all non-
SDLC projects.
A graphic diagram of the non-SDLC process is depicted below in Figure 23.
Figure 23. Non-SDLC Project Process

Navigation menu