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.
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:
ScrumWe 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.
GradingA 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:
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.
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.
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.
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.