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.Project Theme: AI and Matching
In the F15 quarter, the project topic should be related to the theme of Artificial Intelligence and Matching. For more information on this, see the draft document on Matching and AI.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 Organization
Collaboration with Munich University of Applied Sciences (MUAS)
This project will include with teams of students from MUAS, coordinated with the help of the Strascheg Center for Entrepreneurship (SCE) affiliated with MUAS. In Munich, students from different disciplines will work on related projects: Software Engineering students will go through the implementation of a front end using an agile development method (adapted SCRUM), design students are responsible for the appearance and user experience, and business students will investigate commercial aspects of the projects, including a business plan. Similar projects conducted with SCE have resulted in startups, and some of them are now commercially viable businesses.Our contacts in Munich are Ms. Ebru Turgut-Dao from SCE, and Prof. Gudrun Socher from MUAS. To keep the collaboration overhead manageable, we decided to have Cal Poly 480 students develop "matching engines" accessible via the Web through an API. This also allows for the preservation of intellectual property since Cal Poly students can keep their actual code confidential, while allowing the students in Munich to use the functionality provided by the matching engines.
The students in Munich are on a different timeline; MUAS is on a semester system with a slightly later start date. Their winter semester begins on Thursday, October 1. For the business and design students, it is important to have a non-technical overview of the Cal Poly projects so that they can already start their work. The software engineering students will start the implementation work a couple of weeks later, but they need more detailed technical information.
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.
Code and Documentation Repository
We have set up a github "organization" repository for the code and documentation of the projects. Access information will be provided through PolyLearn or Piazza.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.