Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project Module 13 Size Estimating Methods Part 2 - Function Points and Related Methods

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Objective of This Module  To discuss function point methods and related size estimating methods

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Detailed Planning - Processes Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost ScheduleOK Complete Detailed Planning Revise & Negotiate Not OK Estimate Size Estimate Effort and Cost

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Architecture of Spreadsheet Model Based Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Final Effort Estimate Productivity Based Effort Estimate Other Size Estimates... Final Size Estimate Expert Based Size Estimate Size / Reuse EffortEffort & Cost Schedules Generic Schedule Effort Schedule Labor Schedule Cost Schedule

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Methods (background)  Function points measure the size of the customer’s requirements, or the size of the functionality to be produced, rather than the physical size of the software –This is analogous to measuring the size of a house by counting the number and types of rooms, rather than by square footage

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Methods  Function Points as a size unit  Function Point Analysis as an estimating method

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Points are a Unit of Size  “Function points” may be directly correlated to effort, memory requirements, or even to lines of code –All of the estimating methods discussed previously can be used with function points as the size unit –For example, you can compare new software with previous software, or use the wideband Delphi techniques

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Analysis (FPA) is a Method of Estimating  The function point method was developed by Allan Albrecht and refined by others (see references) to deal with situations where much was known about the functionality of the software but little about the structure or the size in “lines of code”.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Methods  The original definition by Albrecht was based on transaction oriented systems –This concept of a “function” may not work as well with other types of software  Variations exist for real time, object oriented, and other kinds of applications

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version (*) This is a goal of all size estimating methods. Goals of Function Point Analysis  To predict size accurately, as early as possible (*)  To provide a mechanism to track and monitor “scope creep” (*) –The difference in the number of function points after requirements analysis, design & delivery is an indication to how much the scope of a project has grown

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Albrecht’s Model of a Computer Software Application Internal Logical Files (ILFs) End User / Other Programs EO EI EQ External Queries External Outputs External Inputs Data Base (External Interface Files)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Categories of Functions - I 1. External Inputs (EI) –An elementary process where data flows in across the system boundary 2. External Outputs (EO) –An elementary process where “derived-data” flows out across the system boundary 3. External Queries (EQ) –An elementary process which outputs data from ILFs based on the data input

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Categories of Functions - II 4. Internal Logical Files (ILF) –A logically related group of data that resides entirely within the applications boundary and is maintained through EIs 5. External Interface Files (EIF) –A logically related group of data that is used for reference purposes only –The data resides entirely outside the application Note: the idea of splitting files into internal & external is credited to Capers Jones in the early 1980’s.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Method in a Nutshell 1) Count the functions in each category 2) Establish the complexity of each: –High, Medium, or Low 3) Establish weights for each complexity 4) Multiply each function count by its weight and then sum up to get total function points 5) Adjust for application characteristics

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Example CategorySimple Average Complex EO Weights Points Total Points for External Outputs: 67

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Function Point Formula “Unadjusted” Function Points (UFP) = EO points + EI points + EQ points + ILF points + EIF points

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Adjustment Factor “Adjusted” FP = UFP * VAF  VAF is an “application characteristics value adjustment factor” that ranges from 0.65 to 1.35 (see appendix A)  VAF is determined by application characteristics that cannot be counted but that affect the application as a whole –Ease of use, reliability, flexibility, etc.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Note on Adjustment Factor  Some studies have concluded that the adjustment factor degrades the function point metric, resulting in lower accuracy  Thus some authors prefer to leave out the adjustment factor and, instead, to assess application characteristics in the process of estimating effort

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The Devil is in the Details  How do you establish the weights?  How do you identify the functions?  How do you determine the adjustment factor?  What do you do if your application seems to have different kinds of functions other than Albrecht’s?  The literature on function points is largely devoted to issues like these

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Step by Step Details  Longstreet, Garmus, and the International Function Point Users Group (IFPUG) have good descriptions of how to count function points  For more information, see the reference list at the end of these notes

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Calibration is Helpful - But Hard!  Albrecht warns against attempting to calibrate for a given industry, application domain, or company  He and others believe the specific software development organization must calibrate the FPA method to their own characteristics.  But few organizations have enough data to do an effective calibration

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Notes on Function Points

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Determine the Application Boundaries The “functions” counted are those that cross the application boundary (except for internal files) Application External Environment

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Plan to Review and Update the Function Point Count  Plan updates at key points where new information will be available, such as at major milestones  Gather documentation, such as key requirements, constraints, and assumptions, for reference during future updates  Record all of the functions that were counted, as well as their complexities

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version How to Compute the Value Adjustment Factor  VAF is based on the 14 General System Characteristics (GSCs) –The degree of influence of each GSC is ranked from as “No-Influence” to “Strong-Influence“ ; 2.5 is “typical”. –Appendix A enumerates the GSCs VAF =  GSC i /100

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Using Function Points as Input to an Effort Estimate  Some effort estimating tools will accept function points as a “size” estimate.  For others, you must convert to function points to LOC LOC = POINTS *CONVERSION FACTOR –Conversion factor is established based on historical experience representing average number of lines per simple function

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version What About Applications Where Function Points Don’t Seem to Fit?  Example: Real Time Systems –Tend to have few internal files –But have very complex algorithms  Extensions to Function Points are often used to handle non-transaction oriented systems, such as real time systems, object oriented designs etc  Among the extensions are Feature Points and Object Points

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Feature Points  An extension of the function point method designed to deal with real time systems.  A new category of function that represents complex algorithms  The complexity of the algorithm is defined in terms of the number of “rules” required to express that algorithm

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Other Changes for Feature Points Method  Lower weights for internal files  Other adjustments based on local experience  Numerous variations in literature  The bottom line is that whatever works for you should be used

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Object Points  This approach is at a more macro level than function points  Developed to address object oriented designs  Assign one object point to each unique class or object, such as a screen, output report, etc.  The rest of the process is similar, but the weights are different

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 Parametric Models These are top-down methods based on some understanding of what factors or parameters affect the size of the software

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version How Do You Determine What Factors Affect the Size? Data Analysis Facts about Which Factors have What Impact Parametric Model

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Several Types of Adjustment Factors

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Using a Parametric Model Parametric Model Specific Values for Specific Situation Expected or Estimated Behavior

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Adjustment Method Derived from Price-S ® Parametric Model  Define attributes for the software, as follows: -- Software development environment -- Software complexity -- Program data -- Project planning Price-S ® is a cost and size estimating tool originally developed by RCA and then owned by General Electric, sold to Lockheed-Martin (Price Systems division).

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Adjustment Method Derived from Price-S ® (continued)  Apply all of these attributes by means of a complex function (mathematical model) to adjust the size estimate Price S Model Specific Values for Specific Situation Expected or Estimated Size

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Software Development Environment Attributes  Number of design reviews planned  Number of code walkthroughs planned  Sophistication of design method –OO, SA/SD. Etc.  Number of hardware and other software elements to integrate with  Sophistication of test methods –Structured, modular, etc.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Software Complexity Attributes (select the one that fits)  Commercial - no constraints  Commercial - moderate constraints –eg., must fit on a Pentium with 16Megabytes  Commercial - significant constraints –eg. must fit on a microprocessor with only 256K bytes and must meet significant timing constraints

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Software Complexity Attributes (select the one that fits) (continued)  Military - no constraints –eg., military data processing application  Military - moderate constraints –eg., ground-based combat support system  Military - significant constraints –eg., flight controls on an aircraft

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Program Data Attributes  Number of unique output page formats  Number of unique display formats (alphanumeric)  Number of unique graphic displays  Number of unique input streams  Number of unique output streams  Number of control states (decision points)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Program Data Attributes (continued)  Number of input message fields (unique fields)  Number of unique operator actions  Number of unique analog signals on input  Number of data elements in tables  Functional bulkiness (tool efficiency, staff experience)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Project Planning Attributes  Expected requirements growth (% of original system requirements)  Organizational know-how and experience  Organizational business approach  Source language

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Advantages of Function Points and Related Methods  Estimates can be made relatively early in the project –before we know the architecture of the software  Easier for customers to relate the impact of change in functional requirements etc.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Advantages of Function Points and Related Methods (continued)  Independent of programming language, technology, and techniques  More reliable relationship to effort – IF you can determine the right functions to measure and the correct weights and adjustments

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Disadvantages of Function Points and Related Methods  It is hard to count and track function points –Much judgment involved –Difficult to automate  Details, such as weights and definitions of complexity level, vary significantly from one application to the next and from one organization to the next

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Disadvantages of Function Points and Related Methods (continued)  Internal complexity of the application is not considered –For example, housekeeping, memory management, and other support functions  Calibration takes time, effort, and data –Although using results from similar applications may be a good starting point

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Many People Really Like Function Points … but...  Many effort/cost estimation tools use lines of code as input, so figures in function points may have to be converted –FPA may be a useful way to estimate lines of code, regardless of whether function points are a good size unit  More data may be available on lines of code than on function points –This depends on your company and business

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version Module Summary  Function point methods do not require information in size in lines of code, only the functions to be performed  Other parametric methods rely on general characteristics of the software rather than specific details

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version References  Albrecht, Allan J., "Measuring Application Development Productivity," reprinted in Tutorial, Programming Issues for the Eighties (Capers Jones, editor), IEEE Computer Society Press, 1986, pp  Garmus, David and David Herron, Measuring the Software Process - A Practical Guide to Functional Measurements, Prentice-hall,  International Function Point Users Group, Function Point Counting Practices Manual

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version References (continued)  Longstreet, David “Function Points: Step by Step”. Available on line at  Symons, Charles, Software Sizing and Estimation, Mk II Function Point Analysis, West Sussex, England, John Wiley and Sons, 1991.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version END OF MODULE 13

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 Appendix A General System Characteristics Used to Calculate Function Point Adjustment Factor

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The 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 –Was response time or throughput required by the user?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The General System Characteristics (continued) 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The General System Characteristics (continued) 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The General System Characteristics (continued) 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version The General System Characteristics (continued) 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?