Software Quality Professional Resource Reviews - December 2003 - ASQ

Software Quality Professional Resource Reviews - December 2003



More Secrets of Consulting—The Consultant’s Tool Kit

CMMI®: Guidelines for Process Integration and Product Improvement


Patterns for Effective Use Cases


Software Architecture in Practice, second edition

Four Books on Architecting Software

Beyond Software Architecture

Patterns of Enterprise Application Architecture

Framework Process Patterns

Software Fortresses

Object Design/Roles, Responsibilities, and Collaborations

Extreme Programming Perspectives

Balancing Agility and Discipline—A Guide for the Perplexed

Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices

Professional Services Automation: Optimizing Project and Service Oriented Organizations


Introducing Software Testing

Practical Software Testing: A Process Oriented Approach


More Secrets of Consulting—The Consultant’s Tool Kit

Gerald M. Weinberg. 2002. Dorset House Publishing. 202 pages. ISBN: 0-932633-52-8.

(CSQE Body of Knowledge areas: General Knowledge, Conduct, and Ethics (I), and Program and Project Management (IV))

Reviewed by Jayesh G. Dalal

As the name implies, this book is an addition to an earlier book (1985) by the author titled The Secrets of Consulting. I have not read the earlier book, so I am not in a position to offer any comparison to it. I should also point out that I have taken some liberty with the CSQE body of knowledge area descriptions provided by ASQ to help me associate this book with the two body of knowledge areas indicated above.

Gerald Weinberg presents a collection of 16 essential tools for a consultant. The book is easy reading and the metaphors used by the author for each tool make them easy to remember. Each tool is presented in an entertaining style using anecdotes, laws, paradoxes, principles, and theorems. The book addresses the “soft” side of consulting, and the tools can help a consultant determine his or her wants, examine and analyze data, negotiate contract, help clients, and grow.

The following tools are discussed:

  • The Wisdom Box—to know what is right or not right for me
  • The Golden Key—to open new areas for learning and practice, and close them
  • The Courage Stick—to try new things and take ris
  • The Wishing Wand—to ask for what I want and live with not getting it
  • The Detective Hat—to examine data and to reason about the data
  • Yes/No Medallion—to say yes and no, and mean it
  • The Heart—to be able and willing to put my heart into my work
  • The Mirror—to see myself, and seek and use feedback
  • The Telescope—to see others and understand them
  • The Fish-eye Lens—to see and understand the context
  • The Gyroscope—to maintain and, when disturbed, restore my balance
  • The Egg—to grow, develop, and learn
  • The Carabiner—to ensure my safety and not take unnecessary risks
  • The Feather—to use humor, and not take things or myself too seriously
  • The Hourglass—to make time for good, and make good use of time
  • The Oxygen Mask—to take care of myself before attempting to help others

Weinberg has not attempted to cover everything a consultant ought to know in this book and points out that other good books on the subject can fill the gaps. I enjoyed the book and found the Wishing Wand and Oxygen Mask particularly useful. The challenge will be to remember that I have all these tools in the tool kit and select the right one to use. The Hourglass and Wisdom Box should help here!

Dr. Jayesh G. Dalal is an ASQ Fellow and CSQE, and past chair of the ASQ Software Division. He is an independent consultant and provides consulting and training services for designing and deploying effective management systems and processes. He has served on the Board of Examiners for the National Baldrige Award and the New Jersey Quality Achievement Award.

CMMI®: Guidelines for Process Integration and Product Improvement

Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. 2003. Reading, Mass.: Addison-Wesley. 663 pages. ISBN: 0-321-15496-7.

(CSQE Body of Knowledge areas: General Knowledge, Conducts, and Ethics (I))

Reviewed by Michael Yudanin

The Capability Maturity Model (CMM) has been around since the early 1990s. Numerous companies around the world have adopted the model; in this reviewer’s opinion, many more impressive numbers adopted the concept as a thinking paradigm rather than as a set of procedures. Many software process improvement paradigms and standards, such as ISO, share the assumption that good processes make good products. However, CMM’s structure of maturity levels as a function of processes capability is much more appealing to many professionals than binary go-no go models; it should be mentioned, though, that these have their own advantages and admirers.

CMMI: Guidelines for Process Integration and Product Improvement is not intended for somebody who is selecting which improvement model to adopt. It doesn’t provide a comparative analysis of different paradigms. If you are on the crossroads, this book is unlikely to help you to make the decision. But if you are one of the “CMM folks,” this book is for you.

The book describes the new model, CMMI®, which stands for Capability Maturity Model® Integration. This model integrates the descendents of the original CMM into one framework. This capability maturity model can be implemented in any organization that develops any product or service. It is very useful for companies that are interested in developing a process framework that covers not only their software development but also hardware development, service solutions, supplier sourcing, and so on.

CMMI: Guidelines for Process Integration and Product Improvement provides an excellent description of the CMMI model. This description is detailed enough to be used as a guide for initial assessment or implementation. It’s also structured enough to keep the reader in control. Once the reader invests four to five hours in understanding how the model (and the book) is organized, it will be easy to find whatever is needed.

Among other issues, the book copes with the integration of the staged CMM and the continuous CMM. The first used the structure of levels, familiar to software engineering professionals. The second stresses the capability of each individual process area. Both have the right of existence under CMMI, and they are referred to, respectively, as staged and continuous representations.

The book clearly describes the statistical foundations of level 5. In many sources, level 5 is presented briefly as the top of the Olympus, where only the immortals can dwell. As a result, its distinctive nature is not always understood. CMMI: Guidelines for Process Integration and Product Improvement provides clear explanations on the subject.

The dependencies between the process areas are clearly spelled out. For those dealing with CMM implementation, it is important to understand these dependencies; for those daring to explore the waters of continuous representation, it is crucial.

