MSc in Computer Science &
MSc in Multimedia Technology
2007
Choosing and Undertaking Your Dissertation Project
C P Willis
1. The MSc Dissertation Project
The dissertation project is an important component of the MSc course — it is the culmination of your MSc studies. It should enable you to exploit knowledge and skills you have learned during the taught component of the course, and broaden and deepen that knowledge in the investigation of a particular topic or area. It should also be enjoyable, since you have time to concentrate on an area of interest to you. Of course, you may not find it quite so enjoyable when you get close to the submission deadline, but if you have planned your time well, kept good notes and been writing up parts of your dissertation throughout the summer then you will be well placed to finish the project without a last minute rush.
The final assessment of the masters programmes is made on the basis of your overall average in the taught component of the programme, and the dissertation mark. To obtain an MSc degree you must pass the taught modules with an average of at least 50% and obtain a pass at the dissertation stage. As so much depends on the result of the project, both the choice of project and the way in which you carry out your project are obviously important.
The project must exploit knowledge and skills acquired during the course, broaden and deepen these skills, and apply them to a substantial task. Students may choose projects which involve use of their previous knowledge before coming on the course, but this should not usually be the major emphasis in the project. Most projects are concerned with investigating a particular topic or area, and usually involve a substantial software component. As an integral part of the dissertation project you should demonstrate that you can use the professional and academic literature available, to extend your knowledge and understanding, in order to successfully undertake the project. In addition, the project should show that you are able to critically evaluate both the work of others and of yourself.
To get you started on your
dissertation you have to take CM50175 Research Project Preparation,
which will introduce you to some of the issues in undertaking an MSc
dissertation, to the research areas of the staff and to some of their
project ideas. During this unit you will be allocated your project
supervisor and will undertake a literature review of your chosen
dissertation area, leading to a project proposal. The literature review
and project proposal form the major part of the assessment for CM50175,
with a small proportion of the assessment coming from attendance and
participation in seminars.
Summary of dissertation timetable for 2007
30th January This document made available to students.
23rd February 12 noon. Hand in Project Preference Form using appropriate hand in box, near Angela's office.
6th March Final project allocations given to students. Students start working on their literature review and project proposal for CM50175 Research Project Preparation.
4th May 12 noon. Hand in date for CM50175 literature review and project proposal.
4th June Students start working full time on their dissertation projects.
17th
Sept 12 noon. Final hand-in date for dissertation project.
Note: Students must work individually on their dissertation projects, and on the literature review and project proposal for CM50175.
2. CM50175 - Research Project Preparation
You should listen to all the talks given by the staff about project areas, and read all the information about potential projects that staff put up on the CM50175 web pages. Do some searching on the Web and the published literature to find out information about the project topics, and decide which ones you are most interested in. Some members of staff may choose to hand out project areas via email and not give talks.
Please fill in the Project Preference Form (copies can be found in the MSc laboratory) with your three preferred supervisors and project areas. Each project area must be with a different supervisor. You must choose three different supervisors to enable us to even out the supervision load across all members of the academic staff, but we try to give as many students as possible their first choice. Return the completed form by 12 noon on 23rd February 2007.
The most important factors in choosing project supervisors and project areas are:
• Choose something that you feel will be achievable. Assess the difficulty of the project and compare it to your ability in the topic. This is often difficult to assess, so discuss the topic with the supervisor and obtain his/her advice.
• Choose something that you find interesting — the best projects are usually the result of someone being highly motivated by the topic. If it is something that you dislike doing, then you are unlikely to do well, however much time you spend on the work.
• Maybe you can look towards the future - where are the job opportunities, what area of computing do you want to work in? Find something related.
• If you want to go on to research for a PhD try to do something related.
• Remember that your supervisor may not be available for the whole of the dissertation period. Remember staff do go away to other universities, to conferences, and on holiday during the summer.
• Be careful about using obscure programming languages or packages unless you are sure you can cope with learning them. If you have to share resources then ensure that there is sufficient time available for you to complete your work.
• Consider the supervisor. If your views on the project topic are incompatible with those of the supervisor, or there are other problems then choose another project.
Please note that we cannot guarantee that you will be allocated any of your preferences, especially if all three of your preferences turn out to be extremely popular with other students.
2.1 Doing your dissertation project preparation for CM50175
You have until 12 noon, 23rd February 2007 to indicate your first, second and third preferences for your project area and supervisor, and to return the project preference form. We aim to make allocations of students to supervisors by 6th March 2007.
As soon as you have been allocated a project supervisor you should meet with your supervisor to confirm your project area. You will need to make an appointment to talk to your project supervisor. Your supervisor should also be able to give you some indication of where to start your literature search, and perhaps a more detailed idea of possible project directions. The project supervisor has the right to veto a project if he or she believes that the project will be inappropriate (for example, if it is too trivial for an MSc dissertation). You will then have to choose another, appropriate, project area with the same supervisor.
The literature review and project proposal must be handed in by 12 noon, 4th May 2007. You should expect to spend about 80 hours researching and writing your literature review and project proposal.
3. Undertaking the dissertation project after the Semester 2 examinations
Note: Students are expected to work individually on their dissertation projects.
The project proposal that you write for CM50175 will be the project that you undertake for your dissertation over the summer. You should be able to reuse some of what you have written for CM50175 in your dissertation, although you should expect to alter and improve it.
The dissertation project for the MSc should occupy you full time (about 40 hours each week) from 4th June 2007 (the end of the exam period) until 17th September 2007. After the submission date you have no further right to assistance from your supervisor, and access to the computers will be severely limited as priority for access must be given to the new intake of students.
As a postgraduate student you are not expected to take the holidays that the undergraduates take. The University is open during the holidays, so you can always gain access. You should not to take any holidays during the summer dissertation period. If this advice is ignored, and you take holidays, then previous evidence has shown that you will find great difficulty in finishing your dissertation on time. Remember that the MSc is a 12-month intensive course, and you are expected to work full-time on it. Extensions will not be available for anyone who cannot meet the hand-in date because they took a holiday.
The summer dissertation period is part of the MSc and you are expected to be working at the University during this period. By working at the University you will be with other MSc students and be able to talk to your project supervisor more easily. Students who choose to work away from the University often find that they lose motivation and find that it is harder to keep up the level of work required to finish the project in time. If you base yourself here in Bath you will find the support of other students working around you as a great advantage.
In normal circumstances your project work should be carried out in the University using the BUCS PCs in the MSc lab. You should ask your project supervisor about any specific hardware or software requirements that he or she may have for your project. Many supervisors will require that project work is done on a specific computer system and in a specific programming language.
If you do any of your project work on your own PC, or if you keep all your work on floppy disks instead of on the BUCS filesystem, then it is entirely your responsibility to make and keep backups. A crashed hard disk on your home PC or a lost/corrupted floppy disk will not allow you a late submission of your dissertation. The BUCS filestore is backed up regularly and will provide some possibility for retrieving lost information. However, do not expect them to backup every night. It is far safer to keep your own backups on floppy disk, CD or ZIP disk, even if you are using the BUCS system.
Demonstrating your software
You should also bear in mind that you will have to demonstrate any software you write for the project to your supervisor and the second marker (allocations of second markers to projects will be done during the summer). Make sure that you can run your software on the BUCS PCs in the MSc lab, or on whatever computer system you r supervisor has requested.
3.1 Project supervision
The project is carried out in consultation with a project supervisor who is normally the member of staff who proposed the project, or the designated member of staff who is liaising with an industrial supervisor. The period of supervision is from the time that you have been accepted onto a project, through to the project submission date. It is important that you have regular contact with the supervisor(s). You can expect your supervisor to offer the following:
• at an early stage of the project, during CM50175, help in finding an appropriate topic, where to start researching the literature and some worthwhile goals;
• general guidance on the project;
• help with points of theory and analysis that you are finding particularly difficult;
• advice on software/hardware needs;
• critical review of work you have done so far (at any stage of the project);
• advice on the next step to take;
• advice on
the structure and content of your dissertation;
Do not expect your supervisor to:
• teach you a programming language;
• debug software;
• be available on demand — you must make an appointment;
• search the literature for you;
• do your project for you;
• write your
dissertation for you.
Guiding you to establish the final form of the dissertation is considered to be part of your training, but as time is finite you can only expect a reasonable amount of your supervisor's time. If you wish to have comments on your dissertation then start showing drafts of your efforts to your supervisor early on in the summer. A supervisor who is presented with drafts from say four students in early September will not be able to cope with the bulk of work.
4. Plagiarism and Cheating
All forms of cheating are serious academic offences, and may lead to the person being required to leave the University without gaining any qualification.
Cheating includes:
• Plagiarism (passing off work done by others as your own), such as: copying from books and papers without acknowledging where the information comes from; reusing programs or designs and pretending that you wrote them; obtaining work from someone else and pretending that you did the work; working jointly with someone and presenting the work as yours alone.
• Fabricating evidence, such as: inventing testing results; inventing questionnaire responses; pretending that you have performed some task when in fact you haven’t; changing results obtained from experiments to look better in some way.
When you describe the work done by others, be careful not to copy it word for word from their publications. You need to read what they have done, and then summarise and discuss it in your own words, and cite the original article where you read the information. Summarising it in your own words does not mean swapping around the order of some of sentences or changing a few words. It means writing your own words to describe the work, generally with your own, justified observations and comments on the work added.
It is perfectly acceptable to quote small sections from the work of others, as long as you make it clear that it is a quotation, and where the quotation is taken from. However, only include quotations where absolutely necessary — your discussion of related work should mostly be in your own words.
You could produce a whole chapter (perhaps on the background to your project) by quoting lots of blocks of text written by others on your topic, carefully citing each one appropriately, and putting a few lines of your own between each quote. This is not plagiarism but it will not get you many marks because you have not really done any work yourself.
If you need to use code developed by others ensure that you clearly mark the code with the name of its rightful author — if it contains comments stating the author, you must not remove these comments.
Again, you could use mostly other people's code for your dissertation project, being careful to cite each piece of code correctly, so that it is clear who the author actually is. But again this will not gain you very many marks, because you have not done much work yourself, only used the work of others, albeit properly referenced.
If you use a diagram or any other form of image from a book or a website then you must acknowledge where the image came from.
The University has a number of things to say about plagiarism:
There are various forms of academic dishonesty but in the student's context it means cheating in examinations or presenting work for assessment which is not your own.
Plagiarism as a form of cheating takes place when the student 'borrows' or copies information, data or results from an unacknowledged source, without quotation marks or any indication that the presenter is not the original author or researcher. If carried out knowingly, cheating and plagiarism have the objective of deceiving examiners and this threatens the integrity of the assessment procedures and the value of your award.
Work produced by someone else may be summarised or repeated providing it is referenced to the original author. As well as text, work such as diagrams, maps and charts must also be acknowledged. In addition to the use of quotation marks when quoting from original sources and secondary material, full references for both quotes and paraphrases or summaries of published material must be given. All references should then be included in a bibliography at the end of the piece of work. Appropriate references for web-based material must also be given, including the relevant URL.
Any student found to have used unfair means in any examination or assessment procedure will be penalised. ‘Unfair means’ include:
• cheating, for example unauthorised reference to notes or course material in an examination
• fabrication, e.g. reporting on experiments never performed
• falsification, e.g. misrepresentation of the results of experimentation
• plagiarism, i.e. taking the writings or ideas of another and representing them as one's own
• unfair collaboration or collusion; i.e. the representation of work produced in collaboration with another person or persons as the work of a single candidate.
The nature and severity of the penalty will depend on the offence, but this may mean failure of the unit concerned or a part of the degree, with no provision for reassessment or retrieval of that failure. Cases of plagiarism or cheating can also lead to an Inquiry Hearing and/or disciplinary proceedings as indicated in University Regulation 7.4(h).
QA53 University Academic
Procedures, Practices and Guidelines - Examination and Assessment
Offences gives details of how cheating and plagiarism is dealt with by
the University. It can be found on the web at http://internal.bath.ac.uk
It is important that you understand
that the Department and the University take cases of cheating and
plagiarism very seriously.
Getting Further Information
The Library and Learning Centre has collected some helpful information about what plagiarism is and how to avoid it:
http://www.bath.ac.uk/library
You should read all the information that is available on these pages. There are also links to other sites which you may find useful.
If you are unsure if what you are doing could be classed as cheating or plagiarism at any stage of your dissertation project, then you should talk to your project supervisor or to your Director of Studies.
Finally
If you do not want to be accused of plagiarism then only use someone else's words if you want to quote exactly what they have written (and then fully reference where the information came from). The same is true for using code written by others. It does not matter if the text you are using is in a book, on the web, in a newspaper, in your friend's files etc. Passing off the work of others as your own is wrong. It is also pointless because you will not have learned anything by doing it. In the end, the main person you are deceiving is yourself - you will not really be able to have any pride in your work if it is not actually yours.
5. Writing your Dissertation
The main piece of evidence supporting an excellent project is the dissertation. Most of the decision-making regarding your grade will come from examining this document. Obviously, to obtain a good mark for a good project the dissertation must be of a similar standard. If the structure described in this document is followed with intelligence and substance then you are likely to obtain a good result. See Appendix A for a reminder of the rules for the award of the MSc.
5.1 Overall Structure of a Dissertation Report
There are many different sorts of project so it is impossible to provide hard and fast structure rules. However, certain components will need to be present, and a certain ordering of these components is also necessary
• Title page (a pro-forma is provided at the end of this document)
• Abstract (of no more than 300 words)
• Acknowledgements
• Signed declaration by candidate (see later in this document)
• A contents lists, giving (at least) chapter titles and their page numbers.
• Main body, including a critical evaluation of your work.
• Bibliography - to include all references to material used while undertaking the project and in preparing the dissertation. Include textbooks, research papers from conferences and journals, manuals, web pages etc. The individual items in the bibliography must be referenced in the appropriate places in the main body of your dissertation.
• Appendices - These contain
information that is essential to the understanding of the dissertation,
but do not require formal descriptions in the main section.
Resist the temptation to pad out the dissertation with
unnecessary appendices.
5.2 The Abstract
The abstract comes immediately after the title page, on a page on its own. It consists of a brief summary (no more than 300 words in length), which accurately outlines the main aims and achievements of your dissertation. For example:
“In this thesis we use machine learning and data abstraction to research the problem of program synthesis through software reuse. We synthesise programs from a specification of an abstract data type by using transformation methods that reuse an existing and correct implementation of a different abstract data type. In this way we are able to build software by making use of previously synthesised, or otherwise generated, correct implementations, thereby avoiding ad hoc techniques which attempt to mimic human cognitive processes. We develop the theory of explanation-based completion (EBC), which combines the essential features of the explanation-based learning paradigm and completion techniques for systems of axioms, such as Knuth-Bendix completion, and provides a new technique for generating correctness-preserving implementations of ADTs at the formal specification level. In addition, we describe how the EBC paradigm has been used to examine inheritance in specifications, and in the synthesis of ADT implementations.”
5.3 Acknowledgements
In this section you should acknowledge those who have helped you, or offered advice during your dissertation project. It is common courtesy to include an acknowledgement to your project supervisor, and people often also acknowledge family and friends who helped to proof-read the work, or perhaps just provided meals at appropriate times! Here is an example:
“Thanks are due to the following people: My supervisor, Dr Fred Bloggs for his help and encouragement throughout this project. Dr Sally Brown from the Management Department, who provided contacts in local management consultancy companies. The companies listed in Appendix B for allowing me to talk to their staff when gathering requirements for the project. My family for their support and encouragement (and continual cups of tea and chocolate biscuits) during the project.”
5.4 Contents Page
This is, of course, made up of all the titles of the sections and subsections in the report. It should be laid out so that the structure of the dissertation is easy to see. You must give the page number at which each section starts. Make sure it is correct! Here is an example from a contents listing:
Chapter 1 Introduction 1
1.1 A background to program synthesis 1
1.1.2 Problems with program synthesis 4
1.2 An alternative approach through reuse 5
1.2.1 Code level reuse 6
1.2.2 Design level reuse 6
1.2.3 Specification level reuse 7
1.2.4 The object-oriented approach 7
1.2.5 Abstraction for reuse 8
1.3 Reuse or synthesis 9
1.4 Combining reuse with artificial intelligence 9
1.5 Overview of thesis 9
Chapter 2 Data abstraction 12
2.1 The history of data abstraction 12
2.2 Formal (algebraic) specification of ADTs 15
2.2.1 Specifying ADTs 17
5.5 The Main Body
This section should be about 75 - 100 pages, including diagrams. Please keep your thesis to this size — longer theses are liable to be penalised unless the extra length is essential for reporting the work undertaken.
You must therefore decide what information must be given in detail, and what information can be presented in summary. Since there are different styles of MSc dissertation it is impossible to given a single set of rules to describe what should be in the main body of the text, so what follows are only general guidelines. A project may not fit neatly into a single category.
You should discuss with your project supervisor, what s/he expects you to produce.
The main body should contain the following:
1. Introductory and background information
This should include an initial description of the problem that you are investigating in your project, and a statement of the aims and objectives of the project. There should also be an indication of the context in which this problem exists (its background and history), and why this is an important problem to consider. In other words, state what you are going to be discussing in your dissertation, and why you are bothering to discuss it! You should include a discussion of related work (work by other people), where it has bearing on your own work. This gives a context for your project, and will help you in your critical evaluation of your achievements. The related work will be referenced in your text, and the references detailed in your bibliography.
You should include a survey of the background and history of your project topic, and why it is an important problem to consider. It is very important that you thoroughly research the area in which you are working to find out what has already been done, because this may be important for how you choose to solve your problem. In some cases you will want to discuss why others' attempts to solve the same (or similar) problem have failed, or why you are choosing to follow one person's approach above all the rest. Also indicate how you intend extending or incorporating what you have learned from others' work into you project. Remember to reference all the literature that you survey in the bibliography.
2. A description of the work undertaken for the project.
This should include details of scientific or technical problems that had to be tackled, including clear descriptions of these problems, how you approached solving them, your proposed solutions to these problems, and a justification of why your proposed solutions are appropriate.
The detailed content of this part of your dissertation will depend very much on the specific project you are undertaking, and it is up to you to decide the best way to report your work. You should discuss this with your project supervisor,
If the project involves a software development component then the software lifecycle (requirements analysis and requirements specification, software design, implementation details, testing) should be followed and documented. The depth to which the software development is documented will depend on the role of the software in the project (that is, whether it is a major part of the project or a minor part).
If the project involves investigatory or experimental work then you will need to report how you chose and designed the experiments, and the criteria by which your experiments will be judged to be successful or otherwise.
3. A description and analysis of the results you have obtained.
Your analysis will, of course, depend on the aims of the specific project you are undertaking. You need to give reasoned explanations of your results, and you also need to justify the way you have analysed your results. Unexpected or negative results should also be reported and analysed. Why did they occur?
4. A critical evaluation of your work and a discussion of the conclusions that can be drawn from it
This is an essential part of your dissertation. The content of this section will depend very much on the original aims of your project, but in general it should be a critical review and evaluation of your project.
First, state what you have achieved in the project. State which of the original requirements have been fulfilled, and which have not (if any). Indicate any extra work you have done, above and beyond the original requirements. If your requirements had to change as you went through the project, describe why they had to change, and how they changed.
Evaluate what you have achieved. Is it what you expected (if not, why not)? Is it good, bad, indifferent? How significant are your results - what are the significant factors and why are they significant. Do your achievements tell us anything new about the subject area you were working in? Would you approach the problem differently if you had to do it again? Why? Was your overall methodology for the project appropriate? Why or why not? How would you change your overall methodology if you had to do the project again?
Make suggestions for future work which needs to be done. Has your project suggested any new or unusual directions that should be considered?
5.6 The Appendices
There may be information that is important to the understanding of your dissertation report, but which does not fit naturally into the main body of the dissertation. For example, if you are using special tools to build your system (such as Macromedia director) you might wish to provide the reader with a brief description of these tools. This description is probably best placed in an appendix, and the reader directed to the appendix at the appropriate point in the main text of your dissertation.
Another appendix could usefully contain the test plans and test results from testing your system. If you have a very large number of test plans and test results then it may be preferable to include only a representative subset, and to state briefly the scope of the tests whose results are not shown. Remember that your testing strategy should be described in the main body of the dissertation where you described the work you have carried out, and the reader directed to the appropriate appendix to find the detailed test plans and results.
If your system is designed to be used and/or maintained by others then you should include the user and maintenance guides as another appendix.
You should also put your code into an appendix, so that the reader can see your coding style and commenting standards. Provide a short overview at the start of the appendix, to allow the reader to find their way around the code. Just presenting the code, with no explanation at all is inappropriate.
You must photo-reduce the code so that you get at least two original pages per A4 page (and preferably four per A4 page, as long as it is still readable). If you have a large amount of code, then you should consider including only a subset of the code — perhaps only the most important components or the most complex components. In general, if the photo-reduced code is longer than 20 pages, then you should leave some of it out, to reduce it to 20 pages.
These are only suggestions — what goes into the appendices is very dependent on the specific project you are undertaking. You should only include appendices that are absolutely necessary. Do not pad out your dissertation with unnecessary appendices.
In any case you should put all your code, including any runnable demonstration, documentation, video etc, on a CD-ROM attached to the inside back cover.
5.7 The Bibliography
You will certainly be using books, research papers, articles, URLs and so forth, to provide you with information to do your project. In addition, the background section of your dissertation will discuss other people's work in the field in which you are working.
You must acknowledge all your information sources. This is done by providing a list of references, usually called a bibliography, at the back of your dissertation, and referring to the individual items in this list at the appropriate points in your dissertation. Citing the quoted work of others is also necessary to distinguish your work from theirs and thereby avoid being accused of plagiarism (copying). The University treats plagiarism as a serious offence, so take great care to make this distinction.
The bibliography is usually put at the very end of the dissertation, after all the chapters and appendices. It is not usual to give a section number to the bibliography section.
The author-date system of referencing
We recommend that you use the following form of bibliography (often called the Harvard system):
Atkinson, C 1991. Object-oriented reuse, concurrency and distribution. Addison-Wesley. |
Barnes, B H and Bollinger, T B 1991. Making reuse cost-effective. IEEE Software, January, 13-24. |
Berztiss, A T and Thatte, S 1983. Specification and implementation of abstract data types. In Advances in Computers, Volume 22. Academic Press, 295-353 |
Dershowitz, N 1985a. Synthetic programming, Artificial Intelligence, 25, 323-373. |
Dershowitz, N 1985b. Computing with rewrite systems. Information and Control, 65, 122-157. |
This bibliography is in alphabetical order, but is un-numbered. Items from this type of bibliography can be referenced in the text as follows:
This deficiency in procedural languages has led to research into separate forms of specification which provide both syntactic and semantic information [Guttag and Horning [1978]].
Goguen, Thatcher and Wagner [1978] gave a description of a formal specification of an ADT as equivalent to an algebra.
We can trace the roots of object-oriented languages back to Simula [Dahl and Nygaard [1966]], which was the first language to provide a means of defining ADTs in modules (called classes in Simula and most later object-oriented languages).
These references are informative when they appear in the text. A reader who is knowledgeable in the research area covered by the report is likely to know which reference is being referred to, without having to look it up in the bibliography. Note that you need to give both the author(s) and the year of publication, where the reference appears in the text. If an author has multiple publications for one year, label them a, b, c and so on, so that they can be distinguished in the text (as in the example for Dershowitz, above).
The use of square brackets for this style of reference is not compulsory. Some people prefer to use round brackets, such as (Dahl and Nygaard (1966)). Some also prefer not to bracket the date, but just to separate it from the author(s) with a comma, such as (Dahl and Nygaard, 1966).
Remember that every item in your bibliography must be referred to at least once somewhere in the text. Your project supervisor may prefer a different style for references, so it would be worthwhile to ask what particular reference style s/he would like you to use.
6. The Main Body of the Dissertation
This section should be 75-100 pages. You must therefore decide what information must be given in detail, and what information can be presented in summary. Since there are different styles of MSc dissertation it is impossible to given a single set of rules to describe what should be in the main body of the text, so what follows are only general guidelines for two different sorts of project - software development projects and investigation/experimental projects. Remember that a project may not fit neatly into a single category and may need a combination of approaches. You should also discuss with your project supervisor, what he or she expects you to produce.
6.1 Software Development Projects
Since this is the commonest style of MSc project a detailed description of the types of things that would be expected is given below. Here is a possible contents list (main chapters only) for such a project. It is not necessarily complete, so do not try to follow it slavishly, but adjust it to the needs of your particular project:
1. Introduction
3. Requirements analysis and specification
4. Overall Design
5. Detailed design and implementation
7. Testing
8. Critical Evaluation
Appendices
Bibliography
Introduction
This section will be quite short, and should include an initial description of the problem that your software system is intended to solve. There should also be a brief indication of the context in which this problem exists (its background and history), and why this is an important problem to consider. In other words, state what you are going to be discussing in your dissertation, and why you are bothering to discuss it! You should include a discussion of related work (work by other people), where it has bearing on your own work. This gives a context for the software that you are going to develop in the project, and will help you in your critical evaluation of your achievements. The related work will be referenced in your text, and the references detailed in your bibliography.
This section should include a survey of the background and history of your project topic, and why it is an important problem to consider. It is very important that you thoroughly research the area in which you are working to find out what has already been done, because this may be important for how you choose to solve your problem. In some cases you will want to discuss why others' attempts to solve the same (or similar) problem have failed, or why you are choosing to follow one person's approach above all the rest. Also indicate how you intend extending or incorporating what you have learned from others' work into you project. Remember to reference all the literature that you survey in the bibliography.
Requirements analysis and requirements specification
This section should contain a detailed analysis of the problem you are trying to solve. Remember that the requirements are the user requirements (that is, what the user wants), so should not usually include any specific design or implementation details. If possible and appropriate, you should discuss the requirements with potential users.
The idea of the requirements analysis is to produce a requirements specification, which is a precise statement of the problem you are going to solve. This should include the goals that your final system should meet. Note that the requirements specification comes after the requirements analysis.
For some projects it is more appropriate to include the requirements analysis as part of the discussion of the background and related work. In which case this section will just contain the requirements specification. If the user interface is a large component of your project, it is likely that you will need to do a separate background, requirements and design for it.
Overall design
The first part of the design should be an analysis of the problem, as it is stated in the requirements specification, to determine the most appropriate approach to solving it.
Once you have decided upon a suitable solution you can start designing the overall structure of the software system with which you will implement this solution, and the components which are required. If you are following a modularisation approach, you should describe how you determined the data abstractions required, their individual operations, and the relationships between them. After that, each component should be individually specified, as formally as possible. If you have considered and rejected alternative designs, you should describe them and explain why they are inappropriate.
If the user interface is not a major
component of your project then its design can be described as a
sub-section of the overall design. If the user interface is a major
component of your project then you may wish to include a separate
chapter detailing the user interface analysis and design.
Detailed design and implementation
This will vary depending on the sort of project you are undertaking and the language you are implementing in, but will involve detailing how the overall system design is implemented in your chosen language. The detailed design is likely to include pseudo-code algorithms for important or complex operations, and determining the ways in which the data will be represented.
You should provide detailed design and implementation details for non-trivial components of your system. You should not describe the implementation of every little procedure and function. It is up to you to decide which design and implementation issues are important and need detailed descriptions and which do not. If you had problems implementing your designs, these should be described here. One of the main problems we see with this part of the dissertation is that students tend to describe far too much trivial detail about implementation.
If the user interface is a major part of your system, you may decide to have a separate chapter detailing its implementation, or you could include it in this chapter.
System testing
Obviously, testing will occur throughout the development of your software, but if you document it when and where it occurs, this will leave the testing information dotted throughout your dissertation. It is usually much better to have a separate section in which you describe all the levels of testing for your system. You should start this section by describing and explaining your testing strategy. You can then describe the various stages and levels of testing undertaken. The aim is for you to demonstrate that you understand the reasons for and the process of testing a substantial piece of software.
You are unlikely to have time to
perform complete testing of your software, so you should choose
carefully those aspects which you will test, explain why these aspects
are important, and detail the testing done on them. Test plans and test
results can be placed in an appendix.
Critical Evaluation
This is an essential part of
your dissertation. The content of this section will depend very
much on the original aims of your project, but in general it should be
a critical review and evaluation of your software.
The evaluation might include discussions on the following topics:
— whether the requirements were appropriate, or had to change as the project progressed.
— which requirements were fulfilled, which were not;
— any extra work done above and beyond the requirements, and why it was needed;
— whether you made the correct design decisions;
— whether the project achieved all its aims satisfactorily;
— whether the software fulfilled user needs;
— how you might design/implement the system differently if you had to do it again;
— any future
work which remains to be done.
The appendices are suitable places for reduced copies of code, the project timescale chart etc. Do not pad the report with unnecessary appendices.
6.2 Investigation/Experimental Projects
There are many different sorts of investigation project, so you may need to alter this layout description to suit your specific project. Common forms of investigation project include: building a prototype package to perform some set of tasks, evaluating its performance and determining ways in which it might be improved; investigating the behaviour of a known algorithm for a particular set of tasks, and determining when its use is appropriate and when another method should be chosen, (possibly, also determining ways in which the algorithm’s usefulness might be improved or enhanced).
1. Introduction
2. Design of the experiment(s)
3. Running the experiment(s) and experimental results
4. Analysis of experimental results
5. Critical evaluation and conclusions
Introduction
This section should include an initial description of the problem that you are investigating, its background and history. This will give a context for the main work of the investigation. You will need to do a literature survey of the topic under investigation (this could be in a separate chapter), and, if appropriate, a literature survey of actually undertaking such investigations.
It is quite likely that your project will be rather specialised, so you will need to ensure that you provide sufficient information for the reader of your dissertation to be able to understand and appreciate the topic.
It is very important to thoroughly research the background of the problem you are investigating, so that you can be clear about the aims and extent of your investigation. Ensure that the reader knows exactly what you intend achieve.
Design of the experiment(s)
You should describe, and justify your choice of experiments, explaining clearly what sort of information they are intended to provide and how that information will be used. Then you can detail the design of the experiments. If your investigation involves designing and implementing experimental software you should describe your requirements, software design and implementation here (you should look on this part as a mini-software development project). Remember that any software, even if it is experimental, needs to be tested before it is used to provide experimental results.
When you design your experiments, it is essential that you state the criteria by which your experiments will be judged successful. How will you evaluate the performance of your experimental software?
If your experiment consists of developing a prototype package for undertaking some set of tasks you must show both the design and development of the software, and the design of the tests that you are going to run with the prototype. For example, you may need to design usability tests, which you will get test users to undertake, and perhaps questionnaires for them to fill in after the tests. Remember to justify your designs for all these components.
Running the experiment(s) and experimental results
In this chapter you should describe how the experiments were undertaken, and report the results obtained. It is important to present the information in a clear, structured manner.
If you have a developed a prototype software package that was tested on users, you will need to describe how you undertook the user tests, and present the results you obtained from them. There may be several forms of results — you may have notes taken by yourself, as the usability tests were in progress; you may have items produced by the users during the tests, using your prototype; you may have questionnaire results from questionnaires filled in by the users.
Analysis of Experimental Results
Here you need to analyse the results you have obtained through running your experiments. Your analysis will be dependent on the aims of the specific investigation project you are undertaking. Remember to justify the way you have analysed the results. At this stage you could indicate where results appear to be unexpected.
Critical evaluation and conclusions
This will be very dependent on the original aims of the investigation. You may need to consider:
— what your investigation has determined, based on the results obtained. If you developed and tested a prototype software package, how well did it perform, and how might it be improved?
— how significant are the results you have obtained in your investigation? What are the significant factors and why are they significant?
— whether the experiments you chose were appropriate, based on the usefulness of the experimental results you obtained;
— if the experiments did not provide useful results, or mediocre results, how they could be re-designed to be more useful and appropriate;
— whether your methodology for the investigation was appropriate. Why or why not? How would you change your overall methodology if you had to do the project again, to obtain more useful results?
7. Document layout and style
The actual content of your dissertation is, of course, highly important — you will not get an MSc if you have not done an MSc-level project. However, you also need to consider the appearance of your dissertation, since producing a professional document is an integral part of the dissertation section of the MSc. Any reader can be put off the content of a document by poor English and sloppy formatting — make life easy for your readers by presenting them with a well-formatted, error-free, easy-to-follow dissertation.
We have already discussed the various components you are likely to need in your dissertation, and how they might be ordered. The following sections discuss some more general points concerned with layout and consistency.
7.1 Section numbering
As you can see from the example contents listing in section 3.4, it is normal practice to number sections and sub-sections. Consider this contents list again, since it shows us how we should number our sections. The indenting also helps indicate to which higher level section each subsection belongs:
Chapter 1 Introduction 1
1.1 A background to program synthesis 1
1.1.2 Problems with program synthesis 4
1.2 An alternative approach through reuse 5
1.2.1 Code level reuse 6
1.2.2 Design level reuse 6
1.2.3 Specification level reuse 7
1.2.4 The object-oriented approach 7
1.2.5 Abstraction for reuse 8
1.3
Reuse or synthesis? 9
Chapter 2 Data abstraction 12
2.1 The history of data abstraction 12
2.2 Formal (algebraic) specification of ADTs 15
2.2.1 Specifying ADTs 17
The main sections (called chapters in the above example) are the first level of units which divide up your dissertation, and are numbered 1, 2, 3, and so on, as you would expect. Do not start with a section 0.
The second level units, are subsections which divide up each main section. These are numbered so that it is immediately clear to which main section they belong. For example, 1.1, 1.2, 1.3 are in section 1, while 2.1 and 2.2 are in section 2.
In this sample contents list we also have third level units, which divide up some of the sub-sections. These sub-subsections are also numbered so that it is clear which subsection they belong to. Thus, 1.1.2 is in subsection 1.1, while 2.2.1 is in subsection 2.2.
Do not go to any further levels of numbering, such as 1.2.2.1. This is far too much! If you really do need to subdivide the contents of a third level unit (of the form 1.2.3), use un-numbered headings, which should not appear in the contents list.
7.2 Numbering diagrams and other components
If you need to have diagrams, or figures, as they are more usually called, in your dissertation then these too will need numbering. It is usual to number a figure according to the main section it is in. Thus the first figure in section 1 will be Figure 1.1, the second figure will be Figure 1.2, and so on. Do not number figures according to the subsection or sub-subsection they are in; that is, a diagram which resides in subsection 1.3.2 will still be numbered Figure 1.x, not Figure 1.3.2.x.
Where a figure appears in your
dissertation you must give it an appropriate number, and a title, which
describes what it shows. For example,
Figure 7.1 A simple linked list
(As a matter of style, notice that the figure is separated from the rest of the text by horizontal lines above and below it, which serve to make it stand out from the page).
It is very useful for the reader if you provide a list of figures, and where each is to be found, on a page after the contents list.
You can number components other than figures in a similar way. For example, if you have a lot of programs or tables in your dissertation, these could be entitled, Table 1.1, Table 1.2 and so on, and Program 1.1, Program 1.2 and so on. Make sure that each has an appropriate title as well as its number.
7.3 Referring to sections, sub-sections and figures
Numbering sections and figures is very useful because it allows you to refer to them in the text, without any ambiguity. So, if you want to direct the reader to another part of your dissertation, you can say something along the lines of "See Section 3.3 for an example of how pointers work in Oberon-2."
Note that if you have numbered your figures, then you should always refer to them in the text by their numbers. For example, if we were writing the text to discuss the example diagram (given above), we would refer to it as follows: "Figure 6.1 shows a diagram of a simple linked list."
7.4 Page appearance
Do not try to be innovative and clever with your document style. You want your dissertation to convey information about the dissertation project you undertook, not to convey how clever you can be with Microsoft Word!
The most important aspects of document design are clarity and consistency:
Clarity: choose layouts, fonts and so on, so that the reader finds it easy to read.
Consistency: keep to your chosen layouts, fonts, numbering conventions and so on.
Fonts and font sizes
Choose a font that is easy to read, and conveys the right message about the information that it is being used to report. You may need to use several different fonts, but do not use too many, because this can make a page look far too "busy", and hard to read.
For the main text you should use one of the "standard", proportionally-spaced, serifed fonts such as Times, Palatino, New Century Schoolbook. An MSc dissertation is definitely not the place to be experimenting with fonts that look like handwriting.
Sans serif fonts such as Arial and Helvetica, are not really suitable for the main text, but can be useful for formal specifications and pseudo-code algorithms. You may also wish to use a mono-spaced font for program code, where it appears in the body of your dissertation.
If you are not sure what is meant by serif and sans serif, proportional and mono-spaced, the following may help:
This is Times, it is a proportionally-spaced, serifed font. The serifs are the tiny bars on the ends of some of the letter strokes.
This is Helvetica, it is a proportionally-spaced, sans serif font. It is sans (without) serifs because there are no bars on the ends of any of the letter strokes.
This is Courier, it is a mono-spaced (fixed width), serifed font. The above fonts are proportionally-spaced, which means that each letter only takes up as much space at it needs. Thus, in Times, an i takes up far less space than an m. In a mono-spaced font, each letter takes exactly the same space.
You also need to consider the font sizes you will use. For the main text, a font size of 10 point or 11 point is probably best. 9 point is rather too small to read comfortably, and 12 point can look unreasonably large, as if you are trying to spread out your work because there is not enough of it.
However, note that font sizes can differ considerably from font to font. The three sample fonts above are all in 10 point, but look quite different in size from each other.
You can use font sizes to differentiate between different levels of section heading. For example, the main text in this document is in 10pt Palatino, the chapter headings are in 24pt Palatino, the subsection headings are in 14pt bold Palatino, and the sub-subsection headings are in 12pt bold Palatino.
Page layout
Your dissertation must be typeset on A4 paper. Choose appropriate margins — make sure that your text does not come too close to the edge of the page, since this will make your dissertation very uninviting and hard to read. Equally, be sensible and do not make your margins too large, so that there is very little text on the page!
Remember to include page numbers!
You will need to decide whether you want your text to be fully justified, or simply left justified. This document is formatted with left justified text, which gives a ragged right margin. Whichever one you choose, make sure that you are consistent in using it throughout your dissertation.
Spacing and white space
Never be afraid of using white space, to make your document look attractive and easy to read (though, obviously, do not use too much, or you will make it look silly). This document uses lots of white space to separate the various components on the page, yet it still manages to fit plenty of information onto each page.
Although you may never have thought about it, the spacing between lines is very important when it comes to making a document easy to read. Single line spacing tends to be too close together for comfortable reading, and double line spacing tends to be too spread out. We prefer 1.5 line spacing. This document uses 10pt text in a 16pt line, so is close to 1.5 line spacing.
You also need to consider the spacing between paragraphs. Some people choose to have no extra space between paragraphs, and just indicate the start of a paragraph by indenting the first line.
Pages formatted in this way look very
uniform (especially if the text is fully justified as it is just here)
but may give the impression of being complex and inaccessible. You may
have noticed that in this document we do not use an indent for the
first line of a paragraph, but instead prefer to have an obvious gap
between paragraphs. This alternative use of white space makes it much
easier to see the start of a paragraph. It also breaks up the page so
that it looks much more inviting for the reader.
If you look at the various section headings in this document, you will see that we use different amounts of white space before and after each different level of heading. Section headings (of the form 1.) have a 20pt space before them and a 10pt space after them. The subsection headings (of the form 1.2) have a 10pt space before them and a 5pt space after them, while sub-subsection headings (of the form 1.2.1, though here we have chosen to leave them unnumbered) have a 5pt space before them and a 2pt space after them.
7.5 Writing
As an author, it is your job to ensure that any reader of your dissertation reads it all, and does not give up and stop reading because of irritation or boredom. This means that you must express your thoughts in good English. In this context, good English means being clear, interesting, informative and grammatically correct.
First, your dissertation is a scientific report, so do not write in the first person (that is, "I designed the interface to...", "I tested each component separately"). In general you should write in the passive tense, though use of "we" as in "we have shown that..." or "as we have described..." can also be acceptable, so long as it is not over-used. Here are some examples of acceptable styles:
The initial descriptions of the two methods may lead one to conclude that there is little or even no link between the theories or their use. However, in later chapters, explanation-based learning and completion will be exploited in a new theory which combines important attributes of both methods.
In this paper it is demonstrated that explanation-based completion optimises the completion procedure by completely removing the undirected search that is a feature of standard completion methods
Using this view of EBL, it can be seen to be performing theory reformulation on an existing domain theory, without changing the content of the theory.
In this research we will combine the EBL method with critical pair completion, to enable axiomatic domains of knowledge to be used to learn new knowledge. The general approach has a similar formulation to that taken by Dietterich and Flann (1997), where they combined EBL with reinforcement learning.
We will now examine the EBC paradigm in the context of a particular class of equational theories - those which describe abstract data types. We will then exploit EBC to reuse ADT specifications, by discovering mappings to previously implemented specifications.
Please ensure that you proofread your dissertation very carefully indeed. It is very easy to miss out words, or write a sentence which does not make sense, when you are typing in your work. Some word processors have grammar checkers, but these are nearly always useless, and not worth wasting time on — check the grammar yourself, or get a friend who is good at English to check it for you.
Obviously, you should always use a spelling checker to ensure that your spelling is correct, but spelling checkers cannot pick up missing words, nor can they recognise a mistake where you use the wrong word (for example, using "were" instead of "where"). Again, careful proofreading is needed.
Finally you need to use a dictionary to ensure that the meaning you are attributing to a word is correct. We frequently see this type of error. Here are some actual examples from coursework:
"the conjunction of these two components provides the final solution..."
where "conjunction" should have been "combination".
"The attainment of items on the screen allows the user to..."
where "attainment" should have been "arrangement".
Use of apostrophes
One of the most annoying problems we see in students' documents is incorrect use of apostrophes in words. The two main uses of apostrophes in English are: writing contractions and indicating possession.
Contracted words, such as "can't" for "cannot", "doesn't" for "does not" and "isn't" for "is not", are inappropriate in a scientific document such as a dissertation, so you should not use them.
However, the use of the apostrophe that you will need to get right, is to indicate possession (ownership). Thus we write about "the module's contents", which is "the contents belonging to the module". Similarly, we say "the students' courseworks", which are "the courseworks belonging to all the students".
If you are writing that "the program should match its specification", or that "the need to test software at all stages of its development cannot be over emphasised", you do not need the apostrophe in the "its". (The word "its" only needs an apostrophe if you are using it as the shortened form of "it is". Thus, "it's hot today", and "if it's possible, please may I leave early", are both correct uses of "it's". However, since “it’s” is a contracted word you should not be using it in your dissertation.)
Here are some example sentences showing correct use of apostrophes which indicate ownership:
Prior to this, the programmer had to map all the data structures required by a particular problem solution into the language's available types.
This is really an extension of Guttag's early approach, where, instead of equating all error terms to the same error constant, we now introduce a constant for each type of error.
Readers' experiences of media are many and varied.
Since students can independently pursue their own courses of study, the instructors have more time to pay attention to the students' work.
As a general rule, we never use an apostrophe when writing plural forms. Thus a programming language might provide modules, loops, records and arrays. It is wrong to write "module's", "loop's", "record's" and "array's" if you simply want to indicate more than one module, loop and so on.
The following book provides a very straightforward guide to correct punctuation, and we strongly suggest that you buy and read it:
The Penguin Guide to Punctuation by R L Trask. Paperback, £6.99.
For a more entertaining read, still covering some serious points:
7.6 Using a word processing package
Since your dissertation must be typeset, we would expect all of you to be using a word processing package (probably Microsoft Word) for producing your dissertation. The following points are aimed at Microsoft Word users, but many of them are applicable to any breed of word processor.
1. Keep each chapter of your dissertation in a separate file. Do not put your whole dissertation into one enormous file — if the file gets damaged you will lose everything in one go. If you have your chapters in separate files, and one gets damaged, you will only have lost a small part of your work. Losing your files will not gain you an extension on the dissertation hand-in date.
2. Make a copy of your files every night, when you finish working on them. Just copy them onto floppy disk, date the disk and store it away. Use several disks in rotation, so you can always get back to a slightly earlier version of your work if something drastic goes wrong.
3. If you have a lot of large diagrams in your dissertation, consider "linking" them into your document, rather than actually including them. Diagrams, especially if they are screenshots, can make a file unmanageably large.
3. Use "styles" to maintain consistency of formatting. This document is entirely formatted via Word styles, which we have set up to ensure that our documents have a consistent appearance.
4. Keep the
main versions of your documents on your BUCS filestore. This is
by far the safest place for them, since BUCS backup the filestore most
nights. Having said this, do not just rely on BUCS — you must
take responsibility for keeping backups of your documents on floppy
disks, and on your home PC.
8.
Presentation of your
dissertation
It is very important that you submit your dissertation with the appropriate layout and binding. This section tells you how to do this.
The University offers a binding service. Information about the time required for binding, costs, and further details may be obtained from the University binder: Mr Rob Price, extn 5475
1. Two copies of the thesis must be submitted to Angela (room 1West 2.11) by the submission date of 12 noon, 17th September 2007. Both copies must be "perfect" bound as detailed below. We keep both copies, so if you wish to have your own copy of the thesis then get an extra one printed and bound.
2. You must demonstrate any software you have produced for your dissertation to your supervisor, and provide a copy of your software on CD-ROM or floppy disk, with installation instructions. It is your responsibility to arrange a demonstration of your software.
3. The thesis must be "perfect" bound with a clear acetate front cover.
4. The first
page of each copy of the thesis will read:
FULL TITLE OF THESIS
your name
MSc in Computer Science/MSc in Multimedia Technology, 2007
5. The second
page of each copy of the thesis will be a full title page which will
read:
FULL TITLE OF THESIS
submitted by ....................
for the degree of MSc
of the University of
Bath
COPYRIGHT
Attention is drawn to the fact that copyright of this thesis rests with its author.
This copy of the thesis has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the thesis and no information derived from it may be published without the prior written consent of the author.
Declaration
This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Master of Science in the Department of Computer Science. No portion of the work in this thesis has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author.
[your signature]
See Appendix B for an example of the first and second pages of the thesis.
6. Candidates wishing to include copyright material belonging to others in their theses are advised to check with the copyright owner that they will give consent to the inclusion of any of their material in the thesis. If the material is to be copied other than by photocopying or facsimile then the request should be put to the publisher or the author in accordance with the copyright declaration in the volume concerned. If, however, a facsimile or photocopy will be included, then it is appropriate to write to the publisher alone for consent.
7. The thesis will be printed on one side only of white A4 paper within the range 70g/m2 to 100 g/m2 in a minimum of one-and-a-half line-spacing, with double-spacing being used if necessary. The margin on the binding edge of the page should not be less than 40mm. Other margins should not be less than 15mm.
8. The thesis should be word processed, and the printing should be of sufficiently high quality to ensure that clear photocopying can be obtained.
9. All pages should be numbered, including introductory pages, appendices, reduced copies of computer print-outs, etc. A single sequence of Arabic numerals should be used if possible. This is to facilitate photocopying and binding, so pages may remain in the correct order. (If necessary, roman numerals may be used to number sequential sub-sets of the whole work.)
10. Restrictions of the use of theses by others for the purposes of study should be the exception rather than the rule, and are highly unlikely to be the case for an MSc dissertation. However, if confidential information (e.g., information which is the subject of a patent application) is included in a thesis, some restriction is obviously necessary. If access is to be restricted, permission must be sought through the procedures set out in the appropriate Regulations. A certificate signed by the author and worded as follows will be placed at the foot of the title-page of each copy of the thesis:
(a) If there are no restrictions:
This thesis may be made available for consultation within the University Library and may be photocopied or lent to other libraries for the purposes of consultation.
[Signature]
(b) If there are to be restrictions:
This thesis may not be consulted, photocopied or lent to other libraries without the permission of the author* for .. years [normal maximum three years] from the date of acceptance of the thesis.
[Signature]
*If the author has included in the thesis confidential information obtained from a third party whose interests also require protection and from whom permission for consultation, photocopying or lending is also to be sought, the third party's name will be inserted after 'the author'.
9. Submission of your dissertation
You must submit your completed dissertation project by 12 noon, 17th September 2007, which is the official deadline for submission. Most students find that the final write-up of the dissertation takes much longer than was originally planned.
Submission details will be provided later in a separate document which will also give advice about writing your dissertation.
The 17th September 2007 submission deadline is rigid. Do not ask for an extension of this date - you will be refused. Extensions are only allowed by permission of the Board of Studies for the Faculty of Science. They only consider ill-health and compassionate grounds as reasons for extensions. Being behind schedule, having a hard disk crash, taking a holiday, or having been offered a job, etc, will not be considered as grounds for late submission. Suitable evidence will be required before any extension is granted.
Note: If you are given an extension of registration you will be asked to pay a continuation fee. The continuation fee is currently £460 per year (with supervision and access to the library and BUCS), payable in installments; or £70 per year (without supervision or access to the library or BUCS). You will be asked to pay pro rata for the length of your extension. You will also have to pay a re-registration fee. These fees are set centrally and cannot be waived.
If you have software/hardware problems or supervision problems speak to your supervisor or your Director of Studies. If you are ill or there are compassionate reasons for being delayed then inform both your supervisor and the Director of Studies. You must give the Director of Studies appropriate documentary evidence (such as certificates from your Doctor) that can be brought to the attention of the examiners or the relevant committee. In all cases you will need to fill in a Mitigating Circumstances form and give this to your Director of Studies.
Appendix A Assessment and Progression Regulations
Progression to Semester 2
Progression from Semester 1 to Semester 2 depends on a student passing all the taught units in Semester 1. The unit pass mark is 40%
Should a student fail a maximum of 12 credits worth of units, whilst maintaining an overall average of 40% in Semester 1, progression to Semester 2 will be permitted. A student failing more than 12 credits worth of units at this stage will fail the programme and be required to withdraw from the course.
During Semester 2 the student will
need to pass the reassessment (referral) in the unit(s) failed in
Semester 1. If a student does not pass the reassessment in the failed
unit(s), at a mark of 40% or above, the student will fail the programme
of study and be required to withdraw from the course. Reassessed units
are capped at 40%. The reassessed mark will be used when calculating
averages.
Progression to the Dissertation Stage
Progression from Semester 2 to the Dissertation normally requires that a student achieves an average mark of 50% or above in the aggregate of the Semester 1 and Semester 2 material.
If a student achieves an average mark
of at least 40%, but below 50% in the aggregate of the Semester 1 and
Semester 2 material, the Postgraduate Diploma will normally be awarded.
Dissertation Referral
A student will only be permitted to retrieve a failed dissertation at the discretion of the Board of Examiners and, normally, where the dissertation has obtained a mark of at least 35%. Resubmission of the dissertation should normally be within 12 months of the first submission. A student is allowed only one attempt at retrieval of the dissertation.
A student who fails to submit a
dissertation will not normally be allowed a retrieval, and will only be
considered for the award of the Postgraduate Diploma.
Awards
MSc: A dissertation mark of 40% or above is required for the award of an MSc. An average mark across all the taught units of 70% or above, and a mark of 70% or above for the dissertation would normally qualify the student for the award of an MSc with Distinction.
Postgraduate Diploma:
A mark of 40% or above in the aggregate of the Semester 1 and Semester
2 taught units will qualify a student for the Postgraduate Diploma.
Appendix B Sample First and Second Pages
Sample First Page for MSc in
Computer Science
THE USE OF INHERITANCE IN SOFTWARE DEVELOPMENT
Fred Bloggs
MSc in Computer
Science, 2007
Sample First Page for MSc in
Multimedia Technology
Robot Path Planning
Sally Smythe
MSc in Multimedia
Technology, 2007
Sample Second Page for MSc in
Computer Science and MSc in Multimedia Technology
THE USE OF INHERITANCE
IN SOFTWARE DEVELOPMENT
submitted by Fred
Bloggs
for the degree of MSc
of the University of
Bath
COPYRIGHT
Attention is drawn to the fact that copyright of this thesis rests with its author.
This copy of the
thesis has been supplied on condition that anyone who consults it is
understood to recognise that its copyright rests with its author and
that no quotation from the thesis and no information derived from it
may be published without the prior written consent of the author.
Declaration
This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Master of Science in the Department of Computer Science. No portion of the work in this thesis has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author.