Project and dissertation
To obtain either of the MSc awards available from the Programme, a student must complete an extended project. This differs from the module assignments—each of which contains an element of project work—in two important ways:
- it affords an opportunity for the student to formulate their own problem or challenge;
- it may involve the application and integration of ideas taught in more than one module, or drawn from the wider software engineering curriculum
This is a taught programme, and although the project needs to be an original demonstration of ability and understanding, there is no requirement to advance the state of the art in the field. Students need only choose and apply an appropriate selection of existing ideas and techniques—provided that their choice, the process of application, and any outcomes are properly explained. New ideas and techniques are welcome—and we've seen several over the years—but they are not expected.
The project component involves compulsory attendance at a project module in Oxford, at which students present and refine their proposal, and attend teaching sessions on: research skills; engineering in context; and social, legal and ethical issues. Six weeks later, they submit their proposal for formal approval.
- The student develops an idea for a project, discusses this idea with their supervisor, and books a place on a project week.
- The project week affords an opportunity for the student to start work in earnest, to attend teaching sessions and workshops, and to have one-to-one meetings with their supervisor.
- Six weeks later, the student submits their proposal for formal review. If this is approved, they may continue. If not, then they will need to revise the proposal, and submit it for assessment after the next project week.
- The student provides their supervisor with further reports on progress as they complete the project and start to work on the dissertation.
- The student prepares a final version of the dissertation, and submits it as soon as they are ready—which should be before the submission deadline pertaining to their current final term of study.
The project and dissertation should represent the same amount of effort, and achievement, as two taught modules, complete with assignments: that is, two weeks full-time—the equivalent of two teaching weeks—plus 18 weeks part-time—the equivalent of two pre-study and two assignment periods. This work is usually undertaken over a period of one year.
The dissertation should be between 45 and 60 pages in length, excluding appendices and illustrations; there is a nominal word limit of 20,000. There is no need to submit the complete source code, or detailed output, for programs; nor is it necessary to submit complete sets of design documentation. The dissertation should present the key aspects of the project work, a distillation of the results, and a suitable analysis.
Normally, candidates for the MSc will start work on their project after attending most, if not all, of their taught modules.
The Programme Office maintains a small library of past dissertations for students to browse through, in order to get an idea about subject matter and extent. An abstract of every past dissertation is stored on the Programme's administrative database.
Students may choose any topic that will allow them to demonstrate understanding of software engineering through the medium of a dissertation. The best way of doing this is usually to choose a topic related to one or more of the subjects taught on the Programme. Many students choose topics that are related to their current employment, allowing them to see how the ideas taught in the Programme may be applied alongside current practice.
There are three broad categories:
—involving the application of software engineering techniques to the specification, analysis, design, development, or testing of a particular product. This product could be entirely fictitious, it could exist only as a part of another system, it could be hardware or software, but it must afford an opportunity to apply software engineering techniques.
Any technique or combination of techniques could be applied to—or around—this product. There might be a study of requirements, a security analysis, one or more specifications, some design work, some analysis, some programming, or some testing.
Examples include: an object-oriented design and implementation, with some accompanying analysis; the formal specification of a software component; a case study in requirements engineering.
—involving the extension of a particular technique, or a combination of techniques, for use with a particular class of application. Examples include: a technique for conducting hazard analysis using a process algebra; a customised profile for UML; a set of parametrised process constructs for writing test cases with CSP.
—involving an examination or assessment of particular techniques, their development and application, in academia or in industry. If no application is involved, the resulting dissertation must contain enough original insight, analysis, or critical reflection to demonstrate the student's own understanding.
Examples include: a description and critical analysis of the software testing process for a particular product line; an analysis of a software standard, with proposals for change, based on ideas from the Programme.
Most projects fall into the first category, but there have been many successful projects that are either theory- or process-based. Each type of project has its own advantages: the development or description of a particular product might make it easier to define goals, or to measure progress; a theory-based project is unlikely to suffer from implementation problems; a study of process might result in immediate improvements to the working environment.
The work starts with a project proposal containing:
- a description of the subject matter: product, theory, application area, or problem domain;
- a brief account of the original contribution that the project work might be expected to make;
- a plan, or outline, of the dissertation, explaining how it will demonstrate the student's understanding;
- a list of resources that will be required.
- a suggested schedule of tasks and delivery dates; and
- an outline of any social, legal, or ethical issues relating to the work.
This should be prepared in consultation with the student's supervisor, and submitted to the Programme Office together with a completed project start form. Depending on the project topic, a change of supervisor may be appropriate, if there is another member of staff available with particular expertise in the area of proposed study.
While working on their project and dissertation, the student should take care to keep their supervisor informed of progress. The primary mode of communication will be email. As the work progresses, there might be considerable variation from the original proposal: any drastic change may require approval.
The results of the project work are presented in a short dissertation, of 15,000-20,000 words, or 45-60 pages. This forms the basis for formal assessment of the project, just as the written assignments form the basis for assessment of the taught modules. The dissertation can be submitted at any time during the allowed period of study, although it is usually the last piece of work a student submits before being examined.
The main matter of the dissertation will contain between three and eight sections, beginning with an introduction and ending with a discussion. The front matter is what comes beforehand: the cover page, the abstract, the table of contents. The back matter is what comes afterwards: the bibliography, and any appendices.
The student's name, and the name of their college, should appear on the cover of the dissertation, along with the title and the year of submission; the name of any employing organisation may also be included. There should be something to indicate that this is a submission for the Master of Science in Software Engineering: the words MSc in Software Engineering will suffice, although the full form is
A dissertation submitted in partial fulfilment of the requirements for the degree of Master of Science in Software Engineering
The second page should include an abstract of between 100 and 200 words: this should be written in the passive voice, even if the remainder of the dissertation is written in the first person (singular or plural). Furthermore, the abstract should avoid mention of any company-specific or confidential information, even if the dissertation is to be the subject of a confidentiality agreement (because the abstract will be made available even if the dissertation as a whole is not).
At this point, the student may wish to include a dedication and acknowledgements. They must include a written declaration:
The author confirms that: this dissertation does not contain material previously submitted for another degree or academic award; and the work presented here is the author's own, except where otherwise stated.
This declaration should be on the exam entry form The declaration need not be part of the dissertation itself: it could be submitted on a separate sheet of paper.
It is quite acceptable to include sections of text written by another person, but in every case the author should be clearly identified. Plagiarism—presenting someone else's work as if it were your own—is a very serious matter. See Acknowledgement of Sources for a more detailed account of how to quote the words of others and Examination Conventions for the policy on plagiarism.
If the dissertation contains material of a commercially-sensitive nature then this should be clearly stated on the first or second page.
The last part of the front matter is the table of contents, which should list the name of each top-level or second-level section, together with the number of the page where it starts. There is no need to include third- or fourth-level sections in the table of contents.
The main matter of the dissertation should be divided into either chapters or sections, with lower levels of sectioning as necessary. In a document of this length, more than two levels of numbered sectioning is likely to inhibit readability. The following is a generic structure describing how a dissertation might be organised:
Introduction (2-5 pages)
The first section should do three things: introduce the subject matter: explaining the motivation for the project, and saying something about the background area; describe the contribution made by the dissertation: the results of the project, the impact or value of the work; provide an outline of the dissertation, explaining how this contribution is realised in the subsequent sections.
This section may be only a page or two in length, but it is the most important part of the dissertation. It will shape the expectations of the reader, and provide them with a guide to the rest of the work.
Application area (4-10 pages)
In most cases, there will be a second section that describes the context of the work: the application area, the problem domain, or the theory that is to be extended or analysed. In other cases, if this description is only a couple of pages long, it could be made part of the Introduction.
This description should be limited to the context, not the work itself. If the project involves the creation of a model for a software product, then this section should describe the product, but not the model. If the project is theory-based, this description should describe the existing theory, but not the proposed extensions.
As with the Introduction, this section will shape the reader's expectations. It should provide enough information about the context to allow the reader to assess the contribution made. It should mention only those aspects or features that are relevant to the subsequent sections, emphasising those that are particularly relevant.
Project work (25-50 pages)
We have now reached the heart of the dissertation: one or more sections presenting the results of the project work:
If the project is product-based, there might be sections on requirements capture and analysis, specification, design, implementation, or testing. There is no need to address all of these areas. A dissertation might present three different specifications of a simple product or component, and a subsequent implementation, in four successive sections: State-based Specification (10 pages); Behavioural Specification (10 pages); UML Model (10 pages); Java Implementation (10 pages).
Here, a commentary might be expected: something that compares and contrasts the different specifications, and explains how they might be used to validate, or even generate, the implementation. However, it would not then be necessary to include an account of testing strategies or requirements analysis, nor a detailed analysis of the consequences of the design decisions associated with the specifications and implementation.
Alternatively, a dissertation might present a single specification, with a formal or rigorous account of properties and perhaps their verification. If the specification and the properties are sufficiently complex or novel, this might comprise the whole of the project work. Alternatively, there might be another section describing a prototype or implementation. Thus we might see: Formal Specification (20 pages); Analysis (8 pages); Prototype (8 pages).Finally, there might be two models, each of which has its own analysis and implementation, repeating this structure one more time.
If the project is theory-based then this part of the dissertation could be broken in sections describing different aspects of the overall achievement.
For example, a dissertation that describes a simple extension (or application) of the theory of CSP to testing activity might, after a section that reviews the CSP language, present the project work as: Test Purposes and Test Cases (12 pages); Testing Processes (8 pages); Case Study (20 pages). Two of these might describe the extensions, the third an example of their use.
The same applies to projects that are process-based: this part of the dissertation could be broken into sections describing different issues addressed. For example, a dissertation that contains a critical analysis of a particular company's development process might, after a section that describes that process, present the work as: Requirements Engineering (12 pages); Development Management (10 pages); Testing Strategy (10 pages); Proposals for Change (12 pages).
Discussion (3-6 pages)
The preceding sections should contain a certain amount of reflection and analysis. However, anything particularly insightful should be repeated here, and discussed in as much detail as seems appropriate.
In most dissertations, the discussion section will be one or two pages. However, it may be that the student has learnt or achieved a great deal that is not immediately apparent from the preceding chapters. If that is the case, then a deeper discussion may be necessary.
If the specification now seems inadequate, or the implementation has been unsuccessful, the student could use an extended discussion to explain exactly what the problems are, and to suggest how things might be remedied. This could be as informative, and rewarding, as a reworked project: it might also be the only way to produce a satisfactory dissertation in the time available.
The discussion might also complement the introduction by relating the results of the project work back to the original context, suggesting further work or comparing the student's work with that of others.
The page counts shown above are simply for guidance. Like the numbering of sections, or the proportion of illustrations, or the amount of code displayed, they will vary quite widely from dissertation to dissertation.
The back matter should begin with a bibliography, or a list of references. In a product-based project, this might take up half a page; in a theory- or process-based project, it might be longer. Either way, it is essential: it provides a way for the reader to learn more about the context of the work.
Many dissertations have an appendix of some sort. This may contain excerpts from the code of an implementation, or screenshots of an application in use, or a mathematical proof supporting the conclusions of a specification or analysis section. Any appendix will be excluded when the formal extent of the dissertation is measured; however, you should note that an over-long appendix might be ignored by the Examiners.
The best way of writing a good dissertation is to produce a succession of drafts, concentrating first upon the central sections, and then upon the introduction and conclusion. This should minimise the risk of producing large amounts of text, detailed accounts or polished explanations, that may not be required in the final version.
The successive drafts will allow the project tutor to measure progress and provide advice. Furthermore, if the work can not been completed as originally intended, a reasonable draft of a whole dissertation is better than a detailed draft of two sections: it is more likely to serve as the basis for a suitable submission.
It is important to remember that the final content of one section may depend upon that of subsequent sections. For example, a section that introduces a software product need mention only those features that are modelled or analysed later in the dissertation.
Presentation and submission
Although any editor or word-processing package could be used to produce the dissertation, students are advised to make their choice with care. Some tools that appear ideal for short letters and reports may prove cumbersome or otherwise unsatisfactory when dealing with large, technical documents. The effort involved in learning a new system—such as LaTeX—may be repaid many times over. There is no need for doublespaced text: the default line spacing used by most packages is perfectly adequate.
The dissertation should be printed using one side of each sheet of paper. There is no fixed format or document template, and either A4 or letter paper is acceptable. As a rough guide, you should expect to find no more than 10 or 12 words per line, and no more than 40-50 lines per page. Each page, apart from the cover, should be numbered. It may also be appropriate to add a header to each page, identifying the current top-level section. The dissertation should be securely bound in such a manner as will facilitate reading and assessment: comb, spiral, wire, and thermal bindings are all acceptable; paperclips, ring-binding, and slide-binding are not.
Two copies of the printed dissertation should be sent to the Programme Office, in a package marked "for the attention of the Programme Manager", to arrive before the end of the student's final term of registration.
If a student wishes to use software with an education license, the Programme Manager will be happy to provide confirmation of student status should this prove necessary. The wide variety of subject matter, and the fact that the project work may be closely related to the student's (or their employer's) business, makes it impractical for the Programme to provide resources to support the project work. However, Oxford University Computing Services can provide licenses for some software products.
Many students choose a product-based project in which they will construct a model of a product or component that they have already encountered, or developed, as part of their employment. Alternatively, they may choose a process-based project in which they analyse existing practices within their organisation.
The results of these projects will usually be commercially sensitive: they may describe design features, or aspects of the development process, that the student's employer would wish to keep secret. To make such projects possible—their educational value is considerable—programme staff undertake to respect the confidential nature of each student's work.
A written confidentiality, or non-disclosure, agreement can be established between the University and the student (or their employer). The Programme Manager has a template for this agreement, and is the first point of contact for any student requiring reassurance. However, the University cannot accept financial liability for breaches of confidentiality.
The University claims no rights to commercial exploitation of work submitted by students on the Programme. However, it does claim a licence to use whatever is submitted for assessment for non-commercial, academic purposes. This is to avoid any risk of an individual constraining future research and teaching in the University by arguing—with or without merit—that it is based upon their assignment submission.