Are you sizing your software? Do you know the size of your projects or applications? I assume that most people would think to answer that question with a “yes.” After all, you have estimated the effort, duration and cost, and once the project is complete and in production, you know the real cost and you can measure the cost of maintaining the application. But does that information really tell you anything about the size of the software? Isn’t it a bit like me telling you that I bought a new house for $x and that it took n number of months to build – but you really don’t know anything about the size, the number of square feet for example.
When sizing your software, you should want to accurately know how big or small it is so you can properly plan, estimate and manage the delivery of that software. Sizing software requires a size measure that is ideally meaningful to both the development team as well as to the end user, and it should be a measure that can be applied consistently across all projects and all applications.
The development team will want to have an accurate measure of size so that they can properly estimate the level of effort and duration. They can also use the size measure to monitor changing requirements (scope creep) as features or functions are added to the original requirements document. The end user will want a measure of size so that they can understand the relative business value of what is being delivered: what features and functions the user is actually getting. Therefore, we would want a size measure that will satisfy both developers and end users.
The best size measure that satisfies the needs of both the developer and the end user is Function Point Analysis (FPA). FPA is an industry standard for measuring the size of software. It provides a quantitative measure for estimating the size of the software deliverable and it measures the functions and features that are important to the business end user.
In brief, the FPA method defines the size of a software project or application by evaluating five key elements: unique inputs, outputs, inquiries, interfaces and internally maintained data. The methodology clearly defines the characteristics of each of these five elements making it easy to identify and classify. Each unique element is evaluated and assigned a value based on its complexity. The result is a numeric value of size. The cumulative size of all five elements thus represents the total “size” of all the unique business functions.
As a simple example, let’s imagine that a user has requested the addition of five new reports to be included as part of an existing application. A requirements document is produced describing the five reports as new and unique outputs. The function point analyst would identify those five reports as five unique transactional outputs and assign a number of function points to each report based on their relative complexity. The end result is a functional size that represents the enhancements being made to the application.
To continue with our example, the developer can now use this size indicator to estimate how much effort this particular enhancement project will take. By knowing how many hours it takes to produce a function point, the project estimator can use that value and make a calculation to estimate the effort required for this particular enhancement based on its size.
Now, let’s imagine that the user, midway through the project, suddenly realizes that they want to add an additional output report. No problem. The function point size is now recalculated including this additional report and a new estimate is generated. Of course, the project will now take longer, but the user understands that the size of their original request has increased and therefore more time is required to complete the project.
This is, of course, a simple example. But you can begin to see how the function point sizing measure may be used to size and to monitor or control the overall project. It also can serve as an excellent way to help manage customers’ expectations. When the requirements change, that change can be sized and measures can be developed to show scope creep over time. This should help project managers communicate the size of the change and the overall impact to the project.
Function point size can also be applied at the application level. Organizations can size their application portfolio. The resulting size of each individual application, as well as the entire portfolio, can serve to monitor and manage application maintenance support. For example, application and portfolio growth can be tracked for more efficient resource loading and budget planning.
The key to successful software management is having the right information available to make the best possible decisions. Knowing the size of your software deliverable is one of the key indicators that contribute to improved decision making.
Vice President, Software Performance Management