Page 155 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 7: Introduction to Verification

independence requires that the services provider not organizationally be or have been, nor use Notes
personnel who are or were, involved in the software development or implementation effort,
or for that matter participated in the project’s initial planning and/or subsequent design. Such
technical independence helps ensure every review report is free of personal or professional bias,
posturing, or gold plating. Secondly, managerial independence is required of the services provider
to ensure that the effort is vested in an organization departmentally and hierarchically separate
from the software development and program management organizations. Such managerial
independence helps ensure that the service provider is able to deliver to both State and Federal
executive leadership and management, findings and recommendations of an review without
restriction, fear of retaliation, or coercion.
The terms verification and validation are related to software quality checking. Very often we
have heard various comments and debates concerning the question if static analysis of program
source code should be referred to verification and validation and in what way these notions
differ. On a whole, it seems that everyone means something different by these terms and it leads
to a mutual misunderstanding.
We decided to make it clear in order to stick to the most proper understanding of these notions.
“Software verification methods” it gives a thorough description of the terms and we decided to
further rely upon the definitions provided in this work. Here are some extracts from it related
to verification and validation.
Verification and validation are the types of activity intended for checking the quality of software
and detecting errors in it. Having the same goal, they differ in the origin of the properties, rules
and limitations (whose violation is considered an error) being tested during these processes.
The term can be defined as “an artefact of software life-cycle”. By artefacts of software life-cycle
we appreciate various information entities, documents and models created or used during the
process of software development and maintenance. Thus, requirements specification, architecture
description, domain model in some graphics language, source code, user documentation etc.
are artefacts. Various models used by single developers during software creation and analysis
but not fixed in the form of documents available to other people are not considered artefacts.
Verification checks if some artefacts being created while developing and maintaining software
correspond to some other artefacts created earlier or being used as source data and also if these
artefacts and processes of their development correspond to the rules and standards. In particular,
verification checks if standards, software requirements specification, design decisions, source
code, user documentation and operation of the software itself correspond to each other. Besides,
it checks if the requirements, design decisions, documentation and the code are arranged in
correspondence with the software development rules and standards accepted in a particular
country, branch and organization, and also if all the operations stated in the standards are
executed and in the appropriate sequence. Defects and errors detected during verification are
divergences between some of the listed documents, between documents and actual program
operation or between standards and actual processes of software development and maintenance.
Making a decision what document must be corrected (if not both of them) is a separate task.
Validation checks if any artefacts being created or used in the process of software development
and maintenance correspond to the needs of the users and customers of this software, with taking
into account the laws of the domain and limitations of software usage context. These needs
are usually not fixed in the form of a document - when they are, they turn into a requirements
specification, i.e. one of the artefacts of the software development process. That is why validation
is a less formal activity than verification. It is always carried out in the presence of customers’,
users’, business-analysts’ or domain experts’ representatives - those whose opinion can be
considered a rather good expression of the needs of users, customers and other persons concerned.
The methods of its execution often involve specific techniques of discovering knowledge and
actual needs of the participants.

LOVELY PROFESSIONAL UNIVERSITY 149