693JJ926RQ000450_TRIPRS DRAFT SOW.pdf

Traffic Records Improvement Program Reporting System

(TRIPRS)

Statement of Work March 2026

Version 1.0

Prepared by The U.S. Department of Transportation

National Highway Traffic Safety Administration Office of National Driver Register and Traffic Records Division

(NDR&TR)

1 INTRODUCTION

The National Highway Traffic Safety Administration (NHTSA) is an agency of the U.S.

Department of Transportation (DOT). NHTSA’s mission is to save lives, prevent injuries and reduce traffic-related health care and other economic costs. The agency develops, promotes and implements effective educational, engineering and enforcement programs with the goal of ending preventable tragedies and reducing economic costs associated with vehicle use and highway travel.

NHTSA accomplishes this in part by awarding State Traffic Safety Information System Improvement grants to support State efforts to improve their data systems. NHTSA’s National Driver Register and Traffic Records Division (NDR&TR) is tasked with helping states improve their traffic safety data collection, management, and analysis capabilities through evaluation, training, and technical assistance. The NDR&TR Division is also responsible for the Model Minimum Uniform Crash Criteria (MMUCC) and helping states align their crash systems and documentation to the latest edition of MMUCC.

2 BACKGROUND

NHTSA’s NDR&TR support for States centers on six traffic records data systems (Crash, Driver, Vehicle, Roadway, Citation/Adjudication, Injury Surveillance). NHTSA commissioned the development of the Traffic Records Improvement Program Reporting System (TRIPRS) in 2010 to monitor and track the advances in the States’ Traffic Safety Information Systems technology and practices. TRIPRS allows the collection and organization of data and currently houses State documents and information collected in the normal operations of the State Traffic Records Assessment Program (STRAP); the Safety Program Assessment (SPA) module that currently includes assessments for pedestrian and bicycle safety, impaired driving, and occupant protection programs; the Data Mapping module; and the State Electronic Data Collection grant application and monitoring module.

The NHTSA Office of the Chief Information Officer (OCIO) operates and maintains a set of virtualized Windows servers that host various Traffic Records data systems. Currently there are three pairs of servers that are supporting the TRIPRS application. Each pair is a combination of a database/application server and a web server. One pair is for disaster recovery, one pair is for development and testing, and one pair is the production system host. Each pair utilizes the latest version of Oracle Enterprise database 19.7.0.0.0 (19c), Oracle Application Express (21.2.0.0.0), Oracle ORDS (21.4.0.0.0), Oracle Business Intelligence (BI) Publisher (12.2.1.4.0), Oracle Web Logic (12.2.1.4.0) (Web Application Server), and Oracle Web Logic (12.2.1.4.0) (BI Publisher Hosting Server).

3 OBJECTIVES

The purpose of this project is to support develop, enhance Traffic Records Improvement Program Reporting System (TRIPRS) system while sustaining the software in the Production environment.

The primary goal is to O&M Support, enhance and expand existing features, provide backend integration with Oracle cloud Infrastructure (OCI) services and other NHTSA systems. Note that this includes non-functional requirements, which include optimizing the development environment, cost control, optimization, performance and user experience, all of which must be addressed in lockstep with functional requirements. Continuous improvement is a necessity and a key common thread across DOT projects. Thus, the architecture and design principles utilized for

TRIPRS system, as well as the software development process and associated tooling, must also continue to be refined, enhanced and remain extensible to facilitate seamless implementation of future requirements.

Across all programs and projects, using Agile methods and sound software engineering best practices, DOT generally seeks to leverage automation to reduce manual efforts, increase efficiencies, reduce operational risks, and reduce overall costs by implementing self-service features, automating manual tasks and increasingly incorporating new and emerging technologies, such as Artificial Intelligence (AI) and Machine Learning (ML) in addition to existing push for serverless and managed cloud services whenever possible. Additionally, as all S93 digital factory programs and projects contribute to the same DOT mission, they often operate on closely related data. Thus, integration and cross-referencing of information between IT solutions within DOT is important.

The automation goal in particular also includes the software development lifecycle itself. Like many projects at DOT, It is the goal of DOT to ensure all stages of the CI/CD pipeline are sufficiently automated such that continuous delivery, comprised of any number of small changes, are deployed to the Production environment frequently without manual intervention.

Additionally, in alignment with a key guidance from the S93 Digital factory Chief Technology Officer (CTO), all implementations, regardless of which project they original from, must take not only a cloud-first but also an enterprise-first approach so that the solutions can be deployed across DOT and be readily re-usable by other projects within DOT.

Using these guiding principles – automation, self-service, enterprise-first, leveraging emerging technologies and continuous improvement, the goal of the TRIPRS project to provide users with a modern, high-quality software solution, built with highly automated modern techniques, that offers exceptional user experience which allows them to carry out their mission activities with ease, efficiency and reduced cost. Along the same guiding principles, the Contractor is encouraged to be innovative and make recommendations for improvements in processes, techniques, tools and new technologies.

The work performed through this contract will be coordinated with the Traffic Records (TR) Project Manager, Contracting Officer Representative (COR) (if different), the DOT OCIO, and other contractor staff. Work under this contract will provide TRIPRS application and Oracle software support. TRIPRS user support (help desk and training) will be contracted separately from this solicitation.

4 SCOPE OF WORK

The scope of this statement of work relates Operations and Maintenance (O&M) and Optional Development, Modernization and Enhancement (DME) support for the Traffic Records Improvement Program Reporting System (TRIPRS) for the DOT’s National Driver Register and Traffic Records Division (NDR&TR). TRIPRS is hosted on an Oracle Cloud Infrastructure (OCI) Platform.

4.1 SPECIFIC REQUIREMENTS

4.1.1 Operations And Maintenance of the TRIPRS Application

The contractor shall provide Operations and Maintenance (O&M) support (e.g. Application support, Database management, documentation, reports, authorization to operate (ATO)) to the current TRIPRS application. The TRIPRS application currently includes STRAP, SPA, Data

Mapping, SEDC grant monitoring module, a Document Library (used by all modules), and a Sandbox module. All modules are accessible through TRIPRS and several have linked Tableau data dashboards.

STRAP Module

SEDC grant Module TRIPRS

SPA Modules

• Ped/Bike

• Impaired Driving

• Occupant

Protection

Data Maping

Module

Figure 1: TRIPRS and Existing, Connected Modules (STRAP, SPA, Data

Mapping, SEDC, Document library and Sandbox)

4.1.2 Development, Modernization, and Enhancement (DME) These are Optional tasks based on funds availability As an actively used system to support the mission of NHTSA’s Traffic Records Division activities, the TRIPRS system will have an evolving backlog containing various requirements and system enhancements. In accordance with the Agile approach, should the Government award this optional task, the Contractor shall lead efforts under the direction of the COR to groom and refine these Product Backlog items on a biweekly basis, or as directed by the COR. As part of the refinement activities, the Contractor shall capture new requirements, conduct discovery and elicitation, and track them using NHTSA’s Agile project management tools, prioritizing them as directed by the COR. As described in the Software Development Process section of this document, each item in the Product Backlog must be sufficiently detailed and complete, and the Contractor shall generally maintain a clean, accurate, and up-to-date Product Backlog. The Contractor shall lead collaboration and coordination efforts with other DOT/NHTSA teams, as appropriate, analyze relevant requirements, develop and document detailed requirements, and design, develop, and deploy capabilities that meet these requirements. The Contractor shall provide work products, milestones, and deliverables for new requirements in accordance with the Agile schedule. This means that the deliverable is generally due and updated on cadence, every Sprint or Release, or as directed by the COR. The Contractor may negotiate the specifics of each milestone and deliverable with the COR

4.1.2.1 Develop new State highway safety program assessment sub-module within SPA (Optional)

The contractor shall leverage the existing program assessment sub-module format in the SPA module (i.e., Impaired Driving, Occupant Protection, Ped/Bike) to build new State highway safety program assessment sub-modules (e.g., motorcycle program, EMS program). This includes replicating the highway safety program assessment questions within the sub-module, testing, validating, deploying, and documenting using Agile process.

4.1.2.2 TRIPRS Modernizing (Optional)

The TRIPRS system has an evolving backlog item containing various bugs and system enhancements to already implemented capabilities detailed below under Fixes and Enhancements, Text and Tasks. The contractor shall include these backlog items part of TRIPRS Modernization task. The Modernizing plan should include Proof of concept and other details, from the current client server architecture to a DOT approved Oracle cloud environment.

Fixes and Enhancements:

o Identify Respondents to match SPA functionality. Add pick list and ability to Limit to assessment state o There is an "easy button" for the SPA Team Leader/Editor role. Can we add this ability to Assessors in STRAP? Can we also add this for the SPA modules?

o TRIPRS currently logs the dates and recipient of system-generated emails, but not the content. They could start tracking the content as well, but this would be a heavy lift. It could be helpful for verifying that links are valid and working.

o Updates to TRIPRS to automate report templates for customized assessments is a heavy lift—a good time to explore this would be when TRIPRS moves to a new platform.

o Please create a report that can count how many times a question has been used in recommendations o Eliminate codes for respondents in the assessment report--just use respondent names instead of their codes

Text o System Access o Token o Help tab on Left –All sections o Verify the Language and links o Update the "What do I do" sections, roles have changed and contact info. Also note that the text changes font.

o Change page reference text from "Page" to "Page(s)"

Tasks o Develop a Modernization plan based on current system functionalities align with Oracle Cloud plat form and DOT Standards including Google Work space Capabilities.

o Review Modernized plan with Program office team and DOT Enterprise Architecture team to align DOT Standards.

o After receiving an approval from Program office and DOT EA teams.

Contractor shall work with Program office team for planned delivery including Data migration, reports and any other third-party software products.

4.1.2.3 Model Minimum Uniform Crash Criteria (MMUCC) Mapping AI Project Integration (Optional)

