4

Object-Oriented Software
Estimation

After the requirements are gathered, the customer may like to know the cost and time estimates
of the project. In order to determine the cost and time of a project, estimates of size and effort
are required. Providing accurate estimates for any software project is an important activity.
Unfortunately, determining estimates in the early phases of software development is difficult due
to lack of information available about the system at such an early stage. However, early estimates
are highly desirable in order to determine the feasibility of a project or to bid for a tender. The
importance of realistic estimates can be best explained by an example.
Suppose we want to construct our home and we have received many quotations mostly
around ` 30 lakh. We select a builder who offers to do this job in 6 months for ` 25 lakh. The
contract is signed and the builder begins the work. After about 2 months, the builder comes
and demands ` 4 lakh extra and another 2 months for the same job. This is a real problem for
us as we can neither arrange for more loan nor wait for 2 more months. After a great deal of
discussion, we were forced to stop the construction. This was a great loss to us and to the builder
as well. The real problem was that the builder made unrealistic or probably poor estimates.
The above is a classic example of lack of estimation capabilities of the builder. Thus, providing
realistic estimates is essential to project planning process. By using estimations, the project can
be measured and controlled. In order to conduct effective software estimates, we must identify:
 Scope/boundaries of the project
 Size of the project
 Effort of the project
 Resources required in the project
 Risk involved in the project
123
124  Object-Oriented Software Engineering

In this chapter, the object-oriented methods for estimating size and effort are presented.
These methods can be used in requirement and design phase of software development life cycle
in order to estimate effort. The process of risk management is also presented so that uncertain
and critical activities can be identified in the early phases of software development.

4.1 Need of Object-Oriented Software Estimation

Traditional software estimations include lines of source code and function point analysis for
size estimation: COCOMO 81, COCOMO II and Putnam resource allocation model for cost
estimation. However, as the paradigm is shifting towards object-oriented software, we wonder “Is
object-oriented software estimation different than traditional software estimation?” We would say
it is a similar activity but the key parameters (for example size) to do an estimation change in the
case of object-oriented software. Object-oriented software engineering uses unified modelling
language for creating models. As discussed in Chapter 3, one of the important mechanisms to
depict the functionality of the system is use cases. The use case diagram may be used to predict
the size and hence the effort of the software at an early stage of software development. Classes
are also an important element for measuring size in object-oriented software. Figure 4.1 shows
the framework for estimating an object-oriented software.

Figure 4.1 Framework of object-oriented software estimation.

The functionality of an object-oriented software can be depicted using use cases and these
use cases are transformed using classes. Thus, the effort can be estimated using the size measures
computed for object-oriented products.

4.2 Lorenz and Kidd Estimation Method

The Lorenz and Kidd method for estimation of size and effort is one of the earliest methods
developed in 1994 (Lorenz and Kidd, 1994). The results of this method are based on the study
of 5–8 projects developed in C++ and Smalltalk. Lorenz and Kidd provided two methods for
estimation of a number of classes:
1. Use of scenario scripts: The number of scenario scripts (same as use cases) may be
used to estimate size of classes.
Number of classes = 17 × number of scenario scripts
This method for determining the number of classes can be used in early phases of
software development life cycle, i.e. before the classes have been identified.
 Object-Oriented Software Estimation  125
2. Use of key and support classes: After elaborating the design phase, the number of
classes can be determined. Lorenz and Kidd differentiated between key classes and
support classes. Key classes are specific to business applications and are ranked with
higher priority by the customer. These classes also involve many scenarios. Support
classes are common for many applications. These classes include user interface, back
end classes and communications.
The following are used to determine the support classes:

Interface type Multiplier

No GUI 2.0
Text-based user interface 2.25
Graphical user interface 2.5
Complex graphical user interface 3.0

Support classes can be calculated as:

Support classes = Number of key classes × Multiplier
Finally, the total number of classes is obtained by adding key classes and support classes.
Total number of classes = Key classes + Support classes
According to Lorenz and Kidd, each class requires 10 to 20 person days for implementation.
Thus, effort can be calculated as:
Effort = Total number of classes × (10 to 20 person days)
This method is easy and simple to understand.

EXAMPLE 4.1 An application consists of 15 scenario scripts and requires 15 person days to
implement each class. Determine the effort of the given application.
Solution Number of classes = 17 × Scenario scripts
   = 17 × 15 = 255
Effort = 255 × 15 = 3825 person days
EXAMPLE 4.2 Consider the database application project with the following characteristics:
1. The application has 45 key classes
2. A graphical user interface is required
Calculate the effort to develop such a project given 20 person days.
Solution Number of key classes = 45
Number of support classes = Number of key classes × Multiplier
= 45 × 2.5
= 112.5
Total number of classes = Number of key classes + Number of support classes
= 112.5 + 45
= 157.5
126  Object-Oriented Software Engineering

Effort = 157.5 × 20
= 3150 person days

4.3 Use Case Points Method

The use case points method was developed by Gaustav Karner of Objectory (currently known
as IBM Rational Software) in 1993 (Karner, 1993). The method is used for estimating size
and effort of object-oriented projects using use cases. The method is an extension of function
point analysis technique developed by Albrecht and Gaffney (1983). Karner’s work on use case
points was written in his diploma thesis titled “Metrics Objectory”. The use case points method
measures the functionality of the software based on the use case counts. The use case model is
a very popular technique for requirements gathering and can be used at early phases of software
development in order to provide estimations of the project. Figure 4.2 shows the steps followed

Figure 4.2 Use case points method.

 Object-Oriented Software Estimation  127
to calculate use case points using the use case points method. Thus, the following steps are used
in the use case points method:
1. Classification of actors and use cases: In this step, the complexity levels of the actors
and use cases are identified and their weighted sum is computed.
2. Computing unadjusted use case points: The estimates of unadjusted use case points
are made.
3. Calculating technical complexity factors: In this step, we identify the degree of
influence of technical factors on the project.
4. Calculating environmental complexity factors: In this step, the environmental
complexity factors are classified.
5. Calculating use case points: In the final step, the use case points are calculated on the
basis of values obtained from steps 1, 2 and 3.

4.3.1 Classification of Actors and Use Cases

The first step involved in the calculation of use case points is the classification of actors and use
cases. The actors are ranked according to their complexity, i.e. simple, average or complex. The
criteria for classifying an actor as simple, average or complex are given in Table 4.1.

Table 4.1 Actors with weighting factors

Actor complexity Description Weighting factor
Simple Represents another system with a defined 1
application programming interface (API).
Average Represents interaction with another system 2
through a protocol such as TCP/IP or a
human interaction with a line terminal.
Complex Represents interaction through a graphical 3
user interface.

The unadjusted actor weight (UAW) is the weighted sum of actors. Mathematically,
n
UAW = Â ai ¥ wi
i =1

where n is the number of actors, ai is the ith actor and wj is the value of weighting factor of the
ith actor.
The use cases are ranked according to their complexity: simple, average or complex. The
criteria for classifying a use case are given in Table 4.2. There are two methods for classifying
use case complexity:
1. A use case may be classified as simple, average or complex based on the number of
transactions. A transaction can be defined as a collection of activities that are counted
by counting the use case steps.
2. The other method to classify the use case is counting the analysis objects which are
counted by determining the number of objects that we will need to implement a use case.
128  Object-Oriented Software Engineering

Table 4.2 Use cases with weighting factors

Use case complexity Description Weighting factor
Simple Number of transactions  3 5
Analysis objects  5
Average Number of transactions >3 and <7 10
Analysis objects >5 and <10
Complex Number of transactions  7 15
Analysis objects  10

Each use case is multiplied by its corresponding weighting factors and this sum is added to
get unadjusted use case weight (UUCW). Mathematically,
m
UUCW = Â ui ¥ wi
i =1

where m is the number of use cases and ui is the ith use case.

4.3.2 Computing Unadjusted Use Case Points

After classifying actors and use cases, the resultant unadjusted use case points (UUCP) are
computed by adding UAW and UUCW as shown in mathematical form below:
UUCP = UAW + UUCW
The procedure for calculating UUCP is given in Table 4.3.

Table 4.3 Calculating unadjusted use case points

Units Complexity count Totals
Actor × weighting factor
× weighting factor

Use cases × weighting factor

× weighting factor

Total unadjusted use case points

4.3.3 Calculating Technical Complexity Factors

Technical complexity factor (TCF) assesses the functionality of the software. TCFs are similar
to the ones in function point analysis except some factors are added and some deleted. The
criterion for technical factor is defined by Symons (1988) as:
 Object-Oriented Software Estimation  129

A system requirement other than those concerned with information content intrinsic to and
affecting the size of the task, but not arising from the project environment.

TCFs vary depending on the difficulty level of the system. Each factor is rated on the scale of
0 to 5 as shown in Figure 4.3. Table 4.4 shows the weights assigned to the contributing technical
factors.

Figure 4.3 Measurement scale for TCF.

Table 4.4 Weighting factors for TCF

Factor (Fi) Contributing factors wi
1 Distributed systems 2
2 Application performance, objectives in 1
either response or throughput
3 End user efficiency 1
4 Complex internal processing 1
5 Reusability of source code 1
6 Installation ease 0.5
7 Ease of usability 0.5
8 Portability 2
9 Ease to change 1
10 Concurrency 1
11 Special security issues 1
12 Direct access for third parties 1
13 Special customer training provided 1

TCF is obtained by using the following relationship:

13
TCF = 0.6 + 0.01 Â Fi ¥ wi
i =1

4.3.4 Calculating Environmental Complexity Factors

Environmental complexity factor (ECF) helps in estimating the efficiency of the project. This
factor is calculated based on the early estimations in the project based on the interviews carried
out in objectory projects. Figure 4.4 classifies the ECF on the measurement scale from 0 to 5, 0
being irrelevant factor and 5 being essential factor. Table 4.5 shows the weights assigned to the
contributing environmental factors.
130  Object-Oriented Software Engineering

Figure 4.4 Measurement scale for ECF.

Table 4.5 Weighting factors for ECF

Factor (Fi) Contributing factors wi
1 Familiarity with objectory/process 1.5
2 Application experience 0.5
3 Analyst capability 0.5
4 Object-oriented experience 1
5 Motivation 1
6 Part-time workers –1
7 Programming language difficulty –1
8 Stable requirements 2

The ECF is obtained by using the following relationship:

8
ECF = 1.4 + ( -0.03) Â Fi ¥ wi
i =1

4.3.5 Calculating Use Case Points

The final number of use case points is calculated by multiplying UUCP by TCF and ECF.
UCP = UUCP × TCF × ECF
Duration can be measured 20 person hours per use case point.
The use case points method can be used in early phases of software development in order to
estimate the size and effort.

EXAMPLE 4.3 Consider an airline reservation system where the following information is
available:
Number of actors: 05
Number of use cases: 10
Assume all complexity factors are average. Compute the use case points for the project.
Solution
5
UAW = Â ai ¥ wi
i =1
= 5 ¥ 2 = 10
 Object-Oriented Software Estimation  131

10
UUCW = Â ui ¥ wi
i =1
= 10 ¥ 10 = 100
UUCP = UAW + UUCW
= 10 + 100 = 110
13
TCF = 0.6 + 0.01 Â Fi ¥ wi
i =1
= 0.6 + 0.01 ¥ (3 ¥ 2 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 0.5
+ 3 ¥ 0.5 + 3 ¥ 2 + 3 ¥ 2 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1)
= 0.6 + 0.01 ¥ 42 = 1.02
8
ECF = 1.4 + ( -0.03) Â Fi ¥ wi
i =1
= 1.4 + ( -0.03) ¥ (3 ¥ 1.5 + 3 ¥ 0.5 + 3 ¥ 0.5 + 3 ¥ 1
+ 3 ¥ 1 + 3 ¥ -1 + 3 ¥ -1 + 3 ¥ 2)
= 0.995
UCP = UUCP ¥ TCF ¥ ECF
= 110 ¥ 1.02 ¥ 0.995
= 111.639

EXAMPLE 4.4 The following information is available for an application:

2 simple actors, 2 average actors, 1 complex actor, 2 use cases with the number of transactions 3,
4 use cases with the number of transactions 5 and 2 use cases with the number of transactions 15.
In addition to the above information, the system requires:
(i) Significant user efficiency
(ii) Essential ease to change
(iii) Moderate concurrency
(iv) Essential application experience
(v) Significant object-oriented experience
(vi) Essential stable requirements
Other technical and environmental complexity factors are treated as average. Compute the use
case points for the project.
Solution
5
UAW = Â ai ¥ wi
i =1
= 2 ¥1 = 2
132  Object-Oriented Software Engineering

2¥2 = 4
1¥3 = 3
UAW = 2 + 4 + 3 = 9
8
UUCW = Â ui ¥ wi
i =1

= 2 ¥ 5 + 4 ¥ 10 + 2 ¥ 15 = 10 + 40 + 30 = 80
UUCP = UAW + UUCW
= 9 + 80 = 89
13
TCF = 0.6 + 0.01 Â Fi ¥ wi
i =1

= 0.6 + 0.01 ¥ (3 ¥ 2 + 3 ¥ 1 + 4 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 0.5

+ 3 ¥ 0.5 + 3 ¥ 2 + 5 ¥ 1 + 2 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1)
= 0.6 + 0.01 ¥ 44 = 1.84
8
ECF = 1.4 + ( -0.03) Â Fi ¥ wi
i =1

= 1.4 + -0.03 ¥ 3 ¥ 1.5 + 3 ¥ 0.5 + 3 ¥ 0.5 + 4 ¥ 1

+ 3 ¥ 1 + 3 ¥ -1 + 3 ¥ -1 + 5 ¥ 2
= 1.4 + ( -0.03) ¥ 19.5
= 0.815
UCP = UUCP ¥ TCF ¥ ECF
= 89 ¥ 1.84 ¥ 0.815
= 133.46

EXAMPLE 4.5 Consider Example 4.4 and calculate the effort for the given application.
Solution
Effort = UCP × 20
= 133.46 × 20
= 2669.2 person hours
 Object-Oriented Software Estimation  133
EXAMPLE 4.6 Consider the following use case model of result management system:

The number of transactions required for each use case is given as follows:

Use cases Number of transactions

Maintain student details 7
Maintain course details 10
Maintain result details 5
Generate reports 3
View results 2
Login 4

Assume all complexity factors are average. Compute the use case points and effort for the
project.
Solution
Use cases Complexity
Maintain student details 15
Maintain course details 15
Maintain result details 10
Generate reports 5
View results 5
Login 10
(Contd.)
134  Object-Oriented Software Engineering

(Contd.)
Actors Complexity
Data entry operator 2
Administrator 2
Student 1
Faculty 1
UUCP 66

13
TCF = 0.6 + 0.01 Â Fi ¥ wi
i =1

= 0.6 + 0.01 ¥ (3 ¥ 2 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 0.5 + 3 ¥ 0.5

+ 3 ¥ 2 + 3 ¥ 2 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1 + 3 ¥ 1)
= 0.6 + 0.01 ¥ 42 = 1.02
8
ECF = 1.4 + ( -0.03) Â Fi ¥ wi
i =1

= 1.4 + ( -0.03) ¥ (3 ¥ 1.5 + 3 ¥ 0.5 + 3 ¥ 0.5

+ 3 ¥ 1 + 3 ¥ 1 + 3 ¥ -1 + 3 ¥ -1 + 3 ¥ 2)
= 0.995
UCP = UUCP ¥ TCF ¥ ECF
= 66 ¥ 1.02 ¥ 0.995
= 66.98
Effort = 20 ¥ 66.98 = 1339.67 person hours

4.4 Class Point Method

This method is used to provide the system level size estimation of the object-oriented software. The
class point method was given by Costagliola and Tortora (2005). This method primarily focuses
on classes for the estimation of size. The complexity of a class is analysed through determining
the number of methods in a class, the number of attributes in a class and the interaction of a
class with other classes. This method can be used for estimation during requirement and design
phase of software development life cycle. The steps required for the estimation of size are given
as follows:
1. Identification of classes
2. Determination of complexity of classes
3. Calculation of unadjusted class point
4. Calculation of technical complexity factor
5. Calculation of class point
 Object-Oriented Software Estimation  135

4.4.1 Identification of Classes

In the class point method, four types of classes are identified. The types of system components
are given in Table 4.6.

Table 4.6 Class type with description

Class type Description Example (library
management system)
Problem domain type (PDT) Represents real-world entities in the Student, Book
application domain.
Human interface type (HIT) Satisfies the need for visualizing information LoginForm, BookDetailForm
and human–computer interaction.
Data management type (DMT) Includes classes which incorporate data Login
storage and retrieval.
Task management type (TMT) Includes classes which are responsible for BookDetailsController,
tasks StudentDtailsController

4.4.2 Classifying Class Complexity

In the class point method, two measures CP1 and CP2 are used. In CP1, the initial estimate of
size is made and CP2 provides detailed estimate of size. The following measures are used in the
calculation of CP1 and CP2 measures:
1. Number of external methods (NEM): It measures the size of class in terms of methods.
It counts the number of public methods in a class.
2. Number of service requested (NSR): It measures the interaction between system
components. It counts the number of services requested by other classes.
3. Number of attributes (NOA): It measures the complexity of a class. It counts the
number of data members in a class.
In the CP1 measure NEM and NSR are used to classify complexity of a class. Table 4.7 shows
the complexity for CP1 measure.

Table 4.7 Class complexity for CP1

0–4 NEM 5–8 NEM  9 NEM
0–1 NSR Low Low Average
2–3 NSR Low Average High
 4 NSR Average High High

In the CP2 measure, NOA is also considered; thus, a detailed insight into the estimate of size
is obtained. Tables 4.8 to 4.10 show the details for classifying class complexity for CP2 measure
on the basis of NEM, NSR and NOA.
136  Object-Oriented Software Engineering

Table 4.8 Class complexity for CP2

NOA
0–2 NSR 0–5 6–9  10
0–4 Low Low Average
NEM 5–8 Low Average High
9 Average High High

Table 4.9 Class complexity for CP2

NOA
3–4 NSR 0–4 5–8 9
0–3 Low Low Average
NEM 4–7 Low Average High
8 Average High High

Table 4.10 Class complexity for CP2

NOA
 5 NSR 0–3 4–7 8
0–2 Low Low Average
NEM 3–6 Low Average High
7 Average High High

4.4.3 Calculating Unadjusted Class Points

The total unadjusted class point (TUCP) is calculated by assigning complexity weights based on
the classifications made as given in Table 4.11.

Table 4.11 Complexity weights for each class type

Class type Description Complexity weight
Low Average High
PDT Problem domain type 3 6 10
HIT Human interface type 4 7 12
DMT Data management type 5 8 13
TMT Task management type 4 6 9

After classifying the complexity level of classes, the TUCP is calculated as follows:
4 3
TUCP = ÂÂ wi j ¥ xij
i =1 j =1
 Object-Oriented Software Estimation  137
where wij is complexity weights j ( j is low, average, high) assigned to class type i. xij is the number
of classes of type i (i is type of class problem domain, human interface, data management and
task management).

4.4.4 Calculating Technical Complexity Factor

The factors F1–F18 are the degree of influence (DI) as shown in Figure 4.5. Each DI is rated
on the scale of 0–5. DI is used to determine technical complexity factor (TCF). The TCF is
determined by the following mathematical formula:
18
TCF = 0.55 + 0.01 Â Fii
i =1

Fi Description Fi Description
1 Data communication 10 Reusability
2 Distributed functions 11 Ease of installation
3 Performance 12 Ease of operation
4 High used configuration 13 Multiple users
5 Transaction rate 14 Facilitation of change
6 Online data entry 15 Adaptability by user
7 End-user efficiency 16 Rapid prototyping
8 Online update 17 Multiuser interaction
9 Compiler processing 18 Multiple interfaces
Figure 4.5 Computing technical complexity factor.

4.4.5 Calculating Class Point and Effort

The final class point is calculated by multiplying total unadjusted class point values with
technical factor. The procedure for calculating adjusted class point (CP) is given as:
CP = TUCP × TCF
Costagliola and Tortora (2005) used data from 40 systems developed in Java language in order to
predict the effort during two successive semesters of graduate courses of software engineering.
They used ordinary least-square (OLS) regression analysis for deriving the effort model. The
effort is defined in terms of person hours for both CP1 and CP2 measures as:
Effort = 0.843 × CP1 + 241.85
Effort = 0.912 × CP2 + 239.75
138  Object-Oriented Software Engineering

Two measures CP1 and CP2 have been described. The CP1 measure can be used in early phases
of software development and the CP2 measure can be used when the number of attributes is
available.

EXAMPLE 4.7 Consider a project with the following parameters:

Class type Number of classes NEM NSR

PDT 4 6 2
4 5
10 15
5 7
HIT 6 7 10
5 8
8 12
6 9
2 4
4 2
DMT 3 2 3
1 0
3 4
TMT 2 4 8
8 12

Assume all the technical complexity factors have average influence. Calculate class points.
Solution

Class type Number of classes NEM NSR Complexity Weights

PDT 4 6 2 Average 6
4 5 Average 6
10 15 High 10
5 7 High 10
HIT 6 7 10 High 12
5 8 High 12
8 12 High 12
6 9 High 12
2 4 Average 7
4 2 Low 4
DMT 3 2 3 Low 5
1 0 Low 5
3 4 Average 8
TMT 2 4 8 Average 6
8 12 High 9
 Object-Oriented Software Estimation  139
The total unadjusted use case points are calculated as:
4 3
TUCP = Â Â wij ¥ xij
i =1 j =1

    = 6 × 2 + 10 × 2 + 12 × 4 + 7 × 1 + 4 × 1 + 5 × 2 + 8 × 1 + 6 × 1 + 9 × 1
    = 12 + 20 + 48 + 7 + 4 + 10 + 8 + 6 + 9
    = 124
18
TCF = 0.55 + 0.01 Â Fii
i =1

    = 0.55 + 0.01(18 × 3)

    = 0.55 + 0.54 = 1.09
  CP1 = 124 × 1.09 = 135.16

EXAMPLE 4.8 Consider a result management system with the following information:

Class name Class type NEM NSR NOA

Login PDT 4 1 10
Student PDT 3 3 12
Course PDT 4 0 8
Marks PDT 4 1 5
StudentForm HIT 1 1 1
CourseForm HIT 4 2 1
MarksForm HIT 2 8 1
LoginDetail DMT 2 1 0
StudentDetail DMT 4 2 0
CourseDetail DMT 5 3 0
MarksDetail DMT 6 2 0
LoginChecker TMT 2 0 0
MarksControl TMT 2 2 0
CourseControl TMT 3 3 0

In addition, the system requires

1. User adaptability is significant
2. Rapid prototyping has strong influence
3. Multiple interfaces are significant
4. Distributed functions are moderate
Assume all other factors as average. Calculate CP1 and CP2 using class point method and effort.
140  Object-Oriented Software Engineering

Solution

Class name Class type NEM NSR NOA CP1 w1 CP2 w2

Login PDT 4 1 10 Low 3 Average 6
Student PDT 3 3 12 Low 3 Average 6
Course PDT 4 0 8 Low 3 Average 6
Marks PDT 4 1 5 Low 3 Low 3
StudentForm HIT 1 1 1 Low 4 Low 4
CourseForm HIT 4 2 1 Low 4 Low 4
MarksForm HIT 2 8 1 Average 7 Low 4
LoginDetail DMT 2 1 0 Low 5 Low 5
StudentDetail DMT 4 2 0 Average 8 Low 5
CourseDetail DMT 5 3 0 Average 8 Low 5
MarksDetail DMT 6 2 0 Low 5 Low 5
LoginChecker TMT 2 0 0 Low 4 Low 4
MarksControl TMT 2 2 0 Low 4 Low 4
CourseControl TMT 3 3 0 Low 4 Low 4
65 65
18
TCF = 0.55 + 0.01 Â Fii
      i =1

   = 0.55 + 0.01(14 × 3 + 2 × 4 + 1 × 5 + 1 × 2)
   = 0.55 + 0.01 × 57 = 1.12
  CP1 = 65 × 1.12 = 72.8
  CP2 = 65 × 1.12 = 72.8
Effort = 0.843 × CP1 + 241.85 = 303.22 person hours
Effort = 0.912 × CP2 + 239.75 = 306.14 person hours

4.5 Object-Oriented Function Point

The traditional function point method can be mapped to obtain object points. The object point
sizing method is also known as object-oriented function point method as it is very similar to the
function point method. The object point method does not require much experience, requires less
effort for computation and can be calculated quickly. It better suites for object-oriented systems
and is easier to calculate as compared to the traditional function point method.
The object point method involves counting of classes and methods (services). All this
information is obtained from the object model of object-oriented design. In this approach, the
function point concepts are mapped to object-oriented concepts and the ambiguities present in
the function point method are removed.
 Object-Oriented Software Estimation  141

4.5.1 Relationship between Function Points and Object Points

A class is a template that encapsulates attributes and member functions into a single unit.
Objects are data members of the class. Classes may be divided into external and internal classes
depending on their scope and boundary. The relationship between concepts defined in function
point and their corresponding concepts in object points are shown in Table 4.12. The internal
logical files are mapped to internal classes, external interface files are mapped to external classes
and external inquiries/inputs/outputs are mapped to services.

Table 4.12 Relationship between function point and object point

Function point concept Object point concept
Internal logical files Internal class
External interface files External class
External inquires Services (methods)
External outputs
External inputs

The internal classes are the classes that reside inside the application boundaries and the
external classes are the classes that reside outside the application boundaries. The services are
the methods defined in the class. Figure 4.6 depicts the method to compute the object-oriented
concepts in object point method. For each external/internal class, it is necessary to compute the
number of data element types (DETs) and record element types (RETs). The DETs correspond
to the total number of attributes of a class and the RETs correspond to the total number of
subclasses of a class (descendants of a class) as shown in Figure 4.7. In inheritance hierarchy, the
classes that inherit the properties of the base class while having their own properties are known
as subclasses.

Figure 4.6 Steps for calculating object points.

142  Object-Oriented Software Engineering

Figure 4.7 Calculation of DETs and RETs.

4.5.2 Counting Internal Classes, External Classes and Services

An internal class identifies the total number of DETs and RETs in the class. In the IFPUG
Manual 4.1, DETs are defined as (IFPUG, 1994):
A unique user recognizable, non repeatable field.

DETs are counted by applying the following rules:

1. A DET is counted for each simple attribute (integer, string, real) defined in a class.
For example, the book accession number (integer type) stored in a class is counted as
one DET.
2. A DET is counted for each attribute required to communicate with another internal class
or external class (association or aggregation relationship; see details in Chapter 5).
In the IFPUG Manual 4.1, RET is defined as (IFPUG, 1994):
A unique recognizable subgroups of data elements within an internal logical file or external
interface file.

In object-oriented systems, these subgroups are known as subclasses or descendants. The

RET is counted for each of a given class. For example, if employee is a base class and salary,
contract based or hourly employee are three subclasses of class employee, then the RET count
for employee class is 3. One of the following rules is applicable to a class while counting RETs:
1. Count an RET for each subclass of the internal/external class.
2. If there are no subclasses, count internal/external classes as one RET.
Each service in the class is examined. For each service, the number of DETs and file type
referenced (FTR) needs to be counted. The counting of DETs and FTR involves simple and
complex data types referenced by the methods. A simple data type is a compiler-defined data
type and a complex data type is a user-defined data type. The following are the counting rules
for DETs and FTR for each service:
 Object-Oriented Software Estimation  143
1. A DET is counted for each simple data type referenced as arguments of the service or
global variables referenced by the service.
2. An FTR is counted for each complex data type referenced as arguments of the service or
returned by the service.
In Tables 4.13, 4.14 and 4.15, the complexity values for internal classes, external classes and
services are shown.

Table 4.13 Complexity table for internal class

1 to 19 DETs 20 to 50 DETs 51 or more DETs
0 to 1 RETs Low Low Average
2 to 5 RETs Low Average High
6 or more RETs Average High High

Table 4.14 Complexity table for external class

1 to 19 DETs 20 to 50 DETs 51 or more DETs
0 to 1 RETs Low Low Average
2 to 5 RETs Low Average High
6 or more RETs Average High High

Table 4.15 Complexity table for services

1 to 4 DETs 5 to 15 DETs 16 or more DETs
0 to 1 FTR Low Low Average
2 FTR Low Average High
3 or more FTR Average High High

Consider that the example of the result calculation of a student is shown. The class model is
given in Figure 4.8.

Figure 4.8 Class model of result management system.

144  Object-Oriented Software Engineering

In Table 4.16, the RET and DET are calculated for each class shown in Figure 4.8.

Table 4.16 Assigning complexity values in the given example

Class DET RET Complexity Complexity value
Student 4 3 Low 7
Internal exam 1 1 Low 7
External exam 1 1 Low 7
Result 1 1 Low 7

Table 4.17 shows the values of complexity types (high, average, low) for internal classes,
external classes and services.

Table 4.17 Values of complexity

Function type Low Average High
Internal class (IC) 7 10 15
External class (EC) 5 7 10
Services (S) 3 4 6

After classifying the internal classes, external classes and services, these are multiplied by
their complexity values. Finally, the results are summed up using the following formulas:
n
IC total = Â ICi
i =1
m
EC total = Â ECi
j =1
o
Stotal = Â Si
k =1

where n is the number of internal classes, m is the number of external classes and o is the
number of services.
The classes in the given example are internal, hence the occurrences of internal classes
are multiplied with their corresponding weights and summing all the resulting values, we get
IC = 4 × 7 = 28. The concrete services in the classes are 5. Assuming that the methods have
average complexity (as their signature is not given in the example), the services are 5 × 4 = 20.

4.5.3 Calculating Unadjusted Object Points

The unadjusted object points (UOP) are obtained as follows:
UOP = ICtotal + ECtotal + Stotal
In the example given in Figure 4.8, the UOP = ICtotal + Stotal = 28 + 20 = 48.
 Object-Oriented Software Estimation  145

4.5.4 Adjustment Factors

The Fi (i = 1 to 14) are the degree of influence and are based on responses to questions noted
in Figure 4.9. Each factor is rated on a scale of 0 to 5. The adjustment factor (AF) is calculated
using the following mathematical formula:
14
AF = 0.65 + 0.01 Â Fi
i =1

Finally the adjusted object points are calculated by multiplying UOP by AF as follows:
OP = UOP × AF

1. Does the system require reliable backup and recovery?

2. Is data communication required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Figure 4.9 Adjustment factors.

EXAMPLE 4.9 Consider a project with the following data:

Internal class DET RET

C1 4 2
C2 5 7
C3 3 1
C4 2 1
External class DET RET
C5 6 10

The above classes contain six methods with high complexity and the complexities of the
adjustment factors are average. Compute object points.
146  Object-Oriented Software Engineering

Solution
ICtotal = 3 × 7 + 1 × 10 = 31
ECtotal = 1 × 7 = 7
Stotal = 6 × 6 = 36
UOP = ICtotal + ECtotal + Stotal
= 31 + 7 + 36 = 74
14
AF = 0.65 + 0.01 Â Fi
i =1

= 0.65 + 0.01 (14 × 3)

= 0.65 + 0.42 = 1.07
OP = UOP × AI
= 74 × 1.07
= 79.18

EXAMPLE 4.10 An application has the following data:

5 high internal classes, 2 average external classes and 6 average services. Assume the adjustment
factor as significant. What are the unadjusted object points and object points?
Solution
ICtotal = 5 × 15 = 75
ECtotal = 2 × 7 = 14
Stotal = 6 × 4 = 24
UOP = ICtotal + ECtotal + Stotal
= 75 + 14 + 24 = 113
14
AF = 0.65 + 0.01 Â Fi
i =1

= 0.65 + 0.01 (14×4)

= 0.65 + 0.56 = 1.21
OP = UOP × AI
= 113 × 1.21
= 136.73

4.6 Risk Management

Identifying and managing risks in the early phases of software development life cycle can
prevent software companies from facing major disasters. Risk is defined as the probability of
 Object-Oriented Software Estimation  147
some unexpected happening in the future, a situation that can cause unwanted results. Risk
management involves identifying and estimating the probability of risks with their order of
severity.

4.6.1 What is Risk?

Risk is defined as the combined effect of probability of occurrence of an undesirable event and
the impact of the occurrence of this event. Risk can delay the delivery of the software and over
budget a project. Risky projects may not also meet specified quality levels. The risk may be
defined as:
Risk = Probability of occurrence of an undesired event × Impact of occurrence of that event
There are various types of risks that may cause threat to the completion of a project. These
include technical risks, economical risks, deployment risks and environment risks. Technical
risks deal with the feasibility and understanding of the problem. Do we actually know the
problem? Is there any feasible solution to the problem? These risks must be analysed during the
start of the project life cycle. Economical risks involve budget, time, personnel and quality risks.
After identification, these threats require continuous monitoring. Deployment risks consist of
mishandling of the software, inadequate user training and ineffective maintenance activities. No
matter how much high quality software is produced it cannot run without environmental support.
The security and safety of the workplace is a very important issue that should be addressed. The
security issues involve catastrophic failures, unauthorized access and virus threats.
The risk may be rated according to urgency to address these risks. Initial identification of
threat potential must lead to effective planning and analysis of risks. Risks may be rated as
1. Urgent: Risks that would cause high loss to the business.
2. High: Risks that would prevent the delivery of the software.
3. Medium: Risk may affect the company from meeting a milestone.
4. Low: Routine risks with little or no impact.
It is important to classify risks so that they can be analysed and prioritized based on their
probabilities and impacts. Risks rated urgent should be addressed before the risks rated high, as
they cause huge loss to the organization. Similarly, high-rated risks are more severe than medium
rated-risks. Thus, the high-rated risks should be addressed before the medium-rated risks.

4.6.2 Framework for Managing Risks

Risk management is a key part of project planning activities and the specific risky areas are
highlighted in the plan. The project plan is expected to highlight both probability of failure
and impact of the failure and to describe the steps to be taken in order to reduce the risk. Risk
management consists of the following steps:
1. Risk identification
2. Risk analysis and prioritization
3. Risk avoidance and mitigation
4. Risk monitoring
148  Object-Oriented Software Engineering

Steps 1–3 are carried out iteratively in order to identify, analyse, prioritize and reduce risks.
The risks should be identified and appropriate plans must be made to reduce the high prioritized
risks. After reducing the high prioritized risks, the impact of reducing these risks should be
reanalysed and also risks that may have been introduced should be identified. For example, if a
new technology is introduced in order to resolve risk for delay in the schedule of the software.
However, the hiring of new experts might introduce new risks. After identifying new risks, the
risk reduction and removal activities may be planned again.

4.6.3 Risk Identification

In risk identification, we consider what unexpected can happen? More specifically, we are
looking for unusual events that may occur and prevent the delivery of the software on time,
with specified quality and within budget. Risk identification primarily involves brainstorming
activities and preparation of risk list.
Brainstorming is a group discussion technique in which stakeholders such as actual users,
developers and managers may be brought together. These group discussions may lead to
new ideas and promote creative thinking. Brainstorming sessions can be used to identify the
potential problems and the possible solutions to these problems. Preparation of risk lists involves
identification of generic risks that may have been found continuously in previous software
projects. The top 10 risk items are given by B.W. Boehm and are summarized in Table 4.18
(Boehm, 1989).

Table 4.18 Risk checklist

S. No. Risks Risk reduction strategies
1 Short of personnel  Hiring top professionals
 Teamwork
2 Unrealistic cost and time estimates  Use of more than one estimation technique
 Analysis of historical data from past projects
 Incremental methods
 Standardization of methods
3 Software developed with incorrect  Prototyping
functions Construction of early user manuals
 Early user feedback
4 Software developed with incorrect  Prototyping
user interface  Continuous user involvement
5 Gold plating of requirements  Identify important requirements
 Prototyping
 Incremental development
6 Requirements are changed late in  Stringent change central processes
software development life cycle  Incremental software development
7 Shortfalls in externally purchased  Conduct of verification activities such as
components walkthroughs and inspections
 Quality assurance and management activities
 Certifications
(Contd.)
 Object-Oriented Software Estimation  149
Table 4.18 Risk checklist (Contd.)
S. No. Risks Risk reduction strategies
8 Shortfalls in externally performed  Quality assurance activities
activities  Prototyping
9 Shortfalls in real-time performance  Prototyping
 Simulation
 Benchmarking
 Technical analysis
10 Technical difficulty in development  Training of person
 Technical analysis
 Hiring of experts

The stakeholders must go through the risk checklist given in Table 4.18 and identify the
risks specific to their project.

4.6.4 Risk Analysis and Prioritization

There may be many risky areas in the project. These risks should be addressed according to
their priority. Risk analysis and prioritization is a process consisting of the following steps:
1. Identifying the problems.
2. Assigning probability of occurrence value.
3. Assigning impact of occurrence value.
4. Assigning values obtained in steps 2 and 3 on a scale of 1 (low) to 10 (high).
5. Calculating risk exposure factor which is the product of probability of occurrence of a
problem and impact of the problem on software operation.
6. Risks are ranked on the basis of the value of risk exposure.
7. A risk table (shown in Table 4.19) is prepared.

Table 4.19 Table for risk analysis

S. No. Problem Probability of Impact of Risk Priority
occurrence of a problem the problem exposure
R1
R2
R3

On the basis of the case study on “Library Management System” given in Chapter 3, the
potential problems are identified. The risk exposure factor is calculated for each potential
problem which is the multiplication of probability of occurrence of the problem and impact
of that problem on software operation. The risk analysis and prioritization table is given in
Table 4.20.
150  Object-Oriented Software Engineering

Table 4.20 Risk analysis table for library management system

S. No. Problem Probability of Impact of the Risk Priority
occurrence of a problem problem exposure
R1 Issue of incorrect password 2 2 4 10
R2 Incorrect entry in book details 8 2 16 4
form
R3 Incorrect user interface of student 7 3 21 1
details form
R4 Coding takes longer than expected 4 5 20 2
R5 Lack of expertise causes delay in 1 10 10 6
the project
R6 Testing reveals lots of defects 1 9 9 7
R7 Design is not robust 2 7 14 5
R8 Documentation is in improper 4 2 8 8
format
R9 Changes in requirements during 2 9 18 3
implementation
R10 Requirements specification takes 7 1 7 9
longer than expected

The potential problems ranked by the risk exposure factor are R3, R4, R9, R2, R7, R5, R6, R8,
R10, R1. A risk matrix may be used to capture the potential risks. The probability of problem
and impact of problem values may be classified as urgent, high, medium, and low based on their
rankings. Tables 4.21 and 4.22 show the probability of occurrence of the problem and impact
with their corresponding types of risks, respectively. The values obtained on the scale of 1–10
are changed on the scale of 0 to 1.

Table 4.21 Probability type

Probability of Type
occurrence of problem
0.8–1 Urgent
0.6–0.7 High
0.3–0.6 Medium
0.0–0.3 Low

Table 4.22 Impact type

Probability of impact Type
0.5–1 Urgent
0.3–0.5 High
0.1–0.3 Medium
0.0–0.1 Low
 Object-Oriented Software Estimation  151
In Figure 4.10, the risk matrix for the LMS is shown. The values of probability and impact
are shown by their position of the risk in the matrix. The importance may be given either to
probability or to impact depending upon the needs of software under development.

Urgent R5, R6, R4

R9, R7
High R8 R3 R2
Medium R1 R10
Low
Low Medium High Urgent
Figure 4.10 Risk matrix.

Risk matrix is a popular tool for designing prioritization schemes. The probabilities of
estimates on the scale of 1–10 are required in order to construct a risk matrix. The probability
and impact values may be categorized as urgent, high, medium, and low. These two values are
essential for prioritizing risks. After the risks are ranked, the urgent and high priority risks
should be reduced first.

4.6.5 Risk Avoidance and Mitigation Strategies

The purpose of risk avoidance strategies is to altogether eliminate the occurrence of risks. One
possible way to avoid risks is to reduce the scope of the projects by removing unnecessary
requirements. When the number of requirements is reduced, the whole risk list will come down.
In mitigation strategies, plans are developed in order to reduce the impact of the risk
when it occurs. For example, to reduce the impact of risk that a component A will not perform
adequately, a set of tests may be used to ensure its proper functioning. If we want to reduce the
risk that a design tool will not create the design of the application effectively, its features will
be investigated before hand to ensure that the design is built successfully. Similarly, by taking
regular backups of the data, the impact of database corruption may be reduced.

4.6.6 Risk Monitoring

The risks should be monitored on continuous basis by reevaluating the risks, the probability of
occurrence of risks and the impact of the risk. This ensures that:
 The identified risks have been reduced or resolved.
 The new risks are discovered.
 The impact and magnitude of the risk are reassured.
The risk can be monitored by scheduling regular review meetings to evaluate risks. Some risks
may move down the risk list, some may be eliminated from the list and some new risks may be
identified and added to the list.
152  Object-Oriented Software Engineering

4.6.7 Estimating Risk Based on Schedule

If the activities of the project take longer than expected, they will most likely cause risk of delay in
the completion of the project. The importance of identifying critical path activities and uncertainties
is that these have high risk for causing delay in the projects. Critical path method (CPM) and
program evaluation review technique (PERT) are two well-known methods for identifying critical
activities and estimating uncertainties of meeting dates. Both of the techniques are used for
visualizing the projects where activities are represented as arrows joining circles or nodes.

Critical Path Method

The CPM shows the activities that are crucial to the end date of the project. In the CPM, arrows
represent activities that take time to execute and circles represent events. The events represented
by the circles are divided into four quadrants:
Event number: It shows the event number, i.e. the order in which the activities must be executed
in the project.
Earliest start date: The earliest date by which the event must occur.
Latest date: The latest date by which the event must occur.
Slack: Slack is a measure that calculates how much an activity may be delayed without
affecting the finish date of the project.
The node for the CPM chart is shown in Figure 4.11.

Figure 4.11 Node of CPM.

The estimated durations of activities given in Table 4.23 are used to illustrate the construction
of networks by the CPM.

Table 4.23 An example application

Activity Description Required predecessor Duration (months)
A Market research – 5
B Product analysis – 1
C Product design A 2
D Product model A 3
E Sales brochure A 2
(Contd.)
 Object-Oriented Software Estimation  153
Table 4.23 An example application (Contd.)
Activity Description Required predecessor Duration (months)
F Cost analysis C 3
G Implementation D 4
H Testing B, E 2
I Training H 1
J Project report F, G, I 1

Forward Pass
In the forward pass, the earliest date of the event is calculated. The forward pass of the example
given in Table 4.23 is shown in Figure 4.12. Using Figure 4.12 and Table 4.24, the forward pass
is carried out as follows:
1. Activities A and B may start immediately, so the earliest start date for both the events
is 0.
2. Activity A will take 5 months to complete, hence the earliest end date is 5 for this
activity.
3. Activity B will take 1 month to complete, hence the earliest end date is 1 for
activity B.
4. Activity C must begin after the completion of activity A, hence the earliest start date
for activity C is 5 months and the earliest end date is 7 months (duration of activity C is
2 months).
5. Activity D must also begin after the completion of activity A. The earliest start date is
5 months and the earliest end date is 8 months.
6. Similarly, the start date and the end date are calculated for all the other activities.

Figure 4.12 Forward pass.

154  Object-Oriented Software Engineering

Table 4.24 Table after forward pass

Activity Duration (months) Earliest start date Earliest end date
A 5 0 5
B 1 0 1
C 2 5 7
D 3 5 8
E 2 5 7
F 3 7 10
G 4 8 12
H 2 7 9
I 1 9 10
J 1 12 13

Backward Pass
Now, we follow the backward pass in order to compute the latest dates till when the project must
be started and finished without any delay in the project. Figure 4.13 and Table 4.25 show the
calculation of the latest date for each event of the project.

Figure 4.13 Backward pass.

The backward pass is carried out as follows:

1. The latest completion date for activity J is assumed to be 13 months.
2. Activity J must therefore latest start at 12 (13 –1) months and latest end at month 3.
3. The latest end dates for activities F, G and I are at 12 months at which activity J must
start. They have the latest start date months 9 (12 – 3), 8 (12 – 4) and 11 (12 – 1),
respectively.
4. Activity H must be started at 9 (11–2) month and completed by 11 month. Similarly
activity E must begin at month 7 and end at month 9. Activity E must begin at month 7
and end at month 9.
 Object-Oriented Software Estimation  155
5. Activities C and D must start at month 7 (9 – 2) and month 5 (8 – 3), respectively. They
must end at months 9 and 8, respectively.
6. Activity B must be completed by month 9 (the latest start date for activity H). Activity A
must finish at month 5 (the latest start date for activity D).
7. The latest start date for the project is zero.
The backward pass rule states that when there is more than one activity following an activity,
then we take the earliest of the latest start date for these activities. For example, there are three
activities C, D and E with latest start dates 7, 5 and 7, respectively. Thus, the latest finish date
for activity A is 5.

Table 4.25 Table after backward pass

Activity Duration (months) Earliest start date Earliest end date Latest start date Latest end date
A 5 0 5 0 5
B 1 0 1 8 9
C 2 5 7 7 9
D 3 5 8 5 8
E 2 5 7 7 9
F 3 7 10 9 12
G 4 8 12 8 12
H 2 7 9 9 11
I 1 9 10 11 12
J 1 12 13 12 13

Calculation of Slack and Identification of Critical Path

The slack of the events is calculated by computing the difference between the earliest date and
the end date. The critical path is identified as the path with the slack value equal to zero. The
critical path identifies those activities which are crucial and cannot be delayed. The final CPM
chart with activities having slack value zero shown in dotted lines is given in Figure 4.14.

Figure 4.14 Final pass.

156  Object-Oriented Software Engineering

After identifying the critical path, the activities with slack value zero are identified to be
risky and critical and are cause of concern.

EXAMPLE 4.11 Consider the description of a set of activities given below. Draw the CPM
chart and identify high risky activities.

Activity Description Required predecessor Duration (months)

A Feasibility study – 3
B Requirement analysis – 2
C Requirement specification – 4
D Cost analysis – 3
E Product design A, B 2
F System model E 4
G Implementation F 2
H Unit level test cases D 1
I Testing G, H 2
J Training C, I 4

Solution The forward pass is given in Figure 4.15 and the data is given in Table 4.26.

Figure 4.15 Forward pass.

Table 4.26 Table after forward pass

Activity Duration (months) Earliest start date Earliest end date
A 3 0 3
B 2 0 2
C 4 0 4
D 3 0 3

(Contd.)
 Object-Oriented Software Estimation  157
Table 4.26 Table after forward pass (Contd.)
Activity Duration (months) Earliest start date Earliest end date
E 2 3 5
F 4 5 9
G 2 9 11
H 1 3 4
I 2 11 13
J 4 13 17

The backward pass is shown in Figure 4.16 and the final data is given in Table 4.27.

Figure 4.16 Backward pass.

Table 4.27 Table after backward pass

Activity Duration (months) Earliest start date Earliest end date Latest start date Latest end date
A 3 0 3 0 3
B 2 0 2 1 3
C 4 0 4 9 13
D 3 0 3 7 10
E 2 3 5 3 5
F 4 5 9 5 9
G 2 9 11 9 11
H 1 3 4 10 11
I 2 11 13 11 13
J 4 13 17 13 17
158  Object-Oriented Software Engineering

The final CPM chart is shown in Figure 4.17. The critical path is A-E-F-G-I-J.

Figure 4.17 Final pass.

EXAMPLE 4.12 For a software project, consider the following information:

Activity No. Activity name Duration (weeks) Immediate predecessor

1 Obtain requirements 4 –
2 Determine operations 4 –
3 Identify and define subsystems 2 1
4 Develop database 4 1
5 Make decision analysis 3 2
6 Identify risks, assumptions, constraints 2 5
7 Build module A 8 3, 4, 6
8 Build module B 12 3, 4, 6
9 Build module C 18 3, 4, 6
10 Write report 10 6
11 Testing and integration 8 7, 8, 9
12 Deployment 2 10, 11

Draw the CPM chart. Find out the project completion time and the critical path.
Solution The forward pass of the above problem is shown in Figure 4.18 and the table for the
forward pass is shown in Table 4.28. The backward pass is shown in Figure 4.19 and the data for
the backward pass is given in Table 4.29.
 Object-Oriented Software Estimation  159

Figure 4.18 Forward pass.

Table 4.28 Table for forward pass

Activity Duration (months) Earliest start date Earliest end date
1 4 0 4
2 4 0 4
3 2 4 6
4 4 4 8
5 3 4 7
6 2 7 9
7 8 9 17
8 12 9 21
9 18 9 27
10 10 9 19
11 8 27 35
12 2 35 37

Figure 4.19 Backward pass.

160  Object-Oriented Software Engineering

Table 4.29 Table after backward pass

Activity Duration (months) Earliest start date Earliest end date Latest start date Latest end date
1 4 0 4 1 5
2 4 0 4 0 4
3 2 4 6 7 9
4 4 4 8 5 9
5 3 4 7 4 7
6 2 7 9 7 9
7 8 9 17 19 27
8 12 9 21 15 27
9 18 9 27 9 27
10 10 9 19 25 35
11 8 27 35 27 35
12 2 35 37 35 37

The final CPM chart is shown in Figure 4.20.

Figure 4.20 Final pass.

Program Evaluation Review Technique (PERT)

PERT can be used to measure the uncertainty in activity durations. The PERT was developed
for high-risk, expensive and large-sized project. Thus, the environment was similar of today’s
software project. The PERT is based on the CPM technique and requires the following
estimates:
1. Most likely time (m): The expected time taken by a project in ordinary conditions.
2. Optimistic time (a): The expected shortest time taken by a project.
3. Pessimistic time (b): The worst possible time that a project may take.
 Object-Oriented Software Estimation  161
The PERT calculates the total estimated time by using the above three estimates as
a + 4m + b
t=
6
Table 4.30 shows the additional time estimates for project taken in Table 4.23.

Table 4.30 Table with time estimates

Activity Optimistic (a) Most likely (m) Pessimistic (b)
A 4 5 7
B 0.5 1 2
C 1 2 2
D 2 3 3
E 1 2 3
F 1 3 4
G 3 4 6
H 1 2 3
I 0.5 1 2
J 1 1 1.5

The nodes in the PERT network are divided into four quadrants as shown in Figure 4.21.

Figure 4.21 PERT node.

In the forward pass, we calculate the expected duration as shown in Figure 4.22. Table 4.31
shows the expected time of the project. Unlike the CPM technique, the PERT is based on the
expected date instead of the earliest date by which the project must be completed. Thus, the
PERT deals with the uncertainties involved in durations. The three estimators put emphasis on
the fact that we are uncertain about the future happenings and thus the approximate estimate of
the durations is taken.
162  Object-Oriented Software Engineering

Figure 4.22 First pass of PERT.

Table 4.31 Expected time and standard deviation for PERT

Activity a m b t SD
A 4 5 7 5.17 0.5
B 0.5 1 2 1.08 0.25
C 1 2 2 1.83 0.17
D 2 3 3 2.83 0.17
E 1 2 3 2 0.33
F 1 3 4 2.83 0.5
G 3 4 6 4.17 0.5
H 1 2 3 2 0.33
I 0.5 1 2 1.08 0.25
J 1 1 1.5 1.08 0.08

The degree of uncertainty can be measured by the calculation of standard deviation (SD)
which is calculated by using the following formula:
b-a
SD =
6
The SD is proportional to the difference between pessimistic and optimistic activity durations.
This measure can be used to rank the activities by calculating the probability of uncertainty of
meeting the target date. Figure 4.23 shows the SD of the project. Two standard deviations cannot
be added; thus, they are calculated as follows:

(SD1 )2 + (SD2 )2
 Object-Oriented Software Estimation  163
The SD for event 2 is 0.5 as it depends only on activity 1. For event 3, there are two
possibilities (A + E or B). Thus, the total SD is given by

(0.5)2 + (0.33)2 = 0.25 + 0.1089 = 0.6

Similarly, the SD for each of the events is calculated.

Figure 4.23 Standard deviation.

The PERT uses the following steps to compute the probability of meeting the target durations:
 Calculate the Z value for each event corresponding to its target date.
 Convert the Z values to probabilities of meeting or missing the targets.
The Z value for each event is calculated by using the following formula:
TT - t
Z =
SD
where TT is target time.
If we want to complete the event 5 in 9 months, the Z value for event 5 is:
9-8
Z = = 1.886
0.53
By seeing the table of normal distribution, we conclude that there is 0.89 probability of meeting
the target date. Thus, there is 11% risk of not meeting the target date at the end of month 9.
After calculating the probabilities of meeting the target dates, we can rank the risk by their risk
percentage. Using these rankings, we can find out which activity is more uncertain and a cause
of concern.
EXAMPLE 4.13 For the following software project, draw the PERT chart and identify the
critical path.
164  Object-Oriented Software Engineering

Activity Task description Prerequisites Optimistic Most likely Pessimistic

duration duration duration
1 Identify stakeholders’ needs – 1 2 3
and construct plans
2 Cost–benefit analysis – 2 3 4
3 Construct module A 1 1 2 3
4 Construct module B 2 2 4 6
5 Construct module C 3 1 4 7
6 Testing 3 1 2 9
7 Integration 4, 5 3 4 11
8 Deployment 6, 7 1 2 3

Solution The PERT chart and its corresponding table are given in Figure 4.24 and Table 4.32,
respectively.

Figure 4.24 PERT chart.

Table 4.32 Expected time and standard deviation for PERT

Activity a m b t SD
1 1 2 3 2 0.33
2 2 3 4 3 0.33
3 1 2 3 2 0.33
4 2 4 6 4 0.66
5 1 4 7 4 1
6 1 2 9 3 1.33
7 3 4 11 5 1.33
8 1 2 3 2 0.33
 Object-Oriented Software Estimation  165
EXAMPLE 4.14 Consider the following data concerning the activities in a project (in weeks):

Activity Immediate predecessor a m b

A – 2 4 6
B – 6 8 10
C A 1 5 15
D C 1 5 9
E B 6 8 10

(a) Using the PERT, compute the expected time and the standard deviation required to
complete each activity.
(b) Draw a network diagram and find the critical path. What is the expected length of the
critical path?
(c) Assuming that the normal distribution applies, compute the probability that path A-C-D
will be completed in at most 16 days.
(d) How much time must be allowed to achieve a 95% confidence of timely completion?
Solution The PERT chart and its corresponding table are given in Figure 4.25 and Table 4.33,
respectively.

Figure 4.25 PERT chart.

Table 4.33 Expected time and standard deviation for PERT

Activity a m b t SD
A 2 4 6 4 0.66
B 6 8 10 8 0.66
C 1 5 15 6 2.33
D 1 5 9 5 1.33
E 6 8 10 8 0.66
166  Object-Oriented Software Engineering

(a) Expected time = 16, SD = 2.76

(b) Critical path B, E
TT - t 16 - 15
(c) Z = = = 0.3623
SD 2.76
Risk = 0%
(d) To achieve 95% confidence, risk factor = 5%
TT - t
Z =
SD
TT - 16
= 1.75
2.76
TT = 2.76 ¥ 1.75 + 16 = 20.83

Review Questions
1. What is the need for object-oriented software estimation techniques?
2. Describe any two object-oriented size estimation techniques.
3. An application consists of 20 scenario scripts and requires 17 person days to implement.
Determine the effort of the given application.
4. Describe the steps in the use case points method to calculate effort. Why is the use case
points method becoming acceptable in the industry?
5. Compute the value of the use case points for a project with the following information
domain characteristics:
Number of actors: 3
Number of use case: 8
Assume all complexity factors to be average.
6. What metrics can be used to estimate the size of an object-oriented software product?
How is the use case points metric advantageous over the function point metric? Explain.
7. Describe the use case points method with a suitable example.
8. Describe the class point method in detail.
9. Explain the type of classes identified in the class point method. Identify the type of
classes for result management system.
10. What is the purpose of CP1 and CP2 measures? In which software development life
cycle phase can they be calculated?
 Object-Oriented Software Estimation  167
11. Consider a project with the following parameters:

Class type Number of classes NEM NSR NOA

PDT 3 6 2 4
4 5 5
10 15 3
5 7 2
HIT 5 7 10 1
5 8 7
8 12 8
6 9 4
2 4 5
4 2 3
DMT 4 2 3 2
1 0 2
3 4 4
TMT 3 4 8 1
8 12

Assume all the technical complexity factors have average influence. Calculate CP1, CP2
and effort using class point method.
12. Compare and contrast function point method and object-oriented function point method.
13. Explain all the element types that are used to count object-oriented concepts in the
object-oriented function point method.
14. Describe the steps for calculating object points.
15. Establish the relationship between function point method and object-oriented function
point method.
16. Discuss the method for calculating object-oriented concepts in object point method.
17. Assume that a project has five classes with DET and RET values given below:

Internal class DET RET

C1 4 2
C2 5 7
C3 3 1
C4 2 1
External class DET RET
C5 6 10

The above classes contain four methods with high complexity and the complexities of
the adjustments factors are average. Compute object points.
168  Object-Oriented Software Engineering

18. Consider the following class model. Determine DET and RET for each class.

19. Consider the example given in Question 18. Calculate unadjusted object points. Assume
all the services to be of average complexity.
20. What is risk? Describe the various risk ratings.
21. Describe the framework for managing risks.
22. What are the risk management activities? How can risks be prioritized?
23. Consider the result management system. Analyse and prioritize the various kinds of
risks associated with such a project.
24. Discuss the risk list given by Boehm.
25. What is risk exposure? Describe the method to prioritize risks.
26. Explain the steps in constructing a CPM network model with an example. Explain the
importance of critical path.
27. How can PERT be used in risk analysis? How can we identify uncertainties in activities
using the PERT chart?
28. Explain with examples the importance of PERT and CPM charts.
29. Draw the CPM network for the project specification given in the table below. Explain
each step of the network in detail. Identify the critical path.

Activity Duration (weeks) Precedent

A 8
B 4
C 6
D 8 A
E 3 C
F 2
G 4 C, E
H 5 B, F
 Object-Oriented Software Estimation  169
30. Draw the CPM network for the project specification given in the table below. Explain
each step of the network in detail. Show the critical path on your CPM chart. List the
tasks that are on the critical path.

Activity Activity name Duration (weeks) Immediate predecessor

1 Obtain requirements 4 –
2 Analyse operations 4 –
3 Define subsystems 2 1
4 Develop database 4 1
5 Make decision analysis 3 2
6 Identify constraints 2 5
7 Build module 1 8 3, 4, 6
8 Build module 2 12 3, 4, 6
9 Build module 3 18 3, 4, 6
10 Write report 10 6
11 Testing and integration 8 7, 8, 9
12 Implementation 2 10, 11

31. What do you mean by risks in software projects? How does risk management tackle
these risks? What procedure is usually followed?
32. What do you understand by a “critical path” in a project schedule? Bring out the
importance of software project estimation in the context of software project management.
33. How can PERT be used to evaluate the effects of uncertainty? Explain with an example.
34. Consider the following data for a given project. Draw the PERT chart using the given
information. For the due date 20, 24 and 25, calculate the percentage of risks.

Activity Predecessor Optimistic Most likely Pessimistic

A – 4 5 9
B – 3 6 15
C A 3 4 5
D A 2 7 9
E B, C 3 5 7
F D 6 8 13
G D, E 1 3 11

35. You are given the following data concerning the activities in a project (numbers refer to
weeks):
170  Object-Oriented Software Engineering

Activity Immediate predecessor aj mj bj

A – 5 7 15
B - 6 15 18
C A 6 10 14
D B, C 3 5 7
E B, C 4 12 14
F D 4 5 6

(a) Using the standard PERT approximation formulas, compute the expected time and
the variance required to complete each activity.
(b) Draw a network diagram and find the critical path by inspection. What is the
expected length of the critical path?
(c) Assuming that the normal distribution applies, compute the probability that the
critical path will take between 25 and 32 days to complete.
(d) How much time must be allowed to achieve a 95% confidence of timely completion?

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. After the requirements have been gathered, the customer may like to estimate:
(a) Cost (b) Coupling
(c) Inheritance (d) Polymorphism
2. In object-oriented systems, size can be estimated by:
(a) Use cases (b) Objects
(c) Classes (d) All of the above
3. Which one is not an object-oriented software estimation method?
(a) Use case point (b) Lorenz and Kidd
(c) Function point (d) Class point
4. The use case points method was developed by:
(a) B. Boehm (b) V. Basili
(c) G. Karner (d) A. Albrecht
5. Use case points can be calculated by:
(a) UUCP × TCF × ECF (b) UUCP × TCF
(c) UCP × H (d) UUCP × ECF
6. The use case points method is based on:
(a) Classes (b) Objects
(c) Scenarios (d) Use cases
7. The use case points method can be used in:
(a) Early phases (b) Later phases
(c) Effort estimation (d) Both (a) and (c)
 Object-Oriented Software Estimation  171
8. TCF stands for:
(a) Technological complexity factor (b) Technical complexity factor
(c) Technical class factor (d) Total complexity factor
9. The class point method was developed by:
(a) G. Karner (b) G. Costagliola
(c) B. Beizer (d) B. Boehm
10. The class point method involves identification of types of cases. How many types of
classes are identified?
(a) 3 (b) 2
(c) 4 (d) 5
11. In the class point method, how many measures can be calculated?
(a) 1 (b) 2
(c) 3 (d) 4
12. In the class point method, the number of technical complexity factors is:
(a) 10 (b) 14
(c) 20 (d) 18
13. In the calculation of CP1, which measures are used?
(a) NEM and NOA (b) NOA and NSR
(c) NEM and NSR (d) NEM, NSR and NOA
14. In the calculation of CP2, which measures are used?
(a) NEM and NOA (b) NOA and NSR
(c) NEM and NSR (d) NEM, NSR and NOA
15. In the CP1:
(a) Initial estimate of size is made
(b) Detailed estimate of size is made
(c) The number of attributes is determined
(d) Both (a) and (c)
16. Object-oriented function point can be mapped to:
(a) Use case points method (b) COCOMO model
(c) Putnam resource allocation model (d) Function point method
17. In services, which measures are calculated?
(a) DET and RET (b) DET
(c) RET and FTR (d) DET and FTR
18. In the object point method, external classes can be mapped to _____ in the function
point method.
(a) External interface files (b) External inquiries
(c) External outputs (d) External inputs
19. A DET is counted for:
(a) Simple attributes (b) Class
(c) Method (d) Method argument
172  Object-Oriented Software Engineering

20. In the object-oriented function point, the number of complexity adjustment factors is:
(a) 15 (b) 18
(c) 14 (d) 20
21. Risk is defined as:
(a) Probability × priority (b) Probability × size
(c) Priority × size (d) Probability × impact
22. Which one of the following is not a risk management activity?
(a) Risk identification (b) Risk activation
(c) Risk prioritization (d) Risk monitoring
23. Risk mitigation activities include:
(a) Reducing probability of risk (b) Increasing probability of risk
(c) Reducing impact of risk (d) None of the above
24. CPM stands for:
(a) Critical path methodology (b) Cost path method
(c) Crucial path method (d) Critical path method
25. The events in the CPM are divided into four quadrants. These quadrants present:
(a) Event number, standard deviation, latest date, slack
(b) Event number, earliest date, latest date, slack
(c) Event number, estimated time, latest date, slack
(d) Event number, earliest time, estimated date, slack
26. Forward pass in CPM includes the calculation of:
(a) Earliest date (b) Latest date
(c) Estimated date (d) Standard deviation
27. Backward pass in CPM includes the calculation of:
(a) Earliest date (b) Latest date
(c) Estimated date (d) Standard deviation
28. Critical path in CPM consists of events with:
(a) Slack > 1 (b) Slack > 2
(c) Slack = 0 (d) Slack > 20
29. PERT stands for:
(a) Program estimation review technique
(b) Program estimation resource technique
(c) Program evaluation review technique
(d) Process evaluation review technique
30. Z values can be connected to probabilities using:
(a) Normal distribution (b) T-test
(c) F-test (d) Z-score distribution
 Object-Oriented Software Estimation  173

Further Reading
The report by David N. Card focuses on object-oriented software measurement which can be
found in:
Card, D., Emam, K. and Scalzo, B., Measurement of Object-oriented Software Development
Projects, http://sern.ucalgary.ca/courses/SENG/693/F00/readings/OO%20Measurement %20
-%20March%202001.pdf, 2001.
The following research papers provide a framework on estimating use case points:
Banerjee, G., Use Case Points: An Estimation Approach, http://www.bfpug.com.br/Artigos/
UCP/Banerjee-UCP_An_Estimation_Approach.pdf, 2001
Roy, K. Clemmons, Project estimation with use case points. CROSSTALK The Journal of
Defense Software Engineering, February 2006.
Ferens, D., Fischman, L., Fitzpatrick, T., Galorath, D., and Tarbet, D., Automated Software
Project Size Estimation via Use Case Points. El Segundo: Galorath Incorporated, 2002.
A detailed explanation of use case point method with example case study may be obtained from:
Kirsten, R., Estimating Object-Oriented Software Projects with Use Cases. Master of Science,
Thesis 7th November 2001.
Other useful research papers may be:
Minkiewicz, A., Measuring object-oriented software with predictive object points. Proc.
ASM’97—Applications in Software Measurement, Atlanta, 1997.
Moser, S., Measure and Estimation of Software and Software Processes. PhD Thesis, University
of Berne, Switzerland, 1996.
Antoniol, G., Lokan, C., Caldiera, G., and Fiutem, R., A function point-like measure for object-
oriented software. Empirical Software Engineering, 4(3): 263–287, 1999.
An excellent tutorial on risk management is given by Boehm in:
Boehm, B., IEEE Tutorial on Software Risk Management. New York: IEEE Computer Society
Press, 1989.
Chapter 6 of the book by Galorath and Evans discusses the measures for estimating object-
oriented projects:
Galorath, D.D. and Evans, M.W., Software Sizing, Estimation, and Risk Management.
Philadelphia, PA: Auerbach Publications, 2006.
Hughes and Cotterell provide an introduction to risk management in Chapter 7 of the book:
Hughes, B. and Cotterell, M., Software Project Management. New Delhi: Tata-McGraw Hill,
2009.