【正文】 為確認(rèn)變更是否正確完成 ? 一般可以用以下兩種方法去審查： ? 正式技術(shù)評審 ? 軟件配置審計 142 ? 正式的技術(shù)評審 著重 檢查已完成修改的軟件配置對象的技術(shù)正確性 ， ? 評審者 評價 SCI，決定它與其它 SCI的一致性，是否有遺漏或可能引起的副作用。 ? 配置狀態(tài)報告對于大型軟件開發(fā)項目的成功起著至關(guān)重要的作用。以后如果需要對它變更，就必須得到項目負(fù)責(zé)人的批準(zhǔn)，或者必須得到變更控制負(fù)責(zé)人的批準(zhǔn)。 133 ? 為了增加或者刪掉某些功能、或者為了改變完成某個功能的方法而需要的變更 。如果需要長時間工作于某個文件，最好能 創(chuàng)建一個分支 ，并在分支上做工作。 120 版本管理的主要任務(wù) ? 集中管理檔案，安全授權(quán)機(jī)制 ： ? 版本管理的操作 將開發(fā)組的檔案集中地存放在服務(wù)器上 ， 經(jīng)系統(tǒng)管理員授權(quán)給各個用戶 。 ? 版本管理可以把 一些屬性結(jié)合到各個軟件版本 上。 (兩個復(fù)合對象之間的相互聯(lián)系 ) data model interrelated test case class m。 ? 資源 包括由對象 產(chǎn)生的 、 處理的 、 引用的 或 其它需要 的 一些實體 。 109 配置標(biāo)識 ? 一方面隨著軟件生存期的向前推進(jìn)，SCI的數(shù)量不斷增多 。因為要使用這些工具來生成文檔、程序和數(shù)據(jù)，如果編譯程序的版本不同，可能產(chǎn)生的結(jié)果也不同。 ? 例如，把一個 名為 B的 SCI從項目數(shù)據(jù)庫復(fù)制到工程師的專用工作區(qū)中 。 ? 隨著軟件工程過程的進(jìn)展， 軟件配置項(SCI)數(shù)目快速增加。 m t N bt e bt( ) ( ( ) )? ? ? ?1 193 ? 實驗表明： ? 對于一般功能單純的小規(guī)模的程序模塊，具有時間延遲的NHPP模型比較合適； ? 對于功能比較復(fù)雜的程序模塊，S型 NHPP模型比較合適； ? 對于 80000行以上的程序，最基本的指數(shù)型 NHPP模型比較合適。 86 ? 用 ns 表示 經(jīng)過相當(dāng)長時間測試可能發(fā)現(xiàn)的播種故障數(shù) ，用 Ns 表示測試對象軟件內(nèi) 預(yù)先埋設(shè)的播種故障總數(shù) ,用平均值為m(t)的 NHPP模型 描述測試時發(fā)現(xiàn)播種故障的過程 ? m(t)的收斂值 m(?)＝ N ? 測試精確度 Ac的推測值： A c ? ???nNmNNNss s s( )87 ? 若設(shè)測試過程中到時刻 ti 能發(fā)現(xiàn)的累積播種故障總數(shù)為 yi ，則在測試期間可得到一連串?dāng)?shù)據(jù) (t0, 0), (t1, y1), ……, ( tm, ym) ? 可得到一組方程： ? 應(yīng)用最小二乘法可得到參數(shù) N 與 b的估計值，并得到測試精確度 Ac。 ? 當(dāng) N一定時， b越大，在短期內(nèi)發(fā)現(xiàn)的故障越多。 68 ? 成功地運(yùn)行程序 ─是指不僅程序能正確地運(yùn)行，滿足用戶對它的功能要求， 而且當(dāng)程序一旦受到意外的傷害，或系統(tǒng)故障時，能盡快恢復(fù)，仍能正常地運(yùn)行。這種失效的數(shù)據(jù)，不能用來度量軟件的可靠性。 ? 失效 (failure)： 對錯誤不做任何修正和恢復(fù)， 導(dǎo)致系統(tǒng)的輸出不滿足用戶要求 ，稱為軟件的一次失效。 ? MTBF可以看做是對軟件可靠性做估計的樣本數(shù)據(jù)，但不能看做是依據(jù)。例如一個電子產(chǎn)品的壽命就是指該產(chǎn)品從出廠直到喪失使用價值的持續(xù)時間。 ? Action： 對 評價發(fā)現(xiàn)的問題進(jìn)行改進(jìn)活動 ，如果實現(xiàn)并達(dá)到了質(zhì)量目標(biāo)就轉(zhuǎn)入下一個工程階段。 ? 客觀性： ? 經(jīng)濟(jì)性： 42 質(zhì)量保證活動的實施步驟： ? Target：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準(zhǔn)則、質(zhì)量設(shè)計準(zhǔn)則的各質(zhì)量特性設(shè)定質(zhì)量目標(biāo)。 ? 建立 ? 在各階段中執(zhí)行質(zhì)量評價的 質(zhì)量評價和質(zhì)量檢查系統(tǒng) ? 有效運(yùn)用質(zhì)量信息的 質(zhì)量信息系統(tǒng) ，并使其運(yùn)行。 ? 必須 明確反饋途徑 。 ? 必須 在各開發(fā)階段對影響產(chǎn)品質(zhì)量的因素進(jìn)行切實的管理 ，認(rèn)真檢查實施落實情況。 ? 管理者 或 產(chǎn)品服務(wù)者 要 制定技術(shù)培訓(xùn)計劃 、 技術(shù)水平標(biāo)準(zhǔn) ，以及 適用于將來需要的中長期技術(shù)培訓(xùn)計劃 。 25 3. 掌握開發(fā)新軟件的方法 ? 在開發(fā)新軟件的過程中大力使用和推行軟件工程學(xué)中所介紹的開發(fā)方法和工具。 19 軟件的質(zhì)量保證 ? 質(zhì)量保證的概念 ? 軟件質(zhì)量保證的主要任務(wù) ? 質(zhì)量保證與檢驗 ? 軟件質(zhì)量保證體系 ? 質(zhì)量保證的實施 ? 軟件的質(zhì)量設(shè)計 20 質(zhì)量保證的概念 ? 什么是質(zhì)量保證，它是 為保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進(jìn)行的有計劃、有組織的活動 。它適用于一些能夠直接度量的特性，例如，出錯率定義為：錯誤數(shù)／ KLOC／單位時間 。 ? 人們通常把影響軟件質(zhì)量的特性用軟件質(zhì)量模型來描述 。不符合需求的軟件就不具備質(zhì)量。 4 質(zhì)量特性及其組合 ， 是軟件開發(fā)與維護(hù)中的重要考慮因素 ? 為滿足軟件的各項精確定義的功能、性能需求，符合文檔化的開發(fā)標(biāo)準(zhǔn)，需要相應(yīng)地給出或設(shè)計一些質(zhì)量特性及其組合。 6 軟件質(zhì)量特性 ? 軟件質(zhì)量特性，反映了軟件的本質(zhì) 。 ? 驗收度量 是在軟件開發(fā)各階段的檢查點，對軟件的要求質(zhì)量進(jìn)行確認(rèn)性檢查的具體評價值，它是對開發(fā)過程中的預(yù)測進(jìn)行評價。對模塊復(fù)雜性的度量采用 McCabe 環(huán)路度量。 22 軟件質(zhì)量保證的主要任務(wù) ?為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件質(zhì)量保證的主要任務(wù)大致可歸結(jié)為 8點。 27 5. 排除無效勞動 ? 最大的無效勞動就是 因需求規(guī)格說明有誤 、 設(shè)計有誤 而造成的 返工 。 32 質(zhì)量檢驗的原則 ? 用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”。 34 軟件質(zhì)量保證體系 ? 軟件的質(zhì)量保證活動，是涉及各個部門的部門間的活動。 ? 制定質(zhì)量保證計劃 ，在計劃中 ? 確定 質(zhì)量目標(biāo) ? 確定 在每個階段為達(dá)到總目標(biāo)所應(yīng)達(dá)到的要求 ? 確定 進(jìn)度安排 ? 確定 所需人力、資源和成本等 。 ? 為了達(dá)到這個目標(biāo)， 在開發(fā)過程中的各個階段進(jìn)行檢查和評價 。 43 ? Check： 以 Plan階段設(shè)定的質(zhì)量評價準(zhǔn)則進(jìn)行評價。 ? 例如，軟件質(zhì)量需求中的“ 性能 ”，可以轉(zhuǎn)換成軟件內(nèi)部結(jié)構(gòu)中的構(gòu)成元素，即 每一個程序模塊和物理數(shù)據(jù)各自應(yīng)具有的性能特性 。 59 ? 軟件的 使用壽命與輸入環(huán)境有關(guān) 。 61 在軟件工程中常用的定義 ? 故障 (fault)： 軟件的內(nèi)在缺陷 。 64 軟件故障產(chǎn)生原因 ? 支持軟件工作的基本條件 (除硬件外的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、編譯程序、微代碼等 )的缺陷 ? 軟件設(shè)計不當(dāng) ? 加入了允許范圍之外的輸入 65 軟件可靠性的定義 ? 軟件可靠性是軟件在 給定的時間間隔 及給定的環(huán)境條件 下， 按設(shè)計要求 ， 成功地運(yùn)行程序 的概率。 ? 由于功能不同，失效帶來的損失就不一樣。這時有 ? 如果 bi比較顯著 ， 應(yīng)當(dāng)每隔一段時間 ，由兩個測試員再進(jìn)行分別測試 ，分析測試結(jié)果，估算 B0。 測試結(jié)束時軟件產(chǎn)品質(zhì)量水準(zhǔn) 84 ? 測試質(zhì)量的度量可以靠 測試的故障捕捉率和遺漏率 來衡量。 m t N e b t d( ) ( )( )? ? ? ?191 92 ? 測試員從發(fā)現(xiàn)錯誤征兆到確認(rèn)錯誤，需要反復(fù)執(zhí)行程序，以再現(xiàn)錯誤，造成時間拖延。 ? SCM活動的目標(biāo)是為了 (1) 標(biāo)識變更； (2) 控制變更； (3) 確保變更正確地實現(xiàn)； (4) 向其他有關(guān)的人報告變更。 ? 基線的 作用是把各階段工作的劃分更加明確化 ，以便于檢驗和肯定階段成果。 ? 在變更完成、評審和批準(zhǔn)之前，不許對它做任何操作。 106 配置對象 107 ?