Software Quality

See accompanying Word file

“Software quality 1”

Successful projects

• Successful software projects should be completed on time, within budget, with all required functionality, and be of acceptable quality.

• But, what is software quality?

• There is no single unambiguous definition.

Software quality : 6 features

• Low levels of defects when deployed, ideally approaching zero defects

• High reliability, or the capability of running without crashes or strange results

• A majority of clients with high user-satisfaction when surveyed

• A structure that can minimise bad fixes or insertion of new defects during repairs

• Effective customer support when problems do occur• Rapid repairs for defects especially for high-severity defects

Software defect origins: 6 sources

• Requirements

• Design

• Source code

• User manuals or training material

• Bad fixes or mistakes made during repairs

• Flawed test cases used by the application

Nothing new …

• IBM developed an automated software defect reporting system in the early 1960s that accumulated data on:

the numbers of software defects found; the severity levels of reported defects; whether the bugs were found by means of reviews,

inspections, tests, or by customers; and whether the defects entered the application from

requirements, design, code, manuals, or whether they were secondary defects caused by “fixes”

Conclusions 1:

Front-end requirements and design problems outnumber coding problems

Coding errors in large systems tend to clump in "error-prone modules."

Formal inspections are more efficient than testing to find software bugs.

Secondary "bad fixes" can be very troublesome unless controlled.

Test cases and test libraries are often buggy themselves.

Conclusions 2:

High quality leads to short schedules and low development costs.

Lines of code metrics don't work for cross-language comparisons.

Function point metrics are the best choice for software quality research.

Function point metrics can measure non-code software defect levels.

Poor Software Quality: Root causes

• Inadequate training of managers and staff

• Inadequate defect and cost measurement

• Excessive schedule pressure

• Insufficient defect removal

• High complexity levels

• Ambiguous and creeping requirements and designs

Software Defects:Elimination Strategies

• Methods and tools that lead to the achievement of:

• Effective defect prevention

• High levels of defect removal efficiency

• Accurate defect prediction before the project begins

• Accurate defect tracking during development

• Useful quality measurements

• Ensuring high levels of user-satisfaction

Quality declines as size goes up

• Jones addresses software in the sizes: • 1 function point or 125 C statements

• 10 function points or 1,250 C statements

• 100 function points of 12,500 C statements

• 1,000 function points or 125,000 C statements

• 10,000 function points or 1,250,000 C statements

• 100,000 function points or 12,500,000 C statements

Size rule

• A general rule for predicting software defect potentials is to take the size of the application in function points and raise it to the 1.25 power.

• This simple algorithm will provide a rough estimate of the minimum sum of all problems or bugs in requirements, design, code, user manuals, and bad fixes.

Size rule: consequences

• Applying this algorithm to the six size ranges quickly illustrates why quality control is progressively more important as overall software size gets larger:

for a small application of 100 function points, the defect potential is only about 316 bugs;

for a large system of 10,000 function points, the defect potential is an alarming 100,000.