Disciplined Software Engineering Lecture 1 Software Engineering Institute

Disciplined Software Engineering Lecture #1 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U. S. Department of Defense Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1

Course Text • “A Discipline for Software Engineering” Watts S. Humphrey Grading • Homework – 40% • Midterm – 30% • Final – 30% Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 2

General The book will be followed very closely. Class time • 50 minute lecture • 10 break Office Hours • 1 hour before/after class by appointment • Email or phone calls are fine GTA • Chaoyang Liu Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 3

Contact Information Dr. Tom Potokte@ornl. gov www. csm. ornl. gov/~v 8 q 574 -0834 Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 4

Computational Engineer Position Modeling and Simulation Group The Computational Sciences and Engineering Division in the Computing and Computational Sciences Directorate at the Oak Ridge National Laboratory (ORNL) seeks to hire a Computational Engineer with a strong interest and proficiency in computational solutions to engineering problems in the area of structural mechanics. The successful candidate will be expected to ensure that state-of-the-art finite element techniques are employed in applications to structural analysis problems and to participate in developing additional sources of funding that support research and development work within the Group. http: //computing. ornl. gov/ http: //ornl 7. ornl. gov/employment/detail. cfm? id=143 Qualified candidates are invited to send a current resume and a list of three or more references to: D. M. Hetrick, Computational Sciences and Engineering Division, Oak Ridge National Laboratory, PO Box 2008, Oak Ridge, TN 37831 -6415 or E-mail hetrickdm@ornl. gov ORNL, a multiprogram research facility managed by UT-Battelle, LLC, for the U. S. Department of Energy, is an equal opportunity employer committed to building and maintaining a diverse work force. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 5

Schedule Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 6

Software Engineering What is it? What is a process? Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 7

Course Objectives To introduce you to a process-based approach to developing software To show you how to measure and analyze your personal software process (PSP) To show you how to use process data to improve your personal performance To show you how to apply these methods to your other tasks Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 8

General Information Prerequisites • You must know a programming language. Helpful background • familiarity with basic statistics • ability to read simple formal notations Facilities • an available development environment • spreadsheet capability Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 9

Course Overview Introduction - 1 lecture Planning the process - 4 lectures Defect management - 3 lectures The design process - 2 lectures Scaling up the process - 1 lecture Design verification - 2 lectures Process development - 1 lecture Using the PSP - 1 lecture Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 10

Lecture #1 Overview PSP principles • costs and benefits • personal software process (PSP) overview The capability maturity model (CMM) • process maturity • the CMM and the PSP The initial PSP 0 process Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 11

PSP Principles - 1 The quality of a software system is governed by the quality of its worst components. The quality of a software component is governed by the individual who developed it. This is governed by your • knowledge • discipline • commitment Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 12

What is this? Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 13

The last picture taken from the Mars Lander … A software flaw probably caused the Mars Polar Lander to shut off its descent engines prematurely, sending it on a fatal plunge into the red planet, according to a report released Tuesday… "There was inadequate software design and testing. The software should have been designed to prevent premature engine shutdown, " he said. "In space, one strike and you're out. " The loss to taxpayers was approximately $165 M. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 14

Process Examples Top quarterbacks knows what was his pass completion record for last year. Top sales people know how much money they brought in. Racing teams know how minor changes to their cars will affect performance What do you know about your software development skills? Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 15

PSP Principles - 2 As software professionals you should know your own performance. You should measure, track, and analyze your work. You should learn from your performance variations. You should Incorporate these lessons in your personal practices. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 16

With a Stable PSP You can • estimate and plan your work • meet your commitments • resist unreasonable commitment pressures You will also • understand your ability • be better able to improve Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 17

A PSP Also Provides A proven basis for developing and practicing industrial-strength personal disciplines A discipline that shows you how to improve your personal process The data to continually improve the productivity, quality, and predictability of your work Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 18

What is a PSP? A personal process for developing software • defined steps • forms • standards A measurement and analyses framework to help you characterize your process A defined procedure to help you to improve your performance Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 19

The CMM and the PSP - 1 The capability maturity model (CMM) was developed by the SEI with the help of leading software groups. The CMM characterizes the most effective large-scale software practices. The PSP: • applies the CMM • is for individual work Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 20

