Object oriented project management with UML

To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Introduction
-----------

About the Author
Part One—Principles for Object-Oriented Program
Management
Chapter 1—Object-Oriented Development as a
Management Tool
Meet the Enemies
Inadequate and Unstable Requirements
Inadequate Customer Communications
Poor Team Communications

Unnecessary Complexity
Ineffective Team Behavior
Conquering Enemies with Object Technology
Attacking Complexity
Collaboration
Development as Collaborative Problem Solving
Team Communications
Common Vocabulary, Common Language
The Right Amount of Communication
Team Dynamics
Team Formation
From Here


Chapter 2—The Unified Modeling Language as
a Management Tool
Using Abstraction
Unified Modeling Language
Documenting Requirements
Use Cases
Use-Case Diagrams
Documenting Package Requirements
Documenting Software Design
Software Objects and Classes
Attributes of a Good Design
Components and Subsystems
Levels of Testing
Traceability
From Here

Chapter 3—Choosing a Development Lifecycle
Model
Lifecycle Model Principles
Software Development as Team Problem Solving
Four Lifecycle Models
Waterfall
Spiral Model
Rapid Application Development: Time Box Model
Controlled Iteration
Incremental Builds
Recommendation
From Here

Chapter 4—Planning Object-Oriented Projects
Developing the SDP
Scoping the Plan
Practical Advice
Designing the SDP
Deliverables
Development Environment
Size and Effort Estimates


Risk Planning
Lifecycle Model
Work Breakdown Structure (WBS)
Schedules
Staffing and Organization
Product Teams
Time-Phased Budget

Metrics Plan
From Here

Part Two—Managing Through the Lifecycle
Chapter 5—Managing the Inception Phase
Management Overview
Team Issues
Development Activities
The Use-Case Database
Use-Case Diagrams
Prototyped User Interface
Top-Level Class Diagrams
System Test Plan
Process Tasks
Assigning Responsibility
Phase Exit Criteria
Coordinating Activities
Microschedules
Program Meetings
Customer Communications
Managing Deliverables
Holding the Requirements Review Meeting
Phase Completion
From Here

Chapter 6—Managing the Elaboration Phase
Management Overview
Team Issues
Leadership

Development Activities
Use-Case Elaboration
Class Design
System Design Specification
Subsystem Integration and Unit Test Plans
Updated Artifacts
Process Tasks
Coordination of Activities
Internal Design Reviews
Program Meetings
Customer and Manager Communication
Holding the System Design Review Meeting
Phase Completion
From Here

Chapter 7—Managing the Construction Phase
Management Overview
Resetting the Baseline
Team Issues
Leadership
Development Tasks
Integration Strategy
Class Development
Horizontal and Vertical Development
User Interface Development
Incremental Subsystem Integration and Testing
Incremental System Integration
The Final Integration
User Documentation

Updated Artifacts
Construction Process Tasks
Assigning Responsibility
Coordination and Tracking Activities
Risk Management
Setting the Microschedule
Change Control
Transition Preparations


Team Meetings
Operational Test Readiness Review
Construction Phase Exit Criteria
From Here

Chapter 8—Managing the Transition Phase
Management Overview
Leadership Issues
Transition Development Activities
The Problem Report Process
Addressing Defects
Design, Code, and Test
Transition Process Tasks
Assigning Responsibility
Coordination of Activities
Build Meetings
Program Meetings
Customer Communication
Transition Phase Exit Criteria
From Here

Part Three—Measuring Progress and Success
Chapter 9—Tracking and Oversight
Budget Tracking
Understanding the Variances
Development Metrics
Monthly Status Report
From Here: Principles for Success

Bibliography
Appendix A
Index


Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Table of Contents

-----------

