Models for the estimations 1

U1. Actividad de aprendizaje para RA: Activity 2. Task: Models for the estimations

Juan Carlos Valencia Osorio

Tutor

Hugo Alfonso Ortiz

Universidad Manuela Beltrán

Gestión de proyectos de desarrollo de software

Quito, Ecuador

2023
Models for the estimations 2

Index

Boards.............................................................................................................................................3
Figures.............................................................................................................................................3
Introduction....................................................................................................................................4
Content............................................................................................................................................6
Software Estimation Types..........................................................................................................6
Software estimation by expert judgment................................................................................6
Software estimation by analogy..............................................................................................6
Software estimation by decomposition...................................................................................6
Software estimation by means of estimation models..............................................................7
Tools for software estimation......................................................................................................7
Estimation by expert judgment...............................................................................................7
Wideband Delphi Method.......................................................................................................8
Estimation by analogy............................................................................................................10
Software estimation by decomposition.................................................................................10
Techniques we've seen so far................................................................................................11
Techniques based on software project estimation models...................................................12
COCOMO II............................................................................................................................12
IFPUG function points............................................................................................................13
COSMIC function points.........................................................................................................14
Agile software estimation methods.......................................................................................15
Conclusion.....................................................................................................................................17
Bibliography..................................................................................................................................18
Models for the estimations 3

Boards
Table 1 Function points (PMOinformatica.com, 2018)..................................................................13

Figures
Figure 1 Wideband Delphi (PMOinformatica.com, 2018)................................................................9
Figure 2 Decomposition (PMOinformatica.com, 2018).................................................................11
 Models for the estimations 4

Introduction

The first component of a software project is project planning. At this stage, one of the most
important tasks is the estimation of both resources and time, cost and effort for the satisfactory
development of the project. Due to the importance of estimation, multiple investigations have been
motivated to improve the understanding of the software development process, as well as to build and
evaluate software cost estimation tools. Estimating the factors related to a project (effort, personnel,
schedule, cost, etc.) requires knowing or estimating its size in order to evaluate possible solutions,
compare alternatives, and calculate costs before deciding on a particular approach (Fillottrani, 2007).

Within the framework of a Software project, there may be various variables to be estimated,
such as the estimation of the duration of each of the tasks to be carried out within the project (analysis,
design, management, development, testing, among others) or of the project in total, as well as the
estimates of the test cases by use cases, the risks, the effort to be made, among various estimable
indices. Any intention to calculate times, resources or costs for the future implies estimates.

When project management and planning is carried out, the first thing that is done is the estimate
of the size of the software and then proceed to estimate the necessary effort, and the possible
schedules. Cost estimation is one of the first activities carried out in the project, most of the time after
the establishment of the requirements, however, it continues to be applied regularly throughout the
execution of the project in order to adjust the precision in the previous estimate.

While estimation is difficult, a good approach may be to incrementally develop the

requirements, revising estimates as more information becomes available (spiral development). Early
estimation can cause problems (produce risks), since the amount of information that is initially available
from the system is usually limited, which makes this process difficult.

It is very useful to be clear about the fundamental uses of cost estimation in project
management:

 In the planning stage, it allows deciding the number of people needed to execute the
project and establishing adequate schedules.
 During the progress of the project, it allows you to monitor its progress and assess
whether the project is running according to schedule and, if not, be able to take action
on time. For this, it is necessary to have metrics that allow measuring the level of
compliance of software development.

In the field of software engineering, cost estimation is basically estimating the size of the
software, as well as the number of people needed to develop the product. Unlike other engineering
disciplines, in which the cost of materials is the main component to be estimated (Gómez, 1999).

Furthermore, the strong relationship between cost, schedule and quality is undeniable. These
three aspects are closely related and confront each other. In this way, it becomes difficult to increase the
quality without increasing the cost and/or the schedule of the software to be developed. Similarly, the
development schedule cannot be dramatically reduced without deteriorating the quality of the software
product and/or increasing the cost of development. Estimation models play an important role as they
allow balancing these three factors (Gómez, 1999). It is very necessary to highlight that the estimation
 Models for the estimations 5

