DOC

1,327 views
1,244 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,327
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DOC

  1. 1. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT 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. Requirement Response / Reference Num. M-33 CDCR utilizes a structured SDLC that is consistent with industry- Section 6.1 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. 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
  2. 2. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE • 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 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 EXHIBIT I-146 EDS SOMS STATEMENT OF WORK
  3. 3. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Implementation System Approval Optimize Implement Business Organization Business Need Components Definition START Application Solution Definition Software/Data Produce Define Technical Plan/Test Project Plan Environment Design Analyze Requirements Technical Documentation Specifications System Design Logical System Specifications Specifications Manage 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 validate intermediate results EDS SOMS STATEMENT OF WORK EXHIBIT I-147
  4. 4. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 Section 6.3, approach and methodology used for the SOMS Project. Section 6.5 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. Bidder Response Detail: 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 EXHIBIT I-148 EDS SOMS STATEMENT OF WORK
  5. 5. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-149
  6. 6. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Iterative Phases Plan/ Prepare Plan/ Prepare for Iteration for Iteration Evolve Architecture Com m it Iteration Results Optim ize Last Release 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. EXHIBIT I-150 EDS SOMS STATEMENT OF WORK
  7. 7. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Project Plan Architecture Release/Iteration Approach Iterative High-Level Requirements Phases Plan/ Development Prepare for Environment Establish Define Architecture Iteration OO Mentor Business Need Definition Evolve Architecture Architecture Technical Launch Findings Commit Iteration Results Implementation Approval Optimize Last Project Plan Release Iteration? Yes No Architecture No Implement Last Close-Down Release Release? Yes Manage 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-151
  8. 8. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. EXHIBIT I-152 EDS SOMS STATEMENT OF WORK
  9. 9. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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- EDS SOMS STATEMENT OF WORK EXHIBIT I-153
  10. 10. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 EXHIBIT I-154 EDS SOMS STATEMENT OF WORK
  11. 11. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 through the 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-155
  12. 12. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Component Purpose 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 EXHIBIT I-156 EDS SOMS STATEMENT OF WORK
  13. 13. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 EDS SOMS STATEMENT OF WORK EXHIBIT I-157
  14. 14. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 EXHIBIT I-158 EDS SOMS STATEMENT OF WORK
  15. 15. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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®. EDS SOMS STATEMENT OF WORK EXHIBIT I-159
  16. 16. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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, Scope Statement e-mails, minutes) High Level Business Process Model Requirements Detailed Requirements (e.g., use cases, f unctional, non-f unctional, business rules) Other Work Products Design / Code Test Plans / Cases (e.g., User and Training Manuals) Figure 6.4-5, End-to-End Requirements Traceability EXHIBIT I-160 EDS SOMS STATEMENT OF WORK
  17. 17. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-161
  18. 18. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. EXHIBIT I-162 EDS SOMS STATEMENT OF WORK
  19. 19. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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 Planning for the design iterations; an ongoing process that occurs Iteration 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 EDS SOMS STATEMENT OF WORK EXHIBIT I-163
  20. 20. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE OCE Process Core Focus 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. Establish Architecture 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. EXHIBIT I-164 EDS SOMS STATEMENT OF WORK
  21. 21. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Establish Architecture Use Case View Establish Establish Establish Establish Logical View Development Process View Physical View View Development Logical View Process View Physical View View Commit Architecture Project Team Client Project Release/Iteration Leadership Architecture Approach 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-165
  22. 22. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. EXHIBIT I-166 EDS SOMS STATEMENT OF WORK
  23. 23. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-167
  24. 24. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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 EXHIBIT I-168 EDS SOMS STATEMENT OF WORK
  25. 25. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-169
  26. 26. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Prepare Project Identity and Develop/Update Establish Team and Acquire Reusable Evolve Glossary Work Plan Environment Affected Groups Assets 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: EXHIBIT I-170 EDS SOMS STATEMENT OF WORK
  27. 27. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Evolve Use Case Views Use Case View Evolve Evolve Evolve Evolve Logical View Development Process View Physical View View Development Logical View Process View Physical View View Integrate System 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. EDS SOMS STATEMENT OF WORK EXHIBIT I-171
  28. 28. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Affected work products – The following key work products are affected during the execution of this sub-process: 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 EXHIBIT I-172 EDS SOMS STATEMENT OF WORK
  29. 29. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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 EDS SOMS STATEMENT OF WORK EXHIBIT I-173
  30. 30. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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. EXHIBIT I-174 EDS SOMS STATEMENT OF WORK
  31. 31. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 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. Affected work products – The following key work products are affected during the execution of this sub-process: 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 EDS SOMS STATEMENT OF WORK EXHIBIT I-175

×