Attachment 1. DRAFT PWS_DSAID FY26.pdf

1 Ver: Feb 2024

Performance Work Statement (PWS) Defense Manpower Data Center (DMDC)

Defense Sexual Assault Incident Database (DSAID)

1.0 INTRODUCTION

The Defense Manpower Data Center (DMDC) requires support services for the continued maintenance, operation, and further development for the Defense Sexual Assault Incident Database (DSAID) to impact system access, sexual assault case management, sexual assault victim care and advocacy, reporting, document management, and enhanced reporting capability.

With the ever-increasing number of requests for information and requirements from Congress and senior leaders within the DoD, DSAID must continue to deliver a high level of confidence with the data it maintains, as well as foster efficiencies in operations.

2.0 BACKGROUND

The Duncan Hunter National Defense Authorization Act (NDAA) for Fiscal Year 2009, Section 563, establishes implementation of an information database on sexual assault incidents in the armed forces. Subsection (a), Database Required, mandates that the Secretary of Defense implement a permanent, centralized, case-level database for the collection, maintenance, and reporting of information regarding sexual assaults involving a member of the Armed Forces.

Subsection (d), Reports, states the database will be used to develop and implement congressional reports and ad hoc queries.

Section 1723 of the Fiscal Year (FY) 2014 NDAA mandates the retention of the Department of Defense (DD) Form 2910, “Victim Reporting Preference Statement,” and the DD Form 2911, “DOD Sexual Assault Forensic Examination Report,” be retained for fifty years in both Restricted and Unrestricted Report cases. Department of Defense Sexual Assault Prevention and Response Office (DOD SAPRO) uses DSAID to collect and retain these forms to ensure future availability to the Department of Veterans Affairs.

Section 543 of the FY2017 NDAA mandates inclusion in the annual reports to Congress information on complaints of retaliation in connection with reports of sexual assault in the armed forces. DOD SAPRO uses DSAID to collect and report sexual assault retaliation information in the same manner as it reports sexual assault information.

Now implemented, DSAID encompasses five functional capabilities to include, reporting, data entry, data interface, case management, and business management. Reporting functionality allows DOD SAPRO the ability to electronically develop and execute congressionally mandated reporting, facilitate trend analysis, perform data validation, and respond to ad hoc requests.

Data entry and interfaces enable DSAID to receive case-level information from designated Sexual Assault Prevention and Response (SAPR) Work Force, DSAID Service Program Managers (PMs), DSAID Service Legal Officers (LOs), and/or other Service data systems. This approach allows for timely responses to departmental and congressional inquiries and alleviates

2 Ver: Feb 2024 redundant data entry and unnecessary data calls to the field. The case management functionality enables all the Military Department SARCs, National Guard SARCs, and Coast Guard SARCs to input and maintain sexual assault case data directly into DSAID. Finally, business management functionality provides administrative and oversight capability through case management reviews, meeting minutes, SARC and SAPR Victim Advocate (VA) management, and User Access permissions. The Department also uses DSAID to meet document storage requirements associated with sexual assault reports under the purview of the Sexual Assault Prevention and Response Policy.

Currently, the DSAID system is comprised of the following overarching modules: the DSAID Enhanced Reporting Capability (ERC) and the DSAID Document Management Module (DMM). Henceforth, the term DSAID includes the ERC, DMM and any of their sub-components.

3.0 SCOPE AND OBJECTIVE

3.1 SCOPE

The Contractor shall provide the personnel, management, materials, equipment and travel necessary to perform system management, further development, and support for the entire DSAID system and its components.

As requested by the Government, the Contractor shall respond to tasks related to increased functionality as a result of additional requirements to include congressional mandates; shall provide engineering support in system modernization efforts; and shall provide the necessary support and documentation to the Government to ensure information assurance requirements are met to achieve Authority to Operate (ATO) status.

Additionally, the Contractor shall maintain all current DSAID operations to include all hardware and software, development, migration, training, test and production environments, software changes/updates/maintenance, configuration/customization changes, ERC data extract transform and load (ETL) process, and help desk support. Modernization initiatives with DSAID's servers and the operating system shall be conducted with the support of the host provider. All upgrades and configuration changes to the Production system will be mirrored in each DSAID environment. Each DSAID environment will meet applicable Risk Management Framework (RMF) requirements as defined in applicable DoD regulations. Additionally, the Contractor shall provide Cloud migration support, infrastructure development, and RMF accreditation of a Test and Production environment built within an approved cloud service provider enclave.

The general scope of this requirement covers the full range of maintenance services to ensure uninterrupted service of the existing information technology (IT) systems and related software while employing technology that increases IT capabilities and improves operating efficiency.

The scope includes:

• Data management and governance services to develop, operate, and maintain the Government approved data ingest, data validation, data storage, data management, and data quality;

3 Ver: Feb 2024

• Cloud support services including all services required to migrate/transition, deploy, develop, operate, maintain, and safeguard applications;

• Development, Modernization & Enhancement (DME) support, including introduction of new or modified functionality or scope that requires the re- engineering and/or enhancement of an existing system, the re-platforming of a system to a new technical architecture, or the development of a new system.

