1 / 66 ©Jozef De Man 2007 CMMI for Development Capability Maturity Model Integration for Development Prof. Dr. ir J. De Man

CMMIfor Development

1 / 66©Jozef De Man 2007

Capability Maturity Model Integrationfor Development

Prof. Dr. ir J. De Man

CMMIfor Development


Total Quality Managementof Manufacturing Process

Product Developmentis a technical activity

Total Quality Managementof Product Development

Product Developmentis also a business activity

Focus onmanagement aspects

Product Development is a process

Product DevelopmentMain drivers

Modeling ofSoftware

Modeling ofof Development Processes

CMMIfor Development


Overview

Total Quality Management Principles

Product Development Processes

Capability Maturity Model Integration

Critique

CMMIfor Development


Total Quality ManagementManufacturing Process

Total Quality Management Development Process

Development ProcessLearning from Manufacturing

RoutinePredictableAutomatedHierarchicalPrecise Requirements

CreativeUncertainHuman-intensiveNetworkingChanging Requirements

Principles must be carefullyre-interpreted in this different context

CMMIfor Development


Total Quality ManagementPrinciples

Senior Management commitment

“Listen to the voice of the customer”

Process quality drives product quality

Quality (first time right) saves time and effort

Continuous improvement

Quantified goals and measurements

Full participation of the entire workforce

Improvement takes time, it is about creating a culture

CMMIfor Development


TQMSenior Management Commitment

Studies show lack of senior management commitment is one of the major causes of project failure

Senior management must not delegate responsibility for quality but actively promote quality values and monitor improvement actions

Quality goals and customer satisfaction must be performance indicators of all employees

No “Management by Fear”; employees must be encouraged to report problems as early as possible

Reward and recognition of contributions to quality

CMMIfor Development


TQMListen to the Voice of the Customer

This must also include listening to the voice of the end-user, who is not necessarily the customer

It avoids spending effort on features, customers do not need Adequate level of quality The right features When the customer needs them At acceptable cost

User-involvement also enables promotion of existingfeatures to satisfy supposedly new requirements

CMMIfor Development


TQMProcess quality drives product quality

A defined process contributes to repeatable performance and consistent results

Causes of defects can be eliminated if they can be traced to lack of process adherence or inadequacies in the process

The process must have the “robustness” to minimize the impact of uncontrollable factors on the product quality (Taguchi)

CMMIfor Development


TQMQuality saves time and effort

Quality is Free (Philip Crosby, 1979)

By doing it right the first time, you save the effort of detecting and correcting defects and also reduce the elapsed time

Testing can be used to show the presence of bugs but never to show their absence (E.W. Dijkstra, Notes on Structure Programming 1970)

Error detection and correction becomes increasingly costly in later stages of the development cycle - to be revisited

CMMIfor Development


TQMContinuous improvement

There is no such thing as the optimal process

The process can always be improved by identifying “pockets of excellence” and spreading best

practices across the organization adopting new technology improving the knowledge and skills of the staff removing specific and common causes of defects listening to suggestions of people executing the process benchmarking against the competition adopting to new business requirements

Quality erodes if it is not sustained

CMMIfor Development


TQMQuantified goals and measurements

If you can not measure it, you can not improve it (Lord Kelvin)

To measure is to know (Lord Kelvin)

If you do not know where you are going, any road will take you there (Chinese proverb)

In physical science the first essential step in the direction of learning any subject is to find principles of numerical reckoning and practicable methods for measuring some quality connected with it. I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.” (Lord Kelvin)

CMMIfor Development


TQMFull participation of the entire workforce

Quality is not only the responsibility of the “quality department”

All employees must be actively involved in improvement activities

The process must not be imposed by management but the entire organization must be convinced this is the current best way of working

At the same time everybody must be actively looking for improvements

Improvements must be evaluated and piloted first before they are deployed

CMMIfor Development


TQMQuality Culture

A quality culture cannot be bought

It is established through a growth process that takes time

It must evolve from the practices that have been proven successful in the organization

Not all improvements can be done at once: You have to establish a process first before you can

improve it You must start measuring performance before you can

define quantified goals for improvement

A culture of excellence retains people in the organization

CMMIfor Development


TQMapplied to creative processes

By standardizing and automating the repetitive (unattractive) tasks of software development, people can focus on the creative tasks

Creative energy can be directed to process improvement: Spend your effort correcting mistakes you keep making, or Find a way to prevent these mistakes from being made

Measurements are necessary to improve the process but must not be used to blame people

However, practices that work in manufacturing must not be copied blindly to (software) development, it’s the principles we have to apply

CMMIfor Development


