GPS application - evaluating the cost needed to introduce new functionalities

This example for estimating the cost of introducing new functionalities is based on a GPS application.

Let's predict we have one of the first GPS applications ever made - it shows only where you're right now. Even though there's appropriate map installed, application can do nothing with it. Then, we need to turn ourselves into visionaries for a while, and invent a "new" idea - we want GPS to show us a few possible routes. The presumptions are simple - we want to be asked for a destination, and - then - receive a few possible routes in revenge. The problem is that there are thousands of possible routes between New York and San Francisco, for instance.

Thousands of more or less stupid ones, and only a few worth considering. How to let the system choose these last ones? The shortest, and the fastest one? That's quite a good choice, but here comes the whole complexity - how to let the system count it?

In the same way as in the application development case, we need to expatiate files and divide them into categories. Once we know the "exact" number of function points representing the project, we can turn them into work hours, work days, and - finally - into money.

The important thing to remember is the fact that interface simplicity has nothing in common with application's complexity. And it must be kept in mind when trying to understand the sense of Function Points Analysis.