Content uploaded by Senthilvelmurugan Manivannan
Author content
All content in this area was uploaded by Senthilvelmurugan Manivannan on Nov 09, 2019
Content may be subject to copyright.
Content uploaded by A. Seetharaman
Author content
All content in this area was uploaded by A. Seetharaman on Oct 29, 2015
Content may be subject to copyright.
Budgeting and accounting of
software cost: Part 1
A. Seetharaman
is Associate Dean & Chairman, Center for Multimedia Banking, Investment & Accounting Center for Multimedia
Banking, Investment & Accounting, Faculty of Management, Multimedia University, Malaysia. He has published over 60
articles in international refereed publications and is a member of the Malaysian Account Research and Education
Foundation.
M. Senthilvelmurugan
is a part-time lecturer in IT at the Faculty of Management, Multimedia University, Malaysia. He holds a Masters degree
in information technology.
T. Subramanian
is a lecturer in IT at the Faculty of Management, Multimedia University, Malaysia. He holds Masters degrees in
computer applications, business administration and economics.
Keywords: costing systems, costing models, function point analysis, software
development lifecycle
Abstract Many organizations today invest hugely in developing and launching
information systems. The costs include labor-related consultation, software
development and design fees, as well as software and hardware expenditures.
However, with the subjective nature of software development, the estimation of
software cost is usually inaccurate. Such organizations generally consult a software
vendor to deliver information systems based on a set of specific user requirements.
Deterministic approaches to software development cost are often miscalculated,
however, and the end result is usually a higher cost for the customer. The scope of
this study is limited to the fundamentals of software cost estimation approaches and
how the results of these cost models are used to determine software cost. This paper
is not a software engineering model. It focuses on only a subset of the software
development lifecycle (SDLC) pertaining to the estimation of software size and cost.
This paper highlights the issues determining the size of software and how they relate
to the accounting and budgeting of software cost through the estimation of various
software metrics to empirically predict the cost involved before starting development.
The paper also discusses how project and software costs are derived from the results
obtained from the cost metrics. For this purpose, a practical six-step approach is
derived and presented. Finally, the limitations are discussed and a conclusion is given.
The paper consists of two parts. The first part deals primarily with a survey of
literature reviewing the trends in costing systems and constructive cost models. The
second part of the paper will deal with selected case studies, models, discussion,
analysis and findings.
INTRODUCTION
In the middle of the 20th century,
hardware played a dominant role in
determining the total cost of electronic
data processing systems. It was an era of
hardware-driven software. To meet the
ever-mounting difficulties of the business
world, there was a rapid growth of
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
347
Dr. A. Seetharaman
Associate Dean &
Chairman
Center for Multimedia
Banking, Investment &
Accounting,
Faculty of Management,
Multimedia University,
63100 Cyber Jaya,
Malaysia.
Tel: +60 3 8312 5573
Email:
seetha@mmu.edu.my
information technology and information
systems leading to the age of software-
driven hardware. This led to a situation
in which a sizable percentage of the total
cost of computer projects was being
spent on software development. With
the dawn of customer-driven software
development, software costs further
increased to around 80–90 per cent of
the total cost of tailor-made IT projects.
Controlling and accounting for
software costs are pressing problems for
accountants and other managers, both in
the systems and in the management
accounting areas of the business. The
main areas of software production
activity are designed, developed, and
monitored by specialist software houses.
Software development cost control is,
incontrovertibly, an important issue.
Over- or under-estimation of the cost,
late deliveries, poor quality, non-
compatibility with hardware are
examples of the seemingly intractable
problems encountered in software
development and maintenance activities
leading to the software crisis.
Many authors have previously stressed
the reuse of software for different
purposes. Nevertheless, despite
numerous papers in the areas of software
architecture, development, and software
reuse, authors have only addressed the
economics of software. Understanding
the determinants of software cost plays a
critical role in software engineering
management and control.
RESEARCH PROBLEM
Many companies are spending large
sums of investments to develop and
launch information systems. These costs
include labor-related consultation and
software development, plus design fees,
as well as software and hardware
expenditure. However, with the
subjective nature of software
development, the estimation of software
cost is usually inaccurate. This problem
is usually related to the following
reasons:
.Thousands of software projects require
significant investment from the customer
without corresponding justification of
the actual cost of the project itself. Many
proposals and sales on software systems
are made with inaccurate assumptions
that lead to unnecessary high investment
expenditure.
.Many research papers focus on issues
pertaining to software cost metrics to
determine the efforts required to deliver
the information system. However, the
information presented does not detail the
accounting part of software costing.
.Many research papers are not intuitive
enough to allow an inexperienced
project manager to gauge the
understanding into the complexities of
software cost estimation using the
available cost metrics.
.The problem of using jargon in the
research papers is confusing and
sometimes even conflicting. For example,
some papers use the term cost models to
denote the techniques used to determine
the size of software; others use the term
cost metrics.
.There is a lack of additional evidence to
justify which cost estimation method to
use for a particular situation. The papers
in the literature focus on a set of
industries only — this may bias the
conclusion to those specific industries.
Objectives
The objectives of this research are:
.to explore the benefits of using cost
metrics when determining software cost
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)348
Seetharaman, Senthilvelmurugan and Subramanian
over the conventional ‘‘gut feeling’’
approach;
.to identify how labor effort (results
obtained from using the cost metrics) can
be turned into software cost;
.to provide a better understanding of the
various cost metric approaches and
which should be used in a particular
scenario;
.to compare the different cost metric
approaches.
Scope
The scope of this study is limited to the
fundamentals of software cost estimation
approaches and how the results of these
cost models are used to determine
software cost. It is necessary to
emphasize that this paper is not a
software engineering model. It focuses
only on a subset on the software
development lifecycle (SDLC)
(determining the project scope and cost
during project proposal stage in the
SDLC) pertaining to the estimation of
software size and cost. However, the
accounting process of how the software
cost is derived from results obtained
from the cost models will be discussed.
RESEARCH METHODOLOGY
The information presented in this paper
was obtained from various sources of
secondary data. The sources came
mostly from the internet via search
engines like Google, MetaSearch,
Altavista and online searches from
reputable online databases like ProQuest,
Emerald Library and ACM Digital
Library. The database sites were able to
provide secondary data from sources
Use of cost metrics to determine
software cost
COCOMO
COCO
MFPA
CMM
Other
models
Problems and issues in determination of
accurate basis of software cost
Six steps solution to Enigma
Figure 1: Research framework on determination of software cost
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
349
such as journals and extracts from
newspapers, books and magazines.
Other references were also sought from
compiled resources from the University
library and books. More than 40
research papers were obtained pertaining
to software costing.
The information obtained from these
sources went through a rigorous process
of short-listing. The authors vetted the
information found within the research
papers and selected more than 20 articles
to be included into this paper. The
authors decided to classify the research
papers as depicted in Figure 1.
The next step was to analyze the
information and to start preparing the
document framework. Authoring
commenced in tandem with analysis of
the survey. The results from the surveys
were processed to obtain a set of
discussions, analysis and findings for this
paper.
SURVEY OF LITERATURE
To facilitate meaningful discussion, it is
necessary to place the literature into a
framework for understanding and to
serve as a ‘‘launch pad’’ for the
contribution of prior work to the
current paper. For this purpose, the
survey of literature is grouped and
presented under various headings
namely, trends in costing systems,
constructive cost model (COCOMO),
function point analysis (FPA), and other
models and case studies.
Trends in costing systems
Describing trends in costing software,
Walker
1
stated that cost estimation
models in software engineering were
introduced with the prevailing of
computers in the mid-1960s. The cost
estimation techniques were introduced
to reduce the difficulty in estimating the
size of software projects, with the hope
of eliminating the ‘‘gut feeling
approach’’ of estimating software cost.
In the early 1960s, software engineering
was based on craftsmanship,
2
where the
skills of the project team greatly
contributed to the success of the project.
Each of the projects had custom-built
tools and processes in place and re-
usability of software codes was scarce.
Through the 1980s and 1990s, the
software industry matured with the
availability of more software cost
models and methodologies. However,
even with the abundance of such cost
models, this era of software engineering
still focused greatly on research and
development (R&D), hence the
economies of software cost still
depended on the creativity of the project
team.
3
This situation in the software industry
today has, however, changed. The
software process is more driven towards
a productive-centric approach where,
with the availability of case tools and
methodologies, the software project
team can now focus on the real problem
of building the information system and
not on the engineering process itself.
The trends in software engineering are
depicted in Figure 2.
4
Over the years, it
can be seen that budgeting the cost and
deriving estimated efforts and timeline
for software are becoming more
predictive and accurate.
However, Walker has not detailed the
reasons why software projects still fail
due to running over budget and
timeline. Even with the available tools,
why are some projects successful while
others fail to meet their objective? The
various points of failure in software
engineering should have been covered
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)350
Seetharaman, Senthilvelmurugan and Subramanian
using modern cost estimation
techniques, supplemented by effective
measures to tackle them.
Chulani
5
and Boehm et al.
6
suggested
that there are several ways to estimate
the cost of software engineering. The
various methods available suggest that
there is no one way to estimate software
development cost, and that it is a
subjective matter.
Over the past several decades, there
has been a growing number of software
cost estimation techniques, parametric
models, expertise techniques, dynamic-
based models, models that utilize
Bayesian techniques, and many more
that face the challenges of ever-changing
information technology. With the
advent of Unified Modeling Language
(UML), XML, and web services, such
metric models require revision in order
to sustain a level of accuracy in the real
world.
Chulani suggested that although many
techniques are available, no one
technique is better than the rest. It is up
to the project team to decide the best
estimation approach to use and,
sometimes, a combination of the
estimation models is desirable to obtain
the best result for a particular situation.
The authors, however, did not
recognize that the estimation techniques
used are strongly coupled to their
environment, the project team and the
nature of the software itself. These
factors provide risks that are inherent
during software development and can
pose a threat to software completion.
Verner and Evanco
7
identified the
reasons why software projects fail due to
under-budgeting and lack of resources.
Figure 2: Trends in software economics
Source: Walker, R. (2001) ‘‘Improving software development economics Part 1: Current trends’’ (see ref. 1).
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
351
The authors surveyed the practice of
software cost estimation in real business
environments. Their research tended to
combine the tangible and intangible cost
factors that many other research papers
failed to address.
Their survey found that only one-
third of software projects involved the
project manager during the initial
software cost estimation. They found
that predicting a realistic software cost
estimation was necessary to the success
of implementing the said software. The
majority of the project managers were
not involved in the initial software cost
estimation.
The authors also stressed that
identifying and allocating the right
number of resources (programmers) to
the project is key to its success or failure.
This factor is particularly important in
projects with an aggressive schedule.
The authors found that the effect of
adding staff (programmers) very late in
the project schedule could be disastrous.
Indeed, many projects failed because of
failing to add staff earlier in the project
development lifecycle.
A shocking discovery was that all the
surveyed projects were over-estimated,
which shows that optimism still
prevailed during the software budgeting
process. Almost all the projects were
estimated with unclear requirements,
leading to assumptions. The lack of
proper risk management adds to the
predicament of software failure (under
budget, over schedule and lack of staff).
The quality of data samples was,
however, a drawback to this study.
None of the surveyed projects used the
proper cost estimation methods discussed
in this paper (COCOMO, function
point etc). This did not reflect the
ideology of software cost estimation
theory, which suggests that with the
proper cost estimation process, the
chances of under-budgeting and staffing
would be reduced greatly. Hence,
Verner and Evanco might have provided
a more robust conclusion had the data
samples been segregated accordingly.
Constructive cost models 1 and
2 (COCOMO)
The original COCOMO cost estimation
method was introduced due to the
experience of increasing difficulties in
estimating the cost of software.
However, as software matured to levels
beyond those that COCOMO could
support, Boehm derived a new metric
model from the COCOMO model,
and introduced COCOMO 2 in 1981.
8
The COCOMO 2 model is a hybrid
of software sizing methods, ranging
from object point analysis, function
point analysis and source line of
code and including source code
reusability. The objectives of
COCOMO were:
.to address the issues of modern software
development and to pre-determine cost
and schedule before the project has
started;
.to collect data and statistics on current
software cost so as to provide a set of
data to empirically enhance and improve
on the COCOMO model;
.to provide a quantitative analytical
framework, tools and techniques for
evaluating the software lifecycle to
further improve the software lifecycle
cost and schedule.
Boehm discussed the future trends of
software engineering and how his cost
model could be used to derive sizing and
cost estimation for the software. He also
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)352
Seetharaman, Senthilvelmurugan and Subramanian
discussed the differences between
COCOMO and COCOMO 2, and the
strategy and rationale behind the
introduction of the COCOMO 2
model. Boehm showed empirically how
gross effort was calculated from the
components of COCOMO 2 (using
object and function point analysis) and
how the introduction of cost drivers
affected the net effort of the software,
which in return could be used to
calculate software cost.
Boehm did not, however, mention
that software cost also depends on a few
intangible cost factors that can only be
derived from past project experience,
historical data and through observation
of the project team’s competency.
Intangible cost factors that can
contribute to the increase in software
cost include: skills and experiences of the
project team members (project manager,
system analyst, analyst programmers,
programmers); delays due to unforeseen
circumstances like change in
governmental policies which directly
affect the software system (payroll, HR
management systems) etc; and the
competency of the customer’s project
team in managing the project.
Abts et al.
9
discussed another cost
estimation model for software which is a
derivation of the COCOMO model
introduced by Boehm. The model,
known as the constructive commercial-
off-shelf (COCOTS) model can be used
to estimate cost for small to medium-
sized software projects with average
complexity. However, it has its
limitations in dealing with larger
projects and other cost models like
COCOMO 2 should be used instead.
The authors provided a module
overview of COCOTS, describing the
four sub-models:
.Assessment: the activity whereby COTS
software products are vetted and selected
as viable components for integration into
a larger system.
.Tailoring: the activity whereby COTS
software products are configured for use
in a specific context.
.Glue code: the new code needed to get a
COTS product integrated into a larger
system.
.Volatility: system volatility effort (SVE)
refers to that extra effort which occurs
during the development of the larger
application as a result of the use of
COTS components in that system
development.
It was found that the greatest COTS
integration effort tends to be
concentrated on glue code development.
The authors suggested that this is due to
the fact that the difficulties that must be
addressed in glue code are often not
apparent until the COTS integration
process is well underway, making
backtracking of designs and rework a
necessity.
The authors ended the paper abruptly
by stating that the total COTS
integration effort was the sum of the
four components above. There was no
conclusion or summary in the research
paper, which was a limitation as the
reader would have to assume the
conclusion of the authors.
Chulani et al.
10
introduced the
Bayesian analysis technique of
calibrating software cost. Bayesian
analysis uses inductive reasoning which
is used in many scientific disciplines
today. One distinctive feature of this
approach is that it permits the
investigator to use both sampled data
and expert judgment in a logically
consistent manner in making inferences.
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
353
Bayesian analysis is applied on the
COCOMO 2 1998 metrics
11
using two
statistical approaches, the multiple
regression approach and the Bayesian
approach. Most cost estimation models,
including COCOMO 2 1997 use a form
of multiple regression approach, which
prevents project managers from making
good decisions from quality data. The
Bayesian approach alleviates this
problem by making use of expert
judgment data with sampling
information in a logically consistent
manner.
The Bayesian approach incorporates a
formal process of merging historical data
with existing data. In other cost metrics,
the ability to incorporate proper
historical data is limited, hence the
Bayesian approach processes data in a
more competent way to provide project
managers with an environment for
better decision making in software
projects.
Although the authors provided a
thorough paper on the Bayesian
approach, many assumptions were made
pertaining to human factors in managing
this approach. An inexperienced project
manager might find this method a
tedious and rigorous approach to
estimating and controlling software cost.
Hence, it would have been beneficial for
the authors to provide a skill rating for
this research paper so that junior project
managers could meet the prerequisites of
this paper before attempting to engage
Bayesian analysis in estimating the cost
of their software project.
Function point analysis
Roetzheim
12
provided three excellent
papers to discuss how function point
analysis could be used in determining
the size of software. The author covered
the issues of calculating unadjusted
software function points from user
requirements, which can be used to
estimate the number of lines of code,
which in return is used to determine the
estimated labor efforts required to
complete the software project. The
author refined the unadjusted function
points by introducing cost drivers. The
software effort estimation process was
then further fine-tuned by introducing
the concept of software component
reusability.
Software reusability is a component-
based concept that can greatly reduce
the time to develop software. In this
context, software is developed from a
library of components, akin to
manufacturing a laptop computer. For
example, the laptop manufacturers need
only be concerned about designing the
laptop around the existing peripherals
like hard disk, monitor, touch pad,
battery etc. They need not worry about
designing and manufacturing the
peripherals, and hence, this greatly
improves their economies of scale.
The author did not, however, further
elaborate on how the labor efforts could
be used to determine the cost of the
software; rather, he left the reader to
gauge the software cost based on current
accounting principles and practices.
Vickers provided an excellent, more
thorough research paper on FPA.
13
The
paper addressed the fundamentals of
why software measurement with
numbers was far more accurate than the
‘‘gut feeling’’ approach. The author took
the classified software metrics into two
classifications: direct and indirect metrics.
Direct metrics are cost factors that
contribute directly to the overall cost of
the project (eg cost, effort, speed etc)
and indirect metrics, as the name
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)354
Seetharaman, Senthilvelmurugan and Subramanian
suggests, involve cost factors that are
usually indirect to the cost of the
software (eg function, quality,
complexity, efficiency etc).
The author then discussed the meaning
of line of code (LOC) used in function
point analysis and how it differs from
one computer programming language to
another. Vickers touched on the issue of
productivity and how it can determine
the cost of software, an issue which was
omitted by Roetzheim.
14
Productivity
of the project team is an intangible issue
that can only be measured by statistically
calculating the maturity index (MI) and
productivity index (PI) of the project
team which can be a determining cost
factor during the cost estimation process.
Vickers’ paper went on to explain
how function point analysis is used,
albeit in a more technical way as
compared with Roetzheim’s paper. The
author then discussed the benefits and
problems faced by using FPA and how
its limitations were overcome by the
introduction of MKII Function Point
Analysis (MKII FPA) pioneered by
Symons.
15
Although Vickers’ paper discussed
FPA to a significant extent, its method
did not allow for the problems of
software development delays. Delays in
software development (an inherent risk)
cannot be controlled by determining
metrics based on direct or indirect
metrics. Hence, the paper assumed that
software is handled by experienced
project managers who can control this
potential risk with professionalism to
reduce its effect. Further, it adhered to
the basic cost accounting elements,
namely direct and indirect costs.
Symons wrote a paper on the reasons
of decline for the usage of FPA in
software cost estimation today. At the
time of FPA’s creation by Allan
Albrecht of IBM, software was small to
medium in terms of design complexity
and size; hence FPA was widely used at
that time. Modern software
development, however, does not favor
the old FPA, hence the author examined
the reasons for this decline in using FPA.
The author further examined the
Figure 3: The evolution of function point analysis.
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
355
evolution of FPA and through its
progress, COSMIC FFP was derived
from the International Function Point
User Group (IFPUG). Figure 3 shows
the evolution of function point analysis.
Symons provided the insight into the
benefits of COSMIC FFP in modern
software development, an area that the
obsolete FPA did not. However,
Symons’ research covered only software
metrics related to FPA. There are other
software cost estimation techniques in
the software industry and it would have
been more comprehensive had Symons
contributed a section in his paper to the
comparison between these cost models.
Fabrizi’s research paper presented a
study on FPA software project
measurement being utilized by Banca
d’Italia, the Italian central bank.
16
The author provided a time/effort
comparison of past, present and future
development methodologies adapted by
the bank. In the past, the bank utilized a
‘‘waterfall’’ methodology to software
development. Most projects were
outsourced to third-party software
vendors, contracted on a three-year
agreement with software vendors. The
bank currently still uses the ‘‘waterfall’’
model, but for the future, it is working
towards a ‘‘back-bone with traffic
lights’’ methodology and the
outsourcing contract remains the same.
This paper was limited in that it only
identified FPA within the context of the
Italian bank and the research was limited
to FPA. The author should have
provided a general paper on software
measurement with function point and
from a wider perspective, including
other industries.
Wu’s research on FPA stressed the
complexity of sizing software and
determining its cost.
17
The paper
discussed the available methods for
software size estimation, starting by
explaining LOC, which is one of the
oldest methods of software size
estimation. How FPA was derived from
LOC was then discussed, and explained.
The authors then surveyed 500 firms
in Hong Kong to obtain information
about software sizing, development
tools, effort estimation and factors
affecting software development time and
activities. The data were collected and
analyzed by the authors.
It was found out that 77.1 per cent of
companies were using the LOC method
and 22.9 per cent were using the FPA
approach. This indicates that LOC was
more favorable as it was easier to use
than FPA. It was also found that the
project manager’s experience and user
participation in the requirements
specification stage were crucial to the
implementation success of the project.
Finally, it was found that FPA had more
benefits than LOC, as LOC tends to be
influenced by the type of programming
language used. Hence, for a project that
utilized multiple programming
languages, this approach tends to be less
feasible.
Although the research paper provided
some commendable demographic
results, it did not illustrate the effects of
other cost drivers on FPA and LOC.
The authors failed to identify the
economic factor that can influence the
total estimate of software which
determines the final size of the software
to deliver and the investment that has to
be allocated.
The Armour et al.
18
paper discussed
managing the user requirements
volatility which affects the total cost of
the overall software project. The authors
identified that, as the development of
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)356
Seetharaman, Senthilvelmurugan and Subramanian
the project commences, new
requirements can be added by the
customer. This will have a significant
impact on the cost and timeline of the
software project. In order to control this
situation, the authors proposed a
lifecycle estimation framework (LCEF)
which consists of a number of estimating
methods applied at key areas within the
project lifecycle.
To determine the labor efforts needed
to comply with the addition of new
requirements, the size of the
requirements are indicated by functions,
which are akin to the function points
found in FPA. The authors suggest that
each requirement be assigned a set of
function points to denote the size and
complexity of the requirement. The
requirements are grouped together and a
regression analysis is performed. FPA is
used to determine the number of
function points for each requirement.
Hence, the final software size can be
determined based on the number of
function points for each requirement.
The authors’ research, however, did
not state the size of the software projects
used in the study. This can be a
limitation in the research paper as
complexity of software is directly
proportional to software size increments.
Other models
Victor and Daily
19
introduced another
approach for determining software cost.
This approach is known as the
SPECTRE Model. The SPECTRE
approach is akin to FPA except that it
utilizes what is known as a construction
point evaluation (CPE). CPE is different
from FPA from the point of view of the
target entities and fundamental
objectives. The SPECTRE task
estimation consists of three phases:
.Construction evaluation which focuses on
two classes of functions, input/output
and processing;
.Development effort calculation which
focuses on identifying the features of
processing logic like data restructuring,
sorting, conditions, data retrieval,
calculations as such; and
.Results display displays the result of the
task estimate in two sections:
—Section 1 consists of actual
estimates like LOC, development
effort in days etc.
—Section 2 consists of additional
items which are of value and
interest like complexity rating of
the software, experience rating
and etc.
The SPECTRE model has a realistic
prediction technique. Victor put his
SPECTRE model through vigorous test
cases to see the standard deviation of this
model. It was found that an average
standard deviation of 5.4 was discovered
when comparing the estimated LOC
with the actual results. Table 1 depicts
this result.
Although the SPECTRE model
offered good prediction, the authors
Table 1: The standard deviation between
estimated and actual LOC derived from using the
SPECTRE approach
Test case LOC LOC Deviation
programs (estimated) (actual) (%)
1 1,287 1,338 –3.9
2 4,715 4,848 –2.8
3 5,684 5,695 –4.7
4 1,560 1,551 +0.6
5 11,280 10,776 +4.6
6 5,520 5,963 –7.5
7 540 634 –14.8
8 11,424 12,590 –10.0
9 2,277 2,342 –2.8
10 4,175 4,080 +2.3
Source: Victor & Daily (2001)
22
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
357
failed to derive how the final software
cost is determined. Again, like other cost
models, the model focuses on labor
efforts needed to deliver a software
product based on the number of lines of
code that need to be written.
Kokol et al.
20
conducted research on
the impact of using software metrics and
evolutionary decision trees to control the
quality of software. The aim of the
research paper was to present the a
metric and the usage of ain decision trees
so as to produce a fault predictive metric.
First, the reliability and complexity of
software metrics was discussed and its
weaknesses were revealed. Then the
authors described the physical
background of communication,
comparing a computer program and
natural language texts. The methods of
describing the correlation properties of
texts were discussed and one such
method was known as long range
correlation (LRC). LRC can be used to
quantify a software system’s behavior
and can allow for the recognition of
similarities between systems. This
induced the results required to allow the
authors to show how software fault
prediction using decision trees could be
potentially identified.
This research was limited by the
inability to identify the accounting
aspects of producing software reliability
and how this could in turn become a
cost-saving factor within the
environment of an organization.
Woodings and Bundell
21
consolidated
their efforts to discuss a framework for
software metrics. Their paper defines a
taxonomy of software metrics which is
derived from the needs of users,
developers and management.
The authors discussed the properties
based on this classification, and
introduced some rules (known as Metrel
(Metric Relationship) rules) that were
used to generate a new set of software
metrics from an existing class. The
authors claim that by using the Metrel
rules, management, staff and customers
would be able to view the success and
process improvement efforts of software
on one graph. This approach can be
beneficial during meetings between the
project team and the customer. In
addition, the Metrel rules approach
provides a check into the way software
metrics are chosen and is employed as a
supplement to the existing methods of
metric definition and generation. Lastly,
the Metrel rules are important to the
modeling of the software development
process by providing a mechanism for
the expansion and transformation of
metric models.
This paper was limited by the inability
of the authors to show how the results
of the Metrel rules are able to affect the
accounting of software, which relates to
how decisions are made within the
business.
NOTE
Part 2 of this paper will be published in the
next issue of the Journal.
REFERENCES
1. Walker, R. (2001) ‘‘Improving software
development economics Part 1: Current
trends,’’ The Rational Edge, Available at:
http://www.therationaledge.com/
content/apr_01/f_econ_wr.html.
2. Ibid.
3. Ibid.
4. Ibid.
5. Chulani, S. (2001) Software Development
Cost Estimation Approaches, University of
Southern California, Los Angeles, CA.
6. Boehm, B., Clark, B., Horowitz, E.,
Westland, C., Madachy, R., and Selby
JOURNAL OF DIGITAL ASSET MANAGEMENT
Vol. 1, 5 347–359 #Henry Stewart Publications 1743–6559 (2005)358
Seetharaman, Senthilvelmurugan and Subramanian
R. (1995) Cost Models For Future
Software Lifecycle Processes:
COCOMO 2.0, NEC Research
Institute, Available at: http://
citeseer.nj.nec.com/boehm95cost.html.
7. Verner, J. M. and Evanco, W. M. (2000)
State of the Practice of Effort Estimation in
Business Environments, European
Software Control and Metrics. Available
at: http://www.escom.co.uk/
conference2000/index.shtml.
8. See ref 5 above.
9. Abts, C., Boehm, B.W. and Bailey
Clark, E. (2000) COCOTS: A COTS
Software Integration Cost Model — Model
Overview and Preliminary Data Findings,
Software Control and Metrics. Available
at: http://www.escom.co.uk/
conference2000/index.shtml.
10. Chulani, S., Boehm, B. and Steece, B.
(2000) Calibrating Software Cost Models
Using Bayesian Analysis, University of
Southern California, Los Angeles, CA.
11. See ref 5 above.
12. Roetzheim, W. (2000) ‘‘Estimating
software costs,’’ Software Development
Magazine Online, October. Available at:
http://www.sdmagazine.com/print/
documentID=11137; Roetzheim, W.
(2000) ‘‘Project cost adjustments,’’
Software Development Magazine Online,
October. Available at: http://
www.sdmagazine.com/print/
documentID=11124; Roetzheim, W.
(2000) ‘‘Calculating for reuse,’’ Software
Development Magazine Online,
December. Available at: http://
www.sdmagazine.com/print/
documentID=11115.
13. Vickers P. (2001) An Introduction to
Function Point Analysis, School of
Computing and Mathematical Sciences,
Liverpool John Moores University,
Liverpool, UK.
14. See ref 5 above.
15. Symons, C. (2001) Come Back Function
Point Analysis (Modernised), European
Conference on Software Measurement
and ICT Control. Available at: http://
www.escom.co.uk/conference2001/
download.shtml.
16. Fabrizi, S. (2001) Software Project
Measurement Using Function Point: A
Continuous Improvement, European
Software Control and Metrics. Available
at: www.escom.co.uk/conference2001/
papers/fabrizi.pdf.
17. Wu, I.K. (2000) Using Function Point
Analysis Method or Line of Code for
Software Size Estimation?, European
Software Control and Metrics. Available
at: http://www.escom.co.uk/
conference2000/index.shtml.
18. Armour, F., Catherwood, B. and
Beyers, C. (2001) ‘‘A framework
managing requirements volatility using
function points as currency,’’ Proceedings
of the ESCOM 2001, April 2001,
London, pp. 295–303.
19. Victor, D. and Daily K. (2001) Software
Estimating at the Task Level — the
SPECTRE Approach, European
Software Control and Metrics. Available
at: http://www.escom.co.uk/
conference2001/download.shtml.
20. Kokol, P., Podgorelec, V. and Pighin,
M. (2001) Using Software Metrics and
Evolutionary Decision Trees for Software
Quality Control, European Software
Control and Metrics. Available at:
http://www.escom.co.uk/
conference2001/download.shtml.
21. Woodings, T.L. and Bundell G.A.
(2001) A Framework for Software Project
Metrics, NEC Research Institute.
Available at: http://citeseer.nj.nec.com/
538619.html.
22. See ref 19 above.
Budgeting and accounting of software cost: Part 1
#Henry Stewart Publications 1743–6559 (2005) Vol. 1, 5 347–359
JOURNAL OF DIGITAL ASSET MANAGEMENT
359