DMDC constantly evolves to meet shifting priorities and may require completion of additional projects throughout the period of performance.

3.2 OBJECTIVE

The goals associated with this effort are efficient service delivery, responsiveness to customer requirements, flexibility to the changing environment, use of best practices in software development, high levels of customer service and satisfaction, and highly reliable, quality systems to support mission readiness and day-to-day operational support for multiple concurrent users. This performance- based order incorporates the following objectives:

• Deliver high-quality technical performance

• Adhere to order schedule, milestone, and delivery requirements

• Efficiently and effectively control labor resources

• Manage workload surges effectively and in a manner that, given mission requirements and competing priorities, efficiently schedules and applies resources to meet the needs of supported activities without one activity’s needs being given primacy over the other

• Post official DoD registries to shared spaces for operational use, as determined by the cognizant Product Owners.

• Improve and maintain DMDC standard documentation and maintenance procedures

• Improve data access and integration, data monitoring and data exchange

• Improve data quality monitoring and provide data quality trend reports

• Improve metadata capture and integrate with DMDC standard metadata tools which are, currently SPARX and Collibra.

• Ensure maintenance of DSAID utilizing the current applications (Entellitrak® and

MicroStrategy®), software patching, and server maintenance (e.g., Oracle, Tomcat, Apache, Internet Information Services, and SQL).

4.0 REQUIREMENTS

4.1 TASK 1-TRANSITION

The Contractor shall support an orderly 90-day transition-in period. Transition-In/Transition- Out, will be exercised concurrently with the mandatory labor CLINs supporting Tasks 7-10.

4.1.1 Transition Plan

The Contractor shall prepare and provide an initial transition plan. The Transition Plan shall present a methodology detailing how transition will occur from the current Contractor(s) to the new contract staff at the beginning of the contract and how transition will occur to the Government or to another Contractor at the end of the contract. The transition activities shall minimize both loss of support and cost. The Transition Plan shall address, at a minimum, the following areas:

• Transition of Program Management Support and Other Personnel

4 Ver: Feb 2024

• Transition of Task Requirements in the contract

• Asset Transfers [hardware, software, Government Furnished Property]

• Resource Requirements [personnel and budget]

• Security Clearance Actions and Status

• Transition Milestones and Timeline

• Risk Mitigation Practices

• Governance/Process/Procedures knowledge transfer for planning, architecture, acquisition, security, development lifecycle, deployment, and decommission.

The incoming and outgoing Contractors shall work together, in collaboration with the Government, to realize Transition-In and Transition-Out Plans to affect a transition that provides for smooth operational turnover and minimizes operational impact to supported organizations.

4.1.2 Transition-In

The Government is currently receiving services under an existing contract. The successful Contractor shall perform transition-in services necessary, within the timeline prescribed in PWS Section 4.1, to provide a smooth and efficient transition from the incumbent Contractor(s) without any interruption or degradation in any services.

Contractor shall:

• Develop and validate comprehensive communications and IT supported equipment list with the Government and outgoing Contractor.

• Establish procedures with the outgoing Contractor to transition operations, maintenance, and logistics functions while maintaining an uninterrupted continuity of services without a degradation of service. This includes defining processes for turnover of system administration, accounts, privileges, and access.

• Coordinate with the Government to validate or establish maintenance priorities for supported releases.

• Schedule weekly status meetings with all pertinent stakeholders for the duration of the transition period at a mutually agreed upon data and time.

NOTE: The Transition Plan will be incorporated into the contract at Government acceptance via a written modification to the contract. Therefore, the Contractor shall be required to perform and complete all transition-in activities in accordance with their Transition Plan.

4.1.3 Transition-Out

The Contractor shall perform all the services necessary to transition the work performed under this contract to the Government or another Contractor at the conclusion of this contract. The Contractor shall perform an orderly transition of work at the end of this

5 Ver: Feb 2024 contract without delays or disruptions to the daily operations of DMDC and DOD

SAPRO.

The draft plan shall be due thirty (30) days after notification or no later than ninety (90) days prior to the end of the performance period, whichever is sooner. The final plan shall be due fourteen (14) days after receipt of Government comments on the draft. The Contractor shall work with the incoming Contractor to ensure a seamless transition. In the Transition-Out Plan, the Contractor shall identify how it will coordinate with the incoming Contractor and/or Government personnel to transfer knowledge regarding the following:

• Project management processes.

• POCs.

• Location of technical and project management documentation.

• Status of ongoing technical initiatives.

• Appropriate Contractor-to-Contractor coordination to ensure a seamless transition.

• Transition of Key Personnel roles and responsibilities.

• Schedules and milestones.

• Actions required of the Government.

• Plan to establish and maintain effective communication with the incoming Contractor/Government personnel for the period of the transition.

• Inventory, inspection and transfer of IT software and hardware, licenses, and warranties.

• Inventory, inspection and transfer of all Contractor-maintained sensitive, unclassified data, equipment, and devices, ensuring positive control, accountability, and chain of custody.

• Technical artifacts and configuration baselines.

• Elevated system privileges.

• Operations, maintenance, helpdesk, engineering, and logistics functions.

• Maintenance priorities for supported equipment.

