Page 42 -

CHAPTER 1 THE PRODUCT 13

later." At first, this statement may seem counterintuitive. However, as new people
are added, people who were working must spend time educating the newcomers,
thereby reducing the amount of time spent on productive development effort. Peo-
The Software Project ple can be added but only in a planned and well-coordinated manner.
Managers Network at Myth: If I decide to outsource the software project to a third party, I can just relax
3
www.spmn.com can
help you dispel these and and let that firm build it.
other myths. Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects.
Customer myths. A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales department,
or an outside company that has requested software under contract. In many cases,
the customer believes myths about software because software managers and prac-
titioners do little to correct misinformation. Myths lead to false expectations (by the
customer) and ultimately, dissatisfaction with the developer.
Myth: A general statement of objectives is sufficient to begin writing programs—
we can fill in the details later.
Work very hard to
understand what you Reality: A poor up-front definition is the major cause of failed software efforts. A
have to do before you formal and detailed description of the information domain, function, behavior, per-
start. You may not be formance, interfaces, design constraints, and validation criteria is essential. These
able to develop every characteristics can be determined only after thorough communication between cus-
detail, but the more
you know, the less risk tomer and developer.
you take. Myth: Project requirements continually change, but change can be easily accom-
modated because software is flexible.
Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. Figure 1.3 illustrates the impact of
change. If serious attention is given to up-front definition, early requests for change
can be accommodated easily. The customer can review requirements and recom-
XRef mend modifications with relatively little impact on cost. When changes are requested
The management and during software design, the cost impact grows rapidly. Resources have been com-
control of change is mitted and a design framework has been established. Change can cause upheaval
considered in detail in
Chapter 9. that requires additional resources and major design modification, that is, additional
cost. Changes in function, performance, interface, or other characteristics during
implementation (code and test) have a severe impact on cost. Change, when requested
after software is in production, can be over an order of magnitude more expensive
than the same change requested earlier.

3 The term “outsourcing” refers to the widespread practice of contracting software development
work to a third party—usually a consulting firm that specializes in building custom software for
its clients.