Decomposition Techniques, Estimation â€“ Tools

<< Estimation - Concepts

Estimation â€“ Tools >>

Software Project Management (CS615)

LECTURE # 30

6. ESTIMATION

6.3

Decomposition Techniques

Software project estimation is a form of problem solving, and in most cases, the

problem to be solved (i.e., developing a cost and effort estimate for a software

project) is too complex to be considered in one piece. For this reason, we

decompose the problem, re-characterizing it as a set of smaller (and hopefully,

more manageable) problems.

Before an estimate can be made, the project planner must understand the scope of

the software to be built and generate an estimate of its "size."

6.3.1

Software Sizing

The accuracy of a software project estimate is predicated on a number of things:

(1) The degree to which the planner has properly estimated the size of the product

to be built

(2) The ability to translate the size estimate into human effort, calendar time, and

dollars (a function of the availability of reliable software metrics from past

projects)

(3) The degree to which the project plan reflects the abilities of the software team

(4) The stability of product requirements and the environment that supports the

software engineering effort.

As project estimate is only as good as the estimate of the size of the work to be

accomplished, sizing 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.

There are four different approaches to the sizing problem:

1. "Fuzzy logic" sizing: This approach uses the approximate reasoning

techniques that are the cornerstone of fuzzy logic. To apply this approach, the

planner must identify the type of application, establish its magnitude on a

qualitative scale, and then refine the magnitude within the original range.

Although personal experience can be used, the planner should also have

226

Software Project Management (CS615)

access to a historical database of projects8 so that estimates can be com- pared

to actual experience.

2. Function point sizing: The planner develops estimates of the information

domain. Its characteristics will be discussed later in the session.

3. Standard component sizing: Software is composed of a number of different

"standard components" that are generic to a particular application area. For

example, the standard components for an information system are subsystems,

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.

4. 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, changing

code, and 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.

6.4

Estimation Tools

Work Breakdown Structure (WBS)

a) Dividing into Logical Units/Tasks

To correctly estimate the effort, size, or cost of completing a project, it is

important to be aware of the multiple tasks that comprise a project. You can

divide a project into logical units or tasks by using the WBS technique.

Creating a WBS is a prerequisite for any estimation activity. It enables you to

conceptualize an abstract entity, such as a project, into distinct, independent units.

After dividing a project into tasks, you can categorize them as logical, broad

tasks. For example, tasks, such as drawing up a marketing strategy, planning a

phase-wise product release, and interacting with media agencies and the

production department can be compiled under a common category, Marketing.

b) Benefits of Using a WBS

227

Software Project Management (CS615)

Using a WBS provides a number of benefits to the management and to the

development teams.

First, it gives the management an idea about the size and complexity of the

project.

Second, it helps in planning, scheduling, and monitoring a project realistically.

This is possible because all the tasks in the project can be preformed measurable

targets for each task.

To aid planning, scheduling, and monitoring a project, you can use tools such as:

Program Evaluation and Review Techniques (PERT)

Critical Path Method (CPM)

Timeline charts

Gantt charts

These tools use WBS as the fundamental basis for assessing resources to tasks,

computing the number of days needed, and the cost required to complete the

tasks.

ii.

Measuring Effort for a Project

Measuring the effort for a project is a specialized activity. It enables you to derive

cost estimates that are critical for project management. An incorrect measurement

of effort at the beginning of project can result in inaccurate project plans and

frequent slippages. It can also lead to inaccurate cost estimates, which can cause

steep cost deviations between estimated and actual cost values.

There are many techniques that you can use to accurately estimate effort, such as:

a) Source lines of Code (SLOC)

b) Function Point (FP)

c) Constructive Cost Model (COCOMO)

These are quantitative estimation techniques because they rely on the use of

formulae to calculate effort.

In addition to quantitative estimation techniques, there is a human-based

technique known as:

d) Delphi technique

This technique is based on soft skills and relies more on human factors, such as

collecting information during group discussions.

228

Software Project Management (CS615)

a) SLOC- Technique

At the beginning of a software project, it is important to determine the size of the

project. The project size helps determine the resources, effort, and duration of the

project.

There are many techniques to calculate the size of a software project. You can

calculate the size by using a directly measurable technique, the SLOC technique.

It is defined as the source lines of code that are delivered as part of the product.

The effort spent on creating the source lines of code is expressed in relation to

thousand lines of code (KLOC).

The SLOC technique is an objective method of estimating the size because there

are no multiple ways of calculating the lines of code. Therefore, the effort

estimate is close to being accurate.

This technique includes the calculation of lines of code, documentation of pages,

inputs, outputs, and components of a software program. Components are again of

