# CS615 - Software Project Management - Lecture Handout 30

User Rating:  / 0
PoorBest

# ESTIMATION

## 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."

## 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 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.

## Estimation – Tools

### Work Breakdown Structure (WBS)

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.

### Benefits of Using a WBS

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.

### 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:

1. Source lines of Code (SLOC)
2. Function Point (FP)
3. 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:

### Delphi technique

This technique is based on soft skills and relies more on human factors, such as collecting information during group discussions.

### 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

### 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.

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.

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.

### 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.

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 userrequested 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.

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:

1. Identify the unadjusted function points.
2. Calculate total GSC s.
3. Calculate Value Adjustment Factor (VAF)
4. Apply a formula to calculate Adjusted FP (AFP)

### 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.