Rework Requirement Changes in Software Maintenance

Bee Bee Chua Faculty of Engineering and Information Technology,

University of Technology, Sydney Sydney, Australia

bbchua@it.uts.edu.au

Abstract—The rework cost of a requirement change is high. Requirements changes, which relate to hidden catastrophic failures, can cost many thousands of dollars to fix. An exploratory study on software maintenance records demonstrates that specific change characteristics in corrective change and functional change are shown to have an effect on rework. In pursuing a deep understanding of the effects, we found that unexpected errors and poor understanding of errors trigger higher rework effort. This correlates to 1) weak characteristics and attributes found in coding, 2) the lack of user involvement, 3) unavailability of user documentation, and 4) the lack of motivation and confidence in software maintainers (excluding functional change) to contribute to an increase in rework effort for software maintainers. As such, the author of this paper propose ways to improve the situation by introducing new criteria in change request forms and developing a framework to be used for eliminating rework problems. The understanding of effort rework effects of corrective and functional changes can help software practitioners to be aware that estimation error can be prevented.

Keywords—requirements changes; rework effort; functional change; corrective change.

I. INTRODUCTION Maintaining a software application is a

daunting task for both project managers and software maintainers. Not only do they need to know the consequence of a requirement change, but they must also be proactive enough to manage complex requirements.

Because requirement change is expensive, estimating effort rework on each change is consequently not cheap either. The cost of a simple requirement change can range from a few dollars to a million dollars to fix. In the worst scenario, requirements changes related to hidden failures can incur a huge amount of overhead maintenance cost for an organization, and this money is not easy to recoup even after many years.

No organization can claim to be uninterested in reducing software maintenance costs. Every

organization wants as much as possible to control wasteful resources. In order to eliminate software maintenance costs, organizations have tried all kinds of strategies and techniques to improve estimates. A critical aspect in software maintenance is estimation. Two obvious situations that can occur while estimating requirements changes are that a wrongly estimated requirement change cost is equally as bad as no estimate for software maintainers and users, or that many of the costs of requirements changes have been over or under-estimated.

A sound understanding of requirements change in relation to the cost of reworking is therefore extremely important. Because a requirement change is never constant, the ripple effect it has on other changes is high and the impacts of one change can double the overall cost.

The objective of this paper is to demonstrate that the characteristics of both corrective and non-corrective changes affect and cause an increase in effort reworks. The findings are based on a case study conducted on a review of change release forms for a range of on-going maintenance applications. The structure of the paper is as follows: Section 2, the highlight of some authors’ previous works on software maintenance and requirements’ changes. Results from case studies are presented in Sections 3, 4 and 5. Section 6 concludes lessons learned in the paper and the previews of future work discussed in Section 7.

II. REQUIREMENTS CHANGES IN SOFTWARE MAINTENANCE REVIEW

The definitions and concepts of a requirement change originate from software maintenance and change management, as each requirement change identifies the type of change, the functionality of change, and the effect and impact of each change [1-6]. The reasons for requirements change mostly

2010 Fifth International Conference on Software Engineering Advances

978-0-7695-4144-0/10 $26.00 © 2010 IEEE

DOI 10.1109/ICSEA.2010.45

252

2010 Fifth International Conference on Software Engineering Advances

978-0-7695-4144-0/10 $26.00 © 2010 IEEE

DOI 10.1109/ICSEA.2010.45

252

relate to error detection and correction, the modification of original requirements change for operational purposes, and the support of user request. Requirements change can be categorized by type, by volume, by case study context, by domain, by change management and by its own characteristics and attributes [7-12] .

According to small and large software maintenance environments and change management, user change and software change [13] are the most significant kinds of requirements change to be reported. A study conducted by Weiss and Basili [13] of software development changes made in projects at the NASA Software Engineering Laboratory reported that the most frequent type of software change is unplanned design modification. They found that the reasons for software changes relate to 1) improving program optimization, 2) improving the services offered to users, and 3) clarifying and improving the maintainability of software products.

In a range of systematic literature that were reviewed [2-8,13-15], the factors of requirements changes found in project management, change management, software maintenance, information systems and software engineering disciplines were perceived to be largely related to 1) environmental-issues and 2) learning-issues. No doubt there are many other factors influencing requirements change; however, these two groups are known to be the two largest groups that are critical to projects and which are repeatedly mentioned in the literature.

