Software Engineering for Students A Programming Approach

358 Chapter 29 ■ Software metrics and quality assurance
■ how much will this software cost?
■ how much effort will be needed to alter this software to meet changed needs.
In this chapter we review various ways of applying metrics to software. The purposes
of metrics in software engineering include:
■ predicting qualities of software that is about to be developed
■ making judgments on the quality of a piece of software that has been developed
■ monitoring and improving the software development process
■ comparing and assessing different development approaches.
In this chapter we first review metrics, then look at the application of quality assurance.
29.2 ● Basic metrics
The simplest measure of software is its size. Two possible metrics are the size in bytes
and the size in number of statements. The size in statements is often termed LOCs
(lines of code), sometimes SLOCs (source lines of code). The size in bytes obviously
affects the main memory and disk space requirements and affects performance. The size
measured in statements relates to development effort and maintenance costs. But a
longer program does not necessarily take longer to develop than a shorter program,
because the complexity of the software also has an effect. A metric such as LOCs takes
no account of complexity. (We shall see shortly how complexity can be measured.)
There are different ways of interpreting even a simple metric like LOCs, since it is
possible to exclude, or include, comments, data declaration statements, and so on.
Arguably, blank lines are not included in the count.
The second major metric is person months, a measure of developer effort. Since
people’s time is the major factor in software development, person months usually
determine cost. If an organization measures the development time for components,
the information can be used to predict the time of future developments. It can also be
used to gauge the effectiveness of new techniques that are used.
The third basic metric is the number of bugs. As a component is being developed, a
log can be kept of the bugs that are found. In week 1 there might be 27, in week 2
there might be 13, and so on. As we shall see later, this helps predict how many bugs
remain at the end of the development. These figures can also be used to assess how good
new techniques are.
Collecting and documenting quality information can be seen as threatening to developers
but a supportive culture can help.
29.3 ● Complexity metrics
In the early days of programming, main memory was small and processors were slow.
It was considered normal to try hard to make programs efficient. One effect of this was