Attachment 12 Software Development Lifecycle SDLC Process Guide.pdf

8/04/2020 Version 2.0

IT Governance

System Development Lifecycle (SDLC) Process Guide

Technology Office Rural Development Washington, D.C.

System Development Lifecycle (SDLC) Process Guide

RD Technology Office ii

Table of Contents

1. OVERVIEW

1.1. Purpose

1.2. References

1.3. Using This Document

1.4. SDLC Phase and Stage Overview

2. AGILE SDLC STAGES IN-DEPTH

2.1. Pre-Select Stage / Mission Needs Process

Pre-Select Stage Objective Pre-Select Stage Artifacts Pre-Select Stage Gate Review (IRB Investment Selection) Contracting and Budgeting

2.2. Plan Stage

Plan Stage Objective Plan Stage Key Activities Plan Stage Artifacts Agile Development Readiness Stage Gate Review

2.3. Agile Development

Agile Development Objectives Key Activities – Prior to Sprint 1 Key Activities – Sprint 1 Key Activities – Iterative Sprints

Key Activities – Final Sprint (Pre-Release) Cybersecurity A&A Process Agile Development Artifacts Deploy Readiness SGR

2.4. Deploy and Close

Deploy Stage Close Stage

3. SDLC FOR WATERFALL PROJECTS

3.1. Pre-Select Stage / Mission Needs Process

3.2. Plan Stage

Plan Stage Key Activities Plan Stage Artifacts

Design Readiness Stage Gate Review

3.3. Design Stage

Design Stage Key Activities Design Stage Artifacts Develop Readiness Stage Gate Review

3.4. Develop Stage

Develop Stage Key Activities Develop Key Artifacts Test Readiness Stage Gate Review

3.5. Test Stage

Test Key Activities Test Key Artifacts Deploy Readiness Stage Gate Review

RD Technology Office iii

3.6. Deploy Stage

3.7. Close Stage

APPENDIX A: COMPREHENSIVE PROJECT DELIVERABLES LIST – AGILE

APPENDIX B: COMPREHENSIVE PROJECT DELIVERABLES LIST – WATERFALL

APPENDIX C: CYBERSECURITY ARTIFACT DESCRIPTIONS

APPENDIX D: GLOSSARY OF TERMS AND ACRONYMS

Table of Figures

Figure 1: RD System Development Lifecycle Figure 2: RDTO SDLC Stages (Agile) Figure 3: Iterative Release Activities - Agile Development Figure 4: RD SDLC Stages (Waterfall)

RD Technology Office 4

1. Overview

1.1. Purpose

The U.S. Department of Agriculture (USDA) Rural Development Technology Office (RDTO) System Development Lifecycle (SDLC) promotes the successful planning, execution, and control of IT projects by providing a framework to ensure that all aspects of a project are properly and consistently defined, planned, and communicated. This Process Guide is intended to provide clear and comprehensive guidance on the standard development process for both new and existing RDTO IT projects, as well as a single resource for SDLC procedures. The SDLC uses an “Agile first” approach, where the structure of projects and related activities follows an Agile-friendly methodology, while allowing for hybrid or waterfall methodologies as needed.

The intent of this approach is to meet all standards and objectives outlined within the USDA Integrated IT Governance Framework, including its required deliverables and decision gate review requirements for major investments, while providing RD-level implementation details. Links to the department’s Integrated IT Governance Framework documentation are available on the USDA OCIO website. Projects that fall under RD investments must also align with the Enterprise Architecture (EA) strategy, driven by the Assistant Chief Information Officer’s (ACIO) IT Strategic Plan.

1.2. References

RDTO SDLC Stage Gate Review Process Guide, v.2.0 USDA Integrated IT Governance Framework Overview; Deliverables Matrix; and IT Management

Lifecycle, v3.2, 1 April 2014 OMB FY21 IT Budget – Capital Planning Guidance, Revision 28 June 2019 Key Agile Concepts – Agile Alliance, Accessed 16 February 2017 SAFe 4.6 for Lean Enterprises, 03 October 2018 RDTO Enterprise Architecture Process Guide

1.3. Using This Document

IT project teams will use this Process Guide from the beginning of all RD IT projects through completion, through every phase and stage of the SDLC. This includes the following:

Assessing the current and target technology landscape and business stakeholders Initiating a project Planning for the requirements and necessary resources Conceptualizing and designing system functionality Developing and testing the functionality Deploying the functionality to the production environment Supporting the business users as they begin using the new or updated system.

For each project stage, the SDLC will define the required artifacts to be created and activities to be performed in order to progress to the next stage. A library of detailed standard operating procedures (SOPs) for completing individual artifacts and activities will be maintained in JIRA/Confluence and made available to all RDTO members.

RD Technology Office 5

It is important to note that not all IT projects have the same size and scope, so some tailoring of artifacts, activities, and Stages is permitted and even expected. Many of the deliverable documents referenced in the SDLC have associated templates, which are available in JIRA/Confluence. A full list of SDLC artifacts is provided in Appendix A — Comprehensive Project Deliverables List.

