Function Point Analysis, Transactional Function

IFPUG’s definition of transactional function, Transactional functions provide the means for a user to transact with the application. These functions facilitate the processing of data contained in the system, and convert and present it in a form desired by the user. Following rules can be used to identify transaction

•          The transaction is visible or accessible to the user
•          All transactions are identified to be outside the boundary but within the scope of the application being counted
•          The various data elements that constitute the transaction necessarily move from outside to inside the application boundary and vice versa.
•          The transaction could be invoked through various means of input (batch or online) or through a variety of hardware devices, sensors and more.

IFPUG defines EI, EO and EQ as follows:

External Input (EI)

An external input (EI) is an elementary process that processes data or control information that comes from outside the application’s boundary. The primary intent of an EI is to maintain one or more ILFs and / or alter the behavior of the system

External Output (EO)

An external output (EO) is an elementary process that sends data or control information outside the application’s boundary. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, or create derived data. An external output may also maintain one or more ILF and / or alter behavior of the system.

External inquiry (EQ)

An external inquiry is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, not is the behavior of the system altered.

Determining Complexity of EI, EO and EQ

Two components of any transaction decide its complexity; that us, Data Elements (DET) and File Type Referenced (FTR)

DET: A data element type is a unique user- recognizable, non repeated field. In simple terms, it is a filed in a file or a column in a database table, but the mapping of a field or column in the file should be with respect to the data element recognized from the user’s point of view.

FTR, a file type referenced (FTR) is a file, internal or external, that has been accesses by the transaction.

EI Complexity Factor

Range	1 to 4 DET	5  to 15 DET	16 or More DET
0 to 1  FTR	Low	Low	Average
2 FTRs	Low	Average	High
3 or more FTRs	Average	High	High

EO / EQ Complexity Factor

Range	1 to 5 DET	6  to 19 DET	19 or More DET
0 to 1  FTR	Low	Low	Average
2 to 3 FTRs	Low	Average	High
4 or more FTRs	Average	High	High

EI/EQ FP Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	3
Average	4
High	6

EO Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	4
Average	5
High	7

CRUD Transactions

If we evaluate the elementary process involved in CRUD transactions, we find that except in the case of a Read transactions, all others are unique, As such, while counting EI for a data maintenance transaction, we count them three EI, One each for Create, Update and Delete. The complexity of these three EIs might vary depending on the number of data element involved in each of the transactions.

Function Point Analysis, Data Functions

Data function is one of the two most critical components of the entire FPA process. The functionality requirements of the application are met through data functions and are facilitated by means of internal and external files. The focus here is on logical storage of data in the forms of files and not the physical implementation.

IFPUG’s Counting Practice Manual broadly classifies the data function types into two categories: Internal Logical Files (ILF) and External Interface Files (EIFs). The boundary of the application being counted decides what is internal and what is external to the system. All files owned and maintained be the application being counted are ILFs and all files referenced by the application but outside the boundary of the scope of count, are EIFs. In other words, if the CRUD (Create, Read, Update and Delete) factors apply to a file in the system, it is likely to be an ILF, and if it is read only, the file is an EIF.

The CPM 4.2 defines ILF and EIF as follows:

ILF: An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application. The Primary intent of an ILF is to hold data maintained through one or more elementary process of the application being counted.

EIF: An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary process within the boundary of the application counted. This means an EIF counted for an application must be an ILF in another application.

The basic difference between an ILF and EIF is that although the ILF is owned and maintained by the application being counted, the EIF is used and referenced by the application being considered for FP counting purpose. The EIF referenced by the application being counted must be an ILF to another application.

Determining Complexity of ILFs and EIFs

IFPUG has defined a clear process of identifying an ILF or EIF as Low, Average or High and also has a fixed number of unadjusted function points assigned to each of these categories. Only two major components of any data file decided its complexity: data elements (DET) and record elements (RET).

DET

A data element type (DET) is a unique, user-recognizable, non-repeated field. In simple terms, it is a filed within a record of a file or a column in a database table (file), but the mapping of a filed or column in the file should be with respect to the data element recognized from the user point of view.

RET

A record element type (RET) is a user-recognizable subgroup of data elements within an ILF or EIF. There are two types of subgroups, Optional and Mandatory.

ILF/EIF Complexity Factor

Range	1 to 19 DET	20 to 50 DET	51 or More DET
1 RET	Low	Low	Average
2 to 5 RET	Low	Average	High
6 or more RET	Average	High	High

