June 2001
Volume 3 • Number 3

Contents

Resource Reviews

PROJECT MANAGEMENT VIDEO

Essential Software Engineering: A Video Curriculum

Roger Pressman. 1995. Boca Raton, Fla.: R. S. Pressman & Associates. (CSQE Body of Knowledge area: Software Project Management)

Reviewed by Susan McGrath Carroll

There are eight components in the Essential Software Engineering (ESE) curriculum.
They are:

1. Software engineering overview
2. Software project management
3. Information engineering
4. Reengineering techniques
5. Object-oriented methods
6. Software testing
7. Software quality assurance
8. Software configuration management

A ninth advanced topic is ISO 9000 software development.

Each component comes packaged with videotapes (40 to 60 minutes per tape, multiple tapes per topic), course notes, and a user’s guide.

The total package is a basic learning curriculum for each topic complete with lecture, exercises, reading from course notes, and additional reading sources. An update to the ESE curriculum is planned during 2001, with lessons that will be Web based.

This curriculum was filmed in 1995, but the fundamental lessons are still applicable. It is a good supplemental training source.

Each component can be kept in a library for use by all employees. Off-site employees who may not have access to training can use these courses when they have time without traveling to training classes, and employees can view training when transferring to new areas. There is a combination of talking head lecture, lecture in a classroom setting, question-and-answer segments, and exercises. The tapes move quickly enough to stay interesting but will not lose those new to the topic.

This issue of Software Quality Professional includes a review of software project management. Other reviews will follow in future issues.

Software project management is a vital skill for those involved in software development. For those who have taken a course in project management, this course will help them understand the particulars for software. Pressman’s goal is to link software engineering and project management together. He succeeds in this tape series. The things that are important in any kind of project management include: the size of the project, the technology used, the schedule, the costs, the environment, user requirements, and the people involved. All of these are covered in this course.

This topic is divided into four modules. The first module is measurement and metrics. The topics covered are:

• Software projects
• Measurement
• The TQM connection
• Managers and measurement
• Metrics for the project
• Collecting project (hard) data
• Collecting support (soft) data
• Normalization: size vs. function
• Function points computation and analysis
• Computing function points by "backfiring"
• Productivity metrics
• Factors impacting productivity
• Quality metrics
• Metrics summary

One must have measurement to determine the size of the project and for improvement. Pressman prefers function points over lines of code and explains how to count function points. He also explains that one should not use size as an incentive unless he or she wants inflated code. One can use lines of code to predict function points, and there is a chart to help with that conversion. There is a call for hard data collection and the need for more. Cyclomatic complexity is suggested as a type of hard data collection available. I would have liked more detail about hard data. Pressman suggests that soft data are not essential but can be used.

Productivity is explained, which includes an interesting explanation of productivity rates for large vs. small projects. Pressman also goes into the expected quality metrics using errors or defects. Overall, this is a good overview of metrics and how they relate to software project management.

Module two is project estimation and includes:

• Project scope
• Performing a grammatical parse
• Cost estimation
• Estimation techniques
• Conventional methods
• Empirical models
• COCOMO cost model
• Estimation guidelines
• An estimation example
• The make-buy decision
• Building a decision tree
• Buying commercial off-the-shelf (COTS) software
• Contracting software work

Pressman explains that one must understand the scope of the problem in order to perform project management effectively. People can use past projects, current metrics, and functional decomposition to help them understand the scope. This process is explained in a step-by-step fashion.

One must be able to estimate the project cost, and Pressman explains that one needs three data points to determine the cost. These should be determined by systematic methods. There is a lot of detail about how to get these data points, as well as an understanding that anything based on estimation will have uncertainty and may need to be reworked as the project proceeds. One can also use a table-driven method that uses historical data and tasks to determine effort. This is explained in a step-by-step method. Conventional methods would include a task breakdown, size determination, and data from past projects. Empirical data would include modeling such as COCOMO. The topic of reuse is also covered. The overall code size is smaller, but the effort needed must be considered. There is a small section on estimating reuse of object-oriented objects. Pressman gives good guidelines for size and effort estimation, and there is an example included in the workbook that helps explain the technical details of this section.