Introduction
This book is a practical guide to modern software development. It grew out of
a course I regularly teach at TASC, which itself began as happenstance. I had
been asked to appraise an online course on managing object-oriented
development. I hated it. It was a rehash of the old, discredited waterfall
methods of software development. They replaced the design and code steps
plus some object jargon. When I expressed this opinion, TASC management
threw down the gauntlet, essentially saying, “If you are so smart, then you
teach the course.”
While preparing the course, I realized a few things: The first is that we in the
industry really do know how to manage software development. There is no
reason for software development to be a risky, high-stress business. On the
other hand, most programs do not seem to benefit from what we have learned
over the last few years. Second, a lot of material must be covered when
teaching software management, most of which is not commonly taught in
universities. And because developers are still the best source of software
managers, it is important that a book be available to teach the trade. As of this

writing, I know of no other book that covers the material that I feel is essential
for any project manager.
The third realization is that the use of objects and object design languages such
as the Unified Modeling Language (UML) can improve not only the technical
quality of the development: It can also facilitate the task of the project
managers. I believe that all new software development projects should adopt
object methodology and be managed according to the techniques in this book.

Goals


Based on my experience, the available literature, and conversations with my
colleagues, staff, and students, this text describes the effective management of
software development projects using object-oriented methodology. I describe
not only what the project manager should do through all phases of the project,
but explain why the techniques work. To that end, the book covers the
planning, staffing, organization, development, and delivery of object-based
software. The day-to-day activities of the project manager are covered in
depth, providing leadership and management to your team. I include enough
theoretical background so that you come to understand the why as well as the
how. The theory will help you apply the techniques to your particular situation.
As a project manager, you should have a library of books, because no one can
cover all you need to know as you broaden your skill base. Although this book
covers a lot of ground, I leave such topics as maturing the organization and
quality management to other books, and only peripherally cover others. I
provide references for those who want to learn more about the topics of
secondary importance to this book.

Who Should Read This Book
The book’s primary target is software project and program managers,

neophytes, and experts, as well as those developers who have an interest in
how their roles fit into the overall development process, or even better, who
aspire to project management. So, too, the managers of project managers
should read the book, to develop an appreciation of what your project manager
is doing and thereby have a basis for providing oversight. The same goes for
those who contract software.
I have strived to make the book applicable to developers of small programs, as
well as to development teams working on large programs. The techniques
described can be applied to research and development projects, internal tool
development, contracted software, and shrink-wrapped products. To a great
degree, this book is self-contained. I assume the reader has some experience
with software development and some notion of software objects. I also assume
the reader has at least participated in a software development project and can
read a Gantt chart.

How This Book Is Organized
The book has three parts. The first lays the foundation for the rest of the book.
In order to succeed at software project management, you need to understand
some important principles. These underlying principles are introduced in
Chapter 1. This is followed by an introduction to the Unified Modeling
Language (UML) and its use in software development in Chapter 2. Chapter 2
also provides an overview of object-oriented design and the UML for the
project manager. Anyone familiar with the UML can skim this chapter.
However, there is some managerial advice on managing complexity that even
the UML expert may find of use. Chapter 3 completes the foundation with a
discussion of software development lifecycle models.
The second part of the book discusses the application of the concepts inherent
in the software development phases. All the phases and activities of UML

software development are covered in detail. Chapter 4 details how to plan and
organize your project. Chapters 5 through 8 describe the software development
lifecycle in detail, how to manage throughout the phases: activities, exit
criteria, and special managerial and communication issues.
The third part consists only of Chapter 9; it tells you how to assess and report
your project’s status, and it provides the means, budget, and development
metrics to verify whether your project is on track. Chapter 9 also outlines a
format for the program manager to use to succinctly report status and project
health to upper management and/or the customer.
In addition to the body of the book, an ongoing example of a software
development project—a manned cockpit simulator for a stealth fighter—is
presented in sidebar format throughout. The example, while detailed, is
fictional and is not based any real project. It was written to be sufficiently
complicated to show how the book’s methods work. The example is intended
to help you to understand how plans are set, teams are organized, risks are
managed, and code is developed and delivered, not how to actually build a
simulator. I reviewed the simulator architecture with some developers who tell
me it is reasonable, however, I’m not sure I would actually use it in a real
program.

