Top 10 Crucial steps for software project

estimation success
Software project estimation is a sophisticated task requiring real experience and
collaboration of various parties. Without sufficient internal resources including
personnel to appropriately evaluate the software project, final results may turn out to
be unfavorable, over-budget, and time-wasting.
What is software project estimation?

Literally, estimation is a process to predict the time and the cost that a project
requires to be finished appropriately. But in terms of software development, it also
means of consideration of the experience of the software development company; the
technique they employ; the process they may go through to finish the task. This
whole process requires the use of complex tools and good mathematical background
knowledge. It is in some cases is the accomplishment of the hard work of a whole
team. The error margin is, consequently, guaranteed possibly around 5-10%.

The whole process of estimation would cost the company rather considerable cost
and time at the very first stage of building an app. But this will make the final result
more credible, realistic, and customer-satisfying. Projects especially big ones are
advised to employ this crucial step to avoid unpredictable failure.

1. Determining the goals and commitments:

Similar to going on the road, you should be very clear about your final destination
before setting off. Communicating clearly the goals or the needs of yours with the
estimation team would well guide the whole process to the right place it is expected
to be.

Communication of the goals clearly also allows both the estimation team and the
software development company to vision the reality of all the requirements. They,
therefore, would plan an appropriate timeline, personnel and employ the suitable
technologies to achieve the goals in the most fruitful way. Basing on those
mentioned, terms and agreements between the customers and the app developing
team would be set.

2. Comprehending the functional scope of the

project: 
The most essential factor for sizing a project is to determine what you want to
develop and what would it reach. In some cases, there would be breakdowns in
functions according to reference documentation. This lets you know in-depth about
the possible extent and elements of the system which will be estimated.

However, in some cases, the estimation task becomes much more uncertain and
complex. Then, it is necessary that the estimator should follow the following steps to
get out.

 Foster communication to enhance comprehension.

 Learn from the existing similar system.
 Spend more effort in studying the industry and the type of project.
 Review the validation and prioritize created functional requirements created.

3. Paying attention to non-functional needs:

These functions focus on the “how” the project might work to meet the requirements
of the customers which are usually left unaddressed when determining the functional
requirements.

Followings are some of the typical non-function requirements software estimation

process usually left unattended:

 Maintainability
 Scalability
 Security
 Interoperability
 Performance
 High availability
 Usability

These non-functional requirements may account for different importance depending

on the type of project or industry. Also, the complexity and the context of different
projects could vary the role of the about mentioned functions

4. Setting clear priorities:

The estimations and limits of the project as money, time, or personnel make
obtaining the planned goals much more complex. In these situations, it is important
to clarify the utmost importance of each functional priority in order to focus on the
most essential ones.

Estimating clearly the priorities from the beginning would also keep the project more
on track. Not many changes and additional requirements occur during the time of
making the software, which would save a lot of time and effort.
5. Considering goals and commitments in agile plans:
Agile methodology is a contemporary developing method that allows customers
and app development centers to continuously communicate and make changes to
their products throughout the process of development. Iterative sprints of delivery
enable customers to see their final product as well as how it functions.

They, then, could make modifications to their requirement which have been agreed
on in the previous stages. This method provides flexibility to the customers but
requires the company to have a highly skilled development team to continuously
adapt to the changing needs. Also, Agile is most likely suit for small-scale projects.

Read more about Agile methodology:  Why does Agile stand out as the most favorable
app development method?

6. Choosing estimation strategies:

Depending on the type of project, its complexity, the information present, the
number of requirements, and the delivery times of the estimation, it is necessary to
think and choose the right strategy. We can look at some of these here:

There are plenty of estimation strategies that estimators could employ. But, firstly,
they could take into consideration the complexity of the project, the amount of
information acquired, and time constraints. An appropriate combination of those
things could result in the estimating approaches as follows:

Classic estimation (expert judgment): This is likely the most common way, and it
includes selecting a requirement and allocates it a time value based on the difficulty
and how experienced the estimators are in the required field. The estimation team is
advised to break down the requirements into more detailed components including
business, presentation, and database. Then, a suitable amount of time will be
allocated for each of them. The final estimation is then the combination of smaller
ones from the mentioned elements.  

Note: This strategy is favorable and advisable to be used when a sufficient amount of

time is allowed and the number of requirements to estimate is considerable.

Estimation by order of complexity:

 This is just the process of ordering the requirement based on their complexity.
 Then, use the traditional model to estimate a representative sample of all the
requirements.
  Next, the value of the traditional estimations from the requirements from the
