CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2003, Dennis J. Frailey, All...

version 3.09

SMU CSE 8314 / NTU SE 762-N

Software Measurement and Quality Engineering

Module 14Software Reliability

Models - Part 2

version 3.09

Contents• Requirements Volatility• RADC Model• Summary

version 3.09

Requirements Volatility[NOT an IEEE Metric, but Similar]

Goal: Determine the stability of the requirements, so you can decide: – How far you really are in your

development,– How reliable your software is likely to

be, and– What type of process to use for

software development

version 3.09

Requirements VolatilityGeneral Rules of Thumb

• If requirements are stable, use “waterfall” or similar processes

• If requirements are unstable, use incremental or evolutionary development

version 3.09

Requirements VolatilityPrimitive Data Collected

R = # of original requirements– In original specification, for example

C = # of changes to original requirements

A = # of additions to original requirements

D = # of deletions from original requirements

version 3.09

Requirements VolatilityEquation

V = (C + A + D) / R

•Very large V means unstable requirements

•You measure periodically to see if things are stabilizing

version 3.09

Typical Graph of Volatility

1 2 3 4 5 6 7 8 9 10

Volatility

version 3.09

Requirements VolatilityUsage Notes - 1

• In a mature development effort for a production product, V should flatten out in the design phase, indicating stabilization of requirements

• If it continues to rise, it means you have an unstable development and should not be proceeding to later phases yet, unless this is a prototype effort

version 3.09

Requirements VolatilityUsage Notes - 2

• If V is large, the implication is that the current software development effort is really a requirements definition effort, which suggests a prototype, incremental or evolutionary development approach– If intended to be final development, do

not go on to next step of process yet

version 3.09

Requirements VolatilityVariation

T = Number of “TBD” (“to be determined”) requirements in original specification

• This gives you more insight on changes that MUST happen (TBDs)

• It also gives more insight on stability over time

V = (C + A + D + T) / R

version 3.09

Typical Graphs of V

1 2 3 4 5 6 7 8 9 10

With TBDs Without TBDs

version 3.09

You Can Also Learn a Lot by Graphing the Individual Factors of the Equation

R = # of original requirements– In original specification, for example

C = # of changes to original requirementsA = # of additions to original requirementsD = # of deletions from original

requirementsT = # of TBDs

version 3.09

Requirements Volatility Factors

Sample GraphRequirements Volatility

020406080

100120

1 2 3 4 5 6 7 8 9

C A D T R V

version 3.09

Thresholds and Targets• The nature of the development

determines what thresholds should be established

• In a supposedly stable development, thresholds for stability should be very low - instability indicates development effort may be being wasted -- lots of rework ahead

Continued ...

version 3.09

Thresholds and Targets• In a development that is expected

to be volatile, thresholds might be high and targets would be established to determine when stability has been achieved.

• Historical data is essential for establishing reliable thresholds and targets

version 3.09

RADC Measurements

Rome Air Development CenterUS Air Force

Rome Air Force Base

version 3.09

RADC Measurements• These are based on a large amount

of data collected from U.S.A.F. Projects:– 5 million lines of code– 59 projects– Dating back to 1976

• 24 reliability models were studied• Used as the basis for several

government standards

version 3.09

Like IEEE, These Measurements Break the

Process into PhasesPredict

ReliabilityEstimate Reliability

Start Codin

Release Software

Requirements

Design

CodeTest

version 3.09

Background of RADC MeasurementsAssumptions:

– # of faults is fixed at the start of formal test– # of faults correlates to # of failures (failures

are easier to measure and are the things the customer cares about)

Goals:– Get the number of faults as low as possible– Predict number of faults as early as possible– Use Predictions to Manage the Process

version 3.09

Basic Approach to RADC Measurements for Reliability

(one variant)• Each factor that influences reliability is

expressed as a number N 0 < N < 1

N = reliability impact of the individual factorN near 0 means it lowers reliability N near 1 means higher reliability

• The product of all these factors is the net reliability

• Each factor may be defined as the product of other, more detailed factors

version 3.09

RADC Concept

F1 F3F2

