Project Overview


An important part of this course is the term project. As a member of a team of around 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 joint 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


The members of a team can select their own project topic, subject to my approval. Ideally, the teams should have chosen a topic by the end of the second week; if necessary, you can postpone this decision for up to a week, but this will leave you with less time for the actual project work.
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 will 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.

Project Overview, Background, Difficulty and Relevance

  • Overview: At least two paragraphs that describe the purpose, goal, context, and intended users for the project.
  • Background and Related Work: A description and discussion of similar projects, methods, experiments, or other things that are related to your project. Most frequently, this section contains information about related approaches, or systems that offer similar functionality or use similar methods. Sometimes it also addresses the history of the project and its context, especially if it is part of a larger effort. You can also include a discussion of methods, techniques, technologies, tools, or similar aspects if they are essential for the project.
  • Difficulty: Relative degree of difficulty for the project, considering the context. I may change this during the course of the quarter, typically to reflect changes in the scope or focus of the project. Usually this is in the range of 8-10, assuming that the team has discussed their topic choice with me.
  • Relevance: Assessment of how well the focus of the project matches with the class topics.

Features, Requirements, and Evaluation Criteria


I'm using this to evaluate the part of your project description where the team identifies what they will be working on, and how it can be evaluated.
  • Features: Project attributes that are of interest at the end user level; may be formulated in less technical terms, and more intended for marketing purposes.
  • Requirements: Conversion of features into specifications that can be used as a contract between the software/system developers and the project owners (end users, or whoever would pay for the system).
  • Evaluation Criteria: Measures that can be applied to the system in order to determine if it meets the requirements or not. Ideally, they should be objective and measurable. Frequently there is a close correlation between requirements and evaluation criteria.

System Design and Architecture


This section focuses on the following:
  • The functional components of the system, their interfaces and interaction methods with other parts (possibly also users), and design patterns.
  • The description usually is at an abstract level, and should not refer to specific implementation aspects (such as languages, technologies or tools used); those will be addressed in the next section.
  • The core of this section is often a block diagram that shows the main components and how they interact. Class hierarchies and UML diagrams also frequently fit in this section. If you use specific computational methods or algorithms, you can describe them here, e.g. through flow charts or pseudocode.
  • Data structures, data base schemata (e.g. entity-relationship diagrams), ontologies, APIs also typically fit in here).
If necessary, also address changes in the system design that became necessary during the course of the quarter.

Implementation


Here you identify specific technologies, tools, languages, development methods or processes, and hardware aspects. Obviously there will be a close correspondence to the previous section. If necessary, you can also merge this section into the previous one, but then you should be careful to structure the combined section in an appropriate manner so that design and implementation aspects can still be identified separately. You should also address obstacles and implementation issues here, especially if they lead to changes in the design and architecture of your system.

Validation and Evaluation


This section should identify mappings between features of the system as described in the respective section, and the corresponding requirements. You should use the evaluation criteria identified there to measure or judge important aspects of the system, such as performance, response times, task completion times, responses to test inputs, or comparison against standards or similar systems.

User Feedback


If possible and appropriate, you should demonstrate your system to members of the intended user community, and collect feedback from them. This can include reactions to the user interface, comments on functionality of the system, or their impressions of the performance.

Conclusions


This section gives an overview of the system from the "hindsight" perspective. Typically it includes a discussion of features, performance aspects, interesting technical and implementation issues, lessons learned, and future work.

Project Documentation


I'm using this criterion to assess the use of the project wiki for the documentation of your work. I'm looking at aspects like structure of the Wiki, appearance, or spelling and grammatical errors.

Team Member Feedback


This is the outcome of the questionnaire with the feedback on your team as a whole, and on your team members. If you don't submit your evaluation of the other team members, your score will be significantly reduced.

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 all the work, but it is not enough). 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 Displays and Presentations


The final displays or presentations for the project will should demonstrate the overall work performed throughout the quarter. Typically it includes an overview of the project, some background information, relevant design, architecture and implementation aspects, a demo of the system, and user feedback collected throughout the development (if applicable). The final displays or presentations usually take place during the lecture and lab times of the last week in the quarter. In the case of presentations, there will be time limits based on the overall number of projects in each section of the class.

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. Up to 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 team members, you may not receive any points for this part.
We will have project displays or presentations around the middle of the quarter (Week 6 is typical), and towards the end of the quarter (Week 10). In-between (Weeks 2, 4, and 8) there will be project reviews during the lab sessions, where I review the respective project documentation with each team.

Project Grading Scheme

  • Project Overview, Background, Difficulty and Relevance: 10% (Week 2; Team 1 is first)
  • Features, Requirements, and Evaluation Criteria: 10% (Week 4; Team 3 is first)
  • System Design, Architecture and Implementation: 10% (Week 4)
  • Display/Presentation I: 20% (Week 6; Team 5 is first)
  • User Feedback: 10% (Week 8; Team 7 is first)
  • Validation, Evaluation, Conclusions: 10% (Week 8)
  • Project Documentation: 10% (Week 10)
  • Display/Presentation II: 20% (Week 10)
  • Mutual Team Member Evaluation: 20% (Week 10)