COMSM0111, Individual Project: Implementation

This web-page outlines the process for 4th year, MEng CS projects under the COMSM0111 unit only; for example, similar but distinct versions exist for 4th year Maths&CS and CSE projects. Also, the associated business plan unit, COMSM0306 has a largely independent process and deadlines. COMSM0111 now spans the first and second teaching blocks (previously it existed in the second teaching block only) but there are still roughly three phases, albeit with a different time-line. In common with other units, it has an online forum which can act as a good place for general questions and discussion.

Phase 1: Specify the project

Your first task is identification of a topic and supervisor. The Departmental handbook does a good job of describing this process from a generic (i.e., not COMSM0111 specific) perspective.

Phase 1.1: Select a supervisor and topic

Our approach is to assume you are able to engage with the staff here without being chased to do it; for example we do not run a "roadshow" in the same way as other units, reasoning that you already have an idea of what the staff do and how to contact them. In addition, you should not assume there is some canonical "menu" of projects to select from: often, members of staff prefer to develop ideas collaboratively with interested students rather than simply list topics. As such, a good approach would be as follows:

Think about an area which you are interested in, and try to identify members of staff (or research groups) who relate to this area. For example, you may have done a related unit or notice that a member of staff lists a particular research interest on their web-site. The research and project idea pages on the Departmental web-site will be helpful, but act as a starting point only.
Make an appointment to talk to members of staff about specific ideas. You should make an effort to do some background research, or think of ideas or areas yourself: engage in a conversation (or negotiation) to refine your combined ideas into a concrete project topic.

Note there is an emphasis placed on forth year projects having a clear and significant scientific or engineering challenge to achieve high marks. That is, it is entirely possible for someone to get a good mark for what one might describe as development (e.g., where the skill is based on understanding and integration of technologies and implementation of a resulting system). However, it is almost always the case that a project that includes some flavour of research (e.g., reading and understanding research level material, potentially coming up with a novel approach or solution to a given problem) will have a higher ceiling.

Phase 1.2: Develop a project specification

Important Dates

04/11/11 (end of week 4) : Project specification deadline. Complete all the fields within the online form by clicking on the current project title opposite your name (that should initially read "None").
07/11/11 and 09/11/11 (week 5): 15 minute(ish) informal interview with Unit Director(s) to discuss project and plan for execution; this goal is to provide feedback on your specification and trouble-shoot potential problems before they impact on what you plan to do. Sign-up via the Doodle poll with your name (or username) and choice of slot.

Once you have an idea and a member of staff who has agreed to supervise the project, translate this into a short project specification:

The motivation part should motivate the project (i.e., what is the problem, what solutions are possible, what would be the impact of a solution, who cares about the problem) and briefly explain any technical detail or areas you already looked at.
The objectives part should outline what you are going to do (e.g., investigate X, design Y, develop Z) in bullet point form and hint at why each point is important, challenging etc.
The plan part should, given the stated objectives, outline how you will spend your time. The idea is to estimate the tasks required and how long they will take; this might help to set priorities and identify potential bottlenecks for example.

You shouldn't view this as needing to be hundreds of words long, nor a "hurdle" just for the sake of it; it isn't marked and can changed as and when appropriate. Rather, thinking about it carefully now will make you more focused for later phases of the project and act as a basis for an informal interview (or progress check) with the Unit Director. For some projects, resource planning is an important part of the plan. Note that:

The unit holds no budget to support resources beyond those in the Department already; if you need equipment, software, licenses or data, it is your supervisor who should help to arrange this.
As a result of new School and Faculty organisation, IT services are now centralised rather than managed within the Department. As such, requests for resource or support should go through the service desk or Syed Rahman, our CS-specific student support officer.

Phase 2: Execute the project

Once the specification phase is complete, you will be work towards the execution of your plan. Regular contact with your supervisor (who will act as your first point of contact) during this period is vital, since they will be able to offer the best advice given their domain-specific knowledge. You can increase the changes of success by planning ahead at each stage; two aspects are particularly important:

Ideally you will have been working on background research and exploratory implementation from the point at which the project was specified. This will be crucial in developing a concrete idea of what you will do and how you will do it: without such a plan, there is a danger the execution phase will become unfocused and "drift".
As you progress, you should attempt to develop a set of working notes that will eventually act as a skeleton for your thesis. Leaving this until the last minute will inevitably mean you forget aspects of what you have done, or do not explain them in enough detail for the marking panel to understand.

Phase 3: Write and present results

Responsibility for the final delivery of your work rests with you. There are two components: a written thesis, and a presentation and demo in front of a (small) marking panel. Although the Departmental handbook does a good job of describing general assessment criteria for projects, it is worth keeping in mind a shorter checklist by which the marking panel will assess what you have done (in a manner appropriate to the project topic):

