Analysis of Attributes Relating to Custom Software Price

Masateru Tsunoda

Akito Monden, Kenichi Matsumoto

Department of Information Sciences and Arts
Toyo University
Saitama, Japantsunoda@toyo.jp

Graduate School of Information Science
Nara Institute of Science and Technology
Nara, Japan{akito-m, matumoto}@is.naist.jp

Sawako Ohiwa, Tomoki Oshino
Economic Research InstituteEconomic Research Association
Tokyo, Japan{er421, er352}@zai-keicho.or.jp

Abstract—Price of custom software is very important for a user
(end user company). However, there is very little information
which helps the user judge the validity of the custom software
price. So, one of our research goals is building price estimation
model and showing its accuracy for the user to judge thevalidity of the custom software price. The other goal is how to
get value for money custom software. In the analysis, we used
31 projects collected from Japanese organizations. First, weanalyzed relationships of unit price of effort, unit price of FP(function point), and productivity. The analysis result showed
productivity is more important variable than unit price ofeffort for the custom software price estimation. Next,
relationships of other variables were analyzed to identify
important variables for the price estimation. The result
suggested some variables such as system architecture areimportant for that. At the end, the price was estimated basedon FP and effort. In the analysis, when the price was estimatedbased on FP, the median balanced relative error (BRE) was
86.6%, and when it was estimated based on effort, median
BRE was 20.2%.
Keywords-price; estimation; asymmetric information; unit
cost;

I.

INTRODUCTION

Price of custom software is very important for a user (enduser company). Generally, the user uses package softwareand custom software. Versatile software such as word
processor or spreadsheet software is made as package
software, and the user buys it on the market. Custom
software is highly specific software which is made to fit
workflow of each user, and the user orders custom software
to a developer (software development company). In Japanese
end user companies, rate of custom software is 38.7%, rateof used package software is 28.1%, and rate of in-housedeveloped software is 33.2% [12]. That is, custom software
is most important for the user.
Various package software made by various developers issold on many stores. So, the user can judge the validity ofpurchase price of software, comparing functions and pricesof the software with others on the market. On the contrary,

the user does not know functions and prices of software usedin other users’ organization. Therefore, the user cannot
compare functions and prices of custom software with others,
and it is difficult to judge the validity of the custom software
price.
Nature of custom software price is similar to building
price. It is difficult for a purchaser to judge the validity ofbuilding price because each building has high individuality.
In public works, to judge the price of building, the standardof cost estimation method and unit price is defined by
Japanese Government and local government. Based on thestandard, the valid price (standard contract price) is settled
before public works building is developed. On the contrary,
there is very little information which helps the user judge thevalidity of the custom software price.
Also, the uncertainty of the custom software price may
affect the economic efficiency of the society. As stated above,
the user has not enough information of the price. It is called
asymmetric information in economics. Asymmetric meansthat the user has poor information of software but thedeveloper has rich information. The user cannot reach the
optimal price because cost and time to search the price arelimited [18]. As a result, the trading price (i.e. costeffectiveness) become different on each trade, and thatcauses imperfect competition (Software whose price andquality is not balanced is saleable, i.e., some users buy such
software). Minimizing the difference (i.e. balancing priceand quality) will shift the economy from imperfectcompetition to perfect competition (Software whose priceand quality is balanced is more saleable), and that promotes
economic efficiency. To minimize the difference, theinformation about the custom software price is needed.
One of our research goals is building a price estimation
model and showing its accuracy for the user to judge thevalidity of the custom software price (Note that our researchgoals are not building the model for the developer to settle
the price, and therefore the model is not optimized for thedeveloper). The other goal is how to get value for money
custom software. To achieve the goals, we set researchquestions as follows:•

RQ1: To get value for money custom software, whatshould the user pay attention to?
• RQ2: Which variables should be used to build aprice estimation model?
• RQ3: How much is estimation error of the pricewhen the price is estimated simply by multiplying avariable such as functional size by a constant?
RQ1 is set for the latter goal (the way of getting value formoney software). RQ2 is set for the former goal (building
the estimation model). We do not build the price estimation
model yet. The answer of RQ2 will be useful to build themodel. RQ3 is also set for the former goal. Instead of themodel, we used simple estimation method and analyzed its
estimation error. Note that we did not show the constant of
the simple method, to avoid abusing the result.
Section 2 describes dataset used in the analysis. Section 3
explains preliminary analysis of relationships of price,function point (FP), and effort. In Section 4, relationships ofunit price of effort, unit price of size, and productivity are
analyzed. In Section 5, the price is estimated based on FP
and effort. Section 6 explains related works, and Section 7
concludes the research.
II.

