DEVELOPMENTAL SIZE ESTIMATION FOR OBJECT-ORIENTED SOFTWARE BASED ON ANALYSIS MODEL

DEVELOPMENTAL SIZE ESTIMATION

FOR OBJECT-ORIENTED SOFTWARE BASED

ON ANALYSIS MODEL

CHAMUNDESWARI ARUMUGAM* and CHITRA BABU†

Department of Computer Science and Engineering

Sri SivaSubramaniya Nadar College of Engineering

Rajiv Gandhi Salai, SSN Nagar, Tamil Nadu � 603 110, India*[email protected]

†[email protected]

Received 7 November 2011

Revised 7 July 2012

Accepted 7 September 2012

Software size estimation at the early analysis phase of software development lifecycle is crucial

for predicting the associated e®ort and cost. Analysis phase captures the functionality addressedin the software to be developed in object-oriented software development life-cycle. Uni¯ed

modeling language captures the functionality of the software at the analysis phase based on use

case model. This paper proposes a new method named as use case model function point toestimate the size of the object-oriented software at the analysis phase itself. While this approach

is based on use case model, it also adapts the function point analysis technique to use case

model. The various features such as actors, use cases, relationship, external reference, °ows, and

messages are extracted from use case model. Eleven rules have been derived as guidelines toidentify the use case model components. The function point analysis components are appro-

priately mapped to use case model components and the complexity based on the weightage is

speci¯ed to calculate use case model function point. This proposed size estimation approach has

been evaluated with the object-oriented software developed in our software engineering labo-ratory to assess its ability to predict the developmental size. The results are empirically analysed

based on statistical correlation for substantiating the proposed estimation method.

Keywords: Object-oriented software; use case model; function point; analysis; software

estimation.

1. Introduction

Developmental size of software can be de¯ned as the size of the software that involves

coding for realizing the functionality but not including the coding related to testing.

This size can be predicted at the analysis phase in the software development life cycle.

Function Point Analysis (FPA) is a widely used method for this purpose. It was

International Journal of Software Engineering

and Knowledge Engineering

Vol. 23, No. 3 (2013) 289�308

#.c World Scienti¯c Publishing CompanyDOI: 10.1142/S0218194013500083

289

Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

http://dx.doi.org/10.1142/S0218194013500083

initially proposed [1] to estimate the software size based on the functionality from the

requirements speci¯cation, independent of the technology used to build the software. It

contains ¯ve components that are estimated based on the functionality. In addition,

Value Adjustment Factor (VAF) was evaluated from 14 Technical Complexity Fac-

tors (TCF). FPA has been approved by International Function Point User Group

(IFPUG) [35] and it has become a standard for size estimation. It is widely accepted in

software industry as a superior metric compared to the naïve Lines of Code.FPA method cannot be directly applied to Object Oriented (OO) software [25, 4]

due to the mismatch in the features supported by OO. However, this method can be

suitably adapted for estimating the developmental size of OO software. Many

researchers have proposed the adaptation of FPA for OO software size estimation

using Uni¯ed Modeling Language (UML) diagrams such as object model [4, 9, 34].

These approaches estimate the developmental size of the OO software by mapping the

various key features of the object model to the FPA components. Alternatively, e®orts

have been made to estimate the developmental size based on the analysis model, Use

Case Model (UCM) in terms of use case points [19, 21, 13] or use case size points [22].

UCM provides more appropriate information in the analysis phase of the software

development life cycle compared to any other model and consequently provides

adequate support for estimation. However, the earlier works are only based on the

use case diagram and did not make use of the information available through the use

case documentation. In addition to this, even though use case points and use case size

points are size estimation methods based on the use case diagram, they do not adhere

to any standard. On the other hand, FPA is standardized by IFPUG. Hence, it would

be bene¯cial to combine the advantages of UCM as well as those of FPA for de-

velopmental size estimation.

The objective of this paper is to propose a developmental size estimation method

called Use Case Model Function Point (UCMFP) by suitably adapting the FPA

method to UCM. This has been achieved by extracting the necessary information

from UCM and deriving the essential components for estimation. The FPA com-

ponents are suitably mapped to the derived UCM components and the formulae for

size estimation have been derived. The proposed estimation method has been applied

on sample OO projects and the results are empirically evaluated to analyse the

accuracy of the estimation.

The remainder of this paper is organized as follows. Section 2 surveys the work

related to developmental size estimation of OO software. In Sec. 3, a developmental

size estimation approach which adapts FPA to the UCM is presented. Section 4

discusses the case study. Section 5 discusses the empirical analysis and Sec. 6 con-

cludes and suggests possible future directions.

2. Related Work

Quantitative developmental size estimation for OO software has been the focus

of many researchers. It has been dealt during the various phases of the software

290 C. Arumugam & C. Babu

Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

development life cycle such as analysis [15, 4, 14, 17, 34], design [25, 29, 34] and

development [30, 26, 23]. As already mentioned, the FPA method cannot be directly

used for estimating the developmental size of the OO software [15, 4, 25, 17, 34].

Hence, it has to be suitably adapted.

Antoniol et al. [4] proposed a OO Function Point (OOFP) method, by

adapting the traditional FPA method for estimating the size of the OO software

at the OO analysis and the design phase based on the object model. Four di®erent

ways to identify logical ¯les based on a single class alone and relationships such as

aggregation, inheritance and their combination, between classes were de¯ned.

Rules were de¯ned to identify the transactional functions and measure the com-

plexity of the various methods in the class diagram. However, the inherited data

was not considered to evaluate the complexity of the logical ¯les in the inherited

methods. A precise de¯nition of external logical ¯les was also absent in this work.

Further, the rationale behind the grouping of classes was somewhat ambiguous

and this resulted in variations in OOFP depending on how the grouping rules

were interpreted.

Janaki Ram et al. [25] proposed the OO Design Function Point (OODFP)

method, from the designer's perspective at the design phase based on the object

