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.

Staff:

First lecture: On Discord at 09:15 (see Moodle announcement and agenda)

Details

  • At the beginning of the semester, you will form teams of 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 and coherent with the Android experience.
  • 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.

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.

Your individual grade is based on your own week-to-week work:

  • Contributions: Did you get something done? Is the code readable and robust, including tests? Did you have good ideas? Were you a problem solver?
  • Teamwork: Did you help your teammates, such as by reviewing their code? Did you go the extra mile?
  • Management: When you served as a Scrum Master, was the team able to work smoothly? Was the team’s demo compelling?

Your team grade is based on your team’s overall result:

  • Functionality: Does your app perform a useful and compelling task? Is it easy to use? Does it look like a native Android app?
  • Dependability: Does your app work? Is it resilient to user error and malice? Is it resilient to outside issues such as poor Internet connectivity? Is there a test suite to demonstrate this?
  • Maintainability: Does your code use proper abstractions and patterns? Does it follow a consistent coding convention? Could someone else take over and be productive?

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.

We’re also 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 real apps, and they will pitch these projects to you.

Here are some examples of apps from previous years:

  • Fly2Find helps rescue victims of avalanches using drones
  • PolyBazaar, a marketplace for and by EPFL students
  • Favo, an easy way to give and receive favors
  • Run0rD1e, a distributed multi-player game
  • 360 Estate, a virtual reality app for virtual visits of rental apartments
  • Runnest, an app to challenge your friends around the world to 1-on-1 running races with real-time tracking and updates
  • SpotOn, and 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
  • Tutosaurus, an app to help students find tutors on a variety of subjects

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.