Hi everyone! Today we are going to learn about an exciting and important topic for software development, Verification and Validation of Software (also known as V&V), the first thing that we need to understand it’s those two keywords, I have mentioned about them in a previous blog post, but will refer to them in here:
“A test of a system to prove that it meets all its specified requirements at a particular stage of its development.”
Definition of Verification by IEEE-STD-610
“An activity that ensures that an end product stakeholder’s true needs and expectations are met.”
Definition of Validation by IEEE-STD-610
As we can see in the definitions, the key difference it’s that verification can happen at any particular stage of the development, this to verify that the system meets the requirements at that stage, and we finally validate our end product to see if it satisfies the users/stakeholder’s expectations. Although, validating can be at the end of each stage too.
V&V on Life Cycles
V&V sounds good, but every time you are working on a software project on a company, it is natural to follow a life cycle model (you can see more about them in my post), and the question will be: How can I verify and validate at every phase?
Mohamed Sami has a great blog post, that I recommend reading, where he talks about V&V and how it’s implemented in each of the Software Development Life Cycle (SDLC) phases:
| Phase | Verification | Validation |
| Requirements | The requirements need to be unique and server a purpose for each one of them. | The requirements need to fulfill the vision of the client/stakeholder, eliminating every ambiguity. |
| Design | Verify that the designs meet the requirements that are specified by the previous phase. | The design has prototypes, either of UI, wireframing, or architecture design. Could even be a design document. |
| Implementation | This is the place where we verify the code by using unit and integration testing, and code reviews. | The requirements are well defined and implemented, make changes accordingly if necessary. |
| Testing | Verify that all the test cases have passed, and the software works properly. | Validate that the software is fit for client and user acceptance, meeting the requirements previously defined. |
| Deployment | Verify installation and configuration of environment, running tests. | Make sure that everything works when is installed. |
International Standards
Now we arrive to the standards part! Which we have a lot of those regarding software practices, we are going to dive into these really briefly, keep in mind that if you want to deeply learn about these, it is recommended to go to the links I will provide in each one of them. We are going to focus on only two of them ISO and CMMI, keep in mind that there are others too. I recommend reading this blog post where it details more high level information about V&V.
ISO
The first International Standard of V&V that we are analyzing is ISO/IEC 12207:2008, which includes a series of activities of verification and validation that are part of the software development process.
| Verification | Validation |
| The requirements need to be reviewed before going forward. | Elaborate test requirements, such as the test cases based on those requirements. |
| The software design need to have reviews on both high and low level design documents. | Evaluate testing cases based on the designs. |
| During implementation Code Reviews are necessary. | Test functionalities and other metrics needed. |
| It’s necessary to verify that the user manuals and other documents are correct and updated. | Test that the software meets business standards. |
On my experience, this is the one that I am most familiar with in my past internships at Google, specially with both high and low level design documents and code reviews, which is a fundamental part of the development.
CMMI
The Capability Maturity Model Integration (CMMI), evaluates the process of developing, maintaining and operating software systems. It has with it a few V&V activities that are good practice for large companies:
| Verification | Validation |
| Do peer reviews. | Validate that the software is ready are suitable for the production environment. |
| Establish organizational policies for planning and reviews. | Make changes accordingly with the lessons learnt in the reviews. |
| Verify what are the work of the products built. | When providing validation, everything needs to be monitored and controlled. |
Personally, I am not to familiar with this method, although I have experience pieces of it, such the establishment of organizational polices for planning and reviews. From my perspective, this environment works best when releasing huge products for enormous companies, one example is Oracle DB services for companies. You can read more about this model in here.
Plan V&V
First of all, when we start gathering requirements and designing, we need to have a plan on how we are going to verify and validate our software, this is called the System Verification Plan, and it’s common to see in a “V” like life cycle:
On this document it shows what are the procedures that are going to be follow to validate the program, and it also shows the requirements of the stakeholder’s. It can be written at the start of the software development life cycle, but sometimes changes are made later after the design once things are starting to get clearer about the whole system structure.
Administrating the plan
While in executing, things need to be always monitored, for this, we have can administrate what is happening, for this we mostly use tools, and nowadays, online tools, there is this document from the Requirements Experts where it shows many tools for administration, and also I have a blog post where I talk about Tools for V&V. For administration the ones that are the most useful are:
- Verification Requirement Definition Sheet.
- Task Definition Sheets.
- Task Performance Sheet.
Final Thoughts
Verification and Validation is crucial for a lot of software development companies, it provides a way to correct or identify issues before they appear, and mostly avoiding having “spaguetti code” as the code base starts to get larger. Definitely a thing that is worth reading more about!
Hivini 