Delivery of Automated Systems for Healthcare (DASH) Program

Consolidated Deliverables Management List (CDML)

ATTM 011

Consolidated Deliverables Management List (CDML)

V.15.0

Table of Contents

1. INTRODUCTION

2. PROJECT DELIVERABLES

2.1. D-001 – VENDOR STAFF MANAGEMENT PLAN

2.2. D-002 – QUALITY ASSURANCE MANAGEMENT PLAN

2.3. D-003 – CONFIGURATION MANAGEMENT PLAN

2.4. D-004 – DEVELOPMENT METHODOLOGY DOCUMENT

2.5. D-005 – REQUIREMENTS TRACEABILITY MATRIX (RTM)

2.6. D-006 – FUNCTIONAL DESIGN SPECIFICATION (FDS)

2.7. D-007 – TECHNICAL DESIGN SPECIFICATION (TDS)

2.8. D-008 – INTERFACE CONTROL DOCUMENT

2.9. D-009 – DATA ANALYTICS SPECIFICATION

2.10. D-010 – RELEASE MANAGEMENT PLAN

2.11. D-011 – DEPLOYMENT PLAN

2.12. D-012 – SYSTEM ADMINISTRATION DOCUMENT

2.13. D-013 – USER MANUAL

2.14. D-014 – SYSTEM INTEGRATION TEST PLAN

2.15. D-015 – SYSTEM INTEGRATION TEST SUMMARY REPORT

2.16. D-016 – ACCESSIBILITY TEST SUMMARY REPORT

2.17. D-017 – END-TO-END INTEGRATION TEST PLAN

2.18. D-018 – END-TO-END TEST SUMMARY REPORT

2.19. D-019 – PERFORMANCE TEST PLAN

2.20. D-020 – PERFORMANCE TEST SUMMARY REPORT

2.21. D-021 – USER ACCEPTANCE TEST (UAT) SUPPORT PLAN

2.22. D-022 – OPERATIONS AND MAINTENANCE (O&M) PLAN

2.23. D-023 – HELP DESK PLAN

2.24. D-024 – DATA CONVERSION PLAN

2.25. D-025 – DATA CONVERSION MAPPING RULES

2.26. D-026 – DATA CONVERSION VALIDATION SCRIPTS AND TEST RESULTS REPORT

2.27. D-027 – FINAL DATA CONVERSION REPORT

2.28. D-028 – VENDOR TRAINING PLAN

2.29. D-029 – TRAINING MATERIALS

2.30. D-030 – TRAINING DELIVERY

2.31. D-031 – TURNOVER PLAN

2.32. D-032 – VENDOR FEDERAL CERTIFICATION PLAN

3. OFFICE OF CYBERSECURITY (OCS) DELIVERABLES

3.1. D-033 – SYSTEM SECURITY AND PRIVACY PLAN (SSPP)

3.2. D-034 – INFORMATION SECURITY RISK ASSESSMENT (ISRA)

3.3. D-035 – PRIVACY IMPACT ASSESSMENT (PIA)

3.4. D-036 – DISASTER RECOVERY AND BUSINESS CONTINUITY (DR/BC) PLAN

3.5. D-037 – SYSTEM DESIGN DOCUMENT

3.6. D-038 – AUDIT/ASSESSMENT/TESTING RESULTS AND PLAN OF ACTION & MILESTONES

V.15.0 Page 1

1. Introduction The South Carolina Department of Health and Human Services (SCDHHS) defines a deliverable as a quantifiable good or service that will be provided during the Project Lifecycle. The following deliverables are included as part of the Consolidated Deliverables Management List (CDML) applicable to SCDHHS vendors for system implementation projects. The deliverables listed herein are the expected minimum list for SCDHHS Vendor contracts.

Unless otherwise specified within the individual deliverable, any updates to a deliverable after the initial submission and SCDHHS’ approval will be communicated minimally on an annual basis.

The Delivery of Automated Systems for Healthcare (DASH) program is responsible for the successful planning and implementation of the various modular Medicaid components that together comprise the enterprise Medicaid Management Information System (MMIS). DASH has established project management standards, plans, and controls to be used as a framework for management of these projects.

Project-based deliverables are documented, monitored, measured, and reported via the SCDHHS defined project management processes. Deliverables identified in “Section 2 – Project Deliverables” are submitted to the DASH (Delivery of Automated Systems for Healthcare) program using DASH approved formats/templates. Deliverables identified in Section 3 - Office of Cybersecurity (OCS) Deliverables are delivered to OCS using OCS approved formats/templates.

V.15.0 Page 2

2. Project Deliverables

2.1. D-001 – Vendor Staff Management Plan

