Proceedings 2007 v10 - DPO

Published in Proceedings Software Measurement European Forum (SMEF) 2007

FP Chaos – Making sense of Zero FP projects Carol Dekkers

1. Introduction Productivity based outsourcing contracts first emerged in the early 1990’s with the rise of application development and maintenance agreements. Since then, outsourcing contracts have evolved to encompass greater aspects of IT development and management. Despite this evolution, productivity measurement remains one of the most common gauges of outsourcing achievement. When examining software development performance, the project size (in function points) and effort measured in hours, give way to the hours per function point productivity (delivery rate). This calculation makes sense when we are talking about “new” construction in terms of $ per function point or function points per effort hour. However, when it comes software enhancement or maintenance, using the same productivity equation without careful consideration can result in situations of zero function point projects and thus zero apparent productivity. In some cases, customers become giddy at the thoughts of getting work for free (do zero function points equate to zero dollars?) and outsourcers can begin to lose faith in the power of the function point measure. In fact, I can cite a few outsourcing contracts where the whole notion of how to handle zero function point enhancement projects was given no advance thought and, as a result, the morale and outsourcing relationship has been unnecessarily strained. I attest that including zero function point projects in the portfolio of outsourcing project productivity is a misapplication of function points, because it fails to delve into the reasons, most notably the terminology difference between business and function points that often contribute to this zero FP assessment. The intention of this paper is to clarify the issues surrounding using function points (FP) on enhancement projects in the hopes of creating more equitable and easily understood outsourcing measurements. This paper explores how to realign and properly measure productivity on maintenance and enhancement projects using a common sense guide. Through appropriate measurement and analysis, both outsourcers and customers can benefit through productivity and function points.

• • • •

The following list of topics will be explored in this paper: Terminology and consistent definition of terms (enhancement, productivity, delivery rate). Issues with function points on enhancement projects. Addressing customer needs for gauges / assurance of success. Steps forward.

307


2. Terminology and consistent definition of terms On any software project, there are three types of requirements: • Functional user requirements: These describe WHAT the software will do from a user1 perspective, without regard to how the software must operate or how it will be built. Functional user requirements include elementary business processes, such as: “add customer to database”, or “send data file to payroll system”. Function points measure the size of this type of requirement. • Non-functional user requirements: These describe HOW the software must perform once it is in production and are the business constraints for the software. Non-functional requirements include the “ilities” such as reliability, maintainability, quality, security, portability, etc. as described in ISO/IEC 9126:2000-1 [2], as well as performance, accuracy and other non-functional business constraints. Function points cover a portion of this type of requirement through an adjustment factor called the value adjustment factor. • Technical requirements: These describe HOW the application or project WILL BE BUILT, and include everything from development tools, programming language(s), platforms, reuse (%), work breakdown structure, skills, team size, etc. Function points are independent of the technical requirements. A construction analogy often helps to distinguish the differences in these types of requirements: • Functional requirements are like the software’s “floor plan” and function points measure its size by classifying the rooms (functions) into a number of square feet or meters (function points). The resultant floor plan area (in ft2 or m2) tells us one important piece of data about what we will build – the size. Note that the area of a floor plan is independent of how the building must operate, and also independent of how it will be built. In the same manner, function points reflect the functional size of software and are independent of how the software will operate, and also independent of how the software will be built. • Non-functional requirements are like the software’s “building code” and the value adjustment factor (VAF) used with IFPUG Function Points reflects the complexity of the business constraints on the software. For example, because I live in Florida, we have items in our building code related to hurricane force winds (hurricane hangers must secure the roof to the walls). In software we have constraints related to operational constraints such as reliability (must be available 24 x 7 with an average response time not to exceed 1.0 seconds 90% of the time) or data accuracy (pacemaker software must pass federal regulations to ensure this constraint is met). These constraints pertain to how the software must perform in production, however, they are independent of how large the software is and also independent of how it will be built. • Technical requirements are often the builder (developer) response to address how to satisfy through a physical software implementation the functional and non-functional requirements. As such the decision whether to use Oracle or Sybase, whether to use waterfall or agile development methods, and whether to use power tools (such as Java) rather than hand tools (such as Assembler or Cobol) are all part of the technical requirements.

1

User in the context of functional size measurement means ‘any person or thing which interacts with the software at any time.’ (IFPUG Counting Practices Manual [1]) As such, a user can be other a person using the application, system administrators, other software, hardware, etc – anything that has a requirement to interact (send to or receive data from) the software

