A Straightforward Approach to Effort Estimation for Updating Programsin Object-Oriented Prototyping Development
Satoru Uehara, Osamu Mizuno and Tohru Kikuno
Department of Informatics and Mathematical Science,
Graduate School of Engineering Science, Osaka University, Japan
fs-uehara, o-mizuno, kikunog@ics.es.osaka-u.ac.jp

Abstract
In this paper we discuss estimation of efforts needed to
update programs according to a given requirement change.
In the Object-Oriented prototyping development(shortly the
OO prototyping), the requirement changes occur frequently
and regularly. Thus a simple and fast estimation of efforts isstrongly required by both developers and managers. However, existing estimation methods cannot be applied to the
OO prototyping.
Therefore we will try to propose a straightforward approach to effort estimation, which reflects the specific properties of the OO prototyping. First, we analyze the following
characteristics of the OO prototyping: (1) updating activities consist of creation, deletion and modification, (2) thetarget to be updated has four kinds of types(void type, basic
type, library type and custom type) and (3) the degree of
information hiding is classified into private, protected andpublic.
Then, we present a new formula E (P;  ) to calculate theefforts needed to update a program P according to a setof requirement changes  . The formula E (P;  ) includes
weighting parameters: wupd , wtype and winf -h according
to the characteristics (1), (2) and (3), respectively. Finally,
we conduct experimental evaluations by applying the formula E (P;  ) to actual project data in a certain company.
The evaluation results prove statistically to some extent thevalidity of the proposed approach.

1 Introduction
For the software development, a lot of development
paradigm has been proposed. Among them, the ObjectOriented(OO) development, shortly the OO development,
has such high capability that transforms the real complex
things into software products using the concept of object.
The environments of development of software products in

the OO language such as Smalltalk, C++ and JAVA havebeen provided, and various techniques for the OO development have been proposed[3, 12]. As a result, the OO
development has been widely used in industries.
It is also said that the OO development is reasonable andnatural to be combined with rapid prototyping[10, 13]. Because the OO paradigm makes it easy to understand thesystem structure and to reuse the previous components ofother systems. We call the rapid prototyping combined with
the OO development as the Object-Oriented prototyping development(shortly, the OO prototyping).
In the OO prototyping, it is very important from the management point of view to estimate the cost for updating
needed by each requirement change. Since the requirementchanges are issued frequently from the customers, the developers have to update or revise so often their design orprogram code to prepare a new version for new requirement.
Based on an accurate estimation of successive updating
activity, the developers can achieve not only high productivity but also high quality of the program code[11]. So
managers have to know how much their updating activities
are needed. In this paper we try to estimate the cost for
updating activities using the only data that can be obtained
before coding activities start.
Although there are many models and methods for costestimation in software development, such as COCOMO
model[2] and the function point method[1], there are little methods which take the property of the OO development
into account. Furthermore, since the existing methods needa lot of preparation with respect to customization of methods to the environments, it is difficult to apply in such asmall development that must be done under the restrictive
cost limitations.
Our objective is to propose a straightforward approach toestimate efforts for updating programs in the OO prototyping
development. In other words, we aim to develop an intuitive
estimation method which is easily and cheaply applicableto the real development environment. In the method, wepresent a formula E(P;  ) for the effort estimation where P
is a certain version of program to be updated and  is a set of
requirement changes. The E(P;  ) is calculated as the sumof scores for all activities included in updating.
In order to define the efforts E(P;  ), we have analyzed
the activities for updating a program. First, we clarify thefollowing three viewpoints: (1) the kind of updating activities, (2) the types of targets to be updated, and (3) the degreeof information hiding. Then we define the formula E(P;  )using three weighting parameters: wupd , wtype and winf -hintroduced to consider (1), (2) and (3), respectively.
Finally we perform experimental evaluation of our proposed method. We apply the formula E(P;  ) to two actual
project data in a certain company. The statistical analysis on
the results of these experiments shows to a certain extent thevalidity of our proposed method.
The rest of this paper is organized as follows: Section 2shows an outline of our work. The key idea of our study
is explained in Section 3. The proposed cost estimating
method is shown in Section 4, and sample values for weighting parameters are given in Section 5. Section 6 shows two
experiments for evaluation. Finally Section 7 concludes thispaper.

