軟件質(zhì)量概念軟件質(zhì)量保證軟件可靠性軟件配置管理軟件質(zhì)量管理1軟件質(zhì)量概念軟件質(zhì)量管理1軟件質(zhì)量概念軟件質(zhì)量的定義軟件質(zhì)量特性軟件質(zhì)量模型軟件質(zhì)量的度量和評價2軟件質(zhì)量概念軟件質(zhì)量的定義2軟件質(zhì)量的定義ANSI/IEEEStd729-1983定義軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。M.J.Fisher定義軟件質(zhì)量為“所有描述計算機軟件優(yōu)秀程度的特性的組合”。3軟件質(zhì)量的定義ANSI/IEEEStd729-1983定質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件的各項精確定義的功能、性能需求，符合文檔化的開發(fā)標準，需要相應(yīng)地給出或設(shè)計一些質(zhì)量特性及其組合。如果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，則這個軟件產(chǎn)品質(zhì)量就是高的。4質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。標準定義了一組開發(fā)準則，用來指導(dǎo)軟件人員用工程化的方法來開發(fā)軟件。如果不遵守這些開發(fā)準則，軟件質(zhì)量就得不到保證。軟件質(zhì)量是各種特性的復(fù)雜組合。它隨著應(yīng)用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。

5軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)量，問題最終要歸結(jié)到定義軟件的質(zhì)量特性。定義一個軟件的質(zhì)量，就等價于為該軟件定義一系列質(zhì)量特性。人們通常把影響軟件質(zhì)量的特性用軟件質(zhì)量模型來描述。6軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)軟件質(zhì)量模型軟件質(zhì)量特性定義成分層模型最基本的叫做基本質(zhì)量特性，它可以由一些子質(zhì)量特性定義和度量。二次特性在必要時又可由它的一些子質(zhì)量特性定義和度量。1976年Boehm質(zhì)量模型1979年McCall質(zhì)量模型1985年ISO質(zhì)量模型7軟件質(zhì)量模型軟件質(zhì)量特性定義成分層模型788ISO的軟件質(zhì)量評價模型按照ISO/TC97/SC7/WG3/1985-1-30/N382，軟件質(zhì)量度量模型由三層組成軟件質(zhì)量需求評價準則（SQRC）軟件質(zhì)量設(shè)計評價準則（SQDC）軟件質(zhì)量度量評價準則（SQMC）高層和中層建立國際標準，低層可由各使用單位視實際情況制定9ISO的軟件質(zhì)量評價模型按照ISO/TC97/SC7/WG3Boehm質(zhì)量模型10Boehm質(zhì)量模型1011111991年ISO質(zhì)量特性國際標準（ISO/IEC9126）質(zhì)量特性：功能性、可靠性、可維護性、效率、可使用性、可移植性推薦21個子特性：適合性準確性互用性依從性安全性成熟性容錯性可恢復(fù)性可理解性易學(xué)習性操作性時間特性資源特性可分析性穩(wěn)定性可變更性可測試性可安裝性可替換性適應(yīng)性一致性121991年ISO質(zhì)量特性國際標準（ISO/IEC91261313軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量是利用定量或定性的方法，估算軟件質(zhì)量的評價值，以得到軟件質(zhì)量的比較精確的估算值。驗收度量是在軟件開發(fā)各階段的檢查點，對軟件的要求質(zhì)量進行確認性檢查的具體評價值，它是對開發(fā)過程中的預(yù)測進行評價。14軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量有兩種。第一種叫做尺度度量，這是一種定量度量。它適用于一些能夠直接度量的特性，例如，出錯率定義為：錯誤數(shù)／KLOC／單位時間。第二種叫做二元度量，這是一種定性度量。它適用于一些只能間接度量的特性，例如，可使用性、靈活性等等。15預(yù)測度量有兩種。15尺度度量檢查表16尺度度量檢查表16二元度量檢查表17二元度量檢查表17通過對照檢查項目，確定一種質(zhì)量特性的有無。例如，在設(shè)計和編碼階段的復(fù)雜性度量，利用尺度度量方法來做。對模塊復(fù)雜性的度量采用McCabe環(huán)路度量。對于二元度量，可針對檢查表中每一項都應(yīng)給以記分，指定信息存在時記“1”，否則記“0”。表中所有各項的分數(shù)相加，即得度量結(jié)果。18通過對照檢查項目，確定一種質(zhì)量特性的有無。18軟件的質(zhì)量保證質(zhì)量保證的概念軟件質(zhì)量保證的主要任務(wù)質(zhì)量保證與檢驗軟件質(zhì)量保證體系質(zhì)量保證的實施軟件的質(zhì)量設(shè)計19軟件的質(zhì)量保證質(zhì)量保證的概念19質(zhì)量保證的概念什么是質(zhì)量保證，它是為保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進行的有計劃、有組織的活動。質(zhì)量保證是面向消費者的活動，是為了使產(chǎn)品實現(xiàn)用戶要求的功能，站在用戶立場上來掌握產(chǎn)品質(zhì)量的。軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品。20質(zhì)量保證的概念什么是質(zhì)量保證，它是為保證產(chǎn)品和服務(wù)充分滿足消軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動。即為了確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、有系統(tǒng)的管理活動。21軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品軟件質(zhì)量保證的主要任務(wù)為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件質(zhì)量保證的主要任務(wù)大致可歸結(jié)為8點。

22軟件質(zhì)量保證的主要任務(wù)為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件1.用戶要求定義熟練掌握正確定義用戶要求的技術(shù)熟練使用和指導(dǎo)他人使用定義軟件需求的支持工具重視領(lǐng)導(dǎo)全體開發(fā)人員收集和積累有關(guān)用戶業(yè)務(wù)領(lǐng)域的各種業(yè)務(wù)的資料和技術(shù)技能。231.用戶要求定義熟練掌握正確定義用戶要求的技術(shù)232.力爭不重復(fù)勞動考慮哪些既有軟件可以復(fù)用在開發(fā)過程中，隨時考慮所生產(chǎn)軟件的復(fù)用性。242.力爭不重復(fù)勞動考慮哪些既有軟件可以復(fù)用243.掌握開發(fā)新軟件的方法在開發(fā)新軟件的過程中大力使用和推行軟件工程學(xué)中所介紹的開發(fā)方法和工具。

使用先進的開發(fā)技術(shù)：如結(jié)構(gòu)化技術(shù)、面向?qū)ο蠹夹g(shù)使用數(shù)據(jù)庫技術(shù)或網(wǎng)絡(luò)化技術(shù)應(yīng)用開發(fā)工具或環(huán)境改進開發(fā)過程253.掌握開發(fā)新軟件的方法在開發(fā)新軟件的過程中大力使用和推行4.組織外部力量協(xié)作的方法一個軟件自始至終由同一個軟件開發(fā)單位來開發(fā)，也許是最理想的。但在現(xiàn)實中常常難以做到。改善對外部協(xié)作部門的開發(fā)管理。必須明確規(guī)定進度管理、質(zhì)量管理、交接檢查、維護體制等各方面的要求，建立跟蹤檢查的體制。264.組織外部力量協(xié)作的方法一個軟件自始至終由同一個軟件開發(fā)5.排除無效勞動最大的無效勞動就是因需求規(guī)格說明有誤、設(shè)計有誤而造成的返工。定量記錄返工工作量，收集和分析返工勞動花費數(shù)據(jù)較大的無效勞動是重復(fù)勞動，即相似的軟件在幾個地方同時開發(fā)建立互相交流、信息往來通暢、具橫向交流特征的信息流通網(wǎng)275.排除無效勞動最大的無效勞動就是因需求規(guī)格說明有誤、設(shè)計6.發(fā)揮每個開發(fā)者的能力軟件生產(chǎn)是人的智能生產(chǎn)活動，它依賴于人的能力和開發(fā)組織團隊的能力。開發(fā)者必須有學(xué)習各專業(yè)業(yè)務(wù)知識、生產(chǎn)技術(shù)和管理技術(shù)的能動性。管理者或產(chǎn)品服務(wù)者要制定技術(shù)培訓(xùn)計劃、技術(shù)水平標準，以及適用于將來需要的中長期技術(shù)培訓(xùn)計劃。

286.發(fā)揮每個開發(fā)者的能力軟件生產(chǎn)是人的智能生產(chǎn)活動，它依賴7.提高軟件開發(fā)的工程能力要想生產(chǎn)出高質(zhì)量的軟件產(chǎn)品必須有高水平的軟件工程能力。在軟件開發(fā)環(huán)境或軟件工具箱的支持下，運用先進的開發(fā)技術(shù)、工具和管理方法開發(fā)軟件的能力。

297.提高軟件開發(fā)的工程能力要想生產(chǎn)出高質(zhì)量的軟件產(chǎn)品必須有8.提高計劃和管理質(zhì)量能力項目開發(fā)初期計劃階段的項目計劃評價計劃執(zhí)行過程中及計劃完成報告的評價將評價、評審工作在工程實施之前就列入整個開發(fā)工程的工程計劃中提高軟件開發(fā)項目管理的精確度308.提高計劃和管理質(zhì)量能力項目開發(fā)初期計劃階段的項目計劃評質(zhì)量保證與檢驗其一是切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量保證活動開展得如何；其二是預(yù)先防止軟件差錯給用戶造成損失。為了確保每個開發(fā)過程的質(zhì)量，防止把軟件差錯傳遞到下一個過程，必須進行質(zhì)量檢驗。31質(zhì)量保證與檢驗其一是切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量檢驗的原則用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”。靠質(zhì)量檢驗，一般檢查的是“真質(zhì)量”的質(zhì)量特性。能靠質(zhì)量檢驗的質(zhì)量特性，即使全數(shù)檢驗，也只是代表產(chǎn)品的部分質(zhì)量特性。必須在各開發(fā)階段對影響產(chǎn)品質(zhì)量的因素進行切實的管理，認真檢查實施落實情況。

