Wiebe van der Hoek: Guidelines for M.Sc. Projects COMP702, 2005

General

These notes offer some specific guidance about the Liverpool Computer Science MSc project scheme. An excellent general book on how to tackle Computer Science projects is:

Christian W. Dawson, "Computing Projects: A Student's Guide", Prentice Hall, 2000.

There are many valuable writing guides, either in book form or on the net, one example is provided by the university of Kansas. There, you can find information on Study Strategies, Writing Your Research, Citing and Documenting Your Sources, Grammar and Usage, and Theses and Dissertations. You are encouraged to also use other sources, but try to be consistent in your approach to your project, and writing your thesis.

Dr I. Biktasheva is responsible for the allocation of projects. For details about this process see her page.

A description of what is required from a project is given here.

Last but not least, being trained to be a computer scientist, it is important and useful to be aware of some general codes of practice, the British Computer Society is an association for professionals in Computer Science that, among many other things, wrote such a guide, that is useful for every practitionar in the field.

Timetable 2005

First of all, note that a deadline for dd/mm/yy means a deadline of 5:00 pm for that day!

The location of all presentations is, unless stated otherwise, the seminar room on the 2nd floor of the Chadwick building.

June 24 - project specification two page summary given to all markers by 5.00pm.

June 29 - presentation of project specification Individual presentation times are here.

July 29 - project design two page summary given to all markers by lunchtime.

Aug 2 - presentation of project design Individual presentation times are here.

Sept 2 - two page summary given to all markers

Sept 7/8 - final presentations. Individual times for presentations will be issued.

Sept 7 - 15. demonstrations. Students make an arrangement with their first marker.

Sept 15, 17:00 - deadline for dissertation submission, which is accompanied with a signed Submission Form

Table with deadlines

Basic Philosophy

The main aim of an MSc dissertation project is for a student to develop and demonstrate autonomy in the management and development of realistic projects in computer science, either research or application oriented. Although new technical skills may be acquired, this is not the main aim of the project. At the end of the project a student should have demonstrated the ability to initiate, plan, manage and deliver a complete project for a customer or research sponsor. The delivery of the project will include giving interim presentations describing important stages of the project, and a final dissertation describing the project as a whole.

Customers / Sponsors

Logbook

Technical Support

Focal Points

Projects will be overseen by project focal points. These will be members of staff allocated for the period of the projects. They will not be allocated to individual students. Normally focal points will only be available at project surgeries. The project focal points will be responsible for providing advice to students on all aspects of the projects, except marking, which will involve the markers. They will be the main point of contact for all students and customers. Focal points for this year are:

• Stephen Phelps, tel. 42075, office 8.03.
• Paul Sant, tel. 47798, office 1.13.

Surgeries

Project surgeries will be run by focal points, normally on at least four days in each week throughout the duration of the project. For each week there will be a duty focal point. The surgeries will consist of fifteen minute slots which can be pre-booked by students, by signing up for an appointment on the form displayed outside the duty focal point's office. The form will indicate any times during the week at which the focal point is not available. Students are asked to give half a working day of notice when making appointments. Students are not in general required to attend surgeries, but the department reserves the right to require attendance if this is thought to be necessary, for example where a problem is detected during one of the assessment stages. Surgeries are for general advice on the management of the project, such as reviewing a project proposal or a design, general technical advice, and advice on the assessment requirements.

To book a slot, use the booking sheet outside the office of the duty focal point. Please book at least one half a working day in advance of the desired appointment. Anyone having problems getting assistance should email the duty focal point for that week, and copy it to Prof. Dr. W. van der Hoek.

Markers

All assessments are done by two markers, except for the final dissertations, which are marked by all staff. The markers for this year are

• Prof. Dr. M. Fischer
• Dr. G. Malcolm

Project Proposals

The deadline date is the latest date for the submission of proposals. Proposals may be submitted, and the project commenced, before this date if possible.