Overview


Product Development Processes


Critique

CMMIfor Development


Product DevelopmentBasic Elements

Processes

People Tools&Technology

perform

use

automate andensure adherence to

Processes are also the “glue” between the three elements

CMMIfor Development


Product DevelopmentTraditional View

• People use tools to develop products• People must have the skills to work

with the tools

• Tools are the primary means to improve quality and productivity

• Processes are individual and ad hoc

CMMIfor Development


Product DevelopmentEvolved View

• People must adhere to processes• People focus on continuously

improving processes

• Tools automate processes• Tools ensure adherence to

processes

• Process quality determines product quality• Processes shared through the organization

capture best practices

CMMIfor Development


The People factorProcesses are executed by people, who

have the required knowledge about the product, processes and technology

have the skills to perform the process, to execute technical activities, to work in a team, manage their time, to manage projects/teams/competence,...

are motivated to meet business objectives find their work rewarding

People must not acquire this knowledge and these skillsby accident but processes must be established to manage this

CMMIfor Development


Development Tools

Tools must not be evaluated based on personal preferences, vendor salesmanship, or vague promises for improvement

Tools are not solutions in their own right

Tools must increase the efficiency and consistency of processes through automation and by ensuring adherence to processes

There is no “silver bullet”(promising miraculous results)

CMMIfor Development


Processesand Software

Processes are software too Processes can be partially automated by programs Processes can be modeled as software

Software is a process Software is often part of a business process

We can therefore use our knowledge of software modeling to better understand processes as well

L. Osterweil. Software processes are software too, Proceedings of the Ninth InternationalConference of Software Engineering, pg 2-13, Monterey CA, March 1987.L Osterweil. Software Processes are Software Too, revisited: An Invited Talk on theMost Influential Paper of ICSE9, ICSE 1997 pg 540-548.

CMMIfor Development


Model Driven Software DevelopmentProcess Model

ERA

Process Description

Project/Process

The Process Model Hierarchy is an example ofModel Driven Software Development.The upper levels of the hierarchy define the genericpart of the software.Specific applications are generated by supplyinga data structure with the lower-level model definition

Process Model

CMMIfor Development


Processa simple model

WorkProduct

Activity

Role Milestone

Subactivity

Start/EndInputOutputControl

LeadsPerforms

CreatesReviewsApproves

CreatedApprovedReleasedWhat?

How?

Who?

When?part of

CMMIfor Development


Model HierarchyLevel 1: Process

WorkProduct

Activity

Role Milestone

SystemArchitect

ProjectManager

Designers

QualityManager

ProjectStart

IterationMilestones

instances

CMMIfor Development


Model HierarchyLevel 0: Project

WorkProduct

Role Milestone

SystemArchitectProject

Manager DesignersQuality

Manager

ProjectStart

IterationMilestones

John Doe 14 Feb2007

John DoeJohn DoeJim Greene

instances

CMMIfor Development


Process ModelingWhy?

Facilitates sharing with/understanding by people

Enables formal reasoning: completeness, consistency

Provides a foundation for (partial) automation

Provides a foundation for improvement

CMMIfor Development


Overview


Software Development Processes


Critique

CMMIfor Development


The Quality Frameworks“Quagmire”

ISO 9000-2000

SW CapabilityMaturity Model

ITIL

Malcolm BaldrigeQuality Award

Bootstrap

Trillium

Spice

European Foundationfor Quality Management

BalancedScorecard

TL 9000

CMM Integration

MIL STD-498,...

IEEE standards

Tickit

People CMM

PersonalSW Process

TeamSW Process

IPPD

Six Sigma

CMMIfor Development


History Of The CMMISM

Based on principles of TQM, applied to software development

History 1987 SEI maturity questionnaire 1989 Managing the Software Process 1993 Capability Maturity Model, v.1.1 2002 CMMI - CMM Integration 2006 CMMI version 1.2

CMMI unifies Staged and Continuous representation Software Engineering, Systems

Engineering, Integrated Product and Process Development, Supplier Sourcing

Constellations CMMI for Development CMMI for Acquisition CMMI for ServicesThe SEI is a Federally Funded Research and

Development Center (FFRDC) established in 1984 at Carnegie Mellon University by the US Department of Defense

http://www.sei.cmu.edu

CMMIfor Development


Why use the CMM(I)?

To assess your product development capability

To define improvement targets

To guide improvement of your development capability

To assess the development capability of your suppliers

To create a culture of excellence

CMMIfor Development


CMMIIntroduction

A model is a simplified representation of the world

Capability Maturity Models contain the essential elements of effective processes