DATASET

The dataset used in the analysis was collected from 114
Japanese organizations by Economic Research Association[6]. The dataset includes 163 software development projects,
and the range of employees of organizations is from several
to about 40,000 people. Variables in the dataset have missing
values. To align conditions of analyzed projects, we selected
new development projects which performed basic design,detailed design, coding, integration test, and system test.
After the selection, we eliminated projects where actual
effort, actual function point (FP), or price were missing. As aresult, we chose 31 projects.
The dataset including custom software price collectedfrom various organizations is very rare and valuable. If thedataset collected from few organizations is analyzed, theanalysis result may be affected by individuality of theorganizations such as payroll system or profits. Although weanalyzed only one dataset, we think the analysis results havegenerality to some extent because it is cross company dataset.
Variables included in the dataset are as follows:• User classification: affiliated company of thedeveloper = 0, non-affiliated company of thedeveloper = 1 (the developer is not an affiliatedcompany of the user).
• Contract classification (basic design phase): mandate= 0, contract for work = 1.
• Effort, function point (FP; a metric of software size),and duration (estimated and actual value).
• Error of effort, error of FP, error of duration: (actual
value - estimated value) / actual value.
• System architecture: Web based system = 0, client
server system = 1.
• Operating system of the server: Linux = 0, Windows2000 = 1, other OS = missing value.

•

ILF/FP, EIF/FP EI/FP, EO/FP, EQ/FP: actual value /actual FP (ILF, EIF, EI, EO, and EQ are element
metrics of FP).
• Screen/FP, report/FP, file/FP: number of the elementin the custom software / actual FP.
• Price: price which the developer regarded as valid
price.
We defined ILF/FP, EIF/FP, EI/FP, EO/FP, and EQ/FP.
Values of ILF, EIF, EI, EO, and EQ increase in proportion to
FP. So, ratios such as ILF/FP may be more preferable thanvalues such as ILF, to emphasize features of custom software.
We also defined screen/FP, report/FP, and file/FP for thesame reason.
In the dataset, variable “price” is not actual price, butvalid price which the developer regarded as. Actual price isaffected by the relationship between the user and thedeveloper. So, using the valid price is more preferable than
the actual price, considering the research goal (validating
custom software price).
There is not an understanding of the error margins
reported in the dataset. To verify the dataset as correct, we
confirmed actual effort and actual FP did included abnormal
values. In addition, we verified price using unit price(described in section 4). In preliminary analysis, we made aneffort estimation model using the dataset and the model
showed relatively high estimation accuracy. So, we think thedataset does not include low quality data very much.
III.

PRELIMINARY ANALYSIS OF PRICE, FP, AND EFFORT

A. Selecting explanatory variables
As preliminary analysis to answer RQ1, we analyzed
relationships between the price and actual effort, and theprice and actual FP. The reason of selecting FP is as statedbelow. One of our goals is building the price estimation
model for user to judge the validity of the price. So,
considering usability, it is not good for the user to use many
variables to judge the validity, or to use variables whose
values are difficult to know for the user. We regarded FP as
the fittest variable to the conditions.
In contrast, the developer can settle custom software
price based on rich information such as estimated ratio of
each development phase, ratio of staff of each rank such as
project manager and programmer, and estimated effort.
However, the user does not know such information generally,
and therefore the model should not include variables
including such information. Note that preliminary analysis
showed that ratio of each development phase and ratio ofstaff of each rank did not relate to the price explicitly.
The reason of selecting effort is as stated below. One of
the major pricing methods is cost-plus pricing, which setssum of cost and profit as price. We assumed that price ofcustom software is settled by the method in many cases, andtherefore, if effort is roughly same as cost, effort has a strong
relationship to the price. Although the user does not know
effort, the analysis results clarify the followings:• If the relationship is not very strong: cost-plus
pricing is not used widely, or other variables such asPrice (normalized)240

ρ = 0.92
190
140
90
40
-10
-60
0

20000

40000

60000

Actual Effort
Figure 1. The relationship between the price and actual effort.

Price (normalized)240

ρ = 0.67

190
140
90

IV.

40
-10
-60
0

2000

4000

Actual FP
Figure 2. The relationship between the price and actual FP.

•

