Software Acquisition

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Example: Task Order Objective

The Government requires resources to support the implementation, integration and sustainment of a fully integrated solution that provides the full spectrum of services to replace an antiquated legacy and Commercial of the Shelf (COTS)/ Government off the Shelf (GOTS) Systems with disjointed capabilities. The requirement calls for a solution that is scalable to support accelerated site deployment, while at the same time supporting integration with additional systems and sustainment of current integrations. Each of these requirements must be supported simultaneously.

The current integrated systems include:

1. [add integrated systems]

In addition, the solution will require resources and technical support for legacy products. The legacy products include but are not limited to:

1. [Example of COTs product with description of capabilities]
2. [Additional specific legacy systems]

All development and sustainment activities shall follow an agile methodology of iterative delivery [specific guidance within the agency to support a standardized approach].

---

Example: Scope of Work

The Contractor shall provide products, operations support and security compliance for the solution. A product is defined as one that has been deployed to a production (or approved production-like) environment, validated through testing, monitored for resiliency, and determined to be operable and available for customers. This support includes all development, testing, integration, architecture, refactoring as needed, and all ongoing planned and unplanned operations and maintenance support to include predictive, preventative, corrective, and evolutionary through a cycle of Continuous Integration as well as hardware and infrastructure management.

The requirement calls for a solution that is scalable to support accelerated site deployment, while at the same time supporting integration with additional systems and sustainment of current integrations.

---

Example: Resource Requirements

The Contractor shall provide resources with a blend of specific expertise and experience in Agile methodologies, product management, Development, Security and Operations (DevSecOps), engineering, organizational change management, training, customer support and data migration.

Technical teams are required to have technical expertise in the following areas: modern software development tools to include [add tools and expertise as appropriate], cloud technology, DevSecOps, as well as Government Toolsets currently in use [specific toolsets].

The Contractor shall provide cross-functional resources for the development of enhancements to capabilities and underlying infrastructure in alignment with Government policies and procedures. Roles in agile development include, but are not limited to: DevSecOps Coach, Release Engineer, Scrum Master, Tech Lead, DevSecOps Engineer/Security Specialist, Solution System Architect/Engineer, and Solution Lead.

