Introduction to Software Estimation Tutorial

1.2 Introduction to Software Estimation

Hello and welcome to software estimation course offered by Simplilearn. We will cover some important concepts and techniques in the field of software sizing and effort estimation.
In the next 2 days we will cover the basics of software sizing and effort estimation followed by some widely used sizing techniques. This course is divided into 7 modules. The first module will introduce us to software estimation, in the second module we will understand function point analysis (FPA), and the third module is about the components of function point analysis. We will then move on to Module 4 which deals with counting rules, which will be followed by summarizing FPA in the fifth module, in the sixth module we will understand the flavors of function points and NESMA (pronounce as nes-ma), and the seventh and the last module is about other estimation techniques.
Let us begin by looking into the agenda of the topics.

1.3 Agenda

In this module, we will start with the basic question of “What is Software Size?” After that we will understand the major differences between software sizing and software estimation, followed by the relationship between the two. Then we will find out the various categories and types of sizing techniques along with the benefits of a good estimation.
Let us find out what software size is.

1.4 Software Size

What does the term “software size” mean?
Size is a unit of measurement to measure the quantity possessed by an entity. It represents the inherent characteristics of a software application.
Consider the example of a box.
The volume of the box is measured by calculating its size – the length, breadth, and the height of the box.
It is the same for any object around us and they have various units of measurement like length, weight, height, distance, time, etc.
How is software application measured? There are various units of measures used for describing the size of a software application. Some of the widely used ones are lines of code, function points, complexity points, story points, etc.
These topics will be dealt with in detail in due course.
We will understand the differences between sizing and estimation in the next slide.

1.5 Sizing vs Estimation

This is a common misconception that most software professionals, new to the science of estimation have; software sizing and effort estimation are not the same.
Sizing is a formal, usually a scientific way of measuring the size of a software application. Most sizing techniques are algorithmic based, and is consistently understood irrespective of who is performing the activity.
In case of estimation, it is an activity where a lot of assumptions and rationale play a vital role. The experience of the person performing the activity impacts the effort estimate.
Sizing is done to count the size of the application; whereas estimation is used to estimate the effort taken to develop the application.
For example: Consider the case of a person traveling from point A to point B. The distance between the two points and the time taken to cover the distance has to be calculated.
What would be the typical approach? First, the distance between A and B will be measured in terms of miles, kilometers, yards, etc. Now assume the distance is measured as 2 miles. Irrespective of whom this question is asked to, they would find that the distance is always 2 miles, on the condition that the standard measuring tool is used.
Now, how is the time required to cover the distance determined? The person’s past experience of travelling the same distance have to be taken into account. Or, the person may refer or ask a friend how much time it would take to cover the distance. Various assumptions and constraints like traffic, mode of transportation, weather information, etc., will also be considered.
The point to note is that the final figure would differ based on the assumptions various people would make.
Similarly, for the case of sizing and effort estimation, sizing is like determining the distance, and estimation is like determining the time. The way a person does sizing would be fairly consistent, based on the sizing technique. However during effort estimation, many factors influence the decision. Factors like team’s productivity; complexity of the scope of work; past experience; etc., leads to a variation in the effort estimates.
In the next slide, we will understand the flow-down of size to other estimates.

1.6 Flow Down of Size to Other Estimates

Sizing and effort estimation is different. While sizing is usually an algorithmic, structured exercise; many considerations, assumptions, and risks are involved in the case of effort estimation. Size forms the base; for deriving the effort estimate, estimated cost, estimated duration, and finally, to draw up the schedule.
Usually, size is determined using the different sizing techniques covered in the next slide. For example, as shown in the slide, consider the size of a retail application derived as 1000 function points. Based on this size, the effort is estimated. This is done by dividing the size by the past productivity baseline. Usually, organizations maintain baselines of their productivity based on data collected from past projects. For example, consider that the current productivity baseline is 5 function points per hour. Using this, the effort required to develop the application is determined; that is 1000 divided by 5 which equals 200 hours.
Do note that this is an estimate because the productivity baseline that is considered is based on the past data which has an underlying variation. This variation in the baseline impacts the overall estimated effort.
Once the effort has been estimated, the cost can be easily determined. This is done by multiplying the billing rate to the effort and including any additional costs like license procurement, margins, overhead costs, etc. In the example, consider that the average billing rate is 25 dollars per hour and other costs are 300 dollars. Thus, the total estimated cost is 200 multiplied by 25 plus 300 dollars which equals 5300 dollars.
The estimated duration for completion of the application development is also determined based on the number of people assigned, number of working days in a calendar month, and the number of working hours in a day. Consider that the number of people assigned is 2, the calendar days in a month is 22 (excluding weekends and holidays), and typical working hours in a day is 8hrs. Based on these and the estimated effort, the estimated duration would be 0.56 person months or 12 person days.
The final step in this process would be to develop the schedule. The schedule consists of the break-up of the tasks required to develop the application along with the resource allocation for each task. This is done using Work Breakdown Structure (WBS) where the overall development activity is divided into more granular tasks and the total estimated effort is split and allocated to each granular task.
As evident from this slide, sizing plays a pivotal role for determining effort, cost, and schedule. So, it is very important to understand various sizing techniques so that the appropriate technique can be used based on the scenario.
Various sizing techniques and their characteristics will be discussed in the next slide.