previous step would be extrapolated, also according to complexity order. For
instance, we have 100 requirements and the estimation process is as the
following steps:

1. Complexity order assigned for all the requirements (e.g., Scalability:

1,2,3,5,7,12).
2. Use traditional estimation to evaluate the representative requirements (e.g.,
11).
3. The complexity of the overall project is the average of the subset
requirements (e.g., 3 representatives have the complexity of 2, these 3
estimations are averaged).
4. The estimated value of non-estimated requirements is also taken and
assigned.

Note: This strategy of estimation is suitable for projects with a large number of
requirements.

Estimation based on analogy: This estimation strategy is an approach that allows a

company to build an estimation of the current project based on the similar one or
ones they have carried on before. This to some extent will save a great deal of time
and resources but also requires the company to have the following to ensure a
similar outcome:

 Hand-on and extensive experience.

 A good and comprehensive record of the previous projects.
 Knowledgebase to analyze and recognize similar projects.
 The estimators must be trained to adapt the analogous estimations and
manage the knowledge repository.
 Adapt of the analogous estimations and management of knowledge
repository

Estimation by team: This approach is partially similar to the classic one. The only
difference is that the smaller components as system module, business, presentation,
etc., will be delegated to separate teams. Each team will independently offer their
estimation. And the final result will be consolidated by the combination of individual
results of the teams.

Note: This strategy of estimation is used for projects with an average number of

requirements.

7. Recognizing AND address possible assumptions:

It is not possible to list down all the possible assumptions during the estimation
process. But it is advisable to address the more of them the better to avoid
possibilities of uncertainties. This will enhance the common understanding of the
parties involving in the process of estimation.

8. Revising estimations:
Two heads are better than one. Revision with other estimators during the software
estimation project help foresee the possibility of the projects, the possible
assumptions, and the best estimation strategy. The only downside of this could be
that the time constraint. More people, more ideas.

You, then, have to be strong enough to selectively choose which advice and change
to carry on.

9. Employing estimation tools:

Software project estimation companies now could make use of tools to facilitate their
estimating. With the assistance of tools, their work would be more systematic, and
automatic. The process of estimation would cost less time and make it much easier
to make reports and store data for future projects.

10. Noting for special projects:

The projects with a number of special requirements require of course more
specialized hands to be accomplished appropriately. Then, the common tasks
– software testing, analysis, infrastructure, development-which are usually taken care
of by the estimation team have to be exclusively cared for by the high-profiled
testers, designers, analysts.

Conclusion:

Software project estimation is not a big task. It is advisable to gather a team of

estimators experienced in various industries and kinds of projects. The team could
work collaboratively to obtain clear understandings of the scale, objectives, and
commitments and to utilize the recommendations to reduce uncertainties to get the
most accurate estimation.
5 Steps to Software Development
Effort Estimation

The software development effort estimation is an essential activity before

any software project initiation. In this article, I will illustrate how to easily
estimate the software effort using known estimation techniques which
are Function Points Analysis (FPA) and Constructive Cost Model
(COCOMO).

What is Estimation and why it is

important?
The estimation is a process to find the most accurate sizing figure for the
software project effort, for example, how many months you will need to
develop the software, how many resources you will need to finish the
project in the required time. And this translated to money at the end.

The estimation is important because it gives the project team some

confidence about the required effort and time to plan ahead for the project.
Moreover, not all software project is time and material contracts, some of
them are fixed cost projects and this estimate will be used as a foundation
to negotiate the project cost.

The Estimation Process

As mentioned the estimation is a process and this process contains the
following steps to reach the estimate, this process is cycling until you reach
the final estimate for the project.
1- Scoping
You need first to scope the project even if you do not have the full detailed
requirements but you can assume some of them or add margins later. While
in most cases you will have a defined scope to start with. You can read
this article to understand what is the scope and how it is different from the
requirements specifications.

You can always list your assumptions to justify the outcome of the
estimation process and its results.

2- Decomposition
In this step, you will need to break your software into smaller components
and functions and you can categorize them to a different set of elements,
this is similar to work breakdown structure but only for the software
components not all the working activities for the software.

You may also collect different data from the project team or the customer to
ensure that you have listed all functionalities.

3- Sizing
In this step, the actual estimation will be done for each component alone,
and I will illustrate more about how you will do that using the techniques
mentioned above, this will be illustrated in 8 steps in details below.

In this step, and for more validation, you can use different estimation
techniques to analyze the different estimation outputs and you may take an
average of these estimates as well.

4- Expert and Peer Review

