ATTM 009.pdf

ATTACHMENT 009 CDML

Attachment 010: Minimum Content For Project Deliverables D-001: Project Kick-Off Meeting

D-002: Project Kick-Off Meeting Report

D-003: Vendor Project Schedule

D-004: Release Management Plan

D-A05: Project Management Plan (PMP)

D-A06: Cost Management Plan

D-007: Project Communication Plan and

Communication Matrix

D-A08: Project Risk and Issues Management Plan, Project Risk Watch List Matrix, and Project Issues Log

D-009: Vendor Software Quality Assurance Plan and

Quality Assurance Reports

D-A10: Project Change Management Plan, Project

Change Request Form, and Project Change Request Log

D-011: System Security Plan

D-012: Technical Architecture and System Design

Document/Architecture Diagrams

D-013: Configuration Management Plan

D-014: Training Plan and Materials

D-015: Test Plan

D-016: System Design Document

D-017: Conduct Gap Analysis

D-018: Gap Analysis Document

D-019: Solutions Requirements Document

D-020: Solution/Sprint Backlogs

D-021: Use Cases

D-022: User Stories

D-023: Requirements Traceability Matrix

D-024: Physical and Logical Data Models

D-025: Data Dictionary

D-026: Data Conversion and Migration Plan

D-027: Data Map

D-028: Data Conversion and Migration Software/Scripts

D-029: Data Conversion and Migration Test Results

Report

D-030: SCDHHS Acceptance of the Converted and

Migrated Data

D-031: Detailed Design Specifications Document including FDS and TDS

D-032: Design Review Sessions/Design Sprint

D-033: Test Cases

D-034: Prepare All Test Environments

D-035: Unit Test Results Report

D-036: System Test Results Report

D-037: Regression Testing Results Report

D-038: Integration Test Results Report

D-039: Section 508 Product Assessment and

Accessibility Test Results Report

D-040: Demonstration of Tested Solution

D-041: Disaster Recovery and Business Continuity

Management Plan

D-042: Disaster Recovery and Business Continuity Plan

D-043: Load and Performance Test Plan

D-044: Load and Performance Test Cases

D-045: Load and Performance Test Scripts

D-046: Load and Performance Test Readiness Report

D-047: Load and Performance Test Results Report

D-048: SCDHHS Acceptance of Performance for each release

D-049: User Acceptance Test Plan

D-050: UAT Test Cases and Test Scripts

D-051: UAT Training Materials

D-052: UAT Training

D-053: UAT Results Report

D-054: SCDHHS Acceptance of Tested Solution

D-055: User Guides, Quick Reference Guides, and

Online Help Documentation

D-056: Technical and System Administration

Documentation

D-057: Training Materials

D-058: SCDHHS Acceptance of Pilot Completion

D-059: Training Delivery

D-060: Release/Deployment Readiness Checklist

D-061: Completed Deployment Readiness Checklist

D-062: Communication Management Plan

D-063: Operations and Maintenance Plan

D-064: Onsite Assistance during Deployment Readiness

D-065: Validation Test Results Report

D-066: Deployment UAT Results Report

D-067: SCDHHS Acceptance of Deployment UAT Results

D-068: Vendor Support During Stabilization Period

D-069: SCDHHS Acceptance of Stabilized Solution

D-070: Lessons Learned

D-071: Project Status Meetings Agenda and Minutes

D-072: Project Status Reports

D-073: Sprint Reports

D-074: Operations and Maintenance Status Reports

D-075: Transition Plan

D-076: Information Security Risk Assessment (ISRA)

D-077: Privacy Impact Assessment (PIA)

D-A78: Quality Management Plan

D-079: Database Design Document

D-A80: Scope Management Plan

D-081: Configuration Management Plan

D-A82: Schedule Management Plan

ATTACHMENT 010: CONSOLIDATED DELIVERABLES MANAGEMENT LIST (CDML)

Introduction

The South Carolina Department of Health and Human Services (SCDHHS) defines a deliverable as a quantifiable good or service that will be provided or adhered to throughout the Project Lifecycle. Deliverables can be tangible or intangible and are most often specified functions or characteristics of the project. The following tangible deliverables are included as part of the Consolidated Deliverables Management List (CDML) applicable to (SCDHHS) contractors managed in accordance with the Contractor (Vendor) Management Plan. The deliverables listed herein are the expected minimum list for SCDHHS third-party contracts. Depending on the scope of work (SOW), SCDHHS may include additional deliverables to this list or exclude by exception only. Therefore, this is not an all-inclusive list. Vendors may work with the assigned SCDHHS Project Manager to propose packaging related deliverables into a single submission for the respective deliverables to SCDHHS. Certain deliverables may also be determined as not applicable by SCDHHS and signed off as such by the assigned SCDHHS

Project Manager.

Unless otherwise indicated in the specific deliverable list below, deliverables will be submitted electronically by close of business (COB) at SCDHHS (5:00 p.m. Eastern Time). The ‘data rights of ownership’ for each deliverable is the State of

South Carolina. 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.

Project-based deliverables are documented, monitored, measured, and reported via the SCDHHS defined method (e.g., Schedule Management Plan, Communications Management Plan, etc.) throughout the contracted life of the project’s lifecycle. All deliverables will be reviewed and approved per the project team. All SCDHHS plans referenced throughout the

CDML can be replaced with similar vendor plans if approved by SCDHHS.

