Carnegie Mellon University Software Engineering Institute Disciplined Software

Carnegie Mellon University Software Engineering Institute Disciplined Software Engineering Watts S. Humphrey Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 -3890 Sponsored by the U. S. Department of Defense © 2001 by Carnegie Mellon University

A War Story - 1 The 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 2

A War Story - 2 Development 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? © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 3

Agenda The nature of engineering The Personal Software Process (PSP) The Team Software Process (TSP) SM SM TSP costs and benefits TSP introduction Conclusions SM Personal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie-Mellon University. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 4

Definition Engineering 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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 5

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 overbudget 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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 6

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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 7

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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 8

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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 9

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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 10

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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 11

PSP and TSP Principles - 1 The 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 12

PSP and TSP Principles - 2 Plan 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 13

How PSP and TSP Build Engineering Teams PSP TSP Skill-building Team-building Personal measures Process discipline Estimating & planning Quality management Team Members Project goals Team roles Team process Project plan Balanced plan Team Disciplines TSP Team-working Risk analysis Team communication Team coordination Status tracking Project reporting Team Management Disciplined Engineering Teams Version # Course or Lecture or Module Info. - page 14

Introducing Personal Disciplines Until 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 15

The PSP Is an Evolving Process Team Software Process PSP 3 Cyclic development PSP 2 • Teambuilding • Risk management • Project planning and tracking PSP 2. 1 • Code reviews • Design reviews Design templates PSP 1. 1 PSP 1 • Size estimating • Test report • Task planning • Schedule planning PSP 0. 1 PSP 0 • Current process • Basic measures • Coding standard • Process improvement proposal • Size measurement © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 16

Estimated Minutes - Actual Minutes / Estimated Minutes Effort Estimation Results Effort Estimation Accuracy Trend 0. 7 0. 6 0. 5 Mean Time Misestimation PSP Level Average 0. 4 0. 3 0. 2 0 1 2 3 4 5 6 7 8 9 10 11 Program Number © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 17

Quality Results Defects Per KLOC Removed in Compile and Test 120 110 Mean Number of Defects Per KLOC 100 90 Mean Compile + Test 80 PSP Level Mean Comp + Test 70 60 50 40 30 20 10 0 0 1 2 3 4 5 6 7 8 9 10 11 Program Number © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 18

Productivity Results Lines of (New and Changed) Code Produced Per Hour of Total Development Time 30 Mean LOC / Hour 28 26 Mean LOC/Hour PSP Level Average 24 22 20 0 1 2 3 4 5 6 7 8 9 10 11 Program Number © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 19

Design Time Results Time Invested Per (New and Changed) Line of Code 1. 4 Mean Minutes Spent Per LOC 1. 2 1. 0 0. 8 Design Code Compile 0. 6 Test 0. 4 0. 2 0. 0 0 1 2 3 4 5 6 7 8 9 10 11 Program Number © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 20

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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 21

The 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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 22

TSP Overview TSP projects can start on any phase. Launch Requirements Each phase starts with a launch or relaunch step. Relaunch The strategy is to • overlap phases • develop in increments • balance team workload • accelerate tasks wherever possible Relaunch High-Level Design Implementation Relaunch Integration and Test Postmortem © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 23

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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 24

The Launch Process Meetings Day 1 1. Establish Product and Business Goals Day 2 4. Build Topdown and Next-Phase Plans 2. Assign Roles and Define Team Goals 5. Develop the Quality Plan 3. Produce Development Strategy 6. Build Bottomup and Consolidated Plans © 2001 by Carnegie Mellon University Day 3 Day 4 7. Conduct Risk Assessment 9. Hold Management Review 8. Prepare Management Briefing and Launch Report Launch Postmortem Version 010130 Disciplined Software Engineering - page 25

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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 26

TSP Planning Define Process and Tasks Produce Conceptual Design Estimate Defects Injected Make the Engineers’ Plans Estimate Tasks Make Size Estimates Balance Team Workload Estimate Yields Estimate Weekly Time Conceptual Design Overall Project Plan Quality Plan Version # Detailed Engineer Plans Balanced Team Plans Course or Lecture or Module Info. - page 27

Tracking a TSP Project The 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 28

TSP Project Tracking Enter Time by Task Product Summary Enter Week Task Completed Engineer A Updated Team and Engineer Task, Schedule, and Quality Plans Enter Defects by Component and Phase Task Status Enter Size by Component Quality Summary Version # Team Task and Schedule Summary Schedule Status Engineer A Course or Lecture or Module Info. - page 29

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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 30

Engineering Reactions With 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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 31

A TSP Industrial Project - 1 Communications 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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 32

A TSP Industrial Project - 1 Communications 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 © 2001 by Carnegie Mellon University Version 010130 Actual 89. 9 14, 711 71 0. 6 0. 02 0. 0 Disciplined Software Engineering - page 33

A TSP Industrial Project - 2 Comparison with a prior project of 9, 500 LOC. • Engineers not PSP trained. • Communications system controller Size - KLOC Field testing duration engineering trial acceptance trial Trial defects/KLOC © 2001 by Carnegie Mellon University TSP non-TSP 89. 9 9. 5 2 weeks 3 weeks 0. 02 Version 010130 3 months 6 months 5+ Disciplined Software Engineering - page 34

TSP Benefits Software Size (Boeing Pilot #1) 2. 36 X more Sloc count # of Defect Detected 75% lower Defect Release # 6 Release # 7 Release # 8 Release # 9 PSP/TSP trained © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 35

TSP Benefits (Boeing Pilot #1) System Test time 32 days 41 days 28 days 2. 36 X more Sloc count 94% less time 4 days Release # 6 Release # 7 Release # 8 Release # 9 PSP/TSP trained © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 36

A TSP Government Project Air Force flight planning system • 6 software engineers • 5 were PSP trained Projects A B C Size - LOC 67, 291 7, 955 86, 543 25, 820 Test Days 63 23 92 System test defects/KLOC 2. 21 4. 78 2. 66 Acceptance and test defects/KLOC N. A. 1. 89 0. 07 Integration system test time was reduced from TSP 6 0. 54 0. 15 an average of 22% of schedule to 2. 7%. Productivity was 2. 33 times the same team’s prior project. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 37

A TSP Maintenance Project A company applied PSP/TSP with 2 -engineer teams on 14 maintenance projects. Average results showed. Time estimate errors Size estimate errors Defects/page Review yield Productivity - pages/hour © 2001 by Carnegie Mellon University TSP non-TSP +- 7. 5% +- 10. 0% 0. 14 57. 1% 2. 28 Not tracked +-23. 4% 0. 35 Not tracked 2. 08 Version 010130 Disciplined Software Engineering - page 38

Getting Started with PSP/TSP Sprinkling 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 © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 39

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. © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 40

For More Information Visit 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: customer-relations@sei. cmu. edu © 2001 by Carnegie Mellon University Version 010130 Disciplined Software Engineering - page 41