NOTES FROM LONGSTREET’S TRAINING BOOKLET
http://www.softwaremetrics.com/freemanual.htm

INTRODUCTION
Developed first by Allan J. Albrecht in the mid 1970s

• FPA is a method to break systems into smaller components, so they can be better understood and analyzed
• Function points are a unit measure for software
• much like an hour is to measuring time, miles are to measuring distance or Celsius is to measuring temperature
• One of the largest misconceptions of function points is understanding what functionality is being exposed to an end user versus the delivered functionality.
• When we size software applications we want to understand what is exposed and what is under the surface.
• There are two basic types of elementary processes in a software application.
• Data in motion and data at rest
• Data in motion has the characteristic of moving data inside to outside the application boundary or outside to inside the application boundary.
• Data in motion
• External Inputs
• External Outputs
• External Inquiries
• Data at rest
• Internal Logical Files
• External Interface Files

Function points are not a very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work. The productivity of individual maintenance programmers can vary as much as 1,000 percent.

Performance tuning may or may not have anything to do with functionality. Performance tuning is more a result of trying to understand application throughput and processing time. There are better metrics to utilize when measuring this type of work.

• Three types of Function Point Counts
• Development Project Function Point Count (a.k.a Baseline Function Point Count)
• Enhancement Project Function Point Count
• Application Function Point Count

• Productivity of the Language
• Hours per Function Point
• Productivity of the Programmer

Frederick W. Taylor believed that application of scientific methods, instead of custom and rules of thumb could yield higher productivity. A century after Frederick Taylor most software managers use rules of thumb instead of systematic study.

• Productivity = outputs/inputs (within a time period, quality considered)
• Software Productivity = Function Points / Inputs
• Software productivity is defined as hours/function points or function points/hours
• Industry data shows is the unit cost of software goes up with size
• Unit Costs
• The unit cost for external inputs may not be the same as the unit cost of external outputs
• The online external inputs and the batch external inputs do not have the same unit cost
• The cost per unit to build and implement internal logical files is not the same per unit cost as the building and implementing of online reports

FUNCTION POINT COUNTING PROCESS
The overall objective is to determine adjusted function point count

1. Determine type of function point count
2. Determine the application boundary
3. Identify and rate transactional function types to determine their contribution to the unadjusted function point count.
4. Identify and rate data function types to determine their contribution to the unadjusted function point count.
5. Determine the value adjustment factor (VAF)
6. Calculate the adjusted function point count.

• FPA can be broken into three major parts
• FPA for transactinal function types
• FPA for data function types
• FPA for GSCs

• Since the rating of transactions is dependent on both information contained in the transactions and the number of files referenced, it is recommended that transactions are counted first.
• Every FTR must have at least one or more transactions
• Each transaction must be an elementary process.
• An elementary process is the smallest unit of activity that is meaningful to the end user in the business. It must be self-contained and leave the business in consistent state.

ESTABLISHING THE BOUNDARY

• The boundary indicates the border between the project or application being measured and the external applications or user domain
• A Boundary must be drawn according to the sophisticated user’s point of view
• There is a tendency to create a “new” application for the Internet/Intranet extension, but this approach is incorrect.
• The boundaries for client/server applications need to be drawn around client and server together.

IDENTIFYING RET’S, DET’S, FTR’S

• Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF
• File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an internal logical file or external interface file.
• Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field. A DET is information that is dynamic and not static. A dynamic field is read from a file or created from DET’s contained in a FTR. Additionally, a DET can invoke transactions or can be additional information regarding transactions. If a DET is recursive then only the first occurrence of the DET is considered not every occurrence.

• All of the components are rated based upon DET’s, and either RET’s or FTR’s.
• EI: FTR, DET
• EO: FTR, DET
• EQ: FTR, DET
• ILF: RET, DET
• EIF: RET, DET

