By Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli
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.
Audience: senior undergraduate; junior graduate
|
Topics |
Chapters/sections |
Class hours |
|
Overview |
|
2 |
|
SW qualities and principles |
|
4 |
|
SW design and architecture |
|
10 |
|
Specifications |
|
8 |
|
Verification |
|
10 |
|
Organizing the process |
|
4 |
|
SW economics |
|
3 |
|
SW tools |
|
3 |
Exam organization:
The final evaluation should be based on:
|
Topics |
Chapters/sections |
Class hours |
|
Start up |
Case studies: presentation and discussion |
3 |
|
Projects presentation |
|
2 |
|
Project assignment |
|
1 |
For each project: |
|
|
|
|
Team and process organization |
1 |
|
|
Intermediate project reviews: 2-3 |
1 hour each |
|
|
Final report presentation and discussion |
2 |
Exam: a global evaluation will be given at the end of the project based on the results of intermediate reviews and the final report/discussion.
In a one‑semester course an appropriate subsetting must be applied w.r.t. the full year organization: it is important to cover Chapters 1‑3, selections from Chapters 4, 5, and 7, and the case studies at the end of book, before the project starts. Obviously, the projects will be of smaller scope, and less educational. It is unlikely that they can exploit sophisticated and formal approaches such as Z or model checking. More from Chapters 4 and 5, selections from Chapter 6, and all of Chapters 8, 9, and 10 can be covered concurrently with the project. The more case studies the students see before they start their own project, the better they will be able to anticipate problems. For this reason, the case studies in Section 7.6 should be reviewed before the projects starts.
Audience: senior undergraduate
|
Topics |
Chapters/sections |
Class hours |
|
Overview |
|
1 |
|
SW qualities and principles |
|
2 |
|
The very basics of specification and design |
Sec. 5.1 through 5.4; 5.5.1, 4.1, 4.2 |
5 |
|
Case studies |
7.6.1, 7.6.2, 4.4, 7.7.1, (A or B) and C from the case studies chapter |
4 |
For each project: |
|
|
|
|
Team and process organization |
1 |
|
|
Intermediate project review |
1 |
|
|
Final report presentation and discussion |
2 |
|
Complements of SW design and architecture |
Sec. 4.6, 4.7; hints on 4.3 and 4.5. |
5 |
|
Specifications |
Sec. 5.5.2, 5.5.3, 5.6.1, 5.7.1, 5.7.2.2, 5.7.3 |
5 |
|
Verification |
Sec. 6.1, 6.2, 6.3 (excluding 6.3.7), 6.4.1, 6.5.1, 6.6, 6.7, 6.8 |
7 |
|
Organizing the process |
Sec. 7.1 through 7.4, 7.7.2, 7.7.3, 7.8, 7.9 |
3 |
|
SW economics |
|
3 |
|
SW tools |
|
3 |
Exam should be based on a final set of exercises complemented by project evaluation
This topic is becoming more and more important even outside the field of software engineering. A short course on requirements engineering can be easily carved from the book.
Audience: senior undergraduate; beginning graduate whose major is in any field of engineering.
|
Topics |
Chapters/sections |
Class hours |
|
Introductory concepts |
Sec.7.1, 7.2, 7.3.1, 7.3.2 |
4 |
|
Basics of specification techniques |
Sec. 5.1 through 5.6 |
8 |
|
Essentials of modularization techniques |
Sec. 3.3, 4.2, 4.6 |
5 |
|
Requirement specification and organization |
Sec. 5.7 possibly complemented by some archival paper such as van Lamsweerde [2000a] |
6 |
Exam organization:
Besides class exercises and homework assisted and evaluated by a TA, students should produce a report on a case study, possibly derived from some of the proposed term projects. For instance, we recommend:
The case study could be augmented by some requirement modeling, formalization and elicitation supported by suitable tools (e.g. formalizing part of the requirements in Z and checking their consistency).
Design principles and their application are the most traditional and still the most important part of software engineering. A short course can be designed to rapidly introduce beginners to these fundamentals of the discipline. The course, however, should also cover some more recent and advanced topics such as software architectures and distributed systems. Such a course should be centered on Chapter 4. Complementary material from other chapters would be necessary to put it in the right perspective.
Audience: undergraduate students in any field of engineering.
|
Topics |
Chapters/sections |
Class hours |
|
Overview |
|
1 |
|
SW qualities |
|
1 |
|
The basics of software specification |
Sec. 5.1 through 5.4 |
2 |
|
Design principles |
|
2 |
|
Design techniques and software architectures |
Ch. 4, possibly complemented with technical documentation on specific notations and/or architectures such as UML or CORBA. |
14 |
|
Software design in perspective |
Sec. 5.7 (without 5.7.2), 6.1, 6.2, 7.1, 7.3, 7.6, |
5 |
Term project
A term project should be obtained from some of the projects of the full course by minimizing the requirement analysis and the verification phases. Projects stressing distribution and the exploitation of middleware and/or components such as the electronic mail system, the bulletin board, the visual system for managing program libraries are recommended. The term project should start as soon as the very basics of design techniques have been presented (approx. at one half of Ch. 4)
Exam organization:
The evaluation should be based on the results of the project and of a final –or several midterm- test(s).
Object orientation has now gained wide popularity as a major design approach. Among the many existing notations and methodologies based on OO, UML is a widely adopted standard, also supported by the OMG. The coverage of such topics provided by the text makes it suitable to organize a short course on these topics. Such a course could be offered not only to junior students, right after an introductory course on programming as a surrogate for, or a step towards, a more comprehensive course on software engineering, but also to industrial and professional people who need to keep updated with recent technology.
Audience: undergraduate students in any field of engineering; professionals needing to update their knowledge on software design.
|
Topics |
Chapters/sections |
Class hours |
|
Overview |
|
1 |
|
SW qualities and principles |
|
2 |
|
Fundamental design techniques |
Sec. 4.1, 4.2, 4.4 |
4 |
|
Key concepts in OO design |
Sec. 4.6 |
3 |
|
OO architectures |
Sec. 4.7, complemented with technical documentation on UML and on some specific OO architecture such as CORBA. |
5 |
|
OO analysis |
|
5 |
|
Preliminary concepts on specification |
Sec. 5.1 through 5.4 |
2 |
|
OO specification techniques |
Sec. 5.5.2, 5.7.1, 5.7.3 (possibly complemented with 5.6.3 and 5.7.2 for a theoretically oriented audience) |
3 |
|
From OOA to goal-oriented requirement analysis |
Some suitable scientific paper such as van Lamsweerde [2000a] |
2 |
Term project
Term project could be organized in the same way as for the course on software design and architecture.
Exam organization:
The evaluation should be based on the results of the project and of a final –or several midterm- test(s).