外文翻譯--軟件質(zhì)量保證方法

1、.英文資料翻譯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

2、 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 tha

3、t 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) So

4、ftware 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 su

5、rely 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 essentia

6、l 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

7、 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, explic

8、it 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 sol

9、e 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 as

10、surance 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 implicatio

11、n 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 wh

12、o 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 o

13、f 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 S

14、QA 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

15、, 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

16、 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

17、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

18、 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

19、 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 ident

20、ies, 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 deviation

21、s; 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

22、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

23、 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 &q

24、uot;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

25、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 ot

26、her 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 a

27、t 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

28、 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 m

29、ost 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

30、 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 progr

31、am. 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 con

32、text 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

33、 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 ob

34、vious 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

35、 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 subs

36、equent 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 t

37、o 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 detecti

38、on 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

39、 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 e

40、fciency 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 a

41、ll 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

42、 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

43、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

44、 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 m

45、oney. 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.軟件質(zhì)量保證方法一、軟件質(zhì)量保證介紹即使最疲憊的軟件開發(fā)者也同意，生產(chǎn)高質(zhì)量的軟件是一個(gè)十分重要的目標(biāo)。但我們將

46、如何定義質(zhì)量呢？有一個(gè)笑話說(shuō)：“每個(gè)程序都能夠做好一些事情，不過(guò)不是我們希望它做到的那些而已。”文獻(xiàn)中對(duì)軟件質(zhì)量的定義有很多種。在我們這里對(duì)軟件質(zhì)量做如下定義：明確聲明的功能和性能需求、明確文檔化過(guò)的開發(fā)標(biāo)準(zhǔn)、以及專業(yè)人員開發(fā)的軟件所應(yīng)具有的所有隱含特征都得到滿足。顯然上述定義還可以修改或擴(kuò)充。實(shí)際上，對(duì)軟件質(zhì)量的確定性定義可以無(wú)限制地爭(zhēng)論下去。在本書中，上述定義強(qiáng)調(diào)了以下三個(gè)重要方面：1) 軟件需求是進(jìn)行“質(zhì)量”度量的基礎(chǔ)。與需求不符就是質(zhì)量不高。2) 指定的標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則。如果不能遵照這些準(zhǔn)則，就極有可能導(dǎo)致質(zhì)量不高。3) 通常有一組“隱含需求”是不被提及的(如對(duì)易維護(hù)性

47、的需求)。如果軟件符合了明確的需求卻沒有滿足隱含需求，軟件質(zhì)量仍然值得懷疑。1. 背景對(duì)于任何為他人生產(chǎn)產(chǎn)品的企業(yè)，質(zhì)量保證都是必不可少的活動(dòng)。在20世紀(jì)之前，質(zhì)量保證曾經(jīng)只由生產(chǎn)產(chǎn)品的工匠承擔(dān)。第一個(gè)正式的質(zhì)量保證和控制職能于1916年在貝爾實(shí)驗(yàn)室出現(xiàn)，此后迅速風(fēng)靡整個(gè)制造行業(yè)。在計(jì)算機(jī)發(fā)展的早期(50和60年代)，質(zhì)量保證曾經(jīng)只由程序員承擔(dān)。軟件質(zhì)量保證的標(biāo)準(zhǔn)是70年代首先在軍方的軟件開發(fā)合同中出現(xiàn)的，此后迅速傳遍整個(gè)商業(yè)領(lǐng)域IEE94。在今天，這一定義的含義是在一個(gè)組織中有多個(gè)機(jī)構(gòu)負(fù)有保證軟件質(zhì)量的責(zé)任包括軟件工程師、項(xiàng)目管理者、客戶、銷售人員和SQA小組的成員。SQA小組充當(dāng)客戶在公司

48、內(nèi)部的代表。這就是說(shuō)，SQA小組的成員必須以客戶的觀點(diǎn)看待軟件。軟件是否充分滿足第18章中的各項(xiàng)質(zhì)量因素？軟件開發(fā)是否依照預(yù)先設(shè)定的標(biāo)準(zhǔn)進(jìn)行？作為SQA活動(dòng)的一部分的技術(shù)規(guī)程是否恰當(dāng)?shù)陌l(fā)揮了作用？SQA小組的工作將回答上述的及其他的問(wèn)題，以確保軟件質(zhì)量得到維護(hù)。2. SQA活動(dòng)軟件質(zhì)量保證由各種任務(wù)構(gòu)成，這些任務(wù)分別與兩種不同的參與者相關(guān)做技術(shù)工作的軟件工程師和負(fù)責(zé)質(zhì)量保證的計(jì)劃、監(jiān)督、記錄、分析及報(bào)告工作的SQA小組。軟件工程師通過(guò)采用可靠的技術(shù)方法和措施、進(jìn)行正式的技術(shù)復(fù)審、執(zhí)行計(jì)劃周密的軟件測(cè)試來(lái)考慮質(zhì)量問(wèn)題(并保證軟件質(zhì)量)。在本章中將只討論復(fù)審問(wèn)題。本書中的第3到第5部分將討論有關(guān)的

