Software Quality Professional Resource Reviews - June 2002 - ASQ

Software Quality Professional Resource Reviews - June 2002

Contents

GENERAL KNOWLEDGE, CONDUCT, AND ETHICS


Software Leadership: A Guide to Successful Software Development
By Murray Cantor


SOFTWARE QUALITY MANAGEMENT


Software Process Improvement: Practical Guidelines for Business Success
By Sami Zahran


SOFTWARE ENGINEERING PROCESSES


Agile Software Development
By Alistair Cockburn

E-Business and IS Solutions: An Architectural Approach to Business Problems and Opportunities
By William J. Buffamm

Component-based Product Line Engineering with UML
By Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jurge Wust, and Jorg Zettel

Cocoa Programming for Mac OS X
By Aaron Hillegass


PROGRAM AND PROJECT MANAGEMENT

Manager Pool: Patterns for Radical Leadership
By Don Sherwood Olson and Carol L. Stimmel

The Accidental Project Manager: Surviving the Transition from Techie to Manager
By Patricia Ensworth

SOFTWARE METRICS, MEASUREMENT, AND ANALYTICAL METHODS

Practical Software Measurement Objective Information for Decision Makers
By John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, and Fred Hall

Metrics and Models in Software Quality Engineering
By Stephen H. Kan

SOFTWARE VERIFICATION AND VALIDATION

Software Test Automation/Effective Use of Test Execution Tools
By Mark Fewster and Dorothy Graham

Automated Software Testing/Introduction, Management, and Performance
By Elfriede Dustin, Jeff Rashka, and John Paul

The Web Testing Handbook
By Steven Splaine and Stefan P. Jaskiel

ALL

Fundamental Concepts for the Software Quality Engineer
Taz Daughtrey, editor

From the Resource Reviews Editor:
This issue concludes my second year as resource reviews editor. I want to thank the many reviewers who make this possible. You do a great service to our readers. There are so many books available and the reviews point readers to good books in our field. I would also like to thank the publishers who provide the many books you have seen reviewed. We have grown from two reviews in my first issue to 13 reviews in this issue.

Please note that the CSQE body of knowledge (BOK) used in Fundamental Concepts has been updated since this book was published. The new BOK will be used as a guide for an updated handbook. Please see www.asq.org/certification/software-quality-engineer/bok.html for the current body of knowledge for CSQE.

If you have any comments about Resource Reviews, please send them to me. Sue_carroll@bellsouth.net

GENERAL, KNOWLEDGE, CONDUCT, AND ETHICS


Software Leadership: A Guide to Successful Software Development

Murray Cantor. 2002. Boston: Addison-Wesley. 193 pages.

ISBN 0-201-70044-1

(CSQE Body of Knowledge areas: General, Knowledge, Conduct, and Ethics, Software Quality Management, Software Engineering Processes, and Program and Project Management)

Reviewed by Jayesh G. Dalal


Murray Cantor states in the preface that he wrote this book out of frustrations with the dismal state of software development at many organizations. He attributes the problem to inappropriate leadership. He also points out the increasing realization by hardware firms of the value delivered by software in their products and their lack of software development experience. The book addresses needed leadership skills and is aimed primarily at software development managers with a background in nonsoftware disciplines.

Cantor’s premise is that a competent software development leader needs a good understanding of software quality, effective development practices, team dynamics, and appropriate leadership style. Throughout the book the importance of sound software architecture, iterative development process, team leadership, and appropriate level of communications is stressed. Manufacturing, construction, and hardware metaphors are effectively used to point out similarities and differences between software and product development. The author’s bias toward the Unified Modeling Language (UML) and the Rational Unified Process is visible, but he has adequately explained how the two approaches can help a leader address the software development challenges.

In this easy-to-read book Cantor has achieved his goal of helping a manager with a nonsoftware discipline background lead successful software development. The selected references listed at the end of each chapter under the title are a particularly useful feature for anyone seeking deeper knowledge of the topics discussed. A brief summary of the book follows.

The author begins by identifying the stakeholders for software products and discusses the quality attributes valued by each stakeholder. He then explains these quality attributes and discusses the importance of determining the priority of various quality attributes. A discussion of the risks with the goal of shipping zero-defect software concludes the first chapter.

The software design or software architecture is identified as the means of achieving quality and discussed next. The author selects UML as the method of choice for specifying software architecture and presents the common architecture views. How the UML diagrams address different quality attributes is also explained. Discussion of the central role of software architecture in a software development project concludes this chapter.

Discussion of the software project is the subject of the third chapter. Collaborative problem solving, product development problems, and the nonlinear nature of development effort are identified as key software project attributes. Implications of these attributes to software development and project leadership are explained. Discussions of the importance of “the right amount of communications” for dealing with the dynamic nature of software project and development risks conclude this chapter.

An economics model of software development, a generalized form of the COCOMO model, is presented next. The model identifies project difficulty, size, organization efficiency, and automation of routine tasks as four levers for improving productivity. Methods for manipulating these levers are discussed in this chapter. Discussion of overtime misuse concludes this chapter.

The need for adopting and standardizing on a robust software development process is the theme of the following chapter. The benefits of adopting a robust process and perils of not doing so are discussed at length. Attributes of a good development process are identified, and requirements for an effective process are explained. The Rational Unified Process, an iterative development process, is presented as the process of choice, and the four phases of this process are explained. The importance of staying with the process in times of perceived crises is also discussed.

The final chapter explains how the leader, with the right level of involvement, can keep the project on track and enable necessary communication for the development team. Leadership styles are discussed and the “team member manager” style is identified as the preferred style. How the Rational Unified Process supports this style of leadership, and how architecture-based project organization enables effective team communication are also discussed.

Throughout the book the limitations of serial/sequential approaches to software development are pointed out. In addition, an appendix is devoted to addressing the reasons why three of the commonly followed development approaches (the waterfall process, hands-off approach, and rapid prototyping) are generally ineffective.

Jayesh G. Dalal (jdalal@worldnet.att.net) is the immediate past chair of the ASQ Software Division, an ASQ Fellow, and a National Baldrige Award examiner. He has more than 30 years of experience as an internal consultant and trainer in the manufacturing, software, and service industries. He has an independent practice that offers management systems and process design, assessment, and improvement services to businesses.

Return to top

SOFTWARE QUALITY MANAGEMENT

Software Process Improvement: Practical Guidelines for Business Success
Sami Zahran. 1998. Harlow, England: Pearson Education. Reprinted by Addison-Wesley as part of the SEI Series in Software Engineering. 447 pages.

ISBN 0-201-17782-X

