Is everything really okay?

In software development there are some crucial elements in order to assure that we are doing what we need to solve the initial problem that made us start to begin with.

First of all, are we building the product right? This is what we need to ask ourselves when we think about Verification; every specification should be checked to be sure that our software is well developed, after we are certain that everything’s okay, we will start worrying about the other part: Validation.

Validation is the process of building the right product, while you may think that this process should be done before even starting, well… you may be right, but not quite, what about when we’re almost done with our product but it isn’t quite what the user needs, we should make this process of questioning in order to redefine or reorganice our development so, at the moment of the deployment, it meets the user needs as close as possible.

What happens if something does not go well? We have some concepts fo different kind of errors:

• Fault – wrong or missing function in the code.
• Failure – the manifestation of a fault during execution. The software was not effective. It does not do «what» it is supposed to do.
• Malfunction – according to its specification the system does not meet its specified functionality. The software was not efficient, it was not usable, it was not reliable, etc. It does not do something «how» it is supposed to do it.

What about test cases?

A test case is a tool used in the process. Test cases may be prepared for software verification and software validation to determine if the product was built according to the requirements of the user. Other methods, such as reviews, may be used early in the life cycle to provide for software validation.

International Standards

1012-1986 – IEEE Standard for Software Verification and Validation Plans

Uniform and minimum requirements for the format and content of software verification and validation (V&V) tasks and their required inputs and outputs that are to be included in SVVPs are provided for both critical and noncritical software. For critical software, specific minimum verification and validation (V&V) tasks and their required inputs and outputs that are to be included in SVVPs are defined.

P1012 – Standard for System, Software, and Hardware Verification and Validation

This verification and validation (V&V) standard is a process standard that addresses all system, software, and hardware life cycle processes including the Agreement, Organizational Project-Enabling, Project, Technical, Software Implementation, Software Support, and Software Reuse process groups. This standard is compatible with all life cycle models (e.g., system, software, and hardware); however, not all life cycle models use all of the processes listed in this standard. 

C/S2ESC – Software & Systems Engineering Standards Committee

Verification and validation (V&V) processes are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs. V&V life cycle process requirements are specified for different integrity levels. The scope of V&V processes encompasses systems, software, and hardware, and it includes their interfaces. This standard applies to systems, software, and hardware being developed, maintained, or reused.

At the end as an abstract, we should be sure that our product is what we need and that it is working as needed, so everything turns out well, this can be tested via Validation & Verification, using tools as Test Cases and using IEEE Standards as our backbone.

Thanks for learning with us…

-RC