process is inherently uncertain since it is trying to measure elements such as the size, cost and effort of a
project that has not yet started and of which it is very likely that there is little knowledge. This is why it is
vitally important that the person in charge of managing the project is a person with experience in the
subject, who always takes past work into account so as not to repeat the same previous problems and
with good vision to anticipate possible risks. It must always be borne in mind that estimating in the early
hours is very risky, so it is necessary to constantly review and adjust existing estimates.
 Models for the estimations 6

Content

A software estimate is a prediction of how long it will take or cost to develop and maintain. If it is
a time estimate, the effort can be expressed in person-hours or another unit; if it is a cost estimate, it can
be expressed in the preferred currency.

The challenge of developing software estimates is to make realistic predictions, based on

incomplete and uncertain information.

In software engineering and software project management, estimates are used to:

 Develop project plans.

 Prepare iteration schedules in software development.
 Prepare budgets.
 Carry out investment analysis.
 Pricing software for a business client.
 Analysis to determine the price of software directed to the consumer.
 To plan strategy when preparing to participate in contract auctions in which several
suppliers participate.

Software Estimation Types

Software project estimation techniques can be classified into four types:

Software estimation by expert judgment

Software estimation methods by expert judgment, consist of delivering the software

requirements survey information (for example, the meeting minutes or software requirements
specification document) and delivering it to one or several experts in software development and the
business area to be represented in the new system (PMOinformatica.com, 2018).

Software estimation by analogy

This type of estimation of software projects consists of comparing the proposed software
development with previous similar projects. The advantage over the estimate by expert judgment is that
the analogy is based on documented experiences, which is why it is based on documented numbers.

A possible disadvantage is that if there is a lot of variation in technologies and functionalities

from one project to another it will be more difficult to establish reliable estimates.

Software estimation by decomposition

 Models for the estimations 7

It consists of decomposing the project into components, and these in turn into more detailed
subcomponents. This type of estimation is based on the principle that dividing a problem into its parts
facilitates its approach and analysis.

Estimates on smaller components would have a better level of accuracy than large components,
allowing the identification and debugging of missing information that could affect the estimate.

Software estimation by means of estimation models

Includes the use of parametric, procedural, algorithmic or other models to make software
estimates. The advantage of these methods is that by having a numerical basis they tend to reduce the
bias associated with the judgment of an estimator when making the estimates.

An example of estimation by model is COCOMO, in which a linear regression formula applied to

historical data from previous projects is used, producing the estimates through this estimation function.

Another example is the analysis of function points, under this method, a standard classification is
applied to software components, then determined numbers of function points are assigned according to
their characteristics, obtaining a measurement of their size.

Unlike other types of estimation software, estimation models produce estimates that are based
on mathematical formulas and statistics (PMOinformatica.com, 2018).

Tools for software estimation

We have described the types of software estimation into which the various techniques can be
classified.

In the following of the article, we will explain the following estimation techniques:

 Expert judgment
o 1 point only.
o 3 points.
 Wideband Delphi method.
 Estimation by analogy.
 Decomposition
o Top down.
o Bottom up.
 Software project estimation models
o COCOMO II
o IFPUG function points.
o COSMIC function points.
 Estimation of agile projects through Planning Poker.

Estimation by expert judgment

 Models for the estimations 8

Expert judgment is possibly the most common way used by many to obtain an estimate. It seems
easy, right? Simply get an expert with direct experience in the software you want to develop and its
business model, give them the software requirements and see what they say.

Of course, you must make sure that everyone has the same understanding of how the software
to be developed should work and what is expected of it. Also, another challenge is that the people who
are going to make the estimate are the ones who are going to do the project.

Expert judgment estimation techniques always consider some kind of functional breakdown of
the software into its parts.

Once the expert or group of experts has divided the problem into activities, they can proceed to
assign an estimate to each one, using the following techniques.

A single point

In this technique, only a single estimate is assigned to each activity, usually by a single person.
Once you have the estimates for each activity, you can calculate the total duration.

This is one of the most used techniques, however it has two problems: first, the estimate is
highly influenced by the bias and the premises of the estimate. What happens if some key piece of
information is omitted? Or is some aspect not considered? In addition, the estimate could also “inflate”
your estimates.

Three points

What would happen if instead of asking for an estimate as in the previous case we ask for 3
estimates? Furthermore, what would you think if we gave the specification to three different experts and
see the estimates of each one?

