function point analysis
DESCRIPTION
Function Point Analysis. Function Points Analysis (FPA). What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent the functional size of a software application. - PowerPoint PPT PresentationTRANSCRIPT
Function Point Analysis
Function Points Analysis (FPA)What is Function Point Analysis (FPA)?Function points are a standard unit of measure that
represent the functional size of a software application. It is designed to estimate and measure the time, and
thereby the cost, of developing new software applications and maintaining existing software applications.
It is also useful in comparing and highlighting opportunities for productivity improvements in software development.
It was developed by A.J. Albrecht of the IBM Corporation in the early 1980s.
Objectives of Function Point Analysis
Measure software by quantifying the functionality requested by and provided to the customer.
Measure software development and maintenance independently of technology used for implementation.
Measure software development and maintenance consistently across all projects and organizations.
Important FPA notes
Measured from the user's perspectiveTechnology-independentLow costRepeatableWork well with use cases
FPA
How is Function Point Analysis done?Working from the project design specifications,
the following system functions are measured (counted):
External Inputs (EI) External Outputs (EO) Files (ILF-internal logical files) External Inquires (EQ) Interfaces (ELF – external logical files)
FPA
External Interface Files
Internal Logical Files
Inquiries
Input Output
Boundary
FPA
EI: An elementary process in which data crosses the boundary from outside to inside.Data input screenAnother applicationBusiness data: does update ILFControl data: does not update ILF
EO: An elementary process in which derived data passes across the boundary from inside to outside.Creates reportsCreates output files sent to other applicationsCreated from ILF and ELF
FPA
EQ:An elementary process with both input and output components that result in data retrieval from one or more ILF and ELF Sent outside the application boundary Input process does not update ILF Output side does not contain derived data
ILF: A User identifiable group of logically related data that entirely within the applications boundary and is maintained through External Inputs
EIF: A User identifiable group of logically related data that is used for reference purposes only. Resides entirely outside application Maintained by another application It is an ILF for another application
Unadjusted FP Calculation Functional Count by (Complexity)
Complexity rated by three categories:
• Simple
• Average
• Complex Each of the 5 functional components has its own unique complexity matrix
weighting based on level of complexity
Degrees of Influence (DI)
Data communications Distributed functions Perfomance objectives Heavily used configuration Transaction rate On-line data entry End-user efficiency On-line update Complex processing Reusability Installation ease Operational ease Multiple sites Facilitate change
General characteristics to be ranked by degree of influence from 0-5Degree of Influence Measures
Not Present, or no influence present=0Insignificant Influence=1Moderate Influence=2Average Influence=3Significant Influence=4Strong influence, throughout=5
FP Calculation
Complexity Adjustment Factor (CAF)CAF = 0.65 + 0.01 x DI
each degree of influence is worth 1 percent of a Total count factor which can range from 0.65 to 1.35
Adjusted Function Points (AFP)AFP = CAF x UFP
Complexity of Files& Transactions
Data Element Type (DET)
A unique user recognizable field from a business perspective which participates in a transaction or is stored on a logical data file.
Record Element Type (RET) A user recognizable subgroup of data elements within an
ILF or EIF. (orders types) The complexity of an transaction is determined by counting the
number of logical File Types Referenced (FTRs) and the number of DET.
Productivity Index
Function points method can be used for measuring the productivity of development activities
Critics to FPA
The calculation of function counts tends to take a black box view of the system.
The user defined function types currently established may not be wholly appropriate for current technology.
Function point counts are affected by project size
Difficult to apply to massively distributed systems or to systems with very complex internal processing
Difficult to define logical files from physical files
Critics to FPA
The classification of the user function types into simple, average, and complex appears to be oversimplified
The choice of weights was determined by debate and trial.
The restriction to 14 processing complexity factors is not going to be satisfactory for all time
Benefits of FPA
Organizations that adopt Function Point Analysis as a software metric realize many benefits including: improved project estimatingunderstanding project and maintenance productivitymanaging changing project requirements; and gathering
user requirements
3D Function Points
Each class is an internal fileMessages sent across the system
boundary as transactions Require a greater degree of detail in order
to determine size and consequently make early counting more difficult.
Object-Oriented Function Points(OOFP)
Characterized by a mapping of FP concepts (logical files and transactions) to OO concepts (classes and methods), and by a flexible method for handling specific OO concepts like inheritance and aggregation.
OOFP
Uses OMT ModelObject Model *
Static representation of classes and objectsFirst to be developed so can be measured early stages
Function ModelData Flow DiagramsIdentifiying and Design some methods in early stages
Dynamic ModelState machinessUse case and Scenarios
OOFP
Central Analogy to map FP to OOFP Logical files (collection of user identifiable
data) Classes(encapsulates collection of data items)
Transactions Methods Application Boundary
External classes encapsulates non-system components (external services and reused library classes); EIF
Classes with in the App. Boundary is ILF
OOFP
OOFP Calculation
OOFP Process
Analyze object model and identify units to be counted as LF.
Calculate the complexity of each LF and SR.Convert complexity values to numbersIf LF is “reused” its OOFP value is calculated
with a scale factor f<=1All OOFP values are summed up.
OOFP Process
OOFP
Identify LFClasses are mapped to LFAggregation and Inheritance is encountered
Mainly a concern of implementationAt analysis phase
Each class is a LFScale factor =1 (Origin of class does not matter)
At design phaseScale factor <1, reuse makes classes easier to developFor designer, each class is LFFor user perspective, it is complicated
OOFP
Ways to Identify LFSimple LF
Sigle Class is a LF
Composite LFAggregationGeneralization/SpecializationMixed (combine aggregation and generalization)
Single Aggregation
GeneralizationMix
OOFP
Calcution of DET and RETsOne RET for each ILF/ELFSimple LF
Simple attributes sucs as integer and strings counted as DET
Associations are counted as DET or RET accoring to cardinality
• Single valued association is DET• Multiple valued association is RET
OOFP
Composite LFDETs and RETs are counted as in simple LF,
except for aggregationAggregations act as subgroups in composite LFOne RET is counted for aggregations
For each OOFP , weighted vector table for ILF and ELF in IFPUG (international function point user
group)
OOFP
Service RequestsConcrete methods are only counted once,
abstract methods are not countedSimple Items: (analogy to DET)
• simple data items referenced as a argument• simple global variables referenced by the method
Complex Items: (analogy to FTR)• Complex arguments, objects and complex global
variables references by the method
For each OOFP(SR) , weighted vector table for EI,EQ in IFPUG
OOFP