Imperial College of Science, Technology and Medicine
This page gives general information about group projects, including some general advice and specifications of what you are required to do.
The group project exercise is an opportunity for you to put into practice what you have learned in the first term in a reasonably real-life situation. The role of your supervisor is a customer who has a problem to solve. They know the problem (sometimes not even in great detail, if the project is run the first time) but will pretend not to know much about the technical way of solving the problem. That will be your job. You as a group should think of yourself as a small, young start-up company whose reputation (and hence its likely success) will depend on this first real job you have. You should take advantage of the large resources in equipment and in computer know-how of our department and its staff to find out the best tools and the best technical advisers around which can help you to solve your problem the best possible way.
Our staff have volunteered to supervise a number of projects . However, one or two of these may not run if there is insufficient interest. On the 20th and 27th of November, the projects will be described by their proposers and if selected, probably, the presenters will become the supervisors as well. There will be a selection form posted in a few days' time for you to make your choices.
Project assignments will be e-mailed to you on Monday, the 11th of December, which will allow you to meet as a group and talk to your supervisor before the end of term. To be on the safe side, you should meet by Tuesday the latest and try to arrange a meeting with your supervisor by Wednesday, the 13th. It will be extremely useful for you if you can divide the work among the members of the group before you leave since this will allow you to work independently and gather some information before the start of the new term.
Groups will consist of five or six members. One person will be elected as group leader and another as secretary by the members of the group. The group leader and secretary should have less coding or testing responsibilities than the other members. 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 secretary has to keep a logbook. This 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 secretary is also responsible for integrating documentation (usually provided by all members) into professional looking reports. Each member of the group should keep an individual record of how much time they spent and what they accomplished each week. Actual time spent per week for each member and work carried out should be recorded in the logbook.
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.
The first Report, called REPORT-I 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.
Specifics for 2001:
Some people have asked me whether this report is assessed and how much it will count. The report is not assessed as such. However, this report does play an important part in your final assessment in that your achievements will be measured, and graded, against what you set out to achieve.
I very much hope that all groups will spend much more effort on doing things than on writing about what they are doing. I therefore strongly suggest that this report should be no longer than 5 pages.
This year's reports will be due by 12 noon on Thursday, February 1. In the interest of taking a professional approach to these projects, there will be no extension of this deadline. Reports have to be submitted to the Student General Office, in hardcopy form, 1 report per group. I will collect these reports and distribute them to your supervisors.
Resource requirements will be handled by email.
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-II will be written, which summarises the work you have done during this time and the decisions you have reached.
Contents of Report-II
Update on specification, if necessary. Are you still going to aim to fulfil the functionality specification that you set out to achieve in Report-1? Hopefully, the answer is YES. However, 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.
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?
Technical approach. What techniques are you using to implement the different parts of the project?
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 I think it's useful to
think about them independently.)
Progress. How far have you got?
The main aim of this report is to help you and your supervisor to have a reality-check on how you are progressing. The report will not be assessed as such, but, well done, can easily form the starting point for your final report. I suggest that this report should be about 10 pages long .
This year's reports have to be handed in by 10 a.m., Thursday 1 March . A single hardcopy should be handed in to the Student General Office.
During this period both the following tasks have to be performed:
Final Report
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-I and REPORT-II should be able to provide a substantial part of the contents of the initial sections of your final report.Introduction.
A brief(!) description of the topic and the problem you are
setting out to solve.
Specification.
Specification of the functionality that your project aims to
provide. The contents of this section would normally be
provided by REPORT-I. In addition to that, explain whether
you had to make any changes to the original specification,
and why (This may be taken from REPORT-II.).
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-II.
Group Work.
Division of work - who is doing what? 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-II should already provide this information.)
Final Product
Description of teh 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)? Evaluation: How good is your
product, how well does it perform, how accurately does it
satisfy the specification?
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).
Other Issues:
Length of Report:
After discussing the matter with your course director
Dr. Sadri, I suggest that the main part of your report
(i.e. excluding appendix) should be no longer than 25
pages. Given that you should already have about 10
to 15 pages worth of material from reports 1 and 2, I hope
that will make the task of writing the final report
manageable.
Source code:
I have been asked whether source code should be
submitted. 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).
Important: What to submit and
when
You should submit
Printing etc.
I am sure you have realised bey now that it may be risky to
try to print all 5 copies of your report between 11 and 12
on Monday! Please don't get into that situation. You may use
the machines in Room 439 for spiral-binding if you wish. If
you do that, again please consider that there may be lots of
people trying to use those machines at the last
minute. Also, please take heed of the instructions on the
machines to ask for help if you are not suer how to use
them.
This year's project presentations will be held in the last week of term, on Wednesday March 21 and Thursday March 22, according to the schedule given here.
You will have a total of up to 30 minutes for a presentation and demonstration. Presentation means talking about your project: the problem you solved, how you did it (possibly options you explored), how you worked as a group, what problems you solved and about what your final achievements are. Demonstration means that you give a live illustration of your work. You have 30 minutes' time for both of these together; it is up to you how you divide up the time between presentation and demonstration.
You should be ready to take questions at any time during the presenation and demonstration. Those might be questions of understanding asked whilst you are presenting, or general questions asked at the end. You should allow for a total of at least 5 minutes' of questions, with definitely some of that time right at the end.
Not all members of your group have to participate in the actual presentation. It is quite legitimate that for some group members, preparing a good presentation can be part of their contribution to the project. All members of the group, however, have to be present during the presentations, and need to be able to answer questions. It may be natural that a variety of people will make contributions during that part of your presentation where you may talk about how you worked as a group and about the different components of the final product you produced.
Your presentation should address what the problem was that you set out to address, how you went about solving it, and what your final result(s) is (are). Having said that, try to make your presentation as interesting as possible. This probably means spending more time demonstrating your product or talking about your results than explaining what implementation options that you explored didn't work... Can you illustrate why the results of your project are useful? Interesting? Is there potential for taking this work further?
Your report would have contained a fairly detailed account of the work you did. In the presentation, you have a chance to highlight those issues that you think are best and the strongest "selling points" about your work. Make use of this opportunity. Have a look at the issues that may influence your mark .
The main copy of your report including appendices will be given to your supervisor on Monday 19 March. Schedule permitting, the other copies, consisting of the main part only, will be given to the other supervisors whose projects will be presented in the same session as yours. All supervisors present may have input into the grade you receive.
You will be given one final, overall grade for the project. The following issues will probably influence that grade:
Quality of your final product and technical difficulty of the problem you solved.
How well the group worked together.
Your presentation and demonstration, both contents and how well you present.
Quality of project documentation: Final Report and Log.
It is hoped that the group project exercise will be a satisfying, pleasurable and a learning experience for all of you. It is normal that after completion of a project the group members feel that it could have been done better, which is understandable since the project would be done definitely better if the group could do it a second time. However, it is very rare that anyone has this opportunity. It is highly recommended that you all read the very enjoyable book, The Mythical Man-Month by Frederick Brooks, Jr. (Addison Wesley 1982), which describes a real project for real money (and prestige). You will see that it is not that dissimilar to your own experience even though the project described in the book represents thousands of man/woman-year effort.
In summary, a few things to keep in mind:
Try to negotiate with your supervisor a realistic set of minimum specifications so that your B grade is more-or-less secured.
Take group meetings very seriously. Discuss at these group meetings what each member's task will be for the next period and how the last task was (or was not) accomplished.
Take an interest in all aspects of the project not only in your own part of it. It is obviously to your own advantage to try to help others in your group.
All reports are submitted to SGO and proof of submission (stamp) will be used for determining lateness and penalties. In extremely unusual circumstances waiving of penalties can be applied for to the Project Co-ordinator in writing after the report is submitted. No extension of deadlines in advance will be given.
Keep the project in a reasonable perspective vis-a-vis your other work and courses. Try to do steady work at the start and consistently throughout the ten weeks and then the crunch will not come (hopefully) at the end of the term when there are so many other deadlines.
Originally written by Peter Burger. Modified by
Theodore Hong
Olav Beckmann
MSc (Computing Science) Lab Organisers
Last modified: Wed Jan 15 23:44:22 GMT 2003
Back
to the MSc Conversion Group Projects Home Page