Page 163 -

134 PART TWO MANAGING SOFTWARE PROJECTS

TABLE 5.1 Complexity weight
Complexity Object type
weighting for Simple Medium Difficult
object types
[BOE96] Screen 1 2 3
Report 2 5 8

3GL component 10

sophisticated estimation models (using FP and KLOC) are also available as part of
COCOMO II.
Like function points (Chapter 4), the object point is an indirect software measure
? What is an that is computed using counts of the number of (1) screens (at the user interface), (2)
“object
point”? reports, and (3) components likely to be required to build the application. Each object
instance (e.g., a screen or report) is classified into one of three complexity levels (i.e.,
simple, medium, or difficult) using criteria suggested by Boehm [BOE96]. In essence,
complexity is a function of the number and source of the client and server data tables
that are required to generate the screen or report and the number of views or sec-
tions presented as part of the screen or report.
Once complexity is determined, the number of screens, reports, and components
are weighted according to Table 5.1. The object point count is then determined by
multiplying the original number of object instances by the weighting factor in Table
5.1 and summing to obtain a total object point count. When component-based devel-
opment or general software reuse is to be applied, the percent of reuse (%reuse) is
estimated and the object point count is adjusted:
NOP = (object points) x [(100 %reuse)/100]

where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a “productivity
rate” must be derived. Table 5.2 presents the productivity rate
TABLE 5.2
PROD = NOP/person-month
Productivity
rates for object
points [BOE96]

Very Very
Developer's experience/capability Low Nominal High
low high
Environment maturity/capability Very Low Nominal High Very
low high
PROD 4 7 13 25 50