Delivery Provision Due per approved project schedule no later than the end of the Initiate- Planning Phase

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The purpose of the Vendor Staff Management Plan is to outline the vendor’s staff management approach, methodology and the tools used to define, manage, verify, monitor, control, and report staff-related components of the project.

Expected Deliverable Content

The Vendor Staff Management Plan shall describe:

• How project personnel are estimated, obtained, managed, retained, and eventually offboarded

• Planning and estimating processes to identify the necessary vendor roles needed

• Management of staff turnover and retention, including contingency plans for replacing a subcontractor

• Transition planning for key roles, including the approval process for any changes to key roles

• Vendor organizational information, including an organizational chart for the project

• A staffing plan that identifies the staffing levels required for the duration of the contract:

o A list of all labor resources identifying each person who will be assigned, including any subcontractors o The roles and responsibilities of all staffing resources o The number of dedicated full-time employees and the percentage of each staffing resource’s time needed in each phase o Estimated hours per resource. Specify how long each resource will be needed for each phase of the project o Definition of skills needed for each staffing resource o Matrix of necessary skills/roles for each resource

• Vendor expectations for SCDHHS resources with required skill sets and specified durations for project activities

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and

V.15.0 Page 3 high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.2. D-002 – Quality Assurance Management Plan

Delivery Provision Due per approved project schedule no later than the end of the Initiate- Planning Phase

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Quality Assurance Management Plan details the approach, method, processes, activities, and any tools that the vendor will use to independently examine, review, and assess project delivery processes.

This plan shall describe the approach to measuring the quality of work being performed, assessing compliance, and incorporating continuous improvement across the project delivery area.

Quality Control (QC) activities will be described in the appropriate test plans and not in the Quality Assurance Management Plan.

Expected Deliverable Content

The Quality Assurance Management Plan shall describe the following:

• Quality Assurance Approach defining the approach that will be used to manage quality assurance across the project, the required planning to implement the approach, and the applicable quality standards utilized in the approach

• Roles and Responsibilities identifying the resources and their responsibilities for this plan to support Quality Assurance activities across the project

• Activities the vendor will complete to ensure a quality deliverable such as management actions, quality reviews, quality audits, corrective actions, etc.

• Systems and Tools describing what applications, repositories, and tools will be used on the project to support QA activities

• Metrics describing how, throughout the life of the project, the vendor will collect measurements and analyze quantifiable data to ensure QA practices are enforced

• Reporting describing the report layouts and outputs that will be generated from QA activities

• A defined, documented, repeatable, and measurable process to ensure successful quality management of subcontractor work

Deliverable Format The deliverable shall be created using MS Office products, with

V.15.0 Page 4 high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.3. D-003 – Configuration Management Plan

Delivery Provision Due per approved project schedule no later than the end of the Initiate- Planning Phase

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Configuration Management Plan details the artifacts and solution components that will be placed under configuration management, the activities that will be performed as part of configuration management, and the configuration management tools.

Expected Deliverable Content

The Configuration Management Plan shall contain the following:

• Configuration Management approach and processes explaining the methodology for identifying and controlling the functional and physical design characteristics of configurable items throughout the software development life cycle (SDLC).

Including:

o List of all functional and physical items (configuration items) included in the scope of configuration management, which includes hardware, software, and design o Method and procedure for controlling changes to configuration items o Configuration management activities that include a description of when activities will be performed and scheduled to support key project dates and milestones o Method for ensuring that control will be maintained over design, development, production, installation, and support configuration items o Method for ensuring that Vendor inspections demonstrate acceptability to SCDHHS o Evidence of a disciplined integrated systems development approach

• Roles and Responsibilities identifying the organizations that will participate in configuration management and describing who is responsible for performing the various activities described in the plan, the primary activities they will be responsible for, and the authority they have over the activities

• Systems and Tools describing the environments, infrastructure, and software tools used to accomplish configuration management

V.15.0 Page 5

• Metrics and Reporting describing how the vendor will collect measurements and analyze quantifiable data to ensure configuration management is being enforced as well as defining reports and outputs stemming from the Configuration Management activities

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.4. D-004 – Development Methodology Document

Delivery Provision Due per approved project schedule no later than the end of the Initiate- Planning Phase

This document is subject to vendor review and update when the vendor development methodology changes or as requested by SCDHHS

Description The Development Methodology Document describes the approach, tools, and processes used to implement and manage software for the proposed solution. This document must address the processes and standards used to plan, validate, execute, and monitor development activities and define the development infrastructure

Expected Deliverable Content

The Development Methodology Document must address the following:

• Development Approach o Development Methodology/Lifecycle o Development, Testing, and Deployment Tools o Development and Testing Standards o Code Management o Code Review Process o Development Estimation Model o Development Reports and Metrics

