Appendix A: Measuring Software Size Software size matters and you should measure it. —Mary Gerush and Dave West Software size is the major determinant of software project effort. Effectively measuring software size is thus a key element of successful effort estimation. Failed software sizing is often the main contributor to failed effort estimates and, in consequence, failed projects. Measuring software size is a challenging task. A number of methods for mea- suring software size have been proposed over the years. Yet, none of them seems to be the “silver bullet” that solves all problems and serves all purposes. Depending on the particular situation different size metrics should typically be used. In this appendix we provide a brief overview of the common software sizing approaches: functional and structural. These approaches represent two, often- confused, perspectives on software size: customer perspective and developer per- spective. The first perspective represents value of software, whereas the second perspective represents the cost (work) of creating this value. We summarize the most relevant strengths and weaknesses of the two most popular sizing methods that represent these perspectives: function point analysis (FPA) and lines of code (LOC). In technical terms, FPA represents “what” whereas LOC represent “how” in software development. Finally, we provide guidelines for selecting appropriate sizing methods for the purpose of effort estimation. A.1 Introduction There are two aspects to sizing a system: what is the count, and what is the meaning or definition of the unit being counted? —Phillip G. Armour A. Trendowicz and R. Jeffery, Software Project Effort Estimation, 433 DOI 10.1007/978-3-319-03629-8, # Springer International Publishing Switzerland 2014 434 Appendix A: Measuring Software Size A.1.1 What Is Software Size? One of the key questions project managers need to answer is “how big is my development project going to be?” The key to answering this question is software size. The size of software is the major determinant of project volume, and thus it is commonly used as a proxy for project’s size. It is a basis for essential project management activities, such as planning, tracking, and controlling project scope and productivity. But what constitutes software size? In order to answer this question we need to answer two simple questions: what is software and what is size of software? The first question addresses multiple facets of software that need to be consid- ered. Is software the executable code delivered to the customer? Does it include user documentation? Or does software encompass all products created during the whole software development project? The second question addresses multiple abstractions of software. Is size refer- ring to abstract properties of software such as functionality or to physical properties of software project outcomes such as code and documentation? This multiple nature of software makes measuring its size an extremely challenging task. A number of software sizing metrics have been proposed to address this challenge. Yet, practitioners criticize traditional sizing techniques as being too complex and expensive. In consequence, very few organizations measure size of software or of a project in a consistent and systematic way. The software sizing solution depends on the specific situation in which we need to measure size, and in particular our needs and capabilities. Tip " Choose the right sizing method based on your objectives and capabilities. As with any other technology, software sizing requires associated introduction, applica- tion, and continuous optimization processes. A.1.2 Types of Size Metrics Briand and Wieczorek (2002) group software sizing methods into two types: problem-oriented and solution-oriented. Problem-oriented metrics represent the size of the problem that the future software product will solve, i.e., the target functionality of the system. Since these metrics typically focus on measuring elements of software functionality they are also commonly referred to as functional size metrics. Solution-oriented metrics represent the size of the software develop- ment outcomes such as specifications, the design, or implementation of software system. Since they typically focus on measuring structural properties of software products they are also commonly referred to as structural size metrics. In principle, we may say that while problem-oriented measurement methods represent a cus- tomer perspective, the solution-oriented methods represent a developer perspective. Appendix A: Measuring Software Size 435 Table A.1 Methods for estimating the functional size of software Sizing method Description Function Introduced by Albrecht (1979) the function point method measures the relative size points of software functions based on the amount of different data types processed (enter, leave, read and written to storage) by a software function. Albrecht’s approach evolved into several variants of functional size measurement methods. Several of them have been published as ISO standards: • IFPUG: ISO-20926 (ISO 2009) • NESMA: ISO-24570 (ISO 2005) • FiSMA: ISO-29881 (ISO 2008) • COSMIC: ISO-19761 (ISO 2003) • Mk II: ISO-20968 (ISO 2002) Feature Introduced by Jones (1996) “The SPR Feature Point Method” extended Albrecht’s points function point method by additionally counting algorithms and multiplying this count by relative complexity of an algorithm. This method suffers from imprecise description and lack of reference applications. It has been largely abandoned in practice Use-case Introduced by Karner (1993) Use-Case Points (UCP) are inspired and based on points function point analysis and founded on its philosophy. Inputs for UCP are use-case specifications. UCP counts instances of two elements: actors and use cases. Similar to FPA each instance is evaluated with respect to its complexity and assigned an appropriate weight. The unadjusted CUP count is equal to the weighted sum of individual counts. Similar to FPA unadjusted UCP can be modified using an adjustment factor, which is determined on the basis of several technical complexity and environmental factors Story points Introduced by Cohn (2004, 2005) for the purpose of estimating the size of agile software projects. Story Point is an abstract unit of software size that represents an intuitive mixture of development effort and complexity. Story points are assigned according to a Fibonacci number sequence, where each number is the sum of the previous two. As noted earlier, in planning poker story points may start from 1/2 and continue as 1, 2, 3, 5, 8, 13, and so on Object points A number of different object point metrics have been proposed for measuring software size. Two example measurement methods are: • Predictive Object Points (POP): Introduced by Minkiewicz (1997) predictive object points are based on counts of classes and weighted methods per class, with adjustments for the average depth of the inheritance tree and the average number of children per class. Methods are weighted by considering their type (constructor, destructor, modifier, selector, iterator) and complexity (low, average, high), giving a number of POPs in a way analogous to traditional FPs • Object Points (OP): Introduced by Banker et al. (1992) object points measure software size by counting visual widgets of the fourth generation languages in integrated CASE environments. Widgets are (1) logical system components, (2) constructs of the third generation language that is used to supplement fourth generation language code, (3) user interface screens, and (4) user report. Widgets counts are adjusted by complexity and reuse multipliers, and summed to total object points count. Other than POP object points do not consider such object-oriented concepts as inheritance or encapsulation. Instead OP considers elements of user interface (continued) 436 Appendix A: Measuring Software Size Table A.1 (continued) Sizing method Description Web objects Introduced by Reifer (2000) the Web Objects method extends the well-known Function Point Analysis in that, in addition to the five elements already considered in FPA, it counts four elements specific to Web application: multimedia files, web building blocks, scripts, and links. Web objects are measured on user requirements and Web page designs. The counting procedure is analogical to FPA and comprises counting instances of the nine elements and weighting them according to their complexity. Total size is computed as weighted sum of all individual counts Problem-Oriented Size Metrics Problem-oriented software sizing methods identify the elements of the problem, and count their instances. These instances can additionally be weighted with respect to their complexity. Total software size is then a result of the weighted sum over individual instance counts. Several methods provide an opportunity to adjust software size with respect to the particular context in which the software is developed. For this purpose they consider a set of project context factors, commonly referred to as technical or environmental factors. The method rates each factor based on the associated weights and constants defined within the method. The total adjustment coefficient is then computed as a weighted sum of ratings for all factors. Software size is then adjusted by multiplying it by the adjustment coefficient. Table A.1 provides a brief overview of common problem-oriented software size measurement methods. Solution-Oriented Size Metrics Solution-oriented software sizing