Department of  Computing

MSc Computing Science Group Projects Homepage 2009-2010

MCS Group Projects run throughout term two and give MCS students experience of producing high quality software, often from scratch, in a team. Group projects build on the skills gained in term one but will also involve the acquisition of new skills for most students.

Project Allocation

Supervisors within the department will offer a range of projects which you may be interested in. You will then provide your preferences for projects and groups will be allocated.

The Group Project is compulsory for everybody in

and optional for

Group projects are managed via CATE's Project Portal. Click on the , then on the Admin button, and then on Search the database; this will give you a list of all the projects. The deadline for making your choices will be Friday December 11.

The students in the groups pcs5, pcsa5, pcsai5 and pcsds5 all can pick three projects they would like to do, indicating preference. This will then be used to divide you into groups. If you would prefer to construct your own group of five, that's OK. One of you, from then on the teamleader, has to email the Group Projects administrator all the five names of the people in the group. For all the other students, the groups will be constructed based on your preferences and the possibilities, and a teamleader will be appointed.

For students in the groups pcsba5, pcsvip5, pcscm5, pcss5, and pcsse5, dedicated projects proposals will be put up; these projects will not be open to other students.

Schedule

The 2009-2010 schedule for the Group Projects:

  1. 2nd February: Submission of Report 1
  2. 23rd February: Submission of Report 2
  3. 19th March: Submission of Report 3
  4. Wednesday 24th / Thursday 25th March: Presentations

All submission will take place via Cate; the deadline for each is 4pm (16:00) on the days mentioned above.

Group Organisation

Groups will consist of five or six members. One person can be elected as group leader and another as documentation editor by the members of the group. The group leader decides what route to take when there are different opinions among group members. Also, it is the group leader's responsibility to ensure that group members deliver what is required of them and that they are on time. Normally, the group leader is in charge of the integration process when the various members' contributions are moulded into a single working `product.'

The documentation editor has to keep a logbook and take responsibility for producing and submitting the reports. The logbook contains records of meetings and attendance of members. There should be a record after each group meeting of who agreed to do what and by when. It might also be a good idea to email these agreements to group members after each meeting. The documentation editor is also responsible for integrating documentation (usually provided by all members) into professional looking reports. The logbook should end with a summary giving the contribution to the finished product of the group of each group member, and ideally associating a percent figure with that contribution.

Each member of the group should keep an individual record of how much time they spent and what they accomplished each week. A summary of all programming effort should be given in these records. Actual time spent per week for each member and work carried out should be recorded in these records. These individual records should be ioncluded in the logbook.

Assessment

Assessment of your project is by three reports and a final presentation and demonstration of your software. You will be assessed both on your success as a group and your individual performance.

Report One

During this initial phase the group develops a product specification on the basis of discussions with the supervisor. The group should further try to establish what resources (hardware and software) will be required. It is very important that, with advice from your supervisor, you come to an agreement on what techniques (e.g. which programming languages) you will use to implement the project. The amount of time available means that you may not be able to switch techniques at a later stage. This phase concludes with the writing of your first report.

Contents of Report One

This is a very important document. It is the external specification of the project. This means it should describe what functionality you are setting out to provide with your final product. It is in a way a "contract" between your project supervisor (who will evaluate your work) and you. It should contain clearly stated minimum specifications that you undertake to provide. If your final project meets these minimum specifications, you will in general get at least a B grade. It is therefore very important that you negotiate these minimum specifications with your supervisor in such a way that there is clear understanding on both sides and that you are confident that you can achieve them. Furthermore, this report should also outline your ideas for how you might be able to extend your work to provide /more /than the agreed minimum. Completing such extensions will in general mean that your grade will be better than a B.

Reports have to be submitted via Cate by February 2; no extension will be possible.

Report Two

The best way of using this period is to develop a `fast prototype' of the project which allows you to have an early feasibility-check on the overall integration of your system. During this time different design approaches and technical solutions will be discussed and tested such that by the end of this period the internal design details and technical approaches to solving the main problems become firm. Without knowing at this stage that the different parts of your technical work will definitely be able to `talk' to eachother, you may struggle to get everything to work by the final deadline. At the end of this period, Report Two will be written, which summarises the work you have done during this time and the decisions you have reached.