2 Effort Estimation for Prototyping
2.1 Prototyping Development
Figure 1 shows an outline of typical prototyping
process[10]. Generally speaking, the prototyping development process consists of the rapid interactions between
customers and developers. One of specific characteristics ofthe prototyping is that any complete or fixed specifications
do not exist during the development. The developers design
and implement the product based on the customers’ requirements, and deliver the prototype of program to the customers.
Then the customers try to test the prototype, and return thechanges of requirements to the developers. The development
is iterated until the customers satisfy the program.
Generally speaking, it is very reasonable and natural
to combine the prototyping development and the objectoriented development. Since the object-oriented paradigm
makes it easy to understand the system structure and reuse theprevious components of other systems, the developers candeliver the product rapidly using the advantages of objectoriented development. This kind of speed-up provides agood advantage to prototyping development.
In the afterwards, we call the prototyping development
combined with the Object-Oriented development as the
Object-Oriented prototyping development(shortly, the OO
prototyping).

InitialRequirements
Test

Design &Implementation
V1

V2

Test

2nd
Development

Design &Implementation

Changes in
Requirements
Test

1st
Development

Design &Implementation

Changes in
Requirements
Test

Test

Vn

Test

n th
Development

Final Program Vn
CustomerDeveloper

Figure 1. Development process

2.2

Our Objective

Our objective is to estimate the efforts for updating programs in the OO prototyping development. Since the requirement changes occur frequently and regularly, the costestimation for updating activities should also be done very
fast and be easy to apply. Although the accurate cost estimation helps increasing quality and productivity, the developers
in the industry really want to use such an estimating methodthat is intuitively constructed and is easy to apply.
We aim to develop an estimation method considering thefollowing properties from the practical point of view: (1)intuitive calculation: the way of estimation is intuitive fordevelopers or managers, (2) quick calculation: the developer
and manager can obtain the result of estimation immediately,and (3) easy calculation: the estimation method is easy toapply in the actual development environment.

2.3

Related Works

The traditional model such as COCOMO[2] is one ofgood solutions for cost estimation in general software development. However, our objective mentioned in subsection
2.2 is slightly different from that of the COCOMO. Since
the COCOMO is a regression curve based model and aims
to accurate estimate, it is difficult for general developers tounderstand and apply it.
On the other hand, Kusumoto et al. developed a simulator
to estimate the efforts and faults of the software project[7].

However, their simulator was targeted to the standard waterfall model, so it is hard to apply the simulator to theprototyping development.
Our proposed method(to be defined in Section 4) is basedon the score given to each fundamental component according
to analysis of some characteristics of the OO programs. So it
is very similar to the function point method[1] in that sense.
However, the function point method is not easy to apply the
OO development directly, since the function point method
must deal with the number of inputs/outputs or the numberof screens.
Therefore we have to establish a new straightforward(thatis, intuitive, quick and easy) method to estimate the efforts
for the object-oriented prototyping development.

3 Three Essential Characteristics
3.1 Updating Activities
In the OO prototyping development, the target to be updated could be classes, attributes in classes, or methods inclasses. On the other hand, the activities for updating them
are classified into three fundamental operations:2) Basic type: Basic type is a type which is originallyinstalled in the OO language. In C++ and JAVA, int
and char are examples.
3) Library type: Library type is a type which is defined in
the class library. The classes in Microsoft Foundation
Classes(MFC) are examples.
4) Custom type: Custom type is a type which is defined in
the developing program.
In the formulas for efforts estimation, we distinguish thesetypes and assign distinct score to each type.

3.3

The Object-Oriented paradigm has several useful properties for a large scale software development. Among them,
encapsulation is one of the most important properties in the
OO paradigm. The degree of information hiding clearly affects the updating efforts, since the scope of variables varies
according to it. The following summarizes information hiding in C++ and JAVA:
1) private: the attribute/method in a class cannot be referred by any other classes.
2) protected: the attribute/method in a class cannot bereferred by any other classes except for its child class.