Part 2 of the book consists of a well-structured and detailed description of process areas. Armed with the knowledge acquired in Part 1, Part 2 becomes very useful. The book includes a good list of references, and, notably, a separate list of regularly updated sources—Web sites.

With all that said, this book deepens, and does not fix, a major shortcoming of the CMM literature. It fails to widen the scope of examples beyond the aerospace companies. There are only a few publications that defy the established pattern of providing aerospace examples only. Without a doubt, building mature processes in this type of company is very important. But it would be really great if other businesses will be brought closer to benefit from CMM ideas and guidelines: telecom, medical equipment, shipping software, operating systems, and myriad other applications await that hour, as well as their customers.

The book may be used for many purposes, including the following:

  • Guidelines for CMM implementation. This is the intended purpose. For those who are going to implement CMM, CMMI: Guidelines for Process Integration and Product Improvement will be a great companion.
  • Source of ideas. For those who want to improve processes in their organization, but are not ready for a full-blown CMM implementation, this book can be useful as a source of valuable ideas and definitions. Having it as a reference, one will not need to go through a dozen sources to determine how this or that process may be addressed in a well-structured and measurable way.

To summarize, this book is warmly recommended.

Michael Yudanin is a manager and consultant in software quality assurance and testing. He is an ASQ Certified Software Quality Engineer.


Patterns for Effective Use Cases

Steve Adolph and Paul Bramble. 2003. Reading, Mass.: Addison-Wesley.
216 pages. ISBN: 0-201-72184-8.

(CSQE Body of Knowledge areas: Software Engineering Process (III))

Reviewed by Eva Freund

There are numerous books currently available that focus on writing use cases. However, there are few books that examine the problems that individuals encounter when writing use cases. This book is one of the latter. Not only does it consider the problems people face while writing use cases, but it also describes simple, elegant, and proven solutions to the specific problems described. The authors recommend Alistair Cockburn’s book, Writing Effective Use Cases, to those who are unfamiliar with use cases.

The initial premise is that use cases are helpful not only for designing business processes but also for developing software or eliciting requirements. The second premise is that patterns exist that essentially describe a guideline (a sign of quality) that one can use to evaluate a use case. The third premise is that the reader will grasp the patterns and the signs of quality by experiencing them rather than by reading about them. Thus, the authors have identified approximately 36 patterns that they have organized into categories—organizational patterns, process patterns, and use-case set patterns. Each pattern defines a problem, identifies the context in which it occurs, and recommends a solution. Also, each pattern contains one or more examples demonstrating either the benefit of implementing the recommended solution or the potential consequences of not doing so.

The authors have used an ongoing story to illustrate their patterns. The story involves a group of developers who are tasked to develop use cases for a national travel agency’s new reservation system. The story provides an environment not only for the occurring problems that evolve into patterns but also provides a background for discussing the patterns. And as the authors state—while the story may be contrived, the experiences, conversations, and examples are composites of real events, real conversations, and real use cases.

To describe what a system does or should do, people have used flowcharts, message traces, storyboards, prose, and now use cases. Use cases are stories about how people or things use a system to perform some task, and they provide a number of advantages over the other methodologies, including:

  • A semiformal framework for structuring the stories including the concepts of actors, use cases, and rules
  • The system requirements for the error situations, in every use case, and at every level of description
  • A methodology for realizing the objects required to implement the behavior described by the use case.
  • A scaffold on which to hang other project information (business rules, interface designs, test scenarios and development processes)

The authors have identified two categories of patterns: development patterns and structural patterns. Development patterns describe the characteristics of use-case writing practices, along with the criteria for measuring the quality of the writing process. Structural patterns describe the basic components of use cases, explain how they should be organized, and offer criteria for judging their use. Each of these two categories is divided into subcategories. Development patterns breaks down into team organization, process, and editing. Structural patterns breaks down into use case sets, use cases, scenarios and steps, and use-case relationships. Chapters 2 through 8 address each of the subcategories, respectively.

Writing use cases is easy. Writing effective use cases is not easy. There are numerous mistakes that the beginning writer is likely to make. Common mistakes include:

  • Including too much user interface detail (for example, references to mouse clicks, list boxes, and window design)
  • Including too many user cases at low goal levels (for example, descriptions of individual system functions rather than description of what the system will do for the user)
  • Using a use case for nonbehavioral information
  • Making the use case too long and too hard to read
  • Describing incomplete goal accomplishment (for example, capturing only a portion of the behavior required for goal accomplishment)
  • Using sentence fragments (for example, leaving out a name creating ambiguity)

The excitement of this book is that the authors use use cases to teach the reader how to write use cases. For example, the use case entitled “BalancedTeam” describes staffing the team with people from different specialties to champion the interests of the stakeholders in the development process. It reminds the reader to ensure that the team contains both designers and end users. Another example is a use case entitled “LeveledSteps” describing how to maintain the scenarios at three to nine steps with all of the steps at a similar level and at a level of abstraction just below the use-case goal. These patterns distill and define the properties and characteristics of quality use cases for the reader.

For anyone interested in use case methodologies, this book is a must read.


Software Architecture in Practice, second edition

Les Bass, Paul Clements, and Rick Kazman. 2003. Reading, Mass.: Addison-Wesley. 528 pages. ISBN: 0-321-15495-9.

(CSQE Body of Knowledge area: Software Engineering Processes)

Reviewed by Carolyn Rodda Lincoln,

Software Architecture in Practice is the second edition of a book that describes how to create and use the architecture for a software system. All of the authors are senior members of the technical staff at the Software Engineering Institute (SEI), so this book is a consolidation of the latest SEI thinking on architectural techniques. Some examples are the architecture tradeoff analysis method (ATAM) and the cost-benefit analysis method (CBAM) for design decision making. The authors also draw on the expertise of other SEI staff members for each chapter according to their particular expertise.

