IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 1999

1

PAPER

A New Approach to Estimate Eﬀort to Update
Object-Oriented Programs in Incremental Development
Satoru UEHARA†,††a) , Nonmember, Osamu MIZUNO††b) , and Tohru KIKUNO††c) , Members

SUMMARY
In this paper we discuss the estimation of effort needed to update program codes according to given design
speciﬁcation changes. In the Object-Oriented incremental development(OOID), the requirement changes occur frequently andregularly. When a requirement change occurs, a design speciﬁcation is changed accordingly. Then a program code is updated forgiven design speciﬁcation change. In order to construct the development plan dynamically, a simple and fast estimation method of
eﬀorts for code updating is strongly required by both developers
and managers. However, existing estimation methods cannot beapplied to the OOID.
We therefore try to propose a straightforward approach toestimate eﬀort for code updating, which reﬂects the speciﬁc properties of the OOID. We list up following factors of the eﬀort estimation for OOID: (1) updating activities consist of creation,
deletion, and modiﬁcation, (2) the target to be updated has fourkinds of types(void type, basic type, library type, and customtype), (3) the degree of information hiding is classiﬁed into private, protected and public, and (4) the degree of inheritance affects updating eﬀorts.
We then propose a new formula E(P, σ) to calculate the efforts needed to update a program P according to a set of design
speciﬁcation changes σ. The formula E(P, σ) includes weighting
parameters: Wupd , Wtype , Winf -h and Winht according to thecharacteristics (1), (2), (3) and (4), respectively. Finally, we conduct experimental evaluations by applying the formula E(P, σ)to actual project data in a certain company. The evaluation results statistically showed the validity of the proposed approach
to some extent.
key words: Object-Oriented development, Incremental development process, Code updating, Eﬀort estimation

1.

Introduction

For the software development, a lot of development
paradigm has been proposed. Among them, theObject-Oriented (shortly, OO) development has highcapability that transforms the real complex things into
software products using the concept of object. The environments for the development of software productsin the OO language such as Smalltalk, C++ and JAVA
have been provided, and various techniques for the OO
development have been proposed[3], [14]. As a result,the OO development has been used widely in industries.
Manuscript received May 16, 2000.
Manuscript revised March 19, 2001.
†
The author is with NTT Data Corporation.
††
The authors are with the Graduate School of Engineering Science, Osaka University.
a) E-mail: ueharast@nttdata.co.jpb) E-mail: o-mizuno@ics.es.osaka-u.ac.jpc) E-mail: kikuno@ics.es.osaka-u.ac.jp

It is also said that the OO development is reasonable and natural to be combined with the incremental
development[8]. Because the OO paradigm makes it
easy to understand the system structure and to reuse
the previous components of other systems. We call theincremental development combined with the OO development as the Object-Oriented incremental development(shortly, the OOID).
In the OOID, since the requirement changes areissued frequently from the customers, the developers
have to update or revise so often their design or program code to prepare a new version according to the
new requirement. It is thus very important from the
management point of view to estimate the eﬀort for
updating needed by each requirement change.
Based on the accurate estimation of successive updating activity, the managers can make an adequate
re-planning of current development. So, managers haveto know how much eﬀort are needed for their updating
activities. In this paper, we try to estimate the eﬀort
for updating activities using the only data that can beobtained before coding activities start.
There are many models for the eﬀort estimation
in software development. Among them, analytic models such as COCOMO model[2] and the function point
analysis [1], and process models such as STATEMATE
system[6] are most well-known models[13]. Analytic
models consist of mathematical relationships between
selected model variables, and they support management decision making with respect to the project planning. On the other hand, process models support process improvement by providing operational guidance.
They are also utilized to estimate various features related to the eﬀort, durations and the quality of ﬁnal
product using a stochastic simulation.
There are, however, few or no methods which takethe property of the OO development into account. Furthermore, since the existing methods need a lot of
preparation for customization of methods to each individual environment, they are diﬃcult to be applied
to such a small incremental development that must be
done under the restrictive cost limitations.
Our objective is to develop an intuitive eﬀort estimation method for program code updating, which iseasily and cheaply applicable to the real development
environment when design speciﬁcation changes are derived from the requirement changes. In the method,

IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 19992

