There is no such thing as the size of a piece
of software. There is no size measurement scale for software such as the
metric system for measuring length that is universally agreed on. There
are only various methods for measuring software size of varying usefulness,
accuracy, ease of use and value.
Basically, there are two types of software size
measures, Either
you can measure the amount of ‘functionality’ that the software is required to
provide, or you can measure the size of the physical components of the software
when it is created.
A ‘Functional Size’ is defined in the standard ISO/IEC
14143/1:1997 as ‘a size of software derived by quantifying the Functional User
Requirements’. The latter, usually abbreviated as ‘FUR’, are defined as
‘a sub-set of the user requirements. The Functional User Requirements
represent the user practices and procedures that the software must perform to
fulfil the user’s needs. They exclude Quality Requirements and any
Technical Requirements.’
So some very simplified examples of FUR, whose
functionality can be measured would be:
·
‘The software must be able to record data about new employees, and to
update that data as they change their marital status, get promoted, leave or
die’
·
The software
must be able to receive signals about the actual temperature, compare it
against a pre-set target temperature and send control signals to a heater to
maintain the temperature within plus or minus 1 degree Centigrade
·
The software must retrieve the
given record from disk storage and either return it or return a message
indicating failure to retrieve
Some example of user requirements that would NOT be
considered to contribute to a functional size measurement, as they are
technical or quality requirements would be:
·
the software
must have no occurrences of a major defect in its first month of operation
·
the software
must be written in C and operate a standard PC
·
the software’s
average response time must not exceed 1 second averaged over the weekday period
of 11:00 to 12:00 for all types of standard operational transactions and
enquiries
Functional size measures have the advantages therefore
that they:
·
are independent of the technology used for developing and implementing
the software; it follows they are ideal as the size component of project
performance measures, since project performance can be compared across varying
technologies, platforms, etc
·
can be estimated from statements of requirements early in the life of a
project; they are therefore valuable for project estimating and for project scope
control purposes
Physical size measures include counts of source line
of code (‘SLOC’), modules, object-classes and such like, even lines of
documentation. Whilst they can be measured precisely and even
automatically in some cases, such measures suffer from several important
disadvantages, for example:
·
a size of any
piece of software is not known accurately until the software is built; these
measures are therefore of limited value for estimating purposes
·
the size
measures are technology-dependent, making it difficult to use them to compare
project performance across varying technologies
·
there are almost no agreed standards for such size measures.
Measurements of SLOC, for example, can vary hugely depending on the
line-counting conventions adopted
·
an experienced
programmer writing efficient code may encode a problem in a few lines of source
code. An inexperienced programmer may write more lines for the same problem.
A SLOC count as a measure of ‘work-output’ may therefore be entirely misleading
In summary, functional size measures of software are
generally preferred to physical size measures where the functional size
measures can be shown to work effectively for their intended purpose.