Submission requirements.
Two plastic, ringbound or gumbound
copies on A4 paper to be submitted directly to
the departmental office.
It is customary to add a stiff clear plastic A4 sheet at
the front to protect the front page, and a dark opaque rear
cover.
A standard MS-Word template for the cover page and
original work declaration is available here, both of
which are essential in your report.
Unless the code is short, It is not normal to print and
include all the program source within the report, but of
course you may include relevant snippets that you refer to,
within the body of the report. However, it is normal and
expected that the entire source is included on a CD inside
the back cover, together with an executable image, if
convenient or possible. (In other words, don't attempt to
submit an executable image if it is not convenient or
feasible ...eg. specific hardware, software and
configurations.)
It is imperative that you retain an electronic copy of your
report as backup, in case it is requested in advance by the
extern, or for any other reason.
Timeline: deadlines are typically within 2 weeks of Open
Day, but vary each year dependent on holidays, but you will
be notified of deadlines each year by email. Reports are
handed into the departmental office, during normal office
hours, and deadlines will be enforced strictly.
Report Writing Guidlines.
The danger with regulations is they
stifle innovation if you apply them literally to every
situation; so these are merely guidelines, use your
discretion, adapt and innovate as appropriate to your
circumstances, but try to retain the principles by
following the spirit rather than the letter of these
suggestions.
Basically, all you are saying is why, how and what the
outcome was of your choosing to do something the way you
did.
Target readership.
Assume the report is to be read by someone who is
knowledgeable of CS but who is not a specialist in your
project topic, such as one of your classmates or a recent
graduate; you need to explain the project topic within the
background of CS, but do not need to give a background to
CS.
Also bear in mind that there is a remote possibility that
you may use the project as part of an interview process, so
a professional, clear, concise, authoritative description
and analysis would be beneficial.
Writing Style
Adopt an impersonal passive style suited to conveying
scientific facts and logic in a dispassionate objective
manner, rather than a personal active style more suited to
conveying feelings and emotions in a subjective passionate
way; the former is less likely to induce prejudice in the
reader, whereas the latter may evoke extreme agreement,
derision or even hostility, depending on personal
resonances and moods with the reader. The first appears
factual, and therefore reliable and scholarly, whereas the
other appears more emotive, and liable to be judged as
unreliable and unscholarly; the first emphasises the topic,
whereas the second may draw too much attention to you. As
an example, it is better to say "Several techniques were
critically evaluated in terms of ease of implementation,
robustness or performance. It was clear from the result
metrics in table x.x that method y was superior in all
cases, apart from the relatively rare instances of..."
rather than "we tried one stupid tool after another in
total frustration until we were totally fed-up and at the
end of the day, in utter desperation and exasperation we
thought method x was the best and just ran with it! ". The
first seems to have been methodically and clinically
analysed in a professional manner whereas the second seems
more of a personal emotive journey, which is probably of
little interest to the reader, so the basis for the
decision seems more random and circumstantial rather than
logically evaluated. It is best to remain impersonal in
your discussion and stick to the facts in a scientific or
technological report.
It is also good practice to give scientific or technical
reasons for some behaviour, especially if it was unexpected
or counter-intuitive. e.g. Despite being an O(n^3)
algorithm, a slight reduction (1%) in data size in the
range observed resulted in over 2 orders of magnitude
increase in speed, which we attribute to the compiler being
able to optimise better data placement in cache due to the
slightly reduced data size. This was confirmed by turning
off relevant flags on the gcc compiler, such as
"reorder-blocks-and-partition". Similarly detailed
arguments might apply to issues with interfaces between
technologies or involving threads, and afford you an
opportunity to show your depth and range of knowledge and
analytical ability, and form a good impression with any
reader.
Grammar and spelling.
Naturally you should run your text through a spell-checker
and proof-read to enhance grammar and style, even if your
word processor claims to do such, as you are more
knowledgeable of the domain and intended meaning. The
normal typographical convention is that single spaces are
left between words and all punctuation marks, except a
full-stop, which is followed by two spaces for a following
sentence, unless a paragraph or other break follows.
Structure
A structure is basically an organised
way of arranging things, so that it holds together and
serves the desired function : in this case, your facts and
findings are organised into a report recording and
communicating your methods and conclusions. Clearly,
knowledge is a graph of inter-related themes and topics,
like the web, but for the purposes of presentation in a
bound report is generally dimensionally reduced to a tree,
a matrix, or even a list, which proceeds along the main
theme, stage by stage in a sequential manner.
Subsidiary themes can be introduced at any stage - tending
towards a list of sublists; in effect a tree, and with
increasing cross references, it approximates a graph.
******* FINISH LATER *****
Initially, try to devise a
structured outline which flows logically from one section
to the next to make it easier for reader and writer alike
to cover the topic. It also helps you spot any omissions in
your discussion and where best to include them. The
guidelines below were developed from those for postgraduate
theses, so they are biased towards reports on fundamental
research on a major theme with a single thread of logic
flow rather than software or product development, which may
involve combining several themes; so please adapt as
appropriate. Clearly most of what I say below is
commonsense, and consequently rather obvious and
superfluous, but it is probably worth being reminded.
The basic options are
Sequential structure: covering all relevant topics or
themes, stage by stage.
Traditional research report structure
follows the logical and temporal sequence of a
single major research theme, roughly following these stages
and chapter headings:
1 - introduction to topic,
2 - review of state of the art,
3 - opportunity / rationale / motivation / strategy /
theory for improvement,
4 - implementation
5 - discussion of results
6 - conclusion and future work.
followed by appendices, bibliography and possibly an index.
A software development project may follow a somewhat
similar sequence, but differs in a few major respects.
Generally there will be less emphasis on fundamental theory
and research but more emphasis on design and implementation
details, such as: project management; timelines,
deliverables; requirements specification, design and
testing; with the probable inclusion of many technologies.
These topics are generally best relegated to an appendix,
since they are incidental and common to most projects.
Their inclusion in the main body of the report may be seen
as distracting and superfluous to the main thrust of the
project. While it is good practice to follow such
methodologies, excessive presentation of this type of
material may be seen as padding, or merely repetition of
lecture notes, since they have already been covered
adequately in degree modules on software engineering and
related topics. The obvious exceptions are when the project
specifically addresses some novel aspect of software
engineering with an emphasis on such issues, or the
supervisor advises or requires it.
Therefore, although most reports will generally follow a
similar sequential structure to that above, the delineation
between adjacent chapters may vary depending on
circumstances, as may the existence of some, or extensions
to include other chapter-topics and consequently this
affects the overall structure of the report.
Thematic structure - a single theme at a time, covering all
sequential stages.
One obvious instance, where this apples, is where a
multiplicity of threads: themes, techniques or technologies
were used your project, rather than a single major research
thread. In the case of multiple threads, it might be easier
and less confusing for reader and writer alike, to deal
with each thread of investigation separately and
in its entirety within each chapter, using
subsections within each chapter to mirror the normal
chapter sequence of introduction, review, improvement,
implementation, results and conclusion. The aim is to
cover all stages of a single technique or
technology, before moving onto another thread of discussion
for another technique or technology, so giving a coherent
presentation of a single theme.
Otherwise each chapter in a sequential structure
above would address a single stage (intro, review,
improvement, implementation, results, conclusion) over all
threads, so that continuity across stages within any single
thread is lost between chapters, and it could appear
scattered and confusing for any reader, requiring excessive
effort to follow the plot, as it were.
In general a hybrid structure.
Naturally, there is no point in getting totally hung up on
structure; ultimately it is a compromise between "it's the
thought that counts!" and "It's not what you say, but the
way you say it!" No amount of structure will compensate for
poor content, but just be aware that good content can be
ruined by poor structure. The reality is that the content
and context will dictate the appropriate writing style,
with cross-references as appropriate. All you can do is try
to simplify the structure in an attempt to maximise clarity
and logical flow and minimise confusion and the need for
cross-referencing either explicitly by the writer having to
insert them, or implicitly by reader having to refer to the
index or contents to follow your report.
The choice of structure, in some ways, is analogous to
ordering doubly nested loops, with the overall aim being to
minimise logical context switching for both reader and
writer to avoid confusion and benefit from temporal memory
locality in the reader's mind. Alternatively, it might be
viewed as concurrent interacting threads of execution, with
attendant complexities.
In general, of course, a hybrid approach is probably the
best, depending on the requirements of the discussion. The
sequential structure of a single thematic traditional type
report is trivial, whereas a report dealing with multiple
themes and technologies is a little more problematic. For a
thematic structure involving multiple themes or
technologies, the overall context ('big picture') for the
entire project, could be set out in earlier combined
chapters, such as the introduction, giving a rationale,
structure and layout both for the project and report, while
all the threads from individual techniques could be woven
together in a 'grande finale' at the end, in either a
results or conclusion chapter as appropriate, thus
following the traditional sequential structure at the
beginning and end. To minimise confusion in the case of
multiple technology threads, the middle section could deal
with each thread in it's entirety.
Naturally this is a decision which should be clear to the
writer, and any further discussion on structure in the
absence of real concrete examples would be pointless and
wasteful for all.
Content: Context, Contribution and
Critique.
Regardless of structure, it is really the content and
analysis that counts, and in all sections, from
introduction to conclusion, it is in your interest: to
place things in context, showing that you know the area in
general; to give a critique to show you know the
shortcomings or how it could be improved; and finally your
contribution (although it does not have to be strikingly
original or significant, but must be your own) to show your
and have made reasonable design and implementation
decisions based on your intended direction within the
constraints of resources, be they computing, software or
time.
However, further details on writing reports, following the
traditional sequential structure are available at:-
More detailed guidelines
on the actual report - assuming a traditional
sequential report structure.
The Impromptu version - worth
having a look at, especially if you are bored with
this!
You may also wish to consult the section on grading before beginning your
report.