(CSQE Body of Knowledge area: Software Quality Management)

Reviewed by Carolyn Rodda Lincoln


Software Process Improvement is an introductory process improvement book by a British practitioner. The book therefore has a European flavor that is different from those published in the United States. It is fairly high-level, so it would be particularly good for senior managers, but process improvement teams would also glean important information from it.

This book has five parts: 1) Process Thinking, 2) A Framework for Software Process Improvement, 3) Making Software Process Improvement Happen, 4) Current Models and Standards for Software Process Improvement, and 5) Business Benefits of Software Process Improvement. “Process Thinking” contains the justification for having a process rather than product focus in software development. He uses illustrations from both technical and nontechnical subjects to make his points. For example, an orchestra playing without a conductor is like a process not managed, without notes is like a process not documented, without practice is like a process not trained, with everyone playing what they want is like a process not enforced.

In “A Framework for Software Process Improvement,” the author explains what infrastructure is required (executive sponsor, SEPG, and so on), how to do an assessment, and how to create a software process improvement (SPI) action plan. In “Making Software Process Improvement Happen,” he shows the steps for implementing SPI (for example, SEI IDEAL model) and explains how to institute a metrics program.

The longest part is “Current Models and Standards for Software Process Improvement” where he discusses CMM, SPICE, BOOTSTRAP, ISO 9000, Trillium, and a few other models. Since the book is more than five years old, later versions of the models have been published; however, it still provides a good overview of what is available and how they differ in approach.

The final short part is on “Business Benefits of Software Process Improvement” in which the author discusses benefits in the terms of hard numbers, for example, return on investment. He cites case studies, all of which were conducted before 1995.

The author’s overall approach to SPI is through the total quality management of Walter Shewhart, W. Edwards Deming, and Philip Crosby. He also refers extensively to Watts Humphrey and the CMM. He writes in a clear, logical style with many bullet points, tables, and lists. Since it is a high-level overview, he concentrates on the “why” and “what,” and leaves the “how” to other authors. The book has an extensive glossary and list of references for further study.

Software Process Improvement would be a good introduction to SPI for anyone who is just beginning to learn about SPI or has recently been asked to join an SPI team. It is particularly helpful if the SPI road map has not been chosen yet because it describes so many types of models. Even if the organization has already decided to use CMM, it provides a general background on why to do SPI and how to approach implementing it. Even after an SPI effort is well under way, it can serve as a reference for what to do next or as training material for a new team member.

Carolyn Rodda Lincoln (lincoln_c@titan.com) is an ASQ certified quality manager and member of the DC Software Process Improvement Network. She is currently employed as a process improvement specialist for Titan Systems Corporation and is implementing CMM at the Bureau of Labor Statistics in Washington, D.C. She holds bachelor’s and master’s degrees in math and was previously a programmer and project manager.

Return to top

 

SOFTWARE ENGINEERING PROCESSES


Agile Software Development

Alistair Cockburn. 2002. Boston, Mass.: Addison-Wesley. 278 pages.

ISBN 0-201-69969-9

(CSQE Body of Knowledge areas: Software Engineering Processes)

Reviewed by Pieter Botman

Welcome to the methodology bazaar! The software engineering community has been bombarded with information (and hype) relating to agile methods for at least two years now. Evolution in thinking and practice is to be expected in the software field, and these techniques have emerged from industrial practice, so they cannot be ignored. Experienced professionals, however, wait for various kinds of information about these methods before making large-scale changes. Would you want to develop space-shuttle software using a method “proven” on a payroll system project? First, detailed concrete descriptions of the methods themselves are required. Second, evidence is needed that indicates that the methods have been successfully applied in a number of different (but well-categorized) circumstances.

Alistair Cockburn wrote a book that is valuable and helpful. Consider it a second-generation book, distinguished from others in the “agile” wave in its scope and depth. Moving beyond the fuzzy and somewhat political nature of some books on agile methods, he clearly lays out his family of agile methodologies (called the Crystal family), along with information about teams applying the various methodologies in different environments.

This book is written for experienced developers and is not a simplistic work resting on a list of cookbook approaches to development. Cockburn wants to “reexamine the notions that underlie software development,” and does not attempt to explain software development using the traditional “software engineering” framework. He explores the many aspects of communications, expectations, and behavior within software development projects, and these social themes play a large role in the agile development movement presented by Martin Fowler and Jim Highsmith.

Communication and collaboration issues affect interactions between people on a project, including programmers, customers, domain experts, and managers. They affect management philosophies, team dynamics, and individual work styles. But Cockburn makes the point that not everything is knowable in advance, so great care must be put into how team members interact dynamically, as events unfold during development. After beginning with a more general discussion of these various social forces, Cockburn moves on to bring these factors together for a dynamic development team—one that is largely self-managing, tightly integrated, and highly communicative, gathering frequently in front of a status board, reacting to needs as they change.

Cockburn is honest in positioning his family of methodologies, admitting that the development of life-critical systems is not addressed. He mentions that his methodologies are not recommended for distributed teams. He also makes useful comparisons to extreme programming (XP), responsibility-driven design, adaptive systems development (ASD), and the rational unified process (RUP) at various points. Interestingly, he does not directly criticize the RUP, saying that it is “not incompatible” with the agile principles explained in the book. He does believe that the RUP does not lead to sufficient emphasis on communication, and that many managers do not tailor the RUP sufficiently.

Like the other authors from the agile group, Cockburn covers the rationale and primary philosophies from the Agile Manifesto (Fowler and Highsmith), but goes further in relating these principles to the concept of a methodology and what a methodology should accomplish. In fact, he takes great care in laying out his criteria for the design of a methodology. Methodology gurus, take note—one of his criteria for a successful methodology is: “Would you use this methodology again?”

Cockburn’s ideas regarding development methodology are not merely mechanical in nature. In fact, he rarely gets down to specifics on work products, leaving that to be determined locally. Most of his ideas and criteria center on human communications, dynamic team learning, and adaptation. His methodologies are highly people and communication centric, and flexible in terms of work products and level of ceremony. He devotes an entire appendix to interesting papers on knowledge, language, and communication.

At last someone has published a multidimensional view of agile development—one that takes into account factors that must change as teams become larger, as technical risk rises, or as resources become scarcer. Far from being dogmatic and single-mindedly pushing simply for one simplistic method, Cockburn argues that methodologies must be adapted and tailored, even dynamically adjusted on the fly, within the context of a specific project. He builds this on-the-fly “dynamic tuning” of the methodology into the methodology itself, calling for both pre- and post-increment reflection workshops, where practices are examined, and can be altered.

