doc

EDS AGREEMENT NUMBER [XXXX]CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABIL ITATION (CDCR) EXHIBIT IMANAGEMENT REQUIREMENTS RESPONSE

6.6 Implementation

Subsection 6.6: Implementation

This subsection must include a narrative describing the QBP’s approach to implementation, interface management, and data conversion; and sample Implementation, Interface Management and Data Conversion Plans used by the QBP on another project or projects as described in Section VI.D.9 – Implementation

VI.D.9.Implementation

Req.

Num.Requirement Response / Reference

M-56 The Contractor shall describe the implementation approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the implementation approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 4.2.D,

Section 6.1,

Vol 1 – Appendices

Appendix A,

Section 6.8

Bidder Response Detail:

Team EDS’ approach to implementing the Strategic Offender Management System (SOMS) is framed by our strategy to roll out functionality incrementally and by our overall Project Management Version 2 (PM 2®), EDS’ Project Management methodology. Section 4.2.D, Phasing, describes our incremental rollout of SOMS and explains the rationale for our phasing plan and its dependencies, constraints, and schedule. Meanwhile, Section 6.1, Project Management, and our draft Project Management Plan, Appendix A, describe our approach to managing SOMS as a project consisting of the following nine projects:

Project Management Office (PMO) – startup, operation, and closing of the PMO

Infrastructure delivery – assessment and deployment of the enterprise system architecture and related infrastructure needed for delivery of each project and its associated components, including hardware, software, and tools for the five system environments

Electronic Records Management System (ERMS) –conversion of existing paper documents contained in C-files, parole field files, and juvenile files into electronic images; procedures for “day forward” processing of paper documents

Phase I/Release 1A – configuration and implementation of the initial business functionality for adult institutions (Intake, Movements, and Scheduling functions)

Phase I/Release 1B – configuration and implementation of additional business functionality for adult institutions (functions include: Sentence Calculation; Classification; Programs; Gangs; Holds, Wants, Detains; and Discipline)

EDS SOMS STATEMENT OF WORK EXHIBIT I -262


Phase I/Release 1C – configuration and implementation of remaining business functionality for adult institutions (functions include: Transportation, Property, Visits, Appeals and Grievances, and Administrative processes)

Phase II/Release 2 – configuration and implementation of adult parole and pre-parole processes

Phase III/Release 3 – configuration and implementation of business functionality for juvenile institutions and juvenile parole offices

Maintenance and Operations – establishment of production support for the SOMS project and transitioning of system operations to the State of California Department of Corrections and Rehabilitation (CDCR).

Figure 6.6-1, Implementation Approach, illustrates our phasing strategy and presents our overall deployment schedule for the nine SOMS projects. For each project, Team EDS will submit to CDCR a detailed Implementation Plan that follows the overall implementation approach summarized in Figure 6.6-1.

Year 1 Year 2 Year 3 Year 4 Year 5

Program Planning and Initiation

Phase I : Adult Institutions

Phase I I : Adult Parole

Phase I I I : J uvenile Operations

Electronic Records Management System (ERMS)

Maintenance & Operations

Year 1 Year 2 Year 3 Year 4 Year 5

Program Planning and Initiation

Phase I : Adult Institutions

Phase I I : Adult Parole

Phase I I I : J uvenile Operations

Electronic Records Management System (ERMS)

Maintenance & Operations

Intake, Movements, Scheduling

Juvenile Institutions and Parole

Pre-Parole and Parole Operations

Transportation, Property, Visits, Appeals, Administrative Functions

Sentence Calculation, Classification, Programs, Gangs, HWDs, Discipline

PMO Startup

Production Support

Adult Institutions

JuvenileInstitutions

Parole

Transition & Acceptance

Warranty

1A

1B

2

3

1C

Infrastructure

Figure 6.6-1, Implementation Approach

Our approach to implementing the SOMS projects is founded on our tracks-based approach to aligning work activities and organizing the Delivery team. For our tracks-based approach, we assign a dedicated team to each of the distinct activities required to implement SOMS; for example, one track lead oversees the team responsible for software configuration, a second lead oversees the team

EXHIBIT I -263 EDS SOMS STATEMENT OF WORK


focused on data conversion, a third is assigned to interfaces, and so forth. Using our tracks-based approach, implementation is a separate track that is managed by an experienced Implementation team, which focuses solely on implementation planning and system rollout. The tracks-based organizational structure affords integration with activities that are interdependent with implementation, such as infrastructure readiness, software configuration, interface development, and data conversion. Through this approach, the implementation manager directs implementation activities, drawing resources from track leads as needed. Figure 6.6-2, Activities to Support Implementation Management, identifies the framework and activities involved in implementing the SOMS project and illustrates how various tracks support the overall implementation of each project.

Figure 6.6-2, Activities to Support Implementation Management, shows that our implementation of each SOMS release involves specific tasks in three general categories of activities: cutover planning, pilot testing, and rollout activities. In carrying out implementation activities, track leads and the Project Management Office provide expertise and support in the areas of change management, communication, training, documentation, operational support, testing, data conversion, and configuration management. Throughout the implementation cycle, the Implementation Plan specifies tasks and responsibilities to monitor and evaluate progress, confirm quality and manage the rollout of each SOMS release. A final implementation activity supported by the Project Management Office is to conduct a post-implementation review to make sure the release met the goals specified in the Implementation Plan, and to provide input into subsequent projects/phases.

Change Management

Communication Training Documentation Support Testing Data Conversion

Configuration Management

Conduct Readiness

Assessment

Conduct Communications

Assessment

Conduct Needs Analysis

Develop Strategy & Plan

Conduct Support Assessment



Conduct CM Assessment




Develop Templates & Standards

Develop Strategy & Plan Prepare

Test Plans

Develop Decommission

Strategy


Deliver Change Management Workshops

Develop Communication

Material

Develop Training Material

Develop Business/Tactical Documentation

Develop Service Level Agreement

Coordinate Test Data

Conduct Data Analysis Design

Build Environments

Review BusinessProcess

Conduct Train-the-Trainer Workshop

Develop Online Help

Select Help Desk Software

Conduct TestingDevelop & Test

Data Conversion Programs

Support Environments

Align Business Processes

Deliver Training Maintain Documentation

Establish Help Desk

Support UAT Manage Conversions

Develop CM Documentation

AlignOrganization

Evaluate Training

Manage Ongoing Support

Validate Software in Production

Rollout Production

Monitor and Evaluate Progress Ensure Quality Manage Cutover

Determine Cutover Approach Determine Pilots Develop Implementation Strategy



Figure 6.6-2, Activities to Support Implementation Management

Determine Cutover Approach

The first set of activities in our implementation approach involves planning the cutover of each SOMS release. Team EDS will plan the rollout of each SOMS release by first conducting a readiness assessment. As part of the readiness assessment, our team will examine infrastructure readiness and overall organizational and business process readiness. Thus, outputs from Business Process Management activities provide essential input into the readiness assessment.

Outputs from the readiness assessment serve as input into the infrastructure delivery project and the On-Site Implementation Support Plan and shape the Change Management, Risk Management, and Training Plans. In conducting the readiness assessment for the Electronic Records Management System (ERMS), for example, our team evaluates network bandwidth, confirm availability of equipment at the institutions, validate business process changes involved in rolling out software release, and assess staff preparedness for the cutover. The Project Management team use outputs from the readiness assessment to integrate activities across projects and across track domains, including business process and change management, training, data conversion, testing, and software configuration. In accordance with the requirements of the Request for Proposals (RFP), we submit a Pre-Implementation Readiness Assessment document before CDCR’s user acceptance testing (UAT).

In planning system cutover, a primary area addresses the challenges of coordinating data conversion with cutting over to the new system. Depending on details we learn in the Business Process Management activities, one alternative could be that we disengage legacy systems at the time we begin data conversion, and we cut over to the new system after data conversion is completed. Factors that weigh into coordinating data conversion with the cutover include the duration for data conversion, the impact of “freezing” the legacy system during the data conversion process, and the degree of on-site involvement for data conversion and cutover activities. If the duration of data conversion and the corresponding legacy system “freeze” is projected to negatively affect prison or parole operations, our team may mitigate the issue by engaging a two-step data conversion process, whereby users continue to use the legacy system while historical data is migrated. Then, just before cutover, we would make a second pass through data conversion to migrate recently entered data, disabling the legacy system only during the relatively brief second pass.

Determine Pilot Testing Approach

Team EDS will work with CDCR’s Project team to identify the locations in which we will conduct short-term pilot tests of the software release. During each pilot test, Team EDS works closely with institutional liaisons to test the release in parallel with legacy systems. Pilot tests will last no more than one week; depending on results of the pilot test, the team may determine that a second or third iteration of pilot testing is required. At the close of pilot testing, pilot test



data will be discarded and the team will commence a limited scale rollout of the release, at which time, three institutions cut over to the new software. Implementing the release on a limited scale enables Team EDS to focus implementation resources at the three institutions, not only to be able to resolve implementation issues promptly, but also to prepare the Implementation team for full-scale rollout at all CDCR institutions. Our Implementation Plan determines the precise duration and location of limited scale rollout; based on our experience with previous implementations in other states, we anticipate the three-institution-implementation period to require between two weeks and four weeks.

Develop Implementation Strategy

Team EDS’ implementation manager will work with the CDCR Project team to develop a comprehensive, detailed Implementation Plan using our proven PM2® methodology. Our Implementation Plan draws on extensive experience of implementing our commercial off-the-shelf (COTS) solution in other state departments of correction, with detailed tasks based on CDCR pilot testing and associated lessons learned. As we have stated, Team EDS follows a two-step implementation approach whereby we deploy each release at three institutions in what our plan refers to as “limited-scale production rollout.” After full acceptance of the limited-scale rollout at the three institutions, our team will proceed to roll out the release at all sites. Our Implementation Plan describes how we engage CDCR staff for both limited scale and statewide rollouts; for example, at adult and juvenile institutions, a member of Team EDS will be on site at each location, working side by side with CDCR institutional liaisons and users. Depending on outputs from the “determine cutover approach,” the Implementation Plan will involve a concurrent, statewide rollout or, if conditions warrant, a rapid “rolling wave” of institutional deployments. For example, if we determine that multiple EDS team members are needed on site to cut over individual institutions to the release, we would propose a rolling wave implementation approach whereby we implement the release at a subset of sites concurrently, to achieve statewide deployment over the course of several weeks.

Monitor and Evaluate Progress

Team EDS formally monitors and evaluates progress with each incremental rollout of functionality. We determine the approach to monitor and evaluating the success of the implementation as the project unfolds. Through daily reports, we monitor implementation success at both the project and stakeholder level using strategies that we constantly update when the desired result is not being achieved. Our Project Management Plan specifies the format and frequency of progress reports according to the requirements of the SOMS contract.

Manage Quality

In the course of rolling out each release, the implementation manager and our quality manager jointly execute the Quality Management Plan, which we describe in Section 6.8, Quality Management. Employing our Global Applications Delivery Quality Management System (GAD-QMS), the quality manager defines specific qualitative measures in the Implementation Planning phase and will carry out activities to expose and document shortcomings early and throughout the



implementation process. Our GAD-QMS methodology confirms systematic analysis and reporting of qualitative aspects to enable the Implementation team to take prompt corrective action.

Manage Cutover

Before cutover, we document and monitor detailed checklists of all business and technical readiness activities. EDS’ Implementation team will work with CDCR business experts and the Project team to take on this responsibility and drive activities through to completion before the cutover date. During cutover, Team EDS will direct the maximum number of resources available to implementation activities, including all training and business process management staff. The help desk serves as a central point of contact for on-site liaisons and field staff to report issues during the implementation cycle. Using service desk software from Computer Associates, the help desk logs all reported issues, thereby enabling the implementation manager to direct issue resolution and to communicate progress and issues.

Conduct Post-Implementation Review

The purpose of the post-implementation review is to gather lessons learned for use with future releases. The goal is to obtain useful feedback about the effectiveness of the methods we use in each implementation area. Team EDS will gather, analyze, and document the data and provide CDCR with recommendations that can be incorporated into future implementations.

The following is a list of sample implementation tasks that will be defined in the Implementation Plan and repeated for each SOMS release:

Create a Site Preparation Checklist

Install Required Hardware and Software

Implement all Security Changes

Provide Training to Site Staff

Convert Data

Conduct Implementation

Evaluate System Performance

Provide Application Support and a Help Desk.

At the core of our implementation approach is the integration and use of our structured, proven project management policies. By using an integrated approach to project management, the Implementation team will have ready access to the same tools, methods, and procedures used by the Project Management Office for overall management of the project. This will hasten the identification, resolution, and mitigation of issues and risks, thus enabling the project’s overall success.



