1 Estimation Function Point Analysis December 5, 2006.

Slides:



Advertisements
Similar presentations
FPA – IFPUG CPM 4.1 Rules.
Advertisements

Early Effort Estimation of Business Data-processing Enhancements CS 689 November 30, 2000 By Kurt Detamore.
Planning a software project: Function point analysis. José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada.
Function Point Analysis example. Function point FP is defined as one end-user business function FPA evaluates the system from a user perspective.
R&D SDM 1 Metrics How to measure and assess software engineering? 2009 Theo Schouten.
Software project management (intro)
1 PROJECT SIZING AND ESTIMATING - EFFECTIVELY USING FUNCTIONAL MEASUREMENT Southern California Software Process Improvement.
Predictive Modeling And Reporting Environment (PMRE) CS 552 Senior Design Architecture Review Presenting: Steve Su Ilya Chalyt Yuriy Stelmakh (Architect)
CS 551 Estimation Fall December QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing,
SOFTWARE PROJECT MANAGEMENT AND COST ESTIMATION © University of LiverpoolCOMP 319slide 1.
Information Technology Project Management
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
1 U08784 Software Project Management lecturer: Timothy Au url:
Software Metric capture notions of size and complexity.
Copyright © The David Consulting Group, Inc. 1 UNDERSTANDING and EFFECTIVELY USING FUNCTIONAL MEASUREMENT Presented By The David Consulting Group.
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Estimation Why estimate? What to estimate? When to estimate?
Chapter 6 : Software Metrics
Chapter 1 In-lab Quiz Next week
Chapter 6 The Work Breakdown Structure and Project Estimation Copyright 2012 John Wiley & Sons, Inc. 6-1.
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
Software Cost Estimation 1. APPROACHES Traditional: LOC estimation Modern: Functional Point Analysis 2.
Sizing Your Development Effort Using Function Point Analysis Mike Pasley Logic Central
Personal Estimation with PROBE CS3300 Fall Code Size Estimation Wide Band Delphi (Boehm) Give the team the specs to study Discuss the project goals.
Version control – Project repository, version management capability, make facility, issue/bug tracking Change control Configuration audit – compliments.
Software Metrics Software Engineering.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
Lecture 4 Software Metrics
Project Planning and Estimation
Software complexity estimation by Adam Bondarowicz by Adam Bondarowicz.
Function Point Analysis. Function Points Analysis (FPA) What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent.
SEG3300 A&B W2004R.L. Probert1 COCOMO Models Ognian Kabranov.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
Functional Size Measurement Methodologies. What is FSM ? Definitions: Functional Size: A size of the software derived by quantifying the Functional User.
CSE SW Project Management / Module 13 - Function Points and Related Methods Copyright © , Dennis J. Frailey, All Rights Reserved CSE7315M13.
540f07cost12oct41 Reviews Postmortem u Surprises? u Use white background on slides u Do not zip files on CD u Team leader should introduce team members.
Personal Estimation with PROBE CS3300 Fall Process Everybody has one !!! Formal – Completely defined and documented Informal – Just the way things.
NASA Software Assurance Symposium 2001 Metrics for Fault-Tolerant Real-Time Software Afzel Noore Computer Science and Electrical Engineering West Virginia.
FUNCTION POINT ANALYSIS & ESTIMATION
Intro to Estimating Part Art, Part Science. Importance of Good Estimates Time (Realistic Deadlines) most software projects are late because the time was.
Cost9b 1 Living with Function Points Bernstein and Lubashevsky Text pp
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
Cost23 1 Question of the Day u Which of the following things measure the “size” of the project in terms of the functionality that has to be provided in.
Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project.
Internal Logical Files (ILF) An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within.
THE FAMU-CIS ALUMNI SYSTEM
Alternative Software Size Measures for Cost Estimation
The Work Breakdown Structure and Project Estimation
Testing Techniques.
RET Rules One of the following rules applies when counting RETs:
Data Functions: EIs, EOs and EQs
System Design.
Software Cost Estimation For Component Based Fourth-generation-language Software Applications 지능형시스템 연구실 김정민.
Function Point Analysis
Software Development & Project Management
Mk II Function Point Analysis
Alternative Software Size Measures for Cost Estimation
Software Size Measures for Cost Estimation
Personal Software Process Software Estimation
Function Point.
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Software Sizing and Costing
Software Effort Estimation
COCOMO MODEL.
Presentation transcript:

1 Estimation Function Point Analysis December 5, 2006

2 Agenda FPA Overview FPA Detail How to Count Function Points? When to Use Function Points? Quick Recap

3 FPA Overview What are Function Points? A standard metric for the relative size and complexity of a software system. developed by Alan Albrecht of {IBM} in the late 1970s. Functon points (FPs) can be used to estimate the relative size and complexity of software in the early stages of development - analysis and design. The size is determined by identifying the components of the system as seen by the end-user: the inputs, outputs, inquiries, interfaces to other systems, and logical internal files. The components are classified as simple, average, or complex. All of these values are then scored and the total is expressed in Unadjusted FPs (UFPs). Complexity factors described by 14 general systems characteristics, such as reusability, performance, and complexity of processing can be used to weight the UFP.

4 FPA DETAIL Types of Function Points Transaction Function Points  External Inputs  External outputs  External Inquiries Data Function Points  Internal Logical Files  External Interface Files

5 Transaction Function Points External Inputs EI - Information that comes from outside the application to inside the application boundary. External outputs EO - Information that crosses the boundary from inside to outside the application boundary that contains derived information or updates an internal logical file. External Inquiries EQ - Information that crosses the boundary from inside to outside the application boundary that does not contain derived information or does not update an internal logical file.

