How to write up a project

Dr Jim Briggs

This document is updated from time to time. The most recent version can be found on the WWW at URL http://www.dis.port.ac.uk/disdis/projects/docs/projrpt.htm

This version dated 3 February 2008.

Contents

Introduction................................................................................................................................. 3

Assessment of a project............................................................................................................... 3

The marking process................................................................................................................ 3

Marking criteria........................................................................................................................ 4

Preparing to write your report....................................................................................................... 5

Planning your report..................................................................................................................... 6

Report outline.......................................................................................................................... 6

Benefits of a project report plan................................................................................................ 6

Basic structure of a typical project report.................................................................................. 7

Non-typical projects.............................................................................................................. 12

Abstracts, references and appendices......................................................................................... 13

Abstracts............................................................................................................................... 13

References............................................................................................................................. 13

Appendices............................................................................................................................ 14

Choosing a title for your report................................................................................................... 14

You've got to have style............................................................................................................. 15

Practical issues........................................................................................................................... 16

Preparation and printing.......................................................................................................... 16

Binding and submission........................................................................................................... 17

Summary................................................................................................................................... 18

Bibliography............................................................................................................................... 18

Appendix - Departmental project regulations.............................................................................. 19

Length................................................................................................................................... 19

Presentation........................................................................................................................... 19

Title page............................................................................................................................... 20

Other content......................................................................................................................... 21

Binding.................................................................................................................................. 21

Submission............................................................................................................................. 21


Introduction

This document is designed to give students advice and guidance on how to write up the most important component of your course - the project.

Assessment of a project

The marking process

BSc: Your project will be assessed solely on the contents of your final report. If you are doing a development project, you can develop the best piece of software in the world, but if you don't write up how you did it then you won't be given any credit for it. Conversely if the artefact you build turns out to be a dud but you can reflect in your report on why that happened and what you would do to prevent it if you did it again, then you could still get a first-class mark. Your report will be assessed in the following categories:

Aims and objectives

Literature review

Requirements and specification *

Analysis and design *

Implementation and testing *

Evaluation

Project plan & management

Conclusions

Other supervisor-determined categories

Quality, reliability, timeliness and maintainability of the artefact *

Categories marked with an asterisk would not necessarily be found in non-computing projects.

The markers will determine the weight given to each category.

MSc: In addition to the above categories, there is a mandatory category for your project specification.

WI: See How to do an IBM project for details.

All: Your report will normally be read by two people - your supervisor and a moderator. They will agree a mark between them. If they cannot agree, a third marker will be appointed to arbitrate - in these cases usually the third marker's mark prevails.

One or more of the external examiners may also read your report. This may be because it is exceptionally good, exceptionally bad, or exceptionally difficult for the internal markers to agree a mark on.

If your report is exceptionally good, it may also be read by other members of staff appointed to the task of determining the award of project prizes.

Marking criteria

The more of the following your report has, the higher the mark it will attract:

·        work of publishable standard;

·        clearly defined aims and objectives;

·        clear statements of the requirements of any artefact you built;

·        well-reasoned explanations for design decisions made;

·        perceptive analysis of the problem and its possible solutions;

·        interesting conclusions;

·        development of high quality artefacts;

·        work that was challenging;

·        good quality presentation.

The more of the following your report has, the lower the mark it will attract:

·        errors of fact;

·        vague aims and objectives;

·        vague requirements for artefacts;

·        unexplained or ill-judged design decisions;

·        little or no analysis, solely descriptive;

·        trite conclusions;

·        misinterpretations of literature;

·        development of poor quality artefacts;

·        work that was facile;

·        little evidence of work done by the student;

·        spelling mistakes, poor grammar, lousy structure, crazy layout.

More information on the marking process and criteria can be found in the document How to mark a project.

Preparing to write your report

Hopefully as you have carried out the project, you have kept notes of what you have read and what you have done. If you haven't you will need to reconstruct these from memory (or redo the reading) to make up for it. To remind you of what was recommended in How to do a project here is a list of things to keep a note of as you go along:

