looking ahead your final-year project. in final year you do a project... for these courses, it ’...
TRANSCRIPT
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”