If we have three estimates, we can assign each activity a pessimistic, most likely and optimistic
estimate, then we can determine the estimate of the activity by means of a formula.

Three-point estimation is not the exclusive field of Software Engineering, in fact the Project
Management Institute (PMI) describes it in its PMBOK 6 guide as an estimation method. Following the
PMI standard, the following formula is used to estimate the duration of an activity:

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

Activity standard deviation: (Pessimistic – Optimistic) / 6

Wideband Delphi Method

 Models for the estimations 9

Figure 1 Wideband Delphi (PMOinformatica.com, 2018)

Wideband Delphi is a software estimation technique that involves a group of experts. Unlike
other estimation techniques based on expert judgment, the members of the group do not communicate
with each other while they are preparing their estimates, and they only deliver them to a coordinator.

The Delphi method dates from the 40s, in which several experts created the estimates
individually and then met to agree. In the 1970s, a study showed that the method was not producing
better results than individual estimates, due to political pressures and group dynamics. It was for this
reason that Boehm and Farquhar developed the Wideband Delphi method, which reduces arguments
and debates.

To perform a Wideband Delphi estimation, the following steps are followed:

1. A coordinator presents each expert with a software specification and estimate form.
2. Each expert works individually on his estimate.
3. A meeting is held in which the experts talk about possible problems in their estimates, in
this way each expert provides Feedback to the others without directly influencing the
final estimate they will produce.
4. Each expert prepares an estimate form and submits it to the coordinator anonymously.
5. The coordinator prepares a summary and distributes it to the group of experts.
6. The coordinator and the experts meet, looking at the variations in the estimates. They
also produce a median estimate.
7. The experts vote anonymously if they accept the median estimate. The vote must be
unanimous, if someone votes that they should not go back to step 3, that is, the group
must discuss the problems in their estimates again, and then elaborate new estimates.
 Models for the estimations 10

As you can see, the fact that the estimators prepare their estimates without communicating with
each other and that the vote in the final estimate is anonymous eliminates the group dynamics bias, thus
seeking to obtain more realistic estimates (PMOinformatica.com, 2018).

Estimation by analogy
Software estimation methods by analogy

The estimation by analogy is based on the premise that the organization must have a database in
which the necessary information on the characteristics, actual duration and actual cost of previous
projects is recorded.

The challenge of this estimation method is to have a sufficiently detailed database to identify the
characteristics of the projects and determine if they are comparable with the project to be estimated.
Also, for a constantly innovating organization or many dissimilar projects, it can be challenging to apply
this method.

Its application is feasible if estimates of low accuracy and high uncertainty are being prepared,
that is, if there is a tolerance of deviation from the estimate of 50% or more. Its application is also easier
if the organization executes similar and comparable projects (PMOinformatica.com, 2018).

Software estimation by decomposition.

Top-Down decomposition

Using a high-level work breakdown structure (WBS) , collated with data we have from previous
projects, we can make estimates for each work item to determine overall effort and cost.

The Top-Down method does not use detailed analysis, therefore it is better to use it only when
we need a first estimate to assess the feasibility of projects, but it is not recommended if we need
detailed estimates or costs to determine, for example, a budget (PMOinformatica.com, 2018).

Bottom-Up Decomposition

To apply this method, you need a detailed work breakdown structure (WBS) , which in Software
Engineering would mean doing almost all of the analysis and design of the solution. Therefore, it is a
better technique used in projects that have already been approved and that you have a budget for all the
analysis that this type of estimate requires.

Each WBS task is estimated individually, to later add the estimates and have higher level
numbers. By applying this technique you will obtain more accurate estimates than with the Top-Down
method, however the time investment is greater (PMOinformatica.com, 2018).
 Models for the estimations 11

Figure 2 Decomposition (PMOinformatica.com, 2018)

Techniques we've seen so far

The main difference between the decomposition techniques and the expert judgment
techniques seen above is the detailed analysis of the project that they imply.

In the case of expert judgment techniques, although each expert can perform a breakdown of
tasks in their individual analysis, the technique does not require it (although it is recommended).

On the other hand, decomposition techniques formally establish the need to analyze and design
the solution, in the case of Bottom-Up, details are required that can only be achieved after you have
committed to the project and have a budget and a team. of assigned work.

