1. Capability Maturity Model Integration for Development Prof. Dr. ir J
Capability Maturity Model Integration for Development Prof. Dr. ir J. De Man
CMMI
for Development

2. Product Development Main drivers
is a technical activity
Product Development
is also a business activity
Focus on
management aspects
Total Quality Management
of Manufacturing Process
Total Quality Management
of Product Development
Product Development is
a process
Modeling of
Software
Modeling of
of Development Processes
CMMI
for Development

3. Overview Total Quality Management Principles
Product Development Processes
Capability Maturity Model Integration
Critique
CMMI
for Development

4. Development Process Learning from Manufacturing
Routine
Predictable
Automated
Hierarchical
Precise Requirements
Creative
Uncertain
Human-intensive
Networking
Changing Requirements
Total Quality Management
Manufacturing Process
Total Quality Management
Development Process
Principles must be carefully
re-interpreted in this different context
CMMI
for Development

5. Total Quality Management Principles
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
CMMI
for Development

6. TQM Senior 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
CMMI
for Development

7. TQM Listen 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 existing features to satisfy supposedly new requirements
CMMI
for Development

8. TQM Process 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)
CMMI
for Development

9. TQM Quality 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
CMMI
for Development

10. TQM Continuous 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
CMMI
for Development

11. TQM Quantified 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)
CMMI
for Development

12. TQM Full 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
CMMI
for Development

13. TQM Quality 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
CMMI
for Development

14. TQM applied 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
CMMI
for Development

15. Overview Total Quality Management Principles
Product Development Processes
Capability Maturity Model Integration
Critique
CMMI
for Development

16. Product Development Basic Elements
Processes
automate and
ensure adherence to
perform
Processes are also the “glue” between the three elements
use
Tools&Technology
People
CMMI
for Development

17. Product Development Traditional View
Processes are individual and ad hoc
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
CMMI
for Development

18. Product Development Evolved View
Process quality determines product quality
Processes shared through the organization capture best practices
People must adhere to processes
People focus on continuously improving processes
Tools automate processes
Tools ensure adherence to processes
CMMI
for Development

19. The People factor Processes 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 skills by accident but processes must be established to manage this
CMMI
for Development

20. 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)
CMMI
for Development

21. Processes and 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 International
Conference of Software Engineering, pg 2-13, Monterey CA, March 1987.
L Osterweil. Software Processes are Software Too, revisited: An Invited Talk on the
Most Influential Paper of ICSE9, ICSE 1997 pg
CMMI
for Development

22. Model Driven Software Development Process Model
ERA
The Process Model Hierarchy is an example of
Model Driven Software Development.
The upper levels of the hierarchy define the generic
part of the software.
Specific applications are generated by supplying
a data structure with the lower-level model definition
Process Model
Process Description
Project/Process
CMMI
for Development

23. Process a simple model How? Activity Who? Role Work Product Milestone
Subactivity
Leads
Performs
Activity
Start/End
Input
Output
Control
Who?
Creates
Reviews
Approves
Role
Work
Product
Milestone
Created
Approved
Released
What?
When?
part of
CMMI
for Development

24. Model Hierarchy Level 1: Process
Activity
Role
Work
Product
Milestone
instances
Project
Start
Iteration
Milestones
System
Architect
Project
Manager
Designers
Quality
Manager
CMMI
for Development

25. Model Hierarchy Level 0: Project
Role
Work
Product
Milestone
System
Architect
Project
Manager
Project
Start
Iteration
Milestones
Designers
Quality
Manager
instances
John Doe
John Doe
John Doe
14 Feb
2007
Jim Greene
CMMI
for Development

26. Process Modeling Why? Facilitates sharing with/understanding by people
Enables formal reasoning: completeness, consistency
Provides a foundation for (partial) automation
Provides a foundation for improvement
CMMI
for Development

27. Overview Total Quality Management Principles
Software Development Processes
Capability Maturity Model Integration
Critique
CMMI
for Development

28. The Quality Frameworks “Quagmire”
MIL STD-498,...
ITIL
Team
SW Process
People CMM
IPPD
IEEE standards
SW Capability
Maturity Model
Personal
SW Process
CMM Integration
Tickit
Trillium
ISO
Bootstrap
Spice
Malcolm Baldrige
Quality Award
TL 9000
Balanced
Scorecard
Six Sigma
European Foundation
for Quality Management
CMMI
for Development

29. 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 Services
The purpose of this side is to show the evolution of the CMM from primarily supporting mission critical software systems to all types of software development where cost, schedule, and quality are important.
The CMM is nothing new. It incorporates the teachings of Shewart, Crosby, Juran, and Demming. Their quality techniques have been applied to manufacturing for years and now are being applied to software.
Software management has resisted these techniques for years because SW cannot be touched of visualized like manufactured products.
The best practices from industry have been incorporated into the SW-CMM®.
The SEI is a Federally Funded Research and Development Center (FFRDC) established in 1984 at Carnegie Mellon University by the US Department of Defense
CMMI
for Development

30. 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
CMMI
for Development

31. CMMI Introduction 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
CMMI
for Development

32. 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
CMMI
for Development

33. 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
CMMI
for Development

34. Characteristics Maturity 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
These are the key Project Management activities associated with Level 2.
At Level 2 projects can fulfil the key practices in different ways as long as they are adequately documented and the process regularly followed.
CMMI
for Development 3

35. Characteristics Maturity 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)
As an organization moves to Level 3 there is a shift in responsibility for certain activities.
At Level 2 it was generally the projects responsibility.
At Level 3 the organization establishes a group (usually called the Engineering Process Group [EPG]) that is responsible for developing and maintaining the organization’s processes.
EPG = Engineering Process Group
CMMI
for Development 3