At the beginning of any project someone must ask if this software should be built or bought. There are several ways to buy software, and these are explained. One must determine the least expensive way to acquire the needed software and by the desired date. There are acquisition and implementation costs for bought software that must be compared to the cost of internal development. A process (decision tree) is described to help with this decision. Important points in buying COTS software are also presented, and there are some good guidelines for determining the scope of the project if a contractor is used for parts of the software.

The third module is risk analysis, which consists of:

• Introduction to risk
• A risk-analysis paradigm
• Risk-analysis steps
• Building a risk table
• Risk identification
• Risk categories
• Risk components
• Size risks
• Business risks
• Customer risks
• Process risks
• Technology risks
• People risks
• Risk and management concern
• Risk mitigation, monitoring, and management

The module on risk analysis is written so one can mitigate and manage risks. One has to think about what can go wrong, how likely it is to occur, what the impact will be, and what can be done about it. There is a choice of being reactive or proactive. Someone who is always fighting fires is being reactive, and it might help those people to view this module for guidance on being proactive.

One deals with risks in a cyclical fashion: identify, analyze, plan, track, and control. This is continued throughout the project’s life. Pressman suggests that one complete a risk table to help with risk analysis. That process is explained, and a generic risk checklist is included in the workbook. Remember that change is a risk, so project size is less important than the measure of change from the past baseline.

The following can contribute to the risks: the size of the project, a new customer, deadlines, poorly defined scope, lack of processes, lack of tools, new technology, and lack of people or expertise. What should be done about them? Several strategies for dealing with risks are outlined: mitigation, monitoring, or management. A contingency plan is used in managing a risk. These can be high tech or low tech, depending on the risk involved.

The last module is scheduling, staffing, and control. It includes:

• Introduction to scheduling
• Project scheduling
• Scheduling tools
• Effort allocation guidelines
• Project staffing: team organizations
• Project team structures
• Software quality assurance
• Formal technical reviews
• Project control: software configuration management
• Systems: the certainty of change
• Project monitoring
• Project tracking

This module explains that scheduling a project is not a finite task. One must adjust frequently, as needed. Possible reasons for a late project are explained, and Pressman covers software project management and the need for milestones and deliverables at each milestone. He defines the activities in the software lifecycle as customer communication, planning, engineering, implementation, and release. There are tasks associated with each activity. The interdependencies of the tasks are discussed, as well as the tasks that make up the critical path for the project.

Project staffing is discussed, including the role for all team members and various organizational possibilities. Then there is a discussion of software quality and the processes that go into good quality. The expected discussion of the high cost of finding defects via testing is included, as well as an explanation of the role of quality assurance in making sure tasks are completed. Reviews can help quality and the roles of a formal technical review are discussed.

No project is complete without configuration management for controlling change and revisions. This is a short discussion since there is another component on software configuration management (which will be reviewed in the next issue of Software Quality Professional). The module ends with a discussion of project monitoring and tracking. This can be completed formally or informally; it is the duty of the project manager to monitor progress.

I have taken a class in project management but found that this video series added to my knowledge by putting a software spin on the topic. I could easily watch a complete tape in one sitting but needed to take a break before beginning another tape. The topic is technical and somewhat dry, but Pressman uses a variety of presentation styles to keep students engaged. The tapes are worth the time and are a good investment for a company with several individuals to train and no one expert in the subject area.

Associate Editor Susan McGrath Carroll (suemcgrath@att.net) is a senior software quality analyst with SAS in North Carolina. She has spent 14 years concentrating on internal and external quality awareness, process improvement, and communication. Software Division chair-elect and then chair from 1994-1998, Carroll currently serves as division Internet liaison and is a Senior member of ASQ, a member of IEEE, IEEE Computer Society, and IEEE Standards group.

Amplifying Your Effectiveness: Collected Essays. 2000.

Edited by Gerald M. Weinberg, James Bach, and Naomi Karten. New York: Dorset House Publishing. 146 pages. ISBN 0-932633-47-1 (CSQE Body of Knowledge areas: General Knowledge, Software Quality Management)