# Deliverable and Delivery Provisions Purpose and Minimum Content:

D-001 Project Kick-Off Meeting Responsibility during DDI Responsibility during O&M

Primary Vendor with

SCDHHS input

N/A

Delivery Provision: Conduct meeting within ten (10) State business days of the contract effective date.

Part of the Planning and Design Milestone Task Group.

Milestone A.

SCDHHS Deliverable Acceptance:

Name and Position

Signature and Date

Purpose/Description: The Kick-Off Meeting is held to formally notify all team members, clients, and Stakeholders that Vendor engagement on the project has begun and to make sure everyone has a common understanding of the project and their roles.

The Vendor Project Manager will prepare the agenda, meeting materials, and participate in meeting delivery.

SCDHHS will have a SCDHHS Project Manager facilitate this meeting.

Content:

The agenda of the meeting will include:

a) Project Executions scope, approach, and timeline;

b) Introduction of management and technical Vendor resources assigned to the Project Execution;

c) Review of Vendor and SCDHHS Project

Management Methodology to be used for the Project

Execution;

d) Status reporting mechanisms and timeframes;

e) Deliverable review process;

f) Lines of communication and reporting relationships;

g) Identify schedule for upcoming meetings related to the Vendor Deliverables requested by key dates after contract award;

h) Identify high-risk or problem areas; and

i) Project assumptions and impact of each

D-002 Project Kick-Off Meeting Report Responsibility during DDI Responsibility during O&M

Vendor N/A

Delivery Provision: Within three (3) State business days of the Project Kick-Off Meeting.

Part of the Planning and Design Milestone Task Group.

Milestone A.

Purpose/Description: The Project Kick-Off Meeting

Report summarizes the Vendor understanding of the

SCDHHS methodology and project management expectations, deliverables, project execution details and all understandings and actions items resulting from the Meeting.

Content: As described in Purpose/Description for this deliverable.

D-003 Vendor Project Schedule Responsibility during DDI Responsibility during O&M

Vendor Vendor

Delivery Provision: Draft schedule submitted as part of the

Offeror Proposal.

• Updated Vendor Project Schedule reviewed with

SCDHHS within ten (10) State business days of contract effective date.

• Final Vendor Project Schedule due within twenty

(20) State business days of the contract effective date for SCDHHS review for approval.

• Schedule Baseline is due once the SCDHHS approves the final Vendor Project Schedule.

• Contract duration updated weekly two (2) days prior to next scheduled project status meeting.

• Ad hoc as requested by SCDHHS.

Part of the Planning and Design Annual Firm Fixed Price with Monthly Payments.

Purpose/Description: The Vendor Project Schedule defines all tasks necessary for the Vendor proposed project delivery method, associated interdependencies, and task resource assignments to execute the project.

Vendor Project Schedule will be developed with Microsoft

Project for import into Planisware or developed in

Planisware.

a) Clearly map project management phases, Sprint

Cycles/Modules/Milestones, and Deliverables outlined in this RFP;

b) For recurring near-term planning, sub-divide all tasks to ensure small manageable time chunks are allocated to each task;

c) Identify each Sprint

Cycles/Modules/Milestones/Deliverables;

d) Identify capability/functionality developed by the

Sprint Cycles/Modules/Milestones/Deliverables;

e) The expected duration of the Sprint

Cycles/Modules/Milestones/Deliverables;

f) The order of the Sprint

Cycles/Modules/Milestones/Deliverables;

g) Projected tasks start and end dates;

h) Major business decision points and Deliverables defined in this RFP;

i) Projected Spring

Cycles/Modules/Milestones/decision point due dates;

j) Task dependencies;

k) WBS references for each task and Sprint

Cycles/Modules/Milestones;

l) Resource task assignments and usage for all

SCDHHS staff, Vendor staff, and project team staff from any other organizations; and

m) When allocating work to SCDHHS personnel, the

Vendor Project Schedule must:

I. Be based upon a forty-hour (40 week (8:00 a.m. through 5:00 p.m., Monday through

Friday Eastern Standard Time); and

II. Accommodate that many of the SCDHHS personnel will not be assigned full time to this project and will not complete work on South

Carolina State Government holidays.

D-004 Release Management Plan Responsibility during DDI Responsibility during O&M

Primary Vendor with

SCDHHS input and approval

Primary Vendor with

SCDHHS input and approval

Delivery Provision: Draft plan submitted as part of the

• Baseline Release Management Plan to deliver all business and technology specifications submitted in accordance with the date defined in the approved

Vendor Project Schedule.

• Release Management Plan updated continuously throughout the Contract Duration.

• Update when impacted.

Purpose/Description: The Release Management Plan defines the number of releases to deliver all business and technology specifications, and subsequent requested enhancements for new functionality, planned functionality for each release, subsequent iterations for release(s), plans for each iteration including functionality to be developed and individual tasks necessary to deliver a feature. Not all iterations will be approved by SCDHHS for implementation.

SCDHHS will limit the number of iterations that are approved for implementation/release.

The details for the Release Management Plan will be coordinated with SCDHHS for input and approval.

a) The number of releases planned;

b) Releases planned to include additional functionality or enhancements;

c) Scope of each release;

d) Timeline for each release, including Vendor Team testing, UAT (each release must go through at least one iterations of UAT), and end user training;

e) Features and Epics that will be addressed in each release;

