Project Overview


An important part of this course is the term project. As a member of a team of about 5 students, you will apply the methods and skills learned in class (and hopefully elsewhere) to the design, prototypic implementation, and evaluation of an application. The project consists of several parts, which will be graded separately. Each team has to produce deliverables, which will be the basis for the grades of all team members. The team members will be asked for feedback on the performance of the other team members. This subjective feedback may be used to adjust individual scores. Team members are also required to document their activities, e.g. in the form of work sheets.

Project Topic


Teams can select their own project topic, subject to my approval. Ideally, the teams should have chosen a topic by the end of the first week; if necessary, you can postpone this decision into the second week, but this will leave you with less time for the requirements specification and later activities.
Follow this link for some suggestions for possible topics. You can also look at previous projects to get an idea for the topics other students worked on. I have put together a checklist with a few things to consider when you're going through the process of selecting your project topic.

Project Organization


The first part of the task will be to select a project, and to establish the requirements that will serve as the basis for the later evaluation of the completed project. Then a sequence of prototypes of your selected application will be implemented. In many cases, due to time constraints, the initial prototype may not be fully functional, but it should have a core part that can be used for evaluation purposes. The prototypes will be evaluated by a different team. Finally, there will be a presentation on the project. This presentation will focus on the final version and the evaluation by the evaluation team. It must include information on the initial user requirements, design, and implementation provided by documentation made available through Web pages on the team accounts on the hornet system.
The following paragraphs provide you with more details on the different parts of the project. Included is information on the time frame, and the contribution of the part to the overall grade. An overview of the due dates is also contained in the class schedule.
We’ll use Trac Wikis for the project documentation and organization. The Wikis are assigned to the teams during Week 1, and I’ve put together a template for the main Wiki pages. The template gives you a blueprint for the organization of your own Wiki, and also describes what kinds of documentation I expect from you. You do not have to follow the Wiki structure precisely, but your documentation should address the main topics identified there, and they should be easy to identify. So, for example, instead of using one large page, you can use a small front page with links to the different parts.

A Few Notes on Teamwork


A substantial degree of your grade in this class depends on the overall performance of your team. This can be good (you do nothing, and still get a good grade) or bad (you do a lot of excellent work, but it is not enough for the whole team to earn a good grade). Ideally, every team member should contribute a roughly equal share. In reality, this is often not the case because team members have different backgrounds, experience, work habits, cultures, etc. Just like in a professional work environment, you have to find a balance between looking after your own interest, and contributing to the overall team effort. If at any point you feel that there are serious problems with your project team, feel free to talk to me, and we will try to find a solution.

Project Presentations or Displays


The teams will present progress on their projects at around the mid-quarter mark, and then at the end of the quarter. In the past, we’ve used both conventional presentations where the teams sequentially describe the status of their projects in front of the class, or science fair displays, where each team has a project station with a poster board and demos of their work. We will discuss this in class, and collectively decide which format to use.

Grading


The overall score for the project is 100 points. 80 out of these 100 points come out of my evaluation of the team project, and usually every team member gets the same score. This evaluation is based on the different stages of the project, which concentrate on various aspects of the design and implementation. My evaluation relies on the project documentation on your team wiki in combination with discussions and demos during the lab time. Usually teams will have a chance to improve their work after receiving my feedback, and I will adjust the score accordingly. However, teams will typically only be able to recover about half of the “lost” points, so it is important to try to do things well the first time around.
The remaining 20 points come from an evaluation of your team mates, calculated as the average of all your team mates' scores for your work. However, I reserve the right to adjust this score, especially if everybody gives all of their team mates the highest possible score without thorough justification. If you don't submit your evaluation of the other team members, you may not receive any points for this part.