Reviewed by Linda Westfall

For those looking for a step-by-step method for how to amplify their effectiveness, this is not the book. Amplifying Your Effectiveness is full of interesting, thought-provoking, and somewhat disjointed essays from a group of successful consultants that resulted from the first Amplifying Your Effectiveness conference.
This book is in a "sound-bite" sort of format, the longest contribution being 16 pages and the shortest only two. As such, the book almost begs the reader to pick it up, read a single essay, and then put it away and just think for a while. "How does this idea fit into what I am doing?" "How can I translate that thought into something useful in my environment?"

When I read a book, I use a highlighter to mark the passages that I find interesting, informative, or thought provoking—the ones that I want to reread later. Then I judge the book by the amount of yellow I see as I flip through the pages. While this book did not have the depth that I would have liked or hoped to find, there were a lot of interesting ideas (a lot of yellow). Some of my personal favorites included:

Don Gray’s "Solving Other People’s Problems," which outlines basic principles that should be kept in mind when trying to solve problems. For example, his "Pay Attention" principle tells readers that "critical information about the problem will hide in plain view" and his "Passion Principle" warns "Don’t care more about solving the problem than the other person does."

Gerald Weinberg’s "Congruent Interviewing by Audition" reminds readers "In the end, credentials aren’t what counts, for software development is not an academic subject, it’s a performing art." He recommends including a written test, a problem-solving exercise, or even a code-reading exercise as part of the interviewing process. This is not a new idea; he addressed it years ago in his book The Psychology of Computer Programming, but it is one worth repeating and remembering.

Ester Derby’s "Modeling Organizational Change" illustrates that "systems, even small ones, are very complex" and that "your job in designing an organizational change is to understand the interplay of factors and to identify ways to guide the system in the direction you desire." This essay provides an excellent example of how to use simple diagram of effects models to evaluate potential change ideas.

James Bach’s "Good Practice Hunting" emphasizes that: "The goodness of a practice is not an intrinsic attribute. Goodness emerges from the conjunction of a practice and its particular context." He supplies readers with a useful checklist of questions to ask themselves before adopting a practice.

Readers will not find personal value in every essay in this book. For example, I found Kevin Fjelsted’s "A Brief History of Accessibility of Computers by Blind People" interesting but irrelevant to my work. And while Bob King’s "Life as a Software Architect" does a good job of defining the role of an architect, it is not where I spent my time. There is enough diversity in this book, however, that everyone should find something useful. I will conclude with my favorite of Rick Brenner’s Ten Project Haiku:

We think about risks.

We have contingency plans.

Oops…but not for that.

Linda Westfall (WESTFALL@idt.net), currently chair of the ASQ Software Division, has 20 years of experience in software engineering, quality, and metrics. Prior to starting her own business, The Westfall Team, Westfall was the senior manager of quality metrics and analysis at DSC Communications where she designed and implemented their corporatewide software metrics program. She is an ASQ Certified Software Quality Engineer, ASQ Certified Quality Auditor, and a Certified Manager from the Institute of Certified Progressional Managers.

Function Point Analysis: Measurement Practices for Successful Software Projects.

David Garmus and David Herron. 2001. Boston: Addison-Wesley. 336 pages. ISBN 0-201-69944-3 (CSQE Body of Knowledge areas: Software Project Management; Software Metrics, Measure-ment, and Analytical Methods)

Reviewed by Carol Dekkers

This book provides an introduction and context for applying function point analysis in software development, and presents the function point counting rules from the International Function Point Users Group’s (IFPUG) Counting Practices Manual Release 4.1. The book consists of 16 chapters and is structured so the first five chapters are overview materials covering such topics as software measurement, using function points effectively, and software industry benchmark data. The next five chapters are devoted exclusively to the IFPUG rules (and the authors’ advice); four chapters are devoted to illustrating function point case studies (case studies in counting, counting advanced technologies, counting a GUI application, and counting an object-oriented application). Chapter 15 presents the authors’ analysis of what constitutes "good" tools; and the final chapter is a mock exam intended for readers who are preparing to take the IFPUG Certified Function Point Specialist exam. The book concludes with a series of appendices, including forms, answers to the mock exam, and frequently asked questions.