·        things you have read;

·        things you have been told;

·        advice from your supervisor;

·        decisions you took along the way;

·        problems you encountered and how you solved them;

·        test case and evaluation results;

·        ideas for developing the work (either in your project or in a future project);

·        anything else that is interesting.

You can't write your report as you go along but you can write down the raw materials that you will need when you come to write it later.

Planning your report

At about the mid-point of your project (BSc: say January but you could actually do it either during the Christmas vacation or leave it slightly later until the inter-semester gap; MSc: around June) you should start planning your project report.

There are lessons to be learned in computer programming that can be applied to report writing. When writing a program you don't simply start with the first line of code and keep writing until you reach the last one, instead you design the program as a set of semi-independent modules or procedures, and tackle each one at a time. With a report you do similarly - you should first of all design an outline for the report, then fill in the words later.

Report outline

A report outline consists of chapter and section headings. These should be detailed enough to give a fair indication of what each section is actually going to be about. You can construct a report outline to any level of detail but for this sort of document a division of the report into chapters, then each chapter into sections and each section into sub-sections, should be sufficient. You can if you want be more detailed and decide what each paragraph is going to be about, but the important thing at the outline stage is to show the overall structure of the report and what is going to go where rather than worrying about the content.

Many word processing tools provide support for outlining. For example in Microsoft Word you can choose to view a document in outline mode, and within that to limit what is displayed on the screen just to headings.

Benefits of a project report plan

There are two main benefits of having a project report plan:

1.      It allows you write your report one section at a time, with (if you've done the outline properly) the reasonable certainty that you will not duplicate any material or leave anything important out.

2.      It allows you to judge what work you still need to do. If you have a section entitled "Testing the software" and you haven't yet tested your software then the presence of this will remind you to do so.

Basic structure of a typical project report

Most reports describing a problem-solving exercise have the same basic structure and consist of about six chapters. The titles given here for the chapters are meant to be indicative rather than prescriptive - use common sense to decide what is best to permit your readers to find their way around your report.

This section presumes that you are doing a typical "build an artefact to solve a problem" project, but the principles embodied in it apply to all types of project, including business and social science ones. The next section discusses alternative structures for your report if that is not the case.

1. Introduction

This chapter is essential. It should start off by setting the context for the work. For example:

·        Where did the project suggestion come from?

·        Why is it an interesting problem?

·        Why hasn't it already been solved?

Usually you start with a very broad statement of the problem and refine that down to more specifics. The introduction to my PhD thesis started off talking about programming languages in general before moving on to compilers, then to separate compilation in general and then to separate compilation in Ada (which was what I investigated). Unless yours is a problem area with which all readers of your report will be familiar (very unlikely), you will want to describe the problem in some detail and give sufficient background information for everyone to understand it.

The introduction should then describe the objectives, aims or goals of your particular piece of work. Your overall aim was presumably to solve a particular problem or to answer a particular question. This could be broken down into a number of specific objectives that together work towards achieving the aim. Few projects set out to solve a problem completely, so what particular parts did you choose to tackle? These can be identified as some of your objectives. No project is without constraints, in time, money, equipment, etc. These inevitably affected your objectives. Say how.

The introduction should end with a section that leads the reader in to the rest of the report. You often see things along the lines of "In chapter 2 we will describe X and then in chapter 3 show how it can be used to solve the problem described in chapter 1". Look at some previous reports (or academic papers) that have this sort of structure to see examples of what can be written here. The important thing is to give your reader a clear picture of what your report is setting out to tell them and where they will find particular parts of your case.

2. Review

All projects include some element of review. Your work is done in the context of an academic discipline, computer science (or business or social science). Show how it fits into the framework of that discipline. You've read books and papers describing the problem you are trying to solve. You've read books and papers describing potential solutions to the problem. Review them.

What do we mean by review? There are two main purposes in conducting a review.

Firstly, in tackling your project, you decided to take some particular approach. You need to give your reader sufficient background knowledge for them to be able to appreciate why the approach you took was valid or best. Since they may not be familiar with either the problem or the possible solutions or both, you need to provide them with a basic grounding in the important and relevant material.

This does not however mean that you should include a detailed tutorial. You can for instance refer them to a book that gives a full explanation and confine your description to just the rudiments. Examples to illustrate points are useful.

Secondly, you need to demonstrate that you considered all the possible solutions to the problem and that you took all available material into account. This part of the review usually summarises quite succinctly approaches that have been taken by other people in similar situations. Some will have been successful and some not, and this should be indicated. It is perfectly all right to express justified disagreement with something you've read - "criticism" (in the positive sense of the word) is often an excellent feature of a review.

The most important attribute that your review should possess is relevance. Don't include things that you've read that contributed nothing to your project. Where you do include something, don't just be descriptive - explain how and why it is relevant to the rest of your report.

3. Design

If you've built something (hardware or software) to solve a problem, you had to make some design decisions along the way. (If you didn't your project must have been very mundane and probably very boring!) Why did you choose to do something one way rather than another? Why did choose to include one thing but leave out something else? Which factors did you think were most important and which did you choose to ignore?

