It is a self evident truth
That a report
- is handed in as one volume,
- including appendices,
- continuously paginated,
- bound or stapled, and
- spell checked and proof read
electronic hand in.
A report is one (1) pdf document.
Appendices are NOT handed in separately, unless
specifically required in the project description.
Cdroms or specifically requested attachments must
be marked as specified below.
Appendices/attachments are references and not
evaluated for grading.
Table of Content, suggested
- Front Page/Title Page
- Table of Content
- Problem Statement
- [Resume of Literature]
- Evaluation of Method
- Evaluation of Result
- [Future Spin Offs]
- Front Page/Title Page
- Title of report
- Author's name
- Institution (IBA)
- Instructions etc.
- URI of product
- Maximally one half to three quarters of a page.
- Typography clearly different from rest of report.
Table of Content
- Use standard typography template.
- Automatically generated.
- Update frequently.
- Problem background. Description of domain.
- Problem statement.
[Resume of Literature]
Applicable only if project starts with extensive
- Not common, therefore mostly optional.
- What are the relevant possibilities?
- What is the choice?
- Practice, the functional specs.
- Do not forget the arguments.
- Theory, discuss relevant theory.
- Argue it's relevanse.
- Analysis of data from research.
- This chapter is often joined with Research
into one chapter.
- Generation of application/product.
- Arguments based on Research/Analysis.
- Illustrate with code examples of special
- Discuss your choices.
Evaluation of Methodology
- Evaluation of methodology.
- Discuss applicability.
- Would you do it the same way again?
- Why/Why not?
Evaluation of Result
- Evaluation of result.
- Discussion of result vis a vis expectations.
- Is it completed?
Future Spin Offs
- New Developments in the process
- Possible future projects based on this.
- MUST relate to problem statement only.
- Have the questions been answered?
- No news here!
- Mark as appendicex next to page number.
- Pagination continues from the corpus of the
- No creativity here.
- Use recognised template/method
- Rare in project reports.
Referencing, Harvard Style. Reference List
- General format
Last name, First Initial. (Year published).
Title. City: Publisher, Page(s).
- Alphabetical order by first author's last name
- More refs to same author ordered by publication year
- If in doubt, lookup
Anglia Ruskin University's Guide
Referencing, Harvard Style, Examples
- In-text citation: Direct quotes, or paraphrases, such as
"I will use a simple pseudo-language to demonstrate how
semaphores work" (Downey, 2016).
The reference list at the end of the work:
Downey, A. (2016) Little Book of Semaphores.
Needham, MA: Green Tea Press, p8
Fowler, M. and Sadalage, P. (2013) NoSQL. A Brief
Guide to the Emerging World of Polyglot Persistence.
Boston, MA: Addison Wesley
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(1994) Design Patterns: Elements of
Reusable Object-Oriented Software. Boston, MA:
Metcalfe, R. and Boggs, D. (1976), Ethernet:
Distributed Packet Switching for Local Computer
Networks. Communications of the ACM, 19(5)
Chittenden, M., Rogers, L. and Smith, D., 2003. Focus:
'Targetitis ails NHS. Times Online, [online] 1 June.
Available at: <http://www.timesonline.co.uk/tol/news/uk/scotland/article1138006.ece>
[Accessed 17 March 2005].
Useful References for You
Fibiger, J. and Søgaard, S. (2009) genvejstaster -
til opgaveskrivning og faglig formidling på
Aarhus, Denmark: Academica. Kapitel 9
Eco U. (1977) Come si fa un tesi di laurea.
Milano: Gruppo Editoriale Fabbri, Bompiani, Sonzogna, Etas S.p.A.
Eco U. (1997) Kunsten at Skrive Speciale - hvordan
man udarbejder skriftlige opgaver.
København, Denmark: Akademisk Forlag. Del V Skriveprocessen
Zobel J. (2004) Writing for Computer Science.
London, UK: Springer Verlag. Chapter 2 Good Style, and 3.