Chapter Software Quality Assurance

Software Quality Assurance

What is Software Quality?

Simplistically, quality is an attribute of software that

implies the software meets its specification

This definition is too simple for ensuring quality in

software systems

• Software specifications are often incomplete or ambiguous;

• Some quality attributes are difficult to specify;

• Tension exists between some quality attributes, e.

efficiency vs. reliability;

Software Quality

Conformance to explicitly stated functional and performance requirements,

explicitly documented development standards, and implicit characteristics

that are expected of all professionally developed software

• Software requirements are the foundation from which quality is measured.

Lack of conformance to requirements is lack of quality.

• Specified standards define a set of development criteria that guide the manner in

which software is engineered.

If the criteria are not met, lack of quality will almost surely result.

• There is a set of implicit requirements that often goes unmentioned.

If software conforms to its explicit requirements but fails to meet its implicit

requirements, software quality is suspect.

For example, usability, performance, security, and availability;

Software Quality Assurance

To ensure quality in a software product, an organization must have a three-prong

approach to quality management:

• Organization-wide policies, procedures and standards must be established.

• Project-specific policies, procedures and standards must be tailored from the organization-

wide templates.

• Quality must be controlled; that is, the organization must ensure that the appropriate

procedures are followed for each project

Standards exist to help an organization draft an appropriate software quality

assurance plan.

• ISO, e., 9000-

• ANSI/IEEE standards

External entities can be contracted to verify that an organization is standard-

compliant.

SQA Activities

Applying technical methods

• To help the analyst achieve a high quality specification and a high quality design

Conducting formal technical reviews

• A stylized meeting conducted by technical staff with the sole purpose of uncovering quality problems

Testing Software

• A series of test case design methods that help ensure effective error detection

Enforcing standards

Controlling change

• Applied during software development and maintenance

Measurement

• Track software quality and asses the ability of methodological and procedural changes to improve

software quality

Record keeping and reporting

• Provide procedures for the collection and dissemination of SQA information

Advantages of SQA

Software will have fewer latent defects, resulting in

reduced effort and time spent during testing and

maintenance

Higher reliability will result in greater customer

satisfaction

Maintenance costs can be reduced

Overall life cycle cost of software is reduced

Quality Reviews

The fundamental method of validating the quality of a product or a process.

Applied during and/or at the end of each life cycle phase

• Point out needed improvements in the product of a single person or team

• Confirm those parts of a product in which improvement is either not desired or

not needed

• Achieve technical work of more uniform, or at least more predictable, quality

than what can be achieved without reviews, in order to make technical work

more manageable

Quality reviews can have different intents:

• review for defect removal

• review for progress assessment

• review for consistency and conformance

Quality Reviews

RequirementsRequirements Analysis Design Code Testing Maintenance 1x 3-6x 10x 15-70x 40-1000x Specification Review Design Review Code Review Test Review Customer Feedback

Defect Amplification and Removal

0 0 0% 10 4x1 0% 25 27x3 20% 25 Preliminary Design Detailed Design Code/Unit Testing 10 6 4 37 37 10 27 116 94 To integration testing...

Defect Amplification (cont’d)

94 0 50% 0 0 50% 0 0 50% 0 Integration Testing Validation Testing System Testing 94 94 0 94 47 47 47 24 24 24 0 0 12 Latent Errors

Review Checklist for Software Project Planning

####### Is the software scope unambiguously defined and bounded?

####### Is terminology clear?

####### Are resources adequate for the scope?

####### Are resources readily available?

####### Are tasks properly defined and sequenced?

####### Is the basis for cost estimation reasonable? Has it been developed using

####### two different sources?

####### Have historical productivity and quality data been used?

####### Have differences in estimates been reconciled?

####### Are pre-established budgets and deadlines realistic?

####### Is the schedule consistent?

Review Checklist for Software Requirements Analysis

####### Is the information domain analysis complete, consistent, and accurate?

####### Is problem partitioning complete?

####### Are external and internal interfaces properly defined?

####### Are all requirements traceable to the system level?

####### Is prototyping conducted for the customer?

####### Is performance achievable with constraints imposed by other system

####### elements?

####### Are requirements consistent with schedule, resources, and budget?

####### Are validation criteria complete?

Review Checklist for Software Design

(Design Walkthrough)

Does the algorithm accomplish the desired function? Is the algorithm logically correct? Is the interface consistent with architectural design? Is logical complexity reasonable? Have error handling and “antibugging” been specified? Is local data structure properly defined? Are structured programming constructs used throughout? Is design detail amenable to the implementation language? Which are used: operating system or language dependent features? Is compound or inverse logic used? Has maintainability been considered?

Review Checklist for Coding

Is the design properly translated into code? (The results of the procedural

design should be available at this review)

Are there misspellings or typos?

Has proper use of language conventions been made?

Is there compliance with coding standards for language style, comments,

module prologue?

Are incorrect or ambiguous comments present?

Are typing and data declaration proper?

Are physical constraints correct?

Have all items on the design walkthrough checklist been reapplied (as

required)?