Report Two is a short report detailing project progress and providing a revised (if necessary) schedule for the remaining period. Relate your progress to the schedule you gave in Report One. You may wish to elaborate on areas that have caused problems and how the group has adapted to solve the problems. If you have revised your specification you should include an update in this report.

Contents of Report Two

  1. Update on specification, if necessary. Discuss if you are you still going to aim to fulfil the functionality specification that you set out to achieve in Report One. If not, what changes have you made? Why? Did some aspects turn out to be technically infeasible? Too ambitious? Can you do more than originally planned.
  2. Design and structure of your product. How have you divided the overall system into different parts? What is the functionality that is provided by each part? Are there any key intellectual problems that need to be solved in the different parts?
  3. Technical approach. What techniques are you using to implement the different parts of the project?
  4. Division of work - who is doing what? (Note that in the actual report, the description of the parts and the techniques used to implement them, and the list of people doing each part might be merged, but it might be useful to think about them independently.)
  5. Progress. How far have you got?

Report Three (the final report)

At the end of week ten or beginning of week 11 you must submit your third report. This detailed document will include your project specfication, discussion of your implementation (technologies, design), your project logbooks and some evaluation.

The contents of both reports one and two can be integrated into Report Three. Your final report should include a specification and details of project management e.g. schedule and progress. We don't expect you to re-invent the wheel so feel free to cannibalise the content you already have.

This section gives some suggestions for how you might structure your final report. The precise structure of your report will obviously also depend on the particular project you did, so the items below are not binding, just suggestions. Note that Report One and Report Two should be able to provide a substantial part of the contents of the initial sections of your final report.

Contents of Report Three

  1. Introduction.
    A brief(!) description of the topic and the problem you are setting out to solve.
  2. Specification.
    Specification of the functionality that your project aims to provide. The contents of this section would normally be provided by Report One. In addition to that, explain whether you had to make any changes to the original specification, and why (this may be taken from Report Two.).
  3. Methodology.
    This section should describe the method you have used for solving the tasks described in your specification. How was the overall task divided into different part-problems? What were the intellectual and/or technical problems that had to be solved? What techniques did you consider using for solving the problem? Which did you choose and why? Note that most of these issues would have been addressed in Report Two.
  4. Group Work.
    Division of work; this is not a long story - just a brief statement of who does what.
    (Note that in the actual report, the description of the parts and the techniques used to implement them, and the list of people doing each part might be merged, also note that your Report Two should already provide this information.)
  5. Final Product.
    Description of the final product you have produced, i.e. your overall achievement. What have you implemented? Anything not implemented? What were the difficulties? Any difficulties you managed to overcome? Any results (this would apply more to investigative projects than to implementation projects)? Testing: how did you test it and what are the results? Evaluation: How good is your product, how well does it perform, how accurately does it satisfy the specification?
  6. Appendix.
    The appendix should contain your logbook, with records of group meetings, who did what, and, if possible, amount of time spent by various group members on their contributions (I realise that the latter might be hard to do precisely).

Length of Report

The main part of your report (i.e. excluding appendix) should be around 25 pages (11 point, spaced normally). Given that you should already have about 10 to 15 pages worth of material from Reports One and Two, the task of writing the final report should be manageable.

Source code

Do not submit printed source code, other than possibly in outline fragments for the purpose of illustrating your report (e.g. when you want to explain an algorithm you have used). You may submit your source code on CD-ROM, or else, you should explain to your supervisor where an electronic version of your project can be accessed (you could either make your project directory accessible, or you could make an archive file and give it to your supervisor).

What to submit and when:

All main submissions will take place via Cate. You should submit

Presentation and Demonstration

In week 11 of term two members of your group will give a presentation about your project and give a demonstration of your software. Your supervisor and second marker will be present as will other groups (and your other group members) that are being assessed in your presentation session. You will be questioned about your software and expected to demonstrate its functionality.

Each group is allocated a 45 minute timeslot. This allows for 30 minutes of presentation, 10 minutes of questions and 5 minutes of turnaround for the next group. You will be expected to attend the entire session in which you group is presenting (after all, everyone deserves an audience).

If you have questions, feel free to mail the Group Projects administrator.

Steffen van Bakel (using previous pages maintained by Peter Burger, Theodore Hong, Olav Beckmann, and Aris Papadopoulos; updated on 21/01/2010)