looking ahead your final-year project. in final year you do a project... for these courses, it ’...

Looking ahead

Your final-year project

In final year you do a project...

For these courses, it’s assumed you will build an “artefact”, and report on the building of it.

It’s marked on the cleverness, innovation, problem-solving ability, insight etc. shown in the report.

Project topic Ideally clever & small - you then have

the time to deal with it properly. You choose the topic, in consultation

with possible supervisors. (“Your” topic => motivation => better

projects.) Staff may suggest project topics, or

topic areas though.

Clearly, my suggestions are…

… mainly Software Engineering topics…

SE projects tend to need advance preparation…

… which is why I’m raising the issue now, so we can talk through possible projects over the rest of this year.

My special SE interests

Program tools to help design & code:– graphic editors for design;– prototypers;– programming-language oriented text editors;– program provers;– configuration management tools;– …

Programming languages

Other S.E. staff

No other SE specialists at the moment, but various staff I’d point you at for particular aspects – e-mail me for suggestions!

INSE - Lecture 12

Debugging; Maintenance

Debugging

A thoughtGlendower: I can call up spirits from the vasty

deep

Hotspur: Why, so can I, or so can any man, but will they come when you do call for them?

Henry IV, part 1, Act 3 scene 1

So when you know there’s a bug - finding it takes some mix of persistence, luck, skill and thought.

Skill and thought don’t “just happen”.

Debugging is... time-consuming reveals one’s own errors, so is…

– often inefficiently done, so…

»AVOID IT as much as possible “Short cuts” in design & coding are false economy:

– take extreme care in design– struggle for highest legibility of code

In maintenance:– if something works, don’t tamper.

Effective debugging (1)

Simplify it!– unit test any fragment that you feel might have a

bug, no matter how small, & debug;– size modules so they probably have tiny numbers

of bugs, and debug;– system test for small new combinations, and

debug.

So then you only need to deal with a tiny number of bugs at a time.

Effective debugging (2)

Design every verification test to trap as many classes of bug as possible– avoids messy test-then-debug-then-test-

then-debug… cycles

When there is a bug...

...you often need to improvise a “pursuit test” targeted on chasing the bug -– obvious, but often overlooked, especially

by beginners. …follow the logic of the bug back

towards it’s origin (“back-deduction”) -– also obvious but often overlooked,

especially by beginners.

Where is the bug?

Locate the region of the program that the bug is in -– e.g. in response to a mysteriously

corrupted variable - what/where is corrupting it?

– “wolf fence” tactic» (Also called “divide and conquer”).

Having put in debugging code It was expensive! keep it!

Comment it out:// ... some debug code ...

Eliminate it by conditional compilation:final boolean DEBUGGING = False;…if (DEBUGGING) { … some debug code … }

Dynamic debuggers... … are now common extras for compilers and

IDEs:– you can set “break-points”, then execute to the

first break-point reached;– you can restart from a break-point till the next is

reached;– you can “single-step”;– you can monitor the values of variables;– you can change the values of variables;– ...

Aptitudes for debugging

Ability to spot obscure patterns; Ability to separate interleaved patterns; Meticulousness; Tenacity; Judgement; Intuition; LUCK!!!

Maintenance

expense & risk corrective, innovative & perfective maintenance rate of discovery of bugs aptitudes for maintenance

Maintenance is expensive Most Industry reports say between 60% and

90% of total programming effort is maintenance;

quite where in that range seems to correlate to various sections of the industry;

high end => long life with regular need for functional change;

also varies with the effort that went into making the software maintainable and keeping it so!

Maintenance is risky

You are changing something beyond it’s original design…

… will the design stand up to the changes?

MORAL: designs should have flexibility build in.

Kinds of maintenance

Corrective - is really debugging, done late (the user reported the bug)

Innovative - adding new capabilities, perhaps updating old ones

Perfective - internal improvement to correct software not needing any innovation or update.

Corrective maintenance Fixing errors (or other severe deficiencies) in

a version of the software being used by customers;

therefore much more fraught than “normal” debugging.

Often– either not obvious where (in spec/design/ code)

it originates;– or blatantly a result of wrong requirements or

mis-specification!

Innovative maintenance The requirements have changed...… maybe new facilities are needed/

desired;… maybe the real-world situation has

changed;… maybe there’s a perception that the

real-world situation could be modelled better.

Perfective maintenance

Improving perceived quality, or... Improving actual (internal) quality, or… Increasing capacity, or… Increasing speed, or...

Rate of discovery of bugs

Rate of discovery of bugs

Rate of discovery of bugs

Rate of discovery of bugs

Rate of discovery of bugs

Rate of discovery of bugs

Staffing of maintenance

…perhaps because their managers told them to repair the old one…

MORALS:– keep the team stable;– manage it

thoughtfully.

After this lecture (1) STRATEGIES FOR DEBUGGING:

– avoid;– simplify.

TACTICS:– back-deduce (location by history);– wolf-fence (location by geography).

TOOLS:– dynamic debuggers.– (read the manual for others in the compiler or IDE).

After this lecture (2)

Build for maintainability;

Maintain thoughtfully;

Staff issues for maintainability – choose well!

This is another issue for long-term thought about your experience, and what you observe of other people’s experience.

© C Lester 1997-2014

Revisiting “risks of maintenance”