Presentation is loading. Please wait.

Presentation is loading. Please wait.

Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University.

Similar presentations


Presentation on theme: "Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University."— Presentation transcript:

1 Capability Maturity Model

2 What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University n Framework that describes the key elements of an effective software process.

3 n Describes an evolutionary improvement path for software organizations from an ad hoc, immature process to a mature, disciplined one. n Provides guidance on how to gain control of processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. What is CMM?

4 Process Maturity Concepts n Software Process n set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, user manuals) n Software Process Capability n describes the range of expected results that can be achieved by following a software process n means of predicting the most likely outcomes to be expected from the next software project the organization undertakes

5 Process Maturity Concepts n Software Process Performance n actual results achieved by following a software process n Software Process Maturity n extent to which a specific process is explicitly defined, managed, measured, controlled and effective n implies potential growth in capability n indicates richness of process and consistency with which it is applied in projects throughout the organization

6 What are the CMM Levels? (The five levels of software process maturity) Maturity level indicates level of process capability: o Initial o Repeatable o Defined o Managed o Optimizing

7

8 Level 1: Initial Ê Initial : The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. Ê At this level, frequently have difficulty making commitments that the staff can meet with an orderly process Ê Products developed are often over budget and schedule Ê Wide variations in cost, schedule, functionality and quality targets Ê Capability is a characteristic of the individuals, not of the organization

9 Level 2: Repeatable Ë Basic process management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. Ë Realistic project commitments based on results observed on previous projects Ë Software project standards are defined and faithfully followed Ë Processes may differ between projects Ë Process is disciplined Ë earlier successes can be repeated

10 Level 3: Defined Ì The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization’s standard software process for developing an maintaining software.

11 Level 4: Managed Í Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. Í Narrowing the variation in process performance to fall within acceptable quantitative bounds Í When known limits are exceeded, corrective action can be taken Í Quantifiable and predictable Ípredict trends in process and product quality

12 Level 5: Optimizing Î Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Î Goal is to prevent the occurrence of defects Î Causal analysis Î Data on process effectiveness used for cost benefit analysis of new technologies and proposed process changes

13 Internal Structure to Maturity Levels n Except for level 1, each level is decomposed into key process areas (KPA) n Each KPA identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing software capability. n commitment n ability n activity n measurement n verification

14

15

16 Level 2 KPAs n Requirements Management n Establish common understanding of customer requirements between the customer and the software project n Requirements is basis for planning and managing the software project n Not working backwards from a given release date! n Software Project Planning n Establish reasonable plans for performing the software engineering activities and for managing the software project

17 Level 2 KPAs n Software Project Tracking and Oversight n Establish adequate visibility into actual progress n Take effective actions when project’s performance deviates significantly from planned n Software Subcontract Management n Manage projects outsourced to subcontractors n Software Quality Assurance n Provide management with appropriate visibility into Øprocess being used by the software projects Øwork products

18 Level 2 KPAs n Software Configuration Management n Establish and maintain the integrity of work products n Product baseline n Baseline authority

19 Level 3 KPAs n Organization Process Focus n Establish organizational responsibility for software process activities that improve the organization’s overall software process capability n Organization Process Definition n Develop and maintain a usable set of software process assets Østable foundation that can be institutionalized Øbasis for defining meaningful data for quantitative process management

20 Level 3 KPAs n Training Program n Develop skills and knowledge so that individual can perform their roles effectively and efficiently n Organizational responsibility n Needs identified by project n Integrated Software Management n Integrated engineering and management activities n Engineering and management processes are tailored from the organizational standard processes n Tailoring based on business environment and project needs

21 Level 3 KPAs n Software Product Engineering n technical activities of the project are well defined (SDLC) n correct, consistent work products n Intergroup Coordination n Software engineering groups participate actively with other groups n Peer Reviews n early defect detection and removal n better understanding of the products n implemented with inspections, walkthroughs, etc

22 Level 4 KPAs n Quantitative Process Management n control process performance quantitatively n actual results from following a software process n focus on identifying and correcting special causes of variation with respect to a baseline process n Software Quality Management n quantitative understanding of software quality Øproducts Øprocess

23 Level 5 KPAs n Process Change Management n continuous process improvement to improve quality, increase productivity, decrease cycle time n Technology Change Management n identify and transfer beneficial new technologies Øtools Ømethods Øprocesses n Defect Prevention n causal analysis of defects to prevent recurrence

24 What are the benefits ? n Helps forge a shared vision of what software process improvement means for the organization n Defines set of priorities for addressing software problems n Supports measurement of process by providing framework for performing reliable and consistent appraisals n Provides framework for consistency of processes and product

25 Why measure software and software process? Obtain data that helps us to better control n schedule n cost n quality of software products

26 Consistent measurement provide data for: n Quantitatively expressing requirements, goals, and acceptance criteria n Monitoring progress and anticipating problems n Quantifying tradeoffs used in allocating resources n Predicting schedule, cost and quality

27 Measurements n Historical n Plan n Actual n Projections

28 SEI Core Measures

29 Examples of measurements for size of work products n Estimated number of requirements n Actual number of requirements n Estimated source lines of code (SLOC) n Actual SLOC n Estimated number of test cases n Actual number of test cases

30 Example of measurements of effort n Estimated man-hours to design/code a given module n Actual man-hours expended for designing/coding the module n Estimated number of hours to run builds for a given release n Actual number of hours spent running builds for the release

31 Examples of measurements of quality of the work product n Number of issues raised at requirements inspection n Number of requirements issues open n Number of requirements issues closed n Number of issues raised during code inspection n Number of defects opened during unit testing

32 Examples of measurements of quality of the work product n Number of defects opened during system testing n Number of defects opened during UAT n Number of defects still open n Number of defects closed n Defect age

33 Examples of measurements of quality of the work product n Total number of build failures n Total number of defects fixed for a given release n Total number of defects verified and accepted n Total number of defects verified and rejected


Download ppt "Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University."

Similar presentations


Ads by Google