With the general principle of his methodology thus expressed, Cockburn describes the range of methodologies in the Crystal family, from crystal clear (designed for low numbers of project staff, nominally six), through yellow and orange, to crystal red (high numbers of project staff, nominally 80) and so on. Within each color in the family, the methodology can also be adjusted to adjust for increasing risk, by the use of “more rigor and ceremony.” Cockburn examines the similarities of crystal clear to the XP methodology. Cockburn does not go into each variant at length, although he does so in other works and his own Web site.

This book is definitely worthwhile for experienced software practitioners who are looking for more than a simple list of agile practices. It presents the rationale for agile development with significant intelligence and pragmatism. While there is skepticism from some in the software engineering community (such as Barry Boehm in IEEE Computer), lightweight practices will certainly have their place. Cockburn sums it up thus:


“Light methodologies draw on understanding, discipline and skill more than on documentation, process and formality. They are particularly well suited for exploratory situations.”

Cockburn presents many important principles affecting development methodology, particularly the social factors. These alone should give all managers something to consider, even if they retain their documentation-heavy and planning-driven practices.

Pieter Botman (p.botman@ieee.org) is a professional engineer registered in the Province of British Columbia. With more than 20 years of software engineering experience, he is currently an independent consultant, assisting companies in the areas of software process assessment/improvement, project management, quality management, and product management.

Return to top


E-Business and IS Solutions: An Architectural Approach to Business Problems and Opportunities

William J. Buffam. 2000. Boston, Mass: Addison-Wesley. 256 pages.

ISBN 0-201-70847-7

(CSQE Body of Knowledge area: Software Engineering Process)

Reviewed by John D. Richards, SRA International

 

As the author states, this is not a “how-to” book, but rather it identifies the key practices and principles that lead to success in the development of information systems (IS), in particular e-business systems and solutions. While not necessarily new, these principles and practices have been frequently misapplied. So frequently that real-world IS developments have suffered in excess of 50 percent failures. The supporting objectives for this book are:

  • Define what constitutes “architecture” in the context of information systems
  • Provide a high-level introduction to, and understanding of, the architectural approach to building information technology (IT) solutions
  • Explain the benefits of the architectural approach

This book also addresses how building e-business solutions differs from traditional IS solution building. The intended audiences as designated by the author include business managers involved in e-business and IS solutions, IS professionals with limited experience, and experienced IS professionals.

The book is divided into three sections: setting the scene for architectural solution building, the seven-stage solution building processes, and let’s get practical. These are followed by an epilogue that is a short synthesis or distillation of the most important principles and practices for quick reference. The bibliography is annotated with short reviews of the referenced materials adding to its value. The index is very comprehensive adding to this book’s usefulness as a reference work.

This book is very well organized and coherently structured. Chapters begin with a brief overview and end, where appropriate, with a section on where to get additional information. The text flows well and includes numerous charts, figures, and illustrations that help one understand the material.

I strongly recommend this book to the audiences suggested by the author and also to consultants, e-business developers, or other individuals involved in the selling or development of either IS or e-business solutions. It is a book that will be a ready reference.

John D. Richards (john_richards@sra.com) is an account and project manager for SRA International in San Antonio, Texas. He has more than 30 years as a manager and leader. He is a certified quality engineer and auditor and a Senior member of ASQ. He has a doctorate and an advanced master’s degree in education from the University of Southern California, and master’s and bachelor’s degrees in psychology. He serves as an adjunct professor at the University of the Incarnate Word teaching courses in statistics, quantitative analysis, management, and psychology.

Return to top


Component-based Product Line Engineering with UML

Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jurgen Wust, Jorg Zettel. 2002. London: Addison-Wesley. 506 pages.

ISBN 0-201-73791-4

(CSQE Body of Knowledge areas: software quality management, software engineering processes, program and project management)

Reviewed by Gordon W. Skelton


Aside from a title that is less than self-explanatory, Component-based Product Line Engineering with UML, this is an excellent book on the concepts and process of building a software system based on component engineering. The authors explore the use of KorbA, a system designed for modeling software architectures. KorbA is based on existing object-oriented methodologies such as OMT, objectory, fusion, and catalysis. Though KorbA is a component-based methodology, the authors introduce a new term “Komponent” to describe the logical components that are employed as building blocks.

KorbA was developed in Germany; thus, its name is derived from the German term Komponentenbasierte Anwendungsentwicklung (German for “component-based application development”).

The text is comprehensive in its approach and is directed toward readers interested in gaining greater insight into component-based software engineering, that is, students, developers, software engineering practitioners, and academia. Since its focus is on component-based software development, and even though it employs the Unified Modeling Language (UML), it is not a tutorial on object-oriented software engineering or the UML. For this reason, I consider the text to be of intermediate to advanced nature, building upon the reader’s prior knowledge and experience.

In reading the book I was introduced to many different concepts and software-engineering methods of which I was not familiar. These methods, that is, OORAM, HOOD, FODA, FAST, PuLSE, have European foundations and have not been widely examined in the United States. Broadening my knowledge base is one of the advantages of being exposed to research and methodologies being developed in other countries. This exposure is one of the reasons I recommend this book.

The authors present their method in an ordered and understandable manner. They express the basic goals of KorbA as being simple, systematic, scalable, and practical. These goals have long been a target for many software development methodologies; however, not all have achieved them. In the case of KorbA, I believe that they have made a true contribution by developing a method applicable to complex software systems. People coming from the eXtreme programming world may argue that formalization in a process is a process’s weakness link.

The authors do an appropriate job of presenting the elements of their method by applying it to a unified project that flows through the book. Using this technique aids in continuity in the text and assists readers in gaining a solid understanding of the component-based technique.

This book is more than just an exploration of the authors’ methodology; in fact, it can be quite beneficial as a reference guide to solid software engineering. Attention is directed to many of the key elements of the software development life cycle, including project monitoring and control, component specification, domain engineering, and quality assurance. Adding to these elements, the authors provide reference appendices, which cover both the KorbA metamodel and the process metamodel. These appendices are helpful if one is interested in comparing KorbA with other methods.

Overall, I recommend this book to anyone who is involved in component-base software engineering or would like to expand his or her knowledge of developing quality software systems. In addition, I find this book to be a helpful addition to my library, especially when I need another point of view on how software should be developed.

Gordon Skelton (gwskelton@mvt.com) is vice president for information services for Mississippi Valley Title Insurance Company in Jackson, Miss. In addition, Skelton is on the faculty of the University of Mississippi, Jackson Engineering Graduate Program. He is an ASQ Certified Software Quality Engineer and is a member of the IEEE Computer Society, ACM, and AITP. Skelton’s professional areas of interest are software quality assurance, software engineering, process improvement, and software testing.