The book consists of 19 chapters in four parts: envisioning, creating, analyzing architectures, and then moving from one system to many. The last part describes using architectures in product lines and how to deal with architectures when the system is built from off-the-shelf components. Seven of the chapters are entirely devoted to case studies, and most of the other chapters also include examples. Some of the case studies are an air traffic control system, a flight simulation, and the World Wide Web.

The authors recognize that architecture consumes senior resources on a project and that project managers may be reluctant to devote so much time to it. They argue that architecture is important for: 1) communication among stakeholders, 2) early design decisions, and 3) the transferable abstraction of a system. The drivers for an architecture are the quality requirements: availability, modifiability, performance, security, testability, and usability. The book provides tactics and patterns to describe and then achieve the desired quality.

Software Architecture in Practice achieves the authors’ goal of demonstrating how to do it “in practice.” The text, illustrations, and examples contribute to making it an extremely practical book. Other than using the Unified Modeling Language, the principles are not dependent on a specific language or implementation, so they can be applied in a myriad of situations and environments. Readers should be able to use the techniques immediately in their own organizations to document and improve the architecture and quality of their systems. Even better, the architecture can then be reused for related or future systems so that the quality of the software portfolio will improve over time.

Carolyn Rodda Lincoln is an ASQ certified quality manager and member of the DC Software Process Improvement Network. She is a process improvement specialist for Titan Corporation in Fairfax, Va. She holds bachelor’s and master’s degrees in math and was previously a programmer and project manager.

Four Books on Architecting Software

Reviewed by Scott Duncan

This is a collection of four separate reviews, presented together since all of these books focus on architecture patterns and application frameworks. Though each book gets into some specific implementation details, some begin with a broader approach to the general subject area than others. Before delving into each one, here are definitions of architecture offered by each one. Some provide a direct definition and others define a related term (that is, like “framework”).

Hohmann says a (system) architecture is “the basic ‘structure’ of the system” comprising the modules that perform its major functions, handle data management and distribution, define its user interface, identify the platform(s) it will run on, and so on. Architecture, therefore, “deals with the big picture.”
Fowler says (enterprise) architecture has “two common elements,” which are the high-level “breakdown of a system into its parts” and the “decisions that are hard to change.” Fowler admits he doesn’t have a precise definition, but says a definition would have to include consideration of persistent data (and a lot of it and concurrent access to it), “a lot of user interface screens” (to handle all the data), and a need to “integrate with other enterprise applications.”

Carey and Carlson write about “frameworks” and begin at a lower level than Hohmann and Fowler, since a framework is “a set of components working together so they address a number of problems in one or more domains.”

Finally, though his book’s subtitle is “Modeling Enterprise Architectures,” Sessions doesn’t really define “architecture.” Instead, he says “enterprise systems [are] a series of self-contained software fortresses.” A software fortress is “a conglomerate of software systems serving a common purpose and typically owned by a cohesive group of individuals” who “work together in a tight trust relationship to provide consistent and meaningful functionality to a hostile outside world.”

Beyond Software Architecture

Luke Hohmann. 2003. Reading, Mass.: Addison-Wesley. 342 pages.
ISBN: 0-201-77594-8.

If one has not even begun to delve into architecture and frameworks, why start with a book called Beyond Software Architecture? Why not cover that one last, for example? The book’s subtitle is “Creating and Sustaining Winning Solutions,” and the book is about the broadest context for architecture and frameworks: the entire solution space of a software product. Hohmann says many books have been written that “may help you build a successful architecture… [but]…fall short of the goal of helping you create a winning solution.” His objective is to help readers “move toward understanding and embracing the business issues that must be resolved in order to create a winning solution” by “focusing on the practical, nuts-and-bolts choices that must be made by the development team in a wide variety of areas.” Hohmann writes about architecture in the context of overall product development, including the marketing and contractual issues (the “Marketecture”) affecting the technical solution produced (the “Tarchitecture”). And his “wide variety of areas” includes material on portability, deployment, integration, usability, installability, upgradability, configurability, release management, security, even branding and licensing.

Hohmann makes the point that a system’s lifetime is often an order of magnitude longer than any individuals associated with it and the architecture “determines the nature of change within the system” and “exerts a strong influence on the team[s]” developing and maintaining the system. He points out that “most of us will be spending the majority of our time working within an existing architecture” as we rarely get the chance to build whole, new systems from scratch. Over time, as Belady and Lehman pointed out many years ago in Software Evolution, without some conscious effort to maintain the design integrity of a system, modifications will gradually wear away at the cohesiveness of the system and, eventually, lead to a point where the system can no longer be maintained with an acceptable level of quality or an acceptable cost. Hohmann believes that “how an architecture evolves can be more fascinating and interesting than simply creating its initial version.” It is at this point, early in the book, that Hohmann introduces software patterns as the way to “capture known solutions to recurring problems in ways that enable you to apply that knowledge to new situations.” Years ago, after several years of trying to succeed at “software reuse” and the code module level, many organizations began to look at reuse from the design and architecture perspective. The “emerging discipline of software patterns” as Hohmann calls it, is about such a reuse approach: quite often implemented in code modules, but grounded in design and architecture concerns.

Within this context, then, Hohmann addresses the “wide variety of areas” noted previously, expanding one’s concept of architecture from strictly technical design principles (for example, coupling, cohesion, encapsulation, parameterization, granularity) to encompass “business” and “management” concerns.

Patterns of Enterprise Application Architecture

Martin Fowler, et al. 2003. Reading, Mass.: Addison-Wesley. 557 pages.ISBN: 0-321-12742-0.

Martin Fowler’s book, after a brief introduction discussing architecture and patterns, is divided into two parts: the “Narratives” and the “Patterns.” The former is structured into a discussion of “layering…to break apart a complicated software system” into “presentation logic,” “data source logic,” and “domain logic.” The latter involves defining individual patterns and providing specific guidance for “how it works,” “when to use it,” and one or more examples of actual implementations of the pattern, that is, real code. The material on patterns occupies 80 percent of the book or about 400 pages, covering 51 different patterns.

