DOC

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

6.4 Design and Development

Subsection 6.4: Design and Development

This subsection must include a narrative describing the QBP’s approach to design and development and a sample system Design and Development Plan used by the QBP on another project as described in Section VI.D.7 – System Design, Development, and Customization.

6.4.A System Design, Development, and Customization

VI.D.7. System Design, Development, and Customization

Req.Num.

Requirement Response / Reference

M-33 CDCR utilizes a structured SDLC that is consistent with industry-standard best practices as well as State requirements for information technology projects. The Contractor must use a structured SDLC process, including an iterative software development methodology and incremental deployment of functionality to the production environment. This approach allows both the Contractor and CDCR more frequent feedback as to the progress of the Project with more opportunities to make corrections in interpretation and will result in a better understanding of the challenges of the Project at an earlier date.

Section 6.1

Bidder Response Detail:

Team EDS utilizes a structured systems development life cycle (SDLC) that:

Is mature, proven and subject to continual improvement in line with emerging design and development trends, and from feedback from the hundreds of projects that have and are using the SDLC.

Is based on industry best practices and consistent with California State requirements.

Enables iterative software development and incremental deployment of functionality through the life cycle into production.

Incorporates embedded provision of frequent feedback in order to identify errors, inconsistencies and issues at the earliest possible point thereby reducing costs of correction.

Provides a range of work types (that is, standard life-cycle patterns) which map exactly to SOMS needs, providing work types for COTS out-of-the-box development, custom development, integration and service-oriented architecture (SOA) development, portal development, business intelligence development, and ongoing maintenance.

EDS SOMS STATEMENT OF WORK EXHIBIT I -145


During the project startup stage Team EDS will work closely with CDCR to combine the right combination of work types to fit the specific characteristics of SOMS, providing a tailored and consistent approach that utilizes industry best practices throughout. This activity will be undertaken with input from EDS SDLC experts.

Development Methodology and Technical Practices

As one of the largest information technology (IT) service providers with a long track record, EDS has been able to develop, adopt, and hone a variety of software development methodologies that cover a wide range of development contexts. These EDS methodologies and practices were based on our extensive development experience and our knowledge of leading best practices; such as the Software Engineering Institute’s (SEI’s®) Capability Maturity Model Integration (CMMI®), the Project Management Institute (PMI) and the Information Technology Infrastructure Library (ITIL), and the Institute of Electrical and Electronics Engineers (EEE).

The State of California Department of Corrections and Rehabilitation desires to leverage IEEE Standards for Information Technology, Project Management, and User Documentation for the SOMS project. EDS fully understands the State’s objectives, and Team EDS uses the full suite of EDS best practices for the design, development, test, implementation, and operation of the SOMS system. Team EDS produces artifacts that are in compliance with IEEE 12207-1996 and IEEE 1058-1998 as required by the State. EDS produces these artifacts using the EDS methodologies and processes as described in the following paragraphs. As the following documentation shows, the methodologies and processes in the EDS best-practice library are highly detailed and encompass the same methodologies and processes as the IEEE standards. EDS has developed methodologies and processes using the lessons learned from the more than 40 years of IT outsourcing industry, which EDS helped established. These lessons learned are an accumulation of the knowledge acquired from the industries that EDS serves. These industries include energy, manufacturing, aerospace, healthcare, financial, insurance, food, retail, travel and transportation, communications, and government.

Our methodologies include systems engineering knowledge and best practices developed over forty years — these methodologies are employed throughout EDS to reduce time spent by individual teams and units to determine and document good practices. Input from business units throughout EDS, which often leads to enhancements, helps to improve methodologies for future releases. The methodologies are documented and deployed through the EDS Process Sourcerer®, an interactive electronic medium that encourages project team members to reference the methodologies often, thus enhancing project team knowledge.

Implemented under the umbrella of Global Applications Delivery (GAD) Quality Management System (QMS) described in Section 6.1, Project Management, our Systems Life Cycle Version 3 (SLC 3) software development methodology is the

EXHIBIT I -146 EDS SOMS STATEMENT OF WORK


foundation on which we build work types that are best suited for specific projects. The SLC 3 consists of six phases: Define, Analyze, Design, Produce, Optimize, and Implement as shown below in Figure 6.4-1, SLC 3 Framework for Developing Applications. The structure of SLC 3 is logical rather than sequential, and as such it provides the flexibility necessary for customization and continuous improvement that are required for the development of SOMS.

The SLC 3 maintains a focus on scope, control, quality, and efficiency through its integration with our well established Project Management Version 2 (PM 2), EDS’ project management methodology, detailed in Section 6.1, Project Management. This integration validates that as the software development processes are executed, there is a continuous focus on CDCR’s business requirements of cost control, risk mitigation, and well managed execution of projects. An overview of the SLC can be seen in Figure 6.4-1, SLC 3 Framework for Developing Applications.

Manage

Optimize Implement

Produce Define

AnalyzeDesign

Business Organization Components

Application Software/Data

Technical Environment

Technical Specifications

System Design Specifications

Implementation Approval

System

Business Need Definition

Solution Definition

Project Plan

Requirements Documentation

Logical System Specifications

START

Plan/ Test

Figure 6.4-1, SLC 3 Framework for Developing Applications

This figure illustrates how the SLC 3 software development processes are integrated with project management controls to verify that project business requirements are constantly evaluated and monitored, allowing for quick adjustments that reduce project risk.

The SLC 3 provides direct value to CDCR by maintaining a consistent balance between business and technical considerations. The SLC 3 benefits CDCR by achieving the following:

Aligning IT and business requirements



Strengthening communication between CDCR and EDS

Delivering best practices from EDS

Reducing risk through an iterative approach to verify and validateintermediate results

Directing the timely, incremental implementation of SOMS functions that meet CDCR’s expectations

Facilitating process customization to meet unique CDCR needs

Providing flexibility for integration into any CDCR systems life-cycle methodologies

SLC 3 is an extensible framework that can be generalized to a variety of work types that are each geared toward specific types of development. The flexibility of SLC 3 facilitates the selection of the most appropriate work types that best meet the specific project requirements.

The development practices of EDS' projects in the eligibility space have been cited, through the CalWIN project, as an example of best practice by the California State Office of Systems Integration (OSI).

M-34 The Contractor shall describe the design and development approach and methodology used for the SOMS Project.

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

Section 6.3,

Section 6.5


In our response to requirement M-33, we have introduced SLC 3, the EDS SDLC that form the basis for the development approach used for the SOMS project. We introduced the concept of work types that are geared towards specific types of development. To describe our approach in more detail, we expand on work types and their applicability to SOMS, and then focus on one selected work type to provide a detailed description of our design and development approach.

Selecting Work Types for SOMS

SLC 3 incorporates a range of work types aligning with the most typical types of software development projects. These work types include:

The Object Components Engineering (OCE) work type – focused on new development, both custom and COTS



The Development + Incremental work type – focused on major enhancements of existing systems

The Composite Application and Portal work type

The Integration and SOA Services work type

The Business Intelligence Production Development work type

There are also work types for systems in the Manage phase incorporating the management of simple and complex changes. Each of these work types provides a pre-defined methodology tailored to the specific nature of the target project.

Clearly SOMS is a large-scale and complex program with unique aspects. Therefore during the initial program planning phase Team EDS, in close collaboration with CDCR, selects and combine the most relevant work types for SOMS into a cohesive and integrated set of processes. The fact that all existing EDS work types are built within a common framework, with extensive sharing of common components, makes them consistent and easily blended together to best meet SOMS needs.

In the remainder of our response to this specific SOMS requirement, we use the OCE work type mentioned above as a sample illustration of the depth, completeness, and flexibility of our SDLC methodology. Indeed the OCE work types are the prime work type for SOMS custom and COTS development, supplemented by other work types as required.

Object Components Engineering Work Type

Based on the CDCR requirements for SOMS and EDS’ extensive background supporting large-scale systems similar to SOMS, elements of SOMS are constructed using the OCE work type based on the SLC 3 framework. We also use our comprehensive Requirements Determination Process (RDP) for validation and analyzing requirements and our Enterprise Testing Method (ETM), which incorporates best practices, tools, standards, and processes, for testing activities within OCE.

OCE is based on an iterative development pattern that divides the work for a release into discrete units, facilitating parallel work on the SOMS services, providing support for composite application assembly, and allowing testing earlier in the release development than is typically feasible in some other development work patterns.

An overview of OCE is illustrated in Figure 6.4-2, OCE High-Level View.



I terative Phases

Plan/ Prepare for I teration

Evolve Architecture

Commit I teration Results

Plan/ Prepare for I teration

Optimize Release

Last Iteration?

Yes No

Figure 6.4-2, OCE High-Level View

The OCE processes iterate to provide early feedback and reduction of costly rework.

OCE uses techniques to minimize the effort and risk associated with developing SOMS. Following the OCE work type, we generate the SOMS work products, such as Entity Relationship Diagrams (ERDs). These work products are built iteratively and lessons learned are documented and applied to future iterations until the results meet the desired goals and are approved by CDCR.

This work type provides the mechanism to validate the CDCR business and technical requirement and to make sure that the development effort is minimized while yielding more accurate results. Figure 6.4-3, Object and Component Engineering Work Type, depicts the OCE work type in detail.



I terative Phases

Commit I teration Results

Last I teration?Yes No

I mplement Release Close-Down

Manage

Project Plan

High-Level Requirements

Business NeedDefinition

TechnicalLaunch Findings

Release/ I terationApproach

Architecture

I mplementationApproval

Architecture

Architecture

DevelopmentEnvironment

Project Plan

Last Release?

Define

OptimizeRelease

Evolve Architecture

Establish Architecture

OO Mentor

Plan/ Prepare for

I teration

No

Yes

Figure 6.4-3, Object and Component Engineering Work Type

The OCE work type provides a structure to design, develop, and evaluate SOMS in a manner that best meets CDCR requirements.

Figure 6.4-3 shows the main OCE processes, such as Establish Architecture, and some of the key artifacts, such as the architecture. It also illustrates the iterative nature of OCE as seen by the stack of three processes used to evolve the architecture. The main OCE definitions used to describe OCE processes and work components include the following:

Process – A process is one of the main OCE activities; Establish Architecture is an example of a process.

Subprocess – A subprocess is a group of activities within a process; Control Risk is an example of a subprocess.

Work Element – A work element is an individual activity, such as Publish Status Report, that produces specific results.



Work Product – A work product is an artifact, such as the Project Plan, that is typically shaped by the execution of one or more work elements.

The OCE Plan/Prepare for Iteration, Evolve Architecture, and Commit Iteration Results processes are iterative; that is, they are repeated multiple times as required by the project. Each iteration focuses on a specific set of activities; each iteration builds on the results of previous ones. We use the OCE iterative processes to incrementally evolve the SOMS architecture, communicating early results to CDCR. This approach allows us to identify gaps and take corrective actions early in the development cycle, thus reducing overall project risk. The OCE processes in Figure 6.4-3, Object and Component Engineering Work Type, are the following:

Define – This process allows EDS and CDCR to further refine the business needs and to further develop the Project Plan, defining the work schedule, resources, budget, environment, risks, and communications.

Work Elements Performed – Following are details regarding some of these work elements:

– Perform Project Start-Up – In this subprocess, the Project Manager starts the project and establishes its operational framework. The Project Manager and the client establish the initial expectations of the project’s deliverables, scope, and internal procedures, and organize the team to complete the planning activities. The project team generates and reviews the initial project plan (Plan for the Plan). Start-Up sets the tone for the entire project.

– Define Business Needs – We further analyze the scope of the SOMS project to appropriately define the effect on the various business units, factoring it into our recommended detailed approach.

– Perform Technical Launch – Led by our Lead Architect and experienced technical resources, we establish and approve the overall, high-level design of the SOMS technical solution to provide a clear direction for the development of the detailed design and implemented processes.

– Define Business Solution – This subprocess consists of engineering-specific activities that define the scope and approach for the solution using models and related documentation.

– Check Point – We ascertain that reviews and communication activities during this Define process have occurred before we start focusing on detailed design and implementation processes.

Manage – The goals of the Manage process are to plan, monitor, adjust, and control a series of interrelated activities to achieve a defined objective while dealing with constraints on budget, time, resources, and technology. This process makes certain that the solution meets SOMS requirements while delivering on time and within budget.



Work Elements Performed – Following are details regarding some of these work elements:

– Plan Project Work – This work element allows us to establish the project environment and to develop and maintain an appropriate work plan that is used as the basis for assigning, monitoring, and controlling the work required to deliver the solution based on the SOMS requirements.

– Execute Project Plan – This work element uses the approved Project Plan to manage the work necessary to deliver the solution based on the SOMS requirements. While executing the Project Plan, we continuously perform evaluations to monitor conformance and take necessary corrective actions to guide the project to achieve its intended objectives.

– Manage Suppliers – We select suppliers and subcontractors to provide work products and services for the SOMS project, and manage their performance.

– Establish Architecture – We create the initial architectural vision of SOMS based on verified requirements. To create the vision, we execute design work elements that produce work products including models, standards, plans, and strategies.

– Plan/Prepare for Iteration – Planning for an iteration increases the likelihood of success and reduces project risk. Planning includes identifying and securing required resources and identifying and agreeing with CDCR on the appropriate metrics for evaluating iteration success.

Evolve Architecture – We evolve the architecture, allowing incremental expansion and maturity of specific areas of the architecture. The bulk of the project development time is spent evolving the architecture.

