P. 1


|Views: 114|Likes:
Published by Neeraj Kumar

More info:

Published by: Neeraj Kumar on Apr 13, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PPTX, PDF, TXT or read online from Scribd
See more
See less





Capability Maturity Model (CMM


Birla Institute of Technology, Patna Campus Computer Science and Engineering Neeraj Kumar BE/5699/08 nkneerajnow@gmail.com +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...

Mature Software Organizations ‡ Does not mean they produce good code. 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 .

The Birth of CMM ‡ 1986.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).

some projects produce excellent results ± usually the result of heroic effort ± repeating the result means repeating the heroics .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. most projects produce poor results ‡ in undisciplined organizations.

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 .

success depends on individual effort and heroics basic project management practices to track cost. Managed ‡ 5. few processes are defined. 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. standardized. Repeatable ‡ software process is ad hoc. all projects use an approved. Optimizing ‡ . Defined ‡ 4.Basic descriptions of CMM levels 1. schedule. functionality. 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. integrated into a standard software process. Initial 2. maybe even chaotic. 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.

SW-CMM Structure .

and procedures. processes. ‡ 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. measuring. .Common Features ‡ Commitment to Perform (CO) ± groups all generic practices related to creating policies and securing sponsorship for process improvement efforts. The purpose of these activities is to provide insight into the performance of processes. ‡ 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. and analyzing data related to processes.

Structure of CMM .

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. the KPA is said to be institutionalized .

the KPAs for that level must be satisfied ‡ there are other processes deemed to be not key to achieving a maturity level. they are not addressed by the model .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.

by trying new products can be developing new types of products major organizational changes can be disruptive .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.

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 .

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. focus on individual processes. 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.

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 .

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

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 .

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

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

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

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


Short-comings and Future of CMM ‡ Surprise. systems engineering and integrated product development ± latest initiative: CMM Integration (CMMI) . people. surprise . you fail the level ‡ CMMs now exist for software. software acquisition.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.

software acquisition.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. people. systems engineering. and integrated product development .

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 .

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

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->