Spring Quarter 2005: March 28, 2005 - June 3, 2005
Catalog Description: A study of software engineering techniques for the development, maintenance, and evolution of large software systems. Topics include requirements and specification; system design and implementation; debugging, testing, and quality assurance; reengineering; project management; software process; tools; and environments.
Prerequisite(s): CS 141: Intermediate Data Structures and Algorithms. You must have good programming skills as well as reasonable writing and presentation skills to pass this course!
Time Requirements: Four units (12-16 hours/week): lecture (3 hours/week), laboratory (3 hours/week), individual study (6-10 hours/week; includes reading, writing, and hacking).
Instructor:
Peter H. Fröhlich
Office Hours:
Monday, Wednesday, Friday, 5:10 pm - 6:00 pm
(email for additional appointments)
Location:
Surge,
Room 341
Lectures:
Monday, Wednesday, Friday, 12:10 pm - 1:00 pm
Location:
Sproul Hall, Room 2340
Assistant:
John Anderson
Office Hours:
Location:
Surge,
Room 282
Lab:
Friday, 2:10 pm - 5:00 pm
Location:
Surge,
Room 170
Assistant:
Dragomir Yankov
Office Hours:
Location:
Surge,
Room 282
Lab:
Tuesday, 6:10 pm - 9:00 pm
Location:
Surge,
Room 170
Mailing List: cs180@lists.cs.ucr.edu (Archive)
Note the word tentative above. Things seldom go according to plan, and I expect changes here and there as we go along.
Lecture:
Reading:
Deadlines:
Lecture:
Project: The XP Spike
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
Lecture:
Reading:
Deadlines:
You are expected to do the assigned reading before a topic is covered in lecture or lab. Reading assigned in the week of an exam is part of the exam! Please try to read ahead, you'll be surprised how much more sense the lectures make...
The department's programming guidelines make for quite interesting reading, often highly relevant to this course.
There are three separate things to turn in for each of the three milestones (i.e. requirements, design, and product):
Your overall score for a milestone is made up of your scores for each of these three components: 25% for your draft, 25% for your review of another team's draft, and 50% for your final version.
Your day-to-day development will follow an agile development process: eXtreme Programming (XP). Using XP, you will continuously work on all aspects of your project: requirements, design, implementation, and testing.
Development occurs in weekly iterations: Each week, your leads (or all of you, depending on your client's preferences) meet with your client to report what you have achieved, demonstrate the current version of the system, discuss the requirements, and come up with a plan for the next iteration. Clients report to us what they think of your progress, how well your team works, and (of course) how they like the product you give them.
The iterative development process obviously has to start somewhere, and it does so with Iteration 0 in week 3. Before your first client meeting, you should come up with some initial requirements, a rough design, and maybe even a sketchy first attempt at test cases and implementation. After your frist client meeting, you should have a number of approved and prioitized user stories, initial estimates for how long they should take, and generally an idea what to do. You are now in Iteration 1, trying to make the initial user stories work, and you should be ready to demonstrate what you achieve in your next client meeting. Obviously each team will be on a somewhat different schedule depending on when it has its client meeting. That's okay!
The only thing "special" about Iteration 1 in week 4 is that you must have working code to demonstrate. You have been warned... You will also compute your development velocity for the first time, depending on what you have achieved since the Iteration 0 meeting.
In week 9, each team will have its "final" client meeting at the end of Iteration 6. This particular meeting might last somewhat longer than earlier ones because you'll do a project retrospective with the client. Your goal is to leave a very happy client when you step out of the meeting, one who can't wait to send us enthusiastic email. :-)
There are four possible project areas for this quarter's CS 180 course. The following descriptions define the general goals of each project area. Within that general setting, clients and developers have quite a bit of freedom as to the direction they choose.
There is one fundamental constraint for all projects: Whatever you are building must be portable among Linux, Windoze, and Mac OS X. If you can't test your project on all these platforms for some reason you need to contact us about it early on.
Implement a graphical, document-based spreadsheet application
with enough basic features to support recording of scores and
computation of grades for university courses.
The focus of this project is not just the spreadsheet itself,
but rather the requirement that it use an XML file format that
can be versioned in a meaningful way in CVS, Subversion, and
similar systems that are based on merging instead of locking.
Particular efforts should be made to ensure that changes made
to a spreadsheet through the application result in only "minimal"
changes to the existing XML file; no unnecessary "reordering"
of whole sections of the file should happen for example.
Also, the application should be able to display the results of
a diff between two versions of the same spreadsheet
in a way that supports conflict resolution in a user-friendly
way.
Implement a graphical, document-based circuit simulator with a variety of analysis features. On the most basic level, circuits consist of logic gates only, with "switches" to set up certain bit patterns as inputs and "LEDs" to show the output. Various types of latches should be supported as well, allowing things like shift-registers being built. It should be possible to save circuits as "black boxes" or "integrated circuits" that can in turn be reused in other, bigger circuits. Circuits are built by starting with an empty "board" and then dragging/inserting various components onto the "board"; then wires are used to connect the components. You get the picture... :-)
Examples for more advanced features include timing diagrams, hazard analysis, circuit manipulation (i.e. transformation to CNF or DNF), VHDL output, etc. etc.
Implement a generic and extensible content management system that can be used to establish and maintain an organizational website without having to hire web designers and such. In other words, the system should allow members of an organization running the website to add new articles or news releases and rearrange the content of the website through a user-friendly web interface. A web designer or other expert should only have to be involved to set up the initial design (in the form of several HTML templates and CSS style sheets). The system should be simple to install, and its requirements in terms of web servers or database servers should be minimal (and therefore flexible, i.e. able to use various web or database servers, not just one particular system).
Implement a clone or a variation of a "classic" arcade-style game. The most important overall parameter for this area is playability: You want the game to be fast and colorful enough to lure people into playing it.
Depending on the kind of game you're implementing you should also think about (a) support for USB controllers, (b) support for multi-player versions (maybe even networked?), and (c) support for "intelligent" enemies. One of the big challenges for game projects is automated testing, it can be quite hard to figure out how to make the input-output nature of testing work for immensely graphical and interactive applications.
The following games are available for teams to choose from. You should choose at least three games and rank them in order of preference when you register your team.
Here are descriptions of all the things you need to turn in or otherwise make public over the course of the quarter. Feel free to ask for clarifications, experience shows that even the most detailed description we can give here can still be misunderstood...
Format: PDF (any source)
At the start of the course lots of people potentially don't know each other yet. As a simple way to alleviate this problem, you're required to post your resume to the course mailing list. Consider this part of a "hiring" process in which others in the course pick candidates for their teams. Also, you should have a resume ready anyway, so if you still don't have one, this gives you an excuse to write one (and then keep it up-to-date for the future). You should focus on your skills (i.e. what languages and tools do you have experience with) and successful projects you have done in the past (ideally with a team of people); relevant work-experience is interesting as well.
If you feel like using LaTeX for your resume (a good idea, but not required) check out these links for some examples and LaTeX classes:
If you find something that looks better, please be sure to let everyone know... :-)
Format: PDF (using pdflatex, please hand in source as well); for Week 1 you can turn in a plain text file
Each team member will individually turn in a personal log describing their experiences in the course. The document is cumulative and should be organized into sections by week. For each week, you should record what you did for the course, for example what you read, what you learned, or what you still don't understand. Record important websites you found and why you needed them, and most importantly record how the actual development worked out: Who you paired with for what task, how accurate your estimates were, what problems you found and how you solved them, etc. There is no set amount of text you have to add each week, but we will grade on both content and effort. In the end you should look at this mostly as an investment for yourself, your own "knowledge depot" or something.
Format: PDF (using pdflatex, please hand in source as well)
The requirements document is the first "fake" milestone in the course. Note that your draft is due on Monday in week 4, so you should start working on this in week 3 already.
Your primary goal is to condense the existing user stories as well as your own vision for the project into "real" use cases. You document these use cases with UML use case diagrams and textual use case descriptions in the style discussed in class. The Fowler book includes an overview of the diagrams as well as the textual descriptions; more details on the textual descriptions can be found on Alistair Cockburn's website. Note that you don't have to fill in every piece of information for the template, use your judgment to decide how much is enough and what fields you can leave out. Please make sure to assign a unique number to each use case, you will need these for later milestones.
Your secondary goal is to present a basic domain analysis, covering static as well as dynamic aspects. You document the static aspects in the form of UML class diagrams; take care to focus on domain concepts, not design or implementation concepts. You document the dynamic aspects in the form of UML communication diagrams; pick a number of use cases and show how they "play out" based on the classes from your static model. Please note that communication diagrams used to be called "collaboration diagrams" in earlier versions of UML. It is very important that your models are mutually consistent: You can not send a message in the dynamic model if no corresponding operation has been defined in the static model.
Neither your use cases nor your domain analysis has to conform exactly to the current state of your project. Experience from the iterations informs you while you write the document, but you should include things you anticipate for future iterations as well. After the milestone is finished, however, you should refactor your existing code base to be in line with your document.
Note that it is more important to do a good job with the primary goal, but you cannot just "leave out" the secondary goal. That said, the hardest thing for your team to decide is when to stop; there's intentionally no guideline for how long this document is supposed to be. The best thing would be to take a step back and consider if you would be happy with the document if you were the customer. The second best thing is to give us enough detail so we can tell that you can use the diagrams correctly. :-)
Examples: Here are three example requirements documents from Fall 2004. Note that these are not perfect, in fact all three contain certain errors or omissions. However, they should at least give you an idea of what the document can be like. Many thanks to Deviant Entertainment, The Frinkiac-7, and Presto Forte for allowing us to post their documents as examples.
Deviant's Requirements for Super Mario GTA
Presto's Requirements for Archon
Frinkiac's Requirements for Bomberman
Format: PDF (using pdflatex, please hand in source as well)
The design document is the second "fake" milestone in the course. Note that your draft is due on Monday in week 7, so you should start working on this in week 6 already.
Your primary goal is to extend the static and dynamic domain models you developed for the requirements document towards the eventual implementation context. For example, if you're building a web-based system, you should now detail how your system interacts with external components such as databases, web servers, and web browsers. Also, you need to add enough detail to your models to serve as a starting point for an implementation effort, i.e. attributes, operations, constraints, etc. It is important that your new, more detailed models can still achieve all the use cases you defined in your requirements document. You should reference those use cases (that's why you gave them unique numbers, remember?) when you discuss the new static and dynamic models, and explain how they tie in with your design. You can use a number of UML diagrams for this portion: class diagrams and communication diagrams like you used before, sequence diagrams if they work better for a given use case, state and activity diagrams if they seem to make sense to clarify complicated decision structures, etc. The exact choice of diagrams is up to you, but you must have class diagrams and either communication or sequence diagrams for sure to document the static and dynamic aspects of your design. That said, it would be really nice to see a state or activity diagram used well... :-)
Your secondary goal is to present the system's architecture in more detail, covering software, deployment, and user interface aspects. Software architecture is concerned with the ``big picture'' view of the system, bigger than individual classes. For example, if you're building a web-based system, you should probably have three layers (database, application, presentation), and a given class can only belong to one of these. You will use UML package diagrams to document this aspect. Deployment (or system) architecture is concerned with the typical machine setup necessary or desirable to run your system. Again, if you're building a web-based system, you should probably show client machines, the Internet, and your server machines (maybe split into database servers, application servers, and web servers); there might be additional machines that need illustration, maybe an external credit card authorization server, an advertisement server, etc. You will use UML deployment diagrams to document this aspect. The user interface aspect is concerned with giving an initial idea or guidelines for how the system will interact with its users. You will document this aspect using user interface mockups, which can be drawings or actual screen shots from a prototype system, and a screen flow diagram that illustrates how the various bits and pieces of the user interface relate to each other. Again, if you're building a web-based system, you'd draw a diagram with boxes for the various pages that users encounter, and arrows for navigation between pages (there's actually an example of one of these diagrams in the Fowler book).
Neither your static and dynamic design models nor your architectural descriptions have to conform exactly to the current state of your project. Experience from the iterations informs you while you write the document, but you should include things you anticipate for future iterations as well. After the milestone is finished, however, you should refactor your existing code base to be in line with your document.
Note that it is more important to do a good job with the primary goal, but you cannot just "leave out" the secondary goal. That said, the hardest thing for your team to decide is when to stop; there's intentionally no guideline for how long this document is supposed to be. The best thing would be to take a step back and consider if you would be happy with the document if you were the customer. The second best thing is to give us enough detail so we can tell that you can use the diagrams correctly. :-)
Examples: Here are three example requirements documents from Fall 2004. Note that these are not perfect, in fact all three contain certain errors or omissions. However, they should at least give you an idea of what the document can be like. Many thanks to Deviant Entertainment, The Frinkiac-7, and Presto Forte for allowing us to post their documents as examples.
Deviant's Design for Super Mario GTA
Presto's Design for Archon
Frinkiac's Design for Bomberman
Format: multiple, see below
The product release is the third and last "fake" milestone in the course. Note that your draft is due on Monday in week 9, so you should start working on this in week 8 already.
Your primary goal is to put together a distribution of your system that clients (not just your client but anyone you hand the distribution to) can download and install on their own machines to get a working system. It is very important that you are not personally involved in this process; in other words, a good distribution will not require any email exchanges or meetings between your team and whoever is trying to install the system. You should write up some installation instructions for this, but they can be in whatever (portable) form you choose: a simple text file, an HTML file, a PDF file... It's up to you. Also, the length and detail of those instructions are up to you, just try to keep the "as little interaction as possible" constraint in mind when you put it together.
You should mention all required components, but you can assume that little detail is necessary for, say, Linux itself and Apache if you are building a web-based system; configuration options of both that are relevant for your system are important though. The safest approach is probably to make your distribution a basic tarball, and to rely on whoever is installing to also install all the required components. That said, I guess it could be a nice touch to supply installers for other platforms than Unix as well, but that's not required. Whatever you do, do not overwrite anything without giving the user a chance to back out of the installation process! As part of the review process for this milestone, you should definitely discuss all installation problems you have had, and what your suggestions for fixing those are. And if you really can't seem to get the installation going, please contact the other team's leads and ask them for help.
Your secondary goal is to have well-written and well-designed code to show. Imagine your client handing the system to some third party to get an idea of how well you actually hacked (maybe he or she is trying to figure out whether to hire you again). Whoever is reviewing your code will look for actual mistakes, consistent coding style, object-oriented design, appropriate documentation, useful unit and system testing, etc. In other words, the same things you would be looking for if you were asked to review someone's code. :-)
All you're handing in for this milestone is an archive (in .tar.gz format) that contains all the necessary information, scripts, code, etc.\ to (a) perform an installation and (b) evaluate your actual code; the archive should of course be organized in a useful way. In case you're interested, your code will eventually be graded on functionality (does it work correctly for our test cases) 50%, testing (sensible unit tests, sensible system tests, supporting data) 20%, design (modular, object-oriented design; extensibility) 10%, documentation (interfaces documented; supporting internal comments) 10%, and coolness (whatever is cool) 10%.
Format: PDF (any source)
Format: PDF (using pdflatex, please hand in source as well)
The titlepage must clearly identify which team you are and which team they are. The review document itself should start with an Introduction that explains the document's purpose and establishes some basic context about the following; for example, you should briefly characterize the system the other team is proposing.
The next section should present your Findings; be sure to point out good as well as bad aspects, try to be "fair and balanced" unlike a certain news channel. The order in which you present your findings should match the order of the document you are reviewing; make sure that you provide the necessary cross references, for example by referring to the document's section numbers.
The final section should present your Recommendations. You can suggest whatever you feel like, references to books or websites, detailed comments you wrote up yourself, etc. Imagine the kind of stuff you would like to be told. Again the order in which you present your recommendations should match the order of your findings; again, be sure to provide proper cross references.
This is only a very basic outline, feel free to research how a good review document is structured on your own. :-)
Format: plain text file
In the last week of the course, each of you will
individually evaluate the contribution
that each member of your team (including yourself) made.
You simply assign a score from 0 to 10 points to
each member (be sure not to forget
your own score), and turn in a simple
text file named peer-review.txt
giving real name, account name, and score for everyone.
In case you're wondering, we will average
these scores, not add them.
Before you go ahead and assign scores, please take a few minutes to reflect on the quarter. You might not "like" someone for some reason, but if they did a good job, they should get a good score. Someone might have been a bad pilot, but a great co-pilot, so they should get a good score. Someone might have been more involved with design than with coding, but if that helped to make the client happy, they should get a good score. And so on, I hope you get the point: Try to be as objective and honest as you can, and try to measure the overall contribution to the project, not just contributions to one particular aspect.
After lots of experiments with various kinds of text books, I have finally abandoned hope of finding a decent compromise. So there are no required text books anymore, only one required reference book on UML (see below). All other books listed here are simply suggestions, so feel free to ignore them. Instead of a text book we'll read lots of papers and websites, those will be listed in the schedule.
Martin Fowler: UML Distilled. Addison-Wesley, 3rd edition, 2003. Succinct introduction to the Unified Modeling Language (UML) and also a concise summary of basic software engineering and software construction concerns. The 2nd edition is also good enough for the course, and it's available much cheaper. Please be aware that the terminology changed between the 2nd and 3rd edition, you're responsible for handling that on your own.
Daniel Steinberg, Daniel Palmer: Extreme Software Engineering. Prentice Hall, 2004. Succinct introduction to eXtreme Programming (XP), an agile, iterative development process based on user stories, pair programming, testing first, and other interesting concepts. This was the required text for the Fall 2004 offering of the course.
More to come...
Andrew Hunt, David Thomas: The Pragmatic Programmer. Addison-Wesley, 1999. A wealth of practical advice on various topics relevant to software construction, including design, implementation, testing, debugging, etc. Organized in 46 relatively small "lessons," extensively cross-referenced, including 70 "rules" and several check lists on a reference card. You can download additional material for this book here. An errata is available.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Addison-Wesley, 1995. The standard reference for object-oriented design patterns: well-documented solutions to recurring design and implementation problems. The case study in chapter 2 is also a great introduction to object-oriented design and programming.
Here are a number of "standard" text books on Software Engineering, most of which are huge and expensive. I've opted to not require one of these, which is somewhat unconventional. Instead I'll cover many of the "standard" topics in lecture and leave it up to you to research them further if you want to. I prefer to have cheap, concise books that are more useful in the long term, and the required books above are just that.
Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of Software Engineering. Prentice Hall, 2nd edition, 2003. Recent text, emphasizes concepts over specific methods and processes, but provides a decent survey of those as well. Broad since it covers the whole software life-cycle, yet manages to treat all subjects in sufficient depth for an introductory course. You can download the official slides and other material for this book here.
Ian Sommerville: Software Engineering. Addison-Wesley, 6th edition, 2002. Popular alternative text, frequently used at UC Irvine for example. You can download the official slides for this book here.
Here are a bunch of links you might be interested in as you try to get a grip on software engineering. I didn't have time to organize them yet, but I promise that all of them are quite enlightening.
The following teams are currently registered. If there are any changes in your team, be sure to let us know, we need to approve those to keep track of what's going on in the course. Also, if any information below is wrong, tell us ASAP. Thanks!
Assignments 40% (7), Iterations 20% (7), Midterms 20% (2), Comprehensive 10% (1), Peer Review (1): 10%. See my policies for more information.