Studies [7,16-19] on requirements, requirements instability, and requirement volatility of software defects have been focused on the understanding of their change types, change effects and change impacts caused by influencing factors like organization and environment. Works have been published that detail how software maintainers’ lack of motivation, skills incompetence, inadequate knowledge and insufficient experience affect overall activities in software maintenance [20-22]. Unfortunately, very little work has been published on requirements changes rework caused by implicit factors that correspond to the coding-level, user-level, software-maintainers’ level and user-documentation-level.

In software maintenance, there are four kinds of changes: Corrective, Adaptive, Perfective and Preventive [16]. They have been classified by various authors and their taxonomies as presented in these studies show evidence of significant data [2, 17-19]. The definition of a corrective change refers to modification initiated by defects in the software. A defect can be an error found in design, logic or coding. Adaptive change, however, is driven by the need to accommodate modifications in the environment of the software system. Perfective change describes changes undertaken to expand the existing requirements of a system. Preventive change is undertaken to prevent malfunctions or to improve maintainability of the software [16].

Requirements changes can be grouped into any of these categories without having to determine the cost of the software maintenance effort. However, without knowing the cost of a requirement change, the change cannot be implemented. When assessing the cost of each requirements change, effort is taken into account. The conventional approach drives most project managers and software maintainers to undertake estimation by applying an analogy-based approach where they assign value for effort reworks. Modern estimating tools such as parametric ones, for example, SLIM [23] and COCOMO 2.0 [24], provide good software development effort and the software provides the support cost of effort. Unfortunately, these tools do not elaborate on maintenance effort rework in respect of requirements change.

In order to better understand the estimate process, a research question that develops focusing on the investigation of which variables of requirements changes to consider in estimating software rework effort. An organization that specializes in manufacturing products has many software applications that need maintenance support. This company has a large change management database that stores many releases for different applications. Their historical data (maintenance releases) supplied to us were 6 years old. A total of 119 maintenance records were reviewed, of which 13 records were rejected by software maintainers due to incomplete information in a maintenance release form.

253253

III. MAINTENANCE CHANGE RELEASES SORTED BY CHANGE TYPES

There were 106 valid requirements changes documented in maintenance release forms submitted by end users. They were categorized into software maintenance changes groups. Table 1 shows that 32 of the forms received relate to adaptive change, 41 forms to corrective change, 8 forms to perfective change, 6 forms to preventive change, and 19 forms submitted request functional changes of their applications. The intent of this categorization is to examine the maintenance release forms submitted by users to determine which maintenance change type has the highest number of requirements changes and which maintenance change types and characteristics most involve significantly high rework effort.

TABLE I. NUMBER OF RELEASE FORMS SUBMITTED BY USERS BASED ON REQUIREMENTS CHANGE TYPE

Application size range from 30,000 to 400,000

Change type Insert Up-date

Delete Insert and

update

Insert and

delete Adaptive 10 21 1 - - Corrective 4 35 1 1 Perfective 4 2 2 - - Preventive 3 2 1 - - Functional 14 4 0 - 1

Graph 1 shows a strong demand from users in

the organization to add functional changes to their current software applications. Many applications in this organization are old but are considered stable. The age of the applications is between 10 and 15 years. Because technology and business contexts change quickly, equipment must constantly improve to keep up with the pace of the market, and inserting new and better functionality of programs into the existing software is therefore necessary [25].

By contrast, the corrective changes did not seem to require the insertion of lines of source codes. The assumption of errors found in source code are not difficult fixes and that the updates of the correct change will be sufficient. Hence, the

data in the graph explains why corrective change has many records that require updates.

GRAPH 1 REQUIREMENT CHANGE TYPE

There is no evidence to claim that applying the

traditional way to estimate is incorrect. The basis of rework effort on change of requirements must be based on historical projected data. It is unlikely that the risk of a requirement change can be anticipated and estimated without the availability of past data. Since corrective change and functional change are often discussed widely in the literature, they are the two illustrative examples selected in this paper. In addition, requirements changes in these two change types can be seen to have a higher rework effort than others.

IV. CORRECTIVE CHANGE RELEASES SORTED BY CHANGE TYPES AND REWORK EFFORT

Graph 2 shows an outline of each application size by change type. Interestingly, according to authors [23,24], there are several methods of measuring application size. One traditional technique uses a count of function points or features in a piece of software to determine the size of an application. Ironically, however, measuring the intensity of effort rework is not dependent on the size of a requirement change; rather, it is the complexity of a requirement change that matters most in triggering effort effects. Table 2 shows the breakdown of characteristic types of corrective change by application size and the effort rework on each change for individual applications.

