Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project.

Similar presentations


Presentation on theme: "Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project."— Presentation transcript:

1 Copyright 1995-2008, 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

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

3 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 3 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

4 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 4 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

5 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 5 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

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

7 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 7 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

8 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 8 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”.

9 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 9 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

10 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 10 (*) 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

11 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 11 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)

12 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 12 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

13 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 13 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.

14 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 14 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

15 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 15 Function Point Example CategorySimple Average Complex EO 3 4 5 Weights 4 5 7 Points 12 20 35 Total Points for External Outputs: 67

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

17 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 17 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.

18 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 18 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

19 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 19 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

20 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 20 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

21 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 21 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

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

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

24 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 24 2. 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

25 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 25 3. 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 0 - 5 as “No-Influence” to “Strong-Influence“ ; 2.5 is “typical”. –Appendix A enumerates the GSCs VAF = 0.65 +  GSC i /100

26 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 26 4. 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

27 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 27 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

28 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 28 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

29 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 29 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

30 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 30 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

31 Copyright 1995-2008, 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

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

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

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

35 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 35 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).

36 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 36 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

37 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 37 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.

38 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 38 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

39 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 39 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

40 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 40 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)

41 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 41 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)

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

43 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 43 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.

44 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 44 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

45 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 45 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

46 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 46 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

47 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 47 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

48 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 48 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

49 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 49 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 35-44.  Garmus, David and David Herron, Measuring the Software Process - A Practical Guide to Functional Measurements, Prentice-hall, 1996.  International Function Point Users Group, Function Point Counting Practices Manual

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

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

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

53 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 53 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?

54 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 54 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?

55 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 55 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?

56 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 56 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?

57 Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M13 - Version 8.01 57 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?


Download ppt "Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M13 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project."

Similar presentations


Ads by Google