Final Year Project Handbook - Computer Science - National ...

2012/2013
Final Year Project
Handbook
Department of Computer Science
National University of Ireland, Maynooth
Academic Year 2012/2013
1

2012/2013
Special Note on Plagiarism
Reference the university policy at
http://examinations.nuim.ie/documents/plagiarism.pdf
which is included as an appendix to the handbook
Presenting the work of others as your own is not acceptable.
A reader must be able to clearly distinguish between
your own work and the work of others.
If you use the work of others, either as a direct copy, or summarising or
using their ideas, you must (a) cite their work at every place where you
make use of it, and (b) include a full reference to their work
(see Appendix B for details).
All projects will be submitted to “Turnitin” to assist the Department
in ensuring that your work is original.
Offenders will be subject to disciplinary action.
2

2012/2013
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
3

2012/2013
APPENDIX L: FINAL YEAR PROJECT PROPOSAL TEMPLATE ............................................................................. 40
APPENDIX M: FINAL YEAR PROJECT MARKING FORM ................................................................................... 41
APPENDIX N:UNIVERSITY POLICY ON PLAGIARISM ....................................................................................... 43
4

2012/2013
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
5

2012/2013
• Final Report, Presentation, and Demonstration
The submission deadlines for this year are shown in Appendix A.
1.5 PROJECT TYPES
There are two types of Final Year Project: the Development Project and the Research Project.
1.5.1 DEVELOPMENT PROJECTS
The objective of this type of project is to develop a system that meets a set of user needs. This may take many
forms, for example: an application, a server, a program, a library, a collection of programs, an embedded
system, a hardware-­‐software system, plug-­‐ins, extensions, modifications to existing software etc.
The focus is on following sound software engineering principles, and evaluating your work thoroughly.
The main output is your report. This shows that the system you have developed is of suitable quality, and
solves the user needs.
You will do background research into both the technology and the marketplace. You will evaluate the success
of your system in terms of how well it meets the user’s needs. The system you develop is the principle output
of your project. You must test your software to make sure it works correctly, and then evaluate how well it
meets the user’s needs.
Development projects are based on the principles of quality software development, which can be summarized
as follows:
1. Understand what is needed
2. Design a solution
3. Design and implement a system to realize the solution
4. Verify that the implementation matches the design
5. Validate that the implementation correctly realizes your solution
6. Evaluate how well the solution solves the problem
You only have a limited amount of time available, so you may decide with your supervisor that you are going to
put equal emphasis on each of the software development steps, or just emphasise one (for example analysis or
testing) and put less emphasis on the others. Make sure your project report clearly identifies this decision.
1.5.2 RESEARCH PROJECTS
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.
6

2012/2013
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. THE IMPORTANCE OF FINAL YEAR PROJECTS
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
q
q
q
q
q
“The Essence of Computing Projects”, by C. W. Dawson, Prentice-­‐Hall, (latest edition)
“A Lightweight Software Development Process for Student Projects”, NUIM-­‐CS-­‐TR-­‐2005-­‐09
“Testing Guidelines for Student Projects “, NUIM-­‐CS-­‐TR-­‐2005-­‐05
“CS353 Guidelines for Condensed Software Development Documentation” Version 1.0.0, September
27th 2010
“Guidelines for Documents Produced by Students Projects in Software Engineering”, NUIM-­‐CS-­‐TR-­‐
2002-­‐05
“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
7

2012/2013
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. PLANNING YOUR PROJECT
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:
q
q
q
Single Honours 1 Science students should spend 240 hours (accounting for 25% of final year marks)
CSSE students should spend 240 hours (accounting for 25% of final year marks)
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.
8

2012/2013
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.
5 EXECUTING YOUR PROJECT
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 people’s 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 READING YOUR WAY INTO THE TOPIC
At the outset you need to learn as much as possible about the area in which you’ll be doing the project, as
quickly and efficiently as possible. Structure your research, and avoid “reading much but learning little”.
q
q
Collect any papers, articles, book chapters you can on the area and make a copy for your own personal
archive.
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 it’s 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
9