VI.D.9.a. Implementation Plan Requirements

Req.


M-57 The Contractor shall incorporate the implementation approach into a comprehensive Implementation Plan. CDCR requires incremental deliveries of functionality to the production environment. CDCR anticipates considerable collaboration with the Contractor in the plan’s construction, with particular attention to high complexity components of the existing Offender Management Systems as well as the proposed solution. The Implementation Plan shall:

Deliver solutions that include a significant portion of the technical infrastructure early in the schedule, without compromising the quality or inherent security of the solution. This should also validate the design and architecture.

Expose technically challenging areas of the project as soon as possible. New external interfaces, data conversion, and complex existing Offender Management code being impacted by the new solution, should, where possible, be deployed early in the Project.

Deliver customized functionality to CDCR in incremental pieces that are in logical business application sequence.

Include a deployment schedule developed in cooperation with CDCR that ensures continuous, uninterrupted Offender Management support throughout the project.

The Bidder must submit a sample Implementation Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.


Appendix L,

Section 4.2


Appendix L contains a sample Implementation Plan that is representative of the actual Implementation Plan Team EDS will provide to CDCR for the SOMS project. The sample plan, drawn from Team EDS’ successful CalWorks Information Network (CalWIN) project, illustrates the structured approach Team EDS will take on the SOMS project.

Working with the CDCR Project team from the start of the project, Team EDS will comply with the requirements outlined in RFP Requirement M-57 and adjust the plan as needed to clearly document a detailed Implementation Plan.

As we have explained, our tracks-based organizational approach to implementing SOMS assigns highly skilled technical staff to focus on specific implementation activities, such as interfaces, data conversion, and data bridging. As a result, we can “flesh out” issues associated with technically challenging aspects of SOMS as early as possible; for example, determining a cutover approach early in the



project identifies the technical and procedural challenges of coordinating data conversion with the cutover to new software. As we mentioned in Section 4.2, Phasing, the sequence of functions delivered in individual software releases conforms to logical dependencies and provides for incremental delivery of SOMS functionality. Team EDS will work closely with CDCR project staff to adjust and confirm functional makeup of software releases and the associated deployment schedule. Our team will support functionality provided through each individual release, including all system interfaces, reports, and data bridges until the official closing of the entire SOMS project.

As we describe in Section 4.2.D.3, Impact on State Resources, Team EDS will work with CDCR to designate one SOMS project liaison and one backup at each site. Team EDS will engage institutional liaisons throughout the SOMS project, with the liaisons serving as key points of contact to coordinate on-site activities with Team EDS. Based on our experience in other states, we anticipate institutional liaisons will need to allocate four to six hours a week to assist with the SOMS project; however, in the week before and after implementation of each release, institutional liaisons must allocate approximately half of their work time to the SOMS project. During these brief implementation windows, Team EDS will station implementation staff to work alongside institutional liaisons to foster smooth implementation of the release. Similarly, to prepare for rollout of parole functions, CDCR must designate a liaison for each parole office to assist the Project team with implementation activities.

VI.D.9.b.Capacity Planning Requirements

Req.


M-58 The Contractor shall develop a Capacity Plan (in coordination with the existing DTS Capacity Plan) to include, at minimum, the following areas:

A description of how system capacity and capacity requirements were calculated, including all formulas and calculations used in capacity planning for SOMS.

A description of how SOMS capacity requirements will be met.

How capacity issues will be managed for all components of the SOMS project.

Descriptions of how capacity utilization will be monitored and capacity thresholds will be established.

A description of corrective and escalation processes that will be used in the event any capacity thresholds are reached.


Appendix K,

Section 5.0


As a world leader in infrastructure and system management, EDS brings to the SOMS project a wealth of capacity planning experience and technical resources.



Our team will provide CDCR with a capacity plan that is fully coordinated with Department of Technology Services (DTS) standards and guidelines and that meets all requirements specified in RFP Requirement M-58. Appendix K contains a sample Capacity Plan drawn from EDS’ CMIPS II project, and Appendix L contains a sample Implementation Plan from our CalWIN project. The Capacity Plan we submit to CDCR is tailored specifically for the SOMS project; it describes our detailed approach to determining capacity and explains how our team sets performance and capacity thresholds, monitors utilization levels, and provides procedures and timelines for resolving or upgrading capacity. EDS will work jointly with CDCR and DTS to create procedures for escalation in the event that capacity planning forecasts indicate a need for system expansion.

Our capacity planning activities forecast server, storage, and network resource requirements for hosting each SOMS release to objectively anticipate how the applications will perform before they are put into production. These activities help us to match the appropriate server, storage, and network sizing to system needs and make the most efficient use of resources. Effective capacity planning avoids capacity shortages as well as costly underutilization of resources.

Our capacity planning and evaluation take the following into consideration:

The system’s architecture, related best practices, and product vendors’ relevant sizing models for systems following standard architecture, design patterns, and load conditions

Performance and scalability models gathered from tests executed

General system requirements, such as target response time

Concurrent number of users, transaction volumes, usage scenarios, and trends

Availability requirements

Data volumes

Growth factors for both usage and data.

EDS will conduct performance tests of the SOMS releases not only to validate the performance of each release, but also to provide metrics to feed the SOMS capacity plans to forecast impact on the production environment. While conducting performance tests, we collect a wide variety of infrastructure metrics through our performance testing tool, HP LoadRunner, and use them as inputs for our capacity planning tools. The initial SOMS infrastructure architecture defined in this proposal was created in this manner, using information gathered from our benchmarking exercise of the proposed offender management COTS product in conjunction with other sizing information.

Once in production, the SOMS Enterprise Monitoring System (EMS) provides an additional source of information for the project’s capacity planning models. The SOMS EMS includes Computer Associate’s eHealth, a tool that collects utilization information about servers, network components, storage, database, and application servers through real-time agents deployed systemwide. eHealth provides a centralized data store for SOMS performance metrics. Over time,



eHealth creates a baseline of expected utilization levels for each system component, which automatically alerts the SOMS infrastructure staff if system metrics are not within an expected range. Acceptable levels of utilization are defined by individual component, based on industry standard practices; for example, a server may be considered saturated if operating at levels above 80 percent utilization for extended periods of time, whereas a network circuit may have a lower acceptable utilization level due to performance degradation considerations. In addition, eHealth includes patented algorithms to forecast individual component utilization into the future to allow proactive remediation of resources before users are affected. Section 5.0, Technical Requirements Response, provides additional information about our use of the EMS toolset.

EDS’ SOMS solution deploys capacity and performance monitoring components early in the project to support the onset of document scanning operations and data conversion efforts. Early deployment of infrastructure components enables monitoring of system utilization as SOMS functionality is incrementally added to the system with each software release. Early deployment, combined with our proposed phased approach, facilitates early detection of additional capacity needs before users are affected. In addition, our phased approach also fosters the ability to validate our design early in the process, which reduces project risk.

One of the important outputs of our capacity planning activities is a proposed deployment architecture together with sizing estimates for servers, storage, and network bandwidth. Provided that the input data is fairly accurate in creating a realistic picture of the system under normal production setup, this exercise should provide CDCR and DTS with an accurate sizing estimation for various computing capacities (servers, storage, and network).

Our tracks-based approach assigns infrastructure management as a separate track within the Delivery team. As a result, system architects and technical experts focus on system capacity issues from the start of project, establishing the system infrastructure and exposing technical challenges as early as possible in the project.

VI.D.9.c. Operational Recovery Requirement

Req.




M-59 Disaster recovery requirements relative to the physical systems and planning for recovery from operational failures are not the responsibility of the Contractor. However, the Contractor’s knowledge of the system solution will be helpful in CDCR’s business continuity and disaster recovery planning. The Contractor shall develop an Operational Recovery Plan that addresses the following:

The SOMS solution will ensure 99.99% availability.

Areas of the SOMS system most susceptible to failure or disaster that would result in downtime.

Recommendations for system recovery processes, or steps to take in the event of a downtime event.

Recommendations for CDCR on how to comprehensively and effectively mitigate the risk of a downtime event.

Recommendations for securing the system during a period of emergency operation.


Appendix F


To aid CDCR with business continuity and disaster recovery (DR) planning, Team EDS will provide CDCR with an Operational Recovery Plan that meets the requirements specified in RFP Requirement M-59. We provide a sample Operational Recovery Plan in Appendix F of our response.

Team EDS’ Business Continuity and DR approach builds on industry leading practices, which we draw both from our own experience of serving similar governmental entities and from standards adopted by groups such as the Federal Financial Institutions Examination Council (FFIEC) and the two DR certifying groups, Business Resilience Certification Consortium International (BRCCI), Certified Business Resilience Professional (CBRP) certification and Business Continuity Institute (BCI certification). Managing business continuity and DR requires a careful balance of prevention, readiness, and recovery strategies and procedures. The following table, Table 6.6-1 Basic Approach, outlines the basic steps of our approach.

Table 6.6-1 – Basic Approach

Recovery Requirements Risk Prevention

Definition of availability and recovery requirements for essential business functions and processes of an organization, and the resources and services required to support them.

Proactive measures intended to reduce the risk of threat occurrence and the likelihood of invoking recovery plans.

Recovery Preparedness Recovery/Restoration

Proactive measures should also help ensure that recovery procedures and arrangements will work efficiently and effectively if recovery plans must be

Arrangements and procedures that are verified and held in readiness to recover essential business functions and processes and the critical support services, facilities, resources,



invoked. and equipment on which they depend.

EDS embraces the best practices and recommendations of the Information Technology Infrastructure Library (ITIL) across all aspects of service delivery and support. The ITIL incorporates information technology (IT) operational recovery, which is addressed within what ITIL terms IT Service Continuity Management. In delivering the Operational Recovery Plan, which forms a part of CDCR’s overall Business Continuity Plan, we draw extensively on our ITIL expertise and experience. Figure 6.6-3, IT Service Continuity Process Map, outlines the EDS top-level process map for IT service continuity management, compliant with ITIL.

Change ManagementChange

Management

Change ManagementChange

Management

Change ManagementIncident

Management

I TSCM Assessment Completed

ITSCM Plan Initiated

ITSCM Exercise Schedule

Time Trigger

RFC Requested

Execute ITSCM Plan

Change Closed

Develop,Maintain & Implement ITSM Plan

Perform Analysis & Determine Impact

Update & Approve ITSCM Strategy & Plan

Measure & Manage Risks

Perform ITSCM Awareness

Exercise / Execute ITSCM Plan

Schedule & Prepare Exercise

Execute ITSCM Plan

Perform ITSCM

Exercise

Identify Restoration

Activities

Analyze & Document Results

Updates to ITSCM Plan

ITSCM Plan Time Trigger

ITSCM Assessment

Required

ITSCM Plan Updated

Exercise of ITSCM Plan Necessary

Manage ITSCM

Escalation

Minimum Service Level

Restored

Process Result or Time Trigger

Linked Process

Activities

Figure 6.6-3, IT Service Continuity Process Map

In conjunction with the DR and business continuity planning, the Operational Recovery Plan takes into consideration the potential business impact of SOMS service interruptions and underlying risks. The Operational Recovery Plan addresses the following:

Areas of SOMS most susceptible to failure

Manual work-around procedures (required in the short term if system failures occur)

Prioritization of the operations to be maintained and how to maintain them



Recommendations for system recovery processes and the steps required to put the operational recovery procedures into effect

Documentation of the actions and the activities needed to resume business

Identification of mission-critical business processes and recovery requirements

Recommendations of actions to reduce risk during a downtime event

Recommendations for securing SOMS during emergency operations.

VI.D.9.d.Interface Management Requirements

Req.


M-60 The Contractor shall describe the interface management approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the interface management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

N/A


Team EDS employs a structured, end-to-end approach to developing and administering interfaces. Our success-proven approach to interface management is founded on:

Interface Governance

Optimal management of interfaces begins with our tracks-based alignment of work activities, whereby we establish a team dedicated solely to interface development and administration.

The Interface track consists of a track lead, EDS subject-matter experts (SMEs), developers, and testers and encompasses the following:

Finalizing interface requirements

Defining interface specifications and protocols

Verifying and finalizing interface specifications

Building interfaces

Developing interface test scripts

Testing internal interfaces

Testing pilot interfaces with partners

Updating user and technical documentation.



