The centerpiece of CS305 is a team project to design and build an Android app. This project will provide an opportunity to apply the techniques and processes presented in the lectures to actual software development. You are likely to find this exercise to be challenging on many levels, because developing high quality software is difficult. 

The App

You will build an Android application of your team's own choosing, written exclusively in Java. You must write a proposal and post it to Discourse by the due date of HW1. The application functionality is up to you; the app must fulfill the following implementation requirements:

  • Split app model – Must use cloud-based services (e.g., Google maps). You can write your own server that runs on a public cloud platform, if you wish.
  • Phone sensors – A typical smartphone provides GPS, camera, mic, etc. The app must make reasonably sophisticated use of at least one of these sensors.
  • User support – The app must support the concept of users, and provide means of authentication. By default, we recommend using EPFL's Tequila (which implements OAuth2). Alternatively, you can use Google authentication.
  • DB access – Android offers a wrapper around SQLite for local database access. The application must make reasonably sophisticated use of this local database (e.g., to use it as a cache for cloud-based data, or to store user settings)
  • Automated test suite – The application must have from day-one a test suite that can be executed by simply executing one command on the command line. The staff will be tracking code coverage obtained by the test suite.


We require all teams to follow the widely popular software development process called scrum. This technique is a form of Agile software development, which is a movement started around 15 years ago as a reaction against rigid and hierarchical development paradigms. Agile methods are well suited to small teams working in short development cycles, doing iterative software construction, minimal management, and relying a lot on testing. We cover this development process in-depth during the second lecture.

In our version of scrum, the project will be developed in week-long intervals called sprints. At the start of a sprint, the team will get together with their customer or product owner (a TA) to decide on the set of features that will be implemented over the next week. The list of features is prioritized by the customer, and every member of the team is responsible for implementing at least one feature per sprint. Consequently, features need to be sized so they can be built, tested, and integrated in one week. Complex features that might require more than one week of effort can be split into a collection of simpler features.

During a sprint, the team should have daily stand-up meetings where everyone on the team says what their status is (1 min. max) and if they are facing any difficult challenges that are blocking him/her. This meeting can be done in-person or over video conferencing (e.g., Skype).

The list of tasks should not be changed during a sprint. If a feature cannot be implemented, then it should be deferred and another feature from the list completed in its place.

At the end of a sprint, the team demonstrates to its customer the features that were implemented and discusses the ones that were not fully completed, both to understand if they made a mistake in estimating the amount of work that a feature required and to decide if an unimplemented feature should be rolled over to the next sprint or dropped.

The process is both lightweight and flexible. The features can be almost anything that has a tangible outcome (e.g. implement a prototype UI with given functionality, add encryption to the data storage, add function X, Y, and Z to the UI, etc.) The rapid development cycle forces you to break a big project into small, manageable pieces. The daily and weekly meetings ensure that everyone on the team knows how their project is progressing and makes them quickly aware of difficulties.


You should rotate the "managerial" role among student on the team; the manager in this case simply makes sure things are on-track, the stand-ups take place, etc. Other than that there is little management, rather the team as a whole shares the responsibility for the work getting done and that the final product is of high quality. Joint responsibility can be a problem, for example when a team member is unable or unwilling to fulfill their responsibilities -- this is where a manager comes in handy. The requirement that everyone implement at least one feature per sprint and the presence of a TA at weekly meetings provides strong pressure for everyone to contribute to the project. Your project grade reflects not only the success of your team but also your contribution as an individual. 