• Governance, planning, portfolio/program review, and architecture processes.

• Software Development Lifecycle (SDLC) processes.

• Security and privacy processes and protocols.

4.2 TASK 2 – PROGRAM/PROJECT MANAGEMENT

Reference Appendix A Project Management Process Handbook.

The Contractor shall provide management expertise, oversight, control, and direction in team building, communications, time management, quality assurance and quality control, procedure development, risk management, configuration management, and software integration. An Agile-based, holistic approach to project management is critical to DMDC’s mission as it provides enhanced visibility throughout the lifecycle of a project. The Contractor’s Project Managers shall have subject matter expertise in DevSecOps practices and tooling.

6 Ver: Feb 2024

4.2.1 Project Management Plan

The Contractor shall provide a Project Management Plan (PMP) that establishes the framework for project planning, scheduling, communications, and reporting following DMDC’s Project Management Process Handbook (Appendix A).

The PMP shall include:

• Task assignments

• Major milestones, to include milestone progress checks and updates

• Estimated dates, dependencies, and indications of critical path, in accordance with the Integrated Master Schedule (IMS) that outlines planned sprint schedules

• Project status

• Project statistics

• Risk and mitigation review

The PMP shall be reviewed during regularly scheduled meetings; (i.e., Weekly In- Progress Reviews (IPRs), Monthly Status Reports, Plan Review, Schedule Review, and stakeholder reporting). The PMP is a living document that evolves as the project progresses and shall be maintained with up-to-date information.

4.2.2 The Contractor shall coordinate and support integration activities for requirements, project plans and schedules, briefings, and informational documents with internal and external stakeholders for this project.

Requirements gathering and documentation must follow DMDC’s Requirements Management Business Process.

4.2.3 The Contractor shall develop, maintain, refine, and revise a project collaboration site on DMDC’s internal network (currently SharePoint) as well as external locations when required.

The DMDC internal site shall include the following items:

• Project overview documents

• A consistently updated document library that preserves document history

• Release notes

• Schedules

• Dashboards

• Test cases

• Assignments and POC lists

• Summaries and agendas for all meetings and conferences attended

The project collaboration site shall support collaborative editing/versioning of project documents.

4.2.4 The Contractor shall attend project meetings and conferences in support of the project.

Provide meeting summaries that reflect the meeting highlights, including a list of the

7 Ver: Feb 2024 issues discussed; any action items created and to whom each is assigned; and all decisions or determinations from the meeting and the decision makers for each.

This may include meetings (regular or ad-hoc) in support of Enterprise or Component activities and initiatives to :

4.2.4.1 Provide technical expertise and/or respond to customer inquiries regarding system specifications and capabilities.

4.2.4.2 Provide expertise in support of new requirements, ZeroTrust initiatives, process improvements, as requested by the Government.

4.2.5 The Contractor shall coordinate with all impacted DMDC governance bodies such as

DMDC Information Systems Security Group (DISSG), Architecture Change Management (ACM), Quality Assurance (QA), Configuration Management (CM), IT Operations, Consolidated Call Center (CCC), DMDC Division Director Council (DDC), Problem and Incident Management, Defense Human Resources Activity (DHRA), Data Governance Board and other impacted divisions for project requirements and execution.

In addition, the Contractor shall coordinate transition-in activities with Enterprise Quality Assurance (QA). Adhere to all DMDC Business Process workflows, requirements, and tool usage.

4.2.5.1 The Contractor shall provide architecture documentation and DoD Architecture

Framework (DoDAF) or SPARX artifacts in accordance/compliance with DHRA architecture modeling tools, practices, and standards to support business and program needs.

4.2.5.1.1 The Contractor shall create artifacts such as Data Viewpoint (DIV-3), System Viewpoint (SV-1), Network Viewpoint (SV-2), and other DoDAF or SPARX Viewpoints to support enterprise business and mission value.

The Contractor shall ensure all DoDAF artifacts are reviewed by Enterprise Architecture during the design phase, and whenever changes are made to the artifacts.

4.2.6 The Contractor shall provide a Work Breakdown Structure (WBS). The WBS shall:

• Define each task, identify individual responsibilities, describe output and timelines for completion, and performance standards.

• Identify final completion dates and progress milestones for tasks and provide a basis for monitoring and evaluating the Contractor’s performance.

• Provide the capability to break the scope into manageable activities, assign responsibility to deliver the project scope, and establish methods to structure the project scope into a format that improves visibility for management.

4.2.7 The Contractor shall adhere to all DMDC Business Process Re-Engineering (BPR) workflows, requirements, and tool usage. Current BPR tools include SPARX Enterprise

8 Ver: Feb 2024

Architect, Microsoft Project Server, and ServiceNow, but could change throughout the life of this task order.

4.2.8 The Contractor shall ensure the DMDC Software Development Standards Life Cycle

(SDLC) process is followed and will ensure the runbook, technical specifications and functional specifications are updated monthly or with each production release and submitted to the Government for review and approval.

4.2.9 The Contractor shall conduct comprehensive review annually of existing contract processes and procedures, identifying potential areas for improvement and recommending actionable strategies to optimize efficiency, reduce costs, and enhance overall contract performance.