36. Characteristics Maturity Level 4 - Quantitatively Managed
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
An organization that moves to Level 4 is an organization that has stabilized its Level 3 processes and has sufficient information (data) and expertise to begin to set both process and product goals and measure them using quantitative techniques.
CMMI
for Development 3

37. Characteristics Maturity Level 5 - Optimizing
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
Note this is “optimizing” not “optimized”.
The organization is always looking for ways to improve and people are empowered to do just that.
CMMI
for Development 3

38. CMMI Process 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
CMMI
for Development

39. CMMI Categories of Process Areas (Continuous)
Process Management
Organizational Process Focus 3
Organizational Process Definition + IPPD 3
Organizational Training 3
Organizational Process Performance 4
Organizational Innovation and Deployment 5
Project Management
2 Project Planning
2 Project Monitoring and Control
2 Supplier Agreement Management
3 Integrated Project Mgmt + IPPD
3 Risk Management
4 Quantitative Project Management
Support
Configuration Management 2
Process and Product Quality Assurance 2
Measurement and Analysis 2
Decision Analysis and Resolution 3
Causal Analysis and Resolution 5
Engineering
2 Requirements Management
3 Requirements Development
3 Technical Solution
3 Product Integration
3 Verification
3 Validation
IPPD = Integrated Product and Process Development
CMMI
for Development

40. CMMI Process 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
CMMI
for Development

41. CMMI Project 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
CMMI
for Development

42. CMMI Engineering 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
CMMI
for Development

43. CMMI Support 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
CMMI
for Development

44. CMMI Process Areas by Maturity Level (Staged)
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management 2
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition + IPPD
Organizational Training
Integrated Project Management + IPPD
Risk Management
Decision Analysis and Resolution 3
Process Areas at lower level
must be addressed before Process Areas at higher levels
Organizational Process Performance
Quantitative Project Management 4
Organizational Innovation and Deployment
Causal Analysis and Resolution 5
IPPD = Integrated Product and Process Development
CMMI
for Development

45. CMMI Process Areas Map Process Project Engineering Support OID CAR
ML 5
ML4
ML3
ML2
OPP
QPM RD
DAR
OPF
OPD TS
IPM PI OT
RSKM
VER
VAL
REQM
PPQA PP
PMC MA CM
SAM
CMMI
for Development

46. CMMI Continuous Representation Capability Profile
Capability Level 1-5 for each process area
CMMI
for Development

47. CMMI Staged Representation 5 Maturity Levels
Optimizing
Continuously
Improving
Process
A Maturity Level is assigned to
an organization and is an
evolutionary plateau in process maturity 4
Quantitatively
Managed
Measured,
Predictable
Process 3
Defined
Organisational
Standard
Process 2
Managed
Projects have
Disciplined
Process 1
Initial
Ad hoc
Chaotic
Practices at a lower level must be
established to enable practices at
a higher level to be efficient and effective
CMMI
for Development

48. CMMI Capability/Maturity Levels
For each process area
For the entire organization 2 3 4 5 1
CMMI
for Development

49. Continuous or Staged Representation Benefits
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
CMMI
for Development

50. CMMI Process Areas Definition
Specific Goals
Generic Goals
Specific Practices
Generic Practices
22 Process Areas (version 1.2)
Specific and Generic Goals
Specific and Generic Practices
Process Areas are the same in the two representations
CMMI
for Development

51. CMMI Goals 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
CMMI
for Development

52. CMMI Practices 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
CMMI
for Development

53. CMMI Specific 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
CMMI
for Development

54. CMMI Generic 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
Policy = guiding principle, typically established by higher management
Stakeholder = individual or group affected by or accountable for the outcome of an activity
CMMI
for Development

55. CMMI Generic 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 Information Collect 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
CMMI
for Development

56. CMMI Recursion – some examples
Process Areas
Generic Practices
GP2.2 Plan the Process
Project Planning
GP2.3 Provide Resources
Project Monitoring and Control
GP2.6 Manage Configurations
Configuration Management
GP2.8 Monitor and Control the Process
Organizational Process Definition
GP3.1 Establish a Defined Process
Integrated Project Management
Many Process Areas address institutionalization by supporting the implementation of generic practices
CMMI
for Development

57. CMMI Process Areas supporting GP2.x
Process Project Engineering Support
OID
CAR
ML 5
ML4
ML3
ML2
OPP
QPM RD
DAR
OPF
OPD TS
IPM PI OT
RSKM
VER
VAL
REQM
PPQA
GP2.1 is not supported by a PA! PP
PMC MA CM
SAM
CMMI
for Development

58. CMMI Process Areas supporting GP3.x
Process Project Engineering Support
OID
CAR
ML 5
ML4
ML3
ML2
OPP
QPM RD
DAR
OPF
OPD TS
IPM PI OT
RSKM
VER
VAL
REQM
PPQA PP
PMC MA CM
SAM
CMMI
for Development

59. CMMI Recursion
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”
CMMI
for Development

60. Exercise Create 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
CMMI
for Development

61. Creating a new Process Area Example: 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
CMMI
for Development

62. Creating a new Process Area Example: 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
CMMI
for Development

63. CMMI Concluding 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
CMMI
for Development

64. Overview Total Quality Management Principles
Software Development Processes
Capability Maturity Model Integration
Critique
CMMI
for Development

65. CMMI Areas 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
CMMI
for Development

66. Reading
CMMI Models and other CMMI assets can be downloaded from
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.
CMMI
for Development