March 2003
Volume 5 • Number 2

Contents

Resource Reviews

GENERAL KNOWLEDGE, CONDUCT, AND ETHICS

Strategic Planning Technology Workbook for Small Businesses: Performance Optimization for Your Company, Division, Department, or Team
By Ron Ford and William C. Bean

Building Effective Project Teams
By Robert K. Wysocki

SOFTWARE QUALITY MANAGEMENT

Making Process Improvement Work—A Concise Action Guide for Software Managers and Practitioners
By Neil S. Potter and Mary E. Sakry

Building the Customer-Centric Enterprise—Data Warehousing Techniques for Supporting Customer Relationship Management
By Claudia Imhoff, Lisa Loftis, and Jonathan G. Geiger

SOFTWARE ENGINEERING PROCESSES

Software Fault Tolerance—Techniques and Implementation
By Laura L. Pullum

The Career Programmer: Guerilla Tactics for an Imperfect World
By Christopher Duncan

Agile Software Development Ecosystems
By Jim Highsmith

PROGRAM AND PROJECT MANAGEMENT

Information Security Management Handbook CD-ROM
By Harold F. Tipton and Micki Krause

SOFTWARE VERIFICATION AND VALIDATION

Lessons Learned in Software Testing
By Cem Kaner, James Bach, and Brett Pettichord

Software Verification and Validation for Practitioners and Managers
By Steve Rakitin

Software Testing, A Guide to the TMap Approach
By Martin Pol, Ruud Teunissen, and Erik van Veenendaal

Effective Methods for Software Testing
By William E. Perry

GENERAL KNOWLEDGE, CONDUCT, AND ETHICS

Strategic Planning Technology Workbook for Small Businesses: Performance Optimization for Your Company, Division, Department, or Team

Ron Ford and William C. Bean. 1995. Amherst, Mass.: Human Resource Development Press, Inc. 160 pages. ISBN 0-87425-270-9.

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

Reviewed by John Richards
John_Richards@sra.com

This book was designed to allow the small business owner, or leader of a segment of a larger business, to build “a comprehensive operational and strategic plan.” (p. 3.) This is a step-by-step workbook organized to educate and direct even a novice planner through the process of developing a practical, understandable, and implementable plan. It begins with the basic goals and purposes of a strategic plan. This book then carefully guides readers through the steps of strategic planning with clear diagrams, concise but adequate instructions, and detailed worksheets and sample forms.

The strategic planning process as described here consists of 10 steps: 1) business definition; 2) long-range vision; 3) values structure; 4) mission statement; 5) strategic enterprise assessment; 6) success and failure; 7) strengths, weaknesses, opportunities, and threats analysis; 8) strategic goal identification; 9) action plans; and 10) plan builder and implementation.

While an excellent aid for the inexperienced planner, this book is lacking in a few areas. The implementation section is only six pages long with one page devoted to a sample form and another to a sample meeting agenda. It would be useful to readers to have more information not only on tracking the implementation of the plan but also on how to evaluate its effectiveness. I would recommend another section, step 11, be added on tracking and evaluating the results of the plan. The user needs to know how to determine if the plan is being executed as designed and if the plan is working. This information is critical to the next round of planning. Essentially, check and act have been left out of the plan-do-check-act (PDCA) cycle. A list of other references would also be valuable.

Overall, this is a useful and well-prepared plan for those new to the development of strategic or business plans. The diagrams and sample forms are well done.

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’ experience 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.

Building Effective Project Teams

Robert K. Wysocki. 2002. New York: Wiley Computer Publishing. 266 pages and CD-ROM. ISBN 0-471-01392-7

(CSQE Body of Knowledge areas: General Knowledge - Team Management, Team Tools; Program and Project Management - Risk Management)

Reviewed by Eva Freund
efreund@erols.com

Think “mentor talking with you over a cup of your favorite brew” and one will have identified the focus of this book. Wysocki takes for granted that readers already have the basic management and project management skills. His objective is to reduce the risk that one’s project will fail by teaching readers how to build their team. He teaches readers a comprehensive system for assessing, forming, developing, and deploying an effective project team.

This book introduces the concept, model, and application of this system, which the author calls TeamArchitect. In addition, the book comes with a CD-ROM that contains all of the data used in the case study described in the book.

Part one provides the background and infrastructure for building effective project teams. Part two covers the assessment process and introduces five assessment tools, which do not require a certified professional to interpret the results. Part three takes the information compiled in part two and shows how the tools are used to profile a project and the project team. Part four shows how to develop strategies for making team alignment decisions and how to sustain that alignment over the life of the project.

