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:
- Identify inputs, outputs, file accesses and interfaces to external systems
- Determine the functional complexity of each function
- Calculate unadjusted FPs by summing weightings
- Calculate Value Adjustment Factor for the software
- 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:
- 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
- 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.
- 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.
- External Output (EO): It is mainly the output of the system functions, for example, a transactional data into the database, messages or a report
- 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 List |
Inputs (EI) |
Outputs (EO) |
Files (ILF) |
Inquiries (EQ) |
Interfaces (EIF) |
Component 1 |
1 S*3 = 3 |
1 S*4 = 4 2 C*7 = 14 |
2 A*10 = 20 |
2 S*3 = 6 |
1 C*10 = 10 |
Component 2 |
2 A*4 = 8 1 C*6 = 6 |
3 A*5 = 15 |
1 C*15 = 15 |
2 A*4 = 8 |
2 S*5 = 10 |
Component 3 |
3 A*4 = 12 2 C*6 = 12 |
3 S*4 = 12 |
1 S*7 = 7 |
– |
2 A*7 = 14 |
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 |
F1 | Data communications | How many communication facilities are there to aid in the transfer or exchange of information with the application or system? |
F2. | Distributed data processing | How are distributed data and processing functions handled? |
F3. | Performance | Did the user require response time or throughput? |
F4. | Heavily used configuration | How heavily used is the current hardware platform where the application will be executed? |
F5. | Transaction rate | How frequently are transactions executed daily, weekly, monthly, etc.? |
F6. | On-Line data entry | What percentage of the information is entered On-Line? |
F7. | End-user efficiency | Was the application designed for end-user efficiency? |
F8. | On-Line update | How many ILF’s are updated by the On-Line transaction? |
F9. | Complex processing | Does the application have extensive logical or mathematical processing? |
F10. | Reusability | Was the application developed to meet one or many users needs? |
F11. | Installation Ease | How difficult are conversion and installation? |
F12. | Operational ease | How effective and/or automated are a start-up, back up, and recovery procedures? |
F13. | Multiple sites | How the application was specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? |
F14. | Facilitate change | Was the application specifically designed, 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 Low | Low | Nominal | High | Very High | Extra High | |
Product attributes | ||||||
Required software reliability | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | |
Size of the application database | 0.94 | 1.00 | 1.08 | 1.16 | ||
The complexity of the product | 0.70 | 0.85 | 1.00 | 1.15 | 1.30 | 1.65 |
Hardware attributes | ||||||
Run-time performance constraints | 1.00 | 1.11 | 1.30 | 1.66 | ||
Memory constraints | 1.00 | 1.06 | 1.21 | 1.56 | ||
The volatility of the virtual machine environment | 0.87 | 1.00 | 1.15 | 1.30 | ||
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 experience | 1.14 | 1.07 | 1.00 | 0.95 | ||
Project attributes | ||||||
Application of software engineering methods | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | |
Use of software tools | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 | |
Required development schedule | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 |
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.
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/fpa-work/
- Overview of COCOMO. (n.d.). Retrieved January 13, 2018, from http://www.softstarsystems.com/overview.htm
Useful Links

Help to do more!
The content you read is available for free. If you’ve liked any of the articles at this site, please take a second to help us write more and more articles based on real experiences and maintain them for you and others. Your support will make it possible for us.
$10.00
Wow, that’s some solid math! Thanks for this piece, I really learned a lot. Estimations are hard and applying tried-and-tested formulas to help can really make things easier—and elevate transparency!
Recently, my colleague wrote an article about software estimations, but he focused on a financial side of things. If you’d like to take a look at how to compare prices and what to pay attention to while comparing the costs of different vendors.
Thank you for sharing
Excellent, helped me brush up and do some exercise before I hit the ground.
Thanks a lot for the article.
Great to know that it was helpful to you Manoj ☺️
Thank you ..So simple and understandable article .
Thank you
Nice
Thank you
hey
amazing content and it was very helpful and very well explained.
i am really impressed by the quality you have delivered through this blog.
great work! keep writing.It was of great help!
also check this out for more info on the same topic and related.
Thank you 🙂
Thank you