0510152025303540

Adaptive

Corrective

Perfective

Preventive

254254

GRAPH 2 OUTLINES CORRECTIVE CHANGE OF EACH APPLICATION SIZE BY

CHANGE TYPE

TABLE II. SPECIFIC CHARACTERISTICS OF CHANGE BY EFFORT REWORK

Application

Size Low effort Medium

Effort High effort

30,000 0 2 040,000 0 6 050,000 0 3 160,000 1 5 070,000 0 5 080,000 0 6 090,000 0 0 0

100,000 0 2 0110,000 4 1 0165,000 3 2 0

A requirement change can be further classified

in three ways; by a single characteristic, two characteristics or three characteristics. A single characteristic can be defined as insert, update, or delete. Classification by two characteristics is a combination of any two of the three characteristics insert, update or delete and by three characteristics is a combination of insert, update and delete.

Graph 3 shows more than one characteristic for a large size application. Between the mid-size range of applications and large size applications, I notice that there are more corrective changes as a single characteristic; 4 change request forms are for lines of code insertion, and 35 change request forms are for lines of code to be updated. There is only one case in which the change request form has the two characteristics of insert and update on a relative small-scale application. There is no corrective change on two and three characteristics. In other words, this tells me that many of the

changes found were defects in program logic. To know which specific characteristic of change involves low and high effort rework, the table below presents effort rework by application size grouping.

GRAPH 3 SPECIFIC CHARACTERISTICS OF CHANGE BY EFFORT REWORK

The feedback from project managers on to how they measure effort and effort reworks was that they assign a value to determine whether the effort is low, medium or high. If the subject has qualitative numbers, then it is necessary to convert the qualitative number into a quantitative one. For example if a person day effort is estimated below 50% to complete the rework of a requirement change, by the quantitative method, it is considered low effort. Medium effort is assigned to effort rework which is greater than 50% but less than 80%, and high effort is assigned where the rework is 80% or more. Using a similar approach to quantify the numbers, a software maintainer confidence level that is 100% is assigned a value of 1; if the software maintainer confidence level is 50%, it is assigned a value of 2; and if the software maintainer confidence level is below 50%, it is assigned a value of 3. The following attributes are needed for estimating different modes of effort reworks:

1. Effort (low, medium and high) 2. Project (size and age) 3. Requirement Change (change type and

characteristics) 4. People (skill, knowledge, experience,

participation in projects and confidence level)

0 5 10

30,00050,00070,00090,000

110,000 update and delete

insert and delete

insert and update

delete

Updates

Insertion

02468

30,0

0040

,000

50,0

0060

,000

70,0

0080

,000

90,0

0010

0,00

011

0,00

016

5,00

0

Low effortMedium EffortHigh Effort

255255

The analysis of corrective change is concluded by the fact that effort rework is at the average level for small to large applications. This information tallies with the discussion in the literature that, owing to a continuous flow of requirements changes being inserted or modified, the software becomes more complex, is patched with numerous changes, and becomes progressively more difficult to maintain [25].

If we consider the high rework on a particular change for an application size of 50,000, we might see that the requirement for this change was 1500 lines of source code updates at a moderate estimated rework effort of 25 person-days. By comparing it with others having the same characteristics and noted that there was no significant difference in application age or software maintainers’ skill. This change needed 50,000 lines of source code updating in an application which is already 8 years old, and the software maintainer is a person with 8 years’ experience who has participated in this project and knows the project’s scope well. Except in the column of software maintainer’s confidence skill, he was rated as low.

The effect of rework change which was discovered concerning unexpected and poorly understood errors. This correlates to 1) inconsistent or incomplete attributes in programming, 2) a lack of user communication that relates to poor user involvement (i.e., not knowing the process of the change), 3) unavailability of user documentation, and 4) the lack of motivation and confidence in software maintainers.

It is unlikely to rule out that it might be possible to resolve technical or systems errors, as they are incidental errors occurring for the first time, while nevertheless bearing in mind that it is highly challenging for a software maintainer to analyze a software system comprising 500,000 or 2,000,000 lines of code in order to find a hidden defect or to identify a specific change.

It is interesting to investigate whether non-errors contribute to high effort rework and if so, the major causes of effort rework. The data from

functional change and show the results in a table and a graph. Table 3 and Graph 4 show functional change releases sorted by change type.

TABLE III. FUNCTIONAL CHANGE RELEASES SORTED BY CHANGE TYPE

