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

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

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.

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

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.

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

• Function Point Analysis Calculator
• COCOMO II Calculator

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