Software Estimation

1. Software Estimation

2. Software Estimation • Direct measurement • LOC • Indirect measurement • Heuristics • Function point • Feature point • 3D Function point

3. Lines of Code (LOC) • Lines of Code (LOC) • Most traditionally used metric for project sizing • Most controversial • Count comments? • Declaring variables? • Efficient code vs. code bloat • Language differences • Easier to count afterwards than to estimate

4. Lines of Code (LOC)

5. Software Estimation • Heuristics • Rules of thumb approach to estimating • Require a predictable percentage of the overall effort • 30% planning • 20% coding • 25% component testing • 25% system testing • Estimating Software Costs -Capers

6. Function Points • Function Points • analysis based on evaluation of data and transactional types: • Internal Logical File (ILF) • External Interface File (EIF) • External Input (EI) • External Output (EO) • External Inquiry (EQ)

7. The Application Boundary for Function Point Analysis

8. Function Points • Application Boundaries • The application is planned to be developed in multiple stages, using more than one development project should be counted, estimated, and measured as separate projects, including all inputs, outputs, interfaces and inquiries crossing all boundaries. • The application is planned to be developed as a single application using one development project, but it is so large divide it into subapplications

9. Function Points • Application Boundaries (con’t) • The subapplications should be counted separated, but none of the inputs, outputs, interfaces, and inquiries crossing the arbitrary internal boundaries should be counted. • The function points of the subapplications should be summed to give the total function points of the application.

10. Function Points- Steps • Classify and count the five user function types • 3 level of complexity • Adjust for processing complexity • Make the function point calculation

11. Weight Factor count measurement parameter average complex count simple count number of user inputs x 3 + x 4 + x 6 = number of user outputs x 4 + x 5 + x 7 = number of user inquiries x 3 + x 4 + x 6 = number of user files x 7 + x 10 + x 15 = number of ext. interfaces x 5 + x 7 + x 10 = count = total complexity multiplier function points Function Points

12. Function Points • External Input Types are screen or forms through which human users of an application or other programs add new data or update existing data. • Count each unique user data or user control input type that enters the external boundary of the application being measured, and adds or changes data in a logical internal file type. • An external input type should be considered unique if it has a different format, or requires a processing logic different from other external input types of the same format.

13. Function Points • External Input Type • Simple: few data element types included in the external input type, and few logical internal file types are referenced by the external input type. User human factors considerations are not significant in the design of the external input type. • Average: is not clearly either simple or complex • Complex: many data element types are included in the external input type, and many logical internal file types are referenced by the external input type. User human factors considerations significantly affect the design of the external input type.

14. Function Points • External Output Types are screens or reports, or messages which the application produces for humans use or for other programs. • Count each unique user data or control output type that leaves the external boundary of the application being measured. • An external output type should be considered unique if it has a different format, or requires a processing logic different from other external output types of the same format

15. Function Points • External Output Type • Simple: one or more columns, simple data element transformation • Average: multiple columns with subtotals, multiple data element transformation • Complexity: intricate data element transformations, multiple and complex file references to be correlated, significant performance considerations.

16. Function Points • Logical Internal File Types are logical collections of records which the application modifies or updates. • Count each major logical group of user data or control information in the application, include logical file, or within a data base, each logical group of data from the viewpoint of the user, that is generated, used, and maintained by the application.

17. Function Points • Logical Internal File Types • Simple: few record types, few data element types, no significant performance or recovery considerations. • Average: is not clearly either simple or complex • Complex: many record types, many data element types, performance and recovery are significant considerations.

18. Function Points • External Interface File Types are files passed or shared with other applications. • Count each major logical group of user data or control information that enters or leaves the application. • Complexity classification: use definition similar to those for logical internal file types.

19. Function Points • External Inquiries Types are screens which allow users to interrogate the application and ask for assistance or information. • Count each unique input/output combination, where an input causes and generates an immediate output. • An external inquiry type should be considered unique if it has a format different from other external inquiry types in either its input or output parts, or requires a processing logic different from other external inquiry type of the same format.

20. Function Points • External Inquiry Types • classify the input part using definitions similar to the external input type • classify the output part using definition similar to the external output type. • The complexity of the external inquiry type is the greater of the two classifications.

21. IFPUG File Type Complexity

22. IFPUG External Input Complexity

23. IFPUG External Output Complexity

24. Processing Complexity • Estimate the degree of influence of each of the 14 general characteristics • Sum the 14 degree of influences and develop an adjustment factor • Multiply the adjustment factor to the work-product measure

25. Data Communications Distributed Data Processing Performance Heavily Used Configuration Transaction Rate Online Data Entry End User Efficiency Online Update Complex Processing Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change 14 General Characteristics

26. GSC and Total Adjusted Function Point

27. Fi M Function Point - Calculation • Adjustment factor = 0.65 + 0.01 X • Function Point = count-total X adjustment factor