2012/2013
“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, it’s not efficient to give
each of them the same attention. But it’s 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
q
q
q
q
Shallow read everything and write a 5-­‐line summary of the article.
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.
Read all the labelled articles and write a 1-­‐page summary.
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.
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 (there’s 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 can’t express or speak about a given idea, then you haven’t truly understood it in
any useful way. This is so important, it’s 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 isn’t
as easy as it sounds. You might think that you should just ask your supervisor and he or she should tell you. It
doesn’t work like that. Quite often, a supervisor won’t 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. That’s what good computer science practitioners do: they help
people understand what they want and then they build it for them. Here’s how you do it.
1. Talk to your supervisor
10

2012/2013
2. Write down everything he or she says (by ‘write down’ I mean take notes of his or her words)
3. 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
what’s wanted should be teased out and agreed: what it does, what it doesn’t 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 doesn’t 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.
5.2.1 MODELLING YOUR PROBLEM
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

2012/2013
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. Don’t 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
Your implementation consists of writing the code and testing it.
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.
5.5.2 SOFTWARE TESTING
There are two aspects to software testing: verification and validation.
q
Verification ensures you have “built the system correctly”. That is, that the software correctly
implements your solution. For your project, you will normally carry this out at two different levels:
unit testing, and system testing.
12

2012/2013
q
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.
5.6.1 DEVELOPMENT PROJECTS
Finally, we ask: have I built the best system Again, the hallmark of good computer science: we seek to assess
the systems performance and compare it to that of other similar systems. Ideally, you should identify some
quantitative metric by which to compare the systems, since numbers are the best and perhaps the only way to
objectively describe performance -­‐ for example, the mean time between failures (MTBF). Quite often, we use
statistical measures as our comparative metric, e.g. the mean and standard deviation of some performance
measure when the system is subjected to a large variety of input parameters and conditions.
Evaluation is the act of measuring how well (using quantitative measures) your software system works. Note
that testing your software is different from running your software to get results. Testing your software makes
sure that it is doing what it is supposed to do. Validating your software makes sure that what it is supposed to
do actually solves the original problem. Evaluating your software explores how well your software operates.
Address these three issues separately.
You need to identify the different ‘metrics’ which you need to measure to evaluate your solution. Some of the
obvious ones, which you should normally include, are:
q
q
performance (throughput, latency, memory/disk usage, etc)
stability under load (also called stress testing)
5.6.2 RESEARCH PROJECTS
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

2012/2013
5.6.3 MAINTAINABILITY AND RE-­‐USE
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 it’s 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.
6 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, don’t 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 DOCUMENTING YOUR PROJECT
Your assessment is primarily based on the quality of the work you have done, as expressed through the report
you produce.
6.2 DOCUMENTING YOUR WORK
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

2012/2013
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.
6.5.1 CONTENT OF THE REPORT
Clearly, the content of the report is going to vary from project to project and it is difficult to make any strict
recommendations. However, we can make a few general observations about the content of your report. A
computer science project is an exercise in the well-­‐judged application of knowledge in the solution of some
problem. Your final year project provides you with an opportunity to demonstrate your ability to use your
judgement. This means that you must show your skill at: Assimilating, Synthesising, and Critically Appraising
all material relevant to the computer science project.
Your main opportunity to display your talents at assimilation and synthesis comes when you write the project
report. Needless to say, synthesis means that you must write the text yourself, expressing your understanding
of the material in your own words.
There is a strict page limit on your final year project, so you must determine the most significant information
that needs to be included in your project. You need an appropriate balance between the different facets of
your project to give your readers (and markers) a clear picture of what you have achieved and how you
achieved it.
Resist the temptation, no matter how strong, to copy sentences or paragraphs (or whole sections) from other
books or articles. Copying is not synthesis and it demonstrates neither your assimilation of material nor your
understanding of it. If you do come across a sentence or paragraph which is so good that is just has to be used,
then do so and include it as a direct quotation, providing a proper reference to the original source. Presenting
the work of others as your own work will not be tolerated. In particular, copying material from the web and
presenting it as your own work is expressly forbidden. Offenders will be penalised.
It is extremely important that you also appraise, or assess, your own work critically, i.e. with objectivity and
with a view to seeing how it could be improved. Such honest criticism does not mean you will receive fewer
marks; in fact, it is likely that you will receive more. Typically, you exercise your talents of critical appraisal at
the end of the report in a discussion chapter but you can also exercise it throughout the report wherever it
seems appropriate. Note that this exercise of critical appraisal is different from the testing processes of
verification, validation, and evaluation, which refer to the functionality of the system you have designed. The
critique you write applies less to the system and more to the overall objectives, methodologies, findings and
ultimate outcome of the project.
15

2012/2013
6.5.2 STRUCTURE OF THE REPORT
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 reader’s 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 couldn’t 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. It’s 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, it’s 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. That’s 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

2012/2013
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. ASSESSMENT OF YOUR PROJECT
Your project is assessed on the deliverables using the criteria shown below.
7.1 PROJECT DELIVERABLES
You will be marked on the following project deliverables:
1. Final Year Project Report
2. Attachments
2.1. Source code
2.2. Full details of any models developed
2.3. All project planning documents and records
2.4. Full details of your software testing (verification and validation), including test cases etc.
2.5. Full details of your experiments (metrics, experimental setup, experiments, data, results, analysis)
2.6. Copies of your presentations
3. Supporting Material
3.1. Executable files
3.2. Spreadsheets
3.3. Data files
3.4. Databases
3.5. etc.
4. Project Presentations (interim and final)
5. Project Demonstration
17

2012/2013
7.2 ASSESSMENT CRITERIA
Your project will be assessed on your demonstration of the following:
Category
Knowledge & Understanding
Nominal
Weighting
18%
Note
Analysis
18%
Application
18%
Must add to 90%
Synthesis
18%
Evaluation
18%
Presentations 10% 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

2012/2013
APPENDIX A: GENERAL PROJECT INFORMATION
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
October 1st, 2012
TBD
Monthly: Oct 19th, Nov 23rd, Dec 21st
March 22 nd 2013
April 2-­‐3, 2013
April 10th 2012
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%).
HOW TO SUBMIT YOUR REPORT
Completed final year project reports must be uploaded to Moodle (use module CS440 for all courses). You
must submit two files:
1. The Report, as a PDF file.
2. The Attachments and Supporting Material, including your source code, as a single ZIP file:
a. This file may only contain only two folders at the top level “\attachments“ and “\supporting”.
b. Every file in /attachments must be in PDF format, with no sub-­‐folders. The contents are as
described above for “Attachments”.
c. You may use sub-­‐folders in /supporting, and include any file type as required. You must
include a file README.TXT describing the folder contents in detail, how to run any binary
programs included, etc. Note that if you use non-­‐standard file types, or required special
software tools to use these files, they may not be assessed.
In addition, you must also submit your project log-­‐book to your supervisor.
FINAL YEAR PROJECT CO-­‐ORDINATOR
q
Prof. Ronan Reilly, Callan room 2.23
19