model. FPA components were mapped to the object model in a re¯ned way compared

to the single class logical ¯le method as de¯ned by Antoniol et al. [4]. In the logical

¯les, the inherited data was included to calculate the complexity of a derived class. In

the case of the transaction functions, multi-valued association was included to cal-

culate the complexity. Further, this work had de¯ned the complexity of a class as a

factor to estimate the functionality of a system. However, the accuracy of the results

was not clearly validated.

Zivkovic et al. [34] proposed an Iterative Estimation Technique (IET) to improve

the accuracy of the estimation, at three-abstraction levels in the designer's per-

spective. Estimation is done in three stages namely basic, comparative and ¯nal. For

the basic stage, use case diagram was used. For comparative stage, sequence and

activity diagrams were used. For the ¯nal stage, OOFP for a single class logical ¯le

method was applied on the object model. Transaction function was estimated using

the modi¯ed complexity table [2] instead of the IFPUG external input table. Thus,

this work had attempted to integrate the various estimation methods from analysis

and design to estimate the size of the software. The details of estimation for basic and

comparative stage were not discussed in this work. Thus, this work has attempted to

build an iterative method estimation using the use case diagram, activity diagram,

sequence diagram, and class diagram.

Chamundeswari et al. [9] proposed the Object Model Function Point (OMFP) for

OO software size estimation. This approach provided rules that better guide the

practitioners at the design phase using the object model. This method also adapted

FPA methods to object model by applying all the basic concepts of OO systems

such as inheritance, aggregation, association and polymorphism. This estimation

approach took the multiple interactions of a class such as aggregation, association,

Developmental Size Estimation for Object-Oriented Software Based on Analysis Model 291

Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

and inheritance into account, while calculating the complexity of the logical ¯les.

Transaction function, internal and external logical ¯le components were clearly

identi¯ed by precise rules and guidelines to calculate the OMFP. However, this

approach was applied to the object model at the design phase on single class method

[4] alone.

Fetcke et al. [15] proposed the applicability of FPA to Object oriented Software

Engineering (OOSE) approach [18]. This work proposed the rules as de¯ned in

IFPUG for estimation at the analysis phase from three models, namely, UCM, do-

main model, and the object model. This work introduced the concept of transactional

functions on use cases. The authors have demonstrated the applicability of the FPA

method on three models to measure the functional software size. This measurement

spans from analysis to design phase to complete the estimation. Karner [19] proposed

a new measure called use case points for projects developed with the OOSE method

to address the shortcomings in FPA approach [28]. It introduced tables for weighted

actors, weighted use cases, thirteen factors contributing to technical complexity, and

eight factors contributing to e±ciency to measure the use case point. Though dif-

ferent models are available in the OOSE method, the reason behind the choice of

UCM was not made clear and there was no justi¯cation for the weightages assigned

to various actors, use case, technical and environmental factors.

Size estimation based on UCM was proposed by Marico et al. [22]. This work

introduced two size estimation measures namely use case size points and fuzzy use

case size points. The ¯rst one, named use case size points, focused on the function-

ality of a use case. Fine grain information such as classi¯cation of actors, precondi-

tions, main scenarios, alternative scenarios, exceptions, post conditions, TCF and

environment adjustment factors were considered. The second one, named fuzzy use

case size points focused on the concepts of the fuzzy set theory to create gradual

classi¯cations that better deal with uncertainty. The estimation results were com-

pared with the ones obtained by applying FPA. Error rate of the estimate showed

that there was no signi¯cant di®erence between FPA and the use case size point.

This work extended the estimation granularity of the use case point method by

introducing additional complexity tables. This method lacks in identi¯cation of

use cases that span across the system boundary and use case relationships for size

estimation.

Kim et al. [20] proposed the UML Point, combining use case points and class

points [11] to provide software system size information. This work is based on use

case diagram and class diagram of UML. An automated tool, the UML point gen-

erator, was developed to generate the UML points. This estimation approach, when

it is applied to general software projects, requires comprehensive design information

from class diagrams. Table 1 shows the comparison of various existing OO size

estimation methods based on the UML models.

Based on the comprehensive literature survey, it can be seen that during the

design phase, di®erent size estimation methods such as OOFP, OODFP, OMFP

exist, which are based on the object model. A signi¯cant shortcoming of these


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

methods is that the detailed design needs to be available to apply these methods.

However, it is desirable to estimate the size during the analysis phase itself. Di®erent

size estimation methods based on UCM are available to accomplish this requirement.

Complexity tables, weightage factors, technical and environmental factors are de-

¯ned in use case point and use case size point to estimate the size of the OO software.

These methods are not approved by any standard. On the other hand, Fetcke [15]

applied FPA, which is a standard approved by IFPUG on the use case driven object-

oriented software engineering method [18]. In this method, two components for es-

timation, namely transactional functions and ¯les were derived. FPA components

such as External Inputs (EI), External Outputs (EO) and External Inquiries (EQ)

were mapped to transactional functions, while Internal Logical Files (ILF) and

External Interface Files (EIF) were mapped to ¯les. 15 mapping rules were provided

to map the FPA components. The information regarding the transactional functions

was extracted from UCM while the information regarding the ¯les was extracted

from the object model for size estimation. However, object model provides details

only after the design phase commences. Hence, an attempt has been made in this

paper, to apply FPA completely on UCM at the analysis phase itself to estimate the

size of the OO software.

The proposed estimation method focuses on the various features of the UCM such

as actors, and use cases within the system boundary, external references, relationship

between use cases, and transaction features.

Table 1. Comparison of various existing OO size estimation methods based on UML models.

Estimation size

Developmental

phase UML model Adapted

Antoniol et al. [5] OOFP Design Object model FPA

Ram et al. [25] OODFP Design Object Model FPAZivkovic et al. [34] IET Design UCM, Activity,

Sequence,

Object Model

FPA

Chamundeswariet al. [9]

OMFP Design Object Model FPA