CMMI models provide guidance for developing processes, CMMI models are not processes or process descriptions

The CMMI suite is produced from a common framework with the ability to generate multiple models

CMMIfor Development


Symptoms of an immature process?

Processes are improvised

If a process is defined, it is not generally applied

Focus is on solving immediate problems (fire-fighting)

Heavy reliance on heroic effort of individuals

People are rewarded for solving problems,not for preventing them

Overwork is the rule

People complain about workload and stress

Proposals for change are ignored by middle management

CMMIfor Development


Symptoms of an immature process (2)

There is no time to do it right once but there must be time to do it twice

Changes are imposed from the top without consulting all stakeholders… Not Invented Here syndrome

Change programs are ridiculed

Dilbert cartoons are popular and reflect the company culture

CMMIfor Development


CharacteristicsMaturity Level 2 - Managed

Focus is on managing projects A project manager is in charge of the project Requirements are documented and controlled Work products are identified and placed under configuration

management Work in planned, responsibilities are assigned, resources are

allocated All affected individuals agree to their commitments and are

trained to perform their task Measurements are made and analyzed to track progress

against the plan; corrective actions are taken as necessary Senior management has adequate visibility on progress Practices are retained during times of stress

CMMIfor Development


CharacteristicsMaturity Level 3 - Defined

Focus shifts to the organization Processes now belong to the organization All projects use the organization's standard software process or

an approved tailored version A formal focus (EPG) for process improvement exists Technical and management practices are documented, adequate

and applied, even under pressure Historical data are collected and measurements are made and

analysed to improve the process Training is planned at the organizational level Focus on early defect detection Shift from reactive to pro-active management (risk management)

EPG = Engineering Process Group

CMMIfor Development


At Level 4 the process is quantitatively managed Quality and process performance objectives are quantified Quantitative objectives are based on business objectives Quality and process performance is understood in statistical

terms “Special causes” of process variation are identified and corrective

actions taken (at project and process level) to prevent future occurrence

Knowledge and use of metrics and statistical techniques throughout the organisation (practitioners and management)

Process performance is quantitatively predictable

CharacteristicsMaturity Level 4 - Quantitatively Managed

CMMIfor Development


Focus shifts back to the organization, individuals The organization’s focus shifts from special to common

causes of poor performance, shifting mean performance and reducing variation

Continuous incremental and innovative process and technology improvement to meet business objectives

Effects of improvements are quantitatively predicted and measured

Change is institutionalized and belongs to all individuals in the organization

CharacteristicsMaturity Level 5 - Optimizing

CMMIfor Development


CMMIProcess Area

The CMMI for Development consists 22 Process Areas

Process Areas are NOT Processes

Process Areas define requirements that must be satisified by Processes implemented in an organization

CMMIfor Development


CMMICategories of Process Areas (Continuous)

Process ManagementOrganizational Process Focus 3

Organizational Process Definition + IPPD 3Organizational Training 3

Organizational Process Performance 4Organizational Innovation and Deployment 5

Project Management2 Project Planning2 Project Monitoring and Control2 Supplier Agreement Management3 Integrated Project Mgmt + IPPD3 Risk Management4 Quantitative Project ManagementSupport

Configuration Management 2Process and Product Quality Assurance 2

Measurement and Analysis 2Decision Analysis and Resolution 3

Causal Analysis and Resolution 5

Engineering2 Requirements Management3 Requirements Development3 Technical Solution3 Product Integration3 Verification3 Validation

IPPD = Integrated Product and Process Development

CMMIfor Development


CMMIProcess Managements PAs

OPF Organizational Process Focus – Plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.

OPD Organizational Process Definition + IPPD – Establish and maintain a usable set of organizational process assets and work environment standards

OT Organizational Training – Develop the skills and knowledge of people so they can perform their roles effectively and efficiently

OPP Organizational Process Performance – establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes in support of quality and process performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization projects

OID Organizational Innovation and Deployment – Select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. The improvements support the organization’s quality and process performance objectives as derived from the organization’s business objectives

CMMIfor Development


CMMIProject Management PAs

PP Project Planning – establish and maintain plans that define project activities

PMC Project Monitoring and Control – provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan

SAM Supplier Agreement Management – manage the acquisition of products from suppliers

IPM Integrated Project Management + IPPD – establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes

RSKM Risk Management – identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives

QPM Quantitative Project Management – quantitatively manage the project’s defined process to achieve the project’s established quality and process performance objectives

CMMIfor Development


CMMIEngineering PAs

REQM Requirements Management – manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project’s plans and work products

RD Requirements Development – produce and analyze customer, product, and product component requirements

