MATURATION OF PROCESSES
AND MATURITY MODELS
Presenter Name
Presentation Date
Capability Maturity Model
• Developed in preliminary form by Watts
Humphries (published in a book he wrote that
appeared in 1989)
• Refined by the SEI (Software Engineering
Institute) , a spin-off of Carnegie Mellon
University in Pittsburgh
• Known as the CMM
• Discussed in Schwalbe, page 344-347 (approx)
Immature Software Organizations
• Processes are ad hoc, and occasionally
chaotic.
• Processes are improvised by practitioners ON
THE FLY.
• Testing, reviews and walkthroughs usually
curtailed under stress.
• Quality is unpredictable.
Immature Software Organizations,
Cont’d
• Costs and schedules are usually
exceeded.
• Reactionary management is usually
firefighting.
• Success rides on individual talent and
heroic effort.
• Technology benefits are lost in the
noise.
Mature Software Organizations
•
•
•
•
Processes are defined and documented.
Roles and responsibilities are clear.
Product and process are measured.
Processes and projects finish on time and
within budget
• Management has time to plan, monitor, and
communicate.
Mature Software Organizations,
Cont’d
• Quality, costs, and schedules are
predictable
• Management committed to continuous
improvement.
• Technology is used effectively within
defined processes.
Software Process Definition
•
•
•
•
•
•
Project Planning
Project Management
Software Engineering Procedures
Software standards
Software Quality Evaluation
Software Configuration management
The Five Levels of Software
Process Maturity
•
•
•
•
•
INITIAL
REPEATABLE
DEFINED
MANAGED
OPTIMIZING
Five Levels
Initial
•
•
•
•
Software processes are ad hoc, even chaotic
The software processes are not defined
Success depends on individual effort
The environment is not stable
Initial, Continued
• The benefits of software engineering
practices are undermined
• Planning is nonexistent or ineffective
• Process capability is unpredictable because
the software process is constantly changed or
modified as the work progresses
Repeatable
• Basic project management policies and
procedures are established
• Cost, schedule and functionality (scope) are
tracked by module and task
• A process discipline is put in place to repeat
earlier successes
• Managing new projects is based on
experience with similar projects
Repeatable, Continued
• Basic software management controls are
installed
• Estimations of cost and time to complete are
based on history for similar projects
• Problems are identified and documented
• Software requirements are baselined (made
tough to change)
Repeatable, Continued
• Project standards are defined
• Project teams work with their customers and
subcontractors to establish stable, managed
working environments
• Process is under the control of a project
management system that is driven by
performance on previous projects
• A project performance database is defined
and populated
Defined
• Software processes are documented
• Software processes are standardized and
integrated organization-wide
• All projects use documented and approved
versions of the organization’s processes of
developing and maintaining software
• A Software Engineering Process Group (SEPG)
is created to facilitate process definition and
improvement efforts
Defined, Continued
• Organization-wide training programs are
implemented
• Organization-wide standard software
processes can be refined to encompass the
unique characteristics of the project
• A peer review process is used to enhance
product quality
• Process capability is stable and based on a
common understanding of processes, roles,
and responsibilities in a defined process
Managed
• Quantitative quality goals are defined
• Product quality and productivity are
measured and collected
• Both processes and products are
quantitatively understood
• Both processes and products are controlled
using detailed measures
• A productivity and quality database is
defined
Managed, Continued
• Projects achieve control by narrowing the
variation in performance to within
acceptable boundaries
• Process variation is controlled by use of a
strategic business plan that details which
product lines to pursue
• Risks associated with moving up the
learning curve of a new application domain
are known and carefully managed
• Process capability is measured and
Optimizing
• Continuous process improvement is enabled
by quantitative feedback
• Continuous process improvement is assessed
from testing innovative ideas and
technologies
• Weak process elements are identified and
strengthened
• Defect prevention is explicit
Optimizing, Cont’d
• Statistical evidence is available on process
effectiveness
• Innovations that exploit the best software
engineering practices are identified
• Improvement occurs from
– INCREMENTAL ADVANCEMENTS IN EXISTING
PROCESSES
– INNOVATIONS USING NEW TECHNOLOGIES AND
METHODS
How are firms doing??
• Many U.S. firms have reached the highest
level, OPTIMIZING
• Indian firms may be doing better
Organizational Project Management Maturity
Model (OPM3)
1. Ad-Hoc: The project management process is described as disorganized, and
occasionally even chaotic. The organization has not defined systems and
processes, and project success depends on individual effort. There are chronic
cost and schedule problems.
2. Abbreviated: There are some project management processes and systems in place
to track cost, schedule, and scope. Project success is largely unpredictable and
cost and schedule problems are common.
3. Organized: There are standardized, documented project management processes
and systems that are integrated into the rest of the organization. Project success is
more predictable, and cost and schedule performance is improved.
4. Managed: Management collects and uses detailed measures of the effectiveness of
project management. Project success is more uniform, and cost and schedule
performance conforms to plan.
5. Adaptive: Feedback from the project management process and from piloting
innovative ideas and technologies enables continuous improvement. Project
success is the norm, and cost and schedule performance is continuously
improving.
Enter CMMI: Capability Maturity
Model Integration
• In 2007, the SEI asserted that it would no
longer support the old SW-CMM.
• On Dec 31, 2007 all SW-CMM appraisal
results were expired
• The purpose of the CMMI was to focus
process maturity more towards project
performance
• Organizations must now upgrade to the
CMMI
• The CMMI is vastly improved over the CMM
CMMI Staged Representation - 5 Maturity Levels
Level 5
Optimizing
Process performance
continually improved through
incremental and innovative
technological improvements.
Level 4
Quantitatively
Managed
Level 3
Defined
Level 2
Managed
Level 1
Initial
Slide 24 of
146
Processes are controlled using
statistical and other quantitative
techniques.
Processes are well characterized and
understood. Processes, standards,
procedures, tools, etc. are defined at the
organizational (Organization X ) level.
Proactive.
Processes are planned, documented, performed,
monitored, and controlled at the project level. Often
reactive.
Processes are unpredictable, poorly controlled, reactive.
CMMI Origins
• The CMMI was derived from the
1. SW-CMM—capability maturity model for software
2. EIA/IS – electronic Industries Alliance Interim
Standard
3. IPD-CMM—Capability Maturity Model for
Integrated Product Development
1.CMMI architecture is open and designed to
accommodate additional disciplines, like
1. CMMI-DEV – processes for development
2. CMMI-ACQ—processes required for supplier
sourcing
CMMI: cap mat model integration
•
•
•
•
•
•
•
•
•
•
•
•
Level 0: Incomplete
No goal.
Level 1: Performed
The process supports and enables achievement of the specific goals of
the process area by transforming identifiable input work products to
produce identifiable output work products.
Level 2: Managed
The process is institutionalized as a managed process.
Level 3: Defined
The process is institutionalized as a defined process.
Level 4: Quantitatively Managed
The process is institutionalized as a quantitatively managed process.
Level 5: Optimizing
The process is institutionalized as an optimizing process.
Use of this tool has shown…
• The Engineering and Construction Industries
have a higher level of maturity than do the
information systems and software
development disciplines
New Employee Orientation
• Getting to know your new assignment
• Familiarizing yourself with your new
environment
• Meeting new colleagues
New Work
New
Environment
New
Colleagues
Welcome
Today’s Overview
1
• Familiarize yourself with
your new assignment
2
• Explore your new
environment
3
• Meet your new
colleagues
Learning Objectives
•
•
•
•
Technology
Procedure
Policies
Benefits
NEW WORK
New Work
The technology learning curve
New
Employee
1 yr
2 yr
3 yr
Who’s Who
Lead
Contact information
Jim
Jim@company.com
Dee
Dee@gcompany.com
Mavis
Mavis@company.com
Doug
Doug@company.com
Working Toward Mastery
Projects Worked On
Achieve
Mastery
Get
Experienced
Get Familiar
Time Spent
Doing Your Best Work
• Working from home
• Working offsite
• Technology
requirements
Case Study
• Jeremy
– His first day
– Mistakes made
– Successes achieved
– The moral of the story
Discussion
• What we can learn
from Jeremy
• Best practices
• Take-aways
Summary
• Define your challenges
– Technological as well as personal
• Set realistic expectation
– Mastery is not achieved overnight
• Keep your eye on the goal
– Mentorship programs
Resources
• <Intranet site text here>
<hyperlink here>
• <Additional reading material text here>
<hyperlink here>
• This slide deck and related resources:
<hyperlink here>
QUESTIONS?
APPENDIX