Page 118 -

CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 89

were encountered after release to the customer within the first year of operation.
Three people worked on the development of software for project alpha.
In order to develop metrics that can be assimilated with similar metrics from other
projects, we choose lines of code as our normalization value. From the rudimentary
data contained in the table, a set of simple size-oriented metrics can be developed
Metrics collection
template for each project:
• Errors per KLOC (thousand lines of code).
4
• Defects per KLOC.
• $ per LOC.
• Page of documentation per KLOC.
In addition, other interesting metrics can be computed:

• Errors per person-month.
• LOC per person-month.
• $ per page of documentation.
Size-oriented metrics are not universally accepted as the best way to measure the
process of software development [JON86]. Most of the controversy swirls around the
use of lines of code as a key measure. Proponents of the LOC measure claim that LOC
is an "artifact" of all software development projects that can be easily counted, that
many existing software estimation models use LOC or KLOC as a key input, and that
Size-oriented metrics a large body of literature and data predicated on LOC already exists. On the other
are widely used, but
debate about their hand, opponents argue that LOC measures are programming language dependent,
validity and that they penalize well-designed but shorter programs, that they cannot easily accom-
applicability continues. modate nonprocedural languages, and that their use in estimation requires a level of
detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be
produced long before analysis and design have been completed).

4.3.2 Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by
the application as a normalization value. Since ‘functionality’ cannot be measured
directly, it must be derived indirectly using other direct measures. Function-oriented
WebRef metrics were first proposed by Albrecht [ALB79], who suggested a measure called the
Comprehensive function point. Function points are derived using an empirical relationship based on
information on function countable (direct) measures of software's information domain and assessments of
points can be obtained at software complexity.
www.ifpug.org
Function points are computed [IFP94] by completing the table shown in Figure 4.5.
Five information domain characteristics are determined and counts are provided in

4 A defect occurs when quality assurance activities (e.g., formal technical reviews) fail to uncover
an error in a work product produced during the software process.