On the Web Site
Because one of the goals of this book is to help you in your day-to-day
program management, the publisher, John Wiley & Sons, Inc., has established
a Web site, www.wiley.com/compbooks/cantor, where you can download
material that you might find useful as you apply some the techniques in the
book. Among the site’s features are:
• A sample project file for the simulator example, including a work
breakdown structure (WBS) for a software development program
described in Chapter 4.
• A database template for managing use cases described in Chapter 5.

• A Svedlow diagram for tracking development during the construction
phase found in Chapter 7.
• A development artifact status template from Chapter 9.
In addition, the site contains links to other useful Web sites. You can also use
the site to write me to comment on the ideas in the book and to share your
experience. In keeping with the nature of all Web sites, the content will change
from time to time.

From Here
The value of the book lies in the application of the ideas and technique, so read
it and make use of the Web page. Try out the ideas. They work for me; I think
they will for you. Thank you for reading the book. I hope you enjoy it.

Table of Contents


Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced

Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Table of Contents

-----------

About the Author
Dr. Murray Cantor has over ten years experience managing object-based
systems. He is currently employed by Rational Software as a member of its
Worldwide Services Organization. Before joining Rational, Cantor was a
program manager at TASC, a subsidiary of Litton Industries, where he
directed complex software development programs. Prior to joining TASC, Dr.
Cantor was a development manager at IBM, where he oversaw the
development of high-end graphics and multimedia systems.

Acknowledgments

This book would not have been written without the help of many people.
Some helped directly, others by sharing insight and knowledge throughout the
years. One of the side benefits of writing a book is the opportunity to say thank
you.

First, I want to thank my wife Judi. She provided valuable advice, support, and
insight throughout the writing. Also, she did more than her share. Next time, it
is her turn.
I also want thank the TASC management for their support while I was writing.
Frank Serna, the simulations system Business Unit director, as well as my
manager, deserves special thanks for his encouragement and valuable
discussions throughout the writing of the book. In addition, this book is the
result of many conversations with colleagues, staff, and students. I especially
want to thank David Alvey, Roger Blais, Pat Durante, Robert McCarron, Hal
Miller, William Myers, Michael Olson, David Pierce, and Ralph Vincigeurra.
Martin Svedlow and Todd Withey deserve special thanks, too, for their support


and enthusiasm in applying the book’s techniques. Thanks are also due to
Martha Dionne, the TASC Librarian, and her staff, Audrey Palmieri and
Margaret Ouzts, for their invaluable research assistance. Thanks also to Jan
Lapper and Pauline Parziale in helping me stay organized.
Much of this book is based on my valuable experience at IBM. I especially
thank Khoa Nguyen (now at Videoserver), who guided me through my early
days in project management. I also learned a great deal from working with
Robert Swann and Fred Scheibl.
I am especially grateful to the editors at John Wiley. Thanks to Theresa
Hudson for her belief and support of the book, and to Sandra Bontemps and
Kathryn A. Malm for their patient efforts in shaping the text.

Dedication
With love and gratitude to my wife, Judi Taylor Cantor, and my son, Michael

Table of Contents

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Previous Table of Contents Next

-----------

Part One

Principles for Object-Oriented
Program Management
Chapter 1
Object-Oriented Development as a
Management Tool
If you know the enemy and know yourself, you need not fear the
result of a hundred battles. If you know yourself but not the
enemy, for every victory gained you will also suffer a defeat. If
you know neither the enemy nor yourself, you will succumb in
every battle.
Sun Tzu, Chinese general. The Art of War, Chapter 3,
Axiom 18, c. 490 B.C.; (ed. by James Clavell, 1981).