The NHTSA teams are developing a stand-alone MMUCC mapping AI tool using Databricks. The contractor shall submit a proposed Integration plan for building TRIPRS Integration with this MMUCC mapping AI tool. The plan should include Proof of concept, planned delivery schedules, and AI capabilities using Agile process.

Fixes and Enhancements:

o Input a spreadsheet to create State data structure and mapping report o When creating a State structure, we don’t want the page to have to reload every time we click on something new.

o Alphabetize the elements in the State structure for easier reading o scrolling through the “MMUCC Active Mappings” section could be improved.

Integration o Integrate EDMAS MMUCC mapping w/ TRIPRS

4.2 Technical Requirements

The TRIPRS system is hosted in Oracle Cloud Infrastructure (OCI) and the environment is Federal Risk and Authorization Management Program (FedRAMP) certified at the Moderate level. Contractor shall continue to make use of these and similar managed services and approaches, especially as they improve over time, for all development activities under this SOW. The Contractor shall ensure that deprecated features in OCI or any oracle component of the technology stack are resolved well in advance of obsolesce.

The Contractor shall ensure the system makes use of reusable components and provides a consistent UI behavior across all aspects of the application. The Contractor shall ensure that all UI designs adhere to NHTSA website style guidelines, use styles, layout, color scheme, and fonts approved by NHTSA. The Contractor shall ensure that the web application adheres to the NHTSA Human Interaction Guidelines (HIG), and the Contractor shall design and develop easy-to-use web application interfaces for all new features, enhancements, and applications. The Contractor shall ensure that all services and applications are Section 508 compliant per DOT policy.

The Contractor shall follow well-established conventions and apply sensible defaults across the system, especially where explicit guidance is not provided by NHTSA. Under no circumstances shall the Contractor use hard-coded values.

The Contractor shall ensure consistent behavior for similar UI controls and components across the application. The Contractor shall ensure that all UI elements and controls are highly responsive with a response time of 1 second to refresh content as a result of user actions, except where the COR has explicitly approved longer responses times for highly specialized, infrequently used functionality based on the Contractor’s request. Even in such exceptional cases, which must be few, the Contractor shall ensure the maximum response time does not exceed 8 seconds.

In general, the Contractor shall ensure that all UI elements provide options to show and/or link to data associated to the displayed information, so that users can quickly access all related data and documents. Where appropriate, the Contractor shall provide UI controls that allow the user to create associations between entities. The Contractor shall provide the users with automatic recommendations for potentially related data based on a number of criteria that NHTSA will provide.

The Contractor shall provide a highly positive user experience across these systems by implementing usable functionality with intuitive, conventional user interface components and the effective realization of the workflows and business rules. The Contractor shall incorporate extensible designs that easily facilitate future enhancements, maximize user productivity and efficiency, maximize system performance and responsiveness, and enable efficient maintenance of the system.

The Contractor is expected to apply their skills and experience in developing modern, performant and highly usable cloud hosted systems. As an innovation and continuous improvement, the Contractor is expected to stay current with the evolving technology landscape and encouraged to not only leverage DOT/NHTSA approved technologies and tools within and in the development of the TRIPRS systems, but also make recommendations for new ones for utilization within the TRIPRS and NHTSA.

4.2.1 Authentication and Authorization

The Contractor shall identify and implement the access control permissions required for each new feature or enhancement.

For internal users, the Contractor shall ensure that only Multi-factor Authentication (MFA), currently using the DOT issued Personal Identity Verification (PIV), is allowed.

For external users using the enterprise portal, the Contractor shall ensure that only MFA is allowed, and that the MFA is with a trusted identity provider, which is currently Login.gov.

The Contractor shall ensure that an authenticated user’s activities are logged and the logged in session is maintained across different tabs/windows of the browser. The Contractor shall ensure the authorization mechanism extends to all objects and services touched in the course of executing a user request or action to ensure proper end-to-end authorization.

4.2.2 Application Performance Monitoring and Alerting

The Contractor shall always ensure total view of the health of the TRIPRS systems across the entire technology stack by ensuring the TRIPRS system is highly observable and setting up continuous monitoring of the system using NHTSA’s observability and application performance monitoring tools and services (NHTSA approved Application Performance Monitoring (APM) tools, such as New Relic). The Contractor shall ensure that monitoring spans not only the health of individual services and events but the end-to-end application request/response cycles of the web applications, covering all layers of the application/technology stack, from the browser to content delivery services to the backend microservices, API calls and database. The Contractor shall ensure that the system monitoring provides details on how well the system is performing in real-time in order to provide visibility and key performance indicators about the users’ interaction with the system both in the UI and in areas not visible to the user. The Contractor shall ensure that logs, metrics, traces and data related to the performance and monitoring are easily accessible and published to the development and operations team as well as other NHTSA stakeholders.

Additionally, the Contractor shall set up a mechanism to automatically monitor the system from a user’s perspective by frequently logging into the system and exercising key functions. For example, by setting up an automated Selenium test suite.