Commit Iteration Results – We evaluate the goals of the iteration against the iteration results, based on the criteria that were defined during the Plan/Prepare for Iteration. We factor the results into future iterations and identify reusable artifacts to improve the efficiency of future iterations and potentially to improve the design.

Optimize Release – Begins after iterative development produces a complete, integrated release and the release has been verified as meeting the requirements. The focus of the Optimize Release is to refine the release for better performance, package it for delivery, and obtain implementation approval through formal acceptance testing.

Implement Release – We deliver the system updates of a release to a fully operational user environment in accordance with the Project Plan and requirements with installing the components of the application in the production environment, testing the installed application, training users, supporting personnel, and providing required system start-up support.

Using OCE and other work types and building on our current EDS Software Engineering Standards, we develop the SOMS Software Engineering Standards



that lay the foundation on which the components of the application is developed and maintained. The standards promote consistency and quality of the development team’s work products, allowing SOMS to be easily maintained as EDS transitions support to CDCR.

Orientation to Project Development Methodology, Tools, and Technical Practices

Successful implementation of SOMS depends on CDCR and EDS having a mutual understanding of the project development methodology, tools, and technical practices. Although EDS has used its extensive experience to hone the development methodologies defined in the sections above, the core tenets behind each practice are based on industry-recognized best practices. Combined with our technical staff’s expertise in the Justice subject-area, both EDS and CDCR will share a similar understanding of practice and terminology. This common frame of reference, along with our background of collaboration with clients, facilitates knowledge transfer and effective training in the use of the SOMS development environment and other facets of the system.

EDS uses a variety of forums and media to facilitate training of CDCR staff in the SOMS development environment. EDS provides CDCR staff with documentation of our methodologies and standards, and other training materials, through a SOMS repository. Training seminars are conducted for CDCR technical staff as defined in Section 6.3, Knowledge Transfer and Training. The SOMS technical training curriculum is structured to confirm that what is taught is relevant to those in attendance.

A key component of the SOMS SDLC training is coverage of the SOMS change management procedures. The training sessions is focused on real world examples of change progression to build understanding within CDCR staff. The EDS training documentation and seminars cover the following topics:

Introduce staff and their roles

Review methodologies for the project

Review software engineering standards

Relate each development environment component to usage

Review project management and OCE

Review the EDS Requirements Determination Process (RDP)

Give detailed description of change management and configuration management practices

Review structure of the SOMS repository and search function

Train on SOMS automated regression testing tool



EDS uses a variety of methods to orient CDCR staff to the SOMS development life cycle and OCE work type. Existing materials are used and modified to reflect customization of our extensible practices for the SOMS environment. EDS training and technical staff work together to create documentation, diagrams, and presentations that define the SOMS SDLC in a clear and concise manner. EDS produces materials and training sessions for CDCR staff that cover the following concepts:

Overall system development life-cycle flow

Change management procedures at each stage of the SDLC

Actions that are taken in each phase of the SDLC

Management of parallel development efforts

Release management procedures

The SDLC training documentation will be made readily available in the SOMS repository for review before and after orientation sessions. EDS conducts training sessions for designated SOMS staff to review the SOMS SDLC and answer questions. Both the training sessions and documentation use examples of various types of change to foster understanding by relating concepts to real world environments. The SOMS SDLC training materials covers these concepts. The SOMS repository will contain the following documents related to the SOMS SDLC orientation:

Example documents of various types of change migrating throughthe SOMS SDLC

Checklists and verification procedures used at each stage of the SOMS SDLC

Interaction of the SOMS Integrated Development Environment (IDE) and SDLC

Third-party tool documentation, with hyperlinks to current document versions where possible

Training session PowerPoint files

Besides application-focused activities, EDS also develops documentation and training materials on project and infrastructure management. The EDS Project Management Office (PMO) team conducts training sessions on asset management, documentation management, risk management, issue management, deliverable review, and other applicable project procedures. The PMO staff also conducts training sessions on the SOMS change management procedure after it has been approved by CDCR.

Additionally, the SOMS Architecture and Infrastructure team provides orientation on infrastructure-related change and configuration management and the role of the project’s configuration management database (CMDB).



RDP Components

The RDP, as shown in Table 6.4-1, RDP Components, is divided into five major components: Plan/Manage, Obtain, Understand, Validate, and Evaluate. The core components – Obtain, Understand, and Validate – are executed multiple times, once for each set of project requirements that need to be obtained, understood, and validated.

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

Table 6.4-1, RDP Components

Component Purpose

Plan/Manage We prepare for and manage the RDP. This includes building the plan that is followed throughout the process and managing the overall execution of the RDP.

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

Understand We analyze the information that we have collected to make sure we have a good understanding of the requirements. One of the tasks in this component is evaluating the statements for consistency, completeness, and appropriateness. For each statement, we establish traceability and validation criteria.

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

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

During requirements verification and analysis, we work with CDCR to plan activities to verify and analyze the SOMS functional, technical, and training requirements.

Requirements Verification and Analysis

EDS began the information technology (IT) outsourcing services industry and, after more than 40 years, continues to be recognized as the premier IT industry leader. We know the critical role that well-documented requirements play in a software development project. Requirements management makes sure that efforts invested in gathering, analyzing, and documenting the requirements are



used throughout the entire project life cycle. Requirements management activities dramatically increase project success and reduce the risk of uncontrolled project changes. By keeping project team members informed about the state of the requirements throughout the development process and into maintenance, development rework is reduced and overall quality increased.

EDS has extensive requirements verification and traceability experience for large-scale application projects, as demonstrated by the successful implementation of the CalWIN and CBMS applications California Work Opportunity and Responsibility to Kids (CalWORKs) Information Network (CalWIN), and Colorado Benefits Management Systems (CBMS). For these implementations, we virtually managed thousands of requirements and continue to use them for ongoing production enhancements and modifications.

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

To assist us in gaining a deep understanding of the requirements, we perform software archeology to capture the business logic and related data components from existing legacy CDCR systems. This allows us to identify gaps and refine requirements early in the process to prevent loss of critical business functions, resulting in costly rework that could potentially be required later in the development life cycle.

Using the EDS Object and Component Engineering (OCE) work type, introduced in the preceding Development Methodology and Technical Practices portion of this section, we execute the OCE key requirements verification processes, subprocesses, and work elements.

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

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



The RDP helps us verify and validate SOMS requirements, which form the basis from which the SOMS solution is designed. The RDP provides a framework for communicating with CDCR and with others who receive and use the SOMS requirements to design, customize, configure, and implement the SOMS solution. With this framework, there is a greater potential for clear communication, accurate requirements, and delivery of a solution that meets CDCR needs.

It is important to recognize that the SOMS requirements represent everything to which we have mutually agreed. That is, both parties accept the SOMS requirements as the basis from which we design the application. Therefore, the individual requirements and the set of requirements should be as clear and concise as possible to enable successful implementation.

To successfully work in the requirements determination process, individual requirements should have the following characteristics:

Unambiguous – Has the same interpretation for all parties

Understandable – Is written in language the parties understand

Complete – Includes the necessary details

Verifiable – Can be practically confirmed

Appropriate – Is relevant within the scope of the project and makes good business sense

Consistent – Does not contradict other requirements

Complete – Includes all essential capabilities

Maintainable – Accommodates changes and is adaptable for future reuse

Structured – Reflects broad relationships and levels of detail

Traceable – Contains cross-references to the source from which the requirement was determined

Planning for Requirements Verification

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

EDS subject matter experts (SMEs) work with CDCR-designated stakeholders in a series of workshops to plan the schedule for the activities during requirements verification and analysis. Understanding that a single, authoritative set of requirements is critical to the successful implementation of the SOMS solution, we conduct joint application design (JAD) sessions with the CDCR-designated stakeholders in the Sacramento, California, area. For each SOMS release, we



conduct JAD sessions with the CDCR-stakeholders, bringing them together in one place, eliminating ambiguity and conflict for SOMS requirements. During project start-up, we work with CDCR to define roles and responsibilities, define the appropriate skill sets and people for the sessions, and create agendas. This single set of JAD sessions, aligned with solution function, support the aggressive implementation timeline for each SOMS release.

Joint Requirements Planning (JRP) is a proven technique for conducting requirements verification sessions with two primary objectives. First, JRP sessions are intended to verify and analyze SOMS information about the business requirements and functions, critical success factors, essential data, system screens and technological and environmental constraints and assumptions. Second, JRP sessions should provide a baseline for project requirements to give direction and scope to the project. Our responses to the RFP requirements are the basis for these sessions. We provide an updated requirements traceability matrix as the output of this process.

Requirements Verification Schedule

We develop the Requirements Verification Schedule to outline the proposed number of meetings, names of anticipated participants, and proposed agendas. We also include updates to the Project Work Plan of detailed activities, schedule, and resources required for completing requirements verification and analysis. As mentioned, we anticipate that all meetings will be conducted in the Sacramento, California area, organized by functional and technical requirements.

Verify and Analyze the SOMS Requirements

Team EDS uses the Borland CaliberRM® software package – which is part of the SOMS development environment and is the same package we have used in other EDS projects of similar size and scope – for managing SOMS requirements. Requirements and clarifications received during and after the requirements verification process are entered into the CaliberRM® requirements repository.

A screenshot from the CaliberRM® tool is shown in Figure 6.4-4, A Screenshot from the CaliberRM® Requirements Repository Tool.



Figure 6.4-4, A Screenshot from the CaliberRM® Requirements Repository Tool

We enter requirements and clarifications from the requirements verification process into the CaliberRM® repository.

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

Requirements Traceability Matrix and Report

Requirements traceability is a key component of EDS’ requirements management process. It links a formulated requirement to upstream sources and to downstream fulfillment in the system. Our requirements traceability provides strong control over the management of requirements, not only during the project, but for the lifetime of the requirements and the associated product or service. For SOMS, EDS’ traceability links the following elements:

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



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

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

During verification and validation we record the origin of the requirement in its source documents. As the project proceeds through later phases, additional traceability is extended by identifying the delivery components that satisfy the requirements.

Figure 6.4-5, End-to-End Requirements Traceability, depicts the model for tracing requirements throughout the project life-cycle.

Source Document

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

Scope Statement

High Level Requirements

Business Process Model

Detailed Requirements

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

business rules)

Design / Code Test Plans / CasesOther Work Products

(e.g., User and Training Manuals)

Figure 6.4-5, End-to-End Requirements Traceability

Traceability depends on the use of a consistent scheme to uniquely identify each requirement, its source, and each delivery component.

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



The following guidelines assist us in defining requirements traceability:

Traceability with respect to source components – Source component traceability links source documents with requirements, as follows:

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

– Forward-to-requirements traceability answers the question, “What requirements are impacted or defined by this source?” This answer is supplied by uniquely identifying each requirement and then showing, for each source of information, the identifiers of the requirements it affects or defines. This is useful to evaluate the effect of changes or clarifications in a source document. It also provides a basic check that the source items are covered by the set of requirements.

Traceability between requirements – Traceability is required between the requirements, on the one hand, and the scope statement, high-level requirements, and business process model, on the other.

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

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

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

We use CaliberRM® to maintain the traceability of each SOMS requirement. An example is shown in Figure 6.4-6, A Screenshot from the CaliberRM® Traceability Matrix.



Figure 6.4-6, A Screenshot from the CaliberRM® Traceability Matrix

The Requirements Traceability Matrix (RTM) and Report deliverables, produced from CaliberRM®, provide the traceability properties of each SOMS requirement. The RTM clearly traces the SOMS business or functional requirements to the corresponding technical requirements.

EDS constructs and use the RTM and Report for SOMS, and is regularly maintained after system rollout. The RTM helps identify the effect of changes to key engineering work products, such as the requirements documentation, application design specifications, application components, and testing specifications, by listing each requirement and cross-referencing it to the design specifications that meet the requirement – whether business, technical, or organizational – and the various test cases that prove the requirement has been met. The RTM is regularly maintained to support future enhancements to SOMS and help in defining future testing requirements.

Along with the RTM deliverable, EDS provides a corresponding report to establish that the SOMS requirements as specified in the SOMS RFP and other supporting requirements and deliverables have been linked properly and successfully established in the development environment. We use the project issues management process, defined in our Project Management Office, to resolve traceability issues, and unresolved traceability issues are reported.



General Design

Team EDS’ design experience with large-scale systems is demonstrated in its high-volume solutions in the marketplace – including the UK National Offender Management Information System (NOMIS), Los Angeles GAIN Employment Activity and Reporting System (GEARS), California Work Opportunity and Responsibility to Kids (CalWORKs) Information Network (CalWIN), and Colorado Benefits Management Systems (CBMS) – that bring proven value to the SOMS project. Our familiarity with the CDCR business and stakeholder community provides a lower-risk implementation than other vendors can offer. EDS understands that the business and system functions, and the development methods for implementing them, are critical factors in successfully driving the design and development of SOMS.

In the following section, we present our approach to the SOMS design, including the processes that we use and the work products that we produce. These processes are common to General Design, Technical Infrastructure Planning and Design, and Functional Design.

Following our overall approach to design, we describe how our design approach produces the deliverables that CDCR requires.

Overall Design Approach

During the design process, we use Joint Requirements Planning (JRP) and Technical Architecture Design (TAD) sessions to facilitate knowledge acquisition, maximize collaboration, and create synergies among the participants, and to make sure that they are on the same page. The RV sessions focus on how SOMS is designed from a business perspective, and the TAD sessions are driven from a technical perspective. To be successful, the RV and TAD sessions require the active participation of CDCR and EDS SMEs.