• Development Constraints/Dependencies

• Development Roles and Responsibilities

• Hosting o Cloud vs. Datacenter o Dedicated vs. Shared Tenancy

• Software Framework(s)

V.15.0 Page 6

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.5. D-005 – Requirements Traceability Matrix (RTM)

Delivery Provision Required per Project Release as defined in the approved project schedule at the following points:

• Requirements Phase complete

• Design Phase complete

• Test Phase complete

Description The RTM provides a snapshot of requirement traceability as it is developed during the Project SDLC. The DASH requirements repository, DevOps, is the source of truth for project requirements and traceability to downstream artifacts. Data extracts from DASH shall be used to generate the RTM.

Expected Deliverable Content

Refer to DASH RTM Template in the Requirements Management Plan.

RTM shall include individual tabs for:

• Cover Page with Version History

• Requirement Extract

• Design/Component Extract

• Test Case Extract

• Defect Extract

• Validations for unlinked requirements

• Requirement-driven traceability view

• Design/Component-driven traceability view

• Test case-driven traceability view

• Additional tabs as agreed upon for non-functional requirements

• Reference tab to define public RTM queries

Deliverable Format The deliverable shall be created using MS Office Excel.

2.6. D-006 – Functional Design Specification (FDS)

Delivery Provision Deliverable format must be approved prior to the start of the Design Phase

Due per approved project schedule no later than the end of the Design Phase

V.15.0 Page 7

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The FDS describes the intended capabilities, appearance, and end-user interactions of the business solution for an audience of business stakeholders. The FDS must define how the solution addresses approved requirements to support downstream SDLC activities.

Expected Deliverable Content

The Functional Design Specification shall include details of the business solution, without duplicating content defined in other deliverables. The FDS shall include:

• Business Process Overview

• Requirements o Functional Requirements o Non-Functional Requirements

• Design Constraints/External Dependencies

• Scope o In Scope o Out of Scope

• Use Cases and Business Rules

• Business Process Model o Process Workflow o Information Flow Diagram o Software Component Diagram (including UI wireframes/UX)

• Security o User roles and privileges o Field-level security

• Component Traceability o Mapping to solution components to support lifecycle management and Federal Certification

• Supporting Documentation (pointers to prevent duplication) o Interface Control Document – interface transaction details o Data Analytics Specification – data reporting for downstream business entities o Technical Design Specification – technical implementation details

Deliverable Format The deliverable shall be created using MS Office products, with high-level diagrams shall utilize Excel and Visio.

V.15.0 Page 8

2.7. D-007 – Technical Design Specification (TDS)

Delivery Provision Deliverable format must be approved prior to the start of the Design Phase

Due per approved project schedule no later than the end of the Design Phase

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The Technical Design Specification describes the solution architecture that will implement the functional design for an audience of technical resources.

Expected Deliverable Content

The Technical Design Specification shall include details of the solution architecture, without duplicating content defined in other deliverables.

The TDS shall include:

• Technical requirements not addressed elsewhere

• Technical Approach o Technical Assumptions/Dependencies o In Scope o Out of Scope

• Deployment Model o Breakdown of implementation phases o Phased component delivery

• Solution Architecture o Predefined architecture

• Vendor-controlled Solution Configuration

• User Interface

• Rules Processing Engine

• Reporting Engine

• Document Storage Engine

• Component Diagrams

• Error Feedback o Customized architecture

• Design Details

• User Experience

• Automated Processes

• Error Feedback

• Security o Identity and Access Management

V.15.0 Page 9 o Data Protection

• Component Traceability o Mapping to technical and policy documentation to support lifecycle management and Federal Certification

• Technical References (pointers to prevent duplication) o Interface Control Document - data format and protocol for interchange between systems o Data Analytics Specification - exportable/reportable data o Disaster Recovery and Business Continuity - physical topology o System Administration Document - user-controlled configuration o External Application Documentation - affected applications in the ecosystem

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio.

2.8. D-008 – Interface Control Document

Delivery Provision Deliverable format must be approved prior to the start of the Design Phase

Due per approved project schedule no later than the end of Design Phase

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The Interface Control Document provides a description of the transactional Interfaces of the solution.

Expected Deliverable Content

The Interface Control Document shall fully enumerate all public and private interface definitions related to data interchange for the solution Preference is given toward real-time Open-API Compliant interfaces that conform to a standardized schema, as well as file-driven interfaces that can be scheduled for daily or monthly interchange as required by HIPAA compliance e.g., X12 transactions.

For each interface definition, the vendor shall include:

• Full details of the schema, sequence, format, protocol, endpoint, and frequency of data exchange

