Problems
Document: Software Engineering 1: Lab Report Guidelines
Marking Scheme
Software Engineering 1: Laboratory Report Guidelines
Including Source Files
Typically you will encounter one or more unanticipated "problems" in
any given exercise. This is not a cause for alarm or dispair. We
expect you to encounter problems: you would not have the
opportunity to learn anything if you did not. Problems are
opportunities for learning - and opportunities for getting marks in your
report!
Note that this applies to the Lab exams just as to the normal
exercises. We do not expect that you will be able to complete a
exam without running into any problems. The central point of the exam
is not to see whether you can avoid running into any problems, but
whether you can effectively respond to whatever problems do arise.
Some problems will be very minor and will not deserve reporting. For
example, you leave out a semi-colon, or mistype a variable name.
Provided these are easily and quickly fixed, you should omit them from
the report. But, as a rule of thumb, any problem or difficulty which
takes up anything in excess of 10 minutes of your time qualifies as
significant, and something which must be described in the report.
Remember: you can still get a very respectable mark on a report, even if
you make relatively little "progress" in completing the given exercise
- provided you can clearly explain what problem(s) you encountered
and what steps you took to solve them.
In fact, you will often find that the discipline of trying to explain
clearly what your problem actually is often gives you an immediate
insight into how to solve it!
Problems are extremely diverse, and it is impossible to give a complete
description here; but there are some specific kinds for which we can
give more detailed advice.
- Problems of Understanding: For example, "I don't understand
what a matrix is", "I don't know what type double means",
"I don't understand what for does", "I don't understand what
the given program SUPER.C is supposed to do".
These are all perfectly good statements of a problem. The sorts of
steps you can consider in trying to solve them include (re-)reading the
relevant section of the textbook, (re-)reading the on-line notes,
looking for information in the on-line documentation, trying something in
isolation in a small test program to see what happens, asking a
colleague, asking a demonstrator.
- Compilation Problems: If messages are thrown up when
you attempt to compile a program, then these definitely
constitute problems. Some may be trivial, as already discussed; but
some may be very difficult, in which case they should be discussed in
the report. In that case, you should include, verbatim, at least the
first message which is coming up, together with enough of the program
file to see the context in which the message is appearing. Strategies
for solution include: trying variations in the program to see what
effect these have on the message(s); using the on-line documentation
to try to get
more, or better, information; trying to find a different way of
programming whatever it was you wanted to program. And so on.
- Run-time Problems: These are generally of the form "I ran
this program, gave it this data, and this (unexpected) thing happened".
Note carefully that an adequate description of this kind of problem
requires you to say clearly what the "expected" or "correct"
behaviour would have been. In fact, it will sometimes turn out that the
solution to this kind of problem will be to recognise that you
were mistaken in what you expected (i.e. the program is actually
behaving "correctly"). In any case, solution strategies for this kind
of problem include: rerunning the program with the same data (to see
if the symptoms are repeatable); rerunning the program with different
data (to see if a pattern of failure can be built up);
adding extra
code to the program to get more information on what's going wrong; cutting
down the program to try to localise the problem. And so on.
- Equipment Problems: You may encounter problems with the lab
equipment - hardware or software. These will typically be outside your
control to fix. But, if such a problem has impacted significantly on
doing the exercise, you should include it in the report. In particular,
you should explain what the symptoms were, why you classified it as an
equipment problem, and how long it took for it to be sorted out.
Document: Software Engineering 1: Lab Report Guidelines
Marking Scheme
Software Engineering 1: Laboratory Report Guidelines
Including Source Files
McMullin@eeng.dcu.ie
Fri Mar 29 08:26:31 GMT 1996