It is a brief introduction to capability maturity model which can be used by big companies to grow to next level and analyze their present position.

1. Capability Maturity
Model

2. What is CMM
 CMM: Capability Maturity Model
 CMM was developed and is promoted by the Software
Engineering Institute (SEI), a research and
development center sponsored by the U.S. Department
of Defense (D o D)since 1987.
 A procedure which is used to analyze and refine the
development process of an organization’s software.

3. What is CMM
 It provides guidelines to
further enhance the maturity of software development process.
 This also describes an
evolutionary strategy for software process improvement that
should be followed by moving through 5 different levels.

4. Why to use CMM
CMM
Capability Evaluation
Software Process
Assessment

5. Why to use CMM
 Capability Evaluation
 A capability level is a well-defined evolutionary
process describing the organization's capability
relative to a process area.
 Therefore, the results of the software process
capability assessment can be used to select a
contractor.

6. Why to use CMM
 Software Process Assessment
 Software process assessment is used by an organization to
improve its process capability.
 This type of evaluation is for purely internal use.

7. CMM Levels:
(The five levels of software process
maturity)
 Different levels of SEI CMM have been designed so that it is
easy for an organization to slowly build its quality system
starting from scratch.
Levels :
 Initial
 Repeatable
 Defined
 Managed
 Optimizing

8. Higher the level, mature the process is .

9. Level 1: Initial
 Very few or no processes are described and
followed.
 Success depends on individual effort.
 Capability is a characteristic of the individuals,
not of the organization.
 Products developed are often over budget and
schedule
 Wide variations in cost, schedule, functionality and
quality targets.

10. Level 2: Repeatable
 At this level, the basic project management practices such as
tracking cost and schedule are established.
 Size and cost estimation techniques like function point analysis,
COCOMO, etc. are used.
 Experience with earlier projects is used for managing new
similar natured projects.
 Opportunity to repeat a process exists only when a company
produces a family of products.

11. Level 3: Defined
 The software process for both management and
development activities is defined and documented.
 All projects use an approved, tailored version of the
organization’s activities, roles and responsibilities.
 The processes though defined, the process and product
qualities are not measured.

12. Level 4: Managed
 the focus is on software metrics (standards).
 Product metrics
 characteristics of the product being developed, such as its
size, reliability, time complexity, understandability, etc.
 Process metrics
 effectiveness of the process being used, such as average
defect correction time, productivity, average number of
defects found per hour inspection etc.
 quantitative quality goals are set for the organization for
software products as well as software processes.

13. Level 5: Optimizing
 This is the highest level of process maturity in
CMM. The key characteristic of this level is focusing
on continuous process improvement in the
organization using quantitative feedback.
 Process change Management
 Technology Change Management
 Defect Prevention

14. KEY PROCESS AREAS (KPAs)
 Except for level 1, each level is decomposed into key process
areas.
 Each maturity level is featured by several Key Process Areas that
contains the areas an organization should focus on improving its
software process to the next level.

15. CMM Level Focus Key Process Areas
1. Initial Competent people No KPAs
2. Repeatable Project management Software project
Planning
Software configuration
management
3. Defined Definition of processes Process definition
Training program
Peer reviews
4. Managed Product and process
quality
Quantitative process
metrics
Software quality
management
5. Optimizing Continuous process
improvement
Defect prevention
Process change
management
Technology change

16. Benefits of CMM
 SEI CMM provides a list of key process areas (KPAs) on which
an organization at any maturity level needs to concentrate to
take it from one maturity level to the next.
 Defines set of priorities for addressing software problems.
 Provides framework for consistency of processes and product.

17. Applicability of CMM
 For large organizations
 Highly systematic and measured approach to software
development.
 suits large organizations dealing with negotiated software,
safety-critical software, etc.
 For small organizations
 small organizations typically handle small applications like
internet and e-commerce and don’t have established
product range.
 These organizations need to operate more efficiently at the
lower levels of maturity.

18. Personal Software Process (PSP)
 Scaled down version of the industrial software process.
 Suitable for individual use.
 The process for individual use is different from that for a
team.
 SEI CMM does not tell software developers how to
analyze, design, code, test, or document software
products.
 but assumes that engineers use effective personal practices.
 PSP is a framework that helps engineers to measure and
improve the way they work.

19. PSP Time Measurement
 engineers should track the way they spend time.
 the actual time spent on a task should be measured with
the help of a stop-clock to get an objective picture of the
time spent.
 Because, boring activities seem longer than actual and
interesting activities seem short.

20. PSP Planning
 Engineers must estimate the maximum, minimum, and
the average LOC (lines of code) required for the product.
 They must record the plan data in a project plan
summary.

21. Measurements
 Historical
 Plan
 Actual
 Projections

22. Examples of measurements for
size of work products
 Estimated number of requirements
 Actual number of requirements
 Estimated source lines of code (SLOC)
 Actual SLOC
 Estimated number of test cases
 Actual number of test cases

23. Example of measurements of
effort
 Estimated man-hours to design/code a given module
 Actual man-hours expended for designing/coding the
module
 Estimated number of hours to run builds for a given
release
 Actual number of hours spent running builds for the
release

24. Consistent measurement provide
data for:
 Quantitatively expressing requirements, goals, and
acceptance criteria
 Monitoring progress and anticipating problems
 Predicting schedule, cost and quality