• Detailed descriptions of all elements contained in the interface definitions, including any field-level constraints and any

V.15.0 Page 10 necessary dereferencing information for encoded or enumerated content

• Descriptions of error stream processing and any out-of-band notification processes on success or failure

• Definition of authentication and authorization processes, with references to maintaining credentials in the System Administration Document

• Details of how each interface protects data in transit

• Concurrency and constraints such as quota or threshold limits and timeframes for data exchange

• Auditing and compliance conformity and information accountability

Delivery Provision The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio.

2.9. D-009 – Data Analytics Specification

Delivery Provision Deliverable format must be approved prior to the start of the Design Phase

Due per approved project schedule no later than the end of the Design Phase

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description A Data Analytics Specification document is required when a solution is required to generate exportable datasets or establish connections to a data visualization or analytics engine.

Expected Deliverable Content

• Schema definition of the exportable data sets or data sets visible from external connections that can be ingested into analytics engine

• Reference documentation that includes appropriate dereferencing information for all internal codes or enumerations

• Details of the external connection configuration or process required to generate exportable datasets

Deliverable Format The deliverable shall be created using MS Office products, with

V.15.0 Page 11

2.10. D-010 – Release Management Plan

Delivery Provision Due per approved project schedule no later than the end of the Design Phase

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Release Management Plan outlines the release cadence and overall internal lifecycle of application development within the target project/product. The plan shall establish a common vocabulary of release management terms between the vendor and SCDHHS.

Expected Deliverable Content

The Release Management Plan outlines the general code management strategies and tools that the vendor uses for release management, as well as an outline of the release template that includes manual and automated activities, i.e., a release management checklist.

The plan includes metrics that will be reported throughout the project release lifecycle, including:

• Success criteria – what constitutes a successful release?

• Usage of build and test environments, including CI/CD and the interrelated assets and service components – have all components been verified for compatibility and integrity?

• Internal traceability to components and defects – which components are deployed in this release, and what defects are being addressed?

• Governance compliance – does the current release meet security and other non-functional requirements, including deployment windows and rollback contingency?

Finally, it provides reference to the release notes distribution model for both historical and future implementations in at least one of the following forms, or an equivalent distribution model:

• Links to publicly accessible web pages

• Privately accessible web pages with instructions on obtaining credentials to access content

• Distribution e-mail subscription

• Newsfeed (ATOM, RSS) subscription links

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

V.15.0 Page 12

2.11. D-011 – Deployment Plan

Delivery Provision Due per approved project schedule

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Deployment Plan describes the vendor’s approach and processes required to install, deploy, and transition the solution to Production.

The Plan will encompass all aspects of deployment including the activities required to communicate with and support stakeholders, support SCDHHS in successfully preparing the deployment, deploy the solution, and support users at the time the applications are deployed so that there is the least amount of disruption to daily operations. The deliverable will contain a detailed plan for all deployment steps, procedures, data preparation, hardware and software installations, transition to operations, and a detailed sequence of events necessary to implement the solution.

Expected Deliverable Content

The Deployment Plan shall describe the following:

• The approach, processes, and required activities to execute the installation, deployment, and transition to Production of the solution

• Pre-Cutover activities encompassing the coordination of all testing, validation, data conversion, creation of install and configuration scripts, outreach, and training activities

• Contingency/rollback plans

• Readiness assessments and readiness checklists outlining the process for verification of results, signoffs, and validations necessary to approve the deployment including Go/No-Go Criteria to ensure a successful deployment

• Post cutover activities encompassing incident management/help desk, deployment support (e.g., command center, war room), onsite support, system operations, system performance monitoring, and data cleanup

• Communication/Outreach activities and coordination with all stakeholders to ensure engagement during deployment

• Detailed deployment schedule including Task Description, Start Date/Time, End Date/Time, Estimated Work and Duration, Responsible Person, Dependencies, and Milestones

• Roles and Responsibilities identifying the resources and their responsibilities to support deployment

• Systems and tools describing the applications, repositories, and tools that will be used on the project to support deployment

V.15.0 Page 13

• Metrics defining the measures used to confirm deployment goals are being met

• Deployment Report detailing the results of the deployment including completed tasks, detailed results, verification of deployment requirements, description of lessons learned, tracking and reporting procedures for each phase of the deployment, and post deployment follow-up items

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.12. D-012 – System Administration Document

Delivery Provision Due per approved project schedule with draft document available prior to UAT training and Final revisions prior to deployment training

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The System Administration Document provides technical administration and support details about the Solution for an audience of system administrators and operations support staff.

Expected Deliverable Content

The System Administration Document shall document the steps required to perform all agency-driven technical administrative tasks, including:

• User provisioning and privilege management

• License management

• Admin-controlled system configuration

• Update and maintenance processes

• Auditing

• Troubleshooting

• Communication with support channels

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and

V.15.0 Page 14

2.13. D-013 – User Manual

Delivery Provision Deliverable format must be approved prior to submission of deliverable

Due per approved project schedule with draft manual available prior to UAT training and Final revisions prior to deployment training

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The User Manual explains the functionality of the Solution in language that can be understood by a non-technical user of the software.

Expected Deliverable Content

The User Manual will include:

• Functionality supported by the Solution, such as, accessing the functions, security features, and detailed explanations of the screens and functions

• Table of Contents, Glossary of Terms, Warning Messages, and Error Messages

• Description of User Roles and the functionality assigned to each role so that a user can clearly identify what their role is in the Solution

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio.

2.14. D-014 – System Integration Test Plan

Delivery Provision Minimum of one submission prior to the start of Test Phase as defined in approved project schedule

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The System Integration Test (SIT) Plan provides a comprehensive description of Vendor testing approach, process, tools, resources, and outputs.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Approach o Test Planning o Test Estimation Model o Test Cycles

V.15.0 Page 15 o Test Scenario Definition o Test Case Development o Test Case Review o Traceability o Configuration Management

• Test Scope o Components Tested

• High Priority Components

• Components that Must be Tested Together

• Interfaces/Third Party o Items Not Tested

• Test Inputs o Prior test phase defects o Requirements o Designs/Use Cases o Components

• Test Outputs o Completed SIT Scenarios/Test Cases o SIT Defects o SIT Summary Report o Accessibility Test Summary Report

• Test Entrance/Exit Criteria

• Test Resources o Test Team

• Roles and Responsibilities o Test Tools o Test Environments

• Environment Maintenance

• Data Volume/Quality

• Batch/Interface Management o Test Data Management

• Security Protocols

• Data Preparation

• Test Bed Backup/Restore

• Test Execution o Test Case Execution

• Test Case Workflow

V.15.0 Page 16

• Pass/Fail Criteria

• Execution Considerations

• Suspension/Resumption

• Risks/Mitigation o Defect Management

• Defect Resolution

• Defect Retest/Regression o Communication

• Test Strategy Meeting

• Test Checkpoint Meeting o Metrics

• Test Pass Rate

• Test Case Status

• Defect Status

• Defect Aging

• Unlinked Test Items

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.15. D-015 – System Integration Test Summary Report

Delivery Provision Minimum of one submission per SIT execution as defined in approved project schedule

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The System Integration Test (SIT) Summary Report describes the test outcome and results of Vendor testing.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Summary o Test Phase o Execution Timeframe o Test Environment o Manual Test Cases Summary o Automation Summary

V.15.0 Page 17 o Defect Summary o Test Coverage Summary

• Test Process Variances

• Items Excluded from Testing

• Test Phase RTM

Deliverable Format The deliverable shall be created using MS Word. The RTM attachment shall utilize Excel.

2.16. D-016 – Accessibility Test Summary Report

Delivery Provision Minimum of one submission per SIT/Accessibility Test execution as defined in approved project schedule

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The Accessibility Test Summary Report describes the test outcome and results of Vendor Section 508 testing.

Section 508 Accessibility testing is required by federal agencies, and vendors doing business with federal agencies, to create, buy, and use Information and Communication Technology (ICT) that is accessible to people with disabilities.

Accessibility testing is required to ensure that an organization validates their digital content's compliance or conformance to the Web Content Accessibility Guidelines (WCAG).

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Summary o Test Phase/Cycle o Execution Timeframe o Test Environment o Applicable Standards/Guidelines o Application/Configuration o Accessibility Tools o Test Case/Evaluation Method

• Manual Summary

• Automation Summary o Defect Summary o Test Coverage Summary

V.15.0 Page 18

• Test Process Variances

• Items Excluded from Testing

• Test Phase RTM

• Accessibility Tool-specific Output/Visuals

Deliverable Format The deliverable shall be created using MS Word. The RTM attachment shall utilize Excel.

2.17. D-017 – End-to-End Integration Test Plan

Delivery Provision Minimum of one submission prior to the start of End-to-End (E2E) Integration Test Phase as defined in approved project schedule

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The E2E Integration Test Plan describes the full scope of Vendor integration testing to demonstrate application readiness for User Acceptance Test. Scope for E2E testing must include robust testing of business transactions that span the full breadth and depth of the solution to exercise all relevant applications, interfaces, user types, and data conditions.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Approach o Test Planning o Test Estimation Model o Test Cycles o Test Scenario Definition o Test Case Development o Test Case Review o Traceability o Configuration Management

