Group Projects

This page contains links to information specific to the Group Projects taken by all Third Year Computing and JMC undergraduates, as well as MSc in Computing (Software Engineering) students

Quick links

Group Projects (3rd Yr/MSc in Computing (Software Eng.))

Introduction and Overview

The Group Project will be a unique experience in your student career because it will give you a glimpse of what the 'professional world' is really like. Normally, professionals work in groups, have tight deadlines and have to be able to communicate and co-operate with other people. The performance of a group does not depend simply on the sum of the abilities of the individuals within it. Careful planning, frequent constructive meetings, goodwill and co-operation are needed to make a group successful.

Important elements of the exercise include:

  • If you fail the group project, then you fail to gain professional accreditation for your degree. Also, if you are an MEng Computing student you will be required to change to the BEng programme. For the MSc in Computing (Software Engineering), if you fail your Group Project, then you fail the module and hence the degree.
  • You must keep to the Schedule. In particular:
    • As for many projects in industry and commerce, time is short. Do not delay any tasks or you will soon run out of time.
    • Take group meetings (a minimum of two per week) very seriously. Use these meetings to agree what each member's tasks will be for the next period and how previous tasks were (or were not) accomplished.
    • Keep in contact with your supervisor, with regular meetings (probably once per week).
    • It is essential that by the time that you hit early November, the group clearly understand what is to be done and who does what in the first time-boxed iteration of your software development. You should negotiate with your supervisor a realistic set of minimum deliverable features or functionality for this first iteration.
    • For the remainder of the project, careful project management and planning that embraces change should be used. Goals and task assignments should be made clear to all group members. You should plan for backup in case somebody falls ill or other unforeseeable problems occur.
    • Deadlines are firm. In extremely unusual circumstances, waiving of penalties can be applied for to the Group Project Coordinator in writing after the report is submitted. No extension of deadlines in advance will be allowed. All reports are submitted electronically and proof of submission will be used for determining lateness and penalties.
  • It is better to have a simpler project that works and can be demonstrated satisfactorily, rather than a more complex one which does not allow either of these things.
  • Supervisors consider your final package as the achievement of the whole group. A group may have some members who are more productive than others. It is the group's responsibility to deal with such differences, and potential lack of contribution and effort from an individual. Should the group be unable to resolve such issues, they should inform their supervisor PRIOR to completion of the project. Only in exceptional circumstances will group members be given different marks.
  • You are expected to spend the equivalent of one day per week for your group project. At critical times this will not seem enough. However, you should not neglect your lectures, tutorials, and assessed course work. Careful planning and steady work (especially during the early phases) will not put unreasonable demands on you at the final phases.
  • Take an interest in all aspects of the project, not just your own part of it. It is obviously to your own advantage to try to help others in your group. You should consider having deputies to cover for each assigned role/task in the group.
  • You should back up your work regularly, and use some form of version control system to avoid potential disasters.

Organisation

The group as a whole should take an interest and responsibility in the success of each of its members' activities. Group members should be aware of, and take responsibility for, the overall development process within the group, of the needs arising from integration, testing, and keeping abreast with deadlines.

Sometimes groups cannot easily reach consensus on design or organisational matters. In such cases, the group might elect a leader, with the remit to help the group come to a decision.

The group should also keep a log-book, for records of the meetings and attendance of members and 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 log-book.

Submissions

Final Reportdue: 11th Jan 2016, at 16:00

