29 January 2007
How to put real process management into the software industry when there’s no time to learn the basics of quality? Adrian Price discusses why software organisations have moved away from ISO 9001: 2000 certification and are taking up maturity models in increasing numbers, with many turning to the new version of the five part AS/NZS ISO/IEC 15504 ‘Software Process Improvement and Capability Determination’ international standard set, known as SPICE.
In New Zealand and Australia and even that bastion of certified quality management systems, the UK, there is a downward trend in total ISO 9001: 2000 certifications, while world-wide overall numbers have returned to an apparently unstoppable growth. In NZ, organisations with software included in the scope of certification have diminished to almost zero. Why are organisations walking and software people running away from ISO 9001, when others in the world are still moving towards the ‘light’? Understanding why ISO 9000 doesn’t always work is useful, for New Zealand competitiveness it is vital, making the need for an alternative mechanism to raise quality levels imperative. Overseas many software organisations are turning to maturity models like SPICE for process improvement.
Quality and Software
To be worthwhile Standards must add business value, whether that’s to meet a regulation, a specific purchaser requirement or simply good practice. ISO 9001 is a tool for quality practice in some industries, accepted as the icon of achievement, while for others it has become a millstone. Used in the right place, at the right time, with the proper guidance and by those who know what they are doing, it can find a pure lode of improvement – but that’s the problem. To be successful, a generic Standard like ISO 9001 needs a solid level of industry quality knowledge to create consistent interpretation and meaningful application. It works on processes within mature industries with fixed routines like manufacturing, health and defence engineering, but not with unsettled immature industries with changing processes, technology and products like software.
Both the quality profession and computer software industry are young and dynamic, both starting in earnest in the 1950s. It takes time for a profession or industry to come of age; generations to change some communal mindsets. Software is an industry which seems to believe you can test-in quality, that building-in quality is too costly or not possible, accepts process and product measurements which focus on time and cost, with no causal analysis and a cost of quality around 42%. Rework is rife and individual heroes are lauded when they put things right, even though they often created the problem in the first place.
With limited knowledge of how quality principles, philosophies, concepts and techniques apply, computer software is an industry which ricochets from one management buzzword to the next, constantly looking for the silver bullet. Computer software is now at the same maturity level as manufacturing was during the early days of assembly lines where structured testing at the end of the process is seen as the quality process (e.g. final inspection and test). It took failed businesses, lost industries, major unemployment and mini recessions before the lesson was learnt in hardware manufacturing. What’s it going to take for software?
From Explosive to Implosive Standards
ISO 9001:2000 is a small single-line pass-fail quality management system Standard focused on process efficiency and effectiveness and to derive real management benefit from using it requires each sentence and phrase to be interpreted for the needs of that industry and each organization. This latest version added more flexibility in documentation, required organisations to consistently improve and moved notably away from prescriptive to performance management requirements, which requires even more knowledgeable and detailed interpretation. Unfortunately the computer software interpretation for ISO 9001: 2000, AS/NZS ISO/IEC 90003: 2004, was only available six months after the final date for conversion from the 1994 version. ISO 9001 is an explosive Standard, requiring expanded explanations to make sense, and the software industry finally gave up trying to contain the debris of massive add-on or misaligned quality systems created by non-expert application, which only ever included the bare bones and added little or no real improvement.
So this Standard hasn’t worked in software. The normal way to overcome this would be through training to embed a level of knowledge. However, even basic quality is not on most IT curricula, just testing. IT is forever changing and if any education budget is available most training is used to keep up with technology. An alternative is an implosive Standard, one that gets around the lack of quality knowledge by drilling down into detail, instead of exploding outward trying to find quality knowledge that the software industry doesn’t have. Such a Standard would provide prescriptive detail that indicates the pieces needed to achieve process improvement and would not rely on prior knowledge, but with levels and measurements the potential to keep management interested. What is needed is a maturity model.
Maturing the Software Processes
Philip Crosby’s 1979 book Quality is Free included the first published quality maturity grid. The concept was that by assessing six key aspects of quality management on a five level scale of maturity, management could focus activity on maturing them. Organisational improvement could be managed. That underrated and underused standard AS/NZS ISO 9004: 2000 recognises the value of a scale of implementation, rather than the single-line pass and finish concept of ISO 9001. It includes a simple maturity scale as a way to get management attention and with ongoing improvement to keep it.
The good news for software management is completion of the fourth iteration of the AS/NZS ISO/IEC 15504 SPICE Standard, with the release of the exemplar model – Part 5. It is a process management Standard that implodes objectives into the specific needs of each process, therefore needing less quality knowledge to apply than ISO 9001, though it does help to know some basics. An organisation assesses its capability level, it can then reduce indicated risks in current work but more importantly it can use that same information for permanent process improvement.
There are five parts to 15504 as shown in Diagram 1 opposite which is copied from Part 1. The assessment process is described in Parts 2 and 3 and an assessment model in Part 5. Once complete, the assessment information can be used for capability determination and risk reduction, and process improvement, described in Part 4.
The SPICE Model
The 5 Part model is based on the software life-cycle processes documented in AS/NZS ISO/IEC 12207: 1995 and its two amendments in 2002 and 2004. The 12207 Standard is undergoing yet another change to improve some recognised weakness, but it is adequate for software development and maintenance. The previous three versions of ISO/IEC 15504 focused on these processes and were trialled on real organisations giving the Standard a solid practised strength. It is software generic, not aimed at large organisations or prescribed for any specific industry requirement and the process dimension does
not prescribe or require any specific life-cycle methodology.
Diagram 2 shows an overview of the two dimensional model as described in Parts 2 and 5. Each process is assessed separately, positive and negative findings noted and a capability level assigned. The SPICE model is a continuous model, not staged. Therefore there is no specific process implementation sequence and the model needs a level of knowledge to use, but any improvement sequence should be based on real organisational improvement needs, not a standard model sequence.
Where does all this fit with ISO 9001:2000? A potential problem of working on isolated processes is a possible process separation, a silo effect. Assessing the whole software area using ISO 9001 whenever significant change occurs or a maturity level is reached will ensure the processes work together, the management control and improvement loop is in place and the organisational vision and objectives are adjusted. As maturity levels increase, the growing knowledge of good practice will allow for better interpretation and perhaps an increasing interest in other quality principles, concepts and techniques.
Conclusion
There is a reported increase in the amount of money available for information technology, especially if it can provide product / service differentiation. The IT governance and ITIL service management attention of the past few years seems to be ebbing as management forget about Enron and Sarbanes-Oxley. Organisation differentiation used to mean an increase in internal software development or major maintenance enhancement. However if software development is seen as unruly, nearly always overrunning budgets or having major problems, the money may go into customised off-the-shelf solutions, new technology or new gizmos. If that happens it may begin a development recession and perhaps the industry will have to grow up. However the release of this SPICE Standard set may be opportune as a timely investment in understanding an organisation’s current capability level and a means to reduce the risk of failure and improve internal software processes.