we propose a formula E(P, σ) for the eﬀort estimation
where P is a certain version of program code to be updated and σ is a set of design speciﬁcation changes.
The E(P, σ) is calculated as the sum of scores for all
activities included in an updating.
In order to deﬁne the code updating eﬀorts
E(P, σ), we have analyzed the activities for updatinga program. First, we clarify the following 4 viewpoints
to be considered in the eﬀort estimation: (1) the kindof updating activities, (2) the types of targets to be
updated, (3) the degree of information hiding and (4)the degree of inheritance. Then, we deﬁne the formulaE(P, σ) using four weighting parameters: Wupd , Wtype ,Winf -h and Winht introduced to consider (1), (2), (3)and (4), 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 the validity of our proposed method.
The rest of this paper is organized as follows: Section 2 shows an outline of our work. The key idea of
our study is explained in Section 3. The proposed eﬀort
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 this paper.
2.

Eﬀort Estimation for OOID

2.1 Incremental development
Figure 1 shows an outline of typical incremental development process[12]. Generally speaking, the incremental development process consists of rapid interactions between customers and developers. One of speciﬁc characteristics of the incremental development isthat any complete or ﬁxed requirement do not exist
before or even during the development. The developers
design and implement the product based on the customers’ requirements, and deliver a new version of program to the customers. Then, the customers test the
new version, and return the changes of requirements tothe developers. The development is iterated until thecustomers satisfy the product.
Generally speaking, it is very reasonable and natural to combine the incremental development and the
OO development. Since the OO paradigm makes it
easy to understand the system structure and reuse theprevious components of other systems, the developers
can deliver the product rapidly using the advantagesof OO development. This kind of speed-up provides agood advantage to incremental development.
2.2 Our objective
Our objective is to estimate the eﬀorts for updating pro-

InitialRequirements

Design &Implementation

V1

Test

Design &Implementation

Changes in
Requirements
V2

Test

2nd
Development
Test

Design &Implementation

Changes in
Requirements
Vn

Test

1st
Development
Test

n th
Development
Test

Final Program Vn
CustomerFig. 1Developer

Incremental development processgram codes in the OOID. Since the requirement changes
occur frequently and regularly, the eﬀort estimation for
updating activities should also be done very fast andbe easy to apply. The accurate eﬀort estimation helps
to modify development plans eﬀectively. So, the developers in the company want to use such an estimating
method that is intuitively constructed and is easy toapply.
In the OOID, design speciﬁcation changes are derived manually by the developers from given requirement changes. Of course, such activities take eﬀorts
and they are not neglectable, but the estimation of such
eﬀort is very diﬃcult. In this paper, we do not discusssuch eﬀort.
However, the activity to update program codesfrom given design changes is also diﬃcult. We therefore
try to develop a eﬀort estimation method for updating
program codes from given design speciﬁcation changes,
which has the following properties: (1) intuitive calculation: the way of estimation is intuitive for developers
or managers, (2) quick calculation: the developer andmanager can obtain the result of estimation immediately, and (3) easy calculation: the estimation method
is easy to apply in the actual development environment.
By these properties, our proposed method can help theplanning of development schedule for the next versionof the software.
2.3 Related works
In order to estimate the eﬀort for software development, many works have already been proposed. Analytic models and process models are most widely known
models[13]. Our approach is included in the analytic
model.
Kellner developed a process model based on the

UEHARA et al.: A NEW APPROACH TO ESTIMATE EFFORT FOR OO PROGRAM UPDATING

3

STATEMATE system[6] to support several management control and planning activities including development schedules, planning and task re-planning by thedeterministic and stochastic simulations. Kusumoto etal. also developed a simulator to estimate the eﬀorts
and the number of faults of the software project basedon the generalized stochastic Petri-net[9]. These process models mainly focused on understanding and controlling the software process, and dealt with changes
in the software process. However, since our objective
is to estimate eﬀorts for updating using a given design
speciﬁcation, it is not appropriate to apply them to our
purpose.
As for the analytic model, COCOMO[2] is one ofgood solutions for cost estimation in general softwaredevelopment. However, our objective mentioned in subsection 2.2 is slightly diﬀerent from that of the COCOMO. The main focus in COCOMO is upon estimating the inﬂuence of 15 cost drivers on the development
eﬀort. However, these 15 drivers do not include OO
features.
Our proposed method(to be deﬁned in Section 4)
is based on the score given to each fundamental component according to analysis of some characteristics of the
OO programs. It is thus very similar to the function
point analysis (FPA)[1] in that sense. Within the FPA,
the software is characterized by the ﬁve functions withrespect to the number of inputs/outputs or the numberof screens. These functions, however, do not include
OO features. It is thus diﬃcult to apply the FPA to
OO development directly.
We therefore have to establish a new straightforward (that is, intuitive, quick and easy) method to estimate the eﬀorts of program updating for the OOID.
3.