f) The estimated number of two (2) to five (5) week iterations/sprints to be completed before releasing the code into production;

g) End User Training prior to each release; and

h) Any other communications to be sent to end users prior to each release

D-A05 Project Management Plan Responsibility during DDI Responsibility during O&M

Vendor Adherence Vendor Adherence

Delivery Provision (Adherence): Draft Vendor version of the Project Management Plan detailed as understood by the Offeror submitted as part of the Offeror Proposal.

• Final Vendor Project Management Plan details within twenty (20) State business days of contract effective date. Final plan will be integrated in the

SCDHHS PMP by the SCDHHS.

• Updated throughout Project DDI.

• As needed including the O&M phase if staffing levels change, provide a revised Organization Chart and updated Staffing Plan.

Purpose/Description: The Project Management Plan describes how the Vendor engagement during the Project

Execution will be executed, monitored, and controlled.

a) Project background;

b) Project objectives;

c) Project success criteria and contingencies;

d) Project assumptions and constraints;

e) Project Scope;

f) Project high-level timeline;

g) Project Deliverables;

h) Project management methodology and approach;

i) Entrance and exit criteria for specific project Sprint

Cycles/Modules/Milestones;

j) Status reporting practices and mechanisms, including update of Vendor Project Schedule progress;

k) Monitoring and control mechanisms and corrective plan notification;

l) Technical approach, including transition management;

m) The organizational information, including organizational chart that reflects roles and responsibilities for Vendor and subcontractors (if applicable);

n) Project Staffing Plan of SCDHHS and Vendor resources for DDI and O&M:

I. A list of all labor resources identifying each person who will be assigned during DDI and

O&M to include any subcontractors.

II. The roles and responsibilities of all staffing resources;

III. Vendor organizational information, including an organizational chart.

IV. The number of dedicated full time employees and the percentage of each staffing resource’s time needed in each phase;

V. Estimated hours per resource. Specify of how long each resource will be needed for each phase of the project;

VI. Definition of skills needed for each staffing resource;

VII. Matrix of necessary skills/roles for each resource;

VIII. Vendor specifications for SCDHHS resources with the duration and type of each SCDHHS resource needed;

IX. Other Vendor resources available to

SCDHHS during DDI and O&M; and

X. Plan for resource turnover;

o) Knowledge transfer strategy; and

p) Documentation Deliverable and record management approach.

D-A06 Cost Management Plan Responsibility during DDI Responsibility during O&M

Delivery Provision (Adherence): Contract effective date

+ ten (10) State business days.

Updated monthly at the first project status report of the month.

Purpose/Description: The purpose of the Cost

Management Plan is to outline the cost management approach, methodology and tools used to identify and estimate costs, analyze expenditures and variances, track and reconcile estimates to invoices, monitor, control, and report actual cost/budget expenditures. The approved cost management process ensures a defined, documented, repeatable and measurable process exists for successful quality management.

Provide cost management by estimating, tracking, and controlling expenditures related to all SCDHHS major projects, system-based changes, IT equipment (i.e., infrastructure, hardware, software) and staff (i.e., contract and non-contract) costs.

Content: Contractor (Vendor) will adhere to the SCDHHS

Cost Management Plan requirements as well as the related cost management processes and procedures detailed in the MMS PMP/ MM SOP.

D-007 Project Communication Plan and

Communication Matrix

Responsibility during DDI Responsibility during O&M

Primary Vendor with

SCDHHS Input

Primary Vendor with

SCDHHS Input

Delivery Provision: The date defined in the SCDHHS approved Vendor project schedule.

Purpose/Description: The Project Communication Plan describes the processes necessary to ensure the timely generation, collection, dissemination, storage, and

Vendor provides updates as needed during DDI and O&M.

disposition of project information to project Stakeholders.

The Project Communication Plan also provides a method to identify planned and typical methods of exchanging information both within the project and with Stakeholders and interested parties external to the project. The plan will include or be accompanied by a Communications Matrix that identifies current individuals in each communication group, contact information, and preferred method of communication.

Vendor will work with SCDHHS to define and document the

Project Communication Plan and Communication Matrix.

a. Project Communication Plan:

I. Stakeholder communication needs;

II. Information to be communicated, including language, format, and level of detail;

III. Reason for the distribution of information;

IV. Timeframe and frequency for the distribution of necessary information and receipt of acknowledgement of response, if applicable;

V. Roles and responsibilities regarding the creation, approval/authorization, and transmission of communications;

VI. Person or groups that will receive the information;

VII. Methods and technologies used for communications (e.g., email, reports, memos, SharePoint, newsletters, website, press releases, etc.); and

VIII. Escalation procedures identifying timeframes and the management chain (i.e., individuals) for escalation of issues for resolution;

b. Communication Matrix:

I. A list of Stakeholder groups and member of each group with contact information;

II. Project meeting schedule and attendees’ and

III. A project documentation list to include the document name, the distribution, frequency/schedule, the documentation format, the archival location, the distribution list, and the distribution method.

IV. Track project documentation in a deliverable tracker.

D-A08 Project Risk and Issues Management Plan, Project Risk Watch List Matrix, and Project

Issues Log

Responsibility during DDI Responsibility during O&M

Delivery Provision (Adherence): The date defined in the

SCDHHS approved Vendor project schedule.

Risks and issues identified by Vendor will be reported on

