Department of  Computing

MSc Computing Science Group Projects Homepage 2011-2012

MSc Group Projects run throughout term two and give MSc 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.

The Group Project is compulsory for everybody in

MSc Group Projects are integrated with the following courses:

The MSc group projects are coordinated by Dr. Cristian Cadar and Reuben Rowe. Please send any queries at c.cadar and reuben.rowe07 at imperial ac uk.

Project Allocation

Supervisors within the department will offer a range of projects in which you may be interested. Some projects are offered to all MSc students, while others only to specific degrees.

Group projects are managed via CATE's Project Portal. To see the list of available projects, log into CATE, then click on the Projects button, then on Admin, and finally on Search the database.

There are two main steps in the allocation process:

  1. Students form groups and elect leaders: You will first need to form a group of five or six people. All people in a group should belong to the same degree. Groups will need to elect a group leader. Once this is done you will need to register your group in CATE using the following three steps:
    1. The group leader should log into CATE and sign in to form a group.
    2. The group leader should add all group members to the newly formed group.
    3. Each member should log into CATE and sign into the group.
    Note that we reserve the right to add people to your groups, and under extreme circumstances to reorganize groups.
  2. Groups select projects: In the second step, groups should select and rank five projects. Group preferences are entered into CATE by group leaders. The other group members do not need to do anything in CATE at this step.

You can access the slides used during the 2011/2012 presentation here.

Schedule

The 2011-2012 schedule for the MSc Group Projects:

Group Organisation

One person in each group will be elected as group leader. 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 (e.g., submit the reports) 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 group will also elect a documentation editor. The documentation editor has to keep a logbook containing the 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 each group member.

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. The marks are broken down as follows:

Report One

During this initial phase the group develops a product specification on the basis of discussions with the supervisor, and decides on the development approach that will be used to conduct their project. The group should 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.

Note that you have to use a version control system (VCS) in your project, and Report One should mention what VCS you are using. There will be a lecture on VCSs in the associate Software Engineering course.

Contents of Report One

This is a very important document, which includes 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.

The report should clearly identify the requirements of the project using goal oriented-capture, categorize and prioritize each requirement, assess their feasibility, decide on planned completion dates, and discuss the overall boundaries of your system. A lecture on capturing requirements will be given in the associated Software Engineering course before this report is due, which will provide more details on all these aspects.

Furthermore, the report should identify the development strategy chosen by your group (e.g., Scrum, XP programming) and how you are using it in the context of your project. You should include here information about the division of work.

Report One should be between 2 and 5 pages using an 11-point font size, with 2cm margins all around, and spaced normally. You are required to use Latex to type your reports. We recommend you to use this template for your reports.

If you are unfamiliar with Latex, there is plenty of documentation available on the Internet; a good starting point is http://www.latex-project.org/.

Reports must be submitted via CATE by the deadline mentioned above; no extensions will be granted.

Report One: Summary of Requirements

  1. Should contain the external specification of your project including a proposed schedule (see above for details);
  2. Should discuss the development approach used;
  3. Should specify the version-control system used;
  4. Should be typed in Latex and meet the formatting requirements specified above.

Report Two

By the time of this second report, you should already have produced at least one `prototype' of the project to provide you with an early feasibility-check on the overall integration of your system. During the time between your first and second reports different design approaches and technical solutions would have been 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 interact with each other, you may struggle to get everything to work by the final deadline.

Report Two should discuss your project progress and your overall testing strategy. Relate your progress to the schedule you gave in Report One, and if necessary, provide a revised schedule for the remaining period. 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.

Report Two should also discuss your testing strategy. Several lectures on the topic will be given in the Software Engineering course before this report is due.

You are required to use a coverage measurement tool and report the statement and branch coverage achieved in your code by your current test suite. You should write a summary of your coverage results in the actual report, and include more detailed information (e.g., screenshots produced by the coverage tool) in the appendix. You should ignore any third-party library code from your report. We expect your overall coverage numbers to be above 60% (but hopefully much higher). If it is the case, you should clearly justify why the coverage of certain modules is low and discuss the steps you plan to take to improve it.

Report Two should be between 2 and 4 pages (excluding the appendix) using an 11-point font size, with 2cm margins all around, and spaced normally. You are required to use Latex to type your reports.

Reports must be submitted via CATE by the deadline mentioned above; no extensions will be granted.

Report Two: Summary of Requirements

  1. Should discuss any updates to your specification;
  2. Should discuss your testing methodology;
  3. Should include the coverage achieved by your current test suite (see above for details).

Final Report (Report Three)

This detailed document will include your project specification, discussion of your implementation (technologies, design), your project logbooks and evaluation.

The contents of both Reports One and Two can be integrated into the Final Report. Your final report should include a specification and details of project management, e.g. schedule and progress.

This section gives some suggestions for how you might structure your final report. The precise structure of your report will obviously depend on the particular project, 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 requirements, and why (this may be taken from Report Two.).
  3. Design. This section should provide the overall design of your project. You should justify your main design choices and discuss other options you have considered.
  4. 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 sub-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? What software development techniques have you used to conduct your project? What was your testing methodology, and what coverage is achieved by your current regression suite? Note that some of these issues would have been addressed in Report Two.
  5. Group Work.
    Division of work; this is not a long story - just a brief statement of who did 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 One should already provide this information.)
  6. 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 novel results (this would apply more to investigative projects than to implementation projects)? Evaluation: How good is your product, how well does it perform, how accurately does it satisfy the specification?
  7. 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 (we realize that the latter might be hard to do precisely).

Length of Report and Formatting

The main part of your report (i.e., excluding the appendix) should be around 25 pages with 2cm margins all around, using an 11-point font and spaced normally. The reports should be typed in Latex and meet the formatting requirements specified above.

Source code

You should submit an archive with your source code via CATE. The code should be properly documented and contain instructions on how to run it. 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).

What to submit and when:

You should submit:

Presentation and Demonstration

In week 11 of term your group will give a presentation on your project which should include a demonstration of your software. Your supervisor 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 30 minute timeslot. This allows for 20 minutes of presentation, 5-10 minutes of questions and a few minutes of turnaround time for the next group. Not everyone in the group has to present, but everyone should be prepared to answer questions. You can use any equipment available in the room, but it's your responsibility to make sure in advance that everything is working fine, and that the setup time is kept to a minimum.

You will be expected to attend the entire session in which your group is presenting (after all, everyone deserves an audience). If you are the first group in a session, please arrive at least 10 minutes before the start time of your presentation.

The presentation schedule is available on CATE.

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

Site maintained by C. Cadar, based on previous pages by S. van Bakel, P. Burger, T. Hong, O. Beckmann, and A. Papadopoulos. Last updated: 05/01/2012.