Early Cost Estimation of Software Reworks Using

Fuzzy Requirement-Based Model

Tarig Ahmed Khalid Eng-Thiam Yeoh
Faculty of Computing and Informatics Faculty of Computing and Informatics
Multimedia University Multimedia University
Cyberjaya, Malaysia Cyberjaya, Malaysia
[email protected] [email protected]
Abstract- Defects uncovered during software testing to 70 percent of the overall project’s budget. In
usually consume a considerable amount of the overall general, cost of reworks becomes like a tax taken for
project’s budget. Unfortunately, project managers are not granted and paid by the software firms as a part of the
well-equipped with techniques to estimate such cost overrun. software development process [5].
Moreover, incorporating defects removal process as part of
the software testing activities has made the project managers This paper suggests the following:
overlook this important cost component during their  Splitting the software defects removals from
planning processes. This paper suggested a fuzzy model to testing so as to be considered as an
estimate the cost of defects removal at the early stages of independent process
project planning in terms of the project’s functional size and  A new fuzzy model for estimating the
the experience of the development team. expected cost of defect removals.

II. REWORKS ASSOCIATED PROBLEMS

Keywords- software cost estimation; cost of software
reworks; cost of defects removal; defects removal; software Software reworks associated with defects removal
rework are usually considered as part of the software testing
process although they have two different definitions.
Software testing is defined as “the process of
I. INTRODUCTION analyzing a software item to detect the differences
As software development activities complete, between existing and required conditions and to
software products are to be transferred to the testing evaluate the features of the software item” [6].
environment where defects would be systematically Sommerville [7] stated that “testing is intended to
uncovered. After testing, accepted software would show that a program does what it is intended to do and
then be transferred to the production environment to discover program defects before it is put into use”.
through the implementation phase. Unfortunately, Moreover, the software engineering body of
implementing software products immediately after knowledge (SWEBOK) stated that software testing
finishing the testing activities is just a day dream in consists of the dynamic verification that a program
the world of software development. The unavoidable provides expected behaviors on a finite set of test
fact is that many defects would be uncovered and cases, suitably selected from the usually infinite
many cycles of reworks and retests are to be execution domain [8]. Nevertheless, none of the above
performed before ending-up with accepted product. definitions mentioned anything about defects removal.
Software reworks become a fact of life in software This paper argued that although defects removal is
development projects. Furthermore, reworks have considered as part of the software testing process, its
negative impacts on software projects in terms of time associated activities are not well-defined in the context
delays and cost overruns. Charrette [1] argued that of the software testing. This situation resulted in
software developers spend 40 to 50 percent of their overlooking of the details of the defects removal and
time in reworks activities. Basili et al [2] and Raja and
its associated impact on the healthiness of the software
Marietta [3] suggested that cost of software reworks is
one of the main concern in software development projects in terms of schedule delays and cost overruns.
since cost is an important parameter defining the
success of software projects. Zahra et al [4] described
reworks as a “prevailing scourge” consuming up to 40

1
 We believe that defects removal is a process that is suggested that the current models should be modified
independent from software testing due to the following to incorporate the cost of the unplanned reworks.
reasons: Bhardwaj and Rana [12] described the
relationship among software size, number of software
 Testing and defects removal have iterative defects, productivity, and efforts for software
relationship since defects removal is usually development projects. They applied a multiple linear
followed by retest. However, the nature of the regression technique on a benchmarking historical
data-set. This ended up with two linear regression
testing activities differs from those of the
equations describing the web-based and non-web-
defects removal. Testing is conducted by test based projects. They suggested that web based projects
engineers while defects removal is performed are delivered faster. Moreover, they also argued that
by software developers as it is a regular lower productivity will lead to fewer defects while
software development activity. higher productivity resulted in a higher number of
 They have different ways to estimate costs. defects. Furthermore, they suggested that executing
Cost of testing includes the cost of the test non-web based project with experienced team require
environment in addition to the person-days of less time for development and most of the defect can
the test engineers. The testing efforts depend be identified during unit testing resulting in reduced
on the size of the test scripts. On the other rework efforts. They concluded that software size has
hand, the cost of defects removal is calculated much significant impact on total number of defect in
in terms of developers’ person-days. The comparison to efforts.
amount of reworks depends on the number However, depending on historical data obtained
and complexity of defects found as a result of from previous projects to formulate relationships
the testing process. among some variables is not consistent with the very
 Splitting defects removal as a separate basic attribute of the projects i.e. uniqueness. The
