CS 180: Software Engineering

Fall Quarter 2003: September 25, 2003 - December 5, 2003

Less:

Basics

Coordinates

More:

Basics

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. Let me emphasize that you should have good writing skills to pass this course as a large portion of the work will be reports of various kinds. You should also have reasonable presentation skills, or at least you should be willing to develop them.

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, hacking, and homework).

Coordinates

Instructor: Peter H. Fröhlich
Office Hours: Monday, Wednesday, Friday, 11:00 am - 12:00 pm, Surge 341 (email for additional appointments)

Lectures: Monday, Wednesday, Friday, 6:40 pm - 7:30 pm
Location: Spieth Hall, Room 2200

Assistant: Siddharth Dixit
Office Hours: Wednesday, 10:00 am - 11:00 am, Surge 282

Lab: Monday, 8:10 am - 11:00 am
Location: Surge, Room 170

Lab: Wednesday, 11:10 am - 2:00 pm
Location: Surge, Room 171

Mailing List: cs180@lists.cs.ucr.edu (Archive)

Books

Required

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. The course does not cover everything in the book, and the book does not cover everything in the course. You can download the official slides and other material for this book here.

Andrew Hunt, David Thomas: The Pragmatic Programmer: From Journeymen to Master. 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: Elements of Reusable Object-Oriented Software. 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.

Also Running

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.

Hans van Vliet: Software Engineering: Principles and Practice. John Wiley & Sons, 2nd edition, 2001. Promising alternative text, I am considering this one for the next iteration of the course. However, I have not done a complete evaluation of it.

Schedule (Tentative!)

Note the word tentative above. Things seldom go according to plan, and I expect changes here and there as we go along. Please also read the notes below.

Week	Lecture	Lab	Assignment	Exam	Reading
0	Welcome [Lecture 1]	Open Lab: Accounts, Basics	-	-	G 1
1	Introduction (G 1), Software (G 2) [Lecture 2] [Lecture 3] [Lecture 4]	Tools (G 9.1, 9.2), LaTeX [The Not So Short Introduction to LaTeX]	[Assignment 1: Warmup & Survey]	-	G 1, 2, 9.1, 9.2
2	Principles (G 3) [Lecture 5] [Lecture 6] [Lecture 7]	Elevator Case Study (G 3.8.2), XHTML 1.1 [TBD]	[Assignment 2: Prototype]	-	G 3, 9.3.1-9.3.4
3	Process (G 7) [Lecture 8] [Lecture 9] [Lecture 10]	Budget Control Case Study (G 7.6.2), Configuration Management (G 9.3.9), Subversion [Subversion]	[Assignment 3: Requirements] [Basic Use Case Template]	-	G 7, 9.3.9, 9.3.12
4	Management (G 8) [Lecture 11] [Lecture 12] [Lecture 13]	Organization (G 8.4), Case Study (G A)	[Assignment 4: Schedule]	-	G 8, 9.3.13, A
5	Design and Architecture (G 4), Review [Lecture 14]	Open Lab: Review	-	[Midterm] [Solution]	G 4
6	Design and Architecture (G 4) [Lecture 15] [Lecture 16] [Lecture 17]	Product Families (G 4.1.2), Case Study (G B)	[Assignment 5: Design]	-	G 4, 9.3.8, B
7	Specification (G 5) [Lecture 18] [Lecture 19] [Lecture 20]	Open Lab: Finite State Machines (G 5.5.3), State Charts (G 5.7.2.2), Case Study (G C)	[Assignment 6: Specification]	-	G 5, 9.3.10, C
8	Specification (G 5), Verification (G 6) [Lecture 21] [Lecture 22] [Lecture 23/24]	Informal Analysis (G 6.4.1), Debugging (G 6.8), Case Study (G D)	[Assignment 7: Implementation]	-	G 5, 6, 9.3.5-9.3.7, D
9	Verification (G 6) [Lecture 25]	Open Lab: Project Presentations	[Assignment 8: Testing & Wrapup] [A Rational Design Process]	-	G 6, 9.3.11
10	Epilogue (G 10), Review [Lecture 26]	Open Lab: Review	-	[Final] [Solution]	G 1-10, A-D

Notes

Week 0 refers to the September 25-26 pseudo-week. Open Lab means you can attend any lab section offered that week; you don't have to attend the one you're enrolled in, and you can attend all of them as well.

The terms "G c" and "G c.s" refer to the required text by Ghezzi et.al.; for example, "G 1" refers to chapter 1, while "G 4.1" refers to section 1 in chapter 4. When sections are assigned, it's a good idea to skim the material "around" those sections as well.

Some topics we go over in lecture or lab are not covered in the text; I will try to provide additional references for those. Also, some parts of the book are assigned as reading only and are not covered in lecture or lab (unless you ask about what you have read).

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.