• Test Scope o Components Tested

• High Priority Components

• Components that Must be Tested Together

• Interfaces/Third Party

• Downstream Application Integration

V.15.0 Page 19 o Items Not Tested

• Test Inputs o Prior test phase defects o Requirements o Designs/Use Cases o Components

• Test Outputs o Completed E2E Scenarios/Test Cases o E2E Defects o E2E Summary Report

• Test Entrance/Exit Criteria

• Test Resources o Test Team

• Roles and Responsibilities o Test Tools o Test Environments

• Environment Maintenance

• Data Volume/Quality

• Batch/Interface Management o Test Data Management

• Security Protocols

• Data Preparation

• Test Bed Backup/Restore

• Test Execution o Test Case Execution

• Test Case Workflow

• Pass/Fail Criteria

• Execution Considerations

• Suspension/Resumption

• Risks/Mitigation o Defect Management

• Defect Resolution

• Defect Retest/Regression o Communication

• Test Strategy Meeting

• Test Checkpoint Meeting o Metrics

• Test Pass Rate

V.15.0 Page 20

• Test Case Status

• Defect Status

• Defect Aging

• Unlinked Test Items

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.18. D-018 – End-to-End Test Summary Report

Delivery Provision Minimum of one submission at the end of the E2E Test Phase as defined in approved project schedule

Description The End-to-End (E2E) Test Summary Report describes the test outcome and results of Vendor testing.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Summary o Test Phase o Execution Timeframe o Test Environment o Manual Test Cases Summary o Automation Summary o Defect Summary o Test Coverage Summary

• Test Process Variances

• Items Excluded from Testing

• Test Phase RTM

Deliverable Format The deliverable shall be created using MS Word. The RTM attachment shall utilize Excel.

2.19. D-019 – Performance Test Plan

Delivery Provision Minimum of one submission prior to the start of E2E/Performance Test Phase as defined in approved project schedule

V.15.0 Page 21

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The Performance Test Plan describes Vendor technical validation activities to demonstrate adherence to Performance requirements, targets, and Service Level Agreements (SLAs). Scope for Performance testing must include Load and Stress testing of critical and high-volume transactions defined in collaboration with SCDHHS to analyze system response and behavior.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Approach o Test Planning o Test Estimation Model o Test Cycles o Test Case Development o Test Case Review o Traceability o Configuration Management

• Test Scope o Transactions Tested o Scalability/Load Factor o Interfaces/Third Party

• Test Inputs o Prior test phase defects o Requirements o Designs/Use Cases o Components

• Test Outputs o Performance Results

• Benchmarks

• Metrics

• Performance Tool-specific Output/Visuals

• Performance Defects o Performance Test Summary Report

• Test Entrance/Exit Criteria

• Test Resources

V.15.0 Page 22 o Test Team

• Roles and Responsibilities o Test Tools o Test Environments

• Environment Maintenance

• Data Volume/Quality o Test Data Management

• Security Protocols

• Data Preparation

• Test Bed Backup/Restore

• Test Execution o Execution Strategy o Defect Management

• Defect Resolution

• Defect Retest/Regression o Communication

• Test Strategy Meeting

• Test Checkpoint Meeting o Metrics

• Test Pass Rate

• Test Case Status

• Defect Status

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.20. D-020 – Performance Test Summary Report

Delivery Provision Minimum of one submission at the end of the E2E/Performance Test Phase as defined in approved project schedule.

Description The Performance Test Summary Report describes the test outcome and technical results of Vendor Performance testing.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• Test Overview

• Test Summary

V.15.0 Page 23 o Test Phase/Cycle o Execution Timeframe o Test Environment o Test Case Summary

• Test Cases/Transactions

• Scalability/Load Factor

• Performance Test Results o Benchmarks o Metrics o Defect Summary

• Test Process Variances

• Items Excluded from Testing

• Test Phase RTM

• Tool-specific visualizations

Deliverable Format The deliverable shall be created using MS Word. The RTM attachment shall utilize Excel.

2.21. D-021 – User Acceptance Test (UAT) Support Plan

Delivery Provision Minimum of one submission prior to the start of UAT Test Phase as defined in approved project schedule

Multiple submission(s) may be required for additional project phases/releases as defined in approved project schedule

Description The UAT Support Plan provides a comprehensive description of Vendor activities to support User Acceptance Test preparation and execution by SCDHHS.

Refer to DASH Master Test Plan for additional details.

Expected Deliverable Content

Content must include:

• UAT Support Overview

• Test Preparation Support o Tester Training o Support for Interface/Third Party Testing o UAT Test Environments

• Environment Maintenance