The Interface track lead assigns SMEs to work with external agencies to open channels of communication and to document laws, policies, and security requirements governing interfaces. In the course of defining a Statement of Work (SOW) for each interface, SMEs establish Inter-Agency Agreements (IAAs), Memorandums of Understanding (MOUs), and Service Level Agreements (SLAs) that clarify responsibilities between the organizations and define the protocol for identifying, escalating, and resolving interface issues. The Interface Management Plan describes protocol for Team EDS to prepare and present a draft of each MOU, IAA, and SLA and interface SOWs to CDCR’s SOMS Project team. The CDCR SOMS Project team will then be responsible for securing signoff of the agreements before our team implements the interface. While SMEs are defining the business context for interfaces and securing formal agreements, interface analysts assigned to the interface track work with CDCR staff to document existing interfaces and leverage sophisticated tools to discover, map, and document existing interfaces and application programming interfaces (APIs). Thus, our tracks-based approach allows specialists to focus their expertise on the detailed tasks associated with constructing interfaces, while the track lead works collaboratively with other track leads, orchestrated by the implementation manager, to coordinate requirements definition, testing, implementation, and operating interfaces.

During Phase 0 of the SOMS project, the Interface track lead finalizes an Interface Management Plan that is tailored to CDCR’s specific operational and technical requirements. The purpose of the Interface Management Plan, as we explain in our response to RFP Requirement M-62, is to establish guidelines for developing and managing interfaces, during the SOMS project and beyond. A second Phase 0 objective for the track lead is to create for the Interface team a Responsibility Assignment Matrix, which outlines specific task responsibilities and deliverables for team members.

With many years of experience in integrating complex, disparate systems in a number of technical environments, Team EDS is well positioned to meet CDCR’s interface requirements. For example, EDS’ integration and service-oriented architecture (SOA) methodology is a state-of-the-art “body of knowledge” built over the past 14 years and using cutting-edge technologies and best-practice techniques. Our corporate methodology includes planning, execution, and monitoring of activities that provide consistent, repeatable procedures for our team to efficiently manage interfaces while mitigating risks to the SOMS project. The phases of interface management, from definition through operation, together with specific activities and key deliverables, are shown in the following tables:

Table 6.6-2 – Integration and SOA Methodology Phases

Integration and SOA Methodology – Define Phase

High-Level Activities



Develop the Integration Plan

Develop the Metrics Plan

Establish a Communication Plan and channels with interface owners

Establish SLAs and MOUs

Establish governance and security policies

Gather integration and SOA requirements

Determine the interface identification approach

Gather user-centered design requirements

Key Deliverables

Integration Plan

Metrics Plan

Communication Plan

Integration and SOA Requirements Definition

Integration and SOA Methodology – Analyze Phase


Assess the current environment

Identify critical success factors and risks

Identify and prioritize key interfaces and services

Identify candidate services

Develop services recommendation

Analyze artifacts from Team EDS’ past and current offender management implementations

Conduct Joint Application Design (JAD) sessions with CDCR’s technical services group for existing applications with CDCR SMEs

Inspect existing applications: data mine source code, data structures, database schemas, existing interfaces, data extracts, and business rules

Identify standards, protocols, access channels, laws and policies governing the interfaces

Develop an Interface Partner Education Strategy and Plan

Customize and conduct Interface Partner Questionnaire

Develop interface partner profiles

Perform a gap analysis

Define Test Plans and Test Cases

Key Deliverables

Current Environment Assessment

Gap Analysis

Test Plans and Cases

Service Identification and Definition Report

Integration and SOA Methodology – Architect Phase


Validate requirements

Identify alternative solutions

Develop the logical architecture

Develop the technical architecture

Develop the physical architecture

Develop a Bill of Materials

Develop an Integration and SOA Governance Model

Define the Technical Solution Road Map

Key Deliverables

Technical Solution and Road Map

Governance Model

Bill of Materials

Integration and SOA Methodology – Design Phase




Validate interface and service requirements

Design the security implementation

Develop integration specifications

Design services interfaces

Design transformations and service assemblies

Design the business rules implementation

Design the business activity monitoring implementation

Develop contingency plans

Design services management

Define operational support specifications

Develop test specifications

Key Deliverables

Integration and SOA Technical Design

Configuration Management Plan

Development Environment, Processes, and Procedures

Services Design and Development Specifications



Integration and SOA Methodology – Produce Phase


Configure and install the development and unit test environment

Build and document the integration solution

Develop services

Apply security policies

Build the enabling application services

Publish services

Build business rules

Build business activity monitoring

Develop services management

Build end-system simulators

Perform unit testing

Develop operations support documentation

Key Deliverables

Development/Unit Test Environment

Developed Solution

Test Case Results

Operations Support Guide

Integration and SOA Methodology – Optimize Phase


Develop Integration Test Plans, data, and scripts

Configure and install the integration test environment

Implement version control and configuration management

Execute system test cases and scripts

Conduct load and stress testing

Update registry status

Develop end-user and Operations Training Plan

Execute end-user and operations training

Refine operations support documentation

Key Deliverables

Integration and Services Test Environment

System Test Plans and Cases Results

Completed End-User and Operations Training

Integration and SOA Methodology – Implement Phase


Conduct knowledge transfer from the development staff to production support personnel

Develop the Production Implementation Plan

Install and configure the production environment

Migrate the solution to the production environment

Monitor production performance and support problem corrective action

Evaluate and improve integration and SOA intellectual capital

Perform project close-down

Key Deliverables

Production Environment, Processes, and Procedures

Software and Procedure Updates

Project Completion Documentation



Integration and SOA Methodology – Operate Phase


Perform transformation management

Monitor integration operations and services

Perform incident management

Perform problem management

Develop minor enhancements

Perform minor software upgrades

Perform release management

Perform close-down

Key Deliverables

Transitioned Support Processes

Integration and SOA Operations Reports

Managed Integration and SOA Environment

In addition to our structured approach toward interface management, our COTS solution is uniquely equipped to meet CDCR interface needs promptly. The current generation of our COTS offender management system has been implemented in corrections departments in three states. As a result, our COTS solution contains many interfaces that are common to state corrections departments. For example, the electronic Offender Management Information System (eOMIS) currently provides an interface to the Social Security Administration (SSA), the Department of Homeland Security (DHS), National Prisoner Statistics (NPS), National Corrections Reporting Program (NCRP), U.S. Census, and the Association of State Correctional Administrators’ Performance-Based Measures System (PBMS). Moreover, many of the interfaces CDCR requires are similar to interfaces used in other states and are present in eOMIS. Using existing interfaces as templates, our team is able to rapidly deliver California-specific interfaces. Having implemented a large number of interfaces, in other state corrections departments and for the California State Government, our team will promptly overcome challenges unique to CDCR’s interface requirements. Section 4.2.H, Interfaces, highlights specific examples of our team’s successful implementation of interfaces and describes how it has overcome unique technical and organizational challenges. Two examples that are of strategic relevance to SOMS are the following:

A fully operational HL-7-based interface between eOMIS and healthcare providers for the State of Arkansas Department of Corrections.

A real-time Web services interface between the eOMIS inmate banking system and third-party canteen vendors for the State of Kentucky Department of Corrections. This interface has supported the agency’s business requirements of contracting to different canteen vendors at different institutions. Each canteen vendor interchanges data in real time through a single eOMIS interface. This strategy has enabled vendors to deploy order entry kiosks inside prisons, with each vendor’s kiosk directly updating the inmate banking system through the interface.

Interface Technology: Architecture, Tools, and Standards

Our technical architecture and software tools, which we describe in other sections of our proposal, are instrumental in achieving the goal of providing a



stable, well-managed interface environment. Moreover, our awareness and compliance with State of California and national data exchange standards positions CDCR to readily adapt to changing requirements by:

Using current existing operating interfaces, when appropriate

Leveraging open or industry standards, such as eXtensible Markup Language (XML), National Information Exchange Model (NIEM), Web Services, Simple Object Access Protocol (SOAP), WS*, HL-7, and File Transfer Protocol (FTP)

Reducing integration complexity through the enablement of SOA principles

Decoupling applications from each other by creating a layer of abstraction between interface points

Providing powerful and configurable transformation and routing capabilities

Allowing for an integration between systems that communicate using different protocols and mechanisms

Incorporating proven products, such as Oracle SOA suite and the Sypherlink National Information Exchange (NIE) Gateway and Harmonizer

Exposing commonly used services and data through an Enterprise Service Bus (ESB) to share services across the enterprise and to maximize efficient re-use of interfaces

Using the ESB to implement security rules, leverage pre-built interface adapters, and serve as a repository for interface documentation

Our interface environment is based on SOA principles, enabled through an Oracle ESB that aligns with CDCR’s and the State’s vision for enterprise architecture. The ESB is positioned as the key integration component, and data exchanges are modeled using the NIEM specification. By creating a layer of abstraction between system components, the ESB eliminates the need for agencies exchanging data to have technical information about their counterpart’s system environment. Using a nationally recognized standard for data specification minimizes the level and complexity of programming involved in developing and implementing interfaces.

Although the system architecture and NIEM compliance prepare CDCR to exchange data with agencies that are on the cusp of current technology, we realize that the majority of the systems with which SOMS must interface are not currently NIEM compliant. For those interfaces, we implement interfaces that interact within the technical limitations of the reciprocal system; for example, the California Law Enforcement Telecommunications System (CLETS) is a non-NIEM compliant, Transmission Control Protocol / Internet Protocol (TCP/IP) socket interface. Having constructed a National Crime Information Center (NCIC) in other states, Team EDS is prepared to implement a native interface according to California Department of Justice’s (DOJ’s) technical specifications.



M-61 The Contractor shall incorporate the interface management approach into a comprehensive Interface Management Plan. The Interface Management Plan will be used by CDCR to document the plan for integrating the SOMS System with all systems internal and external to SOMS. The Interface Management Plan shall, at a minimum, address the following areas:

The approach to developing and managing internal and external system interfaces.

Technical tools that will be used for data transformation, transport and error recovery.

Tasks, deliverables and resources necessary to complete interface development and implementation.

Description of how the SOMS development and test systems will work with the external interfaces.

References to applicable sections in the relevant design documents that describe how the SOMS system will be synchronized with the specific internal and external interfaces.

References to applicable sections in the detailed design that describe the mappings between internal and external system data and the SOMS system data.

Descriptions of the process for managing changes to the interfaces, both in the production and non-production environments

Interface(s) needed for maintaining data synchronization between an interim production solution and the final production implementation.

The Bidder must submit a sample Interface Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 4.2.H,


Appendix M


The methodology we have described here and in Section 4.2.H, Interfaces provides the baseline approach for Team EDS’ developing and managing SOMS interfaces. Section 4.2.D, Phasing, and Section 4.2.H, Interfaces, of our proposal detail our implementation approach and the interfaces associated with each SOMS release. To gain a better understanding of the intricacies of each interface, our team will work with CDCR staff, technical support staff from Enterprise Information Services (EIS), and CDCR SMEs, who are knowledgeable about the business context of individual interfaces. With our sophisticated tools and our team’s experience, we anticipate relatively minimal CDCR staff involvement. For each interface, we anticipate from 1 to 6 hours of CDCR staff involvement during the initial Definition phase. Throughout each phase of interface development, our team will involve CDCR, but will require minimal allocation of CDCR staff time. As part of interface implementation, CDCR staff will be called on to disengage



existing interfaces from the legacy environment as required. As the project enters the Maintenance and Operations (M&O) phase, EDS staff will provide technical training to equip CDCR staff to take over interface maintenance duties at the close of the project.

Appendix M contains a sample Interface Management Plan from our CalWIN project. The Interface Management Plan, which EDS will submit to CDCR, will be customized to specifically address governance procedures and technical standards for SOMS interfaces. At a minimum, our Interface Management Plan will include the following topics:

Interface Management and Governance

Protocol for Initiating an External Data Exchange / interface

The Interface Management Plan defines the official protocol, consistent with CDCR policy, to establish a recurring exchange of data and connectivity between SOMS and external entities. The guidelines specify information required from external parties to initiate an interface; for example, the Interface team documents the business context for the interface from the perspective of both CDCR and the external entity, how frequently the information must be updated, anticipated security requirements and provisions, and data privacy considerations. The purpose of this section is to establish formal governance and control over the proliferation of interfaces, with the goal of structured development and administration of interfaces and data exchanges.

Protocol for Initiating Internal Data Exchanges and Interfaces

The integrated nature of our COTS solution, and the reporting, business intelligence, and portal components of SOMS, significantly reduces the need for new interfaces among CDCR business units. Users with appropriate security authorization, with support from the help desk, will be capable of generating extract files and importing data into desk top software without involving EIS staff; however, introduction of new third-party software may warrant new interfaces into and from SOMS. The guidelines outline information to be documented, including business context and security or data privacy considerations.

Interface Scope and Service Agreements

