CS-306 Software Development Project

This is part II of the Software Engineering suite, following CS-305 Software Engineering (SwEng). In SDP, students implement in practice the concepts learned in SwEng. Students experience team-based software development, in a real-world setting. Teams of 6 students, coached by staff members, build an Android app over the course of the semester.

SwEng is a strict prerequisite for SDP. If you have a strongly justified reason for taking SDP without having taken SwEng, please contact us first to explain why.

Moodle: https://go.epfl.ch/sdp-moodle, with a forum for all public questions

Staff:

First lecture: ME B3 31 at 09:00 (see agenda)

Details

  • At the beginning of the semester, you will form teams of around 6 students and decide on an app idea you’d like to implement in the project, which must comply with the app requirements.
  • You will host your code on GitHub, starting from a code skeleton we provide, and using GitHub features for development and management such as issues, pull requests, and projects.
  • Every week, you will meet with your assigned coaches to demo your app, debrief about the elapsed week, and plan the next week, according to an Agile development process.
  • Weekly meetings are only for product management, but you can e-mail and meet your coaches to discuss human or technical issues outside the scheduled weekly meeting.
  • At the end of the semester, every team demos their app for the entire class, and everyone votes for their favorite apps. The teams that developed the top apps receive prizes.
  • You will be graded based on your work throughout the semester, your interactions with your team, and your final product, according to the grading rubric.

App Requirements

All apps developed in SDP must meet these requirements. Your team’s coaches will help you ensure your app meets them.

  • Correctness: All of the app’s features must work as intended, in a way that is clear to users.
  • Utility: The app must accomplish a compelling task, with clear use cases.
  • Split app model: The app must include some public cloud service, such as Google Firebase. In general, you are not allowed to write your own backend, but exceptions can be made in very rare cases that need to be approved by Prof. Candea.
  • Sensor usage: The app must use at least one of the phone sensors, such as the GPS, camera or microphone, as part of its core features. This means the app should make sophisticated use of sensor data, and not just read the data to store it in a field and forget about it.
  • User support: The app must support the concept of users, and provide authentication. We recommend you use the built-in Google authentication, but you can also use others such as EPFL’s Tequila.
  • Local cache: The app must store data on the phone itself, for instance using local files or a SQLite database, as a cache to avoid excessive network requests. This data must be meaningfully accessed at least once every time the app is used.
  • Offline mode: The app should work, perhaps with reduced functionality, even when no Internet connection is available. For instance, it could show data in read-only mode based on a cache.
  • Testing: Your app must have a thorough test suite, for both its core logic and its user interface, that validates its correctness. We expect you to have high test coverage at all times.

The reason we restrict the backend you may use is twofold: (1) your app should still be able to run many years from now, without a human having to manually set up a backend, and (2) it restricts the scope of your project to make sure that it is feasible within a semester. We are aware of the tradeoffs involved, such as security, privacy and vendor lock-in, but the scale of the course is such that we cannot cover these topics in the project. Remember that the technology stack is not what really matters, as we expect you to use modularity and abstraction to ensure you can change the technology underlying the backend without massive changes in the frontend. Design patterns will come in handy for that purpose.

Development Process

SDP uses a variant of the Scrum development process, which is based on the Agile principles that we taught you in SwEng. Scrum is well suited to a small team working in short development cycles with minimal management and lots of testing.

The project is developed by student teams in 1-week “sprints”. At the start of a sprint, the team gets together with the customer representatives, impersonated by coaches, to decide which features to implement in the upcoming sprint. The list of features is prioritized by the customer representatives, and every member of the development team is responsible for implementing at least one feature per sprint. Consequently, features need to be sized so that they can be built, tested and integrated in one week. Complex features should be broken up into smaller ones. At the end of a sprint, the team demoes the app to the coaches, again acting as the customer. Each team member then briefly summarizes their work for the elapsed week, including any work that was not completed. The team discusses any features that could not be implemented for the sprint, to understand if they made a mistake in estimating the amount of work required, and to decide if the feature should be rolled over to the next sprint or dropped. Each team will have a time slot on Friday for the meeting, which includes both reviewing the elapsed sprint and starting the next one. These meetings are mandatory for all team members.

During a sprint, the team should meet at least twice for “stand-up” meetings, where everyone on the team reports their status and whether they are blocked. These meetings should not last more than ten minutes; any issue identified during the meeting should be discussed later with the team members involved in the issue.

