SOFTWARE COST ESTIMATION

• INTRODUCTION• most difficult task in software engineering• difficult to make estimate the cost during planning

phase because of large number of unknown factors in the competitive nature of business.

• preliminary estimate is prepared during planning at the project feasibility review.

• an improved estimate is presented at the software requirements review.

• final estimate is prepared at the preliminary design review.

• Each estimate if the refinement of the previous one.

3.1 SOFTWARE COST FACTORS• programmers ability and their familiarity• Product complexity• Product size• Available time• Required reliability• Level of technology• Availability, familiarity and stability of the

system

3.1.1. Programmer Abilityin chapter1 we discussed experiment on 12 programmers by

sackmamm and his colleagues.• The goal was to determine relative influence of batch and

time shared access on programmer’s productivity• Example: 12 experienced programmer’s were each given

two programming problems to solve batch facilities and time sharing programs.

• Resulting differences in individual performance among the programmers were much greater than could be attributed to the relatively small effect of batch or time shared machine access

• On very large projects the differences in individual programmers ability will tend to average out

• But on projects involving 5 or fewer programmers, individual difference in ability can be significant

• 3.1.2. PRODUCT COMPLEXITY• There are three categories of software products• Application programs -include data processing

and scientific programs• Utility programs -it include Compilers,

assemblers, EDITORS.• System programs -it include operating system,

dbms, real time system• Application programs are developed in

environment provided by the language compilers such as fortran, pascal .

• Interactions with the operating systems are limited.

• Utility programs are written to provide user processing environment. Make sophisticated use of operating systems.

• System programs interact directly with the hardware• Brook’s states that utility programs are three times as

difficult to write as application programs• System programs are three times as difficult to write as

utility programs• Product complexity are 1-3-9 for application, utility,

system programs• Boehm uses three levels of product complexity and

provide equations to predict total programmer month of effort ,PM, In terms of the number of thousands of delivered source instructions ,KDSI

• programmer cost for the software project=the effort in programmer month*cost per Programmer month

• in this terminology the three levels of product complexity are organic, semidetached, embedded

• Organic = application programs• Entity = semidetached programs• Embedded = system programs• application program : PM=2.4*(KDSI)**1.05• utility programs : PM=3.2*(KDSI)**1.12• system programs : PM=3.6*(KDSI)**1.20

• example: for a development of a60,000 line application programs, utility programs and system programs the ratio of pm:1 to 1.7 to 2.8 for the development of 60k line for application program , utility programs, system programs

• The Development time for a program is• Application programs :TDEV=2.5*(pm)**0.38• utility programs TDEV=2.5*(pm)**0.35• system programs TDEV=2.5*(pm)**0.32• Roughly development time is same for all three

types of systems.

• given the total programmer months for a project and the development time the average staffing level is obtained by

• Application program :176.6pm/17.85mo = 9.9programmers

• utility program 294pm/18.3mo=16programmers• System program:489.6pm/18.1mo =

27programmers• failures in estimating the number of source

instructions in a software product is to under estimate the amount of house keeping code required.

• HOUSE KEEPING CODE• It is the portion of the source code that

handles input, output, interactive user communication, error checking and error handling.

• It takes more than 50 or even 90 percent of the source code.

• 3.1.3 PRODUCT SIZE• A large software product is more expensive to

develop than a small one• Boehm equation indicate that the rate of increase in

required effort grows with number of source instruction at an exponential rate greater than 1

• Using exponents of 0.91 and 1.83 results in estimates of 1.88 and 3.5 more effort for a product that is twice as large ,and factors of 8.1 and 67.6 for products that are 10 times as large as known product

• These estimates differ by factors of 1.86(3.5/1.88)for products that are twice as large and 8.3(76.6/8.1) for products that are 10 times as large

• Effort equation Schedule equation Reference• PM=5.2(KDSI)**0.91 TDEV=2.47(PM)**0.35 (WAL77)• PM=4.9(KDSI)**0.98 TDEV=3.04(PM)**0.36 (NEL78)• PM=1.5(KDSI)**1.02 TDEV=4.38(PM)**0.25 (FRE79)• PM=2.4(KDSI)**1.05 TDEV=2.50(PM)**0.38 (BOE81)• PM=3.0(KDSI)**1.12 TDEV=2.50(PM)**0.35 (BOE81)• PM=3.6(KDSI)**1.40 TDEV=2.50(PM)**0.32 (BOE81)• PM=1.0(KDSI)**1.50 - (JON77)• PM=0.7(KDSI)**1.50 - (HAL77)

• Depending on the exponent used we can easily be off by a factor of 2 in estimating effort for a product twice the size of a known product and by a factor of 10 for a product 10 times the size of a known product, even if all other factors tat influence cost remain constant

3.1.4. Available Time• Total project effort is sensitive to the calendar time

available for project completion• Software projects require more total effort, if development

time is compressed or expanded from the optimal time• According to Putnam, project effort is inversely

proportional to the fourth power of the development time E=k/(TD**4)

• This formula predicts zero effort for infinite development time

• Putnam also states that the development schedule cannot be compressed below about 86%of the nominal schedule regardless of the number of people or resources utilized

• Boehm states that “there is a limit beyond which a software project cannot reduce its schedule by buying more personnel and equipment “

3.1.5 Required level of reliability• Reliability - The ability of a program to perform a required

function under stated conditions for a stated period of time

• Reliability can be expressed in terms of1.Accuracy2. Robustness3.Completeness4.Consistency• These characteristics can be built in to a software product• There is a cost associated with different phases to ensure

high reliability• Product failure may cause slightly inconvenience to the

user• While failure of other products may incur high financial

loss or risk to human life

• 3.1.6 Level of Technology• In a software development required project is reflected by1. programming language2. abstract machine3. programming practices4. software tools used• modern programming languages provides additional

features to improve programmer productivity and software reliability. these features include

1. strong type checking2. data abstraction3. separate computation4. exception handling5. Interrupt handling6.Concurrency mechanisms.

• productivity will suffer if programmers must learn a new machine environment as part of the development process

• modern programming practices include the use ofa) systematic analysis and design techniqueb) structure designed notationsc) inspectiond) structured codinge) systematic testingf) program development library• software tools range from elementary tools such as

assemblers, compilers, interactive text editors and DBMs

3.2 cost estimation techniques• software cost estimates are based on past

performance• cost estimates can be made either (i)top down

(ii)bottom up• Top-down: first focus on system level costs such

as computing resources, personnel required to develop the system

• Bottom up: first estimates the cost to develop each module are subsystem.

• These costs are combined to arrive at an overall estimate

• 3.2.1 EXPERT JUDGEMENT• Most widely used cost estimation technique(top down) is

Expert judgment technique • It relies on the experience, background and business sense

of one or more key people in the organization• Eg: an expert might arrive at a cost estimate in a following

manner.i) To develop a process control systemii) It is similar to one that was developed last yr in 10 months

at a cost of one million dollariii) It was a respectable profitiv) The new system has same control functions as the

previous but 25%more control activitiesv) So the time and cost is increased by25%

vi) We will use same computer and controlling devices and many of the same people of the previous system are available to develop the new system

vii) therefore 20% of the estimate is reducedviii) Reuse of the low level code from the previous

reduces the time and cost estimates by 25%ix) The net effect is the reduction of time cost by 20%

This results in estimation of eight lakhs $ and eight months.

x) Small margin of safety so eight lakhs 50,000$ and nine months development time

xi) Advantage: experience

3.2.2 DELPHI COST ESTIMATION• This technique was developed at the rand corporation in 1948

without side effects of group meetings.• This technique can be adapted to software estimation in the

following manner1.A coordinator provides each estimators with system definition

document and a form for recording a cost estimate.2. Estimators study the document and complete their estimates3. they ask questions to the coordinator but they don’t discuss

estimates with one another4. the coordinator prepares and distributes a summary of the

estimators response5. the estimators complete another estimate from the previous

estimates6. the process is iterated for as many as required7. No group discussion is allowed during the entire process

3.2.3 work breakdown structures• A bottom-up estimation tool.• WBS is a hierarchical chart that accounts for

the individual parts of a system• WBS chart can indicate either product

hierarchy or process hierarchy• Product hierarchy identifies the product

components and indicates the manner in which the components are interconnected

• Process hierarchy identifies the work activity and relationship among those activities

• Fig 3.5 a and b show the product and process WBS charts

• Using WBS technique costs are estimated by assigning cost to each individual component in the chart and summing the costs.

• WBS are the most widely used cost estimation techniques

• Advantage: it identify and account for various process and product factors and in making explicit exactly which costs are included in the cost estimate.

3.1.4 Algorithmic cost models• Constructive cost model(COCOMO)• Algorithmic cost estimators compute the estimated cost

of software system as the sum of the costs of the modules and subsystems.

• this model is bottom up estimators.• The constructive cost model (COCOMO)is an algorithmic

cost model described by boehm• In COCOMO model the equation calculates the

programmer month and development schedule are used for the program unit based on the number of delivered source instruction(DSI)

• Effort multipliers are used to adjust the estimate for product attribute, computer attribute, personnel attribute and project attributes.

• The equations and effort multipliers shown in table 3.4 were developed by examining data from 63 project and by using delphi technique

• The COCOMO equation incorporates a number of assumptions.

• for eg. The organic mode (application programs) equation applied in the following type of situation

(i) small to medium size project(ii)familiar application area(iii)stable(iv)in house development effort(v)effort multipliers are used to modify these

assumptions

• The following activities are covered by the estimates

• Covers design through acceptance testing• It includes cost of documentation and

reviews• It includes cost of program manager and

program librarian• The effort estimates excludes planning and

analysis costs, installation and training costs and the cost of secretaries, janitors and computer operators.

• Software project estimated by COCOMO model include the following:

(i) careful definition and validation of requirements is performed by a small number of people

(ii) the requirements remain same throughout the project(iii) Careful definition and validation of architectural design is

performed by small number of people.(iv) detailed design, coding and unit testing are performed in

parallel by groups of programmers working in teams.(v)Integration testing is based on early test planning.(vi) interface errors are mostly found by unit testing and by

inspections (vii) documentation is performed as a part of development

process

• With one example define algorithmic cost estimation using COCOMO b y bohem

• The product to be developed is a 10 KDSI embedded software product for telecommunications processing on a commercially available microprocessor.

• PM=2.8*(10)**1.20=44.4• TDEV=2.5*(44)**0.32=8.4• Effort multipliers are used to adjust the

estimate.

• The effort adjustment factor is 1.17• So PM= 51.9• TDEV=8.8• If the programmers and analyst cost is $6000

per month, the total cost of project personnel• DOLLARS=51.9PM*$6000PER PM=$311,400• COCOMO used to perform sensitivity analysis.• For eg: if less capable programmer may be used

at a cost savings of $1000 oer month, then TDEV=9.7 MONTHS and DOLLARS=$350,760.

• This version of COCOMO is called as Bohem’s intermediate mode.

3.3 STAFFING LEVEL ESTIMATION• the number of personnel required throughout a

software development project is not constant• planning an analysis are performed by a small group

of people• architectural design by a larger or smaller group• detailed design by a larger number of people• implementation and system testing requires the

largest number of people• in 1958 NORDEN observed that research and

development project follows a cycle of planning, design, prototype, development and use with corresponding personnel utilization as in fig 3.6

• Sum of the areas under the curves is approximated by the RAYLEIGH equation as in fig 3.7

• Any particular point on the rayleigh curve represents the number of fulltime equivalent personnel required at the instant in time

• Rayleigh curve is specified by two parameters(i)td-the time at which the curve reaches its

maximum value(ii)k-the total area under the curve(ie) the total

effort required for the project• In 1976 putnam studied 50 army software projects

to determine how rayleigh curve used to describe software life cycle

• From his observation ,rayleigh curve reaches its maximum value td, during system testing and product release for many software products

• From Boehm observation:Rayleigh curve is an accurate estimator of personal requirements for the development cycle from architectural design through implementation and system testing

• FSP=PM(0.15TDEV+0.7t) -(0.15TDEV+0.7t)^2• (0.25(TDEV)^2 0.15(TDEV)^2

3.4 ESTIMATING SOFTWARE MAINTENANCE COSTS• Software maintenance cost requires 40 to 60%of the

total life cycle effort devoted to software product• In some cases it may be 90%• Maintenance activities include1. enhancement to the product2. adapting the product to new processing

environment3. correcting problems a rule of thumb is distribution and maintenance

activities includes enhancement-60%, adaptation-20%,error correction- 20%

• during planning phase of the software project the major concens about the maintenance are

(i) estimating the number of maintenance programmmers that will be needed

(ii) specifying the facilities required for maintenance

• A widely used estimators of maintenance personnel is the number of source lines that can be maintained by an individual programmer

• LIENTZ AND SWANSON OBSERVATION• Maintenance programmers in a business data

processing installations maintains 32K instructions.

• Full time software personnel needed for software maintenance can be determined by dividing the estimated number of source instructions to be maintained by the estimated number of instruction that can be maintained by a maintenance programmer

• For example if a maintenance programmer can maintain 32KDSI then 2 maintenance programmer are required to maintain 64KDSI FSPM=(64KDSI)/(32KDSI/FSP)=2FSPM

• Boehm suggest that maintenance effort can be estimated by use of an activity ratio, which is the number of source instructions to be added and modified in any given time period divided by the total number of instructions

• Step:1 ACT=(DSI added+DSI modified)/DSI total)• The activity ratio is then multiplied by the

number of programmer months required for development in a given time period to determine the number of programmer months required for maintenance in the corresponding time period

• Step :2 PM=ACT*Mmdev• The enhancement is provided by an effort

adjustment factor EAF which recognizes differentiate effort multipliers for maintenance and effort multipliers used for development

• Step:3 PMm=ACT*EAF*Mmdev• Heavy importance on reliability and the use of

modern programming practices during development may reduce the amount of effort required for maintenance

• If less importance on reliability and programming practices during development will increase the difficulty of maintenance