32質(zhì)量檢驗的原則用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”。當開發(fā)階段出現(xiàn)異常時，要從質(zhì)量特性方面進行檢驗，看是否會給后續(xù)階段帶來影響。雖然各開發(fā)階段進展穩(wěn)定，但由于工程能力不足，軟件產(chǎn)品不能滿足用戶要求的質(zhì)量。這時可通過檢驗對該產(chǎn)品做出評價，判斷是否能向用戶提供該產(chǎn)品。要以一定的標準檢驗產(chǎn)品，根據(jù)產(chǎn)品的質(zhì)量特性，檢查各個過程的管理狀態(tài)。33當開發(fā)階段出現(xiàn)異常時，要從質(zhì)量特性方面進行檢驗，看是否會給后軟件質(zhì)量保證體系軟件的質(zhì)量保證活動，是涉及各個部門的部門間的活動。例如，如果在用戶處發(fā)現(xiàn)了軟件故障，產(chǎn)品服務(wù)部門就應(yīng)聽取用戶的意見，再由檢查部門調(diào)查該產(chǎn)品的檢驗結(jié)果，進而還要調(diào)查軟件實現(xiàn)過程的狀況，并根據(jù)情況檢查設(shè)計是否有誤，不當之處加以改進，防止再次發(fā)生問題。34軟件質(zhì)量保證體系軟件的質(zhì)量保證活動，是涉及各個部門的部門間的為了順利開展以上活動，事先明確部門間的質(zhì)量保證業(yè)務(wù)，確立部門間的聯(lián)合與協(xié)作的機構(gòu)十分重要，這個機構(gòu)就是質(zhì)量保證體系。必須明確反饋途徑。必須明確各部門的職責。必須確定保證系統(tǒng)運行的方法、工具、有關(guān)文檔資料，以及系統(tǒng)管理的規(guī)程和標準。35為了順利開展以上活動，事先明確部門間的質(zhì)量保證業(yè)務(wù)，確立部門必須明確決定是否可向下一階段進展的評價項目和評價準則。必須不斷地總結(jié)系統(tǒng)管理的經(jīng)驗教訓(xùn)，能夠修改系統(tǒng)。制定質(zhì)量保證計劃，在計劃中確定質(zhì)量目標確定在每個階段為達到總目標所應(yīng)達到的要求確定進度安排確定所需人力、資源和成本等。36必須明確決定是否可向下一階段進展的評價項目和評價準則。36軟件質(zhì)量保證規(guī)程和技術(shù)準則規(guī)定在項目的哪個階段進行評審及如何評審；規(guī)定在項目的哪個階段應(yīng)當產(chǎn)生哪些報告和計劃；規(guī)定產(chǎn)品各方面測試應(yīng)達到的水平。在每次評審和測試中發(fā)現(xiàn)的錯誤如何修正；37軟件質(zhì)量保證規(guī)程和技術(shù)準則規(guī)定在項目的哪個階段進行評審及如何描述希望得到的質(zhì)量度量；說明各種軟件人員的職責，規(guī)定為了達到質(zhì)量目標他們必須進行哪些活動。建立在各階段中執(zhí)行質(zhì)量評價的質(zhì)量評價和質(zhì)量檢查系統(tǒng)有效運用質(zhì)量信息的質(zhì)量信息系統(tǒng)，并使其運行。38描述希望得到的質(zhì)量度量；38質(zhì)量保證的實施軟件質(zhì)量保證的實施需要從縱向和橫向兩個方面展開。

要求所有與軟件生存期有關(guān)的人員都要參加要求對產(chǎn)品形成的全過程進行質(zhì)量管理這要求整個軟件部門齊心協(xié)力，不斷完善軟件的開發(fā)環(huán)境。此外還需要與用戶共同合作。39質(zhì)量保證的實施軟件質(zhì)量保證的實施需要從縱向和橫向兩個方面展開質(zhì)量目標與度量為了開發(fā)高質(zhì)量的軟件，需要明確軟件的功能，明確軟件應(yīng)達到什么樣的質(zhì)量標準，即質(zhì)量目標。為了達到這個目標，在開發(fā)過程中的各個階段進行檢查和評價。在做質(zhì)量評價時，需要有對質(zhì)量進行度量的準則和方法。需要有在軟件生存期中如何使用這些準則和方法的質(zhì)量保證步驟，以及提高該項作業(yè)效率的工具40質(zhì)量目標與度量為了開發(fā)高質(zhì)量的軟件，需要明確軟件的功能，明確軟件質(zhì)量度量和保證的條件適應(yīng)性：適應(yīng)各種用戶、軟件類型易學(xué)性：不需要特殊技術(shù)，易掌握可靠性：同個軟件的評價結(jié)果一致針對性：設(shè)計階段就確立質(zhì)量目標，在各個階段實施落實。客觀性：經(jīng)濟性：41軟件質(zhì)量度量和保證的條件適應(yīng)性：適應(yīng)各種用戶、軟件類型41質(zhì)量保證活動的實施步驟：Target：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準則、質(zhì)量設(shè)計準則的各質(zhì)量特性設(shè)定質(zhì)量目標。Plan：設(shè)定適合于被開發(fā)軟件的評測檢查項目(質(zhì)量評價準則)。研討實現(xiàn)質(zhì)量目標的方法或手段。Do：制作高質(zhì)量的規(guī)格說明和程序。在接受質(zhì)量檢查前先做自我檢查。42質(zhì)量保證活動的實施步驟：Target：以用戶要求和開發(fā)方針為Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價。計算結(jié)果用質(zhì)量圖的形式表示出來。比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標，看其是否合格。Action：對評價發(fā)現(xiàn)的問題進行改進活動，如果實現(xiàn)并達到了質(zhì)量目標就轉(zhuǎn)入下一個工程階段。這樣重復(fù)“Plan”到“Action”的過程，直到整個開發(fā)項目完成。43Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價。計算結(jié)444445454646軟件的質(zhì)量設(shè)計質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)在軟件定義階段，必須定義對軟件的質(zhì)量需求。即確定軟件的質(zhì)量特性及必需的評價準則，并定量地設(shè)定其必須達到的質(zhì)量水平在以后軟件開發(fā)的每一階段結(jié)束時，要算出評價的分數(shù)，然后與目標值加以對照，以評估在這一階段開發(fā)的軟件質(zhì)量是否達到要求。

47軟件的質(zhì)量設(shè)計質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)47為了實現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)的特性。例如，軟件質(zhì)量需求中的“性能”，可以轉(zhuǎn)換成軟件內(nèi)部結(jié)構(gòu)中的構(gòu)成元素，即每一個程序模塊和物理數(shù)據(jù)各自應(yīng)具有的性能特性。這些性能特性的累積就形成外部規(guī)格中的性能特性。48為了實現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部軟件的結(jié)構(gòu)特性與評價標準結(jié)構(gòu)特性邏輯數(shù)據(jù)層次評價標準全部數(shù)據(jù)元素定義完畢所有層次的操作符定義完畢結(jié)構(gòu)特性功能層次評價標準

全部功能元素定義完畢所有層次的操作符定義完畢49軟件的結(jié)構(gòu)特性與評價標準結(jié)構(gòu)特性邏輯數(shù)據(jù)層次49結(jié)構(gòu)特性邏輯數(shù)據(jù)與功能的對應(yīng)關(guān)系評價準則所有數(shù)據(jù)都與功能對應(yīng)所有功能元素都與數(shù)據(jù)對應(yīng)邏輯數(shù)據(jù)與功能的相互關(guān)系個數(shù)（局部）50結(jié)構(gòu)特性邏輯數(shù)據(jù)與功能的對應(yīng)關(guān)系50

結(jié)構(gòu)特性物理數(shù)據(jù)層次評價準則全部數(shù)據(jù)元素定義完畢物理數(shù)據(jù)之間的所有指針定義完畢上述指針都具有層次性51結(jié)構(gòu)特性物理數(shù)據(jù)層次51結(jié)構(gòu)特性模塊層次評價準則

所有模塊定義完畢模塊之間所有控制關(guān)系定義完畢上述關(guān)系都是標準過程調(diào)用形式各層次上的模塊大小適當52結(jié)構(gòu)特性模塊層次52結(jié)構(gòu)特性

物理數(shù)據(jù)與模塊的對應(yīng)關(guān)系評價準則所有物理數(shù)據(jù)都與模塊對應(yīng)所有模塊都與物理數(shù)據(jù)對應(yīng)對應(yīng)于一個物理數(shù)據(jù)的模塊數(shù)（以一對一為好）53結(jié)構(gòu)特性53結(jié)構(gòu)特性

