Estimation Model And Decomposition

In this lecture we introduce project estimation to estimate project resource requirements, time duration, human effort, and cost. We also discuss the models and techniques used in the project estimation. We also discuss the estimation methods such as comparative, top-down, bottom-up (engineering), historical analogy and expert judgment. Then we presented decomposition technique to break down the project into tasks to assist us in estimating the project. We focus on the work breakdown structure (WBS) decomposition method.

Learning Outcomes

Understand estimation model

Understand decomposition technique and planning tools

1.0 Introduction

In this lecture we continue discussion of project management in software engineering. We start by introducing the project estimation to estimate project resource requirements, time duration, human effort, and cost. We discuss the models and techniques used in the project estimation. We also discuss the estimation methods such as comparative, top-down, bottom-up (engineering), historical analogy and expert judgment. Then we present decomposition technique to decompose the project into tasks to assist us in estimating the project. We focus on the work breakdown structure (WBS) decomposition method.

2.0 Estimation Model

Project estimation is a highly subjective and person-dependent process. A project task could be done in one day by one person but could take a few hours by another person. Hence, different estimates could be given by different persons of the time it takes to perform a task. After actual execution and performing of the task, the time it has taken to be performed is a measured, actual and real time. Accordingly, any time estimate to performing the task that is not close to the actual time is inaccurate.

Project estimates are established at early in a project by the software development team and corporation management. These estimates are required for project resources, work to be done, project cost, project schedule, and time to delivery. Project estimates are required during project planning which is a crucial phase of the project lifecycle. Project estimating techniques are available based on metrics accumulated from past similar project experiences.

Projects should be estimated in a structured and formal way, otherwise, estimates are inaccurate and projects could be handed in late. Structured and formal project estimation methods that use sound techniques and understanding have the following advantages:

They make estimates more accurate

They allow the project team to reach a consensus on the estimates

They improve the accuracy of those estimates

They make it much more likely that projects will come in on time

Project planning requires estimates of the:

Resource requirements

Human effort- in person-months

Time project duration- in calendar time

Project cost and budget

In practice, project history and past experience are often used as a guide in estimating the above values. The estimation usually requires breaking the project into pieces.

At early stages in a project the software development team and management team must establish estimates for resources required (human resources, equipment, software, space, tools, etc.), work to be done and time to product delivery.

Cost, time, and resource estimating techniques are available based on metrics accumulated from past similar project experiences. Usually, several approaches and methods are used to estimate these values. Then, estimated values that result from different estimation methods are compared. If these values vary widely, then this variance is taken as an indication of the need for more information.

Projects could fail due to different causes related to project estimation. For example, the initial estimation of the budget needed for the completion of the project could be too little or too much. This can also be applied to the duration of the project, as some projects fail due to too little time being assigned for completion. As well as this, another factor that leads to project failure is ill planning, where the whole project is not planned out right from the start. Also, the goals and objectives of a project, which are developed at the start of the project may be regularly altered/changed which as a result causes confusion within the workforce. In addition to this, due to technology being a fast-paced industry, the personnel of the project need to stay up-to-date with this rapid change in order to use the correct the technology for the project. Finally, a lack of or ineffective communication between the workforce of the project, regardless of their role and position, can also lead to broken interactions and project failure.

Estimates could be inaccurate due to different reasons including people injury, sickness, or resign. Project development teams could run into unexpected technical problems, etc. Therefore, the objective of estimation is that people in the organization who have the training and knowledge to give an honest, well-informed opinion of the effort (time, cost, resources, etc. ) required to do a task.

The uncertainty about the project could be reduced and more accurate estimates could be generated by producing well-documents about the project scope and vision by the organization’s management and by reaching a consensus on the tasks that must be performed by the development team members. This consensus could be reached through discussion of assumptions.

The following are some project estimation techniques (models):

Source Lines of Code (SLOC): Source Lines of Code (SLOC) is the oldest metric for estimating project effort and thus is the primary input of older cost estimation models. The accurate estimation of a software project estimate is based on size of the project to be built. Project size is translated into human effort, time and money.

Software Equation: In software equation estimate data is collected for thousands of similar projects and a the estimation model is a software equation as given below:

EPM = (L x Sk(1/3) / PP)3 x (1/d4)

Where

EPM- is the Effort in Person Months

L is the number of code Line

Sk is the factor of Special sKills

PP is the Parameter of Productivity

D is the project Duration

Using SLOC as input for cost estimation has some disadvantages because estimating the SLOC early in the software development lifecycle can be difficult. Therefore, if the SLOC estimate is inaccurate, the output of the dependant cost estimation model will be inaccurate.

