Formal Approaches to SQA & Statistical SQA

Formal Approaches to SQA:

We have maintained that software quality is everyone’s responsibility and can be attained by applying recognized software engineering standards, formal technical reviews, a multitiered testing strategy, better control over software work products and modifications, and skilled analysis, design, coding, and testing. Furthermore, a wide range of quality characteristics can be used to define quality, and some indices and metrics can be used to quantify it (indirectly).

A tiny but noisy segment of the software engineering community has advocated throughout the past 20 years that a more formal approach to software quality assurance is necessary. One could debate whether or not a computer program qualifies as a mathematical object. Every programming language has strict syntax and semantics that can be specified, and there is also a strict method for defining software requirements. Once the necessary model definition has been rigorously represented, the mathematical precision proficiencies can be utilized to show which program truly complies with the requirements.

You may find a wealth of information about review checklists at the FTR Archive website.

Statistical Software Quality Assurance:

Statistical quality assurance represents the industry-wide trend towards a greater emphasis on quantitative measures of quality. Consider a software engineering organization that gathers defect data for a year to demonstrate this. While software is being created, some of the flaws are discovered. Others come to light after the program’s end users have been granted access. Even though hundreds of distinct errors are found, all of them can be linked to one or more of the following reasons:

• incomplete or erroneous specifications (IES)
• misinterpretation of customer communication (MCC)
• intentional deviation from specifications (IDS)
• violation of programming standards (VPS)
• error in data representation (EDR)
• inconsistent component interface (ICI)
• error in design logic (EDL)
• incomplete or erroneous testing (IET)
• inaccurate or incomplete documentation (IID)
• error in programming language translation of design (PLT)
• ambiguous or inconsistent human/computer interface (HCI)
• miscellaneous (MIS)

To execute statistical SQA, the following steps must be taken:

1. Data regarding software problems is gathered and categorized.
2. Every flaw is investigated to determine its root cause (e.g., failure to meet specifications, mistake in design, breach of standards, inadequate customer communication).
3. Isolate the 20% (the “vital few”) by applying the Pareto principle, which states that 80% of defects may be linked to 20% of all potential causes.
4. Address the issues that led to the faults when a select few crucial causes have been found.

This rather straightforward idea is a significant first step towards the development of an adaptive software engineering process, where errors are introduced and process parts are improved.

It has been demonstrated that statistical quality assurance methods for software significantly increase quality. Software companies have used these strategies to reduce faults by 50% annually in certain instances.

For Example:

Using statistical SQA, the following table is constructed. The table shows that the three most important causes—MCC, EDR, and IES—account for 53% of all errors. However, it should be highlighted that if only major errors are taken into account, then IES, EDR, PLT, and EDL would be chosen as the crucial few causes.

development engineers can compute an error index (EI) for each significant stage in the development process in addition to gathering defect data. The following information is acquired following analysis, design, coding, testing, and release:

• Ei = the total number of errors uncovered during the ith step in the software engineering process.
• Si = the number of serious errors.
• Mi = the number of moderate errors.
• Ti = the number of minor errors.
• PS = size of the product (LOC, design statements, pages of documentation) at the ith step
• ws, wm, wt = weighting factors for serious, moderate, and trivial errors, where recommended values are ws = 10, wm = 3, wt = 1.
• At each step in the software process, a phase index, PIi  is computed:
  PIi = ws (Si/Ei) + wm (Mi/Ei) + wt (Ti/Ei)
• The error-index is computed by calculating the cumulative effect
  on each PIi,
  EI = ∑ (i x PIi)/PS
  EI= (PI1 + 2PI2 + 3PI3 + . . . iPIi)/PS

An overall indicator of an increase in software quality can be created by combining the error index with data gathered from other tables.