An Alternative to Counting Lines of Code
Software has become integral to almost every facet of life. From computers to automobiles, software plays an important role. When such importance is placed on something such as a product, it is important to make the correct judgments when cost, schedule, and the deployment of resources are concerned. Such is the case with software development. In response to the constraints placed on software development by cost, schedule, and resources, system software metrics have been developed. Such techniques can be useful in the selection and rejection of projects by a business. Many techniques exist, two of which are counting lines of code and Function Point Analysis. Based on a literature review of the theory behind these two techniques, this paper presents an analysis of counting lines of code, its flaws, and why Function Point Analysis offers an alternative.
The Need For Accurate Estimates
To understand the need for accurate estimations, one can look to statistical data gathered on the success and failure rates of software development projects. In their 1999 PM article, “Curing the Software Requirements and cost Estimating Blues,” Major Mike Nelson, James Clark, and Martha Ann Spurlock indicate that a large number of software development projects were not accurately estimated. The results of the 1995 Standish Group survey of 8380 software applications indicate that only 16% of projects stayed on schedule without exceeding their budgets, while 31% were cancelled, and 52.7% were completed with schedule and budget overruns (Nelson et al., 1999). In addition, the average budget overrun was 189% and the average schedule overrun was 222% (Nelson et al., 1999). A survey of the completed projects showed that the developers had to reduce features and functionality to 61% of the original requirements just to meet their schedule (Nelson et al., 1999). From these statistics, it is clear that accurate cost and schedule estimates are needed to avoid these failures. While Nelson et al. does not indicate if the Standish Group recorded the estimation techniques used by those surveyed, or even if those in the survey practiced an estimation technique, the predominant technique employed at the time of the survey was counting lines of code (Ferens, 1998).
Counting Lines of Code
The technique of counting lines of code involves counting the number of compiled source code lines in a program to estimate the size, cost, and effort required (Nelson et al., 1999). According to Nelson et al. (1999), the flaws associated with this technique result in a dramatically high error rate, sometimes reaching 400% of the original estimates. Nelson et al. (1999) notes that the software development industry lacks a standard definition for the measurement of source lines of code. Ferens (1988) concurs and adds that there is a large discrepancy between organizations as to what types of code statements constitute source code. He notes that most estimations include executable lines of code, but some do not include statements such as comments, test data statements, and declarative statements (Ferens, 1988). Compounding this issue is the proliferation of programming languages, which can achieve the same execution with differing numbers of executable statements. Moreover, Sean Furey, in his 1997 IEEE Software article, “Why We Should Use Function Points,” states that object-oriented programming languages make estimation difficult because “applications or major pieces of applications can be created with virtually no countable lines of code” (p. 28). Finally, Nelson et al. (1999) notes that estimates are often produced prior to the determination of the programming language used on a project.
Function Point Analysis
The need to produce estimates prior to programming language selection is perhaps one of the reasons A.J. Albrecht developed the Function Point Analysis technique, which was released to the public in 1979 (Jones, 1999). Since then, several variations of Function Point Analysis have been developed. These include the Symons Mark II version and several revisions developed by the International Function Point Users Group (Furey, 1997).
Function Point Analysis “is a measure of software complexity derived from five attributes of a program” (Jones, 1999, p. 165). Function points are computed by calculating the number of inputs, outputs, inquiries, master files, and interfaces in a program. Under the Version 4.0 rules set by the International Function Point Users Group, the five attributes are assigned a numeric value, weighted according to their complexity, and then are summed. With the sum calculated, adjustments are then made to this value by comparing it to a set of pre-defined criteria. The end result enables managers, developers and even users to estimate the relative size of a program in terms of cost and effort, terms the business, not just developers, can understand (Jones, 1999).
Advantages of Function Point Analysis
Function Point Analysis allows program managers to accurately estimate software size in terms that the business can understand because function points are based on a logical understanding of the software rather than a physical, or line count, view. This enables managers to make informed choices about their software development more objectively (Furey, 1997).
Furey (1997) states that “Function points are technologically independent, consistent, repeatable, and help normalize data, enable comparisons, and set scope and client expectations” (p. 28). In fact, function points allow the focus to be placed on the required functionality of the users, and therefore, also measure the software requirements. As a result of having a basis grounded in functional requirements, function points have an advantage over counting lines of code, in that, function points can be counted earlier in the development process (Furey, 1997).
Perhaps the greatest advantage of Function Point Analysis is that this technique has been ratified as an international standard, embodied in the International Function Point Users Group (Furey, 1997). As such, Function Point Analysis has an established set of rules and is independent of any programming language or changes in languages (Nelson et al., 1999).
An Example of the Benefits of Function Point Analysis
Furey (1997) provides an example of how Function Point analysis can allow managers to make more accurate judgments. In his example, two teams each develop an application that contains the same level of functionality and features, with two different languages. The first team develops the application with COBOL, writes 4000 lines of code, and finishes after ten months of work. The second team develops their application in Smalltalk, writes 900 lines of code, and finishes in five months. Under the lines of code counting technique, the first team is considered to be more productive because they produced more lines of code. However, when Function Point Analysis is applied, the second team was more productive because they developed an application with equal functionality in only half the time (Furey, 1997).
Disadvantages of Function Point Analysis
Ironically, the greatest advantage of Function Point Analysis, can be, at times, its greatest disadvantage. Having an established set of rules is advantageous only when those rules are followed. Barbara Kitchenham (1997) elaborates on this in her 1997 IEEE Software article, “The Problem with Function Points.” She argues that there is a need to understand the limitations of Function Point Analysis. In her analysis, she limits her discussion to Albrecht’s rules and Symons Mark II, citing their respective popularity in the United States and the United Kingdom (Kitchenham, 1997).
Keeping in mind that she is only analyzing Albrecht’s and the Symons techniques, she states that problems can be encountered when using function point measurements as the basis for negotiations and contracts between organizations (Kitchenham, 1997). She cites Albrecht’s use of an ordinal scale of “simple, average, and complex,” rather than a numeric scale, noting that the ordinal scale is vague in its descriptions of systems (Kitchenham, 1997).
Regarding the Symons Mark II technique, she notes that individual function point counts are transformed into weighted counts. She feels that this introduces issues because it assumes that all counts are equivalent measures, when standard conversion factors for these counts do not exist. In addition, she feels that function point counting involves the judgment of the person performing the count, and subsequently introduces variances and discrepancies in counts conducted by different people (Kitchenham, 1997).
Discussion
Accurate software metrics are crucial to the goals of staying on budget and on schedule. Without accurate measurements, serious budget expenses can be incurred and product releases can be delayed. Such failures to deliver could have serious repercussions for those developing the software and those managing the projects.
The literature regarding software estimation reveals two prevalent issues. First, the software metric used by organizations must produce accurate measurements of size, cost, and schedule. The second issue involves industry-wide acceptance of a standard so that organizations can properly make comparisons using their estimations.
Measuring software by counting lines of code has been, and is some analysts’ estimation, will continue to be, the standard software metric. Unfortunately, there is little that can be considered standard about counting lines of code. In fact, the discrepancies are so great that there is little consensus on whether a comment is a line of code. Within an organization, these discrepancies may have little impact. Across the industry, however, the differences in estimation could have serious impacts on the development contracts between organizations.
In terms of estimation accuracy when compared to counting lines of code, it can be suggested from the literature that any Function Point Analysis technique has definite advantages, all of which provide the potential for more accurate estimations. Some empirical studies, such as those conducted by Kermerer, corroborate this suggestion (Kermerer, 1987). The advantages include technological and programming language independence, earlier estimation in the life cycle, and data normalization. In addition to these advantages, Function Point Analysis has the benefit of international standardization. This, however, only applies to the technique developed by the International Function Point Users Group. Albrecht’s original technique and the Symons Mark II technique are not internationally standardized and as such, places Function Point Analysis in a similar situation as the lines of code counting technique in terms of universal acceptance. The fact that Kitchenham neglects the International Function Point Users Group version of Function Point Analysis seemingly underscores this situation and points to the larger issue of a need for function point standardization.
Estimating software to determine cost, schedules, and effort is clearly an important activity for software developers and managers. Making the correct estimations can have serious impacts on a projects success or failure. The technique of counting lines of code does not appear to be providing organizations with the accurate estimates that they require, but by the same token, it would be unfair to characterize Function Point Analysis as the absolute solution to all problems. Even with its flaws, Function Point Analysis can, however, be a valuable alternative to the technique of counting lines of code.
References
Ferens, D. V. (1988). Software Size Estimation Techniques. Proceedings of the IEEE, 701-705.
Furey, S. (1997). Why We Should Use Function Points. IEEE Software, 28-30.
Jones, C. (1999). Software Sizing. IEE Review, 165-167.
Kermerer, C. (1987). An Empirical Validation of software Cost Estimation Models. Communications of the ACM, 416-429.
Kitchenham, B. (1997). The Problem With Function Points. IEEE Software, 29-31.
Nelson, M., Clark, J., & Spurlock, M. (1999). Curing the Software Requirements and Cost Estimation Blues. PM, 54-60.
The Need For Accurate Estimates
To understand the need for accurate estimations, one can look to statistical data gathered on the success and failure rates of software development projects. In their 1999 PM article, “Curing the Software Requirements and cost Estimating Blues,” Major Mike Nelson, James Clark, and Martha Ann Spurlock indicate that a large number of software development projects were not accurately estimated. The results of the 1995 Standish Group survey of 8380 software applications indicate that only 16% of projects stayed on schedule without exceeding their budgets, while 31% were cancelled, and 52.7% were completed with schedule and budget overruns (Nelson et al., 1999). In addition, the average budget overrun was 189% and the average schedule overrun was 222% (Nelson et al., 1999). A survey of the completed projects showed that the developers had to reduce features and functionality to 61% of the original requirements just to meet their schedule (Nelson et al., 1999). From these statistics, it is clear that accurate cost and schedule estimates are needed to avoid these failures. While Nelson et al. does not indicate if the Standish Group recorded the estimation techniques used by those surveyed, or even if those in the survey practiced an estimation technique, the predominant technique employed at the time of the survey was counting lines of code (Ferens, 1998).
Counting Lines of Code
The technique of counting lines of code involves counting the number of compiled source code lines in a program to estimate the size, cost, and effort required (Nelson et al., 1999). According to Nelson et al. (1999), the flaws associated with this technique result in a dramatically high error rate, sometimes reaching 400% of the original estimates. Nelson et al. (1999) notes that the software development industry lacks a standard definition for the measurement of source lines of code. Ferens (1988) concurs and adds that there is a large discrepancy between organizations as to what types of code statements constitute source code. He notes that most estimations include executable lines of code, but some do not include statements such as comments, test data statements, and declarative statements (Ferens, 1988). Compounding this issue is the proliferation of programming languages, which can achieve the same execution with differing numbers of executable statements. Moreover, Sean Furey, in his 1997 IEEE Software article, “Why We Should Use Function Points,” states that object-oriented programming languages make estimation difficult because “applications or major pieces of applications can be created with virtually no countable lines of code” (p. 28). Finally, Nelson et al. (1999) notes that estimates are often produced prior to the determination of the programming language used on a project.
Function Point Analysis
The need to produce estimates prior to programming language selection is perhaps one of the reasons A.J. Albrecht developed the Function Point Analysis technique, which was released to the public in 1979 (Jones, 1999). Since then, several variations of Function Point Analysis have been developed. These include the Symons Mark II version and several revisions developed by the International Function Point Users Group (Furey, 1997).
Function Point Analysis “is a measure of software complexity derived from five attributes of a program” (Jones, 1999, p. 165). Function points are computed by calculating the number of inputs, outputs, inquiries, master files, and interfaces in a program. Under the Version 4.0 rules set by the International Function Point Users Group, the five attributes are assigned a numeric value, weighted according to their complexity, and then are summed. With the sum calculated, adjustments are then made to this value by comparing it to a set of pre-defined criteria. The end result enables managers, developers and even users to estimate the relative size of a program in terms of cost and effort, terms the business, not just developers, can understand (Jones, 1999).
Advantages of Function Point Analysis
Function Point Analysis allows program managers to accurately estimate software size in terms that the business can understand because function points are based on a logical understanding of the software rather than a physical, or line count, view. This enables managers to make informed choices about their software development more objectively (Furey, 1997).
Furey (1997) states that “Function points are technologically independent, consistent, repeatable, and help normalize data, enable comparisons, and set scope and client expectations” (p. 28). In fact, function points allow the focus to be placed on the required functionality of the users, and therefore, also measure the software requirements. As a result of having a basis grounded in functional requirements, function points have an advantage over counting lines of code, in that, function points can be counted earlier in the development process (Furey, 1997).
Perhaps the greatest advantage of Function Point Analysis is that this technique has been ratified as an international standard, embodied in the International Function Point Users Group (Furey, 1997). As such, Function Point Analysis has an established set of rules and is independent of any programming language or changes in languages (Nelson et al., 1999).
An Example of the Benefits of Function Point Analysis
Furey (1997) provides an example of how Function Point analysis can allow managers to make more accurate judgments. In his example, two teams each develop an application that contains the same level of functionality and features, with two different languages. The first team develops the application with COBOL, writes 4000 lines of code, and finishes after ten months of work. The second team develops their application in Smalltalk, writes 900 lines of code, and finishes in five months. Under the lines of code counting technique, the first team is considered to be more productive because they produced more lines of code. However, when Function Point Analysis is applied, the second team was more productive because they developed an application with equal functionality in only half the time (Furey, 1997).
Disadvantages of Function Point Analysis
Ironically, the greatest advantage of Function Point Analysis, can be, at times, its greatest disadvantage. Having an established set of rules is advantageous only when those rules are followed. Barbara Kitchenham (1997) elaborates on this in her 1997 IEEE Software article, “The Problem with Function Points.” She argues that there is a need to understand the limitations of Function Point Analysis. In her analysis, she limits her discussion to Albrecht’s rules and Symons Mark II, citing their respective popularity in the United States and the United Kingdom (Kitchenham, 1997).
Keeping in mind that she is only analyzing Albrecht’s and the Symons techniques, she states that problems can be encountered when using function point measurements as the basis for negotiations and contracts between organizations (Kitchenham, 1997). She cites Albrecht’s use of an ordinal scale of “simple, average, and complex,” rather than a numeric scale, noting that the ordinal scale is vague in its descriptions of systems (Kitchenham, 1997).
Regarding the Symons Mark II technique, she notes that individual function point counts are transformed into weighted counts. She feels that this introduces issues because it assumes that all counts are equivalent measures, when standard conversion factors for these counts do not exist. In addition, she feels that function point counting involves the judgment of the person performing the count, and subsequently introduces variances and discrepancies in counts conducted by different people (Kitchenham, 1997).
Discussion
Accurate software metrics are crucial to the goals of staying on budget and on schedule. Without accurate measurements, serious budget expenses can be incurred and product releases can be delayed. Such failures to deliver could have serious repercussions for those developing the software and those managing the projects.
The literature regarding software estimation reveals two prevalent issues. First, the software metric used by organizations must produce accurate measurements of size, cost, and schedule. The second issue involves industry-wide acceptance of a standard so that organizations can properly make comparisons using their estimations.
Measuring software by counting lines of code has been, and is some analysts’ estimation, will continue to be, the standard software metric. Unfortunately, there is little that can be considered standard about counting lines of code. In fact, the discrepancies are so great that there is little consensus on whether a comment is a line of code. Within an organization, these discrepancies may have little impact. Across the industry, however, the differences in estimation could have serious impacts on the development contracts between organizations.
In terms of estimation accuracy when compared to counting lines of code, it can be suggested from the literature that any Function Point Analysis technique has definite advantages, all of which provide the potential for more accurate estimations. Some empirical studies, such as those conducted by Kermerer, corroborate this suggestion (Kermerer, 1987). The advantages include technological and programming language independence, earlier estimation in the life cycle, and data normalization. In addition to these advantages, Function Point Analysis has the benefit of international standardization. This, however, only applies to the technique developed by the International Function Point Users Group. Albrecht’s original technique and the Symons Mark II technique are not internationally standardized and as such, places Function Point Analysis in a similar situation as the lines of code counting technique in terms of universal acceptance. The fact that Kitchenham neglects the International Function Point Users Group version of Function Point Analysis seemingly underscores this situation and points to the larger issue of a need for function point standardization.
Estimating software to determine cost, schedules, and effort is clearly an important activity for software developers and managers. Making the correct estimations can have serious impacts on a projects success or failure. The technique of counting lines of code does not appear to be providing organizations with the accurate estimates that they require, but by the same token, it would be unfair to characterize Function Point Analysis as the absolute solution to all problems. Even with its flaws, Function Point Analysis can, however, be a valuable alternative to the technique of counting lines of code.
References
Ferens, D. V. (1988). Software Size Estimation Techniques. Proceedings of the IEEE, 701-705.
Furey, S. (1997). Why We Should Use Function Points. IEEE Software, 28-30.
Jones, C. (1999). Software Sizing. IEE Review, 165-167.
Kermerer, C. (1987). An Empirical Validation of software Cost Estimation Models. Communications of the ACM, 416-429.
Kitchenham, B. (1997). The Problem With Function Points. IEEE Software, 29-31.
Nelson, M., Clark, J., & Spurlock, M. (1999). Curing the Software Requirements and Cost Estimation Blues. PM, 54-60.
Labels: Academic Papers, Technology
posted by The Voice at 10:34 PM
0 Comments:
Post a Comment
<< Home