completely. The dataset includes projects in small companies
and large companies, and therefore payroll system orworkload of back-office section may be different for eachdeveloper. So, there was a possibility that actual effort did
not relate to cost strongly. In addition, ratio of staff of eachrank such as project manager and programmer appear to bedifferent for software (especially when the number of staff is
not large), and it might weaken the relationship between
actual effort and cost. Profit added to the price may different
for each developer, and there was a probability that it
weakened the relationship.
Considering the strong relationship between actual effort
and the price, above factors do not seem to affect the pricestrongly. A major finding of the preliminary analysis is thateffort is roughly same as the custom software price, andanalyzing the price without above factors is reasonable. Also,
the result suggests that detail task information which thedeveloper uses on WBS (work breakdown structure) based
estimation is not necessary to judge the validity of the price,because effort (without the detail task information) explains
the price very well.

unit price of staff and profit of each developer are
affected to the price to some extent.
If the relationship between effort and the price isstrong: variables such as unit price of staff and the
profit do not affect the price greatly.

B. Analysis results
To analyze relationships of the variables, we used
Spearman’s rank correlation coefficient and scatter plots. Fig.
1 shows the correlation coefficient ρ and the scatter plot of
the price and actual effort, and Fig.2 shows that of the priceand actual FP. A data point whose price was very high waseliminated from the figure (Note that it was not eliminatedwhen the correlation coefficient was calculated). The price inthe figure is not actual price, but calculated by subtracting
median from actual price.
The correlation coefficient between the price and actual
effort was very high, and the strong relationship was also
observed in the figure. That is, effort has strong relationshipto the custom software price. The relationship between FP
and the price was strong to some extent. However, it is noteasy to judge the validity of the price by FP only, because
the diffusion of data points was not small (the relationshipbetween the price and FP is not very strong). Bothrelationships were statistically significant at 0.05 level.
The analysis result (the very strong relationship between
the price and actual effort) is not exactly obvious, even if
sum of cost and profit is set as the price by the cost-plus
pricing method. Effort does not correspond to cost

ANALYSIS OF UNIT PRICE OF EFFORT, UNIT PRICE OF
SIZE, AND PRODUCTIVITY

A. Definition of ratio variables
Using two variables whose relationship was strong, one
variable was divided by the other variable, and new ratio
variables were defined. New variables are as follows:• Unit price of effort: price / actual effort• Unit price of size: price / actual FP• Productivity: actual effort / actual FP
Note that the productivity is the reciprocal of the common
definition [11] (It is also called project delivery rate (PDR)).
We identified two data points whose unit price of effort issmaller than 1,500 yen as outliers, and removed them fromanalyses.
Generally, on a software project dataset, the strong
relationship is approximately denoted as follows:
y=ax

(1)

y=xb

(2)

In the equation, x and y are the variables, and a and b are
constants (Error term is not included in the equation). When
Spearman’s rank correlation coefficient is high, both
relationships are possible. When the two variables have thelatter relationship, dividing one variable by the other variable
does not become constant value.
The aim of the analysis in this section is to analyze
relationship between price, effort, and FP in more detail.
Using the new variables enable detail analysis. For instance,
using unit price of size, we can analyze whether the unit
price of size varies or not when the price becomes higher. It
cannot be confirmed by the preliminary analysis. The aim of
the preliminary analysis is to confirm influence of factors
such as the unit price of staff and the profit.

TABLE I.

relationship between productivity and unit price ofsize (and the relationship between the price and unit
price of size).
Actual FP weakly related to other variables such as
Unit price of size. So, an additional answer to RQ1 is“There is not strong need for the user to pay
attention to software size to enhance costeffectiveness, at a maximum size of 5,500 FP (themaximum value of FP in the dataset).”THE CORRELATION COEFFICIENTS OF THE PRICE, FP,
AND THE RATIO VARIABLES
Price

Unit price ofeffortUnit price of
size

-0.4

0.0

0.4

Productivity

0.18(0.36)
0.55(0.00)
0.55(0.00)

ActualUnit price Unit priceFPof effort of size
-0.27
(0.16)-0.15
0.49(0.45)(0.01)
-0.08
0.17
0.93
(0.68)(0.38)(0.00)

Error ofFP

Error ofeffortError ofduration

Figure 3. The variances of the errors.