1) Creation: new creation of the target(that is, a class, anattribute in a class and method in a class).
2) Deletion: deletion of the existing target(that is, theexisting class, the existing attribute or the existing
method).
3) Modification: modification to the existing target.
Any modification can be expressed by one of three operationsor the combination of them. For example, consider a case thatan attribute of a class is newly created. Then the operation isexpressed as creation. Next, consider a case that a parameterof a method is added. Then a sequence of the operations
can be considered: an existing method is deleted and a new
method with a new parameter is created. Thus it is expressed
as combination of creation and deletion.
In the formulas for efforts estimation in Section 4, wedistinguish them, and assign distinct score to each operation.

Degree of Information Hiding3) public: the attribute/method in a class can be referredand used by other classes.

4

New Formula for Effort Estimation

4.1

A New Formula

Based on the classification in Section 3, we introduce new
formula to calculate the effort needed for updating of the OO
programs.
Assume that P is a program to be updated according torequirement changes  . In more precise,  is a set of nrequirement changes R1 ; 1 1 1 ; Rn . Then P 0 is a resultant
program that is obtained from P by executing necessary
operations specified in Ri (1  i  n). In this paper, we
propose the following formula to estimate the efforts for
updating program P :3.2 Types of Target to be Updated
Generally, the target(that is, the attribute or the method
in a class in this subsection) to be updated has a type, andthe effort to update it varies with its type. The types are
categorized as follows:
1) Void type: Void type is a type which has no return value.
In C++ and JAVA, void is an example.

E(P; ) =
=

XE
R
=
XXE C
= =
XX XE A XEnrequirement ( i )i 1n mclass ( j )i 1j 1
n m

=

p

(

i=1 j =1 k=1q

attribute ( k ) +l=1

method (Ml ))Intuitively speaking, according to requirement change Ri ,a class Cj is updated. In more detail, an attribute Ak in theclass Cj and Ml in the class Cj are updated. We will explain
the definition of E ’s in the successive sections.

4) Efforts to update an attribute A

Assume that an attribute A is updated. The formula
to estimate the efforts for this updating is defined asfollows:

Eattribute (A)4.2 Efforts for Updating=

1) Efforts to meet a requirement change R

XE
m

j =1

class (Cj )

a)

XE
p

=

k =1

A

attribute ( k ) +

XE
q

l=1

method (Ml ) (2)3) Effort to update a method M

Emethod(M )=wupd 2 wtype 2 winf -h
2(1 + W CC (M ) + W CM (M ) + W P M (M ))2(3)where variables , wupd , wtype , winf -h are constants
to represent characteristics in Section 3 and W CC ,WCM , W P M are fundamental OO metrics to be defined in the next subsection. The semantics of thesevariables are summarized as follows:a)d) winf -h : a weight representing the difference inthe difficulty caused by the degree of information
hiding(see subsection 3.3).
When we apply proposed formula to actual development,
we have to determine the values of , wupd , wtype , winf -h informula (3) and , wupd , wtype , winf -h in formula (4). The
sample values of these variables will be shown in subsection
5.2.

4.3

Assume that a method M is updated. The formula toestimate the efforts for this update is defined as follows:: a basic score for updating a method.

b) wupd : a weight representing the difference in the
difficulty caused by the kinds of updating activities(see subsection 3.1).
c) wtype : a weight representing the difference in the
difficulty caused by the type of return value(seesubsection 3.2).
d) winf -h : a weight representing the difference inthe difficulty caused by the degree of information
hiding(see subsection 3.3).

: a basic score for updating an attribute.

c) wtype : a weight representing the difference inthe difficulty caused by the type of attribute(seesubsection 3.2).

2) Efforts to update a class C

Eclass (C )(4)b) wupd : a weight representing the difference in the
difficulty caused by the kind of updating activities(see subsection 3.1).

(1)

Assume that updating activity of a class C consistsof updating p attributes A1 ; 1 1 1 ; Ap and q methods
M1 ; 1 1 1 ; Mq . The formula to estimate the efforts for
updating the class C is defined as follows:

wupd 2 wtype 2 winf -h

