【正文】 雙向箭頭則表明一種相互關(guān)系 。 ? 復合對象 ： 是基本對象或其它復合對象的 一個收集 。 ? 就可以建立 SCI的一個層次。 ? 為了得到較早時期 (文檔或程序 )的版本，可以從最后版本中 “提取”出 (由工具編目的 )變更 ，使得 當前配置直接可用 ，并使得 其它版本也可用 。 ? 例如，一個簡單的程序版本由 4和 5等部件組成。 ? 某一文件一旦被 登入 ， 鎖即被解除 ，該文件可被其它用戶使用。 128 變更控制 過程 129 132 軟件變更有兩類不同情況： ? 為改正小錯誤需要的變更 。 如果是用戶要求的變更，則用戶應支付這筆費用；否則，必須完成某種成本／效益分析，以確定是否值得做這種變更。 ? 一旦進行了配置審計，其結(jié)果也應該寫入報告之中。使得軟件配置具有良好的可跟蹤性。 。 ? 軟件配置審計的目的就是要 ? 證實整個軟件生存期中各項產(chǎn)品在技術(shù)上和管理上的完整性。 ? 登錄主要 根據(jù)變更控制小組會議的記錄 ，并產(chǎn)生 配置狀態(tài)報告 。 134 ? 如果變更的代價比較高，或者影響比較大，則必須權(quán)衡利弊，以決定是否進行這種變更。 ? 軟件工程過程中 某一階段的變更 ，均要引起軟件配置的變更 ，這種變更必須嚴格加以 控制 和 管理 ，保持修改信息。 ? 任何版本都可以隨時檢出編輯，同一應用的不同版本可以像樹枝一樣向上增長。 118 119 ? 圖中的各個結(jié)點都是 聚合對象 ，是一個完全的軟件版本 。 ? 對于每一配置對象都可以建立一個演變圖 ，用演變圖記敘對象的 變更歷史 。 ER diagram is part of data model。 110 對象類型 ? 基本對象 ： 是由軟件工程師在分析、設計、編碼和測試時所建立的 文本單元 。 ? 每個對象與其它對象的聯(lián)系用箭頭表示。來更新 B。 97 基線 (Baseline) ? 基線是軟件生存期中各開發(fā)階段末尾的特定點，又稱里程碑。 ? 配置管理是一組標識、組織和控制修改的活動，目的是使錯誤達到最小并最有效地提高生產(chǎn)率。 89 ? 測試過程中 已發(fā)現(xiàn)原有故障總數(shù) 為 n0(實測值 )，經(jīng)過相當長時間測試后 可能發(fā)現(xiàn)的原有故障總數(shù) 為 N0， ? 采用平均值函數(shù) m(t)的 NHPP模型 描述測試發(fā)現(xiàn)原有故障的過程 ? m(t)的收斂值 m(?)＝ Nc ? 測試覆蓋率 Cv的推測值 ： Cv =nNnmnNc000 0???( )90 ? 測試開始后，由于測試員對程序和測試環(huán)境不熟悉，造成拖期。需要從測試的 量的方面 和 質(zhì)的方面 ，全面地評價測試。設 測試用例發(fā)現(xiàn)植入故障和原有故障的能力相同 ，則 程序中原有故障總數(shù) N ( =ET )估算值為 NNnnss?78 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。 67 ? 規(guī)定的功能 ─在考慮軟件可靠性時，首先應當明確 軟件的功能是什么 ， 哪些功能是主要的 ， 哪些功能是次要的 。 63 ? 故障是物理地或靜態(tài)地存在的 ? 失誤、錯誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象 ? 軟件發(fā)生失效標志著軟件一次使用壽命的結(jié)束 ? 發(fā)生過失效的軟件通常仍然是可用的。 ? 它指的可能是 bug(設計中的差錯 )、 fault(故障 )、 error(錯誤 )、 failure(失效 )、crash(重大事故 )、 problem(疑問 )等。 ? 希望用一個指標 平均失效間隔時間 MTBF(MeanTime Between Failure) 來表明，在規(guī)定的要求和條件下，能在多大的程度上依賴這個軟件來完成任務。即確定軟件的質(zhì)量特性及必需的評價準則，并定量地設定其必須達到的質(zhì)量水平 ? 在以后軟件開發(fā)的每一階段結(jié)束時，要算出評價的分數(shù) ，然后與 目標值加以對照 ，以評估在這一階段開發(fā)的軟件質(zhì)量是否達到要求。 ? Do：制作高質(zhì)量的規(guī)格說明和程序。此外還需要與用戶共同合作。 36 ? 必須 明確決定是否可向下一階段進展的評價項目和評價準則 。這時 可通過檢驗對該產(chǎn)品做出評價，判斷是否能向用戶提供該產(chǎn)品 。 30 8. 提高計劃和管理質(zhì)量能力 ? 項目開發(fā)初期 計劃階段的項目計劃評價 ? 計劃執(zhí)行過程中及計劃完成報告的評價 ? 將評價、評審工作在工程實施之前就列入整個開發(fā)工程的工程計劃中 ? 提高軟件開發(fā)項目管理的精確度 31 質(zhì)量保證與檢驗 ? 其一是 切實搞好開發(fā)階段的管理 ，檢查各開發(fā)階段的質(zhì)量保證活動開展得如何； ? 其二是 預先防止軟件差錯給用戶造成損失 。 ? 改善對外部協(xié)作部門的開發(fā)管理。 21 ? 軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是 確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動 。 16 尺度度量檢查表 17 二元度量檢查表 18 ? 通過對照檢查項目，確定一種質(zhì)量特性的有無。 ? 1976年 Boehm質(zhì)量模型 ? 1979年 McCall質(zhì)量模型 ? 1985年 ISO質(zhì)量模型 8 9 ISO的軟件質(zhì)量評價模型 ? 按照 ISO/TC97/SC7/WG3/1985130/N382，軟件質(zhì)量度量模型由三層組成 ? 軟件質(zhì)量需求評價準則 （ SQRC） ? 軟件質(zhì)量設計評價準則 （ SQDC） ? 軟件質(zhì)量度量評價準則 （ SQMC） ? 高層和中層建立國際標準，低層可由各使用單位視實際情況制定 10 Boehm質(zhì)量模型 11 12 1991年 ISO質(zhì)量特性國際標準 （ ISO/IEC9126） ? 質(zhì)量特性： 功能性 、 可靠性 、 可維護性 、效率 、 可使用性 、 可移植性 ? 推薦 21個子特性：適合性 準確性 互用性 依從性 安全性 成熟性 容錯性 可恢復性 可理解性 易學習性 操作性 時間特性 資源特性 可分析性 穩(wěn)定性 可變更性 可測試性 可安裝性 可替換性 適應性 一致性 13 14 軟件質(zhì)量的度量和評價 ? 軟件質(zhì)量特性度量有兩類： 預測型 和 驗收型 。 ? 軟件質(zhì)量是各種特性的復雜組合。1 ?軟件質(zhì)量概念 ?軟件質(zhì)量保證 ?軟件可靠性 ?軟件配置管理 2 軟件質(zhì)量概念 ?軟件質(zhì)量的定義 ?軟件質(zhì)量特性 ?軟件質(zhì)量模型 ?軟件質(zhì)量的度量和評價 3 軟件質(zhì)量的定義 ? ANSI/IEEE Std 7291983定義軟件質(zhì)量為“ 與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體 ”。如果不遵守這些開發(fā)準則，軟件質(zhì)量就得不到保證。 ? 二次特性 在必要時又可由它的一些子質(zhì)量特性定義和度量。它適用于一些只能間接度量的特性，例如，可使用性、靈活性等等 。 ? 軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品。但在現(xiàn)實中常常難以做到。 ? 在軟件開發(fā)環(huán)境或軟件工具箱的支持下 ， 運用先進的開發(fā)技術(shù) 、 工具和管理方法開發(fā)軟件的能力 。 ? 雖然各開發(fā)階段進展穩(wěn)定，但由于工程能力不足，軟件產(chǎn)品不能滿足用戶要求的質(zhì)量。 ? 必須 確定保證系統(tǒng)運行的方法 、工具 、 有關(guān)文檔資料 ，以及 系統(tǒng)管理的