Karner [19] Use case point Analysis UCM ��Fetcke et al. [15] FPA � OO Design UCM, Domain

Model,Object Model

FPA

Marico et al. [22] Use case size points,

Fuzzy use case

points

Analysis UCM ��

Edward R Carroll [13] Use case point Analysis UCM Karner method

S. Kusumoto et al. [21] Use case point Analysis UCM Karner method

Kim et al. [20] UML point Design UCM Karner &Gennaro

methods

Mohagheghi P [24] Use case point Analysis UCM Karner method


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

3. Developmental Size Estimation Method

Function points are widely used in the software industry to estimate the function-

ality of the software. This is an advancement compared to a metric such as lines of

code. International Function Point User Group (IFPUG) was set up in 1986, and

since then several versions of the function point counting practices manual have been

published by IFPUG. It consists of ¯ve components namely ILF, EIF, EI, EO, EQ

and VAF.

ILF is a logical ¯le that is used to identify a group of logically related data that

resides entirely within the application boundary whereas EIF is a logical ¯le which

is used to identify a group of logically related data that is used only for reference.

The complexity due to the ILF and the EIF can be measured from two parameters,

namely Record Element Type (RET) and Data Element Type (DET). RET is a

user recognizable subgroup of data elements and DET is a unique user recogniz-

able, non-recursive (non-repetitive) ¯eld. EI is an elementary process in which the

data crosses the boundary from outside to inside whereas in EO, data passes

across the boundary from inside to outside. In EQ, input and output data are

retrieved from one or more ILF and EIF. The complexity due to all these ele-

mentary processes can be measured from two parameters namely File Type

Referenced (FTR) and DET. An FTR must also be an internal logic ¯le or external

interface ¯le. A DET is a unique user recognizable, non-recursive (non-repetitive)

¯eld.

IFPUG estimation method cannot be directly applied to OO software [25, 4] and

it needs suitable adaptation. In order to accomplish this, the FPA components

should be mapped to the UCM components. In FPA, the core concepts are logical

¯les and their data transactions, whereas in UCM, the core artifacts are use cases,

and their transactions.

This paper proposes a developmental size estimation of the OO software which

comprises of four steps. The ¯rst step is the identi¯cation of the boundary. The

second step is the identi¯cation and classi¯cation of ¯les within this boundary. The

third step is the identi¯cation and classi¯cation of transactions within this boundary.

The fourth step is the calculation of UCMFP based on the ¯les and the transactions.

The following subsections describe these steps in detail.

3.1. Boundary identi¯cation

In the use case diagram, the system boundary identi¯es the border between dif-

ferent applications. Figure 1 gives a pictorial overview of the boundary identi¯-

cation of the developmental software. The boundary is identi¯ed for the proper

classi¯cation of logical ¯les. Di®erent actors, such as an active actor, a passive actor

or a device will communicate with the use cases for various operations in the

system boundary. These use cases in turn may invoke other services outside the

system boundary.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

3.2. Identi¯cation and classi¯cation of ¯les

Once the system boundary is identi¯ed, the internal and external operation ¯les need

to be identi¯ed and classi¯ed.

De¯nition 1. Active actor: An actor that initiates the use case is an active actor.

For example, in Fig. 1, \Actor1" and \Actor2" are active actors who initiate the

use case.

De¯nition 2. Passive actor: An actor that responds to the query from a use case is a

passive actor.

For example, in Fig. 1, \Actor3" is a passive actor who responds to the query

received from a use case.

De¯nition 3. Internal Operation File: Information exchanged in the use case

diagram, between an actor and the use cases during the interaction within the system

boundary is encapsulated as Internal Operation File (IOF).

Following De¯nition 3, IOF is identi¯ed by applying the following rules:

(1) Select the active and passive actors that invoke the use cases within the system

boundary to perform one or more operations.

(2) Select the system boundary use cases that have direct connection to either an

active or passive actor as stated in rule 1.

(3) Group the use case(s) with their respective active or passive actors separately.

(4) Reject the system boundary use cases which are indirectly connected to either

active or passive actors.

Fig. 1. Identi¯cation of system boundary.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

ILF component of FPA is mapped to IOF component of UCM. ILF comprises

logically related data within the boundary while IOF comprises groups of the use

cases that directly communicate with an actor within the system boundary. A group

of use cases associated with an actor is one IOF. Classi¯cation of IOF depends on two

parameters, namely, the use case and use case operation data. The weightage for

each use case in a logical group is one. The use case operation data is the data that

°ows between the actor and the use cases. The weightage of each data °owing from

an actor to a use case or from a use case to an actor is one. The complexity of IOF can

be classi¯ed as low, average or high by applying the IFPUG, ILF complexity table.

De¯nition 4. External Operation File: Information exchanges in the use case

diagram, between a use case within system boundary and an actor across the

boundary during the interaction through an external reference is encapsulated as

External Operation File (EOF).

Following De¯nition 4, EOF is identi¯ed by applying the following rules:

(5) Select the use cases within the system boundary that uses the actor across the

boundary for the purpose of references alone.

(6) Group the selected use cases with their corresponding reference actor separately.

(7) Reject all other actors and the system boundary use cases.

EIF component of FPA is mapped to EOF component of UCM. EIF comprises

logically related data across the boundary that is used only for reference while the

EOF comprises the group of use cases that communicate with an actor across the

system boundary for the purpose of reference. Logical grouping of use cases with an

external reference actor is one EOF. Classi¯cation of EOF also depends on the same

two parameters, namely, the use case and the use case operation data. The weigh-

tage for each use case in a logical group is one. The weightage of each use case

operation data °owing from an actor to a use case or from a use case to an actor is

one. The complexity of an EOF can be classi¯ed as low, average or high by applying

the IFPUG, EIF complexity table.

3.3. Identi¯cation and classi¯cation of transactions

De¯nition 5. Transaction Function: The number of messages that °ow for an