After initial estimate, you will need at some point to ask for expert opinion
for some new functionalities you may not aware off, or for considering a
review from your peers that you have done the correct estimation.
Moreover, you may need to do some analogy based techniques for similar
components or functions developed before or maybe a similar project to
ensure that you are on the correct path.

5- Estimation Finalization
This can be considered the final step as you aggregate all the estimations
from all components and functions and have a baseline estimate. You can
go another round across the process until reaching the correct estimate
which will be approved by the Project team and the Management as well.

How to Size
Before we start by describing the 8 sizing steps let us introduce briefly the
techniques we will use to size the project effort.

Function Points Analysis

Function Point Analysis (FPA) is a sizing measure of clear business
significance. First made public by Allan Albrecht of IBM in 1979. It depends
mainly on estimation the lines of code for the software which is also
considered as a critic for this technique.

FPA can be helpful to estimate the effort for a software project at the early
stage when the requirements are known, but the details of implementation
have not yet been specified or evaluated. Which is actually the most case of
the software projects 🙂

To use the FPA, these are the steps to follow after defining the scope and
decompose the system functionality and components:
 1. Identify inputs, outputs, file accesses and interfaces to external
systems
2. Determine the functional complexity of each function
3. Calculate unadjusted FPs by summing weightings
4. Calculate Value Adjustment Factor for the software
5. Apply VAF to UFP to calculate adjusted FPs

Constructive Cost Model (COCOMO)

The Constructive Cost Model (COCOMO) is a procedural software cost
estimation model developed by Barry W. Boehm

Program size is expressed in estimated thousands of source lines of code

(KLOC). COCOMO applies to three classes of software projects:

 Organic projects – “small” teams with “good” experience working

with “less than rigid” requirements.
 Semi-detached projects – “medium” teams with mixed
experience working with a mix of rigid and less than rigid
requirements.
 Embedded projects – developed within a set of “tight” constraints.
It is also a combination of organic and semi-detached projects.
(hardware, software, operational, …)

COCOMO is used for estimating the development effort and time.

Let us start
Step 1
We will start with the FPA after we scoped the requirements and
decompose the functions, we are ready to identify the inputs, outputs, file
accesses and interfaces to external systems. FPA is measured based on
these below elements:

1. Internal Logical Files (ILF): It is a group of logically related

data that is stored and maintained within the application, for
example, databases and files
2. External Interface Files (EIF): is a group of logically related
data that will be used by the application. The difference that these
data will not be maintained in the application, for example,
external databases.
 3. External Input (EI): It is mainly the data transactions which will
be inserted into the application from outside the application
boundary, for example, Data entry process.
4. External Output (EO): It is mainly the output of the system
functions, for example, a transactional data into the database,
messages or a report
5. External Inquiry(EQ): It used to present information to a user
through the retrieval of data from ILF or EIF, for example, search
queries, or exporting a report

The image below, illustrate the software context based on FPA, and how
other users or systems interact with our software. Now, we will need to list
the 5 elements for each subsystem, component, or function to do the next
step.

Software Context

FPA classifies the complexity of each function type as below

Complexity

Function type Simple (S) Average (A) Complex (C)

Internal Logical File 7 10 15

External Interface File 5 7 10

External Input 3 4 6
External Output 4 5 7

External Inquiry 3 4 6

Step 2
The next step is to relate our functions to these complexity levels and apply
the weightings for each one, for example, let us assume that we have the
following outcome from our functional points

Components Inputs Outputs Files Inquiries Interfaces

List (EI) (EO) (ILF) (EQ) (EIF)

1 S*4 = 4 2 A*10
Component 1 1 S*3 = 3 2 S*3 = 6 1 C*10 = 10
2 C*7 = 14 = 20

2 A*4 = 8 1 C*15 =
Component 2 3 A*5 = 15 2 A*4 = 8 2 S*5 = 10
1 C*6 = 6 15

3 A*4 =
12 1 S*7 =
Component 3 3 S*4 = 12 – 2 A*7 = 14
2 C*6 = 7
12

As we can see in the table, that we have 3 components and after we applied
the weights for each one, we can see that each one can have more than one
input for example, and we can estimate each input weight according to our
judgment of this input complexity. In component 3 we have 3 average
inputs and 2 complex input but we do not have any inquiries.
Step 3
You can do the same for all the software components or functions and this
will lead us to the next step of calculating the unadjusted function points by
summation of all weights

Unadjusted Function Points (UFP) = (n × EI) + (n × EO) + (n ×

EQ) + (n × ILF) + (n × EIF)

In the example above the UFP = 176