Essential Characteristics

In order to estimate the eﬀorts to update the programin the OOID, we chose the following 4 factors to beconsidered in the eﬀort estimation: (1) the kind of updating activities, (2) the types of targets to be updated,(3) the degree of information hiding and (4) the degreeof inheritance. The reasons why we chose those 4 factors will be explained in the following subsections.
3.1 Updating activities
The type of updating activity is considered to be inﬂuential element with the eﬀort estimation because, forexample, the eﬀorts for “creating a new class,” and“modifying an existing class” are clearly diﬀerent ingeneral. In the OOID, the target to be updated could
be classes, attributes in classes, or methods in classes.
On the other hand, the activities for updating them areclassiﬁed into three fundamental operations:
1) Creation: new creation of the target(that is, aclass, an attribute in a class and a method in aclass).
2) Deletion: deletion of the existing target(that is, theexisting class, the existing attribute or the existing
method).
3) Modiﬁcation: modiﬁcation to the existing target.
Any modiﬁcation can be expressed by one of three operations or combination of them. For example, consider acase that an attribute of a class is newly created. Thenthe operation is expressed as creation. Next, consider acase that a parameter of 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 combinationof creation and deletion.
In the formulas for eﬀorts estimation in Section 4,
we distinguish them, and assign distinct score to each
operation.
3.2 Targets to be updated
Generally, the targets(that is, the attribute or the
method in a class in this subsection) to be updated
have types, and the eﬀort to update them are diﬀerent according to their types (For example, modifying amethod with int type will take less eﬀorts than modifying a method with a user deﬁned 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.
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 deﬁned in the class library. The classes in Microsoft
Foundation Classes(MFC) are examples.
4) Custom type: Custom type is a type which is deﬁned in the developing program.
In the formulas for eﬀorts estimation, we distinguishthese types and assign distinct score to each type.
3.3 Object-Oriented paradigm
The Object-Oriented paradigm has several useful characteristics for high quality software development. They
are encapsulation, inheritance, polymorphism, multiple
inheritance and so on. Among them, we consider encapsulation and inheritance in the formulas for eﬀort
estimation.
However, we don’t take account of the other properties such as polymorphism and multiple inheritancein this paper. (When a method has several interfaces bypolymorphism, these interfaces can be translated into
several independent methods. That’s why it is considered not to be inﬂuential with the eﬀort to update programs. Similarly, since a multiple inheritance can be

IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 1999

4translated into plural inheritances, we treat the multiple inheritance as plural inheritances and count theeﬀort for each inheritance.)
3.3.1 Degree of information hiding
An aspect of the encapsulation is measured by the degree of information hiding. The degree of information
hiding by encapsulation clearly aﬀects the updating efforts, since the scopes of variables are diﬀerent according to the degree of information hiding. The following
summarizes information hiding in C++ and JAVA:
1) private: the attribute/method in a class cannot bereferred by any other classes.
2) protected: the attribute/method in a class cannot
be referred by any other classes except for its childclass.
3) public: the attribute/method in a class can be referred and used by other classes.
For example, suppose that a class has some “public”
attributes. When modifying this class, it should bechecked whether public attributes are referred from theother classes. Then more eﬀort is needed to modify thisclass.
3.3.2 Degree of inheritanceIn the Object-Oriented development, programmers cancreate a new class which inherits properties of existingclasses. The aspect of inheritance contributes to a highproductivity and helps reuse of previous components inthe other programs or class libraries.
On the other hand, the degree of inheritance isinﬂuential with the updating eﬀorts, since programmers
must pay attention to the children classes when they
update the parent class. In the formulas for the eﬀorts
estimation, we assign each class distinct score which is
proportional to the number of children classes.
4.

Formula for Eﬀort Estimation

4.1 Outline of formula
Based on the classiﬁcation in Section 3, we introduce
new formula to calculate the eﬀort needed for updating of the OO programs for given design speciﬁcation
changes.
Assume that P is a program to be updated according to design speciﬁcation changes σ. In more
precise, σ is a set of n design speciﬁcation changes
SC1 , · · · , SCn . Then P  is a resultant program thatis obtained from P by executing necessary operations
speciﬁed in SCi (1 ≤ i ≤ n). In this paper, we propose the following formula to estimate the eﬀorts for
updating program code P :n