operation in a use case is referred as Transaction Function (TF).

Each use case has one or more associations such as \include", \extend", and

\communication" or \comm". The \extend" relationship is used when one use case is

similar to another use case but is more specialized. The \include" association helps us

to avoid redundancy by allowing a use case to be shared. The \comm" association

helps to invoke the use case by an actor. The \include" association is considered only

once in determining the TF because it is shared. Following De¯nition 5, TF is

identi¯ed by applying the following rules.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

(8) Select every unique use case and identify the corresponding °ows.

(9) Identify the various messages for each °ow.

(10) Identify the unique messages for each °ow.

(11) Reject all overlapping messages for di®erent °ows in each use case.

EI component of FPA is mapped to TF component of UCM. EI is an elementary

process in which the data °ows only inside while TF is a process in which messages

°ow in and out of a use case in UCM. Classi¯cation of the TF depends on two

parameters, namely, the °ow and the message. The di®erent °ows that are possible

in a use case are main °ow, alternate °ow and exception °ow. Amessage represents a

simple unique user recognizable communication for each °ow. When TF parameters

are identi¯ed and classi¯ed, EI complexity table de¯ned as in IFPUG is used for

classifying TF complexity as low, average and high.

EO and EQ components of FPA are not considered. The size estimation of a OO

software application can be determined by applying the eleven rules that have been

proposed above. UCMFP is determined from four components, namely EOF, IOF,

TF and VAF. By determining the complexities of the corresponding parameters, the

complexities due to EOF, IOF and TF are calculated. The developmental size

according to the proposed estimation method, UCMFP, is calculated as given in

Eq. (1).

UCMFP ¼ ðIOFþ EOFþ TFÞ �VAF ð1Þwhere

EOF ¼ f ðUse case; Use case operation dataÞIOF ¼ f ðUse case; Use case operation dataÞTF ¼ f ðFlow; MessageÞ

VAF ¼ 0:65þ 0:01 �X14i¼1

TCFi

" #:

The weightage for each of the 14 TCF based on the degree of in°uence is assigned a

value in the range of 0 to 5. The summation of the weightages for the 14 TCF

multiplied with 0.01 is summed to 0.65 to obtain the VAF. The two constants

de¯ned in the equation for calculating the VAF, 0.65 and 0.01 have been taken from

FPA as de¯ned by IFPUG. A case study for which the proposed size estimation

method has been applied is discussed next.

4. Case Study

As a case study for validating the proposed estimation method, Regional Transport

O±ce (RTO) software developed in the software engineering laboratory in our In-

stitute has been considered. RTO is application software which enables a member to

apply for learner's permit, license, renewals, vehicle registrations and transfers. It


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

also provides them, the necessary information regarding the dates on which tests will

be conducted, issue dates, renewal and expiry time limits. Alert mails will be sent to

license holders when their licenses are about to expire. This system allows the users to

pay registration fees online using their credit/debit cards. The system also provides

information about the fee structure for di®erent modes of licenses and vehicles.

Eleven mapping rules as speci¯ed in Secs. 3.2, 3.3 and Eq. (1) in Sec. 3.4 were applied

for validation. This case study consists of all activities in a software development

life cycle such as analysis, design, implementation and testing. Figure 2 shows the use

case diagram for this application. The total number of use cases is 10. IOFs

are identi¯ed by applying rules 1, 2, 3 and 4. EOFs are identi¯ed by applying

rules 5, 6 and 7.

Figure 2 shows the interactions of actor admin with the use case such as update

results, and send alert mail to perform operations in the system boundary. According

to rule 1, admin actor is selected. Next, update results, and send alert mail use cases

that have direct connections to the actor admin are selected according to rule 2. The

admin actor is grouped with the two use cases, update results, and send alert mail.

Thus, as per rule 3, one IOF group is identi¯ed through the admin actor. The use

case operation data for send alert mail use case are vehicle license number, vehicle

type, license holder name, expiry date, date of birth, email-id, and issue date. Sim-

ilarly, for update results use case, the use case operation data are on-line test date,

Fig. 2. Use case diagram for RTO systems.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

application number, test date, document veri¯cation time, vehicle type, vehicle

model and on road test time. Thus, the total number of use cases is 2 and the total

number of use case operation data is 14. Consequently, the complexity of this IOF

is low.

In Fig. 2, according to rule 5, process application use case uses RTO Repository

actor solely for reference to perform one or more operations across the system

boundary. Group the RTO Repository actor with the process application use case,

according to rule 6. All the other use cases and actors are rejected in accordance

with rule 7. Thus, one EOF is identi¯ed by applying rules 5, 6 and 7. The use case

operation data for the use case process application are license number, license issue

date, license expiry date, issuing authority, signature of holder, retest test date,

vehicle category, and result status. The total number of use cases is one and the

total number of use case operation data is eight, thus making the complexity of

the EOF as low. Table 2 shows the complexity estimation of IOF and EOF for this

case study.

Corresponding to the use case diagram depicted in Fig. 2, TF are identi¯ed

and classi¯ed by applying rules 8, 9, 10 and 11. For the use case \apply form", shown

in Fig. 2, the °ow and unique transaction message are identi¯ed and represented

in Table 3. This use case has one main °ow \user submits the license form" and

two alternate °ows namely, \user is already a license holder", and \user is already

applied for license". Thus, the total number of °ows is 3. It is clear that the \user

submits the new license form" main °ow has 12 transaction messages, and the two

alternate °ows, \user already license holder" and \user already applied for license"

have 6 and 8 transaction messages respectively. From the total of 26 messages,

6 messages are overlapping. After eliminating the overlapping messages, the total

number of messages is 16. Thus, the complexity is 6 for \apply form" use case, with

the TF component, parameters °ow and message as 3 and 16 respectively. Table 4

shows complexity estimation of TF for this case study. VAF is calculated as 1.07 by

considering an average of 3 for all the fourteen TCF. Thus by applying Eq. (1) the

