1 / 38

The Structure of the Capability Maturity Model

The Structure of the Capability Maturity Model. Presented by Chih-Wei Pang Ching-Wen Chang Yu-Lan Wang. What is CMM ?. It is a framework representing a method of improvements recommended for software organizations that want to increase their software process capability.

ulric-boyd
Télécharger la présentation

The Structure of the Capability Maturity Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Structure of the Capability Maturity Model Presented by Chih-Wei Pang Ching-Wen Chang Yu-Lan Wang

  2. What is CMM ? • It is a framework representing a method of improvements recommended for software organizations that want to increase their software process capability. • A descriptive model: It describes essential (or key) attributes that would be expected to characterize an organization at a particular maturity level.

  3. What is CMM ? • A normative model: that the detailed practices characterize the normal types of behavior that would be expected in an organization doing large-scale projects in a government contracting context. • It describes what we would normally expect in a software process, regardless of how the process is implemented.

  4. Five ways of using CMM • Assessment teams  to identify strengths and weaknesses in the organization. • Evaluation teams  to identify the risks of selecting among different contractors for awarding business and to monitor contracts. • Appraisal method developers  to develop other CMM-based appraisal methods that meet specific needs.

  5. Five ways of using CMM (cont.) • Upper management  to understand the activities necessary to launch a software process improvement program in their organization. • Technical staff and process improvement groups  to define and improve the software process in the organization.

  6. Internal Structure of the Maturity Levels

  7. Key process areas • Each maturity level (except for Level 1) is decomposed into several key process areas. • Key process areas indicate where an organization should focus to improve its software process. • To achieve a maturity level, the key process areas for that level (and the lower levels) must be satisfied and institutionalized.

  8. Goals of key process areas • To summarize its key practices and can be used in determining whether an organization or project has effectively implemented the key process area. • To signify the scope, boundaries, and intent of each key process area. • To determine whether the adaptation is a reasonable rendering of the practices.

  9. Overview of the key process areas by maturity level

  10. Key process areas at Level 2 • Overview  to focus on the software project’s concerns related to establishing basic project management controls.

  11. Key process areas at Level 2(cont.) • Requirements management Purpose  to establish a common understanding between the customer and the software project of the customer’s requirements to be addressed by the software project. * This agreement with the customer is the basis for planning and managing the software project.

  12. Key process areas at Level 2(cont.) • Software project planning Purpose to establish reasonable plans for performing the software engineering and for managing the software project. * The plan is documented and maintained as a necessary tool for managing the software project. * Including steps: 1) to estimate the size of the software work products and the resources needed. 2) to produce a schedule 3) to identify and assess software risks 4) to negotiate commitments

  13. Key process areas at Level 2(cont.) • Software project tracking and oversight Purpose  to establish adequate visibility into actual progress so that management can take effective actions when the software project’s performance deviates significantly from the software plans. * based on the development plan * It involves:1) tracking and reviewing the software accomplishments and results 2) revising the software development plan to reflect the actual accomplishments 3) taking corrective action when necessary

  14. Key process areas at Level 2(cont.) • Software subcontract management • Purpose  to select qualified software subcontractors and manage them effectively. • * selection may be based on 1) strategic business alliances • 2) process capability • 3) technical consideration

  15. Key process areas at Level 2(cont.) • Software quality assurance • Purpose  to provide management with appropriate visibility into the process being used by the software project and of the products being built. • * It involves: 1) Reviewing and auditing the projects and activity. • 2) Compliance issues should be first addressed

  16. Key process areas at Level 2(cont.) • Software configuration management • Purpose  to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle. • * Integrity of work products…….. • * Software baselines…………….. • * Change control and configuration auditing functions of Software Configuration Management……………

  17. Key process areas at Level 3 • Overview  address both project and organizational issues

  18. Key process areas at Level 3(cont.) • Organization process focus Purpose  to establish the organizational responsibility for software process activities that improve the organization’s overall software process capability. * Developing & maintaining an understanding of the organization’s and project’s software processes and coordinating the activities *People implementing the process must be intimately involved with its definition and improvement.

  19. Key process areas at Level 3(cont.) • Organization process definition Purpose  to develop and maintain a usable set of software process assets * It involves developing and maintaining the organization’s standard software process, along with related process assets, such as descriptions of software life cycles process tailoring guidelines and criteria the organization’s software process database a library of software process-related documentation

  20. Key process areas at Level 3(cont.) • Training program Purpose  to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently. * Identifying training needs then developing or procuring training.

  21. Key process areas at Level 3(cont.) • Integrated software management Purpose  to integrate the software engineering and management activities into a coherent, defined software process. * It is the evolution of Software Project Planning and Software Project Tracing and Oversight at Level 2.

  22. Key process areas at Level 3(cont.) • Software product engineering Purpose  to perform consistently a well-defined engineering process. • To describe the technical activities, e.g.: requirement analysis, design, code, and test. • Documenting • Maintaining traceability and consistency

  23. Key process areas at Level 3(cont.) • Intergroup coordination Purpose  to establish a means for the software engineering group to participate actively with the other engineering groups. • To address system-level requirements, objects, and issues. • The technical working interfaces and interactions between groups need to be planned and managed. • All engineering groups should know the status and plans of all the groups

  24. Key process areas at Level 3(cont.) • Peer reviews Purpose  to remove defects from the software work products early and efficiently. * via inspections, structured walkthroughs

  25. Key process areas at Level 4 • Overview this level focus on establishing a quantitative understanding of both the software process and the software products being built.

  26. Key process areas at Level 4(cont.) • Quantitative process management Purpose  to control the process performance of the software project quantitatively. * identify and correct the circumstances which drive process performance falling out of quantitative bounds * software process achieves the goal of this key process remains stable and quantitatively predictable * is process focused

  27. Key process areas at Level 4(cont.) • Software quality management Purpose  to develop a quantitative understanding of the quality of the project’s software products and achieve specific quality goals. * quantitative goals are established based on the needs of the organization, the customer, and the end users. * is product focused.

  28. Key process areas at Level 5 • Overview It covers the issues that both the organization and the projects must address to implement continuous and measurable software process improvement.

  29. Key process areas at Level 5(cont.) • Defect prevention Purpose  to identify the causes of defects and prevent them from recurring. * analyze defects, identify the causes, and prevent them from recurring. * sometimes used to change the project’s defined software process. * also result in changing element of the organization’s standard software process.

  30. Key process areas at Level 5(cont.) • Technology change management Purpose  identify beneficial new technologies and transfer them into the organization in an orderly manner. * identifying, selecting, and evaluating hew technologies. * to improve software quality, increase productivity, and decreases the cycle time

  31. Key process areas at Level 5(cont.) • Process change management Purpose  to improve continually the software processes used in the organization * define process improvement goals * identify, evaluate, and implement improvements

  32. Key Practices • Each key process area is described in terms of key practices • Key practices describe the activities and infrastructure that contribute most to the effective implementation and institutionalization of the key process area • The key practice describe “what” is to be done, not “how” • Alternative practices may accomplish the goals of the key process area  • More detailed subpractices are frequently provided under the key practice

  33. Common Features • Common features organize the practices that describe the key process areas • Common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting

  34. Common Features(cont.) • There are five common features • Commitment to Perform • Ability to Perform • Activities Performed • Measurement and Analysis • Verifying Implementation

  35. Common Features(cont.) • Commitment to Perform • Describe the actions the organization must take to ensure that the process is established and will endure • Involve establishing organizational polices and leadership • Ability to Perform • Describe the preconditions that must exist in the project or organization to implement the software process competently. • Involve resources, organizational structures, and training

  36. Common Features(cont.) • Activities Performed • Describe the activities, roles, and procedures necessary to implement a key process area • Involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary • Measurement and Analysis  • Describe the basic measurement practices that are necessary to determine status related to the process • These measurements are used to control and improve the process. Measurement and analysis typically includes example of the measurements that could be taken.

  37. Common Features(cont.) • Verifying Implementation • Describe the steps to ensure that the activities are performed in compliance with the process that has been established. • Encompasses reviews and audits by management and software quality assurance.

  38. Thank you !

More Related