As the authors say in the introduction: "This book is primarily about the function point methodology and the use of function points in managing the development and deployment of software… . The intent of the book is to provide a comprehensive presentation on the function point methodology to the practitioner… . In addition, we would like this book to be read by nonpractitioners."

Whether this book will meet one’s needs depends on his or her perspective and requirements. Let’s address in turn the two audiences for which the authors intended
this book:

1. Function point practitioners: Almost one-third of this book’s main pages (89 out of 285 pages) contain rules out of the IFPUG Counting Practices Manual Release 4.1, and the rules are interspersed with the authors’ experience and opinions. Readers who are looking for an overview of the rules together with illustrative case studies will benefit from this book’s treatment of function points. Certified Function Point Specialist exam candidates will also be pleased that there is an entirely new exam based on the 1999 IFPUG rules included in the book, which the authors state was "perhaps the single most popular section of our first book." One caution or, perhaps, relief, (depending, again, on one’s perspective) is that the book presents proposed solutions to function point counting issues (such as how to count report generators) that are, as of this reviewer’s knowledge, still unresolved by the IFPUG Counting Practices Committee. For those function point practitioners seeking definitive answers to these issues, they may find solace in the authors’ approach. To others seeking an official IFPUG position on the questions, they should still contact the IFPUG counting practices committee directly for definitive IFPUG positions. (The committee consists of approximately one dozen Certified Function Point Specialists.)

2. Nonpractitioners: Function point analysis has long been misunderstood by software quality and IT managers alike. Part of this confusion comes from the polarization and passion of "professionals" when it comes to function points. Opinions expressed in print and presentations run the gamut from glamorizing function points as the cure-all for what ails the software community, to reducing them to a technical metric inappropriate for today’s software. The truth falls in between, and in fact, there are as many positive uses for function points in software as there are for square feet in building construction (reviewer’s analogy). While this book does not rely on analogies, it scores points on its explanation of a function point as a "unit of work." In the chapter titled "Executive Introduction to Function Points," the authors suggest ways to present the value of function points to senior management by positioning them as units of work: "A unit-of-work metric should enable the CIO to measure productivity and business value of the software deliverable on a level playing field. Regardless of the economic or presentation techniques used to display IT performance, such as return on investment and balanced scorecards, establishing a cost per unit of work should be a fundamental element of a manager’s financial tool kit… . Function points are an effective, and the best available, unit of work measure."

The prior release of this book in 1996 was titled Managing the Software Process and, fortunately, this sequel expands on the original premise. Besides updating the 1994 IFPUG rules to the current 1999 rules, positive aspects to this edition include: the aforementioned "unit of work" explanation, case studies that illustrate both the authors’ proposed solutions to counting issues, as well as sample software applications, suggestions about counting software developed with newer technologies, and a new practice exam intended for certification candidates.

In summary, is the book worth the price? It depends on the reader’s needs—whether they be for the pure IFPUG 4.1 function point rules, or for a combination of rules, opinions, examples, and advice about using function points in a variety of circumstances. Perhaps the book itself answers this question best: "Understandably, this book isn’t for everyone involved in software, but it is for everyone who wants to improve his or her software development environment through the effective utilization of software functional metrics." I know the book will benefit our team of industry-leading function point trainers and consultants, by having more published case studies and mock exams available for clients. I anticipate also gaining value for our clients from the "Executive Introduction to Function Points" chapter. The book may save one’s company time and effort as well.

Carol A. Dekkers (Dekkers@qualityplustech.com), an SQP Editorial Board member, is a past IFPUG president and is president of Quality Plus Technologies, Inc., specializing in function point analysis training and software measurement consulting. Dekkers earned her bachelor’s degree in mechanical engineering from the University of Calgary, and is a Certified Management Consultant (CMC), a Certified Function Point Specialist (CFPS), 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.

Telecommunications: An Introduction for Software Professionals.