The Interface Management Plan provides a checklist of requirements for collecting necessary information and agreements. EDS staff will comply with these guidelines to document business requirements, an interface SOW, policies and laws relevant to the interface, security and data privacy requirements, and formal agreement as warranted by the interface. This section of the Interface Management Plan prescribes criteria for when MOUs, IAAs, and SLAs are required and CDCR’s approval process. The Interface Management Plan treats MOUs, IAAs, and SLAs as formal, official documents to be managed in the same manner as Agency contracts in accordance with CDCR policy. The section also contains MOU, IAA, SLA and scope-of-work templates to foster standardization and to minimize administrative burdens.



Procedures for Maintaining a Library of Interfaces

The Interface Management Plan describes procedures and requirements to properly document all new interfaces, together with change management provisions. Team EDS will comply with these guidelines to establish a repository of all interfaces built for SOMS. Each interface will be fully documented, including business and technical documentation, all of which will be maintained within the ESB infrastructure. Detailed information includes source and target systems and their respective environments, file formats, data mapping and transformation rules, exchange protocols, security rules, data and file replacement and cessation rules, references to program libraries, objects, and source code, points of contact, and escalation and notification rules. Business context, such as copies of SLAs, MOUs, and IAAs, are maintained in the Interface Library. Information from the various sources is reconciled to promote accuracy, completeness, and security of SOMS interfaces.

Interface Communication Plan

A subsidiary to the overall Project Communication Plan, the Interface Management Plan outlines procedures for communicating new interfaces, revisions to interfaces, security alerts and breaches, and general issue notification procedures. This section also describes procedures for notifying administrative staff of issues, database changes, and protocol for requesting interface revision.

Interface Change Management

A subsidiary of overarching SOMS change management, the Interface Management Plan describes interface change management procedures; for example, the section describes procedures for executing and monitoring changes to interfaces and for itemizing components that are interdependent with interfaces.

Interface Technical Guidelines

System environment

The Interface Management Plan provides technical information needed by staff engaged in developing and administering interfaces. Examples of information included in this section include database schema; NIEM-compliant data definitions; Information Exchange Package Documents (IEPD); SOA components; the Justice Reference Architecture; specifications and references for ESB usage; security and authorization provisions; and an inventory, description, and reference for all software tools employed in existing and planned interfaces. This section also defines the platforms used to develop interfaces, the test platforms, quality assurance (QA) and pre-production platforms, and the production platforms that will ultimately host interfaces. As a subsidiary to the Configuration Management Plan, this section documents the entire technology stack of all platforms.



Development and Testing Procedures

The Interface Management Plan describes technical guidelines and programming conventions for development of interfaces, including procedures for data discovery, “mining” of system rules, and data mapping protocols. The guidelines also present samples and descriptions of the artifacts required from each of the interface activities (analyze, design, develop, optimize, implement, and operate). The testing portion of the Interface Management Plan, as an adjunct to the overall Test Plan, dictates mandatory unit and system testing, QA procedures, and migration procedures specific to interfaces. The Interface Management Plan includes an appendix with examples of test environments that simulate external and reciprocal systems, lessons learned from interfaces that have been implemented, and guidelines for testing external systems.

Documentation Requirements

The Interface Management Plan describes the information interface analysts are required to submit to the Interface Library and associated change control provisions.

Interface and Reciprocal System Audits and Synchronization

The Interface Management Plan describes procedures, time frames, and staff responsibilities related to periodic auditing of system interfaces. Audit provisions focus on security and data privacy concerns as well as assessment of data integrity. In the Interface Library, each interface includes a definition of data audit requirements and, when applicable, data synchronization provisions; for example, in the event that an interface audit reveals that a reciprocal system that replicates data from SOMS transmissions has become corrupted, the Interface team follows procedures for escalating the problem and taking corrective action, which may involve resynchronization of data in accordance with the specified synchronization guidelines.

Interim Interfaces

The Interface Management Plan addresses requirements, techniques, and provisions for implementing interim bridges in the course of implementing SOMS phases. Provisions for interim bridges address documentation, testing, and implementation procedures with a focus on relationships between SOMS and legacy system environments, data accessibility, and reporting provisions.

M-62 The Contractor will identify any legacy modifications required for the new SOMS System and external systems to exchange data, and CDCR will be responsible for implementing requested legacy software changes.

Section 4.2.E


Our implementation approach rolls out SOMS incrementally in phases to minimize impact on CDCR operations and users. A key strategy for incremental



yet transparent rollout of SOMS involves transmitting data from SOMS back to legacy systems to enable these systems to continue to function until the entire legacy system is retired. In the first SOMS release, Reception Centers will enter inmate records for new intakes into SOMS instead of into the Offender-Based Information System (OBIS). Because not all components of OBIS will be replaced in Release 1A, we implement an interim bridge with this release, by which we transmit data for new intakes from SOMS to OBIS. When the bridge is implemented correctly, users of OBIS do not realize that the record was not created in the usual manner, and all “downstream” functions operate “as is.”

Team EDS will work closely with CDCR technical staff to develop interim bridges between SOMS and CDCR’s legacy systems. Our team takes full responsibility for developing interim bridges, but will depend on CDCR technical staff to install the bridges into legacy systems and to assist in testing the bridges. As with all interfaces, our team will need as much information as possible about the target system. To the extent possible, bridges from SOMS into legacy systems will use file formats and data exchange mechanisms of existing interfaces to avoid the need to develop custom bridges into legacy systems. Team EDS will develop a bridge with administrative assistance from CDCR staff when no interface into the target system exists (as is the case with OBIS). An additional complicating factor of which our team is aware is the fact that certain legacy systems, such as the Distributed Data Processing System (DDPS), are distributed in multiple locations; consequently, installation of interim bridges into such systems will involve on-site or remote access and thorough testing with individual iteration of the legacy application.

Our implementation approach minimizes the need for changes to CDCR legacy systems; however, each SOMS release retires components of legacy systems, but not always the entire system. For components of legacy systems that are replaced by a SOMS release, CDCR staff, with assistance from EDS, will “disable” data updates into the replaced component. Release 1A, for example, replaces the Inmate Number Assignment component of OBIS. To avoid data integrity problems, for Release 1A, EDS will work with CDCR to “disable” Inmate Number Assignment from the OBIS system, while leaving other parts of OBIS unchanged. We have tentatively identified four legacy applications, OBIS, DDPS, the Corrections Institutions Information Management System (CIIMS) and the Automated Transfer System (ATS), which may require modification to support data bridges. Section 4.2.E, Data Conversion, includes an explanation of how SOMS releases will affect these applications under the heading, “Transitioning to SOMS.” Throughout the course of the SOMS project, EDS will partner with CDCR to comply with the requirements set forth by RFP Requirement M-62.

VI.D.9.e. Data Conversion Requirements

Req.




M-63 The Contractor shall describe the data conversion approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the data conversion approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 4.2.E


Team EDS will employ a structured, time-tested approach to data conversion. Our data conversion methodology is based on best practices that we have acquired from our many data conversion engagements. In addition to our proven approach, our team has direct experience of migrating data from Legacy Offender Management applications into eOMIS, the COTS solution we deploy to meet SOMS objectives. Specifically, our team has successfully managed the conversion of legacy data from multiple sources into eOMIS for the Department of Corrections in the States of Arkansas, Kentucky, and Wisconsin. Team EDS has also successfully delivered data migration services to multiple government entities in more than a dozen states, including the State of California, across various business verticals, such as Motor Vehicles, Elections, Unemployment, Retirement, and Public Health. Our former clients are willing to testify to the effectiveness of our data conversion approach and our dedication to providing business continuity throughout the transition process.

A cornerstone of our data conversion approach is our tracks-based alignment of work activities across the project. Because data conversion efforts are essential to the success of the SOMS project, our tracks-based approach dedicates a complete track to the data conversion effort. This dedication provides visibility, focus, and expertise in completing data conversion within the timeframe required by the SOMS project. To manage all aspects of the data conversions, our data conversion track lead will apply EDS’ System Development Life Cycle (SLC3) methodology within the framework of our Global Application Delivery-Quality Management System (GAD-QMS), both of which we describe in Section 6.0, Management Requirements of our proposal. Combining these structured methodologies in conjunction with our tracks-based organization of staff mitigates risks and provides the framework for project success.

Our approach to data conversion is founded on a combination of technology, experience, expertise, and project management methods. Although each project will vary depending on the source and target, a solid set of practices will make sure each incremental data conversion is successful. Throughout the SOMS project, our Data Conversion team will adhere to the following principles and guidelines:

Clarify and Document Conversion Objectives

Our team will begin data conversion activities by documenting the objectives of the undertaking. We focus on migration requirements; potential risks and obstacles, such as multiple locations of source data; and business context related to the effort.



Collaborate With CDCR

Partnership and collaboration are essential to the conversion effort. For each release, our data conversion track lead coordinates activities with the implementation manager and maintains close communications with CDCR staff involved in data conversion activities. To meet the required timeframe, CDCR will have to designate technical points of contact (POCs) for each legacy environment. Our data conversion analysts work directly with technical POCs to gain a rapid understanding of the legacy environment, business rules, constraints, and challenges. CDCR SMEs will also be instrumental in providing business context associated with each legacy system. Team EDS knows from experience that open communication, such as frequent reviews, is a major factor in early identification of potential problems. CDCR staff will be responsible for providing access to needed data from legacy systems that will contribute data to the SOMS database. Team EDS may need to access the data directly from the legacy system or from a mutually agreed upon extraction process.

Our approach minimizes, to the extent possible, the burden on CDCR staff; however, we require the following support from CDCR SMEs and technical POCs:

Validation of record counts of data extracted and converted to SOMS.

Assistance to assess the impact that multiple locations of source data has on the data conversion. Team EDS will work with CDCR staff to determine the optimum approach for resolving issues associated with the existing dispersion of legacy data across CDCR locations.

Assistance to designate the system of record for data that resides in multiple legacy systems.

Assistance to verify data element mapping that is generated by the automated mapping tool set. The automated data analysis and mapping tool will complete the majority of the mapping between the source and target data elements; however, because of the diverse sources of the data and the differences in database structures, some mapping will require human intervention. The SMEs will work with Team EDS to refine mapping decisions that cannot be resolved by the automated mapping tool.

SME assistance for Team EDS to define default values and business rules to populate such fields because it is unlikely that all data elements defined to SOMS will exist in the legacy systems.

SME assistance to relate required legacy code values to SOMS code values, which are National Crime Information Center (NCIC) code value standards. These relationships are recorded for use in automated conversion and interface processes.



SME assistance to define the business rules needed to consolidate data under a single offender ID because the source data is known to contain the same offender stored under multiple offender IDs; for example, an offender may have been incarcerated multiple times with a new offender ID each time. In addition, addresses may have been entered multiple times. Business rules will also be developed in an effort to remove as many duplicate addresses as possible.

Assistance in defining, reviewing, and refining data transformation rules.

Assistance to review error reports to determine the action to be taken to correct errors. The solution may result in legacy data being corrected or the transformation business rules may be altered to eliminate the error.

Validation of conversion results.

Maximize Use of Technology for Accuracy and Productivity

Typically, data conversion is a labor intensive undertaking involving manual efforts to investigate source systems to map data into the new target database. Such a manual approach requires repeated iterations as each field within a file or database is analyzed and traced. To ramp up the productivity of the Data Conversion team, our approach will deploy state-of-the-art, patented automated data migration technology, such as the Sypherlink Harvester. Our team will use the Harvester suite of tools to automate database interrogation, data discovery, cross referencing data within source systems, and high level mapping of data from source systems into eOMIS. These tools include powerful extract, transform and load (ETL) tools as well as the advanced software for source data consolidation. Team EDS estimates that the use these tools accomplishes as much as 70 percent of data discovery and mapping. The migration process will still require multiple iterations, but the automation tools will speed the process dramatically. Each iteration will add to our knowledge of legacy data to incrementally increase our team’s productivity. Team EDS will use this growing knowledge base to refine the conversion process by using standard change management practices.

Insulate the Data Conversion Environment

Team EDS will create a development environment specifically for the conversion process. Because of the iterative nature of the conversion process, we perform this work in a separate environment to avoid interference with SOMS development, testing, and training efforts. This environment also provides a single repository for legacy data to be brought together from the various sources, which is essential for the mapping and transformation processes.

Maximize Reuse of Software

Our technique for developing programs for the ETL of data from a source system into eOMIS takes a modular approach that maximizes code reuse. Our modular design methodology will enable developers to build standard templates for similar mappings to achieve faster and more accurate development of modules. Team EDS’ reuse strategy saves time, money, and resources and lowers total



project cost. Opportunities to collect reusable data are high during conversion projects.

Focus on Data Accuracy

