This book is for students who have not had any previous training in software engineering.... In order to limit the scope ... advanced topics ... have not been in- cluded. It was felt that in an introductory course . . . it is best to introduce the student to the discipline of soft-ware engineering and to some of the important topics, thus preparing the student for . . . advanced courses in software engineering. One of the goals of the book is to include only as much material as can be learned in a semester course, which might be the only soft-ware engineering course in a computer science student's education.

Chapter 2, "Software Requirements Specification," discusses the need to specify requirements in detail; methods of analyzing problems and describing solutions; the charac-teristics, components, and structure of an SRD and require-ments specification languages, such as PSL/PSA; validation of requirements including the SRS (and SRD); and metrics that can be applied to an SRS. While not attempting to teach a complete course in systems analysis, the author leaves out nothing of importance. Techniques, tools, and standards are covered and examples are given. The chapter concludes with the problem analysis and the resulting SRS document (SRD) in augmented IEEE/ANSI standard format for the case study used throughout the remainder of the book.

Chapter 3, "Planning a Project," covers cost estimation, project scheduling, staffing and personnel planning, team structure, software configuration management, quality assurance plans, project monitoring plans, and risk management planning. The chapter ends with a project plan for the case study. Once again, the necessities are covered well while the more advanced and esoteric topics are avoided. Costing is done using the COCOMO model, and the Gantt chart is used for time-related planning. Jalote mentions PERT and implies that it is the same as CPM. A PERT analysis of the case study would benefit students who, if they do not take a systems analysis course, will come across PERT and CPM at work, but know little more than what the acronyms stand for. Having taught the basics of PERT and CPM to second year students in a one-quarter systems analysis course, I do not believe that covering them would add that much time to this course.

Chapter 4, "System Design," covers the objectives of design, modularization techniques (such as modules, interfaces, hiding, and bottom-up versus top-down), object-oriented design, handling anomalies, and verification and design met- rics. The chapter ends with the case study's system design. This chapter is excellent. Topics such as cohesion and coupling are covered, but Jalote does not beat the student to death with 20 kinds of each in excruciating detail. Design methodologies are presented, concentrating on structured design (SDM) and object-oriented approaches (including the use of Ada). Both are well done and in enough detail that the students can utilize either in their own work. The author covers the outputs of the system design process, methods of design verification, and appropriate metrics.

Chapter 5, "Detailed Design," covers module specification; detailed design and the use of design languages; verification; metrics; and monitoring and control. The detailed design document for the case study concludes the chapter. One of the things I like best about this chapter is the way it brings together topics covered in abstract form in computation and language theory courses, such as pre- and postconditions, axiomatic specification, and symbolic execution, with real-world activities. Since "PDL" is a commercial product, and PDL (not pdl) is treated in the text as a real, existing program design language, references should be included as they are for requirements specifications languages and tools.

Chapter 6, "Coding," is about writing software. The major subheadings are programming practices, verification, metrics, and monitoring and control. As Jalote states, "the goal during this phase is not to simplify the job of the programmer. Rather, the goal should be to simplify the job of the tester and the maintainer" (p. 234). Can it be said any better? If students have not learned the programming practices discussed in this chapter by the third year of study, they should never write a program to be used or maintained by someone other than its author. The section on verification is good. Under "Code Reading," desk checking or review is discussed but reading by an independent third party is not. Proofreaders and editors can serve well in the code review process, as well as at other steps of the life cycle.

Chapter 7, "Testing," looks at testing fundamentals (what, why, where, and when), functional and structural testing, the testing process, a comparison of verification and validation techniques, testing phase metrics, and test monitoring and control. The chapter concludes with a test plan for, and the results of testing, the case study. This chapter is concerned with finding those errors that were not detected and corrected earlier in the life cycle. After giving the IEEE definitions of terms (error, failure, fault, reliability, and static and dynamic testing) and a discussion of how they relate to each other and to the problems of verification and validation, the text gets on to the more practical problems of testing. Once again, the text is more than adequate in providing tools, techniques, and evaluation along with discussion geared to its audience. The earnest student will learn how to test software and be reasonably well assured as to the quality of the testing, although the student will not be versed in all possible metrics, controls, and so forth.

In theory-intense courses, lab portions often lead while the lecture lags behind. Therefore, I like two-semester sequences with a lab course following the theory course. This book will work well, however, in environments where this luxury does not exist, such as in most technical schools and applied programs like MIS and CIS.

I can recommend this book for classroom adoption or individual study and would be willing to use it in my classes. If an instructor's manual exists and is as well thought out as the book, it should prove useful as well.