Return to top

Cocoa Programming for Mac OS X

Aaron Hillegass. 2002. Boston: Addison-Wesley. 370 pages.

ISBN: 0-201-72683-1

(CSQE Body of Knowledge area: Software Engineering Processes)

Reviewed by Douglas A. Welton

Cocoa Programming for Mac OS X by Aaron Hillegass is an easy-to-read and well-illustrated journey through the ins and outs of Cocoa, Apple’s object-oriented application development environment. The book’s purpose is to provide a wide range of “how-to” information designed to get those new to Cocoa up to speed as quickly as possible.

Apple Computer’s release of Mac OS X in March of 2001 culminated a four-year effort to successfully integrate a diverse collection of evolutionary and revolutionary technologies into a seamless user experience. Going beyond the user interface (called Aqua), Mac OS X provides software developers with several unique application development environments (Classic, Carbon, Cocoa, and Java). Each environment is designed to facilitate building new applications that take advantage of the unique and powerful underlying technologies Mac OS X has to offer.

Hillegass’ book documents how to build an application using Cocoa, the object-oriented framework (that is, software libraries, headers, and documentation from NeXTSTEP) that was grafted onto Mac OS after the merger between Apple and NeXT in 1998.

According to Apple, Cocoa provides developers with the fastest way to implement new Mac OS X-only projects. Cocoa is small, well designed, easy to learn and use, and provides opportunities for developers from different backgrounds to build innovative and compelling Mac OS X applications.

