Project Overview


The term project is an important part of this class, and provides an opportunity to practice some of the methods discussed in class, and described in the literature. Some of them will be done in collaboration with outside partners.
The emphasis of the project is on the user interaction and user interface aspects, not so much on the underlying functionality. The project work may also focus on a usability evaluation of an existing product or system, and the design of an alternative interaction paradigm or user interface for that system.

Project Topic


I have a list of possible project topics for the class, including some involving outside partners. During the first or second week of the quarter, the teams select their topics, either from that list, or based on their own ideas (subject to instructor approval).

Project Organization


The project is a team effort, with a team size of about five people. Ideally, your team should be the same as for the assignments. Typically, each team will use an online repository (Google Docs, Dropbox, Github, etc) for project materials. Depending on confidentiality constraints with outside collaborators, teams may also use more secure arrangements for their repositories. The following sections identify the main parts of the project. For the the assessment of the team project, I usually use rubrics on PolyLearn. You can view them in a Google docs Rubrics spreadsheet. Not all rubrics may be available initially, and they will be based on the short descriptions given below. I’ll do the actual scoring of the system on PolyLearn with abbreviated versions of the rubrics that contain only categories and rating labels (like “good” or “excellent”). In the past, I’ve included the details in the PolyLearn rubrics directly, but this makes them rather unwieldy to use.

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 (out of 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 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. If you’re using an agile development model, you will probably go through multiple cycles of implementation -> validation and evaluation -> user feedback, either until the system is reasonably stable, or the quarter is over.

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.
AssignmentProject Wiki and Documentation Repository Assignment
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.
AssignmentTeam Member Feedback Assignment
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.

Project Grading Scheme


The overall score for the project is 40 points; 30 come out of my evaluation of the team project, and usually every team member gets the same score. If there is a clear discrepancy between the contributions and performance of the different team members, I may give individual scores for team members. My score will take into account feedback from external customers, but their scores will not go directly into my grade calculations. Up to 10 points come from an evaluation of your team mates, calculated as the average of all your team mates' scores for your contributions. Students who do not submit this mutual team member evaluation may receive a score of 0 for this part. However, I may adjust this part, especially if all team members give each other the highest score, but the overall quality of the project is not correspondingly high.
  • mid-quarter project display: 10%
  • final project display: 10%
  • project documentation: 10%
  • mutual team member evaluation: 10%