Project proposals will have the following structure. They must not exceed 2 sides of A4 when printed. They must be agreed with the project customer and Dr I. Biktasheva. A copy of the project proposal must be given to Prof. Dr. W. van der Hoek by the deadline date. This copy should contain the signature of the customer to confirm that the customer has agreed the proposal. This is a management document and not a technical document.

• CUSTOMER DETAILS: Who the customer is. Contact name(s). Location.
• BACKGROUND: Brief description of the customer's needs and why the project has arisen. Description of any related activity and computer systems.
• PROJECT OUTLINE: What the project aims to achieve.
• EVALUATION CRITERIA: Key features and characteristics of the solution which are essential to the success of the project, and how you will assess the extent to which they have been achieved.
• RESOURCE PLAN: Equipment, software and other materials necessary to achieve the project. How they are to be provided. Financial costs, such as travel.
• PROJECT PLAN: Anticipated milestones and interim deliverables (that is, output). Schedule of activities. Anticipated reviews with customer and focal points. Final deliverables.
• RISK ASSESSMENT: What obstacles may arise, and contingency plans to meet them. One aspect that should be considered here is the availability of the software and hardware you intend to use, and, if you need to interface several pieces of software, whether this is known to be possible.
• QUALITY ASSURANCE PLAN: How you will monitor progress on your project, and how success at each stage will be assessed. This may include, but should not be confined to, the formal project assessments.

  CUSTOMER'S SIGNATURE: To confirm that the customer has accepted the project proposal.

• Students working on related projects must each submit an individual proposal, and indicate their individual role. Proposals do not contribute to the final mark, but projects may not commence without an acceptable proposal.

Specification

The purpose of this stage is to ensure that there is a clear idea of what the project comprises, and there is a well defined plan showing how the project will be progressed.

Assessment will be by a presentation to the two markers. A report of no more than two sides of A4 when printed must be given to Prof. Dr. W. van der Hoek and the markers by the end of the working day, two working days prior to the presentation. Use slides (OHP or in electronic form: there is a data projecter and connection to the network in the seminar room)i: one copy of these slides must be handed in at the beginning i of the presentation. 15 minutes will be allocated for the presentation, including questions. You are responsible for the time-management of this presentation, and take care that you do not consume more than your allocated slot of 15 minutes. A grade will be given for the project specification, and this will be made available within five days of the presentation. This grade will count for 10% of the final mark. The presentation and report should be structured as follows:

1. PROJECT DESCRIPTION: A statement of what the project is about. This should include:
   • Who the project is being done for;
   • What the problems and needs of the customer are;
   • What the proposed solution is;
   • What will be produced on the project;
   • Any major modifications to the original proposal.
2. CONDUCT OF THE PROJECT: This states how it is proposed the project will be carried out. This should include, as appropriate:
   • Background research: what information will be used to understand the problem and its solution;
   • Data required: what data will be need to be acquired for the project and where it will be obtained;
   • Any new skills that will be required and how these will be acquired;
   • What design methods will be used;
   • What software will be used.
3. STATEMENT OF DELIVERABLES: This states what will be produced in the project. In some cases it may be useful to identify some deliverables as essential and others as desirable. As appropriate this will include:
4. Description of anticipated documentation;
5. Description of anticipated software;
6. Description of anticipated experiments;
7. Description of methods for evaluation of the work.
8. PLAN: A timetabled schedule of project activities and outputs. This should include internal milestones as well as external assessments and reviews. The plan should both state progress to date and indicate future activities.

For your guidance a copy of the feedback form that will be used to assess your presentation is here

Project Design

By this stage of the project students should have completed the preliminary research and analysis required for the project and so have a clear idea of how they will realise their project. Typically this understanding will be recorded in a design using some standard methodology. The purpose of this presentation is to present this design.

Assessment will be by presentation to the two markers. A report of no more than two sides of A4 when printed must be given to Prof. Dr. W. van der Hoek and the markers by noon of four days prior to the presentation. Students may use electronic or OHP slides, and one copy of these slides must be handed in at the beginning of the presentation. 15 minutes will be allocated for the presentation. A grade will be given for the design, and this will be made available within five days of the presentation. This grade will count for 10% of the final mark. The presentation and report should be structured as follows:

• SUMMARY OF PROPOSAL: A brief statement of what the project is about, including any necessary changes to the original proposal or specification, based on new information or understanding. A summary of the research and analysis carried out so far should also be included.
• DESIGN: Outline of the project design, according to method chosen in the specification. Although designs will vary according to the needs of particular projects a typical design of a software implementation will comprise:
  • a description of the anticipated components of the system and how they are to be organised;
  • a description of data structures to be used by the system;
  • algorithms to manipulate these data structures; and
  • a design of the intended interface.

  For example, if following an object oriented design method one might include: use case diagrams; an interaction chart (also known as an event trace); the objects to be used in the system; attributes and methods of objects; pseudo-code for the key methods; interface design.

  If following an SSADM style design one might include: data flow diagrams; entity relationship diagrams; entity life histories; pseudo code for the key processes; interface design.

  For a project involving the empirical investigation of some hypothesis one would normally expect to see things such as: A statement of the hypotheses to be tested; A description of the test data to be used; An experiment design, the experiments to be performed, any control to be used; A description of how the results will be analysed, including any statistical techniques that will be used; Anticipated conclusions; Program designs for any software that needs to be developed to generate the test data or conduct the experiments.

  The important thing is that the presentation clearly shows a design method to have been followed, and that the design has been carried out with sufficient attention to detail to inspire confidence that it can be realised, tested and evaluated in the time remaining for the project.

• REVIEW AGAINST PLAN: progress to date. Necessary changes to plan.

For your guidance a copy of the feedback form that will be used to assess your presentation is here

Demonstration

As well as the ability to give a formal presentation of work, it is important also to be able to handle more informal demonstrations where one talks through the software one has produced. In such a situation flexibility to respond to the person to whom one is demonstrating, and the ability to answer questions is important. Each project must be demonstrated. Each student is expected to approach the first marker (see here) and make an arrangment for the demonstration either in the marker's office or, by default, in one of the available laboratories. If desired, paper materials, such as diagrams, may be used to help explain the project. The demonstration should show the functionality of the working software, and students should be prepared to answer questions about the software, and to show the internal workings of the software (e.g code listings etc). The demonstration will be assessed by the first marker mentioned for each project at this list . A grade will be given which will count for 10% of the final mark, and this will be made available within five days of the demonstration.

Some projects may not result in the production of demonstrable software, either because of the nature of the project, or because the project has been developed on an external platform, or because of problems in the progress of the project. The principle of an informal presentation remains, however, important. In such cases students will be expected to produce a poster which they will use to talk about their project, and we be expected to answer questions and respond to their audience as for a software demonstration. If the project does not lead to the production of software, or if for any other reason the software cannot be demonstrated students may, with permission from a marker, instead produce a poster which they will use to talk about their project. Such permission must be obtained by 6th September.

For your guidance a copy of the feedback form that will be used to assess your demonstration is here

Final Presentation

The final presentation is intended to give an overview of what has been achieved on the project. The student will present the results of the project. One copy of the slides must be handed to the markers before the presentation. A report of no more than two sides of A4 when printed must be given to Prof. Dr. van der Hoek and the markers by noon of the working day prior to the presentation. The presentation will last 15 minutes, including questions. The presentation should give an overview of the all aspects of the project. Normally this will include:

• the aims of the project;
• a summary of the design;
• what was produced on the project;
• any interesting aspects of the implementation;
• a description of what was produced in the project;
• an evaluation of what has been achieved;
• any shortfall from the original proposal;
• suggestions for future development.

The presentation will be assessed by two markers. A grade will be given which will count for 10% of the final mark, and this will be made available within five days of the presentation. For your guidance a copy of the feedback form that will be used to assess your presentation is here

Dissertation