• Data Volume/Quality

• Batch/Interface Management o UAT Test Data Management

V.15.0 Page 24

• Configuration Management

• Security Protocols

• Data Preparation

• Reference Data

• Converted/Transactional Data

• Test Files

• Test Credentials

• Test Data Output Locations o Test Bed Backup/Restore

• Test Execution Support o Test Resources

• Test Team

• Roles and Responsibilities o Defect Management

• Defect Triage

• Defect Resolution

• Defect Retest/Regression o Communication

• Test Strategy Meeting

• Test Checkpoint Meeting

• Test Entrance/Exit Criteria

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.22. D-022 – Operations and Maintenance (O&M) Plan

Delivery Provision Due per approved project schedule

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Operations and Maintenance Plan defines the roles and responsibilities of each party involved in the support of the solution and defines the transition to Operations and Maintenance for solution support.

Expected Deliverable Content

Content:

• Organization Chart of the Vendor Support Team

• Organization Chart of SCDHHS Support Team

V.15.0 Page 25

• O&M communications process and matrix

• Description of each support function, resource, and role mapped to each support team and Help Desk

• Staffing levels for each function for O&M

• Support transition and activities to begin O&M

• Description of the Vendor support knowledge base

• Description of the on-going training needs for Vendor and SCDHHS support staff

• System administration/availability

• Configuration management

• Release management

• Capacity management

• Change management

• Service level management

• Incident Management

• O&M Status reporting o Accomplishments during the reporting period o Problems encountered and proposed/actual resolutions o Work to be accomplished during the next reporting period o Issues and risks to be addressed, including contractual o Status of changes/incidents and releases o Availability reporting o Metrics on ticket status and aging and other statistics as requested by SCDHHS

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.23. D-023 – Help Desk Plan

Delivery Provision Due per approved project schedule

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description This Help Desk Plan describes how all help desk related activities are executed, monitored, measured, and controlled. This plan also

V.15.0 Page 26 describes the processes for ensuring adherence to Help Desk requirements.

Expected Deliverable Content

The Help Desk Plan includes the following:

• Description and definition of Help Desk Support, including definitions for Tier 1, Tier 2, and Tier 3 level of support

• Expected hours of support

• Expected response times

• Flow chart of the entire Help Desk process

• Explanation of how the role of the Help Desk progresses through project phases from user acceptance testing through deployment to operations and maintenance

• Help Desk and incident tracking software and tools

• Help Desk procedures for problem response, resolution processes, and escalation processes

• Help Desk Roles and Responsibilities

• The mechanisms for receiving service requests; and expectations for tracking and status reporting

• Help desk performance analysis report template(s) and process(es)

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.24. D-024 – Data Conversion Plan

Data conversion deliverables are not currently applicable to this solicitation, unless SCDHHS issues a change order to add data conversion activities to the MCDE project at a later date.

Delivery Provision Due per approved project schedule no later than the end of the Design Phase

This plan, and other conversion deliverables, are not required when project has no data identified requiring conversion

Each plan is subject to vendor review and update as requested by

SCDHHS

Description The conversion plan deliverable describes the processes and procedures, tools, roles and responsibilities, testing, reporting and

V.15.0 Page 27 quality and metrics necessary for a successful cutover to the new system.

Expected Deliverable Content

Conversion Roles and Responsibilities Conversion Tools and Environments

• Description of tools/software o Vendor is expected to use DevOps for Conversion Defects o Vendors may submit an alternative tool for consideration

• Description of conversion environment

Conversion Processes and Procedures

• Conversion Strategy

• Managing Conversion changes (Change control/Release Management)