Most of the data mapping and transformation process will be performed successfully through use of the automated tool sets Team EDS provides. As discrepancies are uncovered, we add new data quality rules using Team EDS’ Data Conversion methodology. Throughout the data conversion, we locate data exceptions and create rules to correct them. Creating a common process for collecting these exceptions will provide guidance to the Conversion team and easy reference for CDCR. We document such data exceptions and confirm our mitigation strategy with CDCR project representatives.

Perform Data Governance

Data Governance activities define the business rules for dealing with data that exists in more than one legacy source system. These rules guide SMEs with a framework for decision-making and indicate how to manage data. Data Governance policies are a necessary step in the conversion process because they remove uncertainty at a high level. By completing an accurate set of Data Governance policies, CDCR will achieve a significant scope clarification that provides insight throughout the project.

Data Conversion Phases

Team EDS’ overall data conversion approach entails progression through seven distinct phases. Each phase has clear processes, tasks, and deliverables, which we identify as follows.

Discovery Phase

The Discovery phase consists of documenting the existing “baseline” or “as-is” environment across CDCR’s disparate systems. This critical – yet often underestimated – initial step is the effort involved in discovering, documenting, and analyzing baseline data sources. The scope of systems within CDCR is broad; therefore, to assist with our planning of an appropriate risk mitigation strategy, our approach will be to discover the following issues:

Coordination of baseline discovery efforts

Existing network connectivity environments

Poorly documented systems

Lack of subject-matter expertise

Lack of technical resources available at agencies

Lack of cooperation and support by system vendors

Time commitments required by individual agencies to accommodate the process.



Discovery PhaseIdentify

Determine all systems to be

converted in the scope of the project. This

includes understanding the in-house or vendor-based

systems involved.

Acquire

Obtain access to or backups from all required data

sources.

Contact

Establish a user and technical

point of contact for obtaining information, if available, for each system.

Automate

Run Sypherlink Harvester Analyzer to discover

metadata schema and obtain data quality metrics

across all systems.

Learn

Create an expert on the source system by data analysis and

understanding core application functionality and business rules.

Prioritize

Determine what systems will be

completed – and in which order –based upon the complexity and

criticality.

Figure 6.6-4, Discovery Phase

Mapping Phase

The Mapping phase determines how field-level data corresponds to data within eOMIS. A key consideration of the overall time and cost associated will be the amount of effort required to map appropriate relationships from the more than 40 systems into eOMIS. Traditional mapping efforts rely heavily on the availability of SMEs, well-documented systems, and the human cognitive skills of the individual doing the mapping to identify where field-pair relationships exist. The result is a lengthy, laborious, error-prone, and costly mapping exercise. Traditionally, an individual will map from three to five fields an hour for each resource. Extrapolating this across the legacy systems, the cost impact becomes apparent. To effectively and cost-efficiently perform this mapping effort, Team EDS will leverage the Sypherlink suite of products to accelerate the process and improve the quality, time, and cost metrics.

Figure 6.6-5, Mapping Phase

Extract, Transform, Load (ETL) Phase

During the ETL phase, the mappings that were completed during the Mapping phase will be used to design and construct the ETL objects and to organize them



into processes that will allow data to move from the source system into eOMIS. During this phase, we design and implement the necessary data cleansing and data transformation steps of data manipulation, formatting, cleansing, and, if necessary, parsing. Also, we perform basic testing of the ETL transformations to confirm the overall correctness of the data flow and integrity of the data. During this phase, we configure ETL tools so that the data migration from the source system to the target staging area can be scheduled, performed, and monitored.

ETL PhaseCleanse

Devise the approach for data cleansing and data

merging based upon analysis during mapping

stage.

Resolve and Merge

Implement identity resolution functions and

algorithms.

Coding

Import all objects from Mapping phase and

create all remaining ETL objects, flows and data

streams needed.

Configure

Set up ETL tools to run in the specified environment.

Figure 6.6-6, ITL Phase

Internal Testing Phase

Initially, we perform the testing of the logical data units to validate the correctness of the source to target flow; the data formatting and transformation functions; and data integrity testing, which checks the correspondence of associations of data units between the source system and the target staging system. During this time, we further explore and document possible anomalies of the source data. We make recommendations to help resolve the problems found in the source data that negatively affect the data movement and consolidation process. Correctness and the fault rate of coded values matching and resolution are also performed. Also during this phase, the performance of the overall Data Movement process form is measured and tuned.

Internal Testing Phase

Review

Review data sourcemappings and

ETL definitions.

Discuss

Discuss data quality issues and available technical solutions.

Iterate

Review the exception list and fix each item.



Figure 6.6-7, Internal Testing Phase

Load Phase

During the Load phase, we load the data from the source system into the SOMS database. Initially, data is loaded into a target staging area, which has a similar structure to that of the SOMS database. At this point, data from individual source systems will be properly formatted and cleansed so that it is ready for the target. Then, from the staging areas, the data is merged into a pre-production database, in which the data from various source systems is compared and steps are taken to resolve conflicting data and duplicates. We calculate values for parole eligibility and release dates. When the data from the pre-production area is analyzed and its correctness is approved, we move it to the production database.

Load Phase

Load

Use standard Oracle products to load the SOMS

database tables.

Cleanse

Execute cleansing process determined to run against

the SOMS database.

Enhance

Execute process designed to enhance the quality of

the converted data.

Calculate

Once the sentence structure data has been

converted calculate parole eligibility and release

dates on active sentences

Figure 6.6-8, Load Phase

External Testing Phase

External testing includes checking incoming new data for correctness and ensuring that the data is loaded correctly into the SOMS database. eOMIS is then tested to determine that users can access the SOMS database and data correctly. Once again, anomalies of the source data are explored and documented, and recommendations are made to help remedy remaining problems.

External Testing Phase

Identify

Identify a representative

sample set of the source data for

testing purposes.

Test

Execute the Data Quality and ETL functions on the sample data set.

Review

Review results in target eOMIS data

model and application.

Iterate

Review the exception list and

fix each item.

Figure 6.6-9, External Testing Phase



Reconciliation and Cleanup Phase

The objective of the Reconciliation and Cleanup phase is to validate that the iterations of data ETL and testing have been successful and that they meet the goals and the objectives of the data integration process for all stakeholders. This phase involves an end-to-end examination of data flow from the source system to the SOMS target and visualization of the data within the system. Stakeholders from each group involved with data from a particular source will review the data in SOMS and compare it with portions of the original data source to verify proper data flow and integration. Feedback from the External Testing phase, combined with feedback from the Reconciliation, is used to make final adjustments to the data flow before final cutover.

Reconciliation & Cleanup Phase

Coordinate

Work with source agency to coordinate all aspects of production

conversion so there are no

surprises on go live day.

Run

Utilize the tools and

configurations to run the Data

Quality and ETL functions.

Check

Review the results in

target eOMIS data model and

application.

Review

Create exception list and fix issues

that are raised.

Confirm

Work with agency

contacts to confirm data in

the target system.

Quantify

Create statistical report of

conversion results to provide to

project stakeholders.

Figure 6.6-10, Reconciliation & Cleanup Phase

Section 4.2.E, Data Conversion, provides a detailed description of the Syperlink suite of data conversion products Team EDS will employ and explains how these tools will be used for data discovery, data cleansing, and data loading. Section 4.2.E also describes in detail our risk mitigation strategy related to data conversion.



M-64 The Contractor shall incorporate the data conversion approach into a comprehensive Data Conversion Plan that will describe how the Contractor will manage the process of converting (as required) data from the legacy systems for use in the system, and back into the legacy environment. The Data Conversion Plan shall address, at a minimum:

A description of all data sources and data targets.

A description of field mappings, tools, data validation and cleansing methods/algorithms, and any other software programs that will be used or will need to be written to support data conversion. A description of how converted data will be validated to be correct before use.

A description of the approach to converting legacy data to required formats.

A description of the approach to synchronizing the data between the new system and legacy systems that will rely on updates provided by the new system.

A description of how data anomalies and errors will be handled.

A schedule of deliverables and resources needed to complete the conversion effort.

Detailed descriptions of how the data conversion tools provided by the contractor will be operated for each phase of the SOMS solution delivered to the Pre-production environment.

How converted data will be delivered as required to support each phase of the SOMS solution delivered to the pre-production and production environments.

The processes for delivery of the software and hardware configuration information used in creating the converted data, at the time the data is delivered to the pre- production and production environments.

Description of how the data reconciliation process will work.

The Bidder must submit a sample Data Conversion Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.


Appendix N


The team we bring to CDCR for the SOMS project has many years of data conversion experience. It has direct experience of migrating legacy offender management data into eOMIS in three states, as well as experience with large-scale data conversion projects in the State of California. The sample data conversion plan in Appendix N, which is drawn from EDS’ successful CalWIN project, demonstrates our team’s experience in carrying out large-scale data conversion. The SOMS Data Conversion Plan will be tailored to CDCR’s specific data conversion environment and, because of the complexity of SOMS data



conversion requirements, it will be far more detailed than the sample plan we provide. EDS will provide CDCR with two distinct plans that address data conversion. The first plan, titled Data Conversion Plan, will describe detailed procedures and deliverables for migrating data from CDCR’s legacy systems into the SOMS solution. The second plan relating to data conversion, titled “Paper Conversion Plan”, will address the conversion of CDCR’s paper documents into an electronic document management system, which we describe in our response to RFP Requirement M-65. The SOMS Data Conversion Plan will address procedures for managing the process of converting data from CDCR’s legacy systems into our COTS solution and will provide managerial and technical guidelines for data conversion activities. We deliver a comprehensive Data Conversion Plan after contract award; the plan will include an overall data conversion chart and will specifically address the following:

Data Conversion Roadmap

This section will describe the overall strategy and timeframe for migrating individual legacy systems and their data into SOMS. Each SOMS release will include distinct data conversion initiatives, each of which must be choreographed with legacy system retirement and back bridging. The Roadmap section of the Data Conversion Plan will describe the various legacy system data sources, CDCR technical points of contact to assist in conversion activities, itemization of potential risks and obstacles, a matrix for team responsibilities, a schedule for data conversion activities within each release, and a list of data conversion deliverables associated with each release.

Documentation Requirements

This section of the Data Conversion Plan will establish procedures for Team EDS to document data sources and their associated target system mappings. For each distinct data source, the Data Conversion Plan will mandate recording a description of field mappings, tools, data validation and cleansing methods and algorithms, and software programs to be used. The data conversion repository will be updated as the team progresses through the Testing and Data Loading phases and will include information about data transformations, synchronization techniques, and how data exceptions were resolved.

Protocol for Confirming the Data Conversion Strategy

At the conclusion of the Mapping phase for each SOMS release, Team EDS will provide a detailed data conversion blueprint that describes the source-to-target mapping, transformations, testing, and issue log. The purpose of this document is to provide a “management view” of how the data conversion is being carried out, how anomalies are being reconciled, and our strategies for dealing with potential risks and their mitigation. This document will serve as a checkpoint for EDS and CDCR Project staff to confirm the efficacy of specific data conversion steps for each release.



Data Conversion Communication Plan

A subsidiary to the overall Project Communication Plan, this section will outline procedures for communicating data conversion progress, legacy system retirements, data bridging implications, security alerts and breaches, and general issue notification procedures. This section will also describe procedures for notifying administrative staff of issues, database changes, and operational issues that could affect data conversion planning.

System Environment

This section of the Interface Management Plan will provide technical information needed by staff engaged in data conversion activities. Examples of information in this section include a database schema; NIEM-compliant data definitions; security and authorization provisions; and an inventory, description, and reference for software tools employed for existing and planned data conversions. As a subsidiary to the Configuration Management Plan, this section will document the entire technology stack of each platform with references to information that describes how each data conversion tool is used.

Development, Testing and Implementation

As a subsidiary to the Software Design and Development Plan, this section will prescribe technical guidelines and programming conventions for using data conversion tools and developing reusable data migration programs. Techniques described in this section of the plan will include procedures for data discovery, “mining” of system rules, and data mapping protocols. The guidelines will also present samples and descriptions of the artifacts generated from each of the data conversion activities. The testing portion of the Data Conversion Plan will dictate mandatory unit and system testing, QA procedures, backup and auditing provisions, and implementation procedures. A final subsection outlines procedures for migrating data and tools into CDCR’s production environment.



M-65 The Contractor shall incorporate the paper documentation conversion approach into the comprehensive Data Conversion Plan that will describe how the Contractor will manage the process of converting (as required) data from CDCR’s paper documentation for use in the system. The Data Conversion Plan shall address, at a minimum, the following areas:

A description of all data sources (CDCR forms and data fields) and data targets.

