Surviving a final year project

About these notes

This informal guide was written by Dr Andy Brooks (andy@unak.is). The guide is
his personal view and is written from the perspective of a student doing a project
which involves building software as a basis for performing empirical investigations.

Word processing
Decide on your word processing environment early on (Word, Latex,...). Do your
best to eliminate spelling and grammatical mistakes. There is no excuse for a
sloppily produced report in this day and age. Proof read on screen before on
paper. Don’t waste a lot of time learning to use exotic word processing features
but you should master the production of contents’ pages, chapters, references,
appendices and footnotes1 .

Get phased
Most software projects involve the phases of specification, analysis, design, im-
plementation, and test. Most reports will have chapters reflecting each of these
phases. A well rounded project and report will likely attract more marks. (Of
course some projects will involve prototyping, but this just means going round
design, implementation, and test phases more than once.)
Agree a project timetable with your supervisor. By the middle of Semester
1 you should aim to have provided draft Introductory and Literature Review
Chapters. You should aim for a fairly full draft of the report three weeks before
the hand-in.
Don’t mess about. Set aside time each day and work consistently. If you
don’t apply yourself to the task you make things far more difficult for yourself in
the long run. It is very, very difficult to do a project properly if it is all left to
the last minute.
Always make written notes at meetings with your supervisor: supervisors
never like having to repeat several points weeks later. Use e-mail to keep in
touch with your supervisor: this can avoid wasting time knocking on/waiting
outside doors.
1
Don’t overdo use of footnotes...

1
Project Log Book
Keep a project log book. Keep a record of all your project activity (with dates).
Your supervisor may ask to see your project log book at any time.

Supplied code
Sometimes, to make it easier to develop something a bit more worthwhile, projects
will involve extending some existing code (perhaps a class framework obtained
over the Internet). In these cases it is vital to explicitly document ownership of
the supplied code and the code added. Never seek to pass off code as your own
which you have not written - it is not allowed.

The Report
Introduction
In the introductory chapter, restate the project specification (with some fleshing
out), briefly describe each of the forthcoming chapters, and detail the facilities
used (hardware and software used, remembering to note version numbers). If
you can’t state the project aim clearly then something is wrong. It might be best
to write out a full Software Requirement Specification and submit as a report
appendix.
Try to write a paragraph or two on how the project relates to Information
Technology in the large (e.g. training issues, productivity issues, safety issues,
automation issues, useability issues).

Literature Review
As part of the analysis phase, spend about three to four weeks reading and
writing a review of relevant literature. A report will normally contain between
ten to twenty references. A supervisor may supply copies of some of the essential
references, but also spend a little time performing literature searches of your own.
If you are doing a research-oriented project you will spend more time doing such
searches than someone doing a more straightforward project: your supervisor will
advise.
First, try to find dedicated textbooks in the University Library. Then try
to find relevant articles through the electronic databases accessible through the
University Library.
The Internet can also be searched for articles of interest. Also see the Journals
and Bibliographies links from Andy’s home page. BYTE magazine, Communi-

2
cations of the ACM, and COMPUTER magazine (IEEE) should contain at least
one good article on your project topic.
When writing a review, try to be critical. Make positive as well as negative
comments. You should try to discuss in depth one or two key articles. Describe
content in you own words. Where this proves problematic, give an explicit quo-
tation of one or two lines. Don’t be tempted to copy whole chunks - it is not
allowed. Make sure to use proper referencing techniques for articles e.g. to quote
Brooks[1],
The first rule of software hasn’t been written.
Be consistent with the style of referencing you use throughout your report.

Design
If there is a recognized design method for the software you are constructing,
make use of it. Sometimes a high level design or software architecture diagram
will suffice, other times it might be necessary to do a full design. At the very
least incorporate one or two design diagrams. Try to discuss design alternatives
and to argue the case for your chosen design.
It might be relevant to discuss international standards or good practice guide-
lines.
You might have a separate chapter to discuss the design of any experiment in-
volved with the software (software robustness tests, algorithmic performance tests
of time and memory usage, human-computer interface evaluations etc.) or the de-
sign of a questionnaire. It is usually good to prototype/try out human-computer
interaction evaluations/questionnaires on one or two subjects beforehand to firm
up and improve designs.

