Académique Documents
Professionnel Documents
Culture Documents
2013/2014
2013/2014
Table of Contents
1.
INTRODUCTION
......................................................................................................................................
5
1.1
OVERVIEW
.................................................................................................................................................
5
1.2
LEARNING
OUTCOMES
..................................................................................................................................
5
1.3
LEARNING
METHODS
....................................................................................................................................
5
1.4
ASSESSMENT
..............................................................................................................................................
5
1.5
PROJECT
TYPES
...........................................................................................................................................
6
2.
THE
IMPORTANCE
OF
FINAL
YEAR
PROJECTS
..........................................................................................
7
2.1
RESPONSIBILITY
...........................................................................................................................................
7
2.2
RECOMMENDED
READING
.............................................................................................................................
7
3.
PROJECT
ORGANISATION
........................................................................................................................
7
3.1
PROJECT
PROPOSAL
.....................................................................................................................................
7
3.2
PROGRESS
REPORTS
.....................................................................................................................................
8
3.4
INTERIM
REPORT
.......................................................................................................................................
8
3.5
FINAL
REPORT
.............................................................................................................................................
8
4.
PLANNING
YOUR
PROJECT
......................................................................................................................
8
4.1
PROJECT
PLANNING
..................................................................................................................................
9
5
EXECUTING
YOUR
PROJECT
....................................................................................................................
9
5.1
READING
YOUR
WAY
INTO
THE
TOPIC
..............................................................................................................
9
5.2
PROBLEM
ANALYSIS
...................................................................................................................................
10
5.3
SOLUTION
................................................................................................................................................
11
5.4
DESIGN
....................................................................................................................................................
12
5.5
IMPLEMENTATION
.....................................................................................................................................
12
5.6
SOLUTION
EVALUATION
..............................................................................................................................
13
6
DOCUMENTATION
................................................................................................................................
14
6.1
DOCUMENTING
YOUR
PROJECT
....................................................................................................................
14
6.2
DOCUMENTING
YOUR
WORK
.......................................................................................................................
14
6.5
PROJECT
REPORT
.......................................................................................................................................
15
6.6
PROJECT
PRESENTATION
.........................................................................................................................
17
7.
ASSESSMENT
OF
YOUR
PROJECT
..............................................................................................................
17
7.1
PROJECT
DELIVERABLES
..............................................................................................................................
17
7.2
ASSESSMENT
CRITERIA
................................................................................................................................
18
7.3
ADDITIONAL
INFORMATION
.........................................................................................................................
18
APPENDIX
A:
GENERAL
PROJECT
INFORMATION
..........................................................................................
19
DEADLINES
...........................................................................................................................................................
19
REPORT
LENGTH
....................................................................................................................................................
19
HOW
TO
SUBMIT
YOUR
REPORT
...............................................................................................................................
19
FINAL
YEAR
PROJECT
CO-ORDINATOR
.......................................................................................................................
19
APPENDIX
B:
WHAT
IS
RESEARCH?
...............................................................................................................
20
APPENDIX
C:
A
VERY
SHORT
GUIDE
TO
GOOD
WRITING
.............................................................................
21
APPENDIX
D:
GIVING
PRESENTATIONS
.........................................................................................................
22
APPENDIX
E:
TYPICAL
STRUCTURE
OF
A
FINAL
YEAR
DEVELOPMENT
PROJECT
REPORT
................................
23
APPENDIX
F:
TYPICAL
STRUCTURE
OF
A
FINAL
YEAR
RESEARCH
PROJECT
REPORT
........................................
27
APPENDIX
G:
TITLE
PAGE
AND
DECLARATION
..............................................................................................
31
APPENDIX
H:
PROJECT
PLANNING
................................................................................................................
33
G.1
TASKS
......................................................................................................................................................
33
G.2
THE
PROJECT
PLAN
....................................................................................................................................
33
G.3
UPDATING
THE
PROJECT
PLAN
.....................................................................................................................
34
APPENDIX
I:
DESIGN
.....................................................................................................................................
36
APPENDIX
J:
TESTING
...................................................................................................................................
38
APPENDIX
K:
SOFTWARE
ENGINEERING
DOCUMENTS
..................................................................................
39
2013/2014
2013/2014
1.
INTRODUCTION
The
final
year
project
is
one
of
the
most
important
aspects
of
your
degree.
It
provides
you
with
an
opportunity
to
apply
the
principles
learned
in
different
modules,
and
integrate
material
learned
at
different
stages
of
the
course.
There
may
also
be
a
need
for
additional,
domain-specific
knowledge
for
your
project,
which
will
necessitate
additional
study.
1.1
OVERVIEW
You
will
execute
a
significant
project
in
an
area
of
relevance
to
Computer
Science
and
Software
Engineering.
Every
project
is
unique,
but
this
will
generally
involve:
1. Planning
your
project.
2. Executing
your
project.
3. Documenting
your
work.
4. Critically
assessing
your
project.
You
are
expected
to
produce
something
significant
in
your
project:
a
software
implementation,
the
evaluation
of
your
solution
to
a
research
problem,
or
an
evaluation
of
existing
solutions.
1.2
LEARNING OUTCOMES
On
successful
completion
of
the
module,
you
should
be
able
to
apply
your
knowledge
and
understanding
of
computer
science
and
software
engineering
to
analysing
problems,
creating
and
evaluating
solutions,
and
critically
assessing
your
own
work.
You
should
also
be
able
to
prepare
project
plans,
give
presentations,
and
write
reports.
1.3
LEARNING METHODS
The
final
year
project
is
a
self-learning
exercise,
under
the
guidance
of
your
supervisor.
The
following
six
learning
elements
form
the
basis
of
your
project:
knowledge,
understanding,
applying,
analysing,
evaluating,
and
creating.
During
your
project,
you
are
expected
to
use
these
as
follows:
Develop
an
understanding
of
the
technical
domain
knowledge
on
which
your
project
is
based
Apply
your
knowledge
and
understanding
in
executing
the
project
Analyse
a
problem
Create
a
solution
(synthesis)
And
evaluate
your
work
1.4
ASSESSMENT
Semester
1
Interim
Report
and
Presentation
Semester
2
2013/2014
1.5
PROJECT TYPES
There
are
two
types
of
Final
Year
Project:
the
Development
Project
and
the
Research
Project.
The
objective
of
the
research
project
is
to
solve
a
research-oriented
problem.
This
may
take
the
form
of
evaluating
the
effectiveness
of
existing
solutions,
modifying
existing
solutions,
or
even
developing
a
new
solution
to
the
problem.
In
any
case,
your
evaluation
of
the
solution
is
the
key
output.
The
focus
is
on
following
sound
experimental
techniques,
and
evaluating
the
solution
thoroughly.
The
main
output
is
your
report.
This
shows
how
well
the
solution
you
have
worked
on
solves
the
problem.
You
will
do
background
research
into
the
domain
area,
and
a
literature
review
of
existing
publications
to
develop
a
sound
basis
for
your
work.
You
will
evaluate
the
success
of
your
solution,
using
experimental
methods,
in
terms
of
how
well
it
solves
the
research
problem.
The
solution
you
develop
is
the
principle
output
of
your
project;
any
software
you
develop
is
a
tool
to
evaluate
your
solution.
You
must
test
your
software
to
make
sure
it
correctly
implements
your
solution
before
you
run
experiments
to
evaluate
its
effectiveness.
2013/2014
Experimental
research
in
computer
science
and
software
engineering
is
based
on
the
scientific
method,
which
can
be
summarized
as
follows:
1. Formulate
a
hypothesis
(that
your
solution
solves
a
problem
against
selected
criteria)
2. Select
meaningful
measurements
3. Design
and
conduct
experiments,
and
collect
the
results
4. Use
statistical
methods
to
analyse
the
data
5. Interpret
and
explain
the
results
6. Evaluate
any
threats
to
the
validity
of
the
research
results
7. Use
the
results
to
confirm
or
refute
your
hypothesis
You
will
probably
put
a
significant
amount
of
effort
into
solving
the
problem.
You
only
have
a
limited
amount
of
time
available,
so
you
must
decide
with
your
supervisor
how
you
are
going
to
balance
the
time
for
solving
the
problem
against
implementing
and
testing
your
solution.
Note
that
untested
software
is
a
threat
to
the
validity
of
your
results!
2.
You
will
continue
to
gain
experience
after
you
graduate,
but
the
final
year
project
will
be
your
first
exposure
to
a
significant
computer
science
and
software
engineering
project.
It
is
essential
that
you
learn
from
this
exposure,
and
practice
all
of
the
methodologies
involved.
It
is
also
important
that
you
learn
not
just
how
to
apply
what
you
know,
but
also
to
apply
it
with
judgement,
with
the
ability
to
assess
what
you
are
doing
and
to
be
critical
of
it.
Your
final
year
project
is
also
an
important
element
in
determining
your
final
degree
grade.
Also,
for
borderline
cases,
examiners
may
use
your
project
performance
in
deciding
your
overall
result.
2.1
RESPONSIBILITY
It
is
important
to
note
that
you
are
responsible
for
your
project.
Your
supervisor
will
provide
you
with
guidance
and
feedback,
but
you
must
put
in
the
effort
to
achieve
a
successful
project.
So
work
hard
on
your
final
year
project,
while
balancing
your
time
and
effort
with
your
taught
modules.
2.2
RECOMMENDED READING
The
following
provide
reference
material
that
you
may
find
useful
during
your
project:
q The
Essence
of
Computing
Projects,
by
C.
W.
Dawson,
Prentice-Hall,
(latest
edition)
q
A
Lightweight
Software
Development
Process
for
Student
Projects,
NUIM-CS-TR-2005-09
q
Testing
Guidelines
for
Student
Projects
,
NUIM-CS-TR-2005-05
q CS353
Guidelines
for
Condensed
Software
Development
Documentation
Version
1.0.0,
September
27th
2010
q
Guidelines
for
Documents
Produced
by
Students
Projects
in
Software
Engineering,
NUIM-CS-TR-
2002-05
q Document
Templates
for
Student
Projects
in
Software
Engineering,
NUIM-CS-TR-2002-06
All
technical
reports
are
available
on
the
Department
of
Computer
Science
website.
3.
PROJECT ORGANISATION
There
are
a
number
of
organizational
matters
you
should
be
aware
of
to
complete
your
project
successfully.
3.1
PROJECT PROPOSAL
2013/2014
Before
being
accepted
for
a
project,
you
must
submit
a
Proposal
to
your
intended
supervisor.
This
must
describe
the
aims
of
the
project
and
discuss
the
methodology
you
intend
to
use
in
achieving
those
aims.
See
the
FYP
Proposal
Template
in
the
Appendix
for
details.
Supervisors
suggest
both
specific
projects,
and
project
areas,
on
the
departmental
website.
Review
these
carefully,
and
then
go
and
talk
to
potential
supervisors
who
have
indicated
projects
that
sound
of
interest
to
you.
3.2
PROGRESS REPORTS
Your
supervisor
may
require
you
to
submit
periodic,
written
progress
reports.
A
typical
report
might
contain:
1. The
project
title
2. Your
name
3. A
short
description
of
your
progress
since
the
previous
report
4. A
summary
of
the
work
you
expect
to
complete
before
the
next
report
3.4
INTERIM REPORT
You
will
be
required
to
submit
an
interim
report,
and
make
a
short
presentation
on
your
project,
at
the
end
of
Semester
1.
The
report
should
describe
the
background
material/literature
review
for
your
project,
detail
the
problem
description,
and
summarise
your
approach.
This
presentation
should
consist
of
five
slides
(See
Appendix
D:
Giving
Presentations):
Goals
of
your
Project
Overview
of
Background
Progress
to
Date
Problems
Encountered
Planned
Next
Steps
3.5
FINAL REPORT
You
will
submit
a
final
report
at
the
end
of
your
project.
See
Appendix
D
for
suggested
report
structures.
4.
One
of
them
most
important
things
you
will
learn
when
doing
your
project
is
the
need
to
manage
your
time.
Final
Year
Projects
are
completely
different
from
smaller
projects
you
may
have
undertaken.
They
require
a
considerable
amount
of
time:
1
q Single
Honours
Science
students
should
spend
240
hours
(accounting
for
25%
of
final
year
marks)
q CSSE
students
should
spend
240
hours
(accounting
for
25%
of
final
year
marks)
q Double
Honours
Science
students
should
spend
80
hours,
normally
in
the
first
semester
(accounting
for
16.7%
of
final
year
marks)
1
Including special entry courses: Computer Science & Theoretical Physics, HDipCS, etc.
2013/2014
Begin
your
project
early,
work
consistently
at
it,
and
track
your
progress.
A
project
plan
helps
you
to
thinking
about
all
the
things
you
need
to
do,
their
inter-relationships,
and
the
time
each
will
take.
4.1
PROJECT PLANNING
In
order
to
plan
your
project,
you
should
identify
the
tasks
you
need
to
complete.
It
helps
to
organise
these
by
major
activities
(as
described,
for
example,
in
Sections
1.5.1/1.5.2).
For
each
activity,
you
should
list
the
tasks.
For
each
task,
you
should
identify
the
following:
Title
Brief
description
of
the
work
to
be
done
Identify
what
the
output
or
deliverable
will
be
Estimate
the
start
and
end
dates
Identify
the
dependencies
(what
tasks
cannot
be
started,
or
completed,
until
this
task
is
completed)
Identify
the
key
risks
to
completing
the
task
on
time,
and
what
contingency
action
you
will
take
if
you
are
unable
to
do
this
Refer
to
Appendix
G
for
more
details.
It
is
important
that
you
take
a
systematic,
problem-solving
approach
to
your
project:
understanding
the
problem,
designing
a
solution,
implementing
the
solution,
testing
the
code,
and
finally
evaluating
your
solution.
Depending
on
the
approach
you
take,
you
may
start
some
of
these
activities
before
completing
previous
ones.
You
may
also
break
the
problem
into
smaller
problems,
and
address
these
in
turn.
You
must
discuss
your
individual
project
with
your
supervisor
to
identify
the
priority
of
the
different
activities
for
your
project.
Your
project
report
is
a
record
of
how
you
addressed
solving
the
problem,
and
records
the
results
of
the
various
activities.
The
documentation
should
not
take
up
much
time
if
you
have
approached
these
activities
in
a
well-structured
way.
It
is
critical
that
all
material
in
your
report
be
your
own
work.
You
must
not
use
direct
quotes
in
your
report,
even
if
you
have
cited
the
source.
If
you
want
to
include
results
from
other
peoples
work,
then
you
must
express
it
in
your
own
words,
and
cite
the
source.
This
does
not
mean
merely
replacing
words
with
synonyms;
it
means
rewriting
it
completely
to
show
your
understanding
of
the
material.
Cutting
and
pasting
any
material
directly
into
your
report
or
plagiarism
a
severe
academic
offence.
5.1
At
the
outset
you
need
to
learn
as
much
as
possible
about
the
area
in
which
youll
be
doing
the
project,
as
quickly
and
efficiently
as
possible.
Structure
your
research,
and
avoid
reading
much
but
learning
little.
q Collect
any
papers,
articles,
book
chapters
you
can
on
the
area
and
make
a
copy
for
your
own
personal
archive.
q Make
sure
you
keep
a
detailed
record
of
the
source
of
everything
you
read.
Typically,
you
need
to
record
the
title
of
the
article,
the
authors,
the
name
of
the
magazine/journal/book,
the
volume
and
number
of
the
journal
or
magazine,
the
publisher,
the
year
it
was
published,
and
the
page
numbers.
If
its
a
chapter
in
a
book
and
the
author
of
the
chapter
is
different
from
the
editor
of
the
book,
you
need
to
record
both
sets
of
names.
Incomplete
references
are
not
acceptable
-
you
must
provide
all
information
necessary
to
get
a
copy
of
that
article.
You
will
include
all
this
information
at
the
end
of
your
project
report
in
the
2013/2014
References
section.
(Note:
A
URL
alone
is
not
acceptable
as
a
reference,
but
you
may
include
URLs
to
assist
the
reader
in
accessing
a
copy
to
read).
q Not
all
the
articles
you
collect
will
be
equally
relevant
or
important.
Consequently,
its
not
efficient
to
give
each
of
them
the
same
attention.
But
its
not
easy
to
know
how
relevant
it
is
until
you
read
it.
So
how
do
you
proceed?
To
solve
this
dilemma,
you
should
know
that
there
are
three
levels
of
reading:
1. Shallow
Reading:
you
just
read
the
article
quickly
to
get
an
impression
of
the
general
idea.
Read
it
twice.
This
should
take
a
half-an-hour
to
an
hour.
2. Moderate
Reading:
Read
the
article
in
detail
and
understand
all
of
the
main
concepts;
this
will
probably
require
you
to
read
it
several
times
and
take
a
couple
of
hours
to
assimilate.
3. Deep
Reading:
Here
you
make
an
in-depth
study
of
the
article.
This
may
take
you
several
hours
or
even
a
couple
of
days.
After
many
careful
readings,
you
should
know
as
much
about
the
topic
as
the
author.
The
way
to
proceed
with
your
reading
in
is
to:
q Shallow
read
everything
and
write
a
5-line
summary
of
the
article.
q If
you
think
the
article
is
directly
relevant
to
your
project,
label
it,
and
put
it
on
a
list
of
articles
to
be
read
at
the
next
level,
i.e.
Moderate
Reading.
q Read
all
the
labelled
articles
and
write
a
1-page
summary.
q If
the
article
is
going
to
be
used
directly
in
the
project,
e.g.
as
a
basis
for
a
hardware
design
or
a
software
algorithm,
then
you
need
to
add
it
to
your
list
of
articles
to
be
read
at
the
next
level,
i.e.
Deep
Reading.
q Read
all
the
Deep-Read
articles
and
write
extensive
notes
on
them.
Note
that
the
reading
in
phase
of
the
project
can
last
quite
a
long
time
(theres
a
lot
of
reading
and
writing
to
be
done)
and
it
can
overlap
partially
with
some
of
the
other
early
tasks).
Finally,
it
is
very
important
to
realise
that,
in
order
to
fully
understand
anything
that
you
read,
you
must
write
it
up
in
your
own
words.
If
you
cant
express
or
speak
about
a
given
idea,
then
you
havent
truly
understood
it
in
any
useful
way.
This
is
so
important,
its
worth
saying
a
third
time:
Writing
is
an
Essential
Part
of
Understanding
This
is
why,
in
all
of
the
above
guidelines,
you
see
recommendations
to
write
things
down.
(See
the
section
on
documenting
your
research).
5.2
PROBLEM ANALYSIS
Having
chosen
your
project,
you
will
have
in
your
possession
a
short
description
of
what
is
involved
in
the
project.
You
will
realise
by
now
that
this
is
completely
insufficient
for
you
as
a
basis
for
doing
the
project.
Consequently,
your
next
task
must
be
to
find
out
exactly
and
completely
what
the
project
entails.
This
isnt
as
easy
as
it
sounds.
You
might
think
that
you
should
just
ask
your
supervisor
and
he
or
she
should
tell
you.
It
doesnt
work
like
that.
Quite
often,
a
supervisor
wont
have
an
exact
(and
complete)
model
of
what
is
required
supervisors
are
just
like
clients
and
customers
in
the
business
and
industrial
world.
It
is
your
job
to
help
your
supervisor
identify
exactly
what
he
wants.
Thats
what
good
computer
science
practitioners
do:
they
help
people
understand
what
they
want
and
then
they
build
it
for
them.
Heres
how
you
do
it.
1. Talk
to
your
supervisor
10
2013/2014
2.
3.
Write
down
everything
he
or
she
says
(by
write
down
I
mean
take
notes
of
his
or
her
words)
Write
up
everything
he
or
she
says
(by
write
up
I
mean
express
what
your
supervisor
said
in
your
own
words).
4. Consult
with
your
supervisor
to
make
sure
you
have
understood
them
(show
your
supervisor
your
write-
up,
and
ask
for
their
feedback).
5. Read
into
the
problem
area,
to
see
what
others
have
done.
This
will
generally
highlight
a
number
of
opportunities
and
pitfalls.
6. Document
what
you
think
is
required,
including
functional
and
non-functional
requirements.
7. Or,
build
a
prototype
of
what
you
think
is
required.
8. Go
back
to
your
supervisor
and
ask
for
her
or
his
comments.
9. Return
to
step
1,
and
keep
returning
until
you
are
both
happy
with
your
requirements
document.
This
all
translates
into
one
simple
rule:
find
out
what
you
want
the
final
system
to
do,
write
it
down,
and
get
everyone
involved
to
agree
to
it
in
writing.
Make
sure
you
include
all
relevant
detail:
every
single
aspect
of
whats
wanted
should
be
teased
out
and
agreed:
what
it
does,
what
it
doesnt
do,
how
the
user
is
to
use
it
or
how
it
communicates
with
the
user,
what
messages
it
displays,
how
it
behaves
when
the
user
asks
it
to
do
something
it
expects,
and
especially
how
it
behaves
when
the
user
asks
it
to
do
something
it
doesnt
expect.
For
a
development
project,
this
process
is
called
requirements
elicitation
-
you
have
to
work
actively
with
the
client
to
find
out
what
they
really
want
(as
opposed
to
what
they
initially
say
they
want,
which
is
a
completely
different
thing).
It
is
important,
as
it
is
the
basis
of
all
your
work
that
follows,
but
it
will
probably
only
take
up
about
10%
of
your
project
time.
The
User
Requirements
Document
provides
a
template
for
how
you
may
present
the
results
of
this
work.
For
a
research
project,
this
is
probably
going
to
be
a
longer
activity.
It
is
half
of
your
research
work:
the
other
half
is
creating
a
solution.
You
should
consult
with
your
supervisor
how
best
to
present
the
results
of
this
work
it
will
form
the
core
of
your
background
or
literature
review
of
your
report.
For
both
types
of
project,
a
key
output
is
your
problem
statement:
a
clear
and
concise
description
of
the
problem
you
are
solving
in
your
final
year
project.
This
is
the
foundation
of
all
science:
the
creation
of
a
rigorous
usually
mathematical
description
of
the
problem
to
be
addressed.
For
example,
if
your
problem
concerned
with
packet
routing,
you
might
represent
it
using
a
graph
and
deploy
formal
graph
theoretic
tools
for
its
analysis;
if
your
problem
is
concerned
with
signal
analysis,
you
might
choose
a
Fourier
representation
or
an
Eigen-vector
representation
and
deploy
the
appropriate
theorems
in
Fourier
analysis
or
linear
system
theory.
If
your
problem
is
to
do
with
building
a
database,
you
will
probably
model
the
system
with
an
entity-relationship
diagram
and
validate
the
model
by
normalisation.
Be
careful
not
to
involve
design
decisions
in
your
analysis.
Sometimes
the
design
solution
wall
fall
out
naturally
from
the
analysis,
but
if
you
are
making
decisions
then
you
have
moved
to
the
Solution
activity
as
described
in
the
next
section.
5.3
SOLUTION
Having
developed
a
clear
understanding
of
the
problem,
you
now
need
to
invent
or
design
a
solution.
For
a
research
project,
this
is
the
most
important
element
of
your
work.
You
will
probably
do
some
theoretical
development,
and
usually
prove
or
at
least
demonstrate
the
effectiveness
of
your
solution
using
analytical
techniques.
You
will
document
this
in
your
project
report.
For
a
development
project,
you
will
be
analysing
the
problem,
deciding
what
inputs
your
solution
must
accept,
and
the
functionality
and
storage
required
to
produce
the
outputs.
Do
not
concern
yourself
with
details
of
the
interface
yet
you
will
be
designing
them
next.
11
2013/2014
For
both
types
of
projects,
you
will
need
to
work
out
the
requirements
for
input
data,
processing,
and
output
data.
You
can
document
your
work
by
producing
a
User
Requirements
Specification.
5.4
DESIGN
You
must
do
at
least
two
different
types
of
design.
The
first
is
to
design
a
software
product
that
realises
your
solution
to
the
problem.
This
will
identify
the
details
of
the
inputs
and
outputs,
and
identify
any
processing
and
storage
requirements.
For
example,
you
will
design
your
GUI
screens
here.
This
is
traditionally
called
a
Software
Requirements
Specification,
as
it
specifies
the
requirements
that
your
software
must
meet.
The
second
is
to
design
the
software
to
implement
this
product.
This
will
show
how
the
inputs
are
handled,
how
the
processing
is
done,
how
internal
data
storage
is
achieved,
and
how
the
outputs
are
generated.
Do
not
confuse
these
two:
at
the
software
design
stage
you
should
not,
for
example,
be
making
decisions
about
what
the
GUI
will
look
like,
but
rather
how
you
are
going
to
implement
it
given
the
programming
language/environment
you
are
using.
Typically
you
need
to
use
two
levels
of
abstraction
for
your
software
design:
1. a
high-level
design,
showing
the
architecture
of
your
solution
(e.g.
the
major
classes,
and
how
they
interact
with
each
other)
2. a
detailed
design,
showing
the
details
of
the
software
components
(e.g.
the
attributes
and
methods
for
each
class).
Use
an
incremental
implementation
approach.
Dont
attempt
to
build
the
entire
system
in
one
go
in
the
hope
that,
when
you
switch
it
on
or
run
it,
it
will
work.
This
is
the
so-called
Big
Bang
approach
(everything
comes
into
existence
at
one
instant)
and
its
name
is
very
appropriate,
for
it
almost
always
results
in
initial
chaos.
It
is
much
better
to
design,
code,
and
test
each
software
feature
individually
and
add
them
to
an
ever
expanding
system.
In
general,
it
is
best
to
complete
the
high-level
design
first,
but
then
design,
code,
and
test
in
an
incremental
manner.
See
Appendix
I
for
more
details.
5.5
IMPLEMENTATION
5.5.1
CODING
When
re-using
code
that
you
did
not
write,
you
must
create
a
separate
file
containing
this
code.
All
such
reused
code
must
be
properly
documented
and
also
properly
tested
before
use,
and
this
testing
must
be
documented.
It
is
prohibited
to
mix
your
code
with
reused
code
in
any
file.
You
will
be
expected
to
submit
your
source
code
for
assessment.
Make
sure
it
is
clearly
structured,
conforms
to
your
coding
standard,
and
is
well
documented
and
commented.
Make
sure
that
any
code
that
is
not
completely
your
own
work
is
clearly
identified.
Source
code
should
by
submitted
along
with
your
project
report.
12
2013/2014
Validation
ensures
that
you
have
built
the
correct
system.
That
is,
that
your
solution
as
realised
in
the
software
does
actually
solve
the
original
problem.
Software
testing
should
usually
be
automated
(using,
for
example,
CPPUnit
or
JUnit)
for
speed
of
execution,
reliability,
and
repeatabilty.
Unit
testing
should
always
be
automated.
System
testing
can
usually
be
automated
using
various
test
tools
(e.g.
web
test
tools
such
as
Webpagetest,
or
GUI
test
tools
such
as
Abbot/Costello
or
Visual
Studio
Test
Professional).
Appendix
J
gives
more
details
on
testing.
Read
NUIM-CS-TR-2005-05
for
more
details
on
how
you
might
go
about
testing
your
software.
5.6
SOLUTION EVALUATION
Having
developed
an
implementation
of
your
solution,
and
demonstrated
that
it
works
correctly,
you
now
need
to
evaluate
how
well
it
works
in
solving
the
original
problem.
A
research
project
fundamentally
consists
of
a
hypothesis
and
experiments
to
either
confirm
or
refute
it.
Your
hypothesis
is
that
your
solution
solves
the
problem
you
will
need
to
formulate
a
more
detailed
wording
for
your
project
however.
You
implement
your
solution
in
code,
and
run
experiments
against
it.
By
collecting
the
results,
and
analysing
them
using
statistical
methods
(usually),
you
can
then
either
prove
or
refute
the
hypothesis.
You
must
be
careful
about
threats
to
validity
consider
how
valid
your
results
are,
and
how
far
can
you
generalise
them.
If
you
have
done
some
theoretical
development
during
your
research,
which
you
are
evaluating
with
a
software
implementation,
then
your
verification
is
testing
individual
functions
or
classes
to
make
sure
they
perform
as
specified,
validation
is
making
sure
that
the
system
meets
the
requirements,
and
evaluation
is
measuring
how
well
your
system
works.
13
2013/2014
In
the
normal
course
of
events
in
a
computer
science
project,
there
comes
a
time
when
the
system
is
commissioned
and
it
becomes
operational.
As
time
passes,
it
is
necessary
to
monitor
the
performance
of
the
system
and
make
adjustments
and,
occasionally,
to
replace
it.
It
is
almost
inevitable,
too,
that
the
requirements
will
change
with
time
and
this,
in
turn,
will
necessitate
alterations
and
upgrades.
Typically,
this
phase
is
not
of
major
concern
in
a
final
year
project
but
its
as
well
to
be
aware
of
it
since
the
majority
of
the
life
of
a
system
is
spent
in
this
phase
of
its
life-cycle.
DOCUMENTATION
We
noted
earlier
that
writing
is
an
essential
part
of
understanding.
We
note
it
again
here
but
in
a
different
sense.
In
this
case,
writing
is
essential
in
order
for
others
to
understand
what
you
have
done.
There
are
two
reasons
why
you
want
others
to
understand
your
work:
1. So
that
you
can
be
given
credit
for
it
(your
final
mark
depends
on
it);
2. So
that
others
can
carry
on
your
work
and
develop
or
maintain
your
system.
It
is
extremely
important
that
you
document
your
work
at
every
stage
of
your
project.
We
saw
already
that
documentation
is
essential
in
the
initial
reading-in,
requirements,
and
specification
phases
but
it
is
equally
important
in
the
design,
implementation,
test,
and
maintenance
phases.
The
best
way
to
organise
your
writing
is
to
keep
a
a
log
book
of
all
work
in
progress.
You
should
go
out
and
buy
a
hard-cover
notebook
and
write
everything
you
do
on
the
project
into
this
log
book
every
day.
Every
thought
and
observation
you
have
on
your
project
should
go
into
this
book,
along
with
notes
of
meetings
with
your
supervisor,
results,
theoretical
developments,
calculations,
everything.
This
log
book
will
become
an
invaluable
source
of
material
when
you
come
to
write
up
your
project
in
the
final
report.
It
will
also
provide
relevant
material
for
your
monthly
reports.
You
should
submit
the
log-book
to
your
supervisor
at
the
end
of
the
project.
However,
dont
wait
until
the
end
of
the
project
to
begin
the
process
of
formal
documentation.
At
the
end
of
each
phase
of
the
project
(or
at
the
end
of
each
task)
you
should
write
up
any
documentation
and
reports
related
to
that
phase.
These
will,
in
turn,
contribute
to
your
final
report.
Finally,
there
is
one
other
form
of
documentation
that
you
will
have
to
create
during
your
project.
This
is
the
final
presentation.
6.1
Your
assessment
is
primarily
based
on
the
quality
of
the
work
you
have
done,
as
expressed
through
the
report
you
produce.
6.2
The
main
reason
for
documenting
the
work
you
have
done
for
your
final
year
project
is
assessment.
For
this
reason
it
is
important
that
this
is:
concise,
precise,
and
complete.
A
suggested
report
layout
is
included
in
Appendix:
Typical
Structure
of
a
Final
Year
Project
-
but
remember
it
is
the
content
that
is
most
important.
Note
that
this
does
not
mean
that
you
just
simply
have
to
fill
in
the
gaps
in
a
general
report
template.
The
standard
structure
simply
provides
you
with
a
place
to
start
as
you
begin
to
design
the
final
structure
and
content
of
your
documents.
You
will
still
have
to
do
quite
a
lot
of
work
to
make
it
fit
your
own
project
A
second
reason
for
documenting
your
work
is
to
provide
experience
for
the
future:
be
it
in
industrial
development,
or
research,
or
another
setting.
You
will
need
to
produce
documentation
and
reports
in
almost
all
careers,
and
the
final
year
project
provides
you
with
an
opportunity
to
experience
this
in
a
guided
and
supervised
context.
14
2013/2014
Note
that
for
some
projects
the
research
will
provide
the
basis
for
your
software
development;
in
other
projects,
your
software
development
will
provide
the
basis
for
evaluating
your
own
theoretical
developments.
In
either
case,
the
research
must
be
well
performed,
and
the
software
must
be
developed
and
tested
in
a
systematic
manner.
Reference
technical
report
NUIM-CS-TR2003-09
for
additional
details
of
how
to
document
your
work
in
a
structured
manner.
6.5
PROJECT REPORT
Your
final
report
is
a
critical
part
of
your
project.
It
defines
what
you
have
done
and
why
you
have
done
it.
It
is
the
chief
way
that
your
project
is
examined
and
assessed
and
it
on
the
basis
of
the
report
that
you
will
be
assessed.
In
writing
your
Final
Report,
you
will
need
to
decide
on
its
content
and
on
its
structure.
We
will
look
at
both
of
these
aspects
in
turn,
beginning
with
the
content.
We
will
conclude
with
a
few
guidelines
on
good
writing
practice.
15
2013/2014
The
structure
of
your
report
is
critical
to
the
impact
you
make
in
your
writing.
Remember
that
you
are
trying
to
convey
a
message
to
the
reader
and,
since
this
message
is
likely
to
be
quite
complicated,
you
must
assist
him
or
her
by
making
your
points
clearly
and
in
a
logical
order.
Think
of
it
as
telling
an
exciting
story:
you
want
to
tell
enough
early
on
to
attract
the
readers
interest
but
not
too
much
otherwise
he
will
become
confused.
You
want
to
build
up
to
a
climax,
incrementally
revealing
more
and
more
of
your
message,
but
doing
so
in
a
way
which
builds
on
what
you
have
already
said.
This
is
what
we
mean
by
a
logical
structure:
breaking
up
the
story
into
a
sequence
of
messages
which
follow
naturally
one
from
the
other
and
which
lead
to
an
interesting
conclusion
(i.e.
a
conclusion
you
couldnt
have
guessed
from
reading
page
1).
A
clear
structure
will
help
you
avoid
repeating
(or
contradicting)
yourself.
Structure
also
makes
sure
that
the
reader
knows
what
part
the
current
information
plays
in
the
overall
thesis.
You
should
design
your
own
report
to
the
level
of
detail
given
in
the
proposed
structure,
adapting
it
to
your
own
particular
needs.
Note
that
you
should
do
this
before
you
start
writing
anything.
Its
just
like
designing
a
piece
of
software:
the
sooner
you
start
coding,
the
longer
it
will
take
(and
the
more
likely
it
is
to
be
wrong).
Try
to
achieve
modularity
and
independence
amongst
your
chapters
and
sections.
At
the
same
time,
remember
you
are
trying
to
convey
a
convincing
message
to
the
reader.
Again,
its
like
telling
a
good
story:
you
have
to
keep
the
reader
interested
and
he
has
to
be
able
to
follow
the
story-line
(which
means
there
has
to
be
one:
make
sure
there
is).
Keep
the
thread
of
the
story
going
continuously,
from
section
to
section,
and
from
chapter
to
chapter
by
providing
link
sentences
or
paragraphs:
at
the
end
of
a
chapter,
for
example,
remind
the
reader
of
the
important
messages,
tell
him
why
they
are
important,
and
then
say
what
you
need
to
look
at
next,
and
why,
in
order
to
continue
with
the
story.
Thats
your
cue
for
the
next
chapter.
A
typical
outline
of
a
final
year
project
report
is
provided
in
the
following
pages.
A
typical
report
would
consist
of
a
front
page
and
declaration,
an
abstract,
a
table
of
contents,
and
the
following
chapters:
Introduction
Project
Planning
Background
and
Problem
Statement
Solution
Software
Implementation
Experiments
and
Results
Conclusions
Followed
by
a
References
section.
Details
of
the
size
of
your
report
etc.
are
given
in
Appendix
A.
Detailed
examples
of
report
layouts
are
given
in
Appendices
E
and
F.
Note
that
copyright
of
the
projects
rests
with
the
University
as
do
all
intellectual
property
rights
associated
with
the
project.
In
essence,
this
means
that
the
report
is
confidential
to
the
University
and
may
not
be
copied,
published,
or
otherwise
disseminated
without
the
prior
written
permission
of
the
University.
16
2013/2014
6.6
PROJECT PRESENTATION
Your
final
presentation
should
consist
of
five
slides
suggested
titles
are:
Introduction
o Give
a
very
brief
description
of
your
project
goals.
o Describe
the
motivation
for
your
project.
Background
o Describe
the
background
to
your
work.
o Identify
previous
work
your
based
your
work
on.
o Show
you
understand
the
context
of
your
work.
The
Problem
o Describe
the
problem.
o Include
technical
details.
The
Solution
o Describe
the
solution(s)
you
developed
and/or
evaluated.
o Include
technical
details.
o Identify
any
threats
to
the
validity
of
the
solution.
Evaluation
o Summarise
how
you
evaluated
the
solution.
o Summarise
the
results
of
your
evaluation
of
the
solution.
o Evaluate
how
well
you
executed
your
project
-
for
example:
how
well
you
understood
new
knowledge
how
well
you
learned
to
use
new
tools
how
well
you
evaluated
the
solution
7.1
PROJECT DELIVERABLES
3.
4.
5.
17
2013/2014
7.2
ASSESSMENT CRITERIA
Your
project
will
be
assessed
on
your
demonstration
of
the
following:
Category
Nominal
Weighting
18%
Analysis
18%
Application
18%
Synthesis
18%
Evaluation
18%
Presentations
10%
Note
Always 10%
The
relative
weight
of
each
of
the
first
5
categories
is
tailored
by
your
supervisor
to
match
your
project.
See
Appendix
M
for
details.
7.3
ADDITIONAL INFORMATION
In
special
cases,
the
External
Examiner
may
ask
to
interview
students
on
the
final
year
project.
18
2013/2014
DEADLINES
Deliverable
Submit
your
project
acceptance
form
Deliver
your
interim
presentation
Deliver
progress
reports:
monthly
Submit
your
final
report
to
Moodle
Deliver
your
final
presentation
Demonstrate
your
work
Provisional
Dates
th
October
4
th
December
20
st
th
th
Monthly:
Oct
31 ,
Nov
29 ,
Dec
20
th
March
24 ,
2014
th
April
16-17 ,
2014
th
April
28 ,
2014
The
marks
awarded
for
reports
submitted
after
the
deadline
will
be
reduced
by
2%
for
every
day
(or
any
part
of
a
day)
that
they
are
late
-
up
to
a
maximum
of
14%
deduction
for
projects
7
days
overdue.
Projects
will
not
be
accepted
later
than
one
week
past
the
deadline.
REPORT
LENGTH
Your
final
report,
in
PDF
format,
must
not
exceed
either
40
pages
or
12,000
words.
The
report
page
layout
should
be
A4,
using
12
Point
Time
New
Roman,
1.5
line
spacing,
and
leaving
left
and
right
margins
of
approximately
25mm.
You
can
use
Word,
Latex,
or
any
other
suitable
tool
to
prepare
your
report:
consult
with
your
supervisor
first.
This
total
includes
everything
in
the
report:
the
front
page,
table
of
contents,
contents,
index,
figures,
references,
etc.
Attachments
(source
code,
models,
planning
documents
and
records,
software
testing
details
and
results,
experiment
details
and
results,
etc.
in
PDF
format)
do
not
contribute
to
this
page
count.
Overdue,
oversized
or
otherwise
unsatisfactory
reports
will
be
penalised
(by
up
to
20%).
19
2013/2014
20
2013/2014
Use
short
sentences
and
make
sure
the
sentences
are
complete.
A complete sentence usually has a subject followed by a verb and an object. For example:
The compiler identified two syntax errors. We can add other words to enhance the
descriptiveness and richness of the sentence: The C++ compiler identified two subtle
syntax errors but, unfortunately, it was unable to find the semantic errors in my program.
If
you
remove
all
ancillary
words,
you
should
be
left
with
a
valid
sentence;
if
not,
then
you
havent
written
the
sentence
correctly.
Its
a
good
idea
to
check
all
your
sentences
this
way.
Good
writing
strikes
a
balance
between
short
sentences
and
longer
ones.
Just
as
in
speaking,
the
full
stops
mean
pauses:
too
many
pauses
and
the
text
sounds
disconnected,
too
few
and
it
can
be
hard
to
follow
the
story
line.
Strike
a
balance:
favour
brevity
over
complexity.
Use
pictures
and
diagrams,
with
a
self-contained
explanatory
caption
for
each.
Never
refer
to
a
picture
or
diagram
in
the
main
text
without
saying
what
it
is.
For
example,
never
say
Figure
2.3
shows
the
results
of
the
noise
test
and
then
carry
on
to
another
topic.
Help
the
reader.
Summarise
the
content
of
the
figure
in
a
short
sentence:
Figure
2.3
shows
the
results
of
the
noise
test
which
demonstrate
the
robustness
of
the
system
to
Gaussian
noise
with
a
standard
deviation
of
2.3
or
less.
If
you
have
copied
the
figure
you
must
cite
the
source.
Make
the
paragraph
your
unit
of
construction.
Each
paragraph
should
contain
sentences
about
a
given
subject.
If
the
subject
changes,
start
a
new
paragraph.
Omit
unnecessary
words
they
distract
the
reader.
Dont
write:
This
is
a
system
the
performance
of
which
is
very
useful.
Instead,
write:
This
is
a
useful
system.
Write
in
a
way
that
comes
naturally.
Speak
the
sentence.
If
it
sounds
correct,
trust
your
ear
and
use
the
sentence.
If
it
sounds
unnatural,
rewrite
it.
Be
clear
in
your
expression.
If
the
idea
you
are
trying
to
convey
is
getting
lost
in
a
sea
of
words
and
phrases,
draw
a
line
through
the
sentence
and
start
again.
Avoid
unusual
words,
unless
they
have
a
specific
meaning
that
is
important
to
your
sentence.
Dont
take
short-cuts.
Explain
what
you
mean.
Dont
leave
the
reader
to
struggle
trying
to
figure
out
what
the
real
meaning
is
of
a
complex
sentence;
he
may
conclude
there
is
none.
Explain
all
acronyms
the
first
time
you
use
them.
Revise
and
rewrite.
It
is
unlikely
that
you
will
manage
to
find
the
best
way
of
expressing
an
idea
with
your
first
attempt.
Be
prepared
to
revise
it,
again
and
again.
Finally,
if
you
want
to
learn
how
to
write
a
good
report,
you
need
to
do
two
things:
you
need
to
read
other
good
reports
and
you
need
to
practise
your
own
writing.
Adapted from The Elements of Style by W. Strunk & E.B. White, Macmillan 1979.
21
2013/2014
q
q
q
q
q
q
q
q
Dont
depend
too
much
on
PowerPoint
slides:
your
speech
is
the
presentation
and
the
slides
support
you
(not
the
other
way
around).
Do
NOT
just
read
the
text
from
slides
it
is
very
boring
for
the
audience.
Use
slides
to
show
other
aspects
of
your
research
(for
example,
diagrams,
animations,
screen-shots,
photographs,
diagrams,
etc.).
These
make
a
presentation
more
interesting.
Take
your
time:
pause
frequently.
Sometimes,
the
best
thing
to
say
is
nothing.
Short
one-second
rests
create
dramatic
impact
and
also
give
your
audience
time
to
assimilate
what
youve
said.
Of
course,
you
also
have
to
maintain
continuity
and
flow;
otherwise
people
forget
what
you
are
talking
about.
Its
a
question
of
balance.
Use
a
microphone
(and
practice
using
it
before
your
presentation).
Arrive
early
and
make
sure
you
know
where
all
the
equipment
is.
Know
how
to
use
it.
Copy
your
presentation
onto
the
machine
before
your
session.
Look
at
the
audience,
not
at
your
slides.
Project
your
voice
(but
dont
shout).
Smile:
enjoy
giving
your
presentation.
Be
confident:
youve
done
some
great
work
here
is
your
opportunity
to
get
credit
for
it.
The
people
in
the
audience
are
on
your
side
(though
sometimes
they
disguise
it
well!)
They
want
you
to
succeed.
If
they
ask
you
a
question
you
dont
understand,
say
so
and
ask
their
help.
Ask
them
to
explain,
and
ask
nicely.
If
you
still
dont
understand,
dont
bluff.
Admit
your
ignorance
and
suggest
ways
of
how
you
will
overcome
that
lack
of
knowledge.
Nobody
knows
everything;
but
thats
no
excuse
for
not
trying
to
know
everything.
A
knowledgeable
person
knows
enough
to
do
his
job
well,
a
wise
person
knows
that
he
doesnt
know
everything,
and
an
intelligent
person
knows
how
to
find
out
what
he
doesnt
know.
Be
knowledgeable,
wise,
and
intelligent:
be
a
computer
scientist.
22
2013/2014
23
2013/2014
Chapter
3
Project
Management
Introductory paragraph
3.1 Approach
Discuss how you planned the project, and why you planned it the way you did
3.2 Initial Project Plan
Show your initial project plan in the form of a Gantt Chart and a brief description, showing
planned dates. If your task names are not self-explanatory, provide a table to explain the
tasks.
3.3 Problems and Changes to the Plan
Identify problems you faced that caused you to change the plan, and justify the changes.
3.4 Final Project Record
Show your final project plan in the form of a Gantt Chart and a brief description, showing
actual dates.
You should include your full project plan, all intermediate plans, and status reports (see Project Plan)
in an appendix.
Chapter
4
Analysis
Introductory Paragraph this is where you describe and analyse the problem in detail
4.1 Problem Modelling
Breakdown the problem into the different user tasks that the user needs to perform in
order to solve their problem. Summarise the tasks here, perhaps describing a few key ones
in more detail, and identifying the inputs and outputs for each. You might find it useful to
include a summary User Case diagram.
4.2 Non-Functional Requirements
Summarise any requirements that the user has for security, reliability, maintainability,
portability, performance etc.
Include full analysis details (see User Requirements Specification), with Use Case Diagrams, State
Machines, and Activity Diagrams in the Appendix.
Chapter
5
Product/System
Design
Introductory paragraph this is where you describe your solution to the problem
5.1 Introduction
Discuss how you designed the software, identify different design options, and justify why you
picked the one used
6.2 Product Features
Identify and summarise the key product features. For a GUI these are the main commands that
the user can give. For a networked system, these are the main protocol messages accepted.
For an embedded system these are the main external events that the system must respond to
6.3 User Interface
For each product feature, state what each user interface component must do (state the inputs,
actions, and outputs). Include a detailed design for each screen in the Appendix.
6.4 Interfaces to External Hardware and Software
For each product feature, identify the key inputs, actions, and outputs to each important item
of external hardware or software. Include a detailed design in the Appendix.
6.5 Non-Functional Requirements
Summarise requirements on your product/system for security, reliability, maintainability,
portability, performance etc. You should review your software design against these
requirements.
6.6 Data Storage
Summarise what data must be placed in persistent store within the product/system, and what
relationships must be maintained.
24
2013/2014
6.7 Design Verification
Summarise how your product/system design satisfies the user requirements. One way is to
walk through a few key user tasks, using Sequence Diagrams to show how the combination
of features allows the user to achieve the task.
Include full design details (see Product Design Document) in the Appendix.
Chapter
6
Software
Design
Introductory paragraph
6.1 Introduction
Discuss how you designed the software, identify different design options, and justify why you
picked the one used
6.2 High Level Design
Summarise the top level objects and their relationships (e.g. UML Class Diagrams)
6.3 Detailed Design
Summarise the object contents (e.g. Javadoc specifications for Methods and Attributes)
6.4 Design Verification
Summarise how your design satisfies the product/system design requirements. One way is to
walk through a few key product features, showing how the combination of classes allows
the feature to be supported.
Include full design details (see Software Design Specification) in the Appendix.
Chapter
7
Implementation
Introductory paragraph
7.1 Introduction
Discuss your choice of language, tools and platform.
7.2 Coding
Where not obvious, discuss how you translated the detailed design into code (for example:
how you decide to code association classes and two-way associations).
7.3 Verification
Summarise how you tested the code (unit test and system test). Discuss the techniques you
used to select test cases and test data. Summarise the test results, showing that the software
satisfied the detailed design, and that the product/system satisfies the product/system design.
7.4 Validation
Summarise how you showed that the solution satisfies the user requirements. This normally
consists of manual execution of each user task.
Include full source code and testing details (see Software Testing Document and Software Product
Validation) in the Appendix.
Chapter
8
Evaluation
Introductory paragraph
8.1 Metrics
Identify and describe the metrics you used to evaluate your software.
8.2 Experimental Setup
Describe the experimental setup for each metric, and how you obtained the measurements.
8.3 The Experiments
Describe the inputs for each experiment
8.4 Results
Summarise the output data, and the statistical or other techniques to deduce your results.
Summarise your results, including tables or graphs as appropriate with a brief description of
each. Where possible, compare your results with other products/systems.
8.5 Validity
25
2013/2014
Identify any possible threats to the validity of your results, and discuss each.
26
2013/2014
27
2013/2014
Clearly state the problem that you are attempting to solve in your project
Chapter
3
Project
Management
Introductory paragraph
3.1 Approach
Discuss how you planned the project, and why you planned it the way you did
3.2 Initial Project Plan
Show your initial project plan in the form of a Gantt Chart and a brief description, showing
planned dates. If your task names are not self-explanatory, provide a table to explain the
tasks.
3.3 Problems and Changes to the Plan
Identify problems you faced that caused you to change the plan, and justify the changes.
3.4 Final Project Record
Show your final project plan in the form of a Gantt Chart and a brief description, showing
actual dates.
You should include your full project plan, all intermediate plans, and status reports (see Project Plan)
in an appendix.
Chapter
4
Analysis
and
Solution
Introductory Paragraph this is where you describe and analyse the problem in detail
4.1 Problem Modelling
This is the foundation of all science: the creation of a rigorous usually mathematical
description of the real physical problem to be addressed. For example, if your problem
concerned with packet routing, you might represent it using a graph and deploy formal graph
theoretic tools for its analysis; if your problem is concerned with signal analysis, you might
choose a Fourier representation or an Eigen-vector representation and deploy the appropriate
theorems in Fourier analysis or linear system theory. If your problem is to do with building a
database, you will probably model the problem with an entity-relationship diagram. Your
model should identify the inputs that your solution should accept, and the outputs that it
should produce.
4.2 Solution
This is the most critical section of your report. Describe your solution, identifying different
options and their pros and cons. Show, preferably mathematically, how your solution solves
the problem. Provide a model of your solution that clearly identifies the computation required
to produce the outputs from the inputs.
If you need extra space, then include full analysis details in the Appendix.
Chapter
5
Product/System
Design
Introductory paragraph this is where you describe the realisation of your solution to the problem
5.1 Introduction
Discuss how you designed the software, identify different design options, and justify why you
picked the one used
6.2 Product Features
Identify and summarise the key product features. For a GUI these are the main commands that
the user can give. For a networked system, these are the main protocol messages accepted.
For an embedded system these are the main external events that the system must respond to
6.3 User Interface
For each product feature, state what each user interface component must do (state the inputs,
actions, and outputs). Include a detailed design for each screen in the Appendix.
6.4 Interfaces to External Hardware and Software
28
2013/2014
For each product feature, identify the key inputs, actions, and outputs to each important item
of external hardware or software. Include a detailed design in the Appendix.
6.5 Non-Functional Requirements
Summarise requirements on your product/system for security, reliability, maintainability,
portability, performance etc. You should review your software design against these
requirements.
6.6 Data Storage
Summarise what data must be placed in persistent store within the product/system, and what
relationships must be maintained.
6.7 Design Verification
Summarise how your product/system design implements your solution. One way is to walk
through different applications of the solution, using Sequence Diagrams to show how the
combination of features allows the product/system to produce the correct output.
Include full design details (see Product Design Document) in the Appendix.
Chapter
6
Software
Design
Introductory paragraph
6.1 Introduction
Discuss how you designed the software, identify different design options, and justify why you
picked the one used
6.2 High Level Design
Summarise the top level objects and their relationships (e.g. UML Class Diagrams)
6.3 Detailed Design
Summarise the object contents (e.g. Javadoc specifications for Methods and Attributes)
6.4 Design Verification
Summarise how your design satisfies the product/system design requirements. One way is to
walk through a few key product features, showing how the combination of classes allows
the feature to be supported.
Include full design details (see Software Design Specification) in the Appendix.
Chapter
7
Implementation
Introductory paragraph
7.1 Introduction
Discuss your choice of language, tools and platform.
7.2 Coding
Where not obvious, discuss how you translated the detailed design into code (for example:
how you decide to code association classes and two-way associations).
7.3 Verification
Summarise how you tested the code (unit test and system test). Discuss the techniques you
used to select test cases and test data. Summarise the test results, showing that the software
satisfied the detailed design, and that the product/system satisfies the product/system design.
7.4 Validation
Summarise how you showed that the solution satisfies the user requirements. This normally
consists of manual execution of each user task.
Include full source code and testing details (see Software Testing Document and Software Product
Validation) in the Appendix.
Chapter
8
Evaluation
Introductory paragraph
8.6 Metrics
Identify and describe the metrics you used to evaluate your software.
29
2013/2014
8.7 Experimental Setup
Describe the experimental setup for each metric, and how you obtained the measurements.
8.8 The Experiments
Describe the inputs for each experiment
8.9 Results
Summarise the output data, and the statistical or other techniques to deduce your results.
Summarise your results, including tables or graphs as appropriate with a brief description of
each. Where possible, compare your results with other products/systems.
8.10 Validity
Identify any possible threats to the validity of your results, and discuss each. Make sure to
explicitly cover the threat to validity that would be introduced if you software did not actually
implement your solution correctly.
30
2013/2014
Project
Title
Optional
Subtitle
Full
Name
Final
Year
Project
-
2013
B.Sc.
Single/Double
Honours
in
Computer
Science/Computer
Science
and
Software
Engineering
(delete
where
not
applicable)
Department
of
Computer
Science
National
University
of
Ireland,
Maynooth
Co.
Kildare
Ireland
A
thesis
submitted
in
partial
fulfilment
of
the
requirements
for
the
B.Sc.
Single/Double
Honours
in
Computer
Science/Computer
Science
and
Software
Engineering.
31
2013/2014
Declaration
I
hereby
certify
that
this
material,
which
I
now
submit
for
assessment
on
the
program
of
study
leading
to
the
award
of
B.Sc.
Single/Double
Honours
in
Computer
Science/Computer
Science
and
Software
Engineering,
is
entirely
my
own
work
and
has
not
been
taken
from
the
work
of
others
-
save
and
to
the
extent
that
such
work
has
been
cited
and
acknowledged
within
the
text
of
my
work.
Signed:
_________________________________
Date:
_________________
32
2013/2014
G.1
TASKS
The
following
is
a
guide
to
identifying
the
tasks
for
a
project
plan
q Identify
and
number
all
the
major
tasks,
use
the
typical
project
major
activities
shown
previously
as
a
starting
point
q Break
large
tasks
into
sub-tasks
(as
a
rule
of
thumb,
each
sub-task
should
take
about
1
week
to
complete).
Give
these
unique
numbers
of
the
form
task-number.sub-task-number.
A
task
with
sub-tasks
is
referred
to
as
a
summary
task.
q For
each
task,
and
sub-task,
which
is
NOT
a
summary
task:
As
discussed
above,
provide
a
unique,
numerical
task
identifier
of
the
form
taskNumber
or
taskNumber.subtaskNumber
or
taskNumber.subtaskNumber.subsubtaskNumber.
Estimate
how
much
effort
you
expect
it
to
take
(this
is
the
work
in
hours)
and
over
what
period
you
will
spread
that
effort
(this
is
the
duration
in
days).
Identify
the
required
inputs
information,
software,
hardware,
and,
most
important
of
all,
any
outputs
from
previous
tasks
in
your
project.
Identify
the
expected
results
(also
called
the
outputs
or
deliverables)
of
the
task.
Identify
a
course
of
action
to
take
if
the
task
fails
for
some
reason
(e.g.
the
software/hardware
doesnt
arrive
in
time).
q Now
identify
the
order
in
which
you
should
undertake
the
tasks.
In
this,
you
will
have
to
consider
the
relationships
between
each
task,
and
the
use
of
the
outputs
of
some
tasks
as
inputs
to
others.
Some
tasks
will
overlap
often
you
wont
be
able
to
complete
one
task
until
you
have
completed
another.
G.2
In
drawing
up
your
project
plan,
you
should
use
a
standard
project
management
tool
(such
as
Microsoft
Project,
or
GanttProject.
These
tools
make
it
easier
to
draw
the
schedule,
make
changes,
and
track
your
progress.
However,
they
wont
do
the
planning
for
you,
i.e.
they
cant
identify
tasks,
subtasks,
effort,
duration,
etc.
Thats
something
you
have
to
do
yourself.
You
should
be
able
to
make
a
first
attempt
at
this
by
the
time
youve
finished
reading
the
handbook.
Most
projects
can
be
best
presented
using
the
following
two
techniques:
1. a
table
of
tasks,
with
dates,
durations,
and
work
for
each
(see
Fig.
1)
2. a
Gantt
chart
(see
Fig.
2)
You
should
use
summary
tasks
to
summarise
or
represent
major
activities.
The
work,
duration,
start-date
and
end-date
of
a
summary
task
are
calculated
automatically,
so
dont
enter
them
manually!
It
is
clearest
to
produce
one
top-level
plan
to
show
activities
and
major
tasks,
with
only
the
top-level
tasks
shown,
and
then
develop
additional
more
detailed
plans
for
each
activity.
Otherwise
your
Gantt
chart
probably
33
2013/2014
wont
fit
on
a
single
page.
These
more
detailed
plans
will
usually
be
drawn
up
once
you
get
nearer
to
the
activity
or
task
in
question,
and
have
a
clearer
idea
of
exactly
you
will
go
about
it.
You
may
even
need
to
break
it
into
sub-tasks
once
you
have
clearer
understanding
of
the
work
involved.
Make
sure
to
put
a
date
and
revision
number
on
every
plan
you
produce.
Task Table
Activities & Tasks
Start Date
1 PREPARATION
Mon,30-Sep-02
1.1 Initial reading
Mon,30-Sep-02
1.2 Review the literature
Mon,21-Oct-02
1.3 Exploratory programming
Mon,04-Nov-02
1.4 Prepare requirements specification
Mon,25-Nov-02
1.5 Update the project plan
Mon,02-Dec-02
2 DEVELOPMENT
Tue,03-Dec-02
2.1 Develop system design
Tue,03-Dec-02
2.2 Develop basic program
Tue,10-Dec-02
2.3 Add support for feature <xxx>Tue,17-Dec-02
2.4 Add support for feature <yyy>Tue,24-Dec-02
Christmas Break
Tue,31-Dec-02
2.5 Extend feature <yyy>
Mon,30-Dec-02
2.6 Add <zz1> and <zz2>
Mon,06-Jan-03
2.7 Enhance the GUI
Mon,20-Jan-03
2.8 Fix major faults
Mon,27-Jan-03
3 WRITEUP
Mon,03-Feb-03
3.1 Prepare project report
Mon,03-Feb-03
3.2 Prepare demonstration
Thu,27-Feb-03
3.3 Prepare presentation
Fri,28-Feb-03
Duration
[days]
64
19
12
19
5
1
60
7
7
7
7
5
5
12
5
5
26
24
1
1
Work
[days]
End Date
45 days Mon,02-Dec-02
15 days
Fri,18-Oct-02
10 days
Fri,01-Nov-02
15 days
Fri,22-Nov-02
5 days
Fri,29-Nov-02
1 days Mon,02-Dec-02
40 days
Fri,31-Jan-03
5 days Mon,09-Dec-02
5 days Mon,16-Dec-02
5 days Mon,23-Dec-02
5 days Mon,30-Dec-02
Fri,27-Dec-02
5 days
Fri,03-Jan-03
10 days
Fri,17-Jan-03
5 days
Fri,24-Jan-03
5 days
Fri,31-Jan-03
20 days
Fri,28-Feb-03
18 days Wed,26-Feb-03
1 days Thu,27-Feb-03
1 days
Fri,28-Feb-03
Project Summary
Start Date
End Date
Duration
Workdays
Total Work Hours
Work/day
Work/week
Mon,30-Sep-02
Fri,28-Feb-03
151 days
105 days
240 hours
2.3 hours
11.4 hours
G.3
34
2013/2014
You
will
probably
need
to
update
the
plan
once
you
have
fully
understood
the
requirements
and
done
some
exploratory
programming.
You
may
need
to
make
further
updates
at
each
stage
of
the
project
in
order
to
plan
in
more
detail.
Modify
the
plan
as
necessary,
making
sure
to
update
the
version
number
and
the
version
control
history
sections
each
time.
do
NOT
delete
the
old
Gantt
charts
from
your
plan,
but
rather
add
the
new
ones.
Your
final
plan
should
contain
two
Gantt
charts
in
the
body
of
the
document,
the
first
one
and
the
last
one.
A
historical
record
of
all
the
interim
Gantt
charts
should
be
included
as
an
appendix.
Make
sure
to
discuss
significant
changes,
and
the
reasons
for
them,
in
your
project
report.
Your
report
should
include
both
your
original
timetable
(best
shown
as
a
Gantt
Chart),
and
your
final
project
plan
(which
is
in
effect
a
record
of
when
each
task
was
actually
worked
on
and
completed).
35
2013/2014
APPENDIX
I:
DESIGN
I.1
PRODUCT DESIGN
I.2
SOFTWARE DESIGN
I.2.1
HIGH-LEVEL DESIGN
Design
a
product
to
encapsulate
your
solution.
In
many
cases
this
will
be
an
application
with
a
GUI
interface
but
there
are
many
other
types
of
programs.
Design
software
to
realise
this
product.
And
finally
code
the
program,
and
test
it
against
the
design
and
product
specifications.
The
natural
conclusion
of
requirements
analysis
is
the
system
specification.
This
specification
shows
what
the
system
will
do
to
meet
the
user
requirements.
It
says
what
the
system
will
do,
under
what
conditions,
and
what
it
will
not
do.
In
writing
the
specification,
you
should
begin
with
the
requirements
document
and
then
you
should
design
and
specify
the
following:
1. The
system
functionality
2. The
operational
parameters
(conditions
under
which
your
system
will
operate)
3. Failure
modes
and
actions
on
failure
4. Limitations
&
restrictions
5. Detail
the
system
interface
(user
interface,
network
interface,
etc.)
You
should
then
validate
the
specification
against
the
requirements,
and
you
should
get
the
explicit
agreement
of
your
supervisor
that
all
is
in
order.
If
it
isnt,
then
you
must
go
back
to
requirements
if
necessary
and
revise
them
and
the
specifications
(with
your
supervisors
agreement
on
everything).
After
this,
you
validate
again,
and
you
keep
doing
this
until
everyone
agrees.
Presenting
your
design
results:
see
the
Product
Design
Specification
template.
With
your
model
in
hand,
you
are
now
in
a
position
to
design
your
system
using
whatever
design
methodology
is
appropriate
for
the
area
(and
these
will
inevitably
be
specific
to
the
particular
area).
That
said,
there
are
a
few
general
guidelines
that
apply
to
all
areas:
q Identify
several
design
options
and
compare
them
q Analyse
your
design
to
ensure
it
is
technically
feasible
(i.e.
validate
its
realizability).
Remember,
you
cant
always
build
everything
you
design,
either
for
theoretical
reasons
(e.g.
NP-completeness)
or
for
pragmatic
reasons
(the
required
hardware
is
not
installed).
q Analyse
your
design
to
ensure
it
meets
the
specifications
(i.e.
verify
that
it
does
what
is
required)
q Choose
the
best
design.
You
will
have
to
define
what
best
means
for
your
particular
project.
It
might
mean
the
cheapest
to
manufacture,
it
might
mean
the
fastest,
and
it
might
mean
the
smallest
it
all
depends.
Its
up
to
you
to
identify
the
test
for
optimality.
q Note
that
this
is
the
hallmark
of
good
computer
science
(and
software
engineering):
the
practice
of
qualitative
and
quantitative
assessment
of
different
options.
Make
use
of
existing
Open
Source
software
where
appropriate.
Presenting
your
design
results:
see
the
Software
Design
Specification
templates.
For
a
high-level
design
you
should
identify
the
principle
software
components
and
what
their
relationship
to
each
other
is.
You
should
verify
your
design
by
showing
how,
in
principle,
these
components
can
act
together
to
meet
the
software
requirements
specification.
36
2013/2014
For
example,
in
an
object-oriented
implementation,
you
would
use
UML
Class
Diagrams
to
identify
the
components
and
their
relationships,
and
Sequence
Diagrams
to
show
how
they
work
together
to
meet
the
requirements.
I.2.2
DETAILED DESIGN
For
a
detailed
design,
you
should
design
the
internal
details
of
each
component
in
the
code.
For
example,
in
an
object
oriented
implementation,
you
might
use
Javadoc
to
specify
the
attributes
and
methods
for
the
Classes
to
meet
the
high-level
design.
You
may,
in
some
cases,
also
specify
the
algorithm
to
be
used.
37
2013/2014
APPENDIX
J:
TESTING
J.1
UNIT TESTING
J.2
SYSTEM TESTING
In
unit
testing
you
execute
a
unit
of
code
(for
Object-Oriented
code
this
is
normally
a
Class),
using
its
programming
interface,
and
make
sure
that
the
outputs
are
as
expected
for
the
particular
inputs.
If
you
dont
do
this,
then
your
code
may
well
work
under
the
limited
set
of
tests
achieved
by
testing
the
entire
system,
but
may
still
have
many
faults
which
may
result
in
failure
of
the
code.
This
can
result
in
the
software
crashing,
or
even
worse
giving
corrupt
results.
For
both
development
and
research
projects
it
is
therefore
important
to
do
at
least
a
minimal
level
of
unit
test.
Note
that
to
enable
unit
testing
your
need
to
consider
design
for
testability.
The
key
issue
for
most
programs
is
to
separate
your
interface
and
functional
code.
This
both
makes
your
design
more
modular,
so
you
could
move
to
a
different
interface
relatively
easily,
and
allows
you
to
test
the
functionality
separately
from
the
interface.
For
example,
if
you
embed
calls
to
the
GUI
in
your
functional
code
to
display
the
results,
then
you
cannot
test
the
functionality.
However,
if
the
GUI
code
calls
the
functional
code
to
get
and
display
the
results,
then
you
can
easily
test
the
functionality
separately.
In
system
testing
you
execute
the
entire
system,
using
its
system,
interface
(i.e.
the
GUI,
a
network
interface,
the
driver
interfaces
to
hardware)
and
make
sure
that
the
outputs
are
as
expected
for
the
particular
inputs.
If
you
dont
do
this,
then
your
units
may
be
operating
correctly
individually,
but
may
not
be
working
together
correctly
as
a
system.
Again,
this
can
result
in
the
software
crashing,
or
even
worse
giving
corrupt
results.
For
both
development
and
research
projects
it
is
therefore
important
to
do
at
least
a
minimal
level
of
system
test.
Some
systems,
especially
for
development
projects,
will
have
well
defined
responses
to
input
stimuli.
For
example,
clicking
on
a
particular
button
in
the
GUI
may
be
required
to
pop
up
a
particular
window.
Other
system,
especially
for
research
projects,
may
have
less
well
defined
responses.
For
example,
drawing
a
image
with
all
the
edges
highlighted.
For
this,
it
is
suggested
that
you
establish
some
ground
truths,
or
standard
test
data,
derived
from
analysis
to
ensure
that
the
software
is
actually
implementing
your
solution
before
you
start
evaluating
how
well
your
solution
works.
J.3
PRODUCT
VALIDATION
With
forward
engineering
working
from
problem
to
solution
to
implementation
you
can
expect
the
implementation
to
solve
the
problem
to
a
certain
extent.
But
this
is
not
always
the
case.
Problems
usually
result
from
poor
understanding
of
the
original
requirements,
or
inadequate
problem
analysis.
Validation
makes
sure
that
the
system
actually
solves
the
problem
that
it
was
intended
to.
Even
if
the
system
has
passed
system
testing,
that
has
really
made
sure
that
the
system
responds
correctly
to
each
individual
input,
rather
than
it
actually
solving
the
problem.
For
a
development
project,
validation
is
the
act
of
determining
whether
your
software
system
meets
the
users
needs.
For
example:
can
you
actually
book
an
airline
ticket
with
your
program.
For
a
research
project,
validation
is
ensuring
that
the
solution
basically
solves
the
problem.
For
example:
is
every
edge
in
an
image
highlighted?
Validation
will
invariably
involve
manual
testing,
with
a
user
inputting
a
series
data
or
commands,
and
then
examining
the
output
to
make
sure
it
solves
the
problem.
You
will
also
be
assessed
on
a
validation
test
of
your
software
by
your
supervisor
and
second
reader.
So
make
sure
that
you
understand
the
requirements
well,
that
the
software
operates
correctly,
and
it
has
adequate
documentation
(or
ease-of-use)
to
allow
its
functionality
to
be
easily
tested.
38
2013/2014
39
2013/2014
PROJECT PROPOSAL
Please
send
this
form
electronically
to
the
Final
Year
Project
Co-ordinator
by
email
prior
to
working
on
your
project.
You
MUST
send
this
document
using
your
Department
of
Computer
Science
or
University
email
address
emails
from
outside
the
NUIM
domain
will
be
ignored.
Student
Name:
Student
Number:
Supervisor
Name:
TITLE
Your
title
should
ideally
pose
a
question
that
your
project
will
investigate,
or
should
succinctly
describe
the
purpose
of
the
project.
OUTLINE
of
TOPIC
and
RELEVANCE
to
SOFTWARE
ENGINEERING
and/or
COMPUTER
SCIENCE
You
should
succinctly
describe
your
topic
and
the
relevance
to
Software
Engineering
and/or
Computer
Science.
It
is
essential
that
you
describe
your
proposed
project
in
the
context
of
your
work
placement
(200-300
words
maximum).
You
should
clearly
outline
the
Specification
of
Requirements
for
the
project.
APPROACH
REFERENCES
and
RESOURCES
You
should
provide
at
least
two
appropriate
key
references
here
(e.g.
conference/journal
publications,
or
books,
or
course
material).
Do
not
include
a
bibliography;
you
must
specifically
reference
these
works
in
the
previous
two
sections.
You
are
discouraged
from
referencing
non-peer
reviewed
sources
such
as
corporate
or
project
websites,
unless
specifically
appropriate.
You
also
should
detail
resources
required,
and
skills
development
required
for
the
project.
SECOND
READER
RESPONSE
Leave Blank.
40
2013/2014
Student Name:
Title of Project:
Supervisor:
1st Reader
2nd Reader:
Valid
Range
Given
Values
Section
Category
Report,
Attachments1,
Demonstration
10-25
18
Application
10-25
18
Analysis
10-25
18
Synthesis
10-25
18
Evaluation
10-25
18
Interim Presentation
Final Presentation
90%
Project
Presentation 10%
TOTAL
100
Marks
Awarded
Grade
Examiners
Comments
See
next
page
for
marking
guidelines.
(1)
Attachments
and
Supporting
Material
as
detailed
in
section
7.1
Project
Deliverables
41
2013/2014
The
project
is
assessed
on
the
Report,
Attachments,
Presentation,
Demonstration,
and
any
other
supporting
material,
based
on
the
following
criteria.
Description:
mark
reflects
how
well
the
student
shows
that
they
have
developed
an
understanding
of
the
technical
domain
knowledge
on
which
the
project
is
based.
This
includes
both
material
from
their
computer
science
course
and
that
acquired
by
the
student
as
part
of
the
project.
Performance
Indicators:
Memorize,
Recite,
Name,
Identify,
Describe,
Explain,
Classify,
Discuss.
Description:
mark
reflects
how
well
the
student
has
applied
their
knowledge
and
understanding
in
executing
the
project.
This
includes
technical
application
and
project
organisation.
o Performance
Indicators:
Apply,
Choose,
Employ,
Operate,
Practice.
Learning
Outcome:
Analysis
o
Description:
mark
reflects
how
well
the
student
has
applied
analytical
skills,
including
statistical
analysis,
to
the
project.
This
may
be
as
applied
to
analysing
the
problem,
to
analysing
their
solution,
and
to
analysing
their
project
execution.
Performance
Indicators:
Compare,
Contrast,
Calculate,
Test,
Analyze.
Description:
mark
reflects
how
well
the
student
has
created
a
solution.
This
includes
both
the
abstract
solution,
and
the
implementation.
o Performance
Indicators:
Construct,
Compose,
Create,
Design,
Propose.
Learning
Outcome:
Evaluation
o
Description:
mark
reflects
how
well
the
student
has
evaluated
their
work.
This
includes
software
testing
(verification),
evaluation
of
the
effectiveness
of
their
solution
(e.g.
through
experiments
or
system
validation),
and
overall
evaluation
of
their
project
execution.
o Performance
Indicators:
Argue,
Assess,
Defend,
Judge,
Evaluate.
o
42
2013/2014
APPENDIX
N:UNIVERSITY
POLICY
ON
PLAGIARISM
Guidance
for
Students
It
is
recognised
that
nearly
all
assignments
and
essays
draw
on
the
work
of
others:
published
research
and
critical
commentary,
lecturers
notes
and
hand-outs,
etc.
The
effective
use
and
evaluation
of
existing
material
are
among
the
skills
that
students
are
expected
to
develop.
Material
is
cited
in
order
to
contribute
to
a
larger
line
of
argument,
or
to
be
subjected
to
scrutiny,
or
to
be
combined
with
other
material
in
order
to
arrive
at
new
perspectives;
value
should
be
added
by
some
original
thinking
in
the
way
in
which
it
is
used.
In
all
cases,
the
source
of
the
material
(an
idea
or
opinion,
a
quote,
data,
etc)
must
be
acknowledged
in
a
standard
form
of
referencing.
Plagiarism
is
the
passing
off
of
another
persons
work
as
your
own.
It
includes
copying
without
acknowledgement
from
a
published
source
(print
or
electronic),
or
from
unpublished
sources
(e.g.
another
students
essay
or
notes).
Plagiarism
occurs
when
material
is
copied
word
for
word,
but
not
only
in
that
circumstance.
Plagiarism
also
occurs
when
the
substance
or
argument
of
a
text
is
copied
even
with
some
verbal
alterations,
such
as
in
paraphrase
or
translation,
without
acknowledgement.
Plagiarism
includes
using
material
from
books
or
periodicals,
from
the
internet,
from
grind
tutors,
or
from
other
students,
without
full
acknowledgement
of
the
sources.
Copying
and
collusion
are
related
to
plagiarism.
Copying
occurs
when
a
student
copies
work
from
a
peer,
with
or
without
the
consent
of
the
original
author.
Collusion
is
when
students
collaborate
to
present
work
as
if
it
were
individual
and
original.
Both
copying
and
collusion
are
forms
of
plagiarism.
In
instances
where
two
or
more
purportedly
original
assignments
show
clearly
derivative
similarities
that
are
unacknowledged,
they
shall
both
or
all
be
treated
as
plagiarism
unless
the
contrary
can
be
demonstrated.
Plagiarism
in
any
form
of
assignment
contributing
to
marks
or
a
grade
for
a
course
is
a
serious
offence.
It
is
a
form
of
cheating
on
several
counts:
the
perpetrator
is
attempting
to
obtain
credit
for
work
not
done,
and
is
also
attempting
to
benefit
from
work
done
by
somebody
else.
Plagiarism
undercuts
the
whole
thrust
of
scholarly
enquiry
that
is
the
essence
of
education.
Plagiarism
will
be
severely
penalised
wherever
it
is
detected.
Students
submitting
assignments,
essays,
dissertations
or
any
form
of
work
for
assessment
may
be
required
to
sign
a
declaration
that
the
material
in
question
is
wholly
their
own
work
except
where
indicated
by
referencing
or
acknowledgement.
Students
are
reminded
that
any
student
submitting
written
work
for
continuous
assessment
can
be
asked
by
the
marker
or
the
department
to
take
a
supplementary
test.
43
2013/2014
This
may
take
the
form
of
an
oral
examination
on
the
assignment
in
question
and
related
issues,
or
the
writing
of
a
paper
in
controlled
conditions.
Students
should
provide
adequate
and
accurate
referencing
for
their
assignments.
Gordon
Harvey,
Writing
with
Sources:
A
Guide
for
Students,
(Hackett
Publishing
Company,
1998)
is
one
of
a
number
of
booklets
outlining
good
practice
in
reference
and
citation.
Disciplinary
Consequences
Plagiarism
is
a
form
of
academic
dishonesty
and
will
be
treated
with
the
utmost
seriousness
wherever
discovered.
Examiners,
tutors
and
markers
are
required
to
report
instances
of
suspected
plagiarism
to
the
relevant
Head
of
Department
concerned.
PLAGIARISM
Any
student
submitting
written
work
for
continuous
assessment
can
be
asked
by
the
marker
or
the
department
to
take
a
further
test.
This
may
take
the
form
of
an
oral
examination
on
the
assignment
in
question
and
related
issues,
or
the
writing
of
a
test
paper
in
controlled
conditions.
Requiring
a
student
to
take
such
a
test
does
not
necessarily
imply
that
plagiarism
is
suspected.
In
instances
where
an
element
forming
part
of
an
assignment
(from
a
phrase
or
sentence
up
to
a
paragraph
or
two)
is
found
to
be
plagiarised,
marks
will
be
deducted
for
that
assignment,
there
will
be
no
possibility
of
submitting
a
make-up
assignment,
and
previous
and
subsequent
work
submitted
in
connection
with
the
course
may
be
subject
to
particular
scrutiny.
While
the
amount
of
marks
deducted
will
be
proportionate
to
the
extent
of
the
plagiarised
material,
the
deduction
may
be
severe.
In
instances
where
a
significant
part
or
all
of
an
assignment
is
found
to
be
plagiarised,
zero
marks
may
be
awarded
for
that
assignment,
there
may
be
no
possibility
of
submitting
a
makeup
assignment,
and
previous
and
subsequent
work
submitted
in
connection
with
the
course
may
be
subject
to
particular
scrutiny.
In
serious
cases
the
plagiarism
will
be
reported
to
the
Supervisor
of
Examinations
and
the
Committee
of
Discipline.
Plagiarism
in
postgraduate
or
research
material
is
a
particularly
serious
offence.
Penalties
imposed
may
involve
suspension
or
expulsion
from
the
course
and
from
the
University,
in
addition
to
deduction
of
marks.
Early
offenders
may
be
required
to
attend
educative
classes.
44