How to get that little blue check mark on your site or profile… I mean, validating and verifying software (V&V)

As always, let’s get to what we’re gonna be talking about in this post first:

  1. V&V in the life cycle of software development
  2. International standards for V&V of Software
  3. Planning V&V
  4. Administration of a V&V Plan

Before everything, we shall ask our main questions.

What is verification and validation?

Just by hearing those two words, we can get a pretty basic definition, which would be verification: checking that something completes all the requirements it needs and validation: the process that we follow to verificate a product, thing or whatever you could think.

When talking about the life cycle in software, validation and verification is a step used during almost the whole process of development, so we’ll see in the following table what happens in each one, very briefly:

RequirementsValidate requirements along with the client to ensure proper understanding of what’s going to be done.Verifying that all requierements are unique and doable.
Architecture and DesignAll types of design that might end up being used have to be validated with the costumer, as to meet their expectations.We verify that all designs are meeting the non-functional requirements (like performance or usability)
ImplementationFor each requirement done, we have to validate with the client if that’s what they wanted.When doing unit and integration tests, or while having peer review.
TestingCheck that all functionality meets the client expectations and that all messages are clear.All test cases need to pass this part, as to ensure that everything is working as intended.
DeploymentAll software after installation should be working as intented.Configuring environment and running smoke tests.

As to international standards, ISO has always been there to mantain a certain level needed for validating different things, including software. As to what I could say about this, is simply that by having a certain level required for stuff to be valid and verified by certain organisms, we can mantain a same procedure for developing new stuff, such as software, I’ll also leave this article here so that people can indulge in really technical stuff if they feel like it, because I dont feel like it.

Planning and administrating V&V, the real challenge

For this, we have a term that already exists and depicts pretty well what was to be done. Verification and Validations Plans. This pretty much works by going hand with hand on your normal software life cycle, but implementing everything that’s needed to make a V&V correctly:

  • Explaining the test and objective of the project.
  • Define what items you’re gonna be testing, using the required documentation.
  • What features need to be tested? Along with all the data you’ll need.
  • What DOESN’T need to be tested? This should be a small list, and you can include items that need too much time and effort to be properly tested at earlier phases.
  • How is your testing team gonna approach the requirements? By defining a pass/fail criteria, you can prevent later confusion on how to validate and verificate diverse stuff.
  • An approach for handling any mistakes and errors that could stop your testing, otherwise you’ll lose time on making all test cases needed, with their design specification and procedures.
  • Environmental needs (I think this one pretty much speaks for itself? Please don’t run some software on a all mighty computer that your client does NOT have).
  • Approval from the client for all requirements.
  • Operation and maintenance in case a step was missed or something went wrong.
  • An open space of possible upgrades or replacement.

So, this was it for Validation and Verification, if you have anything to share, like experiences, knowledge on the topic, or just a plain comment on how you dislike my blog, please share in the comments so that other people can also enjoy a different perspective!

Who even needs models and standards for software processes? Ah, that’s right… us.

So, here we are again! This time to talk about a one teensy weensy but ever so crucial little tiny detail in software processes! Models and standards.

(have a cookie if you got the reference in that small paragraph before seeing the image)

These are the following topics i’ll try to cover in this blog:

  1. CMMI
  2. TSP/PSP
  3. ISO-15504
  5. IDEAL method


Capability Maturity Model Integration (CMMI), is a processes model that helps an organization promote their members so that they can have a better performance. The questions this model ask are related to how good we work, our improvement and if our processes are as good as they should be and working as necessary, so we can call this model a book of ‘whats’ and ‘hows’, giving us a hint on what to work in.


Whenever we talk about time management, personal improvement on programmers, and guidance on organizations that use a CMMI model, then we’re either talking about PSP/TSP practices, or you’re somehow in an alternate universe where things are incredibly wrong.

something just doesn't add up - pondering retard | Meme Generator

PSP concentrates in work practices in a more individual manner, so that we can organize our day through day activities and handle product quality. This practice can be carried with a team, called the TSP (Team Process Software), which is in turn commanded by a gestion system, and of course, a team leader that evaluates the individual progress of each member of the team.

TSP, is insted, a method of stablishing teamwork and improving it, using two basic components:

  • Work team formation
  • Work team gestion

The major problems that are solved with this, are predicting time and cost in business, lack in productivity, and software development and cycles, along with product quality.

YAY TEAMWORK! - Yay Teamwork! | Meme Generator


This new norm presents us the following objectives:

  • It’s necessary to propose and develop an evaluation stand in software processes.
  • Evaluate progress using experimentation.
  • Promote the evaluation techonlogy to a global state.

This specific standard evaluates software life cycles and requisites and evaluating each one of the evaluation steps in the ISO standard 15288.


MOPROSOFT (in spanish, Modelo de Procesos para la Industria del Software de México) is a model for the development and maintenance of software, focused on the processes of a basic structure company, taking in mind three organization levels: High Direction, Gerency and Operation, looking to standarize all of what they do, both in effectivity and integrity.


Initiating, Diagnosing, Establishing, Acting & Learning, this model serves as a roadmap to initiate, plan, and implementation of process improvement actions. As we can see, this has five main “steps”:

  • Initiating: Initiate the change, lay the groundwork for the changes that WILL happen in the next phases.
  • Diagnosing: Where are we? Was this the place we wanted to be at this point? Analysing in this phase is essential.
  • Establishimg: Plan what you’re gonna do, how are you gonna reach your goal? Prioritize tasks, change implementation and establish the teams.
  • Acting: Do what you planned, nothing more to say for this one.
  • Learning: Learn from the mistakes you made, improve and adapt new techniques for the future, so that the next IDEAL cycle will be better.
IDEAL Cycle — Initiating, Diagnosing, Establishing, Acting & Learning

And that’s all models we’re gonna see today, hope you enjoyed and learn something new (for I surely did), and if you care to answer, which one do you think is better? Or should all of them be implemented somehow? I wanna know!

Software Quality

Time to start with an actual mastery topic! So, in the following blogs, there are basically four sub-topics to follow:

  • Defining Software Quality
  • Focus on process
  • Ensuring Software Quality
  • The role of standards in Software Quality

What is software quality?

By definition, it’s the field of study and practice that describes the desirable aspects of software products. What do we mean by this? We can put it down as the part of software development dedicated to improving and designing all software products, trying to establish the minimum of what’s required in it.

Software Quality Assurance (SQA) ensures how we handle the quality in the processes of a software product, establishing and evaluating all of these in a “process-focused action”, so that in the end, we end up having a product completely functional, with the basic minimum quality being accomplished in all cases, and a happy user in most cases.

The challenge in ensuring quality

In this industry, even if we test an infinite amount of times, against all possible errors that we can think of, we developers can never actually declare that our software is free of defects, unlike how our counterpart, the product manufactures, can. We have some reasons as to why this happens:

Complexity, this one pretty much talks about how many possible paths we have when designing our software, if we first click this, and then that? If I use this button and then go back to click this other one? Imagine this but with a complete application that has many sections. Visibility, this one is pretty clear, manufacturers can see in their products if maybe there’s a splint in one side, or this one part isn’t reinforced enough, us, on the other side, we can’t physically see what’s wrong with what we’re doing, so we have a lot more troubles detecting errors.

Why do we have quality standards?

What happens when we need to work with people that have had a completely different way of learning development and work than we did? How are we supposed to keep a straight line of work to organize our software product and meet all standards that we know along those that the other person knows? That’s right, quality standards. By having a general rule and approach to how something should be built, we can establish a base for everyone to work in.