SOFTWARE VALIDATION AND VERIFICATION

Software validation or, more generally, verification and validation (V & V) are intended
to show that a system conforms to its specification and that the system meets the
expectations of the customer buying the systems. Verification and validation is a whole
life-cycle process. It starts with requirements review and continues through design
reviews and code inspections to product testing. There should be V & V activities at each
stage of the software process. These activities check that the results of process activities
are as specified.
Verification and validation are not the same thing although they are easily confused. The
difference between the is succinctly expressed by Boehm (1979):
- Validation: Are we building the right product?
- Verification: Are we building the product right?
These definitions tell us that the role of verification involves checking that the software
conforms to its specification. You should check that the system meets its specified
functional and non-functional requirements. Validation, however, is a more general
process. You should ensure that the software meets the expectations of the customer. It
goes beyond checking conformance of the system to its specification to showing that the
software does what the customer expects as distinct from what has been specified.
Early validation of the system requirements is very important. It is easy to make errors
and omissions in the system’s requirements and, in such cases, the final software will
probably not meets its customer’s expectations. However, in reality, requirements
validation is unlikely to discover all requirements problems. Some flaws and deficiencies
in the requirements can sometimes only be discovered when the system implementation
is complete.
Except for small programs, systems should not be tested as a single, monolithic unit.
Large systems are built out of subsystems which are built out of modules which are
composed of procedures and functions. The testing process should therefore proceed in
stages where testing is carried out incrementally in conjunction with system
implementation.

Stages in Testing Process

The figure below shows a five-stage testing process where system components are tested,
the integrated system is tested and, finally, the system is tested with the customer’s data.
Ideally, component defects are discovered early in the process and interface problems
when the system is integrated. However, as defects are discovered the program must be
debugged and this may require other stages in the testing process to be repeated. Errors in
program components, say, may come to light during integration testing. The process is
therefore an iterative one with information being fed back from later stages to earlier
parts of the process.
Unit Testing

Module Testing

Subsystem Testing

System Testing

Acceptance Testing

Component Testing Integration Testing User Testing

The stages in the testing process are:

i) Unit Testing – Individual components are tested to ensure that they operate
correctly. Each component is tested independently without other system
components.

ii) Module Testing – A module is a collection of dependent components such as an

object class, an abstract data type or some looser collection of procedures and
functions. A module encapsulates related components, so can be tested without
other system modules.

iii) Sub-system Testing – This phase involves testing collections of modules which
have been integrated into subsystems. The most common problems which arise in
large software systems are interface mismatches. The subsystem test process
should therefore concentrate on the detection of module interface errors by
rigorously exercising these interfaces.

iv) System Testing – The subsystems are integrated to make up the system. This
process is concerned with finding errors that result from unanticipated interface
problems. It is also concerned with validating that the system meets its functional
and nonfunctional requirements and testing the emergent system properties.

v) Acceptance Testing – This is the find stages in the testing process before the
system is accepted for operational use. The system is tested with data supplied by
the customer rather than simulated test data. Acceptance testing may reveal errors
and omissions in the system requirements definition because the real data exercise
the system in different ways from the test data. Acceptance testing may also
reveal requirements problems where the system’ s facilities do not really meet the
user’s needs or the system performance is unacceptable.
 SOFTWARE MAINTENACE

The maintenance stage of system development involves

a) correcting errors discovered after other stages of system development
b) improving implementation of the system units
c) enhancing system services as new requirements are perceived

Information is fed back to all previous development phases and errors and omissions in
original software requirements are discovered, program and design errors found and need
for new software functionality identified.

Definition 1
Maintenance is the process of changing a system after it has been delivered and is in use.
Simple - correcting coding errors
Extensive - correcting design errors.
Enhancement- correcting specification errors or accommodate new requirements.

Definition 2
Maintenance is the evolution i.e. process of changing a system to maintain its ability to
survive.

Types of maintenance
There are FOUR different types of maintenance:
a) Corrective maintenance:
This involves fixing discovered errors in software.
(Coding errors, design errors, requirement errors.)
b) Adaptive maintenance:
This is changing the software to operate in a different environment (operating system,
hardware) this doesn’t radically change the software functionality.
c) Perfective maintenance:
Implementing new functional or non-functional system requirements, generated by
software customers as their organization or business changes.
d) Preventive maintenance:
Making changes on software to prevent possible problems or difficulties (collapse,
slow down, stalling, self-destructive e.g. Y2K).

Operation stage involves

• use of documentation to train users of system and its resource
• system configuration
• repairs and maintenance
• safety precautions
• date control
• Train user to get help on the system.

Maintenance cost (fixing bugs) is usually higher than what software is original due to:
-
I. Program’s being maintained may be old, and not consistent to modern software
engineering techniques.
They may be unstructured and optimized for efficiency rather than
understandability.
II. Changes made may introduce new faults, which trigger further change requests.
This is mainly since complexity of the system may make it difficult to assess the
effects of a change.
III. Changes made tend to degrade system structure, making it harder to understand
and make further changes (program becomes less cohesive.)
IV. Loss of program links to its associated documentation therefore its documentation
is unreliable therefore need for a new one.

Factors affecting maintenance

Module independence
Use of design methods that allow easy change through concepts such as
functional independence or object classes (where one can be maintained
independently)

Quality of documentation
A program is easier to understand when supported by clear and concise
documentation.

Programming language and style

Use of a high level language and adopting a consistent style through out the code.

Program validation and testing

Comprehensive validation of system design and program testing will reduce
corrective maintenance.

Configuration management
Ensure that all system documentation is kept consistent through out various
releases of system (documentation of new editions.)

Understanding of current system and staff availability

Original development staff may not always be available. Undocumented code can
be difficult to understand (team management).

Application domain
Clear and understood requirements.

Staff availability
Hardware stability

Dependence of program on external environment

MAINTENANCE PROCESS
Maintenance process is triggered by
(a) A set of change requests from users, management or customers.
(b) Cost and impact of the changes are assumed, If acceptable, new release is planned
(involving elements of adaptive, corrective and perfective maintenance).
(c) Changes are implemented and validated and new versions of system released.

CHANGE IMPACT SYSTEM CHANGE SYSTEM

REQUEST ANALYSIS RELEASE IMPLEMENTATION RELEASE
PLANNING

PERFECTIVE ADAPTIVE CORRECTIVE

MAINTENANCE MAINTENANCE MAINTENANCE