When supplying the Government with individuals in these roles, the Government requires certifications as listed in Table [#]: Example Agile Roles and Certification Requirements.

Table [#]: Example Agile Roles and Certification Requirements

Role	Certification
DevSecOps Coach	[specific to the agile methodology chosen]
Release Engineer	[specific to the agile methodology chosen]
Scrum Master	[specific to the agile methodology chosen]
Cloud Engineer	Examples: For Amazon Web Services (AWS) Solutions Architect (Professional) or DevOps Engineer (Professional). For Microsoft Azure Government (MAG) Azure Solutions Architect (Expert) or Azure DevOps Engineer (Expert)
DevSecOps Engineer/Security Specialist	Examples: For AWS Solutions Architect (Associate) or Developer (Associate). For MAG Azure Solutions Architect (Associate) or Azure Developer (Associate) And International Information System Security Certification Consortium (ISC)2 (Certified Information System Security Professional)
Solution System Architect/Engineer	[specific to the agile methodology chosen]
Solution Lead	[specific to the agile methodology chosen]
Data Architect	[specific to the agile methodology chosen]
Data Migration Specialist	[specific to the agile methodology chosen]
Cyber Security Risk Lead	Examples: CISSP (Certified Information Systems Security Professional) CISM (Certified Information Security Manager) GSLC: Global Information Assurance Certification (GIAC) Security Leadership Certification
Cyber Security Architect	Examples: CISSP-ISSAP (Certified Information Systems Security Professional-Information Systems Security Architecture Professional CISSP-ISSEP (Certified Information Systems Security Professional-Information Systems Security Engineering Professional
Privacy	[Specific to the system]
Integration Lead/Engineer	[Specific to the integration points and if there are needed certifications]

 

---

Examples: Tasks and Deliverables

The contractor shall perform the following tasks and provide the specific deliverables described below for each product/project initiated under this task order.

The contractor shall utilize agile methodologies for product management to deliver iteratively and incrementally and regularly produce high quality results in a cost effective, timely, and highly collaborative manner via the DevSecOps value-driven lifecycle. This requires open lines of communication among all participants contributing to the project/program/portfolio that include multiple consumers and with other offices/activities.

The foundational structure for Agile development and project management can be found in the latest version of the [Add Guidance]. This guidance describes a schedule of incremental deliveries of useable capabilities every three months or less (or as specifies). This includes delivery of functionality into pre-production or production every thirty calendar days unless approved by the Contracting Officer Representative/ Government Product Management (COR/GPM) prior to build start. For delivery of all project artifacts, the Contractor shall utilize Government-approved tools for managing project execution details and for the management and storage of artifacts using approved templates. All tools used in the solution shall be Section 508 compliant.

Example: Contractor Project Management Plan

The Contractor shall deliver a Contractor Project Management Plan (CPMP) that lays out the Contractor’s approach, timeline and tools to be used in execution of this effort. The CPMP should take the form of both a narrative and graphic format that displays the schedule, milestones, risks and resource support. COR/GPM to establish a baseline. The Contractor shall update and maintain the CPMP monthly throughout the Period of Performance.

Deliverable

1. Contractor Project Management Plan

---

Example: Reporting and Management Requirements

The Contractor shall use the Government’s implementation of the Jira, GitHub (or other approved toolset) to provide a single Agile project/product lifecycle management tool to track execution details. The approved toolset will be used to provide a single authoritative project and product data and artifact repository. All project data and artifacts will be required to be managed in this data and artifact repository daily. All checked out artifacts shall be checked back in daily, and any data updated daily. The Government approved toolset synchronizes all changed information immediately for all team members to access work proficiently without the concern of working on aged information.

The Contractor shall utilize the approved toolset to:

• Input and manage scheduled project/product sprints and backlog
• Input and manage project/product Agile requirements
• Input and manage project/product risks and issues
• Input and manage project/product configurations and changes
• Input and manage project/product test plans and execution
• Input and manage project/product planning and engineering documentation
• Input and manage project/product user guides and training materials
• Input and manage linkages to correlate requirements to change orders to configurable items to risks, impediments, and issues to test cases and test results to show full traceability.

The Contractor shall show all Agile requirements, changes, tests performed and test results in the approved toolset to show evidence of code coverage and test coverage of all the requirements specified. This expectation will allow the Government to have high confidence in a fully documented, requirements traceability matrix, as evidenced by data in the tools.

---

Example: Schedule Management

The Contractor shall create, maintain, analyze, and report integrated schedules. A schedule shall be developed for each build and sprint. The Contractor shall also provide input to the Product Integrated Master Schedule (IMS), at a minimum once a week, in cases where one exists.

The Contractor shall provide and update a product-oriented Work Breakdown Structure (WBS) to track project decomposition and value delivery. The WBS shall be linked to the IMS.

Deliverables

1. Product Integrated Master Schedule
2. Work Breakdown Structure

---

Example: Configuration Management

The Contractor shall:

1. Identify the standard and unique aspects of configuration management to be performed by establishing a Product Configuration Management (CM) Plan (PCMP). The Contractor shall reflect all CM required activities and standards in each project-level CM plan while determining the unique aspects of the project which require individualized procedures. The COR/GPM approves the PCMP.
2. Deliver a Recommended List of Configuration Items as part of the Product Configuration Management Plan. The Contractor shall identify types of configuration items pertaining to each product to be placed under configuration management. Based on Government input, and the unique needs or nature of each project, the Contractor shall determine the components within each project that must be under configuration control.
3. Use a Government approved toolset and repository for all software source code and electronic artifact configuration and version management. The Contractor shall use the Government approved toolset to manage change, activity, issue, action, risk, and other project data as prescribed by Government standards and processes.
4. Ensure that all project software and non-software artifacts are versioned correctly according to Government standards and follow a build/release promotion versioning approach which identifies all major, minor, and update changes to the components.
5. Create Project and Product Artifacts baselined and versioned in the CM repository to allow the tool to show active and past histories of the check-ins and check-outs of all software components, data, and software project engineering documents. Maintain all baselines of software, software builds, and electronic artifacts in the repository, labeling updates and versions according to CM procedures.
6. Develop, verify and submit with all project build deliveries, a Version Description Document that addresses the manifest of the contents of all software builds created for project releases outside the development environment.
7. Establish and maintain status reporting on change and configuration management activity and ensure daily updates.
8. Develop and manage a CM process that supports all necessary changes for the project including changes to Definition of Done, Acceptance Criteria and any other items deemed necessary.

Deliverables

1. Product Configuration Management Plan
2. Version Description Document

Example: Product Management Support

The Contractor shall support the advancement of the maturity of each Product through compliance with the DevSecOps process and other Government guidance. To complete this task, the Contractor shall provide a senior team of SMEs to support the integration and oversight of capabilities within each product through collaboration with relevant stakeholders and partners. Additionally, the Contractor shall support planning across interdependent systems to mitigate technical risk and improve integration with business processes. As part of this task, the Contractor shall manage the following processes:

1. Assists in defining new application implementation requirements, to include the generation of Epics and translation to User Stories while mitigating dependencies between them;
2. Consolidates requirements or sequencing to generate efficiencies within each product;
3. Understands future state requirements for a successful implementation of new applications and identifies impacts to legacy or dependent systems;
4. Provides guidance on dependencies between product implementation requirements to reduce risk as new capabilities are introduced and current systems are retired;
5. Identifies and analyzes the systems targeted for integration and the technologies needed to implement them;
6. Assists with database solutions and designs for data migrations during for implementation;
7. Understands current and future state data flows, networking, cybersecurity and infrastructure requirements.

---

Example: Product Intake Process

During the Base Period, the Contractor shall assist the Government with establishing and supporting the Product request, intake, and disposition process. It is anticipated that throughout the Base and Option Periods, if exercised, additional products may be incorporated. The initial Base intake may be up to 5 products, and a maximum of 20 additional new products may be initiated and occur concurrently over the life of the contract for a total of 25 maximum products. The Contractor shall create and maintain a Product Request Intake Tool that will facilitate the management of the intake process. The Contractor shall continue to maintain the Intake Tool during the Option Periods. The Contractor shall support documenting the processes within an Intake Analysis and Process Guide which shall include process flows and guides. The Contractor shall also support the on-going operations of the intake process by:

1. Capturing and tracking intake requests.
2. Performing a DevSecOps assessment to document development/test/integration processes being used and to assess the maturity of products undergoing intake.
3. Collecting and documenting application/system historical ticket and incident management data to include the turnaround time for each submitted intake request.
4. Identifying and documenting application/system configuration, architecture, operational profile, security, and compliance.
5. Maintaining the intake repository.

 Deliverables

1. Product Request Intake Tool
2. Intake Analysis and Process Guide
3. Backlog Report

Example: Capability Development Lifecycle Activities in an Agile Process Model

The Contractor shall utilize DevSecOps principles and practices and follow an agile process model of iterative builds for development of product capabilities. Builds shall be deployed for each product every three months. The capability development lifecycle activities outlined below include:

1. Human Centered Design and Solution Architecture
2. Requirements Management
3. Software Development
4. Testing
5. Release Support
6. Application Performance Monitoring
7. Decommissioning Support

---

Example: Human Centered Design and Solution Architecture

The Contractor shall lead value stream discovery and documentation for each product. The Contractor shall be responsible for and support elaboration of epics into features and stories and managing cross team risk and dependencies. The Contractor shall work with customers using human centered design approaches to understand their needs, prioritize capabilities, create the product vision and roadmap, define requirements, and guide work through the product team as described below.

The Contractor shall create a Solution Architecture Package that includes the initial business, systems, application, and data architectures for the new features and capabilities using an architecture framework, approved by the COR/GPM. These documents shall be updated utilizing approved templates and GitHub or Government approved tool when appropriate and approved by the COR/GPM in each subsequent Sprint. Each subsequent update shall include a Changes Page, which specifies the updates made to the document for review and approval by the COR/GPM. The Contractor shall also outline any initial gaps, questions or challenges that may hinder progress in future builds or sprints.

1. Deliver Product Discovery Report.

• Perform Discovery and Planning – Conduct discovery activities on existing Government solutions, dependent products, and internal and external business process flows and functions. Work closely with customers to understand their needs and the mapping to
• Develop User Research Artifacts, perform site visits and/or user surveys.
• Document Product Dependencies.
• Develop and deliver Solution User Research and Usability Testing.
• Collect available data, user feedback, and stakeholder feedback and capture in a Product Discovery Report.

2. Deliver Design Artifacts.

• Work with product architects to derive a globally consistent design which meets the needs of the intake item(s).
• Develop As-is and To-be Architecture Models. The As-is Architecture Model shall represent the baseline architecture to be maintained throughout the PoP. Collect available data, user feedback, and stakeholder feedback and capture in a Discovery Report.
• Develop current and correct Architecture Diagrams detailing the logical, network, and dataflow of the products.
• Develop a Product Roadmap – A comprehensive list of the software components, products, services and functionality that needs to be built or updated, and prioritization of these based on the completed discovery efforts. For roadmap items under active discovery or development, issue-tracking and associated documentation should enable full visibility and transparency of all work from user stories through epics up to the roadmap item as well as progress against all work required for a roadmap
• Develop solution data models
• Develop solution architecture (technical, business, and data).
• Support business process modeling.
• Develop, execute, and deliver architecture documents.
• Develop and deliver Discovery Reports: Logical Data Models, Business Process Models.

3. Deliver Solution Lifecycle Artifacts

• Define Solution Level Epics with acceptance criteria.
• Support Solution Level Strategy ensuring the solution meets the business intent and data integrity.
• Develop Business Cases.
• Establish Key Performance Indicators (KPIs) for Solution in concert with COR/GPM and key stakeholders. All KPIs shall be designed to allow the team to effectively and objectively evaluate the product against user needs.
• Develop, groom, and elaborate Solution Backlog Management.
• Develop, execute, and deliver Program Increment (PI) Objectives.
• Mock-up proposed functionality to receive feedback from potential consumers and iterate on designs quickly prior to beginning software development and/or application integration.
• Develop, execute, and deliver Solution Demonstration.
• Identify User Adoption and Training Needs.
• Develop and deliver Solution KPI Definition and Reporting
• Support early user interface and technical prototypes.

Solutions and desired outcomes are planned, baselined, and agreed during PI planning events. The Contractor shall work in coordination with the architects and ensure that the solutions provided are in compliance Enterprise Architectures.

Deliverables

1. Solution Architecture Package
2. Product Discovery Reports
3. Product Roadmap
4. Design Artifacts
5. Solution Lifecycle Artifacts
6. Product KPIs

---

Example: User Research and User Experience in an Agile Process Model

The Contractor shall create and execute a User Experience Strategy to meet the following requirements:

1. Facilitate discovery activities, to include research with users and business stakeholders, assessment of current related features, content review, information architecture review, accessibility review, business process review; and additional relevant data collection.
2. Partner with other product teams to ensure that the capability or service fits into the business architecture.
3. Conduct formative and contextual user research studies to understand users’ goals, needs, journeys, and pain points. Apply insights from user research studies to define minimum viable product functionality, including epics and user stories, as well as operational, business, functional, technical, data, and integration requirements.
4. As part of the overall product test strategy, conduct routine, iterative usability testing to continually improve the user experience and to inform content, information architecture, design, functionality, and accessibility. Iteratively apply insights gathered to inform design and development.
5. Before releasing to production, conduct user acceptance testing on new features, content reviews of existing content, Information Architecture reviews for global navigation and design reviews of existing patterns and User Interface elements to identify and make modifications while maintaining a positive user experience.
6. Document user research and user experience activities

Deliverables

1. User Experience Strategy
2. Documentation of activities

---

Example: Content and Design

As part of the content and design, the Contractor shall:

1. Employ design process management by breaking designs into small, bite-sized implementations and collecting data from each deployment to inform priorities and decisions in the next iteration.
2. Ensure consistency and continuity in product information architecture, including URL schema, page layout, menus and navigation, user flows, and search engine optimization.
3. Craft, test, and deploy design deliverables, including wireframes, low- and high-fidelity prototypes, or interactive web forms to facilitate usability testing and agile development of products to include traceability to epics and user stories. As appropriate, create and update prototypes to conduct facilitated demos or usability testing to elicit feedback for improvements to the design.
4. Develop designs that adhere to Government approved design patterns.
5. Support and comply with all user experience guidelines and standards.

Deliverable

1. Wireframes, low-and high- fidelity prototypes, or interactive web forms

---

Example: Requirements Management in an Agile Process Model

The Contractor shall complete an initial planning session with the government to identify functionality relevant to building the product in alignment with the product roadmap. The planning session shall include a complete review of epics and user stories, elaboration of additional user stories resulting from the session, and alignment of the user stories to the product roadmap.

The Contractor shall:

1. Ensure all epics are included within the overall agile backlog grooming effort.
2. Populate the backlog during the initial planning session identifying all features the team considers relevant to building the product. The backlog serves as the primary source for all program requirements and user stories.
3. Prioritize the user stories in alignment with the product roadmap.
4. Establish initial unit of measurement (e.g. story points) to estimate relative complexity of user stories.
5. Facilitate stakeholder briefings, meetings and/or elicitation sessions.
6. Execute requirements reviews with stakeholders.
7. Collect, update, compile, and maintain requirements data within a government-approved tool. This includes all epics, stakeholder needs, visualizations, user stories, and other sources of requirement information for functional and non-functional requirements.
8. Ensure all requirements data is under change control and is fully linked to work items that show traceability to design changes, configurable items, test cases and test results.
9. Facilitate review, elaboration, and prioritization of the backlog throughout the product lifecycle.

Deliverables

1. Backlog of user stories
2. Updated, traceable requirements data within a government approved tool

---

Example: Software Development in an Agile Process Model

The Contractor shall continuously support the iterative release and configuration methodology to meet the product roadmap. The software development activities include:

1. Solution Planning
2. Build Planning
3. Sprint Planning
4. Sprint Execution

---

Example: Solution Planning

The Contractor shall:

1. Support the setup of all needed development and test environments as required to complete required development and testing. Coordinate with the Government to ensure alignment with all development and test environments.
2. Develop, support, and/or maintain the Authority to Operate (ATO) Package to obtain/maintain approval, as required. Required ATOs must be obtained prior to build release and ATO approval timelines. All necessary security scanning and remediations, must be considered in build planning activities.
3. Develop and utilize automated build and automated publishing capabilities to schedule jobs and support continuous integration for every sprint. Automated build tools shall be in compliance with the approved list from the Government and code shall be demonstrable and stable enough to be promoted to another environment without issue by evidence of the status of tests and results in the Government approved tool (e.g., GitHub/Jira).
4. When developing an interface, the Contractor shall identify issues for proper Integration Control Registration (ICR) and await approval from the Government to proceed.
5. When developing an interface, the Contractor shall ensure the requirements will be added to the backlog.
6. When developing an interface, the Contractor shall also ensure the product complies with Product Interface Control Documents (ICDs), if existing, or assist in the creation of new ICDs to support new integrations that have been approved through the CCB.

Deliverables

1. ICD
2. ATO Package

---

Example: Build Planning

The contractor shall use outcome of the backlog grooming and prioritization to conduct build planning for each product. A build shall be made up of individual sprints, be fully tested by end users, and end in a release to production. A build shall be no shorter than two weeks but no longer than three months in duration. The Contractor shall develop and deliver a Build Plan prior to beginning the build. The Build Plan is the scope of work which will be completed in the agreed upon build timeframe. Planning for future builds will occur during the execution of current builds.

All activity scheduled in each build will be captured and have status showing all work items, changes, impediments, and retrospectives within the government approved tool. All data and artifacts in the Government approved tool shall be fully linked to requirements data and test data.

The Contractor shall:

1. Facilitate review, elaboration, and prioritization of the backlog throughout the build to ensure the highest product priorities are being met.
2. Facilitate selection of prioritized items from the product backlog to be included in the next build with approval of COR/GPM and incorporate those items into a Build Plan for posting to Government approved tool.
3. Conduct an initial design review with stakeholders to ensure the design is technically and fiscally able to be completed during the build.
4. Provide support for identification of field sites, test environments, acceptance criteria, and ATO requirements.
5. Coordinate in the validation or creation of Interconnection Security Agreement/Memorandum of Understanding (ISA/MOU) and Service Level Agreements (SLA) for partner dependencies that specifically highlight the commitment of partners to associated release. The ISA specifies the technical and security requirement of the interconnection, and the MOU defines the responsibilities of the participating organizations.

The Contractor shall provide a Build Test Plan to COR/GPM for approval prior to initiating any development activities. This plan shall include both Contractor and Government testing activities, dependencies, and descriptions of the interfaces and interactions between solution components that are needed to test and validate. The Build Test Plan shall specify the types and scope of testing to be conducted during each product build (e.g. unit, functional, accessibility, system, reliability, usability, interoperability, regression, security, performance). The Contractor shall include testing related to non-functional requirements, (e.g. load, performance, installation, back-out, and rollback) in the Build Test Plan.

At the conclusion of the Build Planning phase, the Contractor shall provide a Build Release Planning Package outlining the prioritized capabilities, estimation of size and timeline for completion.

Deliverables

1. Build Plan
2. ISA/MOUs and SLAs
3. Build Test Plan
4. Build Release Planning Package

---

Example: Sprint Planning

Once build planning is completed and accepted, the Contractor shall initiate Sprint Planning for each Sprint of the build. The Contractor shall:

1. Initiate and participate in a Sprint Planning Meeting, at the beginning of each sprint. The Contractor shall create and update the Sprint Plan in the Government Approved Tool after the Sprint Planning.
2. Support, coordinate and provide input for the Sprint Acceptance Criteria in Government Approved Tool. The Sprint Acceptance Criteria shall be coordinated and approved for every sprint. This task shall result in an Approved Sprint Plan.
3. In collaboration with the government, create and prioritize the sprint backlog from the approved and prioritized items identified in build planning.
4. Identify user stories and tasks to be completed within the sprint, the agreement of acceptance criteria for the sprint, and readiness to begin sprint.
5. Conduct a sprint design to understand what problem needs to be solved for each user story, understand critical business functions, test initial concepts, and look for objective feedback. Methods of design could include mock-ups, storyboards, and rapid prototyping.
6. In collaboration with key Stakeholders, determine the testing events required for the Sprint.

Deliverable

1. Sprint Plan

---

Example: Sprint Execution

All activities executed in each sprint will be captured with the status showing all work items, changes, risks, issues, impediments, and retrospectives. All data and artifacts in Government Approved Tool shall be fully linked to requirements data and test data.

The Contractor shall:

1. Provide a certified Scrum Master to facilitate all ceremonies, ensure Government approved tool is updated daily, enforce scrum framework, track, and assist with removing impediments.
2. Conduct sprint development including disciplined testing (unit, functional, regression) of the features and capabilities identified in the Sprint Plan.
3. Initiate and conduct daily scrums (typically 15 minutes) to show the team progress, impediments and daily plans.
4. Update the Government Approved Tool daily, to include progress on tasks during sprints, blockers and dependencies. Document all activity executed in each sprint including all project artifacts such as work items, changes, risks, issues, impediments, and retrospectives. All data and artifacts in Government approved tool shall be fully linked to requirements data and test data. All project artifacts and source code will be under change and configuration management as specified by the COR/GPM.
5. Coordinate and support demonstration of the sprint activities with the project team and users at the end of each sprint. This is termed a Sprint Review and will result in customer acceptance of the sprint.
6. Develop and deliver automated build and automated publishing capabilities to schedule jobs and support continuous integration for every sprint. Code shall be demonstrable and stable enough to be promoted to another environment without issue by evidence of the status of tests and results in the Government approved tool.
7. Initiate and facilitate a Sprint Retrospective Report at the end of the Sprint to capture team performance lessons learned.

Deliverables

1. Daily updates to the government approved tool
2. Sprint Review
3. Sprint Retrospective Report

---

Example: Testing

The Contractor shall adopt agile practices for integration testing into each sprint and release.

The Contractor shall populate its Test Scripts and Cases in government approved tool.

The Contractor shall conduct tests (e.g. unit, functional, accessibility, system, reliability, usability, interoperability, regression, security, performance) throughout the development lifecycle (e.g. user story, sprint, build, release) using industry best practices of continuous integration methods and automated regression testing. The Contractor shall also conduct testing related to non-functional requirements (e.g. load, performance, installation, back-out, and rollback).

The Contractor shall support user acceptance testing. When a defect is identified during testing, the Contractor shall log it in the government approved tool, selecting the appropriate severity level. The Contractor shall support the COR/GPM for prioritizing the defect in the sprint backlog. Based on a prioritization the defect could be entered into the current sprint or entered into the backlog for future build planning.

The Contractor shall ensure the government approved tool is up-to-date daily so that stakeholders can access accurate and timely status.

The Contractor shall support the security, accessibility, performance, technical standards, architectural compliance, user acceptance and initial operational capability tests, audits, and reviews. Security scanning is done by multiple methods and is done multiple times throughout the course of a project with methods such as infiltration testing (WASA), code analysis tools (Fortify), etc. Performance testing is done through load testing and technical analysis of capacity planning data submitted by the project team.

The Contractor shall ensure all test planning, execution, and results details are entered and maintained in government approved tool and under version control. Specifically test management data and artifacts include such items as scripts, configurations, utilities, tools, plans and results. The Contractor shall provide Test Results to complete the Requirements Traceability Matrix and submit for COR/GPM acceptance

Deliverables

1. Test Scripts
2. Test Data
3. Test Results
4. Requirements Traceability Matrix

---

Example: Release Support

The Release Process is conducted during the release of new functionality or configuration in compliance with Government Guidance.

The Contractor shall utilize the current Government calendaring process and tool to track release and implementation, special works in progress, and other deployment events in the production environment. The Contractor shall provide data for populating and updating the calendaring process for each release.

---

Example: Pre-Release Support

The Release Process is conducted during the product lifecycle by one or more assigned Release Agents who perform frequent, regular reviews of required and appropriately linked product data in the mandated repositories. The Release Agents also provide timely feedback to the product team concerning the status of the product data and the status of the team’s compliance with the Release Process.

The Contractor shall work with the COR/GPM and stakeholders to develop a Build Release Package that will outline processes and documentation needed to deploy the build.

To complete the Build Release Package, the Contractor shall:

1. Develop/update/finalize the Production Operations Manual (POM) and/or the Technical Manual, depending on the product being produced. The POM or Technical Manual shall include regular maintenance and operations information, Responsibility, Accountability, Consulted, and Informed information, process flowcharts, dataflow diagrams, key monitoring indicators, and troubleshooting information.
2. Develop the User Guide, which addresses procedural information for the business users on daily operational use of the software.
3. Develop and maintain the Version Description Document (VDD) which is used to identify, maintain, enhance, and recreate the product throughout its lifecycle.
4. Create a Transition Plan to include a transition meeting to present a coherent methodology for transferring responsibility for system sustainment to the desired sustaining organization. The Contractor shall describe the system components, architecture, interfaces, and environments and then clearly articulate what elements are to be transitioned to Product Support.
5. Develop a Deployment and Installation Guide to include back-out and rollback procedures, a listing of any changes to Security Keys that impact an end user’s ability to access and perform a system function, Technical Manual, System Security Guide, System Contingency Plans, and Disaster Recovery Plan.
6. Provide all documentation required to obtain/maintain an ATO.

Deliverable

1. Build Release Package

---

Example: Assessment and Authorization Support

The Contractor shall provide support, applicable documentation, and coordination with Information Security Officers (ISOs) to ensure consistency with ATO requirements for certification to ensure that the software enhancements meet Government information security policies and standards.

The Contractor shall:

1. Conduct and participate in vulnerability scans and tests or best practice quality checks or reviews as detailed in XXX. Security scanning shall be performed by multiple methods and is done multiple times throughout the course of a project with methods such as infiltration testing (WASA), code analysis tools (Fortify), etc.
2. Remediate critical and high vulnerabilities identified in government scans or quality checks or reviews.
3. Provide Vulnerability Scanning Reports and Assessments

 Deliverables

1. Vulnerability Scanning Reports and Assessments
2. Assessment and Authorization Artifacts

---

Example: Release and Deployment Support

Successful completion of deployment requires that the solution or application has received the required approvals and authorizations. The Contractor shall provide SME to support and coordinate each release with the Government technical staff and the development and integration teams of the systems that are interfaced.

The Contractor shall resolve issues and ensure that migration is completed as planned to the proper technical environments.

The Contractor shall support deployments by:

1. Participating in coordination activities to review deployment requirements and verify the sufficiency of deployment plans and checklists.
2. Working in conjunction with the Government to provide deployment support for each of the scheduled releases.
3. Closely monitoring and documenting the operational solution for a minimum of 90 calendar days after release to ensure quality and seamless transition for operations support.

The Contractor shall create a Release and Deployment Support Plan, which will outline how the Contractor will accomplish the release and deployment support tasks. The Contractor shall also create a Release and Deployment Support Package, which includes:

1. Solution Deployment Packages (SDP) with smart scripting to the Government in support of project deployment efforts. The SDP shall include all applicable required Artifacts covering the Release Management, Product Documentation, and Product Support phases.
2. Updated Build Release Package
3. Release Notes within the Release Package that describe changes to existing software and new features and functions created as a result of this enhancement.
4. Design documents
5. Software code

The Contractor shall include updated and final technical documentation reflecting any changes occurring during IOC and shall make a final, formal delivery to the Government as part of the Release and Deployment Support Package. If any discrepancies are found, the Contractor shall be responsible for resolution.

 Deliverables

1. Release and Deployment Support Plan
2. Release and Deployment Support Package

---

Example: Post Deployment Support

Upon completion of the first product build release and each subsequent release, the Contractor shall provide defect management support and coordination. Defect correction can be planned for a patch to the subsequent production version or will be placed in the product backlog. Defects may be identified by the COR/GPM, users, Help Desk, or Business/Product Owners.

For each defect identified, the Contractor shall deliver a Defect Resolution Plan. It shall include the triage of the defect and a plan for resolution, including timeline and impacts to the code and updates to Government approved tools. Following the COR/GPM’s approval of the Defect Resolution Plan, the Contractor shall execute the approved plan. This support shall also continue for 90 calendar days after completion of the TO (warranty).

1. Tier 0 (Username and password problems, User Box Configuration, low level instructions on how to use the applications) – Handled by others
2. Tier 1 (Application Error Messages) – Handled by others
3. Tier 2 (Report generation, Production Research, Database Updates, Batch job support) – Handled by Contractor
4. Tier 3 (Changes to application code) – Application defects, etc. – Handled by Contractor

Resolution times will be based on each product’s established Service Level Agreement (SLA).

 Deliverable

1. Defect Resolution Plan

---

Example: Application Performance Monitoring and Alerting

The Contractor shall utilize application performance monitoring strategies to develop product performance metrics that that will be monitored throughout the contract.

The Contractor shall provide an Application Monitoring Plan including the automated testing tools and automated testing scripts that shall be used.

The Contractor shall provide the Application Monitoring Plan to the GPM/COR for review and approval. Upon approval, the Contractor shall implement application monitoring in accordance with the approved plan and establish an Application Dashboard that provides real time performance metrics to all program stakeholders.

The Contractor Application Performance Management processes shall:

1. Ensure that custom software components can be instrumented to support a Government approved performance monitoring standard (e.g. Open Tracing)
2. Produce and maintain documentation describing data flow through the application, focusing on how and when the application passes/accepts data to/from other systems or end users.
3. Ensure that all workflows and actions identified during the human centered design process are distinctly mapped/measured in the monitoring environment.
4. Monitor system, network, application, database logs, and performance metrics via Government approved Cloud Service Provider monitoring tools and ensure that code and logic changes are accurately reflected in the monitoring tools.
5. Work with the Government to instrument all significant data paths; or instrument all significant data paths themselves using Government approved monitoring tools.
6. Utilize monitoring plugins and agents to monitor numerical metrics provided by external services, servers, or equipment to collect more in-depth metrics.
7. Work with the Government to establish performance thresholds for the application; integrate those into the monitoring tools.
8. Establish robust and reliable alerting and escalation paths for performance violations (e.g. text, PagerDuty); parties directly responsible for the application as well as the Government should be made aware of performance issues immediately when detected
9. Write and monitor synthetic monitoring scripts for Government infrastructure and applications.
10. Perform postmortems of any outages occurred, including root cause analysis and steps to prevent future outages and provide Postmortem Reports accordingly.

Deliverables

1. Application Monitoring Plan
2. Application Monitoring Dashboard
3. Postmortem Reports

---

Example: Decommissioning Support

The Contractor shall provide an approach and plan for decommissioning legacy systems being replaced by “to-be” systems. The approach should encompass identifying, gathering, and analyzing representative system-specific data to understand the conditions, parameters, limitations, and other factors that will drive decommission plans. Topics of interest and data sources may include, but not be limited to, the following:

• Users/user communities
• System features including how they are used to support user community business operations and what gaps exist between legacy systems and the “to-be” systems
• Data movement within legacy systems, across integrated solutions, and downstream to reporting tools
• Data retention requirements
• Regulations and policies
• Based on scope of issue, determine alternatives to facilitate shut down
• Legal review of course of action for records retention purposes
• System integrations
• Architectures

The Contractor shall identify alternate solutions for decommissioning each legacy system. Depending on the data gathered, this may include a series of interim or transitional steps leading towards the long-term solution. Based on the alternatives identified, the Contractor shall perform an analysis of alternatives for Government leadership to select as the long-term enterprise approach.

The Contractor shall develop a Decommissioning Analysis Document for each legacy system which shall include, but is not limited to:

1. System description
2. Technical architecture (to include internal and external interfaces)
3. Data exchange
4. Data retention requirements
5. Decommissioning dependencies
6. System support resources
7. Decommissioning costs

 Deliverables

1. Decommissioning Analysis Document
2. Legacy System Decommissioning Plan