For many new-to-the-platform software developers, however, Cocoa was one of the more underdocumented tools available on Mac OS X. Cocoa Programming for Mac OS X addresses the needs of these software developers in several ways.

  • Writing style. This book is written in a casual but directed style. Hillegass has years of experience as a trainer and curriculum developer at both NeXT and Apple and this shows in his writing. The book gave me the feeling that it was simply a transcript from one of Hillegass’ seminars.
  • Extensive illustrations. Almost everything one will see on the screen while doing the examples has been captured and included in the book. For readers who are new to Mac OS programming, this type of visual explanation can be quite reassuring.
  • Software Examples. As the book progresses, Hillegass uses examples to explain the concepts he is trying to illustrate. For instance, as the reader progresses from chapter 4 to chapter 10, the RaiseMan example is designed, developed, and augmented to reflect the new ideas to which the reader is being exposed. Although the book does not include a CD of example code, the reader may wish to download the book’s example code from the author’s Web site (http://www.bignerdranch.com).
  • Entry-level focus. Hillegass takes the time to cover a large number of low-level concepts that may be unfamiliar to programming beginners (including sections on How to Read This Book and How to Learn found in chapter 1). The book’s success as a learning tool will be greatly enhanced by appropriately setting the level of the reader’s expectations.
  • Scope of topics covered. Cocoa is a relatively small object framework. Hillegass does a good job of covering the majority of important areas within Cocoa. However, in many cases, this strategy leads to a thin documentation of some important concepts (for example, incorporating drag and drop into your programs). The tradeoff is that the book provides a broad range of exposure to most of the objects within Cocoa.

In general, Cocoa Programming for Mac OS X does a good job of preparing the reader for an initial project using Cocoa. If I were asked how I thought the book could be improved, I would suggest that first, the author focus on organizing the book to locate related topics closer together and second, that he provide additional depth for most topics covered.

Douglas A. Welton (dwelton@bellsouth.net) is a computer scientist and playwright. Over the course of his career, he has contributed innovation, vision, and excellence to leadership roles and product success at Digital Equipment Corp., HBO & Co., Bell + Howell, and Merant. One of his current projects is authoring the forthcoming book Insanely Great Object: A Guide to Software Development Using Objective C and Cocoa on Mac OS X.

Return to top


PROGRAM AND PROJECT MANAGEMENT


Manager Pool: Patterns for Radical Leadership

Don Sherwood Olson and Carol L. Stimmel. 2002. Boston: Addison-Wesley. 280 pages.

ISBN 0-201-72583-5

(CSQE Body of Knowledge areas: General Knowledge (Leadership tools and skills), Program and Project Management, Software Quality Management

Reviewed by J. David Blaine, CSQE, PMP

This book can help software project managers and those who direct or lead others in software development. The authors were motivated to produce this book from the conviction, found through their own software development and management experiences, that modern software development projects must be managed from a new vision. The vision is that organizations are effective when they respect individuals’ uniqueness and that management is “enlightened.” Enlightened means, in one sense, that managers abandon the McGregor’s Theory X management philosophy.

Underlying Manager Pool is the authors’ conviction, gained from experience in real-world software development projects: People matter most. Regardless of the particular development paradigm, tools, technologies, schedules, charts, and graphs, software is development by people, and the manager’s main job is dealing with the human facets of projects.

The authors have applied the now well-known patterns paradigm to project management and leadership. Readers of Manager Pool may already be familiar with the application of patterns, as originated in the seminal work by Christopher Alexander in The Timeless Way of Building, to object-oriented software design, and to software problem frames.

Sixty-one distinct “patterns” are described. Each pattern, in its own chapter, has an interesting title that the authors have carefully designed to serve as a “handle” to the pattern. The chapter states a specific problem to be solved and a solution. The layout of the book makes it easy to leaf through and pick up the gist of each pattern. Each problem is bolded at the chapter beginning and the solution is bolded at the end. Within the body the authors discuss the context, forces, challenges, and issues related to the problem pattern.

The patterns are organized into five categories.

  1. Psychological and retentive: Patterns that describe a state of mind versus actions, and that form the basis for the rest of the patterns. These represent ways of thinking that can be internalized.
  2. Behavioral and expulsive: These patterns are manifested in outward behavior. The behavior patterns are based on the notion that effective leaders must recognize situations in the project and understand the underlying reasons for the situations.
  3. Strategic: Patterns that lay ground-work for the future of the project by focusing on the team as a unit.
  4. Tactical: Patterns that are specific to situations that occur during development or during team formation.
  5. Environmental: Patterns that surround developers.


Several patterns from Manager Pool may strike a familiar chord with many developers. Pattern 23 “Overtime Detox,” the stated problem is “Overtime…remains the most abused and dangerous hammer in the management toolbox.” The offered solution, “Oppose … the temptation of overtime. Resist pressure to compress schedules without corresponding feature reduction…” This is music to the ears of many from the schedule-crunched world of commercial software.

Another sample from Manager Pool may also help readers understand the book’s contents. Pattern 26 is “Push the Customer.” The problem: “Developers become angry and disgusted at working on ‘critical’ projects that get cancelled or mutated at the last minute. …You [the manager] need to manage the chaos your customers are repeatedly trying to inflict on you and your team.” The pattern’s solution: “Tightly control your customer’s expectations. Effective customer management is the key to ending an eternity of fruitless labor.” Well, to this reviewer’s ears, truer words were never spoken.

This book offers an innovative and interesting addition to the program and Project Management knowledge area of the CSQE body of knowledge. This book is recommended for software project managers and software quality managers. Software developers may also find this book helpful, if only to buy and then present to their managers.

J. David Blaine (jblaine@san.rr.com) is the current ASQ Region 7 Software Division councilor. Blaine recently joined Pacific Property Consultants as vice president, quality and process engineering. He has more than 25 years’ experience in aerospace and telecommunications as a software developer, project manager, and quality professional. Blaine holds ASQ Certified Software Quality Engineer and PMI Project Management Professional certifications. He is a co-founder of the San Diego SPIN. Blaine has bachelor’s and master’s degrees in mathematics, and a master’s degree in electrical and computer engineering.

Return to top

The Accidental Project Manager: Surviving the Transition from Techie to Manager

Patricia Ensworth. 2001. New York: John Wiley and Sons, Inc. 255 pages.

ISBN 0-471-41011-X

(CSQE Body of Knowledge area: Program and Project Management)

Reviewed by G. Timothy Surratt

The author clearly indicates that this book is designed for new project managers who were formerly engineers (techies) in organizations “whose primary purpose is not commercial software development.” The primary audience includes those within IT organizations who support an internal user community. The author also states the work would help those who manage or need to understand the activities in such an organization. The disclaimers in the “Who Should Read This Book” section are a bit long, as this book contains valuable information for any first-time project manager. As such, there are a number of possible pitfalls discussed and caution points discussed.

This book is organized according to a project life cycle, starting with project definition and ending with closeout and celebration. The chapters are cutely titled: “Exploring the Elephant” covers understanding the problem and the users. The sections and subsections are more direct (“Know the Users”). The project life cycle is covered in four sections:


I. Before Coding Begins (research and analysis)

II. During Development (design and construction)

III. At Rollout (deployment)

IV. After Release (assimilation and maintenance)


Each section has three chapters, each devoted to a different role that the project manager must play: entrepreneur, technology partner, and team captain. Basically, the entrepreneur has to deal with customers and get funding, the technology partner deals with the fact that there are several projects in the IT department, and the team captain has to manage a group of IT professionals (techies).

Within each chapter, the author provides a well-structured discussion of the activities that need to occur, artifacts that should be produced, methods to consider, and problems that one may encounter. The book is filled with questions to be asked and answered. Clearly the lists are the result of considerable practical experience in managing projects.

This is aided by a Web site (maintained by the publisher) with additional information and resources. Concepts are introduced and explained in an appropriate order. The level of explanation is for the beginner; however, there are a lot of details included in the various steps, so even an experienced project manager may find items to think about in this book. Each chapter ends with a milestone marker, which describes briefly what progress one should have made at this point.

This book is written in an informal style, making it easy to read. It is well indexed so readers can find things easily. Chapters, sections, and subsections are fairly short, so the points come quickly. There is a lot of practical information—more than enough detail to understand what is intended, but not so much as to lose the reader. The materials on the attendant Web site are well organized and downloadable in MS-WORD format. The author’s approach is to focus on the user and the team. The emphasis is well placed, especially for “new” project managers who might rely on their technical skill. The author indicates in a few places where that approach can lead one astray.

As an introductory book, there is one egregious omission: There are NO references. While there is a lot of information, there are no pointers sending readers to places to learn more. There are such pointers on the Web site, but this begs the issue. If the audience is as stated, they should be pointed to places to find more details about key topics. This book will get one started, but there is more to project management, and the book provides no help in finding that information, or even a starting point in the search.

There are some other minor issues from a software quality viewpoint: there is a lot of emphasis on testing and not as much on review and inspection. In fact, the book has a small section on “Code Reviews,” not inspections. The issue of life-cycle selection is cursory at best. Again, the author’s key to quality is focus on the user, build a strong team, monitor progress well, and plan for things to happen.

For readers in the target audience of this book, it is a book to consider but not the only one to have. For those outside the target audience, they may find this interesting, as it has a lot of tips and is easily read. This will not, however, help significantly in understanding project management as a discipline or how it fits the CSQE body of knowledge.

G. Timothy Surratt (tsurratt@xnet.com) is the secretary of the ASQ Software Division and an ASQ Fellow. He is currently director of engineering quality for WMS Gaming. Surratt has more than 25 years of software engineering and quality management experience. He is also the associate director of the ASQ Chicago Section Training Institute responsible for quality management. He has a doctorate in chemical physics from Cal Tech, and is an ASQ Certified Quality Manager, Software Quality Engineer, Quality Engineer, and Quality Auditor.

Return to top

SOFTWARE METRICS, MEASUREMENT, AND ANALYTICAL METHODS

Practical Software Measurement Objective Information for Decision Makers

John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, and Fred Hall. 2001. Boston: Addison-Wesley. 294 pages.

ISBN 0-201-71516-3

(CSQE Body of Knowledge areas: Software Metrics, Measurement, and Analytical Methods)

Reviewed by Scott Duncan


The preface says this book “describes an approach to management by fact for software project managers based on integrating the concepts of a measurement information model and a measurement process model.” As such, the book contains material derived from the practical software and systems measurement (PSM) work sponsored by the U. S. Department of Defense and U. S. Army and from the ISO/IEC JTC1/SC7 work on measurement model/process embodied in ISO 15939 (where the PSM work was, as the authors of this book put it, “formalized”). Indeed, the authors of this book are listed as the authors of the PSM Guidebook (v. 4.0, November 2000), and several of the authors have been significant participants in the work on ISO 15939.

The book states that the purpose of having a measurement information model is to “define the relationship between the information needs of the manager and the objective data to be collected, commonly called measures.” The model recognizes three “levels” of measures: base, derived, and indicators. The glossary defines a base measure as “a measure of a single attribute... [which is] functionally independent of other measures,” such as lines of code. A derived measure “is a function of two or more values of base and/or derived measures,” that is, some combination of more independent measures. Finally, an indicator is described as “an estimate or evaluation of specified attributes derived from an analysis model with respect to defined information needs,” that is, they provide information to a user for decision-making purposes and are not “raw” base/derived measures in that some interpretation is placed on them through the model.

The measurement process model, according to the book, “describes a set of related measurement activities that are generally applicable in all circumstances.” In particular, the four activities covered are: establish, plan, perform, and evaluate. The book acknowledges the similarity to “the commonly seen plan-do-check-act cycle.”

The book is divided into eight chapters and three appendices, plus a glossary, bibliography, and index. The appendices include two case studies and “examples of how the measurement information model is actually applied to define and combine indicators, derived measures, and base measures into a useful information product.”

Under the discussion of information needs, the book mentions the seven categories of information from the PSM: 1) schedule and progress, 2) resources and cost, 3) product size and stability, 4) product quality, 5) process performance, 6) technology effectiveness, and 7) customer satisfaction. Needs can be targeted to fit within one (or more) of these categories, guiding the measurement program to specific measures (base, derived, and indicators), which will supply management with the information required to make more objective (fact-based) decisions.