UCMFP for the case study discussed in this section is 87.74 FP.

UCMFP ¼ ð31þ 7þ 44Þ � 1:07¼ 87:74FP

Table 2. Complexity estimation for IOF & EOF.

Files Actor Use case Use case operation data Complexity

IOF Member 3 29 10

Admin 2 14 7

Cashier 1 9 7

RTO 1 21 7

Total IOF complexity 31

EOF RTO repository 1 8 7

Total EOF complexity 7


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

5. Empirical Results and Analysis

The main objective of this analysis is to empirically analyze the proposed estimation

method by assessing its ability to predict the developmental size of OO software and

its associated error factor. The proposed estimation approach was applied to 15 OO

software projects developed in our software engineering laboratory. These projects

Table 3. Documentation of °ow(s) for \apply form" use case.

Use case: apply form

Main °ow: User submits the new

license form

Alternate °ow 1: User already

a license holder

Alternate °ow 2: User has

already applied for license

1. An applicant requests new li-

cense form

2. Display the new license form

3. Completes and submits the li-cense form

4. Check whether license has

been issued already

5. Con¯rm that license has notbeen issued already

6. Set the status of license

7. Generate a new applicationnumber

8. An applicant receives a new

application number for the

new application form submit-ted.

9. An applicant pays for the li-

cense

10. Process the payment11. Payment process succeeds

12. Applicant receives the receipt

as con¯rmation.

1. An applicant requests new

license form

2. Display the new license

form3. Completes and submits the

license form


been issued already5. License has already been

issued to applicant

6. Convey the information toapplicant

1. An applicant requests new

license form

2. Display the new license

form3. Completes and submits the

license form


been issued already5. Con¯rm that license has

not been issued already

6. Set the status of license7. Status already created

8. Convey the information to

applicant

Table 4. Complexity estimation for TF.

Use case Flow Message Complexity

Signup 2 13 3apply form 3 16 6

pay fees 3 14 4

check status 3 15 4update results 3 18 6

send alert mail 2 13 3

process application 4 32 6

veri¯cation & validation 2 9 3Refund 3 18 6

Validate refund 2 8 3

Total 27 156 44


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

were chosen because all of them were developed in the same environment, by fol-

lowing all the activities in software development life cycle. Each team followed the

same procedure to collect the data required for empirical analysis. All these projects

were developed by the ¯nal year undergraduate students using OO languages. The

number of use cases, number of operation data, number of °ows, number of messages,

complexity due to IOF, EOF and TF for all the projects are shown in Table 5. The

UCMFP estimated using Eq. (1) is also given in Table 5 along with the actual

development e®ort. In this context, the actual development e®ort denotes the total

number of hours taken by the team members to complete the project.

These projects were chosen to measure the linear relationship between UCMFP

and the actual development e®ort using Pearson correlation coe±cient [36]. The

formula for computing pearson coe±cient r is represented below.

r ¼ �ðX� XÞðY� YÞ=N�x�y

where, X denotes the UCMFP data, Y denotes the actual development e®ort,

N denotes the total number of projects, �x is the standard deviation of UCMFP, and

�y is the standard deviation of actual development e®ort. The correlation coe±cient

is always between �1 and þ1. The relationship between the UCMFP and the actual

development e®ort for the training projects is 0.65 positive. This indicates that a

strong positive linear association exists between them.

5.1. Model evaluation

15 projects (sample set, n ¼ 15) represented in Table 5 were used for training and

testing. K fold cross validation [36] with linear regression technique [36] was used to

Table 5. Size estimation of OO projects.

Number of Complexity due toActual

Project use cases

use case

operation data °ows messages IOF & EOF TF UCMFP

development

e®ort (Y)

P1 13 85 19 68 43 35 83.46 30

P2 13 105 37 254 47 64 118.77 36

P3 16 191 33 231 49 60 116.63 36

P4 13 101 38 220 37 66 110.21 36P5 11 50 22 129 33 44 82.39 33

P6 10 81 27 156 38 44 87.74 27

P7 11 51 24 147 33 59 98.44 33

P8 11 74 26 218 42 58 107 33P9 12 68 31 224 46 52 104.86 30

P10 10 73 28 141 43 35 83.46 33

P11 14 184 35 182 45 61 113.42 36P12 13 73 32 153 42 56 104.86 30

P13 12 82 26 132 38 47 90.95 27

P14 10 64 24 152 34 48 87.74 30

P15 12 91 33 168 41 58 105.93 36


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

evaluate the model to assess the association between actual development e®ort

and (i) UCMFP, (ii) IOF&EOF, (iii) TF. SPSS PASW Statistics 18 software was

applied to derive the linear regression equation. Here, 15 projects given in Table 5, is

split into 3 blocks of 5 projects each for evaluation. Training is performed, by con-

sidering UCMFP as the independent variable and actual development e®ort as the

dependent variable. The linear regression equation, Y ¼ aþ bX has been derived

from the 2 blocks. The remaining block that was left out is tested with the derived

regression equation. For testing, UCMFP, a(derived constant), b(derived constant),

are applied and predicted development e®ort, YUCMFP 0 for each project is obtained.

This is repeated until all the projects in that block are tested with same regression

equation. Likewise, this procedure is repeated until all the blocks are trained and

tested. Annex A details the results obtained by this evaluation. Similarly, K fold

cross validation is applied for IOF & EOF and TF and their results are represented

in Annexes B and C, respectively. Table 6 details the mean absolute error and

variance obtained from K fold cross validation for the three variables such as

UCMFP, IOF&EOF, TF. The mean absolute error and variance were measured

to determine the accuracy of the model. Since there is bias in the mean error and to

improve the result further, leave one out cross validation technique [36] was used

to evaluate the model.

In leave one out validation technique, n� 1 projects are used for training and the

remaining was used for testing. This is repeated for each sample in the sample set and

the testing was done using linear regression technique. The evaluation is done to

