SEI Capability Maturity Model.ppt Software Engineering

2
SEI Capability Maturity
Model (CMM)
 Developed by Software
Engineering Institute (SEI) of the
Carnegie Mellon University, USA:
• To assist the U.S. Department of
Defense (DoD) in software
acquisition.
• The rationale was to include:
 Likely contractor performance as a
factor in contract awards.

3
Model
 Major DoD contractors began CMM-based
process improvement initiatives:
• As they vied for DoD contracts.
 SEI CMM helped organizations:
• Helped Improve quality of software they
developed
• Realized adoption of SEI CMM model had
significant business benefits.
 Other organizations adopted CMM.

4
Model
 In simple words:
• CMM is a model for apprising the
software process maturity of a
contractor into different levels.
• Can be used to predict the most
likely outcome to be expected:
 from the next project that the
organization undertakes.

5
Model
 Can be used in two ways:
• Capability evaluation
• Software process assessment.

6
Capability Evaluation
Provides a way to assess
the software process
capability of an organization:
• Helps in selecting a contractor
• Indicates the likely contractor
performance.

7
Software Process
Assessment
 Used by an organization to
assess its current process:
• Suggests ways to improve the
process capability.
• This type of assessment is for
purely internal use.

8
Model
 The SEI CMM classifies software
development industries into:
 Five maturity levels.
 Stages are ordered so that
improvements at one stage provide
foundations for the next.
 Based on the pioneering work of Philip
Crosby.

9
Model
Initial (1)
Repeatable (2)
Defined (3)
Managed (4)
Optimizing (5)

10
Level 1: (Initial)
 Organization operates
• Without any formalized process
or project plans
 An organization at this level is
characterized by
• Ad hoc and often chaotic
activities.

11
Level 1: (Initial)
 Software production processes are
not defined,
• Different engineers follow their own
process
• Development efforts become chaotic.
• The success of projects depend on
individual efforts and heroics.

12
Level 2: (Repeatable)
 Basic project management practices
• Tracking cost, schedule, and
functionality are followed.
 Size and cost estimation techniques:
• Function point analysis, COCOMO, etc.
used.
 Production process is ad hoc:
• Not formally defined
• Also not documented.

13
Level 2: (Repeatable)
 Process used for different projects
might vary between projects:
• Earlier success on projects with
similar applications can be repeated.
• Opportunity to repeat process exist
when a company produces a family of
products.

14
Level 3: (Defined)
 Management and development
activities:
• Defined and documented.
• Common organization-wide
understanding of activities,
roles, and responsibilities.

15
Level 3: (Defined)
 The process though defined:
• Process and product qualities
are not measured.
 ISO 9001 aims at achieving
this level.

16
Level 4: (Managed)
 Quantitative quality goals for products
are set.
 Software process and product quality
are measured:
• The measured values are used to control
the product quality.
• Results of measurement used to evaluate
project performance:
 Rather than improve process.

17
Level 4: (Managed)
 Organization sets quantitative
quality goals.
 World-wide about 100
organizations assessed at this
level.

18
Level 5: (Optimizing)
 Statistics collected from process
and product measurements are
analyzed:
• Continuous process improvement
based on the measurements.
 Known types of defects are prevented
from recurring by tuning the process
 Lessons learned from specific projects
incorporated into the process

19
Level 5: (Optimizing)
 Identify best software engineering
practices and innovations:
• Tools, methods, or process are
identified.
• Transferred throughout the
organization.
 World-wide about 500 organizations have
been assessed at this level.

20
Key Process Areas
 Each level is associated
with a key process area
(KPA) identifies:
• Where an organization at the
previous level must focus to
reach this level.

21
Level 2 KPAs
 Software project planning:
• Size, cost, schedule.
• Project monitoring
 Configuration management
 Subcontract management

22
Level 3 KPAs
 Process definition and
documentation.
 Reviews
 Training program

23
Level 4 KPAs
Quantitative measurements.
Process management.

24
Level 5 KPAs
 Defect prevention.
 Technology change
management.
 Process change management.

25
Comparison Between ISO
9001 and SEI CMM
 ISO 9001 awarded by an
international standards body:
• Can be quoted in official
documents and communications.
 SEI CMM assessment is purely