Vendor status reports and other communication mechanisms as Defined in the Project Risk and Issues Management

Plan.

Project duration in DDI and O&M.

Updated during O&M for any additional iteration(s) that may be in DDI and any identified issues in O&M.

Purpose/Description: Vendor will adhere to the Project

Risk and Issues Management Plan identifies the process, procedures, and tools utilized to identify, mitigate, resolve, and manage risk/issues for Project Execution through a systematic and controlled process. The Project Risk and

Issues Management Plan also includes a Project Risk

Watch List Matrix to document and track the mitigation of risks identified during the projects, and a Project Issues

Log that provides a detailed description of the issues for the

Project and how those issues will be addressed and resolved.

Vendor will assist by providing information as needed to the

SCDHHS.

a. Project Risk and Issues Management Plan:

I. Processes for identifying and assessing risks/issues;

II. Determining effective risk mitigation/resolution actions;

III. Monitoring and reporting progress in mitigating/resolving risks/issues;

IV. Definition of risk/issue categories;

V. Budget;

VI. Quality;

VII. Resource;

VIII. Schedule;

IX. Scope; and

X. Technical Definitions; and

XI. Rating scale of risk/issue severity;

XII. For risk, definitions, and rating scale of risk probability;

XIII. Escalation procedures; and

XIV. Tools used for the risk/issue management process.

b. Project Risk Watch List:

I. Unique identification number;

II. Description of the risk;

III. Date risk was identified;

IV. Escalation procedures;

V. Person assigned to take actions to mitigate the risk and date of assignment;

VI. Area(s) impacted by the risk;

VII. Risk category;

VIII. Signs and symptoms of the risk;

IX. Probability of the risk occurring;

X. Severity of impact if the risk were to occur;

XI. A risk score based on probability and severity;

XII. Mitigation strategy with a complete history of all actions taken;

XIII. Date risk closed; and

XIV. Comments.

c. Project Issues Log:

I. Unique ID:

II. Description of the issue:

III. Date received or identified;

IV. Person assigned to resolve the issue and date of assignment;

V. Issue category;

VI. Issue severity;

VII. Final resolution with a complete history of all activities and the resolution date; and

VIII. Comments.

D-009 Vendor Software Quality Assurance Plan and

Quality Assurance Reports

Responsibility during DDI Responsibility during O&M

Primary Vendor with

SCDHHS approval

Primary Vendor with

SCDHHS approval

Contract duration in DDI and O&M:

• Review and update each time the Vendor Software

Quality Assurance Plan is impacted.

• Review and update every twelve (12) months or when impacted

• Vendor Software Quality Assurance Plan (SQAP) and updates require SCDHHS approval.

• Quality Assurance Report schedule must be approved by SCDHHS.

Purpose/Description: The Vendor Software Quality

Assurance Plan (SQAP) establishes the goals, processes, and responsibilities necessary to implement effective quality assurance functions for the Project Execution. In addition, the plan outlines the verification and validation (V&V) processes that Vendor uses to determine how Vendor products conform to their specifications and fulfill their intended use and user expectations.

a. The purpose and scope of the quality assurance effort;

b. The Quality Assurance (QA) methodology;

c. The QA organization;

d. The QA staff roles and responsibilities;

e. QA estimated resources;

f. The QA tasks for the Project Execution;

g. The entrance and exit criteria for the QA tasks;

h. Applicable federal, State, SCDHHS, departmental, and Vendor standards, policies, and procedures to include coding, design, data documentation, user interface, security, disaster recovery, and commentary standards;

i. Applicable practices, conventions, and metrics;

j. A description of evaluation criteria and results reporting needs and mechanisms;

k. Minimum documentation necessary for QA review and audit;

l. QA tools, methods, and techniques;

m. Controls for media, security, disaster recovery, and suppliers;

n. V&V methodology to include approach, scope of work products, V&V techniques, roles, responsibilities, estimated resources, tasks for

Project Execution, and results reporting;

o. Records collection, maintenance, and retention;

p. Identification and implementation of corrective action plans; and

q. Quality Assurance reporting.

D-A10 Project Change Management Plan, Project

Change Request Form, and Project Change

Request Log

Responsibility during DDI Responsibility during O&M

Primary SCDHHS with

Vendor support

Primary SCDHHS with

Vendor support

Delivery Provision (Adherence): The date defined in the

SCDHHS approved Vendor project schedule.

SCDHHS will maintain the Project Change Request Log and provide updates to the Vendor and Project Team at each Project Status Meeting.

Vendor to submit Project Change Request Form when required or upon SCDHHS request.

SCDHHS will maintain the Project Change Request Log and provide updates to the Vendor and Project Team at each Project Status Meeting.

Purpose/Description: The Project Change Management

Plan is the formal document that establishes processes for documenting, managing, and controlling changes within a project. The Project Change Management Plan also includes a Project Change Request Form and a Project

Change Request Log.

a. Project Change Management Plan:

I. Change control process;

II. Change control process for project documentation/deliverables;

III. Roles and responsibilities for Change

Management;

IV. Change request review turnaround times;

V. Change request evaluation criteria;

VI. Change priority definitions;

VII. Change approval process – amendment or

CR only; and

VIII. Change Payment Process.

b. Project Change Request Form:

I. Unique ID;

II. Date created;

III. Requestor name and contact information;

IV. Type of change;

V. Project name;

VI. Severity of impact;

VII. Priority for change;