28. Sensors test sensor zone setting password User SafeHome User Interface Function zone inquiry messages User panic button sensor status sensor inquiry activate/ deactivate activate/deactivate alarm alert Monitoring & Response Subsystem Password, sensor, … System configuration data Example

29. Feature Points • Feature Points were originally invented to solve the measurement problems of classical MIS. • Feature Point measure accommodates applications in which algorithmic complexity is high such as real time software, systems software, embedded software. • Algorithm is defined as the set of rules which must be completely expressed to solve a significant computational problem.

30. Example: Feature Points Approach

31. 3D Function Point • Data dimension is evaluated in the same way as Function Point (inputs, outputs, inquiries, logical files, interface files) • Functional dimension is measured by considering the number of internal operations required to transform input to output data. • Input and output data may be either internal to the application, external application , or both. • Level of complexity of each transformation is a function of the number of processing steps and the number of semantic statements that control the processing steps.

32. 3D Function Point • Functional dimension • transformation is viewed as a series of processing steps and semantic statements that cooperate to transform one set of input data into a set of output data. • semantic statements the predicated and the pre- and post-conditions for each step of the process. • Input and output do not necessarily refer to the input and output transactions that are part of the data dimension. • Processing that changes only the structure, format, or order of the data is not a transformation.

33. 3D Function Point • Control dimension is measured by summing the counts of both states and transitions. • A state is a set that contains one and only one- value for each condition of interest in the application. Any time the value of any data element in the internal data structure changes, the state of the application also changes. • A transition is a valid path from one state to another, or to the same state

34. Internal Data Structure and Interface

35. Level of Complexity Table for Input

36. Level of Complexity Table for Output

37. Level of Complexity Table for Transformations

38. State Transition Diagram full and start reading invoke manage-copying operator commands full invoke read-op-input copies done invoke read-op-input making copies reloading paper empty invoke reload paper jammed invoke problem-diagnosis not jammed invoke read-op-input problem state

39. Weight Factor count measurement parameter average complex count simple count Inputs x 3 + x 4 + x 6 = Outputs x 4 + x 5 + x 7 = Inquiries x 3 + x 4 + x 6 = Internal Data x 7 + x 10 + x 15 = External Data x 5 + x 7 + x 10 = Transformation x 7 + x 10 + x 15 = Transition x N/A + x 3 + x N/A = Total 3D Function Point Weights to Calculate 3 D Function Point

40. Backfiring • Technique for converting function point count to LOC

41. COCOMO – COnstructive COst MOdel • Developed at TRW, a US defense contractor • Based on a cost database of more than 60 different projects • Exists in three stages • Basic - Gives a 'ball-park' estimate based on product attributes • Intermediate - modifies basic estimate using project and process attributes • Advanced - Estimates project phases and parts separately

42. COCOMO MOdel • Project Types • Organic mode small teams, familiar environment, well-understood applications, no difficult non-functional requirements (EASY) • Semi-detached mode Project team may have experience mixture, system may have more significant non-functional constraints, organization may have less familiarity with application (HARDER) • Embedded Hardware/software systems, tight constraints, unusual for team to have deep application experience (HARD)

43. COCOMO MOdel • Basic Formulas • Organic – Person-Months = 2.4 x (KDSI)1.05 • Semi-detached– Person-Months = 3.0 x KDSI1.12 • Embedded– Person Months = 3. 6 x KDSI1.20 • KDSI = thousands of delivered source instructions, i.e. LOC

44. COCOMO Examples • Organic mode project, 32KLOC • PM = 2.4 (32) 1.05 = 91 person months • TDEV = 2.5 (91) 0.38 = 14 months • N = 91/15 = 6.5 people • Embedded mode project, 128KLOC • PM = 3.6 (128)1.2 = 1216 person-months • TDEV = 2.5 (1216)0.32 = 24 months • N = 1216/24 = 51

45. COCOMO MOdel • Duration Formulas • Organic TDEV=2.5(MM)0.38 • Semidetached TDEV=2.5(MM)0.35 • Embeded TDEV=2.5(MM)0.32

46. COCOMO MOdel • Intermediate Formulas • Organic PM = 3.2 x (KDSI)1.05 * EAF • Semi-detached PM = 3.0 x KDSI1.12 * EAF • Embedded– PM = 2.8 x KDSI1.20 * EAF • EAF =Effort Adjustment Factor

47. Cost Driver Attributes • Personnel attributes • Analyst capability • Virtual machine experience • Programmer capability • Programming language experience • Application experience • Product attributes • Reliability requirement • Database size • Product complexity

48. Cost Driver Attributes • Computer attributes • Execution time constraints • Storage constraints • Virtual machine volatility • Computer turnaround time • Project attributes • Modern programming practices • Software tools • Required development schedule