Features are developed individually on each team member’s machine, then put on GitHub as a pull request for the team to review. All code must have tests, and be reviewed by two other team members before being merged into the main branch of the repository. The main branch of the repository is the only one that the team can use to demo their app to the customer.

Each team member should “touch” all parts of the codebase over the duration of the project. It is not acceptable for a team member to have exclusive ownership of a piece of code, or to be the only one to know how it works.

Each sprint, one team members has the role of “Scrum Master”. The Scrum Master must ensure that the stand-up meetings happen, that work is on track, and that any difficulties are known by the entire team. The Scrum Master is also in charge of organizing the demo for the sprint review.

The process is both lightweight and flexible. Features can be almost anything with a tangible outcome, e.g., implementing a prototype UI with basic functionality, add encryption to the data storage, add some specific feature to the UI, etc. The rapid development cycle forces you to break a big project into small, manageable pieces, with frequent feedback so you are quickly aware of difficulties.

Grading

Your grade has two equally weighted components: your team grade (50%) and your individual grade (50%).

We reserve the right to adjust grades in cases that warrant this.

The team grade is computed roughly as follows:

  • Functionality (30%): Does the app accomplish a useful and compelling task? Is it attractive and easy to use?
  • Reliability and security (30%): Does the app work? Is it resilient in the face of incorrect or malicious inputs, intermittent connectivity, etc.? Is there a test suite to demonstrate this?
  • Code quality and maintainability (30%): Is the code clearly written, using proper abstractions and patterns? Does it follow a consistent coding convention? Are there tests to allow for safe refactoring?
  • Timely delivery (10%): Did the team finish its tasks on time, according to the team’s own estimates?

The individual grade is computed roughly as follows:

  • Contribution to the code base (50%): Did you do your fair share of the overall work, both in terms of creative and grunge work?
  • Project management (25%): As an individual contributor, did you deliver on your promises? Were you an effective Scrum Master? Were the team’s demos compelling during your leadership?
  • Teamwork (25%): Were you a good team player? Were your teammates able to rely on you? Did you perform good code reviews on time?

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 issues, but not share code without prior written permission of the course instructor (not the coaches!).

Collaboration can also take place on the class forum, visible to the entire class. You can ask questions about the course, programming difficulties, tooling issues, and so on. You are also welcome to answer questions from your fellow students as well, since you will most likely have solved similar problems in your team’s project.

Cheating, plagiarism, and any form of dishonesty will be handled with the maximum severity permitted under EPFL rules. If you are in doubt whether an action on your part is acceptable, please ask the course staff privately via the staff e-mail list before proceeding. Asking afterward is too late.

Agenda for Day #1

Here is the agenda for the first day of SDP:

1. Introductory Remarks

  • Course objectives and logistics
  • SDP bootcamp
  • SDP project requirements

2. Project Pitches

Students, staff, and outside groups will present to the class ideas for potential SDP projects, and interested students can join teams to work on these projects. If you have an idea you would like to present, make sure it satisfies the requirements and then send us a 1-paragraph description in order to sign up for a pitch slot on Friday.

For the first time in SDP, we’re making it possible for you to not only simulate but actually work on a real-world app for real customers. This year we have several non-profit customers who are keen to work with SDP teams on apps they need for their operations, and they will pitch these projects to you.

  • Ideas for projects from students & staff
  • Real-world projects:
    • Micro Air Vehicle (Drone) Communication [webpage]
    • Digitalization of the International Mathematics and Logic Games Championship [webpage]
    • Fréquence Banane apps for radio users and radio operators [webpage]
    • Balélec app for festival goers and organizers [webpage]

3. Team Formation

  • SDP teams consists of 6 students. If you already have a team in mind (or a partial team), then please coordinate with your teammates prior to Friday, and sit together in the lecture hall. Every member of the team must be currently enrolled in SDP.
  • We will use Moodle to record the teams. Please pick a representative name for your team.
  • Each team will receive an assignment in Moodle, where you will hand in the description of your project as your very first team task. You will have to explain how the proposed app satisfies the minimal requirements set forth above. This assignment will be due by the end of the first day of class (Friday).
  • Once we validated your projects, you will get an opportunity to sign up for your weekly 1-hour meeting slot with the SDP staff.

Examples of Apps from Previous SDPs

Here are some of the apps that were developed by students 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