The Contractor shall set up a set of automated and real-time alerts which are triggered when pre-defined performance parameters go out of compliance so that the contractor’s team and other COR identified personnel (typically, operations team members) can review and take remedial actions as needed.

To facilitate application monitoring, the Contractor shall ensure all UI events, API calls, database queries, search queries, and in general any application-initiated actions are logged with meaningful data and easily accessible by NHTSA stakeholders. To assist users with reviewing the history of changes to all system entities they can edit, the Contractor shall support an audit trail feature that shows changes to every field of a user editable entity, including the author of the change, date and time, the old value and the new value. Such a model for audit trails is already implemented in other existing NHTSA projects.

4.2.3 Cybersecurity and Privacy

The Contractor shall ensure that the TRIPRS systems architecture always adheres to Federal, DOT, and NHTSA cybersecurity and privacy requirements. The Contractor shall ensure that cybersecurity and privacy prerequisites are prominently included as an integral, first-class concern in all phases and aspects of the Contractor’s development and support activities, including technical approach, software development and IT maintenance activities. The Contractor shall ensure access to the TRIPRS systems and data are maximally secured and protected. The Contractor shall ensure that data at rest as well as in transit within the TRIPRS systems and between the TRIPRS systems and other systems is encrypted. The Contractor shall create or update, as appropriate, cybersecurity related artifacts in accordance with NHTSA cybersecurity requirements.

4.2.4 Artificial Intelligence Integration

The Contractor shall address NHTSA’s evolving data analytics needs by incorporating techniques and tools from the Artificial Intelligence (AI) arena, including Machine Learning (ML) and Natural Language Processing (NLP). As part of the TRIPRS system requirements elicitations, as the need arises, the Contractor shall explore these technologies to see if and how they can be leveraged to address certain NHTSA needs with respect to the TRIPRS data. Further, the Contractor shall also consider AI-powered solutions to apply to the software development process itself, including, for example, GitHub Copilot and other similar emerging technologies. Note that only DOT/NHTSA approved technologies can be utilized at NHTSA. Therefore, the Contract must obtain written approval from the COR when leveraging new technologies within the TRIPRS systems itself or in the construction of the TRIPRS systems software.

Additionally, the Contractor shall collaborate and coordinate with other teams within NHTSA who are building the NHTSA data analytics environment using new and emerging technologies.

4.2.5 Cloud Cost Control and Optimization

The Contractor shall ensure NHTSA’s use of TRIPRS cloud resources optimizes NHTSA’s cost by periodically reviewing their utilization against their cost. As such, the Contractor shall develop a Cloud Cost Control & Optimization Plan (CCC&OP) and submit it to the COR on a monthly basis. Within ten (10) days of receipt, the COR will accept or reject the CCC&OP. The Contractor shall maintain and/or revise the CCC&OP as directed by the

COR.

In the CCC&OP, the Contractor shall evaluate historical TRIPRS cloud resource utilizations through the most recent past month vs. incurred and projected costs and present recommendations to the COR for maximizing the value of cloud resources and minimizing costs by reducing, eliminating or consolidating unused or minimally used resources. The Contractor shall execute the COR approved recommendations immediately and ensure they are reflected in the following month’s CCC&OP. In the process, the Contractor shall collaborate and coordinate with the DOT Enterprise Cloud Service (ECS) team as appropriate.

4.2.6 Application Help & User Guides

The Contractor shall develop and maintain separate User Guides for any newly developed tasks for the internal and external TRIPRS applications. Within ten (10) days of receipt, the COR will accept or reject the User Guides. The Contractor shall maintain and/or revise the User Guides as directed by the COR.

The Contractor shall ensure the User Guides are current and updated with each software release of the TRIPRS systems as applicable. The Contractor shall ensure users are able to download a bookmarked PDF of the User Guides. The Contractor shall ensure that the User Guides are well-written, are complete and include sufficient descriptions of the business workflows, business rules and user roles/access control applicable to the associated application. Where necessary, the Contractor shall ensure that help pages have screenshots and callouts to illustrate and explain the application functionality. Also as necessary, the Contractor shall provide example-driven guides and instructions to walk the reader through a given functionality.

The Contractor shall also ensure the application online help contents include clear messages and tooltips within the application to guide the users on the user interface form fields, form submissions and error messages within the application. The Contractor shall ensure that every failed operation results in a clear and concise message to the user and provides the user with a clear explanation for how to overcome the error condition.

As needed Contractor team shall work with other teams based on program office or S93 office guidance.

All the documentation must be compatible with MS, Google, and PDF formats.

4.3 Software Development Process

For all software development activities (developing a new feature, enhancing existing features or fixing defects), the Contractor shall follow industry best practices in Agile Software Development Lifecycle (ASDLC) and software engineering processes. The Contractor shall develop and submit to the COR an ASDLC Plan (ASDLCP) within thirty (30) days of award. Within ten (10) days of receipt, the COR will accept or reject the ASDLCP. The Contractor shall maintain and/or revise the ASDLCP as directed by the COR.

