Page 166 -

CHAPTER 5 SOFTWARE PROJECT PLANNING 137

4. Develop a comparison matrix that presents a head-to-head comparison of key
functions. Alternatively, conduct benchmark tests to compare candidate software.

5. Evaluate each software package or component based on past product qual-
ity, vendor support, product direction, reputation, and the like.
6. Contact other users of the software and ask for opinions.

In the final analysis, the make/buy decision is made based on the following condi-
tions: (1) Will the delivery date of the software product be sooner than that for inter-
nally developed software? (2) Will the cost of acquisition plus the cost of customization
be less than the cost of developing the software internally? (3) Will the cost of out-
side support (e.g., a maintenance contract) be less than the cost of internal support?
These conditions apply for each of the acquisition options.

5.8.1 Creating a Decision Tree
? Is there a The steps just described can be augmented using statistical techniques such as decision
systematic
way to sort tree analysis [BOE89]. For example, Figure 5.6 depicts a decision tree for a software-
through the based system, X. In this case, the software engineering organization can (1) build sys-
options associated
with the tem X from scratch, (2) reuse existing “partial-experience” components to construct the
make/buy system, (3) buy an available software product and modify it to meet local needs, or
decision? (4) contract the software development to an outside vendor.

FIGURE 5.6 Simple (0.30) $380,000
A decision tree
to support the
make/buy Difficult (0.70) $450,000
decision Build
Minor changes $275,000
(0.40)
Reuse
System X $310,000
Simple (0.20)
Major
Buy
changes
(0.60) $490,000
Complex (0.80)
Minor changes $210,000
(0.70)
Contract
$400,000
Major changes (0.30)

Without changes $350,000
(0.60)
$500,000
With changes (0.40)