CMM Overview A Focus on Level 2

1
CMM OverviewA Focus on Level 2

• James R. Persse
• LightTouch Systems, Inc.

2
The Software Engineering Institutes Capability
Maturity Model
3
Reduce RiskThe UnknownIs Bad
4
What Introduces Risk?

• Unrefined Expectations
• Poor Planning
• Poor Oversight
• Floating process to build software

5
Sources of Risk

• Pressure to get the product out.
• Outside agencies force constraints on IT.
• Too much work and tight resources.
• Staff Turnover.

6
Can You Remove All Risk?No.But Over Time You
Can Remove A Lot
7
Remove Risk byImproving how you build software
By Examining The Steps You Follow. Then Working
to Make those Steps more Effective.
8
SoftwareProcess ImprovementEmerging as a big
concernin Fortune 500 IT shops
9
1996 StudyAverage Fortune 500 New Software
Project

• 189 Over Budget
• 222 Over Schedule
• 30 Incomplete Functionality

10
CMM is a Tool to address this situation
There are others ISO, Demings, Baldridge, etc.
11
The CMM Approach
12
Equation Theory

• High Risk Low Predictability
• Low Predictability Low Chance for Quality
• Maturity Low Risk High Predictability

13
Risk
Predictability
14
Software Process Improvement

• CMM is a means to an end

CMM
Goal SPI
15
Risk
Level 5
Level 4
Predictability
Level 3
Level 2
Level 1
16
Some Risk will always remain.With CMM you
manage Risk proactively.
17
Level is 2 is Step 1

• Its the beginning of an SPI program.
• You dont have to be extensive.
• You dont have to be perfect.

18
The Repeatable Level
A Good Way to Analyze how you build software is
to repeat what you do from project to project.
19
The Path to Improvement

• 1 Define a process.
• 2 Follow the process.
• 3 Study the results.
• 4 Keep what worked.
• 5 Throw out what didnt.
• 6 Start over again.

20
At Level 2You begin SPI by focusing on 5
areas.Key Process AreasAreas where you
develop processes you can repeat and study.
21
The Central Idea of Level 2
Look at what you do Throw out what does not work
well Keep what does work well Refine Repeat
22
Level 2 Key Process Areas

• Requirements Management
• Software Project Planning
• Software Project Tracking and Oversight
• Software Configuration Management
• Software Quality Assurance

23
What each KPA has in Common

• A Policy to show you are committed to doing
  certain things.
• A Structure (resources people and tools -- and
  funding) to carry it out.
• A Plan to document what you will do.
• A Process to follow for doing it.
• Training to prepare your people to act according
  to process.

24
Basic Level 2 Activityfor each KPA
Put the right people in place Have them develop
plans to predict activity Follow the plan Measure
how well it worked Refine Repeat
25
Requirements Management

• Work with Documented Requirements
• Have the team Review them and accept them
• Track them as they change

26
Requirements Management

• Person/People appointed to analyze
• Process to Analyze and Accept and Track

27
Software Project Planning

• Have Requirements and Statement of Work
• Get input/estimates from team
• Create a Plan
• Review the plan with the team before starting

28
Software Project Planning

• Assign a Planner
• Use a Template to create the plan
• Have a Process to derive estimates
• Have a Process to create the plan, review it and
  approve it.

29
Software Project Tracking Oversight

• Use the Plan as chief tool
• Regularly track actuals against planned -
  Status Meetings
• Adjust as necessary

30
Software Project Tracking Oversight

• Assign a Project Manager
• Use a Process to track progress
• Have a Process to make changes to the Plan

31
Software Configuration Management
Identify products to CM Configuration Manage
them Audit their integrity in the CM library
32

• Software Configuration Management
  Establish a Change Control Process Establish
  a Change Control Board

33
Software Configuration Management

• People to sit on the Change Control Board
• A Configuration Manager for the project
• A Change Control Process
• A Configuration Management Library
• A Process to Manage Use of the Library

34
Software Configuration Management

• A Process used to conduct Baseline Audits
• A Configuration Management Plan for the project
• A Template used to create the CM Plan
• A Process used to create, review, and approve the
  Plan.

35
Software Quality Assurance Identify
products and activities to audit Audit
them Report on the Results
36
Software Quality Assurance
A person appointed to serve as SQA analyst A
Template used to create an SQA Plan for the
project. A Process to follow to create, review,
and approve the Plan A Process used to conduct
SQA audits A Process used to handle
noncompliance
37
Basic Elements of CMM

• People in specific roles
• Plans
• Process to follow the Plans
• Measurements

38
Three Keys Simplicity Training/Underst
anding Consistency
39
Simplicity Start small start
easy Grow into the roles Expand when youre
ready
40
Training Educate your people at the
Start Give your team a common
understanding Provide on-going
assistance Not important to be perfect
41
Consistency Required for improvement Essent
ial for Team Direction The Key to Software
Process Improvement
42
CMM FlexibilityNot a Series of
RulesRecommendations you Implement How You See
Fit
43
CMM Relies on Your Professional Judgment

• You know best how your teams work
• Configure CMM to work in your way
• Understand the intention of CMM
• Do not read CMM as requirements

44
CMM is about Process --Not People

• Dont use CMM to judge performance
• Only use CMM to improve process
• There is a People-CMM but Cingular is adopting
  the SW-CMM.

45
CMM OverviewA Focus on Level 2

• James R. Persse
• LightTouch Systems, Inc.