A student’s grade on the project consists of two components. The first, worth 70% of the grade, is the team grade, which is based on the quality of the team’s app, in terms of functionality, correctness, and robustness according to this rubric: 
  • 1/3 Functionality – The behavior of the app. Does it accomplish a compelling, interesting, useful, or entertaining task? Is it attractive? Is it easy to use? Would I want to buy it?
  • 1/3 Correctness – Does the app work properly? Does it produce correct answers? Does it handle incorrect inputs and intermittent connectivity properly? Is the app resilient against malicious attacks? Does it handle intentionally malformed input properly? Are there sufficient test cases to demonstrate these properties? 
  • 1/3 Maintainability – Is the code clearly written? Are the abstractions well thought out? Does the code follow defensive programming practices? Does it follow a coding convention? Does it use design patterns where appropriate? Are the test cases complete enough to allow for future restructuring? 
The other 30% of the grade is your individual grade, which is assigned by the TA based on the features implemented by an individual, as observed in team meetings, by examining check-in code, and by testing the features implemented by the student.

Someone who does nothing on a team that produces a beautiful app will start off with a barely passing grade and will lack the practical knowledge to pass the midterm and final. So, everyone needs to participate fully in their team’s efforts.

Similarly, a team that does a minimal amount of work and produces a barely functioning app will see many points disappear. This may seem unfair to a hard-working member of the team, but it is the way the real world works. There is a saying that "there are no winners on a losing team." Part of this project, like any team exercise, is to work effectively with the other people and get them to do their best work.

Source Control

A team must keep all of their code and tests cases in a git repository on GitHub. The course staff will have access to these repositories and will regularly check out the mainline version, build it, run regression tests, and run the code. We will also randomly check the build status of the master branch of your project repository. Please keep this version up-to-date and quickly fix build breaks -- every time that a staff member encounters a broken build, your team will lose points.


Throughout this project, we will evaluate you not only on the code you write but also the test cases that you produce to test your code. This includes both unit and integration tests, black-box and white-box tests. A beautiful piece of code, even if perfect, that lacks test cases will get a minimal score on the correctness and maintainability aspects of the grading rubric, so please test thoroughly. 

Project Ideas

Below are a number of suggestions for apps that you and your team might want to build. They also should provide you with an idea of the scope and ambition of a reasonable app for this course. Treat these ideas as a starting point for your own app and find something that is interesting and compelling to your team. 

  • Synchronize Google contacts with Facebook friends on a phone. 
This project requires communication with various third-party APIs, but also requires some UI design and potentially clever matching algorithms. 
Social Contact Photo Sync is an existing app with similar aim. 
  • The theme of synchronizing personal data with third-party sources gives rise to a number of other ideas. Apps could, e.g., fetch album art for a music collection or automatically insert Google calendar entries according to students’ is-academia timetable.
  • Phone support for a password management system like or is a project with special security requirements. 
  • An app for personal time tracking. It needs a streamlined UI. Exporting data (e.g., in form of a calendar with differently-colored events) requires student to handle third-party APIs. 
  • An app that helps students in their studies by fighting procrastination? Multiple app users could team up, commit to tasks, and hold each other responsible. This app might be useful for a team in this course.
  • Apps to help the Red Cross in its humanitarian activities.

Collaboration Policy

Members of a team are obviously allowed to discuss the project and share code for it. Members of different teams can discuss their project and programming problems, but they are not allowed to share code without prior permission of the instructor. We will look for reusable components in the various projects that the staff believes might be useful to other teams. A team that agrees to share a component of this sort will receive a bonus in the grading or their project.

Collaboration can also take place on the forum, visible to the entire class. In this setting, it is permissible to answer questions about the course, programming difficulties, issues with the tools, questions about the lectures, etc. It is obviously not appropriate to ask for the answer to a question posed directly to you, say in an on-line quiz. But if, for example, someone encounters a strange error when compiling their Java program and posts it, and you know how to fix it, please share your insight on the discussion group. Such active participation will be noted and positively appreciated by the course staff.

Cheating, plagiarism, and any form of dishonesty will be handled with the maximum severity permitted under EPFL rules; in most cases, this will result in being expelled from EPFL. If you are in doubt if an action on your part is acceptable, please ask a private question to the course staff on before proceeding. Asking afterward is too late.

Subpages (1): SwEng Coding Conventions