Software Engineering Technology
The Evolution of Software Size: A Search for Value©
Arlene F. Minkiewicz PRICE Systems, LLC
Software size measurement continues to be a contentious issue in the software engineering community. This article reviews soft- ware sizing methodologies employed through the years, focusing on their uses and misuses. It covers the journey the software community has traversed in the quest for finding the right way to assign value to software solutions, highlighting the detours and missteps along the way. Readers will gain a fresh perspective on software size, what it really means, and what they can and cannot learn from history. hen I first started programming, it evolved throughout the last 25 years. It In the ’70s, the LOC measure never occurred to me to think focuses on reasons why these approaches seemed like a pretty good device. Wabout the size of the software I was were attempted, the technological or Programming languages were simple developing. This was true for several rea- human factors that were in play, and the and a fairly compelling argument could sons. First of all, when I first learned to degree of success achieved in the use of be made about the equivalence among program, software had a tactile quality each approach. Finally, it addresses some LOC. Besides, it was the only measure in through the deck of punched cards of the reasons why the software engineer- town. required to run a program. If I wanted to ing community is still searching for the In the late ’70s, RCA introduced the size the software, there was something I right way to measure software size. first commercially available software could touch, feel, or eyeball to get a sense cost estimation tool, which used SLOC of how much there was. Secondly, I had Lines of Code converted to machine instructions as the no real reason to care how much code I As software development moved out of size measure for software items being was writing; I just kept writing until I got the lab and into the real world, it quickly estimated. In the ’80s, Barry Boehm’s the desired results and then moved on to became obvious that the ability to mea- COCOMO was introduced, also using the next challenge. Finally, as an engi- SLOC as the size measure of choice. As neering student, I was expected to learn other cost models followed, they too how to program but was never taught to “Now, 25 years later, used LOC measures to quantify the appreciate the fact that developing soft- amount of functionality being delivered. ware was an engineering discipline. The if you Google the It is important to note that while all of idea of size being a characteristic of soft- phrase software size you these models used SLOC as a primary ware was foreign to me—what did it real- cost driver, there are many other factors ly mean and what was the context? And will get more than that influence the cost of software why would anyone care? development as well. These software Now, 25 years later, if you Google the 100,000 hits. cost estimation models also need to phrase software size you will get more than gather information about factors such as 100,000 hits. Clearly, there is a reason to Clearly, there is a the complexity of the software being care about software size and there are lots estimated, the experience and capability of people out there worrying about it. reason to care about of the software development team, And still, I am left to wonder: What does expected reuse, the overall productivity it really mean and what is the context? software size and of the development organization, con- And why does anyone care? straints, and so forth. The quantification It turns out that there are several very there are lots of people of these factors is applied to the soft- good reasons for wanting to measure soft- ware size to determine estimates of cost ware size. Software size can be an impor- out there worrying and effort. tant component of a productivity compu- I believe that SLOC will go down in tation, a cost or effort estimate, or a qual- about it.” the annals of engineering history as the ity analysis. More importantly, a good soft- most maligned measure of all time. ware size measure could conceivably lead There are many areas where criticism of sure productivity and quality would be SLOC as a software size measure is jus- to a better understanding of the value useful and necessary. The lines of code being delivered by a software application. tified. SLOC counts are, by their nature, (LOC) measure—including source LOC very dependent on programming lan- The problem is that there is no agreement (SLOC), thousands of LOC, and thou- among professionals as to the right units guage. You can get more functionality sands of SLOC—is a count of the num- with a line of Visual C++ than you can for measuring software size or the right ber of machine instructions developed. with a line of FORTRAN, which is way to measure within selected units. It was the first measure applied to soft- more than you get with a line of This article examines the various ware, with its first documented use by Assembly Language. This does make approaches used to measure software size R.W. Wolverton in his attempt to formal- using SLOC as a basis for a productivity as the discipline of software engineering ly measure software development pro- or quality comparison among different © Copyright PRICE Systems, 2009. ductivity [1]. programming languages a bad idea.
March/April 2009 www.stsc .hill.af.mil 23 Software Engineering Technology
Capers Jones has gone so far as to label method for estimation and measurement assessing the productivity of their such comparisons “professional mal- within the context of their projects and processes. practice” [2]. practices. Another important considera- While I would be remiss not to Concerns also surround the consis- tion is the fact that once an organization acknowledge the great contribution that tency of SLOC counts, even within the has agreed on measurement rules for Albrecht made to the software engineer- same programming language. There are SLOC, counting can be automated so ing community with the introduction of several distinct methods for counting that completed projects can be mea- function points, I would be equally LOC. Counting physical LOC involves sured with minimal time and effort and remiss to stop the story here. Function counting each line of code written while without subjectivity. points are not the answer to all software logical lines involve counting the lines measurement woes, as they come with that represent a single complete thought Function Points their own set of limitations. to the compiler. In many programming In 1979, Allan J. Albrecht introduced Albrecht developed function points languages, spaces are inconsequential; function points, which are used to quan- to address a specific problem within his because of this, the differences between tify the amount of business functionali- organization, IBM. They, like many busi- physical and logical lines can be signifi- ty an information system delivers to its nesses that developed software, were cant. Add to this the fact that even with- users [3]. Where SLOC represents some- concerned with the problem of runaway in each of these methods, there are ques- thing tangible that may or may not relate software projects and wanted to get a tions as to how to deal with blanks, com- directly to value, function points attempt better handle on their software develop- ments, and non-executable statements to measure the intangible of end user ment processes. According to Tom (such as data declarations). Programmer value. Function point counts look at the DeMarco, “you can’t manage what you style also influences the number of LOC can’t measure” [4]. Function points written as there are multiple ways a pro- related very closely to the types of busi- grammer may decide to solve a problem Where SLOC ness applications that IBM was develop- with the same language. “ ing at the time, proving to be a far supe- Additionally, if SLOC is the only represents something rior measure of business value than characteristic of a software program that SLOC; function points can be much bet- is measured, productivity and quality tangible that ter for an organization that develops studies will overlook many important these types of systems to use for pro- factors. Other important characteristics may or may not ductivity comparison studies. include the amount of reuse, the inher- It’s fair to say that function points ent difficulty of solving a particular relate directly to value, caught on like wildfire in the software problem, and environmental factors that engineering community. Many new and model the approaches and practices of function points attempt successful businesses grew around help- an organization. All of these things ing software development organizations influence the productivity of a project. to measure the use function points to improve their mea- In general, it is fair to say that SLOC surement and quality programs, especial- measurement, considered in a vacuum, intangible of ly for commercial IT software develop- is a poor way to measure the value that ments. Two problems grew out of the is delivered to the end user of the soft- end user value.” introduction of function points. The first ware. It does continue to be a popular was that the fervor to jettison the much- measure for software cost and effort maligned SLOC measures caused many estimation. Even as other metrics have five basic things that are required for a to embrace function points for all types emerged that are considered better by user to get value out of software: Input, of systems, many not well-suited to func- much of the software engineering com- Outputs, Enquiries, Internal Data tion points. The second was that many munity, many of the popular method- Stores, and External Data Stores. A tried to use function points as a panacea ologies used for estimation rely on function point count looks at the num- for all measurement problems. SLOC; many go so far as to convert the ber and complexity of each of these Function points work best for data- better measures into SLOC before actual- components in order to determine the intensive systems where data flows, ly performing estimates. amount of end user functionality deliv- input screens, output reports, and data- There are several likely factors as to ered. Function points create a context base inquiries dominate. As the industry why the SLOC method continues to be for software measurement based on the tried to use function points to measure used despite its many limitations. Many software’s business value. the business value of real-time systems, of the organizations that care about Function points also offer a way to command and control systems, or other software measurement have historical measure productivity that is indepen- systems with several internal logical databases based on SLOC measures. So, dent of technology and environmental functions, they consistently under-repre- although it is a valid argument that factors. It doesn’t matter what program- sented the value that these systems SLOC are impossible to estimate at the ming language is being used or how delivered. It turns out that information requirements phase of a project, it is not mature the technology is, it doesn’t mat- about inputs, outputs, and data stores is hard to understand why so many organi- ter how verbose or terse the program- not adequate for determining the value zations find that they can do it success- mers are, it doesn’t matter what hard- of software that has a lot going on fully within their own product space. ware platform is used—100 function behind the scenes. In 1986, Software They have calibrated their processes and points is 100 function points. This pro- Productivity Research developed feature understanding around this and have met vides businesses a way of looking at var- points to try to address this shortcoming significant success using the SLOC ious software development projects and with function points. The feature point
24 CROSSTALK The Journal of Defense Software Engineering March/April 2009 The Evolution of Software Size: A Search for Value definition added algorithms to the enti- ductivity desired. They still present a [5]), with use cases being introduced by ties that are counted and weighted. Mark good tool for organizations that develop Ivar Jacobson in the mid-80s [6]. Use II function points were introduced by comparable software products to use for cases provide a language for describing Charles Symons and Boeing introduced both benchmarking and determining the requirements of a software system in three-dimensional function points. The best practices. There are, of course, a way that facilitates communication Common Software Measurement Inter- additional limitations with function between developers and the eventual national Consortium’s (COSMIC) full points. Although well-documented rules users of the system. Each use case function points were unveiled in the late exist for counting function points, there describes a typical interaction that may ’90s and became ISO-certified in 2003. is still subjectivity in the interpretation occur between a user (human operator COSMIC function points provide multi- of these rules. Furthermore, the process or other software system) and the soft- ple measurement views, one from the of counting function points has yet to ware. The focus is on the functions that perspective of the user and one from the be effectively automated; the manual a user may want to perform or have per- perspective of the developer. All of process is time-consuming and requires formed, rather than on how the software these alternate methods were intended professional certification. will actually perform those functions. to address one or more of the weak- Use case points count and classify the nesses or limitations of Albrecht’s func- Other Size Measurements actors in the use case and the transac- tion points—now commonly referred to Other sizing measures have been intro- tions that are required to make the use as International Function Point Users duced over the years as well. In the ’80s, case happen. Use case points describe Group (or IFPUG) function points. The as object-oriented (OO) design and the functionality being delivered rather industry loved the idea of having a point development gained popularity, there than the way this functionality is imple- system to define value, but, as with mented; in other words, they describe SLOC, the industry could not agree on business value. As with function points, the best way to measure points. But a crazy thing there are still technical and implementa- Despite the limitations and obstacles, “ tion details that must be addressed on the industry finally had a better way to happened when top of business value when used for measure productivity for software devel- estimation. Unlike function points, the opment projects. And, if you can use it organizations started use case points can cover a wider spec- to measure productivity, it certainly can trum of application types.The problem be used to estimate new projects as well. using function points to with utilizing use cases is their lack of If your organization knows how many standardization across the industry and days it takes to build a function point, estimate projects: even across organizations. An organiza- planning projects into the future should tion that has a well-defined process for be a breeze. But a crazy thing happened They discovered that defining use cases could successfully use when organizations started using func- them for productivity tracking and effort tion points to estimate projects: They things other than estimation. discovered that things other than busi- Agile software development prac- ness value drove project costs. While business value drove tices are adding additional options for function points were good for measur- measurement of the output and produc- ing organizational productivity, they project costs.” tivity of software projects. Agile devel- weren’t really fitting the bill for estimat- opment offers a relatively new paradigm ing cost and effort. The value adjust- for the successful production of soft- ment factor (VAF) was added to the def- was a flurry of activity to develop soft- ware solutions. The tenets of Agile inition of a function point in a rather ware measurements related specifically include very short, well-contained itera- weak attempt to address this limitation. to artifacts that came from OO designs. tions of software development that can VAF takes into account general systems These measures made it possible to per- be carefully measured with respect to characteristics such as the amount of form productivity studies across similar the output of business value. Measures online processing, performance require- projects. Little was done, however, to of story points, acceptance tests passed, ments, installation ease, and reusability. relate these artifacts to the value that the and unit tests created and/or passed It then uses those characteristics to software delivers, making these studies replace more traditional measures with adjust a function point count based sole- less applicable outside of a specific values that speak more directly to the ly on functional user requirements. With application domain. Additionally, business value added in each iteration. the VAF, the function point community because a design was required in order Story point measures focus on function- managed to stray from business value to assess these artifacts, the measures ality that provides end-to-end business while adding very limited additional abil- were not particularly suited to estima- value. They are defined within the soft- ity to accurately predict development tion. OO metrics never really caught on ware development group and are used costs. Estimating costs using value- in a widespread fashion, although there by the group to estimate effort and to adjusted function points became its own are pockets within the community that measure the productivity of successive form of professional malpractice. have found OO measures they are happy iterations. Over time, with discipline, Function points, in their many varia- with and can use effectively. these groups become proficient at tions, offer the software engineering There is a measure which grew out assigning story points to the software community a better window into busi- of object orientation that shows some features they are asked to develop. Test ness value, although the existence of promise in the representation of busi- cases developed and/or passed measure many definitions does not lead to the ness value. Use case points were intro- the quality dimension of business value. cross-cultural comparisons of the pro- duced in 1993 by Gustav Karner (see Agile measures such as story points and
March/April 2009 www.stsc .hill.af.mil 25 Software Engineering Technology tests passed, while having little value one unit of measurement to answer all the output and productivity of software outside of a specific software develop- problems should be avoided. In a per- development projects. Simultaneously, ment group for benchmarking or com- fect world, it would be possible to estab- the software engineering community is parison studies, offer a great deal of lish a one-to-one correspondence attempting to bridge the gap between IT external value for communicating pro- between the effort associated with a and the business by working towards a ductivity and quality and provide an software development project and the business value-based language to N excellent tool for negotiating features business value delivered by that project; describe our software. with management. in the real world, however, there are other factors that come into play. What References Future of Software Sizing seems clear is that with discipline, rigor, 1. Wolverton, R.W. “The Cost of The software industry has struggled dur- and well-defined practices, organizations Developing Large-Scale Software.” ing the last 25 years to find the right way can be successful using any unit for soft- IEEE Transactions on Computers to assess the productivity and quality of ware size for internal project planning Vol. C-23, No. 6: 615-636, June 1974. software development projects. The and productivity studies. 2. Jones, Capers. “Measuring Defect entire industry continues searching for So far, we have failed to identify a Potentials and Defect Removal Effi- solutions because high-quality assess- universally applicable measure for size. ciency.” CrossTalk June 2008. ment methods are necessary for proper The scope of a software project has 3. Albrecht, Allan J. Measuring Appli- project planning and execution. It is multiple dimensions. The amount of cation Development Productivity. user functionality is an important important to understand organizational- Proc. of the Joint SHARE, GUIDE, dimension but, if viewed alone, it has ly how productive our software develop- and IBM Application Development limited value outside of a very narrow ment ventures are. Organizations hop- Symposium. 14-17 Oct., Monterey, context. External benchmarking and ing to improve software processes also CA. IBM Corporation, 1979. productivity studies need to be per- measure in order to benchmark their 4. DeMarco, Tom. Controlling Software formed within stratified categorizations organization against others considered Projects: Management, Measurement of feature complexity and non-function- best in breed and Estimates. Upper Saddle River, . The formula for productivi- al requirements. ty is output divided by effort. Our strug- NJ: Prentice Hall PTR, 1986. While there is still no answer to the 5. Banerjee, Guntam. “Use Case Points – gle has centered on finding the right question of what’s the best way to mea- units to describe output. An Estimation Approach.” Aug. 2001 sure the output of a software develop-
26 CROSSTALK The Journal of Defense Software Engineering March/April 2009