Function Points, or not Function Points: that is the question
I have recently read an article in the Chronologist blog, by Steve Tendon, with a title that caught my attention: ”Function Points Are Fantasy Points”. Steve analyzes Function Points as a metric to estimate project effort that is no longer valid for modern applications, in particular contemporary web applications.
I agree that Function Points are an outdated metric. But you still have to estimate. A lot of money is at stake here.
What is the best way to do it? How would you do it better? Based on what? The more accurate the estimation, the less losses in the projects. When someone loses someone else wins, you don’t want to be the one losing.
Nowadays, and according to the Chronologist’s article, estimators should be in the breach of technology to have the knowledge that allows them to estimate the effort to implement some functionality with a given development framework. And it is a fact that your typical project manager doesn’t have the technical skills for it. That is when developers, analysts or software architects come into the picture. There is not much discussion here. The ones that have the knowledge are the ones that have to estimate, and the ones that are going to build a system know how they are going to do it.
Let’s look how it works in the real brick and mortar construction projects. Do you ask the construction workers how long is it going to take them to build a column or a wall? I don’t think so. I understand that it is the architect the one with necessary knowledge about the techniques to be used in the construction and she will expect that the construction workers will build the elements in the time estimated. But I don’t see the promoter of the building giving the estimations either.
The same for software systems, the architects that design the solution should be the ones to estimate the effort since they are the ones who know and have the details.
Function Points were defined when technology were more or less stable. Today development frameworks and technologies sprout every day like mushrooms in a forest after an October storm, making us to rethink how we measure the effort for each particular framework or technology. They come out so fast that sometimes it is not even worth it to define an estimation method. Does it pay to research, define and establish a method when we will probably have to throw it away and start over when we adapt our application to the latest technically beneficial framework?
When there is so much money behind an estimation (and there is), big companies need to feel secure within a well known, ‘de facto’ standard estimation method so the C’s can feel they are not alone in this –“Oh well, I’m not sure it is the best, but if it is what rest of the world is doing we will all win or lose the same way”–. Being so, to cope with the risk, more than an outdated standardized method like Function Points, now in seems better to have a team of expert architects to estimate based on knowledge and experience.
But there is a major flaw with this approach: people leave the companies looking for new challenges, what happens then? The knowledge is gone and you need to rebuild it. This may be a good reason to use standard estimation methods that don’t rely on internal people so much and the estimator is not so “key”. This way you can delegate on external experts to have an objective estimation of Function Points, costly but very necessary when you outsource the development. Why does a software factory have to accept what an architect in the contracting company says? Or, why does the contracting company has to accept what the contractor estimates it needs to build the system? Sometimes the situation is that the architects designing your solution belong to the contractor, which may look like something you shouldn’t do overall if you are going to be responsible of the maintenance of the system. But it often happens, like when I have to do some refurbishing work in my house: I don’t have the knowledge to discuss the only thing I can do is to compare budgets. It all depends on the outsourcing model you use.
Still, are there any other ‘de facto’ standard metric we can use for more accurate estimations that may substitute Function Points? Story Points, often confused with Function Points but, as the Chronologist explains in his ”Story Points are NOT Function Points” article, they are not the same.
What do you think?
Meet the author Juan Carlos Castromil
Computer Engineer with professional experience in software quality since 2006. Specialist in consulting and Quality Departments implementations for different companies mainly in the banking and insurance sectors. I have recently started doing pre-sale tasks in Spain and Latin America for Optimyth´s solutions.
3 comments on “Function Points, or not Function Points: that is the question”
Leave a Reply
Follow us
Subscribe
button in the bottom right corner
A cool SIZE measure for “modern” systems: use case points. Good for RUP or other loosely UML-based methodologies:
http://www.bfpug.com.br/Artigos/UCP/Clemmons-Project_Estimation_with_UCP.pdf
I used them in my previous job, with very good results.
UCP, anyway, are just a functional size, which is the real issue, in my opinion. Technology, R+D, refactoring, algorithms study, optimization… these are variables that are considered always “adjustment factors” to functional estimation…but I think that they should be measured a part. And many time they represent most of your business. AFAIK there is no estimation method for R+D tasks, they are generally budget-driven…
I do not agree entirely with you. Point-based estimating is about the time the work will take, at least in agile environments. IMHO function points are not a significant improvement in how we build software.
Measuring with points is not like using with pounds instead of kilograms, it is like everyone has their own “kilo” scale they calibrate with, and they are all different.
Seriously, how big is a point? Each ‘scale’ is based on some estimate of how long some task may take. (If we could do that reliably this problem would not exist)
If you compute velocity based on real progress and use that to make forecasts, estimates will be more accurate.
I am not at all sure Function Points are an outdated technique. Yes, they have known limitations, such as inability to measure scientific or multimedia apps, but overall the very purpose of this technique is to measure functional size of an application regardless of the underlying technology.
What may have become outdated, though, is the productivity calibration data used by default in approaches such as COCOMO. Indeed, a number of effort per function point (that is, productivity) could be quite different in, say, J2RR and RoR, but the functional size still remains the same.