academic writing report

1. COMP 208
Academic Writing

2. Advise
• Writing a GOOD report takes time
• Remember that the readers do not have
the same background as the authors

3. Academic Writing
• Almost all projects involve the writing of a
report or dissertation which carries the
bulk of the marks.
• A max of 30% of the available COMP208
project mark is based on quality of the
team effort in the project Portfolio
– There is a chance the merit of a project will not be fully
recognised if such component is badly put together
– A good, balanced, written account can show a project to its best
advantage.

4. PLAN!!

5. Before Writing
• Consider what is required
– Typically there will be clues as to what should be in
the document in the instructions or guidelines
• Consider your audience
– They can be assumed to know some things
– This will help determine the balance and what
requires detail
• Be aware of the target length
– This determines the amount of detail
– Every story can be told in 1 page or in a hundred
pages.

6. Before Writing
• Consider what is required
– Typically there will be clues as to what should be in
the document in the instructions or guidelines
• Consider your audience
– They can be assumed to know some things
– This will help determine the balance and what
requires detail
• Be aware of the target length
– This determines the amount of detail
– Every story can be told in 1 page or in a hundred
pages.
Discuss in a Team
Meeting!

7. Structuring
• Top down approach. Decide:
– Chapter Headings
– Section Headings
– Sub-section headings
– Paragraphs within sub-sections
• Write the paragraphs
Of course you may change the structure as you write.
A structure permits work allocation between people,
and allows flexibility in the order of writing.

8. Structuring Checks
• After first draft examine the structure
– Coverage: check that everything is there
– Detail: check that things are mentioned with the right level of
detail
– Balance: all chapters should have approximately the same
length.
EXAMPLE 1 (GOOD?): chapter 1 (10 pages); chapter 2 (30
pages); chapter 3 (38 pages); chapter 4 (21 pages); appendix (40
pages)
EXAMPLE 2 (BAD?): chapter 1 (10 pages); chapter 2 (24 pages);
chapter 3 (78 pages); chapter 4 (6 pages); appendix (3 pages)

9. Generic Structure
• Title Page: title, author, date, course
• Abstract: a one page summary
• Acknowledgements: people to thank
• Contents: to sub-section level
• List of figures and tables: optional
• Chapters: introduction (should set the scene, provide the
appropriate context), main body (may be more than one chapter),
conclusion
• References: in proper format
• Appendices: labelled A, B, etc, to give details that are disruptive in
the main text, but could be useful to get the full picture.

10. Group Project Report Guidelines
 Your report should be no more than 10 pages.
 It should contain:
 Details of the team members and a summary of their roles on the
project
 An overview of the application: what it does, who is intended to
use it; why they might want to use it
 A description of what was achieved on the project
 An evaluation of the strengths and weaknesses of the project
 Suggestions for future developments
 A one-page discussion of how your project related to the codes of
practice and conduct issued by the British Computer Society
 A bibliography of materials used on the project.
• Only a single “Chapter” - so straight to sections.

11. Sections
1. Members and Roles
2. Application Description
3. What was Produced
4. Evaluation
5. Extensions
6. Professional Issues
7. Bibliography.

12. Sections
1. Members and Roles
2. Application Description
3. What was Produced
4. Evaluation
5. Extensions
6. Professional Issues
7. Bibliography.
For each section, decide
what you want to say, and
the order in which you
want to say it.

13. Sub Sections
In general sections might be further split
into subsections.
Example:
2. Application Description
2.1 Application Domain
2.2 Types of User
2.3 Typical Queries
2.4 Typical System Output

14. Sub Sections
In general sections might be further split
into subsections.
Example:
2. Application Description
2.1 Application Domain
2.2 Types of User
2.3 Typical Queries
2.4 Typical System Output
But excessive sectioning eats up space.
The most important decision is about what to say
and how. Space constraints should guide you in
relation to additional sectioning.
Evaluation of the strengths and weaknesses of the project:
The project’s main aim to provide people an engine to search roommates and have
events was successfully achieved. Although the project has some shortcomings, we
have a functioning application that allows students to find their perfect match to share
an accommodation with.
Project Strengths
Based on the initial mission objectives we have successfully implemented:
• We have a system where the student can create an account, edit their profiles and log
in;
• Accounts that are protected with a password;
• Students have a search engine where they can find students with similar interests and
lifestyles;
• Student can find information about others to contact them externally;
• Students can create groups and add people as well as leave a group if they would wish
to do so.
Additionally:
• We have a tag system where the students can add some extra information that is not in
their bio
making it easier to search for others;
• We have admin pages where administrative information and actions are shown for
safety and control over the system.
• You can access a list of events and sign up to them (as well as not deciding to attend
anymore)
Project Weaknesses
However there are some weaknesses present in our project which include:
• You can only get a reset password link if you’re using a google email account (gmail);
• The project doesn’t have a profile picture system implemented;
Evaluation of the strengths and weaknesses of the project
The project aims to provide people with an engine to search possible roommates and
events. Based on the initial mission objectives we have successfully implemented:
• a system where the student can create an account, edit their profiles and log in;
• password protected accounts;
• a search engine through which students can find students with similar interests and
lifestyles;
• the possibility to create and manage groups of people
Additionally we have
• A tag system allowing students to add some extra information that is not in their bio
• Admin pages allowing extra ontrol over the system.
• the possibility to access event lists
However there are some weaknesses present in our project which include restrictions on
the password reset features and the lack of a profile picture.
WASTEFUL
BETTER

