The unifying theme of this review is the transformations and vicissitudes of the system software development life cycle (SDLC). In its traditional form, the SDLC encompasses the following software development phases: survey of the existing system, requirements analysis, design of the solution, coding, testing, conversion (if applicable), implementation, and maintenance. Cross-reference this traditional linear waterfall model with alternatives (most of which form a sort of spiral of iteratively developed prototypes), bring in methods and methodologies for controlling the management of the process, and apply design techniques to produce the deliverables (the results), and you get a sense of the dynamic and challenging context within which development occurs.

In general, a methodology is a formal set of rules, procedures, and techniques that, when applied to a set of requirements, yields by way of a derivation-like process the software system that satisfies those requirements. Ownership (commercial, intellectual, or both) may be claimed of a methodology, whereas methods are strictly “public domain” (or at least that is one gloss on the distinction). Until recently, the conventional wisdom has been that top-down, structured methodologies are the tools of choice for developing software solutions. The emergence of object-oriented design (OOD) methods does not necessarily contradict or overturn this wisdom. The latter, however, seem to represent a fundamentally different way of conceptualizing problem solutions which, in Grady Booch’s phrase, run orthogonally (at right angles) to the existing tradition. The extent to which this involves a “paradigm shift” (to use Shumate and Keller’s phrase) is a matter of some controversy. At the moment, the debate is about which one forms the “front end” of the other. A possible third term that allows the resolution of the apparent conflict is the appeal that both must make to entity-relationship models [1]. These form the matrix out of which OOD methods have emerged, and allow us to back into functional decomposition.

Abdel-Hamid and Madnick

The project manager and project management staff form the audience for this text. Those responsible for planning and controlling the staffing and estimating of the development process are likely to find it useful. At first, I was put off by the highly theoretical juxtaposition of more than 100 individual, interdependent variables constituting the “integrative model of software development.” The strength of the authors’ approach is the wealth of empirical data gathered to build this model. For example, rather than assuming that Brooks’s law is valid--that adding staff to a late project makes it later because the number of communication interfaces increases exponentially while the discharge of tasks increases arithmetically--the authors subject it to empirical verification. The result is that Brooks’s law must be qualified. Adding staff to a late project always causes it to become more costly, but does not always cause it to be delivered later. What makes this text interesting is that the authors are forthcoming about the tradeoffs made in formulating their model, including ways in which the model fails to satisfy experience, as is seen on pages 112 to 113. Readers are able to judge the applicability of particulars for themselves.

Berkeley, Humphreys, and De Hoog

This report covers the theoretical principles and results of the development of a project management support system by the Commission for the European Communities (CEC). The project focused on the activities of the project manager. The authors make clear on page 90 that their intention is to support (not replace) the project manager. In fact, parts of the text read like a project management handbook: they are didactic, instructive, and clearly written. Actual project managers may find this text too theoretical, academic, and abstract, however. Those with an academic background will enjoy the allusions to generative grammar on page 152. In fact, this elaborate report does not really deliver a model of project management; rather, it delivers a meta-model--a model for generating many possible models, making extensive use of entity-relationship modeling conventions, as discussed on page 106. Nor is the model fully specified until chapter 10. In short, the project manager, although supposedly supported, may be overwhelmed and submerged in and by the environment intended to lend support.

Booch

The audience for this text is software developers charged with the solution of problems of complex control, process synchronization, reporting, and the management of dynamic phenomena. The author states that OOD is orthogonal to the traditional waterfall life cycle (p. 189). While denouncing the “abyss of the structured design mind set” (p. 145), the author manages to avoid choosing between “top down” or “bottom up” by means of the admittedly cryptic cipher “roundtrip Gestalt design” (pp. 188, 195, and 312). Essential terms and methods are defined: object (state, identity, behavior), abstraction, encapsulation (information hiding), modularity, hierarchy, typing, concurrency, and persistence. The wealth of coding level examples makes clear to the reader that, although one may try to implement an OOD using COBOL, what will always be lacking from the latter are syntax-language level features that enforce hierarchical and encapsulation distinctions. One must fall back on convention and agreements between programmers (and someone inevitably doesn’t get the message).

The amusing, cartoonlike illustrations of the first half of the text disappear by the time the reader arrives at the Smalltalk, C++, Ada, and Object Pascal examples of the third part. The author’s extensive bibliography is a definite plus and well worth the reader’s extended inspection.

Fournier

