Qualityworld

• Knowledge portal
• FAQs
• Information
• Qualityworld
  • Current issue
  • Editorial comment
  • Free Qualityworld
  • Past articles
  • Advertisers
  • Subscribe to Qualityworld
  • Advertise in Qualityworld
• Journal of Quality
• Jobs
• Press
• Links

Software quality: a process of maturity

Software, along with communications, is at the heart of business and industrial and social change in these early years of the 21st century. But can it get its act together when it comes to quality, asks Stephen Gibbens?

Since its birth in the early 1960s, the computer and its associated technologies have progressed to a point where they can be discussed with a large degree of common understanding. The internet and a burgeoning supply of digital and communication technologies are bringing about a sea change in society and its exposure to information via software and mobile computing devices.

This is not always a smooth transition. Witness the dot-com boom-bust cycle, and the current delay in take-up of broad-band, 3G and wireless telecommunications technology. Viewed over a ten-year cycle however, it is clear that the developments have been rapid.

Business-to-consumer interaction and email means commercial, government and postal transactions can be performed at home, work or through mobile transactions. Business-to-business integration represents a greater challenge, but promises to provide an infrastructure that can support global commerce and the seamless interplay of information and transactions between organisations. The ability to peer under organisational covers and access information quickly has the potential to lead to greater openness in society as well as fuelling business growth and commercial advantage.

The problem with software

The infrastructure required to underpin such highly responsive architectures requires a mix of extremely reliable hardware, always available, high-speed networks, along with top quality software. In general, most digital hardware devices and network architectures provide high levels of service and reliability. Unfortunately it is software which lets the side down when it comes to quality and reliability. This presents the greatest challenge in terms of bringing stable products and services to market.

In the early days of IT systems development, software and programming were regarded as black arts closely linked to the University Research Laboratory and exempt from the watchful eyes of any quality department. Any procedures for improving reliability were heavily based around debugging once the software had been written, and much of this happened post-implementation. Through the 1970s, 1980s and 1990s, the industry matured and developed techniques designed to eliminate faults earlier in the software development process. Eventually the focus shifted to prevention techniques and the removal of faults in all development lifecycle phases from concept through to implementation.

So, what is it about software that makes it so different and difficult? First, the design and development phases can be quite abstract in their nature. Second, software tends to be intractable. Finally, technological change moves at such a fast pace and there is an ever-increasing pressure to shorten market delivery time. This inevitably leads to difficulty in producing low defect levels, especially desirable in today's web-enabled business processes.

This is why fundamental quality principles can still be valuable. The quality profession depends on the application of tools and methods capable of delivering change within a business or organisation. This applies to software too.

The software quality armoury

So what do we have in a software quality tool-chest? Traditionally, testing has been the fundamental approach to fault detection, and this arguably remains true today. However, as the emphasis has moved from detection to prevention, additional practices - in types of testing, QA models, education etc - have been introduced (see figure 1).

The picture painted is of a profession functionally rich in the processes, tools and techniques required to apply quality management to a mature industry. Looking at the long list shown in figure 1, you could argue that there are too many quality processes and methods in software engineering. In reality, however, this richness allows greater choice in fitting the right tools to the job in hand. Can we now argue that software need no longer be regarded as something of a wild child in the quality industry?

Unfortunately not. Despite many successful projects, too many have failed and still fail in terms of timeliness, cost and quality. Many often cite 'lack of testing' as the reason for further work and injections of cash, but in reality there are many reasons why projects fail such as:

• early adoption failure
• delivering the wrong product
• high error rates
• lack of experienced staff
• lack of training
• risks not assessed/managed

Why do software projects fail?

It is not uncommon, when developing software, for costs and timescales to skyrocket. This means poor quality levels are not out of the ordinary, with many projects being canned and falling by the wayside. When this happens, it's no surprise that the software development industry presents a poor quality image.

Quality management processes often take time to develop, field-test and to become accepted. This is particularly true in the software industry where quality techniques are a newer phenomenon. Theoretical study needs the checks and balances of empirical practice and analysis before an overriding stamp of success can be applied to any new technique or process. This can lead to a lack of confidence in emerging quality measures. It is for this reason that many IT projects have suffered from a (sometimes healthy) scepticism between development and the implementation of good practice.

In software, all too often a 'just do it' mentality is adopted and it is easy to see why quality measures are often dismissed or forgotten. Integrating the three moving targets of technology, business and quality is not for the faint-hearted. Often it's a case of one step forwards and two steps back.