2012/2013
APPENDIX B: WHAT IS RESEARCH
The book “Practical Research: Planning and Design” by Paul Leedy lists eight characteristics of research:
1. Research originates with a question or a problem.
2. Research requires a clear articulation of a goal.
3. Research follows a specific plan of procedure.
4. Research usually divides the principal problem into more manageable sub-­‐problems.
5. Research is guided by the specific research problem, question, or hypothesis.
6. Research accepts certain critical assumptions. These assumptions are underlying theories or ideas
about how the world works.
7. Research requires the collection and interpretation of data in attempting to resolve the problem that
initiated the research.
8. Research is, by its nature, cyclical; that is, it requires multiple passes in order to find the best solution.
This should set the ‘context’ for your project. It should provide a summary of technical aspects of your project,
and also provide a review of relevant research in the area. Make good use of proper references to cite the
papers, books, and other material you have read. Your literature review should show that you understand the
area that your project work will be in, both from a technical viewpoint, and from a viewpoint of relevant
research in the area. If you undertake any theoretical developments as part of your research, these may derive
from your literature review or may originate from a distinct requirements elicitation process.
In Computer Science publications, a citation will normally take the form of a number in square brackets, such
as [1]. An alternative form is to use author’s name and a year in square brackets, such as [Brown 2010]. In your
references, you must have a list of these, and then the full details for each so that the reader can look it up –
you must include the publication title, author, year and publisher. Note that just a URL is not acceptable as the
only content.
Book: Author(s). Book title. Location: Publishing company, year, pp.
Example: W.K. Chen. Linear Networks and Systems. Belmont, CA: Wadsworth, 1993, pp. 123-­‐35.
Article in a Journal: Author(s). “Article title”. Journal title, vol., pp, date.
Example: G. Pevere. “Infrared Nation.” The International Journal of Infrared Design, vol. 33, pp. 56-­‐99, Jan.
1979.
Articles from Conference Proceedings (published): Author(s). “Article title.” Conference proceedings, year, pp.
Example: D.B. Payne and H.G. Gunhold. “Digital sundials and broadband technology,” in Proc. IOOC-­‐ECOC,
1986, pp. 557-­‐998.
Electronic Journal: Author. (year, month). “Article title.” Journal title. [Type of medium]. Vol. (issue), pages.
Available: site/path/file [date accessed].
Example: A. Paul. (1987, Oct.). “Electrical properties of flying machines.” Flying Machines. [On-­‐line]. 38(1), pp.
778-­‐998. Available: www.flyingmachjourn/properties/fly.edu [Dec. 1, 2003].
World Wide Web: Author(s)*. “Title.” Internet: complete URL, date updated* [date accessed].
Example: M. Duncan. “Engineering Concepts on Ice. Internet: www.iceengg.edu/staff.html, Oct. 25, 2000 [Nov.
29, 2003].
20

