CNS 15014-4-2006 Software engineering - Product evaluation - Part 4：Process for acquirers《软件工程－产品评估－第4部：获取者过程》.pdf

《CNS 15014-4-2006 Software engineering - Product evaluation - Part 4：Process for acquirers《软件工程－产品评估－第4部：获取者过程》.pdf》由会员分享，可在线阅读，更多相关《CNS 15014-4-2006 Software engineering - Product evaluation - Part 4：Process for acquirers《软件工程－产品评估－第4部：获取者过程》.pdf（39页珍藏版）》请在麦多课文档分享上搜索。

1、 1 印月 95 11 月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X3014-415014-4經濟部標準檢驗局印 公布日期 修訂公布日期 95 11 月 16 日 月日 (共 39 頁 )軟體工程產品評估第 4 部 ： 獲取者過程Software engineering Product evaluation Part 4: Process for acquirers 目錄 節次 頁次 導論 2 1. 適用範圍 3 2. 符合性 . 3 3. 引用標準 4 4. 用語釋義 4 5. 軟體產品評估一般考量 4 5.1 評估與獲取過程之間的相關性 . 4

2、 5.2 評估過程的輸入 . 5 5.2.1 系統需求 5 5.2.2 完整性層級需求 6 5.2.3 軟體需求規格 . 6 5.2.4 由其他人員履行的評估 . 6 5.3 裁適 . 7 6.“現成 ”軟體產品之獲取期間的評估 . 7 6.1 步驟 1建立評估需求 8 6.1.1 建立評估目的與範圍 . 8 6.1.2 規定評估需求 . 9 6.2 步驟 2規定評估 . 10 6.2.1 選擇量度 10 6.2.2 選擇評估方法 . 11 6.2.3 由其他人員履行的評估 . 11 6.3 步驟 3設計評估 . 12 6.4 步驟 4執行評估 . 13 6.4.1 執行評估方法 . 13 6

3、.4.2 分析評估結果 . 13 6.4.3 草擬結論 14 7. 客製軟體與現有軟體修改之獲取期間的評估 . 15 7.1 步驟 1建立評估需求 15 7.2 步驟 2規定評估 . 15 2 CNS 15014-4, X 3014-4 7.3 步驟 3設計評估 . 15 7.4 步驗 4執行評估 . 15 附錄 A (參考 )其他標準的用語釋義 16 附錄 B (參考 )表格 22 附錄 C (參考 )圖解 26 附錄 D (參考 )評估方法 . 28 附錄 E (參考 )階段化評估過程的範例 . 33 參考書目 35 英中名詞對照表 . 37 導論 軟體是愈來愈普及。隨著更多過程的自動化以

4、利用電腦的優勢，附加之軟體功能性與無失誤軟體產品的需求 日益增加 。 現今 系統已複雜到缺乏軟體就不能夠履行其功能。因為多種可用產品的成長，及軟體工程技術之快速演化，減少對客製化編碼軟體的依賴，加速商業上可用之 “現成 ”(off-the-shelf)軟體產品的成長。基於現有自我包含之單元函式館延伸的應用系統發展，物件導向發展方法亦降低客製 化編碼軟體的需求(requirement)。如此導致極度地注重共存軟體的產品品質，或自我包含 (self-contained)軟體單元品質。 由於失效 (failure)，客製軟體 (custom software)的發展傾向於重作以符合使用者需求。有關於

5、部署、實作、訓練以及維護支援活動，客製軟體之使用也可能需要比預期更大的工夫 (effort)。商業 “現成 ”軟體產品的獲取，或內部現有軟體產品的再使用亦非無風險。因為 “現成 ”軟體產品可能需要客製化，可能會遭遇問題；測試與分析需求可以是廣泛的；當產品已經是過時的或經過修訂的，產品維護與支援是不明確的；整合軟體產品到較大系統中可能是困難的；且產品品質可能與標的系統之需求品質不一致。 商業 “現成 ”軟體產品極端不同，它們可能是： (a) 獨立使用的產品 (即薪資、會 計軟體、消費者軟體或 縮膜 包裝的軟體 即 文書 處理軟體、試算表 )； (b) 當成 組件，整合 進 由其他軟體與硬體組件所

6、 組 成之較大系統 (即作業系統、關聯式資料庫管理系統、圖形使用者介面 GUI) (c) 內嵌在硬體中 (即通訊資料鏈 、可程式化陣列邏輯 PAL) (d) 內嵌成為可 設定 組態之軟 /硬體系統的一部分，可以被使用在特定應用 系統 發展 (即分散式控制系統 )； (e) CASE 工具，使用在支援軟體發展與維護過程 (即編譯器、組態管理工具 )。 獨立軟體產品的錯誤可能 衝擊 生產力，導致財務損失，或導致不必要的重做。軟體組件可能難以 整合，影響整個系統的可靠度，或與系統目標不相容。 CASE 工具可能會引入錯誤在發展的產品中，或者難以使用。 在獲取期間，或作再使用現有軟體或組件的決策時，能