The author claims that the audience includes DP managers, planners, project leaders, programmers, analysts, and users (p. xvi). This text represents the traditional approach to the software development life cycle, amalgamated with liberal doses of data modeling (entity-relationship diagrams) and data element definitions. Prototyping, CASE technology, quality assurance, and formal methodologies are treated as extensions to the traditional framework. The author deploys a formidable amount of detail in the specification of task numbers, names, objectives, inputs, outputs, and formal descriptions of the development activities corresponding to the traditional phases. Although this text has many merits, the reader is left sensing that, unless one already knows how to perform these activities or is in a “start from scratch” situation, this text will be of limited practical benefit. What we have received is less a practical guide than a survey, summary, or reference manual, intended to be a source into which one may occasionally dip for formal definitions. DeMarco [2] remains the source for the engaged practitioner, although it lacks add-ons to CASE. Perhaps the difficulty is that the author has cast too wide a net. In trying to address such a wide audience, the message is diluted.

Shumate and Keller

Software developers responsible for the specification and design of real-time systems would be interested in this text. Its many strengths include extensive graphic notation to support the transition from requirements to design; a coherent case study against which the principles are tested and by which they are exemplified; and an approach that goes a long way toward integrating the methods of structured design (function-driven) and object-oriented design (data-driven). The discussion of information hiding and data abstraction on page 339 is one of the best in the literature, but it is curiously relegated to an appendix. If a weakness exists, it lies in the area of the difficulty of sustaining a case study without redundancy and repetition. This weakness is forgivable, however. The short but excellent bibliography contains many candidates for additional required reading.

Youll

The idea behind this text is sound. Project managers can use graphical and diagrammatic displays to make the status of the project or projects they are controlling visible. This short book delivers on the literal meaning of the promise it makes. It is mostly filled with two-dimensional graphs showing the measure of some variable against time. Some pie charts, bubble networks, and functional decomposition boxes are also featured. I came away with a distinct sense that the book contains less than meets the eye, however. The material is all common knowledge, and in the absence of some other special features to recommend it, the original interesting idea requires further development.

Comparison

These books fall into two distinct groups, which deal with different aspects of the software development life cycle. The first group treats project management, planning, and control issues. The second deals primarily with methods for the design and construction of software systems. In this sense, these two groups are not directly comparable, nor would it be fair to the authors to make comparisons. Nevertheless, they all belong in one unified review because of the perspectives they afford on the SDLC.

Both the book by Abdel-Hamid and Madnick and the book by Berkeley, Humphreys, and de Hoog deploy formal models of project management dynamics. The relative shortness and standardization of Youll’s vision makes his contribution the most limited of the three--no model is deployed. The internal workings of the project model are discussed much more in Abdel-Hamid and Madnick than in Berkeley et al. In some ways this feature makes the former book easier to criticize, since one can see the compromises that occasionally had to be made. For example, Abdel-Hamid and Madnick’s dynamic module cannot capture that five errors are not necessarily distributed evenly across five program modules but are probably concentrated in one error-prone routine (pp. 112–113). Their dynamic module limits the scope of the discussion to the situation after the modules have passed quality assurance testing (p. 113). Nevertheless, the reader is given more practical access to the gears and mechanisms of project management in this way than by the social science theories on the plans and structure of behavior implemented under the covers by Berkeley et al.

Fournier does a credible job of representing the conventional wisdom of standard function-driven system development in large businesses. His book attempts to be encyclopedic, and reads like an encyclopedia. What examples appear in the book are strictly local in extent. We get the concepts without the corresponding intuitions, and although it is not a bad book, the reader is sometimes left feeling empty.

A similar criticism might be leveled at what is in many ways a brilliant book by Booch. He claims that the structured methods are a “front end” to OOD (p. 201), which is apparently inconsistent with his denunciation of the “abyss” of the structured design mindset (p. 145). (Indeed, if the path to OOD lies through “structured,” then we may never get there, since the journey is so long.) Although the book contains a glossary and many excellent definitions, Booch never defines some terms (such as “semantics” and “finite state machine”). The reader’s persistence through a certain amount of blind intuitive groping is ultimately rewarded with an “Aha!” as he or she associates class diagrams with entity-relationship diagrams and database design with the initial phases of OOD (p. 367).

In this context, Shumate and Keller put it all together. Although their book is by no means easy, it successfully deploys traditional structured concepts (such as module coupling and cohesion) in true partnership with data abstraction and information hiding. The detailed case study can show up as both a help and a hindrance (obscuring the forest for the trees), but the two-dimensional graphics are consistently excellent in representational clarity and communicative impact. The transition from specification to detailed design is handled in a masterly way, and the authors find a balance between functional decomposition and the object model.