The link between these two parts of the book occurs in the Narrative part, which contains chapters on domain logic, relational database mapping, Web presentation, concurrency, session state, distribution strategies, and addressing “the tricky question of what patterns to use when designing an enterprise architecture.” Each chapter in the Narrative part identifies the specific patterns that apply to the topic of the chapter. The final chapter, as the book says, “sweep[s] everything together” and covers “technology-specific advice” (for example, Java, J2EE, .NET) and “other layering schemes” (for example, core J2EE, Microsoft DNA, and schemes described by other individuals such as Brown, Marinescu, and Nilsson).

Fowler’s book, therefore, takes the more traditional technical architecture approach to the subject. However, since Hohmann’s and Fowler’s books are part of a series, they properly address different levels of architectural concern, complementing one another as part of such a series.

Framework Process Patterns

James Carey and Brent Carlson. 2002. Reading, Mass.: Addison-Wesley. 246 pages. ISBN: 0-201-73132-0.

This book is also about patterns that they have “encountered (and that typically occur) during normal object-oriented (OO) framework development…from initial requirements gathering to documenting the framework.” As such, the book suggests experience in object-oriented development is important to “get the most value” from it, but they feel, even if you don’t have such experience, reading the book will “expose you to a number of issues you will encounter in the future,” assuming you expect (or want) to be involved in OO development.

The structure Carey and Carlson have chosen to explain each pattern is a bit different from Fowler’s. There is, of course, a name for the pattern, which they describe as “usually humorous,” and which seems related to the story of where it came from in their experience. Then there are:

  • Alternate names for the pattern
  • The pattern’s intent (what it’s about) and context (why it exists)
  • Examples of its use (case studies, not actual code)
  • The problem it addresses
  • Approaches and solutions to solving the problem
  • Tradeoffs in using (or not using) the pattern
  • Specific instances of where the pattern has been used (in particular in “the IBM San Francisco project”)
  • Other patterns related to this one

The patterns are then collected into groups based on whether they apply to the development process as a whole, requirements, analysis, design, documentation, social aspects of a project, or framework use.

At the end of the book, Carey and Carlson note that “much of our discussion revolves around the human aspects of software development.” So this book is not so much about the “tarchitecture,” as Hohmann described it and Fowler addressed it, as it is about the “sarchitecture” [my invention] or social structure of a project and a concern for how the team “communicat[es] and collaborat[es].” Carey and Carlson also note a few “themes” in their book besides this key social one: “iteration is a way of life in software,” “incompleteness” or “the need for leaving some things out of a framework that you would put into as piece of software developed specifically for an application,” and “obvious reminders” about sticking to OO principles, focusing on team issues, and not abandoning the architecture under pressure.

Software Fortresses

Roger Sessions. 2003. Reading, Mass.: Addison-Wesley. 301 pages. ISBN: 0-321-16608-6.

This book discusses “software fortresses” and uses this metaphor in discussing a “hostile world” where matters of interoperability and security are the “two major issues facing the enterprise.” After some introductory material Sessions discusses “transactional integrity” as background “to understand the many flavors of the word transaction and how different parts of software fortresses cooperate to coordinate their work.” Other topics in his book are:

  • Drawbridges (synchronous and asynchronous)—”the information pipelines for the enterprise architecture,” which “carry messages from one fortress to another”
  • Security implementation—keeping things out, that is, “walls,” and letting things in, that is, “guards”
  • Partnerships through “treaties” —what some other architectural approaches call “contracts” and what historically have been known as the definitions of interfaces between parts of a system
  • Web service and presentation (browser) fortresses
  • Mission-critical business applications
  • Legacy, treaty, and service management
  • Architecture design review issues
  • A case study of “a large Internet store”

Sessions also discusses issues common to all fortresses: scalability, reliability, and integrity.

In a “Postlude” chapter, Sessions has a series of “top 10” lists related to important points about fortresses, reasons to adopt the fortress model, rules for fortress design, evaluation of J2EE vs. .NET, the state of the software industry, and controversial aspects of the model. The last point in the latter list is “the model hasn’t been proven,” emphasizing that Sessions’ book is about “a new approach” he has developed for “modeling large enterprise systems.” However, Sessions states that a number of his model’s ideas “have been proven, albeit in different contexts.” He also points out that asynchronous communication has many advantages known “since message queues were first released.” Indeed, he claims many people have expressed their liking for his model since it “formalizes an approach they feel they have already been using.”

Whether you end up liking his model will depend on how you react to the other nine “controversial” aspects of it:

  • Performance doesn’t count.
  • Put security only in the guard.
  • Organizational boundaries (of the enterprise itself) are related to fortress boundaries.
  • Tightly coupled transactions should not cross fortress boundaries.
  • We need fortresses within fortresses.
  • The software fortress model should always be used.
  • Turn off database security (not really, just don’t count on it to do the real security job).
  • Don’t share databases across fortresses. (But Sessions admits “this is definitely an area where some may feel the need to make adjustments to the software fortress model.”)
  • Give scale-out priority over scale-up. (For example, managing many clusters of small machines over a small number of larger machines. Sessions doesn’t consider this “an essential feature of the model.”)

    Object Design/Roles, Responsibilities, and Collaborations

    Rebecca Wirfs-Brock, and Alan McKean. 2003. Reading, Mass.: Addison-Wesley. 399 pages. ISBN: 0-201-37943-0.

    (CSQE Body of Knowledge area: Software Engineering Process (III))

    Reviewed by Scott Duncan