Because I was not familiar with this author, I expected that this would be another book that described the team solely in terms of the skills needed by the project vs. the skills possessed by the team members. Instead I found that Wysocki takes the contrarian position—that individual thinking styles, problem-solving and decision-making styles, and conflict management styles and strategies have a major impact on the success or failure of the project regardless of the task or the project. In addition, the book contains generic knowledge, skills, behaviors, and experiences that identify the proficiency of the project manager. By comparing that profile to the project complexity level, the organization can determine the readiness of an individual to assume project management responsibility.

Wysocki understands that being able to recruit the entire project team may be a once-in-a-lifetime experience and that it is more likely that the manager will have either no choice as to the membership or a choice of only some team members. It is this understanding that distinguishes this book from other books.

In keeping with this mentor approach, the author makes it easy for readers to learn more. His list of suggested reading is diverse, and he provides his Web site to supplement the book and the CD-ROM. Finally, he provides his e-mail address so readers can contact him.

I recommend this book both for those who want to merely understand the concept of building an effective team and those who want to implement the concept and reduce the risk of project failure.

Eva Freund (efreund@erols.com) is an independent verification and validation (IV&V) consultant with 20 years of experience in software testing, standards, and project management. She offers IV&V and software process improvement services to private- and public-sector organizations. She is an ASQ Certified Software Quality Engineer and a Certified Software Development Professional from the IEEE Computer Society.

SOFTWARE QUALITY MANAGEMENT

Making Process Improvement Work—A Concise Action Guide for Software Managers and Practitioners

Neil S. Potter and Mary E. Sakry. 2002. Boston: Addison-Wesley. 264 pages. ISBN 0-201-77577-8.

(CSQE Body of Knowledge area: Software Quality Management)

Reviewed by Pieter Botman
p.botman@ieee.org

Process improvement (PI) as a concept is easily hyped and readily packaged for consumption by managers at the business/corporate level and within software engineering organizations. After all, who wouldn’t want to reduce waste, eliminate defects, shorten development cycle time, and improve customer satisfaction?

PI and assessment frameworks, both general and software specific, offer some value in relating software engineering practices to process models, but do not address many practical aspects of process improvement, particularly change management. This book, aimed at project managers as well as PI practitioners, goes back to basics and presents a pragmatic, from-the-ground-up approach.

This book does not dwell on higher-level PI theory, and the authors begin the book by denouncing approaches that are too “process centric”—approaches that do not produce real gains, and are perhaps overly motivated by the lure of an ideal process. Readers familiar with the Software Engineering Institute’s (SEI) Capability Maturity Model (SEI CMM) school of process improvement won’t find much discussion of the centralized “Software Engineering Process Group” here: “The (PI) plan owner should be the same person who owns the business goals being addressed by the plan…. The primary owner of the improvement plan should not be the process improvement group, the software quality assurance group, or similar support function.”

The book’s organization is simple, and reflects the thinking and actions of one individual (practitioner or manager) who must plan, implement, and manage change to processes within an organization.

“Developing a Plan” sets the pragmatic tone for the entire book. PI efforts begin with an accurate evaluation of actual problems, including their scope and their relation to organizational goals. In discussing the evaluation of problems, and the linking of problems to goals, the authors develop the important theme of broad consultation and cooperation. That theme will become even more compelling in subsequent chapters.

This book contains realistic sample lists of problems, explicitly and effectively linked to real business goals, and edited for clarity. The problems and goals are weighted or prioritized. Basili’s goal-question-metric (GQM) approach is introduced, and then well illustrated by a chart relating the PI goals, questions, and metrics for the example problems identified previously. The authors also offer some pragmatic tips concerning the use of more involved assessments in order to narrow the focus and help identify underlying problems, if not readily apparent after conducting interviews.

The planning chapter is also practical in addressing the action plan. The authors stress the tightly coupled relationship between problem, goal, and action steps. CMM practices, already organized in functional (key practice) areas and structured with respect to specific goals, are suggested as a resource in developing appropriate action steps. The action plan also contains detailed measurement steps and risk management considerations for each contemplated action.

The chapter titled “Implementing the Plan” is really about entering into selling the benefits and the details of the plan to the appropriate stakeholders. Change management terms and techniques are introduced in simple terms. Here the authors have advice not only for the individual PI practitioner attempting to influence a line manager or process owner, but also for the process owner in implementing change within his team: “Managers can help keep the efforts on track by providing a clear focus for each improvement, letting people know what is expected of them, and aligning their own behavior with the improvement…. Managers must remain informed about the planned improvements, and help people see how the new practices support organizational goals.”

