Estimating Software Costs

Software costs estimation is not an easy task by any chance. This is informed by the fact that usually, the bigger the software project, the more detailed and complex the process of cost of estimation (Werner, 2004). In the past, before the need for cost estimation models was realized, software cost estimation used to be conducted in an ad hoc manner. According to Toursnard (2004, p. 1), this trend has since changed with contemporary organizations tending to embrace new models of software costs estimation.
Such new models which big organizations are beginning to embrace include the Function Points (FP) and the Source Line of Codes (SLOC) based models among other commercial-off the-shelf (COTS) tools of cost estimation. Source Line of Codes (SLOC) based models. A SLOC of system software can be got from experience. It can also be determined from the size of the competitors’ system, the size of a past system as well as from disintegrating an existing system into several pieces and then estimating the SLOC in each of the broken down pieces. According to Putnam (1980. pp.
102-127), three particular estimates need to be made. These are the smallest possible SLOC-a, the most likely SLOC-m, and the largest possible SLOC-b. The expected SLOC for a piece, say E, can be determined by summing up the smallest estimate, largest estimate as well four times the most likely estimate. Having summed up all these, the summation is then divided by 6. Represented in a mathematical way, Ei = [a+4m+b]/6. The expected SLOC for the whole software system E is simply determined by the summation of all the expected SLOC for each of the pieces (Putnam, 1980, pp.

102-127). Further, a projection of the standard deviation for each of projected Ei can be established by determining the range in 99% of the projected values have the probability of occurring then dividing the results by 6. In this regard, SDi =| b-a|/6. The standard deviation of the expected SLOC for the entire system would then be obtained by determining the square root of the summation of the squares of the standard deviations of each of the projected SDi Using SLOC Estimate for Cost Estimation
Software Lifecycle Management (SLIM) and the Constructive Cost Model (COCOMO) represent some of the models which employ SLOC estimates in the estimation of software costs (Roetzheim, 2000). The drawback of these models just like many other models is the fact that they depend on the input of SLOC. This has the implication that an inaccurate SLOC estimate would lead to inaccurate cost estimation results. However, that not withstanding, to establish a software system cost estimate, there additional variables are needed apart from the SLOC estimate. These variables include alpha, ?
, which represents the marginal costs for every thousand lines of code (KLOC), beta, ? , which is an exponent as well as gamma, ? , which is the additional fixed project cost. Thus, the calculation for the cost estimate would be represented as, CostEstima te = ? • KLOC? + ? (Toursnard 2004, p 4). It should however be noted that this is a representation of a basic method of estimating software costs using SLOC. The Function Points Model The FP metric was initially came up with to act as an alternative to the SLOC model of estimating software costs more so during the later stages of software development (Kemerer, 1993, pp.
85-97). However, later research point to the fact that the model could as well be reliable in estimating software costs during the initial steps of the lifecycle of software development (Roetzheim, 2000). This has the implication that only a comprehensive software requirement would be needed to carry bout a full FP analysis (Toursnard 2004, p 4). This has the merit that virtually any member outside the software development team would be in a position to carry out the FP analysis without the necessary assistance from a member of the software development team.
The other important merit of not using SLOC is the fact that the estimate is not dependent upon the language as well as other variables of implementation which are usually very cumbersome to consider (Kemerer, 1993, pp. 85-97). To precisely estimate SLOC, the programming language needs to be factored in since some languages are more accurate than others. The implication here is that an estimate for a SLOC developed in Java would definitely be vary from an estimate of the same software but in Assembly Language (Toursnard 2004, p 4).
To fully comprehend the way FP model differs from the SLOC model, it is necessary to understand the way the final FP count is determined and interpreted. Counting Functions and the Calculation of Unadjusted Function Points Even with the formal specification of the software requirements, it would still be an uphill task to count the functions of a software system during the software development cycle (Roetzheim, 2000). To make the process easy, five categories of functions are proposed. These include external inputs, external inputs and external inquiries. The other two categories are external interfaces and external files.
External inputs is comprises of all the information emanating from outside sources and effecting the processing of data. External outputs are comprised of all the information processed and sent from the system. Still, external enquiries are inputs and outputs which require an instant which don not alter the internal data of the system. External interfaces comprise of all the data which are shared with other software systems other than the particular system. Finally internal files are inclusive of the logical data as well as control files to the particular system (Toursnard 2004, p 5).
Usually when a function has been identified in the development process of system software for a particular category, the complexity of the function has to be rated (Roetzheim, 2000). The rating could either be low, average or high (Toursnard 2004, p 5). Each of the function count is then multiplied with the particular associated complexity before a summation of all the counts is done to determine the count for the whole system, described as the unadjusted function points (UFP) (Kemerer, 1993, pp. 85-97). Calculating the Adjusted Function Points
Though UFP is capable of giving a good estimate of the number of functions available in a system, its limitation is the fact that it does not account for environmental variables which determine the efforts needed to program the system (Roetzheim, 2000). For instance, a software system which requires very high performance would need extra efforts to ensure that the software is developed in the most efficient way possible. In this regard, in the development of the FP model, it is important to note some general system features which are rated on a scale of 0-5 regarding their probabilistic effects for the system under count.
Some of these characteristics include data communications, distributed functions, performance as well as transaction rate among others (Toursnard 2004, p 7). The ratings assigned to all the above functions are then harmonized in into a formula to obtain the value adjusted factor (VAF). Eventually, a multiplication of the UFP and the VAF gives the FP (AFP) count. Thus, AFP = UFP*VAF (Kemerer, 1993, pp. 85-97). Conclusion With regards to the interpretation of the adjusted function points, a comparison is usually made between the number of proposed system and the AFP count and cost of systems which have previously been measured.
The more historical the data is comparable, the better the probability of estimating in an accurate way, the cost of the proposed software system (Werner, 2004). To continually refine estimation accuracy, it would be necessary to measure and record the actual cost upon the completion of the system. This actual cost is what would enable an evaluation of the beginning estimate (Toursnard 2004, p 8). In conclusion, many people do have the perception that the functions of software project represents a more logical way of estimating the cost of as opposed to determining the SLOC then running it through a SLOC based model.
Given that many organizations started to employ SLOCF based models before the FP model was even conceptualized would mean that those particular organizations would resist attempts to convince them that the FP model is more superior (Kemerer, 1993, pp. 85-97). However, this does not mean that the FP model has no demerits. For instance, the procedure of counting functions in a software system entails some decisions which are subjective and could vary among people in an organization. However, the FP approach appears to be more advantageous that the SLOC approach in the estimation of software costs (Toursnard 2004, p 8).
References Kemerer, C. (1993) Reliability of Function Points Measurement. A Field Experiment, Communications of the ACM, Vol. 36, No. 2 pp. 85-97 Putnam, L. H. (1980) Example of an Early Sizing, Cost and Schedule Estimate for an Application Software System, in Tutorial, Software Cost Estimation and Life-Cycle Control: Getting Software Numbers, IEEE Computer Society, New York: Computer Society Press, pp. 102-127 Roetzheim, W. (2000) Estimating Software Costs; First in a four-part series: How big will the system be?
How do you measure it? United Business Media LLC Werner, W. (2004) Software cost estimation; predicting the resources required for a software development process. Project Management Slide 1, Sommerville. Retrieved 1st December, 2008 from http://www. evolution. at/download/Lectures/ProjectManagement/SoftwareCostEstimation. ppt Toursnard B. (2004) Software Cost Estimation: SLOC-based Models and the Function Points Model Version 1. 1 pp 1-10. Retrieved 1st December, 2008 from http://bradt. ca/docs/SWE4103-report. pdf.