Function Points FAQs
Robots, File Transfer Systems - Counting Guidelines
Where the application boundary is drawn around the Robot/ File Transfer System, and the Robot is not considered part of the underlying technical infrastructure of another application, how should the robot functionality be counted?
While each robot performs a specific set of functions, a number of generic function types have been identified.These include:
Issues to be addressed include:
GENERAL DISCUSSION AND RESOLUTION
The functionality offered by robots can be counted using IFPUG 4.1 guidelines.The FP Analyst applies the IFPUG definitions to the transactions that enter and leave the application boundary and to the data stored within the application boundary.
However, not every data flow that crosses the boundary of the robot is necessarily a unique elementary process.As stated above, one function may involve multiple data movements between Source system, robot and receiving system, as the data required to complete the transaction is created by iteration.The condition that the transaction "achieve a business goal and leave the business of the system in a consistent state" is relevant and should be applied.
The sole objective of a Robot application is to function as a "virtual" system user and to mimic the way a user would interface between systems.Actions that occur within one application may require a business ‘reaction’ in another application.However this action/reaction sequence is more complicated than a simple transfer of data.Depending upon conditions existing in either the source, or receiving system, a user would be required to make decisions on the appropriate system to access (data from/data to), the data content of the transfer, expected sequence of system responses and how to respond to error conditions.All this user decision-making functionality must be built into the Robot.
Note: The following list of functions are intended to be a generic guide for counting this type of application, there may be instances where particular applications may offer more or less functionality.
Files: Internal Logical Files
Where they exist, the following may be counted asILFs for the Robot System:
Specifies the attributes of the Robot and associated systems and automates the log on/log off functions.
The possibilities are many and varied.They may include:
Record data transfer traffic as it passes through the Robot.
The Robot may be required to keep a copy of all data transfers and update the status of these records.
Normal system security that defines Users and User Profiles. (See Section 3.2.5, Security.)
Files: External Interface Files
Where they exist, the following may be counted asEIFs for the Robot System:
(Those that have not been counted as ILFs.)
These are the screens on the Source applications that the Robot collects data transfer information from.
These are only counted where the data transfer function involves multiple data movements, i.e. where the provision of the data by the Robot is an iterative process.Based on responses from the receiving screen/s the robot provides the necessary data to complete the data transfer.
Where the function of the Robot is to facilitate an enquiry upon a host system, the file enquired upon is counted as an EIF.If a logical file cannot be identified, count the host system screen as the EIF.
Transactions: External Inputs
Any user identifiable transactions required to create or maintain Internal Logical Files may be counted asEIs for the Robot system.
Transactions: External Outputs
Where they exist, the following may be counted asEOs for the Robot system:
The output transactions of a robot are counted as External Outputs rather than External Inquiries.While there may not be any calculated data within the data transfer, the generation of the data and/or data transformations usually involve complex logical processing and are therefore defined as derived data.
The file transfer transactions are logically one EO transaction. They typically collect the required data, pass it through the File Transfer application, perhaps recording the transfer event, perhaps reformatting the data, and pass it on to the destination system.
The main distinction, which needs to be made for a File Transfer System, is to determine whether the system has knowledge of the data that it is transferring. (Robots do). Where the system transfers complete files, with no regard to the file format or contents, regardless of how many files are transferred, between how many systems, there is only one generic transaction. Where different logical processing can be demonstrated, because the FT system is ‘aware’ of the data being transferred, then multiple transactions can be counted.
Transactions: External Enquiries
Any user identifiable transactions required to view/display data on ILFs or (non-screen) EIFs may be counted asEQs for the Robot System. Count as per IFPUG guidelines.