外文翻译--软件质量保证方法.doc

英文资料翻译WAYS OF SOFTWARE QUALITY ASSURANCE一、Introduction of software quality assuranceEven the most jaded software developers will agree that high-quality software is an important goal. But how do we dene quality? A wag once said, "Every program does something right, it just may not be the thing that we want it to do."Many denitions of software quality have been proposed in the literature. For our purposes, software quality is dened asConformance to explicitly stated functional and performance requirements, explicitly doc-umented development standards, and implicit characteristics that are expected of all pro-fessionally developed software. There is little question that this denition could be modied or extended. In fact, a denitive denition of software quality could be debated endlessly. For the purposes of this book, the denition serves to emphasize three important points:1) Software requirements are the foundation from which quality is measured.Lack of conformance to requirements is lack of quality.2) Specied standards dene 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) A set of implicit requirements often goes unmentioned (e.g., the desire forease of use and good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.1. Background IssuesQuality assurance is an essential activity for any business that produces products to be used by others. Prior to the twentieth century, quality assurance was the sole responsibility of the craftsperson who built a product. The rst formal quality assurance and control function was introduced at Bell Labs in 1916 and spread rapidly throughout the manufacturing world. During the 1940s, more formal approaches to quality control were suggested. These relied on measurement and continuous process improvement as key elements of quality management.Today, every company has mechanisms to ensure quality in its products. In fact, explicit statements of a company's concern for quality have become a marketing ploy during the past few decades.The history of quality assurance in software development parallels the history of quality in hardware manufacturing. During the early days of computing (1950s and 1960s), quality was the sole responsibility of the programmer. Standards for quality assurance for software were introduced in military contract software development during the 1970s and have spread rapidly into software development in the commercial world IEE94. Extending the definition presented earlier, software quality assurance is a "planned and systematic pattern of actions" SCH98 that are required to ensure high quality in software. The scope of quality assurance responsibility might best be characterized by paraphrasing a once-popular automobile commercial: "Quality Is Job #1." The implication for software is that many different constituencies have software quality assurance responsibilitysoftware engineers, project managers,customers, salespeople, and the individuals who serve within an SQA group.The SQA group serves as the customer's in-house representative. That is, the people who perform SQA must look at the software from the customer's point of view.Does the software adequately meet the quality factors noted in Chapter 19? Has software development been conducted according to pre-established standards? Have technical disciplines properly performed their roles as part of the SQA activity? The SQA group attempts to answer these and other questions to ensure that software quality is maintained.2. SQA ActivitiesSoftware quality assurance is composed of a variety of tasks associated with two different constituenciesthe software engineers who do technical work and an SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting. Software engineers address quality (and perform quality assurance and quality control activities) by applying solid technical methods and measures, conducting formal technical reviews, and performing well-planned software testing. Only reviews are discussed in this chapter. Technology topics are discussed in Parts Three through Five of this book.The charter of the SQA group is to assist the software team in achieving a high quality end product. The Software Engineering Institute PAU93 recommends a set of SQA activities that address quality assurance planning, oversight, record keeping,analysis, and reporting. These activities are performed (or facilitated) by an independent SQA group that:1) Prepares an SQA plan for a project. The plan is developed during project planning and is reviewed by all interested parties. Quality assurance activities performed by the software engineering team and the SQA group are governed by the plan. The plan identies: evaluations to be performed audits and reviews to be performed standards that are applicable to the project procedures for error reporting and tracking documents to be produced by the SQA group amount of feedback provided to the software project team2) Participates in the development of the projects software process description. The software team selects a process for the work to be performed. The SQA group reviews the process description for compliance with organizational policy,internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan.3) Reviews software engineering activities to verify compliance with the dened software process. The SQA group identies, documents, and tracks deviations from the process and veries that corrections have been made.4) Audits designated software work products to verify compliance with those dened as part of the software process. The SQA group reviews selected work products; identies, documents, and tracks deviations; veries that corrections have been made; and periodically reports the results of its work to the project manager.5) Ensures that deviations in software work and work products are documented and handled according to a documented procedure. Deviations may be encountered in the project plan, process description, applicable standards, or technical work products. 6) Records any noncompliance and reports to senior management. Noncompliance items are tracked until they are resolved. In addition to these activities, the SQA group coordinates the control and management of change (Chapter 9) and helps to collect and analyze software metrics.二、 SOFTWARE REVIEWSSoftware reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed. Software reviews "purify" the software engineering activities that we have called analysis, design, and coding. Freedman and Weinberg FRE90 discuss the need for reviews this way:Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors, large classes of errors escape the originator more easily than they escape anyone else. The review process is, therefore, the answer to the prayer of Robert Burns:O wad some power the giftie give us to see ourselves as other see us A reviewany reviewis a way of using the diversity of a group of people to:1) Point out needed improvements in the product of a single person or team;2) Confirm those parts of a product in which improvement is either not desired or not needed;3) Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageableMany different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a form of review, if technical problems are discussed. A formal presentation of software design to an audience of customers, management, and technical staff is also a form of review. In this book, however, we focus on the formal technical review, sometimes called a walkthrough or an inspection. A formal technical review is the most effective lter from a quality assurance standpoint. Conducted by software engineers (and others) for software engineers, the FTR is an effective means for improving software quality. 1. Cost Impact of Software DefectsThe IEEE Standard Dictionary of Electrical and Electronics Terms (IEEE Standard 100-1992) denes a defect as “a product anomaly.” The denition for fault in the hardware context can be found in IEEE Standard 610.12-1990:(a) A defect in a hardware device or component; for example, a short circuit or broken wire. (b) An incorrect step, process, or data denition in a computer program. Note: This denition is used primarily by the fault tolerance discipline. In common usage, the terms "error" and "bug" are used to express this meaning. See also: data-sensitive fault; program-sensitive fault; equivalent faults; fault masking; intermittent fault.Within the context of the software process, the terms defect and fault are synonymous. Both imply a quality problem that is discovered after the software has been released to end-users (or to another activity in the software process). In earlier chapters, we used the term error to depict a quality problem that is discovered by software engineers (or others) before the software is released to the end-user (or to another activity in the software process).The primary objective of formal technical reviews is to nd errors during the process so that they do not become defects after release of the software. The obvious benet of formal technical reviews is the early discovery of errors so that they do not propagate to the next step in the software process.A number of industry studies (by TRW, Nippon Electric, Mitre Corp., among others) indicate that design activities introduce between 50 and 65 percent of all errors(and ultimately, all defects) during the software process. However, formal review techniques have been shown to be up to 75 percent effective JON86 in uncovering design aws. By detecting and removing a large percentage of these errors, the review process substantially reduces the cost of subsequent steps in the development and support phases.To illustrate the cost impact of early error detection, we consider a series of relative costs that are based on actual cost data collected for large software projectsIBM81.3 Assume that an error uncovered during design will cost 1.0 monetary unit to correct. Relative to this cost, the same error uncovered just before testing commences will cost 6.5 units; during testing, 15 units; and after release, between 60 and 100 units.2. Defect Amplication and RemovalA defect amplification model IBM81 can be used to illustrate the generation and detection of errors during the preliminary design, detail design, and coding steps of the software engineering process. The model is illustrated schematically in Figure 8.2. A box represents a software development step. During the step, errors maybe inadvertently generated. Review may fail to uncover newly generated errors and errors from previous steps, resulting in some number of errors that are passed through.In some cases, errors passed through from previous steps are amplied (amplication factor, x) by current work. The box subdivisions represent each of these characteristics and the percent of efciency for detecting errors, a function of the thoroughness of the review.Figure 8.3 illustrates a hypothetical example of defect amplication for a software development process in which no reviews are conducted. Referring to the gure, each test step is assumed to uncover and correct 50 percent of all incoming errors without introducing any new errors (an optimistic assumption). Ten preliminary design defects are amplied to 94 errors before testing commences. Twelve latent errors are released to the eld. Figure 8.4 considers the same conditions except that design and code reviews are conducted as part of each development step. In this case, ten initial preliminary design errors are amplied to 24 errors before testing commences.Only three latent errors exist. Recalling the relative costs associated with the discovery and correction of errors, overall cost (with and without review for our hypothetical example) can be established. The number of errors uncovered during each of the steps noted in Figures 8.3 and 8.4 is multiplied by the cost to remove an error (1.5 cost units for design, 6.5 cost units before test, 15 cost units during test, and 67 cost units after release). Using these data, the total cost for development and maintenance when reviews are conducted is 783 cost units. When no reviews are conducted, total cost is 2177 unitsnearly three times more costly. To conduct reviews, a software engineer must expend time and effort and the development organization must spend money. However, the results of the preceding example leave little doubt that we can pay now or pay much more later. Formal technical reviews (for design and other technical activities) provide a demonstrable cost benet. They should be conducted.软件质量保证方法一、软件质量保证介绍即使最疲惫的软件开发者也同意，生产高质量的软件是一个十分重要的目标。但我们将如何定义质量呢？有一个笑话说：“每个程序都能够做好一些事情，不过不是我们希望它做到的那些而已。”文献中对软件质量的定义有很多种。在我们这里对软件质量做如下定义：明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。显然上述定义还可以修改或扩充。实际上，对软件质量的确定性定义可以无限制地争论下去。在本书中，上述定义强调了以下三个重要方面：1) 软件需求是进行“质量”度量的基础。与需求不符就是质量不高。2) 指定的标准定义了一组指导软件开发的准则。如果不能遵照这些准则，就极有可能导致质量不高。3) 通常有一组“隐含需求”是不被提及的(如对易维护性的需求)。如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然值得怀疑。1. 背景对于任何为他人生产产品的企业，质量保证都是必不可少的活动。在20世纪之前，质量保证曾经只由生产产品的工匠承担。第一个正式的质量保证和控制职能于1916年在贝尔实验室出现，此后迅速风靡整个制造行业。在计算机发展的早期(50和60年代)，质量保证曾经只由程序员承担。软件质量保证的标准是70年代首先在军方的软件开发合同中出现的，此后迅速传遍整个商业领域IEE94。在今天，这一定义的含义是在一个组织中有多个机构负有保证软件质量的责任包括软件工程师、项目管理者、客户、销售人员和SQA小组的成员。SQA小组充当客户在公司内部的代表。这就是说，SQA小组的成员必须以客户的观点看待软件。软件是否充分满足第18章中的各项质量因素？软件开发是否依照预先设定的标准进行？作为SQA活动的一部分的技术规程是否恰当的发挥了作用？SQA小组的工作将回答上述的及其他的问题，以确保软件质量得到维护。2. SQA活动软件质量保证由各种任务构成，这些任务分别与两种不同的参与者相关做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。软件工程师通过采用可靠的技术方法和措施、进行正式的技术复审、执行计划周密的软件测试来考虑质量问题(并保证软件质量)。在本章中将只讨论复审问题。本书中的第3到第5部分将讨论有关的技术问题。SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SEIPAU93推荐了一组有关QA活动。这些活动将由一个独立的SQA小组执行(或协助)：1) 为项目准备SQA计划：该计划在制定项目计划时制定，由所有感兴趣的相关部门复审。该计划将控制由软件工程小组和SQA小组执行的质量保证活动。在计划中要标识以下几点(参见图8-5)：·需要进行的评价。·需要进行的审计和复审。·项目可采用的标准。·错误报告和跟踪过程。·由SQA小组产生的文档。·为软件项目组提供的反馈数量。2) 参与开发该项目的软件过程描述软件工程小组为要进行的工作选择一个过程。SQA小组将复审过程说明，以保证该过程与组织政策、内部软件标准、外界所订标准(如ISO 9001)以及软件项目计划的其他部分相符。3) 复审各项软件工程活动、对其是否符合定义好的软件过程进行核实SQA小组识别、记录和跟踪与过程的偏差，并对是否已经改正进行核实。4) 审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实S