Effort Estimation for Object-Oriented Systems

In the process of software development, the technique of Object-Oriented Systems has emerged in recent years.

Consequently, many researchers have proposed several metrics suitable for measuring the size and the complexity of object-oriented software, assessing aid, or introducing new metrics that capture exclusive concepts of the object-oriented paradigm, such as inheritance cohesion and coupling. Traditional metrics, such as Function Points, are unsatisfactory for predicting software size because they are based on the procedural paradigm that separates data and functions, w'hile the object-oriented combines them.

Three dimensions were established in object-oriented software. The metrics of object-oriented systems must follow' these dimensions:

  • • Percentage of reuse through Inheritance.
  • • Amount of communication among objects.
  • • Functionality (behavior of objects).

Various object-oriented approaches are as follows:

UML-Based Approach

The second approach to effort estimation of CBSD (Component-Based System Development's Unified Modeling Language (UML) based on the object-oriented approach. In this approach the main characteristic is the use of case points.

Through the conception of object-oriented systems the software system can be described using visualization. UML is a technique developed based on this object- oriented approach. This is referred to as the de facto standard. The above-mentioned UML does not come under an architecture description language, but through UML diagrams the necessary data can be collected and used in size and complexity measurement of the software system. This language-based measurement can be very effective in the upstream level of software designing.

Use case points:

The use case point method was developed for performing effort estimation in the initial stage. Use case point (UCP) measurement can be done through use case modeling. The functional scope required for the development of a software system can be defined with the help of the use case model. This model is not related to the function point method and it depends purely on use case point. The advantages of this method for estimating effort in the initial stage has been explained in various articles.

Counting use case points: Within the flow of events, the number of transactions and actors involved will be counted along with a certain weight for measuring the UCP. When it is conducted among the target systems and actors, it is called a transaction. Within the use case model, the represented actor is defined as a simple, complex, or average. By means of a simple actor another system will be denoted as API. The interaction carried out with another system by means of TCP/IP protocol or the interaction carried out by the person utilizing a text-based interface will be referred to as an average actor. The interaction of the person will be attained through GUI interface in the case of complex actors.

The steps followed in the UCP method for estimating effort are represented as follows:

Step 1: (Counting the actor’s weight).

In the target software system, the number of actor types involved will be counted and this number of actor types will be the product with a weighting factor. The actor weighing factor is represented in Table 2.3. By summing these values the actor weight is measured (Somerville, 2001; Martin Shepperd et al. 1996).

Step 2: (Counting use case weight).

The categorization of every use case will be complex, average, or simple. The decision will be taken based on the number of transactions made in the use case. The alternative path is also included in this transaction. The definition of a transaction is that it is referred to as set of activities, it will be carried out as a whole or not. The

TABLE 2.3

Factors Related to Actor Weighting

Factor

Description

Type

3

Graphical interface

Complex

2

Interactive or protocol driven interface

Average

1

Program interface

Simple

use case which is referred to as extended or included is not taken into account. It was found that seven transactions will be seen as a case of complex use case, four to seven transactions will be seen as a case of average use case, and three or fewer transactions will be seen as a case of simple use case.

In the target software systems, the number of use case types involved will be counted and this number of actor types will be the product with a weighting factor. In Table 2.4 the actor weighing factor is represented. By summing these values the use case weight is measured

Step 3: (Calculating UUCP).

The total for Unadjusted Use Case Weight(UUCW) and total weight for actors, Unadjusted Actor Weight (UAW), will be summed to obtain Unadjusted Use Case Points (UUCP).

Step 4: (Weighting of environmental and technical factors).

On the basis of the value allocated for the number of environmental and technical factors, the obtained UUCP will be altered. The values for the number of environmental and technical factors is represented in Tables 2.5 and 2.6. By calculating the effect of the Ach factor in the application a value is allotted in the range of zero to five. It implies that if the rating is found to be five then the factor is necessary for the application, in cases of a rating of zero then it is determined to be irrelevant.

TABLE 2.4

Transaction-Based Weighting Factor

Factor

Description

Type

15

More than 7 transactions

Complex

10

4 to 7 transaction

Average

5

3 or fewer transaction

Simple

TABLE 2.5

Technical Factors Given for Weight and System

Weight

Description

Factor Number

1

Special user training facilities are required

T13

1

Provides direct access for third parties

T12

1

Includes special security features

Til

1

Concurrent

T10

1

Easy to change

T9

2

Portable

T8

0.5

Easy to use

T7

0.5

Easy to install

T6

1

Code must be reusable

T5

1

Complex internal processing

T4

1

End-user efficiency

T3

1

Response or throughput performance objectives

T2

2

Distributed System

Tl

The product of weight and the value of every factor represented in Table 2.5 (Tl- T3) will be made first to obtain the technical factor (TCF). The obtained value will be summed to determine the technical factor. The equation used for the technical factor is represented below:

The product of weight and value of every factor represented in Table 2.6 (F1-F8) will be made first, to obtain the environmental factor (EF). The obtained value will be summed to determine the E Factor. The equation used for the environmental factor is represented below:

Step 5: (Evaluating UCP).

Equation for finding the UCP is represented as follows:

Step 6: (Effort estimation).

Finally, the obtained UCP and specific values, which are represented in man-hours, will be multiplied to measure the estimation effort.

TABLE 2.6

Environmental Factors Represented for Weight and Team

Weight

Description

Factor

-1

Difficult programming language

F8

-1

Part time workers

F7

2

Stable requirements

F6

1

Motivation

F5

0.5

Lead analyst capability

F4

1

Object-oriented experience

F3

0.5

Application experience

F2

1.5

Familiar with the national unified process

FI

Example:

The utilization of a Restaurant Management System (RMS) will be made to perform the operation of UCP measurement. The generation of a Use Case Diagram for a particular software system is represented in Figure 2.1.

Use case diagram of Restaurant Management System

FIGURE 2.1 Use case diagram of Restaurant Management System.

Make the following assumptions for the components utilized in the use case diagram shown in the figure: one actor is of type simple as chef, one actor is of type average as chef and other two are "complex" as client and cashier. Order food, cook food, serve food and pay for food have ten transactions each - eat food has seven transactions - order wine, serve wine and pay for wine have three transactions each and drink wine has two transactions. Make the following assumptions for the system as a whole: Assigned Value for all the Technical Factors is two and for all eight Environmental Factors is three. Calculate the UUCP for utilizing the RMS. Also, calculate the total effort for developing the RMS if eighteen manhours per use case point is utilized.

Step 1: Unadjusted Actor Weight (UAW).

Evaluation performed for finding UAW is represented below:

Step 2: Unadjusted Use Case Weight (UUCW).

Use Case

No. of Transactions

(a)

Total No. of Transactions of Similar Type

(b)

Type

Factor

(c)

b x c

Drink wine

2

1

Simple

5

1x5 = 5

Eat food

7

4

Average

10

4 x 10 =

Oder wine

4

40

Pay for wine

4

Serve wine

4

Order food

10

4

Complex

15

15 x4 =

Cook food

10

60

Serve food

10

Pay for food UUCW

10

105

Step 3: Unadjusted Use Case Point (UUCP) = UUAW + UAW.

Step 4: Technical Complexity Factor (TCF).

Given that the assigned value to each technical factor is 2, therefore:

T. Factor

No. ofTF of Similar Type (a)

Weight

(b)

Assigned Value (c)

a x b x c

Т1 and Т8

2

2.0

2

2 x 2 x 2.0 = 8.0

Т2-Т5. T9-TI3

9

1.0

2

9 x 2 x 1.0= 18.0

Тб and Т7

2

0.5

2

2 x 2 x 0.5 = 2.0

TF

28.0

ENVIRONMENTAL COMPLEXITY FACTOR (ECF)

Given that the assigned value for each environmental complexity factor is 3:

E. Factor

No. ofTF of similar Type

(a)

Weight

(b)

Assigned Value (c)

a X b X c

FI

1

1.5

3

3 x 1 x 1.5 =4.5

F2 and F4

2

0.5

3

3 x 2 x 0.5 = 3.0

F3 and F5

2

1

3

3 x 2 x 1 = 6

F6

1

2

3

3 x1x 2 = 6

F7 and F8

2

-1

3

3 x 2 x -1 = -6

EF

13.5

Step 5: Use Case Points (UCP).

The evaluation of Use Case Points (UCP) can be performed with the following formula:

For the RMS,

In the case of the RMS the overall estimated size necessary for developing software is found to be 99.81 use case points. On knowing the size of the project the

effort of the project as whole can be determined.

Step 6: Estimating Effort.

Given that man-hours per use case point is 18

Estimated Effort = 1797 hours (approx.)

 
Source
< Prev   CONTENTS   Source   Next >