B. Relationships of the ratio variables
The correlation coefficients of variables are shown in
Table 1. Italic face means the relationship was statisticallysignificant at 0.05 level. P-values are shown in parentheses.
Major observations are the following:• The relationship between the price and unit price ofeffort was weak. So, unit price of effort is notdiscounted (cost-effectiveness is not greatlychanged), regardless of the price.
• The relationship between FP and unit price of size
was weak. This means that unit price of size is notdiscounted (changed) much, regardless of FP.
• Unit price of size (i.e. cost-effectiveness) related to
productivity more strongly than unit price of effort(i.e. unit price of staff). Higher productivity makes
higher cost-effectiveness. Therefore, the answer of
RQ1 is “The user should give weight to productivityof the developer more than unit price of staff.”
Maxwell et al. [11] also pointed out that thedifferences of productivity are large amongdevelopers. Similarly, when the developer
outsources software development to subcontractors,
it should care about productivity of thesubcontractors more than unit price of staff.
• The relationship between productivity and unit priceof effort was weak. That is, unit price of effort is not
expensive on high productivity developers.
• The relationship between productivity and the price
was moderately strong. This may because therelationship was affected by strength of the•

C. Candidate explanatory variables of the model
To select candidate explanatory variables of the priceestimation model, we analyzed relationships between theratio variables such as productivity and other variables
explained in section 2. We assume the estimated number ofscreens, reports, and files are decided after design phase. So,(estimated) screen/FP, report/FP, and file/FP are used for the
candidate explanatory variables. Note that actual duration,
error of duration, error of FP, and error of effort are not thecandidate explanatory variables. They were used for otheranalysis.
The correlation coefficients are shown in Table 2. In thetable, italic face means the relationship was statisticallysignificant at 0.10 level (We did not set significant level
severely because the purpose of the analysis is to selectcandidate variables. The significance level of 0.1 issometimes used [1][8][16] to avoid type I error). Systemarchitecture, EIF/FP, EI/FP, screen/FP, and report/FP related
to the ratio variables. They may indirectly denotecharacteristics of custom software such as mission-criticalsystem, and the characteristics may affect the price. For
example, when developing software needs high reliability, it
may needs higher unit price of size, because more testing isneeded and it lowers productivity. Based on the analysis
results, the answer of RQ2 is “System architecture, EIF/FP,
EI/FP, screen/FP, and report/FP should be used as candidate
variables of the model, in addition to FP.”
Error of duration, error of FP, and error of effort did not
relate to the ratio variables. Therefore, the analysis results are
considered to be not affected by project failure such as cost
overrun. In the dataset, error of duration, error of FP, anderror of effort were small, as shown in Fig. 3. However, if
they are large, it may affect the result.
V.

PRICE ESTIMATION BASED ON FP AND EFFORTTo answer RQ3, we analyzed estimation error of theprice when it was estimated simply by multiplying FP or
effort by the unit price (Building the price estimation modelusing the candidate explanatory variables identified in
section 4 is the future work). The price is estimated asfollows:zˆ = xi ~x(3)zˆ = yi ~y(4)TABLE II.
THE CORRELATION COEFFICIENTS OF CANDIDATEEXPLANATORY VARIABLES AND THE RATIO VARIABLES

User classification
Contractclassification
Estimated duration
Actual duration
Error of duration
Error of FP
Error of effort
System architecture
Operating system of
the server
ILF/FP
EIF/FP
EI/FP
EO/FP
EQ/FP
Screen/FP
Report/FP
File/FPTABLE III.

Unit price of Unit price
Productivity
Effort
of FP
0.04
0.16
-0.19
(0.32)(0.83)(0.39)
0.23
0.24
0.24
(0.28)(0.25)(0.25)-0.07(0.71)-0.11(0.59)-0.25

0.05(0.79)
0.07(0.72)-0.12

0.07(0.71)
0.09(0.65)-0.09(0.21)-0.25(0.26)(0.55)-0.31(0.14)(0.65)-0.23(0.30)-0.08(0.70)
0.02(0.92)-0.11(0.63)
0.13(0.62)-0.66

0.11(0.61)-0.38(0.04)
0.23(0.34)-0.18(0.47)-0.26

0.18(0.41)-0.47(0.01)
0.28(0.23)-0.26(0.30)
0.01(0.01)
0.61(0.02)(0.35)
0.41(0.13)(0.96)
0.20(0.47)-0.12(0.67)-0.16(0.56)
0.34(0.08)
0.07(0.73)
0.09-0.10(0.71)
0.00(1.00)
0.35(0.07)
0.51(0.01)
0.29

