System Development Lifecycle (SDLC) Guide Appendix C DDR Task Order #1 FNS SDLC
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 65
| Download | |
| Open PDF In Browser | View PDF |
SYSTEMS DEVELOPMENT LIFECYCLE (SDLC) GUIDE U.S. Department of Agriculture, Food and Nutrition Service Office of Information Technology August 31, 2017 Version 2.0 National Office – Park Office Center 3101 Park Office Drive Alexandria, VA 22012 System Development Lifecycle (SDLC) Guide APPROVAL OFFICE OF INFORMATION TECHNOLOGY This document was approved by: 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' ____________________________________________________ Kristin Ruiz Date Director, Portfolio Management Division, Office of Information Technology 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' ___________________________________________________ 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. 2 System Development Lifecycle (SDLC) Guide DOCUMENT REVISION HISTORY DATE 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 3 System Development Lifecycle (SDLC) Guide 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 4 System Development Lifecycle (SDLC) Guide 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 5 System Development Lifecycle (SDLC) Guide ACRONYM LIST REFERENCE A&A AAR ADB AO CIO CONOPS COR COTR EVM Fibonacci sequence FIPS 199 FNCS FNS IBR IPT IRR ISO IT ITG IV&V JIRA Kano Model MoSCoW O&M O&MB OA OCIO OIT OMB ORR PDR PERT PIA DEFINITION Assessment and Authorization Acquisition Approval Request Application Development Branch Authorizing Official Chief Information Officer Concept of Operations Contracting Officer’s Representative Contracting Officer’s Technical Representative Earned Value Management 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 Standards for Security Categorization of Federal Information and Information Systems Food, Nutrition and Consumer Services Food and Nutrition Service Integrated Baseline Review Integrated Project Team Implementation Readiness Review Information Security Office Information Technology Information Technology Support Group Independent Verification and Validation Issue and project management software tool developed by Atlassian 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 Must haves, Should haves, Could haves, Won't haves Operations and Maintenance Operations and Maintenance Branch Operational Analysis Office of the Chief Information Officer Office of Information Technology Office of Management and Budget Operational Readiness Review Preliminary Design Review Program Evaluation & Review Technique Privacy Impact Assessment 6 System Development Lifecycle (SDLC) Guide PIR PM PMB PMD PPA PSR PTA PWS SDLC SME SOO SORN SOW SRS TD UAT USDA VPAT VRR Walking Skeleton Post Implementation Review Project Manager Program Management Branch Portfolio Management Division Project Process Agreement Project Selection Review Privacy Threshold Analysis Performance Work Statement Systems Development Lifecycle Subject Matter Expert Statement of Objectives System of Records Notices Statement of Work System Requirements Specification Technology Division User Acceptance Testing United States Department of Agriculture Voluntary Product Accessibility Template Validation Readiness Review 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 7 System Development Lifecycle (SDLC) Guide 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 nonSDLC 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 nonSDLC 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 8 System Development Lifecycle (SDLC) Guide 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 size 1 and stakeholders 2 involved. A graphic diagram of the Waterfall model is depicted below in Figure 1. 1 2 Project size is detailed in Appendix A Stakeholders are defined in Appendix E 9 System Development Lifecycle (SDLC) Guide 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. Deliverables 3 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 10 System Development Lifecycle (SDLC) Guide • • • • 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. Deliverables 4 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 11 System Development Lifecycle (SDLC) Guide • • • • • • • • 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. 12 System Development Lifecycle (SDLC) Guide 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. Deliverables 5 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 13 System Development Lifecycle (SDLC) Guide 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. Deliverables 6 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: • • • 6 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 A comprehensive deliverables list by project size is shown in Appendix B 14 System Development Lifecycle (SDLC) Guide • 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. Deliverables 7 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 15 System Development Lifecycle (SDLC) Guide 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. Deliverables 8 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 16 System Development Lifecycle (SDLC) Guide 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. Deliverables 9 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 17 System Development Lifecycle (SDLC) Guide 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. Deliverables 10 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 18 System Development Lifecycle (SDLC) Guide 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. 19 System Development Lifecycle (SDLC) Guide • 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. 20 System Development Lifecycle (SDLC) Guide 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 Deliverables 11 in these phases include: 11 A comprehensive deliverables list by project size is shown in Appendix B 21 System Development Lifecycle (SDLC) Guide 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 22 System Development Lifecycle (SDLC) Guide 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. 23 System Development Lifecycle (SDLC) Guide Figure 21. Roles and Responsibilities for Hybrid Agile Scrum Role Responsibility Project Sponsor – Champions and sponsors the project within their organization • Product/Business Owner – Represents the business or user community and is responsible for determining what features will be in the product release • • • • • • Ensures accountability for the realization of project benefits Ensures oversight of the project management function Manages senior stakeholders 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 • 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 • • • • 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 24 System Development Lifecycle (SDLC) Guide Figure 22 provides an overview of the Hybrid Agile Scrum process. Figure 22. Hybrid Agile Scum Methodology 2.2.2.1. Sprint Zero 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 25 System Development Lifecycle (SDLC) Guide 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. 2.2.2.2. Sprint Cycles 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 26 System Development Lifecycle (SDLC) Guide 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) 27 System Development Lifecycle (SDLC) Guide 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. 2.2.2.3. Release Management 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. 28 System Development Lifecycle (SDLC) Guide • • • • • 4 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. 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 29 SDLC Guide 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. SDLC Guide May 12, 2017 Page 1 System Development Lifecycle (SDLC) Guide APPENDIX B – SDLC PHASE REQUIREMENTS Waterfall Phase Requirements Phase 1 - Initiation Phase 1 – Initiation Inputs • N/A Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables Small Medium Large Business Case: FNS755 Acquisition Plan / Strategy Acquisition Approval Request Business Case: FNS758 Alternative Analysis Cost Benefit Analysis Procurement Documents – SOW/PWS, SOO (with ISO input) Stakeholders • • Project Sponsor Office of Information Technology Project Manager (OIT PM) 2 System Development Lifecycle (SDLC) Guide Phase 1 – Initiation • Subject Matter Experts (SMEs) Phase 2 – Requirements Gathering and Analysis Phase 2 - Requirements Gathering and Analysis Inputs • Business Case Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables 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 3 System Development Lifecycle (SDLC) Guide Phase 2 - Requirements Gathering and Analysis Scheduling High-Level System Requirements Specification (SRS) System Requirements Specification (SRS) Stakeholders 12 13 Concept of Operations 12 Requirements Traceability Matrix FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems 13 • • • Project Sponsor SMEs OIT PM • • Business Analyst IPT Concept of Operations is optional for large projects. As required by Information Security Office (ISO) 4 System Development Lifecycle (SDLC) Guide Phase 3 - Design Phase 3 – Design Inputs • • • Business Case Project Management Plan System Requirements Document Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables Small Medium Large System Design Document Configuration Management Plan/Change Control Board Charter 14 15 Contingency Plan 16 (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 Configuration Management Plan is optional for small projects. As required by Information Security Office (ISO) 16 As required by Information Security Office (ISO) 14 15 5 System Development Lifecycle (SDLC) Guide Phase 4 - Development Phase 4 – Development Inputs • • Outputs/ Deliverables Outputs/ Deliverables System Requirements Document System Design Document 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 6 System Development Lifecycle (SDLC) Guide Phase 5 – Integration and Testing Phase 5 - Integration and Testing Input • • • • System Requirements Document System Design Document Project Plan Test Plan Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables Small Medium Large Transition Plan Operations/Maintenance Manual UAT Sign-Off System Security Plan 17 Interconnection Security Agreement(s) (if applicable) 18 Contingency Plan Test (CPT) Report 19 Security Assessment Plan (also known as Security Test & Evaluation Plan) 20 Security Assessment Report (includes Security Requirements Traceability Matrix) 21 As required by Information Security Office (ISO) 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) 17 18 7 System Development Lifecycle (SDLC) Guide Plan of Action & Milestones (POA&Ms) 22 Stakeholders 22 Vulnerability / App Scan Results Release Management Plan Training Manual User Manual Test Results Section 508 VPAT and/or Certification • • • OIT PM Business Analyst Developers • • • • SMEs OIT PM Testers IPT As required by Information Security Office (ISO) 8 System Development Lifecycle (SDLC) Guide Phase 6 – Implementation Phase Inputs 6 – Implementation • • • • Project Management Plan System Requirements Document System Design Document Test Plan Project Size Outputs / Deliverables (Checkmark Denotes required) Outputs / Deliverables Installation Document 23 Small Medium Large Concurrency Review Memo 24 Operations Readiness Life Cycle Cost Project Closeout Performance Measures Authority to Operate 25 Application Guide 26 Source Code Installation document is optional for small projects 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 23 24 9 System Development Lifecycle (SDLC) Guide Phase Stakeholders 6 – Implementation • • • • • OIT PM Business Analyst Project Sponsor SMEs Network Managers • • • • Developers Contractors IPT IT Governance Support Group (ITG) 10 System Development Lifecycle (SDLC) Guide 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 Project Size Outputs / Deliverables (Checkmark Denotes required) Output / Deliverables Small System Post Implementation Review Report Operational Analysis (includes Operational and Performance Metrics) Medium Large Annual Updates Required: • • • • • • Systems Security Plan 27 Contingency Plan (includes Disaster Recovery Plan) 28 System Risk Management Plan 29 Configuration Management Plan/Change Control Board Charter 30 Life Cycle Cost Concurrency Review Memo 31 Routine Maintenance As required by Information Security Office (ISO) 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) 27 28 11 System Development Lifecycle (SDLC) Guide 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 Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables Small Medium Large System Disposition Plan System Disposition Checklist Post Termination Review Report Disposition Memo 33 • Stakeholders 32 33 ITG O&MB As required by Information Security Office (ISO) As required by Information Security Office (ISO) 12 System Development Lifecycle (SDLC) Guide 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 Project Size Outputs / Deliverables (Checkmark denotes required) Outputs / Deliverables Small Medium Large Retrospective Meeting Minutes Release Management Plan Product Roadmap Product Backlog Release Burndown Chart Sprint Burndown Chart Privacy Threshold Analysis (PTA) 13 System Development Lifecycle (SDLC) Guide 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 Charter 35 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) As required by Information Security Office (ISO) Configuration Management Plan is optional for small projects 36 As required by Information Security Office (ISO) 37 As required by Information Security Office (ISO) 34 35 14 System Development Lifecycle (SDLC) Guide EVM Report Transition Plan Operation/Maintenance Manual System Security Plan 38 Interconnection Security Agreement(s) (if applicable) 39 Contingency Plan Test (CPT) Report 40 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 As required by Information Security Office (ISO) 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) 38 39 15 System Development Lifecycle (SDLC) Guide 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. 16 SDLC Guide APPENDIX C – SDLC PROJECT PROCESS FLOW Waterfall Method Process Flow SDLC Guide May 12, 2017 Page 1 System Development Lifecycle (SDLC) Guide 2 System Development Lifecycle (SDLC) Guide 3 System Development Lifecycle (SDLC) Guide 4 System Development Lifecycle (SDLC) Guide Agile Hybrid Scrum Method Process Flow 5 System Development Lifecycle (SDLC) Guide 6 System Development Lifecycle (SDLC) Guide 7 SDLC Guide 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 SDLC Guide May 12, 2017 Page 8 System Development Lifecycle (SDLC) Guide 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 9 System Development Lifecycle (SDLC) Guide 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 10 System Development Lifecycle (SDLC) Guide 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 11 System Development Lifecycle (SDLC) Guide 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. 12 System Development Lifecycle (SDLC) Guide 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 dataconversion 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 fullscale 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 13 System Development Lifecycle (SDLC) Guide 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. 14 System Development Lifecycle (SDLC) Guide 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 softwaresystems 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 15 System Development Lifecycle (SDLC) Guide 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 16 System Development Lifecycle (SDLC) Guide 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 Oversee and adjust the SDLC process / methodology Activities • • • • • Analyze SDLC performance measures Determine SDLC issues Identify issue prioritization and mitigation strategies Initiate performance improvement strategies Define project management roles / responsibilities, as needed 17 System Development Lifecycle (SDLC) Guide Oversee and adjust guidelines, procedures, and standards • • • • • • Advocate the SDLC at FNS • • 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 Assess needs related to guidance, procedures, and standards Authorize and modify SDLC guidelines, procedures, and standards (such as Control Gate materials), as needed 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. 18 System Development Lifecycle (SDLC) Guide 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). 19 System Development Lifecycle (SDLC) Guide 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 nonSDLC projects. A graphic diagram of the non-SDLC process is depicted below in Figure 23. Figure 23. Non-SDLC Project Process 20
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.6 Linearized : No Author : Russ, Kevin - FNS Company : USDA-FNS Content Type Id : 0x010100CAFC0368CE9E9F4B834A4D98EF0BCC34 Create Date : 2017:09:06 14:56:16-04:00 Modify Date : 2017:09:06 17:03:24-04:00 Source Modified : D:20170906185524 Has XFA : No Language : EN-US Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.4-c006 80.159825, 2016/09/16-03:31:08 Metadata Date : 2017:09:06 17:03:24-04:00 Creator Tool : Acrobat PDFMaker 11 for Word Document ID : uuid:b5e334c6-a571-4feb-90f9-f7914cf359ce Instance ID : uuid:6a02a077-13f4-4577-838e-97f42b2de252 Subject : 4 Format : application/pdf Title : System Development Lifecycle (SDLC) Guide Creator : Russ, Kevin - FNS Producer : Adobe PDF Library 11.0 Page Layout : OneColumn Page Count : 65EXIF Metadata provided by EXIF.tools