邏輯數(shù)據(jù)與物理數(shù)據(jù)的對應(yīng)關(guān)系評價準則所有邏輯數(shù)據(jù)都與物理數(shù)據(jù)對應(yīng)對應(yīng)于一個物理數(shù)據(jù)的邏輯數(shù)據(jù)數(shù)（以一對一為好）54結(jié)構(gòu)特性54結(jié)構(gòu)特性功能與模塊的對應(yīng)關(guān)系評價準則所有功能都與模塊對應(yīng)對應(yīng)模塊的功能個數(shù)（以一對 一為好）55結(jié)構(gòu)特性55軟件可靠性軟件生存期與軟件壽命的關(guān)系在軟件工程中常用的定義軟件可靠性定義測試中的可靠性分析測試精確度和測試覆蓋度的評價56軟件可靠性軟件生存期與軟件壽命的關(guān)系56軟件生存期與軟件壽命的關(guān)系一切有生命的東西都有一個“壽命”這個概念也可以延伸到對非生命產(chǎn)品的質(zhì)量評價上來。例如一個電子產(chǎn)品的壽命就是指該產(chǎn)品從出廠直到喪失使用價值的持續(xù)時間。從軟件工程的角度來說，軟件產(chǎn)品的壽命是指軟件的整個生存期。57軟件生存期與軟件壽命的關(guān)系一切有生命的東西都有一個“壽命”5從軟件用戶的角度來看，更關(guān)心的是軟件在交付使用后的情況如何。希望用一個指標平均失效間隔時間

MTBF(MeanTimeBetweenFailure)來表明，在規(guī)定的要求和條件下，能在多大的程度上依賴這個軟件來完成任務(wù)。我們把在使用期間軟件能夠正常工作的持續(xù)時間叫做軟件的使用壽命。58從軟件用戶的角度來看，更關(guān)心的是軟件在交付使用后的情況如何。軟件的使用壽命與輸入環(huán)境有關(guān)。例如，有一個存在缺陷的編譯程序，當用于學(xué)生做簡單練習時，MTBF可能很長。而做一個大的課題時，由于程序連續(xù)出錯，MTBF就會變得很短。MTBF可以看做是對軟件可靠性做估計的樣本數(shù)據(jù)，但不能看做是依據(jù)。59軟件的使用壽命與輸入環(huán)境有關(guān)。59“錯誤”這一術(shù)語。在沒有特別加以說明的情況下，這是一個泛用的、模糊的概念。它指的可能是bug(設(shè)計中的差錯)、fault(故障)、error(錯誤)、failure(失效)、crash(重大事故)、problem(疑問)等。在漢譯中，這些術(shù)語的使用更加混亂。60“錯誤”這一術(shù)語。在沒有特別加以說明的情況下，這是一個泛用的在軟件工程中常用的定義故障(fault)：軟件的內(nèi)在缺陷。這些缺陷可在生存期各個階段被引入。錯誤(error)：故障在一定的環(huán)境條件下的暴露，導(dǎo)致系統(tǒng)在運行中出現(xiàn)了不正常、不正確、不按規(guī)范執(zhí)行的狀態(tài)，稱為軟件出錯。失效(failure)：對錯誤不做任何修正和恢復(fù)，導(dǎo)致系統(tǒng)的輸出不滿足用戶要求，稱為軟件的一次失效。

61在軟件工程中常用的定義故障(fault)：軟件的內(nèi)在缺陷。這以上定義的故障、錯誤和失效，分別代表了廣義的“錯誤”在不同的條件下所對應(yīng)的術(shù)語。它們可以理解為：設(shè)計者的失誤─導(dǎo)致系統(tǒng)中留有錯誤的設(shè)計──缺陷或“故障”(fault)，這些故障導(dǎo)致系統(tǒng)的錯誤執(zhí)行──錯誤(error)，由于錯誤導(dǎo)致系統(tǒng)的錯誤輸出──失效(failure)。62以上定義的故障、錯誤和失效，分別代表了廣義的“錯誤”在不同的故障是物理地或靜態(tài)地存在的失誤、錯誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象軟件發(fā)生失效標志著軟件一次使用壽命的結(jié)束發(fā)生過失效的軟件通常仍然是可用的。只有當軟件頻繁失效，或者公認已經(jīng)“過時”了的時侯，軟件才被廢棄，意味著當前這一版本軟件使用壽命的終結(jié)。63故障是物理地或靜態(tài)地存在的63軟件故障產(chǎn)生原因支持軟件工作的基本條件(除硬件外的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、編譯程序、微代碼等)的缺陷軟件設(shè)計不當加入了允許范圍之外的輸入64軟件故障產(chǎn)生原因支持軟件工作的基本條件(除硬件外的操作系統(tǒng)、軟件可靠性的定義軟件可靠性是軟件在給定的時間間隔及給定的環(huán)境條件下，按設(shè)計要求，成功地運行程序的概率。環(huán)境條件─指的是軟件的使用環(huán)境。無論是什么軟件，如果不對它的使用環(huán)境加以限制，都是會失效的。這種失效的數(shù)據(jù)，不能用來度量軟件的可靠性。65軟件可靠性的定義軟件可靠性是軟件在給定的時間間隔及給定的環(huán)境規(guī)定的時間─在定義中，一般采用“運行時間”t

作為時間的尺度。因

具體要處理的問題是多種多樣的其對應(yīng)的輸入環(huán)境是隨機程序中相應(yīng)程序路徑的選取也是隨機的軟件的失效也是隨機的應(yīng)當把運行時間t當作隨機變量來考慮。66規(guī)定的時間─在定義中，一般采用“運行時間”t作為時間的尺規(guī)定的功能─在考慮軟件可靠性時，首先應(yīng)當明確軟件的功能是什么，哪些功能是主要的，哪些功能是次要的。一般從軟件需求分析說明書和設(shè)計說明書中可以了解這些情況。由于功能不同，失效帶來的損失就不一樣。因此，還要明確哪些失效是致命的，哪些失效是非致命的，哪些又是容易修復(fù)的。此外，還要明確，怎樣才算是完成了一個規(guī)定的功能。67規(guī)定的功能─在考慮軟件可靠性時，首先應(yīng)當明確軟件的功能是什么成功地運行程序─是指不僅程序能正確地運行，滿足用戶對它的功能要求，而且當程序一旦受到意外的傷害，或系統(tǒng)故障時，能盡快恢復(fù)，仍能正常地運行。

68成功地運行程序─是指不僅程序能正確地運行，滿足用戶對它的功能測試中的可靠性分析在軟件開發(fā)的過程中，利用測試的統(tǒng)計數(shù)據(jù)，估算軟件的可靠性，以控制軟件的質(zhì)量是至關(guān)重要的。推測錯誤的產(chǎn)生頻度，即推測錯誤產(chǎn)生的時間間隔推測殘留在程序中的錯誤數(shù)評價測試的精確度和覆蓋率

69測試中的可靠性分析在軟件開發(fā)的過程中，利用測試的統(tǒng)計數(shù)據(jù)，估推測錯誤的產(chǎn)生頻度估算錯誤產(chǎn)生頻度的一種方法是估算平均失效等待時間MTTF(MeanTimeToFailure)MTTF估算公式(Shooman模型)70推測錯誤的產(chǎn)生頻度估算錯誤產(chǎn)生頻度的一種方法是估算平均失效等故障累積指數(shù)曲線模型71故障累積指數(shù)曲線模型71估算軟件中故障總數(shù)ET的方法利用Shooman模型估算程序中原來錯誤總量ET—瞬間估算72估算軟件中故障總數(shù)ET的方法利用Shooman模型估算程序解此方程組73解此方程組73利用最小二乘法進行程序原有錯誤數(shù)ET及K的估算由失效率整理得若對程序進行若干次不同的功能測試，可得到一系列實驗數(shù)據(jù)74利用最小二乘法進行程序原有錯誤數(shù)ET及K的估算由失效率74

Ec(ti),(ti),i=1,2,…,n令

有75Ec(ti),(ti),用最小二乘法解此方程組，可解出a、b的估計值最后得到K,ET的估計值

利用植入故障法估算程序中原有故障總數(shù)ET

─捕獲－再捕獲抽樣法76用最小二乘法解此方程組，可解出a、b的估計值利用植入故障法估設(shè)Ns是在測試前人為地向程序中植入的故障數(shù)，ns是經(jīng)過一段時間測試后發(fā)現(xiàn)的播種故障數(shù)目，n

是在測試中又發(fā)現(xiàn)的程序原有故障數(shù)。設(shè)測試用例發(fā)現(xiàn)植入故障和原有故障的能力相同，則程序中原有故障總數(shù)

N(=ET)估算值為77設(shè)Ns是在測試前人為地向程序中植入的故障數(shù)，ns是經(jīng)過一Hyman分別測試法由兩個測試員同時互相獨立地測試同一程序的兩個副本，用t表示測試時間，記t＝0時，程序中原有故障總數(shù)是

B0；t＝t1時，測試員甲發(fā)現(xiàn)的故障總數(shù)是

B1；測試員乙發(fā)現(xiàn)的故障總數(shù)是

B2；其中兩人發(fā)現(xiàn)的相同故障數(shù)目是

bc；兩人發(fā)現(xiàn)的不同故障數(shù)目是

bi。

78Hyman分別測試法由兩個測試員同時互相獨立地測試同一程序的在大程序測試時，頭幾個月兩個測試員測試的結(jié)果應(yīng)當比較接近，bi不是很大。這時有如果bi比較顯著，應(yīng)當每隔一段時間，由兩個測試員再進行分別測試，分析測試結(jié)果，估算B0。如果bi減小，或幾次估算值的結(jié)果相差不多，則B0作為原有錯誤總數(shù)的估算值。

79在大程序測試時，頭幾個月兩個測試員測試的結(jié)果應(yīng)當比較接近，b測試精確度和測試覆蓋度的評價在軟件測試過程中累積發(fā)現(xiàn)的故障數(shù)，可用帶有平均值函數(shù)m(t)的非齊次泊松過程(NHPP)來描述：其中，N是在測試中可能發(fā)現(xiàn)的故障總數(shù)，b是故障發(fā)現(xiàn)率。當N一定時，b越大，在短期內(nèi)發(fā)現(xiàn)的故障越多。80測試精確度和測試覆蓋度的評價在軟件測試過程中累積發(fā)現(xiàn)的故障數(shù)8181N

可以認為是當測試時間無限延長時估計可能發(fā)現(xiàn)的故障總數(shù)。由于

測試的不完全，在某些很難發(fā)現(xiàn)的故障未發(fā)現(xiàn)前就可能結(jié)束測試若程序中潛在的故障較少，則參數(shù)N的估計誤差較大因此，只用測試中累積發(fā)現(xiàn)的故障數(shù)來評價測試是不夠的。需要從測試的量的方面和質(zhì)的方面，全面地評價測試。82N可以認為是當測試時間無限延長時估計可能發(fā)現(xiàn)的故障總數(shù)。由SPQL(SoftwareProductQualityLevel)用如下公式度量：

SPQL＝Ac×Cv其中，Ac(TestAccuracy)是測試的精確度，它反映了測試的質(zhì)量；Cv(TestCoveragy)是測試的覆蓋度，它反映了測試的數(shù)量。測試結(jié)束時軟件產(chǎn)品質(zhì)量水準83SPQL(SoftwareProductQuality測試質(zhì)量的度量可以靠測試的故障捕捉率和遺漏率來衡量。測試數(shù)量的度量指標是執(zhí)行的測試用例數(shù)、確認的程序路徑數(shù)等等；

84測試質(zhì)量的度量可以靠測試的故障捕捉率和遺漏率來衡量。84測試精確度Ac表明在測試的過程中以多大的把握捕捉了軟件中潛在的故障。測定Ac，需要預(yù)先植入播種故障，然后通過測試，根據(jù)播種故障的捕捉率來推測原有故障的捕獲率。

85測試精確度Ac表明在測試的過程中以多大的把握捕捉了軟件中潛在用ns表示經(jīng)過相當長時間測試可能發(fā)現(xiàn)的播種故障數(shù)，用Ns表示測試對象軟件內(nèi)預(yù)先埋設(shè)的播種故障總數(shù),用平均值為m(t)的NHPP模型描述測試時發(fā)現(xiàn)播種故障的過程m(t)的收斂值m()＝N測試精確度Ac的推測值：

86用ns表示經(jīng)過相當長時間測試可能發(fā)現(xiàn)的播種故障數(shù)，用Ns若設(shè)測試過程中到時刻ti能發(fā)現(xiàn)的累積播種故障總數(shù)為yi，則在測試期間可得到一連串數(shù)據(jù)

(t0,0),(t1,y1),……,(tm,ym)可得到一組方程：

應(yīng)用最小二乘法可得到參數(shù)N與b的估計值，并得到測試精確度Ac。

87若設(shè)測試過程中到時刻ti能發(fā)現(xiàn)的累積播種故障總數(shù)為y測試覆蓋率Cv表明在整個測試期間發(fā)現(xiàn)軟件內(nèi)潛在故障的可能性有多大?？赏ㄟ^被測試對象軟件內(nèi)潛在的原有故障的捕捉率來測定的。88測試覆蓋率Cv表明在整個測試期間發(fā)現(xiàn)軟件內(nèi)潛在故障的可能性有測試過程中已發(fā)現(xiàn)原有故障總數(shù)為n0(實測值)，經(jīng)過相當長時間測試后可能發(fā)現(xiàn)的原有故障總數(shù)為N0，采用平均值函數(shù)m(t)的NHPP模型描述測試發(fā)現(xiàn)原有故障的過程m(t)的收斂值m()＝Nc測試覆蓋率Cv的推測值：

89測試過程中已發(fā)現(xiàn)原有故障總數(shù)為n0(實測值)，經(jīng)過相當長時

測試開始后，由于測試員對程序和測試環(huán)境不熟悉，造成拖期。為描述這種情形，對原來NHPP的指數(shù)型平均值函數(shù)加以改造：它是把原來的指數(shù)型平均值函數(shù)在時間軸上平移而得到的結(jié)果，是具有時間延遲的NHPP模型。

90

9191測試員從發(fā)現(xiàn)錯誤征兆到確認錯誤，需要反復(fù)執(zhí)行程序，以再現(xiàn)錯誤，造成時間拖延。因此，在使用測試結(jié)果進行軟件質(zhì)量評價時，只用指數(shù)型的NHPP的平均值曲線(A)是不夠的。實測結(jié)果多是如(B)所示的S型曲線。92測試員從發(fā)現(xiàn)錯誤征兆到確認錯誤，需要反復(fù)執(zhí)行程序，以再現(xiàn)錯誤實驗表明：對于一般功能單純的小規(guī)模的程序模塊，具有時間延遲的NHPP模型比較合適；對于功能比較復(fù)雜的程序模塊，S型NHPP模型比較合適；對于80000行以上的程序，最基本的指數(shù)型NHPP模型比較合適。

93實驗表明：93軟件配置管理在軟件建立時變更是不可避免的，因為在進行變更前沒有仔細分析，或沒有進行變更控制，變更加劇了項目中軟件人員之間的混亂。協(xié)調(diào)軟件開發(fā)使得混亂減到最小的技術(shù)叫做配置管理。配置管理是一組標識、組織和控制修改的活動，目的是使錯誤達到最小并最有效地提高生產(chǎn)率。94軟件配置管理在軟件建立時變更是不可避免的，因為在進行變更前沒軟件配置管理的概念軟件配置管理，簡稱SCM，是一種“保護傘”活動，它應(yīng)用于整個軟件工程過程。SCM活動的目標是為了

(1)標識變更；(2)控制變更；(3)確保變更正確地實現(xiàn)；(4)向其他有關(guān)的人報告變更。95軟件配置管理的概念軟件配置管理，簡稱SCM，是一種“保護傘”在軟件工程過程中產(chǎn)生的所有信息項（文檔、報告、程序、表格、數(shù)據(jù)）構(gòu)成了軟件配置。軟件配置是軟件的具體形態(tài)在某一時刻的瞬時影像。隨著軟件工程過程的進展，軟件配置項(SCI)數(shù)目快速增加。系統(tǒng)規(guī)格說明可繁衍出軟件項目實施計劃和軟件需求規(guī)格說明。它們又依次繁衍出建立信息層次的其它文檔。96在軟件工程過程中產(chǎn)生的所有信息項（文檔、報告、程序、表格、數(shù)基線(Baseline)基線是軟件生存期中各開發(fā)階段末尾的特定點，又稱里程碑。由正式的技術(shù)評審而得到的SCI協(xié)議和軟件配置的正式文本才能成為基線?；€的作用是把各階段工作的劃分更加明確化，以便于檢驗和肯定階段成果。97基線(Baseline)基線是軟件生存期中各開發(fā)階段末尾的軟件開發(fā)各階段的基線98軟件開發(fā)各階段的基線98項目數(shù)據(jù)庫一旦一個SCI成為基線，就把它存放到項目數(shù)據(jù)庫中。當軟件組織成員想要對基線SCI進行修改時，把它從項目數(shù)據(jù)庫中復(fù)制到該工程師的專用工作區(qū)中。例如，把一個名為B的SCI從項目數(shù)據(jù)庫復(fù)制到工程師的專用工作區(qū)中。工程師在B'（B的副本）上完成要求的變更，再用B'來更新B。99項目數(shù)據(jù)庫一旦一個SCI成為基線，就把它存放到項目數(shù)據(jù)庫中。有些系統(tǒng)中把這個基線SCI鎖定。在變更完成、評審和批準之前，不許對它做任何操作。100有些系統(tǒng)中把這個基線SCI鎖定。100基線SCI和項目數(shù)據(jù)庫101基線SCI和項目數(shù)據(jù)庫101軟件配置項SCI軟件配置管理的對象就是SCI—軟件配置項。

系統(tǒng)規(guī)格說明軟件項目實施計劃軟件需求說明可執(zhí)行的原型初步的用戶手冊設(shè)計規(guī)格說明102軟件配置項SCI軟件配置管理的對象就是SCI—軟件配置項。

源代碼清單測試計劃和過程、測試用例和測試結(jié)果記錄操作和安裝手冊可執(zhí)行程序（可執(zhí)行程序模塊、連接模塊）數(shù)據(jù)庫描述（模式和文件結(jié)構(gòu)、初始內(nèi)容）正式的用戶手冊維護文檔（軟件問題報告、維護請求、工程變更次序）103源代碼清單103軟件工程標準項目開發(fā)總結(jié)除以上所列SCI以外，許多軟件工程組織還把配置控制之下的軟件工具列入其中，即編輯程序、編譯程序、其它CASE工具的特定版本。因為要使用這些工具來生成文檔、程序和數(shù)據(jù)，如果編譯程序的版本不同，可能產(chǎn)生的結(jié)果也不同。104軟件工程標準104配置對象在實現(xiàn)SCM時，把SCI組織成配置對象，在項目數(shù)據(jù)庫中用一個單一的名字來組織它們。一個配置對象有一個名字和一組屬性，并通過某些聯(lián)系“連接”到其它對象。每個對象與其它對象的聯(lián)系用箭頭表示。箭頭指明了一種構(gòu)造關(guān)系。105配置對象在實現(xiàn)SCM時，把SCI組織成配置對象，在項目數(shù)據(jù)庫配置對象106配置對象106雙向箭頭則表明一種相互關(guān)系。如果對“源代碼”對象作了一個變更，軟件工程師就可以根據(jù)這種相互關(guān)系確定，其它哪些對象（和SCI）可能受到影響。107雙向箭頭則表明一種相互關(guān)系。如果對“源代碼”對象作了一個變更軟件配置管理的任務(wù)軟件配置管理（SCM）的任務(wù)是：

標識單個的SCI標識和管理軟件各種版本控制變更審查軟件配置報告所有加在配置上的變更。108軟件配置管理的任務(wù)軟件配置管理（SCM）的任務(wù)是：108配置標識一方面隨著軟件生存期的向前推進，SCI的數(shù)量不斷增多。整個軟件生存期的軟件配置就象一部不斷演變的電影，而某一時刻的配置就是這部電影的一個片段。為了方便對軟件配置的各個片段（SCI）進行控制和管理，不致造成混亂，首先應(yīng)給它們命名。109配置標識一方面隨著軟件生存期的向前推進，SCI的數(shù)量不斷增多對象類型基本對象：是由軟件工程師在分析、設(shè)計、編碼和測試時所建立的文本單元。例如，基本對象可能是需求規(guī)格說明中的一節(jié)，一個模塊的源程序清單、一組用來測試一個等價類的測試用例。復(fù)合對象：是基本對象或其它復(fù)合對象的一個收集。110對象類型基本對象：是由軟件工程師在分析、設(shè)計、編碼和測試時所對象標識：（名字、描述、資源、實現(xiàn)）對象的名字明確地標識對象。對象描述包括：SCI類型（如文檔、程序、數(shù)據(jù)）、項目標識、變更和／或版本信息。資源包括由對象產(chǎn)生的、處理的、引用的或其它需要的一些實體?；緦ο蟮膶崿F(xiàn)是指向文本單元的指針，復(fù)合對象的實現(xiàn)為null。111對象標識：111命名對象之間的聯(lián)系對象的層次關(guān)系：一個對象可以是一個復(fù)合對象的一個組成部分，用聯(lián)系<is

partof>標識。

E-Rdiagram1.4<is

partof>datamodel;datamodel<ispartof>DesignSpecification;就可以建立SCI的一個層次。112命名對象之間的聯(lián)系對象的層次關(guān)系：一個對象可以是一個復(fù)合對象對象的相互關(guān)聯(lián)關(guān)系：對象跨越對象層次的分支相互關(guān)聯(lián)。這些交叉的結(jié)構(gòu)聯(lián)系表達方式如下：datamodel<interrelated>dataflowmodel;

(兩個復(fù)合對象之間的相互聯(lián)系)datamodel<interrelated>testcaseclassm;

(一個復(fù)合對象與一個特定的基本對象之間的相互聯(lián)系）113對象的相互關(guān)聯(lián)關(guān)系：對象跨越對象層次的分支相互關(guān)聯(lián)。這些交叉演變圖整個軟件工程過程中所涉及的軟件對象都必須加以標識。在對象成為基線以前可能要做多次變更，在成為基線之后也可能需要頻繁地變更。對于每一配置對象都可以建立一個演變圖，用演變圖記敘對象的變更歷史。114演變圖整個軟件工程過程中所涉及的軟件對象都必須加以標識。11演變圖115演變圖115在某些工具中，當前保持的只是最后版本的完全副本。為了得到較早時期(文檔或程序)的版本，可以從最后版本中“提取”出(由工具編目的)變更，使得當前配置直接可用，并使得其它版本也可用。116在某些工具中，當前保持的只是最后版本的完全副本。116版本控制版本控制是SCM的基礎(chǔ)，它管理并保護開發(fā)者的軟件資源。版本控制管理在軟件工程過程中建立起配置對象的不同版本。版本管理可以把一些屬性結(jié)合到各個軟件版本上。通過描述所希望的屬性集合來確定（或構(gòu)造）所想要的配置。使用演變圖來表示系統(tǒng)的不同版本。117版本控制版本控制是SCM的基礎(chǔ)，它管理并保護開發(fā)者的軟件資源118118圖中的各個結(jié)點都是聚合對象，是一個完全的軟件版本。軟件的每一版本都是SCI（源代碼、文檔、數(shù)據(jù)）的一個收集，且各個版本都可能由不同的變種組成。例如，一個簡單的程序版本由1、2、3、4和5等部件組成。其中部件4在軟件使用彩色顯示器時使用，部件5在軟件使用單色顯示器時使用。因此，可以定義版本的兩個變種。119圖中的各個結(jié)點都是聚合對象，是一個完全的軟件版本。119版本管理的主要任務(wù)集中管理檔案，安全授權(quán)機制：版本管理的操作將開發(fā)組的檔案集中地存放在服務(wù)器上，經(jīng)系統(tǒng)管理員授權(quán)給各個用戶。用戶通過登入（checkin）和檢出（checkout）的方式訪問服務(wù)器上的文件，未經(jīng)授權(quán)的用戶無法訪問服務(wù)器上的文件。120版本管理的主要任務(wù)集中管理檔案，安全授權(quán)機制：120121121軟件版本升級管理：每次登入時，在服務(wù)器上都會生成新的版本。任何版本都可以隨時檢出編輯，同一應(yīng)用的不同版本可以像樹枝一樣向上增長。122軟件版本升級管理：122123123加鎖功能：目的是在文件更新時保護文件，避免不同用戶更改同一文件時發(fā)生沖突。某一文件一旦被登入，鎖即被解除，該文件可被其它用戶使用。在更新一個文件之前鎖定它，避免變更沒有鎖定的項目源文件。124加鎖功能：124在文件登入和檢出時，需要注意登入和檢出的使用:當需要修改某個小缺陷時，應(yīng)只檢出完成工作必需的最少文件；需要對文件變更時，應(yīng)登入它并加鎖，保留對每個變更的記錄；應(yīng)避免長時間地鎖定文件。如果需要長時間工作于某個文件，最好能創(chuàng)建一個分支，并在分支上做工作。125在文件登入和檢出時，需要注意登入和檢出的使用:125如果需要做較大的變更，可有兩種選擇：

a.將需要的所有文件檢出并加鎖，然后正常處理；

b.為需要修改的所有分支創(chuàng)建分支，把變更與主干“脫機”，然后把結(jié)果合并回去。126如果需要做較大的變更，可有兩種選擇：126變更控制軟件生存期內(nèi)全部的軟件配置是軟件產(chǎn)品的真正代表，必須使其保持精確。軟件工程過程中某一階段的變更，均要引起軟件配置的變更，這種變更必須嚴格加以控制和管理，保持修改信息。變更控制包括建立控制點和建立報告與審查制度。127變更控制軟件生存期內(nèi)全部的軟件配置是軟件產(chǎn)品的真正代表，必須變更控制過程128變更控制128129129在此過程中，首先用戶提交書面的變更請求，詳細申明變更的理由、變更方案、變更的影響范圍等。然后由變更控制機構(gòu)確定控制變更的機制、評價其技術(shù)價值、潛在的副作用、對其它配置對象和系統(tǒng)功能的綜合影響以及項目的開銷、并把評價的結(jié)果以變更報告的形式提交給變更控制負責人（最終決定變更狀態(tài)和優(yōu)先權(quán)的某個人或小組）。130在此過程中，首先用戶提交書面的變更請求，詳細申明變更的理由、對每個批準了的變更產(chǎn)生一個工程變更順序（ECO），描述進行的變更、必須考慮的約束、評審和審計的準則等。要做變更的對象從項目數(shù)據(jù)庫中檢出（checkout），對其做出變更，并實施適當?shù)馁|(zhì)量保證活動。然后再把對象登入（checkin）到數(shù)據(jù)庫中并使用適當?shù)陌姹究刂茩C制建立軟件的下一版本。131對每個批準了的變更產(chǎn)生一個工程變更順序（ECO），描述進行的軟件變更有兩類不同情況：為改正小錯誤需要的變更。它是必須進行的，通常不需要從管理角度對這類變更進行審查和批準。但是，如果發(fā)現(xiàn)錯誤的階段在造成錯誤的階段的后面，例如在實現(xiàn)階段發(fā)現(xiàn)了設(shè)計錯誤，則必須遵照標準的變更控制過程，把這個變更正式記入文檔，把所有受這個變更影響的文檔都做相應(yīng)的修改。132軟件變更有兩類不同情況：為改正小錯誤需要的變更。它是必須進行為了增加或者刪掉某些功能、或者為了改變完成某個功能的方法而需要的變更。這類變更必須經(jīng)過某種正式的變更評價過程，以估計變更需要的成本和它對軟件系統(tǒng)其它部分的影響。

如果變更的代價比較小且對軟件系統(tǒng)其它部分沒有影響，或影響很小，通常應(yīng)批準這個變更。

133為了增加或者刪掉某些功能、或者為了改變完成某個功能的方法而需

如果變更的代價比較高，或者影響比較大，則必須權(quán)衡利弊，以決定是否進行這種變更。如果同意這種變更，需要進一步確定由誰來支付變更所需要的費用。如果是用戶要求的變更，則用戶應(yīng)支付這筆費用；否則，必須完成某種成本／效益分析，以確定是否值得做這種變更。134如果變更的代價比較高，或者影響比較大，則必須權(quán)衡利弊，以決這種變更報告和審查制度，對變更控制來說起了一個安全保證作用。在一個SCI成為基線之前，可以對所有合理的項目和技術(shù)申請進行非正式的變更；一旦某個SCI經(jīng)過正式的技術(shù)評審并得到批準，它就成了基線。以后如果需要對它變更，就必須得到項目負責人的批準，或者必須得到變更控制負責人的批準。135這種變更報告和審查制度，對變更控制來說起了一個安全保證作用。配置狀態(tài)報告為了清楚、及時地記載軟件配置的變化，需要對開發(fā)的過程做出系統(tǒng)的記錄，以反映開發(fā)活動的歷史情況。這就是配置狀態(tài)登錄的任務(wù)。登錄主要根據(jù)變更控制小組會議的記錄，并產(chǎn)生配置狀態(tài)報告。對于每一項變更，記錄：發(fā)生了什么？為什么會發(fā)生？誰做的？什么時侯發(fā)生的？會有什么影響？136配置狀態(tài)報告為了清楚、及時地記載軟件配置的變化，需要對開發(fā)的配置狀態(tài)報告信息流137配置狀態(tài)報告信息流137每次新分配一個SCI，或更新一個已有SCI的標識，或一項變更申請被變更控制負責人批準，并給出了一個工程變更順序時，在配置狀態(tài)報告中就要增加一條變更記錄條目。一旦進行了配置審計，其結(jié)果也應(yīng)該寫入報告之中。138每次新分配一個SCI，或更新一個已有SCI的標識，或一項變更配置狀態(tài)報告可以放在一個聯(lián)機數(shù)據(jù)庫中，以便軟件開發(fā)人員或者軟件維護人員可以對它進行查詢或修改。此外在軟件配置報告中新登錄的變更應(yīng)當及時通知給管理人員和軟件工程師。配置狀態(tài)報告對于大型軟件開發(fā)項目的成功起著至關(guān)重要的作用。避免了可能出現(xiàn)的不一致和沖突。139配置狀態(tài)報告可以放在一個聯(lián)機數(shù)據(jù)庫中，以便軟件開發(fā)人員或者軟配置審計軟件的完整性，是指開發(fā)后期的軟件產(chǎn)品能夠正確地反映用戶要求。軟件配置審計的目的就是要

證實整個軟件生存期中各項產(chǎn)品在技術(shù)上和管理上的完整性。確保所有文檔的內(nèi)容變動不超出當初確定的軟件要求范圍。使得軟件配置具有良好的可跟蹤性。140配置審計軟件的完整性，是指開發(fā)后期的軟件產(chǎn)品能夠正確地反映用軟件配置審計是軟件變更控制人員掌握配置情況、進行審批的依據(jù)。軟件的變更控制機制通常只能跟蹤到工程變更順序產(chǎn)生為止。為確認變更是否正確完成?一般可以用以下兩種方法去審查：

正式技術(shù)評審軟件配置審計141軟件配置審計是軟件變更控制人員掌握配置情況、進行審批的依據(jù)。正式的技術(shù)評審著重檢查已完成修改的軟件配置對象的技術(shù)正確性，評審者評價SCI，決定它與其它SCI的一致性，是否有遺漏或可能引起的副作用。正式技術(shù)評審應(yīng)對所有的變更進行，除了那些最無價值的變更之外。軟件配置審計作為正式技術(shù)評審的補充，評價在評審期間通常沒有被考慮的SCI的特性。142正式的技術(shù)評審著重檢查已完成修改的軟件配置對象的技術(shù)正確性，軟件質(zhì)量概念軟件質(zhì)量保證軟件可靠性軟件配置管理軟件質(zhì)量管理143軟件質(zhì)量概念軟件質(zhì)量管理1軟件質(zhì)量概念軟件質(zhì)量的定義軟件質(zhì)量特性軟件質(zhì)量模型軟件質(zhì)量的度量和評價144軟件質(zhì)量概念軟件質(zhì)量的定義2軟件質(zhì)量的定義ANSI/IEEEStd729-1983定義軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。M.J.Fisher定義軟件質(zhì)量為“所有描述計算機軟件優(yōu)秀程度的特性的組合”。145軟件質(zhì)量的定義ANSI/IEEEStd729-1983定質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件的各項精確定義的功能、性能需求，符合文檔化的開發(fā)標準，需要相應(yīng)地給出或設(shè)計一些質(zhì)量特性及其組合。如果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，則這個軟件產(chǎn)品質(zhì)量就是高的。146質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。標準定義了一組開發(fā)準則，用來指導(dǎo)軟件人員用工程化的方法來開發(fā)軟件。如果不遵守這些開發(fā)準則，軟件質(zhì)量就得不到保證。軟件質(zhì)量是各種特性的復(fù)雜組合。它隨著應(yīng)用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。

147軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)量，問題最終要歸結(jié)到定義軟件的質(zhì)量特性。定義一個軟件的質(zhì)量，就等價于為該軟件定義一系列質(zhì)量特性。人們通常把影響軟件質(zhì)量的特性用軟件質(zhì)量模型來描述。148軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)軟件質(zhì)量模型軟件質(zhì)量特性定義成分層模型最基本的叫做基本質(zhì)量特性，它可以由一些子質(zhì)量特性定義和度量。二次特性在必要時又可由它的一些子質(zhì)量特性定義和度量。1976年Boehm質(zhì)量模型1979年McCall質(zhì)量模型1985年ISO質(zhì)量模型149軟件質(zhì)量模型軟件質(zhì)量特性定義成分層模型71508ISO的軟件質(zhì)量評價模型按照ISO/TC97/SC7/WG3/1985-1-30/N382，軟件質(zhì)量度量模型由三層組成軟件質(zhì)量需求評價準則（SQRC）軟件質(zhì)量設(shè)計評價準則（SQDC）軟件質(zhì)量度量評價準則（SQMC）高層和中層建立國際標準，低層可由各使用單位視實際情況制定151ISO的軟件質(zhì)量評價模型按照ISO/TC97/SC7/WG3Boehm質(zhì)量模型152Boehm質(zhì)量模型10153111991年ISO質(zhì)量特性國際標準（ISO/IEC9126）質(zhì)量特性：功能性、可靠性、可維護性、效率、可使用性、可移植性推薦21個子特性：適合性準確性互用性依從性安全性成熟性容錯性可恢復(fù)性可理解性易學(xué)習性操作性時間特性資源特性可分析性穩(wěn)定性可變更性可測試性可安裝性可替換性適應(yīng)性一致性1541991年ISO質(zhì)量特性國際標準（ISO/IEC912615513軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量是利用定量或定性的方法，估算軟件質(zhì)量的評價值，以得到軟件質(zhì)量的比較精確的估算值。驗收度量是在軟件開發(fā)各階段的檢查點，對軟件的要求質(zhì)量進行確認性檢查的具體評價值，它是對開發(fā)過程中的預(yù)測進行評價。156軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量有兩種。第一種叫做尺度度量，這是一種定量度量。它適用于一些能夠直接度量的特性，例如，出錯率定義為：錯誤數(shù)／KLOC／單位時間。第二種叫做二元度量，這是一種定性度量。它適用于一些只能間接度量的特性，例如，可使用性、靈活性等等。157預(yù)測度量有兩種。15尺度度量檢查表158尺度度量檢查表16二元度量檢查表159二元度量檢查表17通過對照檢查項目，確定一種質(zhì)量特性的有無。例如，在設(shè)計和編碼階段的復(fù)雜性度量，利用尺度度量方法來做。對模塊復(fù)雜性的度量采用McCabe環(huán)路度量。對于二元度量，可針對檢查表中每一項都應(yīng)給以記分，指定信息存在時記“1”，否則記“0”。表中所有各項的分數(shù)相加，即得度量結(jié)果。160通過對照檢查項目，確定一種質(zhì)量特性的有無。18軟件的質(zhì)量保證質(zhì)量保證的概念軟件質(zhì)量保證的主要任務(wù)質(zhì)量保證與檢驗軟件質(zhì)量保證體系質(zhì)量保證的實施軟件的質(zhì)量設(shè)計161軟件的質(zhì)量保證質(zhì)量保證的概念19質(zhì)量保證的概念什么是質(zhì)量保證，它是為保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進行的有計劃、有組織的活動。質(zhì)量保證是面向消費者的活動，是為了使產(chǎn)品實現(xiàn)用戶要求的功能，站在用戶立場上來掌握產(chǎn)品質(zhì)量的。軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品。162質(zhì)量保證的概念什么是質(zhì)量保證，它是為保證產(chǎn)品和服務(wù)充分滿足消軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動。即為了確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、有系統(tǒng)的管理活動。163軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品軟件質(zhì)量保證的主要任務(wù)為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件質(zhì)量保證的主要任務(wù)大致可歸結(jié)為8點。