process aims to bring the focus of the project unique nature of every software project may make the
managers and software engineers to its use of data provided by other projects unreliable.
distinct nature as well as its impact on the
project plan. IV. PROPOSED MODEL
 Overlooking this process leads to wrong
estimates of cost and schedule and results in The proposed model aims to estimate the cost of
considerable differences between the planned rework, at an early stage of the project, as a percentage
and actual values. of the cost of the software development phase. This
paper focused on the software size and team
experience as the main independent variables affecting
III RELATED RESEARCH the amount of reworks.
Bharwaj and Rana [12] argued that software sizing
Zimmermann et al [9] conducted a study based on is very important in order to estimate other software
the defects database of the Eclipse open source project aspects like cost, schedule, and reworks.
projects. They established a mathematical model for Since, this research focuses on the early estimation
defects predictions in terms of some complexity of the rework cost as part of planning activities, a
metrics associated with the source code. From project requirement-based sizing will be adopted through the
planning perspective, this prediction is, unfortunately, use of function point analysis. The functional size of
too late as coding is part of the execution phase. software is calculated in terms of the inputs, outputs,
Project managers usually need to predict costs files, inquiries, and interfaces as shown in Table 1
including the cost of defects removal as early as [13], [14].
possible during the planning phase.
Efe and Demirors [10] conducted a case study TABLE 1 IFPUG FUNCTIONAL SIZING WEIGHTS
investigating the impacts of software reworks on Parameter Simple Average Complex
project estimations. The case study showed that during Inputs 3 4 6
the testing phase 152 issues were found resulting in Outputs 4 5 7
additional 133 unplanned persons-day for defects Internal Files 7 10 15
Interfaces 5 7 10
removal. They concluded that using project
Inquiries 3 4 6
management tools and techniques in their basic forms
may not meet the needs of the software projects
Software projects would be classified according to
without considering the special challenges related to
their size. This paper adopts the classification scheme
these software projects. Khalid and Yeoh [11]

2
of the International Software Benchmarking Standards of trapezoidal shapes as in Fig. 2. A set of fuzzy
Group (ISBSG) as shown in Table 2 [15]. numbers is assigned to the linguistic terms as shown in
the Table 4. The fuzzy numbers are assigned
TABLE 2 ISBSG CLASSIFICATION FOR SOFTWARE SIZING according to the percentages of reworks suggested by
Relative software Software size in in function points
size
Small Less than 100
Average From 100 to 999
Large From 1000 to 3999
Very Large Greater than 4000

On the other hand, it is expected that, as the team

experience increased the quality of the deliverables
increased resulting in a reduced amount of reworks.
Following the ISBSG classification, the levels of the
average experience is as shown in Table 3 [15].

TABLE 3 ISBSG CLASSIFICATION FOR TEAM EXPERIENCE

Experience Level Average experience in years Fig. 2 A fuzzy trapezoidal membership function (Rework)
Low Less than 1
Average From 1 to 3
High From 3 to 9
the Micro Focus’s [16] study.
Very High Greater than 9
TABLE 4 FUZZY NUMBERS (R) AND THE
CORRESPONDING LINGUISTIC TERMS
Hence, this research suggests establishing a fuzzy
model relating both the software size calculated in Fuzzy Number (R) Linguistic Term
function points and the experience level of the [0,0, 0.05, 0.10] Very Low
development team with the expected amount of [0.05,0.10, 0.15, 0.20] Low
reworks following the testing process. Fig. 1 show the [0.15,0.20, 0.25, 0.30] Average
suggested fuzzy model. [0.25,0.30, 0.35, 0.40] High
[0.35,0.40, 1, 1] Very High

On the other hand, the fuzzy inputs; software size

(SSize) and team experience (TExp) are shown in
terms of trapezoidal shapes as in Figures 3 and 4
respectively. A set of fuzzy numbers is assigned to the
linguistic terms for each one as shown in Tables 5 and
6 respectively.

Fig. 1 Reworks Estimation Fuzzy Model

The actual cost at complete (ACAC) of the

development activities including the reworks is
expressed as:
ACAC= CoD + CoR
Where CoD and CoR are the cost of development and
cost of reworks respectively.
Moreover, CoR = R x CoD, where R is the percentage
of reworks.
Hence, ACAC = CoD + R x CoD = CoD x (1 + R)

The value of R is fuzzy. Its value depends on the