4.2.9.1 The Contractor shall identify potential bottlenecks, redundant tasks, and areas of administrative burden within the contract execution.

4.2.9.2 The Contractor shall benchmark against industry best practices to identify potential areas for improvement.

4.2.9.3 The Contractor shall perform an analysis of Artificial Intelligence tools approved and in use by the DoD and recommend solutions to reduce costs and gain efficiency.

4.2.9.4 The Contractor shall submit an annual report 180 days after the beginning of each new period of performance. This shall be a detailed report outlining identified inefficiencies, categorized by impact on cost, time, and quality. Specific, actionable recommendations to address each inefficiency, including potential process changes, technology upgrades, and contract modifications and cost-benefit analysis for each proposed efficiency measure, where applicable.

4.2.9.5 DoD 508 Compliance: This defines the requirements for compliance with Section

508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), for all information and communication technology (ICT) developed, procured, maintained, or used under this contract.

4.2.9.5.1 All ICT deliverables must conform to the accessibility standards outlined in Section 508 of the Rehabilitation Act and its implementing regulations at 36 C.F.R. Part 1194, as amended. This includes:

Technical Standards: ICT deliverables must meet the technical requirements outlined in WCAG 2.0 Level AA (Web Content Accessibility Guidelines) or Section 508 standards, whichever is applicable.

9 Ver: Feb 2024

Functional Performance: ICT must be accessible to individuals with disabilities, enabling them to perceive, operate, and interact with the technology effectively. This includes providing equivalent alternatives for non-text content, ensuring keyboard accessibility, and offering options for users with visual, auditory, cognitive, and motor disabilities.

Documentation: All user manuals, training materials, and supporting documentation must be accessible to individuals with disabilities.

4.2.9.5.2 Contractor Responsibilities:

• Compliance Verification: The Contractor is responsible for ensuring that all ICT deliverables comply with Section 508 requirements. This includes conducting accessibility testing throughout the development lifecycle.

• Remediation of Issues: The Contractor must promptly remediate any accessibility issues identified during testing or reported by the DoD.

• Documentation and Reporting: The Contractor shall provide the DoD with:

o A Voluntary Product Accessibility Template (VPAT) for each ICT deliverable, documenting the product's conformance with Section 508 standards.

o Test results and remediation plans for any identified accessibility issues.

o Regular progress reports on Section 508 compliance efforts.

4.2.9.5.3 All ICT deliverables will be subject to acceptance testing by the DoD, which will include verification of Section 508 compliance.

4.2.9.5.4 The Contractor must achieve and maintain compliance with all applicable Section 508 requirements for the duration of the contract.

4.3 TASK 3 - BUSINESS AND SYSTEMS ANALYSIS

4.3.1 Analyze and evaluate current business processes, anticipating new requirements and identifying areas of improvement. Advise customers on value-added solutions to achieve program success.

4.3.1.1 Collaborate with stakeholders to formulate and communicate requirements;

prepare a Business Requirements Document (BRD) that details the solution documenting customer needs and expectations. Conduct requirements and design walkthroughs, including demonstrations or training for new functionalities or program changes, for both internal and external customers. Normally, such sessions are conducted virtually but may occasionally entail face- to-face meetings.

10 Ver: Feb 2024

4.3.1.2 Translate requirements to design modifications, maintaining the integrity of the product’s design and develop user scenarios and interfaces.

4.3.1.3 Provide business process improvement support. This includes all activities involved in helping to improve customer data systems through business processes, including rethinking program design and aligning information technology infrastructures with business missions, goals, and objectives.

4.3.1.4 Create data flow diagrams, perform data standardization, and perform enterprise modeling, functional economic analysis, simulation/modeling, activity-based costing, and activity-based management support.

4.3.1.5 Conduct requirements analysis and end-user support; develop and maintain working knowledge of applications functionality and business processes in order to address user inquiries and assist in development, design, and analysis. Using an agile approach, the Contractor shall provide input to the Government for the development of user stories, and use the Government approved user stories for software development.

4.3.1.6 Develop requirement definitions and documentation based upon stakeholder input;

provide detailed workflow/application deployment instructions sufficient to ensure successful deployment to each of the development environments.

4.3.1.7 Analyze and develop change requests (CR) for new requirements to functional capabilities and data elements. Implement changes to the system that are validated and approved by the DSAID Change Control Board (CCB) and product managers, (reference Appendix - DSAID CCB Charter). Prepare and deliver change request functional analysis reports that describe code changes, impacts, level of effort, and proposed solution(s) .

4.3.1.8 Adhere to, and meet, all of DSAIDs performance management requirements as outlined in the DSAID KPP Document (see Appendix ) and provide a monthly report. Implement procedures for addressing and correcting those areas where DSAID performance levels are not compliant.

4.3.2 Configuration Management Plan (CMP)

The Contractor shall develop and maintain a CMP for recording, tracking and reporting the configuration items (CI) for systems in development that are consistent with DMDC Standard Operating Procedures. The CMP shall address the following:

• Configuration management

• Change management

• Release management

• Problem tracking

• Configuration Management tools

11 Ver: Feb 2024