7、夠評估 (evaluate)軟體產品品質是必要的。可以使用評估以驗收或拒絕單一的產品，或選擇一個產品，以符合替代產 3 CNS 15014-4, X 3014-4 品之標的應用程式所建立的品質需求。評估過程之精確等級必須與產品完整性需求是相當的。當履行 評估關鍵性 軟體產品時，需要最高之 嚴密 等級。 1. 適用範圍 本標準包含現成 (“off-the-shelf”)軟體產品、客製軟體產品，或 現有軟體產品修改的獲取期間，軟體產品品質之系統化的測量、評鑑 (assessment)及評估的需求、建議及指導綱要。本標準使用 CNS 14948-1 所描述的軟體品質模型 (quality model

8、)；詳述本系列標準第 1 部所定義之評估軟體品質的一般過程；使用 CNS 14837 所定義的獲取過程。本標準能夠結合 ISO/IEC 12119、本系列標準第 2 部、第 3 部及第 6 部一起使用。本標準與本系列標準第 5 部之評估過程步驟為是相似的，但使用之全景是相當不同的。在獲取者 (acquirer)委託第二或第三方 (third party)的情況下，要求運用本系列標準第 5 部。在獲取者要求依套件品質需求對照執行軟體套件之第三方測試的情況下，可以運用 ISO/IEC 12119。 本標準所描述之評估過程亦有助於符合決定單一產品的驗收 (acceptance)、或從替代產品中選擇產

9、品的目標。可以裁適評估過程，以適合應用的性質與完整性層級(integrity level)。本標準也是具備充份彈性的，以成本效率方式 順應軟體產品之形式與使用的廣泛範圍。 本標準為專案管理者、系統工程師、發展與維護軟體工程人 員、規劃獲取 (acquire)軟體產品的終端使用者、及提供此類產品的供應者 (supplier)而準備，但不僅限於這些人員。 本標準評估過程之標的軟體產品， 能夠當作組件以 整合成大系 統，或能夠單獨使用。其分類如下： (1) 商業現成軟體產品。 (2) 為了其他應用，或 廣泛共同 應用所發展或獲取的現有軟體產品。 (3) 客製軟體產品或現有軟體產品的修改。 本標準的評

10、估過程也適用於 CASE 工具。因為 ISO/IEC 14102 特別 闡明 CASE 工具的評估，所以 CASE 工具已超過本標準考量的範圍。 本標準設計成與其他標準合作。對於具有高完整性需求的系統，本標準所描述之評估過程可以包括額外的需求，其衍生自範圍 - 特定的標準 ，例如， IEC 880、DOA-167A、 MOD-55 等。 2. 符合性 因為本標準建議之一般性質提供使用者選擇的自由，所以遵循本標準之簡單宣稱是無效的。 採用 本標準作為交易條件的任何組織 有責任規定並公開 符合第 6.1.1 節所規定的必備目標 之評估過程 。已規定之評估過程提供本標準特定 應用的遵循性 章節 。應

11、考量第 6 節與第 7 節之所有活動的應用性。 在獲取過程的執行期間，也能夠以契約建立評估過程的需求。然後，容易建立符合本標準所描述之評估過程的遵循性。 4 CNS 15014-4, X 3014-4 3. 引用標準 CNS 12680 品質管系統基本原與詞彙 CNS 12681 品質管系統要求 CNS 14802 資訊技術 系統與軟體完整性層級 CNS 14948-1 軟體工程產品品質第部：品質模型 CNS 15014-1 資訊技術軟體產品評估第部：概觀 CNS 15014-2 軟體工程產品評估第部：規劃與管理 CNS 15014-3 軟體工程產品評估第部：發展者過程 CNS 15014-5

12、 資訊技術軟體產品評估第 5 部： 評估者過程 4. 用語釋義 本標準使用下列的定義。於本標準中所使用之其他標準的重要定義 複述於 附錄 A。 4.1 商業現成軟體 (commercial-off-the-shelf software；簡稱 COTS) 由市場導向需要 (need)所定義的軟體、商業上可用、且 己 由廣泛範圍之商業使用者 展示 其使用的適宜性。 備考：亦參照 IEEE Std 1062-1993 中的定義。 4.2 客製軟體 (custom software) 為了使用者 特定應用之 需求規格而發展的軟體。 4.3 現有軟體 (existing software) 已經發展且為

