This page describes the UC Berkeley campus course that inspired us to write the book and create the MOOC.
This is the only undergraduate course at Berkeley that claims to address the topic of Software Engineering. As such, it’s ambitious and fast-paced, with six 1-week programming assignments, 5 quizzes or two midterms (depending on that semester's format), and a significant open-ended team project with an external customer, all in a single 14-week semester. We expect students to be comfortable with at least one other OO language and with basic OO concepts (object orientation, classes and inheritance, etc.) and basic software abstractions concepts (data abstraction, procedural abstraction/higher-order functions, recursion, etc.) Prior to this course, Berkeley CS students take CS61A Structure & Interpretation of Computer Programs, which introduces the four major programming paradigms (until recently using Abelson & Sussman’s awesome "wizard book", now using Python); CS61B Data Structures using Java; and (usually) CS61C Great Ideas in Computer Architecture (aka Machine Structures), using C, MIPS assembly, and more Java (for a Hadoop assignment).
RAD Lab project (2006-2011), we needed SaaS apps to show off our machine-learning-based technology for automating various aspects of cloud operations. Since no Berkeley course taught SaaS, we created an informal seminar course in 2007 to bootstrap a cohort of undergraduates to create showcase apps using Rails. It was so popular that we offered it again, increasing the focus on TDD and good software practices, when our colleague Paul Hilfinger observed that we were well on the way to teaching the basics of Software Engineering in a format that students were enthusiastic about, so why not go all-out and teach CS 169 this way? We agreed, and we did a “dry run” of the beefed-up course in Fall 2009, debugged it, and offered the “SaaS version” of CS 169 for the first time in Fall 2010. Enrollments have been increasing by nearly 50% per offering, from 25 students in the experimental version in 2007 to 240 students in Fall 2013.
articles explain why we believe these choices bridge the gap between what academics believe should be covered in software engineering courses and what industry wants to see in graduates of those programs. (Contrary to what one might expect, leading software companies do not want us to become trade schools teaching specific tools, languages or frameworks; they want skills that transcend these, including dealing with legacy code and working in a team serving a nontechnical customer.) We chose Rails because it has the best testing and code-grooming tools and its developer community places high value on beautiful code and thorough testing. There are two lectures and one small-section meeting (~30-40 students) per week, weekly programming assignments, bi-weekly short-answer quizzes, no “big” midterm or final exam, and a 6 to 8 week course project. We are experimenting with pair programming as well.
The Berkeley Group and blueprint (to which Dave Patterson and I are faculty advisors) to identify external customers—some nonprofits, some on-campus units, some others—whose needs could be addressed in part by a SaaS prototype. “Two-pizza” teams of 4-6 students bid on the projects they’re most interested in and we match them up. During each of four 2-week iterations, students meet with their customer, use lo-fi mockups and user stories to agree on goals, use BDD and TDD to develop new functionality and tests, and deploy to the public cloud on Heroku. Per-iteration design/progress reviews with course staff (TA’s) help identify problems and provide technical guidance where needed; we have found no substitute for this critical part of the software craftsmanship apprentice process. Each team’s progress is publicly tracked and estimated (and visible to customer and course staff) using the free Pivotal Tracker throughout, and grading is based heavily on (a) demonstrated responsiveness to customer feedback on deployed functionality, (b) demonstrated improvement in ability to estimate how much work will be completed by end of iteration, (c) sound use of agile processes as demonstrated by BDD scenarios (which Cucumber turns into integration tests), good test coverage, and reasonable complexity and beauty metrics (cohesion, lack of code smells, etc.) on code, which is publicly accessible on GitHub for review by course staff at any time. At the end of the course, students present their work in a poster/demo session attended by course staff, the external customers, and invited guests such as industry practitioners and VCs. Many students reported that their customers were so delighted that they were trying to hire the students to continue the work over the summer. Two projects from Spring’12 were already deployed in production with real users by the time the poster was presented.
We’ve started gathering screencasts and customer interviews highlighting representative projects; more are being added all the time.
(Coming soon: aggregate code statistics for Spring 2012 projects, including test coverage & code cleanliness metrics)
massive open online course in Feb/Mar 2012, it forced the issue and made us sit down and write the autograders. Of course, these are no substitute for actual interaction with an instructor; indeed, the autograders have freed up our teaching staff to focus on creating additional review material and holding design meetings. (If you’re an instructor interested in having a SPOC that gives you access to these facilities in your own classroom, we're ready to help.)
(Thanks to head TA Richard Xia for this info.) The course is approximately split into two halves, with homeworks and quizzes dominating the first half and the project dominating the second half. During the first half, each TA runs a discussion sections of ~30 students (1-2 hours/week + 2-4 hours to prep and review material), holds office hours (2 hours/week), monitors the online question forums on Piazza (4-6 hours), and miscellaneous tasks such as individual emails and handling regrade requests (4 hours). In addition, for the first offering of the course the content creation included not only homeworks, quizzes, and section material, but the grading rubrics for the autograders for each type of evaluation. For the second half of the course, we converted most of the discussion sections into project meetings with the students in which we met with each group for about 10 minutes each week, so less time was spent preparing homework/quiz material and the section-prep time was replaced by evaluating project checkpoints. A few additional hours per week were spent managing the online course, but as we fine-tune the material and autograder logistics, we expect that the online course can be managed by a single 10-hour-per-week TA, leaving the CS169 TAs free for for direct interactions with the students, especially during the project.