Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Cmm

on

  • 1,238 views

CMM

CMM

Statistics

Views

Total Views
1,238
Views on SlideShare
1,238
Embed Views
0

Actions

Likes
1
Downloads
60
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cmm Cmm Presentation Transcript

  • CHAPTER 3 SEI CMM
  • Introduction
    • Definition
    It is a reference model for inducting the software process maturity Into different levels. It can be used to predict the most likely outcome to be expected from the next project that the organization undertakes. Actually the capability of organizations associated with software development is evaluated by this model. That’s why model is called Software Engineering Institute Capability maturity model
  • Background
    • First proposed by Software Engineering Institute , Carnegie Mellon University , USA.
    • Patterned after the pioneering work of Philip Crosby published in the book Quality is Free , the
    • maturity grid for five evolutionary stages for adopting quality practices in an organization.
    Now a days it is called Capability maturity model integration
  • SEI CMM : Two Ways Of Use CMM Capability Evaluation Software Process Assessment
    • Capability Assessment
    • This is a way to assess the software process capability of an organization.
    • The results of Capability Assessment indicate the likely contractor performance
    • If it is awarded a project .
    So the results of Capability Assessment can be used to Select a contractor for completing a project
    • Software Process Assessment
    • Software Process Assessment is the assessment of any organization’s software process capability.
    • It is used by the organization with the objective to improve its process capability
    Hence , Software Process Assessment Is for purely internal use of the organization.
  • The need for software processes prior to CMM
    • Organizations began to adopt computerized information systems, and the demand for software development grew significantly.
    • The processes for software development were in their infancy, with few standard or "best practice" approaches defined.
    • As a result, the growth was accompanied by growing pains: project failure was common and the ambitions for project scale and complexity exceeded the market capability to deliver.
    • Individuals such as Edward Yourdon , Larry Constantine , Gerald Weinberg , Tom DeMarco , and David Parnas began to publish articles and books with research results in an attempt to professionalize the software development process.
    • In the 1980s, several US military projects involving software subcontractors ran over-budget and were completed much later than planned, if they were completed at all.
    • In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI.
  • Precursor to CMM
    • The Quality Management Maturity Grid was developed by Philip Crosby in his book "Quality Is Free“.
    • Note that the first application of a staged maturity model to IT was not by CMM/SEI, but rather by Richard L. Nolan , who, in 1973 published the Stages of growth model for IT organizations.
    • Watts Humphrey began developing his process maturity concepts during the later stages of his 27 year career at IBM.
    • Watts Humphrey's Capability Maturity Model (CMM) was published in 1988 and as a book in 1989, in Managing the Software Process .
    • Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the Software Engineering Institute (SEI).
    • The full representation of the CMM as a collection of defined process areas and practices at each of the five maturity levels was initiated in 1991, with Version 1.1 being completed in January 1993. The CMM was published as a book in 1995 by its primary authors, Mark C. Paulk , Charles V. Weber, Bill Curtis , and Mary Beth Chrissis.
  • Maturity model
    • A maturity model can be viewed as a set of structured levels that describe how well the behaviors, practices and processes of an organization can reliably and sustainably produce required outcomes.
    • A maturity model may provide, for example :
        • a place to start
        • the benefit of a community’s prior experiences
        • a common language and a shared vision
        • a framework for prioritizing actions.
        • a way to define what improvement means for your organization.
    • A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.
  • Capability Maturity Model structure
    • Maturity Levels: a 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.
    • Key Process Areas: a Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
    • Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
    • Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
    • Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
  • The Maturity Levels SEI CMM classifies software development organizations into FIVE Maturity Levels.
    • LEVEL 1 : Initial
    • LEVEL2 : Repeatable
    • LEVEL 3 : Defined
    • LEVEL 4 : Managed
    • LEVEL 5 : Optimizing
  • CMM Model Performed Process Level 2 Managed Process Level 3 Defined Process Level 4 Quantitatively Managed Process Level 5 Optimizing Process Capability Level 1
  • Level 1 : Initial
    • The organization is characterized by ad hoc activities.
    • Either very few or no process is defined in this level.
    • Engineers follow their own processes for development.
    • The development becomes chaotic , sometimes the level is called CHAOTIC level.
    • The success of project depends on own efforts .
    • As soon as the development team leaves the successors fall into great difficulty
    • to understand the process that has been followed.
    • As a result the developed product is of low quality .
  • Level 2 : Repeatable
    • Basic project management practices like tracking cost and schedule are established.
    • Size and Cost estimation techniques like Function Point Analysis and COCOMO are
    • used.
    • The necessary process disciplines are in place to repeat the earlier successes on
    • projects with similar applications .
    • We have to remind that repeat of process only exists when the organization has
    • developed a group of products.
  • Level 3 : Defined
    • Here the processes for both the management and development activities are
    • defined and documented.
    • There is a common organization wide understanding of activities , roles and
    • responsibilities.
    • Although the processes are defined the process and product quality are not
    • measured.
    • ISO 9000 aims at achieving this level.
  • Level 4 : Managed
    • Primary focus concentrated on software metrics , the metrics are Product metrics and Process metrics.
    • Product metrics deals with size, reliability , time complexity , understandability of the product deals with product quality .
    • Process metrics deals with effectiveness of the process that is being used such as average number of defects found per hour of inspection , average number of failures detected during testing per LOC.
    • Various tools are used – Pareto Charts , Fishbone Diagram.
    • Result of process measurements is used to evaluate the project rather to improve the process .
  • Level 5 : Optimizing
    • Process and Product metrics are collected first.
    • Process and Product measurement data are analyzed to improve the process
    • that is being followed.
    • Continuous Process Improvement is achieved through following steps
    • -Analyzing the quantitative feedback from process measurements
    • -Invoking innovative methods and technologies.
  • The Framework At A Glance
  • Key Process Areas CMM LEVEL FOCUS KPA Initial Competent people Repeatable Project management Software project planning Software configuration management Defined Definition of process Process definition Training program Managed Product and process quality Quantitative process management Software quality management Optimizing Continuous process improvement Defect prevention Process change management Technology change management
  • Software process framework for SEI's Capability Maturity Model TYPESD DESCRIPTION Policy Describes the policy contents and KPA goals recommended by the CMM. Standard Describes the recommended content of select work products described in the CMM.
  • Process
    • Describes the process information content recommended by the CMM. The process checklists are further refined into checklists for: roles
    • entry criteria
    • inputs
    • activities
    • outputs
    • exit criteria
    • reviews and audits
    • work products managed and controlled
    • measurements
    • documented procedures
    • training
    • tools
  • Level overview
    • Provides an overview of an entire maturity level. The level overview checklists are further refined into checklists for: KPA purposes (Key Process Areas)
    • KPA Goals
    • policies
    • standards
    • process descriptions
    • procedures
    • training
    • tools
    • reviews and audits
    • work products managed and controlled
    • measurements
    Procedure Describes the recommended content of documented procedures described in the CMM.
  • Don’t Mix Up with ISO 9000
      • ISO 9000 is an external document, where as CMM is purely internal document.
    • CMM only for software industry.
    • CMM shows a way for achiving gradual quality improvement
  • THANK YOU