13、可用的軟體，適用於 “現狀 (as is)”或修改；且由供應者、獲取者、或第三方提供之。 備考：亦參照現成產品的定義 CNS 14837。 5. 軟體產品評估一般考量 5.1 評估與獲取過程之間的相關性 總結獲取過程活動 (在 CNS 14837 中定義 )如下，與第 6 節、第 7 節中的一般評估活動過程活動 (在本系列標準第 1 部中定義 )相結合。第 6 節著重於 COTS產品之獲取期間終端產品品質的評估應用；而第 7 節著重於客製軟體之獲取或現有軟體之修改期間的評估過程應用。 (1) 初始 待獲取的產品、獲取計畫及驗收策略與準則之軟體需求的識別。 (2) 徵求建議書 (Request-

14、for-proposal)(邀標書 )準備獲取需求的規格與文件化(documentation)。 (3) 契約準備與更新供應者選擇、契約準備與協商及契約變更控制。 (4) 供應者監督在軟體產品的驗收與交付的契約執行期間，履行評估活動。 (5) 驗收與完成在產品驗收與最終軟體產品的交付期間，所履行之活動。 備考： 本系列標準第 1 部之一般評估過程不定義為 CNS 14837 所定義的過程，而是一個基本功能 ，相當於每個生命週期過程所實作 (implement)之計畫執行查 核 行動 (plan-do-check-act, PDCA)週期的 “檢查 ”部分。然而，在任何 CNS 14837 的過

