Professional Masters Degree Program
CSE 584: Software Engineering, Winter 1997, Introduction
Every person taking this class has designed, written and maintained more software, and more complex software, than I have. So what can I possibly expect to teach in a course in software engineering in the Professional Masters Program? The plan is to take advantage of the experience of the students in the class, along with my background in research in the area, to achieve several primary objectives:
When you complete the course, my central goal is that you will think differently about the way you engineer software (or perhaps manage software) in your day-to-day work. As Fred Brooks has argued, there is "No Silver Bullet":
"There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement wihtin a decade in productivity, in reliability, in simplicity."
However, there are improvements that can be made, and a set of perhaps minor improvements can collectively lead to significant changes. Being knowledgeable and conscious about the ways in which you engineer software can undoubtedly improve the software that you produce and the productivity with which you produce it.
As a final note, there is a tremendous amount of material in software engineering that we will not cover directly in any depth. This includes software process, measurement and metrics, formal methods (although we will certainly address them to some degree), tools and environments (although we'll touch on them in the evolution material), version control and configuration management, the relationship of artificial intelligence to software engineering, computer-supported cooperative work, software reuse, user interface design, etc. These are important areas, but we can't cover everything. (For those of you especially interested in some topic we're not covering, you might want to look at the second option in the assigned work described below.)
The primary prerequisite for students in this course is that they have significant background in developing and maintaining software. Without this background, it will be essentially impossible to understand the problems in software engineering that I intend to address in the course. For example, how does one convey the notion of assessing design alternatives to someone who hasn't done much design? Or how does one convey the importance of systematic testing if one hasn't seen the costs of delivering a low quality product? It is far preferable to have industrial-strength experience in software development and maintenance than to have (even significant) academic experience.
A secondary, and far less critical, piece of background that it would be nice for students to have is some understanding of the classic software lifecycle: (roughly) requirements, specification, architectural design, detailed design, testing, maintenance. I am not an advocate of software engineering in this classic style (indeed, it's largely considered to be problematic, at best, for most situations), but it lays a nice context for understanding much of what we'll be discussing. For those without any background in this area, I can recommend some books that cover the material reasonably well and concisely.
This is not (not!) a course in which you will design and implement a large software system in groups. That is the structure of many courses in software engineering, including ones that a number of you have taken as undergraduates; indeed, it's structure I use in the undergraduate software engineering course here at UW. But to use this structure in this course would uninspired, at best. In particular, it would be inconsistent with the prerequisite that you have significant background in software development and maintenance. The primary reason that I use a large group development project at the undergraduate level is that it is the best way to start teaching undergraduates what the problems in software engineering are; I'm presuming you have this already (at least to a large degree), so doing this would be a poor use of everybody's time.
So what will the assigned work be? The course will be partitioned into five parts: introduction, requirements and specification, design, quality assurance and testing, and evolution (maintenance, reverse engineering, reengineering). There will be a significant (but not overwhelming) amount of readings assigned in each of these five areas; the course packet will include additional papers beyond the minimum required reading, since these may be papers you are interested in reading anyway (now or after the course is over). The assigned work will be:
Everyone must select one of the two options by April 15, 1997 (the end of the third lecture). If you select the first option, the group and the selected topic must be chosen by then; if you select the second option, we should have already negotiated a topic.