DOC

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

6.9 Production Support and Transition

Subsection 6.9: Production Support and Transition

This subsection must include a narrative describing the QBP’s approach to production support and transition and a sample Production Support and Transition Plan used by the QBP on another project as described in Section VI.D.12 – Production Support & Transition.

VI.D.12. Production Support & Transition

Req.

Num.Requirement Response / Reference

M-89 The Contractor shall describe the production support and transition approach and methodology used for the SOMS Project.

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

Section 6.8,

Section 6.3,

Section 5.0,

Section 6.4

Bidder Response Detail:

As a global leader in the design, development, and implementation of complex programs, EDS considers stability, maintainability, and performance to be critical to project success. For California SOMS, Team EDS continues our history of providing superior production support by leveraging our vast experience, infrastructure and proven service management practices.

The following sections describe Team EDS’ approach to providing ongoing production support of SOMS. Our approach includes activities related to successfully supporting and operating the SOMS components at levels that meet CDCR’s goals and expectations. Team EDS delivers service-level agreements (SLAs) for the aspects of production support through phases of the program. These SLAs guide our performance through design, development, implementation, and operation of SOMS.

Production Support Philosophy

Team EDS’ overall operations and maintenance philosophy is to support and manage SOMS and related system components at levels that meet CDCR’s requirements and expectations. EDS understands that system availability and resiliency is vital to systems that support critical functions such as support staff and public safety. The SOMS enterprise architecture is designed to provide multiple redundancies in order to facilitate un-interrupted service due to server, storage, data center, and network failures. Team EDS resolves operational issues, concerns, or problems related to SOMS operations consistently, efficiently, and promptly using world class process, procedures, and methodologies that are leveraged across our thousands of clients. Team EDS continually improves service levels collaboratively with the CDCR and Department of Technology Services (DTS) through structured methodologies, procedures, and a joint commitment to quality.

EDS SOMS STATEMENT OF WORK EXHIBIT I -339


Communication throughout the project management process with open communication at each project level is the focal point of every successful partnership. Team EDS documents the communication process during the establishment of the SOMS Project Management Office (PMO). The SOMS Communication Plan includes an overview of the operations of the project and the interactions required and desired. It includes standards, guidelines, and formats for communications while allowing flexibility for informal and productive interaction. Additionally, the SOMS project workbook is made available to CDCR for understanding the current status of the SOMS project.

The use of standards facilitates the execution of effective communication with SOMS project participants, promotes quality, and lessens the risk of miscommunication.

To execute Team EDS’ SOMS operations and maintenance philosophy, we continue to use EDS’ Project Management methodology, Version 2 (PM 2®), which is based on Project Management Body of Knowledge (PMBOK®) practices, Software Engineering Institute (SEI®) best practices, and Project Management Institute (PMI®) fundamentals. This approach to project management aligns with CDCR’s project management practices and is used by project management professionals worldwide. PM 2® is a methodology that prescribes a defined, systematic method to plan, direct, monitor, adjust, and control a series of interrelated project activities. Applying our structured, well-defined project management methodology helps reduce project risk along with meeting SOMS operational and maintenance goals.

During the operational phase of SOMS, Team EDS operates, manages, and supports the five SOMS environments along with infrastructure supporting the PMO. A structured approach to manage the ongoing operations and maintenance of SOMS provides the foundation for success of SOMS throughout the operational period. EDS’ structured approach for production support and service management is based on the ITIL framework. EDS’ application of this framework for service delivery is described below in Figure 6.9-1, EDS Common Process – ITIL Process Architecture. This architecture provides the foundation for production support activities, from planning to implementation.

EXHIBIT I -340 EDS SOMS STATEMENT OF WORK


Service LevelManagement

Service Delivery

Operations

IT FinancialManagement

SecurityManagement

CapacityManagement

IT Service Continuity

Management

Design & Planning

Deployment

Application Design

Application Build

Service DeskIncident

Management

ProblemManagement

ChangeManagement

Note: Only key process interfaces are shown

I CT I nfrastructure Management

Technical Support

Service Support

Business Asset Management

<Client>User

IT Asset Management

(Software & Procurement)

<Client>

Clarity Project Workbook

ConfigurationManagement

ReleaseManagement

Business Forecast

ITIL Service Delivery

ITIL Service Support

ITIL ICTIM

EDS Best Practice

ITIL Security Mgmt.

ITIL Application Mgmt.

Client Process

AvailabilityManagement

Request Management

BusinessManagement

Processes

Figure 6.9-1, EDS Common Process – ITIL Process Architecture

EDS’ ITIL Process Architecture is the foundation for Production Support Activities

Throughout production support activities, Team EDS maintains the operational focus, performing the necessary request management, incident management, problem management, change management, release management, and configuration management activities as shown below in the Figure 6.9-2, Operational Focus of Service Management.



Serv

ice D

esk

ConfigurationManagement

Th

e B

usin

ess

an

d U

sers

CM

DB

Changes

Request Management

I ncidentManagement

ProblemManagement

ChangeManagement

ReleaseManagement

ReleasesCla

rity

Pro

ject

W

ork

book

Monitor and Manage Events

I T AssetManagement

Figure 6.9-2, Operational Focus of Service Management

EDS’ ITIL based service management process maintains SOMS operational focus

Reporting required by CDCR from these activities will be viewed through the Clarity Project Workbook, providing effective communication and transparency to Team EDS production support activities.

Our approach to providing operations and maintenance for SOMS is based on the relationships, procedures, and methodologies established during SOMS design, development, and implementation. The maintenance and operation of SOMS involves complex multidisciplinary tasks and functions. During the project, Team EDS and CDCR will focus on the successful development and implementation of SOMS. During this time, we also focus on strengthening team relationships for the successful transition of SOMS production support to CDCR. This focus includes the necessary documentation, the SOMS project workbook, and joint work activities for a smooth transition.

Strict quality control procedures help to provide the highest levels of quality and customer service. We rely on our quality staff to develop, implement, and enforce quality control and assurance policies and procedures. Further, we use feedback from CDCR to verify that our quality control measures are providing the required level of service and quality to CDCR. We achieve these quality metrics in accordance with the EDS Global Application Development Quality Management System (GAD QMS), the quality management approach described in Section 6.8 Quality Management.



Quality control is essential for SOMS’ success, and in accordance with Team EDS’ policy, we include quality reviews and audits of the tasks, activities, system operations processes, and change control procedures for SOMS. Our overall project management approach is based on an understanding that system operation activities, performance metrics, and quality reviews must be fully integrated throughout the operations and maintenance functions to provide the highest degree of customer support.

Team EDS provides operation quality metrics designed to collect, measure, and report on project status at a high and detailed level. We use metrics as part of a continuous business process improvement program. These metrics may include system availability, incident/problem reporting, and change implementation success rates. Quality is a priority for Team EDS. Periodic internal quality assurance audits, conducted at the direction of Team EDS’ top management, enforce the SOMS Project Management Methodology.

The SOMS production team is responsible for SOMS operations, SOMS application maintenance, help desk functions, and maintenance of overall system performance levels during the operational period.

Information Technology Outsourcing Capability

EDS Information Technology Outsourcing (ITO) capability is delivered through our world-wide network of data centers and operations centers supported by our industry recognized service management capabilities. According to the Forrester Wave “Vendor Summary Q2 2007” report, “EDS is a go-to choice for enterprise infrastructure outsourcing clients” and “its Implementation Management processes make operational sense; are extremely detailed; and have been tested across regions, verticals and time. Reference clients awarded a perfect score for their experience with EDS’ implementation capability.”1 EDS is also the number one ranked supplier of IT outsourcing by Brown-Wilson base on client satisfaction and growth.2

ITO support is delivered by assets such as the EDS Service Management Centers (SMC), Global Services Network (GSN) and Service Delivery Network (SDN). The EDS SMC is our global chain of Tier Four data centers and the primary means we provide hosting services to our client. The EDS Sacramento SMC, also known as the Data Center, is located in Rancho Cordova, California and is the primary management center for the Western Regional Hub. The EDS SMCs are equipped with anti-vehicle perimeter barricades, 24x7x365 on site security and biometric access controls. EDS incorporates security incident reporting procedures in the SOMS project management and facilities management plans.

In addition to the robust technical capabilities provided by the EDS SMC, the close proximity of the EDS Sacramento Data Center to the DTS Gold Camp and CDCR Aerojet facilities benefits the State. Use of local telecommunications

1 Roehrig, Paul, (June 14, 2007). “EDS Is A Leader in Global IT Infrastructure Outsourcing.” Forrester Wave Vendor Summary, Q2 2007.2 Brown & Wilson, http://brown-wilson.com/index.htm



circuits reduces total cost of ownership as compared to long haul circuits. The close proximity of our two facilities also greatly aid ongoing knowledge transfer activities throughout the project and eventual system transfer to the State.

The GSN is our global wide area network (WAN) which provides connectivity between client and EDS resources. Utilization of the EDS GSN provides a WAN solution that is highly reliable based on support from multiple circuit supplies and scalable in increments that reflect system needs. The essential value of the GSN lies in its ability to provide end-to-end service quality to the State. By connecting to EDS using the GSN, the State has the advantage of a proven, robust network environment with access to EDS’ full suite of services. We provide you with a comprehensive approach to connecting you to services. You can realize the following benefits with the EDS GSN:

Best-in-class service delivery – Access to the entire portfolio of EDS services (BPO, Applications, IT Outsourcing), comprehensive single point of accountability for multivendor carrier environment, and advanced management capabilities with end-to-end service visibility

Improved quality - Lower risk with network reliability, resiliency, and security management; increased network performance through improved efficiencies; and end-to-end service assurance and quality of service

Speed to market - IP network that assists clients by bringing new services to market faster and scales network environment as business needs change

In addition to our capabilities to support the WAN connections between the CDCR, DTS and EDS infrastructure, we offer a proven solution for data center networks based on our Service Delivery Network (SDN) architecture. The highly extensive network architecture of the SDN provides a standard provisioning process which is custom tailored to the individual needs of our clients. The standards based aspects of the SDN facilitate rapid deployment, security and network performance. The SDN design complies with DTS and CDCR security standards via an architecture that compartmentalizes the SOMS system components. Additionally the EDS SDN solution utilizes the same Cisco based architecture that is implemented by the State for CSGNet and CITIP. The familiarity of the network design and use of common components facilitate integration with State infrastructure and eventual system management transfer.

In addition to industry leading Cisco based intrusion detection and prevention systems, the SOMS is also supported by the EDS Global Network Operations Center (GNOC) and Regional Network Operations Centers (RNOC). In addition to automated detection and reporting, the SOMS will be supported by the GNOC, our network operations centers supported by over 4,700 professionals. The GNOC augments our ability to meet State security reporting requirements from 24x7x365 monitoring by security professionals to facilitate detection and response to new attack patterns that have not yet been incorporated into automated solutions by product vendors.



EDS Enterprise Service Management (ESM) Framework

The EDS Enterprise Service Management (ESM) framework is built upon our 40 years of IT outsourcing experience, leading industry partnerships, innovative management infrastructure and practices that are aligned with recognized standards such as Information Technology Infrastructure Library (ITIL) and Information Technology Service Management (ITSM). As one of the oldest and largest players in the IT outsourcing service space, EDS is one of the pioneers of ESM. The EDS ESM provides a cohesive IT management framework based on a collection of standardized processes and enabling technology that supports our global base of clients. The EDS ESM was architected to avoid siloed and heterogeneous IT that are both expensive and complex to manage. The EDS ESM is designed to meet the following goals:

Connecting “delivery of IT” work to business value

Alignment of IT resources and processes to business objectives

Create operational consistency

Deliver consistent, high-quality, cost-effective service

Reduce IT risk and expense

EDS has integrated process frameworks and best practices for IT operations, applications and security that reach far beyond ITIL alignment. The EDS ESM is based on a holistic approach to service management that encompasses ITIL as well as other best practices, including ICT (Information Communication Technology) infrastructure management, IT security management and IT business management. Our ESM has an unmatched breadth of process frameworks that EDS has implemented globally in a common and consistent fashion, with a high degree of integration between those process frameworks. The ESM is composed of a standard, integrated technology stack deployed consistently around the world to deliver common and consistent business processes In addition to technology, the ESM provides the alignment of people to deliver and support a common and consistent tool-set and processes globally. The ESM is a critical aspect of EDS fulfillment of the requirements noted in this section via our Enterprise Monitoring and Instrumentation (EMI) framework, response and escalation capability, along with our GNOC which provides round the clock network and security monitoring. The EDS ESM framework is the way we do business and delivery services to our clients as well as support our internal operations.

