Estimating Software Projects

and

How to ensure EVM operates well for software projects


Introduction: Software Estimation is calculating the overall effort required to complete a software project/ product. Since human resource is the most important resource in transforming the user requirements to software product the estimation should be accurate. This essay gives and overview of different models used in estimating software projects and use of each model in different projects. And finally I explain how earned value management is used as a tool to measure the progress in software development efforts and key issues of the EVM implementation process.


Software project is difficult to estimate accurately because of the uncertainties that exist in the whole process of software development life cycle.


Why software is hard to estimate? (1)Because the requirements are hard to state precisely (2) Product is essentially invisible until finished.(3) Hard to measure (4) Acceptability depends on the customers taste (Richard D. Stutzke, 2005 p12).


The unprecedented nature of software intensive systems and products, the knowledge intensive nature of software development and rapid evolution of hardware and software technology used to contract them present estimation with two significant challenges ( Richard, 2005 p 12 ).


Initial estimates are inaccurate because of imperfect knowledge, incorrect assumptions and omissions. The estimators knowledge of product, project and process improve with time as illustrated in funnel curve (Richard, 2005, p20).


As the development effort is in progress some of the requirements of the project may change due to which the estimation efforts will also change and therefore the estimator is doing an update on the estimation and this becomes and ongoing process ( Richard, 2005. p20).


Different models are available to estimate software projects. But software projects being complex and uncertain Project Manager must chose the right model depending the size and complexity of the project. A large and complex project has other issues to be considered besides programming effort. We discuss briefly the top down and bottom up approach of estimating.


Bottom up Model: Bottom up approach is done by breaking the total project to manageable small tasks (these small tasks can then be further broken down into sub-tasks), calculating the effort required for each of these tasks and then adding the efforts calculated for all tasks. This gives us the total project estimate.


Bottom up approach is the most appropriate at the later, more detailed stages of project planning. (Bob Huges and Mike Cotterell 2002 p86 ).


The estimator makes assumptions if this model is applied for estimation in the early stages of the project. (Bob Hughes et. Al. 2002 p86)


Top Down Model : The top down method is useful for quickly estimating the total resources required for some object ( project ) and allocating this total to lower level objects ( such as project activities or subsystems). These estimates may be sufficient for early planning (Richard, 2005. p341)


You can use top down method to estimate effort, cost schedule for project tasks. You can also use it to estimate the projects average staffing level and staffing profile.( Richard, 2005. p341 )


Total effort for all tasks performed by a project team is first between the start and end of the project (EDEV) is determined first and then used to determines the number of full time equivalent workers.( Richard, 2005. p342).


FTE= Effort / Duration

FTE=EDEV/TDEV (Richard, 2005 p342)

FTE=EDEV/(R*TDUR) (Richard, 2005. p 342)


The above require conversion of calendar days to work days to calculate the total duration.


Relation between effort, time and staffing is shown in this model. This is used for approximate estimation of the development time. ( Richard, 2005 p 343 ).


A good WBS for large projects is important in the Bottom up approach as the breaking down of tasks for large projects with WBS makes way for estimating these tasks accurately and avoids duplicate estimation of tasks. WBS structure is the decomposition of project in groupings such as deliverables. The lowest level of work is the unit of work assigned to a person out of which a deliverable is produced.


Expert Judgment: Estimating by expert judgment is purely based on the experience and expertise of the Project Manager or Estimator. The advantage of this method is it is quick estimating method. This method is not hundred percent accurate unless he is basing his judgment on similar projects. This method can be used for enhancement projects (carrying out changes/improvements to existing project/software application).


Estimating by Analogy: Estimating by analogy is again trying to compare the project you are estimating to past similar projects, and if found to be close with minor differences the differences are adjusted.


COCOMO Model: The COCOMO model is the most complete and thoroughly documented model used in effort estimation ( James et.Al. 2000 p 571)


COCOMO model is based exclusively on the program size expressed in KDSI. The underlying formula assumes the form (James F. Peters and Witold Pedrycz, 2000 p571).


Effort = a * KDLOC ( to the power b ) ( James et.Al. 2000 p571)


The basic COCOMO model was found not be very accurate and therefore improvements were made to the basic model. The improvements in COCOMO Intermediate model came in the form of attributes to the product. The estimator has to give a rating to the attributes using a six point scale. Later came the COCOMO II model.


COCOMO II model uses “Object” concept whereby each of the screens and reports are treated as objects and these objects are classified into three different complexity levels. weightage is given to these objects are counted by multiplying the number of points by the weightage factor and thus the total object points are counted. This value of the Object points obtained is adjusted by the amount of code reuse.


NOP= (Object points ) X {(100-%reuse)/100} (Roger S. Pressman, 2005 p661)


Identification of key estimating metrics is important. For example if we are doing .Net code development primary object classes become a key metric. If it is database work we are estimating then transaction, table and attributes are key metrics and for user interface work the number of screens (Webforms) is key.