These guidelines are doubly valuable—not only can a line manager use them to improve his own chances for success in implementing change—but the individual PI practitioner can also use them as starting points (and expectations) when beginning discussions with a line manager.

The chapter “Checking Progress” is aptly titled since it does not dwell on “completion” of PI. This is laudable and appropriate. With the groundwork laid out in careful planning, the actions have measurements laid out. So the aims of the checking are to monitor progress, then enact risk management and correction strategies if the action steps are producing negative results. The authors promote specific measurement and tracking of all improvement action steps, followed by determination of lessons learned and corrective actions related to the PI cycle as a whole (the PDCA cycle applied to PI!).

Another important practical consideration for managers and practitioners is relating action-step results to their associated business goals (and hence to the readily recognized business benefits). Once again the theme of communication and cooperation emerges. Regardless of technical merit, managers will support investment in PI only when the results are visible in business terms. Practitioners must be able to demonstrate, and build upon, success.

Some of the appendices are detailed expansions of some of the example lists and tables introduced in the book. Appendix A contains more detailed table mapping sample problems to specific CMM key process areas and practices. Appendix B contains a more complete listing of the cited CMM practices, and Appendix C contains a detailed action plan table, linking goals and prioritized actions. Appendix D contains a table summarizing a sample risk action plan. Not quite as useful, Appendix E contains a very short summary of the SEI’s CMM (v1.1) and CMMI-SE/SW/IPPD (v1.1), and Appendix F contains a short introduction to a “mini-assessment” process.

I found this book to be very pragmatic and straightforward. It includes an unusual blend of quality management, software engineering, and change management topics. While it would not serve as a reference book in any of these disciplines, I would expect that someone assuming the role of PI practitioner would already have significant insight into the technical aspects of software engineering processes. For beginning PI practitioners and managers, the emphasis must be on unifying these three disciplines and in presenting detailed methods of implementation. The authors have clearly achieved these goals.

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.

Building the Customer-Centric Enterprise—Data Warehousing Techniques for Supporting Customer Relationship Management

Claudia Imhoff, Lisa Loftis, and Jonathan G. Geiger. 2001. New York: John Wiley and Sons. 487 pages. ISBN 0-471-31981-3.

(CSQE Body of Knowledge areas: Software Quality Management and General Knowledge)

Reviewed by Jayesh G. Dalal
jdalal@worldnet.att.net

This book describes data warehousing techniques for supporting customer relationship management (CRM). Businesses have recognized the importance of CRM, and the more successful ones have deployed systems to support-related activities. This comprehensive book provides a roadmap for establishing a CRM program, identifies obstacles, and presents methods to overcome the obstacles. Business managers interested in improving their customer relationship management and the IT professionals supporting them should find this book useful.

The authors have written this book with two distinct audiences in mind: the business people who have to manage the customer relationship, and the technical people who have to provide the necessary computer systems support. The authors have succeeded in addressing the needs of these groups, but have taken almost 500 pages to do so.

The book is divided into three parts. The first 20 percent of the book introduces CRM, the next 40 percent addresses planning for CRM, and the last 40 percent covers CRM implementation. The authors have used the needs and experiences of a banking/financial services customer as basis for introducing various CRM concepts throughout the book. Since one can readily relate to this fictional customer, the approach helps readers appreciate the various CRM challenges and solutions presented in the book.

I found this book interesting but not easy to read. I did not like the amount of repetition, frequent references to material elsewhere in the book, and extensive use of acronyms (some not even explained at the first use). I also found the use of data as a singular rather than a plural noun distracting. I agree with the authors that those considering CRM need a balanced perspective of both the business and technical aspects of CRM. Considering the size of the book, however, business-oriented readers may want to skim the technical content, and the technically oriented readers may want to do the same with the business content.

Jayesh G. Dalal (jdalal@worldnet.att.net) is a past chair of the ASQ Software Division, an ASQ Fellow, and a Certified Software Quality Engineer. He has served as a National Baldrige Award examiner. For more than 30 years he was an internal consultant and trainer at large corporations with manufacturing, software, and service business. He now offers consulting and training services for design, assessment, and improvement of management systems and process.

SOFTWARE ENGINEERING PROCESSES

Software Fault Tolerance—Techniques and Implementation

Laura L. Pullum. 2001. Boston. Artech House, Inc. 343 pages. ISBN 1-58053-137-7.

(CSQE Body of Knowledge areas: Software Engineering Processes and Software Quality Management)

Reviewed by Jayesh G. Dalal
jdalal@worldnet.att.net