This is a “how-to” book with minimal theoretical content. However, its “how-to” approach is generic and low-tech, with little technology-specific discussion since it deals with design approaches and techniques one could use on paper as well as on a computer. It tries to teach, as the title suggests, “object design” without regard for tools to implement such approaches or techniques. Indeed, most of the graphics to illustrate design techniques are of index cards and large sheets of paper. The book takes a “behavioral approach to designing object-oriented software” using responsibility-driven design (RDD) (developed by Rebecca Wirfs-Brock) as its conceptual framework. Covering the philosophy and basics of RDD seems to be the best way to review this book.

RDD is described in Chapter 2 as “an informal method” offering “techniques for honing your thinking about how to divvy an application’s responsibilities into objects and coordinating their performance.” The authors define “responsibilities” as “what our software must do to accomplish its purpose.” This is more than just defining requirements and more than implementing classes. It starts with multi-stakeholder requirements gathering/definition. The authors call RDD “a clarification process” because the approach moves “from initial requirements to initial descriptions and models…to more detailed descriptions and models of [candidate] objects…to detailed models of their responsibilities and patterns of collaboration.” The approach is decidedly “iterative and incremental,” revising prior ideas and “reflecting [them] back to stakeholders” to move the clarification process forward. And, though iterative, the authors “adopt a conventional approach to describing [their] object development process.” Some mention is made of project planning, but it is “not the focus of this book.” The explanation of RDD focuses more on analysis and (exploratory) design with the latter including coding of prototypes.

RDD analysis includes:

  • System definition (high-level architectural and “system boundary” diagrams, a “glossary of terms,” and identification of responsibilities through “usage characteristics,…constraints, assumptions, and dependencies”)
  • Detailed description (using documentation of the development environment, “text descriptions of the way users expect to perform their tasks,” more technical descriptions regarding “performance,…maps to legacy data,…handling distributed data and computing, fault tolerance, and reliability,” screen specifications, and so on)
  • Object analysis (using CRC cards and glossaries of “concepts, descriptions of behavior, and business rules”)
    RDD (exploratory) design includes:
  • Associating domain objects with execution ones, assigning responsibilities to them, and developing an initial collaboration model (using “a CRC model of objects, roles, responsibilities, and collaborators,” “sequence or collaboration diagrams,” “descriptions of subsystem responsibilities and collaborations,” “preliminary class definitions,” and “working prototypes”)
  • Justifying tradeoffs (using “documentation of design decisions”)
  • Distributing application control (using “identification of control styles” and “patterns of decision making and delegation in the object model”)
  • Deciding static and dynamic visibility between objects (using “refined class definitions and diagrams”)
  • Model revision for maintainability (using “new object abstractions,” “revision of object roles,” “simplified, consistent interfaces and patterns of collaboration,” “specification of classes that reveal roles,” and “application of design patterns”)
  • Design documentation (using “UML diagrams” and “code”)
  • Design formalization (using “contracts between system components and key classes”)

The last half of Chapter 2 and all of Chapters 3 through 7 are devoted to describing how to do the things identified under analysis and design. This includes a case study on “control style for external user events.” It also includes considerable detail about how to diagram things effectively.

Chapter 8 is about designing appropriate levels of system reliability based on the criticality of a failure (from inconvenience to loss of life). Chapter 9 covers designing for system flexibility, especially when “your software will live in an environment with a history of change.”

And finally, Chapter 10 covers generic design and problem-solving considerations, making it oddly placed, perhaps, considering the specific RDD analysis and design techniques already presented in the book.
Overall, especially for those who are new to object-oriented design, this is a clearly written book that covers the subject well.

Extreme Programming Perspectives

Michele Marchesi, Giancarlo Succi, Don Wells, and Laurie Williams. 2002. Reading, Mass.: Addison-Wesley. 624 pages. ISBN: 0201770059.

(CSQE Body of Knowledge area: Software Engineering Processes)

Review by David Walker

When researching a new or unclear topic, one would want to review more than one source of information. This book is a collection of 47 articles written by various leaders in the extreme programming (XP) community. These articles cover a wide spectrum in the XP scope, providing insight and offering experience-based techniques for implementing XP effectively.

The articles are organized into six parts:

  • XAR: Extreme and Agile Review—A Review of XP and AMs
  • XD: Extreme Development—Analysis of XP Development Practices
  • XTT: Extreme Technology Transfer—Introducing XP and AMs
  • XR: Extreme Reality—Real-Life Experiences
  • XT: Extreme Tools—How Tools May Help the Practices of XP and AMs
  • XEX: Extreme to the Extreme—Ideas on How to Extend XP and AMs

In addition to the authors of the book, the articles are written by such names as Jim Highsmith, Ron Jeffries, Lisa Crispin, Paul Hodgetts, Denise Phillips, and even Mark Paulk who investigates the intersection of XP and Software Capability Maturity Model.

The value of this book is manifested in content and ease of use. The articles expose many elements of XP across multiple dimensions, for example, size, culture, environment, industry, methodologies, approaches, experiences, and so on. The material is not progressive, so the reader can pick and choose articles at random. Although there is impressive detail provided in many of the articles, simple language is used.

Someone new to XP would benefit from Part I of the book, which provides a gentle introduction. Articles can be categorized also to be specifically valuable to designers, analysts, testers, managers, teachers, or quality engineers. Real-world problems are explored in many of the chapters showing how other colleges are using XP/agile practices. Authors describe their experiences with topics that are still unclear and subject to debate.

I found this book to be valuable as an initial investigation of XP and as a future reference as I encounter more unclear areas of XP/agile practices. I also followed some of the further references provided at the end of many articles. Although the author claims that the book assumes the reader already is aware of initial works from Ken Beck, Martin Fowler, Ron Jeffries, and Jim Highsmith, I found a good summary of this work in Part I.

I give this book a thumbs-up, but I would suggest that the information may not be valuable for long, as new experiences are being documented every day. I expect an update and second edition of this book.

