It's so easy to measure time. It's so easy to measure distance, too. Temperature, speed, and so on. Miles, degrees, hours - these are pretty understandable metrics. The problem occurs when it comes to measuring a project, estimating a software or an application. 

How to measure an application?

There are numerous ideas - one worse than another, though. The problem is an increasing complexity, thereupon no direct methods can be used.
For quite a lot of time, the number of lines of application code was thought to be the most meaningful, but that worked not exactly the way it should. Basically, there are numerous programming languages that can be used to reach one goal.

Each of these languages is different and requires different number of data, and - as a consequence - different number of lines of code. Due to that, the same complex application could consist of thousand of lines if written in C++, and of only two hundred lines if designed in Visual Basic, for instance.

Once the "internal" method have failed, people began thinking about estimating and measuring software from the end user's point of view. And the second method was even worse than the previous one, because final functionality has nothing in common with application's actual complexity. Why did this method fail, too?
It is important to keep in mind that every application's interface is designed as simple as possible. Consider the most popular example - booking flight tickets. What is the customer (application's end user) asked to do? The only thing he needs is to input the destination and flight date. He's not obliged to choose the line and compare each proposition - system's task is to find and present appropriate connections only. Even though it's all a matter of a few clicks by the customer, whole system is extremely complex and bases on thousands of particular software algorithms. 

How to solve a problem?

What people do to solve complex problems? What they do to answer complex questions?
When we have a problem that consists of two particular aspects, we should consider taking care about each aspect separately. Once the first of problems is solved, we can turn to another. After that, everything left is to check whether the particular solutions work well together with greater problem.

Back to measuring application complexity, here is where function points play important role.
Basically, the analysis based on function points can be compared to slicing the problem into smaller parts. With FPA (Function Points Analysis) systems are divided into smaller software components, what makes them easier to analyze and understand.