G52GRP Software Engineering Group Project

Student Handbook 2012–2013

Henrik Nilsson

based on earlier versions by
Mark O'Brien, Graham Hutton and Gail Hopkins

Introduction Important Dates Groups Supervisors
Project Descriptions Lectures Meetings Equipment Project Hosting Project Web Pages and Databases
Assessment Assessment Guidelines Peer Assessment
Group Project Site Interim Group Report Final Group Report
Software Individual Report Submission of Reports and Software
Open Day Presentation Day Golden Rules


During your first year of study you learnt 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 people 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 Software Engineering experience and experience in the various different aspects of group working. The former include engineering requirements, system architecture and design, user interface design, implementing a medium sized, multi-component system, systematic testing and debugging, programming in a team, and use of software engineering tools. The latter include running meetings, making collective decisions, time and people management, writing reports, giving presentations, interpersonal skills, and resolving conflicts. 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.

Important Dates

The group project is assessed through a number of tasks to be completed at specific times during the project. There are also other important deadlines that must be met. The key dates and deadlines for the academic year 2010–11 are as follows:

Task Date or Deadline
Equipment requests From 15 October, once per group
Group project site up and running Friday 2 November 2012
Interim reports due Extension: Monday 10 December 2012
Final reports and software due Friday 22 March 2013
Open Day Wednesday 8 May 2013
Presentation Day Friday 10 May 2013

Note that the Monday of the week of the Open and Presentation days is a bank holiday. Thus there is only a single working day that week before the Open Day.


At the start of the group project module you will be divided into groups of around five or six students. The group division is done so as to ensure diversity and, to the extent possible, a well-balanced set of skills within 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. Working with people from different backgrounds, most of whom you will not know initially, is a central aspect of this module, just as it is going to be in your future professional lives.

The group allocations can be found via the main module web page. Note that it can take a couple of weeks from the start of the module before the groups are completely stable as it is not until then that the your individual module choices are finalised. Important! If you are not on the list of students taking this module but should be, or if you have not been assigned to a group but know you should be in one, you need to get in touch with the module convenor as soon as possible. In particular, if you are an incoming exchange student, you are unlikely to be in a group from the start. Similarly, if you find that you cannot make contact with certain group members, perhaps because they have elected to do a different module, it is important that you let the convenor know.

Each group should appoint one member as the Group Leader. In addition to their normal work as a member of the group, the Group Leader will play a management role. For example, the Group Leader should ensure that everyone is involved, that work is divided fairly and according to individual strengths, that tasks are completed on time, and that nothing is forgotten in the project. This does not at all mean that the Group Leader decides everything. On the contrary, the project is “owned” by the group as a whole, and the group may also find it useful to (formally or informally) appoint other leaders for specific aspects of the project, like Chief System Architect, Repository Master, Lead Programmer, or Lead GUI Designer. However, the Group Leader has a specific responsibility to ensure that the group works effectively as a whole, that everyone pulls in the same direction, that the project progresses according to plan, and, ultimately, that the project goals are achieved and the prescribed deadlines met.

Choosing a leader can be difficult, particularly if the group members do not initially know each other. However, it is very important for the success of the project that a leader is chosen. Not doing this is one of the most common regrets found in the final reports from group projects of previous years. If you have problems deciding on 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 he or she is not there to make decisions for you. Rather, the role of the supervisor is to monitor the group, to ensure that it remains focused, to ensure that steady progress is being made, to promote discussion, and to offer advice on matters such as report writing and presentation. In some cases, the supervisor may offer technical advice. 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. Groups meet with their supervisor once a week: see meetings below.

Project Descriptions

Each supervisor will provide their group with a brief written description of the problem that is to be solved, typically a few paragraphs long. 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 discussing among themselves and with their supervisor, and then refine and expand the project description into a requirements specification that the group and the supervisor can agree on.

The problem specifications will normally be made available via the main module web page in time for the introductory lecture or shortly thereafter.


The module is supported by a series of lectures given throughout the fall and spring. The exact number and content may vary a bit from year to year. Various practical aspects of the module are covered, there are usually specific support lectures on presentation and writing, and there may be guest lectures, e.g. from industry representatives, covering a wide range of topics relevant to software engineering, including professional and quality issues. See the main module web page for details.