The number of computer-based and computer-controlled systems around us has steadily increased and so have the reports of their failures and associated consequences. The contribution of software toward the functionality provided by these systems has also increased steadily. In this book, Pullum provides a comprehensive overview of methods that can help protect against software design faults and tolerate operational problems induced by these faults.

Pullum defines software fault tolerance as the use of a variety of software methods to detect software-induced faults and accomplish recovery. She cautions that a fault tolerant system does not mean a safe system, and fault tolerance does not cover other dependability-related attributes such as reliability, availability, and so on. More than once in the book she also points out that the existence of a good requirements specification is essential for dependable software and that fault tolerance methods cannot compensate for requirements specification errors. The book addresses only the faults induced by software components of a system.

In the first third of the book, the author briefly reviews methods to produce dependable software, types of software error recovery, and software redundancy. The concepts of design diversity, data diversity, and temporal diversity and their use are explained, and some examples are provided. In addition, architectural structure for diverse software is explained and a few frameworks for the development of diverse software are presented. Finally, problems and issues associated with the fault tolerance techniques are discussed, and several programming methods are described. Design hints and a description of a dependable system development model conclude this segment.

Software fault tolerance methods use a combination of diversity and decision mechanism to accomplish fault detection and recovery. In the remaining two-thirds of the book a variety of diversity-based software fault tolerance techniques and decision mechanisms are presented. I found the format used by Pullum for the presentation of these methods very useful. First the operation of a method is explained, then its example is presented, and finally associated issues are discussed. This method of presentation made it easy to go back and forth between various methods and gain a better understanding. The design diverse and data diverse methods are covered in great detail. In addition, some methods that do not fall into these two groups are briefly described. The decision mechanisms or adjudicators are presented in the last chapter, where a variety of “voter” and “acceptance test” types of adjudicators are described.

Each chapter includes a summary and an extensive list of references. In addition, a summary is also provided for key sections. These features should be helpful to those who will use this book as a reference. In the preface, Pullum suggests that the book may be used as reference by software professionals or as a textbook for a graduate-level software engineering course. I agree. My only disappointment with the book is that the concept of robust software is treated cursorily and no references for this topic are provided.

Jayesh G. Dalal (jdalal@worldnet.att.net) is a past chair of the ASQ Software Division, an ASQ Fellow, and a Certified Software Quality Engineer. He has served as a National Baldrige Award examiner. For more than 30 years he was an internal consultant and trainer at large corporations with manufacturing, software, and service business. He now offers consulting and training services for design, assessment, and improvement of management systems and process.

The Career Programmer: Guerilla Tactics for an Imperfect World

Christopher Duncan. 2002. Berkeley, Calif.: Apress. 231 pages. ISBN 1-59059-008-2.

(CSQE Body of Knowledge area: Software Engineering Processes)

Reviewed by Scott Duncan
softqual@mindspring.com

The goals of this book, in the author’s words, are:

“Nothing we were taught in school prepared us for the illogical, inconsistent, and sometimes downright silly business practices that are the norm in software development shops both large and small.”

“…almost arbitrary [deadlines]...vague and ever-changing requirements...little or no time for proper analysis and design, and, when we ask management about hiring professional testers and setting up a QA process....”

“This book is about overcoming the obstacles you face on the job that ultimately result in release disasters, stressed-out development experiences, software death marches, and bad software that could have been good.”

“...we need to learn how to manage our management....”

Duncan then sets the stage for the advice he promises by identifying “the problems that most software development teams commonly encounter.” The rest of the book is about how to deal with these problems, within the bounds of what Duncan believes individuals should be willing and able to control, that is, themselves.

Duncan’s first advice is for programmers to learn to “be able to interact with business people and address their perspective in a language that is meaningful to them.” This includes “recognizing the realities of the business world for what they are rather than wishing it were otherwise” and “improv[ing] both our communication and navigation skills...to get what we want out of” interaction with business people. And this, in turn, includes accepting the fact that “the logical, practical, and most sensible arguments” do not necessarily prevail. Thus, programmers must learn that it is a fatal misconception to believe that internal company maneuvering is not a part of their job, no matter how large or small the company may be.

Next Duncan briefly addresses some specific issues such as deadlines, requirements, analysis and design, testing, management, politics, and “the unexpected.” In each case, he tries to highlight reasons why problems occur in each of these areas and offers some basic advice about what a programmer may need to do to address them. For example, with regard to deadlines, he points out a characteristic pattern:

“A deadline is set, you claim it is ‘not enough time to deliver...solid, full-featured, quality software,’ but it is set anyway and people work hard to meet it (because, otherwise ‘there’d be the devil to pay’). Ultimately, something ships, and, to management, that is ‘proof that they were right all along...validat[ing] their practice of choosing arbitrary dates.’”

So why does this happen? Duncan writes about inverted project management, that is, picking a release date, then turning it over to programmers to figure out what to do and how. He mentions “scope creep,” emphasizing that second word by noting few would propose “a new feature equal in complexity to landing a man on the moon... however, just one tiny little enhancement doesn’t seem like a big deal, and developers are made to feel petty and uncooperative if they make a fuss about it.” But he also notes that poor estimating skills contribute to this since if “the person writing the code can’t accurately estimate how long the development effort will take, then there’s no way to come up with an achievable deadline.” Thus, if programmers “want to grapple with management for control over the delivery dates, they had better be ready and able to back it up once given the opportunity.” A “self-perpetuating cycle of missed delivery dates...contributes to management’s resistance.”

The book goes on in this way with chapters including:

• Coding Skills Are Not Enough
• Preventing Arbitrary Deadlines
• Effective Design Under Fire
• Fighting for Quality Assurance
• Keeping the Project Under Control

There is a lot of good advice here, especially about practices and behaviors that develop credibility with management (and peers). The book is delivered in a style that places a lot of blame on management and that may prevent many people from getting very far into it. A manager could take this book, however, and use it to try to improve the problems described. If programmers are being urged by Duncan to develop credibility, estimating skills, effective communication, and so on, then management can take the opportunity to encourage these explicitly, not just expect them implicitly. And, perhaps, hiring practices should explore subjects like this with potential members of the technical (and other) staff members besides just knowing their experience with operating systems, languages, and application domains.

Indeed, if there is one thing this book makes clear it is how many of the problems described are about being too implicit. Not being explicit about expectations—be they about requirements, work habits, achieving quality (even what “quality” means), credibility, and so on—may be the biggest lesson this book teaches, though it seems to do so, in most places, implicitly rather than explicitly.

Scott Duncan (softqual@mindspring.com) has 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. He is 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.

Agile Software Development Ecosystems

Jim Highsmith. 2002. Boston: Addison-Wesley. 441 pages. ISBN 0-201-76043-6.

(CSQE Body of Knowledge area: Software Engineering Processes)

Reviewed by Scott Duncan
softqual@mindspring.com

In SQP vol. 4, no. 3, Pieter Botman provided a review on Agile Software Development by Alistair Cockburn. This book is another in the same series. Cockburn and Highsmith are the series editors with other books being Surviving Object-Oriented Projects, Writing Effective Use Cases, and Improving Software Organizations. This particular book is described in the foreword by Tom DeMarco as “a kind of survey introduction to the agile methodologies.”

After an introduction to the topic, the book is presented in four parts. The first part describes some of the problems and how agility, in general, attempts to address them. The second discusses the people focus of agile software development ecosystems (ASDE) and how this impacts a variety of practices and techniques that generally appear in ASDEs. The third part devotes a chapter to each of the ASDEs noted previously. And, the fourth discusses “Developing an ASDE” which is a kind of do-it-yourself guide to agile methodology design. The book closes with a return to the concepts of “chaordic,” “collaborative,” and “barely sufficient methodology,” where Highsmith rates the ASDEs on a scale of relative “agility” on the following concepts:

• Chaordic organizational view
• Collaborative values
• Barely sufficient methods (BSM)
  
  • Results
  • Simple
  • Responsive and adaptive
  • Technical excellence
  • Collaborative practices

Highsmith provides an agility rating (1 is low and 5 is high) for each element (or subelement under BSM with a BSM average) and an “overall agility rating.”

The author closes by saying that “rigorous cultures face a difficult challenge” in that “no amount of process thinning or document pruning will make them agile” because agility is “an attitude, a sense of how the world works in complex ways.” He states, “Agile cultures and ASDEs will be difficult to implement…to the extent that executives and managers will want the world to be predictable and planable.” But, “ASDEs have two powerfully appealing characteristics. They offer an answer to the problem of developing software faster in highly volatile, demanding situations, and they offer a cultural environment that appeals to many individuals” who, Highsmith states, have responded to the agile approach by stating that it “reflects how we actually work.”

Some will respond to this last statement with, “Yes, software development is done chaotically and we have to rein that in.” Others will say, “Yes, software development is done in an environment where external forces introduce chaos and we try to deal with that, regularly.”

Scott Duncan (softqual@mindspring.com) has 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. He is 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.

