project duration estimation

of 16

Software Project Planning and Management (CAP 590)

Term Paper: - Project Duration Estimation

Synopsis By: - Harsh Behl Submitted To- Sahil Rampal

11100961

RD1102A27

Date: - 07 April 2014

of 16

Index Page no

1. Introduction 3

2. Technique’s Which Are 4

Used to Estimate Project Duration

3. Top Down Approach 4-5

4. Bottom Down Approach 5-7

5. Expert Judgments 7

6. Historical comparison 7

7. Functional Points 7-8

8. Object points 8-10

9. CPM (Critical path method) 10-12

10. Pert 12-15

11. Conclusion 15

12. Bibliography 16

of 16

Introduction

As we all know that estimating the activity duration is very important to

the success of any Software project. Like me and my team will estimate

the various requirements of cost, time, and resources throughout in our

project. As we look upon the activity duration estimation looks at the

time it takes to complete the entire project, activity duration estimation

is dependent on other time and resource estimates also.

We might start on these estimates at the Starting of our project, but we

make the most of the estimates during the planning period.

Estimates are never exact these are just guesses by the whole team. But

we can improve our accuracy by dividing the estimation task into three

distinct steps: determining a Work Breakdown Structure (WBS),

estimating the amount of work and duration of work packages, and

calculating the project schedule.

Technique’s Which Are Used to Estimate Project Duration

We can choose from many other methods, however, if neither CPM nor

PERT meets our needs. Other estimating methods include:

Bottom-up

Expert judgment

Function point

Historical comparison

Top-down

Objects point

of 16

Out of all these methods I will discuss CPM and Pert in detail rest I will

discuss briefly.

So I am discussing each of them one by one…

Top Down Approach

As we all know that the effort for a project is a function of many

parameters. And the main factor which determine the effort for the project

is basically the size of the project. That is if we have larger project the

greater is the effort requirement and greater is the project duration. So top

down approach basically takes effort as a function of project size and it is

important to note down that to apply this function we first have to

determine the size of the project for which effort has to be estimated and

project duration is to be estimated.

If the past productivity for similar projects is known than we can use them

to determine the effort and time duration from the size.

A more general function for determining effort from size that is

commonly used is of the form:

EFFORT = a * SIZEb,

where a and b are constants, and project size is generally in KLOC (size

could also be in another size measure called function points which can be

determined from requirements). Values for these constants for an

organization are determined through regression analysis, which is applied

to data about the projects that have been performed in the past. For

example, Harsh and Vinod analyzed the data of more than 60 projects

done at LPU InfoTech Division, ranging from 4000 to 467,000 lines of

delivered source code, and found that if the SIZE estimate is in thousands

of delivered lines of code (KLOC), the total effort, E, in person-months

(PM) can be given by the equation E = 5.2(SIZE).91.

It should be noted that to use the top-down approach for estimation, even

if we have a suitable function, we need to have an estimate of the project

size. In other words, we have replaced the problem of effort estimation by

size estimation because size estimation is often easier than direct effort

of 16

estimation. This is mainly due to the fact that the system size can be

estimated from the sizes of its components by adding the size estimates of

all the components. Similar property does not hold for effort estimation,

as effort for developing a system is not the sum of effort for developing

the components as additional effort is needed for integration and other

such activities when building a system from developed components.

Clearly for top-down estimation to work well, it is important that good

estimates for the size of the software be obtained. There is no known

simple method for estimating the size and duration accurately. When

estimating software size, the best way may be to get as much detail as

possible about the software to be developed and to be aware of our biases

when estimating the size of the various components. By obtaining details

and using them for size estimation, the estimates are likely to be closer to

the actual size and duration for the final software.

Bottom up Approach

This approach works in this way that the people who are going to do

work in the project work will participate in estimation process. The team

is basically the project team members and project manager who will

develop estimating data the lowest level in the work breakdown

structure Bottom-up estimating is where the people who were going to

do the work participate in the estimating process. When the estimates of

work, duration and cost are set at that level they are aggregated upward

into estimates of higher level deliverables and the project as a whole.

Bottom-up estimating is the most accurate approach to estimating cost

and duration and also usually requires the most time. This kind of

estimating involves the entire project team and gives people the