Deliverables for each stage are identified as Initial, Draft, Final, Updates, or Activity/Action to be performed. Initial documents for a given stage should be fully completed and able to stand as final deliverables but may be adjusted slightly in subsequent stages to ensure alignment with the project. Draft documents for a given stage may be considered “working versions” with significant revisions expected.

Since the SDLC process is part of the overall RD IT Governance strategy, it includes high-level guidance for Cybersecurity, EA, Capital Planning and Investment Control (CPIC), and project management processes. To facilitate best practices in running an IT development process and to meet Office of Management and Budget (OMB) requirements in a coordinated effort, these processes work in correlation with the SDLC Process Guide to assist project teams throughout the entire lifecycle. A library of guides for these processes will be maintained in JIRA/Confluence and made available to all RDTO members.

RDTO will monitor and enforce adherence to the SDLC via the SDLC Stage Gate Review (SGR) process, which is referenced throughout this document. More information on the SGR process is available in the SGR Process Guide, maintained in the SDLC library in JIRA/Confluence.

RDTO will manage Operations and Maintenance (O&M) activities under the Sustainment Engineering Team (SET) process, which is beyond the scope of this document and detailed in the SET Process Guide.

1.4. SDLC Phase and Stage Overview

The RDTO SDLC defines the lifecycle of a system in terms of high-level phases, with multiple stages of project activity that occur within each phase. As illustrated in Figure 1 on the following page, the SDLC defines the following three major phases of a system’s life:

1. Pre-selection

2. Development

3. Production

Figure 1 depicts a system in “cradle-to-grave” fashion with perspectives of the lifecycle from the SDLC stages through which it passes; the IT projects spawned to create and effect change to the system; and the type of authorization necessary to initiate a project.

RD Technology Office 6

Figure 1: RD System Development Lifecycle

The Pre-Selection phase is a timeframe wherein a given system does not yet exist. This phase has only one stage within it, the Pre-Selection stage. Within this stage, the original business need or problem is analyzed, a solution or proof of concept is proposed, and impacts from the distinct governance perspectives of the proposed system are assessed. This stage culminates in a decision by the Investment Review Board (IRB) to approve or disapprove this system as an investment to which the agency may allocate funding and resources.

If the system is approved by the IRB for implementation, then it will become a project and will move into the Development phase of RDTO’s SDLC process.

The Development phase is the period in which the project activities necessary to create a new system or otherwise address the project requirements are executed. This phase contains the following stages that can also be considered the stages of an IT project: (1) Plan; (2) Agile Development that combines iterative Design, Develop, and Test activities; (3) Deploy; and (4) Close. The OMB classifies development of or changes to an IT asset or system as either Development, Modernization, and Enhancement (DME) or O&M. For example, a project involving the creation or initiation of a system, that effort falls under DME and is considered a Development project.

RD Technology Office 7

The Production phase encompasses the “operational life” of the system and starts after the system has been developed and deployed into the production environment, making it operational. The system is now referred to as being in “steady state.” The Production phase can span many years and is characterized by teams executing projects on the operational system to implement change/perform maintenance on the system. These changes can be classified as DME projects, O&M efforts, or a combination of these activities. The USDA OCIO Capital Planning and IT Governance Division has developed IT Definitions guidance that includes guidelines for distinguishing between DME and O&M efforts. Under RDTO policy, if an O&M activity requires more than 80 hours of development time to complete, the activity will be reclassified as a DME project.

The stages involved in the Production phase mirror those of the Development phase. However, if the project involves DME changes to the operational system, a preliminary Mission Needs Analysis will be required, similar to the activities in the Pre-Selection phase. IRB approval is required to proceed before a DME-type project against a production system may enter its Plan stage.

At the end of its “useful" life in the Production phase, a system is methodically shut down and permanently disposed of because it is being replaced or is now deemed obsolete for various reasons.

This activity is also referred to as “decommissioning the system.” Once the approval to retire a system is obtained, the project involved to execute this retirement typically includes the following stages: combined Plan and Test and combined Deploy and Close. (Generally, no Design or Develop activities are involved.)

A unique set of Decommissioning artifacts will be completed in place of the standard DME artifact suite.

2. Agile SDLC Stages In-Depth The objectives, key activities, and required artifacts of each SDLC stage for Agile projects are covered below.

The RD SDLC is an iterative process comprised of five stages: Pre-Select, Plan, Agile Development (combined Design, Develop, and Test activities in iterative sprints), Deploy, and Close. This process pulls key elements from the USDA SDLC, Lean Agile, Scaled Agile Framework (SAFe), Project Lifecycle, Rational Unified Process, and other methodologies to create an approach that satisfies the unique constraints of the RD development environment. The RD SDLC provides a standard approach that results in the production of well-documented, quality software.