The ASDLCP must include the end-to-end, comprehensive approach the Contractor will utilize for software development using an Agile framework to deliver capabilities and value to NHTSA incrementally, encompassing the complete lifecycle activities that include, but may not be limited to, requirements analysis, design, security considerations, development, testing, security testing, user acceptance testing (UAT) and deployment in each iteration. The Contractor is encouraged to utilize well-established programming models and paradigms, such as Test-Driven Development (TDD), Behavior-Driven Development (BDD), Pair Programming, etc. The Contractor shall ensure that the ASDLCP also defines the timelines for all software releases, Sprints, milestones, work products and deliverables which the Government has specified to be delivered according to the Agile Schedule. All ASDLCP related artifacts are considered living and the Contractor shall ensure they are kept current and submitted to the COR for review at least once prior to each software release until the end of the period of performance.

The Contractor shall rigorously incorporate into the ASDLCP the processes and artifacts described in the following sections. The Contractor shall utilize the ASDLCP as part of its overall project management plan to consistently deliver high-quality TRIPRS capabilities and feature sets that address NHTSA’s needs in an iterative manner. The Contractor shall employ rigorous requirements analysis/elicitation, create fully bidirectional Requirements Traceability Matrix (RTM) and implement full automation to build, test and deploy the software solution according to well-established modern DevSecOps processes and modern software development best practices.

The Contractor shall provide and utilize the artifacts identified in this SOW and maintain all of them throughout the period of performance. Not all artifacts may be required for all efforts. As appropriate for a given effort, the Contractor shall request approval from the COR to exclude artifacts that are not applicable to that effort. Unless the Contractor obtains written approval from the COR for exclusions, the Contractor shall develop and maintain all artifacts outlined in this SOW. The Contractor shall submit each artifact for review and approval by the COR in accordance with the Agile Schedule. The COR will review and return the artifact to the Contractor with comments and edits or approve the artifact in accordance with the Agile Schedule.

Many of the milestones and deliverables the Contractor is required to provide for this effort will indicate their schedule is in accordance with the “Agile Schedule”. This means that the deliverable is generally due and updated on cadence, every Sprint or Release, or as directed by the COR. The Contractor may negotiate the specifics of each milestone and deliverable with the COR. The Contractor shall include the finalized, COR directed schedule in the ASDLCP.

4.3.1 Agile Process

The Contractor shall have experience and expertise developing functional, high-quality mission critical enterprise software and web applications using Agile frameworks and state-of-the-art in modern software engineering techniques and tools. Thus, the Contractor shall adapt to continually evolving requirements, changing compliance mandates and rapidly advancing technology landscape.

The Contractor shall develop all software within the scope of this SOW using the Scrum Agile framework using NHTSA’s Agile management tools, currently Atlassian Jira and Confluence.

The Contractor shall conduct Agile ceremonies or events, and develop, maintain and provide all Agile artifacts as deliverables. The table below provides a minimum set of Agile events and deliverables which the Contractor must conduct and deliver, respectively, at the specified cadence.

The COR may direct the Contractor to conduct additional events and/or provide additional deliverables or work products.

The COR will review each artifact and accept or reject it in accordance with the Agile Schedule.

The Contractor shall maintain and/or revise each artifact as directed by the COR.

Event/Deliverable Description Cadence

Discovery Session where Contractor shall elicit requirements from Program office stakeholders

Cadence to be established by COR

Daily Standup Agile standup Daily

Release Planning Planning for work to complete in next Release Start of every Release

Sprint Planning Planning for work to complete in next Sprint based on COR goals Start of every Sprint

Product Backlog Refinement

Adjusting priorities, estimates and details for Product Backlog Items based on direction from

COR

Once per Sprint

Sprint Review & Demonstration Demonstrate work completed in the Sprint Once per Sprint

Retrospective

Review & discussion of what went well and tracking of lessons learned and improvements to apply to future Sprints

End of every Sprint

Project Roadmap

Roadmap that shows project timeline/milestone dates by Release and Epic/User Story based on current estimates

Updated every Sprint

Product Backlog Singular source of NHTSA prioritized inventory of all requirements collected by the Contractor Updated every Sprint

Sprint Backlog Inventory of all work to be completed in the Sprint Created every Sprint

Agile Board Helps plan, visualize and managed the Product and Sprint Backlogs Created every Sprint Updated daily

Sprint Burndown Daily progress toward work committed in the Sprint Updated daily

Sprint Velocity The team’s Velocity (points completed vs.

planned) in every Sprint Updated every Sprint

Release Burndown

Daily progress toward work committed in the Release Updated daily

Epic Burndown Daily progress toward work in the Epic Updated daily

Initiatives, Epics, User Stories, Tasks and Bugs

Hierarchy to organize and track requirements/issues

Updated/Reviewed during every Product Backlog Refinement session

Acceptance Criteria

Criteria that define when an issue can be considered complete

Integral part of every User Story/Task/Bug

Level of Effort Estimation in Units of Story Points

Level of effort to complete the work for a User Story/Task/Bug from start to finish (analysis, design, development, test, deployment, documentation, etc.)

