The Capability Maturity Model

Similar documents
Rational Software White Paper TP 174

SWEN 256 Software Process & Project Management

Applying the Personal Software Process (PSP) sm with Ada

CITS5501 Software Testing and Quality Assurance Standards and quality control systems

Reducing Estimating Errors with the CMM Raymond L. Kile 26 October 2000

Introduction To The The Software Engineering Institute s Capability Maturity Model for Software

Quality Management with CMMI for Development v.1.3 (2013)

Achieving Business Analysis Excellence

1.264 Lecture 5 System Process: CMMI, ISO

MEASURING PROCESS CAPABILITY VERSUS ORGANIZATIONAL PROCESS MATURITY

Quality Management of Software and Systems: Software Process Assessments

STUDIES OF SOFTWARE PROCESS IMPROVEMENT. Summarized by Neal Coulter Updated April 15, 2003

Chapter 6. Software Quality Management & Estimation

SOFTWARE MEASUREMENT GUIDEBOOK. Revision 1

Capability Maturity Model the most extensively used model in the software establishments

New Acronym Alert: BACOE! Why Create A Business Analyst Center of Excellence. Sherry Pate, PMP, EBAC

Capability Maturity Model for Software (SW-CMM )

Achieving SA-CMM Maturity Level A DoD Acquisition Management Experience

6. Capability Maturity Method (CMM)

Continuous Process Improvement - Why Wait Till Level 5?

Measurement for Maturity and Process Improvement Using DataDrill EXPRESS

Capability Maturity Model

Using Pilots to Assess the Value and Approach of CMMI Implementation

Measurement in Higher Maturity Organizations: What s Different and What s Not?

Independent Verification and Validation (IV&V)

How The HP-UX Systems Networking and Security Lab Assures Quality for Release 11i v2

10 Myths of Rapid Software Development. Construx Delivering Software Project Success

IT Service CMM Questionnaire

THE FUTURE CONTENTS. Software Testing

Software Project Management Sixth Edition. Chapter Software process quality

Lessons Learned in Seamless Integration of CMMI, TSP, and PSP Why All Three Are Needed. CMMI Technology Conference November 14, 2007

Information Technology Project Management Fifth Edition

Auditable Security Controls Of Best In Class Security and IT Operations Organizations: What Do They Do And How Do They Do It?

A Software Metrics Primer

Chapter 14: Project and Process Learning and Maturity

Measuring Performance: Evidence about the Results of CMMI

Intro & Executive Summary

Software Engineering Inspection Models Continued

Practical Process Improvement: the Journey and Benefits

Process Improvement Proposals (PIPs) Organization, Team, Individual

A Practical Guide to Implementing Levels 4 and 5

1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General

Tailoring CMM to a Process Improvement Project

Assessment Results using the Software Maintenance Maturity Model (S 3m )

Understanding Model Representations and Levels: What Do They Mean?

Measurement and Analysis: What Can and Does Go Wrong?

High Maturity/Capability Appraisals

Transactions on Information and Communications Technologies vol 11, 1995 WIT Press, ISSN

reasons to invest in a CMMS

Contents. Preface. Acknowledgments. Tables and Figures

T13 TOOLS OF THE TRADE: HOW TO AUTOMATE A SOFTWARE REPOSITORY. James Heires Rockwell Collins, Inc. Presentation Paper Bio

National Association of State Information Resource Executives

9/24/2011 Sof o tw t a w re e P roc o e c s e s s s Mo M d o e d l e s l 1 Wh W a h t t i s i s a Pr P oc o ess s 2 1

NDIA Systems Engineering Division. November in partnership with: Software Engineering Institute Carnegie Mellon University

Process Improvement Is Continuous Improvement

Human Performance Improvement: Who Says We Can t Measure Ourselves? Sheila P. Dennis, CFPS VP, David Consulting Group Malvern, PA

Agile Development Doesn t Have to Mean Fragile Enterprise Processes

Systems Engineering Concept

