Using Software Development Models and Standards

Sue Rule & P. Grant Rule, Software Measurement Services Ltd., www.smsexemplar.com

Limitations of models

IT is at the heart of an organisation, enabling and supporting everything the organisation does from HR, to product development to customer service. In many areas of industry and public service, IT no longer simply supports other parts of the organisation to develop products and serve customers, IT is integral to the product and the way customers interact with the business.

The challenge for IT professionals is to find effective ways of realising the full potential of technology-intensive business systems. Considerable know-how and experience has been accumulated over IT 50-year business history, and much has been invested in devising quality models and standards. However, many myths also abound, frequently created or promoted by parties with a vested interest in a particular model. Quality standards show you where to improve - but not how or why.

An evidence-driven approach should be taken to the adoption of standards and frameworks, as with every other business decision:

• Understand the model-maker’s purpose, and use the guidance provided in appropriate ways. It is guidance; not a rulebook.
• Focus on the outcome not the certificate. Compliance, or the attainment of certificates and interim targets, all too often becomes confused with true business goals. This is dysfunctional; meaning it is behaviour which detracts from overall business performance.
• There should always be a sound business case for adopting an improvement programme, defining clear business benefits and measurable outcomes.
• Measure progress and business results - not compliance to the model. If it matters, measure it. And if it doesn’t, don’t. It is possible to be effective and compliant, but only if effectiveness is the focus. A focus on compliance will not deliver improved effectiveness - or the associated business benefits of improved effectiveness.
• Communication is key to successful and sustainable improvement. Good measurement practices and short feedback loops are vital.

There are many bear-traps into which numerous well-intentioned improvement initiatives have disappeared without trace. Integrated team-working, responsibility-based performance management, and many other behaviours which support value focus, continuous flow, and pull, are often counter-intuitive, especially to staff used to operating in a compliance culture. Because 75-80% of organisations are ‘average’, achieving typically poor levels of performance, few people ever experience ‘high performance’ and do not realise there are better ways of doing things than those they are used to. To achieve real changes in effectiveness, most organisations will need a specialist guide whose experience goes beyond knowledge of the models themselves.

A prescriptive approach is not sufficient to move IT business role from cost centre to strategic enabler.

Used correctly models and standards can support continuous improvement in the quality of IT services, particularly in organisations starting from a very poor understanding of process performance. They support a more consistent and reliable service to business users, and potentially a more competitive business.

But the benefits all lie in correct implementation. If the focus is on compliance without understanding of the value stream, models can hinder effectiveness and efficiency, not improve it. If those using processes are not empowered to change or improve them, process performance is likely to be a constraint on high business performance. This is why the Agile Manifesto emphasises people over process. People are the creative intelligence of the technology-enabled value stream. They must be empowered to use their intelligence and creativity, not constrained to adapt to prescriptive, overly-bureaucratic processes.

Lean-Agile Systems

Lean service focus is about hearts and minds. It is a change of business culture and behaviours which has far greater impact on the value delivered to customers than any prescriptive process. An informed understanding and application of the principles of lean flow production goes to the heart of the organisation and touches everything the organisation does, including its IT infrastructure.

The modern principles of Lean Thinking are derived from the Toyota Lean Production System, but make use of found truths that can be traced back to ancient civilisations. Numerous historic examples show that two key concepts inform effective systems of work, and these concepts are encapsulated in modern Lean thinking as:

Just In Time: Creating an end-to-end system of production that is so in tune with customer demand it can produce the right product or service for its customers, at the right time, for the right price, first time, every time.

Jidoka: Designing-in quality rather than fixing failures. Jidoka implies that everyone engaged in the value stream is empowered to stop production rather than let sub-standard delivery be passed on to the next process step. (Contrast this concept with the exhaustive testing carried out on most software products.)

