The Capability Maturity Model

Transcription

1

2 The Capability Maturity Model Implementation and Risks Abstract Tracey Briscoe Many organizations today talk about striving to improve their software development processes. One common standard of measurement is the Capability Maturity Model (CMM) for an organization's handling of software development. The CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University [1]. The standard documentation for CMM is rather complex. This paper informally explains CMM's overall structure, and outlines some of the common pitfalls of CMM implementations. This paper focuses on CMM Levels 2 and 3, the levels of process maturity that organizations most often strive to reach. A lightning tour of CMM The CMM describes five levels of process maturity. Level 1 is the lowest level (improvement has not started). Level 5 is the highest. Each level above 1 sets Key Process Areas (KPAs) as targets. Most organizations are presently at Level 1. Improving your organization s maturity results in: reduced development time, reduced costs, more efficient use of resources. Evidence of CMM's value The promise of reducing cycle time and costs, and using resources more efficiently, sounds extremely attractive. Many executives, engineers, and managers are consequently jumping on to the SEI CMM bandwagon. Organizations have shown that moving from Level 1 to Level 3 of CMM lowers rework by up to 60 percent [2]. CMM Level 3 organizations claim to have achieved productivity gains from 200 to 300%. Leonard Putnam at Quantitative Tracey Briscoe Page

3 Software Management [3] presents evidence that suggests that payoffs from reaching Level 3 range from 70 to 100% per year. Maturity Level Calendar Months Effort(Person Months) Defects Found Defects Shipped Total Cost (Median Case) $5,440, $1,311, $728, $392, $146,000 Estimated Impact for 200,000 LOC Software Project ( Communique, Sematech) A 1997 paper by Steven Burke [4] of Carnegie Mellon University claims improvements of 215% in effort, 592% on schedule and 143% reduction of errors, for Level 5 versus Level 1 organizations. These may not apply in every case, and it is disputable whether any organization has a valid claim to be at Level 5. Burke points out that more important than actual numbers (because they will vary by organization) is the fact that the improvements are substantial. Statistics cited throughout the industry seem to mirror these numbers. Staying at Level 1, therefore, can be viewed as a large cost to an organization. That s why the CMM is gaining popularity each year. Structure of CMM The 5 Maturity Levels The five maturity levels are rather confusingly named Initial (Level 1), Repeatable (Level 2), Defined (Level 3), Managed (Level 4), and Optimized (Level 5). Of course, all Levels from 2 upwards involve defining and managing the organization's processes, and are to some degree optimized. Key Process Areas (KPAs) With the exception of Level 1, each CMM Level requires several Key Process Areas (KPAs). Each KPA sets several goals, describing key practices that help organizations to climb to the next CMM Level. These practices must become fixed habits within the organization's culture, followed even in times of crisis. KPA Tracey Briscoe Page

4 practices must be supported with an infrastructure of policies, tools, training, and standards. Otherwise, any improvements gained through implementing CMM will be temporary, or worse, never realized. Success through CMM Key ingredients for success are to: Commit to perform from the highest level of management down Define KPA policies Assign responsibilities for maintaining these policies Allocate adequate resources (staff, tools, and time) Give sufficient training Set realistic expectations Baseline process measurements before you start Measure control, process, and quality Verify that staff members are appropriately qualified and follow established procedures. CMM Level 1 - Initial Organizations at Level 1 are not necessarily chaotic or on the road to disaster. Almost 73 percent of organizations are operating at Level 1. Many are successful in terms of profitability, market share, and customer satisfaction. Other Level 1 organizations, though, are struggling with poor quality products, cost overruns, and non-productive staff. In 1996, IS project failures in the USA were estimated at $145 billion. 73 percent of projects were canceled, late, or over budget [6]. An organization operating at Level 1 does not always fail. But projects are less predictable, require more rework, and suffer more defects, schedule slippage and cost overruns. Level 1 organizations that are small, that can divide large projects into smaller pieces, or have plenty of wellqualified staff are more likely to be successful. In today s business environment, CMM Level 1 companies can grow quickly. But technology changes rapidly, growth brings organizational problems, and good staff are scarce. Better processes are becoming increasingly important. CMM Level 2 - Repeatable When an organization decides to take on the CMM challenge, Level 2 is usually the first level that is targeted. As with any project, the CMM effort should be carefully staffed. The project should be realistically scoped and planned with objectives set. The KPAs for Level 2 (Repeatable) are: Tracey Briscoe Page

5 Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management. Level 2 focuses on the activities that relate to planning, managing, and tracking these KPAs. Perhaps surprisingly, the standard software engineering tasks of analysis, design, coding, testing, and documentation are all included in a Level 3 KPA called Software Product Engineering. The KPAs and key practices for Level 2 should be used as the framework for devising the project s requirements and managing its progress. Walk before you run The idea of skipping from Level 1 to Level 3 may be tempting. While it s possible to work on improvements that are found in practices at higher levels, adhoc approaches make overall improvement difficult. Organizations often overlook the actual requirements for Level 2, and delve into the Software Product Engineering KPA, hoping to skip over planning directly to project work. This leads to cost overruns, poor scoping, incomplete requirements, and unsatisfactory end products. Disciplined project management plans allow an organization to start defining and documenting software engineering procedures. Once an organization is solidly at Level 2, individual project level processes can be rolled out across the organization. Only then can software engineering procedures be measured for effectiveness, improved upon, and ultimately defined for the organization as a whole. If the organization is crying for process guidance as it strives for Level 2, some guideline processes can be applied. In most cases, project managers will want to follow familiar processes. Trying to introduce too many changes into an organization at once is never a good idea. Therefore, it is important to try to narrow the focus of the CMM implementation to one level at a time. Tools and metrics Measurement is a key requirement at every maturity level from 2 upwards. For example, at Level 2, the organization should measure the status of each requirement, the effort spent on requirements management activities, and requirement stability. At the higher levels of maturity, metrics should monitor progress and measure process effectiveness. CMM does not require that any specific tools be used. It does not dictate how you perform the KPA. It only stipulates that your practices in each process Tracey Briscoe Page