1.7 Sizing Techniques

Sizing techniques can be classified into three buckets.
The first category is called the “expert judgment methods”. Expert judgment techniques involve consulting with software estimation expert or a group of experts, and use their experience and understanding of the proposed project to arrive at an estimate. In these techniques, the experts perform estimation for the given specification anonymously and all their estimates are consolidated. Then, all the experts meet specifically to discuss the points where their estimates varied widely. Some of the widely used techniques in this category are Wide Band Delphi, and Planning Poker. Planning poker will be covered in later modules.
The next category is called “estimating by analogy”. Estimating by analogy means comparing the proposed project to previously completed similar project, where the project development information is known. Actual data from the completed projects are used to estimate the proposed project. Actually in some respects, it is a systematic form of expert judgment since experts often search for analogous situations while estimating. Some widely used analogy-based estimation models are Simple-Medium-Complex (SMC) Estimation techniques, 3-Point Estimation, etc. SMC technique will be covered in later modules.
The last category is called the “algorithmic methods”. The algorithmic method is designed to provide some mathematical equations or algorithms to perform estimation. The equations and algorithms are based on research, and use inputs like number of functions, language, design methodology, etc. Some of the algorithmic techniques widely used in the industry are IFPUG (pronounce as if-pug), Function Point Analysis, NESMA (pronounce as nes-ma), COCOMO (pronounce as co-co-mo), etc. FPA, NESMA and UCP Techniques will be covered in detail in the later modules.
One important aspect to be noted here is that the variation in the estimates reduces as one move towards algorithmic methods. The assumptions, while estimating is fairly less in algorithmic methods than in expert judgment methods.
The benefits of estimation are dealt with in the next slide.

1.8 Benefits of Estimation

Though there are various benefits of a good estimate before the application development starts, few key benefits are covered in this slide.
If the estimate is near-accurate, the collaboration between the various involved stakeholders like customer, project team, and senior management becomes better. All the stakeholders are in the same plane with respect to the duration and cost of the project. This ensures that there are no surprises for any of the stakeholders.
The next key benefit of good, structured estimates is that it improves the proposals. It makes the proposal very structured and efficient. By using a structured estimation technique and reviewing the estimates with subject matter experts, the bidding team can confidently approach the customer and bid for the projects with proper rationales.
For the organizations, process standardization is achieved with the projects using a standard estimation technique. This helps them to benchmark and compare the estimates of one project to that of the other. This also helps in developing professionals who are skilled on particular estimation techniques. Their skill can then be utilized for helping other project managers perform accurate estimation.
Good estimates can help the project manager have a better control of the cost and schedule. The project manager can track the progress of the project and take adequate actions in case of variation. In general, it helps in better project management. The project manager can manage the risks efficiently by identifying all potential risks during estimation.
Finally, estimation helps in improving customer satisfaction. Proper estimation helps in setting up mutual expectations between the customer and project team. This way, the customer is aware of the project progress and the expected completion of the project.
Let us summarize the module in the next slide.

1.9 Summary

With this, we have come to the end of Module 1. In this module, we started off with understanding what software size is. Software size is the unit of measurement to measure the quantity possessed within a software application. We then debunked a common misconception that software sizing and estimation are the same. While sizing is a structured means of counting the size of the application, estimation is determining the effort and time that is required to develop the application. We also learned that Size forms the base for deriving the effort estimate; estimated cost, estimated duration, and finally, to draw up the schedule. Sizing techniques can be classified into three buckets: expert judgment methods, estimating by analogy, and algorithmic methods. Finally, we found that some of the key benefits of estimation are collaboration among stakeholders, effective proposals, process standardization, better project management, etc.
In the next module, we will introduce the concept of IFPUG Function Point Analysis.