Should Function Point Elements be Used to Build
Prediction Models?
Kohei Yoshigami, Masateru Tsunoda

Yuto Yamada, Shinji Kusumoto

Department of Informatics
Kindai University
Osaka, Japantsunoda@info.kindai.ac.jp

Graduate School of Information Science and Technology
Osaka University
Osaka, Japan{y-yuto, kusumoto}@ist.osaka-u.ac.jp

Abstract—Schedule and cost managements are indispensable
to develop large software, and predicting of project results suchas development effort is the basis of the management. So, highaccuracy of project prediction is needed. Many researches about
software project prediction use software size as a major
explanatory variable. To estimate software size, function point
method is often applied. In the method, five fundamental
function elements are identified and scores called function point(FP) are given to each element. After that, the sum of FP is
calculated. Generally, the FP elements are not used as
independent variables directly, and only the sum of them is used
as an independent variable. As long as we know, it is not clear towhat extent FP elements affect quality, cost, and delivery ofsoftware project. Also, it is not clear whether using the elements
as independent variables improves prediction accuracy of quality,
cost, and delivery or not. So, this study analyzed the influence ofthe elements to quality, cost and delivery. Also, we evaluated theaccuracy of software project prediction when the elements wereused as independent variables. The goal of the study is to support
data collection and variable selection of the prediction.
Experimental results showed that when duration and effort were
estimated by analogy based estimation, using FP elements as
independent variables was effective to enhance the estimation
accuracy.
Keywords—QCD; fault prediction; effort estimation; duration
prediction

I. INTRODUCTION
Schedule and cost managements are indispensable todevelop large software, and predict results of project such as
development effort is the basis of the management. So, highaccuracy of project prediction (small difference between
predicted and actual value) is needed. When the results are
predicted by a mathematical model, the model is built using adataset collected at past software development projects. To
achieve high accurate prediction, many prediction methods
have been proposed. Analogy based estimation is one of major
estimation models. It selects projects (neighborhood projects)
which are similar to the estimated project from past project
dataset, and estimates results based on similar projects’ results.
One of the advantages of analogy based estimation is that
estimation results are comprehensible for estimators such as
project managers [16], because they can confirm neighborhood
projects used for estimation. Although ordinary estimation

models like linear regression model estimate various target
projects’ effort by one model, analogy based estimation does
not make such a model, and estimates results by neighborhood
projects’ results. So analogy based estimation can reflect
individuality of each target project in estimation.
Many researches about software project prediction use
software size as a major explanatory variable. To estimate
software size, function point method [6] is often applied.
Estimating software size is indispensable to make a projectplan. In the method, five fundamental function elements are
identified from all functions of the estimation target software.
After that, scores called function point (FP) are given to eachelement, based on the complexity of the functions. Fivefundamental function elements are the followings [2]:• Internal Logical Files (ILF): Data files logically related
to the estimation target software. They are updated in
the software.
• External Interface Files (EIF): Data files referred by theestimation target software, but not updated in thesoftware.
• External Inputs (EI): Processes which update ILF using
data input from outside of the estimation target software.
• External Outputs (EO): Processes which output
processed data to the outside of the estimation target
software. The processed data is made with someconditions and calculations.
• External Inquiries (EQ): Processes which output data tooutside of the estimation target software. The data is notprocessed data, and the processes do not update ILF.
Especially, the sum of FP on estimation target software iscalled as application FP. Also, in maintenance projects, themethod measures FP of added, modified and deleted functions
separately.
Generally, above FP elements are not used as independent
variables directly, and the sum of them (i.e., application FP) isused as an independent variable. However, it is not clear towhat extent FP elements affect quality, cost, and delivery ofsoftware project. Also, it is not clear whether using theelements as independent variables improves prediction
accuracy of quality, cost, and delivery or not.

