Scribd Logo
Upload

Welcome to Scribd!

  • 15 views

    SE - Cocomo-III

    Uploaded by

    TUSHAR NAMA
    The document discusses COCOMO-II, an algorithm for estimating software development effort. It describes the effort formula used by COCOMO-II and factors that influence estimates like project novelty, risk, and process maturity. It also discusses how COCOMO-II accounts for reuse and modifications in post-architectural estimates.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    SE - Cocomo-III

    Uploaded by

    TUSHAR NAMA
    15 views21 pages
    The document discusses COCOMO-II, an algorithm for estimating software development effort. It describes the effort formula used by COCOMO-II and factors that influence estimates like project novelty, risk, and process maturity. It also discusses how COCOMO-II accounts for reuse and modifications in post-architectural estimates.

    Original Title

    6. SE_Cocomo-III

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses COCOMO-II, an algorithm for estimating software development effort. It describes the effort formula used by COCOMO-II and factors that influence estimates like project novelty, risk, and process maturity. It also discusses how COCOMO-II accounts for reuse and modifications in post-architectural estimates.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    15 views21 pages

    SE - Cocomo-III

    Uploaded by

    TUSHAR NAMA
    The document discusses COCOMO-II, an algorithm for estimating software development effort. It describes the effort formula used by COCOMO-II and factors that influence estimates like project novelty, risk, and process maturity. It also discusses how COCOMO-II accounts for reuse and modifications in post-architectural estimates.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 21

    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%.

    You might also like