A key component of the ESM and general delivery of services is the EDS Agility Alliance, an industry recognized partnership with the world’s leading technology providers such as Cisco, EMC, Oracle and Sun. The mission of the EDS Agility Alliance is to create a seamlessly integrated platform that delivers robust, relevant and value driven technology services to clients around the globe. At the core of this Alliance is the deep collaborative engineering that occurs between EDS and our partners. To develop the Agile Enterprise Platform, we created a unique ecosystem of partners. The EDS Agility Alliance combines market-leading



infrastructure, application and business process providers chartered with driving industry innovation and cost leadership. The partners that are included in the EDS Agility Alliance represent broad-based companies that are globally recognized for their quality, products and value to clients. Collectively, EDS and its Agility Alliance partners collaborate to design build and run a market leading services platform and develop technology based services that deliver tangible results to our clients.

The EDS Agility Alliance is more than just a vehicle for product delivery; the Alliance fosters a deep level of collaboration and cross-pollination of ideas that enhances the way its members deliver services. The Alliance maintains two dedicated joint innovation centers that are solely staffed by participating companies. Clients can visit the centers to access our joint talent, addressing business and technology issues and opportunities. Work there also enables EDS to quickly develop and enhance our services – and fulfill our delivery transformation objectives. The Alliance also promotes expertise among our staff in our partners’ technologies via the EDS Top Gun Program. EDS Top Gun is a total immersion program designed to provide an intensive three-month technical opportunity to nominated EDS senior-level architects. The program is designed to make certain that EDS architects around the globe have deep, hands-on experience with our partners' technologies and products today and a clear vision of the road map for tomorrow.

In addition to the Agility Alliance, EDS industry leading services rely on service management practices and supporting infrastructure based on recognized standards such as ITIL and ITSM. EDS has a well earned reputation for excellence because of the maturity and effectiveness of our maintenance and monitoring procedures honed during the 40 years of our company’s existence. Well defined procedures make sure that in the event a problem is detected, the appropriate response and personal are notified to remedy the situation. Systems such as the EDS On Call Notification (EON) make certain that issues are responded to rapidly. In the event an issue requires escalation, the EDS Response to Operational Problems (RtOPs) is activated to engage State and EDS management. Both EON and RtOPs, along with our other enterprise support systems are supported by highly redundant infrastructure to provide constant vigilance and response. With our vast personnel base covering relevant areas of expertise to SOMS, the State can be assured that there is always someone available with the right skills to resolve issues rapidly.

With the ESM, EDS can recognize issues, resolve problems and service client requests faster. Additionally, the ESM reduces system problems via its innate predictive analytics capability which detects future issues for proactive remediation before the SOMS operations are affected. Additionally, the SOMS monitoring repository provides a single “version of the truth” for production support teams facilitating more efficient root cause analysis. As a result, the State benefits from decreased mean time to resolution for ITO services and faster response time to client requests. In addition to our monitoring frameworks, systems such as EON and RtOPs facilitate rapid response and improved speed/agility to system anomalies. According to Forrester, EDS is “EDS is best suited for robust infrastructure management delivery” and is especially good fit



for clients who “want a mature set of methodologies and process management. EDS operations utilize ITIL based process frameworks and policy-driven tools.”3

Overview to SOMS Production Support

Team EDS uses a robust application development environment that includes a proven approach to modifications and enhancements for the SOMS solution. This environment supports a disciplined approach for implementing solution changes. Our proven methodology provides us with the ability to maintain SOMS with current application functions through regular, monthly enhancement releases, which can include application defect resolution, functional enhancements, and regulatory changes. Team EDS works with CDCR to determine

the most effective schedule to implement these application releases. We prepare a comprehensive System Turnover Plan, which is further described in this section. Our Plan provides for a smooth transition of the knowledge, operations, procedures, programs, and data for the SOMS application.

Team EDS understands that it is crucial that CDCR operations are not disturbed by any SOMS transition. With our structured approach to project management and project implementation, Team EDS supports a smooth transition while continuing to meet system performance and availability requirements. This approach applies equally to supporting the SOMS rollout and the retirement of CDCR legacy systems.

Team EDS understands that SOMS production support begins during the development phases and continues through SOMS’ full implementation followed by transition to the CDCR and DTS. The EDS SOMS solution includes a rich set of production support functions associated with application software stability and system fixes required to correct any defect in the software or documentation. Additionally, it facilitates the incorporation of State- or federal-mandated system modifications as part of providing the following core services:

Operations

Help Desk

Maintenance

Turnover Plan

For each function performed, Team EDS provides appropriate reports including weekly and monthly reports related to operations, help desk, and maintenance. We work with CDCR to develop the required content, format, and delivery schedule using the status reporting during Design, Development, and Implementation (DDI) as a foundation. Team EDS makes sure that information is

3 Peynot, Richard & Takahashi, Sonoko (August 31, 2007). “EDS Provides Solid Remote Infrastructure Management.” The Forrester Wave™ Vendor Summary, Q3 2007



available to the appropriate CDCR team members when required. The following figure, Sample Help Desk Dashboard Report, Figure 6.9-3, is an excerpt from a monthly dashboard or status report on help desk service levels. These reports shall be available within the project workbook tool, CA Clarity.

Help Desk

The following are the statistics for September for the help desk SLAs:

• Call Abandonment Rate—Abandoned Calls—0.3% (Actual), Pass (SLA = <4%).

• Call Waiting Time—Answered Calls—99.4% (Actual), Pass (SLA = > 95%).

• First Contact Resolution Rate—CDCR State and regional facilites—93.5%, Pass (SLA = > 75%). HCPF State and MA sites—99%, Pass (SLA = > 85%).

• Ticket Resolution Rate:

– Priority 1—100%, Pass (SLA = > 90%)


– Priority 3—99.7%, Pass (SLA = > 85%)


Figure 6.9-3, Sample Help Desk Dashboard Report

Our proven practices serves the CDCR in multiple ways: First, the SOMS project benefits from solid management facilitating an accurate and reliable system. Second, during transition, Team EDS works closely and collaboratively with the CDCR and Department of Technology Services (DTS) staff during which the State and Team EDS combines the best aspects of both management practices.

As previously stated, Team EDS’ overall operations philosophy is to support, manage, and operate the SOMS application and system software at levels that meet the State’s requirements and expectations. Team EDS is dedicated to working closely with CDCR to successfully operate SOMS within the agreed scope.

Team EDS’ goal is to provide SOMS application software that has no Level 1, 2, or 3 outstanding defects at the beginning of operations. Level 1, 2, and 3 defects are defined by Table 6.9-1 below:

Table 6.9-1, Level 1, 2, and 3 Defects

Severity

LevelDefinition

OneThere is a complete or severe loss of service in at least one mission critical area; the CDCR operations cannot reasonably continue, or can continue only in a restricted fashion; and service delivery to customers is disrupted.

TwoThere is a complete or severe loss of service in at least one area considered non-mission critical, the CDCR operations cannot reasonably continue, or can continue only in a restricted fashion, and service delivery to customers is disrupted.



ThreeThere is a minor loss of service. The impact is an inconvenience and mission critical areas are not significantly impaired. The CDCR operations continue with minimal disruption. A workaround, acceptable to CDCR, may be employed temporarily to restore service and business operations.

If any defect occurs during operations, the defect is resolved in accordance with the approved SLA. In accordance with the approved implementation schedule, we consider this goal completed when SOMS has met the SLAs in production for the warranty period and the CDCR contract manager has approved the required deliverables.

Team EDS brings to this project the necessary expertise, leadership, technology, creative thinking, and cooperation it takes to excel in the operations arena. We recommend the early integration of ongoing operations into the usual development cycle as this promotes a smoother and more reliable transition to full production for the application. This is particularly true with the advent of rapid design and iterative development cycles made possible by modern open architectures and tools. The deployment of SOMS benefits directly from this approach and the proven experience of Team EDS, as establishing the production support processes allows for thorough testing and refinement prior to production implementation of the SOMS solution.

Team EDS provides full support for the areas of operations described in the following sections until CDCR prefers to take responsibility for SOMS operations. Using the process documentation and work instructions that Team EDS establishes with the State’s participation in knowledge transfer with Team EDS, CDCR and DTS will be well-prepared to take full responsibility for SOMS operations. Section 6.3 Knowledge Transfer and Training details the processes to train CDCR and DTS staff for SOMS operations.

The customer support work pattern encompasses PM 2®, EDS’ project management methodology, described in the preceding Project Management Approach section, and includes the following:

Adaptive maintenance – This is maintenance to an application due to changes in the environment in which it operates. User functions are not affected.

Corrective maintenance – These are specific actions to be taken to eliminate or minimize the impact of known deficiencies. Corrective maintenance consists of maintenance to an application that corrects defects in the application. User functions are not affected.

Perfective maintenance – This is maintenance that modifies an application to improve its operation, such as runtime improvements. User functions are not affected.

Customer support consists of the tasks and activities that enable the ongoing operation of productive applications based on the applications operation requirements provided by CDCR. The following tasks are used to verify conformance to operational requirements:



Application production support – Team EDS monitors the SOMS solution performance for conformance to operational and business requirements.

Application on-call support – Team EDS has staff available to respond to reported application production issues or failures. Team EDS performs root cause analysis, correction, and restoration of the production application.

Preventive maintenance – Team EDS performs application backup, database performance analysis tuning, and system resource planning.

Configuration management – Team EDS employs an inventory management process to classify, store, and control IT delivery components.

Release management – Team EDS takes a holistic view of a change to the SOMS solution and makes sure the technical and nontechnical aspects of a release are considered together.

Change management – Team EDS makes sure standardized methods and procedures are used for efficient and prompt handling of changes to minimize the impact of any related incidents on service.

Customer support provides the services required to keep SOMS operating effectively but do not affect the application software baseline. Customer support consists of processes to monitor the application, provide client support, perform incident management, perform deficiency management, and perform corrective application maintenance (defect management).

Operations Support: Monitor Support

Operations support is focused primarily on the processes that compare and evaluate actual system performance to system specifications in the areas of response times, outputs, application data, and other performance characteristics. Operations support initiates the resolution of any anomalies. These activities and processes are referred to as Monitor Support activities.

Monitor Support activities are managed by the following four main areas:

Systems administration – This group is responsible for physical data security, user management, storage administration, and systems resource management. These tasks use the tools listed in Section 5.0 Technical Requirements to monitor and manage system loads on the servers to verify that server performance is optimal. For example, if one server is continually operating above 80 percent capacity while another server is operating at a significantly lower percentage, steps are taken to balance the workload among the SOMS enterprise servers. This enables Team EDS to make the best use of available resources and optimize system response time. Systems administration is responsible for monitoring the disk space on the enterprise server to make sure the disk drives are used efficiently.

Database administration – Database administration functions consist of developing and implementing database backup and recovery procedures to minimize data loss if there is a database failure. Team EDS also develops the



procedure to perform the requisite daily and weekly maintenance on SOMS databases. This includes examining the page allocations to verify that there are no corrupted tables in the database, periodically re-indexing the database tables, and monitoring and tuning the database devices for performance.

Computer operations – Computer operations functions consists of managing, planning, scheduling, and monitoring the SOMS batch cycles. Computer operations monitors the batch cycles for any abnormalities or errors, including file transmissions.

Business Continuity/Disaster Recovery – Team EDS delivers the SOMS Business Continuity/Disaster Recovery Plan and makes sure it is consistent with State business continuity and disaster recovery requirements. The Plan documents the processes, procedures, and tools used for disaster recovery, including a description of the monitoring, testing, and plan revision processes. The flow of activities for this process is depicted below in Figure 6.9-4, Monitor Support Process.

Figure 6.9-4, Monitor Support Process

The Monitor Support steps are further described as follows:

Monitor application – Team EDS verifies that the production application performs correctly and that other contractual requirements are met. Team EDS verifies critical jobs, tasks, and transactions that must be completed within a particular window to facilitate successful completion within the specified time, and any anomalies observed are recorded using the CA Service Desk incident/deficiency tracking application.

Check outputs – Team EDS verifies that the identified outputs from the application that need to be validated have been checked for accuracy according to documented specifications and records any anomalies observed using the CA Service Desk incident/deficiency tracking application.

Monitor application data – Team EDS verifies that the data that belongs to the application is consistent and records any anomalies observed using the CA Service Desk incident/deficiency tracking application.



Monitor performance – Team EDS evaluates the application for performance efficiency and potential performance Deficiencies. The system is monitored for compliance with service-level agreements (SLAs). EDS records any anomalies observed using the CA Service Desk incident/Deficiency tracking application.