Lessons learned offer standard advice for initiating any organizational program such as start small, provide adequate training, demonstrate commitment, minimize costs, adopt an action orientation, and communicate.

Measurement success factors involve two characteristics: high integration of measurement “into management and technical processes” and support “by the corporate culture.” The indicators of success noted are:

  • “Automatic and natural” data collection (due to integration into the work processes)
  • “Widely available” data (also due to integration into the work processes and a cultural recognition that data are valuable)
  • Data are sought by people for decision-making (from confidence in the data within the organizational culture and the availability of data)
  • Desire to seek “understanding rather than blame” when failure occurs (a cultural phenomenon that develops from getting used to what having data means to decision-making)
  • “Numeric objectives are accompanied by rational plans” (more cultural impact though associated with integration into management and technical processes)
  • “Improvements are made regularly to the measurement process” (part of treating measurement as a work process like any others that can be improved)

The preface also references the PSM site (www.psmsc.com) where this book is called “the official, definitive guide to PSM” and where one can find the following documents available for free download:

  • PSM Guidebook Update (Version 4.0b, November 2000). PSM Insight Version 4.1.0 Software – actual software (13+Mb of it) to implement aspects of the measurement model and process.
  • Guidebook on PSM: Measuring for Process Management and Improvement – an SEI document.
  • A variety of measurement technology papers – on OO measurement and other topics, some from the SEI.


At first glance, one might think that simply taking these free materials could suffice without this book; however, one would also need ISO 15939 which contains model information and measurement process concepts. Also, given that some parts of the 4.0b guidebook are not yet on the Web site, but similar material is present in this book, the book fills in some of the gaps. Of course, if one has the PSM materials, ISO 15939, and this book, one has a complete set of sources and guidance. One thing this book does not have, but the guidebook does contain, is an extensive listing of measurement category descriptions and indicators. On the other hand, the book offers the two case studies that cannot be found in the guidebook.

Overall, if one needs an effective introduction to and overview of how to establish a measurement program, this book can fill that need. I would, however, recommend the PSM material and ISO 15939, which add substantive breadth of detail to what the book describes.

Scott Duncan (softqual@mindspring.com) brings 30 years of experience in all facets of internal and external product software development with commercial and government organizations. For the last nine years he has been an internal/external consultant helping software organizations achieve international standard registration and various national software quality capability assessment goals. He is a member of the IEEE-CS, ACM, the current Standards chair for ASQ’s Software Division, and the division’s representative to the U. S. Technical Advisory Group for ISO/IEC JTC1/SC7 and to the Executive Committee of the IEEE SW Engineering Standards Committee.

Return to top

Metrics and Models in Software Quality Engineering

Stephen H. Kan. 1995. Boston: Addison-Wesley. 344 pages.

ISBN 0-201-63339-6

(CSQE Body of Knowledge areas: Metrics, Measurement, and Analytical Methods)

Reviewed by Carol A. Dekkers

The back cover of Stephen Kan’s book states: “If you need to understand how to measure software quality and how to use measurements to improve your software development, you will want to have a copy of this book. Metrics and Models in Software Quality Engineering provides the information and teaches the skills you need to measure and improve the quality of the entire software development process from high-level to low-level design, as well as all phases of reliability.

“Joining action plans with actual project experiences, this book focuses on using, not just describing, metrics. It provides detailed coverage of essential issues and techniques, including software metrics, software reliability models, and models and analysis of program complexity. Metrics and Models in Software Quality Engineering goes even further, discussing such topics as in-process metrics, defect removal effectiveness, customer satisfaction, and more. Numerous real-life examples, many taken from the author’s experience as the software quality focal point for IBM’s Baldrige Award-winning AS/400, show you how to put the theories and techniques to work. The book also contains examples from such major computer companies as Hewlett-Packard, Motorola, and the NASA Software Engineering Laboratory.

“This excellent balancer of theory, techniques, and examples makes for a highly instructive and practical book on one of the most important topics in software development.”

Author Stephen Kan, an ASQ Certified Quality Engineer and Reliability Engineer, knows about which he writes. Since 1988, he has been involved in AS/400 computer software—and at the time of the writing, was the process manager of the quality management process in product development of the AS/400. While his specialization is AS/400, Kan remains fully grounded in general quality principles and creates a comfortable rapport with readers throughout this book.

There are many aspects of this book that make it an informative read the first time through and a useful textbook reference thereafter. Some of the highlights include:

  • Review of quality principles for newcomers to the software quality arena
  • Fundamentals in measurement theory (in language that is readily digestible by software professionals)
  • Basic measures, six sigma, and types of “metrics” and when to use them in a metrics program
  • Real-life examples of implemented metrics programs (Motorola, HP, IBM Rochester)
  • Seven major tools of Ishikawa (one of the first proponents of statistical process control theories applied to software)
  • Literature review and findings to define software defect removal efficiency
  • The Raleigh model and its application to software
  • In process metrics and measures
  • Collection and analysis of satisfaction data

Intermixed with the theories and facts of Kan’s research are plentiful opinions and notes that caution readers on such things as “Be careful with correlation.” He also warns readers to be cautious about applying SPC principles directly to software activities without due diligence and planning.

Would I recommend this book? Absolutely. For those who are interested in getting started and finding out about the major principles associated with software quality measurement and the models to support it—this is the ideal book. Kan eloquently combines aspects of many other books providing a one-stop introduction to Metrics and Models in Software Quality Engineering, and balancing an even mix of theory and practical application to allow readers to quickly get started with a realistic measurement program.

