Functional Size Estimation

DavidIn a recent IEEE Software article*, the authors (Christof Ebert and Hassan Soubra) provide a comprehensive overview of estimating techniques for software maintenance. In particular they focus on the use of functional size measurement (FSM) as a key parameter for successfully estimating a software project.

What may be most refreshing about the article is the candid observations made regarding the realities of project estimating. For example, they make note of the fact that estimates are often confused with goals or plans and failure to understand the gaps among goals, plans and estimates is often the cause of failure. Additionally, they note that FSM can be "tedious and time-consuming" for organizations with a larger number of projects to measure and go on to introduce a selection of automated tools that support FSM.

The article also does a nice job of introducing the COSMIC method of measuring software’s functional user requirements (FUR) for both the business and real-time applications. This supports their premise that estimation has moved away from being about size and is moving towards a greater focus on functional estimates. Our experience at DCG, seeing the widespread use of IFPUG function points, would underscore that premise.

Finally, the authors included a mini case study that helps to further advance the reader's understanding of the use of FSM. All in all, this article is a good read and provides some useful observations and information that anyone interested in sizing and estimating should know.

If you find yourself intereste in more information about COSMIC and Function Point Analysis, look no further, we have an article comparing the two.

David Herron
Vice President, Software Performance Management

* Functional Size Estimation Technologies for Software Maintenance, IEEE Software, 11/2014

Written by David Herron at 05:00

Improving Estimation Across the Organization

MikeInaccurate software project estimates are the cause of a lot of waste and increased project risk in IT departments. Here at DCG, we often work with clients to improve their software delivery estimation programs to cut down on this waste.

A recent article from IEEE Software, “Organizational Effort Estimation,” discusses the fact that while single-task effort estimations are improving, projects are still often exceeding their estimates.

The authors purport that a focus on single-task estimation is the biggest issue – something that we at DCG agree with. While single-task estimation can offer a useful guideline, an approach that focuses on the organization as a whole is best. As explained in the article, such an approach requires guidelines in the categories of governance, people, processes and tools.

The guidelines for governance begin with the establishment of measureable goals around key performance indicators. Estimators must also be required to follow a standardized framework, which has been accepted by all stakeholders; this should include standardized project phases and defined responsibilities for all stakeholders. The success of such a change also is also dependent on full support from the CIO.

In terms of people, two staff roles must be put in place: a skilled administrative support team and an internal (or outsourced to someone like DCG) pool of trained planning and estimation professionals. The pool of professionals should maintain responsibility for the estimation of all projects. Occasionally, external audits should be conducted (something we can help with!).

When it comes to process, it is important to integrate estimation into an overall quality management process. The estimation process itself should be as standardized as possible.

Finally, the tools used for estimation should have a high degree of standardized parameters and calculations. If possible, organizations should develop their own set of standard parameters for the tools they use.

Of course, there are challenges to implementing these guidelines, which are discussed in the article, but they can be overcome with careful planning. The new guidelines should be implemented one step at a time, with the use of pilot projects, and training materials and communication systems should be in place before attempting such a major change.

Overwhelmed? We can help; start here.

Read the article: Organization Effort Estimation

Mike Harris
DCG President

Written by Michael D. Harris at 05:00
Categories :

Software Estimation is Just That - An Estimate

DavidSuccessfully estimating a software project is not an exact science; therefore, the estimate delivered may have significant variances from actual results. This fact leads organizations to question the usefulness and value of software project estimating. However, the estimating process will always be successful if it includes one key element - open dialogue with the end user/customer.

Estimating a software project is about identifying and managing risk(s). Once the risk factors are identified, the estimator goes to work trying to determine the impact those risk factors will have on delivering the software solution on time and within budget.

A proper estimating model will be able to assess all of the risk parameters identfied and calculate an estimate based on historical data relative to the project being estimated. The output(s) from this process can then be shared with the end user/customer as appropriate.

Whether or not the resulting estimate is considered to be "accurate" may be open to debate; therefore, the value of putting forth the effort to generate an estimate may come into question. However, regardless of the actual results of the estimate, we have found that there is a great deal of value in engaging the end user in a dialogue and being very candid and open about the identified risk factors and the probability of the estimated outcomes.

The issue is as simple as building a relationship of trust and transparency with your end user. We would never represent an estimate as being 100% accurate. No one has that kind of crystal ball. But what we do know is what assumptions we made going into the estimate and our experience with probability trends. We want to let the end user know about the various risk factors we considered. In return, we want them to contribute their input, thoughts and experiences. If we are less than confident with the projected estimates we, of course, want them to know that too.