This study analyzed the influence of FP elements
thoroughly. That is, we analyzed the influence of elements toquality, cost and delivery. After the analysis, we evaluated theaccuracy of software project prediction models when theelements were used as independent variables. The goal of thestudy is to support data collection and variable selection of theprediction models. Concretely speaking, in the analysis, weused ISBSG dataset, and analyzed the relationship of FP
elements to fault ratio, productivity (efficiency), and delivery
speed (The definitions of them are explained in section II).
After that, using analogy based estimation, we predicted thenumber of faults, development effort and project duration,using FP elements as independent variables, to evaluate theeffectiveness of the elements.
II. DATASET
We used the dataset of software development which wascollected from organizations in 20 countries by ISBSG(International Software Benchmarking Standards Group) [7].
The version of the dataset is Release 9. The dataset includes 99
variables and 3026 projects performed between 1989 and 2004.
ISBSG dataset is also called as cross-company dataset, since it
was collected from various companies. To align status ofanalyzed projects, we selected projects which satisfy
conditions shown in the following. The condition is based on
the study of Lokan et al. [10].

TABLE I.

VARIABLES USED IN THE ANALYSIS

Variables
Development type
Application FP
Number of faults
EffortDuration
Plan phase ratio
Requirement analysis
phase ratio
Coding phase ratio
Test phase ratio
Implementation phaseratio
Business sector
Architecture
Platform
Programming language
EI ratio
EO ratio
EQ ratio
ILF ratio
EIF ratio
Add FP ratio
Modify FP ratio
Delete FP ratio
Fault ratio
Productivity
Development speed

DetailNew development or enhancement
Total function point of software
Number of faults after softwaredelivery
Total software development effort
Development duration of a project
Effort of planning / total effort
Effort of requirement analysis / total
effortEffort of coding / total effort
Effort of testing / total effort
Effort of implementation / total effort
Banking, communications, and so on
Stand alone, client/server, and so on
Mainframe, PC, and so on
C/C++/C#, Visual Basic, and so on
EI / application FP
EO / application FP
EQ / application FP
ILF / application FP
EIF / application FP
FP added / application FP
FP modified / application FP
FP deleted / application FP
Number of faults/ application FP
Application FP / effort
Application FP / project duration• Data quality rating is A or B
• FP measurement rating is A or B
• FP measurement method is IFPUG• Effort includes working time of development team only
(e.g., working time of back-office is not included)
To analyze influence of FP elements to quality, cost, anddelivery, we defined fault ratio, productivity, and development
speed, and analyzed the relationships (see Table I). Also, we
assume that when the some elements are very small or large, it
affects quality, cost and delivery. To analyze that, we defied
the ratio of the elements (each elements were divided byapplication FP). Table I shows definitions of each variable
such as EI ratio. On the nominal variables (e.g., businesssector), when the number of cases on a category was small, thecategory was treated as missing variables (i.e., we removed thecategories when the number of them was small).
Generally, characteristics of new development projects andmaintenance projects are very different. Dataset is often
stratified by the development type. So, we stratified the dataset
before applying statistical analysis (re-development was treatedas new development). Note that modified FP and deleted FP
are recorded in the maintenance projects only, and added FP is
100% in new development projects.
As preliminary analysis, we analyzed the relationships of
FP elements to fault ratio, productivity and development speed.
Projects are selected based on the above conditions. In thesubset, 421 new development projects and 606 maintenanceprojects were included. There were missing values in thedataset, and therefore the number of projects used in theanalysis was different on each variable.