Validate application continuity – Team EDS conducts a disaster recovery drill based on the documented plan, analyzes and reports the results of the drill, determines if the existing plan is accurate and complete, and records any anomalies observed using CA Service Desk incident/deficiency tracking application.

Identify issues and resolutions – Team EDS reviews monitoring results and determines if any issues exist. We notify the affected groups of any issues observed. If any changes to the environment are scheduled, Team EDS determines if application changes are required. If application changes are indicated from issues or scheduled systems environment changes, Team EDS creates the necessary application service requests. We determine if the issue is an incident (any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service) or a deficiency (unknown underlying cause of one or more incidents). Incidents or Deficiencies are documented using the CA Service Desk incident/deficiency tracking application.

Collect measurement data – Team EDS verifies that required measurement data is being accurately recorded and collected in accordance with approved standards, including reporting of system size, performance and usage instrumentation, database size, and system data analysis.

Batch Processing

Despite the online processing focus of the SOMS solution, some batch processing is required for interfaces with legacy systems that do not offer real time data interchange, scheduled reports or wide scale statewide sentence recalculations initiated by policy change. The SOMS system is fully available during batch operations due to our infrastructure architecture and deployment of a reporting environment that is isolated from production operations. The SOMS job control system is also used to schedule system maintenance such as database backups. Use of the job control system for scheduled activities provides and enterprise-wide view of system activities facilitating smooth operations.

Team EDS’ batch scheduling and execution team is responsible for managing, planning, scheduling, and monitoring batch operations for the post-development environments, such as user acceptance testing (UAT), training, and production. This includes batch execution, restart, and recovery of batch jobs. Automated scheduling software—Computer Associates’ dSeries Workload Automation (Cybermation)— maximizes the batch cycle processing windows for relevant processes.

The batch scheduling and execution team is responsible for the following activities:



Conducting batch cycle planning

Setting up and maintaining the batch job schedules and documentation

Communicating and coordinating with the State and Team EDS

Coordinating, executing, and monitoring multiple batch cycles

Coordinating and scheduling special requests

Confirming that interface files are properly sent and received

If batch errors occur, this team identifies the problem, notify the appropriate personnel, coordinate resolution, and take corrective action. This team supports the batch cycles through to successful completion and process requests for retransmission of files.

Team EDS designs and implements batch cycle processing so that nightly cycles are completed under a schedule that permits online functions to execute against accurate, updated data daily.

The graphic below, Figure 6.9-5, Sample Batch Cycle in CA dSeries Workload Automation shows how CA dSeries displays a batch cycle.



Figure 6.9-5, Sample Batch Cycle in CA dSeries Workload Automation

dSeries offers a wide variety of metric gathering and standard reporting features such as job duration start and stop times along with deviations. dSeries provides trend analysis reports to facilitate proactive action when cycles of specific jobs increase in duration. Additionally, dSeries provides job schedule modeling and forecasting function which adds to EDS capability to proactively manage SOMS operations. As part of the CA Unicenter suite of tools, the SOMS job control system interacts with the project help desk via the Service Desk application.

Among many other features, dSeries offers features that facilitate batch operations in online oriented systems such as the SOMS through flexible workload scheduling and native SOA integration. The SOMS performance monitoring framework integrates with dSeries, to verify that batch operations do not interfere with online access. In the event the SOMS performance monitoring framework determines resource thresholds have been hit, the system will automatically reduce the amount of batch activity to proactively avoid competition of resources with online activity. For example, if thresholds are met that indicate online performance may be impacted, dSeries will adjust jobs to reduce system load.

Application Support: Incident Management

The primary focus of application support services is to provide incident and deficiency management services in addition to customer support activities that do not affect the application software baseline. This includes handling on-demand requests for issue investigation, providing answers to questions, and performing parameter and schedule changes. Application support services consist of an overall process approach called Provide Client Support.

Provide Client Support activities touch the entire Team EDS but are managed and tracked by a single point of contact. The SOMS help desk is the primary communication link between Team EDS and CDCR. CDCR may contact the SOMS help desk with any operational issues, concerns, or problems related to the SOMS application, telecommunications, enterprise computing components, or the hardware and system software supported by Team EDS. The SOMS help desk is staffed with a comprehensive team including hardware, system software, enterprise computing, and SOMS application specialists.

Reported operational issues or problems are logged through an automated issue tracking system, CA Unicenter ServicePlus Service Desk. If help desk staff is unable to resolve a reported deficiency, the deficiency is given higher priority and assigned to an appropriate group within the production support team for resolution. After assigned, Team EDS contacts the reporting person quickly and work closely with that person toward a resolution. Reported problems and issues are assigned an identification number, which tracks the deficiency until it is resolved.

The Incident Management tasks are further described as follows:



Initiate request processing – Team EDS documents each CDCR request or any incident or deficiency that requires a production change with sufficient information to categorize the request, identifies the requestor, and fully defines the request. Whenever possible, Team EDS provides an immediate response to CDCR. If the request can be completely satisfied, we update the request documentation with the response and mark the request complete. If the request cannot be completely addressed at this point, we acknowledge the request, update the request documentation, and forward the request to an appropriate subject matter expert (SME). Team EDS updates CA Service Desk to reflect the status of any incidents or problems.

Perform necessary research – Team EDS consults with CDCR to better understand the request and provide information about the request that is readily available. We assemble any documentation needed to accurately and efficiently address the request. Based on a review of the available information, we determine the best approach to satisfying the request and document the steps taken. Team EDS determines if the request is an incident or a deficiency and updates CA Service Desk to reflect the status of any incidents or problems.

Provide requested service – Team EDS performs the requested service according to the established procedures for SOMS. If the request is for a small application change that does not affect the application software baseline, such as a change to an application parameter or a change to a production schedule, we provide the service as defined in the application support documentation, consolidate the information, and review it with or report it to the CDCR.

Monitor and track – Team EDS reviews open CDCR requests regularly to make sure they are addressed quickly. We verify that required measurement data is being accurately recorded and collected in accordance with organizational and approved standards.

Conduct application training – If appropriate for the request, EDS conducts training in accordance with the training plan. Training may be conducted using a separate environment and scheduled in parallel with other implementation activities or as part of ongoing production support activities.

The purpose of incident management is to detect and resolve incidents. An incident is an event that is not part of the usual operation of a service and that causes, or may cause, an interruption to or a reduction in the quality of that service. As is the case with the Provide Client Support process, the SOMS help desk is the single point of contact for management and execution of this process.

The Incident Management steps are described as follows:

Recognize and assign incident – On receipt of an incident request, Team EDS validates that the incident is properly assigned or reassigns it as needed. EDS assigns an application support resource to manage the incident and initiate incident tracking. Team EDS makes sure the incidents are documented according to defined standards, identifies any similar incidents, and



determines if the new incident requires individual activity or can wait until the existing active incident is resolved.

Prioritize incident – Team EDS prioritizes incidents based on impact and urgency, determines the schedule of resolving incidents based on priority, and determines the method of resolution and elapsed time. Team EDS uses the approved SLAs and priority definitions to determine if the incident is a major incident.

Resolve incident – Team EDS confirms that the assigned resource has authority levels that are adequate to coordinate and control the resolution. We determine if the new incident is similar to an existing incident and requires individual activity or can wait until the existing active incident is resolved. We research previously resolved incidents and known errors to determine if a defined resolution is available. We follow documented procedures to manage the impact of service incidents. Team EDS identifies and verifies the solution for the incident and performs any action to resolve the incident if possible. Team EDS reviews major incidents with the organizations responsible for making permanent fixes and creates application service requests as needed.

Perform temporary fix – If SOMS service is interrupted, Team EDS determines the cause of the interruption and decides on the best temporary resolution. EDS produces, verifies, and implements the fix and communicates the results to CDCR and any others who may be affected.

Finalize incident – Team EDS updates resolved incidents with resolution comments and obtains sign-off from the requestor. Alternatively, we determine if an underlying problem is at the root of the incident by initiating problem management and causal analysis.

Manage incident status – Team EDS monitors the progress of open incidents until their completion and determines if service levels are being met. We escalate the incident if service levels are not being met, if management approvals or authorizations are required, or if management intervention or awareness is required. Team EDS monitors and communicates the status of incidents until resolutions are obtained.

Application Support: Problem Management

The purpose of problem management is to detect and remove errors from the IT infrastructure, including the SOMS application, by performing cause analysis to minimize the occurrence of incidents and maximize efficiency. A problem is a significant incident or multiple incidents that have common symptoms that indicate a single error. As is the case with the Incident Management process, the SOMS help desk is the single point of contact for management and execution of this process.

The graphic, Figure 6.9-6, Problem Management Process represents the flow of activities for this process.



Figure 6.9-6, Problem Management Process

The Problem Management process steps are further described as follows:

Perform proactive problem analysis – Team EDS performs proactive analysis to determine if problems or errors exist that can be subjected to permanent fixes. We research previous incidents and problems to identify trends, volumes, and types to determine if preventive action is needed. Team EDS creates application service requests to correct the underlying cause of problems as needed.

Acknowledge and prioritize problems – Team EDS records problems and prioritizes problem resolution based on effect and urgency. We follow documented procedures to identify, minimize, or avoid the impact of problems; determine the schedule of resolving problems based on priority; and identify the necessary resources, effort, and cost to provide the method of resolution and elapsed time.

Investigate problems – Team EDS investigates the underlying cause of the problem. We record known errors against the current and potentially affected services in addition to the configuration item suspected of being at fault. We verify that current information on known errors and corrected problems are available to problem management. Team EDS submits application service requests if the resolution results in a permanent service to the baseline application.

Perform temporary fix – If SOMS service is interrupted, Team EDS determines the cause of the interruption and decides on the best temporary resolution. We produce, verify, and implement the fix and communicate the results. We provide information on temporary fixes to those affected and to those required to support the affected services. If the cause of the interruption requires permanent correction, Team EDS submits an application service request.

Manage problem resolution – Team EDS monitors the progress of open problems until their completion and determines if service levels are being met. We invoke an escalation process if service levels are not being met so that the appropriate parties are aware of the service level situation. We close the problem and known error after the corrective change has been successfully applied, or if the error is no longer applicable. Team EDS maintains information



on problem resolutions and temporary fixes, including applicability and effectiveness.

The EDS support team responsible for corrective and emergency maintenance is staffed with individuals who have in-depth knowledge of SOMS. We analyze, prioritize, correct, and test software deficiencies, defects, and performance issues reported by users or identified by Team EDS. We document and track through resolution reported problems and the actions taken to correct them. After corrections are made and testing is complete, we document the changes and distribute them to production.

CDCR users may report problems through the SOMS help desk. When the help desk receives a call identifying a problem, a ticket is entered in CA Service Desk.

Team EDS supports the repair of defects (bug fixes) in the SOMS solution. We continue to use a structured systems life cycle (SLC 3) methodology throughout software change analysis, design, and development. This section addresses defect or bug fixes to the application software.

The services provided by Team EDS in this area include the following:

Investigate causes of software defects – After a software defect has been identified by the CDCR or Team EDS, we take the necessary steps to determine the cause of the defect. These steps may include contacting the software manufacturer for off-the-shelf software packages such as Windows XP.

Analyze potential software corrections – For software developed by Team EDS, this process involves determining the appropriate software modifications to correct the defect.

Document required corrections – After a corrective action has been identified, we prepare the appropriate documentation for the correction. This documentation may be in the form of a memo to CDCR with details regarding the defect or a more comprehensive document for more complex defects. In either case, Team EDS works closely with CDCR to determine the content and format of this documentation.

Design and code application corrections – Team EDS uses SLC 3 methodologies to carry out the design and coding of corrections for a defect. A technical design document is prepared and submitted to CDCR for approval before any work is started on a defect. After the technical design has been approved, we code the correction.

Unit test and system test application corrections – After a correction has been coded, we test it in the current system to verify that it functions according to the design specifications.

Migrate software corrections through test environments – After system testing is completed, we us an automated tool to migrate the software correction through the test regions into the user acceptance test (UAT) systems, if



appropriate. The scope of the correction determines if a UAT is warranted because it may not be cost-effective to perform a full UAT on a small bug fix.

Support UAT of corrections – The procedures developed in this stage of the project are set up for UAT of the corrections before they are migrated to production.

Track software migrations – Team EDS tracks and controls software modifications by the change management component of SOMS.

Migrate software corrections into production – We migrate the software corrections into production through the software distribution system developed for SOMS.

Technology Services