Software LIfecycle Management (SLIM): SLIM was developed in the late 1970’s.

Wideband Delphi: Wideband Delphi is an effective technique in estimating software tasks.

Proxy Based Estimating (PROBE): This is an estimation method that looks at the history of a person in terms of components he has built in the past. It states that a person constructing a component that he has previously constructed (or one similar to it) then the amount of effort that will go into building this component will roughly be the same.

The Constructive Cost Model (COCOMO): COnstructive COst MOdel (COCOMO) is a software cost and schedule estimating method which was developed in the early 1980’s. It was developed through an experiment which involved the analyzing and evaluating of results for 63 software development projects.

COCOMO was updated in 1991 for modern development life cycles, in order to accommodate larger sets of data. It is calculated on the basis of 15 cost factors. These factors, sometimes called variables, cover the cost of the software needed, any computer hardware that will be used, and the cost of labor (wages). These are inputted into the model and as a result, an output is arrived at estimating the size and effort that need to be put into the project for it to succeed.

The Planning Game: The Planning Game is the software project planning method developed by Extreme Programming (XP). It was developed in the 1990s. It is basically used to manage the negotiation between the development team and the stakeholders (Business customers). Unlike Delphi, PROBE, and COCOMO, the Planning Game does not require a documented description of the scope of the project to be estimated. Rather, it is a full planning process that combines estimation with identifying the scope of the project and the tasks required to complete the software.

Estimates use comparative estimate, grass roots estimate, engineering estimate (bottom-up), top-down estimate, historical analogy estimate, expert judgment estimate, models estimate, and/or rules-of-thumb estimate. Typically, estimates are made using some combination of these/some of these estimate methods.

These estimate methods are described in the following paragraphs.

Comparative estimate: Comparative estimate compares project with past similar projects. One advantages of this method is that estimates are based on actual experience. One disadvantages of this method is that truly similar projects must exist.

Engineering estimate (Bottom-up): Engineering Estimate (Bottom-up) assigns different components of the project to individuals to estimate. Then, component estimates are summed to obtain total estimate of the project. Advantages of this method include generation of accurate estimates because of detailed basis for estimate, promotion of individual responsibility, and support of project tracking. Some disadvantages of this method are that the method is time- consuming, detailed data is needed which may not be available, especially before the project starts or early in the project, and integration costs may be disregarded.

Top-Down estimate: Top-Down estimate partitions the project into lower level components where life cycle phases begin at highest level. Some advantages of this estimate are that it is more applicable to early project estimates, it considers system level activities, it is faster, and easier to implement. Some disadvantages of this estimate is that it is less accurate than other methods, it tends to overlook lower-level components, and it provides little detail.

Historical analogy estimate: Historical analogy estimate is based on using the software size, effort, or cost of a comparable project from the past. The comparison is made using measures or data that has been recorded from completed software projects. Analogical estimates can be made at high levels using total software project size and/or cost for individual Work Breakdown Structure (WBS) categories in the process of developing the main software cost estimate.

Expert judgment estimates: Expert judgment estimates specifies that software development team consults with one or more experts. Some advantage of this estimate is that little or no historical data are needed, and it is good for new or unique projects. Some disadvantages of this estimate is that experts tend to be biased, and their knowledge level is sometimes questionable. This is a subjective estimate based upon what the estimator remembers from previous projects and gets modified mentally as deemed appropriate. If the estimator has significant recent experience in both the software domain of the planned project then, expert judgment can be relatively accurate.

Model-based estimate: Model-based estimate uses mathematical relationships or parametric cost models. Parametric cost models are empirical relationships derived by using statistical techniques applied to data from similar previous projects.

Rules-of-thumb estimate: Rules-of-thumb estimate come in a variety of forms and can be a way of expressing estimates as a simple mathematical relationship (e.g. cost = Lines_of_Code / 10) or as percentage allocations of effort over activities or phases based upon historical data (e.g. coding task is 22% of Total Effort).

The popular project estimates approach is to use several methods and compare values. If these values vary widely, then this variance is taken as an indication of the need for more information.

Model-based estimates along with high-level analogies are the principal source of estimates in early conceptual stages. At early stages of the project or before it starts, we usually do not have a clear estimates, but as a project matures and the requirements and design are better understood, analogy estimates based upon more detailed functional decompositions become the primary method of estimation, with model-based estimates used as a means of estimate validation or as a correctness check.

Whatever method is used, it is most important that the assumptions and formulas are documented to enable more thorough review and to make it easier to revise estimates at completion of the project when assumptions may need to be revised.

Expected Value for Software Size is computed as follows:

Suppose that:

Expected value for estimation variable (size) estimate = S,

