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 Fi, 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.
: 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.