Software Quality David Jones, Director

2 Agenda What is it and why is it important? How do we deliver it? Conclusions

3 Why is Software Quality Important? Software Quality should be an inherent part of developing a solution. If not taken seriously, a lack of quality can impact: –User perception and confidence. –Cost (before and after rollout). –Company brand/image. –Market share. –Customer retention.

4 What do we mean by Software Quality? Hard to define – there are as many perceptions of Quality as there are individuals. The IT press/literature and even research papers are inconsistent in the use of the term “Quality”: –Fewer defects? –Quick testing and acceptance? The ISO 8402 definition of Quality: Note the distinction between stated and implied needs. “The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.”

5 What do we mean by Software Quality? Having the best technical designers and developers does not guarantee Software Quality It is a big assumption to expect the designers and developers to identify and deliver consistently all of the implied needs. This is especially true when the needs (stated/implied) do not relate solely to functionality: –Corporate Standards. –Non Functional. –Production. –Live Support. Meeting these needs can impact almost any area of the project and often more than one area at a time. So any method for ensuring Software Quality needs to be wider than just development and design.

6 What do we mean by Software Quality? To deliver high quality software, quality needs to be built into all stages of the programme/project lifecycle: –Business objectives. –Requirements analysis and design. –Technical design. –Testing etc. The goal is to have a method in place that allows Software Quality to be a core part of the project from its inception. –The later you identify a problem…the more it costs to fix it!

7 How do we deliver Software Quality? It’s obvious……isn’t it? –Preventative measures: Stop problems before they even start. –Detective measures: As soon as a problem occurs make sure you know about it. –Traceability throughout: Having a clear understanding of how business objectives flow through to requirements, through to technical design, system tests etc. –Architecture: Transparent design and clear ownership of design decisions to understand how you got to where you are. If it is so obvious, why is it often hard for management to take Quality seriously? –Solving problems is an activity with very high visibility. –Preventing problems isn’t! –It feels like a cost with no return.

8 How do we deliver Software Quality? In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skilled healer. He replied: "I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords." "My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbours." "My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."

9 How do we deliver Software Quality: Preventative Measures Clear business objectives. Robust requirements analysis. Transparent requirements management process. Accurate specifications. Best-practice design. Supporting standards and guidelines. Prototyping. Document reviews. Inspections and/or peer reviews. Unit testing.

10 How do we deliver Software Quality: Detective Measures Integration testing. System testing. Usability testing. Performance and volume testing. Resilience and recoverability testing. Internal tester training. Cutover testing. Production testing. Having traceability from business objectives through to test phases ensures that: –The correct things are being developed and tested (and delivered). –Everyone understand which needs (stated/implied) are being met (and those that are not).

11 How do we deliver Software Quality: Architecture Take an Architected approach Architecture is an overused term, but in this context it really means having a joined up, coherent approach to the solution, that considers: –Project/programme objectives. –Business Requirements. –Functional and Technical Design. –Infrastructure/Platform Design. –Test Strategy. A group such as a Solution Architecture Team can support this through having a vision and understanding for the solution that is a reference point for the project team. By having a view across the solution the Solution Architecture Team can spot problems before they occur and ensure Software Quality. This is a content forum not a management forum – this team usually own the solution and all related design decisions.

12 How do we deliver Software Quality: Architecture Example: Large solution with two key components: a package and a custom build element. Both components had a view of customer, however the developers on the custom side had not considered the intractability of the customer definition on the package side. This was causing a considerable problem for integration, and a challenge for quality due to the complexity and risk involved. Solution Architecture Team were able to resolve the problem such that a common definition, that was agreed by the customer and implementable across the whole solution was defined.

13 How do we deliver Software Quality – Conclusions Ensuring Software Quality should not be viewed as an overhead. –It is a key part of ensuring that a solution is delivered to time, to budget and to the customer’s expectations. Ensure the programme/project approach includes provision for Software Quality. –This includes providing an appropriate programme/project budget for these activities Focus on both preventive and detective activities. –The earlier you find a problem, the simpler and cheaper it is to fix. Ensure the whole team know their responsibilities and accountabilities. –Software Quality is the responsibility of all, not just the design and development team. Use an Architected approach. –This ensures that consideration is given to the whole problem not just the different components.