There are several other important notes about the FPA process that need to be introduced at this time, so we're including them here:
Measured from the user's perspective
The size of the application being measured is based on the user's view
of the system. It is based on what the user asked for, not what is
delivered. It's based on the way the user interacts with the system,
including the screens that the user uses to enter input, and the reports
the users receive as output. Finally, it's also based on their
understanding of the data that needs to be stored and processed by the
system.
Technology-independent
As mentioned in the objectives section, FPA is also technology-neutral.
As a Certified Function Point Specialist (CFPS) it does not matter to me
what technology you are using to implement your application. It doesn't
matter if it's a Web application written in Java, PHP, ColdFusion, or
.Net; or a client-server app written in Java, Delphi, VB; or even an
AS/400 RPG application. Just show me your screens and your data tables
and I'll derive "number of function points" from there.
Low cost
Adding FPA to your software development portfolio is also very easy.
Historically, adding the process of counting FPs to your development
process results in a cost increase of only 1%.
Repeatable Studies
have shown that multiple function point counters can independently count
the same application to within 10% accuracy of each other. Repeatability
is very important, because without it we could not begin to trust the
data from the hundreds of applications that are stored in repositories
around the world.
Work well with use cases
This process works extremely well with use cases, and can even work with
the concept of "stories" in Extreme Programming.