Software Estimation Ch-2

7/31/2019 Software Estimation Ch-2

1/22

Software Estimation

The ability to accurately estimate the time

and/or cost taken for a project to come in

to its successful conclusion

It includes size estimation, effort

estimation, duration estimation ,cost

estimation etc


2/22

Size estimation

The project size is a measure of the problem

complexity in terms of the effort and the time

required to develop the project

Two techniques for estimation

LOC(lines of codes)

FPA(function point analysis)


3/22

LOC

This metric measures the size of the project bycounting the number of source instructions in theprogram.

Comments and header lines are ignored.

Accurate LOC count in the beginning of the project isdifficult, one would have to make systemetic guess.

Project managers divide the problem into modules

and each modules into submodules until the sizes ofthe different leaf level modules can be approximatelypredicted.

Past experience is imp here.


4/22

Disadvantage of LOC

It gives a numerical value of problem size that

can vary widely with individual coding style.

Loc is a measure of the coding activity alone.it

ignores design,test etc

It is difficult to estimate LOC from the problem

specification.


5/22

Function Point Analysis(FPA)

It is designed to estimate and measure the time,and thereby the cost, of developing new softwareapplications and maintaining existing softwareapplications.

This is in contrast to the LOC metric, Where thesize can be accurately determined only after theproduct has fully been developed.

The conceptual idea behind the function point

metric is that the size of the software is directlydependant on the number of different functionsor features it supports.


6/22

How is Function Point Analysis done?

Working from the project design specifications, thefollowing system functions are measured(counted):

number of inputs(Each data item input by the useris counted)

number of Output(reports printed,screen outputs,error messages produced etc)

Number of Files(data structure and physical files)

Number of Inquires(are the user command whichrequire specific action by the system)

Number of Interfaces(interfaces used to exchangeinformation with other systems)


7/22

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


8/22

A simple example:

inputs3 simple X 2 = 64 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


9/22

Value Adjustment Factor - The Unadjusted Function Point count is multiplied by the secondadjustment factor called the Value Adjustment Factor. This factor considers the system's technicaland operational characteristics and is calculated by answering 14 questions. The factors are:

1. Data CommunicationsThe data and control information used in the application are sent or received over communicationfacilities.

2. Distributed Data ProcessingDistributed data or processing functions are a characteristic of the application within the applicationboundary.

3. PerformanceApplication performance objectives, stated or approved by the user, in either response or

throughput, influence (or will influence) the design, development, installation and support of theapplication.

4.Heavily Used ConfigurationA heavily used operational configuration, requiring special design considerations, is a characteristicof the application.

5. Transaction RateThe transaction rate is high and influences the design, development, installation and support.

6. On-line Data EntryOn-line data entry and control information functions are provided in the application.

7. End -User EfficiencyThe on-line functions provided emphasize a design for end-user efficiency.


10/22


11/22


12/22

But how long will the project take and howmuch will it cost?

As previously measured, programmers in ourorganization average 18 function points permonth. Thus . . .

197 FP divided by 18 = 11 man-months If the average programmer is paid $5,200 per

month (including benefits), then the [labor]

cost of the project will be . . .11 man-months X $5,200 = $57,200


13/22

COCOMO

It is known as constructive cost model and

was proposed by Boehm in 1981.

According to Boehm,any software

development project can be classified into

three categories based on the development

complexity:organic, semidetached, and

embedded


14/22

Organic:

A development project can be considered of organic type, if the project

deals with developing a well understood application program, the size of the

development team is reasonably small, and the team members are experiencedin developing similar types of projects.

Semidetached:

A development project can be considered of semidetached

type, if the development consists of a mixture of experienced and inexperienced

staff. Team members may have limited experience on related systems but maybe unfamiliar with some aspects of the system being developed.

Embedded:

A development project is considered to be of embedded type, if the

software being developed is strongly coupled to complex hardware, or if the

stringent regulations on the operational procedures exist.

According to Boehm, software cost estimation should be done through

three stages: Basic COCOMO, Intermediate COCOMO, and Complete

COCOMO.


15/22

Basic COCOMO Model

The basic COCOMO model gives an approximate estimate of theproject parameters

The basic COCOMO estimation model is given by the followingexpressions:

Effort = a1*(KLOC)a2 PM

Tdev= b1*(Effort)b2 monthsWhere

KLOC is the estimated size of the software product expressed inKiloLines of Code;

Effort is the total effort required to develop the software

product,expressed in person months (PMs) a1 a2 b1 b2 are constants for each category of software product.

Tdev is the estimated time to develop the software, expressed inmonths,


16/22

For the three classes of software products, the

formulas for estimating the effort based on the

code size are shown below:1) For organic: effort=2.4(KLOC)1.05 PM

2) For semidetached: effort=3.0(KLOC)1.12 PM

3) For embedded: Effort=3.6(KLOC)1.20 PM

Estimation of development time

1)For organic: Tdev= 2.5(effort)0.38 months

2)For semidetached: Tdev= 2.5(effort)0.35 months

3)For embedded: Tdev= 2.5(effort)0.32 months


17/22

Example:

Assume that the size of an organic type

software product has been estimated to be

32,000 lines of source code. Assume that the

average salary of software engineers be Rs.

15,000/- per month. Determine the effort

required to develop the software product andthe nominal development time


18/22

Intermediate COCOMO model

The basic COCOMO model assumes that effortand development time are functions of theproduct size alone. However, a host of other

project parameters besides the product sizeaffect the effort required to develop the productas well as the development time.

Therefore, in order to obtain an accurate

estimation of the effort and project duration, theeffect of all relevant parameters must be takeninto account.


19/22

The intermediate COCOMO model recognizes this fact andrefines the initial estimate obtained using the basicCOCOMO expressions by using a set of cost drivers(multipliers) based on various attributes of software

development. Product related cost drivers:inherent complexity of the

product, reliability requirements of the product, etc.

Computer related cost drivers:execution speed required,storage space required etc.

Personnel related cost drivers:the experience level ofpersonnel, programming capability, analysis capability,etc.

Development Environment related costdrivers:development facilities available to the developers

these different parameters for a particular project on a scale ofone to three.


20/22

Complete COCOMO model

A major shortcoming of both the basic andintermediate COCOMO models is that they consider asoftware product as a single homogeneous entity.

However, most large systems are made up several

smaller sub-systems; These sub-systems may havewidely different characteristics. For example, somesub-systems may be considered as organic type, somesemidetached, and some embedded.

The complete COCOMO model considers these

differences in characteristics of the subsystems andestimates the effort and development time as the sumof the estimates for the individual subsystems


21/22

The cost of each subsystem is estimated

separately. This approach reduces the margin

of error in the final estimate.


22/22

example

The following development project can be considered as anexampleapplication of the complete COCOMO model.

A distributed Management Information System (MIS) product for anorganization having offices at several places across the country can havethe following sub-components:

Database part

Graphical User Interface (GUI) part

Communication part

Of these, the communication part can be considered as embedded software.The

database part could be semi-detached software, and the GUI part organic

software. The costs for these three components can be estimated separately,and summed up to give the overall cost of the system.

Documents

Software Estimation Ch-2