opportunity to participate in the development of the estimates used to

measure their work. As a result, bottom-up estimating tends to develop a

much higher level of project team commitment than does top-down or

parametric estimating. In top-down, where the numbers come from an

of 16

outside source, people feel we have imposed the estimates on them. The

drawback of the bottom-up approach is that it consumes much more time

than the other estimating techniques.

In bottom-up estimating, we follow a three-step process, working from

the lowest level of detail in the work breakdown structure. We begin

bottom-up estimating by developing a detailed work package to

accompany the WBS. In this work package, we may describe risk

elements, dependencies that affect the activity and its cost and duration.

Once the work package is complete and the team member is comfortable

with it, we can proceed to develop the actual cost or duration estimate.

In bottom-up estimating, a project manager has to be careful not to force

an estimate on the project team member. If the estimate is forced, the

project manager cannot expect to earn much commitment from the team

member. That commitment is dependent on a free and open negotiation

where the team member feels the estimate is fair and reasonable. At this

point in the process, the project manager may use the three estimates

from the PERT process, as that allows an estimate that reflects the

uncertainty inherent in the task.

Last, we aggregate the estimates for each of the activities in the lowest

level of the WBS and roll the numbers up to develop estimates for the

major deliverables and the project as a whole.

We can use a number of mathematical techniques with bottom-up

estimating although the most popular and most accurate is to use three

point estimates where the team members provide the pessimistic,

optimistic and best guess numbers for the three-point calculations.

Expert Judgments

This is basically asking someone who is knowledgeable about the

application area or the development environment to give an estimate of

the effort needed to carry out a task. This method will be used when

estimating the effort and time needed to change the existing piece of the

software or developing the similar kind of software, the estimator would

of 16

have to carry the analysis in order to judge the proportion of code that

would be affected that derive an estimation from the person who is

familiar to be in the best position to do this.

But the true fact is that is simple guessing.

Historical comparison

This basically based on the cased based reasoning. The estimator seeks

out the projects that have been completed and that have similar

characteristics to the new project. The effort and time that has been

recorded for the matching source case can be used as base estimate for

the target. The estimator should try to identify any differences between

the target and source and make the adjustments to the base estimate for

new project duration and effort.

Functional Points

Alan Albrecht while working for IBM, recognized the problem in size

measurement in the 1970s, and developed a technique (which he called

Function Point Analysis), which appeared to be a solution to the size

measurement problem

The principle of Albrecht’s function point analysis (FPA) is that a

system is decomposed into functional units.

Inputs : information entering the system

Outputs : information leaving the system

Enquiries : requests for instant access to

information

Internal logical files : information held within the

system

of 16

External interface files: information held by other system

that is used by the system being

analyzed.

So on the basis of this we basically estimate the time duration for

different kind of functional points etc.

Object points

The approach was devised at the Leonard N. stern school of business,

New York University. It has similarities with FP approach, but takes

different account of features. The approach uses counts of screen,

reports and 3gl component that an application might possess it is these

that referred to as objects. Each object has to be classified as one of the

following…

1. Simple

2. Medium

3. Difficult

The number of objects at each level are multiplied by the approiate

complexity weighting as shown in the figure.

of 16

CPM (Critical path method)

In this we basically capture the activities and their inter-relationships

using a graph

Lines are used to represent the activities.

Nodes are used to represent the start and stop of activities.

With the help of cpm we can calculate the two things

The forward pass in which we calculate the earliest state of the activities

and calculate the project completion date.

of 16

The backward pass in which we calculate the latest start for activities

and identify the critical path from the graph.

Some common terms in this

Critical event : an event that has zero slack

Critical path : a path joining those critical events.

Example to construct a CPM

of 16

Pert

PERT is a planning and control tool used for defining and controlling

the tasks necessary to complete a project. PERT charts and Critical Path

Method (CPM) charts are often used interchangeably; the only

difference is how task times are computed. Both charts display the total

project with all scheduled tasks shown in sequence. The displayed tasks

show which ones are in parallel, those tasks that can be performed at the

same time. A graphic representation called a "Project Network" or

"CPM Diagram" is used to portray graphically the interrelationships of

the elements of a project and to show the order in which the activities

must be performed.

