CAPABILITY MATURITY MODEL for Software (CMM) Version 1.

1
INTRODUCTION

Course Objectives
• Understand terms such as process, capability, and maturity • Discuss the 18 key process areas in the CMM • Interpret the CMM and the key practices in the different contexts • Describe the fundamental concepts of the CMM • Explain and use the structure of the CMM

What can go wrong in a project?
• Bad requirements • Frequent changes to requirements • Wrong interpretation of requirements • Inaccurate estimation • Inaccurate or bad planning • Risks which materialized • Attrition • Bad implementation • No reviews i.E., Inputs from relevant people/ groups • Mismatched resource skill levels • Miscommunication between groups • No defined method for implementing a project • No checks and balances • Inadequate testing • Incorrect source base and so on

Do we need processes?

Do we need processes? Such discipline may stifle my creativity! “Discipline enables creativity by FREEING the most talented software professionals from the many CRISES that others have created. A disciplined process EMPOWERS the intellect...” - Watts Humphrey

What Is CMM ?

A common sense application of process management and quality improvement concepts to software development and maintenance A community-developed guide A model for organizational improvement

 

Other Capability Maturity Models
Focus areas include :  Software CMM  People CMM  CMMI - CMM integrated (new)

A Mature Process
 Consistent with the way work actually gets done defined, documented, and continuously improving  Understood  Used  Living  Supported visibly by management and others  Well controlled  Constructive use of product and process measurements  Disciplined use of technology

Institutionalized Process
“That is the way we do things around here”
 Organizational infrastructure contains  Effective processes  Usable processes  Consistently applied processes  Organizational culture  Must convey the process  Nurtured by management  Is conveyed with role models and rewards  Institutionalized processes ENDURES
( Even after people who originally defined them have gone)

What CMM Does not address?
 The CMM does not address specific software process and quality improvement issues  Issues that are addressed only indirectly, or by implication, include  Specific tools, methods, and technologies  System engineering, marketing, etc  Human resources  Organizational behavior

Structure of CMM

CMM Maturity Level
Maturity level is  Well-defined stages of evolution on the path to becoming a mature software organization  Each level is a layer in the foundation for continuous process improvement  Achieving each level establishes a different component of the software process

CMM Maturity Level

There are five maturity levels in CMM

Intent of the Initial Level -Level 1
 Performance driven by the competence of the people doing the work  High quality and exceptional performance possible so long as the best people can be hired  The process is unpredictable - for good or bad  The major problems facing the software organization are managerial, not technical

Intent of the Repeatable Level - level 2
 The predominant need is to establish effective software project management  Software project management processes are documented and followed  Organizational policies guide the projects in establishing management processes  Successful practices developed on earlier projects can be repeated

Intent of the Defined Level - Level 3
 This level builds on the software project management foundation  To control a process, it must be defined, documented, and understood  The outputs of one task flow smoothly in to the inputs of the next task  At this level, the organization builds processes that empower the individuals doing the work

Intent of the Managed level - Level 4
 Apply the principles of statistical process control  Address the special causes of process variation

Intent Of The Optimizing level - Level 5
 Identify and eliminate chronic causes of poor performance  Continuously improve the software process

Key Process Area (KPAs) of Each Level

Maturity levels are described in terms of 18 key process areas (KPAs)

Level 2 KPAs
      Software configuration management (SCM) Software quality assurance (SQA) Software subcontract management (SSCM) Software project tracking and oversight (SPTO) Software project planning (SPP) Requirements management (RM)

Level 3 KPAs
       Organization process focus (OPF) Organization process definition (OPD) Peer reviews (PR) Intergroup coordination (IGC) Software product engineering (SPE) Integrated software management (ISM) Training program (TP)

Level 4 KPAs
 Software quality management (SQM)  Quantitative process management (QPM)

Level 5 KPAs

 Process change management (PCM)  Technology change management (TCM)  Defect prevention (DP)

Maturity levels cannot be skipped
• Processes at higher maturity levels may be performed, although perhaps ineffectively, even by the organizations at the initial level • Process capability is built in stages, as some processes are ineffective when others are not stable

Maturity levels
 Well-defined evolutionary plateaus on the path to becoming a mature software organization  Each level is a layer in the foundation for continuous process improvement  There are five maturity levels in the CMM  Achieving each level establishes a different component of the software process  Maturity levels are described in terms of 18 key process areas

Goals
 Goals summarize the key practices of the key process areas  They are considered important for enhancing process capability for that level of maturity  They can be used to guide organizations and appraisal teams in assessing alternative ways to implement key process areas  Each key process maps to one or more goals

Common features
• Used to organize the key practices in each key process area Common features are : – Commitment to perform – Ability to perform – Activities performed – Measurement and analysis – Verifying implementation

Commitment to perform
• Describes the actions the organization must take to ensure that the process is established and will endure • Typically include – Policies – Leadership

Ability to perform
• Describes the preconditions that must exist in the project or organization to implement the software process competently • Typically includes – Function – Resources – Delegation – Training – Orientation

Activities performed
• Describes the roles and procedures necessary to implement a key process area • Typically includes – Establishing plans and procedures – Performing the work – Tracking it – Taking corrective actions as necessary

Measurement and analysis
• Describes the need to measure the process and analyze the measurements • Typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed common feature

Verifying implementation

• Describes the steps to ensure that the activities are performed in compliance with the process that has been established • Typically includes reviews and audits by – Senior management – Project management – Software quality assurance

Key Practices
• State the fundamental policies, procedures, and activities for a key process area • Describe “what” is to be done, but they should not be interpreted as mandating “how” • Are organized by common feature • 316 key practices in CMM

End of Introduction to CMM