for internal use.

26
Comparison Between ISO 9001
and SEI CMM
 SEI CMM was developed
specifically for software industry:
• Addresses many issues specific to
software industry.
 SEI goes beyond quality assurance
• Aims for TQM.
• ISO 9001 correspond to SEI level 3.

27
Comparison Between ISO
9001 and SEI CMM
 SEI CMM provides a list of key areas:
• On which to focus to take an organization
from one level to the other
 Provides a way for gradual quality
improvements over several stages.
• e.g trying to implement a defined process
before a repeatable process:
 Counterproductive as managers are overwhelmed
by schedule and budget pressure.

28
CMMI (CMM
Integration)
 CMMI is the successor of the CMM.
 The CMM was developed from 1987 until
1997.
 In 2002, CMMI Version 1.1 was released.
• Version 1.2 followed in August 2006.
 The goal of the CMMI to integrate many
different models into one framework.
• It was created by members of industry,
government and the SEI.

29
Remarks on Quality
Model Usage
 Highly systematic and measured approach to
software development process suits certain
circumstances
• Negotiated software, safety-critical software,
etc.
 What about small organizations?
 Typically handle applications such as internet, e-comm.
 Without an established product range,
 Without revenue base, experience on past projects,
etc.
 CMM may be incompatible

30
Small Organizations
 Small organizations tend to believe:
• We are all competent people hired to
do a job, we can’t afford training.
• We all communicate with one another.
 Osmosis works because we are so close.
• We are all heroes:
 We do what needs to be done.
 Therefore rules do not apply to us.

31
Small Organizations
 Often have problems:
• Undocumented requirements
• Inexperienced managers
• Documenting the product
• Resource allocation
• Training
• Peer reviews

32
Small Organizations
 A two week CMM-based appraisal is
probably excessive:
 Small organizations need to operate
more efficiently at lower levels of
maturity
• Must first fluorish if eventually they
are to mature

33
Personal Software
Process (PSP)
 Based on the work of Humphrey.
 PSP is a scaled down version of
industrial software process:
• Suitable for individual use.
 Even CMM assumes that engineers
use effective personal practices.

34
Personal Software
Process (PSP)
 A process is the set of steps for doing
a job.
 The quality and productivity of an
engineer
• Largely determined by his process
 PSP framework:
• Helps software engineers to measure and
improve the way they work.

35
Personal Software
Process (PSP)
 Helps developing personal skills and
methods.
• Estimating and planning method.
• Shows how to track performance against
plans.
• Provides a defined process;
 Can be fine tuned by individuals.
 Recognizes that a process for individual use is
different from that necessary for a team
project.

36
Time Management
 Track the way you spend time:
• Boring activities seem longer then actual.
• Interesting activities seem short.
 Record time for:
• Designing
• Writing code
• Compiling
• Testing

37
Personal Software
Process (PSP)
Planning
Design
Code
Compile
Test
Postmortem
Logs
Project plan
summary

38
PSP-Planning
 Problem definition
 Estimate max, min, and total LOC
 Determine minutes/LOC
 Calculate max,min, and total
development times
 Enter the plan data in project plan
summary form
 Record the planned time in Log

39
PSP-Design
 Design the program.
 Record the design in specified
format.
 Record the Design time in time
recording log.

40
PSP-Code
 Implement the design.
 Use a standard format for code
text.
 Record the coding time in time
recording log.

41
PSP-Compile
 Compile the program.
 Fix all the defects.
 Record compile time in time
recording log.

42
PSP-Test/Postmortem
 Test:
• Test the program.
• Fix all the defects found.
• Record testing time in time recording log.
 Postmortem:
• Complete project plan summary form with
actual time and size data.
• Record postmortem time in time record.

43
Personal Software
Process (PSP)
PSP 0
PSP 1
PSP 2
PSP 3
 Personal measurement
 Basic size measures
Personal planning
 Time and schedule
 Personal quality management
 Design and code reviews
 Personal process
evolution

SEI Capability Maturity Model.ppt Software Engineering

More Related Content

Similar to SEI Capability Maturity Model.ppt Software Engineering (20)

More from uthayashangar1 (17)

Recently uploaded (20)

SEI Capability Maturity Model.ppt Software Engineering