The EDS design team engages CDCR in designing SOMS by applying the design-related processes of the EDS OCE software development work type introduced under Development Methodology and Technical Practices earlier in this section. These processes are used to develop the general design, technical infrastructure planning and design, functional design, and technical infrastructure deployment.

Table 6.4-2, SOMS Design Processes, highlights the design-related OCE processes and the associated core areas of focus.

Table 6.4-2, SOMS Design Processes

OCE Process Core Focus

Establish Architecture Developing the initial architectural vision of SOMS during general design

Plan/Prepare for Iteration

Planning for the design iterations; an ongoing process that occurs throughout the design as many times as needed




Evolve Architecture Developing the architecture by expanding coverage and depth during technical infrastructure planning and design, functional design, and technical infrastructure deployment

Commit Iteration Results

Evaluating that the goals of the iteration are met or adding outstanding goals to future iterations; documenting lessons learned and factoring them into future iterations

By definition, these processes include work elements for performing reviews and evaluations of the design with CDCR to validate that the design has indeed met CDCR requirements. This facilitates the flow of communication with CDCR as the SOMS design progresses, allowing us to identify gaps and implementing corrective actions as early in the design process as possible. In preparation for formal evaluations, we use iterative and informal evaluations whenever appropriate to increase the effectiveness of the evaluation process.

The OCE processes involve establishing and evolving five architecture views that each focus on specific aspects of the architecture, providing a way for organizing the design and development process and documenting the resulting work products in an industry-standard and consistent manner. These views are the use case, logical, physical, process, and development views, which are based on the 4+1 Architecture View Model1 that has become popular through the Rational Unified Process (RUP). The following sections provide details of the OCE processes used to establish and evolve these architecture views.


The Establish Architecture process of the OCE is used to create the initial architectural vision of SOMS. The subprocesses and work elements performed within this process are based on the requirements gathered during the execution of the OCE Define process and captured in the Systems Requirements Document (SRD) deliverable. The EDS Design team also assimilates available information regarding the current CDCR systems, including use cases, software products, existing or planned network topologies, and package components, to feed the design process. We use the gathered information to establish the use case view of the OCE model and propagate the impacts to the other views of the model. This can be seen in Figure 6.4-7, Establish Architecture Process Diagram, provides an overview of the high-level subprocesses of Establish Architecture.

1 Kruchten, P.B. (1995). The 4+1 View Model of Architecture. IEEE Software, 12, no. 6.



Use Case View

Establish Development

View

Establish Physical View

Establish Process View

EstablishLogical View

EstablishArchitecture

Client Project Leadership

Logical View Process View DevelopmentView Physical View

ArchitectureRelease/ I teration

Approach

Commit Architecture

Project Team

Figure 6.4-7, Establish Architecture Process Diagram

Establish Architecture subprocesses allow the initial architecture vision to be created while tracing the work products to the requirements through use cases.

The Establish Architecture subprocesses facilitate the design analysis and produce the work products, including models, standards, plans, and strategies, such as the use case view, systems engineering standards, system migration plan, and the test plan strategy. The work products established is carried into future design processes, such as the Evolve Architecture process, providing linkage and continuation of the various design and development work products throughout the software development life cycle.

A description follows of each Establish Architecture subprocess, the work elements performed, and the work products produced.

Establish Use Case View – This view defines user services and which roles are interacting with and requesting services from the system. It also demonstrates and validates the convergence of the architectural views. Use cases act as an architectural tool to help identify architectural elements, validate the architecture, and illustrate the architecture.



Work elements performed – Identify business processes, identify use cases, identify actors, and review conformance of use case view against these identified elements.

Affected work products – The following key work products are affected during the execution of this subprocess:

– Actors – The actors work product documents the entities that interact with the system and describes the roles they play when using the system. An actor is someone or something (an external system) that sends information to or receives information from the application. This information evolves into identify user profiles, interfacing systems, and their (security) access into the system.

– Use cases – A use case documents a coherent unit of features and is the primary tool for documenting the functional requirements of the system. It is an effective tool for defining the actors’ interaction with the system. Use cases are logically grouped into application service components, which are used for design, testing scripts, and training.

– Business process model – This model comprises diagrams depicting business events the sequence of business process steps that are executed in response to an event, and the outcome of executing those steps. Typically, the steps closely approximate a use case.

Establish logical view – This view represents the functional requirements of the application and provides a representation of the solution. The software design of the system is captured in areas such as business class diagrams, dynamic views, and logical object model.

Work elements performed – These elements include identify business classes, component model and system interfaces

Affected work products – The following key work products are affected during the execution of this subprocess:

– Business class diagram – The business class diagram is the initial design of the data architecture and is used to identify principal classes and define which classes are within the scope of the application. This artifact evolves into the conceptual data model and identifies key candidate classes.

– Component model – The component model is essential to breaking down any application into manageable components that form the building blocks of the application. This artifact is an early definition of a high-level class diagram, with a clear understanding of the business domain and how the system fits into the enterprise architecture.

– System interface specifications – The system interface specifications are concerned with the identification and definition of the interfaces (internal and external) with the system in order to obtain an agreement between the owners of interfacing systems on how those



entities are communicate. The definitions include dependencies on the physical and software architectures.

– Glossary – A glossary of terms is a source of reference for project team members and contains a definition for each term encountered when exploring the problem (or business) domain. It provides readers, including those who scan and skim, with definitions of unfamiliar words, such as abbreviations, acronyms, and a technical term. The glossary typically evolves in time as an increasing understanding of the customer's business is gained.

Establish process view – The process view addresses system execution characteristics and nonfunctional requirements. This includes system availability, concurrency, distribution, execution, security, and performance. It also specifies process use and distribution.

Work elements performed – The elements include identify nonfunctional requirements, analyze system usage or distribution, and review conformance of process view.

Affected work products – The following key work products are affected during the execution of this sub-process:

– Information protection model – This model identifies the (security) access privileges and restrictions for actors. Actors identified in the use case model are mapped to the logical objects that they must access in performing their business roles. Sensitive or critical data is identified based on the logical object model.

– Logical usage and distribution model – A logical usage and distribution model maps business functions, processes, and data to user classes and logical locations; estimates the volume and frequency of usage for those business processes and data. The resulting information is essential for designing the application architecture for maximum performance.

Establish development view – This view focuses on ease of development, software management, reuse or commonality and any constraints imposed by the toolsets or programming language, required for testing.

Work elements performed – The elements performed include develop performance strategy, develop initial test plan strategy, create initial data conversion strategy, develop reuse plan, develop data conversion plan, develop initial migration plan, define development standards, define persistency approach, and review conformance of the development view.


– Performance strategy – The performance strategy includes evaluations of the system resource usage at each stage of development



to identify and quantify performance characteristics. The evaluation is performed using techniques such as benchmarks and estimation to predict performance.

– Test plan strategy – This strategy is an overview of the approach and testing timeline that details the test activities. The test plan strategy identifies the business scenario types to be tested and identify the process to create test scenarios and cases.

– Initial data conversion plan – The plan identifies the data or programs that are included in the conversion and the availability of people with the knowledge necessary to assist with the development of the conversion strategy.

– Initial migration plan – The initial migration plan establishes the process to be used in the migration of the infrastructure to the new organization. This may involve multiple migration options with the associated key milestones, activities, durations, risks, advantages, and disadvantages.

– Initial disaster recovery plan – The disaster recovery plan documents the procedures and facilities that are used to recover SOMS services that support critical customer functions and return them to regular operating procedures as soon as possible following a disaster. Business continuity requirements are included in the high-level project requirements and in detailed systems management requirements.

– Software engineering standards – These standards include the definition of standards required to support the development activities.

– User interface standards – These standards are developed for Graphical User Interfaces (GUIs), report layouts, and correspondence to provide a consistent look and feel across the entire application.

– Persistency approach – The persistency approach describes the strategy for persisting objects. Based on the choice of persistent mechanism, this document addresses the issues that result from that choice. The approach is analyzed to allow CDCR to consider the risk to the project of each potential solution.

Establish physical view – This view defines the initial implementation plan by working with other affected CDCR and EDS groups, and begins planning the implementation of the system at a high level to allow time to consider implementation requirements and issues. It includes the definition and prioritization of application deployment requirements including network, computers, programming language(s), software, configuration management, software distribution, applicable standards, capacity, availability, security, cost, and location.

Work elements performed – Develop initial implementation plan, establish initial technical infrastructure, and review conformance of physical view.




– System migration plan – This plan identifies the application software modules and supporting components, and the libraries or other configuration information required for migrating to integration test, model office, and production environments.

– Training program specifications – This identifies the training required to prepare users, operators, administrators, technical support staff, and management to perform in accordance with defined job specifications.

– Production support turnover plan – A plan that documents the turnover plan and documents the work necessary to transfer the system to the support staff members who are responsible for ongoing system support. The role each organization has in the support of the system in production is clarified. It is a component of the implementation plan and produced during system development.

– Hardware and software selection – This document defines the specific products, configurations, locations, and interfaces of hardware and software components for the environment in which the application operates. The selection is made according to new environment requirements and hardware and software selection criteria.

Commit architecture – The purpose of this sub-process is to review the architecture with CDCR to make certain that the system has architecture defined that meets CDCR functional and technical requirements. It also updates requirements to reflect the knowledge that was gained during the Establish Architecture process. User scenarios cases are ranked and the higher-ranking user cases are tackled in early iterations.

Work elements performed – Elements include review conformance of architecture, control work products, and change release or iteration approach.


– Requirements traceability matrix – This requirements traceability matrix keeps track of each requirement and the resulting system components that satisfy the requirement.

– Project workbook – The project workbook is a repository for project documents and reference materials that can be a physical or a virtual collection of work products including project management and other discipline work products.

– Architecture – The architecture models, standards, plans, and strategies are updated to reflect the finding of the architecture review.



Plan and Prepare for Iteration

Given the core iterative nature of the OCE, iterations must be well planned to verify that specific goals are met. The iterations should constantly focus on identifying the most architecture concerns to mitigate risks. Our iteration planning includes the specification of the work products and the specific functional requirements that are addressed during the iteration. It also includes identifying and securing the resources required for executing the iteration including hardware, software, space, staffing, budget, and training.

In measuring the success of iterations, we define the appropriate metrics for measuring the success of the iteration and we work with CDCR to agree on criteria for the iteration success. We provide CDCR with the iteration plan, solicit input, and work with CDCR to agree on its roles and responsibilities during the iteration. Finally, we update the work plan to reflect the decisions made. Figure 6.4-8, Plan and Prepare for Iteration Process, illustrates the following approach to the iteration process.

Develop/ Update Work Plan

Prepare Project Team and

Affected Groups

Identity and Acquire Reusable

Assets

Establish Environment

Evolve Glossary

Figure 6.4-8, Plan and Prepare for Iteration Process

A well-planned iteration results in the best use of time and resources by addressing architecture concerns that reduce project risk early.

The following is a description of the Plan and Prepare for Iteration process work elements performed and the work products produced:

Develop and update work plan – Develop the work plan for the current iteration identifying a schedule for detailed activities. The work plan for the iteration contains more detail than the overall project schedule, but is kept in synch with it.

Prepare project team and affected groups – Project team members, participating CDCR personnel, SMEs, and other affected groups are prepared to participate in the iteration activities.

Identify and acquire reusable assets – The assets are identified that can be reused on this iteration and communicate them to the project team.

Establish environment – The project environment previously established in Establish Architecture is built, and more details for the definition of the project approach are provided. The development environment is implemented as needed for the current iteration.

Evolve glossary – The project’s glossary is updated.

Affected work products – The following key work products are affected during the execution of this sub-process: project plan, development view,



reuse plan, reusable assets definitions, development environment, architecture, and glossary.

Evolve Architecture – The Evolve Architecture process of the OCE is used to develop the architecture that was established during the Establish Architecture process. The EDS design team evolves the various architecture views (Use Case, Logical, Development, Physical and Process) to develop the system. The bulk of the project development time is spent evolving the architecture. Figure 6.4-9, Evolve Architecture Process Diagram, illustrates the following process:

Use Case View

Evolve Development

View

Evolve Physical View

Evolve Process View

Evolve Logical View

Evolve Use Case Views

Logical View Process View DevelopmentView

Physical View

I ntegrateSystem

Components

Figure 6.4-9, Evolve Architecture Process Diagram

Evolve Architecture covers the architecture from different views, allowing the established design to evolve into a comprehensive design while maintaining traceability to requirements through the user case view.

The OCE Evolve Architecture approach is directly mapped to the general design so that the work products developed during the general design serve as input to each of the Evolve Architecture processes. This approach produces a natural progression of the design. The following is a description of each Evolve Architecture sub-process, the work elements performed, and the work products produced:

Evolve use case view – The use case view that was established during general design evolves to include additional use cases. The view expands the analysis and documentation of each use case to include the typical course of events, preconditions, post-conditions, exceptions, and to identify the specific



scenarios for each use case. The use case model is refined to consider reuse by identifying abstract use cases that represent commonality across multiple concrete use cases. The other key activity that takes place with the evolution of this view is the design of the business organization transition and expanding the business process model to include the actors who are interacting with and requesting services from the system. This is achieved by further answering how the business adopts the new business processes and use cases.

Work elements performed – Elements performed include refine business process model, review conformance of business process model, refine actors, refine use cases, refine use cases packages, review conformance of use case model and design business organization transition.