The semantics of variables are summarized as follows:

Assume that m classes C1 ; 1 1 1 ; Cm are updated for therequirement change R. The formula to estimate theefforts for requirement change R is defined as follows:
Erequirement (R) =2

Fundamental Metrics

Until now, although various OO metrics have beensuggested[4, 5, 6, 8, 9], most of them are for a class, notfor a method. So, we suggest simple new metrics W CC ,W CM , W P M which indicate complexity of a method.
1) WCC(Weighted Coupling Classes)
Assume that a method M includes n classes
C1 ; C2 ; 1 1 1 ; Cn which are referred in M . We introduce the weight wCi for a class Ci , and then define
WCC as follows:
WCC(

M) =

X wC
n

i =1

i

In fact, the formula of WCC is a part of the definitionof existing OO metrics CBO[5].
2) WCM(Weighted Coupling Members)
Assume that a method M refers n attributes
A1 ; A2 ; 1 1 1 ; An which are defined in a class C . We
introduce the weight wAi for an attribute Ai , and thendefine WCM as follows:

X wA
M
n

WCM(

)=

i=1

i

3) WPM(Weighted Parameters of Method)
Assume that a method M includes n parameters
P1 ; P2 ; 1 1 1 ; Pn . We introduce the weight wPi for aparameter Pi , and then define WPM as follows:
WPM(M ) =

X wP
n

i=1

i

5 Case Study
5.1 Parameters to be Calculated
When a requirement change occurs, the developers in thefirst place decide which parts of the existing program are to
be updated. The decision is performed based on the analysis results of various Object-Oriented design documents.
Although they never know how many lines of codes are to
be updated, they can get the following data (1)-(3) fromthe analysis. The data give the basis for the evaluation ofE (P; ).

5.2

Sample Values for Weight

Here, we determine the values of weights explained insubsection 4.2. The values are shown in Table 1. These
values of weights are obtained by means of questionnaires
to the developers in a certain company. Since these weights
are not determined by formal way, we have to evaluate thevalidity of values by some experiments in Section 6.
Table 1(a) shows values of wupd , wtype , winf -h for attribute Ai . In this case we set basic score = 1:0. Next
Table 1(b) shows values of wupd , wtype , winf -h for method
Mi . In this case we set basic score = 1:0. Then Table 1(c)shows values of wC , wA, wP for software metrics.

Table 1. Sample weight
wupd

Creation Deletion
1.0
0.2

Modifi.
N/A

wtype

Basic
1.0

Custom1.2

Library
1.1(1) Classes to be updated (that is, classes C1 ; 1 1 1 ; Cm informula (1))

winf-hPrivate Protected Public
1.0
1.0
1.0
(a) Attribute (Basic score α = 1.0)

(2) Attributes to be updated in each class Ci (that is, attributes A1 ; 1 1 1 ; Ap in formula (2))

wupd

Creation Deletion
1.0
0.2

wtype

2-1) The kind of updating activity

winf-h2-2) The type of the attribute

Void
1.0

Basic
1.0

Modifi.
0.8
Library
1.2

Custom1.5

Private Protected Public
0.8
0.8
1.0
(b) Method (Basic score β = 2.0)2-3) The degree of information hiding(3) Methods to be updated in each class Ci (that is, methods
M1 ; 1 1 1 ; Mq in formula (2))

wC
wA
wP

3-1) The kind of updating activity

Basic
Library Custom
0.01
0.01
0.01
0.01
0.01
0.01
0.02
0.03
0.03
(c) Metrics WCC, WCM, WPM

3-2) The type of the method3-3) The degree of information hiding
3-4) Concerning the metrics W CC , W CM , W P M ,the followings are defined with respect to the external reference:
3-4-1) The number of parameters and their types
3-4-2) The number of references to external classes
and their types
3-4-3) The number of references to attributes in theclass Ci and their types
By collecting above information, we can apply the proposed effort estimation to the project.

6

Experimental Evaluation