2012/2013
APPENDIX C: A VERY SHORT GUIDE TO GOOD WRITING†
q
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
haven’t written the sentence correctly. It’s a good idea to check all your sentences this way.
q
q
q
q
q
q
q
q
q
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. Don’t 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.
Don’t take short-­‐cuts. Explain what you mean. Don’t 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

2012/2013
APPENDIX D: GIVING PRESENTATIONS
You should have learned something about presentation skills during your time in the University.
Nonetheless, a few pointers may help you give a professional and impressive presentation.
q
q
q
q
q
q
q
q
q
q
q
Don’t 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 you’ve said. Of
course, you also have to maintain continuity and flow; otherwise people forget what you are
talking about. It’s 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 don’t shout).
Smile: enjoy giving your presentation.
Be confident: you’ve 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 don’t understand, say so and ask their help. Ask
them to explain, and ask nicely. If you still don’t understand, don’t bluff. Admit your ignorance
and suggest ways of how you will overcome that lack of knowledge.
Nobody knows everything; but that’s no excuse for not trying to know everything. A
knowledgeable person knows enough to do his job well, a wise person knows that he doesn’t
know everything, and an intelligent person knows how to find out what he doesn’t know. Be
knowledgeable, wise, and intelligent: be a computer scientist.
22

2012/2013
APPENDIX E: TYPICAL STRUCTURE OF A FINAL YEAR DEVELOPMENT PROJECT REPORT
Note: text in bold you may keep as headings. Text in italics is guidelines that you must replace.
Title Page
This page should be formatted as shown in APPENDIX: TITLE PAGE
Declaration
This page should be formatted as shown in APPENDIX: DECLARATION
Abstract
q
q
Use approximately 300 words to summarise the subject matter of the report, the problem being
solved, the motivation for solving it, the approach taken, your findings and conclusions.
Complete the abstract after you have completed the rest of the report. It normally takes several
revisions to achieve a good abstract.
Acknowledgements
q
You may acknowledge help from friends and colleagues, from your supervisor, staff, department and
university, and from your parents and family.
Table of Contents
q
List the Chapters and top-­‐level Sections, giving the page numbers. Generate this automatically, not by
hand.
Chapter 1 Introduction
Every chapter should start with an introductory paragraph to summarise the content. This tells the
reader both how this chapter follows on from previous chapters, and what to expect in the chapter. Do
not just repeat the table of contents for the chapter!
1.1 Goals
State what was to be achieved in the project
1.2 Motivation
Describe why the problem is worth solving
1.3 Method
Summarise how was the project was carried out
1.4 Overview
Give a brief summary of the technical area
1.5 Report Overview
Summarise what material you will cover and how is it arranged
Chapter 2 Background and Problem Statement
Introductory paragraph
2.1 Introduction
In your own words, provide a description of the problem domain
2.2 Literature Review
Present the ‘state-of-the-art’ of product/systems in this area. You should organise this in some
other way than by company or by date in order to show your understanding!
2.3 Problem Statement
Clearly state the problem that you are attempting to solve in your project
23

