1. Capability Maturity Model

2. History 1986 - Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First version published in 1991 has been reviewed by 100s of software professionals closely related to TQM  goal is customer satisfaction not required that customer be "delighted"

3. Levels 1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimizing

4. Level 1 : The Initial Level ad hoc, sometimes chaotic overcommitment leads to a series of crises during a crisis, projects abandon plans capability is characteristic of individuals, not the organization when a good manager leaves, the success leaves with them

5. Level 2 : The Repeatable Level planning based on experience with similar projects  past successes can be repeated policies for managing and implementation  installed basic management controls  track costs and schedules  notice and deal with problems as they arise

6. Level 3 : The Defined Level Standard Processes defined across the organization and used by all projects standard set of roles, activities, quality tracking, etc each project uses a tailored version of this standard process Training Program is in place to ensure everyone has the skills required for their assigned role

7. Level 4 : The Managed Level Quantitative Quality Goals for both Products and Processes Organization-wide Process Database  meaningful variations in process performance can be distinguished from random noise actions are then taken to correct the situation Products are of predictably high quality

8. Level 5 : The Optimizing Level Organization has the means to identify weaknesses and strengthen the process proactively teams analyze defects to determine cause, and disseminate lessons learned throughout the organization major focus on eliminating waste (eg rework)

9. Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level

10. Don't skip levels For example,  collecting detailed data (level 4) is meaningless unless the data is from projects that use a consistent process (level 3)

11. Level Comparison - People Level 1 - Initial  success depends on individual heroics  fire fighting is the way of life Level 2 - Repeatable  people are trained and supported by management  success depends on individuals Level 3 - Defined  people are trained for their role(s)  groups work together Levels 4 - Managed  strong sense of teamwork in every project Level 5 - Optimizing  strong sense of teamwork across the organization  everyone does process improvement

12. Level Comparison - Risk Level 1 - Initial  Just do it Level 2 - Repeatable  problems are recognized and corrected as they occur Level 3 - Defined  problems are anticipated and prevented, or impacts minimized Levels 4 and 5  sources of problems are understood and eliminated

13. Level Comparison - Measurement Level 1 - Initial  ad hoc data collection and analysis Level 2 - Repeatable  individual projects use planning data Level 3 - Defined  data collected for all processes  data shared across projects Levels 4 - Managed  data standardized across the organization Level 5 - Optimizing  data used for process improvement

14. Some Fundamental Ideas Process improvement is based on small steps, rather than revolutionary innovation. CMM is not exhaustive or dictatorial. CMM focuses on processes that are of value across the organization.

15. Benefits of using the model helps forge a shared vision of purpose of process improvement within the organization establishes common language for the software process defines a set of priorities for attacking problems supports measurement  via reliable appraisals  objective  supports industry-wide comparisons

16. Risks of using the model "All models are wrong; some models are useful." Not a silver bullet. Does not address all of the issues that are important for successful projects.  For example how to hire and retain good people expertise in the application domain

17. Obvious Question Alert… Is CMM well-suited for everyone?

18. Criticisms of CMM CMM is well suited for bureaucratic organizations such as government agencies and large corporations.  Its formality is a hindrance to projects where time-to- market is more important than quality. No external body actually certifies a software development center as being CMM compliant. It is supposed to be an honest self-assessment. Promotes process over substance.  For example, emphasizing predictability over service provided to end users. en.wikipedia.com

19. Who uses CMM 75% of organizations are probably Level One.  To get to Level Two, you must have control over the requirements documents. Hence, shrink-wrap companies like Microsoft are Level One. 75% of Level Five organizations are in India.

20. And now... Lots of details!!!! Lots of details!!!!

21. Definitions Each of the five CMM levels is composed of key process areas each key process area is organized into five sections called common features common features contain key practices

22. Common Features 1. Commitment to Perform 2. Ability to Perform 3. Activities Performed 4. Measurement and Analysis 5. Verifying Implementation

23. Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level

24. Objectives of Key Process Areas Level Two  Requirements Management necessary to build software that will satisfy the customer  Software project planning reasonable plans of what to do and when  Software project tracking and oversight visibility into project's progress  Software subcontract management select and effectively manage subcontractors  Software quality assurance process and product are reviewed to create visibility into the process  Software Configuration management baselines and traceability

25. Objectives of Key Process Areas Level Three  Organization process focus coordinating and improving the organization's process  Organization process definition institutionalize process data, criteria, training, etc  Training program develop skills to perform roles  Integrated software management integrate development and management activities into a coherent software process (followup to level 2 tracking)  Software product engineering describe technical activities (e.g. write the SRS, design, coding, etc)  Intergroup coordination the development teams talks with engineering, marketing, etc  Peer Reviews remove defects