4.3.3 Downtime Management and Support

Ref: Appendix B – Incident Management Process Handbook v2.0.pdf Support shall include monitoring product helpdesk emails, providing in-depth troubleshooting, technical analysis, end users’ requests, and accounting for application support activities by creating a ticket for each activity in the Government-approved and provided tool for tracking support issues and bugs.

4.3.3.1 Provide a schedule for all planned downtime events in the IMS. Downtime shall have Government approval in advance and shall not affect performance metrics.

Notifications for unplanned outages shall be provided to DMDC customers per the Government-approved communication plan.

4.3.3.2 Provide technical support (i.e., Tier 3) for any unplanned downtime, latency, or urgent data or application issues/failures. Technical representatives shall support DMDC system recovery teams within 30 minutes, 24 x 7 x 365 and shall be available by phone or email notification. The Government anticipates an average of one event per month.

4.3.3.3 All outages in production must be resolved within 24-hours and must be reported to the DMDC PM within 1-hour of notification. All other tier 3 requirements must be resolved within 72-hours and if not resolved the Contractor shall provide a work around and the Government must approve the work around until a permanent resolution is identified.

4.3.3.4 Create and maintain knowledge base articles for all Tiers 2 and 3 support requests.

4.3.3.5 Provide statistics in the Monthly Status Report.

4.3.4 Help Desk Support

Due to the sensitive nature of the information contained within DSAID, help desk support will remain the responsibility of the Contractor.

Contractor shall

4.3.4.1 Assist DOD SAPRO team with Help Desk operations as outlined in the DSAID Help Desk Management Plan and SOP (Appendix Y).

4.3.4.2 Designate Help Desk primary and alternate points of contact. The points of contact will receive, field, answer, and resolve problems and questions related to DSAID, and redirect to other appropriate tier level support when necessary.

12 Ver: Feb 2024

4.3.4.3 Participate in Contingency TableTop Exercise, as required by the Government.

Identify any ISCP shortfalls and update ISCP, as needed. (Appendix DSAID ISCP).

4.3.4.4 Provide subject matter expert advice during Major Incidents and Service Restoration Team (SRT) meetings to restore normal service operations and service environments as quickly as possible to minimize the adverse impact and keep the Government informed of the progress.

4.3.5 Interface Management Activities.

4.3.5.1 Perform daily/weekly interface data transfers between DSAID and interfacing systems (e.g. military criminal investigation systems or eligibility reporting system) per established memorandums of understanding and interface data mapping documents (See Section 14.0).

4.3.5.2 Maintain and update interface data transfer functionalities.

4.3.5.3 Extract, transform, and load data from DSAID to the DSAID ERC module daily.

4.3.5.4 Implement enhanced and modernized data exchanges (i.e. APIs)

4.3.5.5 Generate data quality reports for internal and external users, to include system metrics on data residing in DSAID and validation checks between data in DSAID and interfaced Service systems

4.4 TASK 4 - APPLICATION DATABASE MANAGEMENT (DBMS)

4.4.1 The Contractor shall manage and organize incoming data and provide ways for the data to be modified or extracted by users or other programs. Ensure supported applications perform per specifications.

4.4.2 The Contractor shall manage database performance, data recovery and integrity;

conduct configuration and maintenance of database instances, configuration of database replication processes, account management, performance monitoring and tuning (to include query performance), service availability monitoring, and space management;

refine and improve database performance; participate in planning and execution for database recovery. Other database technology and caching solutions may be introduced.

The Contractor personnel responsible for application database management will be granted the required access to accomplish the PWS tasks described in this section.

4.4.3 The Contractor shall identify, isolate, research and resolve data quality issues; design, develop and implement data quality controls.

4.4.4 The Contractor shall provide ad hoc transaction analysis reports of external interfaces in terms of quantity and quality (error rates and types).

13 Ver: Feb 2024

4.4.5 The Contractor shall provide problem determination/analysis and isolate problems utilizing diagnostic and system management tools (i.e., system dumps and system/component traces, monitoring tools).

4.4.6 The Contractor shall maintain and create system documentation, review system documentation composed by development teams, and work with governance/architecture teams to maintain that documentation up to date.

4.4.7 The Contractor shall control migration of programs, database changes, reference data changes and menu changes through the development life cycle.

4.4.8 The Contractor shall enforce and maintain database constraints to ensure integrity of the database; administer all database objects, including tables, clusters, indexes, views, sequences, packages, and procedures.

4.4.9 The Contractor shall assist with impact analysis of changes made to the database objects; troubleshoot problems regarding the database, application, and development tools; generate routine and ad-hoc reports, and data queries, as requested by the Government. (Note: Based on historical information, the Government anticipates approximately 5-10 ad-hoc requests per month and 20-25 helpdesk requests per month.

This may increase as the number of users increase.)

4.4.10 The Contractor shall modify database structures impacted by application modernization or reengineering releases and perform database conversions and migrations that support application development.

4.5 TASK 5 – SOFTWARE SUSTAINMENT/MAINTENANCE/ENHANCEMENTS