Integral part of every User Story/Task/Bug

Definition of Ready

Detailed criteria that define when a task is truly ready for development (e.g., there are no requirements clarification questions, the task is not blocked waiting for NHTSA action, etc.)

Included in the

ASDLCP

Updated as necessary or directed by COR Pre-requisite before a task can be started on

Definition of Done

Detailed criteria that define when a task is truly done. Applies to all tasks.

Included in the

ASDLCP

Updated as necessary or directed by COR

Table 1 - Minimum Set of Agile Events/Deliverables the Contractor shall Conduct/Provide on Cadence

On a daily basis, the Contractor shall ensure all issues in NHTSA’s Agile management tool are accurate and complete. At any given time, for any given Initiative/Epic/User Story, Sprint or the overall project, the Contract must be able to answer the following questions quickly based on the information in the NHTSA Agile management tool: 1) How much work has been completed? 2) How much work remains? 3) Is the item on track for completed as scheduled?

It is extremely important to note that all reports and overall project status are informed by the status of the issues in the NHTSA Agile management tool. The Contractor shall ensure that all built-in and plug-in provided reports within NHTSA’s Agile management tool (e.g., Velocity, Release Burndown, Sprint Burndown, Cumulative Flow, Control Chart, etc.) are accurate and up-to-date on a daily basis such that the COR and NHTSA stakeholders can depend on the information they convey. For any given report, if the underlying issues do not have the correct information (summary, status, estimate, etc.), then a garbage-in-garbage-out situation could arise and the accuracy of the report accordingly adversely impacted.

The Contractor shall also ensure that the Agile board is accurate and represents all activities in priority order along with their correct status. The Agile board will be referenced by NHTSA to review the current queue of activities as a key element of the overall project status.

A Sprint will be two or three weeks long, as determined by the COR. The Contractor shall ensure that all changes implemented in a given Sprint-- a product increment-- are ready to be deployed to Production at the end of the Sprint if approved by the COR. The Contractor shall ensure that every product increment provides value to NHTSA within the scope of this SOW. A release will be comprised of two or three product increments, as determined by the COR. Changes to the Production environment (e.g., release deployment) can only be made with the approval of the COR, who will ensure all DOT/NHTSA requirements are met before approving the change. The Contractor is responsible for planning a release in advance, preparing a checklist and all required artifacts to ensure a timely and smooth approval of a Production deployment by the COR.

The Contractor shall ensure that all tickets (Initiative, Epics, User Stories, Tasks and Bugs) in NHTSA’s Agile management tool have a sound and consistent structure with succinct but descriptive summaries and comprehensive, well-written details so they can be understood by the widest audience possible and serve as good historical references in the future. The Contractor shall also ensure that every ticket has a level of effort estimation in story points that is driven by team discussion, sound technical approach and consensus.

The Contractor shall also ensure that an Acceptance Criteria is present for every relevant ticket, and which is accurate and comprehensive. For bugs, the contractor shall ensure the ticket clearly provides context for the bug, states the business and technical impacts of the bug, steps to reproduce the problem, why it is a problem to begin with, and any available workarounds. Most importantly, the Contractor shall ensure that no ticket is marked as completed until the Definition of Done is met.

The Contractor shall be responsible for meeting the goals of every Sprint and Release, working with the COR if issues arise to ensure adjustments are made to correct course without impacting the overall cost, scope or schedule of this contract.

4.3.2 Requirements Definition & Management

The Contractor shall be responsible for creating and maintaining a Requirements Definition Document (RDD) for review and approval by the COR in accordance with the Agile Schedule.

The COR will accept or reject the RDD in accordance with the Agile Schedule. The Contractor shall maintain and/or revise the RDD as directed by the COR.

The RDD will serve as the overarching and complete repository of high-level requirements which will be the main source of the Product Backlog, which the Contractor shall decompose into logically organized Use Cases, Initiatives, Epics, User Stories, Tasks and User Story Maps as appropriate. The RDD will anchor the requirements documentation mechanism by providing a starting point for capturing all NHTSA needs within the scope of this SOW as product capability requirements. The Contractor shall ensure that the RDD includes functional and non-functional requirements, data requirements, reporting requirements, external interfaces, dependencies and constraints, as well as standards and technical compliance requirements such as cybersecurity, usability (e.g., Section 508) and performance metrics.

Additionally, as part of Agile planning and decomposing the work to be completed, the COR may request the Contractor to build an Agile Work Breakdown Structure (WBS) as an overarching organization tool for feature completion, releases, Sprints within releases, activities within a Sprint, etc.

While the COR will prioritize requirements and make trade-off decisions, the Contractor shall be responsible for building and maintaining the corpus of requirements in the RDD, and the decomposed requirements that flow from it, by conducting customer needs analysis and elicitations through one more stakeholder session to be coordinated through the COR.

As requirements change and Product Backlog refinement sessions dictate, the Contract shall update the RDD to reflect the current requirements. However, due to its high-level nature, it is expected the RDD will change infrequently relative to the decomposed, fine-grained user stories, which the Contractor shall create and maintain in NHTSA’s Agile project management tool.