26. Objectives of Key Process Areas Level Four  Quantitative process management notice when performance falls outside of expected bounds  Software Quality Management quality goals, supported by plans Level Five  Defect prevention identify causes of defects and prevent them from recurring  Technology change management identify, evaluate, and integrate beneficial technologies  Process change management continuous process improvement

27. Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level

28. Software Project Planning Goals Goals 1. Soft ware estimates are documented for use in planning and tracking the software project. 2. Software Project activities and commitments are planned and documented. 3. Affected groups and individuals agree to their commitments related to the software project.

29. Software Project Planning 1. Commitment to Perform Commitment 1 -- A project software manager is designated to be responsible for negotiating commitments and developing the project's software development plan. Commitment 2 -- The project follows a written organizational policy for planning a software project.

30. This policy typically specifies that: 1. The system requirements allocated to software are used as the basis for planning the software project. 2. The software project's commitments are negotiated between:  the project manager,  the project software manager, and  the other software managers. 3. Involvement of other engineering groups in the software activities is negotiated with these groups and is documented. 4. Affected groups review the software project's:  software size estimates,  effort and cost estimates,  schedules, and  other commitments. 5. Senior management reviews all software project commitments made to individuals and groups external to the organization. 6. The project's software development plan is managed and controlled.

31. Software Project Planning 2. Ability to Perform Ability 1 -- A documented and approved statement of work exists for the software project. Ability 2 -- Responsibilities for developing the software development plan are assigned. Ability 3 -- Adequate resources and funding are provided for planning the software project. Ability 4 -- The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility.

32.  The statement of work covers: scope of the work, technical goals and objectives, identification of customers and end users, imposed standards, assigned responsibilities, cost and schedule constraints and goals, dependencies between the software project and other organizations, resource constraints and goals, and other constraints and goals for development and/or maintenance.  The statement of work is reviewed by: the project manager, the project software manager, the other software managers, and other affected groups.  The statement of work is managed and controlled.

33. Software Project Planning 3. Activities Performed Activity 1 --The software engineering group participates on the project proposal team. Activity 2 --Software project planning is initiated in the early stages of, and in parallel with, the overall project planning. Activity 3 --The software engineering group participates with other affected groups in the overall project planning throughout the project's life. Activity 4 --Software project commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure. Activity 5 --A software life cycle with predefined stages of manageable size is identified or defined. Activity 6 --The project's software development plan is developed according to a documented procedure. Activity 7 --The plan for the software project is documented. Activity 8 --Software work products that are needed to establish and maintain control of the software project are identified. Activity 9 --Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure. Activity 10 -- Estimates for the software project's effort and costs are derived according to a documented procedure. Activity 11 -- Estimates for the project's critical computer resources are derived according to a documented procedure. Activity 12 -- The project's software schedule is derived according to a documented procedure. Activity 13 -- The software risks associated with the cost, resource, schedule, and technical aspects of the project are identified, assessed, and documented. Activity 14 -- Plans for the project's software engineering facilities and support tools are prepared. Activity 15 -- Software planning data are recorded.

34. Software Project Planning 4. Measurement and Analysis Measurement 1 -- Measurements are made and used to determine the status of the software planning activities.  Examples of measurements include: completions of milestones for the software project planning activities compared to the plan; and work completed, effort expended, and funds expended in the software project planning activities compared to the plan.

35. Software Project Planning 5. Verifying Implementation Verification 1 -- The activities for software project planning are reviewed with senior management on a periodic basis. Verification 2 -- The activities for software project planning are reviewed with the project manager on both a periodic and event-driven basis. Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for software project planning and reports the results.

36. Defect prevention Technology change management Process change management Quantitative process management Software Quality Management Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer Reviews Requirements management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software Configuration management Key Process Areas by maturity level

37. Training Program 3. Activities Performed Activity 1 -- Each software project develops and maintains a training plan that specifies its training needs. Activity 2 -- The organization's training plan is developed and revised according to a documented procedure. Activity 3 -- The training for the organization is performed in accordance with the organization's training plan. Activity 4 -- Training courses prepared at the organization level are developed and maintained according to organization standards. Activity 5 -- A waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform in their designated roles. Activity 6 -- Records of training are maintained.

38. The training plan covers: 1. The specific training needed within the organization and when it is needed. 2. The training that will be obtained from external sources and training that will be provided by the training group. 3. The funding and resources (including staff, tools, and facilities) needed to prepare and conduct or procure the training. 4. Standards for instructional materials used in training courses developed by the training group. 5. The schedule for developing and revising the training courses that will be developed by the training group. 6. The schedule for conducting the training, based on the projected need dates and the projected number of students. 7. The procedures for:  selecting the individuals who will receive the training,  registering and participating in the training,  maintaining records of the training provided, and  collecting, reviewing, and using training evaluations and other training feedback.