164軟件質(zhì)量保證的主要任務(wù)為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件1.用戶要求定義熟練掌握正確定義用戶要求的技術(shù)熟練使用和指導(dǎo)他人使用定義軟件需求的支持工具重視領(lǐng)導(dǎo)全體開發(fā)人員收集和積累有關(guān)用戶業(yè)務(wù)領(lǐng)域的各種業(yè)務(wù)的資料和技術(shù)技能。1651.用戶要求定義熟練掌握正確定義用戶要求的技術(shù)232.力爭不重復(fù)勞動考慮哪些既有軟件可以復(fù)用在開發(fā)過程中，隨時考慮所生產(chǎn)軟件的復(fù)用性。1662.力爭不重復(fù)勞動考慮哪些既有軟件可以復(fù)用243.掌握開發(fā)新軟件的方法在開發(fā)新軟件的過程中大力使用和推行軟件工程學(xué)中所介紹的開發(fā)方法和工具。

使用先進的開發(fā)技術(shù)：如結(jié)構(gòu)化技術(shù)、面向?qū)ο蠹夹g(shù)使用數(shù)據(jù)庫技術(shù)或網(wǎng)絡(luò)化技術(shù)應(yīng)用開發(fā)工具或環(huán)境改進開發(fā)過程1673.掌握開發(fā)新軟件的方法在開發(fā)新軟件的過程中大力使用和推行4.組織外部力量協(xié)作的方法一個軟件自始至終由同一個軟件開發(fā)單位來開發(fā)，也許是最理想的。但在現(xiàn)實中常常難以做到。改善對外部協(xié)作部門的開發(fā)管理。必須明確規(guī)定進度管理、質(zhì)量管理、交接檢查、維護體制等各方面的要求，建立跟蹤檢查的體制。1684.組織外部力量協(xié)作的方法一個軟件自始至終由同一個軟件開發(fā)5.排除無效勞動最大的無效勞動就是因需求規(guī)格說明有誤、設(shè)計有誤而造成的返工。定量記錄返工工作量，收集和分析返工勞動花費數(shù)據(jù)較大的無效勞動是重復(fù)勞動，即相似的軟件在幾個地方同時開發(fā)建立互相交流、信息往來通暢、具橫向交流特征的信息流通網(wǎng)1695.排除無效勞動最大的無效勞動就是因需求規(guī)格說明有誤、設(shè)計6.發(fā)揮每個開發(fā)者的能力軟件生產(chǎn)是人的智能生產(chǎn)活動，它依賴于人的能力和開發(fā)組織團隊的能力。開發(fā)者必須有學(xué)習各專業(yè)業(yè)務(wù)知識、生產(chǎn)技術(shù)和管理技術(shù)的能動性。管理者或產(chǎn)品服務(wù)者要制定技術(shù)培訓(xùn)計劃、技術(shù)水平標準，以及適用于將來需要的中長期技術(shù)培訓(xùn)計劃。