Appli-cation Size

Insert Update Delete Insert and

Update

Update and

Delete

Insert, Update

and Delete

30,000 2 2 0 0 0 040,000 1 0 0 0 0 050,000 1 1 0 0 0 060,000 1 1 0 0 0 070,000 5 0 0 0 0 0400,000 2 0 0 0 1 0500,000 2 1 0 0 0 0

GRAPH 4 FUNCTIONAL CHANGE RELEASES SORTED BY CHANGE TYPE

V. FUNCTIONAL CHANGE RELEASES SORTED BY CHANGE TYPE AND REWORK EFFORT

In every size of application there is at least one functional change requested by a user. This means there is no one system that can be judged as having the best features or best functionality. Nonetheless, a reliable system is acknowledged to be one in which the least number of errors are found. Quite a number of change requests refer to line insertions on an application size of 70,000 during the period. There is minimal functional change on update and delete, which implies that the quality of the source code is good.

0123456

Insertion

Updates

delete

insert and update

insert and delete

update and delete

256256

TABLE IV. FUNCTIONAL CHANGE RELEASES BY EFFORT TYPE

Application Size

Low Effort Medium Effort

High Effort

30,000 0 2 040,000 0 1 150,000 0 1 060,000 1 0 070,000 0 3 2400,000 0 1 0500,000 0 1 2

A general view of rework effort involving

functional change can be found between the medium and high groups. This tells me that rework effort does not only imply error correction. The evidence shows that functional changes increase rework effort if the insertion of lines of code is incorrect, inconsistent, or incomplete. (see table IV and graph 5).

Three typical changes show high rework on

application sizes of 50,000, 70,000 and 500,000, and the changes we reviewed have created new modules. For an application size of 50,000, the insertion of 1500 lines of code required 50 person-days to complete; the insertion of 1800 lines of source code needed 30 person-days to complete for an application size of 70,000; and the insertion of 1000 lines of source code needed 7 person-days to complete for an application size of 500,000.

GRAPH 5 FUNCTIONAL CHANGE RELEASES SORTED BY EFFORT TYPE

Two of the maintenance requests

communicated and involved user participation, so no conclusion that the high rework is due to a lack

of user communication. It was confirmed that the high rework definitely due to the discovery of unexpected and poorly understood errors. This correlates to weaknesses in 1) the characteristics and attributes of the lines of source code inserted and 2) the lack of user documentation.

No deficiency in the software maintainers’ confidence level showed in dealing with functional change. All were confident that they knew what to change based on the release given. Given their skill level and knowledge, they had no difficulty knowing what to do.

VI. LESSONS LEARNED The contribution made by this paper is to

provide software maintainers and change management committees with an insight into various types of software maintenance issues, which are drivers for software rework effort. Having more detailed information can help software maintenance teams or change management committees to narrow their focus when they are considering software maintenance releases or change request forms, and the kind of mandatory criteria on which to review them [26]. For example, criteria might be included in change request forms to review areas in 1) coding format, 2) ensuring that users are involved and informed of requirements changes, 3) check that documentation provides full reference to requirements changes, and 4) determining the software maintainer’s skill, knowledge, experience and motivation in solving each requirement change.

The new criteria can go some way to eliminating or reducing rework cost and effort, and will significantly reduce the risk to effort estimation for the rework. Better control of the changes will be possible, and they will be organized more effectively and efficiently.

VII. FUTURE AND CHALLENGES The results presented in this paper are useful to

organizations with similar application sizes to gain an insight into these implicit variables that constrain the accuracy of rework. In addition to my findings, research in configuration management or software maintenance needs to focus on effort estimation for rework requirements

00.5

11.5

22.5

33.5

Low effort

Medium Effort High Effort

257257

changes, and to develop frameworks that better support the estimation process. Such a framework would ideally be used for tracing high and repeated effort rework in which the issues are critically affecting effort reworks on requirement changes types. This kind of framework, for example [12], must be capable of being incorporated into estimation tools so that effort rework estimate can be more accurate and can benefit a large project management community.

The challenge remains that software maintenance is becoming a core focus in today’s business Information Technology context. More companies are focusing on upgrading existing applications than on implementing new projects. Improved estimation on rework is no doubt an expense, but one that is definitely necessary.

REFERENCES [1] D. V. Edelstein. Report on the IEEE STD 1219-1993-standard for

software maintenance. ACM SIGSOFT Software Engineering Notes. 1993, Vol. 18, No. 4,pp94-95

