Inputs from Service Design

A service is defined by a service package that comprises one or more service level package s (SLPs) and re-usable component s, many of which themselves are services, e.g. supporting service s. The service package defines the service utilities and warranties that are delivered through the correct functioning of the particular set of identified service asset s. An SLP provides a definitive level of utility or warranty from the perspective of outcomes, assets and patterns of business activity (PBA) of customers. It is therefore a key input to test planning and design.

The design of a service is related to the context in which a service will be used (the categories of customer asset). The attribute s of a service characterize the form and function of the service from a utilization perspective. These attributes should be traceable to the predicted business outcomes that provide the utility from the service. Some attributes are more important than others for different sets of user s and customers, e.g. basic, performance and excitement attributes. A well-designed service provides a combination of these to deliver an appropriate level of utility for the customer.

The Service Design Package defines the agreed requirement s of the service, expressed in terms of the service model and Service Operation s plan that provide key input to test planning and design. Service models are described further in the Service Strategy publication.

Figure 4.26 Service models describe the structure and dynamics of a service

The service model (Figure 4.26) describes the structure and dynamics of a service that will be delivered by Service Operations, through the Service Operations plan. Service Transition evaluates these during the validation and test stages.

Structure is defined in terms of particular core and supporting service s and the service assets needed and the patterns in which they are configured. As the new or changed service is designed, developed and built, the service assets are tested and verified against the requirements and design specification s: is the service asset built correctly?

For example, the design for managed storage services must have input on how customer assets such as business application s utilize the storage, the way in which storage adds value to the applications, and what costs and risks the customer would like to avoid. The information on risks is of particular importance to service testing as this will influence the test coverage and prioritization.

Service model s also describe the dynamics of creating value. Activities, flow of resources, coordination, and interactions describe the dynamics (see Figure 4.27). This includes the cooperation and communication between service users and service agents such as service provider staff, processes or system s that the user interacts with, e.g. a self-service menu. The dynamics of a service include patterns of business activity, demand patterns, exceptions and variations.

Figure 4.27 Dynamics of a service model

Service Design uses process maps, workflow diagrams, queuing model s, and activity patterns to define the service models. As Service Transition evaluates the detailed service models to ensure they are fit for purpose and fit for use it is important to have access to these models to develop the test models and plan s.

The Service Design package defines a set of design constraints (Figure 4.28) against which the service release and new or changed service will be developed and built. Validation and testing should test the service at the boundaries to check that the design constraints are correctly defined and particularly if there is a design improvement to add or remove a constraint.

Figure 4.28 Design constraints of a service

Дата добавления: 2015-10-29