“Predicting the effort required to develop a software system is a key responsibility ofsoftware management and many estimation models have been proposed over recent years.Yet still, software cost estimation continues to be a weak link in software projectmanagement.”IntroductionAn accurate software cost estimation is a difficult achievement, with so many varying factorsinvolved. Any estimates are based on the initial requirements of a project and can varygreatly for different organisations depending on the business factors surrounding the contract.Are the developing company trying to break ground in a new sector, are they under financialstress, is there a lot of uncertainty regarding the estimate, are the requirements likely tochange or does the customer require full ownership of the source code. Any one of thesefactors will influence a company’s view on a contract estimation. Cost estimation iscommonly measured in time spent on the project (man months or years), while trying todetermine the size and complexity of the proposed system (Samuel Lee, 2002). Manytechniques have been created to assist in the process of creating an accurate cost estimationand the following report will take a brief look at some of the most popular models.Required effortThere are many factors to be considered when calculating the required effort for a softwareproject, the size of the product, difficulty of the product, expertise of the developers, theeffectiveness of tools and the level of software reuse. It is not uncommon for the effortrequired to be underestimated by up to 50% (BELL, 2005).MeasurementIt is a difficult task to estimate the size of the project and the rate at which software isdeveloped, with the manager depending on their own experience and expertise in interpretingthe projects proposal and requirements. The manager must consider the engineers rate ofproductivity of both software and documentation. The productivity of the developers will alsovary depending on the level of language the system will be developed in. There are a numberof methods to measure software productivity with one of the earliest being based on lines ofcode (LOC). However, with the development of 4th generation languages this has becomemuch more difficult as some statements can span several lines or several statements can becontained on one line. Function points are another method of measurement which representthe number of external inputs and outputs, user interaction, external interfaces and files usedby the system (Sommerville, 2009). Object points are an alternative to function points whenusing 4GLs, they are based on the number of screens, reports and language components(Hareton Leung, 2002).Estimation techniquesMany techniques have been developed to aid in the estimation process, the accuracy of whichis dependant on the interpretation of the projects initial requirements by themanagers/experts.Algorithmic cost modellingThe use of mathematical equations to estimate the cost of software based on historical data.One of the most recognised models, the COCOMO, which having been originally developedin the late 70’s and published in ’81 has seen many iterations and the latest, the COCOMO 2,allows for a great variance in inputs. The advantage of algorithmic cost modelling is theability to generate repeatable estimations and the ease at which it can be modified andrefined. The disadvantage of with is the inability to deal with exceptional conditions and notall experience and factors can be measured (Samuel Lee, 2002). The COCOMO 2 provides 3stage models, the application composition model for the earliest phases, the early designmodel for the next phases and the post architecture model for when the project is ready todevelop (Sarwar, 2013). The estimation output is in terms of person/month (PM) and iscalculated based on the size of the project in thousands of lines of code (KDSI). Cost driversare divided into 4 groups, product, platform, personnel and project factors. Each groupcontain associated cost drivers rated on a scale of very low to very high which are modifiedto reflect the environmental conditions under which your project will be developed. Theeffort adjustment factor (ESF) is then calculated by multiplying the values for all cost driverstogether. For COCOMO to be accurate the model needs to be calibrated using historical data,the original COCOMO 81 was calibrated using 63 data points, the 1998 calibration was basedon 161 data points thus increasing the accuracy (Samuel Lee, 2002).Expert judgementThis method involves gathering estimates created by one or more experts which are thendiscussed and compared. The Delphi technique for expert judgement involves each expertbeing provided with the specification and a form to be completed individually, only allowingcommunication with the coordinator. The coordinator then prepares a summary of all theexperts estimates which is provided to the experts to guide them in creating a new iteration ofthe estimate and the rationales behind it. This step is then repeated for as many rounds as thecoordinator believes adequate (Hareton Leung, 2002). The downside to expert opinion iswhether the experts historical knowledge is easily applied to your environment and ways ofworking.Estimation by AnalogyThe analysis of one or more completed projects that have similarities to the current project(Boehm, 1981). A project is compared to previous similar projects and the data and valuesare used to estimate the current project cost. This process is reliant on the accuracy of the datarecorded on previous projects and the similarity between the projects. (Shivangi Shekhar,2016).Parkinson’s Law”work expands so as to fill the time available for its completion”The cost is determined by the resources available rather than an accurate assessment of therequired resources.Pricing to winRather than focusing on the functionality of the system, in this technique we focus on thebudget of the customer. Although this approach is perceived as unethical, estimating the costof the software at the customers budget can be one sure way of winning the contract. Themain disadvantage of which, is the constrained nature of the project by the agreed budget andthe resulting software may not be what the customer desired.Top-down estimationThe top-down approach provides a more suitable approach from an early stage with the costderived from global properties. With this method requiring less detail and focusing onintegration and management it is faster and easier to implement however, it does not take intoconsideration low level problems (Shivangi Shekhar, 2016).Bottom-up estimationThe bottom-up approach is more suited to a project in which the initial requirements are welldefined as each component of the software system is reviewed and estimated separately toestimate the entire system. This technique is more stable however it does not take intoconsideration activities such as integration and documentation and can take more time(Shivangi Shekhar, 2016).Project duration and staffingHaving calculated the effort required for the project, the manager must also estimate thelength of time for software development and the number of staff required throughout theproject. There is a complex relationship between staffing and the project schedule. One mightthink that doubling the staff would half the time taken, however, an increase in staffing canincrease the schedule. Adding staff increases the time taken to communicate the differenttasks being undertaken by separate teams. An effort should be made to avoid having toomany staff at either the beginning or the end of the project but instead increase that number toa peak during the development and testing phases while gradually decreasing that numbertowards the deployment stage. A good graphical depiction of this ideal is provided byRayleigh’s curve (Sommerville, 2009).ConclusionThe calculation of cost for a software engineering project can never be an exact scienceconsidering the varying degree of inputs and the fact that most inputs are based on people orindeed the opinion of people. To agree with Samuel Lee when he states: “any process thatinvolves a significant human factor can never be exact because humans are far too complexto be entirely predictable” (Samuel Lee, 2002). With strengths and weaknesses related toeach estimation method, formulating as accurate an estimation as possible should be achievedby comparing the results of several methods. Should there be large variances in the results ofthese methods, then the information gathered for the estimate is not sufficient and must bereviewed.