Counting function points

Question

I am performing a function point analysis (FPA) for a project. I am completely new to this process and have started with only the login and authentication modules to validate the results I get.

I think I have understood data function well and my count of internal logic files and external interface files is correct. I need some guidance on calculating transaction function (EI, EO and EQ).

Here is the process specification:

1. New users registers and then logs in
2. Existing user logs in directly
3. On registration user data collected and stored.
4. On login usual validation checks: errors on invalid credential, otherwise successful login
5. Session details maintained for logged in users.
6. User suspended temporarily after more than n invalid logins.
7. Session terminated automatically on idle timeout.
8. Update email/password settings using either forgot password or update settings

I am counting very essential part of this process as EI/EO/ILF:

External Inputs: 4

• Login
• Logout
• Register
• Update settings

External Outputs: 3

• Incomplete/invalid registration form
• Invalid login, or user throttled after unsuccessful attempts
• Session timeout

Internal Logical files: 2

• User data
• Session data

No External Queries or External Interface Files.

Despite weighing the above counts with low complexity, I get 38 UFPs = 2014 SLOC (for Java: 53 SLOC per FP), which turns into a suprisingly high effort estimate when using COCOMO II even with the lowest coefficients.

My doubt is not related to FP count or complexity, I am more concerned about whether I am choosing the right things as EI or EO. As far as I understand the FPA technique, any data/control information entering the boundary of application is counted as EI, so logically login, logout, sign up, update settings, forgot password are all inputs. Similarly Invalid login, successful login, any invalid data related error message, timeout information etc are all outputs. So I have even more EI and EOs than I counted above but then output FP count goes high unrealistically.

Am I doing the FPA correctly, or did I misunderstand something?

Answer 1

You are generally doing the Function Point Analysis correctly, and the results look sensible. However:

• You are wrongly classifying some outputs.
• You are surprised by the COCOMO II estimate for the effort.
• This analysis ignores the reality of modern web development: the web framework probably already implements session management.

What is an External Input and External Output?

For a graphical user interface, it is best to think of EIs and EOs as screens, widgets, or forms. Therefore, your login form is one external input. You are classifying validation errors as a separate external output. I would not do that, since the validation (and rate limiting etc.) is part of the login functionality. Instead, I would weigh the login functionality with a higher complexity if it has to do special error handling.

I would classify your items as:

• Login form: External Input, medium complexity. (justified through extra rate limiting logic and other security considerations)
• Registration form: External Input, simple.
• Logout and session timeout: External Input, simple.
• Update settings: External Input, simple.
• Forgot password: External Input, high complexity. (looks simple, but requires careful security design)
• Session storage: Internal Logical File, simple.
• User details storage: Internal Logical File, simple.

That's right, there are no External Outputs here! But to be fair, this application doesn't really do anything yet and just provides a login. If you had a separate screen for viewing the settings versus updating the settings, I'd count that as a separate simple EO. I also assume the various points where login credentials are entered by the user share some common code, so the complexity of handling passwords is fairly simple on average.

Using complexity weights 3× for simple EIs, 4× for medium EIs, 6× for complex EIs, 4× for simple ILFs, I arrive at a function point count of C = 27. This is noticeably less than your estimate, but still in the same ballpark. If you use the adjustment factors F_i, this might shift further up or down.

What does the COCOMO II estimate tell us?

The estimate does not just describe the time spent coding for that functionality. It is an estimate for the whole project duration, and includes some amount of analysis, design and testing. According to a lecture I heard on the topic, only about 30% of the estimated effort would be for development tasks! So if the 27 FPs correspond to an effort of about 3.5 person-months, roughly 1 person-month of that would be development time.

The estimates you get out of COCOMO tend to sound unbelievably long, but when you put that in context – large organizations, differing skill level, unexpected complications and bugs, all the work necessary for software development that isn't just coding – they are a good reminder to not be too optimistic. Of course it's possible to be faster, but you shouldn't bet on it. When the function point analysis is done meticulously, and when it is applied to a project where FPA is a good fit, then the numbers tend to be in a realistic order of magnitude.

Function points and web development.

Web development is a bit different.

First of all, there are many mature web frameworks and libraries that make it easier to create a solid website quickly (as long as you already know that framework). A single experienced person could probably implement your requirements within a day to a week – login is so important and basic that the web framework might actually teach you how to do this as a “hello world” application.

Secondly, web development tends to involve far more lines of code, but those are not necessary as difficult. If you create the login form by hand, you have to write the form in HTML, style it with CSS, perhaps do client-side checks with JavaScript, create an URL where the login form can POST to, and then create the actual backend code that checks the password. That might well be 400 lines of code in total, but that doesn't mean this would take a whole month.^[1] I'm therefore wary of applying COCOMO to web development, since much code is boilerplate that is written very quickly.

^{[1]: Of course a login form can take month to create, e.g. when it needs considerable design effort, or special security features. I'm sure many large websites have spent far more effort than that into that small text field.}