Team EDS has a proven history of delivering extensive global system management, increasing network scalability, and providing exceptional application performance and the proven reliability to support changing business needs and network security requirements. As the full-service provider for SOMS, the EDS Technology Services team manages, monitors, and provides support for the SOMS solution.

The Production Support plan organizes these activities into the following four broader categories and discusses the associated methodologies, components, activities, and support structure of each focused group:

Enterprise services – Enterprise services includes management and activities related to the following:

Enterprise server management – Management and maintenance of SOMS enterprise servers

Database management – Installation, configuration, and maintenance of SOMS database systems

Application management – Installation, configuration and maintenance for the SOMS application server systems

Business continuity/disaster recovery – The monitoring, testing, planning, and executing of related processes for the SOMS solution. These processes provide the framework to business continuity and disaster recovery goods and services, including SOMS application software backups, SOMS Data backups consistent with CDCR business continuity and disaster recovery plans

Performance monitoring – Rapid identification of impaired network devices and the transfer of this information to a management device console where Team EDS personnel can take action

Distributed services – Distributed services include the following:



Asset management and hardware and software procurement – The tracking of information, using a managed database, of procurement and asset information related to the SOMS infrastructure.

Software and tools services – Software and tools services include the following:

Software and tools services: Support of the software and tools used for SOMS monitoring, help desk, and tracking change and enhancement requests.

Configuration and release management: Configuration and release management includes the following:

Configuration management: Management and control of SOMS configuration items

Release management: Management and execution of software release to post-development environments such as UAT, training, and production

Operations Reporting

Operations reporting provide the necessary communication of Production Support activities on a regular and frequent basis. These reports include the reports described in the sections below.

Weekly Modifications and Enhancements Status Report

Team EDS submits a weekly status report providing the status of operational activities. This report identifies the system software as well as batch and online operational activities, and shall provide the following information: item identification number, item description, date received, individual assigned, current status, issues, proposed resolution(s), estimated completion date, estimated personnel, actual resources to date, and other information appropriate for tracking work in Clarity.

Monthly Management Summary Report

By the seventh workday following the close of a month, Team EDS delivers a monthly management summary report that provides management information for the operational activities for the reporting period. These reports identify system software, batch and online activities, work in progress, completed work, issues, and plans for completion. They also provide information on staff personnel use.

We work with CDCR to develop the exact format and content descriptions for these weekly and monthly management reports.

Production and Ongoing Maintenance of Operations Guide

As part of the delivery of SOMS, Team EDS develops a SOMS Operations Guide that describes the activities performed in support of SOMS operations. This Guide contains information about the application software, system structure, interfaces, and job flows—including job schedules and dependencies. We also detail the



SOMS backup plan to show full system and incremental backups; operating instructions; and online, batch, and database recovery procedures.

Any change to the system results in an update to the configuration documentation and updates to any impacted procedures. To promote timely application of updates to the guide, EDS assigns primary responsibility for document control of the Operations Guide to an individual in the EDS SOMS production support area. The Operations Guide remains a dynamic, living document with a single, designated person controlling the changes to it. The Operations Guide also is subject to the SOMS configuration management processes and procedures to verify that any updates to the Operations Guide are controlled and managed.

Changes are necessary when anyone becomes aware of inaccuracies or new or changed procedures in the current production version. At such a time, a ticket describing the required updates is opened in CA-Unicenter ServicePlus Service Desk, which is our selected tool for issue tracking, and assigned to the document controller. Team EDS establishes a secondary document controller to assist the primary and provide continuity when the primary is unavailable.

The Operations Guide will be in Microsoft Word format and contain version control. The Operations Guide is reviewed by individuals on the operations team once every quarter. Team EDS uses rigorous quality management to promote continuous improvement of this Guide.

The graphic below, Figure 6.9-7, Partial Sample Operations Guide Table of Contents shows a portion of the table of contents of a sample Operations Guide document.



Figure 6.9-7, Partial Sample Operations Guide Table of Contents

Help Desk

Approach to Help Desk Support

Understanding that system availability is just one consideration in the reliability of the SOMS system, another key success factor is the ability to access SOMS end-user and application support for resolving issues. CDCR requires that the help desk implemented to support SOMS be at two levels, end-user and technical. The EDS experience in the industry, recognized as a Gartner Magic Quadrant Leader for Help Desk Outsourcing, North America, 2008. Based on our experience, the SOMS help desk comprises three industry-standard levels of support to meet user needs efficiently and cost-effectively.

Level 1 help desk support will be staffed 24 x7x365 by EDS personnel available via a toll free number. Level 1 support addresses common issues, such as user functionality issues. To prepare the attendants for this support, we provide orientation and training in the use of the SOMS application, service skills, and established and documented procedures for handling the various types of calls. Help desk training requirements are identified during the analysis phase for each training track.

Team EDS manages and operates the Level 2 and Level 3 help desks to resolve more technical SOMS application issues as they are escalated from the Level 1



help desk. The help desk function is established and staffed from the start of the pilot test in Phase I through the end of the contract. The Level 2 and 3 support teams contain personnel with in depth knowledge of SOMS components enterprise-wide including the Offender Management COTS, business intelligence, database, and other sub-systems.

Staffing and Availability

Level 2 and Level 3 help desk support will be available 24 hours a day, seven days a week. If an issue arises during non-business hours, the Level 1 help desk staff contact the designated on-call Level 2 staff to initiate the SOMS problem resolution procedures. Team EDS implements automated escalation and contact procedures within the Unicenter monitoring toolsets for system detected issues. Supported by robust on call procedures, Team EDS works to confirm that the right resources are available at the right time.

Issue Tracking and Logging

Telephone calls, faxes, and e-mail messages to the help desk are logged into the CA Unicenter ServicePlus Service Desk software by Level 1 help desk attendants. The data in the ServicePlus Service Desk becomes the Problem Report (PR) and includes basic caller information, details of the issue, and the current status of the issue. In addition to incident generation via help desk staff, the SOMS Enterprise Monitoring System (EMS) automatically creates and routes tickets to infrastructure support teams. The graphic below, Figure 6.9-8, CA Unicenter Service Desk Incident Detail, provides a view into the Service Desk tool.



Figure 6.9-8, CA Unicenter Service Desk Incident Detail

The Unicenter relational database enables help desk personnel to perform various searches for information on known problems and review groups of cases that match a given criteria or status. Level 2 help desk attendants continually monitor and track the PR for unresolved problems and takes ownership of outstanding issues to their satisfactory resolution.

Throughout the life of the project, Team EDS has access to the SOMS knowledgebase. This knowledgebase contains not only the complete system documentation set, but also captures routine support items to increase the probability of resolution within Level 1 and Level 2 support.

If the Level 2 help desk attendant is unable to resolve the issue, the problem is referred to the Level 3 help desk personnel who deal with problems beyond the expertise of the Level 2 analysts and have the in-depth knowledge of SOMS to resolve virtually any problem that arises. Level 3 analysts include database administrators and application software maintenance and software support maintenance experts.

Help Desk Roles and Responsibilities

The following table, Help Desk Levels and Responsibilities, Table 6.9-2, depicts the responsibilities of each level of support.



Table 6.9-2, Help Desk Levels and Responsibilities

Help Desk Level

Responsibilities

Level 1— Team EDS

Answer calls

Determine scope of problem

Log tickets

Maintain history database

Manage issues that can be resolved quickly

Handles Level 1 defined problems

Level 2—Team EDS Resolve escalated problems

Deal with SOMS functional issues

Bring in expertise (Level 3) as necessary

Level 3—Team EDS Work on higher-level problems

Have in-depth knowledge of SOMS

The SOMS help desk personnel are available to support users 24 hours a day, seven days a week and shall adhere to the established SLA for response. For detailed descriptions of our SLA, see the Severity Codes section of this document.

Help Desk Reports

Reliable help desk support is a critical component in implementing a solution such as SOMS. For users to fully accept the new system, they must know they have a method of resolving their questions, concerns, and problems related to the system. Team EDS has a proven track record in implementing responsive help desk systems that alleviate many of the uncertainties and reservations that come about with a change of this magnitude. Our objective is to make sure that those who call into the help desk know they have an ally and are confident they receive the appropriate response to their issues.

The reporting capability within CA Unicenter demonstrates system robustness via service request counts and item response time. Additionally, the Service Desk database provides metrics to Team EDS regarding request volume and mean time to resolution metrics to facilitate adequate staffing. Team EDS leverages the reporting capabilities of CA Unicenter, which allow for the generation of a series of management reports on help desk activities. These reports cover many categories, such as the number of open, closed, and pending cases; call volume for a given period; and average time for call resolution. Regularly, weekly, or monthly depending on the type of information, Team EDS provides CDCR reports showing statistics about the issues received and how they were resolved.



Severity Codes

Problem Report Severity Level

Problems reported to the help desk are assigned a severity code by the Level 1 help desk attendant who originally accepts the call. This severity code helps the support staff to prioritize the PRs coming into the help desk. The severity code also helps verify that the user receives the expected level of support.

Although personnel use the criteria in the following table, Problem Report Severity Level Criteria, Table 6.9-3, to assign priority codes, severity levels can be overridden in special situations where more expedient service is warranted.

Table 6.9-3, Problem Report Severity Level Criteria

Severity Code Definition

Severity 1 (Critical) The system is inoperable and the inability to use the system has a critical impact on program operations. Severity 1 problems apply to production environments.

Severity 2 (Severe) The system is usable, but an essential component of the system is malfunctioning and substantially impacts program operations. Severity 2 problems apply to production environments.

Severity 3 (Moderate)

The system is usable but not functioning in accordance with specifications and the user documentation for the applicable release of software. The error condition has no substantial impact on program operations.

Severity 4 The system is usable and functioning in accordance with specifications and the user documentation for the applicable release of software. The error condition has no substantial impact on program operations.

Problem Report Acknowledgement

We acknowledge that a PR has been received, categorized, and logged according to, Table 6.9-4, PR Acknowledgement Codes.

Table 6.9-4, PR Acknowledgement Codes


Severity 1 (Critical)

Severity 1 problems will be acknowledged within 15 minutes on a weekly average, but not exceeding 30 minutes in any one instance.

Severity 2 (Severe)

Severity 2 problems will be acknowledged within an hour on a weekly average, but not exceeding two hours in any one instance.





Severity 3 problems will be acknowledged within two hours on a weekly average, but not exceeding three hours in any one instance.

Severity 4 Severity 4 problems will be acknowledged within 10 hours on a weekly average, but not exceeding 16 hours in any one instance.

Problem Report Resolution

The resolution to a problem can come in the form of a tested and implemented software fix, a “work-around” that provides regular system features and program operations, or a solution or answer to an issue.

We provide PR resolutions according to the following table, Problem Report Resolution Time, Table 6.9-5, in which resolution time is connected to the problem’s severity.

Table 6.9-5, Problem Report Resolution Time


Severity 1 (Critical)

We will work on the problem continuously to resolve it within 24 hours of acknowledgment.

Severity 2 (Severe)

We will resolve the problem within five business days of acknowledgment.


We will provide resolution within 20 business days of notification.

Severity 4 We will provide resolution within 45 business days of notification

Notification and Escalation

We provide a help desk plan to define processes for notifying help desk support staff and management of critical problems and for escalating problems when service-level time frames are expiring. At a minimum, we immediately notify the State Contract Manager and the CDCR Chief Technical Officer of Severity 1 and Severity 2 PRs.

Several events could require that special action be taken to notify the appropriate staff or inform other project team members of an issue requiring immediate action, including the following:

A Severity 1 problem

A user unhappy with the level of support provided

A service need discovered during the review of help desk status reports



When events such as these occur, escalation procedures are initiated by the help desk attendant or help desk manager. These procedures include many possible activities, such as paging a technician or manager and transferring the problem to a technician with more advanced skills. Specifics of the escalation process will be defined in the Help Desk Plan.

The detailed Help Desk Plan will include a help desk staffing plan to enable responsive problem resolution through controlled metrics, provide a consistent level of support for the users, and provide management oversight of help desk performance.

Maintenance

Applications Support

Team EDS understands the criticality of maintaining SOMS application software stability. Our approach to development, modifications, enhancements, and testing minimizes application defects and address problems quickly to maintain the integrity of the SOMS application and its documentation.

Software deficiencies, defects, and performance issues reported by CDCR or identified by Team EDS analyzed, prioritized, corrected, and tested. We migrate changes to the SOMS application software through a software change management tool that control access to SOMS modules and keeps an audit trail of access and changes. We document reported problems and actions taken to correct problems and track them through the problem resolution system. When corrections are made and testing is complete, the changes are documented and deployed to production or distributed to CDCR after the system has been transitioned. Complete user and technical documentation detailing changes made to the system shall be available to CDCR.

