Spread Knowledge

CS605 - Software Engineering II - Lecture Handout 30

User Rating:  / 0
PoorBest 

Related Content: CS605 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Engineering II

Statistical Software Quality Assurance

Statistical SQA is a technique that measures the quality in a quantitative fashion. It implies that information about defects is collected and categorized and an attempt is made to trace each defect to underlying cause. It uses Pareto Principle to identify vital causes (80% of defects can be traced to 20% of causes) and moves to correct the problems that have caused the defects.

Example

Let us assume that information about defects is collected for one year and categorized as follows:

  1. Incomplete or erroneous specifications (IES)
  2. Misinterpretation of customer communication (MCC)
  3. Intentional deviation from specifications (IDS)
  4. Violation of programming standards (VPS)
  5. Error in data representation (EDR)
  6. Inconsistent component interface (ICI)
  7. Error in digital logic (EDL)
  8. Incomplete or erroneous testing (IET)
  9. Inaccurate or incomplete documentation (IID)
  10. Error in programming language translation of design (PLT)
  11. Ambiguous or inconsistent HCI (HCI)
  12. Miscellaneous (MIS)

The following data is collected for these categories

Error Category

Serious

Moderate

Minor

Sub Total

IES

34

68

103

205

MCC

12

68

76

156

IDS

1

24

23

48

VPS

0

15

10

25

EDR

26

68

36

130

ICI

9

18

31

58

EDL

14

12

19

45

IET

12

35

48

95

IID

2

20

14

36

PLT

15

19

26

60

HCI

3

17

8

28

MIS

0

15

41

56

 

 

 

 

 

Total

128

379

435

942


We can easily see the following:

    • IES, MCC, and EDR are the vital errors – cause 53% of all errors
    • IES, EDR, PLT, and EDL are vital if only serious errors are considered
    We now start corrective action focused on vital few. For example for EDR we review the data representation techniques to identify the possible improvement areas and adopt a use case tool for data modeling and perform stringent data design reviews.

    Error Index (EI)

    Another statistical technique known as Error Index (EI) is used to develop an overall indication of improvement in software quality. The EI is computed as follows:

    Let

      • Ei – the total number of errors uncovered during the ith step in the SE process
      • Si – number of serious errors
      • Mi – number of moderate errors
      • Ti – number of minor errors
      • PS – product size at the ith step
      • ws, wm, wt – weighting factors for serious, moderate, and minor errors. Recommended values for these are 10, 3, 1 respectively.
      At each step of the software process a Phase Index is computed as:

      Error Index (EI)

      Now EI is computed as the cumulative effect on each PIi = ∑(I x PIi)/PS

      It is important to note that weighting errors encountered in the SE processes more heavily than those encountered earlier. As stated earlier, it can be used to develop an overall indication of improvement in software quality.

      Software Reliability

      Software reliability is another very important quality factor and is defined as probability of failure free operation of a computer program in a specified environment for a specified time. For example, a program X can be estimated to have a reliability of 0.96 over 8 elapsed hours.

      Software reliability can be measured, directed, and estimated using historical and development data. The key to this measurement is the meaning of term failure. Failure is defined as non-conformance to software requirements. It can be graded in many different ways as shown below:
        • From annoying to catastrophic
        • Time to fix from minutes to months
        • Ripples from fixing

        It is also pertinent to understand the difference between hardware and software reliability. Hardware reliability is predicted on failure due to wear rather than failure due to design. In the case of software, there is no wear and tear. The reliability of software is determined by Mean time between failure (MTBF). MTBF is calculated as:

        MTBF = MTTF + MTTR

        Where MTTF is the Mean Time to Failure and MTTR is the Mean time required to Repair.

        Arguably MTBF is far better than defects/kloc as each error does not have the same failure rate and the user is concerned with failure and not with total error count.

        A related issue is the notion of availability. It is defined as the probability that a program is operating according to requirements at a given point in time. It can be calculated as

        Availability = (MTTF/MTBF) x 100

        and clearly depends upon MTTR.