This presentation contains the fundamentals of Function point Analysis. There are plenty of examples included in this presentation and one can learn the concepts using these examples.
2. Introduction
• Function Point Analysis (FPA) is a technique for
measuring/Estimating the functionality of a software app
(Size estimation)
•Developed by A.J. Albrecht of the IBM Corporation in the
early 1980s.
•Technology Agnostic
3. Introduction
• Was developed to overcome difficulties associated with
lines of code as a measure of software size
• In 1984 Albrecht refined the method and since 1986, when
the International Function Point User Group (IFPUG) was
set up, several versions of the Function Point Counting
Practices Manual have been coming out.
4. Reasons for using FPA
• To measure the productivity analysis and evaluate the % of increase and
decrease in productivity rate
• Helps end users/clients to quantify the number of requirements emended in
software
• Prepare the estimation for software development
• Prepare the cost related metrics for software development
• Could be used in Decision Analysis and Resolution Techniques (DART)
• Could be used to prepare the resource pyramid for software development
5. FPA Key Concepts
• Data at Rest = Tables/Storage
• Data in motion = Transactions
• Application Boundary = Within the application to be developed
• Elementary process = A series of steps, which moves data (interwoven EPs
form a system)
6. Key Concepts
Application Boundary
Entry Screens
Database
Business
Logic
External System
Reports/Outputs
• The application
boundary carries user
context
• The boundary is not a
technical concept
• The data residing inside
the boundary is data at
rest
• The data moving into or
out of boundary is data
in motionEach of these are categorized to estimate the size
7. Key Concepts
•Each of the functions points are identified and given a
weightage
•Weightage is given based on complexity of each type of
functional point
•Productivity factor is used to calculate the effort from the
functional point size
7
8. Key Concepts
•DETs (Data Element Type) & RETs (Record Element Type)
•FTR (File Type Referenced)
•EI, EO, EQ, ILF and EIF
8
9. FPA Process
Determine
Type of Count
Identify
Counting
Boundary
Count Data
Function
Types
Count
Transactional
Function Types
Determine
Unadjusted
Function Point
Count
Determine
Value
Adjustment
Factor
Calculate Final
Adjusted Function
Point Count
10. Data Element Type (DETs)
•A unique User Recognizable & Non-repeated field
•A control that invokes action
•Dynamic information & not static
•If DET is recursive, only one instance is considered. E.g.
GRID/TABLE
11. Data Element Type (DETs)
•Can be Quantitative
•Amount, percentages etc
•Can be qualitative
•Text boxes, pictures, Sound bytes
17. Internal Logical Files
• Logically related data
• Data stored & maintained internally (within application boundary)
• A group of DETs
• It could be
• Business Data
• Control Data
• Rule based data
18. Internal Logical Files
• ILF does not mean tables only
• ILF could be
• A Table
• A flat file
• A configuration file
• While counting ILFs, don’t think of it as a table
19. Internal Logical Files
• Business Data
• Author data
• Book
• Rule based data
• Marking criteria
• Assessment criteria
• Control Data
• Printer Port number
• Network resource number
• Asset identifier
20. Internal Logical File
Book
Book Name
Author ID
Year of publishing
Author
Author ID
Author name
Date of Birth
House Address
City
21. External Interface Files (EIF)
•Data at rest stored & maintained by external
applications(outside application boundary)
•Application, to be estimated, interacts with the EIF
•Set of Logically related data
•Used for reference purpose only
23. Record Element Type (RET)
•A logical grouping of data within ILF or EIF
•Can be a parent child relationship
24. DET & RET Example
Emp Code Name
Date of
Joining
Basic Sal Working
90001 Jag Mohan 01-Jan-2012 1,00,000 N
90002 Roshni Mehra 03-May-2012 25,000 Y
90003 Jagdev Mathur 09-Jun-2013 30,000 Y
90004 Seema Singh 10-Jul-2014 15,000 Y
90005 Ratan Verma 11-Jul-2014 26,000 Y
90006 Rupesh Ranjan 19-Aug-2014 39,000 Y
90007 Sonal Dhawan 20-Oct-2014 45,000 Y
DET
• Emp Code
• Name
• Date of Joining
• Basic Sal
• Working
How Many
RETs?
25. Class Exercise – DETs, RETs, ILFs & EIFs
Identify:
DETs
RETs
ILFs
EIFs
26. Class Exercise – DETs, RETs, ILFs & EIFs
Data Element Types (DETs):
• Customer Code
• Customer Name
• Credit Card Number
• Check Credit Card number from
payment gateway
• Active (Check Box)
• Customer Addresses
• City Name
• Street Name
• PIN Code
• Add Address
• Delete Customer
• Add Customer
• Update Customer
RET
30. Class Exercise – DETs, RETs, ILFs and EIFs
Food Ordering System – Class meets care
A food company wants to provide its customers home-cooked food, prepared
by reputed chefs. The Chefs will be creating cuisines, which can be eaten on a
regular basis but in a limited quantity to ensure quality and taste.
Each chef may opt not to prepare food on a daily basis, but must agree to the
schedule 7 days in advance. System will be preparing and publishing the menu,
based on chef’s availability and their offered cuisine.
The customer can choose a meal or snacks from the available ones. The
available quantity will also be limited as proposed by each chef. Customers
can’t order beyond the available quantity.
The system allows the COD option as well as online through net banking or
Credit/Debit card. For every payment received, the chef receives 80% of the
amount
31. Food Ordering System – Class meets careClass meets careClass meets careClass meets care
•Start by identifying key functions
•Keep decomposing till you can’t break it further
•Identify the attributes and fields for each function
•Identify DETs, RETs, ILFs and EIFs
32. Food Ordering System – Class meets careClass meets careClass meets careClass meets care
• A food company wants to provide its customers home-cooked food,
prepared by reputed chefs. The Chefs will be creating cuisines, which
can be eaten on a regular basis but in a limited quantity to ensure
quality and taste.
• Capturing chef details
• Chef offerings and quantity
• Offerings/Menu items and pricing
33. Food Ordering System – Class meets careClass meets careClass meets careClass meets care
Each chef may opt not to prepare food on a daily basis, but must
agree to the schedule 7 days in advance. System will be preparing
and publishing the menu, based on chef’s availability and their
offered cuisine.
• Chef rostering/Menu rostering for a week or more
• Alert in case 1 week forward menu is not rostered
34. Food Ordering System – Class meets careClass meets careClass meets careClass meets care
The customer can choose a meal or snacks from the available ones.
The available quantity will also be limited as proposed by each chef.
Customers can’t order beyond the available quantity.
• Menu Display
• Check on number of means ordered
35. Food Ordering System – Class meets careClass meets careClass meets careClass meets care
The system allows only COD option. The person ordering must verify
his/her phone number and also confirm or choose a delivery
address. For every payment received, the chef receives 80% of the
amount
• Cart
• Confirming order
• User Registration/Login
• Phone verification
• Chef payment details
36. Assignment- I Tasks
•In the project “Class meets care”, Do the following:
•Identify the smallest functions
•Identify EI, EO & EQs
•Identify DETs
•Identify ILFs & EIFs
38. External Input (EIs)
• It is an elementary process
• Data crosses boundary from outside to inside the application
boundary
• Data may be stored or updated in ILF
• Data may come from:
• Input screen
• External Application
40. External Input (EIs)
• Data element types for External Inputs
• Fields, Controls, Messages (both error and confirmation) – not
coming from database
• Calculated values that are stored
• Cancel/Close/Exit – not counted in EI, provided
• Data doesn't cross boundary – noting changed, edited or deleted.
State or behavior of application is not changed
• Calculated values not crossing the boundary, also not considered as
part of EI
• Not counted as DET - menus, link, navigational screens as these
are Usability, not functionality (However need to be careful, as
menu can be dynamic or might involve some programming)
41. External Input (Eis)
Application Boundary
Entry Screens
Database
Business
Logic
External System
Reports/Outputs
Each of these are categorized to estimate the size
46. External Output (EOs)
•It is an elementary process
•Derived or processed data crosses boundary from inside to
outside of the application boundary
•Data may be taken from ILFs and EIFs
47. External Output (EOs)
• Derived Data means
• Not a directly retrieved data
• Can be a result of calculations or algorithms
• Can be a report, chart of graph
• Almost always Business data
• Control data is never derived
• Rule based is also not derived
• May update an ILF
49. External Inquiries(EQs)
• It is an elementary process
• A combination of input & output
• Data may be retrieved from ILFs and EIFs
• Output is not derived or processed data
• Does not maintain any ILFs
• EQs could be
• Reports
• Charts, Graphs etc
56. Amazon E-commerce Application
• Amazon is an e-commerce web application allowing visitors to choose, view
and buy products
• We have considered a sub-section of this web application for our class
exercise purposes
• We have chosen specific screen shots to define the scope.
• This type of project is typically applicable, when a customer provides a
reference website or already has a software.
57.
58.
59.
60.
61.
62.
63.
64.
65. Assignment- II Tasks
•In the project “Amazon”, Do the following:
•Identify & classify EI, EO & EQs
•Identify DETs
•Identify ILFs & EIFs
67. Class Exercise
A tracking system for beer warehouse inventory keeps tracks of – which goods
are stored in the warehouse. As boxes of beer enter the warehouse,
barcodes on the boxes that identify their contents, are scanned. A record of
each scanned box is maintained in a database. As boxes leave the warehouse,
their barcodes are scanned again by a bar code reader to remove it from the
database. The bar code indicates the kind of beer and the box in which it is
kept. A code table maintains the relationship between the box code and the
content. A user can query the inventory database for the type of beer
availability.
68. Assignment- III Tasks
•In the project “Warehouse”, Do the following:
•Identify & classify EI, EO & EQs
•Identify DETs
•Identify ILFs & EIFs
70. Assignment
A telecom company sells talk time recharge products on phone. This facility is
sold to pre-paid numbers only. Agents gets a list of customers using pre-paid
numbers and call them up. The customer may or may not be interested in the
re-charge, but the call details are entered in the system and stored. If the
customer is interested, an order is created. The customer gives his credit card
number and PIN for the validation. The amount is charged to his account and
a code is sent to the mobile number of the customer. The customer enters
the code number sent as an SMS to a fixed number and the customer's
balance is updated.
72. Agile Methodology
• The Agile movement proposes alternatives to traditional project
management.
• Agile approaches are typically used in software development to help
businesses respond to unpredictability.
• Agile is a philosophy really & not a methodology
• It is characterized by iterative, continuous integration & faster delivery.
73. Agile Methodology
• Popular Agile methodology:
• SCRUM
• XP
• DSDM (Dynamic Systems development method)
• Lean Software Development
• Crystal
• Agile Unified Process
75. AGILE vs Traditional
• Highest priority requirements delivered first
• Development is Iterative
• Planning is Adaptive
• Roles blur – Tightly Integrated team
• Frequent communications
• Scope changes
• Requirements Change
• Working software is the primary measure of success
78. SCRUM
• Key feature is a SPRINT
• Features are listed as sticky notes or index cards, known as user stories
• User stories are put on notice boards to facilitate planning & discussion
• A SPRINT is an iteration
79. SCRUM
• SPRINT can be 1 to 4 weeks duration
• Project teams self-organizing
• No project plan or Schedule
• Every body works for the Goal of the SPRINT
• Daily Communication ( SCRUM Meetings)
• Small duration meetings, typically standing meeting
80. SCRUM
• Small team size (4 to 9 members)
• SCRUM Meeting to discuss:
• Project Status - Backlogs
• What did I do since the last Scrum meeting?
• What do I plan on doing between now and the next Scrum meeting?
• Do I have any roadblocks?
• Teams discusses to resolve roadblocks
• No %age or variance or metrics discussed
81. SCRUM
• Product Backlog
• List of requirements to deliver a product
• High level activities with estimates
• Release Backlog
• A subset of Product Backlog
• List with a priority order
• Better estimate
• SPRINT Backlog
82. SCRUM
• SPRINT Backlog
• Release backlog generates SPRINT backlog with high priority items
• Only part of Release backlog used in SPRINT backlog (till SPRINT backlog is filled)
• Item wise estimate
83. SCRUM
• SCRUM Burndown chart
• It helps to provide visibility of the progress of the team and the work remaining.
• The straight line represents an ideal iteration where work is completed in a perfectly
steady and evenly distributed manner.
• The more erratic line represents the work that is actually completed over time by the
team
• Daily chart
85. AGILE Project Management
• Responsible for maintaining the agile values and practices in the project
team.
• The agile project manager removes roadblocks as the core function of the
role.
• Helps the project team members to turn the Product backlog into working
software functionality.
• Manages SCRUM Meetings
• Chief Motivator of the team
86. AGILE Project Management
• Project Manager in an AGILE Project does not:
• manage the software development team.
• direct team members to perform tasks or routines.
• drive the team to achieve specific milestones or deliveries.
• make decisions on behalf of the team.
• involve in technical decision making or deriving the product strategy.
87. FPA for AGILE
• The estimation is done SPRINT wise
• FPA is done for each SPRINT
• It is possible that some user stories may overlap between SPRINTS
• Overlapping features need to be compensated for
• Consider a user story for a SPRINT only if it is getting delivered in that SPRINT
(for estimation)
88. FPA for AGILE
Example
• Lets say, a specific SPRINT needs to develop a user registration screen for
desktops as well as Mobile.
• Lets say the size is 15 FP
• The productivity is estimated to be 1.25 FP per day
• So person days = 15/1.25 = 12 days
89. FPA for AGILE
Example
• Product backlog, release backlog and user stories are updated
• Product backlogs are nothing but set of user stories, which include:
• Features
• Bugs
• Knowledge transfer
90. FPA for AGILE
Example
• Function points are always in the form of EI, EO and EQs along with ILF/EIF
• EI, EO and EQs are transactions so these are included in product backlogs
• The priorities are assigned by grouping transactions
91. FPA for AGILE
Steps to Requirements Management with Function Points in Agile
• Group similar priority/nature of requirements together and consider those as
a Product Backlog.
• If there is a change in requirements then a modified FPA can be used as the
Requirement Traceability Metrics.
92. AGILE Project Metrics
Metric Agile Metric
Velocity or Size total number of function points
delivered
per User Story or per iteration.
Productivity of the team per iteration total number of function points
delivered per iteration / actual effort
spent by the team in P Hrs or PDays
% Change in Velocity ((actual velocity – initial velocity)/initial
velocity ) * 100
Defect Density total weighted defects / size in function
points.
Requirements Volatility available function points in a project/
total function points of the project
(including add, change, delete FPs)
Cost per Iteration cost per function point X total function
points delivered on a project