Software Quality Management
The notion of "quality" is not as simple as it may seem. For any engineered product, there are many desired qualities relevant to a particular project. The section explains software quality fundamentals, including the main SQM processes: quality assurance, verification, validation, review, and audit.
Software Quality Requirements
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.
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.