0% found this document useful (0 votes)
16 views

Function Point Analysis (FPA)

Function Point Analysis (FPA) is a technique for measuring the size and complexity of software applications based on user requirements, focusing on functionality rather than implementation. An example scenario is an online banking system, where various functions are identified and categorized, and function points are calculated based on their complexity. The total function points for the system are determined to be 44, and environmental and technical complexity factors are assessed to further evaluate the system's complexity.

Uploaded by

M Shayan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views

Function Point Analysis (FPA)

Function Point Analysis (FPA) is a technique for measuring the size and complexity of software applications based on user requirements, focusing on functionality rather than implementation. An example scenario is an online banking system, where various functions are identified and categorized, and function points are calculated based on their complexity. The total function points for the system are determined to be 44, and environmental and technical complexity factors are assessed to further evaluate the system's complexity.

Uploaded by

M Shayan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Function Point Analysis (FPA) is a method used to measure the size and complexity of a

software application by quantifying its functionality based on the user’s requirements. FPA
focuses on what the system does rather than how it is implemented. Here's an example
scenario where we can apply Function Point Analysis:

Scenario: Online Banking System

Imagine we are developing an online banking system that allows customers to:

1. View account balances


2. Transfer funds between accounts
3. Pay bills
4. View transaction history
5. Change account settings

We'll perform Function Point Analysis (FPA) on this system by analyzing the functions provided
to the user and classifying them into various function types such as External Inputs (EI), External
Outputs (EO), Internal Logical Files (ILF), External Interface Files (EIF), and Queries (EQ).
Afterward, we will calculate the function points based on the complexity of each function.

Step 1: Identify Functional Components

We break down the features of the system into the following components:

1. View Account Balance


o Function Type: External Input (EI)
o Description: The user inputs their account credentials (login) to view their
account balance.
o Complexity: Low
2. Fund Transfer
o Function Type: External Input (EI)
o Description: The user selects the accounts (source and destination) and enters the
amount to transfer.
o Complexity: High
3. Pay Bills
o Function Type: External Input (EI)
o Description: The user selects the biller, enters the amount, and confirms the
payment.
o Complexity: High
4. View Transaction History
o Function Type: External Input (EI)
o Description: The user requests to view their past transactions.
o Complexity: Low
5. Change Account Settings
oFunction Type: External Input (EI)
oDescription: The user modifies their personal settings like contact information or
notification preferences.
o Complexity: Medium
6. Account Details Report
o Function Type: External Output (EO)
o Description: A report showing detailed account information (balances,
transactions, etc.).
o Complexity: Medium
7. Transfer Confirmation Message
o Function Type: External Output (EO)
o Description: Confirmation message displayed after a successful fund transfer.
o Complexity: Low
8. Transaction History Query
o Function Type: External Query (EQ)
o Description: The user queries their transaction history from the database.
o Complexity: Medium

Step 2: Determine Complexity Levels for Each Function

Function complexity can be classified into Low, Medium, and High based on the number of
data elements and interactions involved. Below is a table summarizing the complexity of each
function type:

Function Type Low Complexity Medium Complexity High Complexity


External Inputs (EI) 4 FP 5 FP 7 FP
External Outputs (EO) 5 FP 7 FP 10 FP
External Queries (EQ) 4 FP 5 FP 6 FP

Now, we can assign function points based on the complexity.

Step 3: Calculate Function Points for Each Component

1. View Account Balance: EI (Low) → 4 FP


2. Fund Transfer: EI (High) → 7 FP
3. Pay Bills: EI (High) → 7 FP
4. View Transaction History: EI (Low) → 4 FP
5. Change Account Settings: EI (Medium) → 5 FP
6. Account Details Report: EO (Medium) → 7 FP
7. Transfer Confirmation Message: EO (Low) → 5 FP
8. Transaction History Query: EQ (Medium) → 5 FP

Step 4: Calculate the Total Function Points

Now we sum the function points for each component:


Total FP=4+7+7+4+5+7+5+5=44FP

Assess Environmental and Technical Complexity Factors

To apply the adjustment factor, we need to evaluate the system against a list of technical and
environmental complexity factors. The Complexity Adjustment Factor (CAF) is determined
based on these factors. Typically, a scale from 0 to 5 is used for each of the 14 predefined
complexity factors, with 0 indicating no complexity and 5 indicating very high complexity.

Here are the 14 general complexity factors (rated on a scale of 0-5):

1. Data Communications: The complexity of how the system communicates with other
systems (e.g., APIs, third-party services).
o For the online banking system, this could be Medium due to secure API
integration with external banks and payment processors.
o Rating: 3
2. Distributed Data Processing: Does the system involve complex data distribution across
multiple locations?
o For this example, no complex distribution of data is required.
o Rating: 1
3. Performance: How critical is performance, such as response time for users and high
transaction volumes?
o Given this is an online banking system with financial transactions, performance is
quite important.
o Rating: 4
4. Heavily Used Configuration: Does the system need to handle many simultaneous users?
o A banking system typically needs to support thousands or millions of concurrent
users.
o Rating: 4
5. Transaction Volume: How many transactions are processed by the system, and how
frequently?
o A high volume of transactions (payments, transfers, etc.) is typical in banking
applications.
o Rating: 4
6. Online Data Entry: Does the system require a lot of data input from users, potentially
increasing complexity?
o The system will require a moderate amount of data entry (e.g., entering payment
details, account settings).
o Rating: 3
7. End-User Efficiency: How efficient is the system in terms of meeting end-user needs
with minimal effort?
o The system needs to be user-friendly and efficient, but it’s not overly complex in
terms of UI/UX.
o Rating: 3
8. Complex Processing: Are there any complex calculations or algorithms that need to be
performed?
o Online banking may require complex calculations (e.g., exchange rates,
transaction fee calculations), but this is still relatively straightforward.
o Rating: 3
9. Code Reusability: Are there opportunities for reusing existing code?
o This system could involve some reusable banking functions (e.g., authentication,
transaction processing).
o Rating: 3
10. Installation Ease: Is it easy to deploy and install?

 Bank systems may require specialized installation and configuration but are not overly
difficult.
 Rating: 2

11. Operational Ease: How easy is the system to operate once deployed?

 Since this is an online banking application, the system must be easy to manage post-
deployment, especially in terms of monitoring and troubleshooting.
 Rating: 3

12. Multiple Sites: Is the system deployed across multiple locations or regions?

 The system may support different geographical regions, but this doesn't introduce high
complexity.
 Rating: 2

13. Facilitate Change: How easy is it to make changes to the system?

 The system must allow for regular updates and patches, but this is not overly complex.
 Rating: 3

14. Use of Third-party Software: Does the system rely on third-party software?

 The system integrates with several third-party financial services (e.g., payment gateways,
bank networks).
 Rating: 4

You might also like