Software Engineering Group Project
Student Handbook 1999-2000

During your first year of study you learned some of the basic principles of computer programming. In industry however, you won't usually be programming on your own, but will be working as part of a group of programmers developing a larger application. As an introduction to group working, part of your second year is made up of a software engineering group project, in which you are divided up into small groups to design, program, and document a computer application.

The aim of the group project module is for you to gain some experience in the various different aspects of group working. These include running meetings, making collective decisions, time and people management, writing reports, and giving presentations. During the project, you will also learn that being a member of a programming group can be great fun!

The group project module runs for the whole of the second year, and is worth 20 credits.

At the start of the group project module you will be divided into groups of around five or six students. To ensure an even distribution of ability across different groups, the results of the first year exams are taken into account when deciding upon the groups. Note that forming your own groups is not permitted, and that you are not allowed to swap places with someone from another group.

Each group should nominate one member as the leader. In addition to their normal work as a member of the group, the leader will play a management role, for example ensuring that work is divided fairly, that tasks are completed on time, and that nothing is forgotten in the project. Choosing a leader can be difficult, particularly if the group members do not initially know each other, but it is very important for the success of the project. Not choosing a leader is one of the most common regrets found in the final reports from previous years group projects. If you have problems deciding upon a leader, your supervisor can help in making the choice.

Each group will be assigned a member of staff as their supervisor. The supervisor is not in charge of the project, and is not there is make decisions for you. Rather, the role of the supervisor is to monitor the group to ensure that it remains focussed, to ensure that steady progress is being made, to promote discussion, and to offer advice on matters such as report writing and presentation. The supervisor also plays a significant role in marking the project. For some projects, the supervisor may also play the part of a customer for whom the application is being developed. At the start of the group project module you should arrange a regular time for weekly meetings with your supervisor.

Each supervisor will provide their group with a one or two paragraph written description of the problem they are to solve. This document will form the initial specification for the application to be developed. Each group will have a different problem to work on. The initial problem specifications will likely be vague, so one of the first tasks of each group will be to understand their problem better, by discussion among themselves and with their supervisor.

Each group should arrange regular times for two kinds of weekly group meetings, one with their supervisor present, and one without.

The weekly meetings with the supervisor will normally be held in his or her office, and should last 30 minutes. The purpose of these meetings is for the group to report on progress since the last meeting, discuss any problems that have arisen, and plan the work that will be carried out by each member prior to the next meeting. These meetings should be quite formal in nature, with a chairperson (who runs the meeting) and a secretary (who records the progress of the meeting and produces "minutes"). A different person will take on one of these tasks at each meeting, so that everyone gains experience with both tasks. Most students will not have attended formal meetings before, so at the start of the group project module you will be given a special lecture on this topic. This lecture will give some suggestions for how to structure your meetings, and also explain the roles of the chairperson and the secretary.

The weekly meetings without the supervisor will normally be held in a mutually convenient location in the school, or elsewhere on campus, and have no prescribed time limit. What goes on at these meetings is completely up to the group, but they are usually more informal in nature. There is no requirement for a chairperson or minutes, but some groups may find it useful to carry on with these practices here.

An emailing list will be set up automatically for each group, allowing the members to easily communicate with each other and the supervisor outside of the meetings.

In the first few weeks of the group project module each group should complete an equipment form detailing the hardware and software requirements for the project. The form will list the standard facilities that are available for group projects, as well as the extra hardware and software that are in limited supply and can be installed by the support staff on specific machines for use with specific projects. Under no circumstances must students themselves install hardware or software on school machines. To confirm that the requests are appropriate, this form must be signed by the project supervisor. No guarantees are made that all requests can be accomodated, but the support staff will do their best to ensure that equipment is allocated fairly.

There are three special lectures, covering topics that will be useful during the group project module:

• An overview of the module;
• How to run group meetings;
• How to give a good presentation.

There is also a guest lecture, given by Richard Shorter from Ford Motor Company:

• Teamwork, leadership and behavioural skills.

The group project module has no written examinations. It is assessed through a number of tasks to be completed at specific times during the project. Some tasks are carried out as a group, and all members of the group receive the same mark. The remaining tasks are carried out individually, and each student receives a separate mark. The tasks, their preliminary deadline dates, and their percentage contribution to the final mark for the project are as follows:

A brief description of each task is given below.

This report should be 3500-4000 words (around 10-12 pages; excluding any appendices), and is due around the half-way stage of the project. Each group must submit one such report, written as a group. The main content of the report should be an updated and expanded description of the problem to be solved (including any relevant background information), a survey of any existing systems that address similar problems, the results of any market research conducted, an overview of the design of the proposed system and its user-interface, and the results of any initial steps in implementation. The programming languages, operating systems, computers, and any additional software and hardware to be used in the project should now all be finalised. The choices made and the reasons for them should be documented in this report. The report should also discuss any problems encountered so far, and include a time plan that outlines how the remaining time for the project will be spent.

This report should be 1500-2000 words (around 5-6 pages), and accompanies the interim group report. Each student must submit one such report, written by themselves. In this report you should summarise your personal contribution to the project so far, the tasks that you have been assigned for the remainder of the project, and how you plan to go about tackling these tasks. The report should also discuss any problems that you have encountered so far, and include a time plan that outlines how your remaining time for the project will be spent.

This report should be 6500-7000 words (around 18-20 pages; excluding any appendices), and is due at the end of the project. Each group must submit one such report, written as a group. The report should be an updated and expanded version of the interim group report, and also include a discussion on the implementation of the design, a summary of what was achieved, and some reflective comments on the success of the project. A user-manual (if appropriate) should be included as an appendix. The code can also be included as an appendix, but this is not mandatory. Two printed copies of the final group report must be submitted, as well as an electronic version in PDF to enable the report to be archived on CD-ROM.