assess the association between actual development e®ort and (i) UCMFP, (ii)

IOF&EOF, (iii) TF. Considering UCMFP as the independent variable and actual

development e®ort as the dependent variable, the regression equation, Y ¼ aþ bX

has been derived from a set of 14 training projects. The derived equation is tested

with the 15th project that was left out. For testing, UCMFP of the 15th project,

a(derived constant), b(derived constant), are applied and predicted development

e®ort is obtained. Likewise, each time, a di®erent set of 14 projects are used for

training and the remaining project is used for testing. The tested sample set of the

projects with the corresponding predicted development e®ort YUCMFP 00 are tabu-

lated in Annex D. The mean absolute error in the development e®ort estimation is

found to be 2.2692. The same cross validation is repeated for IOF&EOF and TF

data and error obtained is represented in Table 6 and their detailed results are

represented in Annexes E and F. The mean error obtained using UCMFP is biased

Table 6. Cross validation results.

K fold Leave one out

Data Error variance Error variance

UCMFP 2.3293 1.8829 2.2692 2.4524

IOF & EOF 3.0081 2.3906 2.2814 2.4377TF 2.6134 1.3523 2.5026 2.2115


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

compared to that of IOF&EOF and TF. This is very clear from the data represented

in Table 6. To further improve the validation, hypothesis testing was applied.

Hypothesis testing [3] is used to evaluate experimental outcome about the

relationship between actual and predicted development e®ort YUCMFP 00. Null

hypothesis (Ho) and the alternative hypothesis (Ha) can be stated as follows:

Ho : D ¼ 0 No di®erence exists between the actual and predicted development

e®ort.

Ha : D 6¼ 0 Di®erence exists between the actual and predicted development e®ort.

The hypothesis is applied on 15 tested projects using the paired t-test. Paired

t-test is a statistical technique that is used to compare two samples that are corre-

lated. It can be used if the sample sizes are very small as long as the pairs are not

reliably di®erent. In this context, the paired t-test is applied to compare the actual

and predicted development e®ort, YUCMFP 00. The formula used for the paired t-test

with n� 1 degrees of freedom is:

t ¼ dffiffiffin

p=S

where d is the mean di®erence between two samples, S is the standard deviation of

the di®erences, and n is the sample size.

The level of signi¯cance considered is 95 percent likelihood (� ¼ 0:05) that a Type

I error is not made. Trade-o® for choosing a higher level of signi¯cance is that it will

take much stronger statistical evidence to reject the null hypothesis. The outcome of

null hypothesis is accept if the computed value of the paired t-test lies between

�2:015 and þ2.015. The tested data, actual and predicted development e®ort of 15

projects are applied to the formula for the paired t-test. The value obtained in the

present study is 0.092. Hence the outcome of the null hypothesis is accept. There

exists no signi¯cant di®erence between the actual and predicted development e®ort.

Thus, the developmental size UCMFP and the e®ort can be predicted at the early

analysis phase based on the UCM.

6. Conclusions and Future Work

This paper proposed a new developmental estimation method at the analysis phase,

namely, Use Case Model Function Points. This method is based entirely on the use

case model as opposed to some of the earlier works where the design level information

is also needed for complete estimation. Further, it also adapts the IFPUG standard,

FPA for the use case model in contrast to the existing works, where the complexity

tables do not follow any standard. The proposed estimation method UCMFP pro-

vides 11 rules to identify the relevant components for estimation from the use case

model. After applying these rules, complexity for these estimation components were

derived by assigning weightage to the various parameters following the appropriate

FPA complexity tables. This method was evaluated on the 15 projects developed by


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

our undergraduate students. K-fold and leave one out cross validation technique

were used for training with UCMFP, IOF&EOF and TF data sets. The relationship

between each of these data and actual development e®ort was derived through linear

regression. The derived linear regression equation was tested on the remaining set or

remaining project to evaluate the accuracy of the estimation of the development

e®ort. 15 projects were tested and the mean error was found. Leave one out cross

validation produced a biased result than K-fold using UCMFP data set. The mean

error produced is 2.2692. Hypothesis testing proved that there exists no signi¯cant

di®erence between the actual and predicted development e®ort, YUCMFP 00. Thelimitation of this approach is that currently it has been tested only with few projects.

The validation can be further strengthened by testing with more projects. This work

also can be extended to measure the testing e®ort at the analysis phase of software

life cycle and to explore the relationship between the testing and the development

e®ort.

References

1. A. Albrecht, Measuring application development productivity, IBM Application Devel-opment Symposium, 1979, pp. 83�92.

2. M. A. Al-Hajri, A. A. A. Ghani, M. N. Sulaiman and M. H. Selamat, Modi¯cationof standard function point complexity weights system, Journal of Systems and Software74(2) (2005) 195�206.

3. D. R. Anderson, D. J. Sweeney and T. A. Williams, Statistics for Business and Economics,9th ed. (South-Western College Publishing, Mason, OH, 2004).

4. G. Antoniol, C. Lokan, G. Caldiera and R. Fiutem, A function point-like measure forobject-oriented software, Journal of Empirical Software Engineering 4(3) (1999)263�287.

5. G. Antoniol, F. Calzolari, L. Cristoforetti, R. Fiutem and G. Caldiera, Adapting functionpoints to object-oriented information systems, Proceedings of 10th International Con-ference on Advanced Information Systems Engineering (CAiSE 98) (Springer-Verlag,1998), pp. 59�76.

6. G. Antoniol, R. Fietum and C. Lokan, Object oriented function points: An empiricalvalidation, Journal of Empirical Software Engineering 8(3) (2003) 225�254.

7. I. Ayman, O. Mohammed and C. David, Software cost estimation using use case models:A critical evaluation, Second International Conference on Information and Communi-cation Technologies, April 2006, pp. 2766�2771.