– Actors – Actors are cataloged as roles of users or external systems that send information to or receive information from the application.

– Use case packages – Use case packages are a combination of use cases and use case diagrams that are logically grouped system features. The use case packages are reviewed for conformance.

– Business process model – The business process model is the business context for each use case and comprises diagrams depicting business events, the sequence of business process steps that are executed in response to an event, and the outcome of executing those steps. The business process model is reviewed for conformance.

– Business organization transition strategy – A business organization model identifies the jobs or roles in an organization and links those roles according to reporting or functional relationships. The model includes the impact on changes to roles and their responsibility. The business organization transition strategy is reviewed for conformance.

Evolve logical view – The logical view that was established during general design evolves to a more concrete representation of the solution while taking into account the evolution of the use case view. This is done by modeling the system software design in class diagrams, dynamic views, logical object model, design object model, implementation classes, and the component model.

One critical goal during the evolution of the view is that architecture-significant functions must be identified so that early iterations or proof-of-concepts for that functional capability can be produced to mitigate the associated risk. Interfaces between the components are clearly defined so that they can evolve through the iterations independently of each other and come together at a later integration step.

This process involves numerous sub-processes and work elements that



generate work products that serve as the cornerstone for the specifications of the SOMS from a functional level. The work products have been mostly established during the Establish Logical View process, but they are detailed and expanded during the Evolve Logical View process.

Work elements performed – Elements include analyze logical system, , analyze workflow, design application, evolve component model, review conformance of component model, design data storage/management, design user interface, produce user interface layer, review conformance of application software, and perform unit testing.

Affected work products – The following key work products are affected during the execution of this sub-process: user case model, business process model, business rule catalog, requirements traceability matrix, activity diagram, workflow diagram, interface specifications, user interface specifications, and project workbook.

Evolve process view – The process view that was established during general design evolves to include updates to the nonfunctional requirements—such as security and performance—that become more apparent because of the extra details that are captured during the iterations in the other design views. The system usage and distribution patterns also are further analyzed to more accurately reflect reality. The updates to the process view impact several work products, especially the ones related to the physical infrastructure.

Work elements performed – Elements performed include refine nonfunctional requirements, review conformance of nonfunctional requirements, and analyze system usage or distribution, and review conformance of logical usage and distribution specifications.


Nonfunctional requirements – The nonfunctional requirements are represented in a catalogue and provide the requirements relating to the physical aspects of the system that satisfy CDCR’s functional and technical requirements.

Logical usage and distribution model – A logical usage and distribution model maps business functions, processes, and data to user classes and logical locations and estimates the volume and frequency of usage of those business processes and data. The resulting information is essential for designing the application architecture for maximum performance.

Evolve development view – The development view that was partially defined in Establish Architecture evolves to reflect updates to the development standards and strategies, refinements to the test strategy, test specifications, and implementation plan. Testing specifications must be produced for each level of testing including unit testing, integration testing usability testing, and acceptance testing. The implementation plan evolves to



describe how and when the current release is to be rolled out to the customer.

Work elements performed – Elements include evolve testing specifications, review conformance of testing specifications, refine development standards or strategies, and review conformance of development standards or strategies.


Test plan strategy and specifications – This defines the plan objectives; determines test approach, environment, resources, and tools; and develops test cases and data for unit, integration, usability, and user acceptance testing.

Software engineering standards – Development standards and strategies include coding standards, user interface standards, component standards, exception handling, and tool standards refined and reviewed for conformance.

Evolve physical view – In Establish Architecture, the emphasis in this view was to define the requirements of the technical infrastructure in terms of capacity, scalability, and resilience and a high-level design indicating the nodes and network topology produced. As the iterations progress, the design is expanded, product selections are finalized, and configurations and provisioning of system software, commercial off-the-shelf (COTS) packages, and system support scripts are defined. The migration plan from the current environment to the target environment should be well defined. This process involves numerous sub-processes and work elements that generate work products to serve as the cornerstone for the specifications of SOMS from the implementation and execution level.

Work elements performed – Elements performed included refine implementation plan, review conformance of implementation plan, design execution scripts, produce execution scripts, review conformance of execution scripts, define impact on current environment, define hardware or software selection criteria, evaluate hardware/software alternatives, specify environment selections or configurations, review conformance of technical architecture specifications, provide hardware and system software, prepare systems management facilities and agreements, test technical environment components, design roles and responsibilities or procedures, design the organization, design non-automated system components, design user guide and job aids, design operational or administrative guides and job aids, design technical support guide and job aids, design training programs, review conformance of business organization designs, produce non-automated system components, produce user guide, produce operational and administrative guides, produce technical support guide, produce organization documentation, develop disaster recovery plan, test documented procedures, produce training materials, review conformance of business organization components, produce migration or conversion utilities, produce transition aids



and communications, document system configuration, test transition components, and review conformance of transition components.


– Implementation plan – Implementation plan refinements include refinements to the application installation plan, contingency plan, database installation plan, platform installation plan, system migration plan, training plan, and production support turnover plan.

– Execution scripts – Execution scripts are used to manage the system or perform system setup operations.

– Technical environment – This provides a platform on which to install and operate the completed application software and data. This includes the hardware, network, and system software components and the intended selection and configuration of products.

– Technical specifications – The technical architecture specifications make certain that the environment in which a system operates is stable and has sufficient capacity for the tasks to be performed. They document any considerations and requirements for the technical infrastructure to support CDCR functional and technical requirements.

– Business organization model – The business organization model is used to design and refine the job functions, roles, responsibilities, procedures, and organizational structures to enhance the performance of the system users.

– System documentation – The system documentation includes the user, operator, administrator, and technical support guides. It also includes information about previous system performance, problems and resolutions, and modifications.

– Disaster recovery plan – The disaster recovery plan documents the procedures and facilities used to recover the EDS services that support critical SOMS client functions and return to regular operating procedures as soon as possible following a disaster. The plan must address the business continuity requirements taking into account data management and administrative procedure designs.

– Training plan and material – The training plan includes the courses and e-learning available, the personnel to be trained, training schedule, and plans for training facilities.

– System migration utilities and aids – The system migration utilities and aids include the list of program modules, source code, utilities, copy members, and data files that are to be moved during the migration process as defined in the system migration plan. The system migration utilities and aids are reviewed for conformance.

Integrate system components – Integrating system components is a critical step in the functional design as it allows conflicts, gaps, and



inconsistencies across components to be identified and resolved producing an overall coherent design. The integration includes interfaces between components within the system and interfaces between the system and other systems. Produced system components are integrated into major components and a complete system. As components are integrated, they are tested to support proper collaboration and usability. If major performance problems are discovered, these may signal a need for redesigning the components. Minor performance tuning and packaging are done during the Optimize phase. Usability testing also is performed to verify system compliance with usability standards and make certain that the system facilitates and improves the performance of business tasks.

Work elements performed – Elements include integrate automated components, incorporate non-automated components, perform integration testing, perform usability testing, and review conformance of prototype with client.


Integration testing plan and results – The integration test plan identifies the levels and portions of integration testing to be performed, the personnel performing the various roles during the integration testing process, the use of automated tools, and the approval procedure. Integration test results document the outcome of integration test cases, performed and validated according to the integration test plan. Results may indicate a need for changes in integration test cases, integration test data, the integration test plan, the produced components, design specifications, logical specifications, or even detailed business requirements.

Usability testing plan and results – The usability test plan specifies how system components or modules are tested by actual or representative users, the use of automated usability tools, and the personnel required to execute the testing. The usability test plan is reviewed for conformance. Usability test results document the outcome of usability test cases, performed and validated according to the usability test plan. Results may indicate a need for changes including the need for refining the user guide specifications, training designs, and other human performance support designs.

Commit Iteration Results

During the Commit Iteration Results process we evaluate the goals of the iteration against the iteration results using the criteria that was defined during the Plan and Prepare for Iteration process. If the goals are not met, we document the shortcomings of the iteration and factor them into future iterations. We seek to identify reuse artifacts to improve the efficiency of future iterations and potentially improve the design. Figure 6.4-10, Commit Iteration Results Process shows the following work elements performed.



Package Release Components

Obtain Client Sign-OffMake Release

Available

Coordinate Formal Acceptance Testing

Review Architecture vs. Release/ I teration

Approach

Required

Conditional based on defined criteria

Figure 6.4-10 Commit Iteration Results Process

Commit Iteration Results validates conformance to the architecture and captures reusable assets to increase the efficiency and quality of future iterations.

The following is a description of the Commit Iteration Results process work elements performed and the work products produced:

Package release components and control work products – Using the configuration management tool, we identify each individual configuration item that is a part of the release and its current status. We build the release from the appropriate components, store in a controlled environment, and update system documentation as appropriate.

Coordinate formal acceptance testing – EDS works with CDCR to conduct final integration, formal acceptance testing, and other testing using the approved testing specifications and the test strategy. We record and retain testing results, and track the problems discovered and resolved. If applicable, we collect, analyze, and store prerelease defects that are discovered during testing and retest as appropriate. Additionally, we update configuration management data.

Review architecture versus release and iteration approach – EDS evaluates the goals against the results of the iteration. If the goals are not met, the shortcomings of the iteration are documented and factored into a future pre-implementation iteration. After review of the iteration results, design metrics are gathered for the iteration, and the metrics are evaluated. The results of the metrics evaluation may influence future iterations. Additional reuse may be identified and the design may potentially be improved. EDS verifies that work products or deliverables created before this point in the project are updated based on the results of the iteration. We review the configuration status accounting report, if one has been created, to be sure that the configuration items are listed.

Obtain CDCR sign-off – EDS follows established sign-off procedures to obtain CDCR sign-off, indicating a successful completion of the application or release as verified by acceptance testing results or other appropriate documentation.



Make release available – Using the configuration management data, EDS makes sure the proper system configuration is built and collects final size metrics. We move the system to the to-be production environment and communicate to CDCR that the release is ready for the pilot or rollout.

Harvest reusable assets for reuse – We harvest project assets for reuse by identifying project artifacts—including objects or components and supporting documentations—that are eligible for reuse. Harvested reusable assets reduce development time for future iterations, improve quality and consistency, and reduce the overall risk of project failure.

Affected work products – The following key work products are affected during the execution of this sub-process: project workbook, reusable assets, reusable asset definitions, requirements traceability matrix, requirements document, testing specifications, and architecture.

In the Overall Design Approach section, we described the processes that we use throughout the various design tasks. These processes also are used for Functional Design and Technical Infrastructure Planning and Design.

We describe our overall design processes that will enable CDCR and EDS to meet the requirements of General Design.

During general design we define the high-level system architecture and create, refine, or eliminate business processes as we gain more details. We define the technical components such as software, hardware, and network architecture as well as devise the conversion and migration procedures. The design decisions are influenced by the consideration for the impact on the CDCR business organization.

EDS has a proven approach for designing and architecting large-scale eligibility systems such as CalWIN using the OCE work type. Additionally, the OCE has been implemented for numerous non-eligibility large-scale projects while serving EDS’ extensive worldwide client base. During general design, the following OCE key processes shown in Table 6.4-3, General Design Processes are executed.

Table 6.4-3 General Design Processes


Establish Architecture Sub-processes and work elements

Evolve Architecture (Iterative)

A specific selection of sub-processes and work elements based on critical architecture areas that need to be evolved

Manage Exercise project control – Conduct conformance reviews:

– Prepare and distribute materials for review and conduct conformance review meeting

Maintain the project schedule:

– Collect and update progress data and evaluate performance to schedule and take corrective action



During general design our goal is to establish the first cut of the architecture by executing the various sub-processes and work elements of the Establish Architecture process to gain a good understanding of the system and the supporting architecture from several different views. We then execute one or more Evolve Architecture iterations to further detail specific areas of the architecture that pose the highest risk. The Establish Architecture and Evolve Architecture processes were detailed earlier in this section.

We facilitate requirements verification (RV) and technical architecture design (TAD) workshop sessions that allow us to work with CDCR to produce an accurate logical flow of the business processes, the related data elements, the business logic associated with each process, and the logical specifications in which to implement the SOMS-enabling technologies. This approach makes certain that SOMS features and functions are correctly understood, documented, and approved by CDCR before moving further into subsequent SOMS design processes.

We base work elements performed within the Establish Architecture process on satisfying the SOMS requirements as defined in the SOMS requirements defined in the Systems Requirements Document (SRD) Deliverable of this response. We analyze each requirement and assimilate it into the appropriate design work products. We update the requirements management tool to establish traceability between the requirement and the related business and technical processes. The tool is used to generate the requirement traceability matrix whenever needed.

One of the main purposes of the user case view of the OCE view model is to provide a view of the system as seen by the external observer. The user case view is the center of the OCE model as it ties the other views together; hence, this view model is known as the 4+1 architecture view where the “1” is actually the user case view. Use cases serve as an input to many OCE processes. We develop and use a standard use case template to consistently create user cases that provide clarity and capture different levels of information related to the use case including assumptions. As the user case is referenced throughout the development process, these assumptions are communicated forward so that we can further analyze them and reflect the findings on other work products.

The work products and strategies that are established during this process are include the following integrated architectures, which provide clear information regarding the design of the baseline application software, the system internal and external interfaces; and the technical infrastructure while using the integrated development toolset, industry-standard specification languages, and models:

Hardware and network architecture – The hardware and network architecture contains the direction of hardware and network architecture including a high-level description of the computing and network resources across SOMS processing environments and physical sites, including connectivity to CDCR Enterprise Network This architecture is established during the Establish Physical View sub-process.



