1 Disciplined Software Engineering Watts S. Humphrey Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Sponsored by the

1

Disciplined Software EngineeringWatts S. Humphrey

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890

Sponsored by the U.S. Department of Defense© 2001 by Carnegie Mellon University

Carnegie Mellon University

Software Engineering Institute

© 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 2

A War Story - 1The team had 9 software and 4 hardware engineers.

They were charged with building a new hardware-software system.

This was to be a new communications line testing device.

Management told the team the product was critically needed in 9 months.


A War Story - 2Development of the prior product had taken two years.

Would this be another crisis project?• late• over cost• months of testing• lots of defects

Or could the team somehow succeed?

The key question: Is this an engineering team?


AgendaThe nature of engineering

The Personal Software Process (PSP)

The Team Software Process (TSP)

TSP costs and benefits

TSP introduction

Conclusions

SM Personal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie-MellonUniversity.

SM

SM


DefinitionEngineering is the practice of• optimally using science• to build or apply products• to the needs of humankind

While engineering is concerned with technology, engineers must provide solutions that are• timely• cost-effective• and of high quality


Why Plan?Planning is like design. Without a plan, engineers • waste time deciding what to do next• can’t tell where they are• focus on the wrong tasks• consistently produce late, poor-quality, and over-

budget products

With a plan, engineers can• negotiate rational schedules and resources• react to changing conditions• keep management informed• take the time to do the job the right way


Why Use a Defined Process?A process is much like a plan. It defines• the job steps• the principal measures• the framework for planning

Without a process, engineers do not have• a framework for making plans• a structure for measuring the work• a basis for analyzing their work


Why Measure and Track the Work?Measurements provide• a factual basis for analyzing the work• the historical data for planning• an objective assessment of job status

Without measurements, we are forced to rely on• opinion• mythology• power and politics


Why Measure Quality? There are no good measures of quality.

Without numbers, however, quality plans are just talk.

Measured quality programs work.

Software quality can be measured.• defect levels• usability• performance• function• user satisfaction, etc.


Why Improve?

People grow and mature.

The technology is evolving.

The world is changing faster than ever before.

Our choices are to• make change happen• watch change happen• wonder what happened


What Do We Need?

To produce consistently good work, we need 3 things.

We need engineers who do disciplined personal work.

We need engineers who can work effectively in teams.

We need engineering teams who act professionally, even under pressure.


PSP and TSP Principles - 1The basic PSP and TSP principles are that• Software work is challenging.• Without proper methods, it is much harder.• Sound software methods are not obvious.• Engineers must be taught these methods to use

them properly.• Unless management supports the use of these

methods, engineers will be able to use them. The PSP and TSP define and teach a family of software engineering, team, and management practices.


PSP and TSP Principles - 2Plan the work before committing to or starting the job.

Use a defined process.

Measure and track development time, size, and defects.

Plan, measure, and track program quality from the beginning of the job.

Analyze every job and use the results to improve the process.

Version # Course or Lecture or Module Info. - page 14

How PSP and TSP Build Engineering Teams

PSPSkill-building

TSPTeam-building

TSPTeam-working

TeamManagement

TeamMembers

TeamDisciplines

Personal measuresProcess disciplineEstimating & planningQuality management

Project goalsTeam rolesTeam processProject planBalanced plan

Risk analysisTeam communicationTeam coordinationStatus trackingProject reporting

Disciplined Engineering

Teams


Introducing Personal DisciplinesUntil they try it, most software professionals do not believe disciplined engineering will work for them.• They won’t try it without evidence.• They can’t get evidence without trying it.

The PSP course provides this experience.• Engineers write 10 programs.• They start with their current methods.• They advance in steps to the full PSP.• They gather data on every program.

They see from their own data that, with disciplined personal methods, they do better work.


The PSP Is an Evolving Process

PSP0•Current process•Basic measures

PSP1•Size estimating

•Test report

PSP2•Code reviews

•Design reviews

PSP3Cyclic development

Team Software Process

•Teambuilding •Risk management

•Project planning and tracking