The application maintenance team continues to employ the system change control and project management methodologies established in the development phase of SOMS. They also are responsible for generating monthly reports that include the following items:

Summary of activities for the past month

New problems that were identified in the reporting month

Problem resolutions and specific corrective actions taken

Unresolved or pending problems and issues

The reports are distributed to State team members at regular monthly operations and maintenance management meetings.

The EDS SOMS software group comprises experts who work closely with CDCR and the other groups on the SOMS operations and maintenance team to maintain SOMS-specific system software and tools such as the offender management COTS and Oracle provided components. This group is responsible for analyzing and testing new versions of SOMS tools and software and making



recommendations for upgrades. If SOMS tools or software upgrades are required, the group distributes a report that includes detailed software specifications, justification for the upgrades, and implementation strategies and schedules that minimize downtime in CDCR.

The EDS SOMS software group delivers monthly reports detailing the following:

Specifications, justifications, implementation plans, and schedules for any necessary system software or tool upgrades

New problems reported in the past month that are related to SOMS-specific system software and tools supported by Team EDS

Problems that were resolved and details of the resolutions in the past month

Unresolved and pending problems

The SOMS help desk is the primary communications link among the operations and maintenance team and CDCR. The CDCR may contact the SOMS help desk with any operational issues, concerns, or problems related to SOMS applications software and system software supported by Team EDS. The SOMS help desk will be staffed with a multidisciplinary team, including application specialists. Reported operational issues or problems are logged through an automated issue tracking system.

If help desk staff are unable to resolve a reported problem, the problem is escalated and assigned to an appropriate group within the operations and maintenance team for resolution. When assigned, a team member promptly contacts the person(s) who reported the problem and work closely with them toward a satisfactory resolution to the problem. Reported problems and issues are assigned an identification number, which tracks the problem from initial entry through resolution.

During these meetings Team EDS provides CDCR with reports related to SOMS performance and problems. Tactical planning such as application software, SOMS tools and software, and change management issues also will be covered in these operations meetings.

The success of daily operations and the ongoing management of SOMS largely depends on maintaining strong relationships between CDCR and Team EDS. Promoting communication, employing a team approach between CDCR and Team EDS, and promoting a “win-win” environment helps encourage strong and successful relationships throughout the operational period of SOMS.

Team EDS supports the repair of defects (bug fixes, data errors) in the SOMS application software. As previously noted, we continue to use our structured SDLC methodology throughout software change analysis, design, development, and implementation. For more information on this methodology, see Section 6.4 – System Design and Development.

Our approach to defect or bug fixes to the application software and the services provided in this area include the following activities:



Investigate Causes of Software Defects – When software defects are identified by either CDCR or Team EDS, takes the necessary steps to determine the cause of the defect, which may require that we contact system software providers.

Analyze Potential Software Corrections – This process involves determining the appropriate software or configuration modifications to correct the defect.

Document Required Corrections – After a corrective action is identified, Team EDS prepares the appropriate documentation for the correction. This documentation may be in the form of a memo to CDCR with details regarding the defect or a more comprehensive document for more complex defects. In either case, Team EDS works with CDCR to determine the content and format of this documentation.

Design and Code Application Corrections – The design and implementation of corrections for a defect is carried out using our SDLC methodologies. We prepare and submit a technical design document to CDCR for approval before any work is started on a defect. After the technical design has been approved the correction will be coded.

Unit Test and System Test Application Corrections – After a correction has been coded it is tested using the approved SOMS testing procedures to verify that it functions according to the design specifications.

Track Software Migrations – We track and control the software modifications by the change management component of the SOMS project.

Migrate Software Corrections into Production – We migrate the software corrections into production following the SOMS change control procedures.

Team EDS establishes a robust application environment, which includes a proven approach to modifications and enhancements for the SOMS application and provides the methodology to meet system processing demands caused by offender population growth, legal mandates and policy changes. System modifications and enhancements are generally the result of new federal, State, or county/municipal government regulations or changes in policies and procedures.

The State may authorize new or revised business requirements, which may necessitate changes to the SOMS application. Additionally, modifications to SOMS may result from SOMS interface changes within other government systems. These changes and modifications are the responsibility of the Team EDS application maintenance team.

Before modifications or enhancements work begins, it important to determine what kind of change is required, within what timeframes it must be accomplished, and any special funding or authorization requirements.

The following are the three main types of changes made to SOMS:

New Development/Enhancement



Mandated Changes

System Enhancements

New Development/Enhancement

New development often occurs when the legislature enacts a new program or the State or CDCR change regulations or policy in a way that does not meet the capabilities supported by the existing system.

Mandated Changes

Mandated changes are typically the result of emergency State or county/municipal regulations or court orders that usually have a short timeframe for compliance and must be implemented on an emergency basis. The SOMS solution is specifically architected to facilitate the changes and enhancements required to the SOMS solution as business requirements change. This flexibility is achieved through:

The use of well defined and easily manipulated business rules

A loosely coupled application architecture and enterprisewide service-oriented architecture

Workflows implemented and modifiable to meet the CDCR requirements

Team EDS, experienced in many public sector environments, helps meet CDCR’s needs to handle changing requirements. When lead time for a change is short, Team EDS employs expedited procedures to complete the required system changes, while maintaining uncompromised system integrity. If CDCR is required to take action before system changes can be implemented, Team EDS assists in documenting temporary interim procedures or workarounds, which applies until the permanent solution is implemented. Team EDS supports SOMS-mandated changes.

One fact that should be noted related to the mandated changes is the flexibility to the SOMS application software. As the eOMIS application is rules based, many changes required by CDCR may be applied without the need to physically make coding changes to the application. To complete the required rules change, an authorized user accesses the rules base and enter the revised business rule. When approved, the new rule can be promoted directly into production. This capability dramatically reduces the time that is required to apply this type of change in policy.

System Enhancements

System enhancements are proposed system changes developed to improve the efficiency or productivity of operations and procedures. Examples of system enhancements include changes to collect or reformat data, modifications to improve existing system functions, and developing additional State-desired features that improve productivity. Features of the SOMS solution that support system enhancements include the following:



Modular eOMIS design that provides enhancements as developed. New features are available with each release.

Loosely coupled architecture that mitigates the impact of change; the scope is limited to the targeted system component.

Enhancements to the supporting COTS products (i.e. Oracle, EMC Documentum) are applied as new releases are made available and supported by the other solution components.

Team EDS assists CDCR in identifying and documenting efficiencies that improve SOMS functions. We also suggest measurements and metrics that assist the State in evaluating the cost-effectiveness of each proposed efficiency improvement when deciding whether to proceed. If special funding or authorization is needed, Team EDS assists CDCR by providing documentation needed from SOMS to secure State approval. EDS’ Office of Government Affairs specializes in tracking legislative and regulatory actions at the State and federal level and alert our team to applicable policy initiatives to work with CDCR to address them in a proactive manner.

CDCR involvement in the decision-making process for initial system design decisions and ongoing system changes supports successful implementation of a change. We take a technical leadership role in the proposed system change design and development process to make certain that the objectives of the proposed change are clear to Team EDS and CDCR. Through systems analysis services we can provide a product that meets the State’s needs.

Methodology

As presented in Section 6.4 – System Design and Development, our SLC 3 methodology was designed to facilitate system development and maintenance activities for the entire systems life cycle. This specifically includes planning, estimating, and scheduling of modifications and enhancements activities. It also helps us foresee and prevent potential problems. We have incorporated these methods into our approach for SOMS application software modifications and enhancements.

SLC 3 emphasizes active customer involvement, enabling Team EDS to deliver a well-designed system that meets customer specifications, satisfies requirements and expectations, and reduces enhancements and modifications activities. It is designed for flexibility and can be applied to a project regardless of its size or complexity.

Version Control

To promote successful implementation of enhancements or modifications to a complex system like SOMS, it is crucial to maintain strict version control across programs that are undergoing enhancements or modifications and those that have been migrated into the testing and production environments. As is often the case, mandated policy changes are date-specific, emphasizing the importance of careful and standardized methods for migrating releases between environments to meet properly timed deployment of system changes. Our approach to



migrating modified application software into the production environment is designed to preserve the integrity of SOMS and protect users from unnecessary work interruptions caused by defective releases.

Depending on the scope of the modifications and enhancements in progress and their associated priorities, Team EDS may be working on multiple changes with overlapping schedules. Our practiced approach uses the following five source code libraries and strict version control procedures to handle multiple changes:

Development Version – This version is what is under development, enhancement, or modification. When programming is complete, we unit test the program(s). Only then do we release the development version to the systems test environment before releasing the module for formal user acceptance testing.

Systems Test Version – This version is released from the development environment by Team EDS systems engineering (SE) staff when it is ready for system, regression, and performance testing. When system testing is complete, the tested version is promoted into the user acceptance environment.

Acceptance Test Version – This version is released from the systems test environment by Team EDS when it is ready for CDCR user acceptance testing. When acceptance testing is complete, the tested version is promoted into the production environment.

Training Version – This normally matches the production version. The exception would be when large system enhancements or modifications have been made and CDCR wants their trainers to be trained on the changes before they are migrated to the production environment. In this situation, we migrate changes from the user acceptance environment to the training environment instead of directly to production. After CDCR training staff has received the necessary training, the changes are migrated from the training environment to the production environment.

Production Version – This is the version of source code on the “current” SOMS.

The physical controls for these versions are enforced through our use of separate program module libraries and facilitated by CA Software Change Manager.

Promotion Procedures

Our promotion procedures contain an extensive use of checks and balances throughout the promotion process. No one person is authorized to promote new SOMS application programs through the different environments. Each environment will have separate staff with the responsibility for authorizing promotions to the next level. The applications team leader is responsible for authorizing the promotion of program modules from the development environment to the systems test environment. The test coordinator is responsible for promoting programs from the systems test environment to the user acceptance test environment.



This promotion process is strongly tied to the use of automated release management to schedule releases that minimize impact to the environment. This includes creating a specific bill of materials for each release that ties back to the change request.

To mitigate risk of the promotion through each SOMS environment to production, the SOMS environments will include a staging environment that implements an exact production configuration. This configuration includes system configuration at a hardware, software, and tools level. Other risk mitigation steps include the following:

Use of Oracle Change Management Pack to deploy database schema changes

Verification of changes against Gold Master databases to provide proper deployment

Performance of database builds offline for immediate deployment

Use of redundant server components to facilitate releases while the system is in a production mode

Use of WebLogic to deploy Web Archive (WAR) files without restart

Inclusion of CA Cohesion and Configuration Management Database (CMDB) to automatically capture and store system configuration changes

Promotion from the user acceptance test environment to either the training or the production environment requires prior approval from CDCR and Team EDS. Our test coordinator will have authorization to migrate modules into these two regions as well as promoting modules from training to production. The test coordinator works with CDCR to coordinate promotion efforts.

When authorized, automated promotion tools will freeze changes until the identified program modules have been copied correctly. The copy tool also performs a verification read to make certain that the promoted version is an exact copy of the approved version.

Technical Documentation

Team EDS places high value and commitment to technical, database, and functional documentation, which is maintained in documentation libraries. The quality of our documentation provides CDCR with readily accessible, accurate information regarding the technical aspects of SOMS. Additionally, this documentation set becomes a key supporting component when conducting the technical training and transition activities. These documents will be available on the Clarity project workbook.

One of our programming assignments is updating technical system documentation. The system engineer (SE) updates the design documentation, data model, and operations manuals as required. Other technical system documentation also may include source code, job code listings, hardware instructions, vendor manuals, and system documentation as required by the State.



Team EDS support SOMS’ needs by keeping application documentation current to accurately reflect the production system features. Vendor or manufacturer manuals will be provided for documentation of SOMS software.

Any changes resulting from updates to procedures, application changes, report changes, screen changes, or other revisions are documented and updated by our SOMS support staff. Documentation is reviewed regularly with CDCR to make sure that it is correct and current.

User Documentation

As the SE is performing the necessary coding changes, Team EDS’ training specialists make necessary updates to the user documentation and training materials, to include online help. Similar to how the technical documentation is maintained, user documentation is maintained in documentation libraries and shall be accessible to CDCR staff and external users accessing SOMS. This activity is tracked and managed through the change management process.

User documentation updates are performed with the required programming, customization or configuration changes, so that the work products required by the change request are ready for system testing and user acceptance testing simultaneously. This concurrent process makes sure that the entire modification or enhancement, consisting of the application, technical, and user documentation, is accurate and consistent. During this documentation process, Team EDS works closely with CDCR so that any specific wording most clearly communicates information to the line staff.