Software architecture – The software architecture is a high-level description of software layers and components—such as operating systems, protocols, database management, languages, utilities, middleware—and how they interact to implement the functional architecture. This architecture is established during the Establish Physical View sub-process.

Functional architecture – The functional architecture is a high-level description of the features and capabilities of the SOMS. This architecture is established during the Establish Use Case View sub-process.

Application software architecture – The application software architecture is a high-level description of the organization of the application into service components, interface management, and security processing. This architecture is established during the Establish Use Case and Logical View sub-processes.

Data architecture – The data architecture is a high-level description of the logical design, structure, and implementation of the data needed for the SOMS features and operations. This architecture is established during the Establish Logical View process.

General Design Document

Our aim is to provide CDCR with a general design document that accurately conveys the mutually determined design decisions. These early decisions are often the most difficult to get right, the most difficult to change, and have the most far-reaching effect on the project and its stakeholders. Our extensive and relevant UK Her Majesty’s Prison Service and CalWIN experience positions us to accurately guide these decisions, saving CDCR significant time and resources and reducing overall project failure risk that might be introduced by others vendors that lack such experience.

Our general design document encompasses various work product documents produced while executing the OCE design processes and includes extractions or detailed descriptions of the non document-based work products. The document addresses the following components:

Overview – A general design overview is provided to summarize and link the design work products together. After CDCR approves this document, it serves as the core input to the Functional Design process that follows.

Architectural component descriptions – A collection of architectural views captures, organizes, and communicates the intent of the SOMS architecture while highlighting the most important features and capabilities of each.

General constraints, limitations, and assumptions – Each artifact contains assumptions and inhibitors identified during the project. To mitigate the impact on users, we use existing business processes and workflows, terminology and nomenclature, and datasets whenever appropriate and to CDCR’s satisfaction.



Security design – The security design includes the security consideration on each architecture component and will be fully compatible with CDCR security policies and procedures.

Communication interface – The description of how the SOMS as a service-oriented architecture (SOA) system communicates within itself and across the various physical sites and with CDCR desktop and user environments, e-mail, Internet, and CDCR networks. The design will be fully compatible with CDCR standards.

External interface – This includes the design strategy for implementing interfaces with the various external systems that interact with SOMS.

User interface – The strategy for designing the user interface to make sure of compliance with functional and technical requirements includes the satisfaction of usability requirements.

Performance – The design consideration for meeting nonfunctional SOMS qualities includes availability, response time, throughput, data volume, problem complexity, maximum number of concurrent users, and peak load.

Additional design consideration – This section includes a description of the design characteristics that are not detailed in other sections of the document.

Given the considerable amount of information that is collected and refined during general design, we update and provide to CDCR (for review and approval) the project control document (PCD), management and operations (M&O) services plan, and conversion and archiving plans. The updates reflect this new knowledge so that the plans more accurately reflect the overall SOMS project status at that point of the software development life cycle.

Technical Infrastructure Planning and Design

The SOMS infrastructure planning and design will be implemented using EDS globally shared methodologies, preexisting extensible infrastructure architectures, the extensive experience of our staff, and our sizeable corporate body of knowledge that has evolved during the company’s 40 years of existence. The SOMS technical infrastructure planning and design uses portions of the EDS Object Components Engineering (OCE) methodology relevant to the development of infrastructure architecture. For the SOMS infrastructure we customize proven EDS architectures to the needs of the SOMS integrating existing shareable services.

EDS’ practices and architectures are industry-recognized by analysts such as Forrester. 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.”2

Besides our recognized corporate-level practices, our design for the SOMS infrastructure uses our depth of experience supporting government agencies to address the specifics of this effort. EDS already provides infrastructure support for several California welfare consortiums and the LA GEARS project. We use our corporate-level practices in designing and supporting similar systems to develop an optimized SOMS infrastructure architecture. From Day One of the infrastructure design effort, our infrastructure architect team works with context-specific knowledge and not purely from theory. Our unique experience facilitates a design that addresses CDCR’S performance and availability requirements and a smooth integration with the CDCR Networks and other interface partners.

The OCE work type introduced in the Development Methodology and Technical Practices portion of this section incorporates infrastructure design planning and implementation sub-processes and work elements that accomplish several objectives:

Infrastructure components are verified in the same environments as the SOMS application,

Infrastructure requirements are traceable in CaliberRM®, and implemented through the project-wide change and configuration management system (CA CMDB) and related tools.

During General Design several infrastructure work products are established that serve as the starting point for this task. During Technical Infrastructure Planning and Design, the following key OCE processes shown in Table 6.4-4, Technical Infrastructure Planning and Design Processes are used to further establish and evolve the Technical Infrastructure work products:

2 Roehrig, Paul, (June 14, 2007). “EDS Is A Leader in Global IT Infrastructure Outsourcing” Forrester Wave Vendor Summary, Q2 2007.



Table 6.4-4 Technical Infrastructure Planning and Design Processes


Establish Architecture Establish Development View—Create initial development

strategies

Develop performance strategy

Evolve Architecture (Iterative) Evolve Logical View—design application—evolve persistency

layer:

Design data storage and management

Evolve Process View:

Analyze system usage and distribution

Review conformance of logical usage and distribution specifications

Evolve development view

Evolve Physical View—Evolve technical environment and

infrastructure:

Design technical environment conversion

Review conformance of technical environment conversion strategy

Design technical infrastructure (define impact on current environment, define hardware/software selection criteria, evaluate hardware/software alternatives, specify environment selections/configurations, and review conformance of technical architecture specifications)

Manage Exercise project control—conduct conformance reviews:

Prepare and distribute materials for review and conduct conformance review meeting

Maintain the project schedule

Collect and update progress data and evaluate performance to schedule and take corrective action

These OCE processes, sub-processes, and work elements are further detailed in the SOMS Design portion of this section. The Evolve Architecture process detailed in the SOMS Design discussion, contained earlier in this section, includes several sub-processes and work elements that are used to evolve the technical infrastructure plan and design. The OCE Evolve Physical View sub-process is based on recognized standards, such as Capacity Maturity Model Integration (CMMI), and Information Technology Infrastructure Library (ITIL). EDS has aligned its information technology (IT) practices to these standards for reasons beyond contract compliance — we have been a significant contributor to the ITIL since its



inception in the late 1980s, writing for both releases of ITIL in 1990 and 2000, along with the ITIL version three rewrite.

The Establish Architecture Physical View sub-process allows Team EDS to develop an enterprise infrastructure architecture that encompasses the following components and requirements:

Network

Computers

Programming language(s)

Software

Configuration management

Software distribution

Applicable standards

Capacity

Availability

Security

Cost

Location

Given the iterative nature of the OCE, the technical infrastructure plan and design evolves for each iteration focuses on a specific set of sub-processes and work elements that affect the various infrastructure work products. For example, the first iteration might incorporate capacity planning activities that are then used in later iterations to develop an infrastructure architecture that addresses system availability, performance, and growth. This allows us to identify the required software to meet technical objectives and rightly size the hardware needed to support the SOMS.

The Evolve Architecture process allows EDS to adapt our design as needs or technology change. Throughout the iterations, the focus of the physical view is to design and produce the technical support elements for SOMS (for example, procedures), as well as the hardware and software configurations that compose the system’s infrastructure. This may include provisioning and configuring of system software or the development of support scripts.

The major outputs of each aspect of the Evolve Architecture process undergo review against infrastructure-related procedures and best practices that are part of the EDS globally implemented Enterprise Quality Management System EDS starts with an initial design based on our experience and infrastructure knowledge. This evolves into the final SOMS architecture based on various



inputs, such as requirements, capacity planning, technological capability, and industry best practices.

Using the OCE and our leading infrastructure implementation expertise, combined with our government support expertise and tools geared toward systems such as the SOMS, EDS develops an enterprise infrastructure design that meets the requirements in the RFP. We produce the following project deliverables, besides other design and implementation documentation:

Technical Infrastructure Design

Facility Management Plans

Information Security Plan

Business Continuity/Disaster Recovery Plan

Besides our in-house methodologies, capabilities, and services, EDS works collaboratively with our industry partners to draw on both breadth and depth of expertise across technologies. The EDS Agility Alliance is the top tier of our collaborative partnerships and is composed of companies with broad-based offerings that are globally recognized for their quality products and value to our mutual clients. The EDS' Agility Alliance program was awarded the 2008 Association of Strategic Alliance Professionals (ASAP) Alliance Excellence Award that recognizes outstanding alliances sponsored by ASAP http://www.strategic-alliances.org/(strategic-alliances.org). The EDS Agility Alliance includes companies such as Cisco, EMC, and Oracle — all of whom are parts of the EDS SOMS solution. The mission of the EDS Agility Alliance is to create an 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 us and our partners. EDS and Alliance companies’ top staff works together during the Evolve Architecture, Implementation, and Operations phases of the SOMS project to combine EDS’ service delivery expertise in the government sphere with the knowledge of the Alliance Partner products.

Design Technical Infrastructure

With more than 120,000 employees worldwide, EDS has a broad base of in-house infrastructure staff to bring to bear on the SOMS project. Because of our support of large scale projects, such as the CalWIN, our infrastructure staff possesses a unique mix of subject-matter, best practice, and technical expertise that can be leveraged to design a solution optimized for the SOMS operating environment. EDS develops a series of infrastructure designs tailored to the nuances of the SOMS processing environments supporting the life-cycle from development through to production. EDS develops documentation for the various combinations of processing environments and sites that comprise the SOMS. The final infrastructure design plan uses a series of iterations that includes the following high-level activities:


http://www.strategic-alliances.org/

http://www.strategic-alliances.org/

https://infocentre.eds.com/cgiwrap/infocentre-cgi-bin/news/gotoStory.pl?styID=971842/0

https://infocentre.eds.com/cgiwrap/infocentre-cgi-bin/news/gotoStory.pl?styID=971842/0


Use the EDS requirements validation process to collaboratively define and finalize SOMS requirements with CDCR.

Generate capacity planning reports using our patented methods and off-the-shelf products such as Hyperformix.

Combine inputs such as requirements, capacity planning metrics, architectures, and best practices into detailed infrastructure design documents including topologies, components, and configurations used by sites and processing environments in collaboration with our Agility Alliance partners.

Implement quality assurance and peer reviews by other technical subject-matter experts (SMEs) using the EDS GAD QMS.

Tailor existing EDS standards documents for the SOMS environment and infrastructure to facilitate efficient management of system resources and performance for the duration of the contract.

Review resulting documentation with CDCR on initial generation and during future updates.

The infrastructure design documentation for the SOMS processing environments also are broken down by the following phases:

Design, Development, and Implementation

Performance Verification

Operations

During this iterative process, additional detail may be gathered in some of the architectural views that affect the Process View. The Process View evolves when changes are made to the physical infrastructure during refinement of technical requirements. As versions of the infrastructure design documents are generated and refined within each of the iteration, they are established in the SOMS software configuration management (SCM), CA CMDB. Each published version of the design documents will be available for CDCR and EDS staff through the SOMS repository.

Technical Infrastructure Design Document

Using our experience supporting similar operating environments for projects such as CalWIN, EDS develops documentation for each pairing of processing environment and site. The final infrastructure design document and maintenance plans include the following topics:

Develop detailed technical infrastructure design

Develop maintenance strategies based on the infrastructure design documents



Create capacity planning procedures and schedules to facilitate proactive expansion of SOMS infrastructure resources in anticipation of system growth to meet project service-level agreements (SLAs)

Use capacity planning reports and vendor support schedules to generate hardware and software refresh schedules

Customize shareable EDS global standards documents for the SOMS environment such as those related to storage management, component labeling, port utilization and other items that facilitate efficient system management and system performance

Develop a holistic system administration and maintenance strategy for the SOMS infrastructure to facilitate individual component and overall system optimization

Identify and design any special utilities or tools to meet the requirements and SLAs of SOMS

Our considerable infrastructure management expertise and background supporting social services systems promotes the rapid development of efficient and effective infrastructure architecture and maintenance procedures. As the project progresses, we augment the initial versions of these documents from knowledge gained during SOMS implementation and from information that is continuously added to the EDS global knowledge base.

Network Design Plan

While EDS anticipates that CDCR will provide network connectivity and engineering and depending on the hosting option adopted, EDS provides data center network connectivity and engineering, the EDS SOMS network support team works with CDCR to validate that the existing CDCR network bandwidth supports the SOMS system. For example, the CDCR and EDS network teams work together to develop the details of the CDCR Wide Area Network (WAN) to facilitate integration and deployment of the SOMS solution. An EDS SOMS architect also contributes to the design to address business continuity and disaster recovery requirements.

We provide input into the SOMS Network Design Plan describing the SOMS network approach established with CDCR and the overall approach in meeting the network-related performance requirements. The document provides design details that include the following:

Enterprise connecting hardware, including the gateway and interfaces

Network security infrastructure

Network management practices and infrastructure such as automated monitoring and maintenance



Resulting artifacts of capacity planning and performance testing efforts along with network architecture documentation, noting how the design meets performance Service Level Agreements (SLA)

Business continuity and disaster recovery plan support

The resulting network design plan will include a combination of architectural, procedural, and capability assessments based on performance testing. Additionally, this plan will document our course of action to meet the functional requirements for providing secure SOMS access for CDCR-designated sites.

Detailed Design