Step 4
The next step, we will need to calculate Value Adjustment Factor, the VAF
consists of 14 General System Characteristics (GSCs) which are listed
below, These GSCs represent characteristics of the application under
consideration how the degree of influence for each factor on the system.

# Technical factors Brief Description

How many communication facilities are there to
Data
F1 aid in the transfer or exchange of information
communications
with the application or system?
Distributed data How are distributed data and processing
F2.
processing functions handled?
Did the user require response time or
F3. Performance
throughput?
Heavily used How heavily used is the current hardware
F4.
configuration platform where the application will be executed?
How frequently are transactions executed daily,
F5. Transaction rate
weekly, monthly, etc.?
What percentage of the information is entered
F6. On-Line data entry
On-Line?
Was the application designed for end-user
F7. End-user efficiency
efficiency?
How many ILF’s are updated by the On-Line
F8. On-Line update
transaction?
Does the application have extensive logical or
F9. Complex processing
mathematical processing?
Was the application developed to meet one or
F10. Reusability
many users needs?
F11. Installation Ease How difficult are conversion and installation?
How effective and/or automated are a start-up,
F12. Operational ease
back up, and recovery procedures?
How the application was specifically designed,
F13. Multiple sites developed, and supported to be installed at
multiple sites for multiple organizations?
Was the application specifically designed,
F14. Facilitate change
developed, and supported to facilitate change?
Each factor may have a value within 0 (no influence) to 5 (strong influence)
to calculate the Total Degree of Influence (TDI). The VAF can vary in range
from 0.65 (when all GSCs have no influence) to 1.35 (when all GSCs have
strong influence) according to the equation below

VAF = 0.65 + (∑_(i=1)^14 Fi * 0.01)

Let us assume that we considered the influence of the GSCs and

we calculated the VAF as follow:

VAF = 0.65 + ((1+4+5+4+1+0+2+4+3+4+4+1+1+1) * 0.01) = 0.65 + 0.35

=1
Step 5
So, this will lead us to the final step of FPA which to calculate The Adjusted
Function Points:

AFP = UFP * VAF = 176*1 = 176

Step 6
Now, we are ready to use the COCOMO estimation technique, this model is
based on KLOC and to obtain our software KLOC, we will use the output
from the functions points analysis.

According to Quantitative Software Management, they created a table

contains updated function point language gearing factors for 37 distinct
programming languages/technologies. We will use this table to calculate
the KLOC by using this equation

KLines of code (KLOC) = AFP * QSM Index (programming

language) / 1000

We assume that we will use .NET programming language, according to

QSM table the average of .NET is 57

KLOC = 176 * 57 / 1000 ≈ 10 KLOC

Step 7
According to COCOMO Complexity, the software effort is calculated based
on predetermined coefficients based on complexity and, lines of code, for
example, if we considered that we are using organic project type our
calculation will be as follow:

Effort Applied (E)= a*(KLOC)^b = 3.2 * (10) ^ 1.05 ≈ 35 Person

Months

Development Time (T) = c*(Effort Applied)^d = 2.5 * ( 35) ^ 0.38 ≈ 9.7

Months
Software Project a b c d

Organic 3.2 1.05 2.5 0.38

Semi-detached 3 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

People required (P) = Effort Applied / Development Time = 35/9.7

≈ +/- 3.6 Persons

Development Productivity = LOC/Effort Applied = 10,000/35 ≈ 286

LOC/Person Month

We have calculated this without calculating the Effort Adjustment Factor

(EAF), Intermediate COCOMO provides 15 attributes rated on a six-point
scale that ranges from “very low” to “extra high”, these 15 attributes called
the cost drivers. For each one of them, you can describe how the project is
related to this attribute, for example, Required development schedule
which is 10 months we can select a nominal value for this attribute.

Cost Drivers Ratings

Very Very Extra

Low Nominal High
Low High High
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of the application
0.94 1.00 1.08 1.16
database
The complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance
1.00 1.11 1.30 1.66
constraints
Memory constraints 1.00 1.06 1.21 1.56
The volatility of the virtual
0.87 1.00 1.15 1.30
machine environment
Required turnabout time 0.87 1.00 1.07 1.15
Personal attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language
1.14 1.07 1.00 0.95
experience
Project attributes
Application of software
1.24 1.10 1.00 0.91 0.82
engineering methods
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development
1.23 1.08 1.00 1.04 1.10
schedule
After identifying the weights for all cost drivers, you can multiply all of
them to get the EAF. Then, we can now calculate the adjusted effort
according to the below equation:

The adjusted effort applied = a*(KLOC)^b * EAF

