Software Cost Estimation
1 like600 views
This document discusses software cost estimation and factors that influence productivity. It defines software cost estimation as predicting resources needed for development like effort, time and total cost. Cost components include hardware/software, travel/training, and effort costs like salaries and overheads. Productivity measures include lines of code, function points based on functionality, and object points. Factors like language, code verbosity, and system characteristics can impact productivity estimates.
Software Cost Estimation
- 1. SOFTWARE COST ESTIMATION Software Engineering CSE470
- 2. Software cost estimation Predicting the resources required for a software development process
- 3. Fundamental estimation questions How much effort is required to complete an activity? How much calendar time is needed to complete an activity? What is the total cost of an activity? Project estimation and scheduling and interleaved management activities
- 4. Software cost components Hardware and software costs Travel and training costs Effort costs (the dominant factor in most projects) salaries of engineers involved in the project Social and insurance costs Effort costs must take overheads into account costs of building, heating, lighting costs of networking and communications costs of shared facilities (e.g library, staff restaurant, etc.)
- 5. Costing and pricing Estimates are made to discover the cost, to the developer, of producing a software system There is not a simple relationship between the development cost and the price charged to the customer Broader organisational, economic, political and business considerations influence the price charged
- 7. Programmer productivity A measure of the rate at which individual engineers involved in software development produce software and associated documentation Not quality-oriented although quality assurance is a factor in productivity assessment Essentially, we want to measure useful functionality produced per time unit
- 8. Productivity measures Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc. Function-related measures based on an estimate of the functionality of the delivered software. Function- points are the best known of this type of measure
- 9. Measurement problems Estimating the size of the measure (e.g. how many function points). Estimating the total number of programmer months that have elapsed. Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate.
- 10. Lines of code What's a line of code? The measure was first proposed when programs were typed on cards with one line per card How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line What programs should be counted as part of the system? Assumes linear relationship between system size and volume of documentation
- 11. Productivity comparisons The lower level the language, the more productive the programmer The same functionality takes more code to implement in a lower-level language than in a high-level language. The more verbose the programmer, the higher the productivity Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code.
- 13. Function points Based on a combination of program characteristics external inputs and outputs; user interactions; external interfaces; files used by the system. A weight is associated with each of these and the function point count is computed by multiplying each raw count by the weight and summing all values.
- 14. Object points Object points are an alternative function-related measure to function points Object points are NOT the same as object classes The number of object points in a program is a weighted estimate of The number of separate screens that are displayed The number of reports that are produced by the system The number of modules that must be developed
- 16. END