1、1 印月9511月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X3014-615014-6經濟部標準檢驗局印 公布日期 修訂公布日期 9511月16日 月日 (共31頁)軟體工程產品評估第 6 部：評估模組的文件製作 Software engineering Product evaluation Part 6: Documentation of evaluation modules 目錄 節次 頁次 導論 2 1. 適用範圍 2 2. 符合性. 3 3. 引用標準 3 4. 用語釋義 3 5. 評估模組概念. 3 6. 評估模組之文件製作的格式. 4
2、6.1 EM0：前言與簡介 4 6.1.1 前言. 4 6.1.2 簡介. 4 6.2 EM1：適用範圍 4 6.2.1 特性. 4 6.2.2 評估的層級 4 6.2.3 技術. 5 6.2.4 適用性. 5 6.3 EM2：參考. 5 6.4 EM3：用語釋義 5 6.5 EM4:輸入與量度. 5 6.5.1 評估的輸入 5 6.5.2 資料元件 5 6.5.3 量度與測量 6 6.6 EM5：結果的解譯 6 6.6.1 測量的對映 6 6.6.2 報告. 6 6.7 EMA：應用程序. 7 6.7.1 使用之技術用語的定義. 7 6.7.2 所需的資源 7 2 CNS 15014-6,
3、X 3014-6 6.7.3 評估指令 7 6.7.4 文件製作 7 附錄A(參考)評估模組的發展 8 附錄B(參考)評估模組的範例失誤密度. 9 附錄C(參考)評估模組的範例功能性 13 附錄D(參考)評估模組的範例可用性與使用中品質 23 參考書目 28 英中名詞對照表. 29 導論 軟體產品評估取決於一組提供有關軟體品質特性資訊的評估技術與量度(metric)。可將許多使用測量(measurement)結果之量度及相關方法供特定的軟體產品評估。ISO/IEC 9126-2與ISO/IEC 9126-3提供對應一個子特性的範例量度。在組織中要一致性地使用這些量度是困難的。發展供特定使用之新
4、量度可能是必要的。因此，組織之支援部門(supporting function)(參照本系列標準第2部)規定組織內每個正確與一致使用之量度可能是必要的。宜將文件化度量與相關方法之格式及其使用的指引標準化。評估模組(evaluation module)之概念提供此需要(need)的解決方法。 評估模組規定適用於評估品質特性的評估方法，且識別其所需要的證據。評估模組也定義基本評估程序與報告技術應用所產生之測量的格式。 文件化評估模組的一致方法具有一些優點： (1) 它在評估模組之理論基礎的描述中，提供共通的參考文獻。 (2) 它識別文件化與發展評估模組需求(requirement)的最小集合。 (
5、3) 它提供收集與分類大量預期之評估模組的必要工具。 評估模組提供有彈性且有結構化的方法，以產生適用於評估中間與最終產品的量度。根據本標準所產生之評估模組的使用有助於保證軟體產品評估是可重複、可再製及客觀的。 文件化評估模組的格式考慮下列： (1) 適用於軟體產品之評估的全景中。 (2) 格式支援發展有關技術發展之水準的新量度需要。 (3) 格式提供量度與其應用之精確的定義。 (4) 提供使用評估模組的人員所需的資訊。 附件A提供新評估模組之發展過程的指引。 附件B、C及D為評估模組的範例。 1. 適用範圍 本標準定義描述評估模組之文件(documentation)的結構與內容。在ISO/IE
6、C 9126與本系列之多個標準的全景中所使用之評估模組。 當產生新的評估模組時，意欲由專家使用本標準於評估科技中，例如測試實驗室、3 CNS 15014-6, X 3014-6 研究機構及其他。 2. 符合性 如果文件符合第6節的需求(評估模組之文件製作的格式)，則評估模組的文件製作符合本標準。 3. 引用標準 CNS 14948-1 軟體工程產品品質第部：品質模型 CNS 14837 資訊技術軟體生命週期過程 CNS 15014-1 資訊技術軟體產品評估第部：概觀 CNS 15014-2 軟體工程產品評估第部：規劃與管理 CNS 15014-3 軟體工程產品評估第部：發展者過程 CNS 15
7、014-4 軟體工程產品評估第4部：獲取者過程 CNS 15014-5 資訊技術軟體產品評估第5部：評估者過程 4. 用語釋義 本標準使用下列用語釋義。 4.1 評估模組（evaluation module） 量測軟體品質特性、子特性或屬性評估技術的套件。 備考：本套件包含： (1) 評估方法與技術。 (2) 評估的輸入。 (3) 待量測與收集的資料。 (4) 支援的程序與工具。 4.2 評估技術(評估所使用的技術)(evaluation technology(technology used for evaluation) 評估所使用的技術、工具、量度、測量及其他技術資訊本系列標準第2部。 5
8、. 評估模組概念 軟體產品之評估能夠是廣泛的任務。品質特性與子特性之不同層面可能需要運用不同的評估技術與收集不同的資料。為了管理此複雜度，宜將評估結構化成可管理單元。每個單元能夠包含一個或多個品質層面。然而，每個單元應該著重於一個特定品質層面的評估，運用特定評估技術評估之。應該收集與套裝實施這些評估的其中之一所需的資訊，以作為未來使用。此套件稱為評估模組。 使用評估模組之標準化格式的利益是： (1) 因為它提供內容的表格，使得什麼是評估必要的資訊與如何處理此資訊(原理、量度、工具、)是看得見的，所以它支援評估模組的發展。 (2) 因為資訊在同質的方法中是可用的，所以它支援評估模組的使用。 (3
9、) 因為它促進評估模組之程式館的建立與維護，所以它支援評估模組的再使用。 (4) 因為格式遵循標準需求，所以它支援評估模組的標準化。 評估模組收集履行品質特性之特定層面的評估所需的全部資訊，運用特定的評估技術評估之。闡明正在量測哪個軟體品質特性的特定層面。定義產生測量的程序及測4 CNS 15014-6, X 3014-6 量的先決條件與準確度。 評估模組提供評估技術、量度、及測量之間的鏈結，當本系列標準第3、4、5部建議評估技術的應用，能夠從評估模組程式館中選擇適當的評估模組(參閱本系列標準第2部)。 評估模組之文件製作有EM0到EM5六個部分及一個備選的附件EMA，EM0到EM5適合不同的
10、目的。 EM0提供有關評估模組的正式資訊，並且提供評估模組中所描述之評估技術的簡介。 EM1定義評估模組之適用性的範圍。 EM2提供相關的參考。 EM3包含評估模組所需的定義。 EM4規定評估所要求的輸入產品，並定義待收集的資料與待估計的測量。 EM5包含有關如何解譯測量結果的資訊。 選項的附件EMA包括運用評估模組的詳細程序。雖然EMA是選項的，但是.建議要包括它。 備考： 評估模組之文件製作格式遵循ISO Directives Part 3中所描述標準的正規需求。此促進評估模組的標準化。 6. 評估模組文件化的格式 應根據第6.1節、第6.2節、第6.3節、第6.4節、第6.5節、第6.6
11、節及第6.7節，來格式化評估模組的文件。 6.1 EM0：前言與簡介 6.1.1 前言 本節將提供關於下列資訊有關於 (1) 準備、認可、貢獻.及變更， (2) 與其他標準或其他文件的關係。 6.1.2 簡介 本節將介紹原理、背景及構成評估模組基礎的技術原理。 備考：第6.2.3節提供評估方法的正規描述。 6.2 EM1：適用範圍 6.2.1 特性 本節將識別評估模組能夠評估(evaluate)的特性、子特性或屬性。 備考：評估模組可能提供一個或多個特性或子特性。 應該識別品質模型(quality model)所描述的特性、子特性或屬性。除非有特殊的理由使用另一個模型，否則應該使用CNS 14
12、948-1的模型。 6.2.2 評估的層級 本節將描述評估模組所定義的評估層級。評估層級與所評估的特性、子特性、或屬性的重要性有關。描述層級應該考慮軟體假定的使用與軟體產品的環境(例如，生命財產安全(safety)條件、安全限制、經濟風險、及應用限制)。 5 CNS 15014-6, X 3014-6 以要應用之評估技術與待達成之評估結果的術語，層級定義評估之深度或周密。不同評估層級提供軟體產品之品質的不同信任層級。 備考： 能夠公式化成層級A、B、C、或D，如本系列標準第5部所描述的。CNS 14802中描述軟體完整性層級。 6.2.3 技術 本節將描述評估模組所應用的評估技術，應包含或適當
13、地參考相關的理論、模型或建構評估的啟發方法。 備考： 評估技術的範例是可靠度成長模型(Reliability Growth Model，GRM)、評效測試(benchmark testing)、及程式碼的靜態分析。 6.2.4 適用性 本節將識別評估模組之適用性的範圍。 備考1. 例如，評估模組可能適用於特殊的程式語言，或所有必要之語言的類別。 應該描述在軟體生命週期中，何處可以使用評估模組。如果在特定軟體生命週期過程中，意欲使用評估模組，則應該識別評估模組。 2.CNS 14837描述軟體生命週期過程。 6.3 EM2：參考 本節將提供規範與技術文件的參考。如果評估模組取決於其他評估模組的結
14、果時，則應於此處說明。 6.4 EM3：用語釋義 本節將定義使用於評估模組中的技術用語。或者，應參考能夠找到定義的來源。 6.5 EM4：輸入與量度 6.5.1 評估的輸入 本節將識別評估所要求的輸入，這些輸入應分為產品組件、產品資訊、支援資訊以及使用中產品的資訊。 備考1. 分類為產品組件的資訊，包括軟體需求規格、軟體設計描述、程式描述、源碼(source code)、可執行碼、及使用者文件製作。 2. 分類為產品資訊的資訊，包括軟體需求審查報告、軟體設計審查報告、程式審查報告、單元測試報告、及使用者文件製作審查報告。 3. 分類為支援資訊的資訊，包括品質保證計畫、組態管理計畫、程式測試計畫
15、、及程式語言與編譯器的描述。支援資訊不被評估，但支援資訊僅作為實施評估之必要背景資訊。 4. 分類為使用中產品資訊的資訊，包括測試報告與描述系統行為的操作報告。系統包括任何相關的硬體、軟體及使用者。 6.5.2 資料元件 本節將規定從輸入中擷取的資料元素。 備考1. 資料元素的範例是：包含註解之程式碼的行數、使用者手冊中句子長度的頻率分配、每個求助訊息中的字數、每個小時操作所觀測的6 CNS 15014-6, X 3014-6 失效(failure)數、每個模組中由規定詞彙掃描所發現之規定類型的符記數。 2. 一般而言，資料元件是來自計算量測的資料，但在某些情形中，原始資料本身可以構成量度。
16、6.5.3 量度與測量 本節將描述如何使用量度從資料元件計算測量。 如果結合量度以得到“較高階”的量度，則應該明白表示相依性。 在量測前應該陳述所有要滿足的假設與先決條件。 6.6 EM5：結果的解譯 6.6.1 測量的對映 本節將規定測量的意義，即測量結果的解譯。這包括將評估尺度對映至由定義的量度所獲得的值。如果對映是重要的，則應該定義做出對映所需之演算法(功能)的細節，或應該參考對映的來源。如果獲得單一特性、子特性、或屬性的多個量測，則本節將描述如何能夠結合測量成為特性、子特性、或屬性的評等。 應規定測量的準確度。 6.6.2 報告 本節將描述提供運用評估模組結果的報告內容。在某些情況中，
17、獲得之值的視覺化是重要的，且宜鼓勵。 6.7 EMA：應用程序 備考：EMA的包含是選項的，但如果包含，應有下列的內容： 6.7.1 所使用技術用語的定義 本節將定義，不為第6.4節所定義的用語，但使用於評估模組或參考來源EMA部分的技術用語。 6.7.2 所要求的資源 本節將規定當應用評估模組時所要求的資源，此應該包括：要求的軟體工具(宜識別任何所需的軟體工具，並宜參考同屬(generic)的工具型式與專用工具)、需要的硬體/軟體、測試工具組(test-harness)或其他設備、技能與資格(應該識別評估者或者評估組織所要求的任何特殊技巧與資格(例如驗證)、應用的工夫(effort)(如果此
18、工夫取決於產品的屬性(例如程式碼的行數)，則應估計評估模組之典型應用所需的工夫，並且應提供估計的演算法)、及任何其他所需的資源。 6.7.3 評估指令 本節將描述待遵循程序的完整細節，此宜包括證據的選擇(例如程式碼的抽樣)、原始資料的產生與記錄、計數規則、從原始資料計算量度的演算法、結果的記錄及工作中與最終文件製作的保留需求。尤其，宜強調所採取的步驟要保證結果的可追蹤性(traceability)與可重複性。描述的程序應符合ISO Guide 25。 7 CNS 15014-6, X 3014-6 6.7.4 文件製作 本節將概述評估模組所產生的內部文件製作。概述報告宜符合ISO Guide
19、25。 相對應國際標準：ISO/IEC 14598-6：2001 Software engineering Product evaluation Part 6: Documentation of evaluation modules 8 CNS 15014-6, X 3014-6 附件A (參考) 評估模組的發展 此參考附件提供關於發展新評估模組過程的指引。新的ISO/IEC 9126第2部、第3部、及第4部可能適用於關於此過程的輸入。評估模組發展過程應包括5個步驟： A.1 評估模組需求的識別 當識別新評估模組的需求與制定決策發展評估模組時，第一個步驟宜為識別新評估模組的需求，此包括品質模型
20、與品質特性或子特性的識別，亦宜決定評估的說服力。 A.2 評估模組的規格 基於識別之評估模組的需求，下個步驟為規定評估技術與評估的輸入(例如，源碼)，以及量度集合與資料元件基本集合。ISO/IEC 9126第2部、第3部、及第4部可能有幫助。 A.3 評估程序的發展 此步驟採取來自於先前步驟之正式規格，且增加一些程序的層面。應該於評估之全景中解釋量度與資料元件的解譯，並宜估計所要求的資源與發展詳細的評估程序，評估程序的試驗應用可能是必要的。 A.4 評估程序的描述 在此步驟中，宜根據評估模組格式，描述於先前步驟中所發展的評估程序，即描述應遵循本標準。 A.5 評估模組的查證與確認(valida
21、tion) 應該對照其規格來審查(或查證(verify)評估模組，並宜由評估技術涵蓋領域所描述的專家執行此工作。確認應該保證評估模組呈現技術發展之水準科技與組織所不熟悉的現有技術。 宜在不同的環境下，由不同群組的人員測試(或確認)評估模組。並宜回饋所獲得的經驗至評估模組發展團隊，作為更新的輸入。 9 CNS 15014-6, X 3014-6 附錄B (參考) 評估模組的範例失誤密度 資訊技術軟體產品評估評估模組：失誤密度 B.0 介紹 使用此評估模組以決定程式的失誤(fault)密度。於設計與測試階段，偵測大量失誤以降低軟體的潛在失誤，潛在失誤將造成操作階段的失效。操作階段之初的大量失誤造成
22、頻繁的失效與降低產品可靠度，所以宜保證失誤密度低於程式運作之前所規定的臨限值。 一般而言，計算軟體產品中之剩餘的失誤數目是不可能的，但藉由使用模型與失誤偵測的歷史資料，能夠估計數目。因此使用此估計來計算失誤密度。一般的估計程序如下： (1) 選擇採取適當的可靠度成長模型，例如，指數的RGM，或S-形RGM。 (2) 記錄測試期間中一個特定時間點之偵測失誤的累積數目。 (3) 決定可讓曲線符合記錄的資料集合之RGM方程式，所要求的參數數目。 (4) 當RGM方程式的時間(t)趨近於無窮大時，能夠計算潛在失誤的估計數目。 B.1 適用範圍 B.1.1 特性 可靠度成熟度失誤密度 B.1.2 評估的
23、等級 層級B如同本系列標準第5部中所定義。 B.1.3 技術 使用可靠度成長模型化技術，其可預測最終之軟體產品中失誤的總數。 B.1.4 適用性 (1) 系統測試期間普遍使用此技術，且適合所有型式的程式語言。 (2) 當需要與不同程式語言所撰寫之程式的其他值比較失誤密度值時，應該要正規化大小值。 B.2 參考 B.3 用語釋義 下列定義適用於評估模組： 失誤 軟體中的缺陷。 失效 一套既定的事件中任何事件的發生(或事件的未發生)。 LOC(程式碼行數，Lines of Code) 程式碼行數。 10 CNS 15014-6, X 3014-6 ELOC(錯誤程式碼行數，Erroneous Li
24、nes Of Code) 偵測與修改的失效之程式碼行數。 EELOC(估計之錯誤程式碼行數，Estimated Erroneous Lines Of Code) 錯誤程式碼行數之可估計的數目。 NCLOC(未註解之程式碼行數，Non-Commented Lines Of Code) 沒有註解的程式碼行數。 FDV(失誤密度值，Fault Density Value) 指示每個單位產品量之失誤數目的數值。 B.4 輸入與量度 B.4.1 評估的輸入 使用下列來源作為評估的輸入： (1) 產品組件：源碼。 (2) 產品資訊：程式測試報告、程式審查報告、程式查證報告。 B.4.2 資料元件 為了應用
25、評估技術，必須收集下列資料元件： (1) 偵測的失誤數目(ELOC)。 (2) 每個失效的偵測時間，必需以一致的方法量測時間，例如，CPU時間或者日曆時間。 (3) 程式碼行數(NCLOC)。 B.4.3 量度與量測 以下列式子計算失誤密度 FDV = ( EELOC ELOC ) / NCLOC B.5 結果的解譯 B.5.1 量測的對映 FDV(在此情況中，沒有量度的對映) 於公司內部之標度的實驗性來源： FDV10E2 差 備考：必須依照應用階段或軟體領域訂定臨限值。 B.5.2 報告 報告下列資訊，以作為應用評估模組的結果： (1) 源編碼的識別。 (2) 失誤密度值：FDV。 (3)
26、 對應的評等優、佳、普通、差。 B.6 應用程序 B.6.1 使用之技術用語的定義 11 CNS 15014-6, X 3014-6 RGM 可靠度成長模型：可靠度成長模型使用於估計錯誤程式碼的行數。 B.6.2 所需的資源 當應用評估模組時，下列資源必須為有效的： 所需的軟體工具： (1) LOC計算工具。 (2) 修改的行數計算工具。 (3) 可靠度資料收集工具與分析工具(選擇性)。 硬體/軟體平台 無特殊需求。 測試工具行頭或其他設備 無特殊.需求，但建議使用可靠度資料收集與分析工具。 技巧與資格 要求應用GRM的知識。 應用的人力工作量 大部分的工作量與失效的測試及紀錄有關，如果應用可
27、靠度與資料收集工具，則RGM的應用與計算FDV僅需要有限工作量。 其他的特殊資源 無特殊需求。 B.6.3 評估指令 (1) 樣本的選擇 選擇樣本源.碼，抽樣率宜超過一半。 (2) 原始資料的產生 從測試報告中擷取失效資料，如果測試報告是無效的，則履行測試。要求應用可靠成長模型GRM，使得“XXX”測試時間最少。 記錄每個失效發生的位置與時間。 計算具有修改時間之修改的ELOC與每個樣本總計的NCLOC。 (3) 演算法 使用可靠度成長模型RGM，估計潛在的錯誤LOC數目。藉由應用GRM模型，找出錯誤程式碼的估計數目： EELOC = RGM (失效，時間) 計算失誤密度值： FDV = (
28、EELOC ELOC ) / NCLOC 備考： 此處必須以所有細節解釋如何使用RGM模型或工具，或必須提供軟體工具之參考與產生估計的手冊。 (4) 工作與最後文件的保留需求： 一個星期量測一次，並且於測試階段期間分析趨勢。 動作：如果失誤密度的計算值大於某個規定值(評等=差)，則再審查、12 CNS 15014-6, X 3014-6 再測試、及除錯源碼，以及再次計算失誤密度。 B.6.4 文件化(內部的) 記錄關於內部文件化的下列資訊： (1) 源碼樣本的識別與版本。 (2) 測試文件化的識別與版本。 (3) 作為EELOC估計的失效集合。 (4) 應用的日期與負責的人員。 13 CNS
29、15014-6, X 3014-6 附錄C (參考) 評估模組的範例功能性 資訊技術軟體產品評估評估模組：功能性 C.0 介紹 使用此評估模組以決定軟體系統/組件的“功能性”，功能性預期的範圍是軟體組件提供符合規定條件下陳述與隱含的需求之功能。 如果具有軟體/系統需求的充分文件化定義，且如果充分描述陳述的需求，則正確的評估是可能的。在每個案例中，評估將考量如何文件化。 ISO/IEC 9126以子特性的觀點定義“功能性”，如下列章節中所描述。藉由更多次項目的量測，每個子特性是可量測的。 每個子特性所描述的基本項目將是子特性值之定義的近似層級。目前不存在此評估的公式，新標準之採用將信任在其應用全
30、景中將找到共通的協議。 關於此評估模組之品質模型考慮不止一個適合每個子特性之基本項目的量度。核對表列(checklist)中描述量測之量度的每個基本項目，每個問題的可能答案為(y/n/d)：y意指是、n意指否、及d意指廢除(因為不適用)。 問題的答案y/n與量度值與預測值之間的比較有關：如果量測值相等或較預測值為佳時，則答案為“是”，否則答案為“否”。 使用下列規則評估“功能性”特性： Vc = Vsci/ nsc |Vscj| = mi/ (nnd) Vc為特性之量測值 Vsci為i-子特性之量測值 Nsc為子特性的數目。 mi為1，如果i-答案為正，否則為0 n為測量的總數 nd為丟棄之問
31、題的數目 C.1 適用範圍 C.1.1 特性 功能性的量度指示軟體組件是否滿足定義的需求，軟體組件亦將滿足隱含的使用者需求；換言之，評估中軟體組件型式學的隱含需求。 功能性的量度包含關於5個子特性的指示符： (1) 適用性。 (2) 準確度。 (3) 互運性。 (4) 遵循性。 14 CNS 15014-6, X 3014-6 (5) 安全性。 在測試與使用者操作所要求的功能期間，適用性量度量測滿足的功能比率；換言之，功能所履行之任務未符合文件化的需求。 準確度量度量測精密性： (1) 計算之錯誤的範圍。 (2) 於實際與預期之履行任務結果間的差異。 (3) 實際操作程序與已文件化程序(例如手
32、冊內)之間的不一致。 互運性量度是量測軟體組件與其他系統、其他軟體、其他設備之間的可傳達層級： (1) 資料轉移(transfer)能力。 (2) 命令交換能力。 遵循性量度依環境規定或規則量測軟體組件的標準化層級。 安全量度依照非法存取與/或非法操作量測防護效能層級。 C.1.2 評估的層級 本系列標準第5部的附件B描述評估等級之選擇的準則。 在此模組中以不同的層面(安全、經濟)來量測關鍵性特性，可影響評估準確度的定義、執行量測的定量定義、及使用的技術。決定評估層級的問題為：如果“功能性”不符合需求，則將存在何種問題？ 下表指示每個層級的層級與條件，考慮： (1) 生命財產安全層面。 (2)
33、 經濟層面。 (3) 安全層面。 (4) 環境層面。 應該產生層級之選擇，採用於至少較高層級，其中層級產生於每個層面的分析。 層級 生命財產層面 經濟層面 安全層面 環境層面 A 許多人員遭受殺害 財務的災害(公司將不存在) 策略之資料與服務的保護 不能復原的環境損害 B 人類生命的威脅 大規模的經濟損失(公司被佔用) 關鍵資料與服務的保護 可復原的環境損害 C 財產損失，少數人員受害 重大的經濟損失(公司受到影響) 對照錯誤風險的保護 局部的污染 D 輕微的財產損失，對人員沒有風險 可忽略的經濟損失 無識別之特定的風險 無環境風險 C.1.3 技術 下表指示所採用的評估技術以評估功能性，從選
34、擇等級的相關列位置開始往下；即如果所採用的評估層級為B，從層級B至層級D的技術適用於評估。 15 CNS 15014-6, X 3014-6 功能性的評估技術 層級A 正式的證明(目前沒有足夠的技術評估層級A的功能性) 層級B 組件測試(component testing)(白箱測試(white-box testing) 層級C 審查、程式碼檢驗 層級D 功能性的測試(functional testing)(黑箱測試(black-box testing) 下列為表中所指示之可能技術的介紹描述。 正式證明 程式證明最常見的方法是“歸納判定(inductive assertions)”的方法，目標
35、是關於評估中軟體組件之一組定理的發展。其方法首先撰寫軟體組件之輸入條件與正確結果的判定。獨立證明必須顯示程式將總是最終會終止。其他證明技術是“述詞轉換器”、“次目標歸納”、“計算歸納”、“結構的歸納”、及“週期性判定”的方法。 未來將擴大此評估模組，涵蓋此評估層級，但是此功能性的層級目前是不可量測的。 組件測試 依需求測試每個軟體組件，亦測試已完整整合的軟體組件。 白箱測試 此技術允許檢查軟體組件的內部結構：測試者從程式邏輯的檢查中取得測試資料。 白箱測試與測試案例執行或涵蓋程式邏輯(源編碼)的程度有關。有用的涵蓋率(coverage)準則是“敘述覆蓋範圍”，即要求程式的每個敘述至少執行一次。
36、較強的邏輯覆蓋範圍準則為“路徑覆蓋範圍”、“決策覆蓋範圍”、“條件覆蓋範圍”、“決策/條件覆蓋範圍”、及“多重條件覆蓋範圍”。 審查 包含軟體組件與所有適當文件之視覺檢驗/分析。 程式碼檢驗 程式碼檢驗包含軟體組件的閱讀或視覺檢驗，目的是發現錯誤，但不是發現錯誤的解答。然而，此技術無法發現“高層級”錯誤，例如設計的錯誤，必須將程式碼檢驗視為電腦基礎檢驗的補充，例如程式碼的靜態分析。 核對表列 審查活動為基於一個已定義的核對表列，允許以少許主觀的準則重複活動。於核對表列中的問題必須盡可能簡單；問題的目標必須為基本資訊。核對表列接受基於應用之經驗修訂、整合、及刪除。 程式碼的靜態分析 藉由分析源碼
37、，推論軟體中錯誤的存在(是有可能)。靜態分析的一種型式為16 CNS 15014-6, X 3014-6 “控制流”，在此時源碼成片段，並且檢查片段間的關係以進行查證，例如，沒有無法執行的片段，或沒有無法到達“停止”敘述的路徑。 分析的另一種型式是關於“呼叫圖形”，或“軟體系統的結構”，其描述所有軟體單元的巢套(nesting)。 功能測試 此為企圖發現軟體產品與其外部規格之間不一致的過程。分析規格以取得一組測試案例，充份定義測試案例與應用特定技術及方法(等價分割法、邊界值分析法、因果圖法、錯誤猜測法、)是重要的。 黑箱測試 軟體視為一個黑箱，即與程式的內部行為與結構無關。測試者僅對根據規格以
38、發現程式無法運行的環境有興趣。如果未有適當的徹底測試，則將需要定義適當的測試案例。 C.1.4 適用性 此評估模組的範圍決定評估中軟體產品的“功能性量測”，當出現下列兩種條件時，此評估模組即是適用的。 (1) 關於評估過程之需求的條件： 適用於評估中特性之評估過程的特定需求(功能性的軟體需求)已滿足時。 (2) 關於文件輸入評估的條件： 適用於文件輸入評估過程的可用性。 評估過程的需求： 功能性的軟體需求 適合性 (1) 應文件化所有功能需求。 (2) 應於文件中描述產品的硬體架構。 (3) 應於文件中描述產品的軟體架構。 (4) 應定義所有輸入、處理、及輸出。 (5) 應識別給實驗室評估之軟
39、體組件與評估中的軟體組件。 (6) 應識別所有測試的硬體/軟體需求。 (7) 應文件化履行的測試結果。 (8) 應完整地規定測試規格。 (9) 關於功能需求，所有設計組件應是可追蹤的。 (10) 應描述每個測試的硬體/軟體環境。 精確性 (1) 程式與資料應無本身內及與文件製作的矛盾。 (2) 軟體文件中所提及的功能應是完整且可正確的執行。 安全性 (1) 應定義安全需求。 (2) 應識別所有的安全威脅、安全目的、及安全執行功能。 17 CNS 15014-6, X 3014-6 (3) 安全執行功能應實現安全目的。 備考：此需求表列需要與評估中生產的軟體特定需求整合。 文件製作輸入至評估：
40、適用於文件輸入至評估過程的可用性 下表描述關於評估過程的毎個評估層級所需的文件/組件，亦指示當在同屬的軟體生命週期中可使用的評估模組。 在表格中，某個層級所定義的內容全部在其他較低的層級亦為有效。 要求的軟體組件、文件 適用的軟體生命 週期階段 評估需求 層級A 軟體需求審查報告、軟體需求查證報告、需求測量報告、軟體設計審查報告、軟體設計查證報告、設計測量報告、使用者文件製作審查報告、軟體規格方法與工具的描述、設計方法與工具的描述、程式語言與編譯器的描述所有軟體生命週期階段期間 不適用 層級B 程式審查報告、程式查證報告、程式審查報告、程式測量報告、程式測試計畫、程式測試報告、單元測試計畫、單
41、元測試報告、系統需求分析、系統規格與設計、系統測試計畫、組態管理計畫、組態管理報告、品質保證計畫、品質保證報告 所有軟體生命週期階段期間 在測試活動期間與“發展者(developer)”合作(7)、機器碼執行於“標的環境”之可用性、於“評估環境”與“標的環境”間之改變資訊的可用性。 層級C 源碼、程式語言與編譯器的描述、軟體需求規格(5)、軟體設計描述、系統審查報告、系統查證報告、系統測試計畫、系統測試報告 在軟體發展階段之後 使用C語言撰寫源碼(6)、在審查過程期間與“發展者”合作 層級D 可執行的產品(1)、產品描述(2)、使用者手冊(3)、系統手冊、測試案例(4) 在遞交產品之前 註(1
42、) 此意謂在評估環境中運產品或進入有可能執產品之可能性的標的環境。 (2) 產品描述為關於使用者對期望產品的資訊收集，它可能有“產品包裝”、或“使用者需求”、或其他資訊的型式。 (3) “使用者手冊”為關於如何利用軟體產品的資訊收集，它可能有書面或未有書面支援之“互動資訊”的型式。 (4) “測試案例”包括測試資料與測試結果，評估過程將利用此類資訊，但並不侷限於利用它。 (5) “軟體需求規格”意謂必要的資訊收集：功能需求、軟體及其外部介面的效能設計限制。 (6) 源編碼語言的限制起因於特定語言之“剖析器(parser)”(或預先編譯器、或直譯器)的實驗室之可用性，它是一個暫時性的限制，當實驗
43、室能夠處理有關18 CNS 15014-6, X 3014-6 的“剖析器”時，擴大至其他的“語言”。 (7) 在此全景中之“發展者”為已經生產軟體產品的“組織”。關於表中所指示之文件製作的詳細描述，參考本系列標準第5部。 C.2 參考 C.3 用語釋義 C.4 輸入與量度 C.4.1 評估的輸入 下列為每個評估層級之最小輸入文件製作。關於文件內容的更詳細資訊，參閱本系列標準第5部：資訊技術軟體產品評估第5部：評估者過程。 文件的標題為“指示的”，可能會依照發展環境中內部/標準文件而改變。宜整合/描述於相似文件(本系列標準第5部)中描述之所需內容。此為一個有用的交互參考指示出評估所需的資訊。
44、評估層級A的輸入 軟體需求審查報告、軟體需求查證報告、需求測量報告、軟體設計審查報告、軟體設計查證報告、設計測量報告、使用者文件製作審查報告、軟體規格方法與工具的描述、設計方法與工具的描述、程式語言與編譯器的描述。 程式審查報告、程式查證報告、程式審查報告、程式測量報告、程式測試計畫、程式測試報告、單元測試計畫、單元測試報告、系統需求分析、系統規格與設計、系統測試計畫、組態管理計畫、組態管理報告、品質保證計畫、品質保證報告。 源碼、程式語言與編譯器的描述、軟體需求規格、軟體設計描述、系統審查報告、系統查證報告、系統測試計畫、系統測試報告。 可執行的產品、產品描述、使用者手冊、系統手冊、測試案例
45、。 評估層級B的輸入 程式審查報告、程式查證報告、程式審查報告、程式測量報告、程式測試計畫、程式測試報告、單元測試計畫、單元測試報告、系統需求分析、系統規格與設計、系統測試計畫、組態管理計畫、組態管理報告、品質保證計畫、品質保證報告。 源碼、程式語言與編譯器的描述、軟體需求規格、軟體設計描述、系統審查報告、系統查證報告、系統測試計畫、系統測試報告。 可執行的產品、產品描述、使用者手冊、系統手冊、測試案例。 評估層級C的輸入 源碼、程式語言與編譯器的描述、軟體需求規格、軟體設計描述、系統審查報告、系統查證報告、系統測試計畫、系統測試報告。 可執行的產品、產品描述、使用者手冊、系統手冊、測試案例。
46、 評估層級D的輸入 19 CNS 15014-6, X 3014-6 可執行的產品、產品描述、使用者手冊、系統手冊、測試案例。 C.4.2 資料元件 從輸入文件所擷取的資訊為兩種型式： (1) “評估過程”的資訊，例如需求列表。 (2) “熟諳系統”之有用的資訊。 資訊之第一種型式是評估過程的資料；關於每個使用的量度，下節描述這類的資料。 第二種型式的資訊未受限於評估，可能由發展者提供給評估者各種非正式的文件所構成，是評估之文件的一部分(例如，傳真、郵件等)。評估者應該維護這些文件與所有其他文件 (即量測活動的工作報告)。 第4.2節定義此評估模組中之一般層級的資料。關於評估模組的較低等級，即
47、“量度”(失誤密度)的評估模組，本節應該更明白與精確。 C.4.3 量度與量測 下列是從特性功能性中分解之子特性，對於每個子特性，指示作為評估的量度。 遵循性的量度 遵循(專案)軟體發展標準比例 正確地運用專案發展標準有關之規則與軟體發展標準規則的總數之比例。 遵循(專案)文件標準比例 正確地運用專案文件標準有關之規則與專案文件標準規則的總數之比例。 標準化資料格式比例 標準化的資料格式與待標準化的資料格式之比例。 標準化字元比例 標準化的圖形字元及控制字元與那些待標準化的字元的比例。 適合性的量度 功能可用的比例 使用者有效地處理的功能與規定功能的總數之比例。 功能的規格變更比例 進入操作(
48、操作測試)之後，必須變更(變更包括增加、修改、及刪除)的功能與規定功能的總數之比例。 備考： 規定功能為定義於需求規中格的功能、或由可操作之軟體所提供或使用者手冊中所描述的功能，作為使用者可存取的功能。 輸入輸出定義精確的比例 清楚且正確地定義輸入輸出資料與輸入輸出總數之比例。 專案文件比例 產品可用之專案文件與專案文件要求的總數之比例。 產品文件製作比例 產品可用之產品文件與產品文件要求的總數之比例。 20 CNS 15014-6, X 3014-6 準確性的量度 有效位數(Significant digit)比例 實作(implement)的有效位數與要求特定準確度之資料項目所要求的有效位
49、數之比例。 程式碼量的比例 實際程式碼的量與所需程式碼的量之比例。 正確性比例 獲得所需的精確程度的資料與預期的資料之比例。 互運性的量度 可傳達的比例 符合網路通訊標準之網路通訊的比例。 系統與所有相互運作系統(inter-operating system)之共通技術語彙之比例。 匹配的資料格式比例 資料格式匹配相互運作中其他系統的資料格式之比例。 匹配的特性比例 圖形字元與控制字元匹配相互運作中其他系統的那些字元之比例。 安全性的量度 軟體存取控制比例 未授權的存取軟體與嘗試數目之比例。 資料存取控制比例 未授權的存取/變更資料與嘗試數目之比例。 加密的資料比例 加密的資料與待加密的資料之比例。 存取歷史比例 具有存取歷史之機密資訊紀錄與所有機密資訊紀錄之比例。存取歷史包含由誰存取、何時存取、及存取什麼機密資訊紀錄的資訊。 資料損壞 運作期間資料損壞的頻率。 偵測的異常運作比例 偵測的非法運作與非法運作輸入之比例。 C.5 結果的解譯 C.5.1 量測的對映 功能性之每個子特性的評估尺度與預見問題之確定答案的百分比(參閱介紹)有