-0.10
(0.7)
0.08
(0.77)
0.26(0.19)
0.54(0.00)
0.29(0.67)(0.14)(0.14)MEDIAN BRE ON THE PRICE ESTIMATIONMedian 95% confidence 95% confidence
BREinterval (lower) interval (upper)
FP based estimation
86.6%
53.1%
249.0%
Effort based estimation 20.2%
8.4%
34.1%

In the equations, ẑ is estimated price, xi is actual effort of
the target project, ~x is the median of unit cost of effort, yi isactual FP of the target project, and ~y is the median of unit
cost of FP. Each price was estimated based on leave-one-out
cross validation (i.e. the median was calculated with leaveone-out cross validation). Note that we did not show themedian, to avoid abusing the result.

To evaluate accuracy of the estimation, we used medianof BRE (Balanced Relative Error) [13]. When x denotes
actual price, and x̂ denotes estimated price, BRE is
calculated by the following equation:
 x − xˆ, x − xˆ ≥ 0 
BRE =  x

ˆ
x
−
x

, x − xˆ < 0 
 xˆ


(5)

Lower value of BRE indicates higher estimation accuracy.
MRE (Magnitude of Relative Error) [4], the popular criterion
to evaluate estimation model, has biases for evaluating under
estimation [3]. Maximum MRE is 1 even if terrible
underestimate is occurred (For instance, when actual price is
1,000,000 yen, and estimated price is 0 yen, MRE is 1). So
instead of MRE, we adopted BRE whose evaluation is notbiased [14].
Additionally, we performed interval estimation of median
BRE by bootstrapping. Bootstrapping is one of theresampling methods [7], and it randomly extracts cases fromthe dataset. The number of extracted cases is the same as thedataset allowing some cases to be extracted more than once
(that is, sampling with replacement). For example, given a fit
dataset containing cases {M1, M2, M3, M4}, bootstrapping
extracts a sample such as {M1, M1, M2, M3} or {M1, M2, M2,M4}. Generally, the extraction is repeated 1000 times.
Table 3 shows median BRE of the price estimation andthe 95% confidence interval. Based on the result, the answer
of RQ3 is “When FP and unit price of FP are known,estimation error (BRE) will be about 87% (at least 53%, at
most 249%). So, when FP and unit price of FP are used toestimate the price, the prediction accuracy is not sufficient tovalidate the price accurately. However, it may be applicable
to identify extremely high or low price (i.e. validate priceroughly).
When effort and unit price of effort are known,estimation error will be about 20% (at least 8%, at most34%).” Effort estimation (e.g. [2], [17]) may be also applied
for the user to judge the validity of the custom software price,because price estimation based on effort showed highaccuracy.
Fig. 3 shows boxplots of the ratio variables. Each value
was normalized by dividing by the median. In boxplots, thebold line in each box indicates the median value. Small
circles indicate outliers, that is, values that are more than 1.5
times larger than the 25%-75% range from the top of the box
edge. The reason of lower accuracy of FP based estimation isthat variance of productivity of projects was larger than unit
price of effort (see Fig. 3), and it made variance of unit priceof FP larger.
The difference of productivity is considered to be notcaused by effort (cost) overrun. Fig. 4 shows productivity
based on estimated value and actual value. The productivity
based on actual value was slightly smaller (better) thanestimated value. The result suggests effort overrun seldom
occurred. So, the difference of productivity was considered
to be caused by the difference of the each developer’s

0

2

4

6

8

VII. CONCLUSIONS

Productivity
Unit priceof effort

Unit price
of FP

30

40

Figure 4. The variances of the ratio variables.

Our research goal is to give useful information for theuser (end user company) to judge the validity of custom
software price. To achieve the goal, we set three researchquestions, RQ1 to RQ3. We analyzed 31 custom softwaredevelopment projects collected from Japanese organizations,and answered to them as follows:• Answer of RQ1: The user should give weight toproductivity of the developer (software development
company) more than unit price of staff.
• Answer of RQ2: System architecture, EIF/FP, EI/FP,
screen/FP, and report/FP should be used as candidate
variables of the price estimation model, in addition
to FP.
• Answer of RQ3: When FP and unit price of FP are
known, estimation error (BRE) will be about 87%.
When effort and unit price of effort are known,estimation error will be about 20%.
Our future work is to build custom software priceestimation model, and to analyze the accuracy.

20

REFERENCES

10

[1]

Actualproductivity

Estimated
productivity

Figure 5. The difference of estimated and actual productivity.

performance, or the difference of difficulty of each custom
software development.
VI.

RELATED WORK

