Examining Requirements Change Rework Effort: A Study

📝 Abstract

Although software managers are generally good at new project estimation, their experience of scheduling rework tends to be poor. Inconsistent or incorrect effort estimation can increase the risk that the completion time for a project will be problematic. To continually alter software maintenance schedules during software maintenance is a daunting task. Our proposed framework, validated in a case study confirms that the variables resulting from requirements changes suffer from a number of problems, e.g., the coding used, end user involvement and user documentation. Our results clearly show a significant impact on rework effort as a result of unexpected errors that correlate with 1) weak characteristics and attributes as described in the program’s source lines of code, especially in data declarations and data statements, 2) lack of communication between developers and users on a change effects, and 3) unavailability of user documentation. To keep rework effort under control, new criteria in change request forms are proposed. These criteria are shown in a proposed framework; the more case studies that are validated, the more reliable the result will be in determining the outcome of effort rework estimation.

💡 Analysis

Although software managers are generally good at new project estimation, their experience of scheduling rework tends to be poor. Inconsistent or incorrect effort estimation can increase the risk that the completion time for a project will be problematic. To continually alter software maintenance schedules during software maintenance is a daunting task. Our proposed framework, validated in a case study confirms that the variables resulting from requirements changes suffer from a number of problems, e.g., the coding used, end user involvement and user documentation. Our results clearly show a significant impact on rework effort as a result of unexpected errors that correlate with 1) weak characteristics and attributes as described in the program’s source lines of code, especially in data declarations and data statements, 2) lack of communication between developers and users on a change effects, and 3) unavailability of user documentation. To keep rework effort under control, new criteria in change request forms are proposed. These criteria are shown in a proposed framework; the more case studies that are validated, the more reliable the result will be in determining the outcome of effort rework estimation.

📄 Content

International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.3, July 2010 DOI : 10.5121/ijsea.2010.1304 48 Examining Requirements Change Rework Effort: A Study
Bee Bee Chua1 and June Verner 2
University of Technology Sydney, Australia 1
Sydney, New South Wales
Australia 2007
bbchua@it.uts.edu.au University of New South Wales2 Sydney, New South Wales
Australia 2007
ABSTRACT
Although software managers are generally good at new project estimation, their experience of scheduling rework tends to be poor. Inconsistent or incorrect effort estimation can increase the risk that the completion time for a project will be problematic. To continually alter software maintenance schedules during software maintenance is a daunting task. Our proposed framework, validated in a case study confirms that the variables resulting from requirements changes suffer from a number of problems, e.g., the coding used, end user involvement and user documentation. Our results clearly show a significant impact on rework effort as a result of unexpected errors that correlate with 1) weak characteristics and attributes as described in the program’s source lines of code, especially in data declarations and data statements, 2) lack of communication between developers and users on a change effects, and 3) unavailability of user documentation. To keep rework effort under control, new criteria in change request forms are proposed. These criteria are shown in a proposed framework; the more case studies that are validated, the more reliable the result will be in determining the outcome of effort rework estimation. KEYWORDS requirements change, effort rework, unexpected errors, weak characteristics and attributes, change request forms

1. INTRODUCTION Software maintenance is becoming a core focus in today’s Information Technology business context. More companies are focusing on upgrading existing applications than on implementing new projects. A global economic downturn has unfortunately pressured many companies into withholding new projects and deferring their implementation.
   Keeping project budget cost and time aligned for on time project delivery during the maintenance of an existing software project is never an easy task for a project manager. While much of the project funding is spent on requirement analysis, design, coding and testing, the remaining funding may not be enough to provide support for other software maintenance issues. Sometimes, the funding may run out completely because the effort rework risks for the cost of requirement changes have not been anticipated.
   Because making requirements changes can be expensive, estimating the cost of effort rework on each change can consequently also be costly. To understand what requirements changes are needed International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.3, July 2010 49

to correct or modify the system, lessons learned from previous effort estimates for requirements change rework need to be applied by IT practitioners. A requirements change can cause a ripple effect on other changes; thus an investigation into the effects of software rework is necessary.
The motivation for this paper is to provide an overview of a conceptual change management framework, empirically validated via a case study, in which a new development is found to be significantly impacted by the effect of effort rework. Further to this finding, an insight is provided into evaluating the criteria used in current change request forms and the introduction of suggested new criteria on which change forms should be based. In section 2, related software maintenance work is discussed. The research method is discussed in section 3. Results from the case study are included in sections 4 and 5. In section 6, the new criteria for inclusion in change request forms are introduced. Section 7 presents a brief discussion of the refinement of our framework, and a conclusion and outline for future work is discussed in section 8.
2. RELATED WORKS The definition of a requirements change originates from the area of software maintenance and change management; each requirements change identifies the type of change, the functionality required by the change, and the effect and impact of the change.
Edelstein [1] quotes a definition of software maintenance based on IEEE standard 1219 [2], which states that it is the modification of a software product after delivery, to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. This definition is similar to the definition of the need for requirements change. Other software maintainers [3,4,5] define software maintenance by focusing their views specifically on bug-fixing, user supp

This content is AI-processed based on ArXiv data.