Also, we stratified the dataset before predicting the numberof faults, effort, and project duration. We eliminated projects inwhich a dependent variable or independent variables include
missing values (i.e., we applied listwise deletion). So, in theprediction accuracy evaluation, the number of projects used tobuild the model are the followings:• Predicting the number of faults (new development): 19• Predicting the number of faults (enhancement): 43• Predicting project duration (new development): 251• Predicting project duration (enhancement): 359• Predicting effort (new development): 270• Predicting effort (enhancement): 364
Generally, it is difficult to collet number of faults after
software delivery. So, it has many missing values and thenumber of projects used to predicting the number of faults was
small.
III. RELATIONSHIP BETWEEN FP ELEMENTS AND OTHERVARIABLES
A. Overview
To clarify the influence of FP elements to quality, cost anddelivery, we analyzed the relationship of FP elements to fault
ratio, productivity, and development speed. Also, we assumed
that when some FP elements are dominant, some development
phases need effort (e.g., when EI is high, test phase needs more
effort). Based on the assumption, we analyzed the relationshipTABLE II.

EI ratio

EO ratio

EQ ratio

ILF ratio

EIF ratioρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects

Fault
ratio
-0.01
98%
36
-0.01
96%
36
-0.12
48%
36
-0.09
61%
36
0.03
86%
36

TABLE III.

EI ratio

EO ratio

EQ ratio

ILF ratio

EIF ratio

Add FP
ratio
Modify FP
ratio
Delete FPratioρ
p-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects
ρp-value# of projects

Fault
ratio
0.02
87%
52
-0.20
15%
52
0.34
1%
52
-0.16
26%
52
-0.01
92%
52
0.07
62%
52
-0.10
49%
52
0.10
47%
52

RELATIONSHIPS BETWEEN FP ELEMENTS AND OTHER VARIABLES (NEW DEVELOPMENT)
Productivity
0.15
0%
421
0.00
97%
421
0.08
9%
421
0.15
0%
421
-0.27
0%
421

Development
speed
0.07
17%
389
-0.01
81%
389
0.11
3%
389
0.12
2%
389
-0.12
2%
389

Plan phase
ratio
-0.08
55%
54
-0.08
59%
54
0.04
76%
54
-0.06
67%
54
-0.01
96%
54

Requirement
analysis phase ratio
-0.07
53%
93
0.04
69%
93
-0.06
58%
93
-0.09
41%
93
0.11
29%
93

Codingphase ratio
0.17
11%
95
-0.04
71%
95
0.11
29%
95
-0.03
79%
95
-0.08
42%
95

Test phase
ratio
-0.14
18%
89
0.14
20%
89
-0.13
22%
89
0.01
90%
89
0.09
41%
89

Implement
phase ratio
0.30
2%
57
-0.18
18%
57
0.01
97%
57
0.00
99%
57
-0.03
85%
57

RELATIONSHIPS BETWEEN FP ELEMENTS AND OTHER VARIABLES (ENHANCEMENT)
Productivity
-0.04
28%
606
0.02
63%
606
-0.13
0%
606
0.14
0%
606
0.03
53%
606
-0.06
12%
606
0.06
15%
606
0.02
64%
606

Development
speed
-0.07
9%
562
0.05
21%
562
0.17
0%
562
0.04
37%
562
0.11
1%
562
-0.11
1%
562
0.09
3%
562
0.15
0%
562

between FP elements and ratio of each phase (e.g. test phaseratio). When the relationship is strong, using FP elements as
independent variables may enhance prediction accuracy ofeffort of each development phase. Some studies [5] predict
effort of each development phase.
We analyzed the relationship between FP elements andbusiness sector, assuming that some business sectors havebiases of FP elements (e.g., EI is high, when business sector isbanking). Similarly, we analyzed the relationship between FP
elements and programming language, assuming that whensome FP elements are high, some programing languages are
selected (e.g., when EI is high, COBOL is selected). If FP
elements have strong relationships to them, FP elements can beused as substitution of them, especially when they are missing
values. For example, when FP elements have strong

Plan phase
ratio
0.34
14%
20
-0.39
9%
20
0.36
11%
20
0.43
6%
20
-0.36
12%
20
-0.58
1%
20
0.56
1%
20
0.36
12%
20

