Group Projects: MSc in Artificial Intelligence
Wed. 11th November, 2020, 12pm
Wed. 11th November, 2020, afternoon
Project proposals available to view
Mon. 23rd November, 2020, 1pm
Deadline for registering groups
Mon. 30th November, 2020, 1pm
Deadline for project preferences
Report 1, 2 deadlines—see CATE
Mon. 26th April, 2021, 1pm
Deadline for final report
Thurs. 29th, Fri. 30th April, 2021
MSc in Artificial Intelligence Coordinator
Dr Robert Craven
MSc Artificial Intelligence Group Projects run throughout term two and the spring holidays. They give 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 students of the MSc in Artificial Intelligence and is integrated with the Software Engineering Practice module.
The MSc AI Group Project Introduction slides. (The presentation recording is on Panopto.)
Your MSc in Artificial Intelligence group project can be conducted with industrial partners; if it is, supervision will be led by an Imperial academic, but you will meet regularly with the industrial partner, starting in the weeks after your project allocation.
All project reports should be submitted online via CATE. Additionally, for the final report only, one hard copy should be submitted to the student office.
Groups will 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, categorize (e.g., essential vs. non-essential) and prioritize each requirement, assess their feasibility, decide on planned completion dates, and discuss the overall boundaries of your system.
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.
If you are unfamiliar with LaTeX, there is plenty of documentation available on the Internet; a good starting point is The Not So Short Introduction to LaTeX 2e and https://en.wikibooks.org/wiki/LaTeX.
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 quality assurance 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 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 project progress;
- Should discuss quality assurance methodology.
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 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 quality assurance methodology? 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, however it is usually a good idea to have a section summarising the division of work. Note that your Report Two should already provide this information.
- 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 and 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. 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.
- A copy of the final presentation slides, uploaded to CATE.
- An archive with your source code on CATE; the code should be properly documented and contain instructions on how to run it. The size of the archive must be below 100 MB.
Presentation and Demonstration
In 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 who 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.