Software Tools

Team EDS understands the requirement that the software tools used by SOMS must be kept no more than one major release back from the most current release. Before updating these software tools, we work with State staff to verify that this maintenance does not interfere with or otherwise jeopardize other State systems or system software upgrade policies. One high-impact factor is the compatibility analysis of new versions of software components that compose the SOMS enterprise system. We include the results of the compatibility analysis in the SOMS Technical Roadmap so that software components are updated in a manner that mitigates risk. For example, SOMS cannot upgrade to a new version of Oracle unless eOMIS is ready to support the new Oracle version. Likewise, the SOMS requirements tracking tool cannot be upgraded if the testing tool does not support the upgraded version.

Starting during the Foundation Modernization phase and continuing through the life of the project, Team EDS develops and maintain a Technical Roadmap, which identifies the present state of the infrastructure and supporting software and the identified future changes and upcoming software releases to the environments. The architecture team reviews the state of vendor software releases to periodically upgrade the Technical Roadmap so that SOMS complies with CDCR’s version requirements.



After Team EDS and CDCR have agreed to the schedule for these software tool upgrades, we proceed with the software release changes at a time of the week that is most convenient for CDCR staff, and in full compliance with established change management processes. These processes are reviewed and governed through the Change Control Board (CCB).

Maintenance Period

Team EDS understands that SOMS maintenance begins during the development phase and continues for six months following SOMS implementation and further understands that post-implementation support does not include the maintenance provided during the development phase. We provide maintenance for these services including functions associated with securing application software stability, including system fixes required to correct any defect in the software or documentation, or in the incorporation of system modifications.

Team EDS manages the software configurations to maintain and migrate SOMS software to the testing, training, and production environments. As previously discussed, we employ our SDLC methodology to provide comprehensive unit, integration, system, regression, and performance testing before the implementation of system modifications and enhancements.

Transition Plan

The smooth transition from one entity to another is the goal of any turnover plan. The final measure of project success is the ability of CDCR to successfully run and manage SOMS after Team EDS has implemented the solution. Team EDS possesses vast knowledge and expertise in transitioning systems to and from our clients. From our experience, we have developed methods and practices that support the proper planning, execution, and oversight of these plans.

During the first month of maintenance, we will produce a turnover plan for SOMS. While the turnover plan will be finalized in the knowledge transfer and transition plan, our disciplined approach to project management makes sure the planning and preparation of the documentation necessary for a successful turnover occurs throughout the project’s life cycle.

Plans—such as configuration management, change control, knowledge transfer, quality assurance, and testing—verifies that roles and responsibilities are developed and tools and processes are put in place. These plans make sure that the proper oversight and reporting are established to validate that collateral, documentation, and training needed to successfully transfer SOMS to CDCR are identified, created, maintained, and tracked. We employ the following three-phase approach to the transition:

Identification and Collection – This phase creates the turnover plan; sets up the schedule; and identifies key processes, personnel, training requirements and assets required to successfully transfer the system. It includes a gap analysis and the identification of risks associated with the turnover. We also produce an application turnover checklist as part of this phase.



Collateral Generation – This phase gathers or creates the documentation and training required for the transition. In this phase we also verify inventories of software, hardware, and current and future customer service representatives. Other key collateral includes the operational documentation and process descriptions that have been used to operate SOMS since the initial releases and implementations of both the Electronic Record Management System (ERMS) and SOMS applications sets.

Information Transfer – This phase performs the transfer of information from Team EDS to CDCR. This transfer includes the following items:

System Architecture documents

System Design Artifacts

Inventory of the hardware and software used to support SOMS

Current copy of the runtime components of the software used to support SOMS

Offender management COTS application and supporting software components documentation

Current copy of the training materials and schedules

Execution of agreed-upon training as specified in Section 6.3 Knowledge Transfer and Training.

“On the Job Experience” – side by side joint team support of the SOMS solution

Current copy of support procedures, examples of which include the following:

Change management procedures

Implementation procedures

Help desk procedures

Systems Management procedures

Database Management procedures

Operations process and procedures

Application Support procedures Status and documentation of outstanding problems and current

recommendations for system improvements that have been identified

Status of known help desk tickets

Projected staffing plan to support SOMS

Team EDS anticipates a six month transition period for the transition of production support and operations from Team EDS to CDCR. During this transition period, a structured approach, defined by the PM 2® methodologies, are executed to complete the transfer of systems operational responsibility.



As the transition from Team EDS to CDCR progresses, the guiding principle is to involve the CDCR team early and often to provide not just “book learning” of the SOMS solution, but to provide actual support experience prior to system turnover. Team EDS anticipates working side by side with CDCR technical staff to provide hands on experiences through the transition period. By building upon the CDCR’s existing knowledge of deployed technologies within the SOMS solution, we will provide and develop the SOMS-specific knowledge and skills required to maintain and operate SOMS into the future.

Team EDS provides a proven solution that combines best practices for staff to gain technical skills and knowledge and a consistent, over time method for learning while managing for success through regular monitoring and progress measurement. This comprehensive approach provides them with deep knowledge, skills, and understanding of the SOMS technical environment.

State technical and operations staff are trained by Team EDS technical staff. Team EDS are knowledgeable in the specific tools and methodologies for which the State staff are being trained. The EDS staff will present on-the-job and knowledge transfer activities, including the following as shown in Table 6.9-6, Training Methods, as they further their understanding of the new SOMS and the underlying technology.

Table 6.9-6, Training Methods

Method Description

Recommended Vendor Training

Vendor supplied training curriculum established for each technical discipline as part of the training and knowledge transfer plan

Focused on establishing a basic understanding and knowledge of specific product features, capabilities, usage, and tools

Established based on each individual’s target technical role, past experience, and existing familiarity with the discipline-related tools and techniques

Completed during the early phases of the project in preparation for SOMS-specific training and hands-on-training

Formal Training May occur at any time as appropriate, but is typically scheduled to occur after the completion of recommended training

Delivered by Team EDS’ technical staff in a formal classroom environment with reusable training materials and aids

Differs from recommended training in that it is specific to the SOMS solution or some other aspect of the SOMS technical environment

May be used, for example, to train the CDCR database administrator on the system entity relationships and data structures in SOMS

Informal

“Brown-Bag” Training

Is delivered in the form of short, topic-oriented sessions and chalk talks

Usually target a specific topic area, such as a particular feature of a data modeling tool, and are tailored to the needs and the experience level of the audience



Method Description

Often used to reinforce specific areas of learning

May be scheduled in advance or ad hoc to meet the needs of the student

Self-paced Learning Accomplished by individual CDCR technical staff in assigned discipline areas by reading product documentation, reviewing project deliverables, and completing Web or computer-based training materials.

Areas of self-paced learning and corresponding learning materials are identified as part of the technical training and knowledge transfer plan

May be augmented at any time based on individual experience, familiarity with the tools, and rate at which new information is absorbed

On-the-Job (OTJ) Training

Starts as soon as an understanding of the product fundamentals is demonstrated

The most powerful tool for training technical staff as it puts individuals to work on real-life tasks and provides the opportunity for immediate feedback

Accomplished by working side-by-side with Team EDS’ technical staff and through active hands-on participation in areas of the project, such as requirements validation, design, development, testing, system administration, and operations

Technical Training Curricula

We understand that the SOMS implementation will be a time of great transition and change for technical and operations staff as they move to a new system and regain confidence and effectiveness. Understanding the impacts of stress, discomfort, and even risk to CDCR overall, a successful strategy for technical training is highly important for project success.

To facilitate this transition, State technical staff will receive training in:

System architecture

SOMS hardware and software including support tools, database models, functionality, project standards, and processes

Adhering to and validating adherence to CDCR and DTS security and training standards

A key benefit of Team EDS’ proposed technical solution is our use of best practices, hardware, and software that tightly align and comply with the State’s standards. This not only reduces risk to CDCR, it also reduces risk for State staff designated to perform roles on the new systems and promotes skill enhancement and opportunity for advancement. This, combined with our integral approach for preparing these staff for their new responsibilities, offers a road to success and helps offset the challenges of such transition.



Technical staff training is skill-based, built on measurable performance objectives based on the needs of the individual. Training for technical and operations staff is individualized and self-paced, allowing the staff member to practice the desired skill until the performance objective is met, while being guided by Team EDS staff according to the action plan.

SOMS system training is a vital part of knowledge transfer and exchange from Team EDS to the CDCR Team. Team EDS’s experience in prior successful technical training programs for State customers has helped identify the key system operations and maintenance training needs in terms of skills.

As shown below in Table 6.9-7, Estimated Technical Training, offers our current view of training requirements for CDCR and DTS staff. The table provides a list of general technical disciplines such as Architects, System Administrators, Database Administrators, and others — for each technical discipline there is a broad topic area that describes the training. For each discipline we:

Estimate the numbers of resources to be trained

Suggest a level of experience that we would typically expect for personnel taking on the roles

Outline the training required

Indicate the planned knowledge transfer methods

Indicate how much training is required and when it should be provided



Table 6.9-7, Estimated Technical Training

Technical Discipline

Topic Areas Estimated Number of Resources to be Trained

Prerequisite Knowledge Expected

Training Required

Knowledge Transfer Method

(vendor class, formal class by project staff, OTJ, or just reading)

Amount Needed (how long a class or OTJ and when)

Architects Maintenance of SOMS architecture and alignment with CDCR business needs

Maintenance of technology road map

Coordination of major technical change impacts

Technical governance and reviews

Vendor technical relationships

2 Experienced System/Technical Architects

Service-oriented architecture fundamentals

Overviews of all key technologies within SOMS solution

SOMS architecture and roadmap

Training tools

Brown-bag training

OTJ

Close collaboration with Team EDS throughout SOMS program

Formal hand-over during transition






Training Required




Application Design and Development Staff

Requirements validation and design tools and techniques used to design our SOMS solution customizations

System, interface, and report designs, including underlying application and technical architectures

Application development tools

Configuration management (version control) and system build procedures

15 Java and IDE (mainly)

.Net and IDE (some)

Application design and development methods

Unit testing

SOMS SDLC

eOMIS

SOMS Oracle technology stack (multiple products)

Documentum and related products

CA Software Change Manager and CA CMDB

Vendor classes

Formal class by project staff

Self-paced learning

Brown-bag training

OTJ

SDLC overview training during project Start-Up phase

IPAs early in Year 3

Training commencing Year 3 Q3 through to transition






Training Required




System Administrators

Set-up, configuration, and administration of each computing environment developed by Team EDS

Tools and procedures necessary for ongoing system configuration, capacity, and security management

5 Experienced System Administrators

Sun Solaris

Microsoft Server

SOMS processes and procedures

Oracle WebLogic administration

Oracle Access and Identity Management Suite administration

Oracle WebCenter administration

eOMIS administration

Oracle SOA Suite administration

EMC Documentum administration

Oracle Audit Vault administration

EMC Storage administration

HP Mercury administration

CA Service

Vendor class


Self-paced learning

Brown-bag training

OTJ








Training Required




Database Administrators

Database design and schema (logical and physical) associated with each operational database, installed by Team EDS, which comprise our SOMS solution

Tools and procedures necessary for ongoing database performance, capacity, and security management

2 Experienced DBAs

Oracle 11g

Oracle RAC

Data Guard

Oracle Enterprise Manager

Microsoft SQL Server

SOMS process and procedures

SOMS database designs and schemas

OTJ IPAs early in Year 3







Training Required




Network Administrators

The design and configuration of Team EDS installed networks and network components

Tools and procedures necessary for ongoing network configuration, performance, capacity, and security administration

1 Experienced Network Administrator


SOMS network design

OTJ Close collaboration with Team EDS throughout SOMS program

Formal handover during transition






Training Required




Configuration Management

Design and maintenance of configuration management system

Maintenance of configuration management database (CMDB)

Management of configuration management process

1 Experienced Configuration Manager


CA CMDB

Vendor class

Self-paced learning

Brown-bag training

OTJ



Test staff System design and usage

System and user acceptance test methodologies, test procedures, and test scripts

Problem reporting procedures

5 Experienced Testers

SOMS processes and procedures

HP Mercury Suite

Vendor class


Self-paced learning

Brown-bag training

OTJ








Training Required




Operations staff

System operating procedures, including exception, and detection and handling procedures

Backup and recovery, and disaster recovery procedures

3 Experienced operational support staff


Job Scheduler

Backup management tools

EMC management tools

CA Clarity


Brown-bag training

OTJ



Help Desk staff

Help desk procedures