Getting the balance right

In striving to make the software development process successful when it comes to quality, there are some fundamental rules to follow which distinguish successful projects from unsuccessful ones.

Tailor the approach to the circumstances

The factors applied in determining an approach (such as application arena, usage patterns, intended life of software, level of fault tolerance in production use, user interface ergonomics and underlying software/hardware architecture) need to be appropriate to the type of software and its intended industrial, scientific or commercial use. Safety critical applications such as on-board aeronautics, military/defence applications or transport and traffic-control, will require different types and depths of measure than those for a system used purely internally for a company's own business purposes.

No 'one-fits-all' solution

The wrong measure applied dogmatically can cause as much harm as doing nothing at all. The benefits of a mix of techniques and procedures applied sensibly are greater than the sum of the parts.

Assess the situation

Whether this is done formally will depend on the size of projects and organisational objectives. For example, the Software Engineering Institute's (SEI) capability maturity model can be regarded as providing a formal set of improvement targets based on key process areas and high levels of assessment and audit at each stage or maturity level. Such an assessment approach allows benefit to be realised in understanding the current maturity level of the software development processes, leading to a programme of continuous process improvement.

But the effort required to implement and move through the stages is high. Whether this is justified will depend on the nature and type of the organisation, the projected return on investment and the requirements of the target marketplace. Other improvement frameworks such as ISO/IEC 15504 (SPICE), testing maturity model (TMM) and test process improvement (TPI), can assist the assessment/improvement process in varying degrees of formality, audit and cost.

Risk, return, and cost

The no-brainer here is the old adage: 'If it ain't broke, don't fix it'. Getting things right first time can have huge payback in terms of development time. Doing nothing in terms of QA is an option, but it brings its own risks and you need to be quite sure that good practice is in place and quality is assured. The flip side of the coin is: 'How do you know it ain't broke?'. So periodic statistical sampling applied over time may be required to measure the effectiveness of decisions made.

The process of balancing quality measures to software development lies at the heart of successful project execution. The underlying principle can be compared to the 'fit for purpose' school of quality management, applying strict measures only where the product or service being developed demands.

Juggling projects and people

Cost, quality, schedule and scope should be balanced as the project tightrope is walked. A large part of how successful this is will depend on managing resources correctly. Not just in terms of having enough trained resources, scheduling work, and hitting targets, but enabling the human interaction and cooperation between the fundamental groups of people at play:

• developers must understand the technology and make it work
• quality professionals must have an eye on the finished product and ensure that deliverables are fully tested, meet requirements and will work in the intended operational environment
• managers (line, project, user) must keep an eye on the needs of the business. In successful projects, despite the potential for disagreement and passing the buck that can go on between these groups, a sense of mutual responsibility is necessary to reap rewards
• software engineers may not be concerned with standard process, best practice or metrics and measurement. They probably have not heard or necessarily care to hear about CMM, ISO or code coverage measures

Quality and test engineers, well versed in good practice, know that there is empirical evidence that it will deliver cost and quality benefits, but they may be a little over-eager to enforce adoption. Managers under pressure to deliver value to the business, will leave technology to the developers, quality to the test manager, and may miss the opportunity to provide carrots or sticks just at the point when their support makes the crucial difference to software process improvement. Communicating and negotiating the correct measures of best practice will enable these groups to work together towards common goals.

What next?

The last 30 years have seen extensive growth and investment in software development. With the completion of year 2000 millennium work, the growth of the internet followed by contraction, dot-com failures and stock market jitters, there has been a distinct lack of confidence to push forward with new investment in IT.

The IT industry itself is partly to blame for this and lessons are being learnt. The next step in the economic and social development cycle will require digital technologies and software that meet their intended purpose dependably. It is not a question of having top-quality software all the time, but using top-quality processes and procedures.

Software development may be compared to other professions with a high need for quality techniques and processes. Project failures and quality issues exist in construction, transport, law and medicine, as in software. However, software will always have its own unique problems of intractability, abstraction layers and complexity. Thirty years of process refinement have developed a level of process knowledge and techniques hitherto unknown, which are capable of delivering the 'maturity level' your software development requires

Biography

Steve Gibbens is a test consultant at SIM Group Ltd, part of the Software Quality Systems AG group of companies, and has managed the development and QA of business software from positions within industry and the software services supply sector in the UK and abroad. He holds a postgraduate diploma from the Open University in computing for commerce and industry and recently attained the practitioner certificate in software testing from the British Computer Society. For further information go to www.simgroup.co.uk