Browse Books

Reviewer: Tom DeMarco

I know it is a sign of economic and intellectual vigor that we have so many books to choose among for whatever subject we would investigate. Want to learn C++__?__ Take your pick from nearly a hundred new titles. Getting into metrics__?__ There must be 70 new books on the subject. Isn't it nice to have a choice__?__ Perhaps. It's just that the n th book on even the most valuable subject begins to seem pointless as n goes into double and triple digits. Wouldn't it be nice, just once, to pick up a book so intrinsically unique that it was and would remain the only one of its kind__?__ Such a book is this volume by Abdel-Hamid and Madnick. It is not another book on anything; it is the only book on its topic. It is chock-full of intriguing and useful insights that are simply not to be found anywhere else. Abdel-Hamid and Madnick lead you where you have never been before. The subject is simulation of software projects. The authors would have you build a fairly elaborate simulation of your next project, after first having calibrated your organization against a norm that they provide. Their advice is specific and to the point. They supply a design for the simulation and all its components and even supply the actual code. They discuss the theory and use of the model in clear, prescriptive text. Once you have a simulation in place, they suggest that you run your project a few times, varying key parameters to see what mix gives you the best outcome. They urge you to tinker with your assumption set to see in advance how unwelcome news may manifest itself: Suppose the system turns out to be 40 percent larger than you had anticipated and you do not discover that until the project is more than half over. Suppose you lose a key person in month eight. Suppose sign-off on the spec is delayed by a month. The simulation tells you what net effect to expect. It may be right and it may be off to some degree, but you quickly come to the conclusion that its best guess as to what the outcome will be is better than your best guess. I have been using Abdel-Hamid/Madnick models for the past three years. I have come to believe that the models I<__?__Pub Caret> construct (guided by the authors' scheme) know better than I do myself how the project will respond to changing circumstances. I would not think of running any but the most trivial project again without using such a model. The work of Abdel-Hamid and Madnick is changing the way projects are run and the way we think about them. It has changed me, and I predict that it will change you.

Reviewer: Lou Agosta

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 Boochs phrase, run orthogonally (at right angles) to the existing tradition. The extent to which this involves a “paradigm shift” (to use Shumate and Kellers 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 Brookss 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 Brookss 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 doesnt 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 authors extensive bibliography is a definite plus and well worth the readers extended inspection. Table 1: Quantitative Data Abdel-Hamid and Madnick Berkeley, Humphreys, and De Hoog Booch Fournier Shumate and Keller Youll Number of chapters 20 13 12 14 8 8 Number of pages in bibliography 16 10 45 5 5 None Number of pages in appendices 10 None 22 20 49 8 Glossary No Yes Yes No Yes No Audience Project manager Software developer Software developer Manager developer Software developer Project manager 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 Youlls 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 Madnicks 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. Table 2: Coverage of Topics Abdel-Hamid and Madnick Berkeley, Humphreys, and De Hoog Booch Fournier Shumate and Keller Youll Project management model Yes Yes No No No No Project staffing model Yes Yes No No No No Graphical presentation methods Yes Yes Yes Yes Yes Yes Functional decomposition No No No Yes Yes No Data modeling No No Yes Yes Yes No Information hiding (encapsulation) No No Yes No Yes No 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 readers 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.