Capability Maturity Model (CMM)


The Capability Maturity Model Integration[3] for Software (CMMI) is an industry-standard model for defining and measuring the maturity of a software company's development process and for providing direction on what they can do to improve their software quality. It was developed by the software development community along with the Software Engineering Institute (SEI) and Carnegie Mellon University, under direction of the U.S. Department of Defense.

[3] CMM, Capability Maturity Model, CMMI, Capability Maturity Model Integration, and Carnegie Mellon are registered in the U.S. Patent and Trademark Office.

What makes CMMI special is that it's generic and applies equally well to any size software companyfrom the largest software company in the world to the single-person consultant. Its five levels (see Figure 21.5) provide a simple means to assess a company's software development maturity and determine the key practices they could adopt to move up to the next level of maturity.

Figure 21.5. The Software Capability Maturity Model is used to assess a software company's maturity at software development.


As you read on and learn what each of the five levels entails, think about the following: If you take the entire universe of software companies today, most are at Maturity Level 1, many are at Maturity Level 2, fewer are at Maturity Level 3, a handful are at Maturity Level 4, and an elite few are at Maturity Level 5. Here are descriptions of the five CMMI Maturity Levels:

  • Level 1: Initial. The software development processes at this level are ad hoc and often chaotic. The project's success depends on heroes and luck. There are no general practices for planning, monitoring, or controlling the process. It's impossible to predict the time and cost to develop the software. The test process is just as ad hoc as the rest of the process.

  • Level 2: Repeatable. This maturity level is best described as project-level thinking. Basic project management processes are in place to track the cost, schedule, functionality, and quality of the project. Lessons learned from previous similar projects are applied. There's a sense of discipline. Basic software testing practices, such as test plans and test cases, are used.

  • Level 3: Defined. Organizational, not just project specific, thinking comes into play at this level. Common management and engineering activities are standardized and documented. These standards are adapted and approved for use on different projects. The rules aren't thrown out when things get stressful. Test documents and plans are reviewed and approved before testing begins. The test group is independent from the developers. The test results are used to determine when the software is ready.

  • Level 4: Managed. This maturity level is under statistical control. Product quality is specified quantitatively beforehand (this product won't release until it has fewer than 0.5 defects per 1,000 lines of code) and the software isn't released until that goal is met. Details of the development process and the software's quality are collected over the project's development, and adjustments are made to correct deviations and to keep the project on plan.

  • Level 5: Optimizing. This level is called Optimizing (not "optimized") because it's continually improving from Level 4. New technologies and processes are attempted, the results are measured, and both incremental and revolutionary changes are instituted to achieve even better quality levels. Just when everyone thinks the best has been obtained, the crank is turned one more time, and the next level of improvement is obtained.

Do any of these levels sound like the process used at a software development company you know? It's scary to think that a great deal of software is developed at Level 1but it's often not surprising after you use the software. Would you want to cross a bridge that was developed at Level 1, ride an elevator, fly on a plane? Probably not. Eventuallyhopefullyconsumers will demand higher quality software and you'll see companies start to move up in their software development maturity.

NOTE

It's important to realize that it's not a software tester's role to champion a company's move up in software development maturity. That needs to be done at a corporate level, instituted from the top down. When you begin a new testing job, you should assess where the company and your new team is in the different maturity levels. Knowing what level they operate in, or what level they're striving for, will help you set your expectations and give you a better understanding of what they expect from you.


For more information on the Capability Maturity Model, visit the Software Engineering Institute's website at www.sei.cmu.edu/cmmi.



    Software Testing
    Lessons Learned in Software Testing
    ISBN: 0471081124
    EAN: 2147483647
    Year: 2005
    Pages: 233

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net