Capability Maturity Model (CMM


Birla Institute of Technology, Patna Campus Computer Science and Engineering Neeraj Kumar BE/5699/08 +91-7549393020

Some Definitions
‡ Software Process
± set of activities, methods, practices, and transformations used to develop and maintain software and associated products
‡ project plans, design documents, code, test cases, user manuals

‡ Software Process Capability
± knowing what the above will give you

‡ Software Process Performance
± actual results from the above

‡ Software Process Maturity
± how well the process is specific process is explicitly defined, managed, measured, controlled, and effective ± also includes consistency and change

Software Process Improvement
‡ Six steps to improve software capabilities through process improvements (one method)
1. Understand the current development process or processes 2. Develop a vision of the desired process 3. List the required process improvement actions in order of priority 4. Produce a plan to implement the actions 5. Commit the resources and execute the plan 6. Start over at step 1

Immature Software Organization
‡ Does not mean they produce poor code ‡ Characterized by
± ± ± ± ad-hoc/improvised processes (project dependant) process are not rigorously followed (if specified) reactionary to immediate crisis ( fighting fires ) quality and function compromised to meet schedule
‡ quality related activities often eliminated due to schedule pressures

± schedules and budgets routinely exceeded ± no objective basis for measuring quality
‡ hard to predict future events...

but ‡ Characterized by ± organization wide ability for managing software development and maintenance ± process is integral to the organization ‡ communicated to staff + staff follow process ± process is useable and useful ± process is not static (evolves in controlled manner) ‡ fit for use + updated as necessary ± objective and quantitative quality metrics ± schedules and budgets based on historical data ‡ and thus usually achieved .Mature Software Organizations ‡ Does not mean they produce good code.

CMM ± a set of key processes and recommended practices ± guidance on how to gain control of their process and how to evolve toward a culture of software engineering and management excellence . investigated maturity framework (Watts Humphrey) ‡ 1987 questionaires ± software capability evaluation ± maturity questionaire ‡ 1991 . the Software Engineering Institute (SEI).The Birth of CMM ‡ 1986.

most projects produce poor results ‡ in undisciplined organizations.Observations that motivated CMM ‡ productivity and quality gains from methodologies and technologies not near what was expected in the early 80s ‡ difficult to do better in a chaotic process ‡ in undisciplined organizations. some projects produce excellent results ± usually the result of heroic effort ± repeating the result means repeating the heroics .

Capability Maturity Model (CMM) ‡ used as a standard for appraising the current state of the organization s software process ‡ used as a guide for identifying and prioritizing the actions comprising the software process improvement effort ‡ Made up of 5 levels and 18 key process areas (KPAs) ‡ a CMM-based maturity questionnaire may be used to assess the software capability of a particular organization ± government may use this to assess the capability of potential software development contractors .

CMM Levels 1 Initial 2 Repeatable 3 Defined Support 4 Managed 5 Optimizing Competent People and Heroics Project Management process Engineering Process & Org Product and Process Quality Continuous Process Improvement .

Basic descriptions of CMM levels 1. maybe even chaotic. functionality. necessary process discipline is in place to repeat earlier successes on projects with similar applications software process for both management and engineering activities is documented. few processes are defined. success depends on individual effort and heroics basic project management practices to track cost. standardized. Defined ‡ 4. both the software process and products are quantitatively understood and controlled continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies ‡ 3. all projects use an approved. schedule. integrated into a standard software process. Repeatable ‡ software process is ad hoc. Managed ‡ 5. Initial 2. Optimizing ‡ . tailored version of the organization s standard software process for developing and maintaining software detailed measures of the software process and product quality are collected.

SW-CMM Structure .

‡ Verifying Implementation (VE) ± groups all generic practices related to verifying that the projects and/or organization s activities conform to requirements. ‡ Directing Implementation (DI) ± groups the generic practices related to collecting. . measuring. ‡ Ability to Perform (AB) ± groups all generic practices related to ensuring that the project and/or organization has the resources it needs to pursue process improvement. processes. and analyzing data related to processes. and procedures. The purpose of these activities is to provide insight into the performance of processes.Common Features ‡ Commitment to Perform (CO) ± groups all generic practices related to creating policies and securing sponsorship for process improvement efforts.

Structure of CMM .

the KPA is said to be institutionalized .Key Process Areas (KPAs) ‡ each maturity level (except 1) is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process ‡ a cluster of related activities which collectively achieve a set of important goals ‡ when the goals are accomplished on a continuing basis.

they are not addressed by the model . the KPAs for that level must be satisfied ‡ there are other processes deemed to be not key to achieving a maturity level.Key Process Areas (cont·d) ‡ KPAs are enhanced in succeeding levels ‡ to achieve a maturity level.

Key Process Areas (KPAs) .

SW-CMM Maturity Levels .

The Initial Process (no KPA) Risk of Total Chaos No management mechanism in place to plan and track the work of individuals If procedures are established they are abandoned during a crisis PM = Panic Management tends to be continuous (make the biggest fire smaller) capability of org = characteristic of individuals .

To Improve to Repeatable Process Understand the difference between speed and progress Basic project control: Project management project size estimation Management oversight quarterly review of process Quality assurance establish a QA organization (} 5-6 % of development org) Change control .

schedule and functionality Experienced at doing similar work realistic project commitments based upon previous results .The Repeatable Process Provides control over the way the organization establishes its plan and commitments basic software management controls exist for tracking cost.

Repeatable (level 2) KPAs Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management major risks to the organization at this level: introduction of new tools will affect process entering new territory. by trying new products can be developing new types of products major organizational changes can be disruptive .