Each group should arrange regular times for two kinds of weekly group meetings: one formal meeting with their supervisor present, and one (or more) 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"). These tasks should rotate among the group members, 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 gives some suggestions for how to structure your meetings and explains 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 e-mail list will be arranged by TSG 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 need to think about whether you will need any non-standard hardware or software (list of standard software here). If so, but only then, you need to complete an on-line equipment request form detailing the hardware and software requirements for your project. Under no circumstances must students themselves install hardware or software on school machines. Note that you only can make one request related to your group project.

What kind of requests can you make? No guarantees are made that all requests can be accommodated, but TSG will try to help with any reasonable request. The most common would be installation of (various kinds of) “free” software that normally is not available on School machines, or standard hardware (like a PC) configured in some specific way for your project. Beyond that, it may be possible to provide access to hardware and software that the School happens to have anyway. Also, don't forget that as it was your supervisor who set the project, he or she might be the one with access to special hardware, or he or she might be willing to purchase something to support the project.

Project requests are filed electronically, through the TSG ticket system, by following this link. Any student who is registered for a group project can fill in the request form on behalf of his or her group. Thus, since only one request can be filed per project, this needs to be thought through and carefully coordinated within the group before making the request. Once the electronic request form has been filled in and submitted, the supervisor is e-mailed asking him or her to approve or optionally alter the request. Once approved, the request will turn into a regular ticket and TSG will inform the group of progress setting up the equipment. Alternatively, the group can ask their supervisor to file the request directly on behalf of the group; e.g., during one of the formal group meetings. Unlike regular tickets, each group project request is visible to the supervisor and all group members.

Further details, along with a link to the electronic request form, are available here.

Project Hosting

The School provides each group with an account on the School's project hosting server, https://code.cs.nott.ac.uk/, giving each group a dedicated site for hosting their project. There is a direct link to the site for each group from the project page. The server runs Indefero, using Subversion for version control, and it provides each group with a version-controlled repository for source code and other major deliverables like group reports, facilities for simple, Wiki-style, inter-linked documentation (ideal for design documents, meeting agendas, minutes, ...), issue tracking, and more. The very first group project deliverable concerns populating the group's project site with basic information about the project and demonstrating that everyone in the group has a basic understanding of how to use Indefero and Subversion; see Group Project Site for details.

Each group should nominate a “Project Site Master” by e-mail to the G52GRP module convener. The Project Site Master is then granted administrator rights for the group's site. This is intended to allow the group to set up their project description and to adapt aspects of how the site works to the needs of the group. However, under no circumstances should the administrator privileges be used to:

In particular, there should only ever be one administrator besides the module convener, and who this is should only be changed after consultation with the module convener.

While it for most projects is strongly recommended that the hosting facilities provided are used for the main development work, this is not a requirement. Indeed, in some cases there may be good reasons not to, say if a project is concerned with extending an existing code base hosted elsewhere.

However, a group wanting to use other facilities than those provided for hosting source code or other aspects of their project, and then in particular facilities external to the School such as GitHub or Google Docs, need to bear the following in mind:

Note that site authentication is by way of your CS credentials. Should you have trouble logging into your project account, TSG recommends in the first instance to reset your CS password:

If that does not help, then please contact TSG directly, either by raising a ticket or in person at A39.

Project Web Pages and Databases

Many groups will need to set up a website and/or a database as part of their projects. The School servers support setting up static as well as dynamic (PHP, CGI) web pages. To support group projects, each group is further allocated a shared web account. However, access is limited to from within the University. Similarly, the School provide access to both Oracle and MySQL servers for setting up databases. For further information, see the TSG help pages:


The group project is assessed through a number of tasks to be completed at specific times during the project. There are no written examinations. Most tasks are carried out as a group, but there is one individual task: an Individual Report to be handed in at the end of the project. Consequently there are two parts to the final mark each student will get: one part for the group tasks and each individual's contribution to those, one part for the individual report. This is explained in more detail in the following.

For the group tasks, each group is awarded a Collective Group Mark on the standard university scale, with the different aspects of the project contributing according to the following table:

Group Task Weight
Group Project Site 5 %
Interim Group Report 15 %
Final Group Report 30 %
Software 20 %
Open Day 15 %
Presentation Day 15 %

