Page 154 -

CHAPTER 5 SOFTWARE PROJECT PLANNING 125

In this section, we consider the software sizing problem. Because a project esti-
mate is only as good as the estimate of the size of the work to be accomplished, siz-
ing represents the project planner’s first major challenge. In the context of project
planning, size refers to a quantifiable outcome of the software project. If a direct
approach is taken, size can be measured in LOC. If an indirect approach is chosen,
size is represented as FP.
Putnam and Myers [PUT92] suggest four different approaches to the sizing problem:
“Fuzzy logic” sizing. This approach uses the approximate reasoning tech-
niques that are the cornerstone of fuzzy logic. To apply this approach, the
? How do we planner must identify the type of application, establish its magnitude on a
size the
software that qualitative scale, and then refine the magnitude within the original range.
we’re planning to Although personal experience can be used, the planner should also have
build? 8
access to a historical database of projects so that estimates can be com-
pared to actual experience.
Function point sizing. The planner develops estimates of the information
domain characteristics discussed in Chapter 4.
Standard component sizing. Software is composed of a number of differ-
ent “standard components” that are generic to a particular application area.
For example, the standard components for an information system are subsys-
tems, modules, screens, reports, interactive programs, batch programs, files,
LOC, and object-level instructions. The project planner estimates the number
of occurrences of each standard component and then uses historical project
data to determine the delivered size per standard component. To illustrate,
consider an information systems application. The planner estimates that 18
reports will be generated. Historical data indicates that 967 lines of COBOL
[PUT92] are required per report. This enables the planner to estimate that
17,000 LOC will be required for the reports component. Similar estimates and
computation are made for other standard components, and a combined size
value (adjusted statistically) results.
Change sizing. This approach is used when a project encompasses the use
of existing software that must be modified in some way as part of a project.
The planner estimates the number and type (e.g., reuse, adding code, chang-
ing code, deleting code) of modifications that must be accomplished. Using
an “effort ratio” [PUT92] for each type of change, the size of the change may
be estimated.
Putnam and Myers suggest that the results of each of these sizing approaches be
combined statistically to create a three-point or expected value estimate. This is accom-
plished by developing optimistic (low), most likely, and pessimistic (high) values for
size and combining them using Equations (5-1) described in the next section.

8 See Section 5.9 for a discussion of estimating tools that make use of a historical database and the
other sizing techniques discussed in this section..