• Transaction DET’s
• External Inputs: Data Input Fields, Error Messages, Calculated Values, Buttons
• External Outputs: Data Fields on a Report, Calculated Values, Error Messages, and Column Headings that are read from an ILF. Like an EQ and EO can have an input side and output sides.
• External Inquiries: Input Side - field used to search by, the click of the mouse. Output side displayed fields on a screen.

For example, a simple application to track distributors could have fields for Distributor Name, Address, City, State, Zip, Phone Number, and Fax Number. This would represent seven fields or (seven data elements) and the add command button would represent the eighth data element. In short, the “add” external input represent a one external input with eight data elements, the “change” external input represents another external input with eight (seven data elements plus the “change” command button), and the “delete” external input represents the last external input with eight data elements (seven fields plus the “delete” command button).

• DET’s for GUI
• Radio Buttons are treated as data element types
• one data element type is counted for all the radio buttons contained in the frame
• Each check box, within a frame, that can be selected should be treated as a data element
• According to IFPUG counting rules each command button would be counted as a data element for the action it invokes
• A display of a graphical image is simply another data element
• Many GUI applications have a sound byte attached. This represents one data element.
• A photographic image is another data element, and is counted as one. (e.g. HR Application with employee photo)
• Messages
• error messages and confirmation messages
• are not an elementary or independent process alone, but they are part of another elementary process
• notification messages
• are treated as External Outputs

• DET’s For Real Time Systems
• time of diagnostics, hardware state during diagnostics, temperature, voltage, so on and so forth would all be examples of data elements.
• Real Time Systems may not have any “traditional user interface.” That is, the stimulus for the Real Time System may be it’s own output – or state.

• Record Element Types (RET’s)
• one of the most difficult concepts in function point analysis
• Most record element types are dependent on a parent - child relationship

• Navigation
• is moving from one transaction to another

EXTERNAL INPUTS

• is an elementary process in which data crosses the boundary from outside to inside
• data may come from a data input screen or another application
• data may be used to maintain one or more internal logical files
• data can be either control information or business information

• If an external input adds, changes and deletes (maintains) information on an internal logical file, then this represents three external inputs
• External inputs (especially change & delete) may be preceded by an external inquiry (see the section on external inquiries)

• An FTR can be either an Internal Logical File and/or External Interface File
• Any internal logical file or external interface file that is referenced by an external input as part of the elementary process of maintaining an internal logical file would be considered an FTR also
• For example, an External Input may update an internal logical file, but must also reference a “security file” to make sure that the user has appropriate security levels. This would be an example of two FTR’s.

• A unique set of data elements, and/or a different set of FTR’s, and/or a unique set of calculations make one external input unique or different from other external inputs.
• That is, one of the following must be true:
• Unique or different set of data elements
• Unique or different set of FTR’s
• Unique or different calculations
• Modification of any of the items, which make an External Input unique from other external inputs, causes the EI to be “enhanced.”
• DET’s added to an EI
• DET’s modified on an EI. The DET was included in the last FP Count.
• A New FTR
• Modifications to a calculation that appears on an EI

• Some sources of information to determine external inputs are
• Screen Layouts
• Screen Dialogs
• Design Documentation
• Functional Specifications
• User Requirements
• Any Input Forms
• Context Diagrams
• Data Flow Diagrams

EXTERNAL OUTPUTS

• an elementary process in which derived data passes across the boundary from inside to outside
• Derived Data is data that is processed beyond direct retrieval and editing of information from internal logical files or external interface files
• Derived data occurs when one or more data elements are combined with a formula to generate or derive an additional data element(s)
• This derived data does not appear in any FTR
• The rating is based upon the total number of unique (combined unique input and out sides) data elements (DET’s) and the file types referenced (FTR’s)

• A unique set of data elements, and/or a different set of FTR’s, and/or a unique set of calculations makes one external output unique or different from other external outputs.
• That is, one of the following must be true:
• Unique or different set of data elements
• Unique or different set of FTR’s
• Unique or different calculations
• Unique processing logic
• Modification of any of the items, which make an External Output unique from other external outputs, causes the EO to be “enhanced.”
• DET’s added to an EO
• DET’s modified on an EO. The DET was included in the last FP Count.
• A New FTR
• Modifications to a calculation that appears on an EO.

