Function Points: The Real Software Currency

DavidA successful outsourcing arrangement is one that delivers a high quality product that meets the needs of the business (provides value) for a reasonable price. You want to measure your outsource providers level of service to ensure the delivery of real value at a reasonable price. So, an ideal scenario would be to have one single measure that would serve to measure both cost and value.

Function Point Analysis is an industry accepted software sizing method that does just this. Read David Herron, Vice President of Software Performance Management's, paper: Successful Outsourcing: Measuring for Price and Value, to learn why Function Point Analysis is the most appropriate measure and how it can be applied.

Join David for a webinar on January 21, "Function Points: The Real Software Currency," for an expanded look at this topic. David will explain how IT outsourcing contracts can use function points as a default currency of value for improved governance.

Register for the webinar now.

Written by David Herron at 08:30

Why You Need To Size Your Software

DavidAre 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.

David Herron
Vice President, Software Performance Management

Written by David Herron at 11:00

The Estimation Center of Excellence: A Case Study

A global financial solutions provider was struggling with its limited capability to accurately predict and successfully manage its software delivery schedule. Based on DCG’s reputation in the field of software metrics, the company reached out for help.

DCG proposed the creation of an internal sizing and estimating Center of Excellence (CoE) following its Build, Operate, Transfer (BOT) approach. This approach starts with the creation of the CoE under the operation of DCG, with ownership transferred to the company over time.

To learn more about this engagement and the BOT approach, read our case study: DCG Establishes Estimation Center of Excellence for Global Financial Solutions Provider, Resulting in Increased Project Oversight and Improved Vendor Management.

The engagement is currently running successfully and the company has reported an improved ability to evaluate third party vendor bids based on software development efforts.

Questions? Leave them in the comments - we're happy to answer them!

Read it Now!

Written by Default at 05:00

'No Estimates' in Action: Our Thoughts

On November 5, Matthew Heusser posted on an article on, "'No Estimates' in Action: 5 Ways to Rethink Software Projects." The article purports that estimates are not essential in development, and this idea has been pushed by Woody Zuill, a development manager at Hunter Industries, through the use of the hashtag #NoEstimates.

Obviously, we at DCG believe in estimation and its value. Our clients do too. It's a key part of our business.

However, I quite understand the distraction that an over-focus on estimates can bring to the development process. But, whether we like it or not, software development mainly takes place in a business context.

This brings two constraints to bear:

  1. At the micro level, selection of the best option for any development problem has to consider effort (cost) and duration;
  2. At the macro level, while I agree that tracking against customer satisfaction is a powerful strength of Agile, at least part of the customer's satisfaction will always relate to on-time, on budget. Hence, some form of estimation is not just management overhead but a development best practice.

So, it's fair to say we at DCG disagree, and we say #YesEstimation! Still, we'd love to hear your thoughts - so please share in the comments below.


Mike Harris
DCG President

Written by Michael D. Harris at 10:26
Categories :

Is There a Business Case for Better Estimation

Another month, another new Trusted Advisor report! David Herron, Vice President of Software Performance Management, and I wrote this month’s report, “Is There a Business Case for Better Estimation."

Is There a Business Case for Better Estimation?
Improving software project estimation requires an organization to commit resources to the development and execution of a well-defined software estimating practice. The ROI or value add of an enhanced estimating process may be directly linked to tangible cost savings or there may be savings that are less direct and harder to specify.

This report is intended to provide a value analysis, or business case, for how an effective estimating practice contributes value to the organization in both financial and non-financial terms.

Trusted Advisor is our free research service, open to all IT professionals. Join Trusted Advisor to submit questions to the research backlog and to vote each month on the question you want to have researched!

Tony Timbol
Vice President of Sales

Written by Tony Timbol at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!