Most RDTO projects follow Agile methodologies, based on an RDTO determination of the appropriate methodology and the documentation in the Performance Work Statement or Task Order award. Key Agile concepts include the following:

Program Increment – A timebox during which an Agile team delivers incremental value in the form of working, tested software and systems. Program Increments are typically 8–12 weeks long and include Agile development sprints with an Innovation and Planning iteration.

Epic – a large unit of work that captures high-level stakeholder needs and business value. Epics can be broken down into features with specific tasks called “user stories” based on the needs and requests of customers or end users. They are implemented over multiple sprints or program increments.

Feature – A service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria and is sized or split so it can be delivered by an Agile team in a Program Increment. Features break down larger business value captured at the epic level.

RD Technology Office 8

User Stories – In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories" that reflect how a given user would interact with a higher-level feature. Each user story is expected to yield a contribution to the value of the overall product and must be achievable within a single iteration or sprint.

Daily Meeting – Each day at the same time, the team meets to bring everyone up to date on the information that is vital for coordination. Each team member briefly describes any "completed" contributions and any obstacles that stand in their way.

Incremental Development – Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable and builds upon the previous version by adding user-visible functionality.

Iterative Development – Agile projects are iterative insofar as they intentionally allow for "repeating" software development activities and for potentially "revisiting" the same work products.

Team – In the Agile sense, a team is a small group of people assigned to the same project or effort, nearly all of them on a full-time basis. A small minority of team members may be part-time contributors or may have a shared services model with responsibilities across multiple teams.

Milestone Retrospective – Once a project has been underway for some time or at the end of the project or program increment, all permanent team members (not just the developers) invest from one to three days in a detailed analysis of the project's significant events.

Minimum Viable Product (MVP) – A completed, functioning code base ready at the end of each sprint. For RDTO, the MVP target deployment will be to a pre-production environment such as Test/Quality Assurance (QA), rather than the full Production deployment that occurs after a Deploy Readiness SGR and during the Deploy stage. At RDTO, the SDLC supports a release-on-demand model where the business helps drive the acceptance of an MVP for deployment at logical increments.

Personas – When the project calls for it—for instance, when user experience is a major factor in project outcomes—the team crafts detailed, synthetic biographies of fictitious users of the future product, referred to as personas.

Product Owner – A member of the team that is responsible for the product vision. The Product Owner manages the Product Backlog by clarifying and prioritizing value, and defines epics, features, user stories, and acceptance criteria.

The Agile Alliance includes these as the foundational concepts for Agile work. Additional key concepts can be found at https://www.agilealliance.org/agile101/agile-glossary/. The RDTO SDLC references a limited number of concepts from SAFe Agile methodology, which can be found at https://v46.scaledagileframework.com/.

RDTO projects will follow an Agile-first methodology of project management. Figure 2 below depicts a typical Agile method where Design, Develop, and Test activities are bundled for each implementation sprint. Once all sprints have been completed, the cumulative activities, artifacts, and MVPs for those sprints are reviewed at a Deploy Readiness SGR Meeting prior to the production release. An Agile project with two production releases may have one SGR after Plan, one SGR after Agile Development (iterative Design/Develop/Test sprints) for each release, one SGR for Deploy following each release, and one

RD Technology Office 9

Close SGR covering all project releases. Agile projects leverage Program-level artifacts whenever possible.

Figure 2: RDTO SDLC Stages (Agile)

The SDLC process is not meant to be one size fits all, and projects should tailor their activities and deliverables in collaboration with functional area teams. To that end, projects can substitute, waive, and/or consolidate SDLC artifacts and/or Stages with the written approval of the Solutions Development Director and DACIO. Agile development, Commercial Off-The-Shelf, Software as a Service, infrastructure projects, emergencies, and minor DME changes (e.g., spelling changes, reformatting a page, additional data element in a report from existing database connections) are all examples of factors that would influence project tailoring. A Project Tailoring Plan must capture all modifications, such as combining SGRs or consolidating artifacts, and will be approved by the functional area reviewers, SGR Chair, and

DACIO.

Agile projects should not treat a combination of stages as a reason to defer activities or delay reviews by functional areas, which should review work products as they are created. For example, a team that iteratively completes Design, Cybersecurity, and Privacy artifacts must not wait until the final sprints of the Agile Development stage before reviewing these artifacts with the EA, Cybersecurity, and Development teams. Further, teams must receive a design concurrence from EA, Data Engineering, Cybersecurity, Production Systems Operations (PSO), and Development prior to implementation.

2.1. Pre-Select Stage / Mission Needs Process

Pre-Select Stage Objective The SDLC Pre-Select stage is a fundamental step in assessing the need for a system development project against its applicability to and impact on the RD mission. Part of this step is following the Requirements Management Plan (RQMP) to create accurate and thorough documentation to establish business needs and the impact on the Agency.

RD Technology Office 10

