Function Points FAQsPositioning of Application Boundaries
Should batch functions, which do not have any DETs that come from outside the application boundary, be counted as elementary processes?
Definition: Boundary:
The application boundary indicates the border between the software being measured and the user.
The boundary is the conceptual interface between the software under study and its users. Where the users are, any person or any thing (including any software application), that communicates or interacts with the software'. The boundary:- Defines what is external to the applications
- Is the conceptual interface between the 'internal' software and the 'external' user world
- Acts as a 'membrane' through which data processed by transactions (EIs, EOs and EQs) passes into and out of the application
- Encloses the logical data maintained by the application (ILFs)
- Assists in identifying the logical data referenced by but not maintained within the application (EIFs)
- Is dependent on the user's external business view of the application. It is independent of technical or implementation considerations.
Defining the boundary is an essential step in functional measurement. It is important in Function Point counting because of its role in identifying the transactions, which pass through it, and therefore can be potentially included in the 'scope' of the count. The positioning of the boundary between the software under investigation and other software applications may be subjective and consequently functional sizing may be subjective.
The positioning of application boundaries directly impacts the size of an organisation'sapplication portfolio. Multiple application boundaries between system suites introduce multiple "interfacing" transactions and shared files. This creates a potential for the same logical business function to be counted multiple times.
Incorrect placement of the application boundary may change the emphasis of the count from a logical perspective, which is the underlying principle of FPA, to a more physical perspective. The main consequences of this are:
- Duplicate counting of the same logical business transaction by multiple 'applications' as each application contributes its sub-processing component to the elementary business process.
- Counting of technical functions that transfer data between platforms/'applications'. For example, the daily download of reference table data from a server to a client application would potentially be counted as an EQ (unload from server) and EI (load to client), plus two logical files (server and client versions of the reference table). From a logical perspective there is simply a requirement for transactions to be validated against the reference table.
- Difficulty in determining transaction type. Where an 'application' provides only part of the processing for a logical business function, the processing provided may not satisfy the IFPUG criteria for determining transaction type.
- Duplicate counting of files. For example the same file may be counted as an ILF to one 'application' and an EIF to the associated 'application. In many cases there is only one physical file but the positioning of the boundary causes it to be counted to more than one 'application'.
For FPA purposes most organisation'sApplication Boundaries are determined by:
- The organisation'sapplication identification and naming standards, i.e. if the organisationrecognise a grouping of software as a separate application, it is defined by FP Analyst as an application.
- The way in which an application is managed i.e. software developed, or maintained, as a whole by a discrete project team is considered to be an application.
- When an application receives its own, independent Work Requests it is considered to be an application.
The above guidelines apply regardless of whether the application functionality is distributed across multiple platforms and processors, or resides on a single platform/processor. Within the one 'application', boundaries are not drawn between platforms/processors.
The Function Point Administrator resolves application boundary issues, raised by FP Analysts. The Administrator is the final arbitrator in defining Application Boundaries for counts. It is recommended that function point FP Analysts provide an application boundary diagram as part of their count documentation.