![What Do We Count? The Logical View.
Function Points looks at Vs. Physical View
the logical View
Functionality
[“The ability to”] Lines of code or
programs
Logically grouped stores of user data Databases or
[Data in 3rd normal form] Tables
Elementary processes Physical
[complete function, e.g., wizard] transactions
(screens)
Typically the user requirements reflect the logical view
©2012 David Consulting Group 6](https://image.slidesharecdn.com/fpintrobasics-120822104654-phpapp01/85/Function-Point-Analysis-An-Overview-7-320.jpg)
Uploaded byDCG Software Value
Function Point Analysis: An Overview
Function Point Analysis (FPA) is a standardized method to measure the size of software based on its functionality from the user's perspective. The International Function Point Users Group (IFPUG) promotes and develops guidelines for FPA. FPA counts different components of software functionality, such as inputs, outputs, inquiries, files and interfaces, assigning each a complexity level and weight in function points. These weights are then summed to calculate an overall function point size for the software.
More Related Content
Similar to Function Point Analysis: An Overview
Function Point Analysis: An Overview
- 1. Function Point Analysis: An Overview David Herron David Consulting Group d.herron@davidconsultinggroup.com
- 2. International Function PointUsers Group • Function Points were introduced in 1979 by A. Albrecht, IBM, at joint Share/ Guide Conference • IFPUG chartered in 1986 • IFPUG Purpose • To promote and encourage use of Function Points • To develop consistent and accurate counting guidelines • Maintains Public Standard for Sizing Software (CPM) • Benefits: • Networking with other counters • Management Reporting • Research projects • Website • Certifications for Function Point Methodology ©2012 David Consulting Group 1
- 3. Function Point History • Now used world-wide in North America, Central America, South America, Australia, Europe, and Asia • Recognized Functional Size Measure for ISO Standards • Functional size measurement (FSM) method which is an International Standard in compliance with ISO/IEC 14143- 1:2007 • IFPUG White Papers published on a variety of measurement-related topics • IFPUG CPM Version 4.3 issued in 2009, effective 2010 • IFPUG - Certifications in FPA and Software Measurement • ISMA - Fall Conferences on Metrics and Measurement • Website : www.ifpug.org ©2012 David Consulting Group 2
- 4. Why Function PointAnalysis? Function Point Analysis is the method for measuring functional size as defined within the IFPUG FSM Method. • Standardized method for measuring the functionality delivered to an end user • Consistent • Available early in the lifecycle • Acceptable level of accuracy • Meaningful internally and externally FSM is accomplished using the information in a language that is common to both user(s) and developer(s). IFPUG FSM Method is the major global functional sizing methodology. ©2012 David Consulting Group 3
- 5. What is (are)Function Points? • Unit of measure for functional size as defined within the IFPUG Functional Size Measurement (FSM) Method • Standard method for quantifying the software deliverable based upon the user view • User is any person or thing that communicates or interacts with the software at any time • User View is the Functional User Requirements as perceived by the user • Functional user requirements are a subset of user requirements: requirements that describe what the software shall do, in terms of tasks and services ©2012 David Consulting Group 4
- 6. Functional vs. Non-Functional Requirements Functional • Data Transfer (Input customer data, send control signal, send transactions from one system to another) • Data Transformation (Calculate bank interest; derive average temperature; use billing data to produce invoice totals) • Data Storage (Store customer order; record temperature over time; store control parameters to drive data) • Data Retrieval (List current employees; retrieve satellite position; display a report of employee dependents) Non-Functional • Quality Constraints (Usability, Reliability, Efficiency, Portability) • Organizational Constraints (locations for operations, target hardware, compliance to standards) • Environmental Constraints (interoperability, security, privacy, safety) • Implementation constraints (development language, delivery schedule) ©2012 David Consulting Group 5
- 7. What Do WeCount? The Logical View. Function Points looks at Vs. Physical View the logical View Functionality [“The ability to”] Lines of code or programs Logically grouped stores of user data Databases or [Data in 3rd normal form] Tables Elementary processes Physical [complete function, e.g., wizard] transactions (screens) Typically the user requirements reflect the logical view ©2012 David Consulting Group 6
- 8. What Do WeCount? INPUT FILES AND INPUT TRANSACTIONS APPLICATION (BATCH INTERFACES) BOUNDARY OUTPUT FILES AND OUTPUT TRANSACTIONS (BATCH INTERFACES) SCREENS INTERNAL LOGICAL FILES (ADDS, CHANGES, (TABLES, DATA FILES, DELETES, QUERIES) CONTROL FILES) OTHER OUTPUTS •REPORTS •FILES •XML •VIEWS CONTROL INFORMATION •FICHE •TAPE •DISKETTES EXTERNAL •LETTERS TABLES & FILES REFERENCED •NOTICES from other applications •ALARMS (Not Maintained) ©2012 David Consulting Group 7
- 9. What Do WeCount? The Logical View. External External External Inquiry Input (EI) Output (EQ) (EO) External Input (EI) Internal Logical External File (ILF) Interface File Other (EIF) Applications Internal Logical File (ILF) Other Applications External Output (EO) Application Boundary ©2012 David Consulting Group 8
- 10. How Do WeCount? • Gather available documentation • Determine the counting scope, boundaries and identify functional user requirements • Identify and classify the base functional components – Measure the data functions • Internal Groupings of data called Internal Logical Files (ILF) • External Groupings of data or External Interface Files (EIF) – Measure the transactional functions • External Inputs (EI) • External Outputs (EO) • External Inquires (EQ) – Each function is assigned a functional complexity (L-A-H) and a weight (FPs) • Calculate the functional size • Document the Function Point Count • Report the result of the Function Point Count ©2012 David Consulting Group 9
- 11. Gather Available Documentation •Should describe the functionality delivered by the software or the functionality that is impacted by the software project that is being measured • Sufficient to conduct the count, or have access to subject matter experts who are able to provide additional information to address gaps in the documentation • Requirements, data/object models, class diagrams, data flows, use cases, process descriptions, report layouts, screen layouts, user manuals ©2012 David Consulting Group 10
- 12. Scope and Boundary •An application boundary is a conceptual interface between the software under study and its users. • Scope of a project could include multiple applications. • A functional size would be calculated for each affected application, in perspective to its boundary, thereby producing its own count • All affected application counts would be compiled to produce the total project count. ©2012 David Consulting Group 11
- 13. Identify, Classify, Calculate 1.Identity and classify system components that are user identifiable - files, reports, inputs, outputs, transactions (System functions) 2. Classify system components into base functional components categories. {Report could be an External Output} 3. Measure each entity by applying a complexity rating (low, average, high) and a weight (in function points). {High Output = 7 FPs} 4. Calculate: Add all the weights together to get an (unadjusted) function point count ©2012 David Consulting Group 12
- 14. Component Complexity &Weights • FP Counting is based on Identification Rules and Complexity Rules (CPM) • Components are assessed based upon complexity according to the rules Complexity Components: Low Avg. High Total Internal Logical File (ILF) __ x 7 __ x 10 __ x 15 ___ External Interface File (EIF) __ x 5 __ x 7 __ x 10 ___ External Input (EI) __ x 3 __ x 4 __ x 6 ___ External Output (EO) __ x 4 __ x 5 __ x 7 ___ External Inquiry (EQ) __ x 3 __ x 4 __ x 6 ___ ©2012 David Consulting Group 13
- 15. What Can WeCount? Any system that has inputs or outputs and has and/or uses data or control information. • Installed application: Baseline (or application) count • Development project: New system or subsystem • Enhancement project: Add, change or delete to present system (includes minor enhancements) • Non-functional (technical) requirements are not countable for some types of maintenance ©2012 David Consulting Group 14
- 16. What Can WeCount? Enhancement vs. Maintenance • Adaptive Maintenance – Software maintenance performed to make a computer program usable in a changed environment – Includes modifications to meet new or changing business or technical requirements – Initiated by business requests (user requests that may be functional or non- functional requirements) – “Enhancement” requests are a subset of this group • Corrective Maintenance – Software maintenance performed to correct faults in hardware or software – Includes defect repair – Ensures that previously delivered functionality performs as required – Effort should be attributed to the original project that introduced the defect • Perfective Maintenance – Software maintenance performed to improve the performance, maintainability, or other attributes of a computer program – Includes system upgrades, performance optimization, platform service agreement maintenance – No business functionality – typically non-functional requirements ©2012 David Consulting Group 15
- 17. What Can WeCount? Enhancement vs. Maintenance • Function Point Analysis is applicable to a subset of Adaptive Maintenance • Function Point Analysis should not be used to size Perfective or Corrective Maintenance work. • Mixing enhancement work with maintenance work can be expedient or necessary, even efficient, but the hours must be tracked separately • For accurate metrics, separation of work effort is necessary • Preventative and/or corrective maintenance have zero function points • Packing into releases and apportioning releases is usually the most manageable approach ©2012 David Consulting Group 16
- 18. Using FP WHEN Can We Count? PROPOSAL DESIGN CONSTRUCTION TESTING DELIVERY CORRECTIVE REQUIREMENTS MAINTENANCE Initial User Feasibility Requirements Function Function Function Study Points Points Points Initial Revised Actual Technical Estimate Size Requirements Counted Counted Size can be Size can be Life Cycle Phase approximated measured? Final ? Functional Requirements Proposal Yes No Requirements Yes Yes Design Yes Yes Construction Yes Yes Function Delivery Yes Yes Points Corrective Yes Yes Maintenance Early Estimate Approximated ©2012 David Consulting Group 17
- 19. Why Do WeCount? – Benefits of FPA • Requirements Management. A tool to determine the benefit of an application to an organization by counting functions that specifically match functional requirements • Benchmarking. Measure software development and maintenance activities independently of technology used for implementation for comparisons • Increase Process Capability. – Metrics. Provide a consistent, normalized measure across various projects, organizations and technology platforms to support performance (quality and productivity) analysis – Estimation Modeling. A vehicle to estimate cost and resources required for software development and maintenance (Must also consider project attributes, work breakdown structure, etc.) • Size Customized and COTs. A tool to size purchased application package • Client-Supplier Relationships. Establish service level agreement (SLA) targets and tolerances. ©2012 David Consulting Group 18
- 20. Contact Us Email: d.herron@davidconsultinggroup.com Phone:1-610-644-2856, ext 21 http://www.davidconsultinggroup.com @DavidConsultGrp /DavidConsultGrp /company/David-Consulting-Group ©2012 David Consulting Group 19
Editor's Notes
- #2 Welcome to DCG’s Function Point Analysis: Sizing the Software Deliverable Series. Function Point Fundamentals is the first course in a series of courses built to help you become a proficient counter, and should you choose to do so, become a Certified Function Point Specialist (CFPS).
- #3 Function points were introduced in 1979 by Alan Albrecht, from IBM. IBM needed a way to quantity the size of their projects in order to provide a better estimation model for their workload. Function points was the answer and in 1986 the International Function Point Users Group was chartered to be the governing body for the function point methodology. IFPUG is a not-for-profit organization consisting of an elected board of directors, and several committees devoted to supporting, developing and implementing consistent and accurate counting guidelines. The Counting Practices Committee (CPC) develops the counting guidelines and the Counting Practices Manual (Documented Rules), the New Environments Committee (NEC) applies those guidelines to new technologies and produces white papers and case studies for use by the IFPUG membership, the IT Performance Committee explores the use of function points in benchmarking and estimation modeling, and other committees oversee the certifications provided by IFPUG. Benefits of being an IFPUG member include reduced pricing for conferences and IFPUG training during the conferences, access to resource material (e.g. articles and white papers), and networking capabilities with the IT community that shares a common interest in metrics and function points.
- #8 Function points only address the functional requirements and are from a logical view not a physical view. A typical developer would be looking at programs, physical database tables, and physical screens. We as function point specialists (counters) look at the functionality provided by the screens (transactions), logical data groupings of tables, and the ability of the application to perform a complete process. Typically, business user requirements reflect the logical view.
- #10 Which of these things are the most important to you or frustrating or challenges…
- #20 This slide concludes the class sessions. This is the first of several classes that we offer in the use of function points. If you want further mentoring or training for the individual or the organization, please contact Fiona Thompson at the DCG Headquarters or Sheila Dennis in the Colorado offices.