TS Technical Solution – design, develop, and implement solutions to requirements. Solutions, designs, and implementation encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate

PI Product Integration – assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product

VER Verification – ensure that selected work products meet thier specified requirements

VAL Validation – demonstrate thata product or product component fullfills its intended use when placed in its intended environment

CMMIfor Development


CMMISupport PAs

CM Configuration Management – establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting , and configuration audits.

PPQA Process and Product Quality Assurance – provide staff and management with objective insight into processes and associated work products

MA Measurement and Analysis – develop and sustain a measurement capability that is used to support management information needs

DAR Decision Analysis and Resolution – analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria

CAR Causal Analysis and Resolution – identify causes of defects and other problems and take action to prevent them from occurring in the future

CMMIfor Development


CMMIProcess Areas by Maturity Level (Staged)

Requirements ManagementProject PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management

2 Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process Definition + IPPDOrganizational TrainingIntegrated Project Management + IPPDRisk ManagementDecision Analysis and Resolution

3

Organizational Process PerformanceQuantitative Project Management

4 Organizational Innovation and DeploymentCausal Analysis and Resolution

5

Process Areas at lower levelmust be addressed beforeProcess Areas at higher levels

IPPD = Integrated Product and Process Development

CMMIfor Development


CMMIProcess Areas Map

CM

OPF OPD

MA

OT

OID

OPP

PPQAPMCPP

IPM

SAM

RSKM

QPM

REQM

RDTS

PIVER

VAL

DAR

CAR

Process Project Engineering Support

ML 5

ML4

ML3

ML2

CMMIfor Development


CMMI Continuous RepresentationCapability Profile

0

1

2

3

4

5

RM PP PMC CM SAM QA MA OPF OPD OT

Capability Level 1-5 for each process area

CMMIfor Development


CMMI Staged Representation5 Maturity Levels

22Managed

Projects haveDisciplined

Process

33Defined

OrganisationalStandardProcess

44QuantitativelyManaged

Measured,Predictable

Process

55Optimizing

ContinuouslyImprovingProcess

A Maturity Level is assigned toan organization and is anevolutionary plateau in process maturity

Practices at a lower level must beestablished to enable practices at

a higher level to be efficient and effectivehttp://www.sei.cmu.edu

11Initial

Ad hocChaotic

CMMIfor Development


Capability Level

Continuous Representation

0 Incomplete 1 Performed 2 Managed 3 Defined 4 Quantitatively Managed 5 Optimizing

CMMICapability/

Maturity Levels

Maturity Level

Staged Representation

1 Initial 2 Managed 3 Defined 4 Quantitatively Managed 5 Optimizing

For each process area For the entire organization

0

1

2

3

4

5

RM PP PMC CM SAM QA MA OPF OPD OT

2233

4455

11

CMMIfor Development


Continuous or Staged RepresentationBenefits

Continuous Allows selecting order of improvement that best meets an

organization’s business objectives Enables detailed comparison on a process area by

process area basis Easy migration from older continuous models

Staged Proven sequence of improvements, from basic practices

following predefined path of successive levels Enables global comparison among organizations based on

a single rating (1-5) Easy migration from SW-CMM

CMMIfor Development


CMMIProcess Areas Definition

22 Process Areas (version 1.2) Specific and Generic Goals Specific and Generic Practices

Process Areas are the same in the two representations

Process Area

Specific Goals Generic Goals

Specific Practices Generic Practices

CMMIfor Development


CMMIGoals

Specific Goals Unique characteristics of process areas that must be

implemented to satisfy the process area

Generic Goals Generic goals appear in all process areas

Goals are required model components Essential to achieving process improvement Used to determine organizational maturity

CMMIfor Development


CMMIPractices

Specific practices Activities that are considered important in achieving the

associated specific goal

Generic practices Generic practices provide institutionalization to ensure that

the processes associated with the process area will be effective, repeatable and lasting

Practices are expected components Explain what will typically be done to achieve a goal Do not specify how Guide model users and appraisers Alternatives are possible

CMMIfor Development


CMMISpecific Goals and Practices - Examples

Process Area: Project Planning (PP)

Specific Goal SG1: Establish Estimates

Specific Practices SP1.1 Establish a top-level WBS to estimate the scope of

the project SP1.2 Establish and maintain estimates of attributes of the

work products and tasks SP1.3 Define the project lifecycle on which to scope the

planning effort SP1.4 Determine estimates of effort and cost

CMMIfor Development


CMMIGeneric Goals and Practices ML/CL 2

Generic Goal GG2: Institutionalize a Managed Process