VIII. Description of the change;

IX. Justification for the change;

X. Schedule impact;

XI. Scope impact;

XII. Estimated Cost of change;

XIII. Person hours associated with change;

XIV. Type and number of resources needed; and

XV. Change Request Status (approval, amicable modification, referrals, rejection, etc.) and date.

c. Project Change Request Log:

I. Unique ID;

II. Description of the change;

III. Requestor;

IV. Date submitted;

V. Priority for change;

VI. Estimated Cost;

VII. Target Completion Date;

VIII. Decision (approval, amicable modification, or rejection);

IX. Information or link to where the CR submission is stored;

X. Date; and

XI. Comments.

D-011 System Security Plan Responsibility during DDI Responsibility during O&M

Delivery Provision: Draft submitted as part of the

Contract duration in DDI and O&M.

• Final submission as defined in SCDHHS approved Vendor project schedule.

• Review and update throughout the project duration with a minimum review and update every twelve (12) months.

• Updated after the system infrastructure requirements and design are finalized.

• Update whenever a significant change that affects security or other applicable trigger (as defined in the most recent NIST standards and most recent

Minimum Acceptable Risk Standards for

Exchanges (MARS-E) PL-2) occurs.

Purpose/Description: The System Security Plan

(SSP) details the security and privacy controls implemented in the system to control security and privacy risks to the system and its data. The System

Security Plan will meet or exceed all State, SCDHHS, and federal security requirements.

SCDHHS will provide information as needed from

Agency Information System Security Officer (ISSO) for the Vendor to complete this task.

It is anticipated that some security and privacy controls required in the System Security Plan will be outside the

Vendors scope to define, implement, or document (for example, the System Security Plan should document that the system is governed by the appropriate security policies at the organizational level). SCDHHS will supply content for all control documentation in the System

Security Plan that is beyond Vendor scope. However, the Vendor is responsible for documenting all security and privacy controls that specific to the Solution itself.

The System Security Plan will be stored in the SCDHHS

Governance, Risk, and Compliance (GRC) tool RSA

Archer. Vendor personnel will be expected to enter the documentation for each applicable Security and Privacy control directly into Archer using access credentials that will be provided by SCDHHS.

a. The security categorization of the Solution including supporting rationale;

b. Full descriptive name of the information system including associated acronym;

c. Unique information system identifier (typically a number or code);

d. Solution owner, Data Steward/Custodian, and authorizing official including contact information;

e. Information on the organization(s) that manages, owns, and controls the Solution;

f. Location of the Solution and environment in which it operates;

g. Version or release number of the Solution;

h. Purpose, functions, and capabilities of the Solution and details of the essential functions or business processes supported;

i. Technical security architecture;

j. Status of the Solution with respect to acquisition or life cycle;

k. Applicable laws, directives, policies, regulations, or standards affecting the security of the Solution;

l. Describes the security controls in place or planned for meeting data security requirements including a rationale for the tailoring and supplementation decisions;

m. Types of data processed, stored, and transmitted by the Solution;

n. Boundary of the Solution for risk management and security authorization purposes;

o. Architectural description of the Solution including network topology;

p. Hardware and firmware devices included within the

Solution;

q. Solution and applications software resident on the

Solution;

r. Hardware, software, and system interfaces

(internal and external);

s. Subsystems (static and dynamic) associated with the Solution;

t. Data flows and paths (including inputs and outputs) within the Solution;

u. Cross domain devices/requirements;

v. Network connection rules for communicating with systems (both internal and external);

w. Interconnected systems and identifiers for those systems;

x. Encryption techniques used for information processing, transmission, and storage;

y. Cryptographic key management information, (e.g., public key infrastructures, certificate authorities, etc.);

z. End user types including organizational affiliations, access rights, privileges, citizenship

(if applicable);

aa. Ownership/operation of the Solution, (e.g., government owned, government-operated;

government-owned, contractor operated;

contractor-owned, contractor-operated; federal

[state and local governments, grantees]);

bb. Security authorization date and authorization termination date;

cc. Incident response outline with points of contact;

dd. Other information as required by the organization;

and

ee. Site Security Plan as required.

The current version of the Minimum Acceptable Risk

Standards for Exchanges (MARS-E) provides complete guidance on the minimum security and privacy controls that must be included in the Security Plan and can serve as a basis for the development of the Solution Security

Plan.

D-012 Technical Architecture and System Design

Document (TASD)/Architecture Diagrams

Responsibility during DDI Responsibility during O&M

Vendor Vendor

Delivery Provision: Draft solution submitted with Offeror

Proposal.

The final version of these diagrams are to be delivered during the planning and design phase.

Updates are made to the diagrams as needed throughout the Contract Duration no less than annually.

Technical Architecture and System Design Document

(TASD)/Architecture Diagrams can optionally be provided as part of the System Design Document D-016.

Purpose/Description: The Technical Architecture and

System Design Document (TASD)/Architecture

Diagrams describes the design of the technical architecture on which Solution will reside, and the functional components that make up Solution. The

TASD/Architecture Diagrams is developed iteratively starting with the Conceptual Design, then the Preliminary

Design, and completed with the Detailed Design. This deliverable is progressively refined (i.e., Conceptual, Preliminary and Detailed) as the Solution is designed, developed, and implemented. The TASD/Architecture

Diagrams will be evaluated by SCDHHS for any necessary changes.