Function Point Model: These class of models are referred to as Albercht’s function points. This is related to requirements specification documents where the functionality of software system is determined. In essence, such function point models are based on visible features of the system that are weighted accordingly to produce an over all score. (James et.Al. 2000 p 565).


According to IFPUG we can describe software using only five components that fall into two types of functions ( data functions and transactional functions ). Example of data and transaction function is given in Figure 1. (www.ifpug.org)


External Inputs: Inputs from user that provide distinct application oriented data

External Outputs: These are directed to the user in the form of various reports or messages.

External files: This deals with all machine readable interfaces to other systems.

Interface files: These are the Master files in the system. (James et.Al. 2000 p 565)

User inquiries: These are interactive inputs requiring response. (James et.Al. 2000 p 565)


There is a separate matrix that needs to be used when estimating complexity and calculating Unadjusted Function Point. Matrix is shown in Figure 2 ( James et.Al. 2000 p 565 ).


This model is developed based on what the software product is supposed to do. This means that the each function point is the function the software is going to perform. This is the basis of function point analysis.


There are some points to be made above the use of function point models, hopefully they help avoid eventual pitfalls associated with these models.( James et.Al. 2000 p 569)




This is because the function point analysis estimates from the user’s point of view. The function point analysis may vary based on the programming language used, the experience and skill of developers and organizations.


Earned Value Measurement: Earned value analysis is based on assigning a ‘value’ to each task or work package (as identified in the WBS) based on the original expenditure forecasts. The assigned value is the original budgeted cost for the item and is known as the baseline budget or budgeted cost of work scheduled ( Bob Hughes et. Al. 2002 p182).


Earned value is the value credited to a project for all the tasks that have been completed at any point during the project ( Bob Hughes et. Al. 2002 p182).


Before the start of the project we must ensure that the work break down structure is accurate and we should be aware of what we need to measure. A training session to all team members is required on earned value analysis to make sure that all team members are aware of this measurement technique and how to apply this technique to ensure that the Project manager is being reported correctly.


Earned value Management is a method for integrating work scope, schedule and budget and for measuring project performance. It compares the amount of work that was planned with was actually accomplished to determine if cost and schedule performance were achieved as planned ( Paul Solomon, 2002 p1)


The most common techniques of earned value in software projects are (i) 0/100 technique (ii) 50/50 technique (iii) the milestone technique. In 0/100 technique the value assigned to a task till it is completed is zero, in 50/50 technique the value assigned to a task is 50% as soon as it is started and given a value of 100% once completed. In the milestone technique the value to the task is given based on the achievements based on milestones ( Bob Hughes et. Al. 2002 p 182)


The most accurate method would be the milestone technique where you assign value percentages to each milestone. For quality purposes reporting the output of a task is important rather than the task itself. The Project Manager can implement a Task Detail worksheet and update the information every week on the progress of tasks associated with each module.


Earned value measurement is more of a Project Manager’s tool rather than a tool which the team members use themselves. Project Team leaders are the key in implementing and driving the Earned Value Measurement process so it is imperative that the Project Manager ensures that Project Leaders are well educated on the importance and significance of earned value measurement process and the importance of accurate reporting.

Conclusion: Estimating software projects is very difficult compared to other industry projects. The choice of estimation model depends on the Project Manager who decides on the model based on type of project in terms of its size and complexity. In most cases the Project Manager uses more than one estimation model to cross check with other estimates. Some Project Managers prefer to use automated estimation tools. Estimation tools have proven to be accurate in most cases and there is increase in the use of estimation tools these days. Each of the models discussed have their disadvantages and advantages. Function point analysis though widely accepted has the disadvantage that it has to be counted manually and thereby time consuming and expensive. The more the function points (in 1000’s) the more the time and cost for estimating. Estimates for Projects with thousands of function points can be done with state of the art estimation tools which are available in the market.


References


  1. Richard D. Stutzke, Estimating Software Intensive Systems, Addison Wesley, 2005.


  1. Bob Huges and Mike Cotterell, Software Project Management, McGraw-Hill , 2002.


  1. James F. Peters and Witold Pedrycz, Software Engineering – An Engineering Approach, John Willey and Sons, 2000.


  1. Leszek A. Maciaszek and Bruc Lee Liong, Practical Software Engineering, Addison-Wesley, 2005.


  1. Capers Jones, http://www.stsc.hill.af.mil/crosstalk/2005/04/0504Jones.html


  1. Roger S. Pressman, Software Engineering, McGraw Hill, 2005


  1. http://www.ifpug.org


  1. Paul Solomon, Using CMMI to Improve Earned Value Management, Technical Note CMU/SEI-2002-TN-016, Carnegie Mellon University, 2002.



About the Author: Venkat Madireddy worked as IT Consultant with Mindteck Singapore from 2004 to 2006. He holds a Bachelors Degree in Electronics Engineering and an MBA in Operations Management and International Business from India. He is also Project Management Certified from PMI. He is based in Singapore.

1