multiple types, such as reports, screens, and files.

The SLOC technique is also used to directly calculate the effort to be spent on a

project.

Following figure is a simple example of counting source lines of code. The code

displayed here contains four lines of code.

If (emp_code<=1200)

Print ("Welcome to the Inventory database.");

Else

Print ("Access denied to the Inventory databases.");

Counting SLOC

You can use the SLOC technique to estimate the effort required for a project

when the programming language and the technology to be used are predefined. In

addition to the programming language and technology, the complexity and effort

required to write a program should be easily predictable.

The use of the SLOC technique requires that the technology or language remain

unchanged throughout the project. Generally, you can use the SLOC technique

when you are using third-generation languages, such as FORTRAN or COBOL.

While counting the source lines of code, there are some general considerations

that you need to keep in mind. However, these can vary in every organization.

229

Software Project Management (CS615)

The general considerations include the following:

Only the delivered lines of code are included in SLOC calculation. For

example, test drivers and other support software are not part of the number of

lines developed for a project.

Only the source lines of code written only by the development team as

counted. This excludes the code created by applications generators.

Only declaration statements are counted as source lines of code. This

excludes comments inserted to improve the readability of programs.

Disadvantages of Using SLOC

Despite being accurate in providing figures to calculate the effort required for a

project, the SLOC technique has a drawback.

The SLOC technique is language-dependent. The effort required to calculate

source lines of code may not be the same for all languages.

For example, to conceive and write 8 lines of code that accomplish a task in the

assembly language may require 15 minutes. However, you may need only five

minutes to complete the same lines of code if it is written in Visual Basic.

b) FP Technique

The FP technique is a direct indicator of the functionality of a software

application from the user's perspective. This is the most popular technique used to

estimate the size of a software project.

This fact is further supported by a quote of Capers Jones, chairman of Software

Productivity Research, Inc. in Burlington, Massachusetts, on page 1 of Computer

Finance brought out in November 1997. He quotes "80% of the Fortune 500, are

using function points, at least somewhere in their application development

organizations".

You use the FP technique to estimate the total size of a project. The total size of a

project is estimated as a single FP value. After calculating the total size of a

project in FP, you divide the total FP into the different phases of the SDLC. This

way, you can determine how much effort per FP is required in that particular

phase.

For example, the testing phase is planned for 20 FP of work. The project

managers, based on their past project experience, determine the amount of effort

in man/person months required in the testing phase.

230

Software Project Management (CS615)

Similarly, you can express the cost required to complete FP of work for a

particular phase. At the end of a project, you can also express the number of

defects reported in terms of per FP for a phase.

Features of Function Points

The total size of a software project is expressed in total function points. It is

independent of the computer language, development methodology, technology, or

capability of the project team developing the software project.

The specific user functionality of the application is evaluated in terms of relation

to what is delivered by the application and, not how it is delivered. Only user-

requested and user-defined components are counted. To calculate FP for a project,

some major components are required.

The major components and their relationships are represented in following figure.

Function Points

Unadjusted Data Function

Unadjusted Transaction

Points

Function Points

Internal Files

External Interfaces

User Inputs

User Outputs

User Inquiries

Figure: Function Points Components and their Relationship

You can calculate the function point estimates for a project or a particular phase

by following four steps:

Identify the unadjusted function points.

Calculate total GSC s.

Calculate Value Adjustment Factor (VAF)

Apply a formula to calculate Adjusted FP (AFP)

231

Software Project Management (CS615)

Advantages of Using Function Points

Function points are language-and technology-independent. Therefore, you can use

them to estimate any kind of project. They can also be used to estimate the effort,

cost, and schedules of projects that use the Prototyping and Spiral models because

such projects have uncertain user and project requirements.

In addition, you can use function points as a project estimation technique when

you anticipate changes in the middle of a project. These changes may disturb the

estimates if, you had used SLOC to estimate the effort, cost, or size of a project.

The FP estimation uses a subjective and holistic approach for project estimation.

Consequently, the estimates calculated by using the FP are unlikely to be

incorrect.

Disadvantages of Using Function Points

Estimation by using FP generally uses data from past projects for assigning

weights to GSC s and the information domain values. To be able to do this

realistically, it is important for the organization to have developed similar projects

in the past.

The organization should also be prepared with adequate data and tools for FP

estimation of the new project.

In addition, FP provides a vague estimation. This characteristic of FP does not

usually provide precise or approximate estimates of the effort, cost and size of a

project.

Consequently, at the end of a project, deviations from the estimated to the actual,

values of each of the factors maybe quite extreme.

232

Table of Contents: