software cost estimation
DESCRIPTION
sceTRANSCRIPT
1
SOFTWARE COST AND SCHEDULE ESTIMATION
Presented By: Deep kumar sharma
Mtech(1st sem)
2
TOPICS COVERED
1. Software Cost components
2. Software productivity
3. Productivity measures
4. Measurement problems
5. Estimation techniques
6. Project scheduling
7. References
3
1.SOFTWARE COST COMPONENTS Travel and training costs
Effort costs (the dominant factor in most projects)
The 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 (eg. library, staff restaurant, etc.)
Hardware and software costs
4
2.SOFTWARE 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
5
3.PRODUCTIVITY MEASURES
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
Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc
6
4.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
7
5.ESTIMATION TECHNIQUES
5.1. SOURCE LINES OF CODE 5.2. FUNCTION POINT ANALYSIS
8
5.1.SOURCE LINES OF CODE LOC is a software metric used to measure the size of a
computer program by counting the number of lines in the text of the program's source code
LOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced
This model assumes that there is a linear relationship between system size and volume of documentation
9
5.1.1.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
10
5.1.2.SYSTEM DEVELOPMENT TIMES
Analysis Design Coding Testing Documentation
Assembly codeHigh-level language
3 weeks3 weeks
5 weeks5 weeks
8 weeks4 weeks
10weeks
6 weeks
2 weeks2 weeks
Size Effort Productivity
Assembly codeHigh-level language
5000 lines1500 lines
28 weeks20 weeks
714 lines/month300 lines/month
11
5.2.FUNCTION POINT ANALYSIS Function point metric is that it can be used to easily
estimate the size of a software product directly from the problem specification
The idea underlying the FP metric is that the size of a software product is directly dependent on the no. of different function or features it support
The function point analysis measure quantities the functionality requested and provided to the user based on the user’s requirements and high level logical design
12
Working from the project design specifications, the following system functions are measured (counted):
Inputs Outputs Files Inquires Interfaces
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
UFP=∑∑ Zij Wij
13
These function-point counts are then weighed (multiplied) by their degree of complexity:
Simple Average Complex
Inputs 2 4 6
Outputs 3 5 7
Files 5 10 15
Inquires 2 4 6
Interfaces 4 7 10
14
A simple example:
inputs3 simple X 2 = 6 4 average X 4 = 161 complex X 6 = 6
outputs6 average X 5 = 302 complex X 7 = 14
files5 complex X 15 = 75
inquiries8 average X 4 = 32
interfaces3 average X 7 = 214 complex X 10 = 40
Unadjusted function points - 240
15
Adjustment factor
Complex internal processing = 3Code to be reusable = 2High performance = 4Multiple sites = 3Distributed processing = 5
Project adjustment factor = 17
Adjustment calculation:Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)] = 240 X [0.65 + (17 X 0.01)] = 240 X [0.82] = 197 Adjusted function points
16
The function point count is modified by complexity of the project
FPs can be used to estimate LOC depending on the average number of LOC per FP for a given languageFP = UFP * CAF
UFP is unadjusted function point
CAF is complexity adjustment factorCAF= 0.65 + 0.01 * ∑ fi
17
6.PROJECT SCHEDULING Split project into tasks (= create a WBS)
Estimate time and resources required to complete each task
Organize tasks concurrently to make optimal use of workforce
Minimize task dependencies to avoid delays caused by one task waiting for another to complete
Dependent on project managers intuition and experience
18
Once tasks (from the WBS) and size/effort (from estimation) are known: then schedule
Primary objectives• Best time• Least cost• Least risk
Secondary objectives• Evaluation of schedule alternatives• Effective use of resources• Communications
19
8.REFERENCES http://www.cfm.va.gov/til/dManual/dmCost.pdf
http://doit.maryland.gov/SDLC/Documents/Cost_Estimating.pdf
http://www.efcog.org/wg/pm_ce/docs/OMBE_Guidelines. pdf
http://www.infosys.com/infosys-labs/publications/Documents/practical-software-estimation.pdf
20