To our knowledge, there is no research which analyzed
variables relating to custom software price. So, there is little
information for the user to judge the validity of the price.
Some researches proposed price determination methods for
package software [9][15]. However, the methods are used forthe developer to gain maximum profit, and therefore they are
not used for the user to judge the validity of the custom
software price.
There is a research which analyzed variables relating tocost to sales ratio of custom embedded software [19].
However, cost to sales ratio does not relate to the pricedirectly, and hence the analysis results are not used for theuser to judge the validity of the price.
Analysis results in Section 2 suggest that ratio of staff ofeach rank such as project manager and programmer is notnecessary to judge the validity of the price, because the mostpart of the price was explained by effort. Dong et al. [5]indicated the staffing pattern has no significant effect on
productivity. The suggestion of our result is reinforced by the
research.

J. Blackburn, G. Scudder, and L. Wassenhove, “Improving Speed andProductivity of Software Development: A Global Survey of Software
Developers,” IEEE Transactions on Software Engineering, vol. 22, no.
12, pp. 875-885, 1996.
[2] B. Boehm, Software Engineering Economics, Prentice Hall, 1981.
[3] C. Burgess, and M. Lefley, “Can genetic programming improve
software effort estimation? A comparative evaluation,” Journal of
Information and Software Technology, vol. 43, no. 14, pp. 863–873,
2001.
[4] S. Conte, H. Dunsmore, and V. Shen, Software Engineering, Metrics
and Models, Benjamin/Cummings, 1986.
[5] F. Dong, M. Li, J. Li, Y. Yang, Q. Wang, “Effect of staffing pattern
on software project: An empirical analysis,” In Proc. of International
Symposium on Empirical Software Engineering and Measurement(ESEM), pp.23-33, Lake Buena Vista, FL, Oct. 2009.
[6] Economic Research Association, http://www.zai-keicho.or.jp/about/english.php[7] P. Good, Resampling Methods: A Practical Guide to Data Analysis,
Birkhäuser Boston, 2005.
[8] N. Lee, and C. Litecky, “An Empirical Study of Software Reuse with
Special Attention to Ada,” IEEE Transactions on Software
Engineering, vol. 23, no. 9, pp. 537–549, 1997.
[9] Y. Liu, H. Cheng, Q. Tang, and E. Eryarsoy, “Optimal software
pricing in the presence of piracy and word-of-mouth effect,” Decision
Support Systems, vol. 51, no. 1, pp. 99–107, 2011.
[10] C. Lokan, T. Wright, P. Hill, and M. Stringer, “Organizational
Benchmarking Using the ISBSG Data Repository,” IEEE Software,
vol. 18, no. 5, pp. 26-32, 2001.
[11] K. Maxwell, and P. Forselius, “Benchmarking Software Development
Productivity,” IEEE Software, vol. 17, no. 1, pp. 80–88, 2000.
[12] Ministry of Economy, Trade and Industry, Japan, Information
processing survey on actual situation. Ministry of Economy, Tradeand Industry, Japan, 2004. (In Japanese)[13] 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.
[14] K. Mølokken-Østvold, and M. Jørgensen, “A Comparison ofSoftware Project Overruns-Flexible versus Sequential Development
Models,” IEEE Transaction on Software Engineering, vol. 31, no. 9,
pp. 754–766, 2005.

[15] M. Murtojärvi, J. Järvinen, M. Johnsson, T. Leipälä, and O.
Nevalainen, “Determining the Proper Number and Price of Software
Licenses,” IEEE Trans. on Software Eng., vol. 33, no. 5, pp. 305–315,
2007.
[16] P. Runeson, and C. Wohlin, “An Experimental Evaluation of anExperience-Based Capture-Recapture Method in Software CodeInspections,” Empirical Software Engineering, vol.3, issue 4, pp.381–
406, 1998.

[17] M. Shepperd, and C. Schofield, “Estimating software project effort
using analogies,” IEEE Transaction on Software Engineering, vol. 23,
no. 12, pp. 736–743, 1997.
[18] G. Stigler, Theory of Price. Prentice Hall College Div, 1987.
[19] H. Uwano, Y. Kamei, A. Monden, and K. Matsumoto, “An Analysis
of Cost-Overrun Projects Using Financial Data and Software
Metrics,” In Proc. of Joint Conference of International Workshop on
Software Measurement and International Conference on Software
Process and Product Measurement (IWSM/Mensura 2011), pp. 227–
232, Nara, Japan, Nov. 2011.