2012/2013
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

2012/2013
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

2012/2013
Identify any possible threats to the validity of your results, and discuss each.
Include detailed data and results in the Appendix.
Chapter 9 Discussion and Conclusion
References
Introductory paragraph
9.1 Solution Review
Discuss how well your solution solves the problem, based on your results from Chapter 8.
9.2 Project Review
Discuss how well you addressed the project, and what you might do differently if you were to
do it again. In particular, make sure to identify how you handled any problems that arose
during the project.
9.3 Key Skills
Identify key skills that you learnt during the project, and clearly describe how you applied
these, and how you might apply them differently if you were to do a similar project.
9.3 Future Work
Discuss any proposals for completion of the project, or for enhancements, or for re-design of
your solution or software.
9.4 Conclusion
Summarise the project and your solution in one or two paragraphs.
Include a list of references cited in the report here. Either use the [numbered] or [name’date] convention.
Appendices (in a ZIP file)
q Source Code (including all scripts, makefiles, XML, HTML, etc.)
q If possible, include a compiled executable with running instructions
q Reading reports
q Interim Progress Reports
q Project Plan Document
q User Requirement Document (Development Project) or Theoretical Development (Research Project)
q Product/System Design Document
q Software High-­‐Level Design
q Detailed Software Designs (for example, if using Java, include the Javadoc output files here)
q Software Test Documents (tests & test results)
q Software Evaluation Results
q Any additional outputs that you created during the project
This is an outline report structure. Many projects will vary from this. Consult with your project supervisor to
create the most appropriate structure for your report!
26

2012/2013
APPENDIX F: TYPICAL STRUCTURE OF A FINAL YEAR RESEARCH PROJECT REPORT
Note: text in bold you may keep as headings. Text in italics is guidelines that you must replace.
Title Page
This page should be formatted as shown in APPENDIX: TITLE PAGE
Declaration
This page should be formatted as shown in APPENDIX: DECLARATION
Abstract
q
q
Use approximately 300 words to summarise the subject matter of the report, the problem being
solved, the motivation for solving it, the approach taken, your findings and conclusions. Clearly identify
any original contributions your work has made to the field.
Complete the abstract after you have completed the rest of the report. It normally takes several
revisions to achieve a good abstract.
Acknowledgements
q
You may acknowledge help from friends and colleagues, from your supervisor, staff, department and
university, and from your parents and family.
Table of Contents
q
List the Chapters and top-­‐level Sections, giving the page numbers. Generate this automatically, not by
hand.
Chapter 1 Introduction
Every chapter should start with an introductory paragraph to summarise the content. This tells the
reader both how this chapter follows on from previous chapters, and what to expect in the chapter. Do
not just repeat the table of contents for the chapter!
1.1 Goals
State what was to be achieved in the project
1.2 Motivation
Describe why the problem is worth solving
1.3 Method
Summarise how was the project was carried out
1.4 Overview
Give a brief summary of the technical area
1.5 Report Overview
Summarise what material you will cover and how is it arranged
Chapter 2 Background and Problem Statement
Introductory paragraph
2.1 Introduction
In your own words, provide a description of the problem domain
2.2 Literature Review
Present the ‘state-of-the-art’ of research in this area. You should organise this in some other
way than by author or by date in order to show your understanding!
2.3 Problem Statement
27