Requirement
analysis phase ratio
-0.06
49%
147
0.05
57%
147
-0.19
2%
147
0.07
39%
147
-0.08
36%
147
-0.02
77%
147
-0.01
87%
147
0.14
9%
147

Codingphase ratio
0.01
88%
151
-0.03
68%
151
0.12
14%
151
-0.10
22%
151
0.16
5%
151
0.15
6%
151
-0.14
8%
151
-0.01
87%
151

Test phase
ratio
0.09
26%
148
-0.03
72%
148
0.11
16%
148
0.08
31%
148
-0.16
5%
148
-0.33
0%
148
0.34
0%
148
0.00
97%
148

Implement
phase ratio
-0.38
4%
29
0.49
1%
29
-0.39
4%
29
0.30
12%
29
-0.01
96%
29
0.48
1%
29
-0.40
3%
29
-0.25
19%
29

relationship to business sector but it is not recorded (or notdisclosed), FP elements can be used as independent variables
in prediction models, instead of business sector. Note we easily
know programming language if it has missing values but wecollect the dataset directly. However, when we analyze thedataset collected by others such as ISBSG dataset, it is difficult
to handle missing values of programming language.
When analyzing the relationship between FP elements andratio scale variables, we used Spearman's rank correlation
coefficient, to avoid influence of outliers. To analyze therelationship between FP elements and nominal scale variables,
we used the correlation ratio. The ratio indicates strength of therelationship between ratio and nominal scale variables. The
range of the value is [0, 1].

TABLE IV.

RELATIONSHIPS BETWEEN FP ELEMENTS AND
CATEGORICAL VARIABLES (NEW DEVELOPMENT)EI ratio
EO ratio
EQ ratio
ILF ratio
EIF ratio

Business
sector
0.37
0.22
0.22
0.23
0.36

Architecture

Platform

0.41
0.19
0.13
0.06
0.24

0.21
0.16
0.15
0.16
0.18

Programming
Language
0.37
0.22
0.23
0.16
0.35

TABLE V.

RELATIONSHIPS BETWEEN FP ELEMENTS AND
CATEGORICAL VARIABLES (ENHANCEMENT)EI ratio
EO ratio
EQ ratio
ILF ratio
EIF ratio

Business
sector
0.48
0.20
0.36
0.34
0.40

Architecture

Platform

0.29
0.16
0.22
0.18
0.22

0.35
0.15
0.21
0.15
0.29

Programming
Language
0.36
0.23
0.36
0.22
0.31