Lean workflow requires the organisation’s software products, and its processes for developing new software products, to be aligned to the delivery of stakeholder value. The products themselves must support a customer-focused service stream most effectively. Agile development methods lend themselves to achieving this alignment. They improve the dialogue between business users and developers, particularly in terms of the collaborative evolution of the software to fulfil real business requirements.

The key to Lean effectiveness however is to change the mindset of software developers to focus on delivering a Lean service. That is, being so in tune with the demands of their business customers that they produce the right product at the right time for the right price, first time, every time. This cannot be achieved without good communications between all the business stakeholders and the software development team, and this remains an issue for many organisations. For businesses at large to benefit fully from the flexibility and responsiveness of Agile development methods, an in-depth knowledge of how software product development delivers value to stakeholders is required. Only by applying such know-how to align the system of work can optimum value be delivered.

Agile methods are still regarded with suspicion by those responsible for corporate procurement and governance. Agile development teams need to recognise the role of process discipline in delivering value to all the business stakeholders. Process performance should be visible to all stakeholders, particularly in an outsourcing context where trust needs to be established between corporate partners.

The key to high performance in software intensive value streams is to create a Lean Service ethos in the workforce. Coupling good, end-to-end process management with Agile development methods significantly increases organisational effectiveness. The two working together have greater impact than either used alone. Success is delivered by people; failure is generally due to poor process.

Choosing a model

Models capture experience and knowledge that can be applied to develop new products and services, resolve new business issues, or address similar issues occurring in different organisations. Unfortunately, the mere act of capturing experience devalues it. It is rather like an archaeological artefact removed from its site. It is significantly the less without its context and provenance. It is therefore essential to interpret the knowledge contained in a model intelligently and adapt it to the business context in which it is being used.

Figure 1. Commercial drivers for the adoption of models and standards

Many models claim to encapsulate ‘best practice’, but experience shows that all models tend to encourage ‘batch and queue’ thinking, with the emphasis on projects rather than on service. This is counter to Lean flow thinking. It is another dysfunctional behaviour pattern.

A model contains only those features that are of primary importance to the model maker's purpose. When choosing a framework to offer guidance to your business, you should ensure you know enough about the model maker’s purpose to be confident that it is both applicable in your business environment; and flexible enough to facilitate the achievement of your business objectives.

Cultural obstacles such as ‘Not Invented Here’ syndrome, resistance to change, and change fatigue can influence decisions relating to the adoption of quality standards, but these should never be allowed to outweigh the business drive for improvement. All these issues can be overcome by engaging knowledgeable specialist support. It is simply a case of evaluating the risk of continuing ‘business as usual’ against the perceived cost of change.

Apart from the business benefits to be derived from improved process performance, there can also be over-riding legal and commercial factors in achieving certification against a recognised standard. Much of the interest in quality standards and frameworks has been driven by the rise in outsourced IT services.

By introducing commercial terms to the hand-off between the development team and the business user, the cost of poor process performance is made apparent. Customers seek to ensure good governance by stipulating the attainment of certain standards. Fig. 1 shows the typical break-point in communication between business users and providers of ICT services that models and standards are frequently invoked to address.

However, there are two problems with this approach:

1. Compliance with the model, rather than real improvement in process performance, becomes the goal.
2. Experience shows that process maturity will devolve to the lowest level extant in the end to end value chain; so if a customer with process maturity mapping to Level 1 of the CMMI© model engages with a supplier that has achieved Level 4, the overall maturity level of the supply chain will typically be Level 1.

In an outsourcing partnership, ‘Measures’ - including payments, incentives and contract terms - must be aligned to pull value through the end-to-end process. Measures imperfectly aligned to the creation of customer value incentivise dysfunctional behaviour which will not be addressed by a ‘tick-box’ compliance with a specified standard. An objective analysis of root causes will be more likely to identify performance issues in outsourcing relationships. Models may then form useful input to an action plan to address the issues identified.

Reality Check: Some Common Process Improvement Myths

MYTH