• Managing conversion requirements/conversion rules (i.e., 1-to- 1 mapping, default, translation/crosswalk (cleanup by rule), complex rules.

• Conversion extracts (security, repository, lifecycle)

• Conversion Software/Scripts o Repository o List of Scripts with purpose of each script o Execution Instructions including special conditions and sequencing

• Conversion Testing/Data Validation o Unit Test o Conversion System Test o Conversion SCDHHS Validation o Mock Conversions o Vendor Deployment Smoke Test

• Data Cleanup/Readiness Reporting o Reporting method o Repository o Monitoring o Types of Cleanup/Readiness Reports

• Quality Standards and Metrics o Quality (Accuracy/Completeness/Performance) o Metrics (acceptable error rates)

Conversion Configuration Management Process

Conversion Backup and Restore Processes

V.15.0 Page 28

Conversion Recovery/Backout Processes

Conversion Status Reporting

Conversion Deployment Support

• Production Cutover Task List and Schedule

• Post Deployment Conversion Support

• Post-Conversion Data Correction Processes

• Template for Data Conversion mapping rules Reports

• Template for Data Conversion Test Results Reports

• Template for Final Data Conversion Report

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be created using the template for DASH Plans.

2.25. D-025 – Data Conversion Mapping Rules

Delivery Provision Due per approved project schedule

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description The data conversion mapping deliverable defines the expectations for data mapping rules and related reporting

Expected Deliverable Content

Document source/target metadata (data dictionary)

• Source tables – identify files/tables and fields/columns for “from”

• Target tables – identify files/tables and fields/columns for “to”

Create rules for source to target mapping

• Default rules (set all values to 0)

• 1 to 1 mapping rules (move value “as is”)

• Translation rules (use a table to convert 1 to Male)

• Cleanup by rule (Verify data against table and set invalid values to blank)

• Complex rules (when source field 1 is blank and source field 2 is ‘Y’ or ‘Z’ set target field to ‘A’)

V.15.0 Page 29

Mapping related reporting

• Source files/fields not mapped

• Target file/fields not mapped

• Unapproved rules report

• Rules report by source file/field or target file/field

• Other systems impacted with impact assessment (what other downstream systems need to be notified of file or data changes)

SCDHHS will provide input and review the Vendor provided Data Mapping Rules for approval.

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio.

Format as approved in D-024 – Data Conversion Plan

2.26. D-026 – Data Conversion Validation Scripts and Test Results Report

Delivery Provision Due per approved project schedule no later than the end of End-to-End Integration Testing

Description The data conversion validation scripts and test results report deliverable provide both an executive summary and detailed documented output of the execution of every validation test for data conversion. For every test script, actual test results will be documented, including any necessary re-testing.

Expected Deliverable Content

Scripts

• List of scripts with description/purpose and expected result

Reports

• Traceability matrix showing that all conversion rules trace to a test script(s)

• Defects created for all validation failures

• Report extracts of unresolved conversion defects

• Summary results of tested scripts

• Detailed results of the executed test scripts showing test results

V.15.0 Page 30

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. Vendor can also propose other formats to be approved by SCDHHS.

Format as approved in D-024 – Data Conversion Plan

2.27. D-027 – Final Data Conversion Report

Delivery Provision Due per the approved project schedule

Description The Final Data Conversion Reports identifies the various types of reporting expected with the execution of the conversion for Deployment

Expected Deliverable Content

Provide all reports from final execution as defined in conversion plan

Reports

• Testing Validation Reports

• Quality Reports and Metrics

• Data Mapping Reports

• Readiness Reports

• Conversion Data Cleanup Reports (for post-conversion cleanup)

• Report extract showing all conversion defects with documentation for defect resolution (e.g., correction/retest, acceptance, post-conversion cleanup, etc.)

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio.

Format as approved in D-024 – Data Conversion Plan

2.28. D-028 – Vendor Training Plan

Each plan is subject to vendor review and update at a minimum one-year interval or as requested by SCDHHS

Description The Vendor Training Plan identifies the training approach, methods, V.15.0 Page 31 materials development, delivery, tools, metrics, reporting, roles, and customizations to conform to the DASH Training Plan.

Expected Deliverable Content

The Vendor Training Plan shall describe:

• Purpose and scope of the training effort

• Types of training to be delivered, including:

o Technical training for system administrators o Systems training for User Acceptance Test (UAT) participants o Train-the-Trainer (TTT) sessions for vendor trainers o Role-based system training for end-users

• A description of training sessions by type of training and the different groups to be trained in each type of training, including:

o Goals for training sessions o User Profiles of trainees to be trained o Prerequisites for trainees o Business functions and processes covered in each training session o Hours needed for each training session

• Delivery mechanism for each type of training (e.g., webinar, in-person, train-the-trainer, electronic documentation)

• Staffing, including roles and responsibilities to develop and deliver the training

• Training activities, tasks, and materials including the timing of the training material development and training delivery

• Training planning and preparation, including training locations, materials, tools, documentation, scheduling, pre-requisites, staffing, and other key training elements

• Hardware, software, data, facilities, and materials needed to support the training effort

• Training feedback mechanism and training evaluation methods

Deliverable Format The deliverable shall be created using MS Office products, with documents utilizing MS Word. Embedded tables, process flows, and high-level diagrams shall utilize Excel and Visio. The deliverable shall be

2.29. D-029 – Training Materials

Delivery Provision Deliverable format must be approved prior to submission of deliverable

Due per approved project schedule with draft materials available prior

V.15.0 Page 32 to UAT training and Final revisions prior to deployment training

Review and update each time the document is impacted during defect correction, testing, or operations and maintenance

Description Develop Training Materials for approval by SCDHHS prior to delivering…