Introduction

The ability to successfully estimate the effort and time for a software project can be the difference between success and failure or result in a project that under-delivers in terms of quality or functionality. Having a repeatable estimating process in place can greatly enhance the ability to estimate cost, effort and duration more accurately.

Characteristics of a Good Estimating Method

A sound method for estimating software projects should have the following characteristics:

Justifiable – the method should be based on some recognised procedure or process, either developed by an organisation or on a method that has been proven to work on a software project.

Repeatable – the method can be used on different types of project eg different types of technology, programming language, business domains etc.

Refinable – the method can be used not only at the start of the project, but as the project proceeds.

Interval – the method should be capable of giving an upper and lower limit to the project’s cost, effort and time. These limits represent what the cost, time and effort would be if all the project’s identified risks were to happen (upper limit), and what the cost, time and effort would be if few or none of the risks happened (lower limit). The interval thus represents the project’s “Worst Case Scenario” and “Best Case Scenario”.

Types of Estimating Method

Basically, there are four types of estimating methods:

Decomposition Method – in the Decomposition Method, a project is broken down into its constituent parts; each of these parts is then converted into tasks. Each task is then estimated in terms of its duration and effort. Any supporting tasks, such as audits, training, configuration management, reviews etc. are added and estimated. The tasks are usually shown in the form of a Gantt chart produced from a scheduling tool, such as Microsoft Project.

Project Managers have a variety of styles in using the Decomposition Method. Some managers estimate on the basis of their own experience from managing previous projects. Others will ask the team, or individuals from the team to estimate the duration and effort required to carry out a particular task.

A third method employed by some project managers is a combination of the previous two styles. In this method, the project manager asks the team to estimate the effort and duration of the project’s tasks, then will make an adjustment to of the tasks, based on the project manager’s experience of their team.

If the project manager feels a team member tends to underestimate a task or tasks, they will add some contingency by increasing the time or effort or both to give their opinion to the true estimate. If they feel a team member tends to overestimate, then they will reduce time, effort etc. to give a true estimate.

Analogy Method – the Analogy Method uses characteristics of a system, such as effort, cost or time of an existing system and extrapolates those parameters to the new system. The existing system can be internal or external to that company, though it is usually internal.

The system will also only have some functionality in common with the new system. For the parts of the system that are not known, the parts that are known are used as a reference for the parts that are not known. When this comparison is carried out, the parts of the system that are understood are categorised in term of size eg complex, medium, simple; high, medium, low or a numeric scale 4,3,2,1. The various parts of the system that have been categorised are then equated to the cost, time and effort based on the previous system and added up to give the overall figure.

This method is useful at the very early stages of a system, such as when the high level requirements or the outline scope are only known.

Expert Opinion Method (Delphi Method) – the Delphi Method uses a consensus approach to arriving at an estimate.

In the Delphi Method, a group of “experts”, usually 2-5 people, meet to discuss a system. They will have done preparation prior to the meeting through reading any documentation already developed eg specifications. The “experts” could be people with an understanding of the type of system to be developed; project managers; customers/users; people with an expertise in estimating or other technical staff.

The meeting is chaired by a “moderator” whose role is to co-ordinate the meeting and perform other tasks, as outlined below.

The experts discuss the system to be estimated and when they feel they an understanding of what’s required, they produce a task list with estimates of effort for each task. They then hand their task lists to the moderator; the moderator takes the task list and shows each estimate to the experts but does not reveal which person made which estimate.

The team then discusses the system to be developed to determine any issues or assumptions that may have changed from the previous discussion. They then revise their estimates and return to the moderator. The moderator again displays each estimate anonymously; the difference between the highest and lowest estimates should decrease until there is a consensus between the team.

If necessary, four cycles of discussion on the system can take place to arrive at a consensus on the estimate. If this doesn’t happen, the team may decide that the system isn’t well enough understood and can request more information or decide to wait until the system is more clearly defined.

Parametric Methods – this family of methods uses a measure of the size of a project to determine cost, effort and duration. There are two ways to measure the size of a project that are used with parametric methods: Function Point Counting (FPC) and Lines of Code (LOC).

FPC takes a specification, such as a Software Functional Specification or detailed Requirements Specification and identifies functional types. In the most commonly used method, IFPUG, there are five functional types:

External Inputs (EI) - any parts of the system to be developed where data can be entered eg a Customer Details screen on an Car Insurance system

External Outputs (EO) – any parts of the system to be developed that are sent to an external source eg a screen, a printed report.

External Queries (EQ) – any query to a file or database that can reference it but not change the data.

Internal Logical Files (ILF) – files or database tables that are part of the application to be developed and that can be modified.

External Interface Files (EIF) – database files or tables that already exist in another system that are referenced from the system to be developed.

FPC counts each of these entities in a specification; the total is known as the Function Point Count.

LOC has been used historically for sizing systems, but is no longer actively used since it is dependent on the language employed to develop the system. FPC is derived from the specification, and hence is independent of the implementation language and can be used across many projects to build a source of historical data that can be employed on future projects.

The FPC/LOC is the most significant input into the Cost Model – a simulation that provides cost, duration and effort for a project. Common models are available as software estimating tools such as: the Common Cost Model (COCOMO); Software Life-cycle Model (SLIM) and Parametric Cost Estimating for Software (PRICE-S). These models allow various parameters to be changed such as: the volatility of the requirements; experience of the team; project risk/novelty etc. By changing these factors, “What-if?” scenarios can be developed.

For more information on the Centre for Software Engineering’s Estimating and Project Management Services, contact us on +353(1) 700 5353 or cse@dcu.ie