A Service Establishment and Delivery Process Area at Maturity Level 3

The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.

The Service System Development process area is applicable to all aspects of a service system. It applies to new service systems as well as changes to existing service systems.

A “service system” is an integrated and interdependent combination of service system components that satisfies stakeholder requirements.

A “service system component” is a process, work product, person, consumable, or customer or other resource required for a service system to deliver value. Service system components can include components owned by the customer or a third party.

A “service system consumable” is anything usable by the service provider that ceases to be available or becomes permanently changed by its use during the delivery of a service.

The people who are considered service system components are those who perform tasks as part of the service system, including provider staff and end users, to enable the system to operate and thereby deliver services. (See the definitions of “service system,” “service system component,” “service system consumable,” and “work product” in the glossary.)

Organizations that wish to improve and appraise their product development processes should rely on the complete CMMI-DEV model, which specifically focuses on development as an area of interest.

Service provider organizations can also choose to use the CMMI-DEV model as the basis for improving and appraising their service system development processes. This use of the CMMI-DEV model is preferred for organizations that are already experienced with CMMI-DEV and for organizations that develop large-scale, complex service systems.

However, the Service System Development process area offers an alternative means of achieving somewhat similar ends by covering requirements development as well as service system development,
integration, verification, and validation in a single process area. Using SSD may be preferred by service provider organizations that are new to CMMI, especially those service providers that are developing simple services with relatively few components and interfaces. Even organizations that use the CMMI-DEV model for service system development may wish to refer to the Service System Development process area for helpful guidance on applying development practices to service system components such as people, processes, and consumables.

It is especially important to remember that the components of some service systems can be limited to people and the processes they perform. In those contexts and similar ones in which service systems are fairly simple, exercise care when interpreting the specific practices of this process area so that the implementations that result provide business value to the service provider organization.

The service system development process is driven by service and service system requirements that are collected from various sources such as service agreements and defects and problems identified during both service delivery and incident resolution and prevention processes.

The Service System Development process area focuses on the following activities:

·         Collecting, coordinating, analyzing, validating, and allocating stakeholder requirements for service systems

·         Evaluating and selecting from alternative service system solutions

·         Designing and building or composing (as needed), integrating, and documenting service systems that meet requirements

·         Verifying and validating service systems to confirm they satisfy their intended requirements and they will satisfy customer and end-user expectations during actual service delivery

CMMI does not endorse particular methods for service system development. How the service organization chooses to develop the service system can range from internal development to outsourcing to commercial product integration. Most service organizations in their efforts to build their service system will engage a development team and a particular development approach. The choice of development method(s) depends on the requirements to be achieved and what service system components will need to be developed. Agile methods constitute one possible family of approaches, but may not be appropriate for all (or any) components. (The phrase “Agile method” is shorthand for any development or management method that adheres to the Manifesto for Agile Development [Beck 2001] and that typically addresses software development.) For organizations that choose to use Agile, the following paragraphs can be helpful in implementing the practices of SSD.

In Agile environments, the requirements, design, development, and validation process is performed incrementally and through continuing engagement with relevant stakeholders, particularly customers and end users. Customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and iteration results. These requirements are prioritized into cycles of development from which design models, operational concepts, and diagrams are evolved to produce service system components. Agile methods give emphasis to a strong working relationship between the development staff, the service provision staff, and the customer (or end user). This iterative and cooperative development approach is used to select and refine the service system solution to provide high degrees of quality and efficiency during service delivery.

Short daily meetings or communications are held to obtain near real-time validation of the technical selections and decisions. End of cycle reviews are also conducted to validate current development and review requirements prioritization for the subsequent cycle of development. Due to the emphasis on early exploration and validation of needs and expectations, stakeholder commitment and availability is essential. Also, it is important that all parties understand their role and are willing to share in addressing the risks that arise from such collaborative work.

Further, when deciding to use an Agile method, consider the implications for other process areas. In particular, the effects on service system transition and delivery may need to be understood upfront; and discussions held on how best to mitigate any impacts.

For more information on how to apply Agile methods, see CMMI-DEV Section 5.0 Interpreting CMMI When Using Agile Approaches.

For standard services, the development processes described in this process area can also be applied at the organizational level to identify, develop, and maintain core assets (e.g., components, tools, architectures, operating procedures, service system representations, software) used in developing or customizing service systems for delivery of standard services (or tailored services).

Refer to the Strategic Service Management process area for more information about establishing strategic needs and plans for standard services.

Refer to the Service Delivery process area for more information about maintaining the service system.

Refer to the Service System Transition process area for more information about deploying the service system.

Refer to the Strategic Service Management process area for more information about establishing standard services.

Refer to the Decision Analysis and Resolution process area for more information about analyzing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Refer to the Organizational Performance Management process area for more information about selecting improvements and deploying improvements.

Refer to the Requirements Management process area for more information about managing requirements of products and product components and ensuring alignment between those requirements and the work plans and work products.

Specific Goal and Practice Summary

SG 1 Develop and Analyze Stakeholder Requirements

SP 1.1       Develop Stakeholder Requirements

SP 1.2       Develop Service System Requirements

SP 1.3       Analyze and Validate Requirements

SG 2 Develop Service Systems

SP 2.1       Select Service System Solutions

SP 2.2       Develop the Design

SP 2.3       Ensure Interface Compatibility

SP 2.4       Implement the Service System Design

SP 2.5       Integrate Service System Components

SG 3 Verify and Validate Service Systems

SP 3.1       Prepare for Verification and Validation

SP 3.2       Perform Peer Reviews

SP 3.3       Verify Selected Service System Components

SP 3.4       Validate the Service System