Ereq (SCi )
i=1
mi
n 

=
Ecl (Cji )i=1 j=1
n mi pij

E(P, σ) =

=

qij
 

(
Eattr (Aij)+
Emeth (Mlij ))k
i=1 j=1 k=1

l=1

(1)
Intuitively speaking, according to design speciﬁcation change SCi , a class Cji is updated. In more detail,ijian attribute Aij
k in the class Cj and a method Ml inithe class Cj are updated. We will explain the deﬁnitionof E’s in the following sections. At this point, we cannot validate this formulation theoretically. Currently,
Equation (1) is based on the interviews with the actual
developers in a certain company.
4.2 Four kinds of eﬀorts
1) Eﬀorts to meet a design speciﬁcation change SC
Assume that m classes C1 , · · · , Cm are updated
for the design speciﬁcation change SC. The formula to estimate the eﬀorts for design speciﬁcation
change SC is deﬁned as follows:
Ereq (SC) =m

Ecl (Cj )

(2)

j=1

We explain the deﬁnition of Ecl (Cj ) in the following.
2) Eﬀorts to update a class C
Assume that updating activity of a class C consistsof updating p attributes A1 , · · · , Ap and q methods
M1 , · · · , Mq . The formula to estimate the eﬀorts
for updating the class C is deﬁned as follows:
Ecl (C)pq
Eattr (Ak ) +Emeth (Ml )
=
k=1

(3)

l=1

We explain the deﬁnition of Eattr (Ak ) andEmeth (Ml ) in the following.
3) Eﬀorts to update an attribute A
Assume that an attribute A is updated. The formula to estimate the eﬀorts for this updating isdeﬁned as follows:
Eattr (A)= α × Wupd × Wtype × Winf -h(4)

The semantics of variables are summarized as follows:a) α: a basic score for updating an attribute.

UEHARA et al.: A NEW APPROACH TO ESTIMATE EFFORT FOR OO PROGRAM UPDATING

5b) Wupd : a weight representing the diﬀerence inthe diﬃculty caused by the kind of updating
activities(see subsection 3.1).
c) Wtype : a weight representing the diﬀerencein the diﬃculty caused by the type of attribute(see subsection 3.2).
d) Winf -h : a weight representing the diﬀerencein the diﬃculty caused by the degree of information hiding(see subsection 3.3).
4) Eﬀort to update a method M
Assume that a method M is updated. The formula
to estimate the eﬀorts for this updating is deﬁned
as follows:
Emeth (M )= β × (1 + W CC(M ) + W CM (M )+W P M (M ) + Winht × N OC(C))×Wupd × Wtype × Winf -hgested[4], [5], [7], [10], [11], most of them are for a class,but not for a method. So, we suggest simple new metrics W CC, W CM , W P M and N OC which indicate
the complexity of a method.
1) W CC(Weighted Coupling Classes)
Assume that a method M includes n classes
C1 , C2 , · · · , Cn which are referred in M . We introduce the weight wCi for a class Ci , and thendeﬁne W CC as follows:
W CC(M ) =

n


wCi

i=1

In fact, the formula of W CC is a part of the deﬁnition of existing OO metric CBO[5].

(5)where variables β, Wupd , Wtype , Winf -h , Winht are
constants to represent characteristics in Section 3
and W CC(M ), W CM (M ), W P M (M ), N OC(C)are fundamental OO metrics to be deﬁned in
the next subsection. In Equation (5), metrics
W CC(M ), W CM (M ), W P M (M ) and N OC(C)are all added rather than multiplied, since they
represent internal properties in a method M andthey are independent from their deﬁnition. Furthermore, from the interviews with developers ina certain company, the eﬀorts that correspond tothese metrics are considered to be independent,
too.
The semantics of these variables are summarized
as follows:a) β: a basic score for updating a method.
b) Wupd : a weight representing the diﬀerence inthe diﬃculty caused by the kinds of updating
activities(see subsection 3.1).
c) Wtype : a weight representing the diﬀerencein the diﬃculty caused by the type of return
value(see subsection 3.2).
d) Winf -h : a weight representing the diﬀerencein the diﬃculty caused by the degree of information hiding(see subsection 3.3).
e) Winht : a basic weight representing the diﬀerence in the diﬃculty caused by the degree of
inheritance.
When we apply the proposed formula to actual development, we have to determine the values of α, Wupd ,Wtype , Winf -h in the formula (4) and β, Wupd , Wtype ,Winf -h , Winht in the formula (5). The sample valuesof these variables will be shown in subsection 5.2.
4.3 Fundamental metrics
Until now, although various OO metrics have been sug-2) W CM (Weighted Coupling Members)
Assume that a method M refers n attributes
A1 , A2 , · · · , An which are deﬁned in the same class
C. We introduce the weight wAi for an attribute
Ai , and then deﬁne W CM as follows:
W CM (M ) =