During Detailed Design Team EDS develops the functional designs of the baseline application software and present them to CDCR. In developing the Detailed Design we use the EDS OCE software development work type introduced in the Development Methodology and Technical Practices section above. Table 6.4-5, Detailed Design Process highlights the key functional OCE processes and the associated core focus.

Table 6.4-5 Detailed Design Process


Establish Architecture Establish logical view

Identify component model

Identify system interfaces


Evolve logical view

Design application: evolve persistency layer (design data storage/management and design object to persistency mapping)

Evolve presentation layer (design user interface)

Transition strategies

Design software conversion

Design data conversion

Manage Exercise project control - conduct conformance reviews

Prepare and distribute materials for review

Conduct conformance review meeting


Collect and update progress data

Evaluate performance to schedule and take corrective action



Develop the Detailed Design

During the Establish Architecture process, the SOMS features are established through the Actors, Use Cases, and Business Process Model work products. These work products are generated using the Establish User Case View process based on the Systems Requirements Document (SRD) described previously in this section of our proposal. These work products are analyzed and used as input to the Establish Logical View process where the functional design work products, such as the business class diagrams, component model, user interface, and system interface specifications, are first established.

Team EDS then expands and enriches the Detailed Design work products during the Evolve Architecture process where the Use Case View sub-process allows us to thoroughly document the user services that the SOMS will provide. We also identify and refine the Actors who are interacting with and requesting services from the SOMS, including external systems. From this information, our team produces the workflow diagrams that demonstrate the dynamic flow of work as it moves through the various CDCR organizational entities and external systems that interact with SOMS.

The Evolve Architecture process is iterative, allowing us to further define the logical view of the architecture through continuous analysis, design, and produce activities. Team EDS establishes objectives for each of the iteration to advance specific aspects of the architecture. The USe Case Model is an input into the Evolve Logical View process, which generates component and class diagrams that represent the SOMS software solution.

We analyze the dynamic aspect of the system by generating collaboration and sequence diagrams that show interactions between the various class instances. Activity diagrams will be developed to determine the business logic and the various states in which classes reside. As these different functional design activities occur, they influence each other because they are connected.

Through the iterations, the Logical View model starts to emerge. The Establish Architecture and Evolve Architecture processes, associated sub-processes, and work elements are detailed in the SOMS Design discussion previously presented in this section.

The EDS design team uses tools and technologies to increase productivity, improve communication with CDCR, and facilitate proper documentation and linkages between the various functional design work products that we produce. These tools include design modeling tools that allow EDS to generate Unified Modeling Language (UML) models, Entity Relationship Diagrams (ERD) that allow us to design our data persistence structures, and decision tables that capture business rules, storyboards, performance models, and simulation. The toolset we are proposing is listed in the Third-Party Software and Hardware list of this response. Given our knowledge of similar eligibility systems, such as the UK Her Majesty’s Prison Service and CalWIN, EDS understands the requirements and can translate them to a functional design that meets CDCR’s needs while providing in-depth expertise on best practices based on our proven results. Our final



functional design incorporates federal, state, and local laws, regulations, and guidelines applicable at the time, plus CDCR’s existing business logic where applicable. This allows us to provide SOMS functional design details that include the following:

Component structure and capability – The subsystems that make up the solution and the physical structure of the software implementation

User interface design – User-friendly and ease-of-use features

Business rules – Compliant with policy requirements

Logical data model – How the architecture supports the business requirements

Security design – Fully compatible with the CDCR security model

Use cases – Help identify architectural elements, validate the architecture, and illustrate the architecture

Interfaces – Requirements for an external system to interface to the SOMS

Requirements traceability – Used to communicate how each requirement is satisfied in the design as detailed in the SOMS Requirements Verification and Traceability portion of this section of our proposal.

Detailed Design Document (DDD)

Using the OCE Evolve Architecture process EDS develops the Detailed Design Document (DDD) to capture the system capabilities. The DDD documents the details of the Baseline Application Software functional specifications. We identify the SOMS functional design, and this document encompasses the deliverable standards. The DDD includes the following descriptors for the functional level of the SOMS:

High-level design summary

Component detailed design

User interface

Baseline application software design and logical data model

Security design

Formulas and algorithms not found in the SRD

Use cases and scenarios

SRD interfaces

Updated requirements traceability matrix



Baseline Application Software and Conversion and Archiving Tools

In previous sections of this System Design and Development Approach, we described our approach to the SOMS design and have provided details on the various design tasks including General Design, Technical Infrastructure Planning a Design, Functional Design, and Technical Infrastructure Deployment using the generated work products

We now move on to focus on our development approach — detailing our strategy for software components and modules production, unit testing, interface development, reviews, and release management.

In doing so, Team EDS applies the development-related processes of the EDS OCE software development work type introduced in the Development Methodology and Technical Practices portion of this section. These processes are used to develop the baseline application software and conversion and archiving tools. Table 6.4-6, Development-related OCE Processes highlights the key OCE processes and the associated core focus.



Table 6.4-6 Development-related OCE Processes


Define Define project plan—improve project control environment

Refine configuration management (CM) plan

Set up CM tool

Establish CM library for baseline

Define project plan—adjust project approach to risk:

Refine high-level risk assessment

Identify, document, and categorize risks

Assess and prioritize risks

Create risk assessment/handling plan

Apply risk plan to other project plan components


Establish development view—create initial development strategies

Develop performance strategy

Develop initial test plan strategy

Create initial data conversion strategy

Create initial development plans (develop data conversion plan)

Identify development standards

Review conformance of development view


Evolve logical view—produce application software:

Produce component interfaces

Produce user interface layer

Produce persistency layer

Produce business objects

Review conformance of application software

Perform unit testing

Evolve development view

Evolve testing specifications

Review conformance of testing specifications

Refine development standards/strategies

Review conformance of development standards/strategies

Evolve physical view—produce transition components

Produce migration/conversion utilities

Produce transition aids and communications




Document system configuration

Test transition components

Review conformance of transition components

Evolve architecture—integrate system components

Integrate automated components

Incorporate non-automated components

Perform integration testing

Perform usability testing

Review conformance of prototype with client

Optimize Release Plan/prepare for optimize release

Development environment, system standard, and procedures and metrics repository

Optimize system performance

Evaluate system outputs/performance and tune the system

Obtain formal acceptance

Package system deliverables

Conduct formal acceptance testing

Gain final approval for system implementation

Implement Release Install release

Establish production environment

Install application data/data structures

Install application software

Install business organization components

Accept production installation

Manage Exercise project control—conduct conformance reviews

Prepare and distribute materials for review

Conduct conformance review meeting


Collect and update progress data

Evaluate performance to schedule and take corrective action

These OCE development processes include comprehensive sub-processes and work elements for performing development, conversion, and unit testing. The OCE Establish Architecture and Evolve Architecture processes are detailed in the SOMS Design portion of this section. We perform software testing using the EDS



Enterprise Testing Method (ETM), which incorporates specific testing best practices, standards, and procedures. The ETM is further detailed in Section 6.5 Testing portion of this response.

The Optimize Release and Implement Release processes are detailed below.

Optimize Release

The Optimize Release process begins after iterative development produces a complete, integrated release and the release has been verified as meeting the requirements. The focus of the Optimize phase is to tune the release for better performance, package it for delivery, and obtain implementation approval through formal acceptance testing.

Plan and Prepare for Optimize Release – A work plan for Optimize Release is developed to refine the technical and organizational project environment, including the methods, tools, standards, and procedures that support configuration, financial, metrics, and quality assurance management.

– Work Elements Performed – Develop and Update Work Plan, Prepare Project Team and Affected Groups, and Establish Environment

– Affected Work Products – Key work products are affected during execution of this sub-process: Development Environment, System Standard and Procedures, and Metrics Repository

Optimize System Performance – To test, monitor, and improve the system performance. Changes are made to reduce resource usage and response time as much as is cost-effective.

– Work Elements Performed – Evaluate System Outputs and Performance and Tune the System

– Affected Work Products – Key work products are affected during the execution of this sub-process: Architecture and System Monitoring Reports

Obtain Formal Acceptance – To obtain client approval for implementing the release. Formal test plans are developed and executed to verify the release's compliance with defined business acceptance criteria and the baseline requirements.

– Work Elements Performed – Package System Deliverables, Conduct Formal Acceptance Testing, and Gain Final Approval for System Implementation

– Affected Work Products – Key work products are affected during the execution of this sub-process: Implementation Plan, Architecture, Formal Acceptance Test Specifications, Test Plan, and Implementation Approval.



Implement Release

The Implement Release OCE process is used to complete the successful delivery of system updates within a release to a fully operational user environment in accordance with the project plan and requirements. This process is concerned with installing the components of the application in the production environment, testing that the application has installed properly, training users and support personnel, and providing required start-up support. Releases are targeted to several different operational environments during the system development life cycle that range from development to production environments. Figure 6.4-11, Release Implementation Key Sub-Processes illustrates the key sub-processes and work elements performed during the Implement Release process.

I nstall Application Software

Install Application Data

Install Production Environment

Install Business Organization Components

Conduct Release Testing

Monitor Production Application

Turn Over Release

Perform Release Testing

Obtain Production Installation Acceptance

Required

Conditional based on defined criteria

Figure 6.4-11, Release Implementation Key Sub-Processes

This process completes the successful delivery of updates to a user environment.

The following is a description of these sub-processes and work elements:

Install Release – Provides an updated production system based on the release contents while following the implementation plan to establish, configure, and install required software and data



Work Elements Performed – Details about some of these work elements follow:

– Establish Production Environment – EDS establishes the production environment in accordance with the technical architecture specifications and the implementation plans. This effort involves coordinating CDCR production site personnel, EDS SOMS staff, and other EDS data centers personnel.

– Install Application Data – EDS installs the application data and data structures into the production environment in accordance with the implementation plans. This includes allocating production files and databases, converting data from the current system using the conversion components created, and loading data into the new production files and databases. After thorough verification of the data, as directed by the implementation plans, EDS backs up the application data for reloading after the application is installed and tested. Additionally, we document the results of the database installation.

– Install Application Software – EDS installs the application software components to the production environment in accordance with application design specifications and implementation plans. This includes installing program source components, as well as executable and other components, into the controlled production environment and is performed according to established promotion procedures. If this is the initial installation of the application, EDS verifies the application software and data structures, and back them up to provide a baseline image of the application.

– Install Business Organization Components – As needed, EDS installs documentation, organization, and training components according to business organization designs and the conversion strategies.

– Perform Release Testing – As specified in the test plans, EDS works with CDCR user acceptance test (UAT) team to perform the test cases needed to validate that key application functions perform appropriately in the production environment. EDS obtains CDCR sign-off through established sign-off procedures.

– Obtain Production Installation Acceptance – After every portion of the system is installed and verified in the production environment, EDS works with CDCR to confirm that the installation is successful and that every aspect of the implementation was completed as planned. Based on the results of the installations, CDCR and EDS collaborates to decide either to activate the installed system or to execute the contingency considerations of the implementation plan.

– Affected Work Products – These key work products are affected during execution of these sub-processes: Platform Installation Plan, Technical Environment, Database Installation Plan, Execution Scripts, Physical View, and Use Case Model.



Conduct Release Training – EDS conducts training in accordance with the approved training plan. Training is conducted using a separate environment and scheduled in parallel with other implementation activities.

Provide Post-installation Support – To monitor and verify the initial cycles of the updated system. The operations and administration staff are trained to support the system.

Work Elements Performed – Support System Start-Up, Monitor Production System, Baseline Application Portfolio Management Metrics, Turn System Over, and Support Restabilization. Details about some of these work elements follow:

– Monitor Production Application – EDS monitors the system to determine functions operate as CDCR expects, meeting expected performance levels. We collect and store post-release defects discovered during the warranty period and baseline appropriate measurement data.

– Turn Over Release – Following successful implementation, the system release is turned over to the SOMS maintenance and operations team, who implement the production support plan. The EDS development team communicates known errors and workarounds to those on the production support team.

– Affected Work Products – These key work products are affected during the execution of sub-processes: Implementation Plan, Application Portfolio Management Metrics, System Monitoring Report, User Guide, Operations/Administrative Guide, and Technical Support Guide.

During the Baseline Application Software and Conversion and Archiving Tools task, EDS designs, develops, tests, and validates the Baseline Application Software components and modules and the conversion and archiving software programs/tools. Our work product deliverables include the application and the utilities developed for reporting, interfaces, and conversion and archiving of legacy systems data, and other legacy data.

Prepare Baseline Application Software Development Plan

Adhering to EDS’ software development methodology and using the associated development tools allow us to specify, design, develop, test, and validate the SOMS Baseline Application Software components/modules with conversion and archiving software tools. Included are the utilities developed for reporting, interfaces, and conversion and archiving of CDCR systems data. Team EDS uses the Conversion and Archiving Plans, and Detailed Design Document (DDD), as the basis for our development efforts after receiving approval from CDCR.

The Software Development Plan (SDP) is discussed in our response to Requirement M-36 below.



Document SOMS Application Software SDLC Standards

The Establish Development View sub-process of Establish Architecture focuses on software policies, guidelines, standards, and strategies that include configuration, customization, testing and are used for the SOMS project. Existing standards and policies are used when possible. Figure 6.4-12, Establish Development View Sub-Process shows the main work elements of the Establish Development View sub-process, and each step is further discussed in the following text.

Create Initial Development

Strategies

Create Initial Development Plan

Identity Development

Standards

Define Persistency Approach

Review Conformance of

Development View

Figure 6.4-12, Establish Development View Sub-Process