A description of field mappings, tools, data validation and any other software programs that will be used or will need to be written to support data conversion. A description of how converted data will be validated to be correct before use in the new production system.

A description of the approach to converting paper documentation to required formats.

This approach must take into consideration that there is no space for contractor staff within the facilities to perform the backfile conversion.

This approach must also take into consideration that the retention of the paper documentation after conversion will be CDCR’s responsibility.

A description of how data anomalies and errors will be handled.

A schedule of deliverables and resources needed to complete the conversion effort.

Detailed descriptions of how the data conversion tools provided by the contractor will be used to convert the paper documentation.

How converted data will be delivered as required to support each phase of the SOMS solution delivered to the pre-production and production environments.

A description of how the data reconciliation process will work.

The Bidder must submit a sample Data Conversion Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.


Team EDS has a significant Document Solutions Practice staffed by a dedicated group of professionals covering every facet of document processing – both incoming documents and outgoing documents. This includes document management, DOD 5015.2 certified records management, paper document scanning, paper forms processing, e-Forms, automated document generation and document driven workflow. We apply our extensive expertise and experience to the herculean task of converting the legacy paper case files and the on-going day-forward paper documents into electronic records that will be integrated into the overall SOMS solution.



There is no question that the task of converting CDCR’s paper case files to electronic records will be particularly challenging. This is due to a number of factors including:

The sheer volume of files and documents – over 300,000 case files and 200,000,000 pages

The condition of many of the paper originals in the case files

The fact that large volumes of offenders and their associated paper case files are transferring between institutions

The requirement to do the backfile conversion of C-Files and Juvenile files in the parking lots of the institutions on a standalone basis

The requirement to preserve the paper files after conversion in contractor’s records management facility

And, of additional importance, the requirement to make CDCR staff successful in accessing and using the electronic image versions of the paper case files during and after conversion.

We have reviewed the sample case files made available by CDCR and have carefully considered the ramifications of the paper document conversion requirements. We discussed document management issues at length in our confidential discussions with CDCR, and demonstrated the simplified viewer that CDCR staff will use to access and view the electronic document images.

We have provided a detailed and comprehensive plan to accomplish both the backfile conversion and to integrate the day-forward paper document scanning into the backfile conversion and the overall SOMS project. We are committing over two-hundred staff to the backfile conversion and a fleet of custom Mobile Backfile Conversion Units to the project to meet the overall SOMS project schedule.

We are also providing an important early win to the SOMS project as CDCR staff will begin accessing electronic C-Files early in the first year of the project with growing volume of converted paper case files on a daily basis as the conversion proceeds.

Paper Backfile Conversion Phasing

The paper backfile conversion will be phased in accordance with the overall SOMS project so that the C-Files for active adult offenders are converted prior to the production start of SOMS Release 1A at the end of project year-one. The Juvenile files will be next and will be followed by the P-Files. Conversion of the remaining C-Files in the Northern and Southern Storage Facilities will be last. There will be significant overlap of these conversion phases to reduce cost by taking advantage of the geographic proximity of CDCR facilities to reduce transportation of the Mobile Backfile Conversion Units. This is a significant cost savings opportunity.



Multiple Paper Backfile Conversion Methodologies

We employ multiple backfile conversion methodologies to meet the specific requirements of each location having paper case files. These methodologies include:

Standalone, Mobile Backfile Conversion Units – self-contained, high-volume backfile conversion in CDCR facility parking lots. Highest cost operating with no logistics support from CDCR.

Standalone conversion operating in hotel meeting rooms – regional conversion for nearby parole offices. Lower cost than Mobile Backfile Conversion Units but still operating without logistics support from the parole offices.

On-Site conversion for Northern and Southern C-File Storage Facilities. Lower cost than hotel-based conversion to handle the large volume of C-Files stored there.

On-Site, day-forward scanning at CDCR custody facilities that will convert the incoming C-Files and Juvenile files of transferred offenders. Lowest cost handling smaller volumes of transferred offenders.

This will allow us to meet all of CDCR’s requirements with the highest integrity conversion results at the lowest overall cost within the project schedule requirements.

Paper Case File Document Preparation

The paper case files will be disassembled by removing the pages from the case file folder bindings. The pages from each section will be scanned together as a batch and classified as a Document Type based on the file section they came from. A batch header sheet will identify the Offender ID and Document Type. Loose or otherwise unidentifiable documents found in paper case files will be scanned with a Document Type of “Exception” and routed to a central workgroup that will include CDCR Record Managers that can manually identify the documents and electronically file them correctly.

High-Fidelity Scanning and Quality Assurance

We use production class Kodak scanners at 300 dpi resolution for the backfile conversion. This will provide digital document images of quality similar to a paper copy made on a modern digital copy machine. Typical industry standards are 200 dpi scanning for backfile (the same resolution as a fax machine). We believe that, based on the condition of the paper documents, 300 dpi scanning will enable CDCR staff to view and interpret the digital document images quickly and with minimal eye strain.

Every document image will be manually verified to confirm that an acceptable scan was captured. The Kodak scanners include ultrasonic double feed detection to validate that two sheets of paper are not pulled into the scanner together and thus not scanning one of them.



Flexible Indexing and Data Extraction

Paper backfile conversion starts very early in the overall project and not knowing what data, if any, data must be extracted from the paper case files to support the larger data conversion efforts. Therefore, we do not extract any data from the paper case files during conversion. We simply index the documents by Offender ID, Document Type (based on the section of the case file the paper document was filed in) and Scan Date. This is sufficient metadata to support the simplified viewer.

If any requirement to extract data from the paper case files is identified during the larger data conversion efforts, that can be done from the scanned document images at a Team EDS facility having extensive resources and expertise accomplishing that. This is the lowest cost approach to any required data extraction with no compromise in timeliness or accuracy.

Post-Conversion Paper Records Management

After scanning and QA processing, all of the sections of a paper case file will be put in original order and secured by a heavy duty band designed for that purpose. The banded case files will then be placed in bar-coded, cardboard banker boxes. As the boxes are filled, they will be sealed. The Documentum Records Manager will store the box number that each paper case file is stored in. Large paper case files that span multiple banker boxes will be noted accordingly.

The sealed banker boxes will be transported to a Team EDS records storage facility in Hayward, California. The boxes will be stored in a protected environment until such time as CDCR authorizes their confidential destruction which will be carried out at the records storage facility.

DOD 5015.2 Certified Records Management

The converted paper case files will be stored as electronic records managed by the proposed Documentum DOD 5015.2 certified Records Manager. This provides structured chain of custody management of the electronic case files with full audit logging and reporting of access to and lifecycle management of the records.

M-66 The Contractor shall configure all required data conversion tools, software and hardware.

Section 5.0


Team EDS will comply with RFP Requirement M-66 by being fully responsible for configuring all data conversion tools, software, and hardware.

Data Conversion in SOMS projects involves two domains:

Electronic Data Conversion, whereby our team migrates data from CDCR’s current systems into our COTS solution



Paper Data Conversion, whereby paper documents are scanned into an ERMS.

Section 4.2.E, Data Conversion, describes our approach and the tools we propose to use to implement data conversion for SOMS. In Section 5.0, Technical Requirements Response, we describe the technical aspects of data conversion with regard to architecture and the proposed environments.

As systems integrator for SOMS, Team EDS will take full responsibility for successful completion of SOMS, especially the data conversion, which has the maximum dependencies and risks across all aspects of SOMS. As we state in our response to RFP Requirement M-64, Team EDS will submit a Data Conversion Plan, which will describe the configurations of Data Conversion tools and the software and hardware for each proposed environment. Because each release involves different data sources, data targets, bridges, and paper records, our team will update the Data Conversion Plan, calling out changes to the configuration of Data Conversion tools. Our team will provide appropriate documentation about tools, procedures, and processes including the detailed configuration and deployment of Data Conversion tools. In addition, we also conduct walkthrough sessions with CDCR staff to provide the opportunity for understanding, review, and approval our plans.

M-67 The Contractor will be responsible for converting all data required from the legacy environment to the new SOMS system. While the Contractor will provide the tools and methodology for converting the legacy data, CDCR will provide dedicated resources to assist the Contractor in understanding the legacy data, assistance in data extracts and data loads, and assisting the Contractor in resolving problems related to the data conversion efforts.

N/A


Team EDS accepts full responsibility for converting all data from the legacy environments into SOMS and for providing associated tools and methodologies for discovering, extracting, cleansing, transferring, and loading relevant data. Team EDS anticipates requiring documentation and technical assistance to understand CDCR’s legacy environment. Our responses to RFP Requirements M-63 and M-64 describe our overall approach to data conversion, assessment of risks, and collaboration with CDCR staff. Although our approach is designed to minimize the need for CDCR staff resources, the existence of multiple locations from which we migrate data will necessitate assistance from CDCR staff. In the course of migrating data from DDPS, for example, our team will need to consult with CDCR staff who are knowledgeable about the differences among locations and with individuals who will provide access to the disparate platforms.

M-68 The Contractor shall be responsible for converting data from the legacy database(s) as required to support the new SOMS system.

N/A




Team EDS will apply world-class technologies and a proven, structured approach to migrate data from CDCR’s legacy databases into the new SOMS environment. We accept full responsibility for converting data. Our responses to RFP Requirements M-63 and M-64 describe our approach and the Data Conversion Plan we provide early in the project.

M-69 With each Pre-Production Release that requires use of data converted from the legacy environment, the Contractor shall provide an updated Data Conversion Release document. This document must include the following:

A description of the field mappings, tools, and programs used to support data conversion.

A description of data that was validated and tested.

A description of how data anomalies and errors were addressed.

A description of the resources and tools used to create the converted data.

The configuration information for the tools and scripts used to produce the converted data.

A description of any data conversion issues that may impact the production environment.

N/A


Team EDS will comply with RFP Requirement M-69 by providing a Data Conversion Release document for all files converted from legacy systems, documenting the source of the data; techniques employed to extract, cleanse, and load the data; configuration parameters for tools and software employed; and a detailed assessment of data conversion risks and issues that may affect the production SOMS environment. The Data Conversion Release document will serve as critical input into development and execution of integrated testing procedures described in our responses to RFP Requirements M-75 and M-76.

VI.D.9.f. Software Configuration Management Requirements

Req.


M-70 The Contractor shall provide a software configuration management system to store, control, and track instances(baselines during the construction lifecycle) of all software configuration items that shall be developed for the State.


Appendix O


Team EDS will comply fully with RFP Requirement M-70 by leveraging products from Computer Associates (CA) to address SOMS software configuration management requirements. These products include the following:



CA CMDB – a functional data repository that unifies and simplifies the management of configuration information. CA CMDB consolidates and reconciles disparate sources of IT-related data in the context of business priorities and provides visibility into configuration item information such as resource attributes, relationships, and dependencies.

CA Cohesion Application Configuration Manager – an automated solution that provides control and management of complex and distributed applications to validate the applications’ security, performance, availability, and compliance.

CA Software Change Manager – a product that facilitates the automation and management of the application development process, enabling efficient tracking and reporting on software changes in a distributed environment. Its intuitive Web interface and multitier, multiplatform architecture can synchronize Development teams across the enterprise.

We use the CA software configuration management system products to store, control, and track instances (baselines during the construction lifecycle) of all software configuration items that shall be developed for the State.

Appendix O, contains a sample Configuration Management Plan from our State of Oregon Medicaid Management Information System (MMIS) project.

M-71 The server(s) that house the Contractor’s software configuration management systems shall reside at the State, and the software configuration management system shall be accessible by State personnel.

N/A


EDS complies with deploying SOMS software configuration management system, CA Software Change Manager at the project office located at the CDCR Aerojet facility. Both State and EDS personnel can access Software Change Manager through both a thin and thick client. Software Change Manager’s thin client capability facilitates access to the system by remote State employees by avoiding the difficulties associated with supporting thick client applications on computers located off site.

M-72 The Contractor must use an industry standard software configuration management tool; CDCR has used SAP’s configuration management tool and Microsoft Visual SourceSafe.

Section 4.2.C,

Section 6.9


Team EDS uses industry standard software configuration management tools identified previously in our response to RFP Requirement M-70. The Configuration Management toolset from CA is widely-deployed within EDS and the IT industry. Section 4.2.C, Technology, describes our overall approach to configuration management, and Section 6.9, Production Support and Transition, explains how our team uses Configuration Management tools to comply with industry standard



procedures, including the Information Technology Infrastructure Library (ITIL) standard.

VI.D.9.g.Requirements Managements

Req.


M-73 The Contractor shall describe the requirements management approach and methodology used for the SOMS Project.

The Bidder must submit a narrative describing the requirements management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format.

