capability maturity model. history 1986 - effort started by sei and mitre corporation assess...
TRANSCRIPT
CapabilityCapabilityMaturityMaturityModelModel
History 1986 - Effort started by SEI and MITRE
Corporation assess capability of DoD contractors
First version published in 1991 has been reviewed by 100s of software professionals
closely related to TQM goal is customer satisfaction
not required that customer be "delighted"
LevelsLevels
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing
Level 1 : The Initial Level
ad hoc, sometimes chaotic
overcommitment leads to a series of crises
during a crisis, projects abandon plans
capability is characteristic of individuals, not the organization
when a good manager leaves, the success leaves with them
Level 2 : The Repeatable Level
planning based on experience with similar projects past successes can be repeated
policies for managing and implementation installed basic management controls track costs and schedules notice and deal with problems as they arise
Level 3 : The Defined Level
Standard Processes defined across the organization and used by all projects
standard set of roles, activities, quality tracking, etc each project uses a tailored version of this
standard process
Training Program is in place to ensure everyone has the skills required for their assigned role
Level 4 : The Managed Level
Quantitative Quality Goals for both Products and Processes
Organization-wide Process Database meaningful variations in process performance
can be distinguished from random noise actions are then taken to correct the situation
Products are of predictably high quality
Level 5 : The Optimizing Level
Organization has the means to identify weaknesses and strengthen the process proactively
teams analyze defects to determine cause, and disseminate lessons learned throughout the organization
major focus on eliminating waste (eg rework)
Defect preventionTechnology change managementProcess change management
Quantitative process managementSoftware Quality Management
Organization process focusOrganization process definitionTraining programIntegrated software managementSoftware product engineeringIntergroup coordinationPeer Reviews
Requirements managementSoftware project planningSoftware project tracking and oversightSoftware subcontract managementSoftware quality assuranceSoftware Configuration management
Key Process AreasKey Process Areasby maturity level
Don't skip levels
For example, collecting detailed data (level 4) is
meaningless unless the data is from projects that use a consistent process (level 3)
Level Comparison - People Level 1 - Initial
success depends on individual heroics fire fighting is the way of life
Level 2 - Repeatable people are trained and supported by management success depends on individuals
Level 3 - Defined people are trained for their role(s) groups work together
Levels 4 - Managed strong sense of teamwork in every project
Level 5 - Optimizing strong sense of teamwork across the organization everyone does process improvement
Level Comparison - Risk
Level 1 - Initial Just do it
Level 2 - Repeatable problems are recognized and corrected as they occur
Level 3 - Defined problems are anticipated and prevented, or impacts
minimized
Levels 4 and 5 sources of problems are understood and eliminated
Level Comparison - Measurement
Level 1 - Initial ad hoc data collection and analysis
Level 2 - Repeatable individual projects use planning data
Level 3 - Defined data collected for all processes data shared across projects
Levels 4 - Managed data standardized across the organization
Level 5 - Optimizing data used for process improvement
Some Fundamental Ideas
Process improvement is based on small steps, rather than revolutionary innovation.
CMM is not exhaustive or dictatorial.
CMM focuses on processes that are of value across the organization.
Benefits of using the model
helps forge a shared vision of purpose of process improvement within the organization
establishes common language for the software process
defines a set of priorities for attacking problems
supports measurement via reliable appraisals objective supports industry-wide comparisons
Risks of using the model
"All models are wrong; some models are useful."
Not a silver bullet.
Does not address all of the issues that are important for successful projects. For example
how to hire and retain good people expertise in the application domain
Obvious Question Alert…Obvious Question Alert…
Is CMM well-suited for everyone?
Criticisms of CMM CMM is well suited for bureaucratic organizations such as
government agencies and large corporations. Its formality is a hindrance to projects where time-to-market is
more important than quality.
No external body actually certifies a software development center as being CMM compliant. It is supposed to be an honest self-assessment.
Promotes process over substance. For example, emphasizing predictability over service provided to
end users.
en.wikipedia.com
Who uses CMM
75% of organizations are probably Level One. To get to Level Two, you must have control over
the requirements documents. Hence, shrink-wrap companies like Microsoft are Level One.
75% of Level Five organizations are in India.
And now...And now...
Lots of details!!!!Lots of details!!!!
Definitions
Each of the five CMM levels is composed of key process areas
each key process area is organized into five sections called common features
common features contain key practices
Common FeaturesCommon Features
1. Commitment to Perform
2. Ability to Perform
3. Activities Performed
4. Measurement and Analysis
5. Verifying Implementation
Defect preventionTechnology change managementProcess change management
Quantitative process managementSoftware Quality Management
Organization process focusOrganization process definitionTraining programIntegrated software managementSoftware product engineeringIntergroup coordinationPeer Reviews
Requirements managementSoftware project planningSoftware project tracking and oversightSoftware subcontract managementSoftware quality assuranceSoftware Configuration management
Key Process AreasKey Process Areasby maturity level
Objectives of Key Process Areas Level Two
Requirements Management necessary to build software that will satisfy the customer
Software project planning reasonable plans of what to do and when
Software project tracking and oversight visibility into project's progress
Software subcontract management select and effectively manage subcontractors
Software quality assurance process and product are reviewed to create visibility into the process
Software Configuration management baselines and traceability
Objectives of Key Process Areas Level Three
Organization process focus coordinating and improving the organization's process
Organization process definition institutionalize process data, criteria, training, etc
Training program develop skills to perform roles
Integrated software management integrate development and management activities into a coherent software process
(followup to level 2 tracking) Software product engineering
describe technical activities (e.g. write the SRS, design, coding, etc) Intergroup coordination
the development teams talks with engineering, marketing, etc Peer Reviews
remove defects
Objectives of Key Process Areas Level Four
Quantitative process management notice when performance falls outside of expected bounds
Software Quality Management quality goals, supported by plans
Level Five Defect prevention
identify causes of defects and prevent them from recurring Technology change management
identify, evaluate, and integrate beneficial technologies Process change management
continuous process improvement
Defect preventionTechnology change managementProcess change management
Quantitative process managementSoftware Quality Management
Organization process focusOrganization process definitionTraining programIntegrated software managementSoftware product engineeringIntergroup coordinationPeer Reviews
Requirements management
Software project planningSoftware project tracking and oversightSoftware subcontract managementSoftware quality assuranceSoftware Configuration management
Key Process AreasKey Process Areasby maturity level
Software Project Planning Goals Goals
1. Software estimates are documented for use in planning and tracking the software project.
2. Software Project activities and commitments are planned and documented.
3. Affected groups and individuals agree to their commitments related to the software project.
Software Project Planning1. Commitment to Perform Commitment 1 -- A project software manager is
designated to be responsible for negotiating commitments and developing the project's software development plan.
Commitment 2 -- The project follows a written organizational policy for planning a software project.
This policy typically specifies that:
1. The system requirements allocated to software are used as the basis for planning the software project.
2. The software project's commitments are negotiated between: the project manager, the project software manager, and the other software managers.
3. Involvement of other engineering groups in the software activities is negotiated with these groups and is documented.
4. Affected groups review the software project's: software size estimates, effort and cost estimates, schedules, and other commitments.
5. Senior management reviews all software project commitments made to individuals and groups external to the organization.
6. The project's software development plan is managed and controlled.
Software Project Planning2. Ability to Perform
Ability 1 -- A documented and approved statement of work exists for the software project.
Ability 2 -- Responsibilities for developing the software development plan are assigned.
Ability 3 -- Adequate resources and funding are provided for planning the software project.
Ability 4 -- The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility.
The statement of work covers: scope of the work, technical goals and objectives, identification of customers and end users, imposed standards, assigned responsibilities, cost and schedule constraints and goals, dependencies between the software project and other organizations, resource constraints and goals, and other constraints and goals for development and/or maintenance.
The statement of work is reviewed by: the project manager, the project software manager, the other software managers, and other affected groups.
The statement of work is managed and controlled.
Software Project Planning3. Activities Performed
Activity 1 -- The software engineering group participates on the project proposal team.Activity 2 -- Software project planning is initiated in the early stages of, and in parallel with, the overall project
planning.Activity 3 -- The software engineering group participates with other affected groups in the overall project
planning throughout the project's life.Activity 4 -- Software project commitments made to individuals and groups external to the organization are
reviewed with senior management according to a documented procedure.Activity 5 -- A software life cycle with predefined stages of manageable size is identified or defined.Activity 6 -- The project's software development plan is developed according to a documented procedure.Activity 7 -- The plan for the software project is documented.Activity 8 -- Software work products that are needed to establish and maintain control of the software project
are identified.Activity 9 -- Estimates for the size of the software work products (or changes to the size of software work
products) are derived according to a documented procedure.Activity 10 -- Estimates for the software project's effort and costs are derived according to a documented
procedure.Activity 11 -- Estimates for the project's critical computer resources are derived according to a documented
procedure.Activity 12 -- The project's software schedule is derived according to a documented procedure.Activity 13 -- The software risks associated with the cost, resource, schedule, and technical aspects of the
project are identified, assessed, and documented.Activity 14 -- Plans for the project's software engineering facilities and support tools are prepared.Activity 15 -- Software planning data are recorded.
Software Project Planning4. Measurement and Analysis
Measurement 1 -- Measurements are made and used to determine the status of the software planning activities.
Examples of measurements include: completions of milestones for the software project
planning activities compared to the plan; and work completed, effort expended, and funds
expended in the software project planning activities compared to the plan.
Software Project Planning5. Verifying Implementation
Verification 1 -- The activities for software project planning are reviewed with senior management on a periodic basis.
Verification 2 -- The activities for software project planning are reviewed with the project manager on both a periodic and event-driven basis.
Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for software project planning and reports the results.
Defect preventionTechnology change managementProcess change management
Quantitative process managementSoftware Quality Management
Organization process focusOrganization process definition
Training programIntegrated software managementSoftware product engineeringIntergroup coordinationPeer Reviews
Requirements managementSoftware project planningSoftware project tracking and oversightSoftware subcontract managementSoftware quality assuranceSoftware Configuration management
Key Process AreasKey Process Areasby maturity level
Training Program3. Activities Performed
Activity 1 -- Each software project develops and maintains a training plan that specifies its training needs.
Activity 2 -- The organization's training plan is developed and revised according to a documented procedure.
Activity 3 -- The training for the organization is performed in accordance with the organization's training plan.
Activity 4 -- Training courses prepared at the organization level are developed and maintained according to organization standards.
Activity 5 -- A waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform in their designated roles.
Activity 6 -- Records of training are maintained.
The training plan covers:
1. The specific training needed within the organization and when it is needed.
2. The training that will be obtained from external sources and training that will be provided by the training group.
3. The funding and resources (including staff, tools, and facilities) needed to prepare and conduct or procure the training.
4. Standards for instructional materials used in training courses developed by the training group.
5. The schedule for developing and revising the training courses that will be developed by the training group.
6. The schedule for conducting the training, based on the projected need dates and the projected number of students.
7. The procedures for: selecting the individuals who will receive the training, registering and participating in the training, maintaining records of the training provided, and collecting, reviewing, and using training evaluations and other training feedback.