COCOMO-II contd------

Economies of scale :a proportionate saving in costs gained by an increased level of

production

If B < 1.0, the project exhibits economies of scale. If the product's size is
doubled, the project effort is less than doubled. The project's
productivity increases as the product size is increased.
If B = 1.0, the economies and diseconomies of scale are in balance. This
linear model is often used for cost estimation of small projects. It is
used for the COCOMO II Applications Composition model.
If B > 1.0, the project exhibits diseconomies of scale. This is generally
due to two main factors: growth of interpersonal communications
overhead and growth of large-system integration overhead.
Best example
• Wal-Mart's "everyday low prices" are due to its huge buying power.
Managerial economies of scale occur when large firms can afford so
much buying at giving u at low cost.
 Early Design Level
Estimates made after requirements confirmed
PM = A × Size B × M + π ( i=1 to n )EM i

where:
A = 2.5 in initial calibration
n = Size in KLOC
B= varies from 1.1 to 1.24 depending on novelty of project, development
flexibility, risk management approaches, and process maturity
EM = (ASLOC × (AT / 100) ) / ATPROD
M = PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED

ASLOC = size of adapted components.

AT = percent of components adapted.
ATPROD = Automatic Translation Productivity.
Post Architectural Model
• Uses same effort formula as early design estimates
• Estimate of size adjusted to account for:
¨ Requirements volatility ( RV)
¨ Rework required to support change
¨ Extent of possible reuse
ESLOC = ASLOC x (AA + SU +0.4DM + 0.3CM + 0.3IM) / 100
• ESLOC is equivalent number of lines of new code

• ASLOC is the adjusted number of lines of reusable code which must be modified

• DM is the % of design modified

• CM is the % of the code that is modified

• IM is the % of the original integration effort required for integrating the reused software

• SU is a factor based on the cost of software understanding

• AA is a factor which reflects the initial assessment costs of deciding if software may be reused
COCOMO-II Manual
• http://www.dmi.usherb.ca/~frappier/IFT721/COCOMOII.PDF
 Reliability Metrics/Issues

Reliability metrics are used to quantitatively express the reliability of the software
product.
1. Mean Time to Failure (MTTF): MTTF is described as the time interval

between the two successive failures. An MTTF of 200 mean that one

failure can be expected each 200-time units.

To measure MTTF, we can evidence the failure data for n failures. Let

the failures appear at the time instants t1,t2.....tn.

MTTF can be calculated as

2. Mean Time to Repair (MTTR)
Once failure occurs, some-time is required to fix the error. MTTR measures the
average time it takes to track the errors causing the failure and to fix them.

3. Mean Time Between Failure (MTBR)

We can merge MTTF & MTTR metrics to get the MTBF metric.

MTBF = MTTF + MTTR

Thus, an MTBF of 300 denoted that once the failure appears, the next failure
is expected to appear only after 300 hours.
3. Rate of occurrence of failure (ROCOF): ROCOF is the frequency of occurrence

with which unexpected role is likely to appear. A ROCOF of 0.02 mean that two

failures are likely to occur in each 100 operational time unit steps.

4. Probability of Failure on Demand (POFOD)

POFOD is the possibility that the system will fail when a service request is made.

A POFOD of 0.1 means that one out of ten service requests may fail.
• An availability of 0.995 means that in every 1000 time units, the

system is feasible to be available for 995 of these. If a system is down

an average of four hours out of 100 hours of operation, its AVAIL is

96%.