SENG380:Software Process and Management

Software Size and Effort Estimation

Part 1

1

2

Software EstimationWhat is a successful project?

Targets are set for a project and the project manager tries to meet them.A project manager has to produce:

– An estimate of the effort.– An estimate of the activity durations.

– An estimate of effort affects costs

– An estimate of activity durations affects the delivery time

3

Difficulties of EstimationSome estimation difficulties include:• Nature of software.

– Complexity and invisibility of software.

• Subjective nature of estimating.– Over-estimating small tasks and– Under-estimating large ones.

• Political implications.– Different objectives of people in an organization.

– Project managers could:

– Increase cost and time estimates to create a comfort zone.– Decrease cost estimates to get approval on projects from higher

management.

4

Difficulties of EstimationSome estimation difficulties include (cont'd):• Changing technology.

– Technology is rapidly changing, making the experience of previous project estimates difficult to use in new ones.

• Lack of homogeneity of project experience.

– Even where technologies haven't been changed,– Other differences between projects:

– Could make the knowledge about task durations for instance not easy to transfer or mimic from one project to another.

– Example: using existing project data for estimating another similar project activity durations could be difficult because of the uncertainties in the way that various terms can be interpreted.

– e.g. the term testing.

5

Where are estimates done?Estimates are carried out at different stages of a software project for a variety of reasons.• Feasibility study.

● Estimates here conforms that the benefits of the potential system will justify the costs

• Strategic planning.● Project portfolio management will involve:

– Estimating benefits and costs of new applications (projects) to allocate priorities.

– Such estimates may also influence the scale of development staff recruitment.

6

Where are estimates done?Estimates at different stages of a software project (cont'd).• System specification.

● Design shows how user requirements will be fulfilled.● Estimating The efforts needed to implement different

design proposals.● Estimates at the design stage will also confirm that the

feasibility study is still valid.

7

Where are estimates done?Estimates at different stages (cont'd).• Evaluation of suppliers proposals.

● A manager could consider putting development to tender.● Potential contractors would examine the system

specifications and produce estimates (their bid).● The manager can still produce his own estimates why?

– To question a bid that for instance that seems too low which could be an indication of a bad understanding of the system specifications.

– Or to compare the bids to in-house development.

8

Where are estimates done?Estimates at different stages (cont'd).• Project planning.

● As the planning and implementation of the project becomes more detailed,– More estimates of smaller work components will be

made.● These will confirm earlier broad estimates.● And support more detailed planning (e.g. staff

allocation)As the project proceeds, the accuracy of your estimates improves because knowledge about the project increases.

9

Software Estimation in the Step Wise Framework

● High level estimates

● At step 3 “Analyze project characteristics”.

● And for each individual activity in step 5 “ Estimate effort for each activity”.

● As steps 5-8 are repeated at lower levels, estimates will be done at finer degree of detail.

10

Over and Under Estimation• Over-estimating a project can cause it to take longer than it

would otherwise.

This can be explained by the application of two laws:

Parkinson’s Law: “work expands to fill the time available”. Thus, e.g. for an easy task over estimating the duration

required to complete it will cause some staff to work less hard to fill the time.

Brooks Law: ”putting more people on a late job makes it later”.

So overestimating the effort required to perform a task (activity) means more staff assigned to it than needed.

Which leads to increasing the managerial overheads.

11

Over and Under EstimationUnderestimating a project:

– Can cause the project to not be delivered– on time– or cost

– but still could be delivered faster than a more generous estimate.

– On the other side the danger of underestimating a project is the effect on the Quality.

– How could staff with less experience respond to pressing deadlines?

● Producing work that is substandard.

– Zeroth law of reliability: “if a system doesn't have to be reliable it can meet any other objective”

12

● Substandard work might only become visible:

● at the later stages of the project “Testing”.● extensive rework at later stages, can easily delay project

completion.

● How do you think agile methods such as XP address such a problem “substandard work not being apparent until late in the project”?

● Testing is done as an integral part of the design/code process

● Testing is not put off as a task to be done by another group “e.g. system testing group” at a later task.

13

Basis for Software EstimatingA) The need for historical data.

– Most estimating methods need information about past projects.

– Care has to be considered when applying past performance to new projects because of possible differences in factors such as:

• Different programming languages.

• Different experience of staff.

• Different terminology.• There are international DBs containing data about thousands of

projects that can be used as reference (e.g. ISBSG the international software benchmarking standards group)

•

14

Basis for Software Estimating (cont’d)B) Measuring work.

The time and cost to implement software depends on:– The developer’s capability and experience.– The technology that will be used.

The usual practice is to start by expressing work size independently of the effort, using measures such as:(a)SLOC OR KLOC: Source lines of code or thousands of lines of

code.– SLOC may not be relevant when parameter-driven

application builders are used.– It doesn't take account of the complexity of the code

produced.(b)Alternative size measure is Function Points (FP).

15

Software Effort Estimation Techniques

Barry Bohem in 1981 identified main ways of deriving estimates of SW development efforts, some include:

● Expert judgment.

– Estimate based on the advice of knowledgeable staff.

● Analogy estimation.– Identify a completed similar project.– Use its actual effort as the basis of the estimate for

the new project.

16

Software Effort Estimation Techniques

● Top-down estimation.– The overall estimate of the whole project is:

➔ Broken down into effort required for component tasks.

● Bottom-up estimation.– Tasks or activities are identified and sized and then

➔ these individual estimated are then aggregated

17

Bottom-up Estimation• In this approach the estimator breaks the system into component

tasks.• The breaking down process is iterative.• Each task is decomposed into its component sub-tasks

➢ The 'top-down' approach is an essential predecessor to bottom-up estimating.

• “The bottom-up” part comes in adding up the calculated effort for each activity to get an overall estimate.

• The bottom-up approach is best at the later more detailed, stages of project planning. If this method is used earlier:

– Assumptions will have to be made about the characteristics of the system and project work methods.

18

Bottom-up Estimation (cont’d) A procedural code-oriented approach

One of the software development activities is:➔ “writing code”.

Using the bottom-up approach at the level of software components:(a)Envisage the number and type of the software modules in the

system. e.g. an Information System may contain the following modules:

➔ ADD➔ DELETE➔ DISPLAY

(b)Estimate the SLOC of each identified module.– By drawing up a program structure diagram or– The estimator may look at existing programs which have a similar

functional description.

19

A procedural code-oriented approach(cont'd)

(c) Estimate the work content taking into consideration the

complexity and technical difficulties. The estimator will specify a factor for complexity and

technical difficulty. The SLOC is multiplied by this factor.

The result is refereed to as the weighted SLOC.

(d)Calculate the work days effort. Historical data can be used to convert the weighted SLOC to

effort.

20

Top-down Estimation• It is associated with parametric or algorithmic models.• A formula for a parametric model:

Effort = (System Size) × (Productivity Rate)

The model of forecasting the SW development effort has two components:

➢ System size is a method of assessing the amount of work.

➢ Productivity rate is a method of assessing the rate of work at which the task can be done.

21

Top-down Estimation

Example:

System Size = 3 KLOC.

Productivity Rate = 40 days per KLOC.

Effort = (System Size) × (Productivity Rate)

Effort = 3 * 40 =120 Days.

System Size is a size driver.

Productivity Rate is a productivity driver.

22

Top-down Estimation (cont’d)

Other parametric models: Function points is concerned more with task sizes. COCOMO is concerned more with productivity rate.

23

Estimation by Analogy• It is also called case-based reasoning.• For a new project the estimator identifies the previous

completed projects that have similar characteristics to it.• The new project is referred to as the target project or target

case.• The completed projects are referred to as the source projects or

source cases.• The effort recorded for the matching source case is used as the

base estimate for the target project.• The estimator calculates an estimate for the new project by

adjusting the (base estimate) based on the differences that exist between the two projects.

24

Estimation by Analogy (cont’d)

• There are software tools that automate this process by

selecting the nearest project cases to the new project.

• Some software tools perform that by measuring the

● Euclidean distance between cases (projects).

• The Euclidean distance is calculated as follows:

distance= square-root of ((target_parameter1- source_parameter

1)2 +…

(target_parameter n- source_parameter

n)2 )

25

Estimation by Analogy Example• Assume that cases are matched on the basis of two

parameters, the number of inputs and the number of outputs.• The new project (target case) requires 7 inputs and 15

outputs.• You are looking into two past cases (source cases) to find a

better analogy with the target project:• Project A: has 8 inputs and 17 outputs.• Project B: has 5 inputs and 10 outputs.Which is a more closer match for the new project A or project B?• Distance between new project and project A: • Square-root of ((7-8) 2 + (15-17) 2)= 2.24• Distance between new project and project B:• Square-root of ((7-5) 2 + (15-10) 2)= 5.39

• Project A is a better match because it has less distance than project B to the new project. What will be the base estimate for the new project?

26

Albrecht Function Point Analysis

• FP is A top-down method.

• Devised by Allan Albrecht during his work for IBM.

Why FP?

• To be able to quantify the functional size of programs

independently of the programming language used.

27

Albrecht Function Point Analysis (cont’d)

The basis of FP analysis is that: An Information System consists of five major components or external user types or functions) that are of benefit to the user.

• Transaction functions:– External input types

– Input transactions that update internal computer files.– External output types

– Are transactions where data is output to the user (printed reports).

– External inquiry types– Are transactions initiated by the user which provide information

but not update the internal files.– The user inputs some information that directs the system to the

details required (screen displays).

28

Albrecht Function Point Analysis (cont’d)

Data functions:– Logical internal file types

– The standing files used by the system.– File here refers to a group of data items accessed together.– It may be made up of one or more record types.

– External interface file types– Allow for output and input that may pass to and from other

computer systems.– Files shared between applications would also be counted here.

29

Albrecht Function Point Analysis (cont’d)The FP approach:1. Identify each external user type in your application.2. Determine the complexity of each user type (high, average or

low).3. FP score for of each external user type = Multiply the weight

of each complexity by the count of each external user type that has that complexity.

4. FP count = summation of all the FP scores.

FP count indicates the size of the information processing.

30

User Type Complexity

● For the original function points defined by Albrecht, the complexity of the components (external user types) was intuitively decided.

● Now there is a group called (IFPUG) international FP user group have put rules governing the complexity and how it is assessed.

● The Albrecht FP is often refereed to as the IFPUG FP method.

31

IFPUG File Type Complexity

External user type

Low Average High

External input types

3 4 6

External output types

4 5 7

External inquiry types

3 4 6

Logical internal file types

7 10 15

External interface file types

5 7 10

Table 1

32

IFPUG File Type Complexity (cont’d)

Number of record types

Number of data types

<20 20-50 >50

1 Low low Average2 to 5 Low Average High >5 Average High High

Table 2

The boundaries shown in this table show how the complexity level for the logical internal files is decided on.

There are similar tables for external inputs and outputs.

Record Type is also called Record Element Type (RET).

Data Type is also called Data Element Type (DET).

33

Example• A logical internal file contains data about purchase orders. The

purchase orders are organized into two separate record types:

• The main PURCHASE-ORDER details:1. Purchase order number2. Supplier reference.3. Purchase order date.

• The details for each PURCHASE-ORDER-ITEM:1. Product code.2. Price.3. Quantity ordered.

What is the complexity of the file and its FP count ? Use tables 1&2.The complexity of the file:We have 2 RET and 6 DET, based on that the file has low complexity.

34

Solution (cont'd)

● FP count =sum (FP scores of all the external user types).

● We have only one type of external user types which is : Logical internal file type

● FP score = the weight of each complexity * the count of each external user type that has that complexity.

● How many “Logical internal file type” ? only one, so count=1

● Complexity = low from previous slide with weight = 7.

● FP score= 7 * 1 =7

● FP count =7