REALITY

The process must exactly reflect the model. Existing processes must be thrown away and replaced by model compliant processes. Process models require bureaucratic documentation. Process models expect all types of work to use the same process. Model based process development reduces budget available for projects. Model based process development means re-training all staff. Model based process development takes a long time to return the investment. Model based process development is a "one-off" task. Models embody ‘best practice’ Models require a ‘big design up front’ approach

Models suggest goals and expectations which can be met in many different ways. Models just provide a means of comparing processes with experience-based good practice. Models expect certain key things to be documented, but allow a low level of formality where appropriate. Models expect a set of processes to be available, covering the range of work types in the organisation. Successful process improvement reduces waste, making more budget available for development. Since the model is NOT the process, the skills and training needed for most staff will be essentially unchanged The time taken to return the investment depends on improvement prioritisation choices, not the model. Improvement is always possible. Continuous improvement delivers benefit continuously.

Failure to realise benefit from models and standards typically occurs not because of the model itself but because of poor management of knowledge and people. Good ideas and good practices may not be consistently applied across the organisation, contributing to a corporate inability to maximise the potential of its people. This can result in loss of skills and capability within the organisation, particularly a loss of innovative thinkers and value-creators, which compounds the problem.

The most common reasons for the failure to deliver benefits from improvement based on the adoption of quality models and standards include:

• lack of clear business objectives
• failure to engage effectively the creative, customer-facing and operations staff
• lack of appropriate skills and resources - and failure to develop capability
• lack of leadership and senior management engagement
• inconsistent decision-making, direction and communication
• inability to integrate and align multiple initiatives

Models and Standards: Model-Maker’s Purpose

Understanding the model-maker’s purpose is a first step towards intelligent application of the framework. The following section describes a selection of commonly used models. It is compiled from a UK perspective, and does not claim to be a comprehensive list of all the models and standards in use.

CMMI© Capability Maturity Model Integration

Web site: http://www.sei.cmu.edu/cmmi/tools/index.cfm

The Software Engineering Institute’s Capability Maturity Model Integration (CMMI) has become established as a leading process performance model, particularly in software development. CMMI-DEV belongs to a suite of CMMI models which have many similarities and complement each other. See the Software Engineering Institute (SEI) website for details of what each model covers and the associated training and appraisal programmes.

CMMI for Acquisition

Designed for clients of software service suppliers that want to improve their ability to select and manage outsourced IT suppliers.

CMMI for Development

Designed for development organizations that want to improve their ability to develop software-intensive products and services.

CMMI for Services

The most recently developed CMMI model is designed to support a better organisational ability to establish, manage, and deliver ICT services.

People CMMI

The People CMMI model was also developed by the SEI, although it does not form part of the CMMI Product Suite. The People CMMI is a maturity framework that describes the key elements of managing and developing the workforce of an organization. It is designed to evaluate progress from an ad hoc approach to managing people, to a mature, disciplined development of the knowledge, skills, and motivation of the workforce. The People CMMI appraisal method can be used alone or integrated with an existing process appraisal method.

COBIT Control Objectives for Information and Related Technology

Web site: http://www.isaca.org

COBIT is a framework for IT governance, control and risk management. The supporting toolset seeks to bridge the gap between control requirements, technical issues and business risks. COBIT emphasizes regulatory compliance, but it is not an audit methodology itself. It is used by organisations to reduce waste and improve assurance of value in ICT investment.

ISO Standards

Web site http://www.iso.org

ISO 20000

ISO 20000 is the global standard for IT service management. The ISO/IEC 20000 series helps service providers - large or small - to understand how to enhance the quality of service delivered to their customers, both internal and external.

The ISO/IEC 20000 series separates process performance from organizational form, size, names or structures, allowing good practices to be shared across market sectors.

ISO/IEC 27000:2009 Information Security Management Systems