results of the testing process. If the software is fully Fig. 3 A fuzzy trapezoidal membership function (SSize)
rejected then R will approach 1. Conversely, if the
deliverable is fully accepted, then R is zero. However,
if the deliverable is partially accepted/rejected, then 1>
R> 0. The fuzzy membership of R is shown in terms

3
 integrate them. The planned durations (AD), actual
durations (AD), planned cost (PC), and actual costs
(AC) are all shown in Table 8. Durations and costs are
in working-days and person-days respectively.

TABLE 8 PROJECT BASIC INFORMATION

Tasks PD AD Developers PC AC

Comp1 4 5 2 8 10
Comp2 5 6 2 10 12
Fig. 4 A fuzzy trapezoidal membership function (TExp) Comp3 11 12 4 44 48
Comp4 8 10 2 16 20
TABLE 5 FUZZY NUMBERS (SSize) AND THE Comp5 8 10 3 24 30
CORRESPONDING LINGUISTIC TERMS
Fuzzy Number (SSize) Linguistic Term System
10 8 2 20 16
[0, 0, 0.01, 0.05] Small Integration
[0.01, 0.05, 0.1, 0.15] Average Defects
N/A 13 2 0 26
[0.1, 0.15, 0.4, 0.45] Large Removal
[0.4, 0.45, 1, 1] Very Large Total 122 162

TABLE 6 FUZZY NUMBERS (TEXPE) AND THE The size of software is calculated in function points as
CORRESPONDING LINGUISTIC TERMS
shown in Table 9.
Fuzzy Number (TExp) Linguistic Term
[0, 0, 0.1, 0.15] Low TABLE 9 FUNCTION POINTS CALCULATIONS
[0.10, 0.15, 0.3, 0.35] Average
[0.3, 0.35, 0.9, 1.1] High Item # Simple # Average # Complex Total
[0.9, 1.1, 2, 2] Very High
Inputs 12 3 7 4 5 6 94
Finally, the relationship among SSize, TExp, and R Outputs 6 4 7 5 5 7 94
is expressed as in the following fuzzy rule: Internal
6 7 9 10 7 15 237
If SSize IS [Value] and TExp IS [Value] THEN R is Files
[VALUE] Interfaces 3 5 6 7 2 10 77
The set of the fuzzy rules are shown in Table 7. Inquiries 4 3 5 4 3 6 50

TABLE 7 REWORK ESTIMATION FUZZY RULES Total 552

SSize TExp R
Small Low Average From Table 9, the size of the software is equal to 552
Small Average Low function points.
Small High Very Low
Small Very High Very Low
It is give that the average experience of the
Medium Low High development team is equal to 3.28 years.
Medium Average Average Table 8 shows the following values:
Medium High Low The actual cost of defects removal = 26 person-days.
Medium Very High Very Low
Large Low Very High
The estimated development cost = 122 person-days.
Large Average High The actual development cost (without rework cost) =
Large High Average 136 person-days
Large Very High Low The actual development cost (including the rework
Very Large Low Very High
Very Large Average High
cost) = 162 person-days
Very Large High Average
Very Large Very High Low Percentage error in estimation (without rework) =
((136 – 122)/122) x 100 = 11.5 %
Percentage error in estimation (with rework) = ((162 –
V. ILLUSTRATIVE EXAMPLE
122)/122) x 100 = 32.8 %
We design a simple example illustrating the basic
calculations of the proposed model. It shows a The crisp values of SSize TExp are the inputs to the
software development project that consists of five fuzzy model.
tasks to develop five components and one task to