B. Relationships to Fault Ratio, Productivity, andDevelopment Speed
Table II shows correlation coefficients of FP elements tofault ratio, productivity, and development speed, whendevelopment type is new development. Table III shows thecoefficients when the type is maintenance. Generally, whenabsolute value of the coefficients is larger than 0.2, it isregarded that there is weak correlation. So, we focused on suchcases in the tables, and they are shown by boldface. When thetype is new development, the absolute value of the correlation
between EIF ratio and productivity was larger than 0.2. Also,
when the type is maintenance, the absolute values between EO
ratio and fault ratio, and EQ ratio and fault ratio were larger.
Add, modify, and delete FP ratio, which were recorded only inmaintenance projects, did not have explicit relationships tofault ratio, productivity and development speed. The analysis
result suggests that FP elements did not have strong
relationships to quality, cost and delivery. However, someelements have weak relationships to them. So, using FP
elements as independent variables may improve the accuracyof prediction in some cases.
C. Relationships to Ratio of Each Development Phase
Table II and III also show the relationship between FP
elements and ratio of each development phase. Whendevelopment type is maintenance, ratio of plan phase andimplementation phase had many missing values. So, we did notanalyzed them when the type is maintenance.
When the type is new development, the absolute value ofthe correlation between EI ratio and implementation phaseratio was larger than 0.2. Also, when the type is maintenance,
the absolute values between add FP ratio and test phase ratio,
and modify FP ratio and test phase ratio were larger. It isreasonable that effort of test phase increases when software ismodified greatly. Add FP ratio and test phase ratio were weakcorrelation. This is because add and modify FP are in a tradeoff relationship. From the result, modify FP ratio is expected tobe effective to improve estimation accuracy when test phaseeffort is estimated.
D. Relationships to Nominal Scale Variables
Table IV and V show correlation ratio between FP
elements and nominal scale variables. Table IV includes
analysis results of new development, and Table V does those ofmaintenance. We focused cases where the absolute values werelarger than 0.3, and denote them by boldface. Whendevelopment type was maintenance, the relationships between
FP elements and business sector were relatively strong. Except
for some cases, other nominal scale variables did not havestrong relationships to FP elements, regardless of development
type. The results suggest that FP elements has moderate
relationships to business sector. Overall, FP elements did nothave strong relationships to nominal scale variables, andtherefore it is difficult to use FP elements as the substitution of
the variables.
Additionally, we analyzed relationships of business sector
to add, modify, and delete FP ratio. As a result, correlation
ratio of them were 0.35, 0.34 and 0.18. So, it is not probablethat modify (or add) FP ratio is high (or low) on some businesssectors.
IV. SOFTWARE PROJECT PREDICTION
A. Analogy Based Estimation
The origin of analogy based estimation is CBR (case based
reasoning) [14], which is studied in artificial intelligence field.
Shepperd et al. [15] applied CBR to software development
effort estimation. CBR selects a case similar to current issue
from accumulated past cases, and applies solution of the caseto the issue. CBR assumes similar issues can be solved bysimilar solution. Analogy based estimation assumes
neighborhood (similar) projects (For example, development
size and used programming language is similar) have similar
effort, and estimates effort based on neighborhood projects’
effort. Although ready-made estimation models such as
COCOMO [2] can make estimation without stored software
project dataset, analogy based estimation cannot estimate
without it. It is a weak point of analogy based estimation, but it
can be overcome by using public dataset.
B. Evaluation criteria
To evaluate accuracy of effort estimation, we used averageand median of AE (Absolute Error), MRE (Magnitude ofRelative Error) [3], and BRE (Balanced Relative Error) [12].
When x denotes actual effort, and x̂ denotes estimated effort,
each criterion is calculated by the following equations:
AE = x − xˆMRE =x − xˆ
x(6)(7)

Dependent
variable

TABLE VI.

RELATIONSHIPS BETWEEN PREDICTION ACCURACY AND COMBINATIONS OF EXPLANATORY VARIABLES

Development
type

Independent
variables
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d
a
b
c
d

Maintenance
Number offaultsNew

Maintenance
Project
durationNew

MaintenanceEffortNew

Average AE

Median AE

Average MRE

6.8
5.9
5.4
7.1
7.7
8.6
5.7
5.0
4.3
5.9
3.4
2.9
6.0
6.8
4.8
4.3
2156
2789
2605
2578
3182
3684
3967
3435

3.0
2.3
3.3
2.6
6.4
5.9
4.5
3.5
2.2
2.3
2.0
1.8
3.0
3.2
2.8
2.6
941
1060
1329
1362
1521
1685
2056
2067

148%
142%
141%
220%
341%
372%
170%
175%
113%
203%
82%
87%
100%
111%
75%
85%
140%
199%
174%
175%
145%
173%
157%
189%

 x − xˆ, x − xˆ ≥ 0 ˆx
BRE = ˆx−x
, x − xˆ < 0 
 x


(8)

Lower value of each criterion indicates higher estimation
accuracy. Intuitively, MRE means relative error to actual effort.
However, MRE have biases for evaluating under estimation [9].
Maximum MRE is 1 even if terrible underestimate is occurred(For instance, when actual effort is 1000 person-hour, andestimated effort is 0 person-hour, MRE is 1). So we gave
weight to BRE whose evaluation is not biased [13].
C. Results
In the experiment, the dependent variable of eachprediction was the number of faults, project duration or effort.
To evaluate effect of FP elements to prediction accuracy, we
combined independent variables as follows (we set the pattern‘c’ to compare ‘d’):a.

