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
Reviewed by Susan McGrath Carroll
There are eight components in the Essential Software Engineering
1. Software engineering overview
A ninth advanced topic is ISO 9000 software development.
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
Each component comes packaged with videotapes (40 to 60 minutes
per tape, multiple tapes per topic), course notes, and a users
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. Pressmans 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:
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.
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"
Factors impacting productivity
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:
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.
Performing a grammatical parse
COCOMO cost model
An estimation example
The make-buy decision
Building a decision tree
Buying commercial off-the-shelf (COTS) software
Contracting software work
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
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
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.
A risk-analysis paradigm
Building a risk table
Risk and management concern
Risk mitigation, monitoring, and management
One deals with risks in a cyclical fashion: identify, analyze,
plan, track, and control. This is continued throughout the projects
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
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
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 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
Associate Editor Susan McGrath Carroll (email@example.com)
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.
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.
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
Reviewed by Linda Westfall
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 provokingthe
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 Grays "Solving Other Peoples 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 "Dont care more about solving
the problem than the other person does."
Gerald Weinbergs "Congruent Interviewing by Audition"
reminds readers "In the end, credentials arent what
counts, for software development is not an academic subject,
its 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
Ester Derbys "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 Bachs "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 Fjelsteds "A Brief
History of Accessibility of Computers by Blind People"
interesting but irrelevant to my work. And while Bob Kings
"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 Brenners Ten Project Haiku:
We think about risks.
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.
We have contingency plans.
but not for that.
Function Point Analysis: Measurement Practices
for Successful Software Projects.
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 Groups (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.
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
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 ones needs depends on his
or her perspective and requirements. Lets address in turn
the two audiences for which the authors intended
1. Function point practitioners: Almost one-third of this
books 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
books 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 ones 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 reviewers 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 todays 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 (reviewers 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 managers financial
. 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 readers
needswhether 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 isnt 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 ones company time and effort
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 (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
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
Clive Tomlinson. 2000. Harlow, England: Addison-Wesley. 224
pages. ISBN 0-201-67473-4.
Software Safety and Reliability: Techniques,
Approaches, and Standards of Key Industrial Sectors.
The author begins by noting that ASQ members obligate themselves
in the Societys 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.
Debra S. Herrmann. 1999. Los Alamitos, Calif.: IEEE Computer
Society Press. 500 pages. ISBN 0-7695-0299-7
Some of Herrmanns 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
"Software safety and software reliability are engineering
specialties which require specialized knowledge, skills, and
"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
"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-pasteall
with full attribution.
G. Gordon Schulmeyer and Garth R. Mackenzie. 2000. Upper Saddle
River, N. J.: Prentice Hall PTR. 384 pages. ISBN 0-13-020584-2
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
This volume is structured around the six skills the authors
regard as requisite for effective requirements management:
Dean Leffingwell, Don Widrig, and Edward Yourdon. 2000. Reading,
Mass.: Addison-Wesley. 528 pages. ISBN 0-201-61593-2
Analyzing the problem
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.
Understanding user and stakeholder needs
Defining the system
Refining the system definition
Building the right system
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
On Time Within Budget: Software Project Management
Practices and Techniques, Third Edition.
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.
E. M. Bennatan. 2000. New York: John Wiley and Sons. 368 pages.
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