Skip to main content

Focus on Verification (V&V) to Transform Your Organization


When I was a quality manager in my earlier job in an MNC (Multi-National Company), a lot of my team members were quite misinformed about the “Power of Verification” in a software development process. I went through a lot of reflection around my own experience working on multiple projects related to doing “software verification” exercises. I gained profound understanding of how organizations can gain immense benefit just by understanding the true power of this activity (if done correctly).

For the uninitiated, let me give a brief understanding about what “Verification” means.

As part of ensuring quality of any software, the whole development process can be split into 2 simple parts –

  1. Verification &
  2. Validation

To put this simply, “Verification” is always done before software code is developed & “Validation” is always done post development of software code.

A “Verification” activity means, doing detailed analysis and reviews for –
  1. Customer Requirements
  2. Software Architecture
  3. High-Level Designs
  4. Detailed-Level Designs

A “Validation” activity means, running actual tests at various stages of the actual software development (such as unit testing, integration testing, systems testing, systems-integration testing and user acceptance testing).

The “Verification” activity is extremely important to “prevent issues” in the later development of the software code. This activity is so powerful, that if this is correctly done by the team, a lot of issues and rework on code can be simply avoided!

Organizations can thus save huge costs and time by doing the following and literally bring in “transformative changes” in delivering very high-quality projects.
  • Mandate Requirement Reviews: Make your teams spend more time in ensuring very high-level of clarity on customer requirements by doing detailed requirement reviews. Moreover, it is very important that every customer requirement is documented by a business analyst! I have worked with so many business analysts who make this eternal mistake of NOT documenting the smallest of requirements and unfortunately, a miss here has a major impact during the software development process.
  • Mandate Architecture and Design Reviews: I have been through so many misconceived ideas from development managers, that the whole team is not required to do an architecture and design review. It is a myth that non-technical staff can not give constructive feedback on architecture and design. Instead, the opposite is true. Leadership should ensure that the whole team should perform a review of the architecture, high-level and detailed-level designs. Sometimes, a simple comment from a layman’s perspective can provide an extremely useful insight to the development team related to their high-level and detailed-level designs.
  • Design Models to Achieve Comprehensive Requirements Coverage: Establish standardization and a process-oriented approach to create models, that become a reference to the team for doing the requirements and design reviews. How a review should be done and the basis of doing the review can greatly help the team and the organization to ensure very high-quality deliverables to their customers.

The last point above can help you standardize with the most appropriate metrics to monitor and optimize across the execution of multiple projects.

I shall be sharing exclusive posts on above, that can help organizations design and build the most appropriate models and metrics to perform a productive requirements and design review session.

A lot more is coming in future… and we will keep you posted.

Please also refer to our other related posts below:

- Written by Anand Nanavati (SupraDigit Solutions)

Labels:
Location: Mumbai, Maharashtra, India

Comments

Post a Comment

Popular posts from this blog

Reduce Your App Development Costs by More than 50% by "Simply Preventing Bugs"!

"Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”— Steve Jobs Everybody loves to avoid a disaster, but there is a “proactive” effort to do activities that can prevent a disaster from happening. Most of the executives do not want to “get involved” in such “proactive” efforts, simply due to the love of fixing urgencies Or having a mindset that it’s not important.   I remember, when once I was working with the Quality Assurance team on a product. The development team simply refused to spend efforts on the most essential “unit testing” for their developed components! The intent was to release the software to the QA team as soon as possible and focus more on so-called “core development”. Over the years, looking at multitude of projects failing in-spite of highly experienced resources, reasonable time and the intent, I have uncovered that, prevention is the “Most Important” and “Ignored” part of software development. Why should we
Post a Comment
Read more

Change the World by Keeping Your Inner Fire Ignited

A decade back, when I was working on a huge enterprise program (with multiple projects) along with a big team (of close to 300 people), we were a group of managers who were evaluated and pushed by the senior management to “proactively” deal with issues and to work on finding new solutions. I used to think of how - we can become “proactive”, when we were already focusing our efforts on fighting our daily “fires” or urgencies of our project work. When I delved deeper into our daily work habits, it struck me that till the time we are not excited about “getting things done”, the willingness to explore more out of our comfort zone just doesn’t happen. The innate human behaviour is to follow a routine and establish a comfort zone over a period. The 1st factor – “an external stimulus” can upset us and force us to think or act out of our comfort zone.  The 2nd factor that can make us “move” out of our comfort zones is about having an excitement of a future or coming up with a vision th
Post a Comment
Read more

The Confusion Between Software “Metrics” Vs “Matrix”

When I was studying in class 10 th , I asked my English teacher a very basic question about why two words in English sound the same but mean different. That time, we never had a separate subject on “phonetics” and I was quite unaware of this part of the English subject then. She smiled and very smartly told me that – “English is a ‘funny’ language” and went away! I was amused by her answer the whole time. Only later I learnt that in English there are so many words with a spelling, that are used “as per the context” to mean different than their similar sounding words with a different spelling. In quality assurance and in general in project management, many testers and project managers make the same mistake with a misunderstanding and confusing these 2 words – “Metrics” and “Matrix”. They use them interchangeably! Metrics in the quality management context means “to measure” (check its meaning here - https://www.dictionary.com/browse/metric) and … Matrix has different meanings based o
Post a Comment
Read more