PROGRAM AND PROJECT MANAGEMENT

Information Security Management Handbook CD-ROM

Harold F. Tipton and Micki Krause. 1999. Boca Raton, Fla.: Auerbach Publications. ISBN: 0-8493-1234-5.

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

Reviewed by Eva Freund
Eva.Freund@nara.gov

Have you wondered what it would take to become a Certified Information System Security Professional (CISSP)? Have you thought about becoming an information security practitioner? Have you wondered what the system security staff needs to know and to do in order to insure the protection of organizational information?

If you answered, “yes” to any of these questions you need this definitive source for computer security. This CD–ROM version contains the entire contents of volumes 1, 2, and 3 of the fourth edition (print) plus “bonus” information not available in the print editions. The content of the CD-ROM maps to the 10 domains tested on the certification examination.

The magnitude of effort required for addressing the myriad of details inherent in these domains demands a multitude of subject-matter experts. To ensure comprehensive coverage of these topics, 79 people, drawn from national and international private-sector organizations and academia, have authored the 145 articles constituting this body of knowledge.

The September 11, 2001, terrorist attacks on the United States, with the dramatic loss of life, property, and infrastructure, have heightened the awareness of and changed the prioritization of both physical and informational security concerns. Delaying and postponing long-dormant security concerns is not a path to be chosen by a prudent manager. With the attendant rise in not only the public’s awareness of security threats and risks, but also the government’s responsiveness through legislative and budgetary realignments, security has become a “here and now” issue.

Concerns that future attacks will be electronic, via the Internet, and directed at our financial and economic systems have moved to the forefront. People may never know if the October 2002 attacks on the Internet backbone were merely a “test” by our enemies in preparation for the yet-to-come real thing. The need for effective information/system security has become more critical and demands a realignment of priorities. These new priorities should include:

• Access control (physical and technical) technology to ensure that files are not corrupted and unauthorized changes are not made to programs
• Business continuity and disaster recovery planning to ensure that companies can survive an attack to their data processing facilities
• Physical security to ensure that intruders do not have access to facilities and evacuation plans be established, promulgated, and practiced
• Telecommunications and network security to ensure that our ability to conduct business activities is not disrupted
• Cryptography to ensure that sensitive information is protected during transmission, while stored on servers, or being transported with a laptop

Individually and collectively, these new priorities mandate that security must go from being discussed to being implemented through a variety of techniques ranging from access control and facial recognition systems, to biometrics and identity chips, to cryptography and filtering software, to sniffing and computer monitoring. Yet, many of the techniques that would enhance security are the same techniques that are likely to diminish personal liberties and/or provide more information about people’s personal lives to the federal government than people might want provided.

There is something for everyone in this CD-ROM. And if something one needs is not there, then try References for links to books by topical areas. This is indeed the definitive source for computer security information.

Eva Freund (efreund@erols.com) is an independent verification and validation (IV&V) consultant with 20 years of experience in software testing, standards, and project management. She offers IV&V and software process improvement services to private- and public-sector organizations. She is an ASQ Certified Software Quality Engineer and a Certified Software Development Professional from the IEEE Computer Society.

SOFTWARE VERIFICATION AND VALIDATION

Lessons Learned in Software Testing

Cem Kaner, James Bach, and Brett Pettichord. 2002. New York: John Wiley and Sons. 286 pages. ISBN 0-471-08112-4.

(CSQE Body of Knowledge areas: Software Verification and Validation; Software Quality Management; General Knowledge, Conduct, and Ethics)

Reviewed by Noreen Dertinger
Noreen.Dertinger@cognos.com

Those involved in software testing will find this book to be useful. Software testers with some experience will get the most out of it. Those new to the field will gain an overview of the types of issues they will have to deal with in software testing, although they may have to do some supplemental reading to get full value out of some of the more advanced material. Managers and developers who deal with testers will gain a good understanding of what constitutes good testing practices and some insight into what drives software testers.

I like Tim Lister’s foreword, in which he compares this book to a bottle of fine port that has aged to excellence and the lessons contained in this software-testing book to guidelines that will help connoisseurs of port maximize their port drinking experience. The three authors, who are highly experienced and respected testing professionals, have managed to distill a combined total of more than 50 years of testing experience into an excellent compendium on what works and what does not work well in software testing. In 293 lessons, the authors present their “assertions,” which are followed by explanations or examples that provide more insight into the lesson being presented.

“The Role of the Tester” contains lessons that all software testers, no matter their level, should be aware of. All testers should know early in their career lesson 1: “You are the headlights of the project.” In most software development environments it is the tester who helps development and management understand how the product’s quality is coming along.