n


wAi

i=1

3) W P M (Weighted Parameters of Method)
Assume that a method M includes n parameters
P1 , P2 , · · · , Pn . We introduce the weight wPi for aparameter Pi , and then deﬁne W P M as follows:
W P M (M ) =

n


wPi

i=1

4) N OC(Number Of Children)
N OC is a part of the deﬁnition of existing OO metrics set[5]. It is a measure of how many subclasses
are going to inherit the methods of the parent class:
N OC= the number of immediate
subclasses subordinated toa class in the class hierarchy

4.4 Limitations
There are several limitations in the proposed eﬀort estimation.
1) Programming languages
We assume C++ and JAVA as programming languages in the proposed eﬀort estimation. Since
most of OO programs in the real ﬁeld are written
in C++ or JAVA, this limitation is not signiﬁcant.
2) Development process
We take account of incremental development
model rather than waterfall model. The main
reason is that the incremental development is themainstream in the OO development.

IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 1999

63) Collection of data
In order to apply our eﬀort estimation to projects,
the values of parameters must be decided before
coding phase. Since the data needed for these parameters are easy to collect, there is no serious
problem with respect to applicability.
5.

Parameter Tuning

5.1 Parameters
When a requirement change occurs, the developers inthe ﬁrst place decide which parts of the existing program are to be updated. The decision is performed
based on the analyzed 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) from the analysis. The data
give the basis for the evaluation of E(P, σ).
(1) Classes to be updated (that is, classes C1 , · · · , Cm
in Equation (2))(2) Attributes to be updated in each class Ci (that is,
attributes A1 , · · · , Ap in Equation (3))2-1) The kind of updating activity2-2) The type of the attribute2-3) The degree of information hiding
2-4) The degree of inheritance(3) Methods to be updated in each class Ci (that is,methods M1 , · · · , Mq in Equation (3))3-1) The kind of updating activity3-2) The type of the method3-3) The degree of information hiding
3-4) Concerning the metrics W CC, W CM , W P M
and N OC, the followings are deﬁned with respect to the external reference:
3-4-1) The number of parameters and theirtypes
3-4-2) The number of references to externalclasses and their types
3-4-3) The number of references to attributes in
the class Ci and their types
3-4-4) The number of subclasses
By collecting above information, we can apply the
proposed eﬀort estimation to the project.
5.2 Target project
In order to determine the values of parameters in Equation (3), we had an experiment using the data of an
actual project. In this experiment, we tuned up thevalues of parameters so that the rank correlation coefﬁcient between them becomes large.
The targeted project was a development of an
application software for a banking related system[16].

The program was written in C++ on Microsoft Windows 95/98/NT. The development was also performed
according to the OMT[14], and had three versions
V1 , V2 , V3 of the program. Table 1 shows the data which
are collected from the project. In Table 1, Vi (i = 1, 2, 3)
denotes the ith version of programs and “# of classes”
denotes the total number of classes included in Vi . The
value of LOC denotes the total lines of code excluding
the comments, and the value of Person-Days indicatesthe eﬀort needed to develop each version.
Table 1
Version
V1
V2
V3

Data from C++ project# of classes
43
53
63

LOC
6295
7765
8925

Person-Days
60
39
30

We ﬁrstly selected 20 classes, each of which was included in the ﬁrst version, V1 , and was actually updated
in V2 or V3 (We should note that, by this selection, we
delete all classes that were in V1 but were not updated
afterwards from the analysis).
We then had an interview with developers of the
project, and asked them to rank all the classes in V 1
according to the diﬃculty to modify. Table 2 shows
the ranking of diﬃculty for each modiﬁed class.
From Table 2, we can see that C1 is the most difﬁcult class to update and C2 is second. C5 and C6
are the same level, and C20 is the easiest class. We
assumed that the most diﬃcult class by developers’ intuition needs the most eﬀort to update it.
Table 2
Class
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10

Rank of diﬃculty