15. Evaluation is Important
• Give a balanced, critical appraisal
• Talk about weaknesses as well as
strengths
– Better to show you recognise things that
could have been better than to pretend
everything is wonderful when it is not
• Discuss things that you would do
differently with hindsight.

16. Format of a Written Report
• Deciding on the format at the outset makes life easier when
you bring the report together
• If there are guidelines, follow them. Otherwise you need to
decide on
– Fonts: Times Roman is recommended for text;
constant width (e.g. courier) for code
– Font size: 12 recommended, no less than 10. Headings
proportionally bigger
– Use single column, justified, with reasonable margins,
with page numbers, monochrome
– Line spacing: One and half is best: single is ok; double
too much.

17. Style
• The style should be clear, but formal
– Avoid “I” as much as possible
– Keep sentences as short as possible
– Avoid abbreviations and slang
– Use simple words
• do not utilise esoteric or arcane terminology
– Do not use contractions (don’t, it’s, isn’t)
– Do use the past tense
– You are writing a report, not a narrative story.

18. Do not write stuff like
After I’d written the program I compiled it, but all I got was alot
of errors. I tried putting everything on different lines, but it still
wouldn’t compile, so I separated out the declarations. Still no
luck. So I went to see Dave Shield and he told me that I was
running C code through a JAVA compiler, and when I used the C
compiler it did sort of compile, and after a bit I got it to run fine.
But now I found that it was giving the wrong answer so I went
to the pub. The next day I realised I’d used + when I meant * in
the relevant line and then it worked ok.
Write instead:
“The program was successfully written, compiled and debugged.

19. Spelling
• Always use a spell checker – but remember
that you may be using correct words in
incorrect places:
– there is no apostrophe in its. “It’s” is a
contraction of “it is”. “Belonging to it” is its
– They left their books over there
– “Alot” is not a word. “A lot” or “allot”
– separate is correct. seperate is not.
– Relevant is correct. Relevent is not.
Belonging to them
A place
much give out

20. Grammar
• Try to use correct grammar
– Do not run sentences together:
• Not “the program was a success, it did everything the
user wanted. Use a semi-colon, or start a new sentence
– Sentences have verbs in them:
• Not “There are two kinds of input device. Keyboard and
mouse.” Either one sentence:
• “There are two kinds of input device, namely keyboard
and mouse”, or put a verb in the second sentence
• “There are two kinds of input device. These are
keyboard and mouse.”
Wrong use of comma:
either semi colon or
full stop
No verb in
this “sentence”
If in doubt use short sentences (with verbs)

21. Abstracts
• A short summary of the report or
dissertation.
• Summarise the background, approach
and results
• Not just a contents listing
• Do not use references in the abstract
• Do not use acronyms in the abstract.

22. Figures and Tables
• Diagrams and Tables are very useful to help explaining
some things and to present results
• All figures and tables should
– Have a number (chapter.figure). Figure 3.4 is the
fourth figure of chapter three
– Have a caption eg,
• Figure 3.4: Architecture of the system.

23. Figures and Tables
1. explain them!
2. do not use a figure or table
instead of a textual
description.

24. References and Use of
Sources
• In the text refer to sources by name and date
– one author: Houndscrounger (1997)
– two authors: Mills and Boone (1967)
– three or more authors: White et al. (1994)
• Make sure you refer to your sources in the text
wherever it is appropriate to do so.
• Attributed quotation shows you know the
literature: Unattributed quotation or paraphrase
is Plagiarism.

25. Use Sources To:
• Give the source of any quotations, diagrams etc that you
use.
– Never use someone else’s words without citation
• To identify context
– “Many planning systems exist (e.g. Tate (1967), Lyle (1985),
Sugar and Venables (1994)).”
• To justify your claims:
– “Z-Sat is provably NP-complete (Jobsworth (1943)).”
– “It has often been said that user interfaces should be user
friendly (e.g. Diaper (1981)).”
• To provide background
– “For a fuller description of the notation, see Marley and Scrooge
(1967)).”

26. Bibliography
• You must also give full details of every
work cited and used in the project.
• Details comprise:
– All authors and initials
– Date of publication
– Journal/Collection (for papers)
– Publisher and Place of Publication (for books)
– Page numbers (for papers).

27. Bibliography - Examples
• Book:
– Thom, A.W., Dick, J., and Harris, K.P., (1957). Principles and
Practice, Clarendon Press: Oxford.
• Journal:
– Lenin, V.I., (1917). Reason and Revolt, International Journal of
Computer Science, Vol. 3, No. 4. pp. 54-67.
• Collection:
– Hill, C., and Dale, W., (1998). Using Colour Effectively. In Fell,
D.R., (ed), Interface Design, Blackwell, Oxford. pp. 234-287.
• Web Site
– Castro, F. (1965). Database Design. Available from
htpp://www.fidel.cu/dbdes (25 January 2000).
– For web-sites, you should give the URL and the date you last
accessed it.

28. Summary
• Think about the structure
• Use a consistent, appropriate layout
• Write clearly, in a formal style, using
correct grammar and spelling
• Cite all your sources
• Give full details of the sources in the
bibliography
• Make sensible use of appendices.

29. PLAN