ILF FP Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	7
Average	10
High	15

EIF FP Contribution

Functional Complexity Rating	Unadjusted Function Points
Low	5
Average	7
High	10

Points to Remember

·       -   An ILF or EIF may appear repeatedly in multiple sections of the same application during the counting process. Ensure that once a specific, identified ILF or EIF is defined and recorder, any subsequent appearances of the same ILF or EIF should be ignored.

·         -  The basic definition of an ILF and EIF maps them to a logical implementation of a file. Do not confuse this with the physical implementation of an existing data model in an RDBMS system. You should identify an ILF or EIF based on user view and ensure it is a logical implementable only.

Overview of Software Estimation

Wikipedia defines “Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.”

Estimation Methods:

An estimation method is a set of process, supported by appropriate empirical formulae and backed with historical reference data,  that help derive predictable results within a decent level of accuracy. Some of the key characteristics of good estimation method are

•     Should be easy to understood and deploy

•     Allow modularization of the software application components

•     Provide predictable results with accuracy within reasonable limits

•     Be comparable across a variety of software projects

•     Provide conversion of the outputs to other project execution parameters such as schedule, cost, progress etc.

Function Point

A function point is a unit of measure for arriving at software application size. It measures the functionality. Functionality is the process by which information about an entity is fetched, stored or exported

FPA Model

The FPA model facilitates the measurement of software application size. The output of this method is function points. A function point is defined as a unit of business functionality delivered through the software.

The FPA model is based on the premise that any software application can be sized based on five key parameters: Input, output, inquiries, internal files and external interfaces.

1. Inputs: For any software application to exists, it is essential that programmers provide the means through which business information can be stored in the files.  Moving data from an external source into the application files and updating and maintaining the data are all included under the input attributes. All the CRUD (Create, Read, Update and Delete) operations are classified under the input attribute.

2. Outputs: Business information processed through the software application could be output in various forms. The outputs could be printed, stored on other media or even displayed on the monitor itself

3. Inquiries: The output of inquiry is quite similar to that of outputs discussed previously but the output generated here are in their original form. Business information is not processed; rather it is just or rearranged based on user request.

4. Internal Files: All the data that are owned and maintained within the application are stored in files known as internal files. These files belong to the application and any modification to the data contents is the responsibility of the application owner.

5. Interfaces: a software application that enables users to make business transitions with the software normally interact with other applications, either within or external to the organization. Interfacing with other application is a key attribute that contributes to the size of the application being measured.

The General system characteristics (GSC) are another set of 14 attributes that define the overall complexity of the software application being sized. These 14 GSC help the estimator define certain performance and operational aspects of the application. 

The ISO 9126 Software Quality Standards

Function	Sub Category	DEFINITION
Functionality	Suitability	Attributes of software that bear on the presence and appropriateness of a set of functions for specified tasks
	Accurateness	Attributes of software that bear on the provision of right or agreed upon results or effects
	Interoperability	Attributes of software that bear on its ability to interact with other systems
	Compliance	Attributes of software that make the software adhere to application-related standards or conventions or regulations in laws and similar prescriptions
	Security	Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs or data
Reliability	Maturity	Attributes of software that bear on the frequency of failure by faults in the software
	Fault tolerance	Attributes of software that bear on its ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface
	Recoverability	Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it
Usability	Understandability	Attributes of software that bear on the users’ effort for recognizing the logical concept and its applicability
	Learnability	Attributes of software that bear on the users’ effort for learning its application
	Operability	Attributes of software that bear on the users’ effort for operation and operation control
Efficiency	Time behavior	Attributes of software that bear on response and processing times and on throughput rates in performing its function
	Resource behavior	Attributes of software that bear on the amount of resources used and the duration of such use in performing its function
Maintainability	Analyzability	Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures or for identification of parts to be modified
	Changeability	Attributes of software that bear on the effort needed for modification, fault removal, or environmental change
	Stability	Attributes of software that bear on the risk of unexpected effect of modifications
	Testability	Attributes of software that bear on the effort needed for validating the modified software
Portability	Adaptability	Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions or means than those provided for this purpose for the software considered
	Installability	Attributes of software that bear on the effort needed to install the software in a specified environment
	Conformance	Attributes of software that make the software adhere to standards or conventions relating to portability
	Replaceability	Attributes of software that bear on opportunity and effort using it in the place of specified other software in the environment of that software