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.
You can follow this link for some suggestions for
possible topics (theses suggestions have been assembled over time, and are not only restricted to matching). 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 Timeline

The project will be conducted in several phases of approximately two weeks, with the following milestones:
  • Project Overview: A brief description of the system or project you are working on. This should include the intended purpose and application domain, more specific goals and objectives, an initial timeline (based on the one from the course schedule), and a short, high-level discussion of methods, tools and technologies under consideration.
  • Features, Requirements and Evaluation Criteria: Features describe the high-level, user-visible aspects of the system or project under development. They should be formulated in terms that are familiar to the users, and should not rely on terminology used by the developers. Requirements specify the expectations on the functionality provided by the system. You can view them as a contract between the designers and the system and the developers actually working on the implementation. In our case, the teams will most likely perform both roles, but it is still helpful to carefully define the requirements. Evaluation criteria are used to determine if the expectations encoded in the requirements have been met through the implementation. To some degree, I may use these evaluation criteria to assess the final implementation of your system.
  • System Design and Architecture: Frequently this milestone consists of a system diagram (often a block diagram with the main components of the system and how they are interconnected), and it is sometimes accompanied by a class diagram. Any diagram should be briefly described in the text, with a focus on the functionality of the components, and their interconnections.
  • Prototype 1: The first prototype should demonstrate the feasibility of the system, and include an implementation of the core components. For this collaboration with MUAS, the prototype also should include a first version of the API.
  • Prototype 2: The second prototype should expand the functionality of the system, eliminate errors, and improve its performance. It may involve changes to the system design or even the requirements, which should be documented in an appropriate manner.
  • Final Prototype: Here, your system should provide the full functionality as specified in the requirements.
Each milestone will include appropriate documentation. Please consult the class schedule for the actual due dates.

Code and Documentation Repository

I recommend to set up a github repository in combination with Google Docs (or similar) for the code and documentation of the projects.

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. The collaboration with MUAS may also benefit from videotaping the project presentations.

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 repositories 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.