Peer assessment is then used to derive an Individual Mark for Group Work, on the university scale, for each group member from the Collective Group Mark. This is done by distributing the collective mark among the group members according to merit as perceived by the group members themselves (but vetted by the supervisor), such that the average of the individual marks for the group work equals the assigned Collective Group Mark.

The Individual Report is also assessed on the standard university scale. The Individual Mark for Group Work and the mark for the Individual Report are then weighed together into an Overall Individual Mark according to the following table:

Component Weight
Individual Mark for Group Work 80% 
Individual Report 20% 

Important! Late submissions, be it of printed copies or electronic copies of reports and software, will be penalised at the standard university guidelines of 5 % per working day.

Most tasks are marked by the supervisor and at least a second marker. The exceptions are the Group Project Site, where the module convener checks that a number of specified tasks have been accomplished by the due date, and the Interim Report, which is marked by the supervisor only. For the Open Day, all members of academic staff are invited to mark the displays in addition to the supervisor and second marker. For the Presentation Day, the presentations are usually marked by a third member of staff in addition to the supervisor and second marker.

Assessment Guidelines

The Group Project Site deliverable is marked by the module convener based on the extent to which the the specified tasks have been achieved by the due date and, where applicable, how well these tasks have been achieved.

The following guidelines are applied when judging the quality of the Group Reports and Software:

The Open Day is marked primarily on

The Presentation Day is marked primarily on

The Individual Report is primarily marked on

The Individual Report is not marked on the contribution of an individual: peer assessment takes care of that. But showing a clear understanding of ones role in the project, the true value of ones contribution, and what was learned about working as a team, including an honest self-assessment, is important.

Peer Assessment

As explained above, peer assessment is a key aspect of the overall assessment. It is used to distribute the collective group mark to each individual according to merit as perceived by the peers, i.e. the other group members. Each group member is asked to rate each of his or her peers according to a number aspects on a purpose-designed form. A written justification supporting the ratings is also required for each member. The peer assessments are submitted in complete confidence as part of the Individual Report, and will not be seen by the other students. Note that, under certain circumstances, it is possible to revise the assessment up until the end of the Presentation Day. See below.

The G52GRP Peer Assessment Form is available in various formats through the following links:

Be sure to read the instructions on the forms carefully, as well as the instructions below, before filling out the forms. The completed forms are to be included as an appendix in your Individual Report.

Each group member is assessed according to the following aspects:

Thus it is not just the amount of contributed work that is being evaluated, say in terms of words in the reports or lines of source code, but a wide spectrum of contributions all of which are important for a successful end result. This also means that everyone gets a chance to contribute according to their specific skills and get proper recognition for this. Clearly, someone who excels in designing the system architecture and implementing it has made a very important contribution. Likewise, someone who is a great writer and took the lead on getting the group reports together has also made a big contribution. But someone who was instrumental in mediating between conflicting views, say, and thus helped holding the group together has clearly also made a very valuable contribution to the group as a whole.

Each aspect is rated on a five-point scale ranging from “None” via “Adequate” to “Excellent”, where “Adequate” means that the assessed person has done what is expected for that aspect: no less, no more. Note that it is the relative performance of group members that matters as the peer marking only serves to redistribute the assigned collective group mark. For example, if everyone rate everyone else “Excellent”, the end result is that everyone gets the same mark for their contribution to the group work which is going to be equal to the collective group mark.

Assessing your peers is a privilege and big responsibility. Be fair and objective in your evaluations. In the past, the members of the School Faculty have been very impressed with the quality and honesty of the peer assessment, and there has almost never been any problems. However, each supervisor is charged with carrying out a sanity check on the peer marks based on what they have learnt during the interaction with the group members throughout the year, as well as from the group and individual reports. Should there be obvious problems with some of the peer marks, then the supervisor together with the module convenor will override any or all of those marks where necessary.

Revised Peer Assessment

Note that the initial peer assessment is submitted as part of the individual reports. While this is sometime before the Open and Presentation days, the majority of work will have been completed by then, and the time of report submission is thus a reasonable time to carry out the peer assessment.

However, it is conceivable that the performance of a peer during the final preparations for and at the Open and Presentation days is significantly better or worse than his or her previous performance, so much so that the initial assessment becomes very unfair. Here “very unfair” means that the overall change of the assessment must be at least 3 points (three different aspects changed one step up, one aspect changed two steps down and one other aspect changed one step down, etc.). Should this be the case, it is permissible to revise the assessment for a peer one time, up until the end of the Presentation Day. The revised assessment is subject to vetting by the supervisor and module convener just like the initial one.