Don't just list your decisions; place them in a context. It should be possible for the reader to understand how your design decisions contributed to meeting your objectives. Also important is that you show the method by which you accomplished your design - "process" is as important as "product" to an engineer. What processes did you use? How did they contribute to ensuring that what you did was complete/consistent/correct? Don't just write about what you did, nor how you did it. Why you did it is most important.

The starting point for your design is of course your requirements - what the customer wants the artefact to do. In some projects the requirements are specified in advance. The customer provides document that (in more or less detail) specifies the behaviour of the item to be constructed. More commonly, the customer has a more vague "need" for something, and it is part of the project itself to refine that into a more detailed set of requirements. A project that doesn't have a written set of requirements is not a very good one, though it would not be normal to describe the requirements in much detail in the body of the report. Better is to include the requirements specification document as an appendix to your report (see later about appendices) and only in this chapter highlight the points relevant to your design. If a detailed discussion of how you elicited, analysed and specified the requirements is necessary (for "necessary" read interesting and relevant), it could be a separate chapter before this one.

If you followed some particular design methodology then you almost certainly produced a design document of some description. Again, the full version would probably appear as an appendix to your report, with only the interesting bits discussed here. In particular you would expect to say why certain things appear in the design in preference to others. You would also give examples of things you rejected (with reasons), which probably don't appear in the design document and therefore would not appear anywhere if you didn't mention them here.

The "design" stage is often held to be the key stage of your project. It is certainly the part of project reports that is most closely looked at by external examiners! It is the one where you can show off your ability to apply your engineering and commercial knowledge and skills to best advantage. This is precisely what you will be doing in your working life if your chosen career is in any way related to your degree.

4. Implementation

After you designed your solution to your problem, you implemented it. This section normally describes how you did that. What tools and techniques did you use? What difficulties did you encounter and how did you overcome them?

Some students believe that this section is equivalent to writing the internal documentation of a program. It isn't. When you are documenting a program, you want to include a lot of detail so that when someone else comes along to maintain the program they can understand how and why you did everything. The essential attribute of documentation is completeness - nothing left out. In contrast, this chapter of your report should only address issues that are interesting. Mundane details about how the program is structured should be left out. On the other hand if you developed a new algorithm (however short) or applied an old technique in a new way then that is of interest and should be included.

There are many possible ways of structuring this chapter and which of them is most appropriate will vary significantly based on what you have done and the way you went about doing it. Certainly, the structure should reflect major stages in your artefact development process or major components of it (or both). Some of the sections might be short (e.g. because they way you did something was "routine") while some of them may deserve more attention because of the extent to which they are "interesting".

If in your project you designed something but did not build it, there may still be scope for an equivalent to this chapter. In that you could discuss issues that would probably arise during future implementation and provide advice on how potential problems could best be prevented or solved.

5. Evaluation

