Metrics for software project size estimation

Accurate estimation of the problem size is fundamental to satisfactory

estimation of effort, time duration and cost of a software project. In order to
be able to accurately estimate the project size, some important metrics
should be defined in terms of which the project size can be expressed. The
size of a problem isr obviously not the number of bytes that the source code
occupies. It is neither the byte size of the executable code. The project size is
a measure of the problem complexity in terms of the effort and time required
to develop the product.
Currently two metrics are popularly being used widely to estimate size:
1- lines of code (LOC)
2- function point (FP)
The usage of each of these metrics in project size estimation has its own
advantages and disadvantages
 LINES OF CODE (LOC)
LOC is the simplest among all metrics available to estimate project size. This metric
is very popular because it is the simplest to use. Using this metric, the project size is
estimated by counting the number of source instructions in the developed program.
Obviously, while counting the number of source instructions, lines used for
commenting the the code and the header lines should be ignored. Determining the
LOC count at the end of a project is a very simple job. However, accurate estimation
of the LOC count at the beginning of a project is very difficult. In order to estimate
the LOC count at the beginning of a project, project managers usually divide the
problem into modules, and each module into submodules and so on, until the sizes
of the different leaf-level modules can be approximately predicted. To be able to do
this, past experience in developing similar products is helpful. By using the
estimation of the lowest level modules, project managers arrive at the total size
estimation.
 FUNCTION POINT (FP)
Function point metric was proposed by Albrecht [1983]. This metric overcomes many of
the shortcomings of the LOC metric. Since its inception in late 1970s, function point
metric has been slowly gaining popularity. One of the important advantages of using the
function point metric is that it can be used to easily estimate the size of a software
product directly from the problem specification. This is in contrast to the LOC metric,
where the size can be accurately determined only after the product has fully been
developed. The conceptual idea behind the function point metric is that the size of a
software product is directly dependent on the number of different functions or features
it supports. A software product supporting many features would certainly be of larger
size than a product with less number of features. Each function when invoked reads
some input data and transforms it to the corresponding output data. For example, the
issue book feature (as show in figure) of a Library Automation Software takes the name
of the book as input and displays its location and the number of copies available. Thus, a
computation of the number of input and the output data values to a system gives some
indication of the number of functions supported by the system. Albrecht postulated that
in addition to the number of basic functions that a software performs, the size is also
dependent on the number of files and the number of interfaces
Besides using the number of input and output data values, function point metric computes
the size of a software product (in units of functions points or FPs) using three other
characteristics of the product as shown in the following expression. The size of a product in
function points (FP) can be expressed as the weighted sum of these five problem
characteristics. The weights associated with the five characteristics were proposed empirically
and validated by the observations over many projects. Function point is computed in two
steps. The first step is to compute the unadjusted function point (UFP).
UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 +
(Number of files)*10 + (Number of interfaces)*10

Number of inputs: Each data item input by the user is counted. Data inputs should be
distinguished from user inquiries. Inquiries are user commands such as print-account-balance.
Inquiries are counted separately. It must be noted that individual data items input by the user
are not considered in the calculation of the number of inputs, but a group of related inputs
are considered as a single input.
For example, while entering the data concerning an employee to an employee pay roll
software; the data items name, age, sex, address, phone number, etc. are together
considered as a single input. All these data items can be considered to be related, since
they pertain to a single employee.
Number of outputs: The outputs considered refer to reports printed, screen outputs, error
messages produced, etc. While outputting the number of outputs the individual data items
within a report are not considered, but a set of related data items is counted as one input.
Number of inquiries: Number of inquiries is the number of distinct interactive queries
which can be made by the users. These inquiries are the user commands which require
specific action by the system.
Number of files: Each logical file is counted. A logical file means groups of logically related
data. Thus, logical files can be data structures or physical files.
Number of interfaces: Here the interfaces considered are the interfaces used to exchange
information with other systems. Examples of such interfaces are data files on tapes, disks,
communication links with other systems etc.
Once the unadjusted function point (UFP) is computed, the
technical complexity factor (TCF) is computed next. TCF refines the
UFP measure by considering fourteen other factors such as high
transaction rates, throughput, and response time requirements,
etc. Each of these 14 factors is assigned from 0 (not present or no
influence) to 6 (strong influence).

The resulting numbers are summed, yielding the total degree of

influence (DI).

Now, TCF is computed as (0.65+0.01*DI). As DI can vary from 0 to

70, TCF can vary from 0.65 to 1.35.
Finally, FP=UFP*TCF
Shortcomings of function point (FP) metric
LOC as a measure of problem size has several shortcomings: • LOC gives a numerical
value of problem size that can vary widely with individual coding style – different
programmers lay out their code in different ways. For example, one programmer might
write several source instructions on a single line whereas another might split a single
instruction across several lines. Of course, this problem can be easily overcome by
counting the language tokens in the program rather than the lines of code. However, a
more intricate problem arises because the length of a program depends on the choice
of instructions used in writing the program. Therefore, even for the same problem,
different programmers might come up with programs having different LOC counts. This
situation does not improve even if language tokens are counted instead of lines of code.
• A good problem size measure should consider the overall complexity of the
problem and the effort needed to solve it. That is, it should consider the
local effort needed to specify, design, code, test, etc. and not just the coding
effort. LOC, however, focuses on the coding activity alone; it merely
computes the number of source lines in the final program. We have already
seen that coding is only a small part of the overall software development
activities. It is also wrong to argue that the overall product development
effort is proportional to the effort required in writing the program code. This
is because even though the design might be very complex, the code might be
straightforward and vice versa. In such cases, code size is a grossly improper
indicator of the problem size.
• LOC measure correlates poorly with the quality and efficiency of the code.
Larger code size does not necessarily imply better quality or higher
efficiency. Some programmers produce lengthy and complicated code as
they do not make effective use of the available instruction set. In fact, it is
very likely that a poor and sloppily written piece of code might have larger
number of source instructions than a piece that is neat and efficient
• LOC metric measures the lexical complexity of a program and does not address the more
important but subtle issues of logical or structural complexities. Between two programs with
equal LOC count, a program having complex logic would require much more effort to develop
than a program with very simple logic. To realize why this is so, consider the effort required to
develop a program having multiple nested loop and decision constructs with another program
having only sequential control flow.

• It is very difficult to accurately estimate LOC in the final product from the problem
specification. The LOC count can be accurately computed only after the code has been fully
developed. Therefore, the LOC metric is little use to the project managers during project
planning, since project planning is carried out even before any development activity has
started. This possibly is the biggest shortcoming of the LOC metric from the project manager’s
perspective