This sub-process focuses on policies, guidelines, standards, and strategies.

The following are descriptions of each work element:

Create initial development strategies – During this activity, we are concerned with developing the strategies that have a direct effect on the development approach. Specifically, this includes the strategy for migration of technology from existing CDCR legacy systems to SOMS.

Create initial development plans – The development plans describe the approaches for areas that directly affect the design of the SOMS solution. This includes issues relating to configuration, customization, deployment, reuse, migration, and conversion. The result of this work element is the initial plan to address each of these issues.

Identify development standards – This work element focuses on identifying and defining the standards required for supporting SOMS development activities. Once the standards are in place, it is essential to make certain that the standards are enforced.

Review conformance of development view – After the development view has been established, a conformance review is conducted. This review assists with verifying the essential needs of the development view and areas to be addressed during application development that have been identified during architecture establishment. This enables Team EDS to develop a system that satisfies CDCR requirements.

Build Baseline Application Software Components/Modules and Conversion and Archiving Software Programs/Tools

Team EDS develops preliminary documentation for baseline application software components and modules and conversion and archiving software tools. This documentation includes “solved example problems” that also serves as test cases to help identify and isolate defects. Developers create a set of example



problems or a tutorial that cover the core functions of each baseline application software component or module and conversion and archiving software tools. Through the iterative process of the Produce Software Application work element, these examples and the developer’s own test cases help to identify and isolate defects earlier in the development process when they are less costly to correct.

The user documentation accompanying the examples or tutorial describes the input that the user is expected to enter, as well as the expected output of the software in response to the specified input. Step-by-step instructions are included that fully describe the actions that the user must take in running each example. Additionally, screen shots will be included as necessary to help supplement the user documentation.

Evolve Logical View/Produce Application Software

During Evolve Architecture, Team EDS executes the Produce Application Software sub-process of the OCE, developing the source and object code for the SOMS baseline application software components, modules, and conversion and archiving software program and tools in conformance with Detailed Design Document (DDD) and SOMS Application Software SDLC Standards.

Applying the iterative OCE development approach to the Evolve Logical View sub-process, EDS reviews the code after each of the iteration looking for places to “refactor” and improve the code to accommodate future iterations and enhancements to the SOMS and to make the system more maintainable. Each component or module is individually unit tested to make certain that it performs the required functions in accordance to design specification and development standards.

Figure 6.4-13, Produce Application Software Sub-Process shows the main work elements of the Produce Application Software sub-process.

Produce Component Interfaces

Produce User Interface

Layer

Produce Persistency

Layer

Produce Business Objects

Review Conformance of Application

Software

Perform Unit Testing

Figure 6.4-13, Produce Application Software Sub-Process

Each work element within the Produce Application Software Component sub-process is carefully tested.

The following are descriptions of each work element:

Produce component interfaces – The SOMS component interfaces are coded according to the specified design. Suitable implementations are acquired for components identified reused objects.

Produce user interface layer – The SOMS user interface is configured and customized in the chosen user interface language and environment.



Produce persistency layer – The SOMS persistency layer is coded to support the system efficiently interfacing with the database(s).

Produce business objects – The SOMS business objects are coded in accordance with the specified design.

Review conformance of application software – A review of the application software is conducted with the SOMS project team to verify that the “as written” SOMS application code satisfies CDCR’s requirements.

Perform unit testing – Tests are carried out on the designated “units.” The main purpose of unit testing is to identify low-level defects in the SOMS implementation classes. Using the prepared test plan and test data with the strategy, Team EDS executes the tests and document the results. If any problems are identified, they are rectified as quickly as possible and the tests are re-run.

Baseline Application Software Components/Modules and Conversion and Archiving Software Programs/Tools

This process is executed for each identified release, and includes:

Object code and source

Associated documentation

Additional information used to support unit test, validation, and quality assurance activities

The resulting baseline application software component or module and conversion and archiving software program and tools are placed in the SOMS repository and the appropriate access permissions and configuration management rules are applied.

M-35 The Contractor must utilize the change request process and tools described below, and garner the approval of CDCR:

All change requests cost estimates must include the use of a Cost Analysis tool, such as Cost Expert and reference to the rates in the Unanticipated Tasks cost worksheet in Section VII - Cost

N/A


A well-defined change request and control process sets the standard for business improvement initiatives and identifies the checkpoints that enable CDCR to endorse progress and approve the continuation, postponement, or stopping of an initiative that does not meet predetermined standards. Change control encompasses both the identification and the tracking of normal modifications and enhancements to SOMS, as well as changes to the scope of requirements agreed upon between CDCR and EDS for a new project. The change control



process relies on a Change Control Board (CCB), which EDS works with CDCR to establish, consisting of CDCR and EDS’ leaders with authority for decision-making. The CCB maintains responsibility for evaluating, approving, and prioritizing change orders.

The outline process for handling change requests is as follows:



Table 6.4-7, Outline Process for Change Requests

Process

Step.Activity Responsibility

1. Receive and Assign Change Request

Receive the change request. Validate that the change request is complete and unambiguous (check for who, what, where, when and why). Return requests to the submitter for clarification as needed. Send each change request received to the functional area responsible for addressing the change. Ensure that where a change may cover multiple functional areas, the request is sent to all stakeholders

Configuration Management SME

2. Provide Business Impacts

Analyze the change request and provide business impact information that can be used to ensure that the change request can be acted on appropriately. Business impact typically encompasses the estimated time, cost, resources needed and effort to realize the change as well as identifies any touch points with other portions of the environment, i.e. other functional areas. Understand current industry methods and trends in relationship to the requested change and ensure that the impact of the change is in line with organizational goals, objectives and strategies

Subject Matter Expert , Change Control Board

3. Disposition Change Requests

Using any business impact information provided, prioritize the change request in relationship to existing change requests and activities. Assign a disposition (accepted, targeted for release, rejected, pending clarification, etc.) for the change request. If the change request status changed, notify the submitter of the new status.

Change Control Board, Subject Matter Expert

4. Assign Change Request to be Actioned

Send the change request documentation to the parties responsible for making the changes. The approved change requests authorize the parties responsible for making the changes to check out the impacted configuration items.

Subject Matter Expert, Change Control Board, Configuration Management SME

5. Approve Release Plan

Review the proposed actions to ensure that the requested changes are being addressed. Validate that there are no unapproved changes associated with the release. Approve the proposed release documentation prior to it being acted on.

Subject Matter Expert, Change Control Board

6. Approve Completed Changes

Ensure that all configuration items have been checked in. Approve the changes in the appropriate pre-production environment and follow procedures to ensure that the applied changes are implemented and deployed in the production baseline environment. Once the changes are completed and approved, close the change request(s) and notify the submitter(s) of the status. Track the status of all other change requests to closure.

Subject Matter Expert, Change Control Board, Configuration Management SME



System Engineering Estimating

Accurate estimates are critical to a project's success. Improving project estimates result in improved project planning, scheduling, and costing, as well as resource allocation, contract pricing, and client satisfaction. Valid estimates increase the number of projects completed on time and on budget, which is favorably reflected in the service performance index. Successful application development and management depends on accurate and reliable project estimating. EDS Systems Engineering Estimating is founded on the following three principles:

Apply the appropriate amount of resources to create and refine an estimate.

Develop alternative scenarios to provide the most effective mix of resources based on given constraints, assumptions, and risk tolerance.

Improve the estimate using current information throughout the project.

EDS Metrics and Estimating Centers

EDS has established Metrics and Estimating Centers (MECs) in the United States, Europe, and Asia Pacific. These EDS central support centers provide professional software project estimating assistance to EDS projects. Additionally, the centers offer assistance with establishing productivity baselines and competitive analysis, project tracking and control, and awareness education to EDS clients, leaders, and teams. The MECs software estimation modeling tool is Software Life Cycle Management (SLiM).

Software Life Cycle Management

SLiM® is a tool that can be used to assist in the development of estimates based on past projects’ actual performance. EDS uses SLiM® to assist in developing “what if” and alternative solution analyses based on project constraints and to provide analysis of the risk involved with different scenarios. Quantitative Software Management’s (QSM’s) SLiM® model is based on the actual behavior patterns of thousands of software development projects. QSM’s database consists of more than 20 years of projects, including all types of applications, platforms, and programming languages. When using SLiM®, EDS supplements QSM’s database with the historical information from EDS projects to create a historical repository of more than 3,000 projects. As EDS adds new projects to the repository, we remove old projects, keeping the size to around 3,000 so that we base analyses on recent history. Figure 6.4-14, SLiM® Estimating Process, depicts the SLiM® components and how they work.



“What if” Scenarios

I nput• Sizing• Constraints• Assessment for

Productivity– Technical

Complexity– Tools / Methods– Personnel

HistoricalData

SLiM

Estimating Tool

Figure 6.4-14, SLiM® Estimating Process

Business Benefits

The impact of the estimating process, the tools, and metrics information is potentially substantial, comprising the following:

Avoids impossible solutions.

Increases confidence and satisfaction for SOMS

Increases employee confidence and satisfaction

Identifies and helps avoid risk factors

Explores alternative solutions.

Process Approach

The estimating process at EDS is comprised of the following steps:

Plan for estimate.

Determine project size.

Develop project estimates.

Create a bottom-up estimate based on the project Work Breakdown Structure (WBS).



Create a top-down estimate using tools that examine the whole project.

Obtain historical data on projects with similar characteristics.

Reconcile differences and create multiple scenarios.

Assemble documentation, including schedule and resource plan.

Review the estimate with stakeholders.

The Systems Engineering Estimating process steps are depicted in Figure 6.4-15, EDS Systems Engineering Estimating.

Plan for Estimate

Determine Project Size

Develop Project Estimates

Reconcile Differences

Assemble Estimating

Documentation Package

Review Estimate with Stakeholders

Figure 6.4-15, EDS Systems Engineering Estimating

Although EDS developed this process for estimating system engineering projects at the highest level, the six-step process may be applied to non-system engineering projects as well.

The strength of the EDS estimating process is focused on the creation of at least two estimates, using the most appropriate type of estimating technique, which we then reconcile. The two most common approaches used to provide these estimates are known as “bottom-up” and “top-down” estimates.

Bottom-up Estimate

The bottom-up approach uses a project plan Work Breakdown Structure (WBS) to develop a task-by-task estimate using the best available historical information. The project plan is used as the basis for estimating project effort and duration. The developers on the team create the estimate, using the following steps:



Confirm development tool(s)

Gather relevant historical information for the development tool(s)

Create tables based on the best available information (if no historical information exists)

Create a WBS if none exists

Develop individual WBS (task) estimates

Consolidate WBS estimates

Document the skill sets that the development team understood in generating the estimates.

Top-down Estimate

The second estimate is a Tool-Based Estimate (also known as a top-down estimate). EDS uses a software-estimating tool called SLiM® for our Tool-Based Estimates. Inputs include aspects about the project, such as function points, lines of code, or staff size. SLiM® produces a complete project estimate based on industry-wide projects in its database. After EDS creates the SLiM® estimate, we compare the estimate to EDS’ historical projects by using statistical control charts. The control charts illustrate how the SLiM® estimate compares to historical EDS projects. EDS revises projects that fall outside the control limits to match EDS’ capabilities.

Other types of estimating techniques sometimes used are as follows:

Analogous Estimate

Drawing from the collective experience of Team EDS with other similar systems, we use Analogous estimating methods to provide estimates as defined by the Project Management Institute (PMI) Project Management Body Of Knowledge (PMBOK®). With Analogous estimating Team EDS uses the actual time frame from our team’s previous, similar project implementations as the basis for estimating the time frame for the SOMS project.

Parametric Estimate

The Parametric estimating technique uses a statistic relationship between historical data and other variables, for example, function points or lines of code, to calculate and validate the schedule and level of effort necessary to complete system development, system qualification testing, and maintain the system once in production operation. To accomplish this, EDS employs Borland CaliberRM® ESTIMATE Professional®, which implements the SLiM® and Constructive Cost Model (COCOMO).0 estimating tools. Using function points as the estimating basis, EDS chose the SLiM® model (a component of Caliber RM® ESTIMATE) for estimating and validating the SOMS schedule and



level of effort necessary to support the system development process and maintenance of the production software.

Next, EDS reconciles these estimates into one estimate for the software and produces a rough estimate of staff requirements and project duration. During the reconciliation process, the estimating team concentrates on the risks and assumptions identified for the estimate. After it is reconciled, Team EDS prepares the estimating documentation package for review.

Monte Carlo Analysis

Team EDS additionally uses Borland CaliberRM® ESTIMATE Professional® to conduct a Monte Carlo Analysis, a technique that defines a distribution of probable results for each activity and calculates the distribution of probable results for the entire project. EDS uses the Monte Carlo Analysis to model project interactions, when necessary, in complex situations or when estimates were made based on a large number of assumptions or risks. ESTIMATE Professional can simulate hundreds to thousands of possible outcomes based on size, productivity, current project phase, and other parameters entered by the estimator. It then estimates the likelihood of various project outcomes and assigns risk levels to different planning options. In complex situations with many possible outcomes, ESTIMATE Professional can create meaningful estimates that would otherwise be impossible to model.

6.4.B Design & Development Plan Requirements

VI.D.7.a. Design & Development Plan Requirements

Req.Num.


M-36 The Contractor shall incorporate the design and development approach into a comprehensive Design and Development Plan (Software Development Plan) complying with IEEE 12207.2, section 5.3.3 - system architectural design.

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