The days of bringing a bunch of hackers together to build a large system are
over. This method of organizing a project, although quick, results in chaos;
such development programs are often in a continual crisis and programmers
burn out quickly. For software organizations to thrive, they must be productive
over the long term. Today’s programming challenges call for large teams of
programmers to collaborate to develop large complex programs without
reeling from crises to crises.
As computers have become more powerful, two complementary phenomena
have emerged:


• Increasingly large and complex programs, whose development
requires teams of programmers, are in demand.
• Better software design packages that automate tools for programming
higher-order languages are being developed.
These two trends call for methods that enable teams of programmers to
develop robust, manageable code quickly and efficiently. Perhaps the most

important trend to emerge, however, is the change of focus from the machine
to the person. Early programming languages were designed to reflect the
limitations of the machine. The programmer had to focus on how the machine
processed data. We revered those who were good at this and labeled them with
the exalted title of hacker. The resulting programs, known today as spaghetti
code, had fatal deficiencies: No one could follow it. No one could fix it. No
one could extend it. Even the original programmer, after some time away from
the code, had no idea how it worked. It was difficult to unravel and brittle,
fixing one bug was likely to introduce another. Attempting to extend the
functionality of such code was futile, and reuse was out of the question. In
fact, changing the format of the date fields in this code to accommodate years
beyond 1999 has proven to be so daunting there is discussion of international
economic catastrophe.
To be fair, the machines of that period were so expensive and resource-limited,
it made sense to write tight programs that used the machines efficiently. Now,
the economics are quite different. Modern languages accommodate human
limitations; machine resources are cheap; labor is expensive. The entire focus
of modern programming methodology has shifted from conserving machine
resources to making teams of programmers efficient.
There are two responses to “humanizing” software development: improved
software design paradigms with the associated programming languages and
project management approaches that better reflect how teams collectively
solve problems. If people are to collaborate, they need to be confident that they
are “on the same page.” Objects make it possible for humans to deal with the
complexity of modern software systems.
Almost all software projects become a battle because the project manager is
often faced with a schedule and budget that are rigidly fixed, while the actual
effort it will take to deliver to a satisfactory release is at best an educated guess
(I will discuss estimation methods later). The goal of every project manager is
to somehow deal with the cost and schedule uncertainty while meeting the

customer’s needs. Victory is claimed with customer acceptance of a project
delivered on time and within budget. But as in all battles, formidable enemies
stand between you and your victory. Therefore, this chapter begins with an
introduction to the enemies and how they conspire to prevent us from
delivering the right product on time. In addition, I will cite some useful ways
to help you understand the enemies so that you can defeat them with a
minimum of effort. The chapter continues with a brief discussion of the chief
weapons you can use in object-oriented projects to defeat the enemies. These
include the standard object concepts and modern concurrent team-based
development techniques. (Later chapters focus on addressing enemies and
achieving victory using object-oriented technology.)


NOTE
As promised in the Introduction, the techniques in this book are applied to a
real-world object development example, which begins in this chapter. Follow
the project as it progresses through the book to learn how you can apply the
techniques to your own projects.

Meet the Enemies
Every software project is besieged by at least one of these enemies:
• Inadequate and unstable requirements
• Inadequate customer communications
• Poor team communications
• Unnecessary complexity
• Ineffective team behavior
Though object technology may be directly applied to attack these enemies, it is
only by understanding their nature and how object technology provides the
necessary weapons that you can successfully apply the book’s techniques to
your particular program. Let us get to know the enemies better.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Previous Table of Contents Next

-----------