Application FP, nominal scale variables and FP
elementsb.

Application FP and nominal scale variablesc.

Application FPd.

Application FP and FP elements (used them as thesubstitution of nominal scale variables)

To calculate evaluation criteria, we applied leave-one-out
cross validation and applied analogy based estimation. We set
the number of neighborhoods (parameters needed to apply
analogy based estimation) as four, when the number of faults
was predicted. Also, we set the number as eight, when projectMedian MRE
74%
85%
73%
73%
73%
115%
81%
75%
61%
52%
54%
45%
50%
51%
53%
50%
54%
58%
66%
64%
52%
53%
68%
69%

Average BRE

205%
214%
280%
264%
375%
402%
195%
224%
141%
224%
207%
109%
115%
125%
150%
102%
174%
225%
230%
220%
186%
198%
261%
231%

Median BRE
138%
113%
153%
85%
154%
179%
111%
108%
70%
69%
99%
62%
66%
71%
88%
71%
79%
75%
109%
103%
69%
70%
134%
118%

duration and effort was predicted. Note that some studies [11]predicts project duration.
Application FP and each FP element have strong
relationships, and therefore multicollinearity should beconsidered when multiple linear regression is applied. In
contrast, there is not need to care it when applying analogy
based estimation (Using such variables sometimes enhance
prediction accuracy and vice versa).
Table VI shows prediction accuracy of each variable. We
focused on average and median of BRE, and show theminimum of them by boldface.
Predicting the number of faults: When development typewas maintenance, and independent variables were application
FP and nominal scale variables (b; see subsection C),
prediction accuracy was relatively high (average and median
BRE were the second smallest). On new development, average
BRE was smallest when an independent variable wasapplication FP (c). Median BRE was the smallest when
independent variables were application FP and FP elements (d).
The result suggests that FP elements do not greatly improveprediction accuracy of the number of faults. Note that the
number of projects used for prediction was small (see section
II). To enhance the reliability of the result, more projects areneeded.
Predicting duration: When development type wasmaintenance, and independent variables were application FP
and FP elements (d), average and median BRE were thesmallest. Also, when the type was new development, prediction
accuracy was relatively high by using the independent
variables (d).

Predicting effort: When development type was new
development, and independent variables are application FP,
nominal scale variables, and FP elements (a), average andmedian BRE were the smallest. Also, when the type wasmaintenance, prediction accuracy was relatively high by using
the independent variables (a).

Especially, our result is effective when variables are
selected before estimating effort and duration. That is, it isbetter to use FP elements as independent variables to improve
estimation accuracy of effort and duration.

From the results, when applying analogy based estimation,using FP elements as independent variables is expected toenhance the accuracy of effort and duration estimation. We
applied linear size adjustment [1] in the estimation, and using
FP elements is considered to improve the adjustment. Since inpreliminary analysis, when the adjustment was not used, theaccuracy was not improved.

This research was partially supported by the Japan Ministryof Education, Science, Sports, and Culture [Grant-in-Aid for
Scientific Research (C) (No. 16K00113)]