a. Network Architecture Diagram (NAD) – This diagram describes the means of communication, the method of sending and receiving information, between the assets in the Technology

Architecture.

The diagram will take logical connections between client and server components and identify network boundaries and network infrastructure required to physically implement those connections. It does not describe the information format or content but will address protocol and capacity issues.

A network architecture diagram shows the deployed logical view of application components in a distributed network computing environment.

Communication should only be logical and should only show technology where it is architecturally relevant.

i. Protocols

ii. Ports

iii. Services

iv. Physical Application Components

v. Physical Technology Components

vi. Location

b. Technology Stack Diagram (TSD) – Technology stack, also called a solution stack, is a set of software components that compose a logically complete platform for running a service or supporting an application. It is the set of software that provides the infrastructure for a solution. The stacks differ based on the deployment location

(e.g., client, server, mainframe). The technology stack diagram depicts the relationships and critical communication paths between the solution’s software components.

i. Physical Technology Components

ii. Physical Application Components

iii. Communication Lines

D-013 Configuration Management Plan Responsibility during DDI Responsibility during O&M

Delivery Provision: The date defined in SCDHHS approved

Vendor project schedule.

Contract duration during DDI.

• Review and update each time the plan is impacted.

Contract duration during O&M.

• Review and update every twelve (12) months.

Purpose/Description: The Configuration

Management Plan explains the methodology for identifying and controlling the functional and physical design characteristics of configurable items throughout the software development life cycle (SDLC). It also will describe version control for all technical environments.

a. List of all functional and physical items

(configuration items) included in the scope of configuration management, which includes hardware, software, and design;

b. Method and procedure for controlling changes to configuration items;

c. Configuration management activities;

d. Configuration management roles and responsibilities;

e. Change status reporting method for configuration items;

f. Method for ensuring that control will be maintained over design, development, production, installation, and support configuration items;

g. Method for ensuring that Vendor inspections demonstrate acceptability to the SCDHHS of material and services will be performed;

h. Evidence of a disciplined integrated systems development approach; and

i. Release management roles and responsibilities, practices/processes, and activities.

j. Release schedule updates with weekly task updates and a three (3) week look ahead.

D-014 Training Plan and Materials Responsibility during DDI Responsibility during O&M

Project duration in DDI and O&M.

• Review and update every six (6) months.

Part of the Deployment, Implementation, and Training

Grouped Deliverables Milestone E.

Purpose/Description: The Training Plan and Materials identifies the strategy, short- and long-term objectives, the work, necessities, and procedures to be carried out to achieve agreed objectives for training staff effectively. The

Training Plan and Materials clearly describes the Vendor strategy for performing role-based training and defines specifically how the training materials will be developed and how the SCDHHS's requirements and specifications will be met.

a. Purpose and scope of the training effort;

b. Types of training to be delivered, including technical, system, train-the trainer, and end user role-based training;

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

i. Goals for training sessions;

ii. Browser version compatibility;

iii. User Profiles of users to be trained;

iv. Prerequisites for users;

v. Business functions and processes covered in each training session; and

vi. Hours needed for each training session;

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

e. Staffing, including roles and responsibilities to develop and deliver the training;

f. Training activities, tasks, and materials including the timing of the training material development and training delivery;

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

h. Hardware, software, data, and facilities or materials needed to support the training effort; and

i. Training feedback mechanism and training evaluation methods.

j. Job aids must be submitted as part of audits and to

CMS for Certification Reviews and Operational

Readiness Reviews (ORR) as applicable.

D-015 Test Plan Responsibility during DDI Responsibility during O&M

Project Duration in DDI.

Contract Duration in O&M.

• Review and update every SCDHHS approved implementation.

• Review and update every twelve (12) months or when impacted.

Purpose/Description: The Test Plan provides the

Vendor testing strategy that includes resources needed, timescales to be tested, entry and exit criteria, test activities and tasks, and tests to be performed.

SCDHHS to provide entry and exit criteria.

a. Categories of testing to be conducted as appropriate to the technical Solution; at a minimum, Vendor will perform Unit Testing, System Testing

(including error handling), Regression Testing, Integration Testing, Performance Testing, and

Accessibility Testing;

b. Definitions of defect levels;

c. Defect management to include:

i. Processes for identifying, assessing, and prioritizing defects;

ii. Determining effective defect remediation actions;

iii. Monitoring and reporting progress in remediating defects;

iv. Definition of defect categories;

v. Definitions and rating scale of defect severity;

vi. Roles and responsibilities in defect management;

vii. Tools used for the defect management process;

viii. Defect testing and release for testing: and

ix. Procedure for defect management status reporting, including report format;

d. For each test category:

i. Test scope;

ii. Test goals;

iii. Entry and exit criteria;

iv. The acceptance criteria; and

v. Test data needs;

e. Testing activities and tasks;

f. Roles and responsibilities to conduct testing and defect management;

g. Automated testing tools, if any (i.e., specific release and version of the product);

h. Test environment constraints and set up;

i. Tools and mechanisms to track and report test results and defect resolution status; and

j. Formats and information to be included in test results reports as approved by SCDHHS, and the frequency of reports.

k. Test strategies for the DDI and O&M portion of the

Contract will be defined in the respective plan; testing performance standards will be included in the PMP and

Quality Management Plan.

D-016 System Design Document Responsibility during DDI Responsibility during O&M