The Pre-Select stage corresponds with the RD Mission Needs process, which takes requests from the initial business inception, through operational assessment to funding approval. The process identifies two areas for business improvement: (1) unresolved, business gaps and the impact that they will have on vital business processes and (2) the technology opportunities available to increase efficiency and/or effectiveness. The requirements development process begins with the completion of the Mission Needs process, which works in conjunction with the RQMP.

The Pre-Select stage allows the business and RDTO to identify the capability gaps, overlaps, deficiencies, or technological opportunities to be addressed via a DME project. The business develops a Mission Needs document, which is then used by the Requirements team, the EA team, the Data Engineering team, and the business to create High Level Business Requirements (HLBRs) and epics.

This HLBR undergoes an architectural review by the EA team and is used by the Budget team to develop project cost estimates. Based on the HLBR, architectural review, and cost estimation, the IRB analyzes and ranks the project against other projects in the portfolio for selection.

Due to the high level of complexity, all Mission Needs activities will be further detailed in and managed according to the Mission Needs Process Guide that is to be released in FY20.

Pre-Select Stage Artifacts The following artifacts are outputs from the Pre-Select stage about proposed IT investments/projects:

Mission Needs Statement – Final Mission Needs Assessment – Final High-Level Business Requirements – Final RDTO Roadmap adjustments – Final Epics – Final Gap Analysis – Final Cost Model/Level of Effort – Final

Pre-Select Stage Gate Review (IRB Investment Selection) Once the key activities of the Pre-Select stage have been accomplished and all required artifacts for this stage have been produced at the correct level of completion (i.e., draft or final), the RDTO leadership reviews the package of artifacts produced during Pre-Select for each submitted Mission Need. Based on this review, RDTO leadership provides investment selection recommendations to the IRB supporting their final IT Investment Selection decisions. These decisions become the IT projects that will be implemented.

Contracting and Budgeting The Contract and Budget teams will be notified once a project slate has been selected by the IRB so the contracting and budgeting processes can begin. These processes are managed outside the scope of this SDLC and will be documented separately. A library of all associated process guides and guidance will be maintained in JIRA/Confluence and made available to all RDTO members.

RD Technology Office 11

2.2. Plan Stage

Plan Stage Objective The goal of the Plan stage is for the project team to create a project plan that meets the business needs determined during the Pre-Select stage. This stage begins the process of changing the ideas expressed in terms of epics into features and user stories, and a considerable amount of time is spent interacting with stakeholders and reviewing the provided input.

Plan Stage Key Activities Develop the Project Tailoring Plan – The Project Tailoring Plan provides a formal, documented means for a specific project to have its Stage Gates and project deliverables tailored to better fit the project’s development methodology and complexity. This document is a required deliverable and may be updated in each subsequent stage with approval from the SGR team.

Develop the Project Plan – All PMs must complete a Project Charter and Project Management Plan for a project. These documents align with lean agile best practices and will reflect the project management structure and approach as described below.

o Project Charter: The Project Charter is a document that defines and justifies the project. It includes: (1) a clear statement of the project purpose; (2) a clearly defined scope statement;

(3) a list of high-level stakeholders, including the Product Manager and PM; and (4) a statement defining and granting project management authority to the Product Manager and PM. The Charter must be approved by RDTO leadership upon completion.

o Project Management Plan (PMP): This key deliverable guides the project through to its successful completion and includes several elements: (1) a statement of the business need/problem being addressed; (2) business objectives to be met; (3) project/program financials; (4) key milestones; (5) roles and responsibilities; (6) assumptions, constraints, dependencies, and impacts; (7) management approaches for risk, communications, quality, and change; (8) metrics collection; and (9) a glossary of terms, acronyms, and definitions.

Develop the Integrated Master Schedule (IMS) – The PM will maintain the IMS in compliance with the RDTO process.

Document the Project Risks – All PMs must document and manage project risks in the RD Risk Register throughout the project’s lifecycle.

Develop the Project Metrics – The PM will analyze the current slate of investment metrics and align one or more metrics to project goals. If no metric exists, one or more new metrics aligning to project goals will be developed in compliance with CPIC reporting requirements. Metrics must align to one or more of the following categories: Customer Satisfaction, Strategic and Business Results, Financial Performance, and/or Innovation.

Define the Business Requirements and Develop the Release Backlog – For Agile projects, the release backlog undergoes backlog grooming to break down epics into user stories that can be achieved within a single sprint. This ensures that all user stories have sufficient detail and viable acceptance criteria prior to development. Functional requirements and system requirements will be defined, prioritized, and validated based on the system capabilities requested by the stakeholders.

RD Technology Office 12

Begin Architecture Definition – Use Case Modeling and Business Process Modeling will be refined according to the defined requirements. A draft Architecture Description Document (ADD) package must be developed and refined based on documentation formed through the requirements and backlog grooming processes.

Coordinate Testing Plans – The PM and project team will coordinate plans for testing with the QA, Cybersecurity, and PSO teams via line items in the project schedule, cross-functional Integrated Project Team meetings, and any required forms in designated RDTO workflow tracking tools.

