BS ISO IEC 20926 pdf – Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009

BS ISO IEC 20926 pdf – Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009
1 Scope
1.1 Purpose
This International Standard specifies the set of definitions, rules and steps for applying the IFPUG functionalsize measurement (FSM) method.
1.2Conformity
This International Standard is conformant with all mandatory provisions of ISO/IEC 14143-1:2007.1.3Applicability
This lnternational Standard can be applied to all functional domains.
NOTE IFPUG continues to publish white papers providing guidelines for use in evolving environments and domains.This International Standard is fully convertible to prior editions of lFPUG sizing methods.
IFPUG function point analysts have identified different delivery rates (hours to deliver a function point) relatedto building applications in different functional domains calibrated for varying project sizes and softwarecomplexities.
1.4Audience
This International Standard can be applied by anyone requiring a measurement of functional size. Personsexperienced with the method will find this International Standard to be a useful reference.
2Normative references
The following referenced documents are indispensable for the application of this document. For datedreferences，only the edition cited applies. For undated references，the latest edition of the referenceddocument (including any amendments) applies.
ISOIEC 14143-1:2007, Information technology— Software measurement— Functional size measurement —Part 1 : Definition of concepts
3Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
adaptive maintenance
modification of a software product, performed after delivery, to keep a software product usable in a changedor changing environment
NOTE Adaptive maintenance provides enhancements necessary to accommodate changes in the environment inwhich a software product must operate. These changes are those that must be made to keep pace with the changingenvironment. For example, the operating system might be upgraded and some changes may be made to accommodatethe new operating system.
[ISO/IEC14764:2006,3.1]3.2
application
cohesive collection of automated procedures and data supporting a business objective, consisting of one ormore components, modules, or subsystems
EXAMPLES Accounts payable, accounts receivable,payroll, procurement, shop production, assembly line control,airsearch radar, target tracking, weapons firing, flight line scheduling and passenger reservations.
3.3
application functional size
measure of the functionality that an application provides to the user, determined by the application functionpoint count
3.4
application function point count
activity of applying this International Standard to measure the functional size of an application
3.5
arranging
activity of sequencing attributes in a transactional function
3.6
associative entity type
entity type that contains attributes which further describe a many-to-many relationship between two otherentity types
3.7
attributive entity type
entity type that further describes one or more attributes of another entity type
3.8
base functional componentBFC
elementary unit of Functional User Requirements defined by and used by an FSM Method for measurementpurposes
EXAMPLE A Functional User Requirement could be“Maintain Customers”, which might consist of the followingBFCs: “Add a new customer,”Report Customer Purchases”, and “Change Customer Detais . Another example mightinclude a collection of logically related business data maintained by the software under study such as “Customer Details”.There are many other examples.
3.9
boundary
conceptual interface between the software under study and its users[ISO/IEC14143-1:2007,3.3]
NOTEISO/IEC 20926:2003 used the term “application boundary”.
3.10
consistent state
point at which processing has been fully executed, the Functional User Requirement has been satisfied andthere is nothing more to be done
EXAMPLE 1 The Functional User Requirement is to print a check and mark the appropriate account as paid. If onlypart of the Functional User Requirement is completed (e.g.,only printing the check or only marking it as paid), theapplication is not in a consistent state. The printing of a check without marking the account as paid causes aninconsistency in the application as does marking it as paid without printing it.
EXAMPLE2 The Functional User Requirement is to have a batch process that accepts an input file to update a datastore, produce a production control report and return an error report back to the sending application. The process is not ina consistent state unless all of these parts are completed.
EXAMPLE 3 The Functional User Requirement is to transter an employee to a new job and validate his/her securityclearance level. To complete this, a real-time request is sent to the security application(which maintains governmentsecurity clearances and not application security) and a response received before the transfer can be completed.All stepsare needed to create a consistent state. The interaction with the security application is not an independent step or action.lt does not happen in and of itself, and the transaction to transfer an employee is not in a consistent state without it.