V. RELATED WORK
Some studies use FP elements as independent variables.
For example, Buglione et al. [4] used them to estimate softwaredevelopment effort. Also, Lavazza et al. [8] used them topredict application FP. This is because measuring application
FP needs effort, and to lessen the effort, some of FP elements
are measured, and based on them, application FP is predicted.
However, as long as we know, past studies did not analyzed theinfluence of FP elements to quality, cost, and delivery
thoroughly. Especially, the relationship between the elements
and the nominal variables, and that of development phase ratio
was not analyzed. Additionally, prediction accuracy of analogy
based estimation using the FP elements was not evaluatedbefore.
VI. CONCLUSIONS
To support data collection and variable selection ofsoftware project prediction, we analyzed the relationships ofFP (function point) elements to quality, cost, and delivery.
Also, we evaluated prediction accuracy when the elements
were used as independent variables on analogy based
estimation. The number of faults, project duration and effort
were used as a dependent variable on the prediction. In theanalysis, we observed the followings:• Overall, FP elements did not have strong relationships
to the fault ratio, productivity and development speed,
except for some cases.
• Modified FP may be effective to improve prediction
accuracy of effort estimation of test phase.
• The strength of the relationship between FP elements
and business sector was moderate. Other nominal scalevariables such as programing language did not havestrong relationship to the elements.
• When duration and effort were estimated by analogy
based estimation, using FP elements as independent
variables was effective to enhance the estimation
accuracy.

ACKNOWLEDGMENT

REFERENCES[1]

M. Azzeh, “A replicated assessment and comparison of adaptation
techniques for analogy-based effort estimation,” Empirical Software
Engineering, vol.17, no.1-2, pp.90-127, 2012.
[2] B. Boehm, Software Engineering Economics, Prentice Hall, 1981.
[3] S. Conte, H. Dunsmore, and V. Shen, Software Engineering, Metrics
and Models, Benjamin/Cummings, 1986.
[4] L. Buglione, and C. Gencel, “Impact of Base Functional Component
Types on Software Functional Size Based Effort Estimation,” ProductFocused Software Process Improvement, Lecture Notes in Computer
Science, Vol.5089, pp.75-89, 2008.
[5] F. Ferrucci, C. Gravino, and F. Sarro, “Exploiting prior-phase effort data
to estimate the effort for the subsequent phases: a further assessment,”
In Proc. of International Conference on Predictive Models in Software
Engineering (PROMISE), pp. 42-51, 2004.
[6] International Function Point Users Group, “IFPUG: Function Point
Counting Practices Manual, Release 4.3,” International Function Point
Users Group, 2010.
[7] International Software Benchmarking Standards Group (ISBSG):
ISBSG Estimating: Benchmarking and research suite, ISBSG, 2004.
[8] L. Lavazza, S. Morasca, and G. Robiolo, “Towards a simplified
definition of Function Points,” Information and Software Technology,
Vol.55, No.10, pp.1796-1809, 2013.
[9] C. Lokan, “What Should You Optimize When Building an Estimation
Model?” In Proc. of International Software Metrics Symposium(METRICS), pp.34, 2005.
[10] C. Lokan, and E. Mendes, “Cross-company and single-company effort
models using the ISBSG Database: a further replicated study,” In Proc.
of the International Symposium on Empirical Software Engineering(ISESE), pp.75-84, Rio de Janeiro, Brazil, Sep. 2006.
[11] C. López-Martín, and A. Abran, “Neural networks for predicting theduration of new software projects,” Journal of Systems and Software,Vol.101, pp. 127-135, 2015.
[12] Y. Miyazaki, M. Terakado, K. Ozaki, and H. Nozaki, “Robust
Regression for Developing Software Estimation Models,” Journal of
Systems and Software, vol.27, no.1, pp.3-16, 1994.
[13] K. Mølokken-Østvold, and M. Jørgensen, “A Comparison of Software
Project Overruns-Flexible versus Sequential Development Models,”IEEE Transactions on Software Engineering, Vol.31, No.9, pp.754-766,
Sep. 2005.
[14] E. Rich, and K. Knight, Artificial Intelligence, McGraw-Hill, 1990.
[15] M. Shepperd, and C. Schofield, “Estimating software project effort
using analogies,” IEEE Transactions on Software Engineeiring, vol.23,
no.12, pp.736-743, 1997.
[16] F. Walkerden, and R. Jeffery, “An Empirical Study of Analogy-based
Software Effort Estimation,” Empirical Software Engineering, vol.4,
no.2, pp.135-158, 1999.