“Bug Advocacy” highlights the importance of reporting bugs accurately and clearly. “A tester who can’t report bugs is like a refrigerator light that’s on when the door is closed.” Perhaps the most important lesson to take away from this chapter is lesson 55: “You are what you write.” This lesson emphasizes the fact that management and development
rely on testers’ reports for vital information, and that the quality of the report has a direct impact on a tester’s reputation.

“Interacting with Programmers” goes hand in hand with “Bug Advocacy,” because reporting bugs will naturally bring about a programmer and tester interaction. This chapter builds on the importance of integrity in the bug reports and interaction with the programmer. While the authors acknowledge that testers are often mistreated by programmers, they point out that the reverse can also happen.

“Automating Testing” addresses a wide range of viewpoints with respect to software test automation. Automation can be beneficial in some environments and harmful in others: “Automation can save time, speed development, extend your reach, and make your testing more effective. Or it can distract you and waste resources.” This chapter provides insights into issues encountered in software test automation.

The appendix (the context-driven approach to software testing) will appeal to those with a taste for context-driven thinking, many examples of which are provided in Lessons Learned in Software Testing. Those who have read and would like to identify themselves with the seven basic principles outlined in the appendix are invited by the authors to join the context-driven school of software testing via the related Web site.

The authors do point out that “This book is not a collection of lessons that are always true” and it is “not a collection of best practices.” Rather it is a compilation of lessons that they have encountered in their work experiences, and not every one of them will be applicable to every work situation. Those looking for a more detailed guide to comprehensive software testing should refer to some of the standard literature on software testing. The authors have provided the titles of such books; in addition, there are references to relevant reading materials that will expand on many of the topics and lessons that are presented.

Noreen Dertinger (Noreen.Dertinger@cognos.com) earned a master’s degree from the University of Ottawa, a certificate in information technology from the University of Victoria, and completed her CMII certification. She has 14 years’ experience in the software industry in development, configuration management, and quality assurance. Dertinger is a software quality control analyst with Cognos in Ottawa, Canada, working on PowerPlay EnterPrise Server.

Software Verification and Validation for Practitioners and Managers

Steve Rakitin. 2001. Boston: Artech House. 256 pages. ISBN 1-58053-296-9.

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

Reviewed by Rufus Turpin
rufus@carpedieminfo.ca

The book claims to be a concise and practical introduction to basic principles of software verification and validation. The claim is well founded. There is much sound and practical advice provided in an easy-to-read fashion for both the beginner and experienced practitioners. The material is presented straight up—introduced, discussed rationally and logically. Questions/issues and answers are provided along with numerous examples, tables, and checklists.

The book is divided into four parts and appendices. Each part focuses on a different aspect of software verification and validation and is presented so that readers build on knowledge presented in the preceding sections. Each chapter contains references and, in many cases, highlights resources on the Internet.

The introduction puts before the reader the day-to-day issues of software development and software quality. Part I provides an introduction to the software quality challenge, software development methods, software development life cycles, and software process improvement models, and gets at why it makes good financial sense to carry out software verification and validation activities and to justify them.

“Overview of Software Verification Activities” helps readers answer the question, “Have we satisfied the conditions in place we started?” The author introduces inspections explaining what they are, the different types of inspections, how to perform inspections, and what one gets out of them. Establishing a software metrics program is covered including quality factors and metrics and metrics related to verification activities. There is also an introduction to software configuration management and its major activities.

“Overview of Software Validation Activities” helps readers evaluate whether they have built the right product. In this part the author introduces software testing reviewing the types and levels of software testing and what is involved in planning for software testing. Building on the software metrics program, the author introduces readers to software metrics related to validation activities. Part III concludes with software reliability. In this part readers are introduced to the different reliability models, how to select a model, and how to apply the selected reliability model in their software development activities.

“Predictable Software Development” helps readers understand how to leverage their implemented software verification and validation activities to create predictable software development. In this part the author presents the characteristics of unpredictable software development and shows how this negatively impacts one’s ability to produce quality software. There is also a good overview on accurate estimating and scheduling through discussion on estimation models and estimating methods. Finally, the author concludes by discussing unpleasant surprises and how to reduce them by honoring commitments and managing risks.

Each appendix focuses on a specific area or technique and offers detailed discussion and/or checklists on the topic presented.