Once you designed and built something, you probably evaluated it in some way. At the very least, you tested what you built to see whether it did what your customer wanted it to do. Evaluation usually comes in one of two forms: either you compare what you did with your objectives, or you compare what you did with what someone else did.

Involving the customer, or potential users of the system, in the evaluation is always a good idea. The ideal would be to install your artefact in the environment in which it was designed to operate, and gain user feedback on how well it does its job or compares to existing systems. Second best is to demonstrate the artefact to likely users and get their opinions. If this can be done in a simulation of the real environment, then so much the better. Feedback from users or customers which is structured (e.g. the results of objective tests or the responses to a questionnaire or survey) is more useful than their verbal comments.

Like in the implementation chapter, you do not want to give lots of boring, mundane detail here. So for example, you would not normally describe in excruciating detail exactly what tests you conducted and their results, but you would describe in general terms what you did (your strategy) and what results you obtained.

Again, like in the design chapter, if you have either followed a standard method for evaluation or made one up yourself, you should describe it. Of course, your own method would take more description than a reference to a well-known method.

6. Conclusions

The conclusions chapter is where you tie up all the loose ends in the previous chapters. It is most important that it relates to what you have described previously, and that it does so in a relevant and concise fashion.

Years of watching TV series like "LA Law" and "Rumpole of the Bailey" have taught me the rudiments of legal procedures. At the start of a trial, each side makes a statement about what they are going to show during the course of the trial. (For example, the prosecution says it is going to show that the defendant was at the scene of the murder, had fingerprints on the murder weapon and had a motive for killing the victim, so therefore must be guilty). This is like the introduction to your report. Then each side presents its evidence. This is like the body of your report. At the end of the trial each side has a chance to "sum up", to summarise how each piece of evidence contributes towards proving whatever it is they are trying to prove. The conclusion of your report is like that. (Extending the analogy, the role of the jury is taken by the examiners of your report who judge whether you have or have not done what you said you were going to do.)

In your summing up, you need to show how what you did contributed to meeting the objectives you set in the introduction. In doing so, it is appropriate to repeat (in summary form) key points from your review, design, implementation and evaluation as necessary. You need to make a convincing case because if you don't, what you describe will not "hang together" - each stage of your project will seem like it is disconnected from the others.

Unlike a legal case, it is perfectly OK to have some loose ends left at the end of a project. Sometimes there will be aspects that you simply did not have time to address. Other times there will be things that you were unable to do because of force of circumstances. Above all there will have been points raised during the course of the project that you did not anticipate and were not within your scope to tackle. All these things can be discussed in this chapter and, where further work can be identified, a distinct sub-section "Suggestions for further work" should be included. Supervisors love that section because it often provides a fertile source of ideas for next year's project students!

You probably also want to reflect upon the work that you've done. Could you have done it better and, if so, how?

The final part of your conclusions should be a mirror image of the first part of your introduction. Whereas in the introduction you started off broadly in setting the context for your project and then got more specific, in the conclusions you should show how your specific conclusions fit into the broader context. You do not have to advance the boundaries of mankind's knowledge very far but at least you should be able to say which boundary it is!

Non-typical projects

It is not our intention to tell you that the above is the only (or best) way of structuring a project report. Indeed of the chapters described above probably only the introduction and the conclusions are essential, though a review chapter (or two) will probably be found in 99% of project reports, and some element of design in all BCS-accreditable ones. Rather we are trying to indicate the major areas you will want to write about, with the ordering of them arranged according to the purpose of the report.

If you decide that you need to have all the above sections, there are other ways of arranging them. For example if your project consisted of four quite distinct activities then you might choose to have the body of your report consist of four chapters, one on each activity, with each chapter perhaps having sections addressing design, implementation and evaluation. Alternatively, it may be best to consider the design of each separately, but to consider the implementation and evaluation of them together. Whatever way you choose, you should do so to facilitate the reader's understanding of the points you are trying to make.

Abstracts, references and appendices

The three sections of a project report that seem to cause most confusion for students are the abstract, the list of references and the appendices. Here we will address them in turn.