TWO COPIES of a dissertation must be submitted (room 3.12, Chadwick building, Janet Lowry). This will count for 60% of the marks, and it will be marked by two members of staff, who may not have seen the previous presentations. The dissertation must be self contained, and contain a complete record of the work carried out. A target size of 7,000 words is recommended, with a maximum of 10,000 words. Appendices will not be included in the maximum, but examiners will not normally expect to read appendices in detail, so they are intended to supply supporting and illustrative material. The content of the dissertation is at the discretion of the student, and will depend on the nature of the project, but for a typical project involving the development of a piece of software, the following elements of the dissertation would be expected:

• ABSTRACT: a one-page summary of the project as a whole. This MUST be included for all projects.
• INTRODUCTION: This will give a brief overview of the project, who it was done for, what problem it addressed, the solution produced, and the effectiveness of the solution.
• BACKGROUND: reading and research done to acquire the necessary information and skills to carry out the project. A clear statement of the project requirements.
• DESIGN: documentation of the design; while the organisation should be similar to the design presentation, full detail of the design is required. All design documentation should be supplied (possibly as an appendix)
• REALISATION: How the design was implemented. Changes made to the design in the course of implementation. Testing of the implementation. Typically code listings, screen shots, and test runs will appear as appendices.
• EVALUATION: A critical appreciation of the strengths and weakness of the project as carried out. This may include, where appropriate, customer feedback
• LEARNING POINTS: a one page summary of the key learning points in the project.
• BIBLIOGRAPHY: a properly cited list of books, articles and other materials consulted during the project and/or referred to in the dissertation.
• APPENDICES: Appendices are meant to contain detailed material, required for completeness, but which are too detailed to include in the main body of the text. Typically they might contain a full code listing, details of test data, screen shots of sample runs, a user guide, and full design diagrams, and similar material. One Appendix should be a project log, which will list important dates in the projects: including completion of major stages, release of versions of the software, review meetings and other quality assurance activities.

For your guidance a copy of the feedback form that will be used to assess your dissertation is here

Plagiarism

First of all, be aware that you are responsible for what you write. Never use other sources if you don't know what is meant. On the other hand, one of the pilars of progress in research is that authors can benefit from each other's earlier work.

However, it is important to make clear, if you write any paper or thesis, what is your original contribution and what is not. If you cannot make your point more clearly than a source that you have (a book, a paper, or a document found on the web), you can use quotations: put the quoted sentence(s) in between quotes " and ", and make clear in the running text where the reference is taken from. Then, cite that source exhaustively in your bibliography. There are many standards to do citation, one example, the American Psychological Association publication format, taken from the university of Kansas website, can be found here. You can freely use this style, or any other, but make sure that you make your citations in the bibliography in a consistent way.

It does not make sense to quote more than 3 or 4 sentences at one occasion. If your readers really have to literally read another source, you should tell them in your introduction, and say that you assume they have read that source before starting reading your dissertation. Of course, this is not a very smart thing to do: the number of potential interested readers for your thesis will dramatically decrease.

Apart from using somebody else's text, you may also come across figures, pictures and diagrams, about which you think that you cannot illustrate your point better than with them. Again, if you do so (and you have verified that you are not acting against any copyright law), make sure that you state that the picture is taken from a particular source, and give the full details of that source in your bibliography.

Finally, you may want to use other sources in your documentation, although not literally. You want to explain what a java class is, or what the benefits of using a particular tool are. You can then summarise what you found in your favourite documents, but again, make clear what is taken from which source (give the sources in your bibliography) and what is your own original thought or idea.

You can find similar and other rules of good practice in citing at this document, that was downloaded on 4th of July 2004 from this link. Last but not least, the University of Liverpool has written its own statement on plagiarism and collusion. This can be found in section 8 of the Code of practice on Assessment, and you are expected to have read this (see below).

To make sure that you have read these codes of practice regarding quotation, referencing and plagiarism, you have to fill in this and attach it to your dissertation when submitting it.

Assessement

Each of the assessed components will be given a grade along the following lines:

Recovery of Problem Projects

A small number of projects may have difficulties, particularly in the early stages. Appropriate action will be suggested for all projects which score below grade C on any of the assessment stages. Specific actions may be recommended for other projects also.