2012/2013
Chapter 3 Project Management
Clearly state the problem that you are attempting to solve in your project
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

2012/2013
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

2012/2013
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.
Include detailed data and results in the Appendix.
Chapter 9 Discussion and Conclusion
References
Introductory paragraph
9.1 Solution Review
Discuss how well your solution solves the problem, based on your results from Chapter 8.
9.2 Project Review
Discuss how well you addressed the project, and what you might do differently if you were to
do it again. In particular, make sure to identify how you handled any problems that arose
during the project.
9.3 Key Skills
Identify key skills that you learnt during the project, and clearly describe how you applied
these, and how you might apply them differently if you were to do a similar project.
9.3 Future Work
Discuss any proposals for completion of the project, or for enhancements, or for re-design of
your solution or software.
9.4 Conclusion
Summarise the project and your solution in one or two paragraphs.
Include a list of references cited in the report here. Either use the [numbered] or [name’date] convention.
Appendices (in a ZIP file)
q Source Code (including all scripts, makefiles, XML, HTML, etc.)
q If possible, include a compiled executable with running instructions
q Reading reports
q Interim Progress Reports
q Project Plan Document
q User Requirement Document (Development Project) or Theoretical Development (Research Project)
q Product/System Design Document
q Software High-­‐Level Design
q Detailed Software Designs (for example, if using Java, include the Javadoc output files here)
q Software Test Documents (tests & test results)
q Software Evaluation Results
q Any additional outputs that you created during the project
This is an outline report structure. Many projects will vary from this. Consult with your project supervisor to
create the most appropriate structure for your report!
30

2012/2013
APPENDIX G: TITLE PAGE AND DECLARATION
Project Title
Optional Subtitle
Full Name
Final Year Project -­‐ 2012
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.
Supervisor: Dr. A.N. Other
31

2012/2013
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

2012/2013
APPENDIX H: PROJECT PLANNING
Projects are complex and require careful thought and analysis to identify manageable tasks. Each unit of work
in a project is called a task. A large task may be divided into sub-­‐tasks. If necessary, sub-­‐tasks may in turn be
broken into sub-­‐sub-­‐tasks.
G.1 TASKS
The following is a guide to identifying the tasks for a project plan
q
q
q
Identify and number all the major tasks, use the typical project major activities shown previously as a
starting point
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.
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 doesn’t
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 won’t be able to complete one task until you have completed another.
G.2 THE PROJECT PLAN
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 won’t do the planning for you, i.e. they can’t identify tasks, subtasks, effort, duration,
etc. That’s something you have to do yourself. You should be able to make a first attempt at this by the time
you’ve 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 don’t 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

2012/2013
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.
Figure 1: An Example of a GANTT Chart using Microsoft Project.
Task Table
Activities & Tasks
Start Date
Duration
[days]
Work
[days] End Date
1 PREPARATION Mon,30-Sep-02 64 45 days Mon,02-Dec-02
1.1 Initial reading Mon,30-Sep-02 19 15 days Fri,18-Oct-02
1.2 Review the literature Mon,21-Oct-02 12 10 days Fri,01-Nov-02
1.3 Exploratory programming Mon,04-Nov-02 19 15 days Fri,22-Nov-02
1.4 Prepare requirements specification Mon,25-Nov-02 5 5 days Fri,29-Nov-02
1.5 Update the project plan Mon,02-Dec-02 1 1 days Mon,02-Dec-02
2 DEVELOPMENT Tue,03-Dec-02 60 40 days Fri,31-Jan-03
2.1 Develop system design Tue,03-Dec-02 7 5 days Mon,09-Dec-02
2.2 Develop basic program Tue,10-Dec-02 7 5 days Mon,16-Dec-02
2.3 Add support for feature Tue,17-Dec-02 7 5 days Mon,23-Dec-02
2.4 Add support for feature Tue,24-Dec-02 7 5 days Mon,30-Dec-02
Christmas Break Tue,31-Dec-02 5 Fri,27-Dec-02
2.5 Extend feature Mon,30-Dec-02 5 5 days Fri,03-Jan-03
2.6 Add and Mon,06-Jan-03 12 10 days Fri,17-Jan-03
2.7 Enhance the GUI Mon,20-Jan-03 5 5 days Fri,24-Jan-03
2.8 Fix major faults Mon,27-Jan-03 5 5 days Fri,31-Jan-03
3 WRITEUP Mon,03-Feb-03 26 20 days Fri,28-Feb-03
3.1 Prepare project report Mon,03-Feb-03 24 18 days Wed,26-Feb-03
3.2 Prepare demonstration Thu,27-Feb-03 1 1 days Thu,27-Feb-03
3.3 Prepare presentation Fri,28-Feb-03 1 1 days Fri,28-Feb-03
Project Summary
Start Date
End Date
Duration
Workdays
Total Work Hours
Work/day
Mon,30-Sep-02
Fri,28-Feb-03
151 days
105 days
240 hours
2.3 hours
Work/week 11.4 hours
Figure 2: An Example of a Task Table
G.3 UPDATING THE PROJECT PLAN
34