Business help desk

System help desk

1 Manager

10 Analysts

Experienced service/help desk staff


CA Service Desk Manager and related tools


Brown-bag training

OTJ



As we do in end-user training, we collaboratively develop and implement methods to assess and evaluate the training project and to make adjustments as necessary, so that participants receive the most effective training for SOMS. We use tools to support an overall evaluation of trainee satisfaction and trainees’ performance against training objectives and expected competencies.

The Knowledge Transfer and Training Plan will provide the overall roadmap for how we collaboratively perform and manage technical training for success. This approach integrates into the EDS PM 2® and provides for the proper oversight and reporting to verify a successful turnover.



6.9.A Production Support & Transition Plan Requirements

VI.D.12.a. Production Support & Transition Plan Requirements

Req.


M-90 The Contractor shall incorporate the production support and transition approach into a comprehensive Production Support and Transition Plan (Software Transition Plan) complying with IEEE 12207.2, section 5.3.3 - system architectural design, that will describe how the Contractor intends to support the System and transition that support over to the responsible State entities. Additionally, the Production Support and Transition Plan must address how the Contractor will provide support of the State’s Post Implementation Evaluation Report (PIER) process in accordance with the Department of Finance (DOF) Statewide Information Management Manual (SIMM) including an Identification of Lessons Learned.

The Bidder must submit a sample Production Support and Transition plan with their proposal response as identified in Section VIII – Proposal and Bid Format.

Vol 1 – Appendices,

Appendix T


EDS has provided a sample Production Support and Transition Plan in Appendix T. The EDS Production Support and Transition Plan will follow EDS best practices learned from our 45 years providing information technology services that complies with Institute of Electrical and Electronics Engineers (IEEE) standards and fully supports the State’s Post Implementation Evaluation Report (PIER) process. This Plan will be developed and submitted by Team EDS to CDCR for review and approval prior to executing production support and the transition activities.



6.9.B General Production Support Requirements

VI.D.12.b. General Production Support Requirements

Req.


M-91 The Contractor shall, at a minimum, provide routine system upgrades and fixes to Contractor software at no additional cost. In addition, the Contractor shall provide at no additional charge, routine system upgrades and fixes to COTS software and field/technical services bulletins periodically as they become available within 24 hours after they receive them from COTS licensors, subcontractors, manufacturers, and other third parties.

M-89


As described within the Application Support section in Requirement M-89 above, Team EDS provides the necessary application software changes to CDCR. These changes follow processes and procedures jointly established between CDCR and Team EDS while maintaining system stability, availability, and to meet the business process needs of CDCR.

These system upgrades and fixes follow the same approach and methodologies used for the design, development, testing, and implementation of the SOMS solution. Maintaining this consistency from the development activities to production support provides CDCR with consistent support processes throughout the life of SOMS production support.

M-92 The Contractor shall provide CDCR with a list of personnel, contact information, and their area of expertise of who shall be performing system production support.

N/A


EDS provides a full list of personnel, their qualifications and contact information for staff performing system production support. EDS understands that the success of the SOMS project is highly dependent upon managing the staff providing services to CDCR. EDS brings a comprehensive approach to staffing and resource management. Our approach covers staff recruitment, team development, staff development, retention, evaluation, staff assignment and allocation, and controlling resources used by the project. There is clear evidence that high staff turnover can put a project at risk. Our successful staff management practices are measured by our low turnover rates.



Staff Recruitment

Team EDS searches for potential candidates whose skills meet or exceed the required skill levels for the project. When staffing requirements are identified during project planning, the EDS project director carefully matches candidates to specific positions. Team EDS fully anticipates staffing from the large, permanent staff base already located in the Sacramento area. If we cannot find staff within EDS, we conduct a nationwide search for the best candidates and bring them into EDS. Project staff members interview prospective candidates and compile a list of qualified individuals. Specific to Production Support, the EDS staff includes the following:

Operations Manager

Infrastructure Technical Lead

Applications Technical Lead

System and Network Administrators

Database Administrators

System and Monitoring Staff

Batch Schedule and Monitoring Staff

Application development staff for application maintenance and deficiency correction

Application development staff for enhancements

Team Development

Team development includes enhancing the ability of the individuals as well as enhancing the ability of the team. Providing and retaining a skilled, highly motivated team involves the following key success factors:

Training new staff on the application and tools, with the understanding that it is important for maintenance team members to understand the entire application they support

Cross-training so that individuals can expand their areas of expertise

Providing career development planning for our team

Acknowledging individual and staff achievements

Providing new challenges and additional responsibilities

Staff Development

Staff development is an important part of building and maintaining effective teams for several reasons, including the following:



Better orientation into the project for new staff members

Improved skills needed to support the project

Training on new releases of a product

Training that gives individuals upward mobility on the project team

Prioritizing staff development not only improves staff performance but also reduces attrition by providing an environment that allows for professional growth on the project.

Retention

Professionals remain where they are challenged, and they perform to high standards when they experience high levels of job satisfaction. EDS focuses on providing challenging work assignments, awards, and training opportunities to maintain high staffing standards.

We understand the effect that staff turnover has on any project, and we actively address project staff retention. Key elements of employee retention include instilling among the staff a long-term commitment to the project, updating and maintaining employees’ skills, and motivating the staff to sustain a high level of job performance. EDS has been able to retain staff in a challenging IT environment by providing extensive opportunities for professional development and responsive and effective management.

Attrition can occur if staff members believe they are locked into their positions and do not have opportunities to expand their horizons. To reduce this factor, we cross-train and promote from within whenever possible. Cross-training also allows us to have backups for key positions, and it provides the staff with a broader base understanding of the project and application.

M-93 The Contractor shall repair any corrupted data that is associated with a system problem.

M-92

M-89


Within the staff described to meet requirement M-92, the resources necessary to repair corrupted data associated with a SOMS system problem will be provided. Correction of corrupted data and the associated system problem will be completed in accordance to established incident response and problem management procedures described in our response to Requirement M-89 above.

M-94 With concurrence from CDCR, the routine planned maintenance activities shall be scheduled without disrupting the 24x7 operational hours. Contractor shall provide CDCR with a copy of the schedule at least 30 days in advance of the scheduled maintenance date for approval.

N/A




Team EDS understands the importance of maintaining system availability to SOMS users during normal operations. Team EDS works with CDCR to establish routine planned maintenance procedures that do not disrupt the 24x7 operational hours. Changes follow established procedures to include notification, scheduling, and reporting of system changes. These procedures include well defined notification and scheduling processes, from the initial scheduling of changes through to application of the change and reporting.

The SOMS solution has been designed to include redundant servers, and when supported by the providing vendors, include hot patching capability. This feature contributes to the ability to perform routine planned maintenance activities without disrupting the 24x7 operational schedules.

M-95 The testing tools and test configurations shall be provided to the State as the systems are transitioned into support.

M-89


Transition of system support from Team EDS to CDCR goes beyond knowledge transfer and training. Team EDS works with CDCR to effectively transition all components of the SOMS system, to include the testing tools and test configurations as support is transitioned from Team EDS to CDCR. These activities will be fully incorporated into the comprehensive transition and technical training plans. This transition is described in greater detail in the section Transition Plan in our response to Requirement M-89 above.

M-96 The Contractor shall provide instructions and training for CDCR support staff that may need to access and support the system remotely.

Section 4.2.G


As detailed in Section 4.2.G, Training, Team EDS provides systems documentation, training aids, and the necessary training required by CDCR staff to both access and support the SOMS system. This includes staff in all CDCR locations and any remote support staff.

M-97 The Contractor shall develop an automated process for purging production system files when necessary.

N/A


Team EDS understands that establishing system housekeeping procedures is critical to the ongoing stable operation of the SOMS system. During design and implementation of the SOMS systems, we establish the necessary processes to maintain a stable SOMS system, which includes the maintenance and purging of



production system files. Team EDS works jointly with CDCR to establish appropriate retention periods for production system files and data. These activities will be controlled through CA dSeries Workload Automation.

By leveraging standard processes and scripts available through our corporate Global Solutions Management Systems (GSMS) and Data Engineering repositories, Team EDS then fills any gaps between CDCR operational requirements and the standard features of the COTS products supporting the SOMS solution.

M-98 The Contractor shall establish an automated maintenance routine that shall backup the user IDs and password data. The Contractor shall also, as a regular maintenance routine, delete or move expired IDs and related data.

Section 6.7


As described in Section 6.7, Security, Team EDS establishes the necessary maintenance routines to manage user and identity management including IDs and passwords. These maintenance routines include deleting and/or moving expired IDs and related data as defined by user ID security standards. Additionally, the automated user provisioning and de-provisioning provides and effective mechanism to avoid “orphaned” system accounts.

Building upon Oracle Identity Manager, CDCR will receive an identity management solution that automates repeatable user administration tasks. Oracle Identity Manager enables policy-based automated provisioning of resources with fine-grain entitlements. Administrators may specify access levels for each resource to be provisioned, granting each user only the exact level of access required to perform their job, no more and no less. When a user leaves the organization or her access is no longer required or valid due to a job change, Oracle Identity Manager revokes access on demand or automatically, as dictated by role or attribute-based access policies. This makes certain that a user’s access is promptly terminated across all no-longer-required resources to minimize security risks, as well as to prevent paying for access to costly resources, such as data services. This is delivered from a centrally managed database repository, backed up with the same capabilities and processes as the other components of the SOMS solution.



M-99 Upon completion of any maintenance call, the Contractor shall furnish a maintenance activity report to CDCR within 24 hours, which shall include, at minimum, the following:

Date and time notified.

Date and time of arrival.

If hardware, type and serial number(s) of machine(s).

If software, the module or component name of the affected software code.

Time spent for repair.

List of parts replaced and/or actions taken.

Description of malfunction or defect.

M-89


As described in detail in our response for requirement M-89 above, Team EDS provides reports for maintenance activities within 24 hours of completion. Team EDS works with CDCR to establish the format and content required to meet the business needs of CDCR. This activity is supported through the Impact Analysis CA Spectrum and Configuration Management Database (CMDB).

M-100 The Contractor must produce a System Operation Manual, which includes System Administration procedures.

M-89


Team EDS understands that complete and accurate documentation of the SOMS system is required to operate and maintain a stable SOMS system. This documentation shall include a complete and comprehensive System Operation Manual, to include system administration procedures. This documentation is described in greater detail in the section Production and Ongoing Maintenance of Operations Guide in our response to requirement M-89 above.

M-101 The Contractor must produce and execute a Help Desk Plan. The State will provide information (including processes, procedures, description of physical infrastructure, and access to a limited number of help desk staff) to the Contractor to facilitate development of the Help Desk Plan.

M-89


As described in the section Help Desk in our response to requirement M-89 above, Team EDS provides a 24x7 help desk to support the SOMS system. The SOMS help desk shall be staffed and operated to an established Help Desk Plan to be developed during the initial phase of the project.



M-102 The Contractor must use a Help Desk tracking tool that employs access control mechanisms.

N/A


Team EDS proposes the use of CA Service Desk to provide help desk tracking capabilities during the life of the SOMS project. This tool fully supports access control mechanisms for all authorized users.

6.9.C SOMS Defect Resolution & Support Requirements

VI.D.12.c. SOMS Defect Resolution & Support Requirements

Table VI-2: Defect Severity Level Definitions

Severity

LevelDefinition

One There is a complete or severe loss of service in at least one mission critical area, the CDCR operations cannot reasonably continue, or can continue only in a restricted fashion, and service delivery to customers is disrupted.

Two There is a complete or severe loss of service in at least one area considered non-mission critical, the CDCR operations cannot reasonably continue, or can continue only in a restricted fashion, and service delivery to customers is disrupted.

Three There is a minor loss of service. The impact is an inconvenience and mission critical areas are not significantly impaired. The CDCR operations continue with minimal disruption. A workaround, acceptable to CDCR, may be employed temporarily to restore service and business operations.

Four There is a deviation from the standard of performance that causes no loss of service. This may be a minor error, incorrect behavior, or a documentation error that does not impede the operation of a system or effect business operations.



M-103 During the maintenance period, the maximum time to restore the functionality of applications and resolve incidents shall be within the timeframes listed below, based on the Table VI-2: Defect Severity Level Definitions.

Severity Level One incidents shall not exceed one (1) clock hours between the opening of an incident and final closure, unless a time extension is approved by CDCR.

Severity Level Two incidents shall not exceed six (6) clock hours between the opening of an incident and final closure; unless a time extension is approved by CDCR.

Severity Level Three incidents shall not exceed 24 business hours between the opening of an incident and final closure; unless a time extension is approved by CDCR.

