Management issues regarding the use of CASE tools in software engineering are addressed. Part 1 of the book provides a brief history of software development and the tools involved. Part 2 introduces readers to two major surveys on which the whole book is based. Part 3 then analyzes different aspects of software engineering management, citing case studies from the surveys above. These aspects include the need for methodologies, the emphasis on an evolutionary approach, human aspects, the use of consultants, the need for a long-term view, interfaces with existing systems, serving the business needs, and tools as part of the engineering process. Success stories in the use of CASE tools are also cited and analyzed.

Although the two empirical studies give interesting facts about the use of methodologies and CASE tools in the United Kingdom, they were undertaken from 1989 to 1991. Most of the projects studied took place in the 1980s. Many changes have occurred in software engineering practice since then. Readers will not be satisfied with a rider explaining that “the keys to success are good management, good working practice and a good understanding of the problems…whichever method or tool is to be employed,…in 1988, 1993…[or] 1998.” Potential buyers of the book would like to see more informative discussions supported by up-to-date successful and unsuccessful cases.

For example, is it still true several years after the surveys that “there are a large number of companies who are neither using CASE nor methods”? Has the waterfall model remained so predominant that other alternatives need not be discussed? Is it still satisfactory to classify companies simply into users or nonusers of methodologies? A follow-up study using Humphrey’s software process maturity model might give readers a better understanding of the situation.

Furthermore, the authors could expand their coverage from structured methods to object-oriented methods, reengineering, and formal methods. For instance, instead of citing only Hierarchical Object-oriented Design (HOOD) as an example of object-oriented methodologies, more popular methods by Booch or Rumbaugh et al. could be discussed. Instead of just mentioning reengineering in passing in the chapter on interfaces with existing systems, further elaboration and references such as Arnold [1] and Lano and Haughton [2] could be included. Instead of regarding formal methods simply as using “mathematics to represent systems,” the authors should look beyond  Sommerville  [3] as the source of reference for VDM and Z.

I do not agree that most of the popular methodologies ignore the existence of a current system to be replaced or to be integrated, and that Structured Systems Analysis and Design Method (SSADM) stands out as an exception. In fact, conventional structured methodologies place so much emphasis on the study of current systems that Yourdon [4] finds that “the emphasis on building ‘current physical’ and ‘current logical’ models of the user’s system has proven to be politically dangerous.” The object-oriented and reengineering methods, likewise, assume that there is an existing system to be integrated or replaced. Furthermore, modern structured methodologies not only use dataflow diagrams, but also entity-relationship diagrams and state-transition diagrams. It is unfair for the authors to compare SSADM today with early works on structured methodologies such as DeMarco [5], Constantine and Yourdon [6], Gane and Sarson [7], and Jackson [8,9].

Although project managers need not be too concerned about details, they should be fully competent in software engineering. Readers of the book will be unhappy, therefore, if they are frequently presented with inaccurate or inconsistent information. For example, Information Engineering was not developed by Texas Instruments. Structured Query Language (SQL) is a specific language and not a generic name similar to database management systems (DBMS) or fourth-generation languages (4GLs). Jackson’s 1983 book on system development [9] did not “describe the principles of structured programming.” Yourdon’s latest book on structured methodology [4] should not be confused with his 1979 work on structured design [6]. On the contrary, the 1979 books by Gane and Sarson, and by DeMarco, are not works on system design.

If the authors are not careful about the accuracy of the preliminaries, readers cannot help wondering about the reliability of the survey findings and recommendations.