2.8 Software quality management  (Page 8/11)

• Find anomalies
• Improve the software product
• Consider alternative implementations
• Evaluate conformance to standards and specifications

The walk-through is similar to an inspection but is typically conducted less formally. The walk-through is primarily organized by the software engineer to give his teammates the opportunity to review his work, as an assurance technique.

Audits

The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures. The audit is a formally organized activity, with participants having specific roles, such as lead auditor, another auditor, a recorder, or an initiator, and includes a representative of the audited organization. The audit will identify instances of nonconformance and produce a report requiring the team to take corrective action.

While there may be many formal names for reviews and audits such as those identified in the standard (see IEEE1028- 97), the important point is that they can occur on almost any product at any stage of the development or maintenance process.

Practical considerations

Software quality requirements

Influence factors

Various factors influence planning, management, and selection of SQM activities and techniques, including:

• The domain of the system in which the software will reside (safety-critical, mission-critical, business-critical)
• System and software requirements
• The commercial (external) or standard (internal) components to be used in the system
• The specific software engineering standards applicable
• The methods and software tools to be used for development and maintenance and for quality evaluation and improvement
• The budget, staff, project organization, plans, and scheduling of all the processes
• The intended users and use of the system
• The integrity level of the system

Information on these factors influences how the SQM processes are organized and documented, how specific SQM activities are selected, what resources are needed, and which will impose bounds on the efforts.

Dependability

In cases where system failure may have extremely severe consequences, overall dependability (hardware, software, and human) is the main quality requirement over and above basic functionality. Software dependability includes such characteristics as fault tolerance, safety, security, and usability. Reliability is also a criterion which can be defined in terms of dependability (ISO9126).

The body of literature for systems must be highly dependable (“high confidence” or “high integrity systems”). Terminology for traditional mechanical and electrical systems which may not include software has been imported for discussing threats or hazards, risks, system integrity, and related concepts, and may be found in the references cited for this section.

Integrity levels of software

The integrity level is determined based on the possible consequences of failure of the software and the probability of failure. For software in which safety or security is important, techniques such as hazard analysis for safety or threat analysis for security may be used to develop a planning activity which would identify where potential trouble spots lie. The failure history of similar software may also help in identifying which techniques will be most useful in detecting faults and assessing quality.