Empirical Techniques in Cost Estimation Model

The foundation of empirical estimation methods is a well-informed estimate of the project parameters. It is useful to have experience developing similar items while employing this strategy. Different aspects of the estimate have been formalized over time, even if empirical estimating procedures are grounded in common sense.

Types of Empirical Techniques:

1. Expert Judgement Technique
2. Delphi Cost Technique
3. Estimation By analogy

Expert Judgement Technique:

One of the most popular methods of estimation is expert judgement. Using this method, a specialist analyses the problem in-depth and then estimates the problem size with some degree of confidence. Typically, the expert determines the approximate costs of the various system components its modules or subsystems and then adds them together to get the total estimate. Nevertheless, individual prejudice and human mistake can affect this technique. Additionally, it’s likely that the expert unintentionally missed some important details.
Furthermore, a specialist providing an estimate might not be fully versed in all facets of the project. For example, he might understand the user interface and database components, but not the computer connection component. An estimate from a group of experts is a more sophisticated kind of expert judgement. When a group of specialists estimates, it reduces the impact of things like human error, unfamiliarity with a certain project element, personal bias, and the motivation to win a contract by making too-optimistic estimates.

On the other hand, an expert group’s estimate could still be biased on matters where the group as a whole might be biased for many reasons, including political concerns. Additionally, a group decision could be influenced by extremely aggressive individuals.

Delphi Cost Technique:

A few of the drawbacks of the expert judgement approach are attempted to be addressed by the Delphi cost estimation approach. A team consisting of a coordinator and some experts does Delphi estimating.

In this method, a copy of the software requirements specification (SRS) document and a form for noting the estimator’s cost estimate are given by the coordinator to each estimator. Estimators fill up their personal, anonymous estimations and send them to the coordinator. The estimators note in their estimates any peculiarity in the product that has affected their estimation. The summary of each estimator’s responses, together with any odd reasons pointed up by any of the estimators, is prepared and distributed by the coordinator.

The estimators re-estimate based on this summary. There are multiple iterations of this technique. However, during the entire estimation process, there can be no conversation among the estimators. The reasoning for this is that if there is room for debate among the estimators, many of them could be swayed by the reasoning of a more senior or experienced estimator. The coordinator is in charge of gathering the data and creating the final estimate following the completion of multiple estimates iterations.

Estimation By analogy:

Another name for this is case-based reasoning. In this scenario, the estimator finds completed projects (source cases) that have comparable features. To the upcoming project (use case). The estimator then determines how the source and goal differ, modifying the base estimate to generate the new project’s final estimate.

This method is mostly applied when you have enough knowledge from prior projects. Finding the similarities and differences between the apps with a large number of previous projects is an additional difficulty or work in this case.

Overall in the cost estimation model, empirical techniques use data-driven methods to generate well-informed projections. These techniques are especially useful when a large body of historical data is available and when there are enough commonalities across the projects to enable insightful comparisons. It is imperative to acknowledge that approximations grounded in past facts are susceptible to uncertainties, and variables like project intricacy, team composition, and technological advancements might impact the precision of approximations.