Reference Appendix B Software Delivery Management Process Handbook, Appendix C DMDC Coding Standards, Appendix E Enterprise Architecture Minimum Viable Architecture, Appendix F DHRA Enterprise Architecture Policy.

4.5.1 The Contractor shall adhere to Appendix L - Agile Sprint Monthly Release. DMDC reserves the right to exchange priorities within the established level of effort (Appendix AC - Agile Sprint Monthly Release). The approved monthly project schedule to include items placed into JIRA will identify the approved priorities for the sprint. DMDC will determine the ultimate time frame for each sprint release, AppendixL is the basis to establish the level of effort for each application; the duration of each sprint will be driven by the approved project schedule.

4.5.2 The Contractor shall support an agile development methodology and software development lifecycle and develop the application to run in accordance with Government defined standards and frameworks (Agile Pilots Guidebook Appendix G).

14 Ver: Feb 2024

4.5.3 The Contractor shall conduct quarterly sprints to support bug fixes, emergency priority requirements, and minor enhancements to address the backlog of requirements.

The stakeholder reserves the right to exchange priorities of similar size, scope, complexity, and level of effort in accordance with the items in the backlog.

4.5.4 The Contractor shall provide all phases of software maintenance as defined in

ISO/IEC 14764 and DMDC Software Delivery Management Process Handbook (Appendix B). Potential categories are corrective maintenance, adaptive maintenance, perfective maintenance, enhancements, and preventive maintenance.

4.5.5 The Contractor shall develop and maintain a Software Maintenance Plan (SMP) that monitors the processes to be followed for sustaining applications. The SMP shall define the steps by which the development and maintenance of software shall be accomplished.

The SMP shall address software processes, methods, organizational responsibilities, tools, configuration management, software quality, and metrics. Sustainment includes addressing issues driven by routine hardware and software upgrades, correcting defects reported by users, applying new functionality and/or remediation mandated by policy and security guidelines, and associated testing. The SMP shall:

4.5.5.1 Detail methods and an approach to be followed for each activity.

4.5.5.2 Document all processes applicable to the system at a level of detail sufficient to allow the use of the plan as the full guidance for the developers.

4.5.5.3 Describe how sustainment metrics will be achieved and sustained throughout the lifecycle.

4.5.5.4 Describe in the sustainment risk areas and develop the mitigation plan.

4.5.5.5 Document the product support implementation status.

4.5.6 The Contractor shall maximize and facilitate code re-use by leveraging already existing or project specific software re-use libraries. Software development shall place emphasis on coding that is easily maintained, highly secure and compliant with DMDC coding practices. All Technical Data and its usage will adhere to DFAR Clauses 252.227-7013 and 252-227-7014. The Government will make its libraries available to the Contractor following contract award.

4.5.7 The Contractor shall provide software maintenance services, to include:

4.5.7.1 Analysis of problems,

4.5.7.2 Preparation of resource estimates and schedules to effect necessary changes, 15 Ver: Feb 2024

4.5.7.3 Design and code changes,

4.5.7.4 Conduct testing of all changes,

4.5.7.5 Complete and/or update all documentation affected by the required changes; and

4.5.7.6 Coordinate change implementation through appropriate approvals and user notifications.

4.5.8 The Contractor shall define, manage, track, and verify computer resources (hardware/software) growth; reserve capacity requirements, this includes reserve capacity for memory, throughput, input/output (I/O), and network and provide statistics in the monthly status report (MSR).

4.5.9 The Contractor shall develop and update designs, specifications, and architecture models for continuing software development and enhancements, support the implementation and ongoing maintenance of the existing components, processes, applications, and the associated knowledge bases, applications, applets, and satellite databases. Document and maintain designs and specifications on the document repository (currently SharePoint). Document and maintain architecture information in the DHRA enterprise architecture information repository (currently Sparx EA). The Contractor shall document all enhancements in the current DMDC issue tracking tool

(JIRA).

4.5.10 The Contractor shall maintain, operate, and enhance all hardware and software components necessary to ensure DSAID remains operational. This includes Entellitrak customized COTS functionality with the DMM), MicroStrategy based ERC, single sing on (SSO) capability, and server components (e.g. Tomcat, Apache, Internet Information Services, and SQL).

4.5.11 Execute and implement functional changes. The Contractor is responsible for reviewing and approving requirements (DSAID Requirements Package) for technical feasibility. DSAID capabilities will be made only for approved Change Requests (CRs).

Changes and/or additions to the capabilities, as a result of collaborative review between the Contractor and the Government. The Government must approve all changes prior to implementation.

4.5.12 The Contractor shall integrate new application architectures; improve application and tool quality and performance; and add, modify and delete functionality based on customer approved requirements.

4.5.13 The Contractor shall monitor, evaluate, and recommend technologies and improvements to the architecture, development processes and tools.

16 Ver: Feb 2024

4.5.14 The Contractor shall maintain a software release plan and ensure software release planning is performed and documented within seven (7) calendar-days prior to the start of Sprint 1 of a release; and report progress against the project plan. The Contractor’s software release plan shall encompass all the software development activities in support of the releases. The Contractor shall have deployments for functionality and maintenance.

4.5.15 The Contractor shall test and approve program release dependencies in the Change

