Our Contribution to OpenSource         

How What Why When Where If - its importance

Author: Varuna E.

Let start with a simple programming question: Write a C program to add two numbers and display the values.

Hmmmmm, is that a trick question? May be yes, or is not at all? Here is the complete source code:

# include <stdio.h>
int main(void)
int a, b, c;

printf(“input first number: “);
scanf(“%d”, &a);
printf(“input second number: “);
scanf( “%d”, &b);
c = a +b;
printf(“computed value = %d\n”, c);

Perfect code indeed & it did compile without any errors or warnings on my FreeBSD 8.0 having gcc 4.2.1. Test case written to cover the entire code worked without reporting any failure.  Me proud of my code.

Lets take this code to the customer for acceptance & the test that they executed indicated a failure! Yes it failed to provide the desired results in their environment.  Me bless me! HOW can the code fail?

Ah ha! the dawning is that there might potentially be an issue is with the compiler on the customer’s system as there is no reason why the C code failed.

Lets begin the root cause analysis:

HOW and WHEN did they execute the code? Was the code executed when the system was under high load? A probable answer to this could be, the system load does not really matter given that the OS on the system is multitasking enabled.  More than that, the executed code is not at all resource hungry – be it in terms of data and code segments, or the time spent on the CPU.

So sets us up to ask the question WHAT did the customer do to have the code fail? The customer indicated that the values used in testing were on the number line.  The perplexing question staring the developer was and caused a review of the code and the values used in the developer end test cases that were: IF a = 1, b = 2, then c = 3 => code works fine.  IF a= 984, b = 984, then c = 1968 => code is absolutely fine indeed.  IF a = 0, b = 0, then c = 0 => code is fine.  IF a = -1, b = -1, then c = -2 => code is fine indeed.

So HOW and WHY the code failed in the customer environment?

As it turned out; the customer executed their defined test cases, and as per that framework it failed.  Hmmmmm, interesting.  HOW different was our test case in comparison to those that of the customer? This is indeed taking us somewhere instead of figuring things in the dark.

The imperative question is: WHAT were the customer test cases based on? The defined objectives for the customer were: The input values should be between -1 and -30, between 20 and 100, between 4000 and 4250, and IF any other values of the input, the code should indicate the appropriate response and exit from further execution.

Me bless me! No wonder that the developed code failed in the customer environment.

The magnum opus questions then are:

WHAT went missing in the requirement specifications?
WHEN did the error creep into the gathered specifications?
WHERE did the error creep in?
WHO is responsible for the mess?
HOW can things be done better?

The pointers that stand out is that the requirements elicitation was incorrect.  HOW can it be so authentically be said that the elicitation was incorrect – there can also be a possibility that the documentation of the requirement specification was incorrectly done? This implies that the error could have crept into at any point in time along the software lifecycle.

If definitely adds value to ask the fundamental questions: WHEN WHAT WHERE HOW WHY and IF all along the software lifecycle.

As a closing note, there is a beautiful book called SWEBOK – Software Engineering Book of Knowledge and is published by IEEE.

<< back     

Your feedback is warmly appreciated and we look forward to  Hear you at feedback at eudaemonicsystems dot net  or online at http://feedback.eudaemonicsystems.net

Simple, Specific & Insightful