In order to evaluate the validity of proposed method fromtwo distinct aspects, we have two experiments based on different data sets. In Experiment 1, we use a set of JAVA
programs. We evaluate the correlation between the effort
obtained by proposed method and actual one for each updating activity. Next, in Experiment 2, we use a set of C++
programs. Then we evaluate whether the effort obtainedby proposed method for each class reflects the difficulty ofclass, or not.

6.1 Experiment 1
Table 3. Efforts estimation for version
Version E(P,σ)
3523.7V1
1084.7
V2
632.9
V3
528.1
V4
V5
375.5
715.5
V6
209.3
V7
90.0
V8
31.6
V9
22.1
V10

6.1.1 Collected JAVA Programs
In the first experiment, the target project is a developmentof application that shows graphical images stored in ObjectOriented database. The program is written in JAVA, and it
can run on WWW browser. The development was performed
according to the OMT[12], and 10 versions of programs weresuccessively developed.
Table 2 shows data which are collected from the project.
In the table Vi (i = 1; 2; 1 1 1 ; 10) denotes the ith version,# of classes denotes the number of classes included in Vi .
The value of LOC implies the lines of code excluding thecomments, and the value of Person-Days indicates the efforts
needed to develop each version.

6.1.2 Effort Estimation using E(P;  )In this experiment, we will investigate the correlation between efforts obtained by proposed method and actual efforts. Thus we calculate the updating effort E(P;  ) for all
versions V1 ; 1 1 1 ; V10 . The result is summarized in Table 3.
6.1.3 Statistical Analysis
Here we perform the correlation analysis between estimatedefforts E(P;  ) in Table 3 and actual Person-Days in Table
2. Note that we exclude the data of V1 from the correlation
analysis. Since our objective is to estimate the efforts for
updating activity, we have to exclude V1 because it is a new
development of programs in the project.
The correlation coefficient is calculated as 0.68. Figure 2
shows the relationship between them.
From the result of analysis, we can say that there is highcorrelation between efforts calculated by proposed formulaand actual ones.

Actual Efforts (Person-Days)

120

Table 2. Data from JAVA project
Version # of classes LOC Person-Days
V1
157
9197
445
V2
169
25603
98
170
27845
90
V3
187
28677
40
V4
V5
190
28916
76
188
28324
56
V6
V7
188
28524
54
V8
189
28713
42
188
28722
42
V9
V10
189
28737
60

100
80
R2 = 0.4579
60
40
20
0
0

200

400

600

Estimated efforts

800

1000

1200

E(P,σ)

Figure 2. Actual efforts and E (P;  )6.2

Experiment 2

6.2.1

Collected C++ Programs

In the second experiment, the target project is a developmentof application for a banking related system[14]. The program
was written in C++ on Microsoft Windows 95/98/NT. The
development was also performed according to the OMT, andhas three versions V1 ; V2 ; V3 of program. Table 4 shows data
which are collected from the project.
6.2.2

Effort Estimation for Eclass (C )In this case, the number of versions is only 3, and is sosmall. Thus we take notice of classes rather than versions
and investigate, for each class, the correlation between theamounts of efforts obtained by proposed method and the
difficulty assigned by interview with the developers.
Thus we select 20 classes, each of which is included in
the first version V1 and is actually updated in V2 and V3 (Weshould note that, by this selection, we delete from the analysis

Table 4. Data from C++ project
Version # of classes LOC Person-Days
43
6295
60
V1
V2
53
7765
39
63
8925
30
V3

Table 6. Rank of difficulty
Class
Rank
Class
Rank
C1
1
C11
11
C2
2
C12
12
C3
3
C13
12
4
C14
14
C4
C5
5
C15
15
C6
5
C16
16
C7
7
C17
17
C8
8
C18
18
C9
9
C19
19
10
C20
20
C10

all classes that are in V1 but are not updated afterwards). Then
we calculate the updating effort Eclass (Ci ) (See formula (2))
for classes C1 ; 1 1 1 ; C20 . The calculated result is shown in
Table 5.

Table 5. Efforts estimation for classClass Eclass(C) Class Eclass(C)
C1
23.5
C11
8.3
C2
41.7
C12
11.0
C3
16.6
C13
8.6
C4
31.7
C14
5.7
C5
9.6
C15
3.3
C6
12.4
C16
5.9
8.6
C17
9.5
C7
C8
5.8
C18
3.0
C9
7.6
C19
4.9
8.4
C20
13.7
C10

