Page 147 -

118 PART TWO MANAGING SOFTWARE PROJECTS

For some projects in established areas the answers are easy. You have done projects
like this one before. After a few hours or sometimes a few weeks of investigation, you are
sure you can do it again.
Projects on the margins of your experience are not so easy. A team may have to spend
several months discovering what the central, difficult-to-implement requirements of a new
application actually are. Do some of these requirements pose risks that would make the
Technical feasibility is project infeasible? Can these risks be overcome? The feasibility team ought to carry initial
important, but architecture and design of the high-risk requirements to the point at which it can answer
business need is even these questions. In some cases, when the team gets negative answers, a reduction in require-
more important. It
ments may be negotiated.
does no good to build Meantime, the cartoon people [senior managers] are drumming their fingers nervously
a high tech system or
on their large desks. Often, they wave their fat cigars in a lordly manner and yell impatiently
product that no one
really wants. through the smoke screen, “Enough. Do it!”
Many of the projects that appear in the newspapers a few years later as whopping fail-
ures got started this way.
Putnam and Myers correctly suggest that scoping is not enough. Once scope is under-
stood, the software team and others must work to determine if it can be done within
the dimensions just noted. This is a crucial, although often overlooked, part of the
estimation process.

5.3.3 A Scoping Example
Communication with the customer leads to a definition of the data and control that
are processed, the functions that must be implemented, the performance and con-
straints that bound the system, and related information. As an example, consider
software for a conveyor line sorting system (CLSS). The statement of scope for CLSS
follows:
The conveyor line sorting system (CLSS) sorts boxes moving along a conveyor line. Each
box is identified by a bar code that contains a part number and is sorted into one of six bins
at the end of the line. The boxes pass by a sorting station that contains a bar code reader
and a PC. The sorting station PC is connected to a shunting mechanism that sorts the boxes
into the bins. Boxes pass in random order and are evenly spaced. The line is moving at five
feet per minute. CLSS is depicted schematically in Figure 5.1.
CLSS software receives input information from a bar code reader at time intervals that
conform to the conveyor line speed. Bar code data will be decoded into box identification
format. The software will do a look-up in a part number database containing a maximum
of 1000 entries to determine proper bin location for the box currently at the reader (sorting
station). The proper bin location is passed to a sorting shunt that will position boxes in the
appropriate bin. A record of the bin destination for each box will be maintained for later
recovery and reporting. CLSS software will also receive input from a pulse tachometer that
will be used to synchronize the control signal to the shunting mechanism. Based on the
number of pulses generated between the sorting station and the shunt, the software will
produce a control signal to the shunt to properly position the box.