308


Work effort and project cost are a function of all three types of requirements: the larger (functional) and more complex (non-functional) and more difficult (technical) a project is, the higher will be the cost and work effort. It follows on that productivity (or more appropriately called “delivery rate”) which is function point size (output) divided by input (hours to develop the function point size) is also a function of all three types of requirements.

3. The word “Enhancement” Now that we have a basic common understanding about where function points fit in, we can begin to talk intelligently about the issues with terminology. The word “enhancement” is the cause of much angst on outsourcing projects involving software enhancement and maintenance because its meaning varies widely between function points and the business. In business, an enhancement is typically anything that enhances the user experience and can mean anything from moving fields around on a screen to upgrading software to making the system run faster, while in the context of function points, an enhancement involves changes to the functional requirements (and potentially the non-functional requirements that are part of the VAF). In actual fact, the majority of business enhancement projects are hybrids containing functional enhancements, non-functional requirements, and/or technical requirements. This is where the outsourcing mismatch occurs – any business “enhancement” projects where there are little or no functional change results in few or zero function points. So, in a contractual situation where (business) enhancement projects are paid for in terms of function points, a (business) enhancement project may be worth only a few function points in spite of many, many hours being expended on changes required by the user. Table 1 summarises the differences between functional, nonfunctional, and technical requirements.

Requirement

Table 1: Requirement categorisation Type of Enhancement to requirement business

1. Add edits to the logic associated with a data entry process 2. Decrease response time for a website 3. Change the literal titles on a set of reports 4. Combine two data entry screens into one form screen (performing the same function) 5. Remove the ability to update a database 6. A combination of the above

Functional

Yes

Non-functional

Yes

Technical or maintenance Technical

Yes

Functional

Yes

Hybrid of all three types

Yes

Yes

Enhancement in function point terms Yes No (unless the VAF increases as a result of this) No No (unless there are also logic changes) Yes Only the functional requirements part

For further clarifications of terminology defined differently in information technology and function points, refer to [3].

309


4. Issues with function points on enhancement projects As you can see from Table 1, business enhancements encompass a wider range of changes to an application than does function point enhancement. A business enhancement project could contain one or more types of requirements, however, only those changes associated with changes to the functional requirements or to the non-functional requirements (where the VAF increases) will result in a non-zero function point count. The majority of business enhancement projects is a hybrid mixture of at least two of the requirements types; i.e., they can contain functional, non-functional, and technical changes. At issue is the fact that non-functional and technical enhancements do not result in any function points, despite the fact that the users wanted the changes and work is expended to deliver to their needs. An example serves to illustrate a few of the issues: Enhancement project A The human resources (HR) department has launched a new software project to “enhance” their main HR system. They want to be able to increase the number of users that can be logged on at once (non-functional) and also want to have the ability to run a new report of average complexity (5 FP) that will compute the total monthly salary for new employees hired in the past month (new functional requirement). The overall project work effort comes out to be 1500 hours with the majority (90%) of work being done to increase the number of users logged on. What is the enhancement productivity of this project? At first glance, most people would calculate the productivity without thinking as 4 FP/1500 hours = .003 FP / hour, but this is an inequitable way of measuring the project delivery productivity. In fact, the first thing we should have done was split the project up into two pieces – the first containing the software development work of creating the new report; the second containing the non-functional requirement of increasing simultaneous access. If this is done using the percentage breakdown of the work, we accurately can determine the productivity (delivery rate) as Productivity = output / input = 7 FP / (10% * 1500 hours) = .03 FP / hour. The non-functional work is similar to renovating a house and replacing the insulation between the walls. It is considered to be work that the user wants, needs, and is willing to pay for; however, it cannot be adequately evaluated by lumping it in with the original project because it does not constitute any functional change to the application. For further information and examples about how to distinguish project parts for enhancement projects, please refer to the IFPUG Counting Practice Manual Release 4.2 [1].

5. Addressing customer needs for gauges / assurance of success It is not uncommon for the customer side of an IT or outsourcing contract to want to measure everything in function points. Unfortunately, function points are not the ‘Swiss army knife’ of measurement – they purely measure the size of the functional user requirements delivered or touched in the delivery of a project. Function point based productivity is intended for use where changes/new delivery items/removed items (functions in function points) go through at least several stages of a software development life cycle.

310