Weighted Average of Optimistic estimate = (S opt)

Most likely estimate (S m)

Pessimistic estimate (S pess )

Then, S can be computed as:

S = (S opt +4 S m + S pess)/6

The calculation of the effort put in, in terms of ‘persons-month’, in a dynamic multi variable model can be defined as follows:

Software Equation (E) = [LOC * B0.333/P]3 *(1/t4)

Where:

E is effort in person-months,

t is the duration of the project,

B is special skills factor,

P is productivity.

2.1 Decomposition Technique

Decomposition technique is used to estimate the project as presented in the previous section. After decomposing the entire project into a number of smaller tasks, we make project estimates. It is easier to handle smaller tasks than to handle a very larger project as a whole. So, the entire project (problem) is broken down into number of smaller tasks (problems) and then each smaller problem could be solved easily.

Decomposition technique is used as a technique or model for cost and project estimate. It is difficult to estimate the project as one task. Therefore, the project is decomposed into smaller tasks and each task is estimated individually and then the partial estimations of project tasks are added up for the whole project.

A sound and formal estimate starts with a work breakdown structure (WBS). A WBS is a list of project major phases, deliverables, and work components (tasks) that will be built by the project that, when completed, will produce the final product. These work components/tasks can then be broken down into the activities that are required to build them.

The concept of this technique is to break down the work into smaller tasks. Each task can in turn be broken down further. This technique is very useful for the project development team and project management team to become familiar with the scope of the project, identifies work tasks, needed resources, and cost estimation. It also helps to monitor the project’s progress.

Project managers use the Work Breakdown Structure (WBS) to estimate projects and make complex projects more manageable.

Some advantages of using WBS include:

Assists with more accurate project estimation in cost, effort, resources, and schedule

Assists with project organization

Helps with assigning responsibilities to project development team members. A WBS that is correctly designed allows for the easy assignment of tasks to a specific element of the WBS, cutting down on confusion/duplication of assigned tasks.

Shows the control points and project milestones

Helps explain the project scope to customers and stakeholders

Assist in planning and control of the project

Tasks and Subtasks are related to each other in the sequence of project task networks. Project Task networks graphically visualize the tasks/sub-tasks and their relationships. Project Task networks are also known as activity networks.

The Work Breakdown Structure is a tree structure. The root of the tree is the whole project and the children of the root are the main tasks at first level of the tree which compose the project. At level 2 of the tree are the sub-tasks of the main tasks of the project at level 1. The rest levels of the tree are constructed similarly.

Using the tree structure of the WBS allows the determining of secondary costs for tasks, resources, etc., into their advanced level “parent” tasks, materials, etc.

The WBS is the basis for dividing work into defined tasks from which the, schedule, cost, and labor hour reporting can be established.

There are many ways to decompose a project into tasks. Different project break-down ways lead to different estimates. If the generated WBS is incorrect, then the project estimates are wrong and time is wasted in doing the estimates. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc.), or by some combination of the two.

WBS uses similar previous projects history and previous experience of projects that have been developed to generate project t estimates.

Large projects are broken into more tasks than smaller projects or they can be broken into larger tasks than smaller projects.

WBS, when created, is used by the project team to create an estimate of the effort required to perform each task. The most accurate estimates are those that rely on similar projects history and prior experience. Team members should review previous project results and find how long similar tasks in previous projects took to complete. Sources of delays in the past should be taken into account when making current estimates.

The level of granularity of WBS varies depending on the level of abstraction and what information is available. At lower-levels of the WBS, expert judgment is the primary method used, while at higher levels of the WBS model-based estimates are more common.

It is not possible to define a task set for the project uniquely. No set of tasks is appropriate for all types of projects. Project breakdown into tasks is dependent on the size of the project, complexities involved in the project, constraints of the projects and the skill set and capabilities of the team members working on the project.

Project tasks have to be properly distributed according to the needs of the project deadlines and schedule. To develop a project schedule, a task set must be distributed on the project time line.

The project set of tasks is defined based on the category of the project which is dealt with by the development team.

Summary

Exercises

Is it possible to create a realistic estimate before the project team has agreed on the technical design for the software?

When the team is working together to generate an estimate, should the testers estimate tasks which will be performed by the programmers?

List three models of project estimate.

What is estimated using project estimate?

Describe the objectives of using decomposition technique?

List advantages of decomposition technique for company managers.

Describe the Source Lines of Code (SLOC) estimation method.

List two advantages and two disadvantages of using The Constructive Cost Model (COCOMO).

What is the difference between Engineering estimate (Bottom-up) and top-down estimate?

Explain decomposition techniques.

How do you define a task set for the software project?

What are project task networks?

Order Now