4.3.3 Requirements Traceability Matrix (RTM)

The Contractor shall create and maintain a Requirements Traceability Matrix (RTM) as part of the requirements elicitations and analysis process and submit it to the COR for approval. The COR will accept or reject the RTM in accordance with the Agile Schedule. The Contractor shall maintain and/or revise the RTM as directed by the COR.

The Contractor shall ensure that the RTM clearly links requirements to where and how they have been implemented in the system. The Contractor shall ensure that the RTM provides bidirectional traceability, meaning the RTM documents each requirement from its definition or reference in the RDD through analysis, design, testing, acceptance, and deployment.

4.3.4 Solution Architecture

The Contractor shall develop/update and maintain the TRIPRS Solution Architecture Document (SAD) to specify the software layers (front end, middle tier, and backend) and the interconnection among major components, including services/APIs, databases information /document stores and third-party software/services/components in support of the requirements provided in this SOW.

The COR will accept or reject the SAD in accordance with the Agile Schedule. The Contractor shall maintain and/or revise the SAD as directed by the COR.

The Contractor shall ensure that the SAD includes comprehensive logical and physical architecture diagrams, their descriptions, system data flow diagrams, security components and performance and scalability objectives and designs. The Contractor shall make architectural choices and recommendations that inherently provide cybersecurity, performance, reliability, scalability, extensibility, high efficiency, reduced costs and innovation for NHTSA. The Contractor shall leverage NHSTA approved cloud technologies, managed services and serverless resources, including new and emerging technologies, that allow NHTSA to innovate on behalf of its end users and focus more on solving business problems and less on infrastructure management.

All technical solutions are subject to review by the NHTSA Architectural Review Board (NARB) and will be coordinated by the COR. The Contractor shall present the TRIPRS technical designs with the NARB periodically and as directed by the COR, and address any feedback and findings in a timely manner as directed the COR. The Contractor shall also undergo an Oracle cloud Well- Architected Framework review, coordinated by the COR, and address any feedback and findings in a timely manner as directed by the COR.

4.3.5 Design Specifications

The Contractor shall develop and submit, to the COR, a Technical Design Specification (TDS) in accordance with the Agile Schedule for all features. The COR will accept or reject the TDS in accordance with the Agile Schedule. The Contractor shall maintain and/or revise the TDS as directed by the COR.

As appropriate, the Contractor shall ensure that the TDS includes the design of the backend, including algorithms, sequencing of calls between all services, synchronous and asynchronous processes, error handling, etc., and how relevant business workflows and rules will be implemented. The TDS need not address all low-level details, but the Contractor shall ensure the TDS contains sufficient details on the implementation blueprint for a given capability, including key design decisions and the rationale for them. The Contractor shall ensure that the TDS is compliant with and supports the SAD.

As part of the TDS, the Contractor shall include application process flows, business process models, including concept of operations, flow charts, business workflows, activity diagrams, use case diagrams, etc., as appropriate. The TDS shall account for all impacted systems and processes, clearly convey the technical approaches taken and serve as a communications tool to clearly convey the intended implementation to the Contractor’s development team as well as NHTSA technical stakeholders.

As appropriate, the Contractor shall also develop and include in the TDS a User Interface Design (UID) that includes wireframes and/or screen mockups that depict how the user interface will be laid out and how UI elements and controls will behave.

The Contractor shall also develop an Interface Control Document (ICD) to describe touchpoints and interactions with other systems. The Contractor shall ensure that the ICD spells out the connectivity, security, communication protocol, data flow, timing, synchronicity, sequencing, data exchange formats and expected Service Level Agreements (SLA) between the TRIPRS system and such systems. The Contractor shall include illustrative diagrams to convey the interaction between the systems and the other systems. The Contractor shall collaborate and coordinate through the COR with the other systems’ points of contact to reach agreement on the ICD.

4.3.6 DevSecOps and CI/CD

The Contractor shall utilize DevSecOps practices to build secure, high quality TRIPRS software in an automated fashion. The Contractor shall build upon the TRIPRS system’s existing Continuous Integration (CI) and Continuous Deployment (CD) pipeline to develop and deploy its solutions across all environments: Development, Test, Staging, and Production environments. The Contractor shall automate application code unit test, integration tests, static and dynamic security tests, functional, and regression tests. The Contractor shall enable CD for the TRIPRS systems by automating all the software build, testing and deployment activities and avoiding any manual steps (except possibly COR approval steps).

The Contractor shall ensure all code, scripts, configurations, database changes, etc., are checked into the NHTSA code repository and deployed via the CI/CD pipeline. Additionally, the Contractor shall follow the DOT/NHTSA configuration and change management processes to apply changes to the TRIPRS CI/CD pipeline and application infrastructure (e.g., databases, infrastructure, network, object storage, and compute resources).

The Contractor shall incorporate Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST) and code quality scans as part of the build and deployment process and resolve all findings to meet DOT/NHTSA cybersecurity requirements before deploying solutions to the Staging or Production environment.