6.2.3 Statistical Analysis
First, we had an interview with developers of target projectin Experiment 2, and asked them to rank all the classes in
V1 according to the difficulty to modify. Table 6 shows the
ranking of difficulty for each modified class.
From this table, C1 is the most difficult class to update andC2 is second. C5 and C6 are the same level. Finally, C20 isthe easiest class.
Then we perform the rank correlation analysis for the data
in Table 5 and Table 6. First, we make a null hypothesis H0 :there is no correlation between the rank of difficulty and thecalculated efforts. As the result of analysis, the Spearman’srank correlation coefficient between them was 0.63. This
result indicates that we can reject the null hypothesis H0 (Thelevel of significance was chosen as 0.5%). Hence, we cansay that the proposed weighting formulas can represent thedifficulty of each class with respect to updating at a certain
extent.

7

Conclusion

We have proposed a new cost estimation method whichtries to implement intuitive, quick and easy calculation. The
proposed method is designed based on the characteristicsof the OO prototype development. The two experimental
evaluations show that the proposed formulas and the sample
weights have a certain extent of validity.
Our future works include the following:(1) More considerations on the weight assignment areneeded. Especially, theoretical basement for weightmust be established or at least some empirical data areneeded to validate it.
(2) We have to apply the proposed method to much more
software development projects. If possible, we shouldcollect practical project data and apply to the collected
data.

References[1] A. J. Albrecht and J. E. Gaffney: “Software Function, Source Lines of Code, and Development Effort
Prediction: A Software Science Validation,” IEEE
Transactions of Software Engineering, Vol.9, No.6,
pp.639–648, 1983.
[2] B. W. Boehm: Software Engineering Economics,
Prentice-Hall, 1981.
[3] G. Booch: Object Oriented Analysis and Design With
Applications, The Benjamin/Cummings, 1994.
[4] L. C. Briand, J. W. Daly and J. K. Wüst: “A Unified
Framework for Coupling Measurement in ObjectOriented Systems,” IEEE Transactions on Software
Engineering, Vol.25, No.1, pp.91–121, 1999.

[5] S. R. Chidamber and C. F. Kemerer: “A Metrics
Suite for Object Oriented Design”, IEEE Transactions
on Software Engineering, Vol.20, No.6, pp.476–493,
1994.
[6] E. M. Kim: “Program Complexity Metric and Safety
Verification Method for Object-oriented Software Development,” PhD. Dissertation, Osaka University,
January, 1997.
[7] S. Kusumoto, O. Mizuno, Y. Hirayama, T. Kikuno,
Y. Takagi and K. Sakamoto: “A New Project Simulator Based on Generalized Stochastic Petri-Net,” Proc.
19th International Conference on Software Engineering, pp.293–303, 1997.
[8] W. Li and S. Henry: “Object-oriented Metrics That
Predict Maintainability,” Journal of Systems and Software, Vol.23, pp.111–122, 1993.
[9] M. Lorenz and J. Kidd: Object Oriented Software
Metrics, Prentice Hall, 1994.
[10] J. Martin: Rapid Application Development, Macmillan Publishing Company, 1991.
[11] O. Mizuno, T. Kikuno, K. Inagaki, Y. Takagi and K.
Sakamoto : “Analyzing Effects of Cost Estimation
Accuracy on Quality and Productivity,” Proc. of 20th
International Conference on Software Engineering,pp.410–419, 1998.
[12] J. Rumbaugh: Object-Oriented Modeling and Design, Prentice Hall, 1991.
[13] I. Sommerville: Software Engineering, AddisonWesley, 1992.
[14] S. Uehara, O. Mizuno, Y. Itou and T. Kikuno: “AnMVC-based analysis of object-oriented system prototyping for banking related GUI applications – Correlationship between OO metrics and efforts for requirement change –,” Proc. of 4th International Workshop
on Object-Oriented Real-time Dependable Systems,
pp.91–104, 1999.