Severity Level Four incidents shall not exceed 40 business hours between the opening of an incident and final closure, unless an extension of time is approved by CDCR.

N/A


EDS utilizes the CA ServiceDesk Service Plus to log and monitor system incidents. EDS works collaboratively with the CDCR and DTS to develop effective change control processes and also facilitate agile response to incidents. A variety of automated tracking, reporting and notification mechanisms to facilitate resolution of system incidents as defined below:

Severity Level One incidents shall not exceed one (1) clock hours between the opening of an incident and final closure, unless a time extension is approved by CDCR.

Severity Level Two incidents shall not exceed six (6) clock hours between the opening of an incident and final closure; unless a time extension is approved by CDCR.

Severity Level Three incidents shall not exceed 24 business hours between the opening of an incident and final closure; unless a time extension is approved by CDCR.

Severity Level Four incidents shall not exceed 40 business hours between the opening of an incident and final closure, unless an extension of time is approved by CDCR.

The combination of EDS’ robust enterprise service management practices along with the SOMS application and infrastructure architectures augments our ability to respond to system incidents within requirements. Proven practices such as the EDS On Call Notification (EON) and Response to Operational Problems (RtOPs) makes certain that the proper resources are brought to resolve incidents and that the proper personnel within the State and EDS are notified. Additionally, the SOMS architecture facilitates both system resiliency and incident remediation. For example, in the event a problem is detected with one of the SOMS



components, the system can fail over to an unaffected resource. Additionally, the SOA enterprise architecture and loosely coupled application architecture facilitates remediation of deficiencies. The EDS SOMS solution incorporates pervasive system monitoring capabilities to facilitate immediate detection of incidents. Additionally, the monitoring system incorporates predictive capabilities to resolve items before the system is affected.

M-104 The Contractor will work with CDCR technical and program staff to fix problems, optimize the system, and implement changes to the internal SOMS system, external SOMS web system, that supports SOMS functionality, Business Intelligence system supporting SOMS, and Web Content Management system. This will include making changes, testing changes, and providing documentation for changes and test results.

M-89


Team EDS follows the same approach and processes, as described in the response to requirement M-89, to fix problems, optimize the SOMS system, and implement changes to the SOMS system. Throughout these activities, Team EDS works with CDCR technical and program staff to develop, test and implement the required changes. These changes are fully documented to include the test results obtained during testing activities.

M-105 The Contractor will respond to critical service requests with a response time not to exceed 2 hours. A critical service request involves failure or degraded operation of a hardware or software component that prevents or seriously impedes CDCR in performing work, and there is no viable or sufficient workaround, redundancy, or backup capability that permits unimpeded operation.

M-89


Team EDS responds to critical service requests within a two hour response time, following the defined problem and incident management processes, as described in our response to Requirement M-89 above. As Team EDS finalized the problem and incident management processes, communication procedures with CDCR staff will be developed, to include notification and escalation procedures.

M-106 The Contractor will respond to non-critical service requests with a response time not to exceed 4 hours. A non-critical service request involves failure or degraded operation of a hardware or software component where there is a viable workaround, redundancy, or backup capability that permits continued satisfactory operation.

M-89




Team EDS follows the defined problem and incident management processes, as described in our response to Requirement M-89 above. Within these processes, Team EDS commits to responding to non-critical service requests within four hours.

6.9.D System Acceptance Requirements

VI.D.12.d. System Acceptance Requirements

Req.


M-107 There shall be one System Acceptance event for the full Offender Case Management System. This System Acceptance event will mark the end of successful Production and Support and the beginning of Maintenance and Operations

N/A


The criticality of SOMS requires that SOMS and related system components perform consistently at levels that meet the CDCR’s requirements and expectations. During the six month production support period, the formal validation confirms that SOMS is meeting the business needs of CDCR’s users and verifies that the system is fully operational after implementation. Our overall performance approach is to proactively take the actions required to meet the system processing demands caused by growth and Adult Institutions, Adult Parole, Juvenile Institutions and Parole policy changes. We are committed to efficiently resolving any performance issues, concerns, or problems related to SOMS operations. We will monitor SOMS performance closely and consistently through structured methodologies, procedures, and tools such as PM 2®.



During the six month production support period, we will use the performance and administrative metrics defined during the project to verify that functional requirements have been met, and that deficiencies identified throughout phases have been resolved. We will demonstrate that SOMS is adhering to performance requirements in the full production environment, to include data conversion, interfaces, tools, and utilities. These measurements focus on several SOMS components including software and hardware functions and performance, adequacy of training, efficiency of the procedures and workflow, adequacy of the help desk support, and effect of change on staff. Additionally, the measurements are used to capture lessons learned for continuous process improvement efforts.

Upon completion of this six month period, and successful execution of the transition plan to CDCR staff, a formal system acceptance is recorded based on pre-established metrics. At this point, the beginning of Maintenance and Operations by CDCR will begin.



M-108 Conditions for System Acceptance shall include: Infrastructure must be hosted by the State. Change configuration and release management must be

provided by the State. The State must be able to provide application maintenance,

development and testing immediately after acceptance of the SOMS system without the Contractor’s intervention.

All ownership of licenses and maintenance contracts must be transitioned from the Contractor to the State.

The State (DTS) will provide software vulnerability risk assessment for all third party software include in vendor’s solution.

The resolution of all documented Contractor-responsible deficiencies as stipulated through the approved defect and issue tracking process.

The SOMS System successfully performs in the production environment for a period of thirty (30) consecutive business days without any level 1 or level 2 deficiencies.

Knowledge transfer and training for end users has been provided.

The successful completion of all other work breakdown structure elements, tasks, and deliverables as specified in the Contractor project schedule as approved by the State.

N/A


Team EDS recognizes that for formal system acceptance to be complete, pre-established metrics must be met. Team EDS works with CDCR to define the system acceptance metrics, to include the following:

The SOMS infrastructure to include servers, storage, and network will be hosted and operated by the State. The transition to the State will be managed to the knowledge transfer and transition plan.

All supporting distributed computing environment components provided by the State shall be validated during the system and integration test.

The service (help) desk will be transitioned to and provided by the State in accordance to the knowledge transfer and transition plan.

All application support activities, including maintenance, new development, enhancements and testing.

Disaster recovery as defined by the State’s business continuity plan and supported by both the system architecture and the disaster recovery processes.

Transfer of software licensing from Team EDS to the State

Resolution of Team EDS responsible deficiencies and defects



Execution of the knowledge transfer and transition plan

Execution of all WBS elements in the master project schedule

M-109 Once all System Acceptance conditions have been met, the Contractor shall provide to the State for approval, a System Acceptance document that shall include a final Requirements Traceability Matrix identifying all SOMS system requirements allocated to current, in-production system components. Sign- off of this document by CDCR will constitute System Acceptance and trigger the beginning of Maintenance and Operations.

N/A


As Team EDS and CDCR complete all system acceptance activities, Team EDS will provide a system acceptance document that includes a final requirements traceability matrix that documents the SOMS system requirements contained in the production system. This requirement traceability matrix will be provided using the Borland CaliberRM® tool. Team EDS uses CaliberRM® as the central requirements management tool from project inception to system acceptance signoff. The graphic below, Figure 6.9-9, Borland CaliberRM®, provides a view of the SOMS requirements traceability:

Figure 6.9-9, Borland CaliberRM®



Borland CaliberRM® provides a powerful tool to trace individual requirements or reports system wide.

6.9.E Warranty

VI.D.12.e. Warranty

Req.

Num.Requirement

Response / Reference

M-109b The Contractor must include a system warranty of six (6) months beginning in conjunction with the Six (6) month post implementation maintenance and support period. The Contractor must describe, in response to this paragraph, the provisions of their warranty(s) including responsibilities for invocation, response, equipment and software failure, etc.

M-89


Team EDS’ project plan includes six (6) months of post implementation maintenance and support, commencing upon receipt of CDCR’s final acceptance of SOMS. During this six (6) month warranty period, Team EDS provides the same level of production support as described in response to management requirement M-89 above, with the distinction that CDCR’s project team directs all activities with EDS’ team taking a consulting and supporting role to CDCR/DTS staff. Thus, during the warranty period, Team EDS supports CDCR and DTS staff in operating and administering SOMS, to include identifying and resolving issues and defects, with the dual objectives of (a) uninterrupted and effective operation of SOMS, and (b) knowledge transfer to CDCR/DTS’ SOMS support team.

In providing post implementation maintenance and support, EDS partners with CDCR, accepting the level of responsibility and “ownership” of maintenance activities on a case by case basis as directed by CDCR’s project management team. During post implementation maintenance and support, CDCR staff invokes assistance and support from EDS’ team through at least two methods: (a) formal escalation of trouble tickets in the Service Desk management system to the EDS support team; or, (b) informal requests for assistance placed by designated CDCR staff. Team EDS logs all requests for assistance and support, enters the status of trouble tickets in the Service Desk system, provides weekly progress reports, and involves CDCR/DTS staff in determining and executing appropriate responses to service requests. In addition, Team EDS documents all support activities, including diagnostic actions, configuration and programming undertaken, testing and implementation steps, and the cause or source of each issue, such as hardware failure, software bug, or improper administrative support or enhancements.

Specific services and aspects of EDS’ post implementation maintenance and support include:

A single point of contact for SOMS related issues, for the CDCR support teams, regardless of solution component



Prompt investigation and response to all reported issues related to the SOMS solution

Identification and coordination of resolution of SOMS related issues with CDCR’s project team

Coordination of application break/fix, bug repair tasks between CDCR and all vendors

Provide patches and bug fixes to correct reported SOMS issues, to be applied to the SOMS environments by CDCR staff.

Support to CDCR in administering change management controls, maintaining software configuration and build information, as well as system and user documentation.

Provide severity level 4 problem support on a 24 x 7 basis; provide level 3 assistance during normal business hours

Maintain eOMIS COTS compatibility with companion products (e.g., Oracle, Java)

Provide product planning information and assistance on SOMS components (e.g. eOMIS, Documentum, EMC)

Provide a minimum of one annual eOMIS COTS enhancement release for licensed modules

Provide monthly activity reports that summarize maintenance and support activity

Per RFP Addendum 10, Section VI.E.1, upon request by CDCR, Team EDS continues post implementation maintenance and support for one year, starting at the end of the six month warranty period, and provides CDCR the option of extending the support for a second year.



6.9.F Maintenance and Operations

VI.D.12.f. Maintenance & Operations

Req.

Num.Requirement

Response / Reference

M-110 Upon System Acceptance, the SOMS System will be turned over to CDCR and DTS for Maintenance and Operations (M&O). To prepare CDCR and DTS for this transition, the Contractor, CDCR, and DTS will partner in order to develop and assimilate the CDCR/DTS M&O operations team with an CDCR/DTS M&O Plan. The Contractor shall develop a formal methodology to be used by CDCR and DTS to manage and operate the new system during CDCR/DTS M&O that is documented in the CDCR/DTS M&O Plan. The Contractor shall replace all other SOMS and Contractor project management plans with the CDCR/DTS M&O Plan at the conclusion of Production Support. The M&O Plan shall incorporate methodologies and practices which will assist CDCR and DTS in successfully managing the SOMS system’s M&O lifecycle and shall address the following areas:

Support Model.

Triage Procedures.

Tools.

Identification of Roles and Responsibilities of support personnel.

Release Management.

Upgrades.

Maintenance.

On-going Operations.

Customer Support.

Specific support procedures for production.

Deliverables.

Resource Requirements (staff loading).

Business Services Migration.

Capacity Management.

Technology Refresh.

System Security.

Backup and Recovery.

Disaster Recovery.

Defect/Issue management.

M-89


As identified in our response to requirement M-89, under Transition Plan, EDS uses an approach built upon the same PM 2® project management methodology used during the design, development, and implementation of SOMS to institute a Maintenance and Operations (M&O) Plan that enables CDCR and DTS to



successfully support the SOMS solution. A key outcome of the Transition Plan, described in response to requirement M-89 above, is to provide CDCR and DTS with comprehensive documentation of the procedures and activities for supporting and enhancing the system. Specifically, the M&O Plan describes procedures for using system tools, identifies roles and responsibilities among the support team, and prescribes system operating procedures. For example, the M&O Plan specifies each of the life cycle activities itemized in requirement M-110, including Help Desk operations, performance monitoring and tuning procedures, backup and recovery steps, security provisions, and system upgrade activities.


DOC

Technology

soms project workbook

soms section

project management process

maintenance of soms

team eds soms operations

soms components

operation of soms

soms projectparticipants