F21 F22 F23

R = F1 * F2 * F3

F2 = F21 * F22 * F23

Assumptions: Factors are Bayesian, Independent, Homogeneous

version 3.09

Use of RADC Formula - I• At start of project, you compute R and

use it as the “current reliability prediction”

• As you go through the project, you try to improve the factors represented by the Fis, thus improving the value of R

version 3.09

Use of RADC Formula - II• e.g. if F3 represents programmer

capability and it has a value of 0.6, you could improve it to 0.7 or 0.8 by hiring more capable programmers or by training your staff in defect reduction techniques

• Eventually, you base your values on actual results rather than on predictions

version 3.09

Reliability Expectation Improves Throughout the

Lifecycle

Requirements PreliminaryDesign

Detailed Design Code Test Release

Historical Actual

Estimates, based on Actual Code

Predictions, based on Factors Known at This

Goal (based on Specific

System

version 3.09

Note: The Whole Thing Can Also Be Done in Terms of Other Factors

• Mean time between failures• Probability of failure• Hazard function• Defects, etc.• Regardless of how it is expressed, the

idea is to:– Set goals based on system requirements– Determine the indicators for reliability– Improve early to achieve desired goals

version 3.09

What Factors does RADC Recommend?

• RADC has studied many software development efforts and has developed a recommended set of factors to use

version 3.09

Predicted Reliability

RP = A * D * S

• A, D and S are factors known before you start developing the software

version 3.09

Predicted ReliabilityFactors

A = Application type– Similar to Cocomo estimation model– Worse for embedded, real time, etc.

D = development environment– Tools, turnaround, etc– Personnel capability also included

S = software development methods & process– Factors included for each phase

version 3.09

S = Software Characteristics

S = S1 * S2

version 3.09

S = Software CharacteristicsS1 = Requirements & design methods &

process– Structured Analysis, OO, etc. score higher– Less Formal techniques score lower– Process Management is a Big Factor

S2 = Implementation methods & process– Language– Coding standards– etc.

version 3.09

S1 = Requirements and Design Methods

S1 = SA * ST * SQ

version 3.09

S1 = Requirements and Design Methods

SA = Anomaly management»Corrective action process»Risk tracking and contingency»etc.

ST = Traceability»Ability to trace design to requirements,

etc.SQ = Results of quality reviews

»Number of defects found

version 3.09

SQ = Results of Quality Reviews

Design

Design Inspection

Design Repair

Design Inspection

27 defects

SQ = .6 (too low)

3 defects

SQ = .9 (OK)

to Next Phase

Note: values of SQ shown are illustrations. Actual values depend on size of code, defect definitions.

version 3.09

General Algorithm

Do Somethin

SiToo Low?

YesRedo

version 3.09

S2 = Software Implementation

Methods and Process

S2 = SL * SS * SM * SU * SX * SR

version 3.09

S2 = Software Implementation

Methods and ProcessSL = Language type– Higher order languages are better– Ada better than C due to Discipline, etc.

SS = Program sizeSM = ModularitySU = Extent of reuseSX = McCabe complexity (of Design)SR = Review results (Defects Detected)

version 3.09

Examples of Improving S2

• Reduce design complexity• Reduce number of defects allowed

before exiting a review or inspection• Use a better language• Reuse proven code• Make software more modular

version 3.09

Estimation Measurements(Based on Actual Code)

F = Failure rate during testingT = Test environment (for Software)E = Operational environmentDuring software test:

RE = F * T

During system test:RE = F * E

version 3.09

Rqmts & Design Coding andSoftware Test

Begins

System TestBegins

Release

Diagram of Estimation Measurements

Predictive Measurements

RE = F * T RE = F * E

version 3.09

T = Test Environment

TE = Test Effort -- amount of work spent testing

TM = Test Methods -- sophistication, etc.

TC = Test Coverage -- percent of paths tested, etc.

T = TE * TM * TC

version 3.09

E = Operating EnvironmentEW = Workload

EV = Input Variability

RE = F * E = F * EW * EV

version 3.09

Summary of RADC Measurement Usage - At Start

of Project1) Establish a reliability goal based on the