PSP2.1 Design templates

PSP1.1•Task planning

• Schedule planning

PSP0.1•Coding standard

•Process improvementproposal

•Size measurement


Effort Estimation Results

111098765432100.2

0.3

0.4

0.5

0.6

0.7

Mean Time MisestimationPSP Level Average

Effort Estimation Accuracy Trend

Program Number

Esti

mate

d M

inu

tes -

Actu

al M

inu

tes /

Esti

mate

d M

inu

tes


Quality Results

111098765432100

10

20

30

40

50

60

70

80

90

100

110

120

Mean Compile + Test

PSP Level Mean Comp + Test

Defects Per KLOC Removed in Compile and Test

Program Number

Mean

Nu

mb

er

of

Defe

ct s

P

er

KLO

C


Productivity Results

1110987654321020

22

24

26

28

30

Mean LOC/HourPSP Level Average

Lines of (New and Changed) Code Produced Per Hour of Total Development Time

Program Number

Mean

LO

C /

H

ou

r


Design Time Results

111098765432100.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

Design

Code

Compile

Test

Time Invested Per (New and Changed) Line of Code

Program Number

Mean

Min

ute

s S

pen

t P

er

LO

C


Working In Teams

Most software work is done by teams of engineers.

The size and complexity of these teams will likely grow in the future.

Teamworking methods are known and well understood, but not obvious.

Teamworking can be taught.

Effective teams provide the support framework engineers need to maintain their personal disciplines.


The TSPThe TSP builds and guides cross-functional teams. It provides• a defined teambuilding process• a teamworking framework• a supportive management environment

It is designed for development and maintenance teams of 2 to 20 engineers.

It includes• a full set of process forms, scripts, and standards• standard team-member roles• a structured launch and tracking process• a team and engineer support system


TSP OverviewTSP projects can starton any phase.

Each phase starts with a launch or relaunch step.

The strategy is to• overlap phases • develop in increments • balance team workload• accelerate tasks

wherever possible

Postmortem

Requirements

Launch

High-LevelDesign

Relaunch

Implementation

Relaunch

Integrationand Test

Relaunch


The TSP Launch

Every TSP project starts with a launch.

The launch takes 4 days.• It is part of the project.• It is led by a trained team coach.• It immediately follows PSP training.

In the launch, the engineers• select personal roles• define their own processes• produce team and individual plans• balance these plans• assess and assign project risks


The Launch Process MeetingsDay 1

1. Establish Product and

Business Goals

2. Assign Rolesand Define Team Goals

Day 2

4. Build Top-down and

Next-Phase Plans

5. Developthe Quality

Plan

6. Build Bottom-up and

ConsolidatedPlans

Day 3

7. ConductRisk

Assessment

8. PrepareManagementBriefing and

Launch Report

LaunchPostmortem

Day 4

9. HoldManagement

Review

3. Produce Development

Strategy


Planning a TSP Project In the TSP, planning is done at three levels.

The team first makes overall project and quality plans.

Then, the team makes a detailed plan for the next project phase.

The engineers next produce detailed personal plans for the following phase.

Finally, the engineers balance their plans to evenly distribute the work and minimize the schedule.


TSP Planning

ProduceConceptual

Design

Make Size Estimates

Define Processand Tasks

Estimate Tasks

Estimate Weekly Time

EstimateDefectsInjected

EstimateYields

Make theEngineers’

Plans

BalanceTeam

Workload

ConceptualDesign

OverallProject

Plan

QualityPlan

DetailedEngineer

Plans

BalancedTeamPlans


Tracking a TSP ProjectThe detailed team and individual plans facilitate precise project tracking.

The team members regularly reassess project risks and devise mitigation actions.

In weekly team meetings, the engineers • report on task status• review the key risks• rebalance the workload

The team produces weekly management status reports.


TSP Project Tracking

QualitySummary

ScheduleStatus

Engineer A

ProductSummary

Enter Defects by Component

and Phase

Enter Size by

Component

Enter Week TaskCompleted

Enter Time by

Task

Updated Team andEngineer Task, Schedule,

