Page 71 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 4: Introduction to Validation, Metrics

The latter definition allows for more flexibility in the interpretation of validation; it answers the Notes
question of “Are we providing what the customer wants?” However, both definitions assume
the existence of correct requirements and focus on the concept of building the right product as
defined by these requirements.
Software validation has always been problematic in software engineering. Unlike many other
engineered products, software often cannot be visualized, thus, in many cases, resulting in
software validation being a reactive last minute process. It is hard for validation to be a continuous
process throughout development as with many physical systems when there is no physical
product to monitor. The ultimate validation of software systems is effectively the operational
evaluation of the system by the user, and often this is where validation of the system is relegated.
The IEEE definition lends itself to this approach as it focuses on the satisfaction of requirements
through testing. Quite simply, validation of software has not had the same rigorous research
and development of processes as other areas of software engineering, particularly verification.
Validation is a relatively misunderstood process.
The software engineering discipline has become competent in the area of verification. We can
build portions of systems to their applicable specifications with relative success. However, we
still build systems that do not meet customer’s expectations and requirements. One of the key
tools to address this situation is validation. Significant efforts afforded to software validation are
now a priority for software engineering. More proactive, rather than the typical reactive, solutions
are being sought. The IEEE definition of validation indicates that it is a process to be carried out
at the end of each phase (or lifecycle activity); however, this should only be the finalization, or
completion, of validation. The validation process should be a proactive and continuous process
to be carried out prior to, and in parallel with, the development and verification activities with
closure at the end of each phase.
Although validation focuses on ensuring that initial customer requirements are met, there
is more to validation than meets the eye. Validation is required whenever a requirements
derivation process occurs (i.e., a translation of requirements from one domain to another). An
example of this is taking a customer’s requirements in their natural language and translating
them into a specification. The specification needs to be validated to ensure that it maps back to
the cognitive understanding of the stakeholders who originally supplied the requirements. To
ensure the traceability of products for validation, the validation process is ongoing throughout
the development cycle whenever this translation of requirements takes place. Any higher-level
requirement being translated to a lower-level requirement requires a validation process to ensure
that the products of the lower-level requirements are indeed valid. In contrast, verification is
defined as “The process of evaluating a system or component to determine whether the products
of a given development phase satisfy the conditions imposed at the start of that phase.”

The key difference between validation and verification is that verification simply ensures that
requirements for a given phase are met. Validation ensures that overall customer requirements
(i.e., customer expectations) are met. There is somewhat of an overlap in validation and
verification processes, particularly when considering either process in the “middle-levels” of
abstraction. They are in fact processes orthogonal to one another. In its purest form, validation
ensures that customer expectations are met; failure to meet these expectations (assuming they are
constant throughout the project) indicates a failure in the validation process. Figure 4.1 shows
graphically how verification and validation contrast.
The end-result of any validation process should be actionable data presented as feedback to the
many different customers, or stakeholders, of the system. This effectively creates a feedback loop
from any stage in the development process that allows the customer to clarify their expectation
of system behaviour.

LOVELY PROFESSIONAL UNIVERSITY 65