1、1 印月9511月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X3014-515014-5經濟部標準檢驗局印 公布日期 修訂公布日期 9511月16日 月日 (共32頁)資訊技術軟體產品評估第 5 部：評估者過程 Information technology Software product evaluation Part 5: Process for evaluators 目錄 節次 頁次 導論 2 1. 適用範圍 . 3 2. 符合性 3 3. 引用標準 . 3 4. 用語釋義 . 4 5. 評估觀念 . 4 5.1 一般觀點 . 4 5.2 評估
2、起動點 5 5.2.1 初始協議 . 5 5.2.2 評估有關的個體 . 5 5.3 評估過程的特性 . 5 5.4 評估過程 . 5 5.4.1 評估活動 . 6 5.4.2 評估過程的輸入 . 6 5.4.3 評估過程的輸出 . 6 5.5 評估與生命週期之間的關係 8 6. 評估過程需求 8 6.1 一般需求 . 8 6.1.1 組織與品質系統 . 8 6.1.2 請求者的責任 9 6.1.3 評估者的責任 9 6.2 評估需求的建立 . 9 6.2.1 評估需求的建立目的 9 6.2.2 評估需求的製作 . 9 6.2.3 評估需求的內容 10 6.2.4 認可與報告 .10 6.3
3、評估規格 10 6.3.1 評估規格之目的 10 2 CNS 15014-5, X 3014-5 6.3.2 評估規格的推敲 11 6.3.3 評估規格的內容 13 6.3.4 認可與報告 .13 6.4 評估之設計 .13 6.4.1 設計評估之目的 13 6.4.2 評估計畫的推敲 13 6.4.3 評估計畫的內容 14 6.4.4 認可與報告 .15 6.5 評估之執行 .15 6.5.1 評估執行之目的 15 6.5.2 履行評估者動作 15 6.5.3 審查與報告 .17 6.6 評估之結論 .17 6.6.1 評估結論之目的 17 6.6.2 評估報告之共同審查 .17 6.6.3
4、 評估資料與文件之處置 17 附錄 A(規定 )樣板評估報告 18 附錄 B(參考 )評估的層級 20 附錄 C(參考 )軟體產品組件 .23 附錄 D(參考 )於請求者與評估者之間的互動 .26 附錄 E(參考 )評估契約 28 附錄 F(參考 )參考書目 30 英中名詞對照表 31 導論 軟體產品在產業與服務的所有領域方面變得愈來愈重要。因此能夠評估 (evaluate)這些軟體產品之品質是必要的。 軟體產品是極端地多樣。例如，就以功能性而論，其產生以滿 足非常多樣的要求(requirement)。其使用的內容也可以是非常多樣的，以一些範例為證，例如於管理資訊系統的應用軟體方面、或內嵌於其
5、他產品的軟體或遊戲軟體內。 評估的潛在利益 (1) 為了改善產品或產生關於產品之發展策略的決策，發展者 (developer)可以使用產品之評估的結果以識別校正動作。 (2) 對於產品的供應者 (supplier)，評估之利益是得到對產品價值的信任；再者，可以使用評估報告於商業目的。 (3) 對於軟體產品的獲取者 (acquirer)，可以使用評估結果以作為建立獲取決策之基礎的客觀資料。 (4) 對於大型產業，軟體產品評估的延伸將有助於品質的使用，以作為行銷的論據。 3 CNS 15014-5, X 3014-5 軟體產品評估之主要目的是提供關於軟體產品品質的定量結果， 其中品質為可理解的、可
6、接受的，以及可被任何利害相關者信賴。 就品質特性而論，以步驟性的程序描述評估過程，允許評估需 求的表示，如同於ISO/IEC 9126 中所定義。評估考慮各種文件，其中可能將文件視為軟體產品的部分，例如設計文件 (documentation)、測試或確認 (validation)報告、源碼 (source code)或使用者文件。建議評估者使用定義評估方法之評估模組 (evaluation module)的函式館。雖然在本標準沒有提出的規定，但可以標準化這些評估模組。評估導致評估者之評估報告的產出。 此評估過程是同屬 (generic)抽象過程，採用於 CNS 14948-1 中所定義的模型。
7、因此，此過程適用於 CNS 14837 中所定義的所有主要生命週期過程。 CNS 14837 所定義之特定支援的生命週期過程是直接與評估過程有關。支援生命週期過程是品質保證、查證、確認、共同審查及稽核 (audit)。 藉由允許使用者規定與設計評估活動，在本標準所定義之評估過程中建立 CNS 14837所定義的裁適過程。 可以使用描述於此的評估過程，以測試標準的符合性，例如 ISO/IEC 12119。 1. 適用範圍 當數個個體需要瞭解、接受及信任評估結果時，本標準提供軟體產品評估之實際實作的需求與建議。尤其，可以使用本標準運用 ISO/IEC 9126 所描述的概念。 本標準所描述的過程定
8、義分析評估需求、規定、設計及履行評估動作，以及總結任何種類的軟體產品評估需要的活動。 只要需要的產品組件是可用的，可以使用評估過程評估現有產品或評估發展中產品。 備考： 關於發展中產品的評估，需要將評估過程與軟體發展過程同步，並且當交付產品組件時，評估產品組件。 下列人員可能使用本標準： (1) 測試實驗室評估者，當提供軟體產品評估服務時。 (2) 軟體供應者，當規劃其產品評估時，包括由獨立測試服務執行的評估。 (3) 軟體獲取者，當要求供應者與測試服務的評估資訊時。 (4) 軟體使用者，當評估產品或當使用由測試實驗室所提供的評估報告時。 (5) 驗證機構，定義軟體產品的新驗證方法。 2. 符
9、合性 因為本標準建議的一般本質係自由地提供使用者選擇，所以簡單宣稱符合本標準是無效的。加入本標準作為交易條件的任何組織負責規定與公開一組需求，其構成本標準遵循性所提供之應用的項目。應考量第 6 節之所有需求的應用性。 3. 引用標準 CNS 15014-1 資訊技術軟體產品評估第部：概觀 CNS 15014-2 軟體工程產品評估第部：規劃與管理 CNS 15014-3 軟體工程產品評估第部：發展者過程 CNS 15014-4 軟體工程產品評估第 4 部：獲取者過程 4 CNS 15014-5, X 3014-5 CNS 15014-6 軟體工程產品評估第 6 部：評估模組的文件製作 4. 用語
10、釋義 本標準使用下列定義。 4.1 評估方法 (evaluation method)：為了獲得規定之測量 (measurement)或查證的結果，由評估者履行所描述動作的程序 ，其中測量或查證適用於規定的產品組件或整個產品。 4.2 評估報告 (evaluation report)：表示評估結果以及其他與評估相關之訊息的文件。 4.3 評估紀錄 (evaluation records)：記錄所有履行的活動與評估過程中所有達成之結果的客觀證據。 4.4 評估請求者 (evaluation requester)：要求評估的個人或組織。 4.5 評估工具 (evaluation tool)：在評估期
11、間，能夠使用儀器收集資料、履行資料的解譯、或評估的自動化部分。 備考： 此類工具的範例是計算程式碼量度 (metric)的源編碼分析器、產生正規化模型的 CASE 工具、執行可執行之程式的測試環境、收集檢驗資料的核對表列 (checklist)、或產生測量之綜合的試算表。 4.6 評估者 (evaluator)：履行評估的組織 備考： 例如，評估者可以是測試實驗室、軟體發展組織的品質部門、政府組織、或使用者。 4.7 軟體產品發展者 (software product developer)：製造軟體產品的個人或組織。 4.8 軟體產品評估 (software product evaluatio
12、n)：根據規定的程序，技術運作由產生軟體產品之一個或多個特性的評鑑 (assessment)所構成。 備考 1. 此定義能夠與 CNS 13606 中之測試的定義對照。然而，為避免與廣為軟體工程領域所接受之測試用語混淆，在本標準中以評估用語為優先。 2. 在驗證方法的全景中，軟體產品評估未必是符合性測試 (如同 CNS 13606，第 14.4 節中的定義 )。然而，一致性測試能夠是評估的一部分。 5. 評估概念 5.1 一般觀點 能夠以 ISO/IEC 9126 所定義之品質特性的觀點，描述軟體產品品質。然而，一般而言，以軟體測量之技術發展的水準要 使得這些特性的直接測量是不實際的。以產品之
13、較低抽象屬性的測量為基礎，評鑑 (assess)這些特性是可能的。 在標準中，評估者能夠使用他或她 的軟體工程經驗作評鑑，這可能降低評估的客觀性。考量的另個觀點是使用非確定性評估方法的可能性，雖然精確地定義，但此種方法能夠要求評估者做出無法事先定義的選擇。 備考： 非確定性評估方法的範例是由轉換產品的規格組件至正規模型，與履行此模型的效能或可靠度評估所構成；轉換階段包含由評估者所做出的許多選擇。 因此，本標準中的規定提供是盡可能維護所有環境中高的評估客觀性等級，這些規定對中間與最後評估結果的審查組織與評估過程紀錄的保存5 CNS 15014-5, X 3014-5 有所影響。 5.2 評估起動
14、點 5.2.1 初始協議 當評估請求者要求評估者履行此軟體產品的評估時，發生軟體產品的評估。 備考： 當要求評估 時，請求者表達由評估者所分析的評估需求。隨後，請求者與評估者協議評估規格。 5.2.2 評估有關的個體 潛在的評估請求者，例如： (1) 軟體發展者。 (2) 軟體供應者。 (3) 軟體獲取者。 (4) 軟體使用者。 (5) 系統整合者，也是獲取者的角色。 潛在的評估者，例如： (1) 第三方測試實驗室。 (2) 軟體生產或配送組織內的測試個體。 (3) 軟體購買或使用組織內的測試個體。 (4) 系統整合組織內的測試個體。 (5) 比較產品的組織。 在某些情況中，即使發展者不是評估
15、的請求者，評估包含軟體產品的發展者。 5.3 評估過程的特性 本標準所描述評估過程的主要目標是促進下列理想的評估過程特性： (1) 可重複性：由相同評估者依相同評估規格重複相同產品的評估，應該產生能夠被接受的相同結果。 (2) 可再生性：由不同評估者依相同評估規格重複相同產品的評估，應該產生能夠被接受的相同結果。 (3) 公平性：評估不應該偏向任何特殊的結果。 (4) 客觀性：評估結果應該是根據事實的，即不應因評估者的感覺或意見而有所扭曲。 備考： 能夠使用不同評估規格實施相同產品的評估。因此，評估結果不能比較，而且可能導致不同的結果。 5.4 評估過程 評估過程 (參照第 6 節 )是由與請
16、求者及評估者合作實施的一組活動所構成，以請求者與評估者所提供或由其他活 動所產生的資料為基礎，履行這些活動。請求者與評估產生其他活動使用的資料，或產生之資料是評估過程的結果。 設計活動需考慮下列議題： (1) 因為發展的軟體產品滿足不同的需求，而且評估請求者可能同意特殊的評估需求，所以目標將從評估一個事件到另個事件而有所差異 (參照第 6.2.1 節 )。 6 CNS 15014-5, X 3014-5 (2) 軟體產品由組件所構成，其形式與性質取決於發展方法，發展方法將非常不同。 (3) 可能之評估技術是眾多的，並且需要考慮評估的目標與產品的組成以選擇評估技術。 上述這些考量加深過程的高度彈
17、性。 5.4.1 評估活動 評估過程 (參照第 6 節 )包含下列五個活動： (1) 評估需求的建立 (參照第 6.2.1 節 )。 (2) 評估規格：評估規格是基於評估需求與請求 者所提供的產品描述 (參照第 6.3.1 節 )。 (3) 評估設計：基於評估規格，評估設計產生評估計畫；此活動考慮待評估的軟體產品組件與評估者所提出的評估方法。 (4) 評估計畫的執行：根據評估計畫，評估計畫的執行由產品與產品組件的檢驗、模型化、量測及測試所構成；能夠使用軟體工具履行這些動作 (軟體工具通常由評估者提供 )；記錄由評估者 所履行的動作，並且將所獲得的結果加入評估報告草稿中。 (5) 評估的結論：評
18、估的結論包含評估報告的遞送、評估產品之評估者的處置、及已經獨自傳遞的產品組件。 5.4.2 評估過程的輸入 請求者提供請求者的需求，此為 評估需求的初始版本。在評估期間請求者提供下列評估過程的輸入： (1) 產品描述。 (2) 產品組件。 產品描述識別已提交評估的軟體產品及其組件。 備考 1. 產品可能包括與規劃、過程或生產所使用的發展方法相關的文件。規劃文件可能包括排程、組織結構或估計的成本。 2. 如果請求者是使用者，其應該與發展者協議以支援評估者，並且可能要求發展者交付待評估的軟體組件與軟體產品之描述給評估者。 評估者提供下列評估過程的輸入： (1) 事先定義的評估規格。 (2) 評估方
19、法。及 (3) 評估工具。 5.4.3 評估過程的輸出 在評估過程期間，評估者提供下列輸出產品： (1) 評估紀錄，包含評估計畫與評估動作的紀錄。 (2) 評估報告草稿，包含評估需求、評估規格及彙整評估結果。 (3) 已審查的評估報告。 評估需求、規格及計畫是評估過 程的中間產品，評估紀錄與評估報告為評估過程的最終產品。 7 CNS 15014-5, X 3014-5 評估需求描述評估的目的；尤其，描述產品的品質需求。 評估規格定義所有履行於產品與 其組件上的分析與測量。識別將被分析與量測的產品組件。 評估計畫描述實作 (implement)評估規格需要的作 業程序；尤其，描述評估所使用的方法
20、與工具。 評估紀錄包含評估計畫與評估者執行評估計畫時所履行 之動作的詳細考量；由評估者保存這些紀錄。 備考 1. 保存評估紀錄是為了允許評估結果的再處理。 評估報告包 括評估需求、評估規格、履行測量與分析的結果、以及能重複或再 生評估所需要的任何其他資訊。最初發佈的評估報告作為審查的草稿，最終版本的評估報告交付給請求者。 2. 下圖提供以上描述過程的概觀，識別活動之間的資訊流。 8 CNS 15014-5, X 3014-5 圖 1 評估過程 評估需求的建立評估的規格評估的設計評估的執行評估的結論請求者的需求評估需求評估規格評估計畫評估紀錄草稿評估報告已審查的評估報告彙整評估結果評估動作的紀錄
21、評估工具產品組件評估者的輸入評估方法產品描述事先定義的評估規格請求者的輸入5.5 評估與生命週期的關係 能夠在 CNS 14837 所定義的任何生命週期過程之全景內履行軟體產品的評估，尤其能夠在獲取、供應、發展、運作或維護的其中一個過程內發生評估。 在產品發展過程中可儘早決定是否 履行軟體產品評估。如果正好於發展過程的開始時實行，則就可能將評估所要 履行的測量與測試嵌入軟體發展過程中。這將確保產品滿足所有關於評估結果 之需求的最大可能性，以將額外風險與意外成本降至最低。 當請求者是產品發展者，提早聯繫 評估者來討論提交產品以供評估的意圖，亦將有助於發展者預期任何評估者可 能有的特別需要 (ne
22、ed)(例如可能要求特殊的文件或證據的要求 )。 某些 (或甚至全部 )的評估動作將必須在現場實行，而不是在評估者的場所。在此情況中，動作仍將由評估者控制以保證結果是公正的。 關於非常大、複雜的軟體專案，在 整個產品的發展期間，發展者若與評估者有連續的、詳細合作將有助於評估過 程的期程與成本減至最少。此合作應該在不降低評估者公平性的情況下進行。 6. 評估過程需求 6.1 一般需求 9 CNS 15014-5, X 3014-5 6.1.1 組織與品質系統 為了滿足第 5.3 節所描述的特性，例如評估結果的可重複性、可再生性、公平性及客觀性，評估者應於組織 的全景中活動，提供所有必要的保證以獲
23、得其活動的足夠品質。為了滿足此需求， 評估者的組織可能遵從 ISO/IEC Guide 25 所規定的需求。 6.1.2 請求者的責任 評估請求者的責任應為： (1) 為了評估目的，建立軟體產品之必要的法律權利。 (2) 提供產品識別與描述之必要的資訊。 (3) 陳述初始的評估需求，並且與評估者協商以決定實際的評估需求；這些評估的需求應遵循相關的法規與標準。 (4) 陳述關於所提交評估之資訊的機密性需求。 (5) 當有需要時，扮演發展者與評估者的中間人。 (6) 當有需要時，提供評估者適當存取電腦與發展軟體產品所用與作業使用所使用的其他設備。 (7) 當有需要時，提供支援給評估者，包括訓練與運
24、用適當的人員。 (8) 當有需要時，保證適時地供應軟體產品、其描述與組件，包括文件與其他資料。 (9) 當有需要時，通知評估者任何可能使評估結果無效的因素。 6.1.3 評估者的責任 評估者的責任應為： (1) 請求者對於履行評估之軟體產品擁有適當的法律權利之調查；為了這麼做，評估者可以要求出自請求者出具證明。 (2) 由請求者提供之所有資訊所要求的機密性之保持，例如包含評估中的產品、評估紀錄及評估報告。 (3) 提供合格的與訓練的人員以實施評估。 (4) 提供評估工具與技術。 (5) 依照評估需求實施評估。 (6) 維護評估期間所履行的任何對於評估結果具有影響之工作紀錄，這。 (7) 保證適
25、時地遞送評估報告給請求者。 (8) 在請求者所要求之程度提供可見性於於實施中之評估。 6.2 評估需求的建立 6.2.1 建立評估需求的目的 建立評估需求的目的是為了描述 評估的目標。此類目標與軟體產品的預期使用與其相關風險 (例如，參照附件 B)有關。可以從數個觀點來考量：不同產品使用者的觀點，例如產品 的獲取者、供應者、發展者、操作者、或維護者 (maintainer)。 6.2.2 評估需求的推敲 (elaboration) 10 CNS 15014-5, X 3014-5 評估需求的分析活動由下列各個子活動所構成： (1) 由請求者提出請求者之的需求。 (2) 由請求者表示評估的範圍。
26、 (3) 支援請求者評估的原因與描述評估者的評估需求。 (4) 解釋評估者所做評估的可信賴度與說服力範圍。 (5) 同意評估需求。 評估之請求者應提供請求者的需 求，其為評估需求的初始版本。評估者宜支援請求者分析要對產品評估的原因與如何描述評估需求。 宜考慮提交評估之產品的應用領 域及其目的之一般描述。亦可能考量關鍵性議題，例如生命財產安全 (safety)、安全、經濟或環境議題。並 宜考量適用的規定與法律。 在請求者的需求中，請求者 應表示評估宜達成何種範圍的需求。同時，評估者宜保證評估具足夠的說服力，以提供軟體產品品質的真正可信賴度。所以，評估者與請求者應對評估需求達成協議評估需求，此為繼
27、續評估過程的前提。 備考： 關於一軟體 產品或其組件的驗證，由評估的請求者規定包含產品需求的規範文件。 6.2.3 評估需求的內容 評估需求應包含提交評估之產品 應用領域的一般描述。應該提供產品目的之一般描述。 評估需求亦應該包含品質需求參考列表，例如 CNS 14948-1 所定義的品質特性。在此全景中，亦可以使用次特性。當需求參考不由 CNS 14948-1 所定義的特性時，應參考定義它之 權威文獻，並且請求者與評估者應該明確地陳述他們相互瞭解此特性。 應該給予評估需求中每個品質特 性的相對重要性，此適用於需要以不同評估需求來評估產品的某個部分。為了表示此重要性，可以使用附件 B 所建議之
28、評估等級的概念。 關於評估需求中的每個需求，應 該提供包含於軟體產品與其待評估組件中的資訊規格。此規格應該儘可能 地參考軟體工程標準。再者，可以規定組件中所使用之正規論 (formalism)的型式，或使用於產生組件之軟體發展方法的型式。 備考： 評估所要求 的資訊之程度與形式一方面能夠與評估成本有關，另一方面與產品之某一特定品質需求的重要性有關。 6.2.4 認可與報告 評估需求應在請求者與評估者之間的共同審查下認可。 評估需求應該包括於評估報告與評估紀錄中。 6.3 評估規格 6.3.1 評估規格之目的 規定評估之目的應該是定義評估 的範圍，與對提交評估的產品與其各種組11 CNS 150
29、14-5, X 3014-5 件所履行的測量。評估規格中詳 細節的程度宜達到保證評估的可重複性與可再生性。 備考 1. 規定的評估 可能是非確定性的。假如是那樣，宜使得在重複的或再生的評估下其結果是一致的。 然而，評估規格不宜包含評估者的專屬資訊。 2. 將包含評估規格的評估報告交付給評估請求者，請求者可能會向其他個體公開評估報告。因此，對於試圖保護一些個人資訊的評估者是不合理的。 6.3.2 評估規格的推敲 去規定的評估活動是由三個子活動所構成： (1) 分析產品描述。 (2) 規定於產品與其組件上所履行的測量。 (3) 查證 (verify)根據評估需求所產生的規格。 備考：為了儘早識別潛
30、在的問題，可以在其他活動時同時進行查證子活動。 6.3.2.1 分析產品描述 請求者應該提供提交評估之產品的描述。此描述的目標為： 允許定義評估的範圍，例如識別那些軟體產品組件可視為產品的一部分：或不視為產品的一部分，而僅為易於瞭解產品僅供參考。 備考 1. 此類識別可由那些部分的文件屬於產品，那些功能由產品實作或未由產品實作來規定。 2. 當提交評估之軟體產品是內嵌於由硬體、其他軟體產品、網或組織所構成的系統內時，因為於此產品之間的分隔並一定明顯，所以定義評估的範圍是重要的。 將提交評估之產品組件的識別給予評估者、瞭解其結構與識別所提供的資訊及如何存取的方法。 此描述應該包含實際提交評估之產
31、品組件的列表、關於產品結構的原理及產品相關文件的列表，所列出的組件可能包含其他無需要列出的較小組件。在列表中的每個組件與產品相關的文件，宜提供下列資訊： (1) 組件之性質的描述。 (2) 組件內所使用之正規論的資訊。 (3) 組件大小的資訊。 (4) 與其他組件的關係。 (5) 關於評估者之產品組件的可用性資訊。 在任何情況中，宜參考適當的軟體工程標準。 評估者應該檢查產品描述是否符合上述的需求。 評估者應該分析所提供的理念與組件的描述，以識別其與評估需求中所識別之組件的關係。 12 CNS 15014-5, X 3014-5 3. 在評估需求中，對所評鑑品質特性可能以理論 觀點來規定組件。
32、在產品描述中，列出實際的組件。可能發生 產品之某些實際的組件包含的資訊出現在 評估需求所規定的 數個組件中。 4. 需要用此一資訊是來識別那個評估能夠履行，此 資訊將會與評估需求一起使用，以建立評估規格。 5. 可以藉由與產品發展者的諮詢，改善產品描述的 分析，這將提供評估者機會，經由履行簡要的稽核，來決定所 要求評估的深度之評估。 6.3.2.2 規定測量 評估者應該為產品本身與產品描述中所識別出的各種組件分配評估需求。這應會導致將評估需求加以分解成，例如子特性。對於提交評估之不同的組件，此分解的結果可能是不同的。在此階段中，可能無法產品描述中所列出的一些組件進一步考量。 然後，評估者應該規
33、定預期使用於評鑑產品與所選擇組件之特性、次特性及屬性的測量。應該由下列型式的聲明組合明確地陳述此規格： (1) 量度的正規化規格，其適用於產品或一套識別的組件，與指令一起表示評估報告中的最終 (resulting)測量。 (2) 規定軟體需求之產品組件的聲明參考，其中將查證這些需求，並且使用程序的規格以查證這些需求。 (3) 軟體產品需求的規格，其為軟體需求文件所欠缺，或需要以更詳細的方式解釋有關查證此需求所使用之程序的評估與規格。 (4) 識別之標準或規則中的聲明參考，提供額外的軟體需求，並且作為查證這些需求的程序規格。 關於每個聲明，應該參考待量測或待查證組件的性質與所使用的正規論。 關於
34、此任務，評估者可以使用事先定義的評估規格，這些基本規格應該以本系列標準第 6 部所建議之評估模組規格的形式。 6.3.2.3 查證產品規格 評估者應該履行關於評估需求之評估規格的查證。 評估者應該檢查產品描述中所列出的組件提供所有必需的資訊，以根據評估需求履行評估。評估者亦應該查證規定的測量與查證是足夠的，以符合於評估需求中所表示的評估目的。 第一個檢查能夠導致產品描述中所列出的組件欠缺資訊的識別。下列其中一個方法可以解決此問題： (1) 產品描述中加入包含欠缺資訊之產品的參考，這意謂請求者將提供此組件與其他一起履行評估的組件。 (2) 簡化評估目的，這意謂修訂評估需求。 第二個檢查針對確認評
35、估規格中所提出的測量與查證與目前最新之技術發展的水準是一致的。下列其中一個方法可能做到此確認： 13 CNS 15014-5, X 3014-5 (1) 藉由識別相關的測量標準。 備考：此類標準可能是如本系列標準第 6 部所規定的評估模組。 (2) 藉由提供詳細的判定 (justification)，參考領域中適當之權威的文獻；評估規格中應包含此正當化理由。 6.3.3 評估規格的內容 評估規格應該包含： (1) 評估的範圍，提及產品描述中所識別的產品組件。 (2) 對照參考，履行評估需要資訊與產品描述中所列出產品組件及其他相關文件之間的交互參考。 (3) 履行的測量與查證之規格與產品組件的參
36、考，履行測量與查證於產品組件上。 (4) 測量與查證之規格與評估需求之間的對映，連同標準的參考或每個列出之測量或查證的正當化理由。 6.3.4 認可與報告 應認可評估規格，作為請求者與評估者間之共同審查結果。 評估報告與評估紀錄中應該包括 評估規格。再者，應於評估紀錄中報告第6.3.2.3 節所規定之評估需求的任何修改。 6.4 評估之設計 6.4.1 設計評估之目的 評估設計應文件化由評估者履行 測量所使用之程序，其中測量被規定在評估規格中。評估者應產生評估計 畫，其描述履行規定之評估需要的資源，以及履行各種動作之資源的分配。 備考 1. 此處考慮的 資源可能是，例如：履行評估動作之人力資源
37、、計算資源、或辦公室空間。 在評估計畫中細節的等級宜保證能以能勝任之方法履行動作。 2. 評估計畫通常包含一些評估者的專屬要訣 (know-how)。 6.4.2 評估計畫之製作 產生評估計畫的活動是由三個次活動所構成： (1) 文件化評估方法與產生草案計畫。 (2) 最佳化評估計畫。 (3) 排定關於可用之資源的評估動作。 6.4.2.1 文件化評估方法與產生草案計畫 為了文件化適用於實作這些組件所規定之測量或查證的詳細方法，此活動之目標是將所規定的測量或查證與待評估之各種產品組件的形式相結合。 評估者應該分析關於評估規格中所規定之測量或查證的技術限制，技術限制可能包括但不侷限於下列的限制：
38、 (1) 作為產品組件的正規論。 14 CNS 15014-5, X 3014-5 (2) 產品組件以電子化或文件呈現的事實。 (3) 事先定義之評估方法的存在。 備考 1. 可能以本系列標準第 6 部所建議之評估模組實作的形式，文件化事先定義評估方法。此類評估模組實作應該與評估規格中所使用的評估模組規格有關。 (4) 支援評估技術之工具的可用性。 (5) 產品組件的大小。 關於評估規格中所規定的每個測量或查證，評估者應該文件化適當的評估方法。 當所描述的評估方法為基於軟體工具的使用時，評估計畫中應識別此工具。此類識別應該至少包括工具的名稱、版本識別及起源 (例如供應者 )。 備考 2. 當評
39、估需求參考到評估層級時，參考附件第 B.2 節提供何種評估技術作為考量的評估層級與品質特性之功能的指引。 藉由產品組件的識別，應該完成評估方法的描述，其中運用評估方法於產品組件上。 當評估規格為了使得在評估報告中能夠包括之前解譯結果，要求測量的專家分析時，評估計畫應該規定解譯程序。此規格應該包含指令，以包括評估紀錄中程序效能的重要考量。 當為評估中產品規劃程式的執行時，應該描述執行需要的環境，以及其實際可用性的規定。 6.4.2.2 測量的最佳化 在此階段中，評估方法與評估規格中的元件有關，其中評估規格中的元件本身與評估需求有關。規劃每個基本評估方法以適用於提交評估的各種產品組件。能夠發生數個
40、基本評估方法適用於相同的產品組件或共通部分的組成。 為了避免重複評估者動作，應該審查草案評估計畫。為了減少錯誤的風險與降低規劃的評估者工夫 (effort)，這是必需的。 6.4.2.3 排定評估動作 一旦已經移除重複的評估動作，評估者應該排定規劃的動作。 評估者應該考慮資源的可用性，例如人員、軟體工具、及電腦。 評估者應該與請求者協議產品與其組件的遞送排程，應規定產品組件之遞送的媒體、格式、及副本的數量。 應該識別評估課程的會議需求。當請求者不為軟體產品發展者時，應該識別評估者與發展者之間的關係。尤其，應該規定發展者需要的支援，此類支援可能包括，例如訓練、非正規的討論、或辦公室設備。 當必要
41、時，應該規定發展與作業場地、及需要資源之取得。 6.4.3 評估計畫之內容 15 CNS 15014-5, X 3014-5 應該由評估方法的文件製作與評估者動作的排程這兩個部分構成評估計畫。 於評估計畫中，某些評估方法的 文件化可能包含評估者專屬資料之參考。在該情況下，評估者宜能夠證明關於相對應評估規格之 元件的方法適當性，與其運用方法的能力。 6.4.4 認可與報告 應認可評估計畫，作為請求者與評估者間之共同審查結果。 評估紀錄中應該包括評估計畫。 評估報告中宜包括評估方法或其參考之文件與產品組件之識別。運用這些評估方法於產品組件上。 6.5 評估之執行 6.5.1 評估執行之目的 評估執
42、行之目的係獲得結果，根 據評估規格中所規定與評估計畫中所規劃之評估需求，從履行量測與查證軟體產品的動作中得到該結果。 履行這些動作導致草案評估報告與評估紀錄之完成。 6.5.2 履行評估者動作 為了履行規劃的動作，評估者應該 (1) 管理由請求者所提供的產品組件。 (2) 管理由評估動作所產生的資料 (包括報告與紀錄 )。 (3) 管理履行評估動作所使用的工具。 此外，只要做出特定的規定，評估者可能： (1) 管理超出評估者前提範圍之履行的評估動作。 (2) 管理特定評估技術之使用所隱含的需求。 6.5.2.1 產品組件之管理 根據於評估計畫中所定義之排程，請求者宜交付產品組件與產品相關的文件
43、給評估者。 評估者應註冊所有產品組件與產品相關的文件。當產品的大小與複雜度證明產品時，應使用正規組態管理。 註冊資訊至少應為： (1) 組件或文件唯一識別符。 (2) 組件名稱或文件標題。 (3) 文件之條件 (包括特別地異常或實體條件 )。 (4) 依請求者提供之版本、組態、及日期資訊。 (5) 接收之日期。 除非與請求者協議，否則評估者應該保護所有產品組件與產品相關文件之機密性。 備考： 機密性需求影響許多評估工作的層面，包括所有產品相關資訊接收、處置、儲存、及廢棄。 6.5.2.2 評估資料的管理 履行評估動作通常包含量測產品與其組件，以獲得中間資料，並且為16 CNS 15014-5,
44、 X 3014-5 了產生包含於評估報告中的結果，解譯這些資料。中間資料可能是不同的性質，例如數字、圖形、圖表、來自組件的摘錄、或為評估所產生的正規化模型。 應以保護原始組件與文件的相同方法，保護中間資訊的機密性。再者，評估者應作所有必需的工作量，以預防這些資料任何意外或惡意的修改。尤其，當中間資訊的數量與複雜度是大量的，宜使用正規組態管理，以保持中間評估結果與評估產品之間的一致性。 評估者應該將任何中間資料包括於評估紀錄內，任何解譯是基於中間資料。在評估計畫所規定的評估紀錄中，亦應包括解譯過程期間所制定的決策。 6.5.2.3 工具使用的管理 評估動作可能需要軟體工具的使用，以收集原始資料或
45、履行中間資料的解譯。 備考 1. 此類工具的範例是計算程式碼量度的源碼 (source code)分析器、產生正規化模型的 CASE 工具、執行可執行之程式的測試環境、收集檢驗資料的檢查列表、或產生量測綜合的試算表。 當使用工具以履行評估動作時，應該在評估報告中包括工具的參考。參考應包含工具與其供應者的識別，以及工具的版本。 應該於評估紀錄中包括被使用工具之更詳細的參考。為了獲得相同的中間結果，紀錄應該包括工具之詳細組態與能夠重複評估動作需要的任何適當資訊。 2. 因為可重複性需求所 參考的中間結果未包括於評估報告中，所以此可重複性需求較強於第 5.3 節中所表示的需求。 3. 在某些情況中，
46、評估紀錄中包括可執行工具的副本可能是適當的。 評估者宜作所有必需的工夫，以保證所使用的工具如預期般的實際運作。評估者應該維護已著手動作的紀錄，以確認在評估過程中所使用的工具。 4. 例如，此類紀錄能夠 基於軟體之現有安裝的數量、或已經使用工具期間的時間總量。 應適當地訓練評估人員使用工具。 6.5.2.4 場所評估 在某些情況中，無法於評估者的建築物內履行評估動作。例如可能在發展者的場所或軟體產品運作中的場所履行評估。 當發生此情況時，評估者應控制所有履行的評估動作。尤其，評估者應該避免任何將使評估結果無效的情況。 評估者應該作所有必需的工作量，以保證能保持評估結果與中間評估結果的機密性。 6
47、.5.2.5 特定評估技術之需求 17 CNS 15014-5, X 3014-5 當評估計畫要求測試產品的可執行程式，應該正確地記錄測試中組態與測試環境。 當評估動作要求檢驗文件，建議使用核對表列。 6.5.3 審查與報告 於評估的執行期間，產生中間評 估結果與最終評估結果。為達到最大客觀性，宜由不同於履行動作的評估人員核對每一評估動作。 應審查所有評估結果。審查目標 取決於所考慮之評估動作的性質。參加審查，應該至少有一個人是不直接 參與所關心之評估動作的執行。評估紀錄中應該包括審查的報告。 一旦審查，評估報告中應該包括 評估規格中所規定的評估結果。再者，當評估計畫規定如此，評估報告中應該包
48、括一些中間結果或解譯決策。 6.6 評估之結論 6.6.1 評估結論之目的 由評估報告與評估資料之處置的審查構成評估結論的目的。 6.6.2 評估報告之共同審查 應該將草案評估報告交付給評估 的請求者。應安排請求者與評估者之間的共同審查。應給予請求者對於評估報告提出意見之機會，如 果有提出意見，應於評估報告之特定章節中包括提出的意見。應將評估報告交付給請求者。 6.6.3 評估資料與文件之處置 一旦已經正規地將評估報告交付 給請求者，評估者應該處置關於評估之資料。依資料之型式，應由下列其中一個方法完成處置： (1) 提交評估之文件應該退回給請求者，或存檔達規定期間，或以安全的方式銷毀。 (2)
49、 應將評估報告與評估紀錄存檔達規定期間。 (3) 應將所有其他資料存檔達規定期間，或以安全的方式銷毀。 當某些資料所規定之存檔期間屆 滿時，應該再次存檔達規定期間，或以安全的方式銷毀。 只要請求者明確同意，評估者可 以使用中間評估結果，以研究評估技術與軟體量度。 相對應國際標準：ISO/IEC 14598-5：2001：1998 Information technology Software product evaluation Part 5: Process for evaluators 18 CNS 15014-5, X 3014-5 附件 A (規定 ) 樣板評估報告 本附件提供評估報告之結構與內容的指引，概括本標準第 6 節所陳述之報告需求。此外，報告中要求包含一些補充資訊。 以下的小節描述評估報告的章節之內容。 A.1 第 1 節：識別 評估報告的此節包含與履行本評估有關之識別資訊。 評估者的識別 本小節應包含下列關於評估者的資訊： (1) 評估者組織之名稱。 (2) 評估者組織之地址。 (3) 已經完成評估的位置 (如果不同於上述地址 )。 (4) 負責評估之人員的名稱。 評估報告的識別 本小節應該包含報告的識別： (1) 報告之