Rufus Turpin (rufus@carpedieminfo.ca) is an independent management consultant with more than 20 years of experience in the software quality disciplines. Turpin works with clients in both the public and private sectors improving the performance of their quality systems. A past chair of the ASQ Ottawa Valley Section, Turpin is a Senior member of ASQ and is currently serving as the Software Division marketing chair and the Technical Programs chair for 13ICSQ. He is an ASQ Certified Software Quality Engineer and ASQ Certified Quality Auditor.

Software Testing, A Guide to the TMap Approach

Martin Pol, Ruud Teunissen, and Erik van Veenendaal. 2002. Boston: Addison-Wesley. 564 pages. ISBN 0-201-745712-2.

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

Reviewed by Hillar Puskar
hpuskar@lucent.com

TMap is a structured test methodology developed in the Netherlands and Belgium by IQUIP Informatica BV. TMap stands for “Test Management Approach” and comprises four components: life cycle, techniques, organization, and infrastructure.

The majority of the book deals with techniques and organization. The life-cycle and techniques sections together make for a good introduction and reference on software testing. They also contain every imaginable checklist, and examples of test specification techniques. I found a number of items in this book that I will try to apply to my own project at work. There is so much material that most readers will skip over parts, but this is okay because the preface states, “This book does not have to be read from beginning to end. Depending on the involvement in testing, readers will look at some parts thoroughly, briefly, or not at all.” That is quite true since the book as a whole can be overwhelming.

One may question what is new about this methodology—isn’t this just existing material reorganized in a different manner? To some extent the answer is “yes,” but TMap is a good and thorough approach. It is also encouraging to see this book come out as another sign that software testing is coming into its own. There is some element of self-hype in the book, but it is mainly limited to the back cover and introductory materials.

The TMap approach seems to come from a perfect world or leisurely development environment;I did not see enough of an awareness about struggle to do what is right vs. what one can do with given time/budget. The TMap book contains short chapters on metrics, test control, and improvements to the test process. The authors believe that TMap can be used in all kinds of projects, but it is mostly left up to the reader to understand what applies and what to discard.

Overall this is a well-intentioned book with an abundance of good information, and it would make a good reference for most software test organizations. The TMap methodology has its focus in the right place; early on it states that the “ultimate objective is prevention —not the relatively expensive detection of defects in the final product.” It can be used to help put together a testing program from scratch, or to help add to an existing testing program as it grows up.

Hillar Puskar (hpuskar@lucent.com) is a technical manager at Lucent Technologies and is involved in systems engineering and testing of tools to design and optimize wireless networks. He has a bachelor’s degree in industrial engineering from Lehigh University, and a master’s degree in computer science from Stevens Institute of Technology. Puskar has extensive experience in systems engineering and all aspects of the development life cycle. He is a member of the ASQ Software Division.

Effective Methods for Software Testing

William E. Perry. 2000. New York: John Wiley and Sons. 812 pages. ISBN 0-471-35418-X.

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

Reviewed by Carolyn Rodda Lincoln
lincoln_c@titan.com

Effective Methods for Software Testing is the “everything you wanted to know about testing but were afraid to ask” book. It is a thorough and detailed discussion of every aspect of testing. The author is the founder of the Quality Assurance Institute and a well-known testing guru. This version is the second edition of a book published in 1995, which has been significantly enhanced with new material.

Perry’s book has five parts and 26 chapters. Part one is a self-assessment that can be used to determine the maturity of an organization’s testing process and testers. Part two addresses the environment for testing: the testing strategy, methodology, and techniques. Part three is by far the longest; it describes the 11-step testing process, which includes both development and maintenance. Part four provides specific guidance for testing specialized systems, for example, client/server, Web-based, and data warehouse. Part five is a short discussion of test documentation.

Effective Methods for Software Testing emphasizes some important but often-forgotten techniques. One is that testers are involved throughout the life cycle, not just at the end. They begin planning the tests at the beginning of a project, but they also “test” the project plans, requirements, and design. Since everything cannot be tested, the book explains how to determine the objectives and risks of the project and then prioritize the tests. Some examples of the test factors derived from risks are correctness, service levels, access control, reliability, and maintainability.

Perry presents information in a “user-friendly” manner. The book is filled with lists, charts, document outlines, and samples. Steps are broken into tasks and subtasks as appropriate. Even if readers have never performed that type of testing, they would have no trouble understanding the instructions and doing the test.

This book is an excellent resource for anyone involved in testing. Beginners could easily be overwhelmed, but they would be impressed with the challenge ahead. An experienced tester would skim the parts they know and dig into the ones that they did not. A testing manager or project manager would use it as a checklist on how to run a successful project. Effective Methods for Software Testing belongs on the bookshelf of every tester, testing manager, and project manager.

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 software process improvement 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