ISO/IEC 27000:2009 provides an overview of information security management systems (ISMS) family of standards, and defines related terms. As a result of implementing ISO/IEC 27000:2009, all types of organization (e.g. commercial enterprises, government agencies and non-profit organizations) are expected to obtain:

1. an overview of the ISMS family of standards;
2. an introduction to information security management systems (ISMS);
3. a brief description of the Plan-Do-Check-Act (PDCA) process; and
4. an understanding of terms and definitions in use throughout the ISMS family of standards.

ISO9000 ISO 9000 Quality Management System

The BS EN ISO 9000 family of standards describes the fundamentals of quality management systems (QMS) and defines related terms. It sets standards of quality management regarding all the features of a product (or service) which are required by the customer.

This International Standard is applicable to the following:

1. organizations seeking advantage through the implementation of a quality management system
2. organizations seeking confidence from their suppliers that their product requirements will be satisfied
3. users of the products
4. those concerned with a mutual understanding of the terminology used in quality management (e.g. suppliers, customers, regulators)
5. those internal or external to the organization who assess the quality management system or audit it for conformity to the requirements of ISO 9001 (e.g. auditors, regulators, certification/registration bodies)
6. those internal or external to the organization who give advice or training on the quality management system appropriate to that organization
7. developers of related standards.

ISO/IEC 12207:2008 Software Life Cycle Processes

ISO/IEC 12207:2008 establishes a common framework for software lifecycle processes whether these are performed internally or externally to an organisation. It contains processes, activities, and tasks that are to be applied:

1. during the acquisition of a software product or service
2. during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.
3. to the acquisition of systems and software products and services
4. to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system. Those aspects of system definition needed to provide the context for software products and services are included.

ISO/IEC 15504 SPICE Software Process Improvement and Capability Evaluation

ISO/IEC 15504 also known as SPICE is a set of technical standards documents for the computer software development process and related business management functions. ISO/IEC 15504 initially was derived from process lifecycle standard ISO 12207 and from maturity models like Bootstrap, Trillium and the Capability Maturity Model (CMMÒ ).

The first versions of the standard focused exclusively on software development processes. This was expanded to cover all related processes in a software business, for example, project management, configuration management, quality assurance, and so on. The list of processes covered, grew to cover six business areas:

1. Organizational
2. Management
3. Engineering
4. Acquisition supply
5. Support
6. Operations

In a major revision to the draft standard in 2004, the integral process reference model was removed and it is now related to the ISO 12207 (Software Lifecycle Processes). The issued standard now specifies the measurement framework and can use different process reference models. There are five general and industry models in use.

Automotive SPICE

The Automotive Special Interest Group, a joint special interest group of The SPICE User Group and The Procurement Forum, created the Automotive SPICE® initiative together with the major motor vehicle manufacturers. The intention was to develop a common framework for the assessment of suppliers in the Automotive Industry. The model is described in the publication, ‘Automotive SPICE® Process Assessment Model’ and the associated Process Reference Model.

ITIL Information Technology Infrastructure Library

Web site: http://www.itil-officialsite.com/

ITIL provides a practical framework for identifying, planning, delivering and supporting IT services to the business. It has been adopted by thousands of organisations worldwide, such as NASA, the UK National Health Service (NHS), HSBC bank and Disney™.

ITIL is a framework; an organisation cannot be certified to ITIL. However, a comprehensive qualifications scheme has been developed, supported by a wide range of service providers including examination institutes, accredited training providers and consultancies, software and tool vendors. This scheme can help organisations ensure that employees have the relevant knowledge, skills and techniques to use ITIL effectively, and that the entire organisation is using a common language.

ITIL practices also underpin the foundations of ISO/IEC 20000 (previously BS15000), the International Service Management Standard for organisational certification and compliance. Organisations can therefore implement ITIL to achieve organisational certification with respect to ISO/IEC20000 (see above).

PRINCE2 PRojects IN Controlled Environments 2

