Software Engineering                                     Jim Murphy
CSCI-112                                                 Fall 2001

Probably the oldest and easiest metric is the size metric, lines of
code LOC, or thousands of lines of code KLOC.  Some like to
include comments and some like to leave comments out which
is sometimes called NCSS non-commented source statements.

This metric is dependent on implementation language as you
can see on page 91 of your text in comparing LOC to FP or
Function Points which is another size metric which attempts
to come to some notion of size prior to writing the code
In either case we can then talk about dollars per size unit or
person hours per size unit or dollars per page of documentation
or errors found per size unit prior to release or defects per
size unit per time period after release

Function Points can be computed using the tables on pages 86
and 87. As you can see on page 86 this measures the interaction
of the proposed system with the external environment - 
information such as we might obtain once we have a context
diagram early in the life-cycle - these numbers of interactions
must be multiplied by a weighting factor depending on 
whether the category is seen as simple, average or complex
note these may vary from category to category and finally an
additional sum of 14 complexity values contribute up to 35%
of the total if they averaged at about 3 each on a scale from
0 to 5 - It is questionable how effective this 1979 measure is
for today's client/server and event-driven projects
This was also developed prior to the object-oriented methods
In fact it is not clear how effective KLOC is in OO development
LESSON 11
These metrics may be helpful in determining productivity within
a given group where measurements are made with some 
consistency on the same people and on similar projects in which
case we might be able to tell whether the group is "improving"
in some sense or is set back by some change in management
But to compare one person to another or one team to another
in this way is quite arbitrary and barometric pressure and 
temperature may be just as effective

These metrics may help in making estimates before the fact if
there is enough consistent history and records are kept of how
good the estimates are and whether they continue to get better
as the weights are adjusted with this experience
Similar things can be said for using various metrics during the
tracking of a project to help determine how close to schedule
we are at any given time.  Milestones are a cruder but safer
measure that is used in tracking when we may be able to tell
whether we have reached a particular point or not - that is, a
yes or a no is a little easier than a floating point metric, probably
more reliable also though perhaps not as valuable

In measuring quality as opposed to size or productivity it only
gets harder.  Quality can be measured relative to use, maintenance 
or revision, and transition or porting to a new environment.

Correctness can be measured as the number of defects per KLOC
where a defect shows a lack of conformance to requirements

Maintainability can be measured with average or mean time to
Change MTTC - how long to fix it - there different reasons why
this might increase but it is always "bad" or costly for it to do so

Integrity can be measured as the sum of 1 - threat*(1-security)
where threat is the probability that an attack of a particular type
will occur in some time period - and security is the probability
that such an attack would be repelled - there is such a term in
the sum for each type of attack being considered

Usability can be a combination of how much skill required to
use the system, time required to become moderately efficient,
net increase in productivity when used by someone with moderate
efficiency, and subjectively what do the users think of it

DRE or defect removal efficiency can be computed as Errors
divided by (Errors + Defects) where Errors are found before
delivery and Defects are found after delivery and you would
like DRE to be close to one - be careful if you put a large
number of known Errors into the system and remove them you
can make DRE arbitrarily close to one for a given number of
Defects - but we would not do that unless we worked in a very
large impersonal place that we should have already left
Developers will be happy to help in the metrics business if they
understand the benefits - if they can not be shown the benefits
then perhaps they are very nebulous and should be questioned
Everyone wants to deliver a "better" product with fewer
resources but how do we do it and how do we know we are

Perhaps planning can help