The estimating process should be viewed as an important part of a successful partnership you and your end user have in the development and deployment of the software deliverable. The estimate itself is not always the most important outcome of the process; rather, it's the opportunity to have a deeper discussion and more thorough analysis of the software deliverable, allowing for more informed decision-making.

David Herron
VP, Software Performance Management


Written by David Herron at 05:00
Categories :

The Mythical Accurate Estimate

AlanI’ve been contributing to a stream on the ISBSG discussion forum on LinkedIn recently, and it amazes me, though it shouldn’t, that estimating continues to exercise so much discussion. Part of it boils down to the confusion of price and estimates. The myth persists that an estimate is a quote, but it cannot be, as an estimate will only be 100 percent accurate at delivery.

In reality, estimates are approximations based on models. That is true with expert estimating, as much as it is with SLIM, SEER and COCOCMO. The quality of the model depends on the quality and completeness of the input data.

An estimate is the most accurate view of the likely effort needed to deliver a specified set of tasks in a defined period and to a set quality, given the quality of the information available at the time the estimate is created. With large projects, estimates should be refined over time.

So, why go with parametric models rather than expert estimates? The simple answer is that over time, parametric models have been proven to be much more accurate than expert estimates. Or, maybe I should say, they are much less inaccurate than expert estimates.

Expert estimates are done by highly skilled people. Studies show that they are as likely to be wrong as right – see our Trusted Advisor Report – though when experts create a model based on historical data, they can be better.

In EDS, we used to think of the estimating process as if it were a mini-project in its own right, and I think that is still a valid proposition. You gather the data, you process it, and doing so, you identify risks associated with the information you have been given. You have to surface and manage the risks, and your estimate must indicate where the risks lie. FPA allows you to size a requirement, but a poor requirement leads to an inaccurate size measure. You must record the potential for growth as part of the sizing process and identify the risks to the project.

The worst case I ever saw was a company who had poor estimating skills and didn't recognise the risks associated with a wildly sketchy requirement. We were brought in as the programme was being canned. The original requirement was counted by my team at 7,000 FP, but we marked it as a red risk for lack of detail and potential for extreme growth. The final size was 30,000 FP and growing. They fixed the price based on the original requirement, didn't revisit the estimate, and then wondered why it all went wrong.

Many projects use multiple methods for delivery, so when you're creating your estimate you have to simplify the model so that the variables are manageable. Trying to take every variable into account means that by the time you deliver your estimate, you run the risk that the work will have already been done by someone else. In any case, if you have no size measure and no risk register associated with the measurement, you won't have a viable estimate.

An estimate is an approximation to enable you to manage your financial exposure, set a budget, construct a plan and build a team to deliver it. If the risks are too great and unmanageable, don't even start the project. Iterate the process until you can deliver a meaningful estimate, that way you are more likely to deliver the project successfully.


Alan Cameron
Managing Director, DCG-SMS

Written by Alan Cameron at 05:00
Categories :

Software Analytics Training

David Consulting Group is well-known throughout the industry for our expertise in Function Point Analysis and Software Estimation. As such, we offer a number of classes to share what we’ve learned over the years and to help your organization improve its Software Analytics practice, no matter your current level of implementation.

Here’s what we currently offer:

  • Function Point Fundamentals - A two-day course to teach you how to apply function point counting techniques. This class can be deployed on-site or via DCG University, our online learning platform.
  • Function Points: Advanced - A one-day course to accelerate your comprehension of the Function Point Analysis technique through intensive instruction and hands-on practical application.
  • CFPS Preparation - A one-day course to prepare participants for their certification exam. This class can be deployed on-site or via DCG University, our online learning platform.
  • Quick and Early Function Points - A one-day class that provides quick techniques for sizing units of work to support estimating and measuring progress.
  • Estimation Techniques Workshop - A two-day course to help you to understand estimation and sizing as it applies to your organization.

All of our classes can be customized to meet your needs, so if you have specific goals or questions, just ask! We’re happy to work with you in any way that we can to help you implement or improve a Function Point Analysis or Estimation program. If training isn’t what you’re looking for, we provide Advisory Services as well!


David Herron, Vice President


David Herron
Vice President, Software Performance Management

Written by David Herron 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!