Develop the Customized Security and Privacy Design Requirements – The Security team provides the RD Baseline Security Requirements and the Baseline Privacy Requirements for the project team to review and include as part of their release backlog. After the development staff has produced the conceptual model of the functional and technical architecture, the RD Cybersecurity team will assist with security-focused design reviews to ensure that security mechanisms built into the system architecture and design fulfill the requirements. Agile projects will capture these as acceptance criteria for all applicable epics and stories in the Release Backlog.

Initiate a Business Impact Analysis – The PM and project team will coordinate with the Cybersecurity and EA teams to initiate a Business Impact Analysis, an analysis of the business processes and interdependencies used to characterize contingency requirements and priorities in the event of a significant service disruption.

Complete the Security Review – Application security must be reviewed by the Cybersecurity team. The design must be validated against the RDTO Baseline Security Requirements and Privacy Baseline Requirements, and guidance must be provided to the Development team to resolve security related architectural and design issues.

Conduct the Preliminary Design Review (PDR) – Product Development teams should conduct a PDR, which will serve as confirmation of the high-level design approach (or “Sprint 0” review) prior to the team completing detailed design and beginning development. The PDR serves to confirm a high-level contextual architecture (draft of ADD Sections 1-5). This PDR will follow all approved RDTO change control processes and guidelines and may be incorporated into the Pre- Development review (see Section 2.3.2) in place of a stand-alone meeting, subject to the approval of the PM and EA Team.

Plan Stage Artifacts The following artifacts are the required outputs from the Plan stage that are reviewed by the SGR Committee:

Project Tailoring Plan – Initial Project Plan – Charter, PMP – Final Project Risks (documented in Risk Register) – Initial Integrated Master Schedule – Initial Metrics – Draft Release Backlog – Initial Release Plan – Initial Security and Privacy Baseline Requirements – Final

RD Technology Office 13

Functional and System Requirements – Initial Architecture Description Document – Draft Business Impact Analysis (BIA) – Initial Agile Development Readiness Review Presentation – Final

Agile Development Readiness Stage Gate Review Once the key activities of the Plan stage have been accomplished and all required artifacts for this stage have been produced at the correct level of completion (initial, draft, updated, or final), the SGR Committee will determine the project’s readiness to enter the Agile Development stage. The SGR Committee reviews all required output artifacts from this stage and provides the authorization to proceed to the Agile Development stage via a full or provisional approval. If granted a provisional approval, the PM will be responsible for completing all action items and reporting back to the SGR Committee within the specified timeframe. The SGR Committee must confirm the action items are completed before the SGR Chair will provide full SGR approval.

2.3. Agile Development

Most RD projects combine design, develop, and test activities into iterative sprints, each of which culminates in an MVP deployment. (See Figure 3.) Each project will define its target deployment environment following the completion of development activities for each sprint (typically in the Test/QA environment). After a project completes all sprints and obtains SGR Committee approval on cumulative Agile Development activities and artifacts, as well as on Integration testing and User Acceptance Testing (UAT), there will be a final deployment to Production. Activities associated with these deployments to Production are addressed separately in Section 2.4.1.

In addition to iterative sprint activities, some RDTO processes and artifacts are completed non-iteratively during the Agile Development stage for a release. The Security Assessment and Authorization (A&A) process begins in Sprint 1 and is completed a single time throughout Agile Development, culminating in the issuing of a signed Authority to Operate (ATO) or Authority to Test letter from the ACIO prior to a production release. The A&A process is detailed separately in Section 2.3.5. Other activities, such as Department-level 508 testing, are only completed once during the initial or final sprint before production release. Activities specific to the first and last sprints are addressed in Sections 2.3.2 and 2.3.4, respectively.

An initial PI Planning Session will be held prior to completing the first sprint, with additional PI Planning Sessions scheduled every 10 – 12 weeks until the production deployment occurs. During each 2-day session, the project teams, stakeholders, product owners, and product managers gather in one place to review the program backlog and determine the direction of the business. Each PI Planning Session yields a list of accepted features with associated delivery dates, feature dependencies with other teams, and updated project milestones.

RD Technology Office 14

Figure 3: Iterative Release Activities - Agile Development

Agile Development Objectives

2.3.1.1. Design Activity Objectives

The goals of design activities are to allocate system functionality, understand the domain, and establish the test strategy based on the Project Plan and requirements determined with stakeholders. Design activities determine data flows within the system and interfaces with external systems. User interfaces and design mock-ups (wire frames) are developed and reviewed according to stakeholder requests. The Mission Needs architectural analysis, as well as prior design artifacts for existing applications, are used as starting points for developing the application architecture. During Design activities, the ADD package is refined to further describe how the solution will meet the requirements.

2.3.1.2. Develop Activity Objectives

