 | Function-Point-Estimation-2 | FPA-Building-Blocks |  |
Introduction to Function Point Analysis (FPA) |
A Function Point (FP) is a standardized unit of measure that quantifies the functional requirements of a software system from the user’s perspective.
Developed in the late 1970s by Allan Albrecht at IBM, FPA became an industry standard for sizing and estimating projects prior to detailed design.
This Section introduces the fundamental concepts of Function Point Analysis (FPA). We'll explore what a Function Point is, why it's a crucial metric for software projects, and the core components that make up the FPA methodology. The goal is to establish a solid foundation for understanding how to measure software size from a user's perspective. FPA was first developed by Allan Albrecht at IBM in the late 1970s as a response to the inherent problems with using Lines of Code (LOC) as a software size metric. LOC is highly dependent on programming language, developer skill, and coding style, making it unreliable for comparing projects or estimating new ones. FPA's strength lies in its ability to be applied early in the software development lifecycle, often from user requirements alone, before any code is written. This early application makes FPA invaluable for pre-contract negotiations, feasibility studies, and initial project planning.
A Function Point is a unit of measurement to express the amount of business functionality a system provides to a user. Instead of counting technical elements like lines of code, FPA measures the logical, user-facing functions, making it a powerful tool for early-stage project planning and estimation. The official definition, according to the International Function Point Users Group (IFPUG), is "a unit of measure for software size that is based on the functions a user requests and receives." Think of it like a builder measuring a house not by the number of bricks, but by the number of rooms, windows, and doors—these are the features the user cares about. The resulting Function Point value provides a tangible, objective measure of the system's size, which is directly tied to the value it delivers to the end-user.
FPA provides a consistent and objective way to measure software size, which is critical for effort and cost estimation, productivity measurement, and scope management. It allows for "apples-to-apples" comparisons across different projects, technologies, and even between different development teams or vendors. For example, a project written in Java and another in Python can be compared directly by their Function Point count, something that would be impossible with LOC. It's especially useful for benchmarking and managing outsourcing contracts because it provides a clear, vendor-neutral basis for negotiation and performance tracking. By focusing on the user's view, FPA also encourages a strong alignment between business needs and technical implementation, as the counting process naturally requires a deep understanding of the user's requirements. This user-centric approach helps prevent scope creep and ensures that the project team is building the right functionality from the start.
FPA breaks down a system's functionality into two main categories: Data Functions and Transactional Functions. Understanding these is key to performing a count. The final function point count is a weighted sum of these functions. Data functions represent the data that is either maintained by the application or referenced from another, while transactional functions represent the processes that actively use this data, such as inputs, outputs, and inquiries. These two categories cover the entire scope of a software system from the user's perspective: the data they need to store and the actions they need to perform.
Represents the data the system stores and manages. This includes Internal Logical Files (ILFs), which are managed within the application, and External Interface Files (EIFs), which are referenced from other systems. These functions are passive; they define the information architecture of the system. For example, a database table of customers and a file of inventory products would both be considered data functions. The distinction is crucial for the count, as they are weighted differently to reflect their complexity and independence. ILFs, being fully controlled by the application, are generally more complex and carry a higher weight than EIFs.
Represents the processes that move and process data. This includes External Inputs (EIs), External Outputs (EOs), and External Inquiries (EQs). These are the active functions that a user interacts with to create, update, or retrieve information. For example, a screen for entering a new customer's details is an External Input, while a generated report showing sales figures is an External Output. The transactional functions are the core user actions that drive the system's behavior and deliver tangible business value.
| | Function-Point-Estimation-2 | FPA-Building-Blocks | |