challenge, i.e., how difficult the project was, for example in intellectual or simply man-hour terms,
contribution, i.e., what you did above and beyond what existed already,
depth and rigour, e.g., were there any unanswered challenges or lines of investigation that should have been completed, or missing references to relevant work or techniques,
novelty and innovation, e.g., how new your approach or results were,
analysis and evaluation, i.e., could you and did you draw robust, interesting and relevant conclusions from what you did,
clarity and quality of presentation, e.g., how well your thesis describes the practical work you did or results you produced.

Your supervisor and the Unit Director will be happy to advise on any matter about which you are unsure. Keep in mind that since COMSM0111 is a level-M unit, the pass mark is 50%, and make sure your aware of the regulations as regards plagiarism outlined in the Faculty handbook.

Phase 3.1: Thesis

Important Dates

18/05/12 (end of week 24) : Thesis and source code deadline. Perform the soft copy hand-in (i.e., PDF file for thesis, TAR or ZIP archive of source code) online; perform the hard copy hand-in (i.e., two bound hard copies of the thesis) via the School office (MVB-2.19). Note that in cases where your soft copy hand-in would be very large (e.g., over 50 MB), make alternative arrangements with the Unit Director. Also note that the office closes at around 17:00, after that your submission is deemed late; there is no "late deadline" with either the soft or hard copy hand-ins.

The main objective of your thesis is to fully describe your project, and the work you have done, so that you get a mark that properly reflects your achievements. It is important to keep in mind that ultimately, the thesis is what is assessed: spending too much time on the project execution and not enough on the thesis is a dangerous tactic! Remember that the person who reads your thesis will not necessarily know what you have done or why, and may not be expert in all the subjects discussed. There are a range of good references on writing style; some examples include

D.E. Knuth, T.L. Larrabee and P.M. Roberts. Mathematical Writing.
W. Strunk Jr. and E.B. White. Elements of Style.

General structure

A typical thesis will be structured according to a number of standard sections described below. However, it is hard to generalise: the aim of outlining this standard structure is not to be prescriptive, but simply to act as a guideline. In particular, the page counts given are important but not absolute: their aim is simply to highlight that a clear, concise description is better than a rambling alternative that makes it hard to separate the important facts from the trivia.

A standard cover and declaration of authorship produced using an online form.
An executive summary of the project. This should help the reader decide what the project is about, why the project was undertaken and whether or not the thesis is one that they want to read ! It should finish with a short list of bullet points (e.g., five or so) that summarise the main contributions and achievements in your project. For example:
- I wrote a total of 5000 lines of software, comprising a Linux device driver for a robot (in C) and a GUI (in Java) that is used to control it.
- I created a new algorithm for computing the non-linear mapping from A-space to B-space using a genetic algorithm, see page 17.
- I implemented a version of the algorithm proposed by Jones and Smith in [6], see page 12, and compared it with several alternatives.
- I spent 120 hours learning the API to the standard Java garbage-collection sub-system.
This ensures that when the marking panel looks at your work, they can be clear about what you have done, how long it took and how it was influence by other material (e.g., the use of libraries or algorithms developed by someone else).

[exactly 1 page]
A detailed contents page giving numbered chapter and section titles as well as any appendices; for some projects a list of acronyms or abbreviations, or overview of notation, can act as a useful reference.

[roughly 1 page]
A section dedicated to describing the context and motivation for the project. The aim of this section is to make three main points. First, what is the project topic, or problem being investigated ? Second, why is the project important ? Put another way, who cares? For example, why there is a need for this project (e.g., a lack of similar software or deficiency in existing software), who will benefit from the project and in what way (e.g., end-users or software developers or researchers), what work your project builds on and why the approach you have selected is interesting. Finally, what is the central challenge involved and why is this significant? Ideally, this section will be at a fairly high-level, and easily understood by a reader who is technically competent but not an expert in the topics itself. It should finish with a short list of bullet points (e.g., five or so) that summarise the main aims and objectives of the project. For example:
- Research and survey literature on public-key cryptography and identify the state of the art in exponentiation algorithms.
- Improve the state of the art algorithm so that it can be used in an effective and flexible way on constrained devices.
- Implement a framework for describing exponentiation algorithms and populate it with suitable examples from the literature on an ARM7 platform.
- Use the framework to perform a study of algorithm performance in terms of time and space, and show the proposed improvements are worthwhile.
[roughly 10 pages]
A section dedicated to describing the technical basis on which the project depends. The aim of this section is to explain the specific problem the project addresses in detail, and the describe previous and related work in the area (e.g., the technical details of alternate solutions or algorithms which you use later on). You might view an additional aim as giving the markers confidence that you are able to absorb and understand research-level material. After reading this section, the reader should have the background required to understand what you have done, and assess how appropriate and novel the work is.