Abstracts

The abstract traditionally is the first thing in a report, even before the list of contents in most cases. The abstract is intended to stand alone and under certain circumstances (e.g. in a database of projects) it might be copied and kept separately from the report itself. The idea is that someone could read the abstract and from it decide whether it would be worth their while to read the whole report. Although it's the first thing that appears in the report, it is probably the last to be written.

The abstract is a précis, a summary, a synopsis of the entire report. As such, it should summarise the important points from the objectives, the review, the design, the implementation, the evaluation, the conclusions and anything else that is in the main part of the report (though not necessarily everything - if one chapter described material that was incidental to the main conclusions of the report you might leave mention of it out of the abstract). Some people mistakenly summarise only the introduction, some only the conclusions, but to do its job properly the abstract should contain the main points of all sections of the report.

References

All project reports should contain a list of references. The only exception would be if you didn't refer to any other work in your report, in which case you have not written a very good report, nor probably done a very good project! The list of references should come at the end, after the conclusions but before any appendices (see below).

A list of references is just what it says it is. It is a list of all the books, papers, computer programs, web pages, etc. that you have referred to in your report. The list of references must contain full bibliographic data sufficient to enable a reader to find the work in a library or similar. A system for citing and listing references (as well as some advice on when to use a citation and when not) can be found in the document How to cite references.

What is the difference between a list of references and a bibliography? Some people use the terms interchangeably but I prefer to reserve the word "bibliography" for a general list of books that people might be interested in or choose to read, and I use "references" specifically when talking about books, etc. that are explicitly referred to.

What if your report has no references? It will fail!

Appendices

Like the anatomical organ of the same name, you can live without an appendix. Appendices to a report contain information that, while not important or interesting enough to be included in the body of the report, is nevertheless relevant. Common examples include program source code, program documentation, intermediate documents (e.g. a requirements or design document). Your report stands alone without these, but the reader may occasionally wish to refer to them.

The key word here is "occasionally". If it is crucial to read something in order to understand some point being made in the report, then that "something" should be replicated in the body of the report. For example, if you are discussing an interesting piece of program code you would not want the reader to have to find it in amongst hundreds of other lines of code (even with the help of page and line number references). Much better is to copy and paste the relevant lines of code into the relevant chapter as a figure.

Choosing a title for your report

This isn't as easy as it may appear. You only have a limited number of words in which to convey to the reader what your report is all about. (There is no fixed limit but you need to get it on at most two lines in a large font on your front cover.)

Avoid noise phrases. Titling your report "A report into..." is redundant: of course it is a report! Words like "study", "investigation", "enquiry" and "development" are often similarly just noise.

Ultimately, your title needs to be different from the title of a report on a different project, so think about what the distinguishing features of your project were. "Constructing a web site" may have been the most significant thing you did in your project, but then it probably was for many other people as well. The order of terms in your title may also be crucial. Put the most important ones first and the least important last. In fact, do you need the least important ones at all?

Mentioning the means by which you solved your problem should only be included in the title if it is crucially important. As an example, suppose your project was concerned with the development of a database and you used Microsoft Access. Unless your project compared your product with a similar database implemented in Oracle, say, then the tool you used to solve the problem isn't as important as the problem you set out to solve.

Fundamentally, your title should reflect the single question that your project report sets out to answer, or the single problem that you set out to solve.

You've got to have style

Everyone's writing style is a bit different. Some people are adept at producing flowing paragraphs of prose while others get stuck with anything more than a list of bullet points. When writing your project report it is important to adopt a style that conveys your message (and reveals your aptitude for computing or whatever) in a clear and concise manner.

Always think of your audience when writing. For projects the best thing to do is to aim your report at your fellow students (perhaps those on your pathway). You don't need to labour points that they already know (e.g. stuff that has been covered in previous years' lectures) and you also have a good idea of how much explanation they will need of points that are not common knowledge. If you pitch it at this level, your report will also be readable by project students in future years.