However, the decomposition techniques still require someone (an expert) to estimate each work
package, which entails the possible application of dissimilar standards between one estimate or another,
as well as bias, or the estimator being very optimistic and pessimistic.
 Models for the estimations 12

We will see below a series of methods that seek to avoid this situation.

Techniques based on software project estimation models

The estimation models seek to produce estimates of software projects from mathematical
formulas that can be applied in the same way from one project to another, bringing the benefit that all
projects are evaluated objectively, in addition, they produce exact estimates that can be broken down
and analyzed. in parts, for example by analyzing the effort and cost of some specific functionality or
software module.

Here are some techniques that use software project estimation models.

COCOMO II

The acronym COCOMO stands for Constructive Cost Model, or “Constructive Cost Model” in
Spanish (COCOMO II). The COCOMO method was originally developed by Dr. Barry Boehm in 1981. Later,
in the 1990s, it was updated and from 1995 it is known as COCOMO II.

To make estimates of software projects, COCOMO II uses three sub-models, each one with a
higher level of fidelity than the previous one. These models are:

 Composition of applications.
 Initial Design (Early Design).
 Post architecture models.

The Application Composition Model is used to analyze the software to be developed and
modified, identifying components, subcomponents, dividing and classifying them. The initial design and
post architecture models are the ones that produce the estimation, both use the following equations:

Effort expressed in people months (E)= a (Kl)^bxm (X)

where:

a, b: Constants with values assigned according to the model being used (initial design or post
architecture).

Kl: Lines of code (em thousands).

m (X): Multiplier that depends on 15 attributes.

Time (Schedule) of the project (Tdev) = c (E)^d

where:

c, d: Constants with assigned values according to the model being used (initial design or post
architecture).
 Models for the estimations 13

E: Effort required (Calculated with the first equation)

Number of people required in the team (P) = E / Tdev

The key variable to achieve a correct estimation in the model is the measurement of the size of
the software to be developed. For size measurement, COCOMO proposes two approaches, code line
count and function point count.

COCOMO II with code line count

The biggest challenge is being able to calculate how many lines of code will have a project that
we have not yet done, COCOMO II proposes the use of historical data from past projects.

If you do not have historical data, you can resort to expert opinion (technique explained in
number 1) just to obtain a measurement of code lines, it being advisable to have 3 estimates, one
pessimistic, most likely and optimistic (3 points).

As you can see, COCOMO II also relies on expert judgment, however, having a proven
mathematical formula to correlate likely lines of code and required effort is better than simply relying on
estimator opinion.

COCOMO II with function points

The estimation of costs by function points is based on the amount of functionality involved in the
software to be developed, they are useful because they are based on information that is available since
the analysis of the project is carried out.

Unadjusted function points measure a software project through the quantification of

information processing functionalities, classifying them into data inputs or outputs, internal or external
logical files. For each one a predetermined number of function points is assigned, which gives us a
functional measurement of the software.

COCOMO II follows the same definitions as the IFPUG function point method, which we will see
in more detail in the following software project estimation technique (Gómez, 1999).

IFPUG function points

Table 1 Function points (PMOinformatica.com, 2018)

Function Type Difficulty level Function points

Enter customer External input High 6
Modify customer External input Medium 4
Customer table Internal logical file High 15
Identity documents Internal logical file Low 7
table
 Models for the estimations 14

Address table Internal logical file Low 7

Although Function Point Analysis can be used in conjunction with COCOMO II, the method can
work on its own as a software project estimation technique.

It was originally developed by Allan Albrecht in 1979 while working for IBM, who defined
concepts for measuring software based on assessments of functionality delivered to the user and not
based on technical aspects, with the intention of producing independent assessments of technology and
phases of development. life cycle used.

Albrecht's work was continued by the international group of function point users, who embodied
his concepts in the IFPUG-FPA method.

IFPUG-FPA performs the evaluations based on the functionality of the system, first classifying
them, then assigning a complexity and weighting to each one according to predefined tables, thus
determining the value of function points (PMOinformatica.com, 2018).

COSMIC function points

COSMIC is a second-generation function point analysis method, in which the functional size of
software is determined from the number of interactions between functional processes.

