CIOZone.com - Professional Network for CIOs and IT Professionals

Dr. Bill Curtis, Director, Consortium for IT Software Quality (CISQ) and the co-author of Capability Maturity Model (CMM), in an email interview with Geetaj Channana, talks about the need for standards in software development.

A: By the mid-1980s most large projects that involved software were late, over-budget and defective.  Although most organisations were focusing on better tools and methods or hiring better programmers, Watts Humphrey, who joined the Software Engineering Institute (SEI) after retiring from IBM, focused instead on improving software development processes.

His critical insight in developing the Process Maturity Framework, the foundation for CMM, CMMI and the People CMM, was that no improvement program could succeed if developers were given unachievable commitments or baselines were not controlled.

Thus, rather than focusing on organisation-wide processes, he first focused on stabilising projects by developing the skills of project managers to plan and manage their projects. Only after projects were stable did he address standardised organisational processes and quantitative project management. This critical insight was a departure from existing models of improvement and led to the impressive success of the various staged maturity models built on his foundation.

Watts asked me to replace him as Director of the Software Process Program at SEI in 1991.  We took his framework, and all the best software practices the SEI had been collecting, and integrated them into the original CMM. Unfortunately the Systems Engineering world built their own maturity model using different architecture and it was difficult to integrate improvement programs in large systems organisations when they were driven by different approaches.

Around the turn of the century, CMMi was developed to integrate these different approaches into one model that could apply to any domain of engineering integrated into a large systems development project. I proved the applicability of Humphrey’s Process Maturity Framework to domains other than engineering projects by developing the People CMM for improving the capability of an organisation’s workforce.

A: CMM and its successor CMMi have been adopted globally. CMMi is especially relevant to enterprises building large software-intensive systems. It remains the only comprehensive model available for guiding the improvement of software and system development organisations. It is often used in conjunction with other models such as ITIL or COBIT at the enterprise level to supplement their lack of depth in software development.

Perhaps the biggest shortcomings of CMMi are its limitations in IT. CMMi was developed primarily by software and systems engineers from large aerospace projects with little experience in IT. It does not present practices such as portfolio management, shared resources and application deployment that are critical to executives managing IT applications.

Many organisations, especially smaller ones, find the number of practices challenging, especially the large number of repetitious institutionalisation practices.  Hopefully some of these issues will be addressed in upcoming revisions. Though, CMMi has a published record of successful implementations.

A: There are three key differences between the CMMi and Six Sigma:

• CMMi is a staged process improvement model and Six Sigma is a process improvement tool bag
• CMMi applies to a specific domain (software and system engineering), Six Sigma tools can be applied to any domain, and
• CMMi specifies process areas that must be addressed within its domain while Six Sigma focuses on the performance of processes as implemented without recommending specific best practices.

Nevertheless, both Six Sigma and CMMi share the same heritage, they emerged from the quality practices pioneered by Walter Shewhart and his protégé W. Edwards Deming.

Watts Humphrey once told me he was trying to figure out how to get software organisations to adopt the same statistical quality management and continuous improvement practices that he had seen work so effectively in other parts of industry. As I mentioned earlier, his critical insight was that he had to eliminate the problems that hindered their adoption, the first of which was poor project management.

His Process Maturity Framework emerged as a staged improvement strategy that eliminates the barriers to continuous improvement through a staged transformation of the organisation’s processes. While some Six Sigma practices can be implemented at each maturity level, CMMi Level 4 is the full implementation of statistical process management, while CMMi Level 5 is a full implementation of plan-do-check-act based improvement and innovation.

A: There is a growing sense of unease about the cost and about the risk of the software being developed and acquired by IT organisations. CISQ was formed to create industry standard measures of software size and quality for use in benchmarking, guiding internal development and evaluating the software delivered by outsourcers and package vendors.

These measures must be defined to a level that can be automated in order to reduce the cost and subjectivity experienced with current measures such as Function Points. The following factors explain the rationale behind CISQ:

• IT applications are deeply embedded in most critical operations.
• The current quality of IT application software exposes businesses and government agencies to unacceptable levels of risk and loss.
• Customers and providers of IT application software do not have a common basis for measuring, managing and evaluating the quality of the application software they deliver or maintain.
• IT executives need objective benchmarks of IT application quality based on industry standards and professionally-credentialed assessment services.
• Businesses, government agencies and their software providers need a forceful, open and objective voice to establish industry-standard metrics for measuring IT software quality and drive an industry-wide agenda for improving IT application quality.

Major industry players such as GM, AXA, US Department of Homeland Security, IBM, Capgemini and Tata Consultancy Services (TCS) are driving this forward to ensure the standard can and will be applied in practice. In fact, TCS became the first member. CISQ supplements CMMi by providing the automated quality measures needed in a mature development process.

A: CISQ provides a neutral forum for all stakeholders in the IT industry to develop standard, automated measures of software quality. Measures will not be adopted into standard practice until they are automated, because of the prohibitive cost of collecting and reporting measures manually.

If we can get product measurement to be a standard application development practice, weaknesses in software will be detected long before they become expensive defects that cause outages, security breaches, corrupted data and degraded performance. To support this objective, CISQ will:

1. Advise, educate and advocate to business and government leaders on the mission critical importance of IT application quality.

2. Develop a consistent quality measurement system that can be used by IT and business leaders to measure and report the software quality of multi-tier business apps.

3. Define methods and processes for using this quality measurement system in negotiating and managing the acquisition, development, or maintenance of IT application software.

4. Develop and promote professional licensing for those providing services to assess the quality of IT application software.

5. Promote the development of a market of competing technologies that provide automated source code measurement and analysis.

A: CISQ is an industry-led forum sponsored by SEI, the Object Management Group (OMG) and supported by NASSCOM in India. Indian outsourcers are beginning to see software quality measures written into outsourcing contracts as the equivalent of Service Level Agreements. If each customer uses a different defnition for a quality measure, an outsourcer may be faced with 50 different defnitions of the same quality characteristic.

If there is a standard measure used across customers, it is much easier for an outsourcer to train their people, develop appropriate methods and tools and manage their relationships. The alternative is a nightmare of expensive special adjustments for each different customer with no economy of scale in using measures to manage the delivery of software.

A: Automating standard measures of application size and quality dramatically reduce the cost and increase the adoption of software measures. Automated quality measures allow weaknesses in the software to be detected much earlier when they are 10 times cheaper to fix.

When presented with objective measures on the quality of their work, application development teams learn much quicker and eliminate various types of defects in their work. Standard measures have also proven to reduce the time spent arguing in customer supplier relationships over what was expected versus what was delivered, thus reducing the overhead while improving the quality of acquired software.  

Of even greater importance than reducing IT costs are the business benefits of improved application quality. The cost of a retail website outage during peak business hours, of a security breach that compromises the confidential information of thousands of customers, or of the degraded productivity from slow application performance across 1000 white collar workers has harmful financial impacts on the business. Just as important, but harder to cost, is the competitive benefit from earlier releases of application enhancements because the application is easier to modify and test.

A: There are two ways to hinder creativity and innovation in an organisation when implementing a standard. The first is to do a sloppy job of implementing practices so that no benefit is achieved and the problems hindering creativity and innovation do not change. The second way is to implement a thoughtless, bureaucratic mountain of practices that get in the way of everything.

If an organisation uses the principles of lean thinking while implementing their improvements and understands the intent of the model, they should see impressive growth in opportunities for creativity and innovation.

For instance, what really reduces the level of innovation in an organisation is that people are fighting too many chaotic fires and do not have the time to pursue creative solutions. This is the case in most immature software organisations at CMMi Level 1. Once they begin to mature and get control of how they spend their time, they can build the time into a project required for exploring alternative solutions and building experimental prototypes.

We have seen this transformation in many organisations. CMMi Level 5 is a state of continuous search for innovative solutions that close the gap between an organisation’s current capability, and the capability they require to achieve the strategic business objectives. When the standard software measures that CISQ will develop are used to guide learning and product improvement, they will have this same impact on creativity and innovation.

Cross posted by the CTO Forum and Infosec Island