Delivery Provisions: Contract effective date + ninety (90)

State business days.

The Contractor (Vendor) will update the MMS System

Design Document.

Purpose/Description: The System Design Document describes design goals and considerations, provides a high-level overview of the system architecture, and describes the data design associated with the system, as well as the human-machine interface and operational scenarios.

The high-level system design is further decomposed into low-level detailed design specifications for each of the system’s components, including hardware, internal communications, software, system integrity controls, and external interfaces.

a. Design specifications;

b. System components;

c. Hardware;

d. System integrity controls;

e. External interfaces;

f. High level overview of the system;

g. Testing details (load, endurance, stress, performance, automation);

h. Architectural strategies;

i. Operational scenarios;

j. System architecture (logical, hardware, software, security, performance, etc.);

k. System design (connectivity, bus requirements, inputs/outputs, 508 compliance, detailed design

(hardware, software, and security);

l. System integrity controls; and

m. External interfaces.

D-017 Conduct Gap Analysis Responsibility during DDI Responsibility during O&M

Delivery Provision: The date defined in the SCDHHS approved Vendor project schedule. Date will be after functional designs and JAD sessions are complete.

Project duration in DDI.

• Update if applicable due to impacts from changes.

Purpose/Description: Vendor will meet with SCDHHS to

Conduct Gap Analysis to identify differences between the SCDHHS technical specifications, technical architecture, and requirements for the Solution and the product the Vendor has proposed as the basis of the

Solution Meetings will be conducted onsite at a

SCDHHS location unless a virtual meeting is approved by SCDHHS in advance.

Work with the SCDHHS onsite (preferred) or with virtual sessions to identify:

a. Technical Specifications and Technical Architecture that are satisfied by the Vendor Solution(s);

b. Technical Specifications and Technical Architecture that are not satisfied by the Vendor Solution(s);

c. Solution roles and access permissions; and

d. Changes to workflows as defined during GAP

Analysis meetings.

D-018 Gap Analysis Document Responsibility during DDI Responsibility during O&M

• Update as needed.

• Final updates during implementation.

Contract duration in O&M.

• Update when impacted.

• Review at least once every six (6) months.

Purpose/Description: The Gap Analysis Document provides a point-by-point comparison of each business and technical requirement, and business and technical specification to the corresponding proposed function(s) in the Vendor's Solution. The Vendor will meet with

SCDHHS to conduct gap analysis sessions to identify differences between SCDHHS technical specifications and requirements for the Solution, as defined in this

RFP, and the Vendor Solution.

a. Definition and description of each customization and configuration necessary to the proposed product for the Solution(s) to meet SCDHHS specifications, including any associated costs for specifications identified during Gap Analysis that were not part of the Contract; and

b. List of Solution roles and access permissions.

D-019 Solutions Requirements Document Responsibility during DDI Responsibility during O&M

Delivery Provisions: The date defined in SCDHHS

• Update as applicable after the detailed design is complete.

• Final updates during implementation.

Contract duration in O&M.

• Review and update each time the document is impacted.

Purpose/Description: The Solution Requirements

Document provides detailed requirements for the

Solution, including Configurations and Customizations, needed to meet all SCDHHS requirements and specifications for the Solution.

a. Detailed requirements and specifications for all

Solution configurations and/or customizations to include system functions, error handling, performance, interfaces, security, reports, queries, and forms;

b. Each requirement/ specification should be understood by users, operators, or other external systems; and

c. Each requirement /specification will contain:

d. Unique requirement tracking identifier;

e. Detailed and unique title;

f. Detailed description sufficient to enable design staff to design a Solution to satisfy SCDHHS technical specifications and requirements for the Solution, as defined in the Contract, and testers to test that the

Solution satisfies the requirements;

g. Assumptions and dependencies; and

h. Prioritization of the requirement/ specification as either critical/essential, conditional, or optional.

D-020 Solution/Sprint Backlogs (as appropriate or defined in the proposed project delivery method)

Responsibility during DDI Responsibility during O&M

Solution Backlog : Primary

Vendor with SCDHHS input

Sprint Backlog: Vendor

SCDHHS input

Delivery Provisions: The dates defined in SCDHHS

• Update as needed for Sprint Planning.

• Final updates during implementation.

Contract Duration in O&M.

Part of the Development and Testing Annual Firm Fixed

Price with Monthly Payments.

Purpose/Description: The Solution and Sprint Backlog is a compiled prioritized list of User Stories and technical tasks that must be done to complete the whole project.

The Backlog breaks down each of the User Stories/tasks on the list into a series of steps that guides the development team. There must be a duration, so the team knows when to start the task and how long they have until they must finish it. The Sprint backlog is a subset of the Solution backlog. The Sprint backlog comes from the Solution (i.e., Product) Backlog, but it contains only that item, or those items, that can be completed during each sprint.

SCDHHS will meet to provide prioritized information as needed to the Vendor.

a. Identifies the Sprint Cycle.

b. Identifies the specific tasks and User Stories.

c. Identifies who is assigned to the task/User Story.

d. Identifies the status of the task.

e. Identifies the timeframe it will take to complete the tasks/User Stories.

D-021 Use Cases Responsibility during DDI Responsibility during O&M

• Continuously as each function is developed

• Refined after technical test execution.

• Refined after UAT execution

• Final updates during implementation.

Contract duration in O&M.

impacted by a change.

Purpose/Description: A Use Case captures the user's point of view while describing functional requirements and specifications of the system. They describe the step-by-step process a user goes through to complete that goal using a software solution. Use Cases may be included in the Solution Requirements Document.

a. Describes how the use case starts and ends;

b. Describes what data is exchanged between the actor and the use case;

c. Describes the flow of events, not only the functionality;

d. Describes only the events that belong to the use case, and not what happens in other use cases or outside of the system;

e. Details the flow of events-all "what's" should be answered. Remember that test designers are to use this text to identify test cases; and

f. The following elements:

i. Actor - anyone or anything that performs a behavior (who is using the Solution)

ii. Stakeholder - someone or something with vested interests in the behavior of the

Solution

iii. Primary Actor - stakeholder who initiates an interaction with the Solution to achieve a goal

iv. Preconditions-what must be true or happen before and after the use case runs.

v. Triggers - this is the event that causes the use case to be initiated, post conditions, system impacted, title of use case, and date created.

vi. Main success scenarios [Basic Flow] - use case in which nothing goes wrong.

vii. Alternative paths [Alternative Flow]-these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.

D-022 User Stories Responsibility during DDI Responsibility during O&M

SCDHHS input

Primary Vendor with

SCDHHS input

• Continuously as each function is developed.

• Refined after technical test execution

• Refined after UAT execution

• Final updates during implementation.

Contract Duration in O&M.

Purpose/Description: A User Story provides a short simple description of a feature/function/requirement/specification from the user perspective. SCDHHS will provide subject matter experts capable of providing the following content to the Vendor. The

Vendor will record the outcomes in the User Stories deliverable based on content provided in facilitated meetings.

a. Describe who is performing the function(s) described in the User Story. This is typically a job role, customer, or other type of user, also known as the user persona.

b. Describe the goal that the user wants the product to accomplish or implement.

c. Describe why the user needs the feature or functionality.

d. Lists acceptance criteria for use when testing the User

Story.

e. May include any estimation and prioritization needed for Sprint planning purposes.

D-023 Requirements Traceability Matrix Responsibility during DDI Responsibility during O&M

SCDHHS input

Primary Vendor with

SCDHHS input

• Continuously as each function is developed.

• Refined after technical test execution.

• Refined after UAT execution

• Final updates during implementation.

Contract Duration in O&M

Purpose/Description: The Requirements Traceability

Matrix (RTM) is used to ensure that each system specification (functional and non-functional) in the Contract is traced to a system requirement(s), detailed design specification(s), test cases, Test Scripts, testing results, and an indication whether it is prioritized for implementation in a

Solution release. The RTM will cross-reference each desired system specification(s) listed in the Contract to a system function/feature and track each system specification in the Contract from development through implementation.

Vendor will provide the Requirements Traceability Matrix in a format that is compatible with JIRA.

SCDHHS will meet with Vendor on site in the Jefferson

Building or virtually via MS Teams to answer questions related to the development and refinement of the RTM.

a. Information on every testable system specification in the Contract;

i. Requirement ID

ii. Requirement Type

iii. Requirement Description

iv. Success Criteria

v. Use Case or Story ID

vi. Use Case Description

vii. Status

viii. Priority

ix. Functional Design Specification

x. Architectural Design Specification

xi. System Components

xii. Software Module(s)

xiii. Interface Requirements

xiv. Unit Test Case ID

xv. Unit Test Case Description

xvi. Integration Test Case ID

xvii. Integration Test Case Description xvviii. UAT Test Case ID

xviv. UAT Test Case Description

xv. Comments

b. Solution requirements for system specifications in the Contract and date accepted;

c. Design specification(s) for each system requirement and date accepted;

d. Technical test case(s) and Test Script(s) for each system requirement;

e. The date and results of all tests performed to verify that contractual specification and/or performance levels have been achieved or exceeded; and

f. User acceptance test case(s) and for each requirement, an indication of whether the testing for the requirement was accepted, and acceptance date; and

g. Date implemented.

D-024 Physical and Logical Data Models Responsibility during DDI Responsibility during O&M

• Update during the implementation of iterations approved by SCDHHS for implementation.

Contract duration in O&M.

• Review at least once every six (6) months

• Update each time the document is impacted by a change.

Purpose/Description: The Physical and Logical Data

Models graphically illustrates Solution database objects and the relationships between those objects.

a. All objects in the database;

b. Table Structure Details for the physical data model;

c. Unique identifier for each object;

d. Attributes for each object; and

e. Relationship each object has with other objects, attributes, or entities.

D-025 Data Dictionary Responsibility during DDI Responsibility during O&M

Purpose/Description: The Data Dictionary will define the basic organization of the Solution database. The Data

Dictionary can be generated through automated means.

• Update during the implementation of iterations approved by SCDHHS for implementation.

Contract Duration in O&M.

• Review at least once every six (6) months

• Update each time the document is impacted by a change.

a. Name

b. Type

c. Range of values

d. Source

e. Origin

f. Usage format

g. Relationship to other data elements

h. Formulas

i. Risks/limitations

j. Authorization for access for each data element in the database.

D-026 Data Conversion and Migration Plan Responsibility during DDI Responsibility during O&M

The plan must be submitted to SCDHHS for approval twenty

State business days in advance of implementation.

Purpose/Description: The Data Conversion and

Migration Plan explains the methodology and strategy for converting and migrating data from the…