Develop activities feature a key step in the project: system construction. To complete Develop activities successfully, two elements are required: (1) a complete set of design specifications and (2) proper processes, standards, and tools. Developers implement the design specification developed during Design activities, design the database, generate the code for the data flow process, and design the actual user interface screens. The Security team performs static code analysis and code review as needed.

Continuous Integration is required by developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

2.3.1.3. Test Activity Objectives

In addition to the developer testing, QA testing is completed during an Independent Testing period. All aspects of the system are tested for functionality and performance, and test data is prepared and processed by developers to refine the code. The system is tested for integration with other products as well as with any previous versions with which it needs to communicate. The activities in this stage must validate and confirm that the system contains all the end user requirements, that all the functions are accurately processing data, that the new system works with all other systems or prior systems, and that the new system meets the quality standards of the company and the customers.

RD Technology Office 15

Key Activities – Prior to Sprint 1 Immediately prior to the start of Sprint 1 activities, the PM and project team will conduct a Pre- Development review with members of the business, the IPT, and other key stakeholders. This review will focus on objectives, requirements, and changes for the upcoming release and will result in the following documentation:

Objectives for each sprint and the overall development effort, to include a clearly defined list of milestones

Resource needs to be fulfilled by and/or in partnership with key stakeholders, to include personnel availability and access to equipment and/or programs such as quality assurance testing suites

Changes to the architecture and infrastructure previously defined in the Pre-Select and/or Plan stages

Due to the nature of agile development, adjustments to the above documents and decision points may be made as needed with the formal concurrence of the PM, business, and other key stakeholders.

The PM may elect to incorporate PDR activities from Section 2.2.2 and/or Section 2.3.1.1 into the Pre- Development review rather than holding separate PDR meetings, subject to the concurrence of the EA Team. This review will follow all approved RDTO change control processes and guidelines.

Key Activities – Sprint 1

2.3.3.1. Design Activities

During Design activities for Sprint 1, the Development team will do the following:

Create Sprint Backlogs and User Stories – The HLBRs and release backlog will serve as inputs to defining and developing user stories, use cases, and detailed requirements and to developing Sprint Backlogs. All user stories, usually documented at the feature level, are translated into a sufficient level of detail for technical implementation. The requirements elicitation process will develop all functional and non-functional requirements necessary for completing the design and the test cases that will drive the development process. For Agile projects, this includes sprint planning, story writing and estimation, backlog processing, high-level story boards, and epics.

Design Application Architecture – The ADD will be further developed to include information on the user-to-system and the system-to-system interfaces. The design team will identify legacy data sources, develop the logical data model, and define the mapping between entities and the logical data model. The ADD must include or reference the draft Network Diagram for the Development and Test environments.

Conduct a Preliminary Design Review – The team should conduct a second PDR, which will serve as confirmation of the high-level design approach prior to the team completing detailed design and beginning development activities. As in Plan stage, the PDR serves to confirm a high-level contextual architecture (draft of ADD Sections 1-5). This PDR will follow all approved RDTO change control processes and guidelines and may be incorporated into the Pre-Development review (see Section 2.3.2) in place of a stand-alone meeting, subject to the approval of the PM and EA Team.

RD Technology Office 16

Develop Preliminary High-Level QA Test Scripts and Cases –Test scripts and test cases will be developed in conjunction with epics. Test cases will be created based on the detailed business and system requirements, focusing on holistic “beginning-to-end” logic. Test scripts will also be developed based on the user stories and use cases. The QA team will work with business analysts to improve the test scripts and test cases as needed.

Address Section 508 Requirements – Project teams will assess Section 508 requirements and document an approach for achieving compliance.

2.3.3.2. Develop Activities

During Develop activities for Sprint 1, the Development team will do the following:

Build and Document the System – The application must be coded, and the system built based on the ADD and requirements documentation, including Section 508 considerations. All requirements must be traced, and all updates must be documented in the appropriate backlog.

Additionally, subsystem dependencies and integrations with other applications must be addressed and the implementation of (or changes to) the physical database must be requested.

The source code and deployment package will be developed and updates to architecture documentation completed based on the code. The team will update the test cases and scripts based on the requirements of the system as needed. For Agile projects, a deployment will occur to a target pre-production environment such as Test/QA.

Provision the Development Environment – The PSO team will provide hosting infrastructure for the development environment throughout development activities.

Provide Security Guidance to Development Team – As development progresses, the RD Cybersecurity team will provide guidance to enable the Development team to conduct secure “static code reviews” (for input validation, access control, etc.) starting in the unit test phase of application development. Static code analysis and reviews must occur early and often relative to the vulnerabilities/defects surfaced. The RD Cybersecurity team will provide additional assistance on how to use source code, components, and products, and how to apply the Secure Configuration Guidelines to solution infrastructure.

Provide Guidance on Privacy Team Development Activities – The Cybersecurity team will provide additional guidance to the Development team on how to implement the privacy mechanisms prescribed in the solution design, traceable to the Privacy Baseline Requirements for that project.