Management System (CMS) within seven calendar-days prior to release to production date according to the program project schedule. Collaborate with Technical Services to submit change requests and follow DMDC production release procedures.

4.5.16 The Contractor shall conduct a daily scrum to synchronize activities, inspect the work since the last scrum, and forecast the work for the next 24 hours.

4.5.17 The Contractor shall develop and execute a software functional testing strategy that utilizes DevSecOps principles in the Quality Assurance process when automated testing of the application can be accomplished (see Appendix I- Agile Software Testing). This strategy must address application or system use cases, user interfaces, security considerations, and reports using test data designed to demonstrate compliance with all documented functional specifications for each release.

4.5.17.1 After test execution, the Contractor shall produce a testing report, generated using DMDC approved tools for each software package, that outlines the outcome for each test case and provides assurance that all use cases and requirements are appropriately covered (see Appendix O- Agile Software Testing).

4.5.17.2 Contractor shall:

• Conduct three (3) code reviews: the first at 50% code complete, the second

75% code complete and a final review with 90% accepted as being complete.

• Perform QA in an agile fashion to ensure all releases are on time every time.

• Provide reports of findings that include recommended mitigation actions as well as risk mitigation and acceptance recommendations based on analyses of reports produced.

• Deliver all software components including source code with release notes to include all updated technical specifications, functional specifications and run books.

4.5.18 The Contractor shall develop and maintain the following agile artifacts:

• User Stories and Use Cases

• Product Backlog

• Sprint Backlog

• Product Burn-down Charts

17 Ver: Feb 2024

• Release Burn-down Charts

4.5.19 Document and follow the DMDC Configuration Management process, (Appendix D

– Configuration Management Process Handbook), and provide a configuration summary report in the monthly status report.

4.5.20 Document and follow DMDC’s established Information Technology Infrastructure

Library (ITIL) Release Management process for performing package releases to the infrastructure.

4.5.21 The Contractor shall perform Unit Testing, which is an independent validation and verification that ensures developed software meets and complies with defined or standardized quality specifications. Unit Testing is an ongoing process within the software development lifecycle. Unit testing shall be accomplished jointly with the QA team.

4.5.22 The Contractor shall participate in discussions and recommend additional license solutions to meet DSAID program needs.

4.6 TASK 6 QUALITY ASSURANCE (QA)

The Contractor shall adhere to Appendix AE - QA Automation. Reference Appendix H Service Validation and Testing Handbook, Appendix J Agile Software Testing and Appendix K - Service Validation and Testing Handbook.

4.6.1 The Contractor shall provide the following:

4.6.1.1 Functions as defined in Appendix B – Software Delivery Management Process Handbook

4.6.1.2 Automate functional testing and incorporate testing functions within a

DevSecOps Continuous Deployment Pipeline. The scope includes ensuring that the deliverables are architected for optimal use of the Continuous Integration and Continuous Delivery services made available at DMDC.

4.6.1.2.1 The scope does not include maintaining the automation framework and

DevSecOps Jenkins pipeline.

4.6.1.3 Create test cases following agile methodologies (see Appendix O – Agile Software Testing)

4.6.2 Testing and Validation

The Contractor shall perform testing and validation in accordance with Appendix K - Service Validation and Testing Handbook

18 Ver: Feb 2024

4.6.2.1 Verify software requirements and capture issues arising from testing in a Software

Trouble Report (STR Template, Appendix X).

4.6.2.2 Resolve issues and/or defects (security issues, adverse accreditation risks, data inaccuracies, etc.) prior to release to the Government for acceptance and/or identified during the Government’s UAT or ad hoc testing.

Criteria for accepting the system for delivery to the production environment: will be based on the following criteria:

• The system has no severity levels of 1, 2, or 3 issues.

• All core test scenarios are executed and passed.

• STRs and discrepancies are documented, resolved, verified, or designated by the Government as future changes. A final version of the STR documenting the Governments approved severity and priority assigned must be submitted.

4.6.2.3 All application testing must be automated as part of the software development process. Exceptions may only be considered when automation is not possible as per Appendix O – Agile Software Testing. The Contractor shall use both the Integrated Development Environment (DEVINT) and quality assurance test (QATST) environment for QA test case execution, as directed by the Government.

4.6.2.4 Automation shall be performed using technologies and tools provided or approved by DMDC. DMDC’s Automation Framework and Test Case Management System are maintained and supported by DMDC. The Contractor is not responsible for maintaining these systems.

4.6.2.4.1 The Contractor shall self-report using the DMDC Test Case

Management System (Currently SharePoint).

4.6.2.4.2 The Contractor shall use DMDC-approved testing frameworks to complete automation.

4.6.2.5 At award, all test cases may not be automated or integrated into the QA

DevSecOps pipeline. The Contractor shall assess the current state of automation to provide an estimate for automation completion and integration into DevSecOps pipeline. The Contractor shall provide a project plan to be accepted by the Government. All existing non-automated tests contained in the backlog shall be automated per accepted plan.

4.6.2.6 Automated test cases must be executable by the end of each Agile sprint.

19 Ver: Feb 2024

4.6.2.6.1 Automated test cases must be executable by the end of each Agile sprint.