Web site: http://www.prince2.com/

PRINCE2 is a structured project management method developed by the UK Government Central Computer and Telecommunications Agency (since renamed Office of Government Commerce). It has become widely adopted both for IT and non-IT projects. There is a defined PRINCE training programme delivering certification at Foundation and Practitioner level. Organisations frequently require individuals fulfilling a project management role to have PRINCE certification.

Correctly applied, PRINCE can be an invaluable guide to good project management practice. However, its focus on a product-based planning approach makes it a blunt instrument which must be used with care to avoid encouraging inefficient and ineffective behaviour.

Scrum

Web site: http://www.scrumalliance.org

Scrum is a framework developed to offer guidance on more flexible and responsive ways of managing workflow. It supports cross-functional, self-organising teams who have no use for bureaucratic project management processes. In small, co-located teams, Scrum has a proven track record of success. Building on this success to improve workflow management in a wider context is work-in-progress.

Scrum contains sets of practices and predefined roles, the key ones being: Scrum-master; Product Owner; and Team Member. There is a defined training programme for the Scrum-master role, but it is frequently the case that the crucial role of Product Owner is given less weight and authority. The Product Owner is responsible for representing the interests of the business stakeholders. These stakeholders provide the ‘pull’ which keeps the Scrum team focused on delivering customer value. If this pull is absent, Scrum will tend to encourage local optimisation at the expense of end-to-end effectiveness.

Six Sigma

It is debatable whether Six Sigma should really be classed as a ‘model’ or ‘standard’, but its use is widespread and it is therefore included for completeness. The Wikipedia entry for Six Sigma reads: ‘Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes. It uses a set of quality management methods, including statistical methods, and creates a special infrastructure of people within the organization (‘Black Belts’, ‘Green Belts’, etc.) who are experts in these methods.’

Six Sigma is frequently coupled with Lean, to indicate a focus on quality and cost reduction through removal of waste. However, the underlying principles of Lean customer focus and designed-in quality should remain paramount to drive through the benefits of a true Lean transformation. Too narrow a focus results in local optimisation, which can have a negative impact on end-to-end effectiveness

The Six Sigma business management strategy was originally developed by Motorola, USA in 1986. As it is derived from manufacturing, where the ability to reproduce items without variation is critical, its applicability to software-intensive systems is questioned by advocates of the integrated Lean-Agile value stream. Software is increasingly recognised as a business service, and the ability to respond rapidly to highly varied and changing user requirements, to innovate, to add or change functionality, is an essential attribute for many software developers.

TMMI The Test Maturity Model Integration

Web site: http://www.tmmifoundation.org/

Because software development has traditionally sought to ‘test in’ quality rather than ‘design in’ quality, testing has become a significant part of the process. The Test Maturity Model Integration has been developed to provide a process maturity standard against which testing processes and practices can be measured. It was specifically designed to complement the existing CMMI framework, and assessment includes compliance with the relevant ISO Standard 15504. The TMMi is managed by an independent TMMi Foundation

TickIT

Web site: http://www.tickitplus.org/

The TickIT scheme has existed since the early 1990s to provide guidance on the interpretation of ISO 9001 quality management. TickITplus was launched in 2011 by the British Standards Institute’s Joint TickIT Industry Steering Committee in response to the changes in today’s world of software development. It is intended to offer a flexible, multi-level approach to IT quality and certification assessment and can be applied at whatever level is deemed appropriate to the maturity of the organization and the needs of its customers. If multiple IT standards need to be addressed, these can be covered under one certification arrangement.

© SMS 2011.

Acknowledgements to:

Grant Rule, SMS Exemplar Group

Roger Gamage, CPIS Ltd. http://www.cpisltd.co.uk

Jill Pritchet, JFP Consulting

SEI http://www.sei.cmu.edu

International Standards Organisation (ISO) http://www.iso.org/

Wikipedia

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2011 issue of Methods & Tools