Coordinate Extract/Transform/Load (ETL) Process – The Data Engineering team will provide guidance on the migration of data from the target to source location(s), the loading of data into the Enterprise Data Warehouse, and the creation of reports for transactional system outputs.

Coordinate the Hosting Plan – The PSO team will coordinate a hosting plan with the service provider and determine a migration path to a production environment.

Coordinate Costs and Billing – The PSO team will coordinate costs and billing with the hosting service provider.

2.3.3.3. Test Activities

During Test activities for Sprint 1, the QA and Cybersecurity teams will do the following:

RD Technology Office 17

Execute Testing – The QA and Cybersecurity teams execute the required tests and document the test case results to include test defects. The types of testing conducted can vary based on the application requirements and design. Please note that all testers will need access to their respective test environments, and the team will need to account for access (test accounts, Network Access Gateway [NAG] access request, etc.). The following is a high-level list of testing types available to the PM:

o Functional/Defect/Regression Testing o Integration Testing o Web-Based Testing o 508 Compliance Testing o Static/Dynamic Scanning

Provide Guidance on Privacy Testing Activities – Additional guidance will be provided to the test team on how to test the privacy mechanisms prescribed in the solution design so that they are traceable to the Privacy Baseline Requirements for that project.

2.3.3.4. Other Activities

Throughout Sprint 1 activities, the PM will perform the following:

Document Project Risks – All PMs must document and manage project risks in the RD Risk Register throughout the project’s lifecycle.

Maintain IMS – The PM will maintain the IMS in compliance with the RDTO process.

Key Activities – Iterative Sprints

2.3.4.1. Design Activities

During Design activities for each iterative sprint, the Development team will do the following:

Refine the Sprint Backlog and User Stories – The PM and project team review items on the Sprint Backlog to ensure that the backlog contains the appropriate items, that they are prioritized, and that items at the top of the backlog are ready for delivery. During this refinement process, the team removes user stories that are no longer relevant, creates new user stories for any newly-discovered needs, reassesses relative priority of stories and refines story estimates, and splits user stories as needed. Once the user stories for the sprint have been finalized, the Security Engineering and EA teams will review the backlog to make sure that all security requirements are articulated.

Refine the Application Architecture – The ADD and Network Diagram will be refined based on any updates to the application architecture.

Conduct a Critical Design Review (CDR) – Teams should conduct a CDR at the beginning of each sprint. The CDR, which will focus on 2 to 3 critical user stories, confirms the interaction of the application with other systems (draft of ADD Sections 6-9) and follows all approved RDTO change control processes and guidelines. This review is critical for Agile projects, since the Agile Development SGR will not occur until just before Deployment.

RD Technology Office 18

Update High-Level QA Test Scripts and Cases –Test scripts and test cases will be updated based on any adjustments to the user stories and use cases. The QA team will work with business analysts to improve the test scripts and test cases as needed.

Address open Plans of Action and Milestones (POA&Ms) – An existing application should include requirements, as part of release updates, to close any open POA&Ms, unless the Chief Information Security Officer (CISO) grants a deferral waiver for any or all open POA&Ms for a later release.

2.3.4.2. Develop Activities

During Develop activities for each iterative sprint, the Development team will do the following:

Build and Document the System – The application must be coded, and the system built based on the ADD and requirements documentation, including Section 508 considerations. All requirements must be traced, and all updates must be documented in the appropriate backlog.

Additionally, subsystem dependencies and integrations with other applications must be addressed and the implementation of (or changes to) the physical database must be requested.

The source code and deployment package will be developed and updates to architecture documentation completed based on the code. The team will update the test cases and scripts based on the requirements of the system as needed. For Agile projects, a deployment will occur to a target pre-production environment such as Test/QA.

Provision the Development Environment – The PSO team will provide hosting infrastructure for the development environment throughout development activities.

Provide Security Guidance to Development Team – As development progresses, the Cybersecurity team will provide guidance to enable the Development team to conduct secure “static code reviews” (for input validation, access control, etc.) starting in the unit test phase of application development. Static code analysis and reviews must occur early and often relative to the vulnerabilities/defects surfaced. The Cybersecurity team will provide additional assistance on how to use source code, components, and products, and how to apply the Secure Configuration Guidelines to solution infrastructure.

Provide Guidance on Privacy Team Development Activities – The Cybersecurity team will provide additional guidance to the Development team on how to implement the privacy mechanisms prescribed in the solution design, traceable to the Privacy Baseline Requirements for that project.

Coordinate ETL Process – The Data Engineering team will provide guidance on the migration of data from the target to source location(s), the loading of data into the Enterprise Data Warehouse, and the creation of reports for transactional system outputs.

Provide Documentation to PSO Team – Using information in the ADD, the PSO team will work with the Development team to develop artifacts in preparation for deployment. These artifacts include a draft Network Diagram for Production, a Deployment Readiness Checklist, and an Application Hosting Profile (AHP).