Getting to the Defined Process Establish a process group } 1-3 % of development org Establish a development process architecture describes the technical and management activities for proper execution of the development process Introduce a family of software engineering methods and technologies design and code inspection formal/semi-formal design methods library control systems comprehensive testing methods .

The Defined Process Processes for development and maintenance of software is standardized across the corporation software engineering is integrated into the larger engineering management processes The Acid-test But only qualitative When faced with a crisis they will continue to use the process that has been defined (might happen at level 2 as well) Little data to support the effectiveness of the process need to move to a quantitative process .

Defined (level 3) KPAs ‡ ‡ ‡ ‡ ‡ ‡ ‡ Organization Software process definition Organization Software process focus Training program Integrated software management Peer reviews (including inspections) Intergroup coordination Software product engineering .

Managed (level 4) KPA ‡ Quality management ‡ Quantitative process management .

To Improve to the Optimizing Process ‡ Causal analysis ± eliminate the causes of defects ‡ Orderly transition of new technologies into the organization ‡ Use process data to analyze and change the process ± continuous improvement ‡ of process to improve product quality ‡ of productivity ‡ of time needed to develop .

The Optimizing Process ‡ Organizational focus is on continuous process improvement is supported by quantitative trend analysis as to process strengths and weaknesses ‡ Process innovations and new technologies are introduced when supported by cost benefit analysis ‡ Data is available to tune the process itself ‡ Ability to put the resources where it counts .

Optimizing KPA ‡ Process change management ‡ Technology change management ‡ Defect prevention .

CMM vs XP .

CMM representations ‡ two representations ± provide alternative approaches to process improvement for familiarity with either approach ‡ represent two different philosophical approaches to process improvement .

allowing the organization to choose which process or set of processes need to have more capability ±continuous view (comparable to systems engineering and IPD models) .CMM Representations (cont·d) ‡ Representation 1. focus on individual processes. focus on the organization as a whole and provide a road map of successive stages aimed at improving the organization s ability to understand and control its process ±staged view (comparable to SW-CMM) ‡ Representation 2.

Representations (cont·d) ‡ each representation is a 600 page document ‡ equivalent staging ± sometimes desirable to convert an organization s capability level achievements into a maturity level ‡ can t translate from maturity level back capability level .

Continuous Representation ‡ groups process areas into ± process management ± project management ± engineering ± support ‡ for each group. assigns a rating from 0 to 5. according to an organization s performance on process areas in that group .

Staged Representation ‡ groups process areas by maturity level ‡ allows an overall assessment leading to an assessment of the maturity level observed in an organization .

Some Differences between Representations Continuous process areas organized by process area categories Staged process areas organized by maturity levels six capability levels (0-5) per category five maturity levels (1-5) improvement is measured using capability levels that reflect incremental implementation of a particular process area additional appendix describing equivalent staging. allows translation of a target profile into a maturity level improvement is measured using maturity levels that reflect the concurrent implementation of multiple process areas no equivalence concept to go from maturity level to a target profile .

source code. or executable code) .. documented plans. and documented processes and procedures ‡ very few of the KPAs address the evolving results (i. quality assurance audits and inspections. design models.Issues with the CMM ‡ key process areas (KPAs) focus mostly on activities and supporting artifacts associated with a conventional waterfall process ±requirements specifications.e. the software product) and associated engineering artifacts (use case models.

they rarely uncover the architecturally significant flaws . assessment process.Issues (cont·d) ‡ no emphasis on the architecting/design process. inspections and traditional Quality Assurance policing methods ±although manual reviews and inspections may be capable of uncovering 60% of errors. or deployment process ±which have proven to be key discriminators for project success ‡ also overemphasizes peer reviews.

and more plans ± thicker documents. more traceability.Issues (cont·d) ‡ most implementations of CMM drive organizations to produce more documents. agile methods may be able to be mapped on to CMM stay tuned! . more detailed information. more reviews. more checkpoints. more artifacts. and longer meetings are considered better ± however.

SPA and SCAMPI Appraisal Results .CBA. IPI.State of the Industry Carnagie Melon Software Enginieering Institute Sofware CMM .


software acquisition. systems engineering and integrated product development ± latest initiative: CMM Integration (CMMI) . you fail the level ‡ CMMs now exist for software. people.Short-comings and Future of CMM ‡ Surprise.CMM is not a silver bullet ± a mature process is no guarantee of a quality product ‡ Not well suited for smaller companies / projects ± Personal Software Process (PSP) is one attempt to address this need ‡ Crude and harsh 5-point scale ± if you fail just one of the KPAs. surprise .

software acquisition. and integrated product development . people. systems engineering.Evolution of CMM ‡ initial Capability Maturity Model was developed specifically to address software process maturity ‡ it was successfully adopted and used in many domains ‡ other CMMs were developed for other disciplines and functions ‡ CMMs now exist for software.

Not Just Software CMM .

Decoding abbreviations ‡ SCE: Software Capability Evaluation ‡ SCDE: Software Development Capability Evaluation ‡ SA-CMM: Software Acquisition ‡ P-CMM: People ‡ SE-CMM: Systems Engineering ‡ SSE-CMM: Systems Security Engineering ‡ IPD-CMM: Integrated Product Development ‡ CMMI: CMM Integration .

. Bill. Watts (March 1988). Richard (July 1973). Boston: Addison Wesley ‡ Nolan. Mark C. The Capability Maturity Model: Guidelines for Improving the Software Process.(IEEE Software achinery) . "Managing the computer resource: a stage hypothesis". Mary Beth (1995). Weber. Chrissis.References ‡ Paulk. Communications of the ACM (Association for Computing Machinery) ‡ Humphrey. Curtis. Charles V. "Characterizing the software process: a maturity framework .

Sign up to vote on this title
UsefulNot useful