6 Transaction Function Points Continued… Transaction Function Point count is based on DET’s and FTR’s DET – Data Element Types The number of user-recognizable fields. FTR – File Type Referenced The number of files updated or referenced.

7 Data Function Points Internal Logical Files ILF - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs. External Interface Files EIF - a user identifiable group of logically related data that is used for reference purposes only.

8 Data Function Points Continued… Data Function Count is based on DET’s and RET’s DET – Data Element Types The number of user-recognizable fields. RET – Record Element Types The number of user-recognizable data elements in an ILF or EIF.

9 Rating External Inputs External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen, electronically or another application. The data can be either control information or business information. If the data is business information it is used to maintain one or more internal logical files. If the data is control information it does not have to update an internal logical file. Rating of External Inputs is based on the number FTR’s and DET’s and is rated as low, average and high as shown in the table below.

10 Rating External Outputs/External Inquiries External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. The data creates reports or output files sent to other applications. These reports and files are created from one or more internal logical files and external interface file. External Inquiry (EQ) - is 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. This information is sent outside the application boundary. The input process does not update any Internal Logical Files and the output side does not contain derived data. EO and EQ Table

11 Function Count Values for transactions An EQ is rated (Low, Average or High) like an EO, but assigned a value like an EI.

12 External Input example This external input would be rated as a low external input and valued at 3 unadjusted function points. This example demonstrates an external input with 15 data elements (DET's) that creates data on one internal logical file (ILF).

13 External Output Example The following EO has 3 data elements (DET's) and references 4 FTR's (file types referenced) and would be rated as an Average and valued at 5 unadjusted function points. The Amount data element is a calculated value (derived data) and you would not be find it on any FTR. The description and due date data element (or fields) could be found on FTR's. What makes this an EO is the calculated values.

14 External Inquiry Example The following EQ has 4 data elements (DET's) and references 1 FTR (file types referenced) and would be rated as a Low and valued at 3 unadjusted function points. The Soc. Sec # is a data element that has been read from an employee file (ILF). The name is three data elements in this case, first name, middle initial and last name. All three DET's are needed to distinguish between employees and the SSI# is needed. So there are four data elements on this EQ and it gets all information from one FTR (ILF). Again, this EQ would be rated as a low and valued at 3 unadjusted function points.

15 Rating Data Functions Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through External Inputs. External Interface Files (EIF) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The External Interface File is an Internal Logical File for another application. both ILF’s and EIF’s the number of record element types and the number of data elements types are used to determine a ranking of low, average or high.

16 Function Count Values for Data Functions

17 External Interface Example This example combines an EQ with an EIF. The EQ contains three (3) DET's {Zip Code, City and State} and references one FTR (Zip Code EIF). The Zip Code information is maintained by another application. Keep in mind, that an FTR must be either an EIF or ILF. From the perspective of the application being counted, the EIF contains three data elements {zip code, city and state}. In actuality, the file may contain more than three data elements but we only consider the logical view from the application being counted.

18 EIF Example … To summarize, this example has on EIF rated low and one EQ rated low. This is only a snapshot of the detail address information. Of course, there would be additionally transactions and files to complete this process. Assumptions -- Beyond this example and it general, it is safe to say that every EIF must have at least one transaction against it. That is at least one transaction (EI, EO and EQ) should reference the EIF.

19 Counting Unadjusted Function Points Following Table gives us the UFP

20 General System Characteristics GSC 1 Data communications  How many communication facilities are there to aid in the transfer or exchange of information with the application or system? GSC 2 Distributed data processing  How are distributed data and processing functions handled? GSC 3 Performance  Was response time or throughput required by the user? GSC 4 Heavily used configuration  How heavily used is the current hardware platform where the application will be executed? GSC 5 Transaction rate  How frequently are transactions executed daily, weekly, monthly, etc.?

21 General System Characteristics Continued… GSC 6 On-Line data entry  What percentage of the information is entered On-Line? GSC 7 End-user efficiency  Was the application designed for end-user efficiency? GSC 8 On-Line update  How many ILF’s are updated by On-Line transaction? GSC 9 Complex processing  Does the application have extensive logical or mathematical processing? GSC 10 Reusability  Was the application developed to meet one or many user’s needs?

22 General System Characteristics Continued… GSC 11 Installation ease  How difficult is conversion and installation? GSC 12 Operational ease  How effective and/or automated are start-up, back-up, and recovery procedures? GSC 13 Multiple sites  Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? GSC 14 Facilitate change  Was the application specifically designed, developed, and supported to facilitate change?

23 Adjusted Function Points FP=VAF*UFP Where UFP=Unadjusted Function Points VAF = Value Adjustment Factor based on the Value of 14 general system characterstics FP = Adjusted Function Points VAF = (sum(GSC) *.01)

24 Using Function Points to Estimate Test Cases There is a strong relationship between the number of defects and the number of test cases and number of function points. The number of acceptance test cases can be estimated by multiplying the number of function points by 1.2. Like function points, acceptance test cases should be independent of technology and implementation techniques. Total number of test cases will approximately equal the number of Function Points raised to the 1.2 power (FP 1.2 ). Total Number of Test Cases = (FP) 1.2 number of acceptance test cases = 1.2xFP Estimating Defects Intuitively the number of maximum potential defects is equal to the number of acceptance test cases which is 1.2 x Function Points.

25 Defect Removal Efficiency

26 References ml