A definition of quality should emphasize three important points: 1.) Software requirements are the foundation from which quality is measured. Lack of conformance to requirement is lack of quality. 2.) Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. 3.) There is a set of implicit requirements that often goes unmentioned (e.g. good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.
Best Practices (3)
- Best Practices for software quality measurement and tracking, including defect tracking
Education and Training (19)
- Courses, seminars, conferences, training products, and resources for learning about software quality.
Experts (37)
updated
- Experts in Software Quality technologies.
FAQs, Glossary, and Acronyms (4)
- Useful resources for finding answers to Frequently Asked Questions (FAQs) and definitions of Software Quality and acronyms.
Literature (4)
- Books, articles, and reports on Software Quality.
Tools (24)
updated
- Resources related to Software Quality tools.
Subtopics of Special Interest
Inspections (9)
- A Software Inspection is a formal review of a work product by the work product owner and a team of peers looking for errors, omissions, inconsistencies, and areas of confusion in the work product. A formal inspection is performed according to established procedures and schedules. A typical inspection includes the following stages: Planning, Overview Meeting (Kickoff), Preparation, Inspection Meeting, Rework, and Follow-up. A formal inspection has well-defined roles for participants, such as moderator, recorder, reader, author, and inspector.
See also DACS Gold Practice href="https://www.goldpractices.com/practices/fi/index.php">Formal Inspections.
Root Cause Analysis (1)
- Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement. [Wikipedia on 4-17-07]
Software Reliability (10)
- Software Reliability is the application of statistical techniques to data collected during system development and operation to specify, predict, estimate, and assess the reliability of software-based systems. "Software Reliability Engineering (SRE) is a standard, proven best practice that makes testing more reliable, faster, and cheaper. It can be applied to any system using software and to frequently-used members of software component libraries."
Statistical Process Control (SPC) (5)
- SPC is about using control charts to manage software development efforts, in order to effect software process improvement. The practitioner of SPC tracks the variability of the process to be controlled. When that variability exceeds the range to be expected from natural causes, one then identifies and corrects assignable causes.
Verification and Validation (10)
- Verification and Validation (V&V) is a series of technical and managerial activities performed by someone other than the developer of a system to improve the quality and reliability of the system and assure the developed product satisfies the user's operational needs. Verification is the assurance that the products of a particular development phase are consistent with the requirements of that phase and preceding phase(s), while validation is the assurance that the final product meets system requirements. V&V can be performed by an outside agency, which is referred to as Independent V&V, or IV&V, or by a group within the organization but not the developer, referred to as Internal V&V. Use of V&V often accompanies testing, can improve quality assurance, and can reduce risk.
DACS Gold Practice Initiative