To revise an assessment, the following procedure must be followed:

Group Project Site

Each group is provided with a School-hosted site for their project, powered by Indefero and using Subversion for version control. See the section on Project Hosting for more information.

The very first deliverable of the group project is for each group to add a description of their project to their site and to carry out a set of exercises designed to ensure that everyone in the group at least has a basic understanding of how to use the project management facilities provided. To accomplish this, each group nominates a “Project Site Master” by e-mail to the G52GRP module convener. This person will be granted administrator rights for the group's site, and is responsible for coordinating the completion of this first deliverable, including educating the other team members in how to use Indefero and Subversion if necessary. Additionally, as adding a project description requires administrator privileges, the Project Site Master is also ultimately responsible for getting the description in place. However, writing the description should be a team effort, and it should reflect the group's collective vision of their project.

The following tasks should be completed by the deadline:

This deliverable is marked by the module convener by checking the extent to which the various tasks have been accomplished as specified and, where appropriate, the quality of the work, in particular the quality of the project description.

Interim Group Report

The Interim Group Report should be 4000–5000 words (around 12–15 pages; excluding any appendices). It 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:

One printed copy of the interim group report should be submitted as well as an electronic copy in PDF format. The front page of the report should include:

Final Group Report

The Final Group Report should be 7000–8000 words (around 20–25 pages; excluding any appendices). It is due at the end of the project. Each group must submit one such report, written as a group. The report should be a self-contained, updated, and expanded version of the Interim Group Report less parts that are no longer relevant.

Important! The report must be self-contained. In particular, the report must not assume that the reader has read the Interim Group Report prior to reading the final report. Nor is it appropriate to include the Interim Group Report as an appendix.

In particular, the Final Report should include:

A user-manual (if appropriate) should be included as an appendix. Excerpts of the developed code can be included in the report for illustrative purposes, but any lengthy excerpts should go into the appendices.

Two printed copies of the final group report should be submitted as well as an electronic copy in PDF format. The front page of the report should include:


An electronic copy of all developed source code should be submitted at the same time as the group report at the end of the project. The code should be submitted either in the form of a zip archive or a gzipped tar archive of the entire source code hierarchy. Auxiliary components, such as code libraries developed by others, data bases, or other lengthy pieces of data do not need to be included. Consequently there is no requirement that what is submitted has to be complete enough to run “out of the box”. But, if feasible, it is good if what is submitted is complete and if instructions for how to run the system are included.

Important! All source code should be properly attributed. Code written by the group should be clearly marked as such (e.g. by a comment at the top of each file). If code has been adapted by the group for the project then the sources must be clearly identified. Any system components not written by the group (e.g. libraries beyond standard libraries) must be properly identified.

Assessed aspects of the submitted software include but are not limited to:

Evidence taken into account include the submitted software itself, information from appropriate parts of the submitted reports (including the testing appendix of the final report), Open Day demonstrations, testing carried out by the first and second markers themselves during e.g. the Open Day, insight gained from the group presentations and ensuing discussions during the Presentation Day.

Individual Report

Individual reflection on the project is an important for getting the most out of it. This is the primary role of the Individual Report. Additionally, this report contains each student's assessment of his or her peers. Each student must submit one Individual Report at the end of the project, written by themselves. It should be 2000–2500 words (around 6–8 pages), excluding the peer-marking part and any appendices.

The main parts of the Individual Report are:

The reflection should cover aspects such as what was achieved, what was not achieved and why, critical discussion on the running of the project, what you have learnt from the project, and what you would do differently if you were starting over again.

The peer assessment is carried out on a dedicated form. The form, in various formats, is linked from this document. Each student must evaluate all members of the group except themselves. Additionally, each evaluation must be justified by a written statement on the performance of each peer. See Peer Assessment for further details, including links to the evaluation form in various formats to facilitate the inclusion of the completed forms with the Individual Report. (If none of the supplied formats is suitable, printed, completed forms can be scanned for inclusion.)

Note that Individual Report is marked primarily on the quality of the reflection and on the qualities as a report, not on the extent of contribution as such to the project: see Assessment Guidelines above.