2012/2013
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

2012/2013
APPENDIX I: DESIGN
I.1 PRODUCT 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 isn’t, then you must go back to requirements if necessary and revise
them and the specifications (with your supervisor’s 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.
I.2 SOFTWARE DESIGN
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
q
q
q
q
Identify several design options and compare them
Analyse your design to ensure it is technically feasible (i.e. validate its realizability). Remember, you
can’t always build everything you design, either for theoretical reasons (e.g. NP-­‐completeness) or for
pragmatic reasons (the required hardware is not installed).
Analyse your design to ensure it meets the specifications (i.e. verify that it does what is required)
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. It’s up to you to identify the test for optimality.
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.
I.2.1
HIGH-­‐LEVEL DESIGN
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

2012/2013
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

2012/2013
APPENDIX J: TESTING
J.1 UNIT 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 don’t
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.
J.2 SYSTEM TESTING
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 don’t 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 user’s
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

2012/2013
APPENDIX K: SOFTWARE ENGINEERING DOCUMENTS
You may document the results of your software engineering work in the following documents (see the CS353
Documentation Guidelines):
1. Project Plan
2. User Requirements Specification
3. Product Design Specification
4. Software Design Specification (High Level)
5. Software Design Specification (Low Level)
6. Software Testing Document
7. Software Product Validation Document
39

2012/2013
APPENDIX L: FINAL YEAR PROJECT PROPOSAL TEMPLATE
Note: this is provided for information only. Use the latest version of the template from the website.
NUIM Final Year Project
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
APPROACH
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.
You should describe your approach to your project including an overview of
major activities. You should include a provisional work schedule identifying
major interim deliverables (300 words maximum). You should include a Gantt
(or similar) Chart detailing a timetable of work, including contingency planning.
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

2012/2013
APPENDIX M: FINAL YEAR PROJECT MARKING FORM
Student Name:
Title of Project:
Supervisor:
1st Reader
2nd Reader:
Section
Category
Valid
Range
Given
Values
Marks
Awarded
Grade
Report,
Attachments 1 ,
Demonstration
90%
Knowledge and Understanding 10-25 18
Application 10-25 18
Analysis 10-25 18
Synthesis 10-25 18
Evaluation 10-25 18
Project
Presentation 10%
Interim Presentation 5 5
Final Presentation 5 5
TOTAL 100 0
Examiner’s Comments
See next page for marking guidelines.
(1) Attachments and Supporting Material as detailed in section 7.1 “Project Deliverables”
41

2012/2013
The project is assessed on the Report, Attachments, Presentation, Demonstration, and any
other supporting material, based on the following criteria.
• Learning Outcome: Knowledge & Understanding
o
o
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.
• Learning Outcome: Application
o 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
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.
• Learning Outcome: Synthesis
o 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.
42

2012/2013
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 person’s work as your own. It includes copying
without acknowledgement from a published source (print or electronic), or from
unpublished sources (e.g. another student’s 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

2012/2013
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