Graphical User Interface

Make a decision about whether the human-computer interface is to be a major
part of the project. Developing a GUI can take up to half of the available project
time. If you do build a GUI try and evaluate it by performing an empirical
investigation i.e. by asking others to use your system to perform some task and
recording their reactions.

Implementation
Describe data structures, algorithms, or objects implemented. Describe any prob-
lems and how they were resolved. State if the software conforms to international
standards or good practice guidelines (e.g. Java Code Conventions). Discuss in
depth the most complex parts of the implementation. Discuss your reasoning
behind using or not using particular language features. You might also discuss

3
performance issues if efficiency of code execution is important or if memory con-
sumption is a factor.
Justify the hardware and software platform you have used, even if this means
stating only pragmatic considerations.
For most projects, the bulk of project time will be spent implementing the
system. Above-average students can consider learning and using a language com-
pletely new to them, but a language may be so suitable that it just has to be used
even though quite a lot of project time will be spent mastering the new language.

Evaluation
Once a system has been built, it is usual to test or evaluate it in some way
i.e. to carry out some form of empirical investigation. The software may be
rigorously subjected to a battery of test cases. Algorithmic performance profiles
may be determined. The software interface may be rigorously tested from an
human-computer interaction point of view by asking several subjects (usually
other students) to try and perform tasks using the system. In this case time and
accuracy might be recorded and it is usually very productive to get participants
to fill in a questionnaire.
Either way, a data set can be obtained which can be analyzed and interpreted.
In the first instance, base your data analysis on simple descriptive statistics per-
haps supplemented with use of simple statistical tests such as the t-test or the
chi-square test. Tabulate raw data in an appendix. Always try to include as
much raw data as is reasonable: it allows a check on any summaries of the data
in the body of your report and at least the data is properly recorded should a
re-analysis be required during the write-up. Only if you are an experienced user
of statistical packages should you consider applying more complicated analysis of
variance techniques.
An alternative approach to evaluation is to be inductive rather than deductive
i.e. you try to find meaningful patterns within the data set.
When it comes to demonstrating a project, it can be a big plus to show results
of some data analysis (even if this is just the results of traditional testing) over
and above showing that your program executes.

Conclusions
The final chapter should always state clearly both what was and what was not
achieved in terms of the original specification. Limitations of your system should
be clearly stated. It is usually seen as a considerable weakness if a report fudges
at this point. Also state clearly what you would have liked to have done given
additional time and resources i.e. have a sub-section called future work.

4
Appendices
Restate the original project description (as say Appendix A) so the reader can
see what the starting point of the whole project was.
Any program you have written, either in a normal language such as Java or
in an application toolkit, should be fully documented in the appendices (com-
mented code listings, design diagrams, User Guide, test results, etc.). It may
be appropriate to submit some of this material on CD-ROM. Make it very clear
how your software can be accessed and run. Remember, if you have made use
of software produced by another, it is vital to explicitly document ownership of
the supplied code and the code added. Never seek to pass off code as your own
which you have not written - it is not allowed.
If you are working in a particularly jargon-rich area there is no harm in pro-
viding a glossary defining terms and abbreviations.
Sometimes it can be useful placing screen captures in an appendix as a docu-
mentation aid. This is especially helpful when there is a human-computer inter-
action emphasis to a project.

Supervisor’s drafts
It is always useful to get comments on the literature review after the first draft -
so supply one to your supervisor by the middle of Semester 1.
About three weeks before the hand-in deadline, try and give your supervisor
a draft of as much as possible of your final report. This will allow time for any
supervisor suggestions to be acted on.

Don’t forget
Be prepared to demonstrate your final system and answer questions about it.
A final year project is not simply like a large assignment where you code up
a solution and nothing more. I expect some results in a data set which can be
analyzed and interpreted.
Get a copy of the project marking scheme and see how marks get apportioned.
When report writing, rather than write in the abstract, it is usually better
style to discuss concrete examples. When report writing, it is better to keep
things simple and to the point. Short sentences are better than long ones with
complex punctuation.

References
[1] A Brooks. Software rules. Software Engineering Heresy, 5(3):185–194, 1984.