Software Quality Assurance in the software life-cycle [Juran et al 1979] defines Quality Assurance (QA) as: "the activity of providing all concerned the evidence needed to establish confidence that the quality function is being performed adequately". Building on this, [IEEE 1983] defines software quality assurance as: "a planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirement". QA techniques have been applied for many years in traditional manufacturing industries. Central to these techniques is measurement. We measure the quality of the product produced and use that information to improve the process producing it. This is the cornerstone of Statistical Process Control proposed by W Edwards Deming and used with dramatic success by the Japanese over the last 40 years. It is therefore not surprising that the Japanese have been recent pioneers in applying these same QA techniques to develop software. Yet, despite these observations, this central role of measurement in software QA is extremely rare in most software development organisations. This can be gauged from [Perry 1987] who reported on the results of a major study of software QA managers that found the following overall ranking of QA responsibilities in order of importance: Certifying systems prior to production status Enforcing data processing standards Reviewing and certifying development and documentation Developing system and programming standards Reviewing system design for completeness Reviewing systems maintenance/change control Testing of new or modified software Developing control standards Training QA managers clearly recognised that measurement had a role to play (the item which came second was essentially concerned with data-collection) but it was seen as one of many specialist activities rather than one which underpinned the entire QA process. More often than not software QA is considered to be the collective term for a set of vaguely defined activities for which most people do not even recognise any measurement obligation. These activities include the following which we have grouped by the traditional life-cycle: Requirements phase QA: Determine feasibility; Estimate and assign resources, Set quality goals Specification and design phase QA: Document inspections and reviews Implementation phase QA: Validation, Verification and Testing; Deciding when to ship Maintenance and project review phase QA: Root cause analysis of defects; Project audit; Process improvement planning Some activities actually take place at more phases than indicated. For example, estimating and assigning resources needs to be continually reviewed as a project develops, quality goals can be set for each subsequent phase, and inspections and reviews can be applied to any project document (ranging from an initial requirements specification through to the source code and maintenance plan). Data collection is, of course, common to all life-cycle phases but we do not regard it as a separate activity except in the sense of certain management procedures which must be followed in order to use measurement effectively. In subsequent sections we define a framework for software QA that is based on measurement since we believe that this is the key to an effective QA procedure. Next section - software metrics in the QA life-cycle

[papers/_private/copyright_notice.html]

Last modified: July 28, 1999.