The IFPUG method (pre-COSMIC) relies on the "function types" defined by Albrecht, which were
suitable for the 1970s, but have become difficult to map to modern ways of modeling software
requirements, such as when software is built as services (SOA) and in areas such as real-time or
infrastructure software.

By the 1990s, the industry was demanding a standard function point analysis method, however,
there was no agreement to select any of the existing measurement methods.

COSMIC's main change from IFPUG is that instead of classifying features and assigning a
predetermined amount of feature points to each type, it focuses on counting interactions between
features and between features and data files.

For example, if a data entry type functionality has two data entry processes, one for writing that
data in the database and another for consulting another functionality via interface (webservice), this
counts for 4 interactions.

The steps to perform a measurement under COSMIC are:

 Phase 1: Measurement strategy.

 Phase 2: Mapping.
 Phase 3: Measurement.

COSMIC has the advantage of not setting arbitrary limits to the functional size, so it can measure
very large or small software components. Additionally, it is based on the functional breakdown of
software components, aligned with Software Engineering practices (PMOinformatica.com, 2018).
 Models for the estimations 15

Agile software estimation methods

Planning Poker

Planning Poker is an estimation technique used in projects executed with agile methodologies,
such as Scrum. It is a technique to measure the product stack elements (Product Backlog) in an agile
project, which are nothing more than the work to be done to develop the software broken down into
software components, specific functionalities, even parts of functionalities.

Planning Poker is an expert judgment technique (see above) but it is based on consensus. The
experts, members of the development team (so they will be the ones who will carry out the work)
engage in a discussion to expose the premises and acquire a shared understanding of each element of
the Product Backlog that they are willing to estimate.

The estimates that Planning Poker produces are not in absolute measurements, instead they are
relative measurements, in which items of similar size are lumped together (PMOinformatica.com, 2018).

Estimation Scale

The most frequently used estimation scale in Planning Poker is the one proposed by Mike Cohn,
based in part on the Fibonacci sequence of numbers. The sequence is: 1, 2, 3, 5, 8, 13, 20, 40 and 100.

When using this technique, software items (Product Backlog features) are grouped by size and
each group is assigned the same number on the scale.

When a size is going to be assigned to a Backlog element, it is necessary to compare it with the
other elements that are already in that same scale. If the experts judge that they coincide, they will
assign that scale, while if they are not, they should look in another of the sizes (PMOinformatica.com,
2018).

How to play Planning Poker

1. The entire agile team participates in the session. Each member receives a bunch of
Planning Poker cards.
2. The Product Owner presents the Product Backlog item to be estimated.
3. The development team discusses the item to estimate and asks the product owner
questions. The latter answers the questions.
4. Each estimator privately selects a card that will represent their estimate.
5. The cards selected by each estimator are displayed simultaneously.
6. If everyone has selected the same card, consensus will have been achieved. The result is
assigned as an estimate to the Product Backlog item.
7. If the estimates were not the same, a discussion is held focused on exposing the
premises taken in each estimate or misunderstandings. In general, one begins by asking
the highest and lowest estimators to explain and justify their estimates.
Models for the estimations 16

8. After discussion, return to step 3. The cycle will be repeated until consensus is reached
(PMOinformatica.com, 2018).
 Models for the estimations 17

Conclusion

The issue of estimation in software projects is of vital importance due to its contribution to the
satisfactory development of the projects. This article reviews the existing estimation models for
construction projects. software, showing the main characteristics of each of these models that allow the
estimation of cost, time and effort.

It is good to highlight, as a conclusion, that the selection of the estimation models to be used
varies according to the characteristics of the project and the experience and appreciation of those
responsible (planner - leader) for carrying out this task, however it becomes necessary to review the
various possible models to be used for the estimation, for the sake of a adequate selection that
guarantees favorable results.
 Models for the estimations 18

Bibliography
Fillottrani, P. R. (2007). Calidad en el Desarrollo de Software. Métricas de procesos de software.

Gómez, A. M. (1999). –COCOMO- UN MODELO DE ESTIMACION DE PROYECTOS DE SOFTWARE.

PMOinformatica.com. (2018, Agosto 27). 10 Técnicas de estimación de software. Retrieved from

http://www.pmoinformatica.com/2018/08/tecnicas-estimacion-software.html