Project requirements & deliverables

The project has a number of specific deliverables, each of which is described on its own page with a checklist of how to meet the deliverables:
  1.   5%   Iteration 0 (project setup)
  2. 60% Four regular iterations (14% each)
  3.   5% Design review (after iteration 2)
  4.   7% 10 minute Technical presentation (in section)
  5.   5%  Peer critiques of others' presentations
  6.   2% 2-minute Poster Preview (in lecture) — see past examples
  7.   3% Screencast demo — see past examples
  8.   3% Final checkpoint: project ready for maintenance
  9.   2% Attend Poster session (during dead week)—see past examples of posters
  10.  (8% discretionary: Project Handoff, GSI notes, customer feedback surveys, etc.)

Project FAQs:

  • What will the project be like?
    • Teams of 6 students will work with a real external customer (generally nonprofits and campus units) to design, plan, develop, test, and deploy a software-as-a-service application. Team size restrictions (both upper and lower bounds) may be given based on enrollment and other considerations.
  • Why will the project be super awesome?
    • You'll learn and use Agile/XP as the development methodology.  You'll use the same techniques and tools used by today's leading software companies, including Behavior-driven Design, Test-FIrst development, Agile/Extreme Programming, Pair Programming. Don't take my word for it; we will have industrial guest speakers, including recent Cal EECS grads now in the software industry, who'll tell you how it is.
  • Can the project use a language/platform/etc. other than Rails 4 for the back end and HTML5+JavaScript for the client?
    • Yes, BUT, you are required to have tools that perform all the following tasks, and your GSI must sign off that they have adequate visibility into what you're producing with those tools:
      • Unit & functional testing framework (we use RSpec for Ruby/Rails and Jasmine for JavaScript)
      • Test coverage measurement (we use Coveralls and Travis CI)
      • Full-stack testing framework that can express tests corresponding to user stories (we use Cucumber and Capybara)
      • Code quality measurement framework (help identify design smells, bad uses of style, etc.) (we use CodeClimate)
      • SaaS server-side framework for server apps (we use Rails)
      • SaaS client-side framework for client apps (we use HTML5+JavaScript)
    • Your project will be held to the same standards regarding test coverage, code quality, etc. as all others.  "Our tool doesn't measure test coverage well" is not an excuse.
    • If you use different tools than those we recommend, GSIs will not be responsible for helping you learn/install/use those tools.
  • What if the project is primarily a static-content website?
    • Projects must have some nontrivial functionality that would not be readily available in an off-the-shelf CMS such as Drupal, Joomla, WordPress, etc.  This is rarely true for static-content sites.
  • Can I write a mobile app instead?
    • It's OK to devote part of the overall project effort to a mobile client part, which we recommend prototyping in JavaScript+HTML5. But the process and testing requirements for that app will be the same standard as for the server side, and we do not plan to provide software, dev kits, or TA support of any kind for things like iOS and Android.  Also, all team members will be responsible for knowing, understanding, and contributing to the development of the server-side part, so you cannot be a "front-end only" developer on your team.
  • How will project groups be assigned?
    • As of Fall 2016, you must enroll as a team. 
  • Can projects be proprietary?
    • Berkeley rules say that your work is your own and you may do whatever you wish with it, including make it private. (But we've found that most customers that are nonprofits are very appreciative if they can continue to use the code.) 
    • During the course, your instructors, TAs, and even fellow students will need to see the project and parts of its code, and they will not be able to sign NDAs to do so.  (Note that content hosted on your project site can certainly be proprietary; you can construct fake/placeholder content for demos.)  
    • You will also be expected to use various tools to analyze your code: all the tools we recommend are free for public repos but most will charge for operating on a private repo, and such charges will be your responsibility exclusively. 
  • A colleague of mine has an idea for a project, or I have an idea for a project.
    • If it fits the above criteria, enroll it using Blueprint.
  • Can people not enrolled in CS169 be part of CS169 project teams?
    • No. 
  • But my favorite project partner is on the waiting list/not sure if they will get in!
    • Yeah, I know, that sucks. Unfortunately not much I can do about it. I really, really advise you NOT to depend on project team members who aren't enrolled in the class for credit. Seriously.

Have a question? Email the course staff or Prof. Fox and we can add the answer here.