Cost of Software Estimation - Coursework Example

of affiliation: Estimating software cost is a fundamental step in software development process. This part of the process determines if carrying on with the project is worthy or not. Every software project development aims at developing a system that will meet all the pre stated requirements within the least possible cost. In the recent days, researchers have identified poor costing and scheduling of software development projects as the leading cause of failures in majority of the projects (Sommerville, 2007). This study placed poor estimation of software cost before other causes that included political, technical or development team problems. Additionally, this study found out that only a few software companies had a good understanding regarding this matter, with only a small, percentage taking it as a science and not merely an art. This work details a step by step approach to estimation of software cost and schedules. The Estimating Lifecycle In the initial stage, the program developers require to build an in-depth knowledge on the software cost estimating limitations at the macro level. As we will see in the next diagram, accuracy of cost estimate is frequently determined by the present software development stage. Early uncertainty in the estimation process is largely founded on variances in the input parameters to the estimate while later uncertainties to the variance of the models used. At the start i.e. the concept level, developers may get a definition of the project which is unclear. Here, it is possible to recognize the general purpose of the new software despite the limited knowledge on the requirements. Typically, for an experienced estimator, the estimates at this point will depict an accuracy of ± 50% when using informal methods such as group consensus or historical comparisons (Londeix, 2008). Macro Lifecycles 50 25 10 Typical Cost Estimating Accuracies Once the requirements have been understood to a convincing level, preparation of function-oriented estimate begins. Here, an experienced estimator will come up with estimates depicting an accuracy of ± 25% when using the methods outlined above. On completing the detailed design, the developers roll in the final stage which entails preparation of the implementation –oriented estimate. This estimate frequently depicts an accuracy of ±10 %. In all these, the key point is recognizing the significance of periodic re-estimates although the project lifecycle, a factor that will enhance identification of problems in the early stages and allow corrective actions to be taken (Trendowicz, 2013). Estimating Program Volume Program volume is the other factor considered when coming up with the costing of prospect software. While coming up with an estimate of the project volume, developers can choose the use the SLOC, or number of source line codes. SLOC refers to a human written line of code which typically is neither a comment or a blank line. Here, caution is taken not to recount any line, particularly in cases where the code is used several times in the application. It should be noted that project developers usually work on related number, thousands of KSOC, or SLOC, when estimating. The COCOMO (Constructive Cost Model) is the most common estimating metric used in such cases. A simplest estimate using this model requires the developer to first know the number of KSLOC to be written and the effort required for each KSLOC. These two variables are multiplied to get the person months of effort required by the project to come to its completion. Basically, this concept is central in the estimating models. The table below shows some common values identified by researchers that relate to this linier productivity feature. Project Type Linear Productivity Factor COCOMO II Default 3.13 E-Commerce development 3.08 Embedded development 3.60 Military development 3.97 Web development 2.51 Using this approach lets attempt building an e commerce entailing 15,000 Code lines. Here, computation of person’s months of efforts will be done using the following equation. Productivity x KSLOC = 3.08 x 15 = Effort = 46 Person-Months In cases where the projects are relatively small, this basic equation will be found handy. Past studies have however identified variation in productivity depending on project size. As a matter of fact, large projects have been significantly shown to be less productive as when compared to small projects. This has been explained citing a probable combination of increased communication and coordination time, in addition to more rework requirement caused by misunderstandings (Qi, 2013). The established productivity decrease following the increase in project size is solved by raising the figure of KSLOC to a figure bigger than 1.0. The exponential factor used is used to penalize large projects for reduced efficiency (Hill, 2011). The table below gives examples of well known size penalty of several project types. Project Type Exponential size penalty factor COCOMO II Default 1.072 E-Commerce development 1.030 Embedded development 1.111 Military development 1.072 Web development 1.030 Using our example of e commerce we can then compute the number of persons months of efforts required to complete our 15,000 lines of code. The computation will be as follows: Productivity x KSLOC Penalty = 3.08 * 15 1.030 = 3.08 x 16.27 = Effort = 50 Person-Months Up to this point we can see a straight forward flow of events; however, it will be important to ask the question as to whether the project gets to the 15000 SLOC. Two approaches namely “function points with backfiring” and direct estimation can help developers unfold this dilemma. In this approaches, the determination of the fundamental input variables follows an expert’s opinion, with developers functioning as the experts (Trendowicz, 2013). Typically, the initial stage of estimating number of code lines entails breaking of the project into modules. A good example of this process involving a high level breakdown is one which takes a front-end processes; data base code and middle-tier processes. The developers use their experience to build similar systems with their focus placed on estimating the number of lines of code required. It is strongly recommended that developers get three estimates for every input variable used i.e. Expected case; the best-case and worst-case estimates. These three estimates are then used to compute the mean and standard deviation as shown below: Mean= Standard Deviation= Standard Deviation measures how much deviation is possible in the final number. For instance, the mean + 3(standard deviation) ensures there is 99 percent probability that the project is under the estimate (Pfleeger, Wu, & Lewis, 2010). Estimating Function Points Another option is to begin with function points followed by a process called backfiring that helps convert the function points to SLOC. This method was first used by IBM to measure program volume. In this case, the program functionality (which translates to its cost) is considered based on the number of ways it must interact with users. Determination of function points begins with the estimation of the external interface files, external queries, external inputs, external outputs, and logical internal tables. Eternal inputs are basically the data entry screens. In the cases where the screen contain tabbed notebook or related metaphor then the tabs are considered as external input separately. External interfaces files arise from files which are based outputs or inputs. The entire record format in the file, or each data object type in the case of XML, would be taken separately as an interface file in all cases. The reports are taken as the External outputs and external functions or messages based communications going in or out of the application as external quarries. Lastly, logical internal tables constitute the number of the database tables (Boehm, 2000).Conversion of raw values into actual function point’s count entails multiplication of the raw numbers using a conversion factor drawn from the following table. Raw Type Function Point Conversion Factor External inputs 4 External interface files 7 External outputs 5 External queries 4 Logical internal tables 10 Taking a case in which 25 data entry screen, 15 reports, 5 interfaces, 20 logical internal table and 10 external queries are presented we can calculate functional points in the following g way. (25 x 4)+ (7 x5) + (15 x5) + (10 x 4) + (20 x 10) = 450 Function Points Now that the function points have been calculated, the only remaining step is to employ backfiring in converting points to SLOC. This is accomplished by using a language equivalencies table (Bennatan, 2009). The table below presents some of the common values: Language SLOC per Function Point C++ default 4 Cobol default 7 Delphi 5 5 HTML 4 4 Java 2 default 10 Let us take an example of an implementation which uses java to complete the above project (50 function points). Calculation of SLOC will be as follows: 450 x 46 = 20,700 SLOC Assuming this was an e commerce system, the project would require the following effort to implement. Productivity * KSLOC Penalty = 3.08 * 20.7 1.030 = 3.08 * 22.67 = Effort = 70 Person-Months References Bennatan, E. M. (2009). On time within budget: software project management practices and techniques (3rd ed.). New York: Wiley Boehm, B. W. (2000). Software cost estimation with Cocomo II. Upper Saddle River, NJ: Prentice Hall. Hill, P. R. (2011). Practical software project estimation a toolkit for estimating software development effort & duration. New York: McGraw-Hill. Londeix, B. (2008). Cost estimation for software development. Wokingham, England: Addison-Wesley. Pfleeger, S. L., Wu, F., & Lewis, R. (2010). Software cost estimation and sizing methods: issues, and guidelines. Santa Monica, CA: Rand Corp.. Qi, E. (2013). The 19th International Conference on Industrial Engineering and Engineering Management. Berlin: Springer. Sommerville, I. (2007). Software engineering (8th ed.). Harlow, England: Addison-Wesley. Trendowicz, A. (2013). Software cost estimation, benchmarking, and risk assessment the software decision-makers guide to predictable software development. Berlin: Springer. Read More