Direct Quality Measures in Software

The direct quality measures need to be defined as part of the activities to set quality goals,
when such goals re quantified. Direct quality measure refers to measuring exactly the thing
that you are looking to measure. Direct measures include cost and effort applied in the
development of software. Direct measures of the software include how many lines of code
(LOC) produced, execution speed, memory size, and defects reported.

Direct measurements are ascertained by using a system or tool to directly read the height,
length or any other aspect of an object to determine its measurement. The concept of direct
measurement allows a measurement to be known as it is, however errors may ensue
depending upon the skill of the person performing the measurement. Examples of direct
measurements include measuring your height by using a measuring tape, determining the
temperature of your oven through the use of a thermometer, and measuring the length of
your morning exercise through the use of a stopwatch.

In the world of physics, one of the more common examples of direct measurement is current.
When attempting to measure the current flowing through a wire, you use an ammeter
connected to the circuit to directly measure it. This method is considered a direct
measurement because the tool being utilized, the ammeter, measures the current in the wire
without the need to know any information prior to the measurement.

The following direct measures that are commonly use in software are:

• Length of source code by LOC

Source lines of code (SLOC or LOC) is a software metric used to measure the size of a
software program by counting the number of lines in the text of the program's source code.
SLOC is typically used to predict the amount of effort that will be required to develop a
program, as well as to estimate programming productivity or effort once the software is
produced.

There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC
(LLOC). Specific definitions of these two measures vary, but the most common definition of
physical SLOC is a count of lines in the text of the program's source code including comment
lines. Blank lines are also included unless the lines of code in a section consists of more than
25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of
code.

Logical LOC attempts to measure the number of "statements", but their specific definitions
are tied to specific computer languages (one simple logical LOC measure for C-like
programming languages is the number of statement-terminating semicolons). It is much
easier to create tools that measure physical SLOC, and physical SLOC definitions are easier
to explain. However, physical SLOC measures are sensitive to logically irrelevant formatting
and style conventions, while logical LOC is less sensitive to formatting and style conventions.
 Unfortunately, SLOC measures are often stated without giving their definition, and
logical LOC can often be significantly different from physical SLOC.

• Duration of testing purpose by elapsed time

Elapsed time is the amount of time that passes between the start of an event and the end of
the event.

We can calculate elapsed time using a number of different techniques, one of which is the
number line on which we break up the time intervals between the start time and end time of
an event, easy to calculate intervals, and then add up those intervals to determine the total
elapsed time.

• Number of defects discovered during the testing process by counting defects

Defect counts are often considered as measurements of product quality. However, the most
important defect count in that respect is by definition unknown; the number of undiscovered
errors. Defect counts can be used as indicators of process quality. In doing so, one should
avoid assuming simple causal relations. Defect counts can provide useful information but
have to be presented with care.

A defect count is a number of defects that have been discovered. In order to be included in a
count a defect has to be logged and classified. The number of severe and still open defects
caused by specification errors and found during system test is an example of a specific
defect count that might be of interest to somebody.

• The time a programmer spends on a program

Developers spend more time maintaining, testing and securing existing code than they do
writing or improving code.

While this might not be surprising to developers, it is perhaps disheartening to see that
respondents spend less than one-third of their time writing new code or improving existing
code (32%). Respondents spend 35% of their time managing code, including code
maintenance (19%), testing (12%) and responding to security issues (4%). Another 23% is
spent in meetings and on management and operational tasks.

Indirect Quality Measures in Software

The Indirect measures include functionality, quality, complexity, efficiency, reliability, and
maintainability. Indirect quality measure means that you are measuring something
by measuring something else. Direct measure is easy to compute compare with indirect
measure of software. We can calculate the cost of the software development but it is difficult
to calculate the functionality and quality of the software.

Indirect measurements occur when you take the measurement of one unit/object and
convert it so that it matches the characteristics of something else. The concept of indirect
measurement may be a bit difficult for some people to grasp due to the fact that many people
don’t have a use for it in their everyday lives. Let’s look at an example. If you were to take a
dial gauge to measure the height difference between a measurement target and a gauge
block you would then, using the indirect measuring system, use your calculation to indirectly
estimate the target’s height.

However, let say if I want to find out about something that is a little harder to measure like
how quickly the wind is blowing. I may not be able to measure the wind's actual speed, but if
I had a windmill, I could measure how much power the windmill is making. Then, using this
information, I could work backwards to figure out how fast the wind must be. This would be
an example where I have to measure something 'indirectly.'