Coordinate a Hosting Plan – The PSO team will coordinate a hosting plan with the service provider and determine a migration path to a production environment.

Coordinate Costs and Billing – The PSO team will coordinate costs and billing with the hosting service provider.

RD Technology Office 19

2.3.4.3. Test Activities

During Test activities for each iterative sprint, the QA and Cybersecurity teams will do the following:

Execute Testing – The QA and Cybersecurity teams execute the required tests and document the test case results to include test defects. The types of testing conducted can vary based on the application requirements and design. Please note that all testers will need access to their respective test environments, and the team will need to account for access (test accounts, NAG access request, etc.). The following is a high-level list of testing types available to the PM:

o Functional/Defect/Regression Testing o Integration Testing o Web-Based Testing o 508 Compliance Testing o Static/Dynamic Scanning

Provide Guidance on Privacy Testing Activities – Additional guidance will be provided to the test team on how to test the privacy mechanisms prescribed in the solution design, traceable to the Privacy Baseline Requirements for that project.

Reconcile Production and Test Environments – The Test team will work with the PSO team during Deployment Readiness Testing to ensure the Production environment is configured as closely as possible to the Certification environment. Updated versions of the deployment documentation (to include the AHP and other artifacts as needed) will be provided to PSO at this time.

2.3.4.4. Other Activities

Throughout iterative sprint activities, the PM will perform the following:

Document Project Risks – All PMs must document and manage project risks in the RD Risk Register throughout the project’s lifecycle.

Maintain IMS – The PM will maintain the IMS in compliance with the RDTO process.

Conduct a Mid-Development Review – At the discretion of the PM and RDTO leadership, the PM and project team may conduct one or more Mid-Development reviews with members of the business, the IPT, and other key stakeholders. This review will focus on any updates to objectives, requirements, and changes for the upcoming release and will result in the following documentation:

o Objectives for each sprint and the overall development effort, to include a clearly defined list of milestones o Resource needs to be fulfilled by and/or in partnership with key stakeholders, to include personnel availability and access to equipment and/or programs such as quality assurance testing suites o Changes to the architecture and infrastructure previously defined in the Pre-Select and/or Plan stages

RD Technology Office 20

RDTO may designate a project for a Mid-Development review based on factors such as it scope, the duration of its development window, its interdependencies with other RDTO efforts, and the number of new requirements or other design adjustments introduced following the Pre- Development review.

Key Activities – Final Sprint (Pre-Release)

2.3.5.1. Design Activities

During design activities for the final pre-release sprint, the Development team will do the following:

Refine Sprint Backlogs and User Stories – The PM and project team review items on the Sprint Backlog to ensure that the backlog contains the appropriate items, that they are prioritized, and that items at the top of the backlog are ready for delivery. During this refinement process, the team removes user stories that are no longer relevant, creates new user stories for any newly discovered needs, reassesses relative priority of stories and refines story estimates, and splits user stories as needed. Once the user stories for the sprint have been finalized, the Security Engineering and EA teams will review the backlog to make sure that all security requirements are articulated.

Refine Application Architecture – The ADD and Network Diagram will be refined based on any updates to the application architecture.

Conduct Final CDR – Teams should conduct a final CDR at the beginning of the final sprint.

Finalize High-Level QA Test Scripts and Cases – Test scripts and test cases will be finalized based on any adjustments to the user stories and use cases. The QA team will work with business analysts to improve the test scripts and test cases as needed.

Address open POA&Ms – An existing application should include requirements as part of release updates to close any open POA&Ms, unless the CISO grants a deferral waiver for any or all open POA&Ms for a later release.

2.3.5.2. Develop Activities

During Develop activities for the final pre-release sprint, the Development team will do the following:

Build and Document the System – The application must be coded, and the system built based on the ADD and requirements documentation, including Section 508 considerations. All requirements must be traced, and all updates must be documented in the appropriate backlog.

Additionally, subsystem dependencies and integrations with other applications must be addressed and the implementation of (or changes to) the physical database must be requested.

The source code and deployment package will be developed and updates to architecture documentation completed based on the code. The team will update the test cases and scripts based on the requirements of the system as needed. For Agile projects, a deployment will occur to a target pre-production environment such as Test/QA.

Coordinate ETL Process – The Data Engineering team will provide any final guidance on the migration of data from the target to source location(s), the loading of data into the Enterprise Data Warehouse, and the creation of reports for transactional system outputs.

RD Technology Office 21

Provide Documentation to PSO Team – Using information in the ADD, the PSO team will work with the Development team to finalize artifacts in preparation for deployment. These artifacts include a draft Network Diagram for Production, a Deployment Readiness Checklist, and an AHP.

Coordinate Hosting Plan – The PSO will coordinate a hosting plan with the service provider and determine a migration path to a production environment.

2.3.5.3. Test Activities

During Test activities for the final pre-release sprint, the QA and Cybersecurity teams will do the following:

Execute Testing – The QA and Cybersecurity teams execute the required tests and…