Carol A. Dekkers (Dekkers@qualityplustech.com), an SQP Editorial Board member, is a past IFPUG president and is president of Quality Plus Technologies, Inc., specializing in function point analysis training and software measurement consulting. Dekkers earned her bachelor’s degree in mechanical engineering from the University of Calgary and is a Certified Management Consultant, a Certified Function Point Specialist, and a Professional Engineer (Canada). She is the host of a weekly IT radio show available over the Internet, “Quality Plus e-Talk with Carol Dekkers,” and is a regional councilor for the ASQ Software Division.

Return to top

SOFTWARE VERIFICATION AND VALIDATION


Software Test Automation/ Effective Use of Test Execution Tools

Mark Fewster and Dorothy Graham. 1999. Great Britain: Addison-Wesley. 576 pages.

ISBN 0-201-33140-3

Automated Software Testing/ Introduction, Management, and Performance

Elfriede Dustin, Jeff Rashka, and John Paul. 1999. Boston: Addison-Wesley. 575 pages.

ISBN 0-201-43287-0

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

Reviewed by Milt Boyd

Software test automation (STA) “describes how to structure and build an automated test regime…on a medium to large scale…include practical advice for selecting the right tool and for implementing automated testing practices… intended to be of most help to those starting out… [showing] the most likely problems and how to avoid them.”

Automated software testing (AST) “is a comprehensive, step-by-step guide to the most effective tools, techniques, methods… everything you need to know to successfully incorporate automated testing into the development process...[It] focuses on the automated test lifecycle methodology (ATLM) [parallel to] the rapid application development methodology commonly used today.” “The focus…is the pragmatic concerns and information needed by the software test engineer/ manager…the software developer, the quality assurance engineer, the project manager….”

These books want to advance beyond a collection of automated tests. They share a vision of automating the testing activity or process. There is a stark and clear contrast between them. STA focuses on the techniques involved in effective use of automated tools, presuming that organizational issues have been settled. AST, in contrast, focuses on management issues, and the life-cycle context involved in testing with automated tools.

STA is organized into two parts. Part 1 concerns techniques for automating test execution; part 2 provides case studies and guest chapters. There are also an appendix, a glossary, references, and an index.

Chapter 1 provides context for the topic. Chapter 2 distinguishes test automation from some alternatives. It gently walks readers through the intricacies and alternatives involved in test automation. This can be an eye-opener for those lacking experience.

Subsequent chapters concern scripting, automated comparison, automating pre- and post-processing, building maintainable tests, metrics, and choosing and implementing tools.

An interesting feature is the inclusion of “Experience Reports.” Short vignettes of real life, they bring home important points in wry or amusing ways.

The case studies in part 2 are varied. One is from the early days of test tools around 1990. Most contain cautionary tales about things that did not work right at first, with changes that had to be made. The studies are usually stronger on describing actions taken than on describing choices rejected.

AST is organized into four parts, with appendices. The intent is to match the tasks and steps involved in ATLM. Part 1 answers, “What is automated testing? Why do I need it?” Part 2 answers, “What is involved in setting up a tool? How do I get a test team in place? What early test planning is required?” Part 3 focuses on automated test planning, analysis, design, and programming. Part 4 addresses “What’s involved in doing the testing? How do I manage schedules? How do I document and track defects?” Part 5 has appendices on how to test requirements, tools, test engineer development, sample plan, and best practices.

AST also includes a CD-ROM containing documents in PDF forms and graphics in eps, jpg, pdf, and tif formats. The documents include a sample test plan, a list of sample tools, and tool selection criteria. The graphics portray the ATLM.

AST starts each part with a relevant aphorism to put the reader in the proper mind frame. Each chapter starts with a graphic of the automated testing life-cycle methodology, indicating “Where are we in the grand scheme?” Each chapter ends with a summary and references.

STA does a very good job of presenting a number of alternatives at every step. There are usually statements of the pros and cons associated with each alternative. These sometimes take the form of graphs with labeled axes but no scale. In the hands of an expert, these provide talking points for doing x rather than y; for the neophyte, they may be more of a confusing muddle of choices.

Similarly, the case studies serve to present real life in all its complexity and confusion. Experienced practitioners can mine these for valuable lessons. Neophytes may find it difficult to compare a study with their own situation and apply the principles with confidence. That said, I think the book’s case studies provide valuable information.

The book may be better suited for use in the classroom, or with access to someone who “knows the answers,” rather than for self-study. Clearly, a champion for the use of test execution tools can use this to bring an organization “up to speed” on what is to be done.

AST sets automated testing in the context of the whole organization. However, this focus results in a distracting depth of detail in some places. For example, Section 5.4 discusses test engineer recruiting, and within that, section 5.4.5 provides advice on locating test engineers. In fact, the advice is really about finding good candidates for any technical position.

Some details in appendix B of AST will become dated quickly. This appendix lists and describes particular tools, including their hardware requirements and supported platforms. Similarly, the list of test training organizations in appendix C may be overtaken by events.

In the Certified Software Quality Engineering body of knowledge, section VI deals with V & V. Both of these books can prepare the candidate for questions dealing with subsections C (test planning and design) and D (test execution and evaluation).

Both books contain material relevant to section III (SEP), especially subsections D (methods and tools) and E (maintenance management). However, AST provides more emphasis on the process aspects of test automation.

Both books describe the application of Software Configuration Management (SCM) to the materials used in automated testing. Both books are valuable but for different audiences. If test automation is new to the reader, and he or she has questions about technique, and
how to automate software testing, then STA is a good buy. If the reader has issues with management and organization, and the inclusion of automated testing in the development life cycle, then AST is the right choice.

Milt Boyd (miltboyd@arczip.com) is a member of ASQ’s Software, Reliability, and Quality Management Divisions. He is an ASQ Certified Quality Manager and is certificated by IRCA as a Lead Auditor of Quality Management Systems. He is currently employed as a systems engineer by Avidyne Co. of Massachusetts.

Return to top


The Web Testing Handbook

Steven Splaine and Stefan P. Jaskiel. 2001. Orange Park, Fla: STQE Publishing. 410 pages.

ISBN: 0-9704363-0-0

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

Reviewed by Eric Patel

This book can help testing professionals involved with a software development project to migrate a traditional mainframe, PC, or client/server system to a Web site/application. Each chapter focuses on a different perspective of what is important when testing a Web-based application. Considering the breadth and depth of Internet technologies employed by Web applications, this handbook is a useful guide to help readers understand and decipher the mysteries and complexities. In addition, there are case-study test plans available online that demonstrate how the chapter’s topics can be used to test a Web site.

