Guidelines

You and your team will be designing and building a non-trivial desktop or mobile application that solves an real-world problem. You will spend the first few weeks determining the target users for your application, defining an interesting problem to solve for them, and designing features to address it. You will spend most of the term iterating on your project: designing, implementing and delivering these features.

We will provide you guidance through the process! In lectures, we will discuss team-practices e.g., how you should work together, how to track a project, and development-practices e.g., how you should structure your code; how to synchronize data with a database; how to write unit tests. We’ll introduce technical topics, and even provide samples code and demo how to do things during labs.

You will provided time in-class to work together, and course staff will be present to help. You will also be assigned a TA who will act as your user; periodically you will need to demonstrate your progress to them, get their feedback and incorporate that feedback into your designs.

Purpose of this Document

In this course, you are assessed on the quality and completeness of final product, but also on how you work together.

This document describes how you are expected to work, both individually and as a team. The topics below are all taught in this course, and you are expected to apply them during the term.

For details on what you need to deliver, see the requirements instead.

Topics

Topics listed here are discussed in-class. Note that some are very brief e.g., you must hold team meetings, while others represent substantial policies e.g., everyone should write unit tests. All are important.

If we discuss it in-class, it’s because we want you to use it in your project!

Team Composition

You will work in teams of four. The following constraints apply when forming teams:

• Team members must be registered in the same course sections.
• Everyone is expected to be on-campus for the term.
• Everyone agrees to meet regularly and attend project activities in-person.
• Team members must agree to a team contract that you will establish when you setup your project.

See form a team for details on forming and registering a team.

Best Practices

You and your team must use software development and project practices that are discussed in-class. Required practices include:

• Project tracking. All project assets including source code must be stored in a GitLab project.
• Team meetings. You and your team will meet at least twice per week. You must keep minutes of these meetings.
• Tracking your work. You are expected to keep a developer journal, and you must log details of your work as issues in GitLab.
• Code comments. You are expected to add code comments where appropriate and useful.
• Unit testing. You must write comprehensive unit tests to accompany your source code.

See best practices and lecture slides for details on each of these practices.

Technologies

You must use the following technology stack.

• Kotlin as your primary programming language. SQL is also allowed where appropriate.
• Gradle must be used for building the project, executing unit tests, and running your application for demos and testing.
• Compose Multiplatform and/or Jetpack Compose should be used for building user interfaces.
• JUnit and the Kotlin test extensions should be used for unit testing.
• SQLite should be used for database requirements.
• Ktor should be used for networking and web api requests.

Any deviations from this list must be approved by the instructor in writing, and the email chain should be included in your project documentation. Unapproved deviations will result in a significant penalty.

See toolchain for more details on this tech stack.

Design

You are expected to leverage the concepts that we will discuss in-class:

• Design a layered architecture, using MVVM. Clean Architecture is also allowed with instructor permission.
• Demonstrate design principles that we discuss in lectures e.g., loose coupling, high cohesion.
• Use suitable design patterns that will be demonstrated and discussed.

These topics will be addressed in lectures.

Exceptions

You are not allowed to deviate from these Guidelines without explicit, written permission from the instructor.

Requesting an exception

If you wish to deviate for any reason, (a) discuss with the instructor first, and (b) if informally approved, email them for a formal, written confirmation of the deviation, and finally (c) include that confirmation email in your project documentation.

Deviating without written permission will result in a significant penalty to your grade.