Rank
1
2
3
4
5
5
7
8
9
10

Class
C11
C12
C13
C14
C15
C16
C17
C18
C19
C20

Rank
11
12
12
14
15
16
17
18
19
20

5.3 Process of tuning up
We tuned up the values of parameters so that the rankof estimated eﬀort becomes almost the same as the difﬁculty of classes in Table 2. The steps for tuning up are
as follows:
Step 1 Firstly, we set initial values of parameters asshown in Table 3.
Step 2 We calculate the eﬀort for each class according
to Equation (3).

UEHARA et al.: A NEW APPROACH TO ESTIMATE EFFORT FOR OO PROGRAM UPDATING

7
Table 3

Initial values of parameters(a) Parameters for attributes (α = 1)
Wupd
Creation
Deletion
Modiﬁ.
1
1
N/A
Wtype
Basic
Library
Custom1
1
1
Winf -hPrivateProtected
Public111(b) Parameters for methods (β = 1)
Wupd
Creation
Deletion
Modiﬁ.
1
1
1
Wtype
Void Basic
Library Custom
11
1
1
Winf -hPrivateProtected
Public
1
1
1
Winht
0.1
(c) Parameters for software metrics
Basic
Library Custom
wC
N/A
0.1
0.1
wA
0.1
0.1
0.1
wP
0.1
0.1
0.1

Step 3 We then compare the diﬃculties with obtained
eﬀorts by rank correlation analysis.
Step 4 In order to acquire better rank correlation coefﬁcient, we change some values of parameters basedon some conditions, then back to Step 2. Or if thecurrent correlation coeﬃcient is considered as thebest one, accept the values of parameters.
The conditions used in Step 4 are summarized asfollows:• The eﬀort needed to create an attribute is larger
than or equal to that of deletion.
• Custom types need more eﬀorts to update thanlibrary types, and library types need more thanbasic types.
• Public attributes or methods need more eﬀorts to
update than protected ones, and protected ones
need more than private ones.
• Generally, the eﬀort to update attribute is larger
than or equal to that of to update method.
• Based on the interviews with the developers ina certain company, Wupd should be larger than
Wtype .
• Based on the interviews with the developers in acertain company, Wtype should be almost the sameas Winf -h .
• Based on the interviews with the developers in acertain company, the values of wC , wA and wP areconsidered almost the same.
(Note that these conditions are mainly based on theinterviews with the actual developers in a certain company. In the further research, we have to show thevalidity of this work empirically.)
According to these steps, we actually determinedthe values of parameters. The obtained values areshown in Table 4. Table 4(a) shows values of W upd ,Wtype , Winf -h for attribute Ai . In this case, the pa-

rameter α became 3. Table 4(b) shows values of W upd ,Wtype , Winf -h , Winht for method Mi . The parameter βbecame 1. Table 4(c) shows values of software metrics
wC , wA and wP .
The estimated eﬀort for each class, which was calculated using the values of parameters in Table 4, isshown in Table 5. The Spearman’s rank correlation coeﬃcient between estimated and actual eﬀorts for eachclass became 0.81. We thus can say that the values ofparameters are optimized well.
Table 4

Final values of parameters(a) Parameters for attributes (α = 3)
Wupd
Creation
Deletion
Modiﬁ.
10
2
N/A
Wtype
Basic
Library
Custom1
2
3
Winf -hPrivateProtected
Public123(b) Parameters for methods (β = 1)
Wupd
Creation
Deletion
Modiﬁ.
5
1
3
Wtype
Void Basic
Library Custom
1
1
2
3
Winf -hPrivateProtected
Public
1
2
3
Winht
0.1
(c) Parameters for software metrics
Basic
Library Custom
wC
N/A
0.1
0.12
wA
0.05
0.1
0.12
wP
0.05
0.1
0.12

Table 5 Eﬀorts estimation for classClass Ecl (C)Class Ecl (C)C1
1722.5
C11
159.7
C2
593.2
C12
242.2
C3
352.9
C13
129.7
C4
2346.7
C14
87.6
C5
178.9
C15
75.2
C6
169.9
C16
93.7
C7
165.5
C17
119.4
C8
113.3
C18
50.5
C9
169.9
C19
74.8
C10
258.8
C20
155.9

6.

Experimental Evaluations

