Skip to main content

Table 3 MPS-SV level G processes and how they were implemented

From: From project-oriented to service-oriented software development: an industrial experience guided by a service reference model

MPS-SV process purpose and expected results

How the expected results were implemented

Service Delivery (SD)

Purpose:

 

The purpose of this process is defining the strategy and establishing the service system to deliver services in conformance with the service agreements.

Required Results:

SD 1. A service delivery and operation strategy is established and maintained;

SD 1. The defined service delivery and operation strategy is shown in Figure 1.

SD 2. The availability of the needed elements for providing the service is confirmed;

SD 2. The availability of needed elements was assured by the contractual framework, which included an internalized requirements analyst at the customer side.

SD 3. The service system is put into operation to deliver the agreed services;

SD 3. The service system was put into operation.

SD 4. The service system is maintained to assure continuous service delivery.

SD 4. The service system was maintained operating.

Service Level Management (SLM)

Purpose:

 

The purpose of this process is to assure that the SLA goals for each customer are met.

Required Results:

SLM 1. Services and their dependencies are identified;

SLM 1. The identified service was software development, including corrective and evolutionary (new functionalities) maintenance.

SLM 2. Service level goals are defined in an SLA;

SLM 2. The defined SLA is shown in subsection ‘Service Level Agreement and Penalties’.

SLM 3. Services are monitored against the SLA;

SLM 3. Monitoring was achieved by defining the service management controls depicted in Figure 2.

SLM 4. Service level performance is communicated to relevant stakeholders;

SLM 4. The request-tracking spreadsheet (Figure 3) was shared with the customer and sent monthly for billing purposes. It provides an overview of the service performance against the SLA.

SLM 5. Changes in service requirements reflect in the SLA.

SLM 5. Those changes did not happen in the context of this experience, but would imply in changing the SLA appendix of the contractual framework and both sides, supplier and customer) were open to discuss such changes.

Incident Management (IM)

Purpose:

 

The purpose of this process is to handle individual incidents and service requests within a SLA.

Required Results:

IM 1. A strategy for incident and service request management is established and maintained;

IM 1. The defined strategy involved fine-grained request monitoring by using the internal managerial controls shown in Figure 2.

IM 2. An incident and service request management system is established and maintained;

IM 2. The internal managerial controls were established and maintained.

IM 3. Incidents and service requests are registered and classified;

IM 3. Each request was registered into the request-tracking spreadsheet (Figure 3) and classified as an incident (correction) or a new service request (change or new functionality).

IM 4. Incidents and service requests are prioritized and analyzed;

IM 4. Each request had its priority defined and impact analysis performed, using the traceability provided by the issue-tracking system, to estimate the required effort.

IM 5. Incidents and service requests are resolved and concluded;

IM 5. The request-tracking spreadsheet shows the managerial status of each request, allowing managing them until conclusion.

IM 6. Incidents and service requests that did not progress according the SLA are communicated to higher level management;

IM 6. The request-tracking spreadsheet was shared and monthly sent to directors of both companies. It explicitly identifies the request that did not meet the SLA.

IM 7. Status information on incidents or service requests is communicated to relevant stakeholders.

IM 7. Status communication to higher management and customer stakeholders was achieved through the spreadsheet. Communication to the internal development team by using the Kanban chart.