Group Projects

Group projects are your opportunity to practice the principles you learned in lectures and individual assignments, and the tools you learned in the course material available in this website.

You form groups of 5 or 6 students and work on a project of your choosing throughout the course. While we recommend that you use the tools in the Toolbox, your group is free to use almost any tool you want. A staff member is assigned to your group as advisor, helping to find the right project for you, and trying to solve any technical difficulties along the way.

The work is divided in iterations that last two weeks. Each iteration comes with a set of goals, and your advisor reviews your progress at the end. While each iteration has its own goals, you may have to work on all aspects of your application in every iteration. For example, the goal of Iteration 1 is design, and the goal of Iteration 6 is implementation, but you may have to do some implementation work in Iteration 1 to wire different libraries together, and you may have to do some design work in Iteration 6 if the implementation changes some decision in the design. We favor an agile approach over a waterfall one.

Laboratory Sessions

This is in-class time for you to work on your project, discuss your progress with your advisor, and so forth.

⚠️  You must read the page for the current iteration before the laboratory session and come ready to work on the project.

⚠️  You must go to the room assigned to your group, which may not be our usual classroom.

If you still haven’t formed a group by Laboratory Session 1, or if your group is still looking for more members to reach the 5-person minimum, go to our usual classroom ready to discuss your project proposals with other students.

Presentations

You must present your project twice throughout the course:

Both presentations follow a similar format:

Demonstration: Demonstrate the distinguishing features of your application that are already working. Don’t show obvious features such as user signup and login, data input, and so forth. Use real fake data in the demonstration—don’t use filler text (lorem ipsum).

Project Proposal: What problems does your application solve? How does your application solve them? How is your application different from competitors? And so forth. The best way to cover these topics is to work them into the demonstration.

Design: Cover the architecture, the class diagram, and so forth.

Code Review: Give a brief code review, highlighting the most interesting parts of the implementation, and connecting them with the features discussed above.

Recommendations for a Good Presentation

• Prefer a live demonstration, but have a recorded one as a backup. As a last resort, show screenshots or wireframes.

• Every group member must talk at least a little.

• Only talk about the distinguishing features of your application, not about the data-manipulation ones.

• Only talk about features that you built, not features based on third-party APIs and other tools.

• Avoid slides. They’re usually a bad way to present.

• Go to the presentation room before the presentation to test the projector and whatever other hardware and software you’re using, for example, the software to mirror a phone into a projector.

• Have fonts that are large enough, particularly for class diagrams and the code review.

• Practice, practice, practice. In particular, practice the transitions from one speaker to the next.

• Improve your presentation skills by following the recommendations in speaking.io, by taking the courses on presentation skills offered by the university, and by reading books such as The Art of Explanation and Presentation Zen.

Submission

By the end of each iteration we collect whatever you have at the master branch and evaluate that. There’s no extra steps you have to take to submit, just make sure the code at the master branch is in a good state: all the branches that should have been merged are merged, the tests are passing, and so forth. Also, keep the project board up-to-date and document your progress with issues, pull requests, and so forth.

Examples

You must work on your own ideas—the following examples are only to help you gauge the scale of project suitable for the course. See our discussion on difficulty.

Semester.ly: An application that helps students find courses and come up with a schedule. This application was developed by a group formed in OOSE, but they actually developed it after the course. Your application doesn’t have to be as polished as Semester.ly, and it doesn’t have to be so broad in scope (for example, it may not support multiple universities, and it may not scrape data form the university’s database automatically), but it must be at the same level of maturity. You could develop something like this using only the tools in the Toolbox.

Guitar-Hero-Like: In 2018 we had a successful group work on an application that was a game similar to Guitar Hero, but for Android and playable on the touchscreen, as opposed to on a guitar-like controller. Their game had a note editor to create levels, and could find the beats to match the taps in a song given by the player. Also, the timing of the taps and the animations on the screen were fairly sophisticated. To develop something like this, you’d have to use tools beyond the Toolbox, including Android, and music libraries.

Auditioning Musicians: Also in 2018 we had another successful group working on an application related to music. This time the problem was finding musicians to join a band. The application would issue challenges like playing certain scales, record the applicant playing the challenges, and then analyze the result to determine how well the applicant did in terms of timing and pitch. To develop something like this, you’d have to use tools beyond the Toolbox, including libraries for audio analysis.