1706.發(fā)揮每個開發(fā)者的能力軟件生產(chǎn)是人的智能生產(chǎn)活動，它依賴7.提高軟件開發(fā)的工程能力要想生產(chǎn)出高質(zhì)量的軟件產(chǎn)品必須有高水平的軟件工程能力。在軟件開發(fā)環(huán)境或軟件工具箱的支持下，運用先進的開發(fā)技術(shù)、工具和管理方法開發(fā)軟件的能力。

1717.提高軟件開發(fā)的工程能力要想生產(chǎn)出高質(zhì)量的軟件產(chǎn)品必須有8.提高計劃和管理質(zhì)量能力項目開發(fā)初期計劃階段的項目計劃評價計劃執(zhí)行過程中及計劃完成報告的評價將評價、評審工作在工程實施之前就列入整個開發(fā)工程的工程計劃中提高軟件開發(fā)項目管理的精確度1728.提高計劃和管理質(zhì)量能力項目開發(fā)初期計劃階段的項目計劃評質(zhì)量保證與檢驗其一是切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量保證活動開展得如何；其二是預(yù)先防止軟件差錯給用戶造成損失。為了確保每個開發(fā)過程的質(zhì)量，防止把軟件差錯傳遞到下一個過程，必須進行質(zhì)量檢驗。173質(zhì)量保證與檢驗其一是切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量檢驗的原則用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”?？抠|(zhì)量檢驗，一般檢查的是“真質(zhì)量”的質(zhì)量特性。能靠質(zhì)量檢驗的質(zhì)量特性，即使全數(shù)檢驗，也只是代表產(chǎn)品的部分質(zhì)量特性。必須在各開發(fā)階段對影響產(chǎn)品質(zhì)量的因素進行切實的管理，認真檢查實施落實情況。