Balancing Agility and Discipline—A Guide for the Perplexed

Barry Boehm and Richard Turner. 2004. Reading, Mass.: Addison-Wesley. 304 pages. ISBN 0321186125.

(CSQE Body of Knowledge area: Software Engineering Processes)

Reviewed by Ray Schneider

Barry Boehm and Richard Turner start out Balancing Agility and Discipline in the title itself casting a bit of gas on a fire already raging. Proponents of agile development methods are unlikely to see agile methods as involving a tradeoff between agility and discipline. The presence of three forewords by Grady Booch, Alistair Cockburn, and Arthur Pyster, however, testifies to the lengths the authors have gone to generate a balanced book about the latest stage of what Grady Booch’s foreword calls the “method wars.”

Alastair Cockburn addresses the use of the word discipline in his foreword by pointing out that, at least in the agile methods camp, different methods have different levels of discipline. “My Crystal Clear methodology is as low on the discipline scale as I can make it. On the other hand, extreme programming (XP) calls for high levels of discipline, as anyone who has attempted it can attest.”

Arthur Pyster endorses the need, “Balancing agility and discipline is essential in any sizable project.” So we get off to a flying start with a certain tension in the forewords. The premise in the preface is that there is a conflict between supporters of the newer agile method supporters and those supporting traditional plan-driven, process-based methods that have dominated software engineering management models. That is probably an understatement. As the preface says, “True believers on both sides have raised strident, often antagonistic, voices.” Each side seems convinced that the other is misguided.

Balancing Agility and Discipline is subtitled A Guide for the Perplexed. Each approach promises rewards. What stance should project managers, developers, and others involved at one remove such as executives, academicians, and students take in this contentious matter? Have plan-driven methods had their day to be replaced by these upstart agile methods? Or is the agile movement just another flash in the pan, over-promised and under-delivered, like so many “silver bullets” that have come down the software engineering pike? Or, despite the denials of the true believers on each side, can some accommodation be made? Can good features of each be mixed and combined to tailor processes to the needs of projects? Boehm and Turner set out to explore these questions.

“One size fits all” is the core notion that the method wars turn on. It’s an odd phenomenon, perhaps a sign of an immature discipline, that this myth continues with such vigor. Fred Brooks wrote about it in his memorable paper “No Silver Bullet” in 1986, but the myth persists. In a prelude, Boehm and Turner tell a parable about an elephant and a monkey serving a village as food gatherers, each with its own methods. The elephant is methodical but not agile. The monkey is agile. They learn to cooperate to the great benefit of the village. Can our real-world elephants and monkeys do the same?

Chapter 1, “Discipline, Agility, and Perplexity” attempts to frame the issue first by contrasting agility as “the counterpart of discipline.” The book has extra-wide margins, and a running summary for each paragraph is printed in italics in the margin. This feature allows the book to be rapidly scanned. It can be easily read at the outline level and readers can dig deeper where their interest draws them. The first chapter summarizes seven plan-driven methods and five agile methods. The authors then pose the problem of finding the middle ground, proposing that there is a place for both.

Having posed the question in Chapter 1, Chapter 2, “Contrasts and Home Grounds,” highlights four areas of contrast between agile and plan-driven methods:

  1. Application characteristics
  2. Management characteristics
  3. Technical characteristics
  4. Personnel characteristics

Each of these areas is analyzed for both agile and plan-driven methods. Each contrast is broken down into three dimensions, and these are used to distinguish “home grounds,” that is, relative strengths, for agile and plan-driven methods. For example, in the area of application characteristics under the dimension of primary goals, agile methods focus on providing value rapidly and high responsiveness to change, while plan-driven methods concentrate instead on predictability, stability, and a high degree of assurance. Each dimension receives a brief but perceptive analysis.

Chapters 3 and 4 provide a flavor of the different methods. “A Day in the Life,” as Chapter 3 is titled, describes in a “you are there” narrative what a typical day is like and what a crisis day is like on a PSP/TSP plan-driven project and on an extreme programming (XP) project. Differences, similarities, and observations are gathered together at the end of the chapter.

I found this chapter difficult to read because it wasn’t real. I found it hard to care about the illustration and the made-up representative people. The authors got help from the Air Force Software Engineering Division of Hill Air Force Base and Dr. Tom Hilburn from Embry-Riddle Aeronautical University in developing the PSP/TSP section.
Dr. Laurie Williams of North Carolina State University, who has done pioneering work in the study of extreme programming (XP), helped develop the XP section, so I’m confident that the section has both fidelity and integrity. It only lacks the verisimilitude of being by and about real people on a real project.

By contrast, Chapter 4, “Expanding the Home Grounds: Two Case Studies,” highlighted fidelity by presenting two real-world projects. One described how agile practitioners used plan-driven techniques to scale-up agile methods and the other explored how leading plan-driven practitioners used agile methods to streamline their traditional methods.

Building on these two case studies, in Chapter 5, “Using Risk to Balance Agility and Discipline,” the authors provide a five-step, risk-based method for planning programs that incorporate both agility and discipline in appropriate proportion. They illustrate the methods by applying them to three related hypothetical software projects, each varying by an order of magnitude in team size as well as variation in seven other characteristics. Planning strategies and risk ratings for each project are described and method strategies derived. This chapter was a bit theoretical, but the use of trade-off tables and other analytical methods gave it a greater sense of reality than the straight narrative of Chapter 3.

After putting agile and plan-driven methods under the microscope for five chapters, Chapter 6, “Conclusions,” wraps up with six major findings and some recommendations for how one can start balancing agile and plan-driven methods appropriately in his or her business or project.

