【文章內(nèi)容簡(jiǎn)介】 excellence of a software product difficult to assess is the elusive nature of software quality． Boehm et al．（ 1978） suggest that quality criteria include but are not limited to： Economy Correctness Resilience Integrity Reliability Usability Documentation Modifiability Clarity Understandability Validity Maintainability Flexibility Generality Portability Interoperability Testability Efficiency Modularity Reusability Exactly how some of these criteria may be quantified is not clear． Furthermore， as Buckley and Poston（ 1984） point out， parts of this definition may have no value for a particular product． It may be possible to transfer a system from a microputer to a large mainframe but this is often a nonsensical thing to do． Assessment of software quality thus still relies on the judgement of skilled individuals although this does not mean that it is necessarily inferior to quantitative assessment． After all， we cannot assess a painting or a play quantitatively yet this does not preclude a judgement of its quality． Within an anization， quality assurance should be carried out by an independent software quality assurance team who reports directly to management above the project manager level． The quality assurance team should not be associated with any particular development group but should be responsible for quality assurance across all project groups in an anization． The activity of quality assurance involves sitting in on design reviews[7]， program walkthroughs，etc. ， and reporting on the overall quality of the product as it is developed． It also involves checking that the finished product and its associated documentation conform to those standards which exist． The quality assurance team may also assess if the different representations of a product（ requirements， design， code） are consistent and plete． Notice that quality assurance is not the same as system testing． It is the development or testing team’s responsibility to validate the system， with the quality assurance team reporting on both the validation and the adequacy of the validation effort． This naturally involves quality assurance being closely associated with the final integration testing of the system． Software quality assurance is now an emerging subdiscipline of software engineering[8]． As Buckly and Poston point out， effective software quality assurance is likely to lead to an ultimate reduction in software costs． However， the major hurdle in the path of software management in this area is the lack of usable software standards． The development of accepted and generally applicable standards should be one of the principal goals of research in software engineering． NOTES [1] carried out... 分詞短語(yǔ)修飾 activities。 [2] with quality assurance... development 介詞 with 引導(dǎo)的獨(dú)立分詞結(jié)構(gòu)，起補(bǔ)充說明的作用。 [3] 主句謂語(yǔ)是 consists of，其賓語(yǔ)為分詞短語(yǔ)修飾的 procedures， techniques， and tools。 [4] of course：插入語(yǔ)，譯為 “當(dāng)然 ”。 [5] 此句包括兩個(gè)定語(yǔ)從句：第一個(gè)定語(yǔ)從句 which defines 中 which 指 representation；第二個(gè)定語(yǔ)從句 which the developed 修飾 performance， robustness， anization。 [6] Ada 語(yǔ)言（一種程序設(shè)計(jì)語(yǔ)言，以 Agusta Ada Byron 命名）； PDL：程序設(shè)計(jì)語(yǔ)言。 [7] sitting in on design reviews：列席設(shè)計(jì)評(píng)審會(huì)議。 上學(xué)吧（ ） 第 9 頁(yè)，共 64 頁(yè) 上學(xué)吧為您提供“ 軟件 設(shè)計(jì)師 ” 資料下載： [8] emerging subdiscipline of... ： ……的新興分支。 KEYWORDS software quality assurance 軟件質(zhì)量保證 software standard 軟件標(biāo)準(zhǔn) 翻譯 : 軟件質(zhì)量保證活動(dòng)與軟件生存周期各階段的驗(yàn)證和有效性確認(rèn)活動(dòng)緊密關(guān)聯(lián) 。事實(shí)上，在許多組織中這些活動(dòng)沒有明顯的區(qū)別。盡管如此，質(zhì)量保證實(shí)際上與其他驗(yàn)證和有效性確認(rèn)活動(dòng)相差甚遠(yuǎn)，質(zhì)量保證是一個(gè)管理功能，而驗(yàn)證和有效性確認(rèn)是軟件開發(fā)過程的一部分。 Bersoff（ 1984）給出了軟件質(zhì)量保證的恰當(dāng)定義：質(zhì)量保證由在產(chǎn)品開發(fā)周期中專業(yè)人員要確保產(chǎn)品達(dá)到或超過某些預(yù)先設(shè)定的標(biāo)準(zhǔn)所要用到的那些過程、技術(shù)和工具所組成。如果沒有具體的規(guī)定性的標(biāo)準(zhǔn)，質(zhì)量保證則需要保證產(chǎn)品達(dá)到或超過工商業(yè)可接受的優(yōu)良性能的最低標(biāo)準(zhǔn)。 當(dāng)然這是一種相當(dāng)籠統(tǒng)的定義。它首先指出軟件標(biāo)準(zhǔn)可以建立；其次軟件產(chǎn)品 的優(yōu)良程度可以評(píng)測(cè)。 軟件工程項(xiàng)目標(biāo)準(zhǔn)的開發(fā)是一個(gè)非常困難的過程。一個(gè)標(biāo)準(zhǔn)是一個(gè)產(chǎn)品的某種抽象表示，它定義了被開發(fā)產(chǎn)品必須達(dá)到的最低性能、健壯性、結(jié)構(gòu)等。在寫此文章時(shí)，一些軟件產(chǎn)品標(biāo)準(zhǔn)已經(jīng)由 IEEE， ANSI 和一些軍事機(jī)構(gòu)制定了。 這些標(biāo)準(zhǔn)描述了配置管理計(jì)劃、文檔、規(guī)范實(shí)施、軟件對(duì)照等。其他一些處于開發(fā)階段的標(biāo)準(zhǔn)包括可靠性、測(cè)量方法、 Ada 用作為程序設(shè)計(jì)語(yǔ)言、軟件測(cè)試和其他方面的標(biāo)準(zhǔn)。Bransta 和 Powell（ 1984）描述了已有的和已規(guī)劃的軟件標(biāo)準(zhǔn)，用更概括的語(yǔ)言討論了標(biāo)準(zhǔn)化問題。 軟件的 國(guó)家標(biāo)準(zhǔn)問題在于這些標(biāo)準(zhǔn)過于籠統(tǒng)，這是必然的，因?yàn)椴幌裼布?，我們至今尚不能將大多?shù)軟件特性進(jìn)行量化。因此有效的質(zhì)量保證就要求開發(fā)更多特定的組織標(biāo)準(zhǔn)。 當(dāng)然，為質(zhì)量保證而開發(fā)軟件標(biāo)準(zhǔn)所帶來的問題及軟件產(chǎn)品的優(yōu)良程度難于評(píng)估是軟件質(zhì)量難以把握的本質(zhì)。 Boehm 等人（ 1978）提出的質(zhì)量準(zhǔn)則包括但不局限于： 經(jīng)濟(jì)性 正確性 彈性 完整性 可靠性 可使用性 文檔 可修改性 明晰性 易理解性 合法性 可維護(hù)性 靈活性 通用性 可移植性 互操作性 可測(cè)試性 效率 模塊性 可重用性 如何精確量化其中的某些準(zhǔn)則尚不清楚。而且，正如 Buckley 和 Poston（ 1984）指出的那樣，此定義的某些部分對(duì)特定產(chǎn)品也許毫無價(jià)值。把一個(gè)系統(tǒng)從一臺(tái)微機(jī)移到一臺(tái)大型機(jī)上是可能的，但這樣做往往是毫無用處的。因此，軟件質(zhì)量的評(píng)估仍然依賴于熟練的個(gè)人判斷。盡管這并不意味著此方法一定比定量評(píng)估差。盡管我們不能定量地評(píng)價(jià)一幅畫或一場(chǎng)演出，但這畢竟不能阻止對(duì)其質(zhì)量的判斷。 在一個(gè)組織內(nèi)，質(zhì)量保證應(yīng)由一個(gè)獨(dú)立的軟 件質(zhì)量保證小組來實(shí)施，該小組直接向項(xiàng)目經(jīng)理層之上的管理層報(bào)告。質(zhì)量保證小組不應(yīng)與任何開發(fā)小組有聯(lián)系，但要對(duì)本組織中所有的項(xiàng)目組的質(zhì)量保證負(fù)責(zé)。 質(zhì)量保證活動(dòng)包括旁聽設(shè)計(jì)復(fù)審、程序走查等，并報(bào)告開發(fā)過程中產(chǎn)品的整體質(zhì)量。質(zhì)量保證也包括檢查已完成產(chǎn)品及其有關(guān)的文件說明是否與現(xiàn)有標(biāo)準(zhǔn)一致。質(zhì)量保證小組也可以評(píng)估一件產(chǎn)品的不同表示方式（需求、設(shè)計(jì)、代碼）是否一致和完備。 注意，質(zhì)量保證不同于系統(tǒng)測(cè)試。系統(tǒng)有效性確認(rèn)是開發(fā)或測(cè)試小組的責(zé)任，而質(zhì)量保證小組要報(bào)告確認(rèn)和確認(rèn)工作是否充分。這自然意味著質(zhì)量保證與系統(tǒng) 最后階段的綜合測(cè)試有著密切的聯(lián)系。 軟件質(zhì)量保證正成為軟件工程的一個(gè)新興分支。正如 Buckley 和 Poston 所指出的，有 上學(xué)吧（ ） 第 10 頁(yè)，共 64 頁(yè) 上學(xué)吧為您提供“ 軟件 設(shè)計(jì)師 ” 資料下載： 效的軟件質(zhì)量保證很可能導(dǎo)致軟件費(fèi)用的最終降低。然而，在這一領(lǐng)域中軟件管理的最主要障礙是缺乏適用的軟件標(biāo)準(zhǔn)。為人們所接受和普遍適用的標(biāo)準(zhǔn)的開發(fā)應(yīng)成為軟件工程研究的一個(gè)主要目標(biāo)。 軟件需求模式之領(lǐng)域和基礎(chǔ)架構(gòu) 一些類型的需求依賴于基礎(chǔ)架構(gòu)，就像錯(cuò)誤！未找到引用源。錯(cuò)誤！未找到引用源。中“錯(cuò)誤！未找到引用源。 “中討論的。需求模式使我們有機(jī)會(huì)確定一種類型的需求所依賴的基礎(chǔ)架構(gòu)，而不 必為某一個(gè)需求考慮。而且我們可以進(jìn)一步討論每一個(gè)基礎(chǔ)架構(gòu) ——也就是當(dāng)為系統(tǒng)需要的基礎(chǔ)架構(gòu)定義需求時(shí)必須記住的。但是它不可能非常詳細(xì)，也不可能針對(duì)實(shí)際的需求，因?yàn)槊總€(gè)組織，每個(gè)系統(tǒng)的不同要求，會(huì)使需求差別極大。為了清楚起見，它們被稱作基礎(chǔ)架構(gòu)概述。 不能指望讓每一個(gè)需求模式描述它需要的任何基礎(chǔ)架構(gòu)，這個(gè)解釋的責(zé)任被給予了模式所屬的領(lǐng)域。這是因?yàn)槊總€(gè)基礎(chǔ)架構(gòu)一般都會(huì)被領(lǐng)域中的多個(gè)模式使用。為了避免重復(fù)，每種基礎(chǔ)架構(gòu)只在一個(gè)領(lǐng)域中描述。本書中的每一章的模式中包含一節(jié)關(guān)于該領(lǐng)域的基礎(chǔ)架構(gòu)。本書討論了三個(gè)基礎(chǔ)架構(gòu) ：信息存儲(chǔ)（錯(cuò)誤！未找到引用源。錯(cuò)誤！未找到引用源。），用戶界面，以及報(bào)表（都在錯(cuò)誤！未找到引用源。錯(cuò)誤！未找到引用源。）。這幾個(gè)關(guān)鍵概念的相互關(guān)系如圖所示。 Domain: 領(lǐng)域 Infrastructure: 基礎(chǔ)架構(gòu) Requirement Pattern: 需求模式 Depends Upon: 依賴 圖 32 領(lǐng)域，需求模式，以及基礎(chǔ)架構(gòu)之間的關(guān)系 需求模式可以自由使用其他領(lǐng)域中的基礎(chǔ)架構(gòu)。但是最好避免相互依賴，所以如果一個(gè)領(lǐng)域依賴另一個(gè)領(lǐng)域，那么后一個(gè)領(lǐng)域就不應(yīng)該依賴前一個(gè)領(lǐng)域 ——如果可以避免的話。一個(gè)基礎(chǔ)架構(gòu)也可以依賴另一個(gè)基礎(chǔ)架構(gòu)。 基礎(chǔ)架構(gòu)概述應(yīng)該說些什么呢？它的角色是指導(dǎo)和建議如何定義一個(gè)特定系統(tǒng)的基礎(chǔ)架構(gòu)的需求，提出需求需要覆蓋的主題。最少，它應(yīng)該陳述系統(tǒng)需要基礎(chǔ)架構(gòu)提供什么：它存在的目的是什么，它的主要功能。有些問題有