and Quality Plans

Team Task and Schedule

Summary

Task StatusEngineer A


Management Support

The TSP will not work unless the engineers are fully supported by all management levels.

During the project launch the team reviews their plan with management.• answers questions• resolves issues• explores alternatives

To sustain the TSP, management must • periodically review the project• probe the team’s data• focus on quality


Engineering ReactionsWith proper support, TSP engineers can produce extraordinary results.

Engineers like to use the TSP:• This really feels like a tight team.• The TSP forces you to design, to think the whole thing out.• Design time is way up but code time decreased to compensate.• Tracking your time is an eye opener.• Really good teamwork on this project - no duplication of effort.• I’m more productive.• Gives you incredible insight into project performance.• Wonderful to have team members assigned specific roles.• Team really came together to make the plan.• I feel included and empowered.


A TSP Industrial Project - 1Communications test equipment• 12 software and 3 hardware engineers• not all software engineers PSP trained

Plan

Size - KLOC 110 Effort - hours 16,000 Schedule - weeks 77 Defects per KLOC Integration and system test 1.1 Field trial 0.0 Customer use 0.0


A TSP Industrial Project - 1Communications test equipment• 12 software and 3 hardware engineers• not all software engineers PSP trained

Plan Actual

Size - KLOC 110 89.9Effort - hours 16,000 14,711Schedule - weeks 77 71Defects per KLOC Integration and system test 1.1 0.6 Field trial 0.0 0.02 Customer use 0.0 0.0


A TSP Industrial Project - 2Comparison with a prior project of 9,500 LOC.• Engineers not PSP trained.• Communications system controller

TSP non-TSP

Size - KLOC 89.9 9.5Field testing duration engineering trial 2 weeks 3 months acceptance trial 3 weeks 6 monthsTrial defects/KLOC 0.02 5+


TSP Benefits

# of Defect Detected

Release # 6 Release # 7 Release # 8 Release # 9

75% lower Defect

PSP/TSP trained

(Boeing Pilot #1)

2.36X moreSloc count

Software Size


TSP Benefits

System Test time

Release # 6 Release # 7 Release # 8 Release # 9

PSP/TSP trained

(Boeing Pilot #1)

2.36X moreSloc count

32 days 41 days28 days

4 days

94% less time


A TSP Government ProjectAir Force flight planning system• 6 software engineers• 5 were PSP trained

Integration and system test time was reduced from an average of 22% of schedule to 2.7%.

Productivity was 2.33 times the same team’s prior project.

Projects A B C TSPSize - LOC 67,291 7,955 86,543 25,820Test Days 63 23 92 6System test defects/KLOC 2.21 4.78 2.66 0.54Acceptance test defects/KLOC N.A. 1.89 0.07 0.15


A TSP Maintenance ProjectA company applied PSP/TSP with 2-engineer teams on 14 maintenance projects.

Average results showed.

TSP non-TSP

Time estimate errors +- 7.5% Not trackedSize estimate errors +- 10.0% +-23.4%Defects/page 0.14 0.35Review yield 57.1% Not trackedProductivity - pages/hour 2.28 2.08


Getting Started with PSP/TSPSprinkling a few PSP-trained engineers around an organization will not produce noticeable results.

Installing PSP/TSP in an organization requires• a team-based improvement focus• careful planning• senior management involvement and sponsorship• a change in the behavior of both the engineers and

their managers


Conclusion

The PSP shows software professionals how to use engineering methods in their personal work.

The TSP shows organizations how to build and manage effective engineering teams.

When software professionals use sound engineering methods, their teams produce extraordinary results.


For More InformationVisit the PSP or TSP web sites http://www.sei.cmu.edu/psp/ http://www.sei.cmu.edu/tsp/

Contact a PSP transition partner http://www.sei.cmu.edu/collaborating/partners/trans.part.psp.html

Contact SEI customer relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone, voice mail, and on-demand FAX: 412/268-5800 E-mail: [email protected]

Documents

1 Disciplined Software Engineering Watts S. Humphrey Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Sponsored by the