]
]This book contains a collection of practical tips - byte sized observations and lessons learned - gathered from the authors' software engineering experience (both as educators and a practitioners) and from many excellent books/articles on the topic. However, it does not intend to cover software engineering theory.
The book is meant for students following software engineering project courses. It is usually hard for students to apply previously learned theories in a practical context. This is an attempt to help such students.
Today's students have very little time for reading supplementary texts. That is why we try to keep this as short as possible.
This book is free for use by anyone. If you want to reproduce some of this contents elsewhere - that could be arranged too; please let us know in advance.
Use this book to guide you in your project. It might not fit your project exactly, as project courses differ widely. If it doesn't, do let us know - we shall try our best to address the mismatch in a future version.
This book can be used as supplementary text for your project course. In particular, it might ease the pain of starting a new project course.
If you are an experienced educator, probably there are many tips you could add to this guide. Please help us improve this guide by sending feedback.
If you would like to co-author a customized version of this book to fit your own course, become a co-author by adding more tips, or to translate it to a different language, please drop us an email.
Although not specifically targeted for practitioners, this book can help newly-recruited programmers, especially if they are not CS graduates. More importantly, as practicing software engineers of today, you could help us educators do a better job of training tomorrow's practitioners - by helping us improve this book.
This guide has been written for the following typical setup of an SE project course. But most of the contents should be applicable even for project courses set up differently.
Students implement a non-trivial medium-sized product (typically, 10-20 KLOC in size). The functionality of the product should be well specified, either by students (as part of the project work), or by the teaching team (at the beginning of the project). Preferably, the product should consist of multiple sub-systems (e.g., front-end sub-system and back-end sub-system).
Students work in not-too-small teams (e.g., 4-8 members). Each project team consists of multiple sub-teams. Each sub team works on a separate sub-system, as independently from each other as possible.
Each team is assigned a supervisor from the teaching team, who oversees the team's progress, provides expert advice on the problem domain, and takes part in grading the team. Project teams meet their supervisors for regular consultations (e.g., weekly).
Several peer-evaluation exercises are conducted during the course. These help to identify problems early (e.g., freeloaders, conflicts in teams), 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 process model (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 production system iteratively. Each iteration adds more functionality to the product and produces 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 are counted towards 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.) and 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+demo+Q&A at the end of the project. This session is for students to argue why they should be given a higher grade, and for the teaching team to evaluate those arguments.
The delivered product is evaluated from several perspectives. Functionality -the most important aspect- is objectively evaluated using a bank of test cases and (preferably) 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). Aspects that are hard to measure objectives (e.g., design quality) are measured based on arguments presented by the students (in the project report, and in the project presentation).
A student's grade is calculated based on what the whole team achieved, possibly moderated based on his/her individual contribution to the project. Contribution statistics (e.g., LOC written by each team member, test cases written, bugs produced, bugs found, ...), peer evaluations and supervisor's observations can be taken into account during grading.
Authors thank (in no particular order):
by
Christian W Dawson, - Aimed more at research projects than course (system
development) projects, but useful if your course project incorporates an
element of research.
by Philip Weaver - Aimed more at final/honors year (system
development) projects, but applicable to course
projects as well. 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.8, 3rd Sept 2008, Copyrights: Damith C. Rajapakse |---