【正文】 量保證的概念 ? 什么是質(zhì)量保證，它是 為保證產(chǎn)品和服務(wù)充分滿足消費(fèi)者要求的質(zhì)量而進(jìn)行的有計(jì)劃、有組織的活動(dòng) 。即為了確定、達(dá)到和維護(hù)需要的軟件質(zhì)量而進(jìn)行的所有有計(jì)劃、有系統(tǒng)的管理活動(dòng) 。 25 3. 掌握開發(fā)新軟件的方法 ? 在開發(fā)新軟件的過程中大力使用和推行軟件工程學(xué)中所介紹的開發(fā)方法和工具。必須明確規(guī)定 進(jìn)度管理 、 質(zhì)量管理 、 交接檢查 、 維護(hù)體制 等各方面的要求 ， 建立 跟蹤檢查 的體制 。 ? 管理者 或 產(chǎn)品服務(wù)者 要 制定技術(shù)培訓(xùn)計(jì)劃 、 技術(shù)水平標(biāo)準(zhǔn) ，以及 適用于將來需要的中長期技術(shù)培訓(xùn)計(jì)劃 。 ? 為了 確保每個(gè)開發(fā)過程的質(zhì)量 ，防止把軟件差錯(cuò)傳遞到下一個(gè)過程，必須進(jìn)行質(zhì)量檢驗(yàn)。 ? 必須 在各開發(fā)階段對(duì)影響產(chǎn)品質(zhì)量的因素進(jìn)行切實(shí)的管理 ，認(rèn)真檢查實(shí)施落實(shí)情況。 ? 要以一定的標(biāo)準(zhǔn)檢驗(yàn)產(chǎn)品，根據(jù)產(chǎn)品的質(zhì)量特性，檢查各個(gè)過程的管理狀態(tài)。 ? 必須 明確反饋途徑 。 ? 必須 不斷地總結(jié)系統(tǒng)管理的經(jīng)驗(yàn)教訓(xùn) ， 能夠修改系統(tǒng) 。 ? 建立 ? 在各階段中執(zhí)行質(zhì)量評(píng)價(jià)的 質(zhì)量評(píng)價(jià)和質(zhì)量檢查系統(tǒng) ? 有效運(yùn)用質(zhì)量信息的 質(zhì)量信息系統(tǒng) ，并使其運(yùn)行。 40 質(zhì)量目標(biāo)與度量 ? 為了開發(fā)高質(zhì)量的軟件，需要 明確軟件的功能 ， 明確軟件應(yīng)達(dá)到什么樣的質(zhì)量標(biāo)準(zhǔn) ，即 質(zhì)量目標(biāo) 。 ? 客觀性： ? 經(jīng)濟(jì)性： 42 質(zhì)量保證活動(dòng)的實(shí)施步驟： ? Target：以用戶要求和開發(fā)方針為依據(jù)，對(duì)質(zhì)量需求準(zhǔn)則、質(zhì)量設(shè)計(jì)準(zhǔn)則的各質(zhì)量特性設(shè)定質(zhì)量目標(biāo)。在接受質(zhì)量檢查前先做自我檢查 。 ? Action： 對(duì) 評(píng)價(jià)發(fā)現(xiàn)的問題進(jìn)行改進(jìn)活動(dòng) ，如果實(shí)現(xiàn)并達(dá)到了質(zhì)量目標(biāo)就轉(zhuǎn)入下一個(gè)工程階段。 48 ? 為了實(shí)現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些 質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)的特性 。例如一個(gè)電子產(chǎn)品的壽命就是指該產(chǎn)品從出廠直到喪失使用價(jià)值的持續(xù)時(shí)間。 ? 我們把 在使用期間軟件能夠正常工作的持續(xù)時(shí)間叫做軟件的使用壽命 。 ? MTBF可以看做是對(duì)軟件可靠性做估計(jì)的樣本數(shù)據(jù)，但不能看做是依據(jù)。 ? 在漢譯中，這些術(shù)語的使用更加混亂。 ? 失效 (failure)： 對(duì)錯(cuò)誤不做任何修正和恢復(fù)， 導(dǎo)致系統(tǒng)的輸出不滿足用戶要求 ，稱為軟件的一次失效。只有當(dāng)軟件頻繁失效，或者公認(rèn)已經(jīng)“過時(shí)”了的時(shí)侯，軟件才被廢棄， 意味著當(dāng)前這一版本軟件使用壽命的終結(jié)。這種失效的數(shù)據(jù)，不能用來度量軟件的可靠性。一般從軟件需求分析說明書和設(shè)計(jì)說明書中可以了解這些情況。 68 ? 成功地運(yùn)行程序 ─是指不僅程序能正確地運(yùn)行，滿足用戶對(duì)它的功能要求， 而且當(dāng)程序一旦受到意外的傷害，或系統(tǒng)故障時(shí)，能盡快恢復(fù)，仍能正常地運(yùn)行。 79 ? 在大程序測(cè)試時(shí)，頭幾個(gè)月兩個(gè)測(cè)試員測(cè)試的結(jié)果應(yīng)當(dāng)比較接近， bi 不是很大 。 ? 當(dāng) N一定時(shí)， b越大，在短期內(nèi)發(fā)現(xiàn)的故障越多。 83 ? SPQL (Software Product Quality Level) 用如下公式度量： SPQL ＝ Ac Cv ? 其中， Ac (Test Accuracy) 是 測(cè)試的精確度 ，它反映了測(cè)試的質(zhì)量； Cv (Test Coveragy) 是 測(cè)試的覆蓋度 ，它反映了測(cè)試的數(shù)量。 86 ? 用 ns 表示 經(jīng)過相當(dāng)長時(shí)間測(cè)試可能發(fā)現(xiàn)的播種故障數(shù) ，用 Ns 表示測(cè)試對(duì)象軟件內(nèi) 預(yù)先埋設(shè)的播種故障總數(shù) ,用平均值為m(t)的 NHPP模型 描述測(cè)試時(shí)發(fā)現(xiàn)播種故障的過程 ? m(t)的收斂值 m(?)＝ N ? 測(cè)試精確度 Ac的推測(cè)值： A c ? ???nNmNNNss s s( )87 ? 若設(shè)測(cè)試過程中到時(shí)刻 ti 能發(fā)現(xiàn)的累積播種故障總數(shù)為 yi ，則在測(cè)試期間可得到一連串?dāng)?shù)據(jù) (t0, 0), (t1, y1), ……, ( tm, ym) ? 可得到一組方程： ? 應(yīng)用最小二乘法可得到參數(shù) N 與 b的估計(jì)值，并得到測(cè)試精確度 Ac。 ? 為描述這種情形，對(duì)原來 NHPP的指數(shù)型平均值函數(shù)加以改造： ? 它是 把原來的指數(shù)型平均值函數(shù)在時(shí)間軸上平移而得到的結(jié)果 ， 是具有時(shí)間延遲的 NHPP模型 。 m t N bt e bt( ) ( ( ) )? ? ? ?1 193 ? 實(shí)驗(yàn)表明： ? 對(duì)于一般功能單純的小規(guī)模的程序模塊，具有時(shí)間延遲的NHPP模型比較合適； ? 對(duì)于功能比較復(fù)雜的程序模塊，S型 NHPP模型比較合適； ? 對(duì)于 80000行以上的程序，最基本的指數(shù)型 NHPP模型比較合適。 95 軟件配置管理的概念 ? 軟件配置管理，簡(jiǎn)稱 SCM，是一種“保護(hù)傘”活動(dòng)，它 應(yīng)用于整個(gè)軟件工程過程 。 ? 隨著軟件工程過程的進(jìn)展， 軟件配置項(xiàng)(SCI)數(shù)目快速增加。 ? 由正式的技術(shù)評(píng)審而得到的 SCI協(xié)議和軟件配置的正式文本才能成為基線。 ? 例如，把一個(gè) 名為 B的 SCI從項(xiàng)目數(shù)據(jù)庫復(fù)制到工程師的專用工作區(qū)中 。 100 ? 有些系統(tǒng)中把這個(gè)基線 SCI鎖定。因?yàn)橐褂眠@些工具來生成文檔、程序和數(shù)據(jù)，如果編譯程序的版本不同，可能產(chǎn)生的結(jié)果也不同。箭頭指明了一種構(gòu)造關(guān)系。 109 配置標(biāo)識(shí) ? 一方面隨著軟件生存期的向前推進(jìn)，SCI的數(shù)量不斷增多 。例如，基本對(duì)象可能是需求規(guī)格說明中的一節(jié)，一個(gè)模塊的源程序清單、一組用來測(cè)試一個(gè)等價(jià)類的測(cè)試用例。 ? 資源 包括由對(duì)象 產(chǎn)生的 、 處理的 、 引用的 或 其它需要 的 一些實(shí)體 。 data model is part of Design Specification。 (兩個(gè)復(fù)合對(duì)象之間的相互聯(lián)系 ) data model interrelated test case class m。 115 演變圖 116 ? 在某些工具中，當(dāng)前保持的 只是最后版本的完全副本 。 ? 版本管理可以把 一些屬性結(jié)合到各個(gè)軟件版本 上。 ? 軟件的每一版本都是 SCI（源代碼、文檔、數(shù)據(jù)） 的一個(gè)收集 ，且各個(gè)版本都可能由不同的變種組成。 120 版本管理的主要任務(wù) ? 集中管理檔案，安全授權(quán)機(jī)制 ： ? 版本管理的操作 將開發(fā)組的檔案集中地存放在服務(wù)器上 ， 經(jīng)系統(tǒng)管理員授權(quán)給各個(gè)用戶 。 123 124 ? 加鎖功能 ： ? 目的是 在文件更新時(shí)保護(hù)文件 ，避免不同用戶更改同一文件時(shí)發(fā)生沖突 。如果需要長時(shí)間工作于某個(gè)文件，最好能 創(chuàng)建一個(gè)分支 ，并在分支上做工作。 ? 變更控制包括 建立控制點(diǎn) 和 建立報(bào)告與審查制度 。 133 ? 為了增加或者刪掉某些功能、或者為了改變完成某個(gè)功能的方法而需要的變更 。 ? 如果同意這種變更， 需要進(jìn)一步確定由誰來支付變更所需要的費(fèi)用。以后如果需要對(duì)它變更，就必須得到項(xiàng)目負(fù)責(zé)人的批準(zhǔn)，或者必須得到變更控制負(fù)責(zé)人的批準(zhǔn)。 ? 對(duì)于每一項(xiàng)變更，記錄：發(fā)生了什么？為什么會(huì)發(fā)生？誰做的？什么時(shí)侯發(fā)生的？會(huì)有什么影響？ 137 配置狀態(tài)報(bào)告信息流 138 ? 每次 新分配一個(gè) SCI，或 更新一個(gè)已有SCI的標(biāo)識(shí) ，或 一項(xiàng)變更申請(qǐng)被變更控制負(fù)責(zé)人批準(zhǔn) ， 并給出了一個(gè)工程變更順序 時(shí) ，在配置狀態(tài)報(bào)告中就要增加一條變更記錄條目。 ? 配置狀態(tài)報(bào)告對(duì)于大型軟件開發(fā)項(xiàng)目的成功起著至關(guān)重要的作用。 ? 確保所有文檔的內(nèi)容變動(dòng)不超出當(dāng)初確定的軟件要求范圍。為確認(rèn)變更是否正確完成 ? 一般可以用以下兩種方法去審查： ? 正式技術(shù)評(píng)審 ? 軟件配置審計(jì) 142 ? 正式的技術(shù)評(píng)審 著重 檢查已完成修改的軟件配置對(duì)象的技術(shù)正確性 ， ? 評(píng)審者 評(píng)價(jià) SCI，決定它與其它 SCI的一致性，是否有遺漏或可能引起的副作