Quality-Driven Software Development for Maintenance

Quality-Driven Software Development for Maintenance

Iwona Dubielewicz, Bogumila Hnatkowska, Zbigniew Huzar, Lech Tuzinkiewicz
DOI: 10.4018/978-1-61350-438-3.ch001
OnDemand:
(Individual Chapters)
Available
$33.75
List Price: $37.50
10% Discount:-$3.75
TOTAL SAVINGS: $3.75

Chapter Preview

Top

Introduction

Software maintenance is an integral part of a software life cycle. It means that software maintenance should not be considered without the context of software life cycle. The consequence is that “the main problem in doing maintenance is that we cannot do maintenance on a system which was not designed for maintenance” (Schneidewind, 1987). So, our basic assumption when dealing with maintenance is manifested by the phrase: Don’t think about software maintenance if you didn’t think about it during software development process.

Nowadays, dominating approaches to software development form the group called Model Development Engineering (MDE). It means that models are considered as basic artifacts elaborated within the software development process. One of the MDE approaches, Model Driven Architecture (MDA), (Kleppe, Warmer & Bast, 2004)) introduces three categories of models: Computer Independent Model (CIM), Platform Independent Model (PIM), and Platform Specific Model (PSM), and proposes the software development as a process of elaboration and transformation of the models according to the schema:

CIM → PIM → PSM → Code

It means that on the basis of initial CIM model, first PIM and next PSM models are elaborated, and finally PSM model is transformed into Code.

In the chapter, we follow the scheme of MDA. This pattern may be used repeatedly in the life of the software product. The first application of this scheme is associated with the initial development of the software product – with the issue of the first release of a software product. The subsequent application of the same scheme may result from the need of the product maintenance, and is concerned with the issue of a new release of the software product. The scope of subsequent applications of MDA scheme depends on the kind of maintenance. ISO vocabulary (ISO/IEC 24765, 2009) defines three kinds of maintenance: adaptive, perfective and corrective. In the chapter, we concentrate on perfective maintenance, and we have omitted adaptive and corrective maintenance. The reasons are twofold. First, perfective maintenance covers about 60% of total maintenance costs (Canfora & Cimitile, 2000; Deissenbock, 2009), and is concerned with a change in the problem domain. Second, adaptive maintenance is concerned with the solution domain and corrective maintenance concentrates mainly on modification of code. Additionally, perfective maintenance entails modification of all MDA models, while adaptive maintenance entails modification of PSM model and code, and corrective maintenance entails only modification of code.

The MDA models may be defined in different ways depending on the applied software development methodology. There are many methodologies that are based on the MDA approach (Kleppe, Warmer & Bast, 2004). In the chapter, to define the MDA models we use Quality Driven Software Development (QUAD) methodology (Dubielewicz, Hnatkowska, Huzar &Tuzinkiewicz, 2010). QUAD belongs to the group of Unified Process methodologies. The main reason for QUAD selection is its specificity, i.e. the quality and evaluation models are applied to selected artifacts on each stage of software development. Maintainability is one of the quality characteristics defined in (ISO/IEC 9126-1, 2001), and models are the main artifacts of the developing software. Therefore, maintainability may be assessed in the same way as it has been proposed in QUAD methodology for software quality evaluation. The knowledge of QUAD is not necessary because the required elements are introduced and explained in further presentation.

Maintainability, similarly to other ISO quality characteristics (ISO/IEC 9126-1, 2001), may be considered from external and internal perspective of quality specification.

In general, it is very difficult to specify maintainability from external perspective. In practice, maintainability is usually not considered from external (i.e. contracting user) perspective, when the contract for the first release of a software product is agreed. The client realizes the problem of maintainability when there is a request to modify, usually to extend, the software product, and, in consequence, there is a need to sign a contract for the new release of the software product. In this situation the problem is how to extend the software product at minimum cost. The idea is to find a balance between the extent of changes and the cost of labor of the software developer. In such a context it is difficult to treat the maintainability similarly to other quality characteristics.

Complete Chapter List

Search this Book:
Reset