objectives of the product2) Using organization’s history, characterize

the process in terms of the correlation between expected defect or reliability level and the various RADC parameters

3) Use this information to predict the reliability or defect level and use that information to affect the planning process– e.g. use to decide what language, CASE tools,

version 3.09

Summary of RADC Measurement Usage - During

Project Execution4) Track actuals and compare with

historical data and plans5) Adjust behavior if actuals are

inadequate to meet goals6) Record actuals for future use

version 3.09

Summary• Requirements volatility is easy to

measure early in the project and it can give you a useful prediction of reliability and stability

• RADC and IEEE reliability models use different techniques for different phases of development

• RADC uses facts about the development process to predict reliability

version 3.09

References• Bowen, C., et al., Methodology for Software

Reliability Prediction, RADC-TR-87-171, Vol I & II, Rome Air Development Center, 1987.

• Lyu, Michael R., Handbook of Software Reliability Engineering, IEEE, 1996, Catalog # RS00030. ISBN 0-07-039400-8.

• Musa, John, Software Reliability Engineering: More Reliable Software, Faster Development and Testing, McGraw Hill. ISBN: 0-07-913271-5.

• Xie, M. Software Reliability Modeling, World Scientific, London, 1991. ISBN 981-02-0640-2.

version 3.09

END OFMODULE 14

CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2003, Dennis J. Frailey, All...

Documents

August 13, 2000 CSE 7315 - SW Project Management / Chapter 1 – Software Management Overview Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved

CSE 7315 - SW Project Management / Module 14 - Size Estimating Notes and Reuse Copyright 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M14

January 20, 2000 CSE 7315 - SW Project Management / Chapter 13 – SW Process Maturity, Appraisal & Imp Copyright © 1995-2000, Dennis J. Frailey, All Rights

CSE 7315 - SW Project Management / Module 07 - Software Development Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M07 Slide

Camira - Viccarbe · Cse 34 Cse 30 Cse 07 Cse 16 Cse 35 Cse 33 Cse 18 Cse 36 Cse 27 Cse 03 Cse 44 Cse 25 Cse 05 Cse 29 Cse 45 Cse 31 Cse 14 Cse 32 Cse 46 Cse 13 Cse 26 Cse 02 Cse

Andhra Loyola Institute of Engineering and Technology · 2019. 6. 13. · cse cse cse cse cse cse cse cse cse roll number 14hpia1212 12hpia0507 11hpia0204 1 a0224 1 a0225 1 ... ch

Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M35 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project

CSE 7315 - SW Project Management / Module 25 - Risk Management Overview Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved CSE7315M25 Slide

CSE 8314 - SW Metrics and Quality Engineering Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved CSE8314M01 8/20/2001Slide 1 SMU CSE 8314

CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 Slide

AEROSPACE QUALITY SYSTEMS (AQS) (Susan Frailey, +1 618 …

CSE 7315 - SW Project Management Copyright © 1995-2002, Dennis J. Frailey, All Rights Reserved CSE7315M00 January 12, 2002 Slide 1 SMU CSE 7315 / NTU SE

Green University of BangladeshName: Mst. Isma Khatun Course Code Grade CSE 425 A CSE 431 A CSE 432 A-CSE 400B I CSE 437-CSE(161) C+ CSE 438-CSE(161) ... CSE (Diploma- We Course Code

CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and Negotiation Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M23

Print Tutorial on Earned Value Management Systems - Dennis J Frailey-2003

CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2005, Dennis J. Frailey, All Rights Reserved CSE8314M15 version 5.09Slide 1 SMU CSE

CSE 7315 - SW Project Management / Module 26 - Risk Management Process, In Detail Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M26

CSE 7315 - SW Project Management / Module 1: Process - the Framework of SW Eng Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M01

CSE 7315 - SW Project Management / Module 3 - Product Development Lifecycles Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M03 Slide

Students have to fill webkiosk... · 101704 nancy kondal ... cse cse cse cse cse cse cse cse cse cse cse cse cse ... radha agnihotri 131336 sagar bansal 131342 132210 132219 141215