Important concepts in software engineering

The tools to make it easy to apply common sense!

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

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

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

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

Calculate time when student can deliverStudent 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

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

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

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

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 fixScale by 2 for each phase during which defect is missed

Phase Error Defect Defect scaling factor

Design

Write-out

Code

Debug Test

Found later

Total

Scaled defect

11

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

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

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

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

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

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

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

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

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

Group 1 and 2 results

24

Group 3 and 4 results

25

Group 5 and 6 results

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

Further information

Watt Humphreys, “A Discipline of Software Engineering – Personal Software Process”

Dr. Mike Smith – smithmr@ucalgary.ca