This report should be 3000-3500 words (around 9-10 pages), and accompanies the final group report. Each student must submit one such report, written by themselves. In this report you should summarise your personal contribution to the project, what you have learned from the project, and what you would do differently if you were starting over again. The report should also include a critical discussion on the running of the project, and the performance of the other group members. In particular, the report must contain a written assessment of the performance of each of the other group members, together with a peer assessment mark (see below) for each member of your group apart from yourself. Two printed copies of the final individual report must be submitted, as well as an electronic version in PDF to enable the report to be archived on CD-ROM.

At the end of the project each student assigns each of their group members apart from themselves an integer mark in the range 0% - 100%. This mark is for the group members overall performance on the project, and should take into account their contribution to: the formal and informal group meetings; the research, design, implementation, testing and debugging of the application developed; the management of the project; the preparation for the presentation and the open day. These marks are submitted in confidence as part of the final individual reports, and will not be seen by the other students. Students must use the following table as a guideline when assigning their marks, and must provide a written justification for each of their marks:

For reference, an average contribution to a project should be awarded a mark of 58%, and a mark of greater than 75% would be very rare. Be fair and objective when assigning your marks - the module organiser reserves the right to question students about their peer assessment marks, and to adjust or ignore any marks that are deemed to be inappropriate.

The presentation should be 10 minutes long, with an additional 5 minutes for questions, and is attended by both staff and students. Each group must prepare one presentation, which is usually performed by the best speaker in the group. The main content of the presentation should be a description of the problem to be solved, an overview of the application developed, and some reflective remarks on the success of the project. The presentation is usually given using overhead transparencies or Microsoft Powerpoint. Some groups may choose to include a live demonstration of their application, but, with the possibility of unforeseen technical problems, this is risky. We generally recommend that demonstrations are given using pre-prepared slides. Note that it is the quality of the presentation itself that is assessed, not the quality of the project or the application. To make the day more fun, everyone dresses formally for the group project presentations.

Most students will not have given presentations before, so prior to this part of the group project you will be given a special lecture on this topic. This lecture will give some suggestions for what to put into your presentation, what to put onto your slides, and how to speak well.

Before the presentations each group should complete an equipment form detailing the hardware and software requirements for the presentation. The form will list the standard facilities that are available for presentations, as well as the extra hardware and software that can be installed by the support staff if requested. Under no circumstances must students themselves install hardware or software for presentations, or modify the settings of the presentation equipment. This form must be signed by a member of the support staff. Group using anything other than overhead projector slides will be required to demonstrate in advance to the support staff that their presentation works properly in the presentation room.

The group project open day is a chance for the groups to show off their finished applications to the other groups, to students from other years, and to members of staff. We take over one of the labs for an afternoon, and each group is given a small area in which to set up a "trade stand" with posters, leaflets, and a live demonstration of their application. Note that it is the overall quality and professionalism of the stands that is assessed during the open day, not just the application itself. As with the presentations, everyone dresses formally for the open day.

Before the open day each group should complete an equipment form detailing the hardware and software requirements for the open day. The form will list the standard facilities that are available for the open day, as well as the extra hardware and software that can be installed by the support staff on specific machines for use with specific projects. Under no circumstances must students themselves install hardware or software on school machines. To confirm that the requests are appropriate, this form must be signed by a member of the support staff. No guarantees are made that all requests can be accomodated, but the support staff will do their best to ensure that equipment is allocated fairly.

To give you a flavour of the open day, here are a couple of photographs from 2000:

• Work consistantly throughout the project. Start work on your project quickly, and don't leave all the real work until just before the deadlines. The group project module is worth 20 credits, each of which corresponds to 7.5 hours of time, so you should expect to spend around 150 hours in total on your project, which averages out to around 5 hours per week during term time. If you are not spending at least 3-4 hours per week on your project then you are not working hard enough, and will have problems later on.

• Make sure that you have enough to do. Half of the marks for the group project module are for your individual contributions to your project, so make sure that you have enough concrete tasks to write about when it comes time to write your reports. Don't wait to be assigned tasks - volunteer for things that you find interesting. Keep in mind that 20% of your marks will be awarded by your group members, so make sure that you make a good impression by taking an active role in the project and working hard.

• Don't leave the programming until too late. It is very easy to spend too long designing your application, and then find that you don't have enough time to complete the programming. In particular, there are often problems linking the different parts of applications together. Make sure that the interaction between parts is well documented before programming begins, and don't leave linking the parts together until the last minute.

• Keep track of everyone's progress. Make sure that everyone in your group is working consistently on the tasks they have been assigned. Your supervisor can provide some guidance with managing your project. Ultimately, however, it is the responsibility of the group themselves to monitor the progress of each member, to ensure that tasks are being carried out as required, and to take remedial action as and when appropriate.

• Take the meetings seriously. Without proper formal and informal meetings each week, your project has little chance of being successful. Spend some time preparing for each meeting, and make your own notes during the meeting in addition to the minutes. Note, however, that most of the real work on the project will be done outside of the meetings. Students whose only work on the project is to contribute to the meetings will find that they have little to write about in their reports, resulting in poor marks for the module.

• Keep good records of your meetings. Collecting your minutes together on a web page is a good way to ensure that they do not get lost, and that everyone can read them. Use the minutes to ensure that the group doesn't discuss the same points for weeks on end, that decisions made are not forgotten about, and that real progress is being made.

There is a cash prize of £200 awarded by Ford Motor Company each year to the group that worked most effectively together as a team. This need not be the group that obtained the highest marks for their project, or the group that produced the best product. The winning group is decided by the project supervisors, and the prize is presented to the previous years winners by Richard Shorter from Ford during his guest lecture.