Group projects homepage
27 November (Mon), 1pm
Deadline for registering groups
4 December (Mon), 1pm
Deadline for entering project preferences
Report 1,2,3 deadlines - see CATE
22-24 May 2018
Project Presentations (Timetable)
MSc Computing Science Group Projects run throughout term two and the spring holidays. They 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.
The Group Project is compulsory for everybody in MSc Computing Science and is integrated with the Software Engineering Practice course.
All project reports should be submitted online via CATE. Additionally, for the final report only, 2 hard copies should be submitted to the student office.
Groups will usually consist of 5 or 6 students. 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 noted in these records, and these individual records should be included in the logbook.
Assessment of your project is by 3 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: 15%
- Report Two: 15%
- Final Report, Presentation & Demo: 70%
During the 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 are required to use a version control system (VCS) in your project, and Report One should mention which VCS you are using.
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 (essential vs. non-essential) 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 3 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 to use the provided template that can be found on CATE.
Reports must be submitted via CATE by their deadlines; no extensions will be granted.
Report One: Summary of Requirements
- Should contain the external specification of your project including a proposed schedule (see above for details);
- Should discuss the development approach used;
- Should specify the version-control system used;
- Should be typed in Latex and meet the formatting requirements specified above.
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.
Contents of Report Two
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 3 and 5 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; no extensions will be granted.
Report Two: Summary of Requirements
- Should discuss any updates to your specification;
- Should discuss your testing methodology;
- 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. Do not include your source code in the report, other than possibly in outline fragments for the purpose of illustration (e.g. when you want to explain an algorithm you have used).
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
A brief description of the topic and the problem you are setting out to solve.
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).
This section should provide the overall design of your project. You should justify your main design choices and discuss other options you have considered.
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.
- Group Work
Describe the division of work. This need not be a long story - just a brief statement of who did what. You may mention who has done what as you describe each section of the implementation (in section 3), however it is always a good idea to have a section summarising the division of work.
- Final Product
Description of the final product you have produced, i.e. your overall achievement. What have you implemented? What have you not managed to implement? What were the difficulties: which did you manage to overcome, and how? 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?
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).
The report should be typed in Latex, and the main part (i.e. excluding the appendix) should be around 25 pages with 2cm margins all around, using an 11-point font with normal (single) line spacing. 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. You can find a Latex template on CATE for your final report.
What to Submit and When
You should submit:
- A full copy of the report on CATE; this will count as the official submission.
- An archive with your source code on CATE; the code should be properly documented and contain instructions on how to run it.
- Two hard copies of the report, one full copy (i.e. with appendices) and one copy of the main part of the report only (i.e. no appendices), to the Student Office. Mark them for attention of the Teaching Fellow for MCS.
Presentation and Demonstration
In week 4 of the Summer 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 minutes of questions and another 5 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.