In order to evaluate the validity of the proposed method
and the values of parameters shown in Table 4, we had
another experiments using the other projects’ data.
(Another possibility may be an experiment which applies the values in Table 4 to the target project data
mentioned in subsection 5.2. But since only three versions of programs were developed in the project, wecannot analyze well on this project.) In these experiments, we got the data from two development projects
of OO program. We then evaluated the correlation between the eﬀorts estimated by proposed method andactual ones for each updating activity.

IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 1999

8

6.1 Experiment A

6.1.3 Statistical analysis

6.1.1 Collected Java programs

We then evaluated statistically these estimated eﬀorts
E(P, σ) in Table 7 by comparing with actual PersonDays in Table 6.
Note that we exclude the data of V1 (initial version) from the correlation analysis. Since our objective
is to estimate the eﬀorts for updating activity, we excluded V1 because it is a new development of programsin the project† .
The correlation coeﬃcient was calculated as 0.71,
and it was statistically signiﬁcant with 1% level of signiﬁcance. Figure 2 shows the relationship between
them.

Table 6120

100
Actual Effort (Person-Days)

In the ﬁrst experiment, the targeted project was a development of an application software that shows graphical images stored in Object-oriented database[17]. The
program was written in JAVA, and it was able to run
on a WWW browser. The development was performed
according to the OMT, and 10 versions of programs
were successively developed.
Table 6 shows the data that were collected fromthe project. In Table 6, Vi (i = 1, 2, · · · , 10) denotes
the ith version of programs and “# of classes” denotes
the total number of classes included in Vi . The valueof LOC denotes the total lines of code excluding thecomments, and the value of Person-Days indicates theeﬀort needed to develop each version.
Data from a JAVA project used in experiment A

Version
V1
V2
V3
V4
V5
V6
V7
V8
V9
V10

# of classes
157
169
170
187
190
188
188
189
188
189

LOC
9197
25603
27845
28677
28916
28324
28524
28713
28722
28737

Person-Days
445
98
90
40
76
56
54
42
42
60

80

60

40

20

0
0

2000

4000

6000

8000

10000

12000

14000

16000

18000

Estimated Effort

Fig. 2

Actual eﬀorts and E(P, σ)

6.2 Experiment B
6.1.2 Eﬀort estimation using E(P, σ)
The values of parameters used in the estimating formula were the same as in Table 4. Since the development environment or the skill of the development teamof this project were almost the same as that of in subsection 5.2, we were able to apply those values of parameters to this project.
We calculated the updating eﬀort E(P, σ) for eachversion V1 , · · · , V10 by Equotion (1). The result wassummarized in Table 7.
Table 7Eﬀorts estimation for each version
VersionE(P, σ)V194271.4
V2
15843.6
V3
10002.0
V4
8384.7V56662.3
V6
9241.3
V7
2120.7
V8
1013.8
V9
242.6
V10
171.3

In the second experiment, the targeted project was adevelopment of an application software that calculates
software metrics in several programming languages.
The program was written in C++, and the size of development was about 20 KLOC. There were 9 versions
available for this experiment.
Table 8 shows the result of experiment B. In Table 8, Vi (i = 1, 2, · · · , 9) denotes the ith version of programs, the Person-hours indicates the eﬀort needed todevelop each version, and E(P, σ) shows the program
updating eﬀort.
We also evaluated statistically these estimated efforts, E(P, σ), and actual Person-hours in Table 8. The
correlation coeﬃcient was calculated as 0.83 †† , and it
was statistically signiﬁcant with 1% level of signiﬁcance.
†

Note that our estimation approach seems to be applicable logically to any versions, including an initial version,of a software development. The initial version, however, has
special activities such as designing the algorithms and implementing highly reusable components, which may not be
represented in the proposed formula. That’s why we exclude
the initial version of the development from experiments.
††
We also exclude the initial version from calculation of
the correlation coeﬃcient.

UEHARA et al.: A NEW APPROACH TO ESTIMATE EFFORT FOR OO PROGRAM UPDATING

9
Table 8Result of experiment B

Version
V1
V2
V3
V4
V5
V6
V7
V8
V9

Person-hours
335.8
33.2
71.8
15.3
105.2
13.3
33.7
41.3
20.5

E(P, σ)19951.3
1212.52604.71213.42425.8
575.9
699.6
546.5
301.0

From these result of experiments A and B, we cansay that there is high correlation between eﬀorts calculated by the proposed formula and actual ones. Thatis, we can conﬁrm that the eﬀort estimation using thevalues of parameters in Table 4 is useful for the otherdevelopment project.
7.

Conclusion