8. A. Chamundeswari and B. Chitra, Function point size estimation for object-orientedsoftware based on use case model, International Conference on Software and DataTechnologies, 2008, pp. 139�145.

9. A. Chamundeswari and B. Chitra, An extended function point approach for size esti-mation of object-oriented software, International Workshop on Empirical SoftwareEngineering at India Software Engineering Conference (ISEC), 2010.

10. A. Cockburn, Writing E®ective Use Cases (Addison-Wesley, Boston, 2001).11. G. Costagliola, F. Ferrucci and G. Tortora, Class Point: An approach for the size esti-

mation of object-oriented systems, IEEE Trans. on Software Engineering 31(1) (2005)52�74.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

12. S. Diev, Use cases modeling and software estimation: Applying use case points, ACMSIGSOFT Software Engineering Notes 31(6) (2006) 1�4.

13. R. C. Edward, Estimating software based on use case points, International Conference onObject Oriented Programming Systems Languages and Applications, 2005, pp. 257�265.

14. N. C. Fernandez, S. Abrahao and O. Pastor, Towards a functional size measure for object-oriented systems from requirements speci¯cations, Fourth International Conference onQuality Software, 2004, pp. 94�101.

15. T. Fetcke, A. Abran and T. H. Nguyen, Mapping the OO-Jacobson approach intofunction point analysis, Proceedings of IFPUG, 1997 Spring Conference, 1997, pp.134�142.

16. G. Robiolo and R. Orosco, Employing use cases to early estimate e®ort with simplermetrics, Innovations in Systems and Software Engineering 4(1) (2008) 31�43.

17. V. Harput, H. Kaindl and S. Kramer, Extending function point analysis of object-orientedrequirements speci¯cations, Eleventh IEEE International Software Metrics Symposium,2005, pp. 39�49.

18. I. Jacobson, Object Oriented Software Engineering: A Use Case Driven Approach(Addison-Wesley, 1992).

19. G. Karner, Resource estimation for objectory projects, Objectory Systems SFAB (°cRational Software), 1993.

20. S. Kim, W. Lively and D. Simmons, An e®ort estimation by UML points in the early stageof software development, International Conference on Software Engineering Research &Practice, 2006, pp. 415�421.

21. S. Kusumoto, F. Matukawa, K. Inoue, S. Hanabusa and Y. Maegawa, Estimating e®ortby use case points: Method, tool and case study, Sixth International Symposium onSoftware Metrics, 2004, pp. 292�299.

22. M. R. Braz and S. R. Vergilio, Software e®ort estimation based on use cases, 30th AnnualInternational Conference on Computer Software and Applications, 2006, pp. 221�228.

23. A. F. Minkiewicz, Measuring object-oriented software with predictive object points,International Conference on Applications in Software Measurements, 1997.

24. P. Mohagheghi, B. Anda and R. Conradi, E®ort estimation of use cases for incrementallarge-scale software development, International Conference on Software Engineering,2005, pp. 303�311.

25. D. Janaki Ram and S. V. G. K. Raju, Object oriented design function points, Proceedingsof the First Asia Paci¯c Conference on Quality Software, Hong Kong, 2000, pp. 121�126.

26. M. Schooneveldt, Measuring the size of object-oriented systems, Second AustralianConference on Software Metrics, Metrics Association, 1995, pp. 168�177.

27. J. Smith, The estimation of e®ort based on use cases, Rational Uni¯ed Process (RUP)white papers, 1999.

28. C. R. Symons, Function point analysis: Di±culties and improvements, IEEE Trans. onSoftware Engineering 14(1) (1988) 2�11.

29. T. Uemura, S. Kusumoto and K. Inoue, Function point analysis using design speci¯cationbased on the uni¯ed modelling language, Journal of Software Maintenance Evolution:Research Practice 13 (2001) 223�243.

30. A. S. Whitmire, Applying function points to object-oriented software models, in SoftwareEngineering Productivity Handbook (McGraw-Hill, New York, 1992), pp. 229�244.

31. W. Zhou and Q. Liu, Extended class point approach of size estimation for OO product,International Conference on Computer Engineering and Technology, 2010, pp. 117�122.

32. A. Zivkovic and M. Hericko, Tips for estimating software size with FPA method,IASTED International Conference on Software Engineering (Acta Press, 2004),pp. 515�519.


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

33. A. Zivkovic, M. Hericko, B. Brumen, S. Beloglavec and I. Rozman, The impact of detailsin the class diagram on software size estimation, Informatica 16(2) (2005) 295�312.

34. A. Zivkovic, I. Rozman and M. Hericko, Automated software size estimation based onfunction points using UML models, Journal of Information and Software Technology47(13) (2005) 881�890.

35. IFPUG, Function Point Counting Practices Manual, Function Point Users Group,Westerville, Ohio, 1999.

36. S. P. Gupta, Statistical Methods (Sultan Chand & Sons, 2001).

Annex A. 3 fold cross validation with UCMFP

Project UCMFP

Actual

developmente®ort (Y)

Predicted

developmente®ort (YUCMFP 0)

Errord¼ (Y-YUCMFP 0)

Absoluteerror

Mean

absoluteerror

P1 83.46 30 28.8138 1.1862 1.1862P2 118.77 36 35.1696 0.8304 0.8304

P3 116.63 36 34.7844 1.2156 1.2156

P4 110.21 36 33.6288 2.3712 2.3712

P5 82.39 33 28.6212 4.3788 4.3788P6 87.74 27 30.54468 �3.54468 3.54468

P7 98.44 33 32.49208 0.50792 0.50792

P8 107 33 34.05 �1.05 1.05 2.3293

P9 104.86 30 33.66052 �3.66052 3.66052P10 83.46 33 29.76572 3.23428 3.23428

P11 113.42 36 34.55528 1.44472 1.44472

P12 104.86 30 33.40824 �3.40824 3.40824P13 90.95 27 31.5443 �4.5443 4.5443

P14 87.74 30 31.11416 �1.11416 1.11416