Clive Tomlinson. 2000. Harlow, England: Addison-Wesley. 224 pages. ISBN 0-201-67473-4.

This book provides an introduction to software professionals who are baffled by unfamiliar technology and jargon upon entering the telecommunications industry. The stated intent is to offer a high-level account of telecom technologies, the structure of the industry, and the special software methods that it uses. There are five chapters on circuit-mode networks and two chapters on packet-mode networks (including Internet protocols) all wrapped within chapters on the telecoms market, business practices, and support systems. The final chapter, "Software and Systems Issues," consists of a dozen brisk pages on specialized languages and tools that have been developed for these applications. This book is well indexed with an extensive acronym list and references.

Software Safety and Reliability: Techniques, Approaches, and Standards of Key Industrial Sectors.

Debra S. Herrmann. 1999. Los Alamitos, Calif.: IEEE Computer Society Press. 500 pages. ISBN 0-7695-0299-7

The author begins by noting that ASQ members obligate themselves in the Society’s Code of Ethics to "do whatever I can to promote the reliability and safety of all products that come within my jurisdiction." After an introduction to basic concepts and techniques, the author marches through relevant standards in the ground transportation, aerospace, defense, nuclear power, and biomedical industries. These detailed treatments allow readers to see issues unique to each, as well as commonalities across industries. Each chapter concludes with discussion questions and extensive listings of additional resources.

Some of Herrmann’s concluding observations:

"A ‘good’ software engineering process is insufficient by itself to produce safe and reliable software."

"The achievement of software safety and reliability should be measured throughout the lifecycle by a combination of product, process, and people/resource metrics, both quantitative and qualitative."

"Software safety and software reliability are engineering specialties which require specialized knowledge, skills, and experience."

"A layered approach to standards is the most effective way to achieve both software and system safety and reliability."

Contact information is provided on standards organizations and commercial safety and reliability analysis tools.

Verification and Validation of Modern Software Intensive Systems.

G. Gordon Schulmeyer and Garth R. Mackenzie. 2000. Upper Saddle River, N. J.: Prentice Hall PTR. 384 pages. ISBN 0-13-020584-2

"Traditional" verification and validation (V&V) involves verification of requirements, design, and implementation, as well as validation through testing. "Contemporary" V&V, as contrasted to the traditional in 11 chapters without being defined, is a collection of techniques that respond to the novelties of various application domains. This volume is highly derivative, with some 258 citations in 452 pages of text, many long quotations, tables, figures (few in the book are original), and several end-of-chapter appendices that are straight cut-and-paste—all with full attribution.

The majority of the treatment is devoted to specific application areas, ranging from object-oriented to GUI to Internet and data warehousing. The book concludes with an appendix to which have been relegated two case studies.

Managing Software Requirements: A Unified Approach.

Dean Leffingwell, Don Widrig, and Edward Yourdon. 2000. Reading, Mass.: Addison-Wesley. 528 pages. ISBN 0-201-61593-2

This volume is structured around the six skills the authors regard as requisite for effective requirements management:

• Analyzing the problem
• Understanding user and stakeholder needs
• Defining the system
• Managing scope
• Refining the system definition
• Building the right system

The Unified Modeling Language is introduced and key concepts are woven into subsequent discussions, as are references to a number of IEEE software engineering standards. Vignettes of actual experiences are interspersed.

Threaded throughout is a full-blown case study, complete with an appendix containing more than 30 pages of project artifacts. Other appendices provide templates for a "vision document" and a "modern" software requirement specification package.

On Time Within Budget: Software Project Management Practices and Techniques, Third Edition.

E. M. Bennatan. 2000. New York: John Wiley and Sons. 368 pages. ISBN 0-471-37644-2

Addressed to practicing software project managers rather than developers, this book ranges across contractual concerns, lifecycle issues, project support functions (including quality assurance), standards, and organizational excellence. There are treatments of proposal preparation and evaluation, estimating, scheduling, and handling of large projects.

Attractively presented with many charts and diagrams, this volume offers a well-rounded overview with reasonably thorough reference to the more technical literature. Each of the 12 chapters ends with a neat page-long summary and questions suitable for the classroom.