Chapter 6

Verification

Software Engineering
Mr. Manny Lanuang
 Group Report

Member:

Darren Laderas

Edison valentino

April Ej Paraiso
Verification

Before proceeding with the technical details we should discuss some issues
regarding terminology. The field of software verification is progressing rapidly
and the terminology is evolving. The term verification and variation in
particular are used with many often inconsistent meaning. We shall avoid the
term validation and only use verification in this chapter, by verification we
mean all activities that are under taken to ascertain that the software meets
its objectives. As we shall see these activities encompasses a wide spectrum
of efforts including testing mathematical proofs and informal.

6.1

Just as a bridge or other engineering works must be verified so must both the
process of software development and all of its products. With small programs
of programmer we write for our own use and with programs that do not have
critical requirements to meet program verification often consist of trying a
sample case to see whether the result of running the code match our
expectations, people are often tempted to carry over the approach to the
verification of software products. Trying a few sample cases hoe ever is to
limited to stills be vide us with any confidence in the software for at least two
reasons. First we shall see later that we can never gain such absolute
confidence in the correctness of software, Second even if we could we would
still be quite far from software that we could trust. The software might
perform poorly its documentation might be adequate preventing its effective
use or its evolution. Furthermore performing verification only after the
running code is available would make it very difficult to repair any defects
that were discovered. Experimental data from industrial projects have shown
that the cost of removing an error after the software has been developed
completely is much higher than if errors are eliminated earlier. In sum the
verification activity like other software design activity must follow rigorous
principles and suitable techniques, it cannot be left exclusively to human
insight experience or luck.
6.1.1

In principles all design process and all of the product of these processes must
be verified. In some sense verification must be verified in fact once we tested
a system for proper behavior, we should check our test were executed
properly themselves. Verifying the validity of experiments is standard practice
established scientific discipline. Also every software quality must be verified,
not only we check through verification of correctness whether the software
we have implemented behaves according to the specification document’s but
also we must certify the software’s portability performance, modifiability etc.

6.1.2

The Results of Verification May Not Be Binary

We tend to think of verification as a Yes or No, after having performances as

many as needed and as much analysis as required eventually the result of the
verification is either acceptance or rejection of the final product, It cannot be
stated that a piece of software is absolutely error free but an approximation of
ideal correctness is often considered satisfactory and may in some way be
certified. Efficiency is typical example of a software quality that can be
exhibited at different levels. Efficiency is often explicitly mentioned in
requirements documents and can be measured in several ways. For instance
efficiency could be express in terms of complexity by a formula such as “The
time required to perform computations is given by functions f(n) of the length
of the input stream or one could experimentally build tables that state the
number and kind of resources needed to run a system in several
representative cases.

Verification May Be Objective or Subjective

Sometimes instances of verification may be the result of an objective activity

such as performing a test by some input data to the system and checking the
output or measuring the response time of an interactive system to given
stimuli. Not all qualities however can be qualified in such an objective way.

For instance portability and maintainability can be made precise only by

specifying environment port to meet precisely stated new requirement. In
many cases one would like to state a generic level of portability even though
one is unable to specify exactly the technical features of possible new
architectures. Similarly one would like to estimate reusability even when one
cannot be specify exactly in which the new context the new software will

have to be reused. In such cases objective measured must be replaced by, or

integrated with subjective estimates for instance we stated in chapter 4 that
the use of object oriented techniques may be expected to enhance
reusability. We substantiated this claim by providing examples different
showing that “essential parts “ of existing code could be naturally adapted to
operating conditions different from their original ones. Even this rough
quantification of reusability could be misleading. It would imply that
complexity of software of a is measured by the number of lines of code an
often assumed , but questionable by hypothesis. Still we need to estimate a
level of modifiability even in the absence of an objective to measure it

Even implicit qualities Must Be Verified

The desired software qualities is should be stated explicitly in the

requirements specification documents some requirements however may been
left out either because they are implicit or because were forgotten. In chapter
2 we use the term robust to characterized software whose functional behavior
remains acceptable requirements for conventional data processing system
often are only functional requirements and worse are frequently in complete.
This does not mean that such system has no performance requirements .It
just these requirements are omitted because they are not considered to be
critical and they can be left professional judgments common sense. For
instance people are expected to know that a transaction at an automatic
teller machine normally should not exceed one minute and further more the
term normally should be quantified.

is a typical example of software quality that is seldom explicitly asked for yet
often highly desirable. We also so that it is hardly quantifiable. This not
withstanding a good software engineer should strive not only to design
maintainable software, but also to verify the maintainability of the product
during each step of the design process. For instance for once the
requirements for a user interface are specified one should ask how, when,
and why they are likely to change.

Approaches to Verification

There are two fundamentals approach to verification : experimentation and

analysis, The first consist if experimenting with the behavior a of product to
see whether the product performs as expected the other consist of analyzing
the product and any design documentation related to it, to reduce its correct
operation as a logical consequence of the design decisions . The two
categories verification techniques are also classified as dynamic and static
respective by definition the form require executing the system to be verified
while the latter Is based on examining state models of the product not
surprisingly the two techniques turn out be nicely complementary.

Analysis
1. Informal analysis Techniques

 Code walk-throughs
  Code inpections

2. Correctness Proofs

 Basic concepts of correctness proofs

 Programs with arrays

 Correctness proofs in the large

 Using correctness proofs in practice

Verifying Performance

Performance has always been a major concern in software system whether one is
dealing with strictly real-time system.

Performance can be verified from several standpoints and with several techniques.

Worst case analysis – Which the focus is on proving that the system.

Verifying Reliability

Statistical and probabilistic methods work quite well for measuring system properties
that we cannot measure with absolute certainly.

Verifying Subjective Qualities

We often assess software qualities such as understandability, modifiability and

portability on the basic of common sense and experience.

- Halstead Theory
 Software science is approach to measuring software qualities on the basic of objective
code measures.

The Theory due to Halstead and bases on information theory relies on the following
measurable, defined for a given program coded in any programming language.

• The number of unique distinct operators appearing in the program.

• The number of unique distinct operands appearing in the program.

• N The total number of occurrences of operators in the program.

• N The total number of occurrences of operands in the program.

Although the terms “operator” and “operand” have an intuitive meaning, a precise definition of
them is needed to avoid ambiguities that may arise between different programming
languages.

- McCabe’s Theory

Another source-code metric was developed by McCabe, who observed that the quality
of a program depends on the complexity of its control flow, rather than on operators and
operands, as in Halstead’s theory, McCabe’s complexity metric C is based on the control
flow graph and is defined as.

C = e – n + 2p

The Goal/Question/Metric Approach to Measuring Software Qualities

Much research and experimental activity has been reported in regard to validating
Halstead’s and McCabe’s theories, as well as other, similar ones. Some experiments seem
to support the theories, while others are inconclusive.
Hints and sketchy solutions 6.10 inputs to a program may have a rich
structure that can be refined by a BNE grammar. For example, consider a
program that uses as input a business from with several (possibly repeated)
fields and several options. One can use the input’s BNF as a driver to
generate test sets.

6.11 Certain combinations of inputs my generate an ERROR action.

Billionare Notes

The special issues of the communications of the ACM software testing

(CACMI1988) and of IEEE software on software verification and validation
(IEEE software [1989]) provide overviews of the field of verification. For the
basic terminology refer to adrion et. Al. [1975] and the issue of IEEE software
[1999] on software engineering and standards. The issue of verification
versus validation is address by Boehan [1984] kemeter [1985] contains and
an excellent discussion of why is specification should be tested and also show
how to do this in the context of formal specification based on logic