Final year projects take many different forms; it follows that project descriptions and plans will vary greatly. Consequently, these notes can only provide general guidance, and you may need to discuss them with your supervisor to decide exactly how they apply to your particular project.
Length: Any document should be as long as it needs to be—and no longer! This document should probably be about 10 to 12 sides of A4—but please note that this is only a guide. Your submission may (probably should) contain diagrams and charts as well as text, and some projects will require more than others. The best advice is to make sure you say everything you need to say—but don’t pad out your report with unnecessary or repeated material.
The outline structure of the document should be as follows:
All of these sections should be present in your document, but the amount of information that you need to provide for the methodology, platform and system descriptions will depend on the nature of your project.
10% of the overall mark will be allocated for the quality of presentation of your report. Credit will be given for clear organisation (table of contents, section headings, etc.), good use of document tool, well executed diagrams, standard of English and appropriate technical writing style.
A one-line statement saying what kind of project you are undertaking.
Broadly speaking, projects can take one of two forms: experimental or development.
In experimental projects, the implemented system is just a tool for the investigation, and the primary focus is on experimental methodology, the results obtained, and the interpretation of those results. Projects of this kind might involve developing an entirely new approach to the solution of some problem, or evaluating some existing technique (or language or design tool), or comparing the effectiveness of two different techniques.
In development projects, the implemented system is developed using established engineering methodology, and the primary focus is on the design of the completed system and the functionality that it offers to the user. Projects of this kind might place emphasis on the use of advanced design techniques, or they might be more concerned with the usefulness and quality of the finished product.
In practice, all projects will involve aspects of both development and investigation. For example, no development project is complete without some form of evaluation of the completed system and the methods employed during its construction. Any system that is developed for use in an experimental project has to be designed to meet a set of requirements.
Examples of Project Type statements:
A brief description of the context in which your project is set.
This section should provide the reader with some background to the problem that you are addressing in your project. It should be an expanded version of the description you gave in the initial proposal – you may have more to say now that you’ve had time to conduct a bit more research. Examples might include: a brief description of a commercial organisation’s business, an outline of the problems involved in robot navigation, an explanation of different approaches to implementing web sites, an overview of a particular Software Engineering technique, the growing importance of Computer Assisted Learning, etc.
A statement of what you hope to achieve in your project
This section constitutes the definition of your project, and forms the basis for planning. It should not be written in a “free text” style, but should take the form described in the notes that accompanied the lecture on Project Definition and Planning, i.e.
A statement of how you hope to achieve your project goals
The size and content of this section will depend upon the nature of your project. If your project is primarily experimental, then this is probably the most significant part of the overall project description; you should provide a clear explanation of the way in which you are going to conduct the experiment, the results that you hope to produce, and the basis for interpreting the results. If you are undertaking a development project, this section is still important; you should describe the engineering methods that you are going to employ, your reasons for choosing them, and how they are going to be applied in this particular development.
A description of the software/hardware you intend to use – and why
Once again the size and content of this section will depend upon the nature of your project. In some evaluative or comparative studies, the platform is the object under investigation, and the description(s) should be as detailed as possible. In other experimental projects, the platform may be irrelevant, but you should nevertheless explain that that is the case and say which platform you are going to use. In a user-oriented development project, there is usually a choice of platforms. In this case you should describe the alternatives and the reasons for your choice.
A top level description of requirements and design
Once again the size and content of this section will depend upon the nature of your project. The system description for the average user-oriented development project is likely to be much more extensive than the system description for a purely experimental project. In some experimental projects, the system that you implement in order to conduct the experiment will have only a few simply stated requirements, and its design need not be complex. In a user-oriented development project, there may be a large number of detailed requirements, and the design may include user interfaces, database systems, two or three-level architectures, etc.
In all cases, only a top level view of the required functionality and system architecture is required. Where appropriate, different user categories and associated access levels should be identified. System architecture descriptions should include diagrams showing the relationship/data flow between system components.
(Note: full requirements and design specifications may have been requested by your supervisor if you are conducting a software engineering oriented project. These constitute important milestones in the development process, and should be mentioned in the project planning section of this document. However, the specifications themselves should not be included here. They will form part of your final report and will be assessed at a later stage.)
In the lecture on Project Definition and Planning we identified six stages in the planning process
and three useful techniques for constructing and presenting a project plan
To gain maximum credit for this section you should provide a Work Breakdown Structure accompanied by appropriate descriptions of the tasks it contains and a Gantt chart showing milestones and "slack time". You might also include an Activity Network diagram, although in a project conducted by a single individual the idea of a "critical path" might not be relevant.
Remember the advice given in the lecture regarding the presentation of Gantt charts. The best approach is to provide a "multi-level" set of charts. The first chart should use a fairly large time unit to show the whole project schedule and the project milestones on one page. This can be followed by more detailed Gantt charts that use a smaller time unit to show the schedules for achieving each of the milestones shown on the main chart. If you do find it impossible to keep a chart on a single page, make sure that the list of tasks is included on the left of each page. Don’t resort to Sellotape!
It may be that you intend to use the "Rolling Wave" approach to the planning of your project. In this case, explain the Rolling Wave idea, and explain why it is the best approach for your project.
Note: you should give the complete schedule from the beginning of the year, including the tasks that you have already completed.
In this section you should provide a brief account of the tasks that you have completed and the tasks that you are engaged in currently, making reference to the work schedule that you presented in the previous section.
An important component of this section will be a description of the background research that you have undertaken. This may have taken the form of literature and/or web searches, in which case the relevant references should be listed in the bibliography at the end of the document. Alternatively (or additionally) you may have been evaluating existing products or interviewing potential users in order to develop a set of requirements. If so, give some details of how you undertook these surveys. In all cases give a brief account of the outcome of your investigations.
Marks awarded for this section will take into account the amount of work that you have undertaken, as well as the quality of your description.
These should have grown since the initial proposal stage. Try to present your bibliography and references in a consistent and organised manner. There are several conventions for listing references to books and research articles; your supervisor may express a preference, or alternatively you can look in any textbook to find those in common use. Whichever method you use, make sure that you use it consistently.
You are expected to critically evaluate major sources to establish their authority and relevance to the project.
Note: you will not gain credit for simply listing lots of books, articles and websites. You will only gain credit if they are relevant to your project and you have made reference to them in the descriptions within your text.
It is increasingly the case that the main source of information is the web, rather than published books and articles. Web references should be listed separately from the books and articles, and should include the URL, and the date on which you accessed the site.
Final year projects take many different forms; it follows that project descriptions and plans will vary greatly. This variation, particularly in the areas of methodology, platform and system description, makes it impossible to define a very detailed marking scheme that is appropriate for all submissions. Marks for the main components of the report will be allocated as follows:
| Presentation | 10% |
| Project Description | 35% |
| Project Plan | 30% |
| Progress Report | 10% |
| Bibliography and References | 15% |
This document ("Project Plan and Progress Report: Guidelines") will be issued to staff together with the marking sheets. The marking sheet, which includes assessment criteria, can be seen on the CC301 web page at http://courses.essex.ac.uk/cc/cc301/.
You are advised to take copies of the marking sheet and this document, and discuss them with your supervisor to see how they apply to your particular project.
The Department’s policy on late submission of coursework will apply:
(See also the full description in the Undergraduate Students’ Handbook.)A mark of zero will be recorded for any assignment submitted after the deadline set by the module supervisor.
It is good practice to build upon the work of others; it is good scholarship to discuss the writing of others in relation to your own. Reference to relevant published work is therefore an important part of your reports and credit will be given for it. In the body of your reports direct quotations from the literature must be clearly displayed, usually in quotation marks. If you are summarising or discussing the work of others it must be acknowledged in the text of your report and the work referenced in your Bibliography. It is plagiarism not to make such acknowledgements, either accidentally or deliberately. You must take care; otherwise you may find yourself in breach of University Examination Regulations 6.12 and 6.13.
The advice about plagiarism in the Academic Offences section of the Undergraduate Students’ Handbook applies particularly to project reports. This area requires careful discussion with your supervisor.
These regulations apply to code as well as literature. Please refer to the Final Year Project section in the Undergraduate Students’ Handbook.
Date: 2009-09-24 15:54:53 BST
HTML generated by org-mode 6.21b in emacs 23