4
Using MatLab and applying the set of functions and International Journal of Modern Education and
rules described in Tables 4, 5, 6, and 7, the rework is Computer Science, vol. 6, no. 2, p. 41. 2014
de-fuzzified to a crisp value of 22.5% [5] Blue Print, “The rework tax: reducing software
Then, the overall development is calculated. development rework by improving requirements”,
Estimated cost (with reworks) = 1.225 x 122 = 149.5 White Paper, Blueprint Software Systems Inc.,
person-days Toronto, Canada, July 2015. Available at:
Comparing this value with value obtained from the http://www.blueprintsys.com/content/the-rework-
traditional method yields: tax-reducing-software-development-rework-by-
improving-requirements/ (Accessed: 2/7/2016)
Error in the traditional technique = 32.8%
[6] ISO/IEC/IEE Software and Systems Engineering-
Error in the proposed model = ((162 – 149.5) / 149.5)
Software Testing Part 1: Concepts and
x 100 = 8.4% definitions,", ISO/IEC/IEEE 29119-1:2013(E) ,
This example shows that using the proposed fuzzy vol., no., pp.1-64, Sept. 1 2013.
model is expected to enhance the accuracy of the [7] I. Sommerville, “Software testing” in Software
development cost estimation by incorporating the Engineering, 9th ed. Boston: Edison Wesley, 2010.
expected cost of rework. [8] P. Bourque and R. E. Fairley (eds.). Guide To
The Software Engineering Body Of Knowledge,
VI. DISCUSSION AND CONCLUSION Version 3.0: IEEE Computer Society;
www.swebok.org, 2014.
The suggested model shows the impact of the [9] T. Zimmermann, R. Premraj and A. Zeller,
software size and team experience on the cost of the "Predicting Defects for Eclipse," Predictor Models
expected rework, which is missing in the current in Software Engineering, 2007. PROMISE'07:
project management techniques. The illustrative ICSE Workshops 2007. International Workshop
example shows a reduction in the estimation error on, Minneapolis, MN, 2007, pp. 9-9. doi:
from 32.8% to 8.4%. 10.1109/PROMISE.2007.10
Incorporating the estimation of the rework cost in [10] P. Efe and O. Demirörs, "Applying EVM in a
project plans is supposed to increase the accuracy of Software Company: Benefits and Difficulties,"
2013 39th Euromicro Conference on Software
the software cost estimation and therefore enables the
Engineering and Advanced Applications,
project managers’ focus on this overlooked process.
Santander, 2013, pp. 333-340.
We are motivated to continue this research by doi: 10.1109/SEAA.2013.55
applying the proposed model using real-live data of [11] T. A. Khalid and E. T. Yeoh, "Controlling
software projects with different scales. The direction software cost using fuzzy Quality based EVM,"
of the future research is also to study factors, other Computing, Control, Networking, Electronics and
than the software size and team experience, such as the Embedded Systems Engineering (ICCNEEE),
team size and software development methodology 2015 International Conference on, Khartoum,
which may have impacts on the cost estimation of 2015, pp. 275-280.
software reworks. [12] M. Bhardwaj and A. Rana, “Estimation of Testing
and Rework Efforts for Software Development
REFERENCES Projects,” in Asian Journal of Computer Science
[1] R. N. Charette, "Why software fails" in IEEE and Information Technology, vol. 5, no. 5, pp. 33-
Spectrum, vol. 42, no. 9, pp. 42-49, Sept. 2005. 37, May 2015. doi:10.15520/ajcsit.v5i5.15.T
doi: 10.1109/MSPEC.2005.1502528 [13] Function Point Counting Practices Manual,
[2] V. R. Basili, S. E. Condon, K. El Emam, R. B. Release 4.3.1, International Function Points Users
Hendrick and W. Melo, "Characterizing and Groups (IFPUG), Netherland, Jan. 2010.
Modeling the Cost of Rework in a Library of [14] A. B. Nassif, L. F. Capretz and D. Ho, "Software
Reusable Software Components," Software Effort Estimation in the Early Stages of the
Engineering, 1997., Proceedings of the 1997 Software Life Cycle Using a Cascade Correlation
(19th) International Conference on, Boston, MA, Neural Network Model," Software Engineering,
USA, 1997, pp. 282-291. Artificial Intelligence, Networking and Parallel &
doi: 10.1145/253228.253289 Distributed Computing (SNPD), 2012 13th ACIS
[3] U. Raja and M. J. Tretter, "Defining and International Conference on, Kyoto, 2012, pp.
Evaluating a Measure of Open Source Project 589-594. doi: 10.1109/SNPD.2012.40
Survivability," in IEEE Transactions on Software [15] ISBSG Data Demographics D&E Repository,
Engineering, vol. 38, no. 1, pp. 163-174, Jan.-Feb. Release 2016 R1, International Software
2012. doi: 10.1109/TSE.2011.39 Benchmarking Standards Group (ISBSG),
[4] S. Zahra, A. Nazir, A. Khalid, A. Raana, and M.N. Australia, March 2016. Available at:
Majeed, “Performing Inquisitive Study of PM http://isbsg.org/wp-
Traits Desirable for Project Progress,” in content/uploads/2016/04/ISBSG-DE-

5
 Demographics-2016-R1.pdf (Accessed:
01/06/2016).
[16] Micro Focus, “Successful projects start with high
quality requirements”, Micro Focus International
plc , White Paper, Rockville, Maryland, Feb.
2016. Available at:
https://www.microfocus.com/media/white-
paper/WP-Successful-projects-start-with.pdf
(Accessed: 10/07/2016).