SEI Capability Maturity Matrix Broadly agree to define how a software organization matures and improves Based on manufacturing process improvement and “best practices” from software engineering Some dramatic successes. . . Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 21

Capability Maturity Matrix Developed by the Software Engineering Institute (SEI) by Watts Humphry and Mark Paulk. Five levels of maturity for an organization • Level 1 - Initial; • Level 2 - Repeatable; • Level 3 - Defined; • Level 4 - Managed; • Level 5 - Optimizing. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 22

Initial Poorly defined procedures and controls No management mechanism to to ensure they are followed Heroic efforts by one or two people saves the day. Projects are late, crisis to crisis Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 23

Repeatable Basic project controls Quality problems No framework for orderly improvement Fault data is being collected Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 24

Defined Commitment to software process evaluation and improvement Appropriate software engineering standards and methods are in place Strong qualitative understanding of the process Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 25

Managed Process is quantified Quality and productivity measured for each key task Wide dissemination of process related information Errors can be predicted with acceptable accuracy Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 26

Optimizing Process improvement feed-back and feedforward controls Rigorous defect causal analysis and defect prevention Proactive management Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 27

More on CMM There are 18 key process areas defined by CMM, including • Requirements Management, • Software Configuration Management • Process Change Management • Defect Prevention Each key process area has five common features: • 1) goals to be achieved; • 2) ability to perform; • 3) activities performed; • 4) measurement and analysis; • 5) verification Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 28

The CMM and the PSP - 2 5 4 3 2 1 Level 5: Process change management* Technology innovation* Defect prevention* Level 4 Quality management* Process measurement and analysis* Level 3 Peer reviews* Intergroup coordination Software product engineering* Integrated software management* Training program Organization process definition* Organization process focus* Level 2 Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight* Software project planning* Requirements management Level 1 Copyright © 1994 Carnegie Mellon University *PSP key process areas Disciplined Software Engineering - Lecture 1 29

The CMM and the PSP - 3 The CMM provides the framework for effective process management. It assumes that the software professionals will follow disciplined personal methods. The PSP provides the framework for disciplined individual work. It assumes effective process management. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 30

The CMM and the PSP - 4 Management S E P G The Software Engineering Work the Engineers Copyright © 1994 Carnegie Mellon University S Q A / S C M SEPG - software engineering process group SQA - software quality assurance SCM - software configuration management Disciplined Software Engineering - Lecture 1 31

PSP Overview - 1 The PSP is introduced in 7 upward compatible steps You write 1 or 2 small programs at each step You gather and analyze data on your work You use these and analyses to improve your work Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 32

PSP Overview - 2 PSP 3 Cyclic development PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard Copyright © 1994 Carnegie Mellon University PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) Disciplined Software Engineering - Lecture 1 33

PSP Overview - 3 PSP 0 - you establish a measured performance baseline PSP 1 - you make size, resource, and schedule plans PSP 2 - you practice defect and yield management PSP 3 - you scale up PSP methods to larger projects Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 34

At Course Conclusion You will have practiced the key elements of a level 5 industrial process. You will understand which methods are most effective for you. You will do better work. You will have long-term improvement goals. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 35

Other Course Results The following charts show others have improved during the PSP course. These data are for 12 students who took the PSP course at Carnegie Mellon University in the spring of 1994. The data are on: • compile time • test defects • productivity Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 36

14 hours to 3 hours Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 37

39 Errors to 1 on average Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 38

Big drop in defects Big potential increase In productivity Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 39

The PSP 0 Process A simple defined personal process Use your current design and development methods. Gather data on your work: • time spent by phase • defects found in compile and test Prepare a summary report. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 40

The PSP 0 Process Elements A process script A project plan summary form A time recording log A defect reporting log A defect type standard Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 41

The PSP 0 Script - 1 Reference - Table C 10, page 652 Planning - estimate development time Development - develop the product using your current methods Postmortem - complete the project plan summary, with the time spent and defects found and injected in each phase. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 42

The PSP 0 Script - 2 Design - design the program, using your current design methods Coding - Implement the program Compile - compile until defect free Test - test the program and fix all defects Record defects in the defect log and time per phase in the time log. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 43