Inadequate and Unstable Requirements
Software projects derive from a customer’s need. Someone must want you to
deliver something useful or that person would not be willing to pay for its
development. These needs are captured as requirements, or the specifics of
what the system must do. For example, despite the complexity of bridge
building, it is comparably easy to specify its requirements: a bridge needs to
connect point A to point B, withstand storms, and be able to carry a certain
volume of traffic. Barring any geological surprises, it is possible to completely
specify a bridge that fully meets requirements.
Software projects, too, are governed by a list of requirements. Unlike the
requirements for a bridge, however, which do not change often, specifications
for building a piece of software are frequently added and changed throughout
the development cycle. Establishing stable software requirements and
communicating them effectively is the challenge.
Thus, one of the software project manager’s critical skills is the ability to
manage system requirements. Software systems are often intended to support
complicated operational needs, such as automating office work, managing
mission-critical tasks in an aircraft or weapons system, or supporting and
handling complicated financial transactions. These systems are so complicated
that any attempt to fully specify their capabilities is bound to fall short. A 1994
IBM study (Gibbs, 1994) found that 88 percent of large distributed systems
that met published requirements were not operational. In fact, the most
disciplined government programs in terms of requirement specifications have
been the most spectacular failures.


The Reconfigurable Cockpit Simulator
Your assignment is to manage the development of the software for a

reconfigurable cockpit simulator for a Stealth fighter. The simulator is a
mock-up of the Stealth fighter cockpit. The instrumentation is identical to
that of the actual fighter. The windshields have been replaced by
high-resolution monitors connected to top-of-the-line graphics generators.
The flight controls include the same tactile feedback as those in the real
cockpit.
This is not a video game, but a serious tool for skill and mission training. It
presents to the trainee a faithful representation of all the displays,
instruments, and out-the-window visualization of the modeled simulation.
Skill training includes take-off and landing under various conditions
(weather, terrain, etc.), formation flying, and engagements. For the simulator
to be effective, the simulator must model with high fidelity the actual
response of the fighter to the pilot’s controls. There cannot be any
discernable time lag cause by system overhead. Further, as the Stealth is
modified over its lifespan, the simulator must be modifiable to reflect these
changes. In fact, it should be capable of being configured quickly to model
the characteristics of the different versions in deployment. This flexibility is
what is meant by reconfigurable.
The trainer (the person who creates the lessons) must be able to program
threats (enemy aircraft, missiles, and antiaircraft fire). An important feature
is the ability to save a session and play it back for the student as a teaching
aid.
Mission training comprises rehearsing a planned mission as preparation. It
requires accurate modeling of the real terrain, placement of cultural items
(roads, building, airfields), as well as the expected weather. The ability to
quickly create the scenarios is essential.
A trainer workstation is attached to the cockpit simulators. The trainer
controls and monitors the missions. In addition:
• The hardware interfaces are stable, adequately documented, and
readily available.

• The simulator is a standalone system with no need to interface with
other systems.
• A software model of the aircraft’s response to the controls (thrust,
pitch, yawl, and drag) is available as an off-the-shelf product from a
third party.
You are given two years to deliver a working system. The delivery date is a
hard customer requirement and not negotiable.
As the new project manager, you are faced with planning, staffing, and
delivering the software with this system. Your company has some experience
in modeling and simulation, but this is your first manned simulator. No one
you know has ever flown a Stealth fighter.


TIP
It is wise to assume that you never have a complete specification of the
system.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword

Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Previous Table of Contents Next

-----------

Inadequate Requirements
Successfully addressing customer satisfaction risk requires you and the
customer to agree unequivocally on what makes a system successful. Rarely
are you handed a complete set of interface specifications that have to be met to
declare victory. The more common, and probably worse, situation is that you
are given a detailed set of requirements, which in practice do not really specify
the system. Further, you will not be able to address cost and schedule risk
unless you have a means for achieving requirement stability.
There are two common causes for insufficient requirement specification. First,
the customer often does not fully understand what is required. For example, a
customer who runs a bank may need to extend his or her checking account
management software to include Internet accessibility. The customer

understands the need for security and data integrity and may even have some
idea of the acceptable response time. On the other hand, the customer may not
have thoroughly examined how a user will interact with the system. He or she
probably has not considered the user who submits 300 transactions in a day.
Therefore, the customer may need you and your team to help him or her think
through these issues.
Second, even if the customer is capable of thinking through the details of the
complex system required, he or she may not know how to document these
requirements effectively. There are two types of requirements:
Static. A quantitative description of the capacity and performance of the
system; for example, a database must handle 1,000 transactions a
minute.
Dynamic. How the users and others interact with the system so that the
task gets accomplished; for example, how the user enters a new record
in a database.
Usually, a system is specified in a requirements document that consists of a