Once the application is automatically built, automated functional, regression and load testing run and pass, automated security testing (static and dynamic) run and pass, and UAT passes, the Contractor shall ensure that the deployment to Production proceeds in a controlled and automated fashion with no manual intervention, other than the required approval by the COR to deploy to Production.

The Contractor shall incorporate the DevSecOps approach in the ASDLCP. Further, the Contractor shall review the DevSecOps activities and CI/CD pipelines on an ongoing basis and make enhancements to streamline both, increase automation and integration of the various pipeline stages, reduce errors and decrease build and deployment times.

4.3.7 Testing

The Contractor shall conduct functional, unit, system/integration, regression, smoke, load/performance and/or stability tests as applicable for each system release. The Contractor shall use industry-standard automated testing approaches and any NHTSA approved tools, such as JMeter for load/performance testing, Cucumber for acceptance testing, and Gauge or Selenium for UI testing. The Contractor shall utilize load/performance testing to stress test the system entry points (APIs, database queries, search queries, etc.) as well as from the user’s perspective by simulating concurrent real users accessing the system and carrying out typical use cases. The Contractor shall ensure that load/performance testing includes various load scenarios that the system is likely to experience during peak usage by users.

The Contractor shall ensure at least 85% of all tests in each category are automated and run on a scheduled basis or triggered a set of predetermined criteria or events. The Contractor shall ensure that the full history and results of each run of tests are easily accessible to authorized NHTSA personnel.

The Contractor shall conduct an amount and type of testing commensurate with the size, scope, and risk of the specific release as mutually agreed upon by the Contractor and the NHTSA COR.

The Contractor shall develop a Test Plan that outlines the Contractor’s overall approach for conducting the various tests mentioned in this section throughout the development process, describes the test environment(s), the process and types of tests to conduct, and the process for recording test findings and sharing test result reports with NHTSA.

The Contractor shall develop and provide a UAT Plan (UATP) for every software release and submit it to the COR for approval at least 5 days prior to the UAT event. The COR will accept or reject the UATP within three (3) days of receipt. The Contractor shall revise the UATP as directed by the COR.

The Contractor shall prepare all UAT test cases in the UATP, set up required data to facilitate the UAT in the UAT environment (typically Staging) and, as appropriate, provide pre-UAT training for users that will participate in the UAT. The Contractor shall ensure that test cases and the UAT activities cover all changes (e.g., user interface, data entry, workflow activities, reporting and other changes that may have operational impact on the system) as well as all user roles.

The Contractor shall ensure that the cybersecurity, access control, performance, and usability of the new system in the UAT environment is identical to how the system will behave in Production.

The Contractor shall facilitate and assist NHTSA in performing UAT when a product increment has passed the Contractor’s functional testing, regression testing and quality control checks.

Although NHTSA is responsible for conducting the UAT, the Contractor shall facilitate the UAT sessions, document all findings in real time during the UAT and work with NHTSA to prioritize remediation actions and plan additional UAT sessions as appropriate. The Contractor shall ensure all defects and feedback items, including request for new enhancements, are tracked in NHTSA’s Agile project management tool.

The UAT is considered passed and successful only when the COR has accepted the product increment which underwent UAT. The Contractor is responsible for obtaining a written product acceptance from the COR, which is required for deploying the product increment in Production.

4.3.8 Software Release Deployment

The Contractor shall release software into the Production environment on a regular cadence according to the Agile Schedule following the process outlined in the ASDLCP. The Contractor shall create a comprehensive, step-by-step Release Deployment Checklist (RDC) listing all activities for every deployment to Staging and Production and submit it to the COR for approval at least five (5) days prior to the software release date. The COR will accept or reject the RDC within two (2) days of receipt. The Contractor shall revise the RDC as directed by the COR.

The RDC must include assumptions, constraints, dependencies, and contingencies. The Contractor shall identify all parties on which the release has a dependency and clearly identify their tasks in the RDC. The RDC must also contain a rollback plan that the Contractor will execute to revert the system to the pre-deployment state if/when a release deployment proves non-viable and NHTSA approves a rollback. The Contractor shall ensure that the RDC has a mandatory section on cybersecurity and privacy to ensure compliance with the requirements outlined in this SOW. The Contractor shall ensure that no software is deployed, or any changes made in the Production environment without approval from the COR.

The Contractor shall prepare and manage Release Notes to document all changes (fixes, enhancements, and new features) included in each system release and support the release process using the NHTSA standard tools. The Contractor shall submit the Release Notes to the COR prior to every release. The Contractor shall ensure every release is well planned and must collaborate with NHTSA to coordinate support from all required resources within and outside NHTSA. The Contractor shall distribute the RDC and conduct such coordination at least two weeks in advance of every release. The COR will review the RDC and Release Notes in accordance with the Agile Schedule. Once approved by the COR, the Contractor shall disseminate the Release Notes to users and/or stakeholders as directed by the COR.

4.3.9 User Training

In addition to any in-application help contents and the User Guide,…