The Individual Report should be submitted electronically, in PDF format. The front page of the report should include:

Submission of Deliverables

This section is subject to being changed as we hope to move to Moodle for electronic sumission

Please check the deadlines for each deliverable carefully. The following table gives submission details for each deliverable:

Deliverable Submission Printed copies Format of electronic copy File name of electronic copy
Group Project Site joint N/A Indefero N/A
Interim Group Report joint 1 PDF <group-id>-igr.pdf
Final Group Report joint 2 PDF <group-id>-fgr.pdf
Software joint N/A Zip/Gzipped TAR <group-id>-src.zip or <group-id>-src.tar.gz
Individual Report individual None PDF <group-id>-ir-<user-id>.pdf
“Joint” submission means that the deliverable is to be handed in by the group as a whole. For electronic copies, this means that one member of the group submits the file in question. “Individual” submission means that each group member submits the prescribed number of copies in the prescribed formats of the deliverable in question. At present, this means an electronic copy only of their own Individual Report. Further details on the Coursework Submission Pages. Instructions for creating PDF copies of the reports are available here.

Important! Make SURE you understand how the CW system works, see the Coursework Submission Pages. In particular, be aware that if you are submitting more than one deliverable (e.g. you are responsible for submitting the Final Group Report on behalf of your group in addition to your own Individual Report), you must, the way CW currently works, submit all deliverables together, as any earlier submission is overridden by a new submission.

Examples. Suppose abc10u and xyz10u are two members of the group gp11-nhn. Suppose it is time for submitting the final deliverables, and that the group has agreed that abc10u will submit the joint deliverables on behalf of the group. abc10u will then submit the following files (and nothing more) in one go using CW:

All other members will only submit a single file: their own Individual Report. For the member xyz10u, this means submitting the following file (and nothing more) using CW: Recall that the individual report must include the peer assessment as an appendix. Thus, peer assessment should absolutely not be submitted in separate files. It is also very important to follow the exact naming conventions defined above, including all lower-case letters. Not doing this might result in delays which could cause your submission to become late: see below.

Each deliverable should be handed in no later than 4:00 pm on the due date. Printed copies should be handed in to the School Office. Electronic copies are handed in using the School's CW coursework submission system.

Important! You must ensure that your both printed and electronic copies of the deliverables are submitted using the proper procedures, including the exact file name conventions defined above. Failure to do so will likely result in the coursework being late, which in turn will result in marks being deducted.

You are also strongly advised to avoid handing in at the very last minute, as any delays due to e.g. long queues to the printers or heavy load on the servers are entirely your own responsibility as such problems are not unlikely and thus should be taken into account when planning.

Open Day

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 a day, and each group is given a small area in which to set up a “trade stall” with posters, leaflets, and a live demonstration of their application. Note that it is the overall quality and professionalism of the stalls that is assessed during the Open Day, not just the application itself. To make the day more fun, 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 the supervisor. No guarantees are made that all requests can be accommodated, 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 2007:

Further photos here and here.

Presentation Day

Each group must prepare one presentation, which is usually performed by the best speaker in the group. The presentation should be 10 minutes long, with an additional 5 minutes for questions. It is attended by both staff and students. The main content of the presentation should be a description of the problem addressed by the project, an overview of the application developed, and some reflective remarks on the success of the project. The presentation is usually given using electronic slides (e.g. 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.

Many students may not have given presentations before, so prior to this part of the group project there is a support lecture on this topic. This lecture gives 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 if there are any non-standard needs. 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 the supervisor. Groups using anything other than overhead projector or data projector will be required to demonstrate in advance to the support staff that their presentation works properly in the presentation room.

The presentation day is divided into sessions, usually with three presentations in each. You will not be required to attend for the entire day, only for the session to which you have been allocated. The project presentation schedule will be available two to three weeks before the Presentation Day. You should read carefully the information given and check to see when and where your group will be presenting. The sessions normally start on the hour, and groups are required to arrive during the preceding break to make all necessary preparations (such as copying PowerPoint slides to the main computer and ensure they display properly) before the session starts to ensure a smooth and speedy transition between the presentations during the session.

Golden Rules

Below are some tips based upon the reflective comments in the final reports from previous years group projects. Read them carefully; they are the golden rules for a successful project.

Last updated 12 March 2013.