maturation of processes and maturity models
Post on 04-Jan-2016
53 Views
Preview:
DESCRIPTION
TRANSCRIPT
MATURATION OF PROCESSES AND
MATURITY MODELSPresenter NamePresentation 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 operating within measurable limits
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 Emphasis is on business needs, integration and
institutionalization
Slide 24 of 146
CMMI Staged Representation - 5 Maturity Levels
Level 5
Initial
Level 1
Processes are unpredictable, poorly controlled, reactive.
Managed
Level 2
Processes are planned, documented, performed, monitored, and controlled at the project level. Often reactive.
Defined
Level 3 Processes are well characterized and understood. Processes, standards, procedures, tools, etc. are defined at the organizational (Organization X ) level. Proactive.
Quantitatively Managed
Level 4
Processes are controlled using statistical and other quantitative techniques.
Optimizing
Proce
ss
Mat
urity
Process performance continually improved through incremental and innovative technological improvements.
CMMI Origins• The CMMI was derived from the
1. SW-CMM—capability maturity model for software2. EIA/IS – electronic Industries Alliance Interim
Standard3. IPD-CMM—Capability Maturity Model for
Integrated Product Development
1.CMMI architecture is open and designed to accommodate additional disciplines, like1. CMMI-DEV – processes for development2. CMMI-ACQ—processes required for supplier
sourcing3. CMMI-SVC—processes required for services
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
• Familiarize yourself with your new assignment1
• Explore your new environment2
• Meet your new colleagues3
Today’s Overview
Learning Objectives
• Technology • Procedure• Policies• Benefits
NEW WORK
New WorkThe technology learning curve
New Em-
ployee
1 yr 2 yr 3 yr
Who’s Who
Lead Contact informationJim Jim@company.com
Dee Dee@gcompany.com
Mavis Mavis@company.com
Doug Doug@company.com
Time Spent
Proj
ects
Wor
ked
On
Get Familiar
Achieve Mastery
Working Toward Mastery
Get Experience
d
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
top related