|
| Estimation method | Limitations |
|
| Estimation by analogy | Subjective selection of correlation standards and dispute identification process (confidence level) |
| Requires analogous project for comparison from historical data from database |
| These analogous projects are rarely available in software development |
|
| Decomposition and bottom-up (WBS-based) | It may be time-consuming for large or even medium-sized projects |
| High risk of ignoring system-related tasks such as testing, integration, and configuration is high |
| This method may lead to underestimation due to lack of project information at early stage |
|
| Parametric models (SLIM, SEERSEM) | Usually does not take into account the project team’s skill set specific to the organization’s software and project management culture |
| Modern methods of code reuse, code less programming, and various agile development methods for software development may not be feasible |
| Highly dependent on programming language |
|
| Expert estimation (Delphi, PERT, planning poker) | These methods rely on the experience, knowledge, and perception of experts, and there may be deviations or biased, which often lead to overestimation or underestimation |
| All the factors used by experts in the estimation process are unable to justify and quantify |
|
| Size-based estimation models (use case, FPA, sTory points) | Requires trained personnel which is not easily available |
| High effort and cost is required for the application of large projects |
| Due to limited information, using this method in the early stages of a project may result in inaccurate estimates |
|