[roughly 20 pages]
A detailed summary, in bullet point form, of any third-party hardware and software components used during the project. For example:
- I used the Java BigInteger class to support my implementation of RSA.
- I used a parts of the OpenCV computer vision library to capture images from a camera, and for various standard operations (e.g., threshold, edge detection).
- I used an FPGA device supplied by the Department, and altered it to support an open-source UART core obtained from http://iloveverilog.com.
Use of such components is perfectly acceptable: the aim of this section is to be clear about where and how they are used. The content can focus on the project topic itself; there is no need for example, to include "I used the LaTeX typesetting system to write my thesis".

[exactly 1 page]
A section dedicated to describing the project execution; normally this means the design and implementation of components which form some solution to the problem presented earlier. However, this is perhaps the hardest sections to generalise. The exact content will depend heavily on the topic; the aim is essentially to convey what you have done, and how it has been evaluated (using whatever means is appropriate). Often it can make sense to split the section in two: one part relating to some activity such as implementation, and one for results or evaluation. For example you might include performance results from software components, and analysis of them which comes to some conclusion. You might discuss any design rationale or decisions made; evidence of "best practice" project management (such as version control, choice of tools or programming language and so on) should only be included if there is a clear reason to discuss them.

[roughly 20 pages]
A section concluding and critically evaluating the project, and outlining any open problems or future plans. The aim of this section is to clearly state the current project status (e.g., X is working, Y is not) and to evaluate what has been achieved with respect to the initial aims and objectives. There is no problem including items which were not complete, as long as there is justification for why.

[roughly 5 pages]

More specific guidelines

The hard copy should be laser printed on A4 size white paper: make every effort to print on both sides of the paper.
For the soft copy (i.e., online hand-in) submission, present a PDF file (not OpenOffice, Word or similar) which you have tested using the version of Acrobat Reader available in the lab.
In either case, the pages should be numbered consecutively; the preferred position for the page number is typed at the bottom centre of the page. The top, bottom and side margins should be not less than 15mm. The text should be single or 1.5 line spaced, ideally using a 10 point serif font.
Lengthy mathematical proofs, sample calculations or length results, user manuals, source code, and other material not central to the work but required for reference may be included appendices to the main text.
All diagrams, graphs, photographs and so on should be called Figures and numbered in sequence as they are referred to in the text.
A list of appropriate references to published work should be included, although it is not usually necessary to repeat more than short extracts from them in the thesis itself. When this is done, the origin must be clearly acknowledged.
References should be numbered. You should list them in one of the standard forms and each reference should be complete, including the names and full initials of all the authors, the title of the book or paper, the publisher and publication date of a book and the journal name, date and first and last pages of a paper. When referring to a particular part in a book or long paper, it is helpful to indicate the specific sections or pages.

Phase 3.2: Presentation and demo

Important Dates

to be decided (within week 26-27, dates pending exam timetable) : Opportunity to test presentation materials and equipment in the presentation rooms.
to be decided (within week 26-27, dates pending exam timetable) : Delivery of presentation and demonstration.

Assessment of your project is focused on the the scientific content, and on the thesis alone. However, to support the marking process you will be expected to give a verbal presentation of your work to the marking panel, give a demonstration of any hardware and software which forms part of the project, and engage in a question and answers session to address specific issues. Your presentation will be allocated a 20 minute slot. Although specific projects might demand a different format, a guideline would be to split this roughly into 10 minutes for the actual presentation, 5 minutes for the demonstration, and 5 minutes for questions.

More specific guidelines

The presentation should focus on and reinforce the main points made in your thesis. For example, the main idea and motivation, why the idea is novel, where the technically challenging areas are, what the major contributions and achievements are and so on.
The demonstration should compliment the presentation and give the marking panel confidence that your ideas and implementation work as described. Some people prefer to include the demonstration within the presentation itself, others leave it until the end. Note that for some projects (e.g., theory-based) , a traditional demonstration will be hard; you need to think about how to replace such a demonstration with something else which serves a similar purpose.
As long as there is good reason, it is sometimes permissible to present a pre-recorded demonstration (i.e., a video) rather than a live one. Examples might include when the demonstration would require a prohibitively long time to complete, or require non-portable equipment, or needs to be performed in a particular setting (e.g., outdoors).
You should be prepared to answer questions during the presentation as well as at the end.
A standard Linux based workstation (i.e., you can login as you would in the lab) will be available in both rooms to display your presentation materials; any other equipment is your responsibility. It will be possible to connect your own laptop to the AV equipment instead of the workstation available.
Opportunity will be given before the presentation day to test your presentation materials (including any internal or external equipment required). Note that you are responsible for checking beforehand that your presentation and demonstration will work; you should not assume there will be time to do this within the allocated 20 minute slot. In particular, make sure your presentation materials are easily accessible via a USB stick, via download using a web-browser or on the Departmental filestore (preferable all three) so you can start as quickly as possible.