174質(zhì)量檢驗的原則用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”。當開發(fā)階段出現(xiàn)異常時，要從質(zhì)量特性方面進行檢驗，看是否會給后續(xù)階段帶來影響。雖然各開發(fā)階段進展穩(wěn)定，但由于工程能力不足，軟件產(chǎn)品不能滿足用戶要求的質(zhì)量。這時可通過檢驗對該產(chǎn)品做出評價，判斷是否能向用戶提供該產(chǎn)品。要以一定的標準檢驗產(chǎn)品，根據(jù)產(chǎn)品的質(zhì)量特性，檢查各個過程的管理狀態(tài)。175當開發(fā)階段出現(xiàn)異常時，要從質(zhì)量特性方面進行檢驗，看是否會給后軟件質(zhì)量保證體系軟件的質(zhì)量保證活動，是涉及各個部門的部門間的活動。例如，如果在用戶處發(fā)現(xiàn)了軟件故障，產(chǎn)品服務(wù)部門就應(yīng)聽取用戶的意見，再由檢查部門調(diào)查該產(chǎn)品的檢驗結(jié)果，進而還要調(diào)查軟件實現(xiàn)過程的狀況，并根據(jù)情況檢查設(shè)計是否有誤，不當之處加以改進，防止再次發(fā)生問題。176軟件質(zhì)量保證體系軟件的質(zhì)量保證活動，是涉及各個部門的部門間的為了順利開展以上活動，事先明確部門間的質(zhì)量保證業(yè)務(wù)，確立部門間的聯(lián)合與協(xié)作的機構(gòu)十分重要，這個機構(gòu)就是質(zhì)量保證體系。必須明確反饋途徑。必須明確各部門的職責。必須確定保證系統(tǒng)運行的方法、工具、有關(guān)文檔資料，以及系統(tǒng)管理的規(guī)程和標準。177為了順利開展以上活動，事先明確部門間的質(zhì)量保證業(yè)務(wù)，確立部門必須明確決定是否可向下一階段進展的評價項目和評價準則。必須不斷地總結(jié)系統(tǒng)管理的經(jīng)驗教訓(xùn)，能夠修改系統(tǒng)。制定質(zhì)量保證計劃，在計劃中確定質(zhì)量目標確定在每個階段為達到總目標所應(yīng)達到的要求確定進度安排確定所需人力、資源和成本等。178必須明確決定是否可向下一階段進展的評價項目和評價準則。36軟件質(zhì)量保證規(guī)程和技術(shù)準則規(guī)定在項目的哪個階段進行評審及如何評審；規(guī)定在項目的哪個階段應(yīng)當產(chǎn)生哪些報告和計劃；規(guī)定產(chǎn)品各方面測試應(yīng)達到的水平。在每次評審和測試中發(fā)現(xiàn)的錯誤如何修正；179軟件質(zhì)量保證規(guī)程和技術(shù)準則規(guī)定在項目的哪個階段進行評審及如何描述希望得到的質(zhì)量度量；說明各種軟件人員的職責，規(guī)定為了達到質(zhì)量目標他們必須進行哪些活動。建立在各階段中執(zhí)行質(zhì)量評價的質(zhì)量評價和質(zhì)量檢查系統(tǒng)有效運用質(zhì)量信息的質(zhì)量信息系統(tǒng)，并使其運行。180描述希望得到的質(zhì)量度量；38質(zhì)量保證的實施軟件質(zhì)量保證的實施需要從縱向和橫向兩個方面展開。

要求所有與軟件生存期有關(guān)的人員都要參加要求對產(chǎn)品形成的全過程進行質(zhì)量管理這要求整個軟件部門齊心協(xié)力，不斷完善軟件的開發(fā)環(huán)境。此外還需要與用戶共同合作。181質(zhì)量保證的實施軟件質(zhì)量保證的實施需要從縱向和橫向兩個方面展開質(zhì)量目標與度量為了開發(fā)高質(zhì)量的軟件，需要明確軟件的功能，明確軟件應(yīng)達到什么樣的質(zhì)量標準，即質(zhì)量目標。為了達到這個目標，在開發(fā)過程中的各個階段進行檢查和評價。在做質(zhì)量評價時，需要有對質(zhì)量進行度量的準則和方法。需要有在軟件生存期中如何使用這些準則和方法的質(zhì)量保證步驟，以及提高該項作業(yè)效率的工具182質(zhì)量目標與度量為了開發(fā)高質(zhì)量的軟件，需要明確軟件的功能，明確軟件質(zhì)量度量和保證的條件適應(yīng)性：適應(yīng)各種用戶、軟件類型易學(xué)性：不需要特殊技術(shù)，易掌握可靠性：同個軟件的評價結(jié)果一致針對性：設(shè)計階段就確立質(zhì)量目標，在各個階段實施落實?？陀^性：經(jīng)濟性：183軟件質(zhì)量度量和保證的條件適應(yīng)性：適應(yīng)各種用戶、軟件類型41質(zhì)量保證活動的實施步驟：Target：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準則、質(zhì)量設(shè)計準則的各質(zhì)量特性設(shè)定質(zhì)量目標。Plan：設(shè)定適合于被開發(fā)軟件的評測檢查項目(質(zhì)量評價準則)。研討實現(xiàn)質(zhì)量目標的方法或手段。Do：制作高質(zhì)量的規(guī)格說明和程序。在接受質(zhì)量檢查前先做自我檢查。184質(zhì)量保證活動的實施步驟：Target：以用戶要求和開發(fā)方針為Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價。計算結(jié)果用質(zhì)量圖的形式表示出來。比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標，看其是否合格。Action：對評價發(fā)現(xiàn)的問題進行改進活動，如果實現(xiàn)并達到了質(zhì)量目標就轉(zhuǎn)入下一個工程階段。這樣重復(fù)“Plan”到“Action”的過程，直到整個開發(fā)項目完成。185Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價。計算結(jié)186441874518846軟件的質(zhì)量設(shè)計質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)在軟件定義階段，必須定義對軟件的質(zhì)量需求。即確定軟件的質(zhì)量特性及必需的評價準則，并定量地設(shè)定其必須達到的質(zhì)量水平在以后軟件開發(fā)的每一階段結(jié)束時，要算出評價的分數(shù)，然后與目標值加以對照，以評估在這一階段開發(fā)的軟件質(zhì)量是否達到要求。