Contents for Final Report: The project report should not be longer than 35 pages (recommended length is around 30 pages), and might be organised according to the following structure:

  • A. Executive Summary
    • Your 'elevator pitch'
    • What is your Project? What does it do? Why would I want to buy it? etc.
    • No implementation, software engineering details, or project management
  • B. Introduction
    • Set the scene ('motivation')
    • State the problem you are trying to solve ('objective(s)')
    • Summarise your main achievements
  • C. Project management
    • Planning, group organisation, breakdown + task allocation etc.
  • D. Design and implementation
    • Detail your design (why did you do it this way?) - design of your software, possibly including a diagram of the major components
    • Summarise key implementation details (how did you do it? what technology was used and why? what other technology was considered, but not used and why?
    • Any technical challenges encountered and how addressed?
    • Any risks anticipated, and how mitigated
  • E. Evaluation
    • Evaluate your deliverables e.g. performance, usability, etc.
    • Summarise testing procedures (+ relevant testing results)
  • F. Conclusion and future extensions
    • What did you learn? What might you have done differently?
    • How would you build on what you have done?
  • F. Bibliography
  • H. Appendix The appendix is optional, and does not count towards the 35 pages. It may contain thing like: User guide, installation instructions; more extensive design, testing, statistics etc.

Make sure that the final report presents a coherent story. Ask advice from your supervisor. You might also draw inspiration from the instructions about writing up your individual project.

Bear in mind, that most of the project assessors will not have followed the project throughout and will only have a short time to listen to a presentation or see a demonstration. For this reason they will rely heavily on the report to judge the project.

The report should be submitted electronically through CATE. i.e. report.pdf.

 

Final Submissiondue: 20th Jan 2016, at 17:00

All the code and documents produced for/used by the project - including the Final Report and any Presentation slides - must also be submitted electronically as a single archive (zip or tgz) via CATE. i.e. project.zip or project.tgz.

 

Assessment

Group project

The group project assessment is undertaken by each group's supervisor, and moderated by a larger group of assessors, who will attend your presentation, and/or read your final report. The assessment is based on:

  • Executive Summary, 5%
  • Presentation, 10%
  • Group Collaboration and Management, 20%
  • Report, 30%
  • Technical Difficulty and Achievement , 35%

The group project (along with the Software Engineering course) is worth 440 Marks for both the MEng and BEng students.

Overall assessment

The overall assessment is the sum of the group project component and the Software Engineering Course in an 80:20 split.

Recommended Reading

Agile Estimating and Planning by M. Cohn. (Prentice Hall, Professional Teaching Reference, Pearson Education; 2006) is, quoting from its cover, "the definite, practical guide to estimating and planning agile projects ... shows you exactly how to get the job done, with real-world examples and case studies."

The Mythical Man-Month by F. P. Brooks Jr. (Addison Wesley, 1995) 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.

More reading material will be recommended during the Software Engineering Course.

Schedule

Note: All submissions must be to the Student Administrative Office using CATE by the date and time stated. All times use the 24-hour clock, '12.00' means midday.

2015/2016 Schedule

Date & Time

Activity

7th Oct 2015

11.00

308

Introductory Talk (Third Year Students)

7th Oct 2015

12.45

145

Introductory Talk (MSc in Computing (Software Engineering) Students)

8th Oct 2015

17.00

Submission of team membership on CATE

9th Oct 2015

18.00

Submission of teams' project choices via CATE

12th Oct 2015

17:00, or earlier

CATE will be updated with the project allocations.

23rd Oct 2015

12.00

CSG

Submission of the details of any special Project Resources requirements to CSG

13th Nov 2015

17.00

Deadline for initial WebPA peer assessment submission.

Week 9

Completion of project implementation/integration/testing.

By now, the project should ideally be complete and to specification. There will be very little time for any further tuning or minor modifications and trying to do any could jeopardise the integrity of the package demonstration to follow as well as your performance in exams since Week 10 is Revision week.

Any remaining time should be spent completing the Final Report and preparing the presentation and demonstration.

11th Jan 2016

12.00

Submission of Final Report electronically through CATE.

11th Jan 2016

14.00 - 16.00

144

Talk on Group Project Presentation Skills.

After this talk we'll have a few volunteer groups presenting and give feedback to them, which will help you refine your presentations.

12th Jan 2016

18.00

Deadline for final WebPA peer assessment submission.

12th Jan 2016

10:00-13:00, in 311

Mock presentations and feedback

13th Jan 2016

<dd>10:00-13:00,</dd><dd> or </dd><dd> 15:00-18:00</dd>

Mock presentations and feedback - part 2

13th Jan 2016

11:00-13:00,

145

Group Project Presentations - 540

25 minute examination of the project, which should comprise about 10 minutes of presentation (with video projector) and 10 minutes demonstration of your software, and leave some room for questions. You are free to mix the presentation and demonstration in any manner which shows off your efforts to their best advantage.

Attendees: The group, the supervisors, and the moderators. Also, any interested students or other people.

14th —15th Jan 2016

145

Group Project Presentations - 362

25 minute examination of the project, which should comprise about 10 minutes of presentation (with video projector) and 10 minutes demonstration of your software, and leave some room for questions. You are free to mix the presentation and demonstration in any manner which shows off your efforts to their best advantage.

Attendees: The group, the supervisors, and the moderators. Also, any interested students or other people. <b>Timetable</b> can be found <a href=https://cate.doc.ic.ac.uk/projects/allocations.cgi?key=2012:1>here</a>. </tr>

20th Jan 2016

17:00

Final Submission of all the code and documents produced for/used by the project as an archive on CATE.

20th Jan 2016

Return of any special CSG-supplied resources used by the project.

Examples

Top Group Project Reports of 2015-16

Executive Summaries

Please remember that the Executive Summary is to be included as part of your report. It should just contain a concise information on your "product" and should not contain any Implemenation Details, Software Engineering Overview or Project Management.