Software Development Life Cycle QA&Testing. January 2014 Alain Chacun all rights reserved 1

Choosing Delivery Method

FAA s Experience with Process Improvement & Measurements

Eight ways to alleviate the complexities of policy and procedure management with document control.

Relationships Between the Systems Engineering Capability Maturity Model SM and Other Products, Version 1.0

CMM and CMMI : Show Me the Value!

Personal Software Process SM for Engineers: Part I

ACHIEVE BUSINESS SUCCESS WITH ACCURATE SOFTWARE PLANNING

Software process improvement (SPI) has been

Incorporating the Personal Software Process into the Rational Unified Process

WHITE PAPER. Standardization in HP ALM Environments. Tuomas Leppilampi & Shir Goldberg.

Fast Track Your CMMI Initiative with Better Estimation Practices

A Software Metrics Primer 1

6 STEPS TO PERFORMANCE MANAGEMENT BEST PRACTICES A PRACTICAL GUIDE

Common Myths and Best Practices. By Gr e g o r y A. Ga r r e t t

Finding PLM to Fit Midsized High-Tech Companies By : Jim Brown President Tech-Clarity

White Paper. Driving Efficiency through Test Life Cycle Metrics

2008 ERP REPORT. CONTACT: Panorama Consulting Group Part One in a Series

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management

The Impact of Capability Maturity Model Integration on Return on Investment in IT Industry: An Exploratory Case Study

CAPABILITY MATURITY MODEL INTEGRATION - CMMI. Software Engineering Competence Center

Software Engineering. Lecture 2: The Personal Software Process

Keys to Narrowing Business Continuity Planning Gaps: Training, Testing & Audits

WHAT S THE SECRET TO CMMS SUCCESS?

Bootstrapping Process Improvement Metrics: CMMI Level 4 Process Improvement Metrics in a Level 3 World

Case Study. Effort = (Size X Complexity) Productivity. A Case for Software Estimation

The Basics of ITIL Help Desk for SMB s

Linda Carrington, Wessex Commercial Solutions

PPM Assessment. Analyze Your PPM Practices In-Depth for Systematic Improvement

How to Create a Salesforce Roadmap to Grow Your Business for the Future Build a Plan that Supercharges Salesforce for Maximum Value

A Business Case for Software Process Improvement

In this Part 6 we will cover:

PROJECT MANAGEMENT OVERVIEW

Software technology 3. Process improvement models. BSc Course Dr. Katalin Balla

Project Management Maturity Model (PMMM) in educational organizations

The Mystery Behind Project Management Metrics. Reed Shell Blue Hippo Consulting

A Proven Approach to Requirements Engineering

Managing Conflict, Politics, and Negotiation

Viewpoint Adopt a service orientation

INCREASING PRODUCTIVITY THROUGH THE CMM

The Victim Trap. The TSP Symposium September 23, Watts S. Humphrey and The Software Engineering Institute Carnegie Mellon University

Types of Process Methodologies

Transcription:

www.telelogic.com

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 2 03-11-99

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) 1 29.8 593.5 1348 61 $5,440,000 2 18.5 143.0 328 12 $1,311,000 3 15.2 79.5 182 7 $728,000 4 12.5 42.8 97 5 $392,000 5 9.0 16.0 37 1 $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 3 03-11-99

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 4 03-11-99

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 5 03-11-99

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 6 03-11-99

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 7 03-11-99

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. 11-23. 3. Putnam, Lawrence, The Economic Value of Moving Up the SEI Scale, Managing System Development, July 1994 4. Burke, Steven Radical Improvements Require Radical Actions: Simulating a High-Maturity Software Organization, Software Engineering Institute, Carnegie Mellon University, June 1997 5. Hayes, Zubrow Moving On Up: Data and Experience Doing CMM Based Process Improvement, Software Engineering Institute, Carnegie Mellon University, August 1995 6. Standish Group International, http://www.standishgroup.com, 1996 Tracey Briscoe Page 8 03-11-99