Vol 1 – Appendices

Appendix I


In our response to Requirement M-34 above, we outline the importance and positioning of the Design and Development Plan (Software Development Plan) as part of our SDLC. This plan is a compilation of many of our other plans addressed throughout this proposal. EDS integrates and compiles the information from the appropriate references to develop the Software Development Plan (SDP). Table 6.4-8, Sample Design and Development Plan outlines each of the SDP components, the requirements description of each, and where these plans are referenced.



The State desires to leverage IEEE Standards for Information Technology, Project Management, and User Documentation for the SOMS project. EDS fully understands the State’s objectives, and Team EDS uses the full suite of EDS’ best practices for the design, development, test, implementation, and operation of the SOMS system. Team EDS produces artifacts that are in compliance with IEEE 12207-1996 and IEEE 1058-1998 as required by the State. The artifacts are prepared using the methodologies, processes and templates identified in Table 6.4-8, Sample Design and Development Plan.

We have included a sample Design and Development Plan from California Personal Care Services Program/In-Home Supportive Services (IHSS) Plus Waiver/IHSS Residual (PCSP/IPW/IHSS-R) project in Appendix I of our response. In this case the Design and Development Plan is part of the overall Project Management Plan (PMP). Hence it is the PMP we have provided.

Table 6.4-8, Sample Design and Development Plan

SDP Component Requirements Prime References

Project Organization Software Roles/Responsibilities defined

Manage/Control procedures for application development

Tracking/reporting progress procedures

Project Management Plan

Project assumptions and potential risks

Document key assumptions, risks, and plans for migration

Track assumptions and potential risks biweekly

Project Management Plan

Quality Management Plan

Schedule Provide detailed plan Project Schedule

Configuration Management

Describe how multiple development builds of the Baseline Application Software are tracked to avoid confusion

Software Configuration Management Plan and System

Release Control Describe criteria for releasing Baseline Application Software and how the Baseline Application Software meets requirements (validation) and works properly (verification)

Pre-production and Production Release Plans

Pre-implementation Readiness Assessment

Implementation Plan

Test Process Describe the methodology for testing the Baseline Application Software

System and Software Test Plan

Deficiency Tracking Describe how we track and resolve Baseline Application Software Deficiencies

Problem Resolution Management Plan



SDP Component Requirements Prime References

Test Strategy—Testing Approach

Describe approach for planning and executing testing, both incrementally during development and for the entire product before delivery to CDCR

Describe test objectives and responsibilities for the testing levels

Describe the scope and guiding principles for the testing effort

Describe the proposed policy for resolving conflicts that arise during the testing process


Test Strategy—Testing tasks to be performed

Describe how each major group of software features will be tested and the major testing activities, techniques, and testing tools to be used

Include configuration of the SOMS test environment

Propose the responsible individuals or organizations and its responsibilities

Document the general rules for software acceptance


Technical Infrastructure Description

Testing Tools, Test Configurations, and Related Documentation

Test Strategy—Testing Schedule

Include proposed tasks and major testing milestones and integrate dates with the Project Work Plan schedule


Project Schedule

6.4.C General Development Requirements

VI.D.7.b.General Development Requirements

Req.Num.


M-37 The Contractor shall follow industry standards for all development work, including database naming and usage.

N/A


Team EDS follows industry standards for development work. We work with CDCR to define and agree on the standards to be adopted and document these agreements in the Technical Architecture and Software Development Plan, as appropriate.



Our commitment will be in-line with EDS’ strategic objectives with respect to industry standards.

Participation – Participate in the development and adoption of standards to achieve business value for EDS and our clients.

Compliance – Make certain compliant with selected standards in EDS infrastructure, solutions and services.

Industry Leadership – Gain recognition for industry leadership in the development of standards

Alignment with Business Partners – Join with alliance partners, vendors and clients to drive the development and acceptance of industry standards.

Industry standards specific to the development of SOMS may include:

Technical standards – Standards for interfaces between system components (hardware or software) including protocols and exchanged data.

Best practices standards – processes, metrics, techniques or disciplines for certain business functions or administration.

Government regulations – Legal requirements imposed by governments on business practices or use of technology.

Table 6.4-9, Software Engineering Standards, is a high-level table of contents for the SOMS Software Engineering Standards.

Table 6.4-9, Software Engineering StandardsSoftware Engineering Standards

1.0 INTRODUCTION1.1 Audience1.2 Related documents1.3 Purpose1.4 Scope1.5 The evolution and application of the standards

2.0 TECHNIQUE STANDARDS2.1 Application design techniques

2.1.1 General considerations2.1.2 Data currency2.1.3 Edit at the source2.1.4 Interfaces2.1.5 Output2.1.6 Security2.1.7 Transactions2.1.8 Usability 2.1.9 Decision table modeling



Software Engineering Standards 2.1.10 Memory management 2.1.12 Code reusability2.1.13 Variable Initialization2.1.14 Application Object Naming

2.2 Database design techniques2.2.1 Database normalization2.2.2 Database de-normalization

2.3 Design sessions and requirements determination techniques

2.3.1 Facilitated sessions2.3.2 Requirements determination techniques2.3.3 General systems design techniques2.3.4 Detailed system design techniques

2.4 Quality control (QC) review techniques2.4.1 Release review checklist2.4.2 Configuration management checklists2.4.3 Code Walkthrough/peer review checklist

2.5 Technical review techniques2.5.1 Technology specific checklists

2.6 Testing techniques2.6.1 White-box/unit testing2.6.2 Black-box/integration testing2.6.3 System testing2.6.4 Regression testing2.6.5 Performance testing

3.0 WORK PRODUCT STANDARDS3.1 Activity diagram standards3.2 Business logic diagram standards3.3 Class diagram standards3.4 Customer view standards3.5 Data flow diagram standards3.6 Data model standards

3.6.1 Logical data model3.6.2 Physical database model

3.7 Decision table standards3.8 Functional decomposition diagram3.9 Functional structure charts standards3.10 Interface impact standards3.11 Job stream dependency list standards3.12 Job stream diagrams standards3.13 Physical process model standards3.14 Program specifications standard



Software Engineering Standards 3.14.1 Program specifications example/template3.14.2 Service program specifications example/template

3.15 Requirements3.16 Test plans standards

3.16.1 Unit test plan standards3.16.2 System test plan standards3.16.3 Performance test plan3.16.4 User acceptance test plan

3.17 Test verification documentation standards3.18 Use case standards3.19 User interface standards3.20 Technology-specific construction standards

3.20.1 General3.20.2 ASP coding standards3.20.3 Business objects coding standards3.20.4 C coding standards3.20.5 Cobol coding standards3.20.6 Error handling3.20.7 Html coding standards3.20.8 Java coding standards3.20.9 Method modification log3.20.10 Java script coding standards3.20.11 JSP coding standards3.20.12 SQL coding standards3.20.13 XML/XSL coding standards3.20.14 Operating systems standards3.20.15 Application and system configuration file standard3.20.16 Reference table coding and usage standard

3.21 Service delivery request standard4.0 GLOSSARY/TERMINOLOGY STANDARDS5.0 BIBLIOGRAPHY

M-38 The Contractor shall provide CDCR access to the software components and documentation.

N/A




Team EDS provides CDCR with access to all software components and documents specified as project deliverables in the project plan in accordance with project governance procedures. We deploy a Microsoft SharePoint project document repository to which both authorized CDCR and Team EDS staff will have access.

M-39 The Contractor may not use CDCR production system resources (data or source files), or data derived from the production system resources, off-site without authorization from CDCR.

N/A


Team EDS fully understands the need for absolute integrity and care in regard to sensitive production systems data and resources. We fully comply with CDCR security and privacy policies and procedures, including the requirement for prior authorization for off-site use of CDCR production system resources or data derived from production system resources.

6.4.D Design & Development Plan Requirements

VI.D.7.c. Legacy Software Modification Requirements

Req.Num.


M-40 The Contractor shall be responsible for leading and coordinating the review of legacy software and the extraction of business rules.


Team EDS takes responsibility for leading and coordinating the review of legacy software and the extraction of business rules. We have an established and proven approach to applications modernization, incorporating an ‘Applications Relearn’ capability that we use as the basis for activities with CDCR. Relearn is a discovery process that captures the intellectual property investment that has been made in legacy applications over many years, and enables that investment to be preserved and carried forward through modernization.

The benefits of Relearn are:

Accurately document AS–IS state of IT assets/applications.

Discover active application component elements & their characteristics using select tools (where these are available for the type of legacy system platforms in place to analyze the system components, including data.



Isolate business knowledge (business logic & business rules) for reuse.

Preserve business value of legacy assets and retains intellectual capital.

Reduce time required for modernization, projects.

Promote business understanding of technical implementations.

Figure 6.4-16, Re-Learn Process Context Diagram below illustrates the overall process context for the Relearn activities. Note that Relearn is an existing systems development lifecycle Work Type, as described in our response to requirements M-33 and M34 above.

Inputs into the process include source code, screen definitions, database schemas, file structures, interface definitions, job control language and any existing documentation.

Source CodeConfiguration

DocumentationLog FilesJ ob Flows

Application ModelsBusiness Rules

Repository

Application Understanding & Documentation

Capability or work around

Languages and

database supported

Work with tool vendors and

service providers

Client:

• Source code

• Subprograms/subroutines

• Screen systems

• Transaction systems

• J CL

• Databases and data files

• Legacy documentation

Adapt Re-learn process

System Management Environment

Step 4

Analysis

Identify Batch Function Excludes

Infrastructure Architecture

Security Environment

Development Environment Architecture

Testing Environment Architecture

Information Architecture

Application Architecture

Presentation Architecture

Assess Application Characteristics

Non-Functional Requirements

Perform Business Rule Mining

Prepare for Data Profiling

Create UML Diagrams

Analyze Metadata Validate Physical Inventory

Identify Batch Code Excludes

Identify Interactive Code Excludes

Identify Interactive Function Excludes

Resolve Code Issues

Inventory Application Code

Collect Application Artifacts

Step 5

Integrate Rel-earn Findings

Step 3

Document Physical Inventory

Step 2

Excludes

Step 1

Establish Inventory

Step 0

Refine Scope

Define Application Context

Define Business Context

Initialize Re-learn Engagement

Establish Re-learn Goals

Define Technology Context

Collect Business Functions

Collect Data Artifacts Validate Business Rule Findings

Validate Data Findings

Validate UML Diagrams

Obtain Approval

EDS ProcessInputOutput

Figure 6.4-16, Re-Learn Process Context Diagram

From our understanding of CDCR legacy estate, we know that our processes and toolsets already support the programming languages in use, for example, Adabas and Natural. For other systems EDS rapidly adapts the process or work with legacy tool vendors to automate as much as possible of the process. Where this is not viable, more manually-oriented discovery activities are utilized. Nevertheless the ReLearn process remains valid and valuable.



The following illustration, Figure 6.4-17, Re-learn Process Outline, depicts the process that EDS follow. It is anticipated that an iterative and incremental approach is adopted, in line with the core SOMS phasing plan.

System Management Environment

Step 4

Analysis

Identify Batch Function Excludes

Infrastructure Architecture

Security Environment

Development Environment Architecture

Testing Environment Architecture

Information Architecture

Application Architecture

Presentation Architecture

Assess Application Characteristics

Non-Functional Requirements

Perform Business Rule Mining

Prepare for Data Profiling

Create UML Diagrams

Analyze Metadata Validate Physical Inventory

Identify Batch Code Excludes

Identify Interactive Code Excludes

Identify Interactive Function Excludes

Resolve Code Issues

Inventory Application Code

Collect Application Artifacts

Step 5

Integrate Relearn Findings

Step 3

Document Physical Inventory

Step 2

Excludes

Step 1

Establish Inventory

Step 0

Refine Scope

Define Application Context

Define Business Context

Initialize Re-learn Engagement

Establish Re-learn Goals

Define Technology Context

Collect Business Functions

Collect Data Artifacts Validate Business Rule Findings

Validate Data Findings

Validate UML Diagrams

Obtain Approval

Figure 6.4-17, Re-learn Process Outline

Outputs from the process can include:

“AS–IS” state fully documented

Universal Modeling Language (UML) Diagrams

Business logic and business rules for reuse

Understanding of application data

Reduced time required for modernization, projects

Improved business understanding of technical implementations

Understanding of application relationship with other systems.



M-41 All extracted business rules will be subject to the review and approval of CDCR.

N/A


Client approval for findings from business rule extraction is always sought, as shown in the final step (step 5) of our process structure illustrated in Figure 6.4-17, Re-learn Process Outline, above.

M-42 The following constraints are placed on the modifications made to legacy software:

All modifications to CDCR legacy code will be developed, tested, and deployed by the State.

The staging of legacy code changes resulting from the State will be managed by the State.

The impact of migration of SOMS business logic to the new technology on CDCR legacy applications will be determined by the State.

The State will work with the Contractor to coordinate the testing of modified CDCR legacy code.

Model/dictionary/and or format of CDCR legacy data, including field length, type, description, and relationships to other data will be provided by the State.

N/A


Team EDS understands the constraints put forward by CDCR and will work to these. The coordination of new SOMS developments and legacy modifications is clearly an area where close coordination is required across planning, development, testing, and change and release management. EDS works collaboratively and openly with CDCR in all such respects.


DOC

Documents

industriesthat eds

eds methodologiesand

eds bestpracticelibrary

eds sdlc experts

eds process sourcerer

development plan

box development

project startup stage