The types of projects that students have successfully completed include mobile apps, web apps, software/hardware interfaces, machine learning, data mining, computer vision, natural language processing, visualization, and etc.
A typical team consists of four senior-year students. They work on your project for two quarters (from early Jan. to early June). Students entering this class typically know some computer languages well and can quickly pick up new languages/tools/skills. They are motivated to learn and to work on real projects. That means they can typically develop a decent prototype.
We have 50-70 projects and 20-25 teams each year. Here are some tips to make a project more appealing to students. 1. We distribute all project descriptions to students – that is a lot of reading. Therefore, a clear and concise project description helps. A good title also helps. 2. Students tend to like projects that they can relate to. So, it helps to motivate the project well and avoid a lot of jargons. 3. We distribute the project list based on the submission date. So, submit early if you can. 4. Allow students to contact you before project matching for clarification. (To respect your time, our default mode is that students can only contact you if they are matched to your project).
University policies provide students intellectual property rights to their work. At the same time, we understand that sometimes to push a product further, a client may need to hold the IP. If so, we ask the client to clearly indicate this requirement in the proposal so that students can make their own decisions. This is entirely a team’s decision. If a team finds a project interesting enough and they want to see it go further after their graduation, they may choose to let the client have the IP.
Please make sure that you or your delegate have at least 30 minutes every one-two weeks to meet with student teams. This is the most important predictor of project success. Students are most motivated when they get your consistent feedback and know that you care about the project. Most of our projects can deliver at least a viable product. Some are now in production. However, this is a class where students learn. As in any other classes, trial-and-error is a part of the learning, also we have A+ outcome as well as C outcome. We do not have the ability to maintain a project after the class. Therefore, this class is most suitable for 1) prototyping; 2) trying crazy ideas; and 3) if you can do at least a minimum level of maintenance after the class.
We share the collected projects with students in mid. Dec. so that they can think about what interest them and start to form teams. In the first week of the Winter quarter (early Jan.), the projects are “officially” announced. Students form teams and submit their interests by the end of the first week. I match projects to student teams based on their interests and capability. In the second week (Jan. 10-15), they receive their assignment and will immediately contact their client.
If your project is matched, you will be contacted by the student team during the second week of the Winter quarter (Jan. 10 - 15). If your project is not matched, I will inform you in the third week of Jan. (~Jan. 21).
We have this class every year. It is not uncommon that a project that is not matched in a previous year is matched in a subsequent year. If you are interested, I am happy to contact you again for a future submission.
As soon as the project is matched. The student team will contact you to set meetings. Your student team will meet with you every one/two weeks, initially to understand the project and then to update their progress. The first one/two meetings are important in hashing out the detailed requirements of the project. We (TA and me) meet with the team every week for discussion and progress update. By the end of the first quarter (mid. March), we expect the team to deliver the alpha version, which is a bare-bone prototype with key functionalities. Play with the product and see whether the functionalities suit your needs and what else is needed. I will also ask for your feedback. The team continues the development in the second quarter and delivers the beta-version (early May), which is considered outside-user-test ready. Test the product and give feedback to the teams for additional tuning/debugging. They deliver the final product and documentations late May.
Meet with student teams regularly and provide feedback. We recommend once a week for 30 minutes. Your feedback is the best way to shape to the product to your need and to keep students engaged and motivated. Let us know if you have any questions/suggestions/feedback regarding the project progress, student communications, and the course.
