By Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli
July 2002
This book is designed to be used as a textbook by students of software engineering either in a classroom or for self-study. A major characteristic of the book is that it relies on teaching a few carefully selected principles in depth, rather than give an overview of a large number of techniques. In particular, Chapter 3 of the book presents the principles and the subsequent chapters demonstrate the application and instantiation of those principles with a few chosen methods. We believe that once the student learns these principles deeply, he or she will be able to attack software engineering problems critically and successfully. He or she will be able to learn new methods and understand their strengths and weaknesses. These are the very skills that we try to teach in the book. The classroom should be used to teach depth in the subject. Breadth can be achieved by independent reading.
Over the last decade, object-oriented development has become standard practice to the extent that many books now equate software engineering to object-oriented software engineering. We, on the other hand, cover the principles of object orientation in a balanced way, rather than as the only way to do software engineering. Object-oriented analysis, design, and programming have certainly evolved and become a dominant approach to software engineering. We believe, however, that the principles underlying software engineering are deeper than objects. The student should first learn the principles and methods that can be used in different approaches. The student should learn how to choose between approaches and should be able to apply object orientation when it is the right choice. For example, the student should learn about information hiding before learning about objects and inheritance. In the future, component-based software engineering will probably become more important. But even then, the principles will remain important.
Another area in which a great deal of progress has been made since the first edition of the book was published is the so-called “requirements engineering.” There is now a general consensus that this is a most crucial aspect of software engineering because all other aspects of the software product and process depend on an appropriate understanding of the requirements. Requirements engineering is emerging as a discipline on its own. Although we do not have a chapter that is devoted to the subject, we cover it in a balanced way in the context of the book. In particular, in Chapter 5 we deal in some detail with requirements specification, and in Chapter 7 we cover the role of requirements engineering in the software process, including a dedicated case study. Later in this guide, we offer a sample syllabus for a course on requirements engineering based on the text.
The case studies presented throughout the book and also in the appendix have two purposes. One is to present the issues discussed in a larger context, in order to give the student a broader view of why the principles or techniques are important. The second reason is to give those students who have not seen real projects a picture of realistic projects. The case studies are necessarily simplified to focus on important issues, but we have found that they are useful especially to less experienced students. The study of software engineering poses a challenge in a university setting because the typical student has not been exposed to the problems that software engineers face daily. These case studies attempt to overcome this challenge.
You may want to assign the case studies as outside of class reading for the students. Or you may want to devote class time to presenting the case studies in order to emphasize particular problems that occur in practice. The choice depends on your style, the background of your students, and the focus of the course. A more practical, less technical, course will benefit from discussion of case studies.
The book contains many exercises of three types:
• short, paper exercises, aimed at extending the knowledge gained from the book or applying the knowledge more deeply; these exercises are interspersed throughout the chapters. Some of these exercises are really intended for the student to test his or her understanding by helping the student focus on a particular direction of thought.
• longer paper exercises at the end of each chapter, requiring integration of the material in the chapter.
• term-projects requiring the development of some substantial software system by a small team.
Solutions to some of the exercises are provided at the end of each chapter. More exercise solutions are given in this Instructor’s Manual. In some cases only a sketch is provided to help the student get started in the right directions. In some cases, a possible solution is given where several are possible.
Many software engineering courses combine lectures and a laboratory project. To do this in a single semester is rather difficult. The teacher will find himself or herself discussing organizational issues while the students are concentrating on their daily forays into debugging. We believe that software engineering must be taught as all other engineering disciplines by first providing the student with a solid foundation in the “theory.” Only after this has been achieved will laboratory experience enhance the student’s knowledge. This implies that the student project must start closer to the middle of the semester rather than at the beginning. In our view, a better approach is to spend one semester on the theory and a second semester on the laboratory. The Instructor’s Manual offers several ideas for organizing a laboratory course based on this text.
The book can be used in several different types of courses, ranging from a complete university course covering all the topics—including term projects—to specialized short courses (sometimes called modules) either addressed to graduate students or to professional people needing to be updated on specific topics. Here we list a sampling of such courses. For each course, a short description of its rationale is provided complemented by a syllabus with indications on possible organization (class hours to be devoted to single topics, suitable term projects, etc.)
We start with the most comprehensive possible course. Most other courses can be derived through appropriate subsetting.
In teaching software engineering, it is important to integrate theory and practice. We believe that the best wav to do this is with a one‑year course, for example organized as two semesters. The first half of the course should be devoted to the study of the fundamental aspects, the principles, and the theory. In the second half, the theory should be put to practice in the form of a laboratory project. This is the way that traditional engineering disciplines are taught also. This basic course “specification“ may be modified to fit the practical constraints, for example to teach the material in one semester alone, or run the lab concurrently. The important point that must be maintained is that the fundamentals must be studied before any project work starts. Once the students start on the projects, all their attention and time will usually be devoted to the details of their projects, preventing them from absorbing the general and basic principles being taught in the course.
For such a two‑semester course, the book may be followed sequentially and completely in the first semester. In the second semester, start by reading the case studies at the end of the book. Choose or assign projects (see suggestions given later). Based on the case studies and on Chapter 7, decide on an appropriate lifecycle model for the project. The students should report their progress regularly (at least bi‑weekly), by emphasizing the principles and formal techniques they are applying and the difficulties they are facing. They should be asked to distinguish between the difficulties they are facing due to the nature of the project and those due to the techniques they are using.