It goes without saying that you must ensure that your report is free from spelling and grammatical errors. Get a good dictionary and a book such as Fowler's Modern English Usage (his earlier The King's English is online) or Strunk's Elements of style. There are also resources available at Online Writing Labs (OWLs) such as those at Purdue, Michigan and Maine. Proofreading is essential. I always read a paragraph immediately after I have finished writing it, and then read the whole piece again when I've finished it. The latter can be most effective if you leave it for some hours or even days after writing. By then your mind will be free of what you were thinking when you wrote it and you will read it with a more objective eye.

Write clearly. If you are trying to make a complicated point, break it down into its constituent parts. Think about whether what you have written follows on from what went before it (especially if you are inclined to over-use the word "thus"). Ensure that you use technical terms accurately and appropriately. "A picture paints a thousand words" is an old adage that remains true, but take care that the extra time you spend drawing a diagram pays off by making things clearer to the reader rather than just showing off your artistic ability (or lack of!). Similar advice applies to graphs and pictures. Splitting a list into a series of bullet points (or numbering them) is a good way of making it clearer. Invent chapter and section headings that succinctly describe what the chapter or section contains. Italicise words or phrases that you want to emphasise. Use bold type for keywords and headings. Don't overdo emphasis - if some text is in bold, italics, bigger type and a different font, then underlining it probably doesn't make it stand out any more!

Don't leave every section and chapter to stand completely on its own. Where appropriate, start a section with its own mini-introduction (possibly only a sentence or two) that says what the section is going to be about (particularly in relationship to the previous section). Similarly, you can end a section with a mini-conclusion that sums up the section and sets the scene for the next. Navigational aids such as these make a report much easier for the reader to follow. Also, the act of writing them will clarify in your mind what the section is intended to convey. The old adage "Tell them what you are going to tell them; then tell them; then tell them what you just told them" holds true.

Be clear, be accurate, be concise, be interesting, be relevant, be incisive, and be discriminating. Don't be muddled, vague, boring or offensive. Tell the reader what you did, how you did it, and why you did it that way. At the end of the day, a project report that is easy to read is easier to give good marks too. Remember that your examiner may have a dozen or more to read and they are only human!

Practical issues

Preparation and printing

I don’t know of any student in recent years that has not used a word-processor to prepare their report. Applications such as Microsoft Word, Word Perfect, Word Pro and many others make the preparation of medium-sized documents very easy. The main reason to choose one particular program over another is usually your familiarity with it. Whichever one you use, take advantage of the features it provides over and above basic formatting. Features such as paragraph styles, automatic numbering, automatic production of tables of contents and spell checking provide you with easy ways to ensure a consistent presentation throughout your report. Many Windows-based programs also facilitate the insertion of objects such as pictures and spreadsheet tables into a document.

If you have your own computer with a printer then this paragraph does not apply to you, but if you are intending to use the facilities in the University's labs, be warned, so are many other people! (BSc: The deadline for submission of your project coincides with deadlines for similar work in other departments on the campus. There will be long queues for PCs and even longer queues for laser printers.) If you can't make alternative arrangements, plan your work so that you can complete at least a few days early to avoid the last-minute peaks.

Binding and submission

You have to submit two copies of your report. [BSc: This was a new regulation in 1997-98.] After the examination process is complete one copy will go to your supervisor, the other will be lodged in the University Library. (There are two exceptions to the latter: (i) projects that failed are not retained; (ii) projects where the student, or the organisation they collaborated with, make a case that the project report contains material that is confidential.) If you are doing your project for an external client, it is customary to provide them with a copy of your final report (in addition to any other deliverables that you may have provided during the course of the project). If you want such a copy, and/or one for yourself, it is your responsibility to produce and bind it/them according to the standard requirements.

A separate document, How to bind and submit a project describes the process of binding and submission in more detail.

Summary

Your project report is probably the biggest single piece of work you will produce during your academic career. It is important for a variety of reasons and therefore you need to pay appropriate attention to its production and quality.

