CS-305(a): Software Development Project

This course (SDP) requires that you take CS-305 Software Engineering (SwEng) at the same time. If you insist on taking SDP without SwEng, you must first contact us and explain why.

In this course, you design and build an Android app in groups of 6 students coached by a team of two staff members. This project provides an opportunity to apply the techniques and processes presented in the lectures to the development of a real-world software application. This exercise is challenging on many levels, because developing high quality software is difficult.

Please see the main course page for course information.

App Requirements

You will build an Android application of your team’s own choosing, written exclusively in Java. The application functionality is up to you to choose, but the design and implementation must fulfill all of the following requirements:

  • Split app model: Must use cloud-based services (e.g., Google maps, Firebase). Do not write your own server, because it introduces added complexity and is rarely a good idea anyway, given the richness of existing cloud services. If you do want to write one, then it must run on a public cloud platform; by no means can you run it on privately managed hardware.
  • Phone sensors: A typical smartphone provides GPS, camera, mic, etc. Your app must make sophisticated use of at least one of these sensors.
  • User support: The app must support the concept of users, and provide means of authenticating users. You may use one of the major authentication services (Google, Facebook, etc.) or EPFL’s Tequila OAuth2.
  • Database access: Android offers a wrapper around SQLite for local database access. Your app should make sophisticated use of this local database (e.g., use it as a cache for cloud-based data, or to store user settings).
  • Automated test suite: Your app must have from day one a test suite that can be executed by running a single command on the command line. You must maintain a minimum level of 80% code coverage.

Scrum

All teams to follow the Scrum software development process. This technique is a form of Agile software development introduced decades ago as a reaction to 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 initial lectures.

In our version of Scrum, the project will be developed in sprints that are 1-week (occasionally 2-week) long. At the start of a sprint, the team gets together with their “customer” (impersonated by a coach) to decide on the set of features that will be implemented in the coming sprint. The list of features is prioritized by the customer, and every member of the dev 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 1 week of effort must be split into a collection of simpler features.

Weekly sprint reviews and planning with the coaching team are mandatory. The coaching staff member will be acting as the customer for the application that the team is developing. In the meeting, the team will demonstrate the progress they achieved over the past week and will negotiate the set of features that they will deliver in the next week. You will be graded on your contribution to each week’s sprint and participation in the weekly meeting. Each team will have a specific time slot and location on Friday, to be determined after team formation.

During a sprint, the team must have a minimum of 2 stand-up meetings per week, where everyone on the team reports on status and blockers, and plans for the next couple of days. Meetings can be done in-person or over video-conference, but not over IM or Slack (i.e., the meeting must be live).

The list of sprint tasks does not change during the 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 demos 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 frequent meetings ensure that everyone on the team knows how their project is progressing and makes them quickly aware of difficulties.

Management

You should rotate the “administrative” role among students on the team; the admin in this case simply makes sure things are on-track, the stand-ups take place, etc. Other than that, there is little management, because the team as a whole shares the responsibility for the work getting done and for the final product being of high quality. Joint responsibility can be a problem when a team member is unable or unwilling to fulfill their responsibilities ‒ it is the rest of the team that is responsible for resolving such situations. The requirement that everyone implement at least one feature per sprint and the presence of two SwEng staff members 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 and the value that the rest of your team puts on those contributions.

Source code version control

Each team must keep their code and test cases in a GitHub repository, and give suitable access to the course staff. The staff will regularly check out the mainline version, build it, run the test suite, and try out the app. 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.

Testing

Throughout this project, we will evaluate the team not only on the code written but also on 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.

Battle of the Apps

At the end of each semester we hold a competition in which teams get to show off their apps. We have prizes for the top three winners.

Here are some of the apps that did well in the competition in previous years:

  • HouseView360 – A virtual reality app targeted at real estate agencies and their clients, enabling virtual visits of apartments for rent (see the video)
  • Runnest – An app to challenge your friends around the world to 1-on-1 running races with real-time tracking and updates.
  • SpotOn – Ephemeral photo sharing app enabling users to discover popular photos taken nearby (think Snapchat meets Google’s “Near-me-now”)
  • PolyLove – A dating app to help EPFL and UNIL students meet
  • Love at first song – An app that shows you who’s listening to what music nearby
  • Tutosaurus – An app to help students find tutors on a variety of subjects

Collaboration policy

Members of a team are of course 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 written/emailed permission of the instructor (not the coach!). We will actively try to identify reusable components in the various projects that we believe could be useful to share with 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 class 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 not appropriate to ask for the answer to a question posed by the staff directly to you, say in a 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 whether an action on your part is acceptable, please ask the course staff privately via sweng-staff@googlegroups.com before proceeding. Asking afterward is too late.