15、程 (即發展、維護、獲取、確認 (validation)中，可以實作一般評估過程；所以一般評估過程與 CNS 14837 所使用之 5 CNS 15014-4, X 3014-4 “過程 ”觀念的抽象化是在不同的等級。 當實作一般評估過程時，此差異是重要的。獲取者需要定義在獲取期間他 /她將遵循達成評估需求的評估過程與獲 取過程。在較大系統發展的全景中，需要將遵循之獲取及評估活動與其他發展及 整合活動整合，並且識別本系列標準第 2部 (準備中 )所規定之專案測量計畫的獲取與評估活動；即評估的特定獲取實作考量，包括下列考量： (1) 評估所要求 之軟體需求規格能夠形成徵求建議書 (邀標書 )所要

16、求的獲取需求基礎。 (2) 可能需要 分開 的預備評估活動，以預選軟體產品與供應者。 (3) 在獲取需求中或在契約的準備期間，需要規定評估的供應者與產品資訊需求。 (4) 能夠執行評估活動，作為建議評估的一部分，在契約執行的監督期間，作為產品發展的一部分，或在產品交付之後，作為正規產品驗收的一部分。 5.2 評估過程的輸入 5.2.1 系統需求 決定標的軟體之評估需求的起始 點以整體系統需求為開始。系統需求識別使用者、使用者目標、任務及特 性，包括使用產品的環境，還有產品或系統之功能與其他的需求。他們形 成以後的系統架構設計、軟體需求之規格及軟體架構設計的基礎。在 此階段，因為他們影響獲取與評

17、估過程的 嚴密與正規手續，需要識別相關法律上與管理的需求。 在系統需求分解與設計期間，分 配系統需求至硬體與軟體組態項目，並分配至使用者運作，包括系統程序 。在系統發展生命週期期間，設計活動導致以後獲取或再使用現成軟體產 品的決策。因為評估工作在決策制定過程中扮演角色，所以某一些評估工 作實際上是這些設計活動的一部分。各自履行待獲取之軟體產品的評估。 在系統整合與終端產品的測試期間，將軟體組態項目與其他軟體整合，並與硬體組態項目整合 (參考 CNS 14837)。圖1 顯示評估與獲取之較大系統工程的全景。 本標準之使用與獲取的 備選對象 是能夠將軟體產品整合成較大系統組件的軟體產品。其分類如下

18、： (1) 商業現成軟體產品。 (2) 為了其他應用或 廣泛 共同應用而發展或獲取的現有軟體產品。 (3) 客製軟體產品或現有軟體產品的修改。 在軟體組態項目與較大系統整合的情況下，需要定義每 個項目的軟體需求。在其他的情況下，系統與軟體組態項目符合一致， 並可以視為相等的。 待獲取的硬體組態項目 可能包含軟體，例如常駐在韌體 (即 ROM、 PROM)的作業系統。當現有軟體以此方 式形成硬體不可或缺的部分，通常需要一起評估硬體組態項目。 6 CNS 15014-4, X 3014-4 圖 1 軟體產品評估與獲取的系統工程全景 初始指系統需求擷取與系統設計使用者目標與環境功能與其他的需求完整性

19、層級電腦子系統工程子系統整合與系統確認產品評估與獲取人體工程與人因工程硬體工程軟體工程系統程序系統操作非電腦子系統工程5.2.2 完整性層級需求 如果軟體在控制可驗收範圍內之系統的重要生命財產安全 (safety)、安全、金融、環境及社會之風險方面 是關鍵的，則在採購與評估之前，必須已經建立且正確地文件化所要求的完整性層級。 CNS 14802 提供決定過程之完整性層級的指引。最終 (resulting)完整性層級決定在評估過程中如何處理軟體。 5.2.3 軟體需求規格 應該使用適當之良好定義的 品質模型，定義軟體需求，為此目的，除非有使用其他模型的特殊理由，否則應該使用 CNS 14948-

20、1 中的品質模型與定義。 此模型定義六種廣泛的使用中軟 體特性種類：功能性、可靠度、可用性、效率、可維護性及可攜性。能夠 更進一步將他們分成具有可量測或可評鑑之屬性的次特性。 宜以 在外部量度 (metric) (ISO/IEC 9126 定義之外部量度 )定義需求，其中量度與使用者需要直接相關，並應 該在需求規格中文件化。文件化使用者需要能夠從產生所要求 之功能與效能需求的非正規列表到準備產品 (或系統，如果產品是內嵌的 )完整需求規格而有所不同。然後，在獲取過程中，需求規格可能形成投標期間所使用之 獲取需求的基礎，依此基礎對照履行日後的產品評估。 5.2.4 由其他人員履行的評估 只要結果

21、是值得信賴的，可以經 由存取評估活動之結果而縮小目前評估過程的範圍，其中由第二或第三方 履行評估活動。此類評估活動可以構成事先存在的驗證、產品評估及 /或過程評鑑。例如： 7 CNS 15014-4, X 3014-4 (1) 可以標準化產品發展的軟體工程過程，以符合 CNS 14837、 CNS 12680-3或其他範圍 -特定標準的需求。 (2) 關於 CNS 12681 需求，可以由第三方驗證發展軟體之供應者的品質系統。 (3) 關於本系列標準第 5 部或 ISO/IEC 12119 需求，可以由第二或第三方；評估軟體產品。 (4) 可以由第三方評鑑 (assess)可驗收之產品發展的供

22、應者軟體過程能力。 (5) 可以功能評估，作為較大系統發展階段部分之軟體。 (6) 可能為了具有不同完整性需求的另一個應用，已經事先評估過軟體產品。 (7) 可能已經由組織內其他個體履行產品上的評估，其中經由非正規或正規之評估活動履行。 獲得與解譯標的應用之外部評估 結果所要求的額外成本與時間，可能影響此方法的可行性。為了獲得在其 他結果中之足夠的信任，可能需要與評估者或供應者協議。 備考： 供應者軟體 工程過程、供應者品質系統、或供應者能力的評估結果無法單獨為 準則，以證明軟體產品包含所要求的品質特性。需要執行其他產品評估方法例如， 適合終端使用者需求之 特別量測因素與品質屬性。 5.3 裁

23、適 可以應用評估過程在獲取需求、完整性需求及評估者目標的廣泛範圍中。例如： (1) 軟體套件的獲取者可能希望僅使用 ISO/IEC 12119 評估軟體套件。 (2) 關於獨立評估，軟體產品的獲取者可能使用本系列標準第 5 部。 (3) 小型或單獨獲取者可能需要具有最少評估之文件化的評估過程，其中過程是較不正規的。 (4) 關於 消費者 軟體，評估過程目標實際上可能是簡單地選擇、測試及獲取一些相似產品之中的一個產品。正規獲取過程 則可減化 為 完全的 購買，且不包括契約準備。 評估過程應該具有適合每個應用之 獨特性的彈性，以避免不必要之工作或未增加任何價值的工作，且並提供建立 軟體之必要信任的

24、實際工具。軟體所要求之完整性層級主要決定評估過程的精確與正規手續。 能夠裁適評估過程為使用 CNS 14837 中裁適指引的評估過程，與待獲取的特定軟體產品之要求的完整性層級。具 有高完整需求之完整軟體系統的獲取通常將造成獲取活動與任務的 全部 集合，連同 CNS 14837 中規定 對應的供應過程活動與任務，。一般而言，隨著 完整性層級增加，宜增加 嚴密 與獲取過程有關之活動與任務的數量。 根據標的軟體完整性層級需求，在附錄 B 中表 B.1 顯示一個整合的獲取與評估過程活動的裁適範例。 6. “現成 ”軟體產品之獲取期間的評估 在本系列標準第 1 部所定義的一般軟體產品評估過程中，由四個主

25、要步驟構成，特 8 CNS 15014-4, X 3014-4 別實作與精製軟體產品評估過程以著重於本標準中現成產品獲取期間之的終端產品品質評估。然而無法排除特定品質特性之中間產品的評估，因此步驟實作之細節與本系列標準第 1 部所描述的細節相異，但未不一致。下列表 1 以步驟與重要任務的觀點總結評估過程與輸入及輸出。 表 1 現成產品之獲取期間的評估過程 輸入 評估步驟 重要任務 輸出 系統 /軟體需求 建立評估需求 (第 6.1節 ) 規定目標、目的及範圍。規定評估的精確。識別評估的輸入。識別履行或由其他人履行的評估。識別待採用的獲取過程與如何傳達評估輸入需求給供應者。 評估需求規格評估需求

26、 規定評估 (第 6.2節 ) 選擇與軟體產品之特性相關的量度。建立評等等級。選擇評估方法之最有效的集合。建立總結不同品質特性之評估的程序，且在特殊環境中，促成軟體產品之品質評鑑的其他觀點。 評估規格 評估規格 設計評估 (第 6.3節 ) 準備描述評估方法之評估計畫與評估的排程。識別在評估活動與獲取活動之間的聯繫點。 評估計畫 評估計畫 執行評估 (第 6.4節 ) 實施選擇的評估活動，並分析與記錄決定軟體產品之適用性的結果。分析識別的缺陷影響與管理產品使用的選項。作出關於產品可接受性與購買或不購買之最後決策的結論。 評估紀錄與結果6.1 步驟 1：建立評估需求 6.1.1 建立評估目的與範

27、圍 評估過程應該建立： (1) 一組使用 CNS 14948-1 之品質模型與定義的軟體品質需求，依此可以客觀地評估軟體產品之使用的適宜性。 (2) 宜制定軟體品質特性之適當的優先權。 (3) 適用於應用的完整性層級之評估之 系統化的基礎，包含建立關於評估活動中所要求之精確或細節的等級需求，與評估過程的輸入及輸出。 備考： 圖 2 提供軟體產品評估過程的概觀，顯示獲取者觀點之評估過程輸入與評估過程最終輸出的不同觀點。 (4) 待遵循的獲取過程與如何傳達評估輸入需求給供應者。 備考：參照附錄 C 圖 C.1 中結合的評估與獲取過程之範例。 (5) 評估的範圍、目的及目標需考量下列： (a) 是否

28、使用軟體產品於特定應用、大量的特定應用、或應用的同屬 (generic)範圍。 9 CNS 15014-4, X 3014-4 (b) 是否已經由第二或第三方執行任何評估，或是否規劃稍後履行的任何評估活動。 6.1.2 規定評估需求 評估需求規格應該識別： (1) 使用者與其目標、任務、特性及產品的使用者環境。 (2) 軟體應用的完整性層級 (倘若軟體錯誤導致風險 )，與評估過程所要求的精確等級。 (3) 律定的需求 (要求提主管單位確保產品品質所需的文件 (如果有的話 )(參照CNS 14948-1 的遵循性 )。 (4) 產品界限與介面，包括軟體產品的介面需求 (即經過介面之資料的型式、資

29、料格式、介面存取機制、故障 /錯誤處理、時間之選擇的議題、介面行為議題及介面狀態的相依性與轉態 )(參照 CNS 14948-1 的互運性 )。 (5) 整合需求，如果產品是需要與其他組件或產品整合較大系統的一部分。 (6) 軟體品質需求，包括： (a) 必備與選項之需求間的區別。 (b) 所有假設、 例外、限制、互斥、或需要解譯或瞭解需求之未解決的議題。 (c) 所有重要品質特性的使用者 需求與其優先權 (即如果將可維護性視為重要的，則識別特定可維護性需求 )。 (d) 所有設計與 環境的限制由軟體產品的使用、其他現有軟體之軟體產品的整合等 級與複雜度、客製軟體及使用者應用的硬體強加功能或效

30、能限制。 (e) 所有專案管 理限制，即資源之可用性與履行評估活動的專門技術、排程與預算 補助、可能的相依性或風險、重要假設或評估工夫本身的假設。 (f) 不同於 CNS 14948-1 所定義的品質模型之使用的原理。 (7) 待評鑑的供應者服務，即支援能力、應用發展能力及訓練能力。 (8) 待評鑑的特殊需求，即特定技術的可行性議題或設計實作問題。 (9) 彼此一致的評估需求 (即無衝突的需求 )，並且與應用的完整性層級一致。 (10) 產品是否將再使用在未來應用中，與文件化是否將需要支援產品的任何未來評估。 (11) 獲取過程，與在投標期間之供應者所要求的資訊。 (12) 由第二或第三方所履

31、行評估，能夠使用其降低產品的評估工夫。 備考： 雖然可以使用評估結果在其他階段之進一步的工作、預期問題或排除特定軟體產品或供應者，但是評估需求規格之細節與完全性層級直接影響評估的完全 性層級，即無法將基於預備需求的評估視為完整評估。通常在主要評估活動之前，完成這些評估需求，作為適當設計或規劃活動的一部分。在完成需求之前，亦可能要求一些評估工作。 10 CNS 15014-4, X 3014-4 圖 2 從獲取者之觀點的軟體產品評估過程概觀評估過程建評估需求規定評估設計評估執評估評估輸入的各種觀點產品觀點使用者與技術文件軟體質需求 成本評鑑過程觀點品質系統維護過程工程過程雛型法 /測試運作史失效

32、資訊使用中產品觀點品質需求符合之信任的必要層級產品的使用限制所需的的額外查證活動評估結果的觀點6.2 步驟 2：規定評估 評估規格宜文件化，使得合適之合格人員能夠重複評估過程，得到重複的結果。 6.2.1 選擇量度 評估規格宜識別下列事項： (1) 待評估之產品的特性。 (2) 當使用軟體時，與品質之可量測觀點有關的外部量度 (附錄 B 表 B.2 顯示外部量度與可能的驗收準則之範例。 注意，當這些數量沒有可靠與快速的規則時，由使用者基於經驗規定實際 之驗收臨限值 (threshold acceptance numbers)。 (3) “使用中品質 ”量度與包含軟體的系統品質之使用者觀點有關

33、(參照附錄 B 表B.3 的使用中品質量度範例 )。 (4) 描述可驗收之範圍的充分量度準則 (例如：需要多少運作史，提供特定品質特性與完整性層級保證之合理程度 (參照附錄 D.4 與 D.5 之運作史的特定細節 )。 (5) 任何套裝的評估模組 (evaluation module)。 (6) 在其他人員實施任何事先評估審查之後，與評 估需求相關的涵蓋率(coverage)層級是必需的。 (7) 由評估待回答的核對表列 (checklist)。 (8) 一個有助於回答問題的範例列表。 (9) 待使用之測試案例。 (10) 待收集與分析的資料，與其格式。 (11) 待使用的特定評估方法，其包括

34、一個或多個方法的審查或評鑑： 11 CNS 15014-4, X 3014-4 (a) 軟體產品使用者與技術的文件化 (包括線上文件化 )(參照附錄 D.1)。 (b) 基於供應者課程與訓練的軟體產品評估 (參照附錄 D.2)。 (c) 軟體工程過程，包括中間軟體產品 (參照附錄 D.3)。 (d) 供應者之產品運作史 (參照附錄 D.4)。 (e) 客戶之產品運作史 (參照附錄 D.5)。 (f) 供應者能力、支援及品質系統 (參照附錄 D.6)。 (g) 雛型法 (prototyping)或其他評估方法 (參照附錄 D.7)。 (h) 產品缺陷表列與相關的資訊 (通常於網站上發現 )。 (

35、12) 評鑑評估結果的方法。 (13) 當從相似的產品中選擇產品時，允許選擇分級評鑑的適當方法。 (14) 任何有助於比較超過一個軟體產品的評等方法。 依照品質特性的優先權，可以是加權評等方法。 6.2.2 選擇評估方法 應該規定評估方法的組合，以允 許產品之選擇或建立產品的使用適宜性。待評估的範圍包括： (1) 一些考量是否可能是互相矛盾的 (例如，所選擇的 評鑑 方法的成本是否於預算範圍內？ “方法是否闡明所有的評估需求？ ”可能是不一致的 )。在此情況下，由評估者基於評估需求的優先順序執行必要的取捨。 備考： 附錄 B 表 B.4 顯示根據成本與有效性，軟體品質特性之評估方法排序的範例。

36、 (2) 在選擇考量的方法組合中，評估是否提供適當的涵蓋率或範圍 (scope)，考量下列： (a) 如何證明軟體符合其規格。 (b) 方法涵蓋率的重疊提供額外的信任。 (c) 整體看來，活動之集合是否提供保 證的可驗收等級，其中保證具有重要之軟體品質特性的完整涵蓋率。 (d) 方法彼此互補的程度。 (e) 每個方法的有效性與客觀性指出各種特性。 (f) 評估方法中各種不同作法的多樣性 (例如，某個審查、某個分析及某個基於方法的測試 )。 (g) 在應用上，最終將導入成為整個系 統發展生命週期一部分的的任何評估活動，予以採計。 (h) 採計其他人員所履行的評估。 (3) 為了縮小產品的選擇，產

37、品功能上考量適合進一步的評估， “非正式 ”預評活動的使用，如審查或調查，或同儕 /使用者軼聞的經驗、交易日誌產品審查、可存取之產品使用者的文件化、或產品審查的資料庫。 6.2.3 由其他人員履行的評估 在信任其他人所履行的評估前，宜考量下列： 12 CNS 15014-4, X 3014-4 (1) 評估是否指出精密程度與應用的完整性層級一致的評估需求。 (2) 評估報告是否識別正被評鑑之軟體產品的版本、評估的範圍、所使用之決策準則及達成的結論。 (3) 評估報告是否識別軟體產品或軟體工程過程的任何缺陷、指出這些缺陷之建議的任何矯正措施已因應及矯正措施是否實施。 (4) 評估者是否具有適當的

38、專門技術，包括： (a) 履行評估與分析的經驗。 (b) 國際所接受標準之相關軟體品質經驗。 (c) 軟體工程議題的專門知識。 (d) 與供應者完全無關。 6.3 步驟 3：設計評估 產品評估計畫宜識別： (1) 供應者或第三方是否願意且能夠提供存取所需的文件化、設備、工具、軟體、課程與 /或訓練、及相關的成本。 (2) 與存取任何機密或專用資訊之規定有關的任何條件。 (3) 供應者或第三方是否願意且能夠提供具有正確專門技術以回答問題的個體、所有相關的成本，包括旅行成本。 (4) 評估者所需專門技術以實施評估，基於評估需求及獲得此特殊專門技術有關的任何成本。 (5) 建立產品適合全部尺度測試之

39、所要求的任何預先測試。 (6) 提供履行評估之測試環境 (例如，測試硬體、支援設備與工具及專業人員 )有關的任何成本。 (7) 評估的責任與要求的排程。 (8) 提供品質保證之評估方法中的任何限制與缺陷，計畫中其他部分是否包含限制或缺陷；例如，評估方法無法涵蓋特定品質特性的所有次特性。 (9) 各種使用的評估方法之間的 任何互依性，即順序相依性 (一個測試中所獲得之資訊可能在另一個測試中是有用的 )，建立評估方法的最佳順序。 (10) 所需的資源、全部評估之成本及每個評估方法的成本。 (11) 在評估活動與獲取活動之間的聯繫點 (參照附錄 C 圖 C.1 結合的評估與獲取過程範例 )。 (12

40、) 在評估過程中的決策點，其決定應考量評估何時與為何完成 (即驗收或拒 絶準則 )與應何時與為何終止評估。 (13) 對每個評估活動規劃下列： (a) 應該遵循的程序與技術。 (b) 資訊輸入及輸出與要求的文件化。 (c) 任何產生之文件化的任何格式與內容需求。 (14) 在定義評估計畫中制定出任何罕見或 例外的決策之後，文件化理由闡述、判定 (justification)及假設。 13 CNS 15014-4, X 3014-4 (15) 評估工具。 (16) 發展及確認量度的程序與標準化評估過程、量度及測量的程序。 備考 1. 本系列標準第 6 部定義評估模組的觀念，系統化收集實施品質特性

41、之特定觀點評估的所有必要資訊，其中品質特性適用於特定評估技術或方法。 2. 在排定評估方法中，認 定各種評估方法之間存在高度的互依性是重要的，即一個方法所獲得 之資訊可能影響另一個方法的焦點。因為評估之本質是迭代的，當獲得資訊時，可能重返議題。 所以當實施評估時，將可能改變評估計畫。 例如，一旦發展評估，可能普遍的是將有更多評估之詳細等級視為非必需或額外的需求。 3. 可能在發展生命週期之 不同點的階段中實施軟體產品評估，在生命週期中的一個點，或一次 全部。不同個體或群體可能負責履行不同部分的評估。當在階段中完 成評估，在每個階段中重複評估活動的步驟，直到不再要求另外的工作 (參照附錄 E 階

42、段化評估過程的範例 )。 6.4 步驟 4：執行評估 6.4.1 執行評估方法 (1) 宜履行、文件化及分析評估，以達成下列事項： (a) 建立適當的信任程度，其中軟體產品能夠符合評估需求。 (b) 識別任何關於評估需求之缺陷與決定這些缺陷範圍所需的額外評估。 (c) 識別任何設置於軟體產品之使用的特別限制或條件。 (d) 識別評估本身之缺陷或省略與任何所需的額外評估。 (e) 識別由評估所發現之軟體產品使用的任何選擇。 (2) 評估執行的紀錄宜識別： (a) 評估的執行，其根據評估計畫中所規定之程序。 (b) 評估程序的按步執行 ( 包括使用的資 料、建立過程及任何狀態資訊 )、評估結果 (

43、所有問題的答案與答案來源的參考 )、及軟體產品版本號碼。 (c) 評估活動中的任何限制、約束、缺陷 、或排斥，包括使用、組態、修改、或在規定時間外軟體產品之一般維護的影響。 (d) 評估者與其資格。 (e) 評鑑的產品版本與對應的評估輸入之 間的任何差異，即文件化或項目清單。 (f) 陷事件的解決或 “逐步完成 (work-arounds)”。 6.4.2 分析評估結果 評估活動之分析的紀錄宜識別： (1) 每個缺陷、任何相關的分析及如何解決每個缺陷，缺陷的解決可能包括下列因素： (a) 其他評估方法之一已經提供缺陷不是 主要的保證；例如，廣泛運作史可能彌補有缺陷的軟體工程過程。 14 CNS

44、 15014-4, X 3014-4 (b) 可以發現符合要求的 “逐步完成 ”，以降低缺陷的影響；例 如，產品的修改、去能或移除不需要的功能性 、使用反向工程再生遺失的設計需求。 (c) 原始需求不是必備的，且缺陷是可以驗收的。 (d) 缺陷為可驗收的，提供由特定條件或限制所控制之軟體產品的使用。 (e) 需要額外評估工作，以解決評估的缺陷或漏洞。 (2) 履行任何額外評估以解決任何已識別的缺陷： (a) 決定缺陷的範圍或影響。 (b) 建立無缺陷的信任。 (c) 查證 (verify)工作周圍是技術上可行與 /或適合與可驗收的。 (d) 查證軟體之正確與可驗收的效能，產 生設計改變或多個改

45、變以修正缺陷。 (3) 在需要限制或控制軟體產品之使用的情況下，限制是否： (a) 干擾符合應用之必備需求的軟體產品。 (b) 影響應用的設計、預算及排程。 (c) 要求額外評估工作。 (d) 導入應用之失效的任何可能性。 (4) 評估範圍之任何排斥與 /或每個評估結果的限制，例如： (a) “評估未包括產品之功能性的詳細審查。 ”或 (b) “對成功完成的產品，認為此軟體 產品具有要求的完整性層級之資格，提供要求的功能性之全部的評估。 ” (5) 所有評估活動整合的結果，允許做出軟體產品評估的整體結論。 6.4.3 草擬結論 結論應該陳述軟體產品使用於預 期的應用中是否是充分與適當的，考量應

46、用完整性層級與實際的評估需求 。如果因為發現缺陷或缺乏評估資訊，而不可能使用軟體產品 “現狀 ”，則必須作出履行更進一步之評估的建議，或控制或限制標的應用之軟體產品的使用。 可能使用 “需求遵循的聲明 ”正規化結論，其中聲明將描述每個特定需求，用以符合需求之軟體產品的特性、 功能、或服務，與提供已符合需求之適當信任的評估方法。潛在的設計策略可能彌補軟體產品之 缺陷或潛在的失效，例如，設計多樣性的實作、組態的冗餘、介面完整性檢查及復原 (recover)技術。 評估可能導致未驗收使用之軟體 產品的決策，或企圖不遵循評估需求的決策，並且導致重新評估替代方法的建議。最後的決策是購買或不購買。 購買決

47、策能夠導致購買具有可能 額外評估之軟體產品的契約，其中評估是以產品驗收測試的形式。 不購買決策能夠導致可能的替代 方案，包括修改軟體產品、發展客製軟體產品、或變更需求。 15 CNS 15014-4, X 3014-4 7. 客製軟體與現有軟體修改之獲取期間的評估 本節著重於客製軟體之獲取或現有軟體之修改期間的評估過程之應用，附錄 C 圖 C.2顯示客製軟體與現有軟體修改之結合的獲取與評估過程範例。 7.1 步驟 1：建立評估需求 第 6.1 節中所定義之建立評估需求的過程亦適用於此情況。評估需求形成獲取需求的基礎，能夠送出獲取需求， 作為事先選擇供應者請求提案的一部分。對於現有軟體的修改，評

48、估需要主要著重於軟體產品與其介面之變更的部分。 在徵求意見書之前，以能力、品質 程式及軟體工程過程為基礎，應該履行初步評估以預先選擇供應者。 7.2 步驟 2：規定評估 第 6.2 節規定 “現成 ”軟體產品評估，亦適用於客製軟體之評估與現有軟體的修改。然而，要求額外測量作為供應 者發展過程的部分，基於量測中間產品之品質，以預測終端產品的品質。本系列標準第 3 部提供在發展期間，量測中間產品的需求與指引。 7.3 步驟 3：設計評估 第 6.3 節適用於具有下列額外考量的客製軟體之獲取與現有軟體之修改。 在投標期間選擇供應者可以要求供 應者升級軟體工程或維護過程，在軟體發展或修改之前，要求達成

49、標的完整性需求。 然後，要求評估活動變成供應者效 能過程的一部分，即在引導供應者發展、查證、共同審查與稽核、及測試與確 認活動的過程期間。在要求供應者遵循的品質或發展計畫中規定這些需求。獲 取者監督計畫的供應者效能，並且在供應者與獲取者之間的契約協定中建立計畫的需求。 7.4 步驗 4：執行評估 根據品質計畫，經由供應者效能與獲取者監督活動實施實際的評估之外，第 6.4節中評估執行的需求在此亦適用。 在產品交付至獲取者前，成功之軟體產品驗收測試是必要的準則。在使用產品之前，獲取者可能決定對軟體作額外的修改，以指出在評估期間所發現的缺陷。 相對應國際標準： ISO/IEC 14598-4： 1999 Software engineering Product evaluation Part 4: Process for acquirers 16 CNS 15014-4, X 3014-4 附錄 A (參考 ) 其他標準的用語釋義 本標準使用本系列標準第 1 部的用語釋義，除非陳述其他用語釋義。 A.1 獲取者 向供應者獲