[2] B. P. Lientz and E. B. Swanson. Software Maintenance Management. Addison Wesley, Reading, MA. 1980

[3] ANSI/IEEE. IEEE standard glossary of software engineering terminology. Technical Report 729. 1983

[4] B. J. Cornelius, M. Munro, and D. J. Robson. An approach to software maintenance education. Software Engineering Journal. 1988. Vol. 4, No. 4, pp. 233-240

[5] G. Kotonya and I. Sommerville. Requirements Engineering Processes and Techniques. John Wiley and Sons, London. 1998

[6] S. D. P. Harker, K. D. Eason, and J. E. Dobson. The change and evolution of requirements as a challenge to the practice of software. In Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE Computer Society, Los Alamitos, CA. 1992, pp. 266-272

[7] G. E. Stark, P. Oman, A. Skillicorn, and A. Ameele. An examination of the effects of requirements change on software maintenance releases. Journal of Software Maintenance: Research and Practice.1999, Vol. 11, No. 5, pp. 293-309

[8] W. Lam. Achieving requirements reuse: A domain-specific approach from avionics. The Journal of Systems and Software. 1997, Vol. 38, No. 3, pp. 197-209

[9] T. E. Bell and T. A. Thayer. Software requirements: Are they really a problem? In Proceedings of the 2nd IEEE International Conference on Software Engineering, San Francisco, CA. 1976, pp. 61-68

[10] B. B. Chua and J. M. Verner. IT practitioner's perspective on Australian risk management practices and tools for software development projects: A pilot study. SoMeT 2005, pp. 111-125

[11] B. B. Chua, J. M. Verner, and D. Dalcher. A framework for predicting person-effort on requirements change. SoMeT 2006, pp. 439-451

[12] B. B. Chua, D. V. Bernardo, and J M. Verner. Criteria for estimating effort for requirements change. EuroSPI 2008, pp. 36-46

[13] V. R. Basili and D. M. Weiss. Evaluation of a software requirements document by analysis of change data. In Proceedings of the 5th International Conference on Software Engineering. San Diego, CA. 1980

[14] G. Walia and J. Carver A systematic literature review to identify and classify software requirement errors. Information and Software Technology. 2009, Vol. 51, No.7, pp. 1087-1109

[15] P. Grubb and A. A. Takang. Software Maintenance Concepts and Practice (2nd edn.) World Scientific, Hackensack, NJ. 2003

[16] T. Javed, M. E. Maqsood, and S. D. Qaiser, Study to investigate the impact of requirements instability on software defects. In Proceedings of ACM SIGSOFT Software Engineering Notes. 2004, Vol. 24, No. 4, pp. 120-128

[17] L. J. Arthur. Software Evolution: The Software Maintenance Challenge. John Wiley and Sons, New York. 1988

[18] W. M. Osborne. Building and sustaining software maintainability. In Proceedings of the IEEE Conference on Software Maintenance. 1987, pp. 13-23

[19] M. Jorgensen, D. Sjoberg, and G. Kirkeboen. The prediction ability of experienced software maintainers. In Proceedings of the 4th European Conference on Software Maintenance and Reengineering. Zurich. 2000, pp. 93-99

[20] K. Molokken and M. Jorgensen. A review of software surveys on software effort estimation. In Proceedings of the IEEE Transaction Symposium on Empirical Software Engineering. 2003, pp. 223-230

[21] S.J. Hoch and D.A. Schkade. A psychological approach to decision support systems. Journal of Management Science. 1996, Vol. 42, No. 1, pp. 51-64

[22] F. Bergeron and J. F. St-Arnaud. Estimation of information systems development efforts: A pilot study. Journal of Information Management. 1992, Vol. 22, pp. 239-254

[23] H. L. Putman. A general empirical solution to the macro software sizing and estimating problem. IEEE Transactions on Software Engineering. 1978, Vol. 4, No. 4, pp. 345-361

[24] B. W. Boehm, B. Clark, E. Horowitz, J. Christopher Westland, R.J. Madachy, and R W. Selby. Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering. 1995. Vol. 1, pp. 57-94

[25] A. April, A. Abran, and R. Dumke. What do you need to know about software maintenance? Journal of Maintenance and Asset Management. 2005, Vol. 20, No. 2, pp. 33-37

[26] B. B. Chua and J. M. Verner. Designing criteria for change request forms. In Proceedings of the 5th Software Measurement European Forum (SMEF), Milan. 2008, pp. 23-29

258258