3rd Year Group Projects Introduction

3rd Year Group Projects

Introduction and Overview

The Third Year 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.
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 submit the project inception report (Report One), 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. Being late with a report will lead to the loss of marks. 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 to the SAO and proof of submission (stamp or CATE cover sheet) 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 infrom their superviasor PRIOR to completion of the project. Only in exceptional circumstances will group members be given dfferent 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 source 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 integartion, testing, and keeping abreast with deadlines.

Sometimes groups cannot easily reach consensus on design design or organizational 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

Report One: Inception — due: 12.00 27th Oct 2011

This important report documents results from the inception phase of your project. It serves as a loose contract between your group members and your supervisor. It should contain:
1. Key Requirements: Up to 10 most critical or high-risk, but definitely essential, requirements that your completed system will meet; their realisation should secure at least grade B.
2. Extensions: Additional features or requirements that, if implemented satisfactorily, could contribute to the group getting an A (provided the group scores well on all other criteria).
3. Choice of Development Method:
  - Suggested (blend of) agile software development method you intend to use.
  - A description of the anticipated methods and practices for code testing and version control.
  - Identification of needed information technology.
  - Your project management: how you measure project progress or velocity, what roles and responsibilities team members have throughout project, how often and in what form (e.g. Scrum meeting) will you meet, etc.
4. Draft Schedule: A well-considered but non-binding estimate of how the project should progress:
  - Outline of anticipated number of time-boxed iterations you will use
  - Tentative list of features or milestones that each iteration should deliver in executable software
  - For each feature, an analysis of the technical components necessary for their realization.
  - Identify which components are supposed to work for each iteration.
5. Detailed Plan for First Iterationn:
  - Specification of length of, and dates for, your first time-boxed iteration of software development.
  - Detailed mapping of tasks for the iteration, wg with a Sprint backlog.
  - Identification of potential risks during first iteration.
  - Planned progress measure for first iteration.
Evaluation Criteria for Report One: A professional and cogent account of the five items above. Try to be succinct, precise, and focused.
The report should be written such that a manager who oversees your project within a portfolio of IT projects will understand what this project is about and what you are about to do, and why.
Report Two: Progress & Revisions — due: 12.00 11th November 2011

This report has four aims:
1. Progress: to report on the progress of the project so far.
  It should detail how many iterations and what requirements or features have been completed so far. Also include what problems - technical or other - have been encountered and what measures have been taken to mitigate their effect on overall success.
2. Revisions: to record any changes to any of the five items in Report One.
  
  You are expected to include appropriate elements of Report One to highlight any changes made.
  - Have key requirements changed, been deleted or added? If so, has this been cleared by your project supervisor?
  - Have your infrastrucutre needs changed?
  - Do you still plan the same feature extensions?
  - Have you changed how you measure progress?
  - Are there problems that threaten completion of core functionality?
  - How many iterations do you still plan?
  - Also present a revised, less speculative schedule.
3. People management: to document any issues that may have emerged in the work dynamics of your group
  - How do you cope with the fact that group members have different levels or areas of skills?
  - how do you ensure that all group members contribute fairly
  - How do you resolve any problems?
4. Ethical and Environmental Impact:
  - Discuss whether your project has any potential ethical issues and explain how you intend to address such issues in your design, implementation, deployment or work practice,
  - Assess the environmental impact of your to-be-deployed system; describe ways in which this impact can be limited without compromising key requirements, or argue why the environmental impact cannot be decreased without such compromise.

Evaluation Criteria for Report Two: the same as for Report One. But keep in mind that change and its management are the norm, not the exception.

Report Three: Software Validation — due: 12.00 10th December 2011

This report has three aims:
1. Testing: to report on your use of testing during development; at which development stages did you use tests, which portions of your code base were tested in this manner, what bugs did testing reveal?
2. General Validation: to decribe any other methods you may have used to validate your executable deliverable; the following list is only suggestive but should give you an idea of what things you could do:
  - Did you validate your user interface design?
  - Did you use lint or similar tools?
  - Did you conduct a manual code inspection (not by the person who wrote the code)?
  - Did you exert your software to stress testing?
  - Did you test the GUIs of your software?
3. Managerial Documentation: to give a formal account of group management and group activities:
  - Collaboration tools used (eg svn)
  - Management policies (eg code change/validation policies)
  - Management of knowledge transfer within the group
  - A table of the group meetings - including dates, format and which members attended
  - A table of the hours spent per week on which tasks or activities by each member on the project
  - The Log-Book
Evaluation Criteria for Report Three: the same as for Reports One and Two.
Final Report — due: 9th Jan 2012, at 11:00

Contents for Final Report: The project report should not be longer than 45 pages, and might be organized according to the following structure:
- A. High Level, Nontechnical Description Why you should buy this product/listen to this presentation? What is the functionality of the product?
- B. Short Technical Description
  - Short introduction into technologies used
  - Design of your software, possibly including a diagram of the major components of the project
  - Main achievements
- C. Software Engineering Issues:
  - 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?
  - Any collaboration/coordination difficulties encountered and how addressed
  - Development and testing methods and/or tools used; comparison of plans with actual achievements
  - Estimates of length of code in each of the components, or any other comparable measure of the effort required.
  - Summary of each team member's contributions
- D. Validation and Conclusions How did you validate your product? Was the project successful? What did you learn? What might you have done differently?
- E. Bibliography
- F. Appendix The appendix is optional, and does not count towards the 45 pages. It may contain thing like: User guide, installation instructions; more extensive design, testing, statistics etc.
Feel free to re-use material from the previous reports as you see fit, but 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 to SGO in form of a hard copy, as well as electonically through CATE.
Executive Summary — due: 11th Jan 2012, at 16:00
Three copies of a two page loose leaf Executive Summary must be submitted to the SGO, and also on CATE. The Executive Summary should follow the structure (A-D) as suggested above.
Final Submission — due: 18th Jan 2012, 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

Reports One, Two and Three

The assessment of Reports One (30%), Two (30%) and Three (40%) is undertaken as part of the Software Engineering Methods course, according to the evaluation criteria outlined above. To foster incremental feedback, the aim will be to return marks for the Reports within 7-10 days after their respective submission deadline. Reports One, Two and Three are worth 123 Marks for the BEng students, and 132 Marks for the MEng students.

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 presnetation, and/or read your final report. The assement is based on:

Executive Summary, 5%
Presentation, 10%
Report, 15%
Software Engineering and Group Collaboration, 35%
Technical difficulty and achievement, 35%

The group project is worth 287 Marks for the BEng students, and 308 Marks for the MEng students.

Overall assessment

The overall assessment is the sum of the Reports One, Two and Three, and the group project component.