long list of static requirements and a set of constraints on the dynamic
requirements. For example, the document might contain the line “the system
must handle 1,000 transactions a minute” (a static requirement). Another line
might read “the system is entirely menu-driven from a mouse; there are no
keyed-in commands” (a constant on the dynamic requirements). Sometimes, a
detailed description of the dynamic requirements, called a concept of
operations document, is provided along with the static requirements. The
statistics show that systems that meet the written requirements are often not
operational; the stated static requirements were met, but the unstated dynamic
requirements were not.
One of the advantages of object-oriented development is that it includes use
cases, a method for specifying and managing dynamic requirements. Use cases

provide a format for specifying the dynamic requirements. They capture in
detail how the system will behave in response to user interaction. When you
and your customer share the use cases, a common understanding of the
expected behavior of the system can be reached. In addition, use cases form a
bridge between the customer’s view and the designer’s and implementer’s
view of the system. (Use cases are discussed in more detail in Chapter 2.)

Unstable Requirements
Even after a software project is near completion, requirements continue to be
discovered or refined. These changes may be discovered during design
reviews, or early testing or through unexpected system component
interactions. Unstable requirements will impede your ability to deliver a useful
project.
Requirements may become unstable for several reasons:
• Customers develop a clearer understanding of what they need as the
program develops.
• Customers come to realize that the original requirements failed to
capture their intent.
• Customers may have asked for something that they do not really need
and are willing to forgo later in the development.
• The customer’s needs change.
• The customer staff or management changes. (Someone arrives with
his or her own ideas and an urge to make a difference.)
These unanticipated changes in requirements, if discovered during the later
phases of development, could be the cause of a major project setback and,
thereafter, for recrimination. In order to be successful, the project manager
needs tools to manage requirements that will be changed, refined, and
discovered throughout the development cycle. Object-oriented design provides
these tools.
One of the more insidious forms of this enemy is sometimes called function

creep. It is the slow addition of system function throughout the development
so that in the end, the customer expects significantly more than you originally
signed up for. Throughout the development, your staff or your customer has
small suggestions that will lead to a system improvement. Over time, however,


suggestions add up until your ability to deliver the system is in jeopardy.
Every software project manager has experienced function creep without any
concomitant relief on schedule or budget. Use cases, explored in Chapter 2,
allow each of the functional enhancement suggestions to be captured and
addressed in a disciplined way.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Previous Table of Contents Next

-----------

Inadequate Customer Communications
Another project management enemy and one of the potential causes of project
failure is poor communication between the customer and the developer. Given
the difficulty of specifying the requirements, it is essential that you and the
customer maintain open and constructive communications to ensure that you
are building what the customer expects. To accomplish this requires ongoing
interaction.
In addition, every development project is based on less than perfect
information. The development effort begins with a set of assumptions about
how the project will go. Almost certainly, these assumptions will have to be
adjusted as the project unfolds. There will be trade-offs in budget, schedule,
and functional content. You and the customer must share in these trade-offs, so
the communications channels must be in place to permit reaching agreement.
An example of a poor customer/developer communication style is an
adversarial approach, sometimes called correct by construction. The customer
requires that reams of requirement and design specifications be created by
your team. He or she must review and approve the documents before coding is

begun. The premise is that if the documentation is sufficiently detailed and
found to be correct by the customer, then the project is correct by construction.
The developers only need build what has been documented.