• Some sources of information to determine external outputs are
• Report Layouts
• Design Documentation
• Functional Specifications
• User Requirements
• Database descriptions
• Field Sizes and Formats
• Graphical Report Layouts

• External Output have an input side if the input side is not stand-alone and required by external output process
• The FTR’s and DET’s used to search should be included in the count
• An external output can update an internal logical file, but it is incorrect to say that an external output can maintain an internal logical file.

EXTERNAL INQUIRIES

• an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files
• the input process does not update or maintain any FTR’s and the output side does not contain derived data

• A unique set of data elements, and/or a different set of FTR’s make one external inquiry unique or different from other external inquiry.
• That is, one of the following must be true:
• Unique or different set of data elements
• Unique or different set of FTR’s
• Unique processing logic
• Modification of any of the items, which make an External Inquiry unique from other external inquiries, causes the EQ to be “enhanced.”
• DET’s added to an EQ
• DET’s modified on an EQ. The DET was included in the last FP Count.
• A New FTR

• Some sources of information to determine external inquiries are
• Screen Layouts
• Design Documentation
• Functional Specifications
• Table Layouts
• User Requirements
• Database descriptions
• Pick lists
• Field sizes and formats

• all external inquiries have an input side
• an external inquiry may update an internal logical file, but it is incorrect to say that an external inquiry can maintains an internal logical file

INTERNAL LOGICAL FILES

• a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs
• an ILF can consist of multiple physical files with different record types

• Some sources of information to determine internal logical files are
• Table Layouts
• Database descriptions
• Logical data models
• Field sizes and formats
• Design Documentation
• Functional Specifications
• User Requirements

EXTERNAL INTERFACE FILES

• a user identifiable group of logically related data that is used for reference purposes only.
• data resides entirely outside the application boundary.
• pull theory
• external application “reaching into” another applications and retrieving data
• push theory
• applications to create interfaces (EO or EQ) which other applications read

• Some sources of information to determine internal logical files are
• Table Layouts
• Interface Diagrams
• Database descriptions
• Logical data models
• Field sizes and formats
• Design Documentation
• Functional Specifications
• User Requirements

GENERAL SYSTEM CHARACTERISTICS

• to rate the general functionality of the application being counted
• 14 general system characteristics
• each characteristic has associated descriptions to determine the degrees of influence.
• the degrees of influence range on a scale of zero to five, from no influence to strong influence.
• 0 Not present, or no influence
• 1 Incidental influence
• 2 Moderate influence
• 3 Average influence
• 4 Significant influence
• 5 Strong influence throughout

• General System Characteristics
1. Data communications
• How many communication facilities are there to aid in the transfer or exchange of information with the application or system?
2. Distributed data processing
• How are distributed data and processing functions handled?
3. Performance
• Did the user require response time or throughput?
4. Heavily used configuration
• How heavily used is the current hardware platform where the application will be executed?
5. Transaction rate
• How frequently are transactions executed daily, weekly, monthly, etc.?
6. On-Line data entry
• What percentage of the information is entered On-Line?
7. End-user efficiency
• Was the application designed for end-user efficiency?
8. On-Line update
• How many ILF’s are updated by On-Line transaction?
9. Complex processing
• Does the application have extensive logical or mathematical processing?
10. Reusability
• Was the application developed to meet one or many user’s needs?
11. Installation ease
• How difficult is conversion and installation?
12. Operational ease
• How effective and/or automated are start-up, back up, and recovery procedures?
13. Multiple sites
• Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?
14. Facilitate change
• Was the application specifically designed, developed, and supported to facilitate change?

• the Value Adjustment Factor (VAF) is based on general system characteristics
• VAF = 0.65 + SUM(GSC[1:14])/100

Function Point Count

• Function Point Count (FPC) is the product of Unadjusted Function Point Count (UFC) and Value Adjustment Factor (VAF)
• FPC = UFC * VAF