1. Humboldt University Berlin, University of Novi Sad, University of Plovdiv, University of Skopje, University of Belgrade, University of Niš, University of Kragujevac DAAD Project “Joint Course on Software Engineering” Version: Apr. 01, 2005 Topic X Personal software process (PSP) Parts of this topic use material from the textbook W. S. Humphrey, “A Discipline for Software Engineering”, Addison-Wesley, 1995

2. Literature Watts S. Humphrey “A Discipline for Software Engineering: The Complete PSP Book” Addison Wesley, 1995. Watts S. Humphrey “Introduction to the Personal Software Process” Addison Wesley, 1997.

3. PSP: A Self-Improvement Process for Software Engineers published Watts S. Humphrey “PSP: A Self- Improvement Process for Software Engineers” Addison Wesley Professional, 2005.

4. What makes you better? Why are you a better programmer than a first year student? Why are some organizations better than others? (deliver software on time; deliver with high quality and few defects) Do some of the same things for a personal level scale up to organizations?

5. PSP - Personal software process “Software improvement must begin at the individual level.” Watts S. Humphrey  Awareness  Best practices  Commitment

6. The software problem  Poor software quality in delivered systems is expensive expensive service and enhancement potential for accident or loss of life.  Organizational progress with process improvement is limited because process improvement takes time / is hard to sell.  The PSP addresses these problems by providing convincing evidence of the benefits of process improvement exposing the engineers to the benefits of using effective processes in their work teaching the engineers effective process improvement methods providing the historical data to better manage cost, schedule, and quality.

7. Objectives for process improvement schedule (delivery date) functionality (features) quality (defects)

8. What is PSP? (1) PSP is a framework of techniques to help software engineers improve their performance. PSP is a self-improvement process designed to help control, manage, and improve the way you work. It is a structured framework of forms, guidelines, and procedures for developing software. (PSP as introduced in 1995 by its author, Watts S. Humphrey, SEI)  PSP takes those large scale project methods and practices which can be used by individuals, structures them so that they can be introduced gradually, and provides a framework for teaching them.

9. What is PSP? (2)  Provides engineers with a disciplined personal framework for doing software work.  Provides a set of methods, forms, and scripts that show how to plan, measure, and manage the work.  Emphasizes effort estimation & software quality.  Designed for use with any programming language or design methodology.  Can be used for any aspect of software development.  Provides a rapid way to infuse each engineer with software engineering skill and experience.  Goal – produce zero defect products on schedule and within planned costs.  Key – ability to recognize and handle undue pressures.

10. Mistakes, Errors and Defects

11. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 11 Basic Concepts  You are building a project.  The project is made up of “phases”. You complete a phase of the project and then move onto the next phase. Possible phases are “design”, “coding”, “testing”  In the Lab., some people would consider each “task” as a “phase”. You complete all the design, code and testing for one task, and then move onto the next task  Some people would call each part of a task a phase  The key element is – you decide a “phase” for your project, and then you decide whether you have completed that “phase” and can move onto the next stage, or whether you have to keep working to make this phase work

12. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 12 Mistakes in a project with 3 tasks Task 1 – 100 LOC – Lines of Code  7 Task 1 mistakes are made (developer does not know this) BUT ONLY  3 Task 1 mistakes are discovered before moving onto Task 2 Task 2 -- 100 LOC – Lines of Code  5 Task 2 mistakes are made (developer does not know this) BUT ONLY  3 Task 2 mistakes (errors) are discovered before moving onto Task 3  1 mistake (defect) made in Task 1 is discovered and fixed Task 3 -- 200 LOC – Lines of Code  2 Task 3 mistakes have been discovered and fixed – at this point in time in the project  1 mistake from Task 1 has been discovered and fixed – at this point in time in the project  1 mistake from Task 2 has been discovered and fixed – at this point in time in the project  ? mistakes have been made  ? Defects will be fixed? PRODUCT IS RELEASED AFTER THE DEVELOPER “COMPLETES” T3 HOW MANY PROBLEMS LEFT IN THE PROJECT

13. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 13 Questions to ask  How many mistakes is it likely that the programmer will make during Task 3?  How many mistakes made during Task 3, will the programmer find in Task 3 (errors) before deciding to releasing the project to the customer?  How likely is it that the programmer will, during Task 3, find any mistakes (defects) left behind from Task 2?  How many mistakes (defects) can be expected to be left behind after the product has been released?

14. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 14 Errors and Defect  Mistake – anything you do wrong (including misreading the manual)  Error – are mistakes you make in “ this phase” of the project and FIND before moving on to the “next phase” of the project.  Defects – are mistakes you make in “ this phase” of the project and DON’T FIND before moving on to the “next phase” of the project  There is no mention of what constitutes an error or a defect – it is anything you do wrong! Includes misreading the manual Errors can both be syntax mistakes or logical mistakes. Defects are more likely to be logical mistakes. The difference is one of time -- “when (in the project) did you find the mistake”

15. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 15 How many errors and defects in this code?  Can’t answer the question, until you define “phase of a project” and also know the code- review habits of the programmer.  Humphreys suggests – code + assembler + link = 1 phrase

16. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 16 How many errors and defects in this code?  Editor is suggesting syntax errors in Po (key-word colour coding). Would be found by assembler before moving onto next task  Formatting is suggesting an error in the loop as there should be 4 non- indented lines  There are in fact 8 other mistakes in the code. How many would be caught by assembler?

17. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 17 Better – after a code-review  There are still 2 mistakes in code. A warning will be issued by the assembler and will then cause a fatal error with the linker A mistake that will not be caught by the assembler or linker and get into the next phase

18. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 18 Errors and defects recognized When should project be released? Task 1 – 100 LOC – Lines of Code  7 Task 1 mistakes were made (we don’t know this) BUT ONLY  3 Task 1 mistakes (errors) are discovered before moving onto Task 2 Task 2 -- 100 LOC – Lines of Code  5 Task 2 mistakes were made (we don’t know this) BUT ONLY  3 Task 2 mistakes (errors) are discovered before moving onto Task 3  1 mistake (defect recovered) made in Task 1 is discovered and fixed Task 3 -- 200 LOC – Lines of Code  2 Task 3 mistakes (errors) have been discovered and fixed – at this point in time  1 mistake from Task 1 (defect recovered) has been discovered and fixed – at this point in time  1 mistake from Task 2 (defect recovered) has been discovered and fixed – at this point in time  ? mistakes have been made  ? Defects will be fixed? PRODUCT TO BE RELEASED AFTER THE DEVELOPER “COMPLETES” TASK 3!

19. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 19 Should the developer release the project?  Can’t really tell with this small amount of data – metrics should be gathered over many projects.  Personal Software Process  Will demonstrate the principles

20. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 20 Based on the available data  Developer does not know whether a mistake has been made  Developer only knows about errors recognized and defects recovered Task 1 – 100 LOC – Lines of Code  3 Task 1 mistakes (errors) are discovered before moving onto Task 2 Task 2 -- 100 LOC – Lines of Code  3 Task 2 mistakes (errors) are discovered before moving onto Task 3  2 mistake (defect recovered) made in Task 1 is discovered and fixed  1 mistake (defect recovered) made in Task 2 is discovered and fixed  Based on this data – developer makes 9 mistakes per 200 lines of code developed – 45 / kLOC -- Actually making 60 / kLOC but doesn’t know that till later.  Task 3 (assuming same level of complexity as Task 2 and 3) has 200 LOC and there fore the developer is probably making 9 +- 2 mistakes  I reckon that I am having a good day if I can get below 80 kLOC, but that is because I am not spending enough time fixing my development process. What’s your real mistake rate

21. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 21 Mistake Recovery Efficiency -- MRE How to calculate Mistake Recovery Efficiency Errors found for a = ------------------------------------- given project phase Mistakes found (Errors + Defects) Can’t really be calculated for THIS project till the project is finished (Must have past history available) Task 1  3 mistakes are discovered before moving onto Task 2 3 ERRORS FOUND  1 defect found in Task 2 and another in Task 3 2 DEFECTS FOUND Mistake Recovery Efficiency = MRE = 3 / 5 = 60% recovery calculated Actually (but we can’t measure that ) True MRE is 3 / 7 – lower than 60% Task 2  3 mistakes are discovered before moving onto Task 3 3 ERRORS  1 mistake made in Task 2 is discovered and fixed 1 DEFECT RECOVERY Mistake Recovery Efficiency = MRE 3 / 4 = 75% recovery Average MRE = (60 + 75) / 2 = 67.5% (2/3)

22. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 22 Task 3 Problems with final customer code How many? – based on MRE Task 1 – 100 LOC  7 mistakes are made – expecting only 4.5 in this amount of code  3 mistakes are discovered before moving onto Task 2 3 ERRORS Task 2 – 100 LOC  5 mistakes are made – expecting only 4.5 in this amount of code  3 mistakes are discovered before moving onto Task 3 3 ERRORS  1 mistake made in Task 1 is discovered and fixed 1 DEFECT RECOVERY Task 3 – 200 LOC -- Based on LOC developed – 9 errors in 200 LOC  2 mistakes have been identified 2 ERRORS  1 mistake from Task 1 has been discovered 1 DEFECT RECOVERY  1 mistake from Task 2 has been discovered 1 DEFECT RECOVERY PRODUCT RELEASE HOW MANY PROBLEMS? This programmer averages MRE = 67.5% in each phase – therefore expect that of the 9 mistakes probably made in task 3 – 9 * 0.675 of those will be found (6.3). Has found 2 errors already Can expect to find another 4 errors based on past performance 3 defects left will probably be left in customer code from Task 3

23. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 23 Problems with final customer code From Defects left over from T1 and T2 Task 1 – 100 LOC  Expect 4.5 mistakes to be made  3 mistakes are discovered before moving onto Task 2 3 ERRORS  2 defects recovered (Task 2 and 3) -- probably no more defects left Task 2 – 100 LOC  Expect 4.5 mistakes to be made  3 mistakes are discovered before moving onto Task 3 3 ERRORS  1 mistake made in Task 2 is discovered and fixed in T3 1 DEFECT RECOVERY PRODUCT RELEASE HOW MANY PROBLEMS? This programmer averages MRE = 67.5% in each phase – therefore expect that of the 9 mistakes probably made in task 1 and 2 – 9 * 0.675 of those will be found (6.3). Has found 9 errors already Based on the statistics from this project – developer has found all problems in Task 1 and probably most in Task 2

24. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 24 If you are going to do this sort of metrics seriously  The programmer needs to know their own MRE and Defect Recovery Rate. Must collect “metrics” from past experiences  The programmer needs to know need to know whether the tasks were of equal difficulty A more difficult task can be expected to cause more than the average number of defects  Is this a safety critical task Might spend more time looking for possible defects (Perhaps write more tests (TLD))  Time estimation – how long will the product take to develop? How big is the product? Learn estimation skills What is your efficiency (lines of debugged code / hour)? Errors / 1000 lines of code? Defects / 1000 lines of code? How long does it take you to fix a “typical” error or defect? When fixing errors and defects – how many new mistakes do you introduce for each one you fix? (Industry about 1 in 3) What are your most common mistakes? And what are you doing to fix them in time for final exam and post-lab 3 quiz

25. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 25 Example on Errors / Defects / Mistakes Possible Final Exam question A student is doing 5 tasks – all roughly the same size and difficulty. You know that the students MRE = 60% and DRE = 20% Task 1 10 errors discovered Task 2 5 errors discovered 2 defects from Task 1 found Task 3 10 errors discovered 1 defects from Task 1 + 2 defects from Task 2 found Task 4 12 errors discovered 1 defects from Task 1 + 2 defects from Task 2 + 2 defects from Task 3 found Task 5 10 errors discovered 2 defects from Task 2 + 2 defects from Task 3 + 1 defect from Task 4 Explain both qualitatively (reasonability argument) and quantitatively (number argument) the following issues 1) The programmer moved onto Task 3 from Task 2 at the correct time – true or false 2) The programmer should stop working on Task 5 and release the product 3) Why is impossible in Task 5 to discover a defect from Task 5 This programmer has been using test first development (test driven development). 4) Explain why you might think that this student does not know how to write TDD tests (some people are good at testing and some are not) 5) Looking back at your previous classes – make an estimate of your MRE and DER rates 6) Make a comment on what you feel is your MRE and DER rates now 7) Has TDD helped you or hindered you? 8) Some people feel that writing tests before coding takes longer that writing tests after the coding. In theory – since you need the same tests – this is not true. But in practice it often is true – explain the discrepancy 9) What is the difference between a unit test and a system test? Using one of your labs as an example give details of a unit test and a system test?

26. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 26 Some more practice on loops and arrays. Indexing through arrays array(count) = 2;  How many errors and defects if you define errors as being “found before assembler is used”

27. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 27

28. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 28

29. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 29 Array(count) = count

30. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 30 Hardware loop – 11 syntax errors

31. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 31 What defects are present?

32. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 32 Getting ready to go “really fast”

33. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 33

34. 10/9/2015Mistakes, Errors, Defects, Copyright M. Smith, ECE, University of Calgary, Canada 34 Blackfin in “full parallel operation”