Requirements for the Reconfigurable Simulator
As a project manager, you are handed thousands of pages of requirements.
As you go through them, you come to realize they consist mainly of the
descriptions of the instrumentation given in gory detail. You are left with
many questions, which primarily concern how the trainer needs to interact
with the system. The authors of the specifications were the aircraft engineers,
who do not have full appreciation of the operational considerations of the
skill and mission training. What information does the trainer’s workstation
need to display? How are the scenarios built? Are they stored and retrieved?
Does the trainer have a set of scenarios that are used as lesson plans? Does
the trainer need to stop the lesson from time to time to make a point? How
exactly does a trainer monitor four simulators at once?
You have a fairly good idea of the static requirements. But your
understanding of how the system is used, the dynamic requirements, is much
less clear.
You have another concern. The requirements in many cases look more like a
wish list than a serious attempt to describe a system that can be delivered on
time. For example, one requirement is that a checkpoint be made as often as
every tenth of a second, and that playback go backward and forward in time.
Furthermore, certain of the requirements seem expensive to implement and
not as important as the others.
And never forget, the requirements may change. After all, it is not due for
two years.
Certainly, adding formality and discipline to the development process is a
good idea, but there are several problems with the adversarial approach. This

approach is defocusing; it adds risk and expense to the project. Since the entire
success of the project depends on correct documents, the customer and the
developer focus their attention on the documentation, not the project. An
unreasonable amount of effort may be spent in the attempt to create a correct
diagram. In fact, so much of the project’s budget can be spent trying to finish
the flawless design that the project may be canceled before the software is
coded.
This approach also discourages shared responsibility. If the document is
incorrect, and the project is delivered as specified, then it is the customer’s
fault if it does not work. If is not delivered as specified, it is the developer’s
fault. The clear placement of accountability may appear to be an advantage,
but in practice, it has been shown to be dysfunctional. It hampers the essential
constructive communication between the customer and the developer.
Experience has also shown that no amount of formal process, checkpoints, or
design review can completely eliminate the risk of delivering a nonoperational
system. While effectively establishing dynamic and static requirements helps,
you and your customer need to maintain an ongoing dialog. To ensure this,
develop a common vocabulary to discuss the system specifications in a way
the customer can understand. Assess whether this project will serve his or her
needs. This will drive the design process. As the project proceeds, the


customer’s understanding of the program will evolve. Only by taking
advantage of the increased understanding can you and the customer ensure that
what is delivered is acceptable. Communicating in this way provides an
ongoing view of what will be delivered and a chance for you to respond to the
customer’s reaction as the project proceeds. Chapters 4 through 9 discuss how
to promote this kind of communication.

Previous Table of Contents Next

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.


To access the contents, click the chapter and section titles.

Object-Oriented Project Management with UML
Go!
Keyword
Brief
Full
Advanced
Search
Search Tips

(Publisher: John Wiley & Sons, Inc.)
Author(s): Murray Cantor
ISBN: 0471253030
Publication Date: 08/01/98

Search this book:
Go!

Previous Table of Contents Next

-----------

Poor Team Communications
A software system of any significant size requires a team of developers. It is
not unusual to have 10, 50, 100, or even 1,000 developers on a development
team. Each developer is responsible for a piece of code that must work in
conjunction with all of the code being generated by all of the other developers.
Clearly, communication among team members is imperative.
As the number of developers increases, each developer has that many more
people to synchronize. Accordingly, as pointed out in Fred Brooks’ The
Mythical Man-Month, the amount of communication among developers
increases almost quadratically with the size of the project.
Poor communications thus is an enemy with two faces: too little and too much.
Too little communication will result in a system that does not come together.
Too much communication results in too much time spent coordinating efforts
and not enough time spent developing code. Unless you take steps to explicitly
manage the communications within your development team, they can get out
of hand.
FOR FURTHER READING
Everyone who develops software should read Fredrick P. Brooks and
Fredrick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley). The
anniversary edition was published in 1995.

One approach to managing a program of any significant size is to break down
the development team into functional subteams. This divide-and-conquer
approach is essential, but it is not without communication problems. If there
are communication barriers among the teams, friction is the result. This poor
communication across teams will have a negative effect on the project, in
particular, each team may meet its own goals to the detriment of the total
program.