But the book isn’t done. Balancing Agility and Discipline provides a healthy set of five supporting appendices. The first provides thumbnail summaries of 13 methods organized by number and strength of constraints low to high. The methods don’t fall neatly into agile and plan-driven categories. Four are very lightweight agile methods with few constraints. Five are intermediate, some agile and others plan-driven, but with stronger and more severe constraints. Finally, four extend into the level of very high constraints and are predominantly plan driven. Other appendices zero in on the agile manifesto, capability maturity models, tools for balancing, and empirical information.

Balancing Agility and Discipline is an important contribution to the agile/plan-driven methods controversy that is still raging. It is a largely qualitative and provisional work, pointing a direction, but not proving a case. It is a must read for those actively struggling with these issues, but it won’t stand alone without further research and understanding of the methods to be used as elements of any process of balancing. I was impressed throughout by the book’s no-nonsense common sense. This is not a book by advocates. It is a book by sincere enquirers. It seeks not a “silver bullet” but a more mature and malleable process. It proposes to serve the software development industry by offering a tailoring process that combines the best features of agile and plan-driven methods. I think it is the beginning of a dialog and not the end.

Ray Schneider holds a bachelor’s degree in physics, a master’s degree in engineering science, and a doctorate in information technology. He is an assistant professor in the mathematics and Computer Science Department of Bridgewater College in Bridgewater, Va.

Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices

Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis. 2003. Reading, Mass.: Addison-Wesley. 334 pages. ISBN: 0-321-11884-7.

Reviewed by Scott Duncan

Whenever I read a book about maintaining (older) systems, I inevitably recall the Lehman and Belady book, Program Evolution (1985). The authors of Modernizing Legacy Systems include it in their bibliography, and a quote from Manny Lehman recommending this new book appears on its back cover. Program Evolution addresses the need to preserve architectural/design integrity when maintaining systems. Modernizing Legacy Systems notes that “legacy” seems to be applied to systems “when they begin to resist modification and evolution,” that is, when maintenance becomes increasingly harder to perform.

The authors state that the book is intended to help someone:

  • “…decide whether a modernization or replacement effort is justified…”
  • “…develop an understanding of the legacy system…”
  • “…gain an understanding of, and evaluate the applicability of, information system technologies that can be used in the modernization…”
  • “…involve the stakeholders…and reconcile their conflicting needs…”
  • identify architecture’s role in modernization
  • “…estimate the cost of modernization…”
  • “…evaluate and select a modernization strategy…”
  • “…develop a detailed modernization plan…”

The book begins by identifying factors that contribute to modernization project failure and by discussing various system evolution and reengineering topics. The bulk of the book uses a case study (called “the Beast”) to explore these factors and topics. The case study is covered in significant detail and involves a 1.8M line of code (approximately 900 elements of about 2 KLOC each) retail supply system coded in COBOL 85 and based on Unisys® server technology, which was to be replaced by a J2EE architecture. The book (from Chapter 2 through 17) goes into considerable detail regarding specific technical decisions made and specific technologies used in the transition.

The final chapter is entitled “Recommendations” and attempts to generalize from the case study to some principles [with my abbreviated characterization of the principle as I read the material]:

  • Find a better way [don’t replace one legacy system with another because it seems like the easy way to go]
  • Use commercial components [referencing to the Software Engineering Institute’s COTS-based Initiative]
  • Manage complexity
  • Develop and deploy incrementally [presumably to reduce risk and exposure]
  • Software engineering skills [train people with old skills in new ones]
  • Component-centric approach [what you cannot buy (that is, COTS) build for reuse]
  • Architecture-centric approach [as the authors say “architecture can be used to encourage and enforce a component-centric approach”]
  • High levels of concurrent development [which the authors say is “possible only in a highly structured, mature environment”]
  • Continuous integration [to reduce risk by frequent checks that things can be made to work together at some level through the project]
  • Risk-managed development [like complexity, you have to manage risk]

While the case study is admirable work, it seems to take over the book. The principles at the end seem rather thin in that they cannot be argued with much, but there is little guidance in applying them if the case study does not match the reader’s situation. Indeed, the authors say, in an 11th recommendation, that it’s “but one example, and the specifics of how this project was planned and managed may not be appropriate in your modernization effort.”

Professional Services Automation: Optimizing Project and Service Oriented Organizations

Rudolf Melik, Ludwig Melik, Albert S. Bitton, Gus Berdebes, and Ara Israilian.
2002. New York: John Wiley & Sons, Inc. 405 pages. ISBN: 0-471-23018-9.

(CSQE Body of Knowledge areas: Project Management (IV))

Reviewed by Irv Segal

While this book does not address any specific areas of the body of knowledge, it does address a means for optimizing performance of all the activities surrounding the body of knowledge.

This book provides an excellent blueprint for optimizing any project- and service-oriented organization (PSORG) by automating with application software. IT Departments, IT consulting firms, and software quality assurance organizations are perfect examples of PSORGs. These organizations stand to substantially benefit from optimizing through automation.

This book is organized into four parts. Part 1 delivers a comprehensive overview of this topic, including insight into the market and related jargon, setting the stage for the remaining parts.

Part 2 details the primary and supplemental components of PSORG business processes that should be considered for automation. It also provides requirements-level information to establish a basis for searching for a solution.

Part 3 provides a road map for selecting, implementing, and operating a solution. This includes a comprehensive list of issues likely to arise with insightful advice for dealing with them. It is obvious that the authors offer their advice from personal hands-on experience, which readers should find more valuable than purely theoretical solutions.

Part 4 provides an opinion of the future direction and outlook for this software market. This seems more useful for software vendors competing in this arena that it might be for someone implementing a solution.

In addition to the excellent presentation throughout the book, the appendix provides many useful tools, including a template for requesting solution proposals.

One should note that this book was a collaborative effort compiled by several employees of Tenrox, a PSORG solution provider. As such there is always the potential for bias toward the authors’ own solution. However, this seems to be a comprehensive work that is independent of any specific solution.