Section 6.4


Requirements Verification and Analysis

EDS began the IT outsourcing services industry and, after more than 40 years, continues to be recognized as the premier IT industry leader. We know the critical role that well-documented requirements play in a software development project. Requirements management uses efforts to gather, analyze, and document requirements throughout the entire project life cycle. Requirements management activities dramatically increase project success and reduce the risk of uncontrolled project changes. By keeping project team members informed about the state of requirements throughout the development process and into maintenance, development rework is reduced and overall quality is increased.

EDS has extensive requirements verification and traceability experience with large-scale projects, as demonstrated by the successful implementation of the CalWIN and CBMS applications. For these implementations, we virtually managed thousands of requirements and continue to use them for ongoing production enhancements and modifications.

Through mature, robust process sets qualified by Software Engineering Institute (SEI®) Capability Maturity Model (CMM) assessments, our team will maintain a detailed understanding of SOMS requirements and the requirements’ current state and keep CDCR informed of product status. These requirements will be tracked and maintained through Borland’s CaliberRM® requirements management software. This will provide CDCR with the necessary information to make informed business decisions at various project stages.

To assist us to gain a thorough understanding of the requirements, we perform software archeology to capture the business logic and related data components



from existing legacy CDCR systems. This approach will allow us to identify gaps and refine requirements early in the process to prevent loss of critical business functions, which would result in costly rework that could potentially occur later in the development life cycle.

Using EDS’ Object and Component Engineering (OCE) work type, introduced in Section 6.4, System Design and Development, Development Methodology and Technical Practices, we execute the OCE key requirements verification-related processes, subprocesses, and work elements. The following table, Table 6.6-3, Requirements Verification and Analysis Processes, highlights these processes and the associated core focus.

Table 6.6–3, Requirements Verification and Analysis Processes

Requirements Verification and Analysis Processes

OCE Process Core Focus

Define Define Project Plan – Refine Scope:– Refine Scope Statement and Refine High-Level

Requirements Define Business Need:

– Describe Business Problem / Opportunity– Define Scope of Business Need (High-Level Business

Functions, Context of the Business Need, High-Level Events and Responses, Business Entities and Relationships)

– Determine Impact of Business NeedManage Manage Scope and Requirements

In carrying out the OCE Define Business Need subprocess, we take advantage of our best-practice processes, tools, and services—including EDS’ Requirements Determination Process (RDP)—to analyze and verify SOMS requirements. We use requirements-based testing to verify that requirements are valid and unambiguous and requirements and defect-traceability tools to trace defects back to original project requirements.

EDS’ RDP is a proactive, value-added approach that supports requirements validation. EDS formalized this process in 1992, reflecting a process maturity gained through years of experience and best practices in eliminating issues that could arise from misinterpreting information about the client’s needs. The RDP provides a framework for communicating with CDCR to design and develop successful applications and projects. The process enables us to obtain, understand, document, and validate the business and technical requirements for a client application.

The RDP will help us to verify and validate SOMS requirements, which form the basis for the design of our SOMS solution. The RDP will provide a framework for communicating with CDCR and with others who receive and use SOMS requirements to design, customize, configure, and implement the SOMS solution. Use of this framework provides a greater potential for clear communication, accurate requirements, and delivery of a solution that meets CDCR needs.



To foster a mutual understanding of project requirements between CDCR and EDS, we document individual requirements adhering to the following principles:

Unambiguous – requirements should not leave room for interpretation; they should mean the same thing to both parties

Understandable – state requirements in written language that both parties understand

Complete – requirements must include necessary details

Verifiable – must be able to practically confirm each requirement

Appropriate – requirements must be relevant, within the scope of the project and make good business sense

Consistent – must be no contradiction between requirements

Maintainable – requirements must accommodate changes and be adaptable for future reuse

Structured – requirements should reflect broad relationships and levels of detail

Traceable – requirements must contain cross-references to the source from which the requirement was determined.

RDP Components

As shown in the following table, Table 6.6-4, Major Components of RDP, the RDP is divided into five major components: Plan/Manage, Obtain, Understand, Validate, and Evaluate. The core components—Obtain, Understand, and Validate—are executed multiple times, once for each set of project requirements that must be obtained, understood, and validated.

The RDP enables EDS to determine SOMS needs and expectations and provides a quality solution that meets business needs for the services delivered by each application.

Table 6.6-4 – Major Components of RDP

ComponentsRDP Components

Purpose

Plan/Manage During this component, we prepare for and manage the RDP. This includes building the plan we follow throughout the process and managing the overall execution of the RDP.

Obtain When CDCR has provided EDS with the SOMS functional and technical requirements, one of the tasks included in this component is to identify the appropriate representatives who can assist with verifying and analyzing this information from relevant perspectives. The information obtained during this component is stored for later retrieval and traceability.



ComponentsRDP Components

Purpose

Understand During this component, we analyze the information we have collected to verify that we have a good understanding of the requirements. Among the tasks in this component are evaluations of statements for consistency, completeness, and appropriateness. For each statement, we establish traceability and validation criteria.

Validate This component could be considered the most important because a mutual understanding of the implications of the requirements is confirmed. EDS will conduct facilitated joint application design (JAD) workshops with CDCR to assist with validating SOMS requirements.

Evaluate This last component contains the quality improvement tasks for the RDP. During this component, we assess how well the process has worked and determine the effectiveness of the techniques and the requirements statement. We also obtain independent evaluations of the RDP from everyone involved and determine how the total effectiveness can be improved for the next execution of the RDP.

During requirements verification and analysis, we work with CDCR to plan the execution of activities that take place to analyze and verify SOMS’ functional, technical, and training requirements.

Planning for Requirements Verification

The Validate component of the RDP brings together CDCR, EDS, and other stakeholders to develop a common set of expectations. Validation confirms with CDCR a mutual understanding of the implications of SOMS’ functional, technical, and training requirements and provides a common set of expectations.

EDS SMEs will work with CDCR-designated stakeholders in a series of workshops to plan the schedule for activities during requirements verification and analysis. A single, authoritative set of requirements is critical to the successful implementation of the SOMS solution. Toward this end, we conduct JAD sessions with CDCR-designated stakeholders in the Sacramento, California, area. For each SOMS release, we conduct JAD sessions with CDCR stakeholders assembled in one place, thereby eliminating ambiguity and conflict for all SOMS requirements. During project startup, we work with CDCR to define roles and responsibilities, define the appropriate skill sets and people for the sessions, and create agendas. This single set of JAD sessions, aligned to solution function, will support the aggressive implementation timelines for each SOMS release.

Our team will conduct facilitated JAD sessions to verify the SOMS requirements to provide an updated requirements traceability matrix as the output of this process.

Requirements Verification Schedule

Team EDS develops the Requirements Verification Schedule to outline the proposed number of meetings, names of anticipated participants, names of anticipated participants, and proposed agendas. Also included will be updates to



the project work plan of detailed activities, schedule, and resources required to complete requirements verification and analysis. As we have stated, we anticipate all meetings to be conducted in the Sacramento, California, area, organized by functional and technical requirements.

Analyze and Verify the SOMS Requirements

The EDS team will use the Borland CaliberRM® software package to manage SOMS requirements. All requirements and clarifications received during the procurement and Requirements Verification process will be entered into the CaliberRM® requirements repository.

Team EDS assigns a unique identifier to each SOMS requirement and verifies that these requirements are concise and complete. We schedule clarification sessions with CDCR staff and CDCR-specified key users of SOMS as deemed necessary. Additional documentation, such as clarifications, details, or examples to help more thoroughly clarify a requirement, is attached to the appropriate requirement in CaliberRM®.

System Requirements Document (SRD)

The Obtain/Understand components of the RDP involve close interaction between CDCR and EDS to verify that information is properly conveyed, comprehended, and categorized during requirements creation. In driving to a shared understanding of SOMS requirements, we produce the System Requirements Document (SRD), which fully lists verified functional, technical, and training requirements that include design impacts before initiating design. The document serves as the foundation for future design and development.

Requirements Traceability Matrix and Report

Requirements traceability is a key component of EDS’ Requirements Management process and is the degree to which a relationship or link can be established between two or more products of the Development process—particularly when they have a predecessor-successor or master-subordinate relationship. EDS’ Requirements Traceability process includes project artifacts that need to be explicitly traced from another project artifact to keep track of the dependencies between them. Our requirements traceability provides strong control over management of requirements, not only during the project, but for the lifetime of the requirements and the associated product or service. For SOMS, traceability links the following elements:

Information sources – Source documents, such as meeting minutes and interview notes, that contain the original context of the elicited information

Requirements – Requirements statements resulting from the RDP, including parent-child and peer-to-peer requirements relationships, and the Business Process model

Delivery components – Downstream components such as design documents, code modules, and so on that implement the requirements.



During verification and validation of SOMS requirements, we record the origin of the requirement by capturing the traceability between the requirement and its source documents. As the project proceeds through later phases, we capture additional traceability for each requirement to identify the delivery components that satisfy the requirements.

Figure 6.6-11, End-to-End Traceability of Requirements, depicts how end-to-end requirements traceability depends on the use of a consistent scheme to uniquely identify each requirement, its source, and each delivery component.

Source Document

(.e.g., contract, CR, URL, e-mails, minutes)

Scope Statement

High LevelRequirements

Business Process Model

Detailed Requirements

(e.g., use cases, functional, non-functional,

business rules)

Design / Code Test Plans / CasesOther Work Products

(e.g., User and Training Manuals)

Figure 6.6-11, End-to-End Traceability of Requirements

Effective requirements traceability encompasses both “forward-to” and “backward-from” linkages between elements. Traceability is used to verify that we have met the SOMS business requirements. This is accomplished by cross-referencing each requirement to its source or owner, to other requirements, and to delivery components.

Source component traceability links source documents with requirements:

Backward-from-requirements traceability answers the question “Where did this requirement come from?” This answer is supplied by uniquely identifying appropriate portions, such as paragraphs or sections, of each source of information and then showing, for each requirement, the identifiers of its sources. This is useful if tradeoffs must be made later and we need to re-examine the rationale that led to the potentially affected requirements.

Forward-to-requirements traceability answers the question, “What requirements are affected or defined by this source?” This answer is



supplied by uniquely identifying each requirement and then showing, for each source of information, the identifiers of the requirements it affects or defines. This is useful to evaluate the effect of changes or clarifications in a source document. It also provides a basic check that the source items are addressed by the set of requirements.

Traceability between requirements is determined through analysis of business processes and assessment of dependencies.

Traceability with respect to delivery components—downstream traceability links requirements with delivery process components such as design, code, and test cases as follows:

Backward-to-requirements traceability answers the question “What is the purpose of this component?” The purpose is found by showing, for each component, the identifiers of the requirements that the component addresses. This is useful in evaluating the effect of future changes to individual components.

Forward-from-requirements traceability answers the question “What delivery components satisfy this requirement?” This answer is supplied by showing, for each requirement, the identifiers of the EDS process components that address it. This is useful in evaluating the effect of future changes to that requirement. It also provides a basic check that requirements are addressed by the set of delivery components. This is done simultaneously with backwards-to-requirements traceability.

The traceability properties for each SOMS requirement are useful in producing the Deliverable Requirements Traceability Matrix (RTM) and Report out of CaliberRM®. The RTM clearly traces the SOMS business or functional requirements to the corresponding technical requirements.

Team EDS will construct and use the RTM report for SOMS, and we regularly maintain it after system rollout. The RTM will help identify the effect of changes to key engineering work products such as the requirements documentation, application design specifications, application components, and testing specifications by listing each requirement and cross-referencing it to the design specifications that meet the requirement—business, technical, or organizational—and the various test cases that will prove the requirement has been met. The RTM will be regularly maintained to support future enhancements to SOMS and assist with defining future testing requirements.

Together with the RTM deliverable, EDS provides a corresponding report to establish that the SOMS requirements and deliverables have been linked properly and have been successfully established in the development environment. We use the Project Issues Management process, as defined in our Project Management Office, to identify and resolve traceability issues.



M-74 The Contractor shall incorporate the requirements management approach into a comprehensive Requirements Management Plan. The Requirements Management Plan will be used by the project to assure that requirements are met. The Requirements Management Plan shall, at a minimum, address the following areas:

Establishment of a baseline for existing requirements.

Management of versions of requirements.

Establish and maintain CDCR’s requirements traceability matrix that will be used for requirements management, and will map where in the software a given requirement is implemented.

A requirements change control process.

A methodology for managing requirements in an iterative development lifecycle.

Procurement, installation, and administration of requirements management tools.

A description of the relationship between the requirements management role and the other roles (i.e. test management, quality assurance management) on the project.