49、技術(shù)問(wèn)題。SQA小組的職責(zé)是輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。SEIPAU93推薦了一組有關(guān)QA活動(dòng)。這些活動(dòng)將由一個(gè)獨(dú)立的SQA小組執(zhí)行(或協(xié)助)：1) 為項(xiàng)目準(zhǔn)備SQA計(jì)劃：該計(jì)劃在制定項(xiàng)目計(jì)劃時(shí)制定，由所有感興趣的相關(guān)部門復(fù)審。該計(jì)劃將控制由軟件工程小組和SQA小組執(zhí)行的質(zhì)量保證活動(dòng)。在計(jì)劃中要標(biāo)識(shí)以下幾點(diǎn)(參見圖8-5)：·需要進(jìn)行的評(píng)價(jià)。·需要進(jìn)行的審計(jì)和復(fù)審。·項(xiàng)目可采用的標(biāo)準(zhǔn)。·錯(cuò)誤報(bào)告和跟蹤過(guò)程。·由SQA小組產(chǎn)生的文檔。·為軟件項(xiàng)目組提供的反饋數(shù)量。2) 參與開發(fā)該項(xiàng)目的軟件過(guò)程描述軟件工程小組為要進(jìn)行的工作選擇

50、一個(gè)過(guò)程。SQA小組將復(fù)審過(guò)程說(shuō)明，以保證該過(guò)程與組織政策、內(nèi)部軟件標(biāo)準(zhǔn)、外界所訂標(biāo)準(zhǔn)(如ISO 9001)以及軟件項(xiàng)目計(jì)劃的其他部分相符。3) 復(fù)審各項(xiàng)軟件工程活動(dòng)、對(duì)其是否符合定義好的軟件過(guò)程進(jìn)行核實(shí)SQA小組識(shí)別、記錄和跟蹤與過(guò)程的偏差，并對(duì)是否已經(jīng)改正進(jìn)行核實(shí)。4) 審計(jì)指定的軟件工作產(chǎn)品、對(duì)其是否符合定義好的軟件過(guò)程中的相應(yīng)部分進(jìn)行核實(shí)SQA小組對(duì)選出的產(chǎn)品進(jìn)行復(fù)審；識(shí)別、記錄和跟蹤出現(xiàn)的偏差、對(duì)是否已經(jīng)改正進(jìn)行核實(shí)、定期將工作結(jié)果向項(xiàng)目管理者報(bào)告。5) 確保軟件工作及工作產(chǎn)品中的偏差已被記錄在案，并根據(jù)預(yù)定規(guī)程進(jìn)行處理偏差可能出現(xiàn)在項(xiàng)目計(jì)劃、過(guò)程描述、采用的標(biāo)準(zhǔn)或技術(shù)工作產(chǎn)品中。6

51、) 記錄所有不符合的部分，并報(bào)告給高級(jí)管理者不符合的部分將受到跟蹤直至問(wèn)題得到解決。除進(jìn)行上述活動(dòng)之外，SQA小組還需要協(xié)調(diào)變化的控制和管理(參見第9章)，并幫助收集和分析軟件度量信息。二、軟件復(fù)審軟件復(fù)審是軟件工程過(guò)程中的“過(guò)濾器”。復(fù)審被用于軟件開發(fā)過(guò)程中的多個(gè)不同的點(diǎn)上，起到發(fā)現(xiàn)錯(cuò)誤(進(jìn)而引發(fā)排錯(cuò)活動(dòng))的作用。軟件復(fù)審起到的作用是“凈化”分析、設(shè)計(jì)和編碼中所產(chǎn)生的軟件工作產(chǎn)品。Freedman和Weinberg在FRE90中對(duì)復(fù)審的討論如下：技術(shù)工作需要復(fù)審的理由就象鉛筆需要橡皮“人非圣賢，孰能無(wú)過(guò)”。我們需要復(fù)審的第二個(gè)理由是：盡管人善于發(fā)現(xiàn)自己的某些錯(cuò)誤，但是犯錯(cuò)誤的人自己對(duì)許多種錯(cuò)誤的發(fā)現(xiàn)能力遠(yuǎn)小于其他的人。因此復(fù)審過(guò)程正好回答了Robert Burns的祈禱者的祈求：“賜予我們力量吧！讓我們能夠像別人看我們那樣看我們自己”一次復(fù)審(任何復(fù)審)是一種借助一組人的差異性來(lái)達(dá)到目的的方法：1) 指出一個(gè)人或小組生產(chǎn)的產(chǎn)品所需進(jìn)行的改進(jìn)。2) 確定產(chǎn)品中不需要或者不希望改進(jìn)的部分。3) 得到與沒有進(jìn)行復(fù)審相比更加一致、或者至少更可預(yù)測(cè)的技術(shù)工作的質(zhì)量，從而使得技術(shù)工作更易于管理。在軟件工程過(guò)程中可以進(jìn)行的復(fù)審有許多種，它們各有用處。在咖啡機(jī)旁討論技術(shù)問(wèn)題的非正式會(huì)議是一種復(fù)審；將