189軟件的質(zhì)量設(shè)計質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)47為了實現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)的特性。例如，軟件質(zhì)量需求中的“性能”，可以轉(zhuǎn)換成軟件內(nèi)部結(jié)構(gòu)中的構(gòu)成元素，即每一個程序模塊和物理數(shù)據(jù)各自應(yīng)具有的性能特性。這些性能特性的累積就形成外部規(guī)格中的性能特性。190為了實現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部軟件的結(jié)構(gòu)特性與評價標準結(jié)構(gòu)特性邏輯數(shù)據(jù)層次評價標準全部數(shù)據(jù)元素定義完畢所有層次的操作符定義完畢結(jié)構(gòu)特性功能層次評價標準

全部功能元素定義完畢所有層次的操作符定義完畢191軟件的結(jié)構(gòu)特性與評價標準結(jié)構(gòu)特性邏輯數(shù)據(jù)層次49結(jié)構(gòu)特性邏輯數(shù)據(jù)與功能的對應(yīng)關(guān)系評價準則所有數(shù)據(jù)都與功能對應(yīng)所有功能元素都與數(shù)據(jù)對應(yīng)邏輯數(shù)據(jù)與功能的相互關(guān)系個數(shù)（局部）192結(jié)構(gòu)特性邏輯數(shù)據(jù)與功能的對應(yīng)關(guān)系50

結(jié)構(gòu)特性物理數(shù)據(jù)層次評價準則全部數(shù)據(jù)元素定義完畢物理數(shù)據(jù)之間的所有指針定義完畢上述指針都具有層次性193結(jié)構(gòu)特性物理數(shù)據(jù)層次51結(jié)構(gòu)特性模塊層次評價準則

所有模塊定義完畢模塊之間所有控制關(guān)系定義完畢上述關(guān)系都是標準過程調(diào)用形式各層次上的模塊大小適當194結(jié)構(gòu)特性模塊層次52結(jié)構(gòu)特性

物理數(shù)據(jù)與模塊的對應(yīng)關(guān)系評價準則所有物理數(shù)據(jù)都與模塊對應(yīng)所有模塊都與物理數(shù)據(jù)對應(yīng)對應(yīng)于一個物理數(shù)據(jù)的模塊數(shù)（以一對一為好）195結(jié)構(gòu)特性53結(jié)構(gòu)特性

邏輯數(shù)據(jù)與物理數(shù)據(jù)的對應(yīng)關(guān)系評價準則所有邏輯數(shù)據(jù)都與物理數(shù)據(jù)對應(yīng)對應(yīng)于一個物理數(shù)據(jù)的邏輯數(shù)據(jù)數(shù)（以一對一為好）196結(jié)構(gòu)特性54結(jié)構(gòu)特性功能與模塊的對應(yīng)關(guān)系評價準則所有功能都與模塊對應(yīng)對應(yīng)模塊的功能個數(shù)（以一對 一為好）197結(jié)構(gòu)特性55軟件可靠性軟件生存期與軟件壽命的關(guān)系在軟件工程中常用的定義軟件可靠性定義測試中的可靠性分析測試精確度和測試覆蓋度的評價198軟件可靠性軟件生存期與軟件壽命的關(guān)系56軟件生存期與軟件壽命的關(guān)系一切有生命的東西都有一個“壽命”這個概念也可以延伸到對非生命產(chǎn)品的質(zhì)量評價上來。例如一個電子產(chǎn)品的壽命就是指該產(chǎn)品從出廠直到喪失使用價值的持續(xù)時間。從軟件工程的角度來說，軟件產(chǎn)品的壽命是指軟件的整個生存期。199軟件生存期與軟件壽命的關(guān)系一切有生命的東西都有一個“壽命”5從軟件用戶的角度來看，更關(guān)心的是軟件在交付使用后的情況如何。希望用一個指標平均失效間隔時間

MTBF(MeanTimeBetweenFailure)來表明，在規(guī)定的要求和條件下，能在多大的程度上依賴這個軟件來完成任務(wù)。我們把在使用期間軟件能夠正常工作的持續(xù)時間叫做軟件的使用壽命。200從軟件用戶的角度來看，更關(guān)心的是軟件在交付使用后的情況如何。軟件的使用壽命與輸入環(huán)境有關(guān)。例如，有一個存在缺陷的編譯程序，當用于學(xué)生做簡單練習時，MTBF可能很長。而做一個大的課題時，由于程序連續(xù)出錯，MTBF就會變得很短。MTBF可以看做是對軟件可靠性做估計的樣本數(shù)據(jù)，但不能看做是依據(jù)。201軟件的使用壽命與輸入環(huán)境有關(guān)。59“錯誤”這一術(shù)語。在沒有特別加以說明的情況下，這是一個泛用的、模糊的概念。它指的可能是bug(設(shè)計中的差錯)、fault(故障)、error(錯誤)、failure(失效)、crash(重大事故)、problem(疑問)等。在漢譯中，這些術(shù)語的使用更加混亂。202“錯誤”這一術(shù)語。在沒有特別加以說明的情況下，這是一個泛用的在軟件工程中常用的定義故障(fault)：軟件的內(nèi)在缺陷。這些缺陷可在生存期各個階段被引入。錯誤(error)：故障在一定的環(huán)境條件下的暴露，導(dǎo)致系統(tǒng)在運行中出現(xiàn)了不正常、不正確、不按規(guī)范執(zhí)行的狀態(tài)，稱為軟件出錯。失效(failure)：對錯誤不做任何修正和恢復(fù)，導(dǎo)致系統(tǒng)的輸出不滿足用戶要求，稱為軟件的一次失效。

203在軟件工程中常用的定義故障(fault)：軟件的內(nèi)在缺陷。這以上定義的故障、錯誤和失效，分別代表了廣義的“錯誤”在不同的條件下所對應(yīng)的術(shù)語。它們可以理解為：設(shè)計者的失誤─導(dǎo)致系統(tǒng)中留有錯誤的設(shè)計──缺陷或“故障”(fault)，這些故障導(dǎo)致系統(tǒng)的錯誤執(zhí)行──錯誤(error)，由于錯誤導(dǎo)致系統(tǒng)的錯誤輸出──失效(failure)。204以上定義的故障、錯誤和失效，分別代表了廣義的“錯誤”在不同的故障是物理地或靜態(tài)地存在的失誤、錯誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象軟件發(fā)生失效標志著軟件一次使用壽命的結(jié)束發(fā)生過失效的軟件通常仍然是可用的。只有當軟件頻繁失效，或者公認已經(jīng)“過時”了的時侯，軟件才被廢棄，意味著當前這一版本軟件使用壽命的終結(jié)。205故障是物理地或靜態(tài)地存在的63軟件故障產(chǎn)生原因支持軟件工作的基本條件(除硬件外的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、編譯程序、微代碼等)的缺陷軟件設(shè)計不當加入了允許范圍之外的輸入206軟件故障產(chǎn)生原因支持軟件工作的基本條件(除硬件外的操作系統(tǒng)、軟件可靠性的定義軟件可靠性是軟件在給定的時間間隔及給定的環(huán)境條件下，按設(shè)計要求，成功地運行程序的概率。環(huán)境條件─指的是軟件的使用環(huán)境。無論是什么軟件，如果不對它的使用環(huán)境加以限制，都是會失效的。這種失效的數(shù)據(jù)，不能用來度量軟件的可靠性。207軟件可靠性的定義軟件可靠性是軟件在給定的時間間隔及給定的環(huán)境規(guī)定的時間─在定義中，一般采用“運行時間”t

作為時間的尺度。因

具體要處理的問題是多種多樣的其對應(yīng)的輸入環(huán)境是隨機程序中相應(yīng)程序路徑的選取也是隨機的軟件的失效也是隨機的應(yīng)當把運行時間t當作隨機變量來考慮。208規(guī)定的時間─在定義中，一般采用“運行時間”t作為時間的尺規(guī)定的功能─在考慮軟件可靠性時，首先應(yīng)當明確軟件的功能是什么，哪些功能是主要的，哪些功能是次要的。一般從軟件需求分析說明書和設(shè)計說明書中可以了解這些情況。由于功能不同，失效帶來的損失就不一樣。因此，還要明確哪些失效是致命的，哪些失效是非致命的，哪些又是容易修復(fù)的。此外，還要明確，怎樣才算是完成了一個規(guī)定的功能。209規(guī)定的功能─在考慮軟件可靠性時，首先應(yīng)當明確軟件的功能是什么成功地運行程序─是指不僅程序能正確地運行，滿足用戶對它的功能要求，而且當程序一旦受到意外的傷害，或系統(tǒng)故障時，能盡快恢復(fù)，仍能正常地運行。

210成功地運行程序─是指不僅程序能正確地運行，滿足用戶對它的功能測試中的可靠性分析在軟件開發(fā)的過程中，利用測試的統(tǒng)計數(shù)據(jù)，估算軟件的可靠性，以控制軟件的質(zhì)量是至關(guān)重要的。推測錯誤的產(chǎn)生頻度，即推測錯誤產(chǎn)生的時間間隔推測殘留在程序中的錯誤數(shù)