ISO IEC 20968 pdf download

ISO IEC 20968 pdf download.Software engineering — Mk II Function Point Analysis — Counting Practices Manual
1.1 Mk II FPA is used to measure the size of the functionality required by the users of an application, within a boundary defined for the purpose of the FP count. 1.2 The application or part of the application enclosed by the boundary must be a coherent body of functionality, comprising one or more complete Logical Transaction Types. (In the following, ‘Type’ is dropped for ease of reading.)
2.1 The Functional Size of an application is the sum of the sizes of each of the Logical Transactions whose input and output components cross the enclosing boundary.2.2 A Logical Transaction is the lowest level of self-consistent process. It consists of three components; input across an application boundary, processing involving stored data within the boundary, and output back across the boundary. 2.3 It is triggered by a unique event that is of interest to the user, which, when completed, leaves the application in a self-consistent state in relation to the unique event. It may also be triggered by a user requirement to extract information from the application, leaving it unchanged. 2.4 A Logical Transaction is counted once when sizing an application, even though it may be executed from more than one point in the application. 2.5 Changes to are counted by summing the size of the added, changed, and deleted Logical Transactions. 2.6 In the case of changed Logical Transactions, the size counted is the size of the changes made to the Logical Transactions, not the overall size of the Logical Transactions. The size of the changes made is found by summing the counts of the added, changed and deleted input, process and output components of the Logical Transactions.
3.1 The processing component of a Logical Transaction is analysed by reference to its manipulation (i.e. create, update, delete, or read) of stored data. 3.2 The processing component is sized by counting the number of Primary Entity Types that are referenced by the Logical Transaction, plus the System Entity if referenced. See Section 4.4 for definitions of ‘Entity- Type’ and ‘Primary’. 3.3 All accesses to Non-Primary Entity Types within the entity model are considered to be references to a single entity called the System Entity. 3.4 Within an application boundary there can be only one System Entity, to which a maximum of one reference may be included in the processing component of a Logical Transaction.
4.1 The input and output components of a Logical Transaction are sized by counting the number of Data Element Types crossing the application boundary, via each component respectively. 4.2 A Data Element Type is a uniquely processed item of information that is indivisible for the purposes of the Logical Transaction being sized. It is part of an input or output data flow across an application boundary.
5.1 The Functional Size of a Logical Transaction is the weighted sum of the input, processing, and output components of the Logical Transaction. 5.2 The industry standard weights are as follows: Input Weight is 0.58 (per Input Data Element Type), Processing Weight is 1.66 (per Entity Type Reference), and the Output Weight is 0.26 (per Output Data Element Type).
The purpose of this section is to summarise the key factors in each of the steps 1 to 6 which comprise the Mk II FPA Counting Process, the additional steps 7 to 8 which are needed to determine the most commonly required performance parameters, and the optional steps 9 to 11 which are needed to take into account the Technical Complexity Factor. Reference is made to the Rules of Chapter 2, and to other parts of this manual which provide greater detail and guidance. The Functional Size of an application is derived from the Functional User Requirements as expressed by the commissioning user. Any function that is provided, but which was not required by the user, is ignored for FPA purposes (Rule 1). Functional requirements are usually modelled in the Requirements Specification and Logical System Design documents. They are an expression of what an application should do or does, rather than how it does it, and these are therefore good source documents for counting purposes. Access to a member of the project team knowledgeable in what the system is supposed to do, and to a data analyst for the data entity model, is also an invaluable asset to a count.