If we assume that our EAF is 1.17 then the adjusted effort will equal to 35 *
1.17 ≈ 41 Person Months. After that, you can recalculate all the other values
again. The first calculation is called the Basic COCOMO while the second is
considered the Intermediate COCOMO.
Step 8
Now, we can apply the cost estimate by calculating the cost of every staffed
person * Effort Applied, for example, if all staff have fixed 2K $ Person
Month the cost will be

2,000 * 35 = 70K $

Conclusion
You can apply the same methodology to get the estimate for the project and
you can go deeper and estimate each component alone to get more accurate
figure, for example, if you have integration, testing, development of a
portal, development of backend, you can consider each one a separate
project and estimate the schedule and effort for each of them. I hope you
have learned a new thing by reading this article and below are some
references and some useful links as well.
Cite this article as: Mohamed Sami, (January 15, 2018). "5 Steps to
Software Development Effort Estimation," in Mohamed Sami - Personal
blog. Retrieved September 12, 2021,
from https://melsatar.blog/2018/01/15/5-steps-to-software-development-
effort-estimation/.

References
 COCOMO. (2018, January 07). Retrieved January 13, 2018,
from https://en.wikipedia.org/wiki/COCOMO
 Function point. (2017, December 14). Retrieved January 13, 2018,
from https://en.wikipedia.org/wiki/Function_point
 How does FPA work? (n.d.). Retrieved January 13, 2018,
from https://nesma.org/themes/sizing/function-point-analysis/fp
a-work/
 Overview of COCOMO. (n.d.). Retrieved January 13, 2018,
from http://www.softstarsystems.com/overview.htm

Useful Links
 Function
Point Analysis Calculator
 COCOMO II Calculator

Problems with over and underestimates

Last Updated on Thu, 26 Aug 2021 | Software Project

Parkinson's law was originally expounded in C. Northcote Parkinson's tongue-in-

cheek book Parkinson's Law, John Murray, 1957.
A project leader such as Amanda will need to be aware that the estimate itself, if
known to the development team, will influence the time required to implement the
system. An over-estimate might cause the project to take longer than it would
otherwise. This can be explained by the application of two 'laws'.

Parkinson's Law 'Work expands to fill the time available', which implies that given an
easy target staff will work less hard.

Brooks' Law The effort required to implement a project will go up disproportionately

with the number of staff assigned to the project. As the project team grows in size
so will the effort that has to go into management, co-ordination and communication.
This has given rise, in extreme cases, to the notion of Brooks'
Law: 'putting more people on a late job makes it later'. If there is an over-estimate of
the effort required then this might lead to more staff being allocated than are needed
and managerial overheads will be increased. This is more likely to be of significance
with large projects.
Some have suggested that while the under-estimated project might not be
completed on time or to cost, it might still be implemented in a shorter time than a
project with a more generous estimate. There must, however, be limits to this
phenomenon where all the slack in the project is taken up.

The danger with the under-estimate is the effect on quality. Staff, particularly those
with less experience, might respond to pressing deadlines by producing work which
is sub-standard. Since we are into laws, this might be seen as a manifestation of
Weinberg's zeroth law of reliability: 'if a system does not have to

Brooks' law comes from The Mythical Man-month that has been referred to already.

See T. K. Hamid and S. E. Madnick 'Lessons learnt from modeling the dynamics of
software development' in C. F. Kemerer (ed.) Software Project Management, Irwin,
1997.

Barry Boehm devised the COCOMO estimating models, which are described later in

this chapter.

be reliable, it can meet any other objective'. In other words, if there is no need for the
program actually to work, you can meet any programming deadline that might be set!
Sub-standard work might only become visible at the later, testing, phases of a
project, which are particularly difficult to control and where extensive rework can
have catastrophic consequences for the project completion date.

Because of the possible effects on the behaviour of development staff caused by the
size of estimates, they might be artificially reduced by their managers to increase
pressure on staff. This will work only where staff are unaware that this has been
done. Research has found that motivation and morale are enhanced where targets
are achievable. If, over a period of time, staff become aware that the targets set are
unattainable and that projects are routinely not meeting their published targets, then
this will help to destroy motivation. Furthermore, people like to think of themselves
as winners and there is a general tendency to put success down to our own efforts,
while failure is blamed on the organization.

In the end, an estimate is not really a prediction, it is a management goal. Barry

Boehm has suggested that if a software development cost is within 20% of the
estimated cost estimate for the job then a good manager can turn it into a self-
fulfilling prophecy. A project leader like Amanda will work hard to make the actual
performance conform to the estimate.