Steps for Function Point analysis
In this article, we will explain the function point estimation method V4.1.1 provided by the International standard Ifpug (International function points Users Group). As shown, first of all, you should understand the use of functional point estimation method.
Steps for estimating function points of graphs
- Identifies the type of feature point.
- Identify the boundaries and scope of the application to be estimated.
- Calculates the number of non-adjusted feature points provided by the data Type feature point.
- Calculates the number of non-adjustable function points provided by the human-computer interaction function.
- Determine the adjustment factor.
- Calculates the number of adjusted function points.
Identify the type of project
The International Ifpug organization divides the software project into three categories, and the function point estimation method applies to any kind of project
- New development projects
- Two projects developed
- Feature-Enhanced projects
Identify the scope and boundaries of the project
Using the UML "usecase" use case diagram is the best way to identify the scope and boundaries of the project at the user's point of view, because the boundary of the system must be clarified when drawing the use case diagram. Through the boundary of the system we can know which functions to calculate the function point, which function point is the external system is responsible for the calculation. Example: A foreign Trade order system contains only the functions of inputting, modifying, deleting, inquiring and counting orders, and the exchange rate query conversion service is not belong to the system.
Application boundary recognition rules It is important to remember that you cannot think from a technical perspective and must be defined from the user's point of view, and if the project involves multiple systems, the boundaries of the multiple systems must be clearly described.
Figure Foreign Trade Order system use case diagram
FP function Point Estimation classification
The FP function point estimation method divides the function points into the following 5 categories:
- ilf:internal Logical file Internal logical files
- eif:external Interface file External interface files
- Ei:external Input External inputs
- Eo:external output External outputs
- Eq:external Inquiry External Query
Where ILF and EIF belong to the function point of data type, EI, EO, eq belong to the function point of human-machine interaction type.
Take the Foreign Trade Order System project as an example:
- Enter the order, modify the order, delete the order is EI;
- Query order is EO
- Stats order is EQ
- Exchange rate query conversion system for EIF
- Orders and customers are ILF
Key principles for identifying functional points
ILF and EIF should be calculated separately from EI, EO and eq. The calculation of the complexity of ILF and EIF can be easily understood as the computation of database complexity. The calculation of the complexity of EI, EO and EQ can be understood as the computation of the complexity of the program development. General software projects are composed of data and programs, so there is no relationship between calculating ILF, EIF, and calculating EI, EO, and EQ.
Internal logical files and external interface files
ILF Internal logic files
An internal logical file is a set of logic-related data or control information that is identified at the user's perspective and maintained within the bounds of the application. The primary purpose of ILF is to maintain data through one or more basic processes of the application.
EIF external interface file
An external interface file refers to a set of logically related data that is queried within the bounds of the application, but is maintained in other applications and is identified by the user's perspective. So EIF in one application must be ILF in other applications. The primary purpose of EIF is to provide one or more sets of data or information referenced by the underlying operation process for applications within the boundary.
The rules followed by EIF:
- A set of logical data that is identified from the user's perspective.
- This set of data is external to the application and is referenced by the application.
- The compute function Point of this application does not maintain the EIF
- This set of data is maintained as a ILF in another application.
ILF and EIF complexity calculations
The complexity of ILF and EIF depends on the number of RET (Record element type) and det (Data element type). Det is a user-aware, non-repeatable field with a business logic meaning.
Det calculates the following rules:
- Each of these fields is counted as a det, through the execution of a basic process, by maintaining the ILF or returning a specific, user-identifiable, non-repeating field from the Ilf/eif.
- For example: Add a foreign trade order need to save "order number, order date, address, zip code", then for ILF orders it's Det is 4.
- For example, when you save an order, the details of the order are saved, and the order details are often saved as a sub-table, then the "order number" is present in both the main table and the child table (the primary foreign key), but when the user's angle is used to identify the disk, the order number can only be counted as a Det.
- When two applications maintain and/or reference the same ilf/eif, but each application maintains/references their corresponding Det respectively, these det are calculated separately in the maintenance or reference of both applications.
- For example, an application of two "elementary process" basic processing needs to use the "address" information, the address of the information can be subdivided into "country, city, street, zip code." So for one of the basic processes, he handles the entire address information as a whole, only one det, and the other basic process uses the details of each address, then DET is 4.
The rules for RET calculations are as follows:
RET refers to a collection of Det that a user can recognize in a EIF/ILF. If Det is simply understood as a field, the RET can be simply understood as a table in the database. RET is divided into two types in Ilf/eif: Optional (Optional) and required (Mandatory). The rules for calculating RET are the following two points:
- Each of the optional or required collections in a ilf/eif is computed as a ret.
- If a ilf/eif has no subcollections, Ilf/eif is computed as a ret.
For example, "order information, customer ID, Department ID" will be saved when an order is added to the foreign trade Order system. Then the order system ILF RET is:
1. Order Information (required)
2. Customer information (required)
3. Department Information (optional)
So the number of RET in ILF is 3.
The matrix of Ilf/eif complexity is as follows
|
1~19 a Det |
20~50 a Det |
Over 51 det |
1 ret |
Low |
Low |
Medium |
2~5 a RET |
Low |
Medium |
High |
More than 6 ret |
Medium |
High |
High |
CMMI function Point Estimation method---internal logic files and external interface files