GENERAL KNOWLEDGE, CONDUCT, AND ETHICS
Software Leadership: A Guide to Successful Software Development
By Murray Cantor
SOFTWARE QUALITY MANAGEMENT
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
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.
(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.
Cantors 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 authors 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 (firstname.lastname@example.org) 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.
(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 authors 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 (email@example.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 bachelors and masters degrees in math and was previously a programmer and project manager.
SOFTWARE ENGINEERING PROCESSES
Agile Software Development
Alistair Cockburn. 2002. Boston, Mass.: Addison-Wesley. 278 pages.
(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 teamone 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 noteone of his criteria for a successful methodology is: Would you use this methodology again?
Cockburns 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 developmentone 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 (firstname.lastname@example.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.
William J. Buffam. 2000. Boston, Mass: Addison-Wesley. 256 pages.
(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:
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 lets 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 books 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 (email@example.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 masters degree in education from the University of Southern California, and masters and bachelors 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.
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.
(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 readers 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 processs 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 (firstname.lastname@example.org) 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. Skeltons professional areas of interest are software quality assurance, software engineering, process improvement, and software testing.
Cocoa Programming for Mac OS X
Aaron Hillegass. 2002. Boston: Addison-Wesley. 370 pages.
(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, Apples object-oriented application development environment. The books 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 Computers 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.
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 (email@example.com) 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.
PROGRAM AND PROJECT MANAGEMENT
Manager Pool: Patterns for Radical Leadership
Don Sherwood Olson and Carol L. Stimmel. 2002. Boston: Addison-Wesley. 280 pages.
(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 McGregors 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 managers 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.
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 books 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 patterns solution: Tightly control your customers expectations. Effective customer management is the key to ending an eternity of fruitless labor. Well, to this reviewers 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 (firstname.lastname@example.org) 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 bachelors and masters degrees in mathematics, and a masters degree in electrical and computer engineering.
Patricia Ensworth. 2001. New York: John Wiley and Sons, Inc. 255 pages.
(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 informationmore 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 authors 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 authors 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 (email@example.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.
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.
(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:
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:
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 (firstname.lastname@example.org) 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 ASQs Software Division, and the divisions 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.
Metrics and Models in Software Quality Engineering
Stephen H. Kan. 1995. Boston: Addison-Wesley. 344 pages.
(CSQE Body of Knowledge areas: Metrics, Measurement, and Analytical Methods)
Reviewed by Carol A. Dekkers
The back cover of Stephen Kans 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 authors experience as the software quality focal point for IBMs 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 softwareand 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:
Intermixed with the theories and facts of Kans 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 itthis 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 bachelors 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.
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.
Automated Software Testing/ Introduction, Management, and Performance
Elfriede Dustin, Jeff Rashka, and John Paul. 1999. Boston: Addison-Wesley. 575 pages.
(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 Whats 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 books 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 (email@example.com) is a member of ASQs 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.
Steven Splaine and Stefan P. Jaskiel. 2001. Orange Park, Fla: STQE Publishing. 410 pages.
(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 chapters 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 ones test environment using a four-step strategy:
Usability and accessibility are critical quality attributes in the Web world. Quantifying and measuring ones Web site/applications ease-of-use goals will help define the applications level of usability. This chapter also addresses readability, languages, colors, screen size, and personalization. The authors 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:
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 ones site, the section on Diagnosing Performance Problems mentions a handful of strategies including:
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 testand retestany Web-based application.
Eric Patel (firstname.lastname@example.org) is a QA program manager who leads cross-functional testing efforts for VeriTests 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.
Fundamental Concepts for the Software Quality Engineer
Taz Daughtrey, editor. 2002. Milwaukee, Wisconsin: ASQ Quality Press. 296 pages.
(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 Divisions recent International Conferences on Software Quality. The introduction states the articles span the Body of Knowledge established for the American Society for Qualitys 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 ASQs 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 (email@example.com) is a technology project consultant at Bank of America, specializing in software process improvement and the banks 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 masters degree in computer science at North Carolina State University in 1998, and a bachelors 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.