PERT planning involves the following steps:

of 16

1. Identify the specific activities and milestones. The activities are the

tasks of the project. The milestones are the events that mark the

beginning and the end of one or more activities.

2. Determine the proper sequence of activities. This step may be

combined with #1 above since the activity sequence is evident for

some tasks. Other tasks may require some analysis to determine

the exact order in which they should be performed.

3. Construct a network diagram. Using the activity sequence

information, a network diagram can be drawn showing the

sequence of the successive and parallel activities. Arrowed lines

represent the activities and circles or "bubbles" represent

milestones.

4. Estimate the time required for each activity. Weeks are a

commonly used unit of time for activity completion, but any

consistent unit of time can be used. A distinguishing feature of

PERT is it's ability to deal with uncertainty in activity completion

times. For each activity, the model usually includes three time

estimates:

o Optimistic time - the shortest time in which the activity can

be completed.

o Most likely time - the completion time having the highest

probability.

o Pessimistic time - the longest time that an activity may take.

From this, the expected time for each activity can be calculated

using the following weighted average:

Expected Time = (Optimistic + 4 x Most Likely + Pessimistic) / 6

This helps to bias time estimates away from the unrealistically

short timescales normally assumed.

5. Determine the critical path. The critical path is determined by

adding the times for the activities in each sequence and

determining the longest path in the project. The critical path

determines the total calendar time required for the project. The

of 16

amount of time that a non-critical path activity can be delayed

without delaying the project is referred to as slack time.

If the critical path is not immediately obvious, it may be helpful to

determine the following four times for each activity:

o ES - Earliest Start time

o EF - Earliest Finish time

o LS - Latest Start time o LF - Latest Finish time

These times are calculated using the expected time for the relevant

activities. The earliest start and finish times of each activity are

determined by working forward through the network and

determining the earliest time at which an activity can start and

finish considering its predecessor activities. The latest start and

finish times are the latest times that an activity can start and finish

without delaying the project. LS and LF are found by working

backward through the network. The difference in the latest and

earliest finish of each activity is that activity's slack. The critical

path then is the path through the network in which none of the

activities have slack.

The variance in the project completion time can be calculated by

summing the variances in the completion times of the activities in

the critical path. Given this variance, one can calculate the

probability that the project will be completed by a certain date

assuming a normal probability distribution for the critical path. The

normal distribution assumption holds if the number of activities in

the path is large enough for the central limit theorem to be applied.

6. Update the PERT chart as the project progresses. As the project

unfolds, the estimated times can be replaced with actual times. In

cases where there are delays, additional resources may be needed

to stay on schedule and the PERT chart may be modified to reflect

the new situation. An example of a PERT chart is provided below:

of 16

Benefits to using a PERT chart or the Critical Path Method include:

Improved planning and scheduling of activities.

Improved forecasting of resource requirements.

Identification of repetitive planning patterns which can be followed

in other projects, thus simplifying the planning process.

Ability to see and thus reschedule activities to reflect interproject

dependencies and resource limitations following know priority

rules.

It also provides the following: expected project completion time,

probability of completion before a specified date, the critical path

activities that impact completion time, the activities that have slack

time and that can lend resources to critical path activities, and

activity start and end dates.

Conclusion

This helps us to estimate the project duration estimation which later

helps to create a comprehensive estimate which will reflect the different

tasks and real-world scheduling. This approach will removes the

uncertainty and creates a project plan that helps us to know our options

and adapt to path changes. The duration estimation also help us to

estimate the budget of our project. As we all know that estimates can

never be exact but practicing this will make our guesses better.

of 16

Bibliography https://4pm.com/bottom-up-estimating/

https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0CEkQ

FjAE&url=http%3A%2F%2Frpl-blog.blogspot.com%2F2010%2F03%2F411-top-down-estimation-

approach.html&ei=ajtCU6HCKoKOrQfpuYCQDw&usg=AFQjCNE1N13_-t8ZjUaaW-

01OkYFzanMaQ&sig2=svgx9iA9JqHABaLf2HeKvw&bvm=bv.64367178,d.bmk

https://slideshare.com

https://4pm.com/bottom-up-estimating/

https://slideshare.com/

project duration estimation

Engineering