4.6.2.7 The Contractor shall perform Test Driven Development (TDD) also known as Test-First Development in the delivery of functional capabilities of the system.

4.6.2.8 The Contractor shall conduct unit testing to verify that all components of the application perform as expected. Unit testing consists of testing specific modules of source code to validate correctness of methods and algorithms, implementation and maintenance of coding standards, verification of business functionality, and measurement of code coverage and code quality. Unit testing shall start in the development environment and shall pass analysis scans which measure the code coverage and quality of tests generated prior to the application being authorized for promotion.

4.6.2.9 The Contractor shall maintain the state of all test cases, test data, and outcomes of testing within the DMDC provided test case management solution. Test activities and outcomes must be documented within the project management system used to facilitate the Agile development process.

4.6.3 Verification & Validation Functional Testing:

4.6.3.1 The Contractor shall develop test cases and automation for those test cases while actively engaged with each development cycle (i.e. Sprint).

4.6.3.2 Quality assurance personnel (software development engineers in test - SDETs) must work closely with application developers to gain a clear understanding of the changes being implemented.

4.6.3.2.1 At the end of each development cycle, there must be complete coverage of the requirements as defined in the release plan and documented within the Requirements Traceability Matrix (RTM).

4.6.3.2.2 Automated tests must be incorporated into existing DevSecOps pipelines prior to a release being authorized for deployment to an end-user environment.

4.6.3.3 The developer of the functionality shall NOT be the same person who performs software verification and validation.

4.6.3.4 The Contractor shall take an “Automation First” approach to QA. All QA shall be automated. Manual QA activities are not permissible without explicit written approval from the DMDC Product Manager.

20 Ver: Feb 2024

4.6.3.4.1 Automated test cases shall be an outcome of each release iteration. The Contractor shall provide a valid justification for any non-automated test case.

4.6.4 User Acceptance Testing (UAT)

4.6.4.1 Coordinate User Acceptance Testing (UAT) with external partners as needed (the Government anticipates this occurring once per year).

4.6.4.2 Document errors and results in UAT environments.

4.6.4.3 Examine reports and test results to determine the readiness of new or modified system’s code and/or database changes/additions to be released into the production environment. After the UAT team tests any corrections made by the Contractor, the Government will examine the test results and make a determination as to the readiness of the new or modified system’s code and/or database changes/additions to be released into the production environment. The Government will certify the planned release under one of the following categories:

• It is virtually error free and should be released into production.

• Errors that exist will be addressed and a decision could be made that either:

o Release can proceed intact, and the errors corrected and implemented through a subsequent release, or o Proceed with release and portions determined defective shall be removed, errors corrected and implemented through a subsequent release.

4.6.4.4 The release has a major shortcoming. The Contractor shall NOT proceed with the release. The Contractor shall correct and re-test the release.

4.6.4.5 Maintain the user acceptance testing environment. All changes shall pass the appropriate testing in this facility prior to moving into staging and production. The functions shall include testing, tracking of potential defects and bugs, and performing reviews of the system and its components.

4.6.5 Technical Training Environment Support Activities

4.6.5.1 Maintain and operate a DSAID training environment that mirrors the DSAID production environment. Update the training environment to reflect new changes within two business days of a new release to the production environment. Deploy approved application upgrades and software patches to training environment.

21 Ver: Feb 2024

4.6.5.2 Prepare the training environment with training data, on-call support, and ensure environment is available for use for DOD SAPRO led training sessions. The Government will provide training data (e.g. number of cases and the associated locations). The Contractor shall work with local network owners to facilitate access to training environment. Ensure the training environment can be used by a minimum of 50 users simultaneously. (Note, the number of users may grow during the life of this order.)

4.6.5.3 The Contractor shall provide qualified technical Subject Matter Experts (SMEs) to assist in the training curriculum development process as applicable. For ERC, the Contractor shall provide data schema and description of schema level objects to include attributes and metrics.

4.6.5.4 Set up demonstration environment, seed data for DSAID demonstration(s), and present system functionalities in fulfillment of a request from Congress, GAO, DoDIG, DoD leadership or other Government entities.

4.7 TASK 7 - SUBMIT REPORTS AND DOCUMENTATION

4.7.1 Monthly Status Report (MSR)

The Contractor shall provide monthly status reports to track project status, issues, and progress.

The Contractor shall submit the MSR to DMDC SharePoint for the previous month’s performance and present the information during a monthly briefing to DMDC leadership. The Contractor shall submit the MSR to DMDC SharePoint via a Post Award Collaboration, identifying the DMDC COR and Project Manager (PM) as the “Responsible Persons”, by the 15th of each month, in coordination with the monthly invoice. For the monthly briefing, the Contractor shall prepare an agenda and meeting minutes in a clear, concise, and orderly manner. Briefing materials shall be made available to all attendees prior to time of briefing.

The report shall include data of sufficient detail to monitor the completion of deliverables and work products against progress as documented in the PWS and monitor Contractor performance against the Acceptable Quality Levels identified in the PWS. The Contractor shall include the following information in the MSR:

● Activities during the reporting period, by task (include ongoing activities, new…