Generic Practices GP2.1 Establish an organizational policy GP2.2 Plan the process GP2.3 Provide resources GP2.4 Assign Responsibility GP2.5 Train people GP2.6 Manage Configurations GP2.7 Identify and involve relevant stakeholders GP2.8 Monitor and control the process GP2.9 Objectively evaluate adherence G2.10 Review status with higher level management

Stakeholder = individual or group affected by or accountable for the outcome of an activity

Policy = guiding principle, typically established by higher management

CMMIfor Development


CMMIGeneric Goals and Practices ML/CL 3

Generic Goal GG3: Institutionalize a Defined Process

Generic Practices GP3.1 Establish a defined process

Establish and maintain the description of a defined process, i.e. a process tailored from the organizational standard process using organizational tailoring guidelines

GP3.2 Collect Improvement InformationCollect wok products, measures, measurement results, and improvement information derived from planning and performing the process to support future use and improvement of the organization’s processes and process assets

CMMIfor Development


CMMIRecursion – some examples

Project Planning

Process Areas Generic Practices

Project Monitoring and Control

Configuration Management

Organizational Process Definition

GP2.2 Plan the Process

GP2.6 Manage Configurations

GP2.8 Monitor and Control the Process

GP3.1 Establish a Defined Process Integrated Project Management

GP2.3 Provide Resources

Many Process Areas address institutionalization by supporting the implementation of generic practices

CMMIfor Development


CMMIProcess Areas supporting GP2.x

CM

OPF OPD

MA

OT

OID

OPP

PPQAPMCPP

IPM

SAM

RSKM

QPM

REQM

RDTS

PIVER

VAL

DAR

CAR


ML 5

ML4

ML3

ML2GP2.1 is not supported by a PA!

CMMIfor Development


CMMIProcess Areas supporting GP3.x

CM

OPF OPD

MA

OT

OID

OPP

PPQAPMCPP

IPM

SAM

RSKM

QPM

REQM

RDTS

PIVER

VAL

DAR

CAR


ML 5

ML4

ML3

ML2

CMMIfor Development


CMMIRecursion

Recursion is especially interesting for the generic practices in a process area that are supported by that process area

For example:GP2 Plan the process in process area Project Planning

This means that Project planning itself must also be planned Project monitoring and control must be monitored and

controlled Objective evaluation must be objectively evaluated Trainers must be trained ….

Beware of “turtles all the way down”

CMMIfor Development


ExerciseCreate a new Process Area

Using the CMMI framework new process areas can be created

The specific goals and practices at capability level 1 must obviously be defined specifically

The generic goals and practices at capabiliity levels 2 through 5 are taken from the framework

CMMIfor Development


Creating a new Process AreaExample: IT Security

Generic Practices at CL2 Establish an organizational policy for managing IT security Plan the IT security process Provide adequate resources for performing the IT security

activities Assign responsibility and authority (IT Security Officer) Train the people performing or supporting the IT security

activities Place designated work products of the IT security activities

under configuration management

CMMIfor Development


Creating a new Process AreaExample: IT Security (2)

Generic Practices at CL2 (continued) Identify and involve the relevant stakeholders for IT security Monitor and control the IT security activities against the

plan and take appropriate corrective action Objectively evaluate adherence of IT security process

against process description, standards, and procedures, and address noncompliance

Review the activities for IT security with higher level management and resolve issues

CMMIfor Development


CMMIConcluding Remarks

Process Area ≠ Process Process Areas must not necessarily be mapped to processes;

the practices must be embedded in the processes

Process Area ≠ Life Cycle Stage Process Areas do not define life cycle phases; e.g.

Requirements Development is not necessarily a stage

Orthogonal Structure Some practices are supported by Process Areas; e.g. training,

planning, monitoring, configuration management

What, not how The CMMI defines what must be done not how

CMMIfor Development


Overview


Software Development Processes


Critique

CMMIfor Development


CMMIAreas of Concern

Interferes with creativity

Easily slides into bureaucracy

Is only applicable to large projects

Does not support agile responsiveness to change

Is too expensive (especially for small organizations)

May divert attention to maturity improvement instead of performance improvement

CMMIfor Development


Readin

gCMMI Models and other CMMI assets can be downloaded from

http://www.sei.cmu.edu/cmmi/

CMMI®: Guidelines for Process Integration and Product Improvement, 2nd edition, Mary Beth Chrissis, Mike Konrad, and Sandy Shrum, SEI Series in Software Engineering, Addison-Wesley, 2007.

Documents

1 / 66 ©Jozef De Man 2007 CMMI for Development Capability Maturity Model Integration for Development Prof. Dr. ir J. De Man