Correction dimension. The activities on the correction dimension are aimed at bringing the software product at the quality level in conformity to the specifications. The fact that this activity is necessary is often caused by hidden faults in the software. These faults not uncovered by the development process should be dealt with by the supplier supplying the software (initially as a form of warranty and, after the end of the warranty, in the form of a software maintenance contract). According to the result-based concept this would mean that agreements on corrective activities should be in terms of the maximum hindrance a customer might have to deal with concerning the failure of the specific Information system. In the IT domain, there are of course various challenges to be addressed when attempting to implement such kind of agreements. The first problem is that the influence of the quality of the software on the whole information system is hard to assess formally. For example, an average client-server environment consists of 10 IT- components of which 3 to 4 are software related. Not only is the quality of the individual components often unspecified (especially for the software components), the quality implications of their interaction are often based on undocumented service assumptions. Therefore, the agreements proposed by the IT-organization often fall back to an effort basis rather than rely on a result -basis. In creating an SLA it is important to represent both parties involved and to come to a mutually beneficial agreement. Research on the field of service quality has shown that customers don’t have a singular expectation but rather a field of tolerance (Zeithalm 1993). This can be used to specify service levels (a service level guarantee and a service level target). By measuring the actual service level information can be gained about the quality of the (software) components and their interaction. Another growing necessity is the use, and alignment to internal SLA, of underpinning contracts. The modern IT-organization uses more and more third party software and services. When the maintenance of software is provided as a thid party service the service level provided by the supplier towards the customer (in this case the maintenance section) should be aligned to enable the maintenance section to guarantee the total service quality for the application. This approach is also necessary internally with other parties within the IT-organization to align maintenance activities ...