There are a number of measurement situations for which Function Points are ideally suited and a number for which they are not. This is similar to using the right tool for the right purpose. Table two provides an idea of where function point based productivity can and cannot be used for a successful supplier/customer relationship: Table 2: Where Function Points are useful in enhancement projects Object of measurement Is FP/hour suitable? Alternative measures Maintenance project No (0 FP) Maintenance hours / 1000 FP (base) “Enhancement” project where Yes, but only after separating there are multiple applications the project into separate involved and multiple types of subprojects by application, and work (functional and technical removing the technical enhancement) enhancement work from effort hours Data population of tables or No (0 FP) Maintenance hours / 1000 FP one time data extractions (base) Fixes to system software that No (0 FP) System support hours / 1000 was supposed to work when FP (base) à may or may not FP were delivered be grouped with maintenance hours Users who want to measure their IT delivery rates do themselves and their supplier a disservice if they combine all work (FP countable and not countable) into one lump sum of hours, and then try to make sense of the results because the non-functional and technical work is not measurable by function points. For example, would it make any sense to compare two renovation projects in terms of square feet renovated per hour? Renovation project #1 consists of removing the carpet and installing new carpet throughout the living room (400 square feet). The total hours are 400 hours. This is a delivery rate of 1 square foot / hour. Now take renovation project #2: consisting of minor renovations to the kitchen (100 square feet) and the customer also requests the renovators to pressure wash the exterior of her house. Total hours spent = 200 hours, of which 100 hours was spent pressure washing the house. Haphazard calculated delivery rate of renovations = 100 square feet / 200 hours = .5 square feet / hour. So the comparison is 1 square feet / hour versus .5 square feet per hour, and mistakenly supports that the first project is more productive. In actual fact, the calculation of renovation productivity on the second project should be = 100 square feet / 100 hours = 1 square foot / hour – the same productivity rate as renovation project #1. In software, a similar occurrence is common: Take project 1: renovations / enhancements are needed on system A. Screen literals and colours are to be changed (0 FP), two new reports are needed (10 FP) and data encryption is to be added to all data for the protection of data (nonfunctional). If the entire project is 1000 hours, and the hours to complete the reports are 100 hours, only the portion allocated to the functional delivery should be compared to the functional output in FP. (I.e., 10 FP / 100 hours not 10 FP / 1000 hours).

311


No matter how fervent the customer or client is to measure absolutely everything, the right measure is a critical pre-requisite to the measure or metric making sense. In the case of zero function point projects, there are a couple of measurement solutions: 1. The work done may not be functional enhancement at all (thus 0 FP) and the work would be better classified as adaptive or perfective maintenance and classified with that work. Or 2. If the work is truly 0 FP and the users declare it to be data population (i.e., populating databases on behalf of the user and then moving the new datastores into production) – one might consider this as “conversion functionality” applicable to the enhancement project but not to the application count. Or 3. Consider the NESMA leveraged FP research work [4] where FP are allocated on a percentage basis if work has to be done to test or do partial software development life cycle work to meet the user requirements.

6. Steps Forward The best advice I can share with you is to illustrate that the work you are doing is meaningful to your system’s users by measuring the functional enhancements in terms of FP / hour, and separating out work that is not related to the functional work. Zero function point projects do not mean that nothing valuable was delivered by the project – rather it means that the work done on the project did not fit into the FP definition of functional enhancement. When a customer rubs his/her hands together and smile glibly saying, “Oh goody, we get this project for free”, I cringe because I know that work was done to meet their specific needs, and someone will likely get burned by not getting paid. (Note that in most of these cases, the outsourcing agreement generally has problems that lie deeper than function point measurement). Outsourcing contracts must be fair and equitable on both side of the agreement otherwise morale decreases, animosity rises and frustration ensues. Using common sense to separate out the maintenance from functional enhancements goes a long way to restoring trust and sense on the contract.

7. References [1] [2] [3] [4]

IFPUG, Function Point Counting Practices Manual Release 4.2, published by the International Function Point Users Group, Princeton Junction, NJ, 2000, www.ifpug.org. ISO, ISO/IEC 9126:2000-1, International Standards Organiseation, 2000 Dekkers, Carol, Clarifying Common Terminology – Demystifying Function Points, IT Metrics Strategies, Cutter Information Corporation, 2000, www.cutterit.com. NESMA, the Netherlands Software Metrics Association, white paper, www.nesma.nl/english/menu/.

312