PSP 0 Plan Summary - 1 Reference - Table C 14, page 655 Header - name, date, program, instructor, language Enter your best estimate of the total time the development will take. Enter the actual time in minutes you spent in each phase. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 44

Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 45

PSP 0 Plan Summary - 2 Time - To Date - Enter the total time spent in each phase to date. For program 1 A, this is the time spent on program 1 A. Time - To Date % - Enter the percent of the total To Date time that was spent in each phase. Defects injected and removed - Enter the actual numbers of defects injected and removed in each phase. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 46

PSP 0 Plan Summary - 3 Defects - To Date - Enter the total defects injected and removed in each phase to date. For program 1 A, this is the defects injected and removed with program 1 A. Defects - To Date % - Enter the percent of the total To Date defects injected and removed in each phase. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 47

PSP 0 Time Recording Log - 1 Reference - Table C 16, page 657 Header - name, date, instructor, and program number Date - Enter the current date. Start - Enter the time in minutes when you start a project phase. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 48

Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 49

PSP 0 Time Recording Log - 2 Stop - Enter the time in minutes when you stop work on a project phase, even if you are not done with that phase. Interruption time - Enter any time you lost due to interruptions in the start to stop period. Delta time - Enter the elapsed start to stop time less the interruption time. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 50

PSP 0 Time Recording Log - 3 Phase • note the phase on which you were working • use the phase name Comments - describe • the interruption • the task you were doing • anything else that significantly affects your work Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 51

Defect Recording Log - 1 Reference - Table C 18, page 659 Header - enter the name, date, instructor, and program number Date - Enter the date when you found and fixed the defect. Number - Enter a unique number for this defect. Start each project with 1. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 52

Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 53

Defect Recording Log - 2 Type - Enter the defect type from the defect type standard. Inject - Enter the phase during which you judge the defect was injected. Remove - Enter the phase in which you found and fixed the defect. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 54

Defect Recording Log - 3 Fix time - Enter the time you took to fix the defect. You may time it exactly or use your best judgment. Fix defect - If this defect was injected while fixing another defect, enter the number of that defect or an X if you do not know. Note - A defect is anything in the program that must be changed for it to be properly developed, enhanced, or used. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 55

Defect Type Standard - 1 Reference - Table 20, page 661 The defect type standard provides a general set of defect categories. While you may replace this standard with your own, it is generally wise to stick with simple type definitions until you have data to guide your changes. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 56

Defect Type Standard - 2 The PSP defect types are: 10 - Documentation 20 - Syntax 30 - Build, package 40 - Assignment 50 - Interface 60 - Checking 70 - Data 80 - Function 90 - System 100 - Environment Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 57

Assignment #1 Read preface and chapters 1 and 2 of the text. Use PSP 0 to write program 1 A. See Appendix D for the program specifications. See Appendix C for the PSP 0 definitions and examples. Follow the specifications in Appendix C on the materials to submit and their order and content. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 58

Program 1 A Calculates the standard deviation of a list of numbers. The n numbers are held in a linked list. The standard deviation is calculated as follows: i is an index to the numbers, and Xavg is the average value of the numbers. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 59

Suggestions Keep personal copies of what you turn in Submit your programs on diskettes or to Chaoyang by e-mail. Chaoyang@cs. utk. edu Software must be a windows executable! Please keep accurate track of time. YOU WILL NOT BE GRADED ON YOUR TIME OR QUALITY!! Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 60

Some Suggestions - 1 Keep your programs simple. You will learn as much from small programs as from large ones. Keep your reports and standards simple and short. Do not hesitate to copy or build on the PSP materials. Do it right the first time. If you are not sure, find out. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 61

Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 62

Some Suggestions - 2 Software is not a solo business so you do not have to work alone. You must, however, produce your own estimates, designs, and code. You may have others review your work and you may change it as a result. You should note this help in your process report, include the review time you and your associates spend, and log the defects found. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 63

PSP 0 Evaluation Criteria Your process report must be: • complete • legible • in the specified order Your process data must be: • accurate • precise • self-consistent Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 64

Messages to Remember from Lecture 1 1 - The PSP is a defined process to help you do better work. 2 - Once you have completed this course, you will know how to adjust and extend the PSP to meet your future needs. 3 - In using PSP 0, your principal objective is to gather and report accurate and complete data on your work. Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 65