To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
Verification and validation

Verification and validation

Jan 12 2010
Author:

The terms verification and validation are related to software quality checking. We use these terms in our articles and reports. 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. During the investigation we came across a work by V.V. Kulyamin "Software verification methods" [1]. 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.

Before going on we must introduce the term "an artefact of software life-cycle". By artefacts of software life-cycle we understand 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.

The difference between verification and validation is illustrated in Figure 1.

0049_Verification_and_validation/image1.png

Figure 1 - Relation between verification and validation

The definitions given above are drawn through some extension of the definitions of IEEE 1012 standard on the processes of verification and validation [2]. In the standard software engineering glossary IEEE 610.12 of 1990 [3], the definition of verification is nearly the same but the definition of validation is different - it is said there that validation must check if the result software corresponds to the requirements set to it in the beginning of the development process. In this case, validation would be an instance of verification but it is not mentioned anywhere in literature on software engineering, and this is the reason, together with the fact that this definition was corrected in IEEE 1012 of 2004, that it should be considered incorrect. This phrase by B. Boehm which is used very frequently [4]:

Verification answers the question "Are we making the product properly?" while validation - "Are we making a proper product?"

also contributes to the confusion because its aphoristic character, unfortunately, combines with ambiguity. But multiple works of this author allow us to think that he meant by verification and validation nearly the same notions that were defined above. The described discrepancies can be traced in the content of software engineering standards. Thus, ISO 12207 standard [5] considers testing a kind of validation but not verification and it seems to result from sticking to the incorrect definition of the standard glossary [3].

In conclusion, I would like to note that according to the definitions given above static source code analysis corresponds to software verification being the method of checking correspondence between program code and various coding standards. Static analysis checks if the results of the stage of designing a program system correspond to the requirements and limitations stated before.

References

  • IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
  • IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
  • B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. In R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA:MIT Press, 1979.
  • ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.
Popular related articles
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept