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