]
]This guide has been written for the following typical setup of a software engineering project course (modeled after our CS3215 course at SOC, NUS). But I expect most of the contents to be applicable even for student projects set up differently.
The product students implement is usually of non-trivial, typically in the range of 10-20 KLOC. The functionality of the product should be well specified, either by students, but often by the teaching team. It should be able to break it down to multiple sub-systems (e.g., front-end sub-system and back-end sub-system).
Students work in not-too-small teams (e.g., 4-6 members). Each project team consists of multiple sub-teams, each working on a separate sub-system, working collaboratively, yet as independently from each other as possible.
Each team is assigned a supervisor (from the course teaching team), who oversees the project teams progress, provides expert advice on the problem domain, and takes part in grading the team. Project team meets the supervisor for regular consultations (e.g., weekly).
Several peer-review exercises are conducted during the course. This helps to identify problems (e.g., freeloaders, conflicts in teams) early, and take remedial action. Among other things, students are asked to estimate the contribution of each team member to the project.
An iterative process is used as the baseline (e.g., Unified Process, Extreme programming), usually, with some adaptation.
The system is built iteratively. Students start by building a proof-of-concept prototype to validate the architecture, and to evaluate various implementation options. Next, they build the real product in iterations. Each iteration adds more functionality to the product, while producing a working system at the end of each iteration.
The system is delivered incrementally. A number of predefined milestones (V0.1, V0.2, ... V1.0b, V1.0, etc.) specifies when to deliver which functionality. Whenever possible, intermediate deliverables are acceptance-tested, and graded. These intermediate grades may be counted towards a relatively small percentage of the final grade (e.g., 20%).
Each team writes a project report (~50-100 pages), describing the product (the architecture, design, algorithms, non-functional qualities, etc.), as well as the project (the process followed, problems faced, lessons learned, etc.). This too is written incrementally and iteratively. The supervisor provides feedback on intermediate versions of the report, so that students can improve the final version of the report.
Project teams also do a project presentation, at the end of the project. This presentation+demo+Q&A session is a chance for students to argue why they should be given a higher grade, and allow the teaching team to evaluate student arguments.
The delivered system is evaluated in a number of aspects. Correctness -the most important aspect- is objectively evaluated using a bank of test cases and an automated test driver. Other non-functional qualities such as efficiency are measured objectively when possible (e.g., the use of stress testing to evaluate performance), while other qualities such as the design quality are measured based on arguments presented by the students (in the project report, and in the project presentation).
By default, the whole team gets the same grade. However, in cases of uneven contribution from team members, grades are adjusted accordingly. Some per person statistics (e.g., LOC written by each team member, test cases written, bugs produced, bugs found, ...) and peer reviews can be taken into account in such a case.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.9, Jan 2009, Copyrights: Damith C. Rajapakse |---