Check out my first in depth article on a simple framework to improve requirements management here.
Debug your requirements!
Leave a reply
Monthly Archives: October 2012
Follow
ForwardA definition of testing
Testing is changing: analysts comment on the promising trend of the market, big players jump in to get their shares, customers come to the realization that the “Ready, Fire, Aim” school of software engineering is becoming outdated.
Fine, testing is no longer the “necessary evil” but what is it really?
In order to set the record straight, I offer the following definition:
Testing is
- A strategic business project
- Which seeks to confirm the alignment of systems with stakeholders’ expectations
- For an optimum initial cost
- In a manner that can be sustained or, even better, improved over time
It is a project because the validation phase needs to be planned and because measurable exit criteria need to be defined in order to end it. This project is driven by the business, because those exit criteria must be aligned with the users’ priorities.
It is strategic because, for an organization, the ability to implement its vision depends on its ability to align its information system. Its cost can be optimized because, as the work of quality control pioneer, Joseph Juran, has shown, a balance can be struck between the costs of fixing defects and the costs of preventing defects.
Finally to make the investment perpetuate, it is smart to anticipate that the same effort will need to be carried out each time the system is updated and take some measures accordingly such as automating the most critical tests.
Why the world needs better software projects now
In 2006, Gartner introduced the concept of ‘Dead Money’ to characterise the subset of IT budgets devoted to keeping the lights on as opposed to contributing to business growth or enhancing competitive advantage. At the time, the amount of average ‘Dead Money’ was estimated as 80% of IT budgets: eight dollars out of ten.
I haven’t come across a set expression for the remaining two dollars so I’ll stick my neck out and offer this one: ‘Pocket Money’.
Thus we can write the first law of IT budgets:
IT budget = Dead Money + Pocket Money
This equation would normally spur two reactions:
- let’s reduce this ‘Dead Money’ so we can have more ‘Pocket Money’
- and let’s make the most of our existing ‘Pocket Money’.
Unfortunately several studies have shown that ‘Pocket Money’ is shamefully wasted.
When you are overweight it’s of common knowledge that you have to do two things to loose weight: change your eating habits and exercise. One without the other will not give you the expected results.
Similarly, in order to efficiently fight back ‘Dead Money’, organizations need not only to take action against the causes of their overinflated ‘keeping the lights on’ budget but also to change the way they are doing new software projects because inefficient projects generally lead to high maintenance software. In other words, just like greasy hamburgers will eventually become fat, wasted ‘Pocket Money’ is ‘Dead Money’ in the making.
This looping mechanism is what drives the ‘Dead Money’ ever higher. This phenomenon is nothing new but what is unprecedented is the level it has reached in a context where IT budgets are under much pressure due to the global crisis and their ensuing new regulations.
That is why the world needs better software projects now.