Project (Tentative!)

The project for this quarter is a generator for online photo albums. The good news is that since there obviously are tools that perform such a service already, we don't have to bother with a feasibility study. The bad news is that in the limited time you have, you will have to make difficult decisions on how much functionality to include and how "friendly" to make the tool.

Let's get into a little more detail. In it's simplest form, the generator takes a bunch of pictures (that is, a bunch of files in certain formats, at least JPG and PNG) and produces a bunch of XHTML 1.1 files that can be browsed just like a photo album.

Aside from the pictures to include, the user should be able to define the album to be produced as well. At the very least, it should be possible to request one or multiple pages, decide how pictures are to be distributed and arranged on these pages, and what information to display for each page and picture.

Here are some examples of the tradeoffs you will have to make (and justify): Is there a graphical interface? Does the user have to provide the name of every single picture explicitly, or can complete folders be "included" automatically? Is that possible recursively, folders within folders, etc.? Is it possible to extract meta information from the picture files automatically? Just file name and date, or maybe more? If there's no graphical interface, does the user employ command line arguments, a single configuration file, multiple configuration files (e.g. in the tree containing the pictures), etc. to define the details of the album?

It is essential that the generated albums validate as strict XHTML 1.1 and use CSS 2 style sheets (either provided by you or the user), otherwise acceptance of your tool is in question.

Notes (Long But Useful)

The actual assignments are not posted yet, but here is a rundown of the project part of each assignment to aid your planning. In assignment 1, you are going to do a quick market survey of comparable photo album tools; two standard LaTeX pages on three to four tools are enough. Also, you need to form teams of three to five students and register your team with us (think up a cool name!) to receive a shared account.

In assignment 2, the first team assignment, you are going to build a basic prototype of the system. The prototype can "fake" a lot of things, e.g. it does not have to read or analyze actual pictures, and the XHTML you produce does not have to validate. However, the prototype must be able to demonstrate to your client how the tool will (probably) work. There is no restriction on the programming language or tools you can use for this, but you can not just reuse an existing system. Aside from the code itself, you hand in a two-page description of the prototype. You'll also put together your team's website in this assignment.

In assignment 3, you will document the user requirements for the system, using UML use-case diagrams as well as textual descriptions. This will be the first "bigger" document you produce, anywhere from six to ten standard LaTeX pages. If you run out of space, at least explain briefly which use-cases you couldn't fit anymore. Also, try to focus on the most interesting use cases: "Quit program" is hardly as interesting as "Define layout".

In assignment 4, you will "switch gears" and produce a schedule for the remaining development tasks, outlining what activities are to be done to complete the project, as well as who is doing what in your team. You should use appropriate charts and maybe define some "risks" as well, e.g. what's your plan for "Team member drops course". Again, this should be anywhere from six to ten standard LaTeX pages.

In assignment 5, you will develop an object-oriented design for your application. You must definitely include a UML class diagram here, with sensible classes, sensible methods, and sensible relationships (inheritance, association, aggregation, ...). You should then pick some use-cases from the requirements specification and show how you can fulfill them using your classes; here you will want to use UML collaboration and sequence diagrams. Again, this should be anywhere from six to ten standard LaTeX pages.

In assignment 6, you will specify an aspect of your system formally. You're on your own for (a) picking the part to specify and (b) picking the notation to specify it in. Just be sure you understand the choices you make, and try to produce something sensible; drawing nonsense statecharts or wild data-flow diagrams without rhyme or reason will not get you a lot of points. You should turn in at least two standard LaTeX pages, but you can turn in thirty as well if you want; the point of this assignment is making sensible choices, not producing lots of irrelevant (or worse, wrong) details. To be clear: You can get a great score for very little actual work if you make good choices about what to specify and how!

In assignment 7, you will deliver a first version of your application; if you did a good job scheduling, you will not start hacking this week! Unlike the prototype in assignment 2, this implementation has to perform all of the basic things outlined in the description of the project above. Programming language and tools you use are up to you again. You need to produce a two-page "User Manual" that explains briefly what to do in order to see your application do its magic. Also, you need to write a two-page summary describing how your code reflects the requirements and design documents you handed in earlier; or if your code does not reflect them, explaining why not.

In assignment 8, finally, you will describe how you tested your code and why you chose a certain approach. Your description should be four to six standard LaTeX pages, and you should discuss at least one example in detail, i.e. how you went from a specific requirement to specific test cases and what you learned about your code when you actually tested it.

Also in week 9, you will give a short (10-20 minute) presentation on your team's project. The presentation should use slides (handed in before in PDF format) and should give each of your team members time to present one aspect of the project. There will also be one or two questions after your presentation. More details will be posted as we get closer to that event.