P15 105.93 36 33.55162 2.44838 2.44838

Annex B. 3 fold cross validation with IOF & EOF

Project IOF & EOF

Actual


Predicted

developmente®ort (YIE 0)

Errord¼ (Y-YIE 0)

Absoluteerror

Mean absoluteerror

P1 43 30 32.125 �2.125 2.125P2 47 36 33.033 2.967 2.967

P3 49 36 33.487 2.513 2.513

P4 37 36 30.763 5.237 5.237

P5 33 33 29.855 3.145 3.145P6 38 27 32.19 �5.19 5.19

P7 33 33 30.8 2.2 2.2

P8 42 33 33.302 �0.302 0.302 3.008

P9 46 30 34.414 �4.414 4.414P10 43 33 33.58 �0.58 0.58

P11 45 36 33.064 2.936 2.936

P12 42 30 32.779 �2.779 2.779P13 38 27 32.399 �5.399 5.399

P14 34 30 32.019 �2.019 2.019

P15 41 36 32.684 3.316 3.316


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

Annex D. Leave one out cross validation with UCMFP

Project UCMFP

Actual

development

e®ort (Y)

Predicted

development

e®ort (YUCMFP 00)Error

d¼ (Y-YUCMFP 00)Absolute

error

Mean

absolute

error

P1 83.46 30 29.6793 0.3207 0.3207

P2 118.77 36 35.3812 0.6188 0.6188P3 116.63 36 35.0275 0.9725 0.9725

P4 110.21 36 33.8376 2.1624 2.1624

P5 82.39 33 28.6892 4.3108 4.3108

P6 87.74 27 30.9693 �3.9693 3.9693P7 98.44 33 32.1640 0.836 0.836

P8 107 33 33.6333 �0.633 0.633 2.2692

P9 104.86 30 33.5158 �3.5158 3.5158P10 83.46 33 29.0012 3.9988 3.9988

P11 113.42 36 34.4575 1.5425 1.5425

P12 104.86 30 33.5158 �3.5158 3.5158

P13 90.95 27 31.3646 �4.3646 4.3646P14 87.74 30 30.5166 �0.5166 0.5166

P15 105.93 36 33.2399 2.7601 2.7601

Annex C. 3 fold cross validation with TF

Project TF

Actual


Predicted

developmente®ort (YTF 0)

Errord¼ (Y-YTF 0)

Absoluteerror

Meanabsolute error

P1 35 30 28.196 1.804 1.804P2 64 36 33.88 2.12 2.12

P3 60 36 33.096 2.904 2.904

P4 66 36 34.272 1.728 1.728

P5 44 33 29.96 3.04 3.04P6 44 27 30.488 �3.488 3.488

P7 59 33 34.313 �1.313 1.313

P8 58 33 34.058 �1.058 1.058 2.613

P9 52 30 32.528 �2.528 2.528P10 35 33 28.193 4.807 4.807

P11 61 36 34.284 1.716 1.716

P12 56 30 33.444 �3.444 3.444

P13 47 27 31.932 �4.932 4.932P14 48 30 32.1 �2.1 2.1

P15 58 36 33.78 2.22 2.22

Annex E. Leave one out cross validation with IOF & EOF

Project IOF&EOF

Actual


Predicted

developmente®ort (YIE 00)

Errord¼ (Y-YIE 00)

Absoluteerror

Mean

absoluteerror

P1 43 30 29.62 0.38 0.38P2 47 36 35.354 0.646 0.646

P3 49 36 35.021 0.979 0.979


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

Annex F. Leave one out cross validation with TF

Project TF

Actual


Predicted

developmente®ort (YTF 00)

Errord¼ (Y-YTF 00)

Absoluteerror

Mean

absoluteerror

P1 35 30 28.316 1.684 1.684P2 64 36 34.543 1.457 1.457

P3 60 36 33.669 2.331 2.331

P4 66 36 34.973 1.027 1.027

P5 44 33 30.364 2.636 2.636P6 44 27 31.142 �4.142 4.142

P7 59 33 33.815 �0.815 0.815

P8 58 33 33.614 �0.614 0.614 2.5026

P9 52 30 32.453 �2.453 2.453P10 35 33 27.124 5.876 5.876

P11 61 36 33.896 2.104 2.104

P12 56 30 33.386 �3.386 3.386P13 47 27 31.676 �4.676 4.676

P14 48 30 31.62 �1.62 1.62

P15 58 36 33.282 2.718 2.718

Annex E. (Continued )

Project IOF&EOF

Actual

development

e®ort (Y)

Predicted

development

e®ort (YIE 00)Error

d¼ (Y-YIE 00)Absolute

error

Mean

absolute

error

P4 37 36 33.853 2.147 2.147

P5 33 33 28.7 4.3 4.3P6 38 27 30.957 �3.957 3.957

P7 33 33 32.107 0.893 0.893

P8 42 33 33.664 �0.664 0.664 2.2814

P9 46 30 33.505 �3.505 3.505P10 43 33 28.956 4.044 4.044

P11 45 36 34.466 1.534 1.534

P12 42 30 33.505 �3.505 3.505

P13 38 27 31.419 �4.419 4.419P14 34 30 30.483 �0.483 0.483

P15 41 36 33.234 2.766 2.766


Int.

J. S

oft.

Eng

. Kno

wl.

Eng

. 201

3.23

:289

-308

. Dow

nloa

ded

from

ww

w.w

orld

scie

ntif

ic.c

omby

UN

IVE

RSI

TY

OF

RE

GIN

A o

n 09

/03/

13. F

or p

erso

nal u

se o

nly.

DEVELOPMENTAL SIZE ESTIMATION FOR OBJECT-ORIENTED SOFTWARE BASED ON ANALYSIS MODEL

Documents

Transcript of DEVELOPMENTAL SIZE ESTIMATION FOR OBJECT-ORIENTED SOFTWARE BASED ON ANALYSIS MODEL