“Compatibility,” helps readers with one of the most perplexing Web testing questions: “What combinations of client hardware and software shall we validate?” The solution lies in standardizing one’s test environment using a four-step strategy:

  1. Understand the client’s hardware and software capabilities
  2. Group the configuration information into categories
  3. Reduce the combinations to a manageable amount
  4. Install and implement the most likely combinations

Usability and accessibility are critical quality attributes in the Web world. Quantifying and measuring one’s Web site/application’s ease-of-use goals will help define the applications’ level of usability. This chapter also addresses readability, languages, colors, screen size, and personalization. The author’s five-step procedure coaches readers through conducting effective usability testing.

The hot issue of Web site performance is discussed, including smoke, load, stress, and spike/bounce testing. Three ways to improve performance are mentioned:

  • Reduce the entry point (for example, posting frequently-requested content on a file server)
  • Slow the degradation rate (for example, increase the network bandwidth)
  • Postpone the point of “drastic degradation” (for example, upgrading the hardware resource causing the bottleneck)

To model and test “real-world” Web site/application usage, the section on user profiles, factoring the numerous end-user variables such as think times and Internet access speeds, is particularly helpful.

The quality attribute of scalability is also addressed. Planning for future (and often rapid) growth and anticipated Web application use is an important yet often neglected part of Web migration. Solutions such as transaction monitors, load balancer, mirroring, and caching are discussed. The authors point out that one of the fundamental advantages that Web-based applications have over client/server applications is that additional servers can easily be added to accommodate increasing loads of requests. Even so, conducting effective scalability tests will almost certainly require the use of load generators and/or modeling tools, adding to the cost of testing.

Two additional quality attributes, reliability and availability, are also presented. If the user is not able to access one’s site, the section on “Diagnosing Performance Problems” mentions a handful of strategies including:

  • “Onion Skin” (start at the core and work out through the layers)
  • “Drill-Down” (review performance data as they are being captured by the tool/monitor)
  • “Bad-Apple” (replace with “good” components until the “bad” one is discovered)
  • “Christmas Tree Lights” (take each component and add it to known “good” components)

There are numerous testing checklists throughout the book that are informative and helpful. This handbook does stop short of recommending a formal, high-level test strategy (for example, a process or methodology). Nonetheless, each chapter describes in detail enough information for the tester to develop test plans to comprehensively test—and retest—any Web-based application.

Eric Patel (eric_patel@veritest.com) is a QA program manager who leads cross-functional testing efforts for VeriTest’s Boston-area clients through on-site consulting. He holds three certifications: ASQ Certified Quality Manager, ASQ Certified Software Quality Engineer (CSQE), and QAI Certified Software Test Engineer (CSTE). Patel is also deputy regional councilor for the ASQ Software Division Region 1 and serves as a reviewer for SQP and The Journal of Software Testing Professionals.

Return to top


ALL


Fundamental Concepts for the Software Quality Engineer

Taz Daughtrey, editor. 2002. Milwaukee, Wisconsin: ASQ Quality Press. 296 pages.

ISBN 0-87389-521-5

(CSQE Body of Knowledge areas: all)

Reviewed by Scott Duncan

This is a compilation of 20 articles, most of which have appeared in Software Quality Professional. The others are papers presented at the ASQ Software Division’s recent International Conferences on Software Quality. The introduction states the articles “span the Body of Knowledge established for the American Society for Quality’s Certified Software Quality Engineer (CSQE).”

It must be said that, while this is a collection of papers and presentations related to the CSQE body of knowledge (BOK), it is not specifically designed as a survey guide or handbook to that BOK. Indeed, the introduction says it “is not meant to provide any comprehensive treatment of the BOK or to serve as a primary study aid for those preparing to take the CSQE exam.” Work is going on right now to produce a handbook similar to handbooks in other ASQ areas of certification such as the CQA. Such a handbook would provide an outline of the topic area much in the same way that the Software Engineering Body of Knowledge (SWEBOK) has tried to do for the topic of software engineering, in general. This book collects various good articles and uses the CSQE BOK as the structure to organize them into chapters to make relating the articles to the BOK easier.

This book, then, could be a companion to a CSQE handbook in that it provides articles that go into some depth on various topics and, in many cases, provide descriptions of experiences applying the techniques and methods covered. Subscribers to SQP and those who have been to the ICSQs in recent years probably have most, if not all, of these articles somewhere. If not, this is a handy collection.

Reviewed by Greg Jones

This book is a collection of 20 different articles by different authors. The articles are grouped into eight sections, each corresponding to one of the topical areas in the Software Quality Engineering Body of Knowledge (SQEBOK). The SQEBOK is also the basis for ASQ’s Software Quality Engineer certification (CSQE). Because of this parallel organization, it seems reasonable that candidates will probably use the book as a secondary reference when reviewing for the CSQE examination. The articles are solid papers, by well-known and reputable authors, so the content of this book is very helpful to those reviewing for the CSQE exam and also to the general software quality professional.

Although this is a high-quality book, there are some weaknesses. For example, the title may be misleading. The words “fundamental concepts” might imply that this is an introductory text for software quality newcomers. However, many of the articles are neither fundamentals nor concepts. These articles do not always address concepts, but practical, real-world implementation in a complex environment, and are not always fundamental but are often rather advanced.

Additionally, the applicability of a particular article to the topical area in which it is included is not always clear. Some of the articles could have been in other groups, which can pose a problem for some readers. Readers new to the field might be confused as to what each topical area includes, and experienced readers might have a cognitive disconnect if an article is not in the topical area they expect. This lack of clarity is a result of including material of a practical nature rather than content of a more fundamental or conceptual level, a type of content that is more “artificial” and “theoretical,” and thus more easily categorized. In the practical world of advanced implementation and case studies included in the book, boundaries are not always as clean as those in the SQEBOK.

Despite these concerns, this book is a useful review for those already in the SQE field. While it is true that the book should not be used as a comprehensive study aid for the CSQE, it also may not be helpful as a reference for the new practitioner.

Greg Jones (greg.b.jones@bankofamerica.com) is a technology project consultant at Bank of America, specializing in software process improvement and the bank’s change management process. He was previously a QA manager at a financial information company, and a programmer/requirements analyst at a large public utility. Jones received a master’s degree in computer science at North Carolina State University in 1998, and a bachelor’s degree in nuclear engineering from Texas A&M University in 1985. He is certified as an ASQ Software Quality Engineer and a Quality Improvement Associate, and as a Quality Analyst by the Quality Assurance Institute (QAI). Jones is the founder and president of the Charlotte SPIN, past president of the Charlotte IT QA Association, and is an ASQ Software Division regional councilor.

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.