Software Process Improvement Efforts at the U S Census Bureau

1
Software Process Improvement Efforts at theU S
Census Bureau
Howard Hogan Ellen Soper
2
Experience of the Economic Directorate
3
Moral of the Story

• Continuous improvement is hard to see.
• Dont get discouraged.

4
Overview

• Culture Environment
• CMM
• Meta-planning
• Planning
• Future

5
Some History

• 1951 UNIVAC I
• Programmers were statisticians
• Statisticians were programmers

6
Culture

• No tradition of written schedules
• No tradition of written resource estimates

7
Culture

• A tradition of specifications
• Users often also use files, data bases themselves
• Users often applications (SAS) experts
• Software Engineers often highly knowledgeable of
  survey processes
• Years of direct interaction

8
Economic SurveysEnvironment

• On-going surveys
• StEPS
• 5 Divisions
• 3 Subject matter
• 1 Planning and coordination
• 1 Software engineering

9
On-Going Surveys

• Monthly Quarterly Surveys
• Annual Surveys
• Periodic Surveys
• Monthly and annual production
• Maintenance of legacy systems

10
StEPS

• Standard
• Economic
• Processing
• System

11
StEPS

• All-inclusive processing system
• Written in SAS, running on Unix

12
Projects Activities

• StEPS Maintenance
• StEPS Migrations
• New StEPS functionality
• Legacy production and Maintenance

13
Existing Groups

• User group
• Design Architecture Review Board
• StEPS Manager
• Failed Change Control Board

14
Change Request Sources

• Remedy
• Users
• Software developers
• Division Chiefs
• New Projects

15
Perceived Problems

• Slipping schedule
• Little user understanding of resource constraints

16
Structural Problems

• No formal trade off among requirements
• Change control board broke down under weight of
  trivial changes lack of enforcement
• No one to say no

17
What is SW-CMM?

• The Software Capability Maturity Model (CMM) was
  developed by the Software Engineering Institute
  (SEI) of Carnegie Mellon University.
• The CMM is a model used in assessing and
  improving software development processes.

18
The Five Levels of Software Process Maturity
Focus on process improvement
Process measured and controlled
Process characterized, fairly well understood
Projects can repeat previously mastered tasks
Process unpredictable and poorly controlled
19
The Key Process Areas for Level 1
Optimizing
Process is informal and unpredictable
Managed
1
Defined

• No key process areas

Repeatable
Initial
20
The Key Process Areas for Level 2
Project management is in place performance is
repeatable

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

Repeatable
21
What it means to be Level 2

• Procedures are documented and followed
• Realistic project commitments
• Management tracks software schedules, and
  functionality against plans
• Software work products are baselined
• Strong customer/sponsor relationships
• Projects can have their own unique processes
• Requirements are documented and tracked

22
Pilot

• SMASM
• Services Monthly Annual Sample Maintenance
• Quarterly sampling of new establishments

23
SMASM Lessons Learned

• Well accepted by participants
• Showed full model could work
• Used more resources than ordinarily available
• Did not involve those with normal planning
  responsibility

24
Meta-Planning

• Planning on how to plan
• Developing a schedule on when to develop a
  schedule
• Managing the management process

25
Meta-Planning

• Managing the software development improvement
  process is a project in itself.
• It should be treated as a project.

26
Meta-Planning

• Base lining
• Organizing management group
• Gathering resources
• Developing a management structure
• Developing a meta-planning schedule
• Developing templates, policies, training

27
Organizing management group

• Inter-divisional
• Multi-leveled
• 2 Division Chiefs
• 2 Assistant Division Chiefs
• 2 Branch Chiefs
• Builds on existing management structure
• Did not replace existing working relationships

28
Gathering resources

• Software process improvement expert
• Project coordinator
• More, more, more

29
Developing a meta-planning schedule

• What policies, templates, guidelines, schedules
  have to be developed?
• Who will develop them?
• When will they be developed by?
• How will they look?
• Where will they be stored?

30
Developing templates, policies, training

• Choosing a philosophy and approach
• Consistent with goals
• Consistent with resources
• Consistent with culture
• First efforts must be successful
• First efforts should not be mission critical
• First efforts should not be burdensome
• Look for allies, friends, supporters

31
Planning

• Charters
• Project Planning and Tracking
• Developing requirements
• Change control
• Issues tracking
• Schedule

32
Charters

• What is not in scope
• How to develop milestone dates when requirements
  are unknown
• How to get sign-off

33
Project Planning and Tracking
34
Developing Requirements

• Team Chartered
• Extensive Training
• A Major Challenge

35
Change control

• We require a better process for resolving
  problems at lowest levels.
• With different sizes
• Quick and easy fixes
• Median requirement, which could add up
• Major projects

36
Issues tracking

• Harder than we thought
• Tracking both planning issues and sustentative
  issues
• Needed to assign someone with primary
  responsibility

37
Schedule

• Unified schedule at appropriate level
• When to baseline
• New requirement always coming in
• Better to wait until we know more

38
Future Planning Issues

• Pilots II
• Training and roll-out
• Support resources
• Buy-in
• PSP/TSP Pilots

39
Moral of the Story

• Continuous improvement is hard to see.
• Dont get discouraged.

40
Howard Hogan

• hhogan_at_census.gov