6 area satisfy all of its goals. An organization can apply any methods or tools it finds effective. Although CMM does not dictate that any tool be used, an organization striving for Level 2 can benefit greatly from some of the tools on the market that help to automate the practices within the Key Process Areas. CMM Level 3 Defined As an organization moves from Level 2 to Level 3, the focus is on managing software activities based on a defined and documented standard process. All projects must use a documented and approved version of the organization s process for developing and maintaining software. The KPAs for Level 3 (Repeatable) are: Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Review. People often believe CMM Level 3 requires specific software development practices, tools, and methods. The CMM does not stipulate how to develop software or manage your company. It does require you to follow and document the processes you use, and ensure they are technically sound. The CMM key process areas define general areas of performance that must be satisfied to move to a higher maturity level, but they do not specify the methods and techniques to be used. The CMM does not dictate estimating algorithms, CASE Tools, requirements tools, development methodologies, or standards. Just as in Level 2, showing that your practices for each key process area are consistently applied and that they satisfy the goals of the KPA is the key to obtaining Level 3. Level 3 KPAs Level 3 requires standard processes throughout the organization. This does not mean that every project, no matter how large or small, must use the same process. The Level 3 KPAs, Organization Process Focus and Organization Process Definition require coordinating, defining, validating, and improving the standard processes. A common perception is that imposing a process adds bureaucracy and wasteful paperwork. Better processes should allow practitioners to apply the best available technical and managerial methods in a disciplined, efficient, and repeatable way. There are several ways to minimize bureaucracy: Tracey Briscoe Page

7 Involve key contributors to help develop or review your process; Make processes scalable; Do not burden simple projects with overly complex processes: use the CMM as a guide to what to include. If your organization decides to use a commercial method, it should be reviewed for completeness and scalability, and whether it will fit into your organization. New methods can seem to be more complex than they really are: small differences in presentation can hinder acceptance and adoption, unless you get key contributors involved in creating and reviewing new approaches. Involving contributors leads into the next KPA, Integrated Software Management. This KPA requires that the project s defined software process is a tailored version of the organization s standard software process and that the project follows its process. Training and tools are crucial to success. Not surprisingly, Training Program is the next KPA and consists of the following three goals: Training is planned. Training in software management and technical roles is provided. Software engineers are trained. The standard software engineering tasks of analysis, design, coding, testing, and documentation are all included in Level 3 KPA called Software Product Engineering. Its goals include making sure that: Software engineering tasks are defined, integrated, and consistently performed to produce the software. Software work products are kept consistent. Level 3 deals with gathering requirements from customers, organizing them, and tracing them to the products of the engineering activities. Having a process for requirements engineering will ensure that the goals of the Software Product Engineering KPA are met. The Intergroup Coordination KPA must also be met. The customer s requirements are fully agreed to by all affected groups, and verified. All issues and commitments must be identified, tracked, and resolved. The 1996 Standish Group 'Chaos' report [6] cited changing requirements as a major reason for project failure. Ensuring requirements are well written, agreed to by all parties, and tracked throughout the project lifecycle makes sense, whether or not an organization is striving for a CMM Level. A tool can simplify this activity, especially in large organizations with complex projects. The final KPA for Level 3 is Peer Reviews. The purpose of peer reviews is to remove software defects. The author s technical peers methodically examine the products. A written policy about peer reviews, resources, finding defects and Tracey Briscoe Page

8 training must be provided. Peer reviews should be included in project plans and procedures must be documented. In summary - some keys to success: The CMM is not a quick fix for short-term problems. Implementing the CMM takes time to incorporate new processes, procedures, and (most likely) tools. Establish a core group of experts to guide and ensure success. Start small with a few low risk, projects, staffed with good people. Communicate successes early and often. Ensure that top management is behind the effort. Remember that moving to Level 2 will take from 18 to 30 months. Be patient. If people perceive that the effort is just the flavor du jour, they will surely resist adopting it. Successful implementation of the CMM brings improvements in productivity, quality, and team morale. References: 1. The Capability Maturity Model: Guidelines for Improving the Software Process, by Carnegie Mellon University/Software Engineering Institute. 2. Humphrey,W., et al., Software Process Improvement at Hughes Aircraft, IEEE Software, 8, 4 (July 1991), pp Putnam, Lawrence, The Economic Value of Moving Up the SEI Scale, Managing System Development, July Burke, Steven Radical Improvements Require Radical Actions: Simulating a High-Maturity Software Organization, Software Engineering Institute, Carnegie Mellon University, June Hayes, Zubrow Moving On Up: Data and Experience Doing CMM Based Process Improvement, Software Engineering Institute, Carnegie Mellon University, August Standish Group International, Tracey Briscoe Page