 | FPA Calculatoin | PM-Interview-Questions |  |
FPA Practical Application |
| # | Characteristic | Description | Rating (0–5) |
|---|---|---|---|
| 1 | Data Communications | Does the application require communication with other systems over a network? | |
| 2 | Distributed Functions | Are functions or processes distributed across multiple physical locations? | |
| 3 | Performance | Are there strict performance requirements (e.g., response time or throughput)? | |
| 4 | Heavily Used Configuration | Will the system be executed in a high-volume or resource-constrained environment? | |
| 5 | Transaction Rate | Will the system process a high number of transactions per unit time? | |
| 6 | On-line Data Entry | Does the system support on-line data entry with validation? | |
| 7 | End-user Efficiency | Are user-convenience features (menus, help screens) critical for efficiency? | |
| 8 | On-line Update | Does the system allow on-line updates to internal logical files? | |
| 9 | Complex Processing | Does the application include complex internal logic or calculations? | |
| 10 | Reusability | Are there components designed for reuse in other applications? | |
| 11 | Installation Ease | Are there special installation or conversion requirements? | |
| 12 | Operational Ease | Does the system need to be easy to operate and administer? | |
| 13 | Multiple Sites | Will the application be used at more than one site? | |
| 14 | Facilitate Change | Are the requirements likely to change frequently, necessitating maintainability? |
After rating all 14 GSCs, sum the ratings to get TDI (Total Degree of Influence).
In this final Section, we apply our knowledge to a practical case study: a simple e-commerce platform. This example demonstrates how the abstract rules and calculations translate into a tangible estimate for a real-world project. We'll see the breakdown of function points and understand how this final number can be used for project planning, resource allocation, and budgeting. The case study serves to illustrate the entire process, from identifying functions to performing the final calculation, in a way that is easy to follow and understand.
The example e-commerce platform has a user registration system, a product catalog, a shopping cart, and a payment processing integration. For this system, the UFP breaks down as follows, illustrating the relative size of each function type:
The final adjusted Function Point count is not just a number; it's a powerful input for estimation. By using historical data (e.g., your team's average hours per function point), you can convert the FP count into a reliable estimate of effort, cost, and duration. For example:
Effort (hours) = Final FP Count $\times$ Historical Rate (e.g., 8 hours/FP)
The 'historical rate' is a crucial metric that a team develops over time by tracking past projects. It's the average number of hours it takes a developer to complete one Function Point. This provides a much more robust and objective measure for project planning than relying on a simple guess or an outdated metric like lines of code. It enables better budgeting, more accurate timelines, and a more transparent way to measure team productivity. This is the ultimate goal of Function Point Analysis: to move from guesswork to data-driven estimation, leading to more predictable and successful software projects. By tracking these metrics over time, organizations can continuously refine their estimation processes and improve their overall development efficiency.
| | FPA Calculatoin | PM-Interview-Questions | |