1. Important concepts in software engineering The tools to make it easy to apply common sense!

2. 2 Concepts Project time – elapsed time Supervisor requests – reasonable or out to lunch – how can you determine? Mistakes, Defects and Errors, which is the worse What is your code quality? Why and how do you improve your code quality? Short group exercise

3. 3 Project Time versus Elapsed Time Student comes to me and says – “ the assignment you gave me was so hard that it took me three weeks to do” The student has lost all credibility as has indicated that has no knowledge of the difference between “project time” and “elapsed time” Project time – the time actually needed to do the project work Elapsed time – the time period that goes by before the student has the time available to put in the “project time”

4. 4 Your supervisor says – I have this idea – when can you get it done by? You need the ability to be able to estimate how many lines of code a project of this sort would take you to complete (design, code, test, debug, document) You need to know your average productivity (LOC / hr) My productivity is about 20 LOC / hr (designed, coded, tested and debugged) You need to know your other commitments for the week Now you are in a position to answer your supervisor DON’T MAKE COMMITMENTS THAT YOU CAN’T MEET MAKE SURE YOU KNOW HOW TO CALCULATED WHETHER YOU CAN MAKE A COMMITMENT

5. 5 Keep records Estimating Do a quick think about a project Does this seem like a “easy”, reasonably easy, “okay”, “hard but do-able”, “really hard but do-able”, sort of know what is needed, “I want a new supervisor” type of project Lets assume it seems “reasonably easy” – what did “reasonably easy” mean the last time you did a project? -- look at your records Let assume that is meant 150 LOC (excluding comments and spaces) Lets assume productivity is 20 LOC / hr Calculate project time and elapsed time for the following two students

6. 6 Calculate time when student can deliver Student one Monday 3 hrs available Tuesday 5 hrs available Wednesday 7 hrs available Student 2 Monday 3 hrs available Tuesday 1.5 hrs available Wednesday 1.5 hrs available Thursday 1.5 hrs available Friday 1.5 hrs available

7. 7 Joke about students and programming Computer engineering conference All instructors asked “would you go up in a ‘fly-by-wire’ aircraft where the software was designed by your students?”

8. 8 Everybody makes mistakes Know and understand the following The ideal development process involves no mistakes If you can’t have a “mistake-free process” then it is better to have an “error present but defect- free process” than “error-free but defect- present process” What is a “defect” and what is an “error”?

9. 9 Let’s take an example The student is designing the code for the supervisor During thinking about the design of the MathLab code makes a design mistake Write out the design of the code, does a quick “look over” discovers 3 mistakes (which are fixed) but introduces a new mistake Industry standard 1 new mistake for each mistake fixed Code – discover 4 mistakes (fixed) – introduces a new one and misses one Debug and test – makes 2 new mistakes, fixes both, finds 2 of the missed mistakes from earlier on (the one in design and one from code. Other mistakes are not discovered

10. 10 Mistakes, defects and errors Mistake – a problem generated Error – a mistake made during a certain “phase” of the project, and “recognized and fixed” at that stage of the project Defect – a mistake that “escaped” a given stage of the project. The longer a defect is goes unrecognized, the bigger problem it is to fix Scale by 2 for each phase during which defect is missed PhaseErrorDefectDefect scaling factor Design Write- out Code Debug Test Found later Total Scaled defect

11. 11

12. 12 You need to know the quality of your process Modification of the concept of “code quality” taken from Humphrey’s “A discipline of software engineering” Number of Errors Found Quality = 100% * -------------------------------- # Errors + Scaled Defects

13. 13

14. 14 Work out your own phases for the way “you” work – collect defect and error information Consider last student Recorded defects and errors over last three projects Code quality was 40%, 60%, 80% Basic rule – the way you have worked before is the way you are working now, unless you have made an effort to change your process! The student is working on a new project – much larger than before. The number of errors is 26 The scaled defects (found to this point) 14 How much time should the student spend looking for the remaining defects in the code?

15. 15

16. 16 Why improve Quality? More confidence in your work More likely to have something to go to a conference in Australia with! More time to spend on other things Give two other reasons (personal) for improving quality of your code

17. 17 How do you improve Quality? Keep track of the errors you make Do a review Design review (BEFORE YOU LEAVE THE DESIGN PHRASE) Code review (BEFORE YOU HIT THE RUN BUTTON Build tests that you can use now, and use again later when you find you need to modify the code Make testing easy for yourself – get an automated process Consider doing some of the code development in a Test driven manner where you design the tests as part of trying to understand what it is you want to do

18. 18 Keep track of the errors you make For a couple of projects, keep track of all the errors and defects you make Then take the top five – ignore the others Develop a process to stop making the top two Worry about the others later Find tools to assist you Talk to others

19. 19 Do a review -- 1 Design review (BEFORE YOU LEAVE THE DESIGN PHRASE) Code review (BEFORE YOU HIT THE RUN BUTTON) Look for the mistakes in the code that “you typically make”; Don’t look for the mistakes that you don’t typically make Don’t look for the mistakes that other’s make Develop a PSP – personal software process

20. 20 Do a review -- 2 Hints – industry standard If you don’t review for 25% of the time that you code, pack and go home. Your code is so bad, I can’t rely on you. You spent so much time fixing the bugs in the code that you are wasting my and your time and money. Don’t review too slowly (slower than 20 LOC / hr) or too quickly (faster than 150 LOC / hr) Go through the code looking for the first type of error you make, then go through the code for the second. Look for one type of error at a time NOTE: Scanning over the line you have just typed or the line before COUNTS as a review. Personally, if I find a mistake in the line I just typed (or the one before), I don’t even count it as a mistake! On a good day, my error rate can be as low as 80 errors / KLOC. That’s roughly 1 error for each 10 lines of code On a recent assignment I was testing, I was very tired and I was making 300 errors / KLOC – and really wasting my time as I was doing no review

21. 21 Share reviews Rule 1 for finding errors / defects If you don’t find the error / defect by the third time you read through the code, you will not find it the fourth time or later Rule 2 – share reviews and problems with a stranger The stranger could be you – tomorrow or after a coffee break The stranger could be a “plush toy”. Explaining your problem to the plush toy means that you are explaining to yourself Rule 3 – team program. If you and a fellow student are working in a similar area (so you understand the concept), then work together on each other’s project. You discuss, one types, the other reviews, then swap. Then do the same thing for your code Have penalties. If the reviewer spots an error before the typer does, that’s 25c to the reviewer. However if a defect turns up, that’s $1 to the typer – after all defects are bigger problems than errors

22. 22 Quick brain storm Groups of around 4 people working with a similar programming language Excell C++ or C MAtlab Other languages Each person puts in 5 most common mistakes they make. Return with a list of the 2 most common mistakes made by the group Determine what the average productivity is for the group and the range of productivity Determine what the average code quality is for the group and the range of code quality.

23. 23 Group 1 and 2 results

24. 24 Group 3 and 4 results

25. 25 Group 5 and 6 results

26. 26 Concepts Project time – elapsed time Supervisor requests – reasonable or out to lunch – how can you determine? Mistakes, Defects and Errors, which is the worse What is your code quality? Why and how do you improve your code quality? Short group exercise

27. 27 Further information Watt Humphreys, “A Discipline of Software Engineering – Personal Software Process” Dr. Mike Smith – smithmr@ucalgary.ca