Plan your report and keep your readers in mind while you are writing it. Give them good signposts to what is important, interesting or relevant. Don't just be descriptive as to what you've done. Readers will want to know how you did it and, most importantly, why you did it that way.

Bibliography

Christian W. Dawson. The essence of computing projects: a student's guide. Prentice Hall, 2000. ISBN 0-13-021972-X. Publisher's price £16.99. An excellent guide to projects in general.

Gavin Fairbairn and Christopher Winch, Reading, writing and reasoning - a guide for students, Open University Press, 2nd edition 1996. (£10.99) An excellent guide to technical writing and style.

Phyllis Creme and Mary Lea, Writing at university - a guide for students, Open University Press, 1997. (£9.99) A useful guide to techniques of writing.

H.W. Fowler and Robert Burchfield, The New Fowler’s Modern English Usage, Oxford University Press, 1996

Appendix - Departmental project regulations

Successful project reports are lodged in the University library and are available for library users to consult. For that reason, it is important that reports follow a standard format and the following sections constitute the regulations for that. Project reports that deviate from the regulations may be penalised and, in extreme cases, failed.

Length

Normally a project report is:

PJE20, PJS20, WEPT1

 10,000 to 12,000 words

PJE40, PET40, WEPT2, PJ45M, TECPM, PROJM

 12,000 to 15,000 words

long (excluding appendices) but this limit is not mandatory. If your report is likely to be significantly longer or shorter than this, consult your supervisor as to what to include and what to exclude.

Presentation

The report must be submitted on A4 size paper (portrait orientation). Use one side of each sheet of paper only. Use good quality paper.

Text must be in typescript. Single spacing is recommended. 12-point type for normal text is strongly recommended, but chapter and section headings may be slightly larger. Use of a proportional font such as Times-Roman or Arial is strongly preferred for normal text. Program fragments should be in a fixed-width font such as Courier. Text in diagrams and figures may be in either sort of font as appropriate, but keep to a minimum of 9pt type.

Chapters should be numbered (1, 2, 3, …) and appendices lettered (A, B, C, …). Subsections should also be numbered (2.1, 2.2, …) but numbering to more than three levels (i.e. 1.2.3.4) is considered inappropriate.

Margins must be not less than 20mm (25mm or 1 inch is preferred, with an extra 10mm or so allowed at the left-hand (binding) edge).

Pages must be numbered consecutively throughout the report, including appendices. Page numbers located centrally at the bottom of the page are strongly recommended.

Title page

The first page must contain the following information in the order shown below:

University of Portsmouth

Computing & Mathematics Programme Area

Final year project undertaken in partial fulfilment of the requirements for the
BSc (Honours)/MSc Degree in [Degree title]

[Title of project]

by

[Full name of student]

Supervisor: [Name of supervisor]

Project unit: [Project unit code]

[year, e.g. 2008]

Abstract

The abstract of the project should be between 150 and 300 words in length and appear on the title page. It should provide a synopsis of the project, stating clearly the nature and scope of the work undertaken. It should include a brief statement of the objectives of the project, the work done, methods used, problems encountered and conclusions reached.

Other content

Normally the order of presentation will be:

1.      Title page and abstract

2.      Table of contents

3.      Acknowledgements

4.      Chapters

5.      List of references

6.      Appendices

Bulky appendices may be bound separately, but the same regulations for presentation apply.

Binding

The report must be bound together with the covers available from the Departmental Office. Each student is [JSB1] responsible for arranging for his or her report to be bound before submission. See How to bind and submit a project for further details.

Submission

You must submit two copies of your project report to the special hand-in desk on the deadline date. The deadline dates for various cohorts of students are listed in http://www.dis.port.ac.uk/disdis/projects/projdates.htm.

MSc students must also submit a copy of their report on 3¼" diskette.

Submission for all students is subject to the Department's usual rules and procedures for coursework. In the event of special circumstances affecting your ability to submit on time, an Extenuating Circumstances Form must be completed and submitted.


Page: 1
 [JSB1](except WI students) – WI exception removed