This book cuts to the chase with detailed useful information, sidestepping the fluff or stuffiness often found in such works. This work was obviously written by folks who rolled up their sleeves and got involved in the actual tasks being described.

Whether one’s intention is to purchase, customize, or build such an application, this book should be considered a must read. The overview is an excellent primer and planning tool for management, while the detail in the remainder of the book provides an indispensable guide for personnel left to carry out the task of automating a PSORG.

Irv Segal has been a senior consultant with SysGen, Inc., since May of 1997 where he developed SysGen, Inc.’s evidoc™ series of Software Quality Assurance Methodologies. He has more than 13 years of expertise with FDA regulated computer-related systems and more than 20 years’ experience in computer programming, systems analysis, and project management.


Introducing Software Testing

Louise Tamres. 2002. Reading, Mass.: Addison-Wesley. 281 pages. ISBN: 0-201-71974-6.

(CSQE Body of Knowledge area: Software Verification and Validation)

Reviewed by Carolyn Rodda Lincoln

Introducing Software Testing is a beginner’s guide to creating test cases. The author sets up the situation: The ship date is fast approaching and one unfortunate programmer is assigned to test the software. There are few or poor requirements, and no one can provide any guidance to the programmer—what do they do? Although this exact scenario probably occurs rarely, the general state of affairs is much more common. This book was written to immediately help the hapless programmer or anyone else thrown into testing. It would also be a good resource for someone who has done a little testing and wants to learn more techniques.

The book contains 10 chapters filled with practical advice and examples. There is little theory or explanation of testing tasks other than creating test cases. One chapter provides eight stages for approaching test cases in the worst-case scenario. Another shows how to derive test cases from requirements, complete or not. There is a chapter on how to derive test cases from designs such as state machines and decision tables. Two chapters describe how to test object-oriented and Web applications. An extremely important chapter is on how to reduce the number of test cases, since a tester can always design many more test cases than are feasible to perform. The final chapter describes software standards that apply to testing; they are from ISO, IEEE, and the Capability Maturity Model.

Introducing Software Testing is a wonderful resource for those who do not know how to begin creating test cases. It provides an array of techniques from which to choose with worked-out examples, so someone could start using them immediately without extensive training. The text often refers to books in the references so readers can look up more information on a particular technique that interests them. The emphasis is not on test tools; the only tools needed for these techniques are a word processor and spreadsheet. Introducing Software Testing is the book for you if you are either starting to test or managing someone who is. It would also be useful to whose who write requirements so that they can understand how a tester uses them and what makes good quality testable requirements.

Carolyn Rodda Lincoln is an ASQ certified quality manager and member of the DC Software Process Improvement Network. She is employed as a quality assurance analyst for Titan Corporation at the Environmental Protection Agency in Washington, D.C. She holds bachelor’s and master’s degrees in math and was previously a programmer and project manager.

Practical Software Testing: A Process Oriented Approach

Ilene Burnstein. 2002. New York: Springer-Verlag. 699 pages. ISBN:0-387-95131-8.

(CSQE Body of Knowledge areas: Validation and Verification (VI))

Reviewed by Eva Freund

During the 20 years I have spent as a testing manager and the years also spent teaching testing, I first had recommended Boris Beizer for concepts and later Cem Kaner for specifics. However, I had never come across one book that contained the coverage for everything I needed. I often thought I needed to write the definitive book on software testing. Ilene Burnstein has written my book. Practical Software Testing combines the structured theoretical approach required of a textbook for both undergraduate seniors and graduate students. For the practicing professional, it provides concepts, standards, measurements, and practices that support the creation of quality software, and provides the information needed to build the highest caliber individual testing process that integrates with an organizational testing process. Those who seek information on improving their organizational testing process will find this book extremely helpful.

As the author states, “This is an exciting time to be a software developer…poor quality software that can cause loss of life or property is no longer acceptable.” She continues, “…The need for software products of high quality has pressured those in the profession to identify and quantify quality factors…and to identify engineering practices that contribute to the development of quality software products.” This book does more than any other to raise the bar on the testing process that leads to quality software products.

The text endeavors to cover many of the topics referenced in the Software Engineering Body of Knowledge. Each chapter covers a managerial, technical, and/or process-related topic related to testing. Each topic supports the reader’s growth as a test specialist. The relationship of the contents of each chapter to the testing maturity model (TMM) is described. Readers can find true value added by integrating the topics into their individual professional activities or studies.

The first nine chapters contain basic material that allows readers to master fundamental testing concepts at the technical level, and to learn about basic managerial concepts that promote a repeatable and defined testing process. These chapters also highlight the importance of an independent test group, and promote monitoring and controlling of the testing process. Maturity goals at levels 2 and 3 of the TMM have also been integrated into the chapter material.

Chapters 10 through 15 cover more advanced topics related to levels 4 and 5 of the TMM. These chapters support reviews as a testing activity and the automation of testing activities with tools, qualitative and quantitative evaluation of the test process, and qualitative and quantitative evaluation of the software product under test. Finally, Chapter 16 provides a discussion of test process assessment using the TMM. The chapter also describes some present-day industry applications of the TMM.

Each chapter also includes definitions of key terms and exercises that are helpful in learning the described concepts, along with a set of references for the reader who would like further discussion of the topic. Appendix I contains supplementary references including textbooks, papers, and Internet Web sites. Appendix II contains a sample test plan to illustrate the typical contents of such a document. Appendix III contains the TMM questionnaire, ranking algorithms and a full set of TMM activities. Also included are tasks and responsibilities for readers interested in assessing their own test process.

Whether you teach software testing, manage software testing, or practice software testing, this is a must-have book. If you are responsible for delivering a quality software product you will appreciate this book’s value as you implement the topics and activities outlined in it.

Return to top

Featured advertisers

ASQ is a global community of people passionate about quality, who use the tools, their ideas and expertise to make our world work better. ASQ: The Global Voice of Quality.