Article Preview
TopIntroduction
In any software system, maintenance is an inevitable process (Lehman & Belady, 1985). Software maintenance refers to the process of managing changes in a software product after it is released for use. The maintenance activities are generally classified as: (a) corrective, which relates to repairing a fault, (b) adaptive in terms of handling new requirements, and (c) perfective, which is focused on improving the system performance (Lientz & Swanson, 1980). System users, software project managers and system developers can initiate maintenance requests. Software product managers evaluate these requests from a cost and impact perspective. Once approved, requests for change can result in several activities, e.g., system analysis, re-design, prototyping and validation of the system components. Once all the needed changes have been implemented and verified, the new version (containing all the changes) is released to the users (Arther, 1988; Banker & Slaughter, 1997).
Managing the software maintenance process and defect resolution activities in an organization is a challenging management function (Swanson & Beath, 1979). Efficient management of the software maintenance process requires matching the capacity and capability of software developers (referred to as resources) with the defects of varying levels of complexity (Ngo-The & Ruhe, 2009). The defects are reported to a team of software developers, which handles these defects through a software defect resolution (SDR) process. A defect identifier, a defect category, the skill requirements of maintenance resources and a due date for defect resolution, parameterize each software defect. The actual time to resolve a defect depends on the skill and experience level of the assigned developer and the inherent complexity of the defect. The total time a defect spends in the SDR process (referred to as system) consists of the time spent to resolve the defect and the queue wait time, when the assigned team member is busy working on a defect assigned earlier.
There are generally two perspectives regarding the software defect resolution process: the perception of the customer, and the internal perception of the software company (April, Hayes, Abran, & Dumke, 2005). This paper studies the defect resolution process from the latter perspective. In a software company, the activities of a defect resolution process have typical characteristics (Abran & Nguyenkim, 1993). The defects arrive in a random manner and are managed more in line with a queue-management approach rather than as managing a project. The defects are reviewed and managed according to their assigned priorities, which may change at any time.
The SDR considered in this paper is described in Figure 1. The defects of a particular software product are reported to the manager of the software maintenance team. The team manger classifies the defect by assigning it a priority based on the type and its significance. The team manager uses allocation rules to assign a software developer to resolve the defect. This allocation depends on the developer(s) capability, defect resolution requirements, availability of the developer(s) and their assigned workload. Software developers manage their individual work queues according to some sequencing rule. A defect is handled and resolved before the next defect is taken up. The resolved defects exit the system.
Figure 1. Software defect resolution