We have proposed a new eﬀort estimation method
which tries to implement intuitive, quick and easy calculation. The proposed method is designed based on
the characteristics of the OOID. The two experimental
evaluations show that the proposed formulas and thesample weights have a certain extent of validity.
Our future works include the following:(1) More considerations on the weight assignment
are needed. Especially, theoretical basement forweight must be established or at least some empirical data are needed to validate it.
(2) We have to apply the proposed method to much
more software development projects. If possible,
we should collect practical project data and apply
the proposed method to the collected data.
References[1] A. J. Albrecht and J. E. Gaﬀney, “Software function, sourcelines of code, and development eﬀort prediction: a software
science validation,” IEEE Trans. Software Eng., vol.9, no.6,
pp.639–648, 1983.
[2] B. W. Boehm, Software Engineering Economics, PrenticeHall, 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 uniﬁed framework for coupling measurement in object-oriented systems,”
IEEE Trans. Software Eng., vol.25, no.1, pp.91–121, 1999.
[5] S. R. Chidamber and C. F. Kemerer, “A metrics suite forobject oriented design,” IEEE Trans. Software Eng., vol.20,
no.6, pp.476–493, 1994.
[6] M. I. Kellner, “Software process modeling support for management planning and control,” Proc. 1st International
Conference on the Software Process, pp.8–28, 1991.
[7] E. M. Kim, “Program complexity metric and safety veriﬁcation method for object-oriented software development,”
PhD. dissertation, Osaka University, January, 1997.
[8] P. Kruchten, The rational uniﬁed process: An introduction,
Addison-Wesley, 1999.

[9] 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.
[10] W. Li and S. Henry, “Object-oriented metrics that predictmaintainability,” Journal of Systems and Software, vol.23,
pp.111–122, 1993.
[11] M. Lorenz and J. Kidd, Object Oriented Software Metrics,
Prentice Hall, 1994.
[12] J. Martin, Rapid Application Development, Macmillan
Publishing Company, 1991.
[13] D. M. Raﬀo, “Evaluating the impact of process improvements quantitatively using process modeling,” Proc. CASCON93, vol.1, pp.290–313, 1993.
[14] J. Rumbaugh, Object-Oriented Modeling and Design, Prentice Hall, 1991.
[15] I. Sommerville, Software Engineering, Addison-Wesley,
1992.
[16] S. Uehara, O. Mizuno, Y. Itou and T. Kikuno, “An MVCbased analysis of object-oriented system prototyping forbanking related GUI applications – Correlationship between OO metrics and eﬀorts for requirement change –,”Proc. 4th International Workshop on Object-Oriented Realtime Dependable Systems, pp.91–104, 1999.
[17] S. Uehara, O. Mizuno and T. Kikuno, “A straightforward
approach to eﬀort estimation for updating programs in
object-oriented prototyping development,” Proc. 6th AsiaPaciﬁc Software Engineering Conference, pp.144–151, 1999.

Satoru Uehara
was born in 1971. Hereceived B.E. degree in information andcomputer sciences from Osaka University
in 1993. He has been working for NTT
DATA Corporation, and has been engaged in the development of client-server
systems. He is currently a Ph.D course
student in the Department of Informatics and Mathematical Science, Graduate
School of Engineering Science, Osaka University. His research interests include software metrics, object-oriented development methodologies.

Osamu Mizuno
was born in 1973. Hereceived B.E. and M.E. degrees in information and computer sciences from Osaka
University in 1996 and 1998, respectively.
He has been working for Osaka University
since 1999. He is currently a Research associate in the Department of Informatics
and Mathematical Science at Osaka University. His research interests include thesoftware process and the software quality
assurance technique. He is a member of
the IEEE.

Tohru Kikuno
was born in 1947.
He received M.S. and Ph.D. degrees from

IEICE TRANS. INF. & SYST., VOL.E82–??, NO.1 JANUARY 1999

10

Osaka University in 1972 and 1975, respectively. He joined Hiroshima University from 1975 to 1987. Since 1990, he
has been a Professor in the Department
of Informatics and Mathematical Scienceat Osaka University. His research interests include the quantitative evaluation ofsoftware development processes and theanalysis and design of fault-tolerant systems. He served as a program co-chair of the 1st International
Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’98) and of the 5th International Conference on RealTime Computing Systems and Applications (RTCSA’98). He
also served as a general co-chair of the 2nd International Symposium on Object-Oriented Real-Time Distributed Computing(ISORC ’99).