Publishing of standard reports related to requirements management.

The Bidder must submit a sample Requirements Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Volume 1 – Appendices

Appendix P


Team EDS’ approach to requirements management, which we describe in RFP Requirement M-73, will lead to a comprehensive Requirements Management Plan that is tailored specifically for the SOMS project. The Requirements Management Plan will establish the requirements baseline and procedures for updating the RTM. Team EDS will use commercial requirements traceability software, Borland CaliberRM®, to map requirements to software implemented in each release and to generate standard reports that document meeting requirements, issues associated with individual requirements, and associated issue resolution. Appendix P, contains a sample Requirements Management Plan.



VI.D.9.h.Pre-Production Release Requirements

Req.


M-75 When functionality is ready to be delivered to CDCR for User Acceptance Testing (UAT), it shall be delivered in the form of a Pre-Production Release. Since CDCR will perform UAT and approve all releases into production, a pre-production release is equivalent to a production release and requires the rigor associated with a production release. Upon successful completion of UAT, CDCR will schedule a release to be moved to the Production environment. Each Pre-Production

Release shall include the following:

Release-specific Hardware and Software solution components.

An updated Data Conversion Release document.

Release Description including Architecture or Design updates, new functionality introduced, defects fixed, modifications to interfaces with other systems, other changes to existing code, and any software and hardware configuration changes.

Release Contents including a description of the release structure and contents and instructions for assembling and/or configuring the components of the release.

Test Plan and test execution results.

Detailed hardware and software configuration information including any software and hardware dependencies and instructions at a level of detail that will enable DTS system administration staff to rebuild and configure the hardware environment without outside assistance.

Database documentation conforming to industry standards.

Detailed configuration information for any 3rd party hardware and software.

The Contractor shall provide updated documentation when system upgrades to software or equipment occurs through the life of the contract.

Section 6.5


Team EDS understands and will comply fully with RFP Requirement M-75. We conduct rigorous pre-production testing before delivering software components for CDCR’s UAT.

As we explained in our response to RFP Requirement M-44 in Section 6.5, Testing, for each SOMS release, the release testing manager will provide CDCR



with the Master Test Plan, Component Test Plans, and detailed test results reports for each of the following test levels:

Service Testing

System and System Integration Testing

Performance Testing

Consolidated Integration Testing.

In addition to test plans and reports, when we deliver pre-production software to CDCR, Team EDS will also provide technical documentation and configuration information for hardware and software components contained in or affected by the release, Data Conversion Plans, and change management documents that describe functionality and expected impact on system operations and business processes.

M-76 Implementation is expected to be iterative from both a business process and applied technology perspective. CDCR will accept the products into the production environment through application of the acceptance criteria testing plans. For releases that include either servers at DTS, or that impact the data network provided by DTS, representatives of DTS must have been trained, and their own internal checklists must have been met, prior to a production release date being scheduled.

N/A


Team EDS will comply fully with RFP Requirement M-76.

EDS will include entry and exit criteria for the test levels to be performed for all SOMS releases, including User Acceptance and Operational Acceptance Testing. EDS’ Testing team will be responsible for developing the SOMS Master Test Plan and will work closely with designated CDCR representatives to capture and document test criteria. The following are the entry criteria that EDS typically uses for all test levels:

Execution for any prerequisite test level has been successfully completed

Baseline test scenarios and cases have been documented and reviewed

Required baseline testing environment is ready for use

Required testing tools are available for use, and users have been appropriately trained

Baseline versions of all required application products (for example, Job Control Language (JCL)/Scripts, applications, additional software as required, application data, and controlled documentation) have been loaded in the appropriate level of the configuration management system used for the project

Change control procedures have been established and are applied



A formal defect-tracking mechanism has been established

A formal metrics collection and reporting mechanism has been established.

The following are the exit criteria that EDS typically uses for all test levels:

All prioritized test cases have been executed

All defects (failures) and problems have been identified, documented, and managed according to agreed criteria

Appropriate metrics have been captured, reported, and analyzed

The final test results report has been produced

M-77 The Contractor shall deliver to CDCR, a Requirements Traceability Matrix for all delivered functionality, showing all testing activities tracing to delivered functionality, and all delivered functionality tracing to requirements in the requirements repository.

N/A


As we explained in our response to RFP Requirement M-73, Team EDS will deliver a RTM using Borland CaliberRM® software. The RTM will fully document delivered functionality, mapping each requirement to software components provided in each SOMS release, as well as testing carried out before UAT and acceptance of the release.

M-78 The Contractor shall validate that each interface to an external system is working correctly. The Contractor will repair all interface-related problems caused by contractor- developed interfaces.

Section 4.2.H


Team EDS will comply fully with RFP Requirement M-78. We thoroughly test external interfaces to validate that they are working correctly and will repair all interface-related problems caused by contractor developed interfaces.

Our response to RFP Requirements M-60 through M-62 and Section 4.2.H, Interfaces, describe our overall approach to developing and managing interfaces, and to working with external entities that are in control of other systems. Our approach to interface management actively identifies interface issues and fosters problem resolution early in the software lifecycle. Effective testing and administration of interfaces starts with our methodology for designing and documenting interfaces. Our interfaces track lead and the SME assigned to a specific interface will verify that the interface format, channels, transmission protocols, and communication protocols are well understood, approved, and signed by CDCR and the external party. This documentation will address the appropriate APIs, delivery channels, frequency, and formats and will also describe in detail the error and exception conditions anticipated in the system. Our approach of carefully analyzing potential exceptions promotes the



development of an effective Interface Test Plan to be used in pre-production testing and ongoing monitoring of the production environments.

Our technical approach to interfaces maximizes use of the SOA architecture to provide extensive logging and error-handling features to facilitate comprehensive testing and monitoring of interfaces. In addition, our use of logging, error-handling, and alerts reduces the mean time required to diagnose and correct an issue.

For each SOMS release, Team EDS will perform System Integration and Consolidated Integration Testing to validate that each interface to an external system is working correctly and that transactions crossing one or more interfaces deliver the expected results.

Initially, the testing will occur with the use of drivers because not all testing components, particularly external data and systems, may be available in the current environment. This approach also provides the tester with direct control over the transactions being sent to the external entity to minimize the potential for functionality errors in client or Graphical User Interface (GUI) code modules. After initial testing, we re-execute the tests without the use of stubs and drivers. When testing with an external organization, we provide a copy of all test cases to the external organization for review to permit coordination of test execution and synchronization of data. In each stage of interface testing, our team will document details of the type of tests performed, tools employed, and test outcomes.

The purpose of Consolidated Integration Testing is to establish confidence that when introduced to the production environment, the new or revised interface:

Operates correctly and delivers the required functionality

Does not cause undesired effects in systems with which it interacts or co-exists

Does not cause undesired effects to data shared with other systems with which it interacts or co-exists.

Consolidated Integration Testing includes the end-to-end testing of all software including interfaces with external entities and batch and online software.

Consolidated Integration Testing focuses on:

Testing of the new software in a production-like environment in tandem with other software with which it is required to interact or co-exist

Testing to make sure that only required effects are manifested on databases and the data within them, whether or not the data is directly manipulated by the new software.

M-79 The Contractor shall assist CDCR with testing and release preparation in the pre-production environment.

N/A




Team EDS will comply fully with RFP Requirement M-79, and we provide staff to assist with testing and release preparation.

During acceptance testing, the release testing manager and the system integration testing lead will support the development of the User Acceptance Test Plan for each release. EDS test analysts and testers from the System Integration Testing team will be assigned to assist CDCR to execute UAT cases. In addition, Team EDS will offer CDCR staff the opportunity to act as “test witnesses” during system and integration test execution and will provide access to test scripts and test cases. EDS’ technical resources will support the development of the Operational Acceptance Test Plan and development and execution of operational acceptance test cases.

M-80 The Contractor must produce and execute an On-Site Implementation Support Plan.

N/A


Team EDS will submit an Implementation Plan for each project and phase of SOMS as specified in the RFP. The Implementation Plan will include a section that details activities and responsibilities for providing on-site implementation support. The On-Site Implementation Support Plan contained in the Implementation Plan, will present an overview of the type, duration, and level of support provided to each user and will include site-specific information about the number and type of resources provided and the duration and source of support, either EDS or CDCR.

As we stated in our response to RFP Requirement M-56, we work with CDCR to designate an on-site SOMS project liaison at each institution and each parole office. Team EDS will coordinate on-site implementation activities with CDCR’s on-site liaisons. In rolling out ERMS, Team EDS will assign a team member to each institution to complete back-file conversion, establish “day forward” scanning of documents, and assist CDCR staff in the use of the document viewer software. For the rollout of institution-based releases (Releases 1A, 1B, 1C, and 3), one or more of our team will be available at each institution during the cutover period. To implement parole functions (Release 2 and Field Service components of Release 3), Team EDS will verify that CDCR’s on-site liaisons have a comprehensive understanding of implementation activities, and we provide 24-hour centralized support. For all projects and phases, EDS project managers and implementation analysts will provide centralized implementation support, and the EDS Help Desk will serve as a point of contact for all field staff to report implementation issues. The help desk will log all calls into the service desk software to facilitate prompt resolution of calls and reporting to CDCR project staff. In addition to on-site implementation support for institutions, Team EDS’ technical staff will provide on-site support to DTS staff during implementation and operation of each release, through the end of the contract period.



M-81 The Contractor must provide staff at the proposed number of staff, ratios and duration for on-site support.

Section 6.9


The On-site Implementation Support Plan contained within the Implementation Plan will itemize the number of support staff and duration of their engagement during the rollout of each SOMS release. As stated in our response to RFP Requirement M-80, Team EDS will provide on-site support, coordinating implementation activities with CDCR-provided on-site liaisons. EDS will also provide centralized implementation support, including 24x7 help desk support. Our response to RFP Requirement M-89 in Section 6.9, Production Support and Transition, outlines aspects of centralized support and associated staffing levels for the help desk.

Team EDS will also provide on-site technical support to DTS during implementation and operation of the production operating environment through the end of the contract period.

M-82 The Contractor must assess the pre-implementation readiness of each part of the organization and shall document the status in a Pre-Implementation Readiness Assessment.

The Contractor shall conduct an implementation readiness review ten days prior to cutover at each part of the organization.

Volume 1 – Appendices

Appendix Q


Implementation readiness assessments are a fundamental element of our approach to ensuring a smooth ‘glide path’ into system implementation. Accordingly, we conduct a review, at a minimum, 10 days before cutover of each release. As a rule, for complex projects such as SOMS, EDS holds a dress-rehearsal review approximately 20 days before the implementation date, allowing early visibility and action on potential issues and risks, fully recognizing that not all activities will be complete at this point. Team EDS follows a structured approach to these operational readiness reviews, from which we can leverage check-lists and other assets. These reviews are part of a whole life-cycle milestone review process that incorporates Preliminary Design Reviews and Critical Design Reviews. Appendix Q, presents a sample Pre-Production Release Plan.

VI.D.9.i. Production Release Plan Requirements

Req.




M-83 Upon successful completion of the Pre-Production testing, the Contractor shall, in coordination with CDCR, create a Production Release Plan that shall consist of an updated Pre-Production Release notification to assist CDCR in successfully releasing and maintaining the system in the Production environment. It must include, but not be limited to, the following components:

Updated Configuration Information required satisfying the CDCR production configuration management requirements.

Updated System Architecture.

Updated Detailed Design, including detailed system, technical, and user documentation.

An updated Data Conversion Release document.

Deployment schedule.


Appendix Q


Appendix Q, also presents a sample Production Release Plan from our Case Management Information and Payroll System (CMIPS II) project. In accordance with RFP instructions, Team EDS will submit a Production Release Plan, tailored specifically for each release of the SOMS project. At the completion of pre-production and UAT of each release, EDS will work with CDCR to assemble a Production Release Plan that documents hardware installation, software promotion, and necessary testing procedures to migrate the release from the pre-production environment into the production environment.

In conjunction with each Production Release Plan, EDS will update the technical infrastructure and associated environment and software configuration manuals. As stated in our response to RFP Requirement M-70, our structured approach to configuration management will be instrumental in providing CDCR with a comprehensive and accurate Production Release Plan. The Production Release Plan will also identify revisions to legacy systems, including decommissioning of the system, and an updated Data Conversion Plan and Readiness Assessment document. The Production Release Plan, the overall Implementation Plan, and the On-site Implementation Support Plan will collectively document all aspects of cutover of each SOMS release.


doc

Documents

requirementresponse referencenum

data privacy considerations

notifying administrative staff

entire technology stack

management requirements responsevi

management requirements responsem

bidder response detail

operational recovery plan