CNS 15014-3-2006 Software engineering - Product evaluation - Part 3 Process for developers《软件工程－产品评估－第3部：发展者过程》.pdf

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

1、1 印月956月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X3014-315014-3經濟部標準檢驗局印 公布日期 修訂公布日期 956月16日 月日 (共17頁)軟體工程產品評估 第 3 部：發展者過程 Software engineering Product evaluation Part 3: Process for developers 目錄 節次 頁次 0. 導論. 2 1. 適用範圍 2 2. 符合性. 2 3. 引用標準 2 4. 用語釋義 3 5. 評估觀念 3 5.1 一般觀點 3 5.2 使用者需要. 3 5.3 外部屬性 4 5

2、.4 內部屬性 4 5.5 品質指標 4 5.6 評估過程 4 5.7 評估與生命週期過程之間的關係 5 6. 評估過程要求. 5 6.1 一般要求 5 6.1.1 組織要求 5 6.1.2 專案要求 5 6.2 建立評估要求. 6 6.2.1 品質要求識別. 6 6.3 評估規格 6 6.3.1 外部品質要求. 6 6.3.2 內部品質要求. 7 6.4 評估設計 8 6.4.1.規劃外部評估8 6.4.2 規劃內部評估. 8 6.5 評估執行 8 6.5.1 內部評估 8 6.5.2 最終產品評估. 9 6.6 品質評估審查與回饋至組織. 9 2 CNS 15014-3, X 3014-3

3、 附錄(參考)A其他標準定義11 參考書目.15 英中名詞對照表16 0.導論 本標準預期使用於軟體發展期間。適用於需要有紀律之過程的所有軟體發展活動。本標準特別以量測與評估軟體的品質為目的。 本標準提供闡明品質要求(requirement)與實作(implement)及分析軟體品質測量的指導綱要。本標準適用於發展生命週期之所有階段中的所有軟體。著重於這些指標的選擇與報告，這些指標有助於經由量測中間產品的品質預測最終產品品質。亦著重於量測最終產品品質。 1. 適用範圍 當評估與發展並行且由發展者執行時，本標準提供軟體產品評估之實際實作的要求與建議。特別是可以使用本標準，應用CNS 14948-

4、1及ISO/IEC 9126-3與本系列標準第1、2、6部所描述的觀念。 在本標準中所描述的過程定義分析評估要求、規定、設計及履行評估動作、以及完結任何一種的軟體產品評估所需要的活動。 評估過程被設計為與發展同時被使用，需要將評估過程與軟體發展過程同步，並且當實體被交付時，需要被評估。 下列人員可能使用本標準： (1) 專案管理者，用以闡明品質要求、於發展期間監督與控制軟體品質，以及訂定用於保證所需品質已內建之決策。 (2) 軟體設計者，用以識別應被建入軟體中之特定的特徵，或應被變更以符合品質要求的規定特徵。 (3) 負責評估品質要求是否符合的品質保證/控制/稽核(audit)者。 (4) 維

5、護者(maintainer)，用以作變更與重新設計/再造工程實作決策。 (5) 軟體獲取者(acquirer)，當不需獨立的評估時，其為獲取軟體(例如委外軟體發展的情況)時與發展者協議的一部分。獲取者可能為扮演購買角色的人員、外包部分軟體產品的發展者、或終端使用者。獲取者的角色取決於獲取者與發展者之間的協議。本系列標準第4部描述從獲取者觀點的評估。 本標準為專案等級的應用而準備，為了從本標準中獲得完整的利益，組織應參與之。此觀點包含於本系列標準第2部。 本標準未規定特定的指標或量度(metric)，亦未規定任何特殊的發展方法。 2. 符合性 為符合本標準，組織應審查第6節中所有的要求與建議，以

6、識別有哪些是適用的要求與建議，且陳述尚未實作的要求。 3. 引用標準 CNS 14837 資訊技術軟體生命週期過程CNS 14948-1軟體工程產品品質第3 CNS 15014-3, X 3014-3 部：品質模型 ISO/IEC 14598-1:1999, Information technology Software product evaluation Part 1: General overview. ISO/IEC 14598-2:2000, Information technology Software product evaluation Part 2: Planning and

7、 management. ISO/IEC 14598-6, Software engineering Product evaluation Part 6: Documentation of evaluation modules. 4. 用語釋義 本標準使用本系列標準第1部所提供之定義與下列的定義： 4.1 計數規則(counting rule) 獲得測量(measurement)值的條件與程序。 4.2 外部屬性(external attribute) 個體之可量測的性質，僅能自如何與環境相關所衍生。 備考： 外部屬性是與要求相關的屬性(軟體的外部性質)，外部屬性僅能夠自其為其中之一部分的系統

8、操作行為衍生。 4.3 內部屬性(internal attribute) 實體之可量測的性質，能夠完全僅衍生自個體本身。 備考： 內部屬性是與軟體及軟體發展之內部組織有關的屬性。 4.4 單位(unit) 作為測量之標準的量。 備考：每個單位有一個相關的尺度。 5. 評估觀念 5.1 一般觀點 能夠以品質特性，描述軟體產品的品質。 備考：ISO/IEC 9126-4中已定義一組品質特性。 然而，一般而言，直接指定測量值給這些特性並不實際，反而是選擇一組軟體產品的軟體品質屬性，代表特性的主要觀點。這些屬性之測量值提供軟體產品品質的定量表示法。 本標準的重點是當發展生命週期期間應用軟體測量與評估時

9、支援發展者，藉由識別中間產品與發展活動的屬性與量測這些屬性達成支援。本標準提供方法，定量監督與控制發展過程期間尚在發展之軟體產品的品質方法。目標是識別於發展過程中儘可能儘早達到預期品質的問題。 軟體測量與評估之現今知識無法證明單套屬性的建議適用於每個軟體產品與每個軟體發展組織。所以軟體產品、中間產品及發展活動的屬性選擇是基於組織發展軟體的經驗。 5.2 使用者需要 使用者需要的識別是建立一般品質要求的重要觀點，這是透過在使用的特殊全景中，識別使用者之使用中品質的需要來完成。這些一般要求在本質上是非正規的，且要被正規化。能夠利用使用中品質量度量化與評估這些要求。 4 CNS 15014-3, X

10、 3014-3 備考： ISO/IEC 9126-4中描述一組使用中品質量度。 本標準中採用的方法是以外部屬性，有系統地敘述一般要求。 5.3 外部屬性 外部品質屬性表示軟體產品的品質特性，作為定量地表示外部品質要求。藉由指定標的測量值給每個屬性達成之。 當發展軟體產品時，收集屬性的實際測量值，以此提供軟體之品質特性的定量表示法。藉由比較全部屬性實際量測的值與標的值，做到品質評估。 備考：ISO/IEC 9126-2提供一組外部軟體品質量度。 5.4 內部屬性 為了監視與控制發展期間的軟體品質，將外部品質要求轉換成中間產品與發展活動的要求。 藉由轉換軟體產品外部屬性標的測量值成為中間產品與發展

11、活動的內部屬性標的測量值達到。 內部屬性的選擇與外部標的值轉換成為內部標的值為不可忽略的活動。除非發展者提供來自先前完成專案之收集與分析經驗的基礎建設(infrastructure)，否則主要取決於個人經驗。如果是那樣，發展者的經驗能夠支援活動。 備考1. 本系列標準第2部描述組織的觀點。 在發展期間，量測內部屬性的實際值，將實際值與標的值比較，提供發展期間軟體品質的控制。 能夠使用內部屬性識別異常(anomaly)或離群值(outlier)(即屬性值脫離正常預期的屬性值)，一般經驗顯示此類個體值得更為嚴密地檢查。 當定期性地量測內部屬性時(例如每個星期)，能夠使用某些內部屬性監督發展中的趨勢

12、。使用趨勢測量，早期識別產品與發展過程兩者有關的問題。 2. ISO/IEC 9126-3中提供一組內部量度。 5.5 品質指標 內部品質屬性能夠作為品質指標。尤其，內部屬性常常作為外部屬性的指標；但是未有任何品質指標與外部品質屬性間的通用和直接關係已應經過確認。然而，當小心使用時，普遍接受品質指標提供有用的指引。 品質指標的使用允許軟體發展者早期在發展中識別可能的品質問題，且馬上採取矯正的動作。 沒有一套適合於每個軟體發展工夫(effort)之眾所周知且通用的品質指標。在應用、發展方法與工具及專案組織中具有差異性，並且提及一些範例會有文化的差異。所以某些指標在一個組織中可能是有用的，但在另一

13、個組織中卻不可行。 5.6 評估過程 本標準描述的評估過程是由一組發展者所主導的活動構成，以發展過程期間所獲得之測量值的基礎上，履行這些活動。 備考1. 本系列標準第1部描述同屬(generic)的評估過程。 5 CNS 15014-3, X 3014-3 2. 本系列標準第2部描述評估的組織觀點。 評估過程由下列五個活動所構成： (1) 評估要求的建立，依議定的品質模型(quality model)識別一般品質要求所構成，第6.2節描述此活動。 (2) 評估的規格，由決定外部量度與標的測量值(評估準則)所構成，第6.3.1節描述此活動。規格亦由決定內部量度與標的測量值(評估準則)所構成，第6

14、.3.2節描述此活動。 (3) 評估的設計，由規劃資料收集動作所構成，第6.4.1與第6.4.2節描述此活動。 (4) 評估的執行，由在發展期間收集內部測量值，以及比較測量值與標的值(發展期間的評估)所構成。使用內部屬性值(品質指標)估計最終產品品質，第6.5.1節描述內部評估。當外部量測變成可用的且與標的值(產品品質的評估)比較時，亦由收集外部測量值所構成，第6.5.2節描述此活動。 (5) 回饋至組織，基於評估結果的審查，第6.6節中描述此活動。 5.7 評估與生命週期過程之間的關係 能夠於任何生命週期過程之全景內履行軟體產品的評估。 備考1. CNS 14837定義軟體生命週期過程。 本

15、標準主要與發展過程有關。 2. CNS 14837的第5.3節陳述發展過程。如同CNS 14837中所敘述的，此隱含也可能需要考慮維護過程(第5.5節)、支援生命週期過程(第6節)及組織生命週期過程(第7節)。當使用本標準在外包軟體發展的情況下，亦與CNS 14837第5.1節與第5.2節所描述的獲取過程與供應過程有關。 6. 評估過程要求 6.1 一般要求 本節關於組織與專案特定的要求。 6.1.1 組織要求 基於資料分析，發展者宜建立允許資料收集與過程修改的基礎建設。 備考：本系列標準第2部描述評估的組織觀點。 6.1.2 專案要求 發展者發展軟體宜遵循有紀律的發展過程，發展過程允許規劃與

16、引導軟體測量與評估。 備考1.CNS 14837描述生命週期過程，第5.3節描述發展。 2. 本系列標準第1部能夠找到軟體產品的概觀。 發展者應協調評估活動、支援過程與活動。 3. CNS 14837描述支援過程，特別包括品質保證過程(第6.3節)、查證過程(第6.4節)、確認過程及稽核過程(第6.7節)。 許多資料分析方法要求來自於相似條件下發展且具有可比較的品質要求之先前專案的資料。所以，發展者應運用發展者組織在先前專案中已經使用6 CNS 15014-3, X 3014-3 過的相似發展模型，在專案中亦宜運用相同一組的屬性供資料分析。 6.2 建立評估要求 本節是關於一般品質要求之建立與

17、其可行性的分析。 6.2.1 品質要求識別 發展者宜保證已識別適用於軟體系統的一般品質要求。當識別一般要求時，應考慮使用者需要、組織經驗、應用領域經驗、軟體完整性要求、所需的標準、法規、法律等。 備考1. CNS 14802描述軟體完整性層級(integrity level) 發展者宜確保議定的品質模型作為建構品質要求。 2. CNS 14948-1描述品質模型。 應產生其他系統要求的列表，這些要求可能影響品質要求的可行性。應考慮獲取關心的事，例如成本與排程限制、授權保證書及組織關心的事。應解決互斥的要求。 3. 焦點應在外部產品屬性上。 已識別的要求可能為衝突或協同的。宜解決要求之間的矛盾。

18、此外，假如品質要求的選擇與成本衝突，宜替換排程或系統功能性其中之一。 發展者宜執行品質要求的可行性分析，應考慮來自發展者組織中已執行具有相似品質要求之先前專案的經驗。 發展者宜保證要求為技術上可行、合理、互補、可達成及可查證。 應解析品質要求成為單一的一組品質要求，其中根據已議定的品質模型規劃要求。應從所有相關實體尋覓一般要求之最後列表的協議。 6.3 評估規格 本節是關於品質要求的定量。關於每個要求，選擇一或多個外部屬性表示要求。指定之標的值作為要求的定量表示法(評估準則)。 關於每個外部要求，在發展期間選擇一或多個內部屬性表示要求。內部屬性所指定之標的值作為控制發展期間的品質。 6.3.1

19、 外部品質要求 發展者應定義在哪些生命週期過程與活動中將實作測量與評估。 備考1. 在已經完成發展之後，通常將發生外部屬性的測量與評估。 發展者應定義哪些個體為待量測與評估。 2. 通常個體將是最終產品的一部分(例如：執行中的系統或使用者手冊)。 發展者宜定義哪些外部屬性要被量測。 發展者宜識別每個品質要求(來自於定義的外部屬性與實體)的量度。 發展者宜定義每個量度的標的值。 3. 標的值提供品質要求的定量表示法。 4. 標的值作為評估準則。 發展者宜定義履行測量的條件，此意謂識別其他屬性，其屬性值影7 CNS 15014-3, X 3014-3 響測量，以及影響定義這些屬性值。 發展者宜執行

20、品質要求之精煉的可行性分析，應考慮來自發展者組織中已執行具有相似品質要求之先前專案的經驗。 發展者應保證要求為技術上可行、合理、互補、可達成及可查證。 外部屬性值可取決於其他屬性的值，應規定這些條件，使得測量值是有意義的。 5. 例如，系統的反應時間取決於硬體、作業系統、其他於系統上執行的程式、使用者剖繪等。 6.3.2 內部品質要求 發展者應定義在哪些生命週期過程與活動中將實作內部屬性的測量與評估。 備考1. 在發展過程期間，通常將發生內部屬性的測量與評估。 發展者宜定義哪些個體要被量測與評估。 2. 通常選擇的個體將是中間產品與活動。 發展者宜定義量測的內部屬性為何。 3. 對於不同的中間

21、產品所需的屬性可能不同。 發展者宜為屬性與個體的每組相關組合識別量度。 發展者應定義一組內部屬性，其 (1) 涵蓋每個相關的中間產品與活動。 (2) 對於應用領域與發展中所使用的方法而言是適當的。 (3) 涵蓋識別的產品與發展的風險。 4. 發展風險之範例包括不穩定的規格、已識別但未解決的問題、進度落後等。 適當的趨勢測量宜包括其中。 5. 有些量度在軟體發展過程中採定期方式應用時，某些量度的有助於趨勢的識別，這類趨勢測量範例像是“完成的模組的個數”、“已解決之問題的個數”、“被改變的要求個數”等。 發展者宜定義一組與所有外部屬性相關的內部屬性；亦即相關於所有的品質要求，這些屬性將被當作為品質

22、指標。 6.相關的中間產品與收集內部測量資料： (1) 評估中間產品的品質，以找出其品質要求之達成(或未達成)的指示。 (2) 獲得最終產品之品質的指示(預測)。 7. ISO/IEC 9126-3可作為指標選擇的指引。 發展者應為已定義的品質指標描述預測模型；即指標與外部品質屬性間的關係。 8. 指標與其想要量測的品質屬性之間，並未要求嚴格一對一關係，但是，指標與相關品質屬性間的鏈結，宜有清楚的定義。 基於管理運用的效率考量，指標的個數宜保持在低量。可由現行過程，例如組態管理或整合測試的期間已蒐集到之資料支援的指標，8 CNS 15014-3, X 3014-3 宜賦予優先順序。 在適當時機

23、下，發展者應為內部屬性設定標的值。 發展者應定義測量的條件，此意謂要對其值會影響測量的其他屬性進行識別，並且定義出這些屬性的值。 9. 根據定義，能夠量測內部屬性的值，可由其他屬性獨立地測量出來。 6.4 評估設計 本節是關於評估的設計。外部評估部分關注外部品質要求，而內部評估關注於發展期間的內部品質監視與控制。 備考：從本系列標準第2部可找出定量評估(quantitative evaluation)計畫的參考。 6.4.1 規劃外部評估 發展者應為每一外部量度，規定獲得實際值時所要履行的資料收集活動(程序)。這些活動包括時間排程、責任及資料收集與分析工具使用的規格。若人員有特殊訓練的需要，亦

24、宜予以規劃。 發展者應該定義測量精密度。任何所應用到的統計模型，包括輸入資料要求、抽樣策略等。 備考： 如果發展者的組織已經定義了一組評估模組(evaluation module)，則此活動還包括評估模組的選擇。評估模組的文件化於本系列標準第6部中描述。 6.4.2 規劃內部評估 發展者應為每項內部量度規定獲得實際值所履行的資料收集活動(程序)。這些活動包括時間排程、責任及資料收集與分析工具使用的規格。若人員有特殊訓練的需要，亦宜予以規劃。 發展者應該定義測量精密度。任何所應用到的統計模型，都應該要規定包括輸入資料要求、抽樣策略等。 發展者應定義應變措施，如在測量結果未獲結論或有警示時的額外評

25、估。 發展者應考慮任何會對軟體發展活動的影響。在資料獲取需要之下，此測量集可能隱含對於發展過程的變更。 備考1. 硬體或軟體工具可能必須查找、評估、購買、調適或發展，以實作測量。測量集可能隱含對用以產出軟體系統之組織結構的變革。品質保證/控制組織或整個發展團隊可能需要測量運用與資料收集程序方面的訓練。如果測量的實作已經引起發展過程的變革，則可能要變革對教育發展團隊實施教育。 2. 如果發展者組織已經定義了一組評估模組，此活動還包括選擇評估模組的選擇。評估模組的文件化於本系列標準第6部中描述。 6.5 評估執行 本節是關於依計畫收集品質資料，以及與標的值(評估準則)比較。 6.5.1 內部評估

26、品質監視與控制。內部屬性的實際值被收集，如果在出現不預期值的情況9 CNS 15014-3, X 3014-3 下，成因要予以分析，藉此，讓發展者瞭解對問題作出反應。 發展者應根據已定義的資料收集動作，為事先定義之內部屬性收集實際的測量。如果品質要求被改變，發展者應考慮評估的規格(第6.3節)與評估的設計(第6.4節)。 發展者應採取必要的行動以確保收集到之資料的品質。在適當的時候，這些行動宜包括資料收集所用自動化工具的確認資料收集的以及由人工程序檢對資料。 發展者應將實際值與標的值比較。 發展者宜使用事先定義之指標的實際值，估計最終產品品質。來自於發展組織先前類似品質要求之專案的經驗宜列入考

27、量。 備考： 品質預測憑恃已確認的指標。發展組織首先將需要為數個專案收集指標值與產品測量值，以得到一組已確認的指標。 為了識別發展風險，發展者宜使用實際值監視趨勢。 為了識別離群值，發展者宜分析實際值。離群值常常標示問題或異常的狀況，宜經常尋求離群值的說明。有時離群值有好的理由，果真如此，可能沒有採取矯正措施的理由。 必要時，應採取應變行動。 6.5.2 最終產品評估 軟體產品的品質評估，於發展完成時開始。 外部屬性的實際值被收集。 備考1. 如果可能，軟體的組件可於發展完成前量測。 發展者應根據定義的資料收集動作，為事先定義之外部屬性收集實際的測量。如果品質要求被改變，則發展者應重新考慮評估

28、的規格(第6.3節)與評估的設計(第6.4節)。 發展者應採取必要的行動以確保收集之資料的品質。在適當的時候，這些行動宜包括資料收集的自動化工具的確認以及由人工程序檢驗資料。 發展者應該將實際值與標的值(評估準則)比較。 2. 本標準描述由發展者引導的評估過程，本系列標準第5部描述獨立的評估過程。 發展者應對評估結果作評鑑(assessment)。為了支援發展結果的決策(例如改善產品、檢視要求等)，應該總結實際值，並與其他值比較，例如時間與成本。 發展者應文件化評估結果。 6.6 品質評估審查與回饋至組織 發展者應使得組織可使用收集的資料於其他發展專案中。 發展者應審查評估的結果與評估過程、適

29、用的指標與量度之有效性(validity)。為了改善評估過程與評估模組，應使用來自審查的回饋。當需要改善評估模組時，為了要確認模組可供以後使用，應包括額外指標的資料收集。 10 CNS 15014-3, X 3014-3 備考：本系列標準第2部描述品質評估審查與回饋。 相對應國際標準：ISO/IEC 14598：2000 Software engineering Product evaluation Part 3: Process for developers 11 CNS 15014-3, X 3014-3 附錄A (參考) 其他標準定義 除非有其他標示，否則定義來自於本系列標準第1部。 A

30、.1 獲取者(Acquirer) 向供應者(supplier)獲取(acquire)或採購一項系統、軟體產品或軟體服務的組織。 CNS 14837 A.2 屬性(attribute) 個體之可量測實體或抽象的性質。 備考：屬性可以為內部或外部的。 A.3 發展者(developer) 於軟體生命週期過程期間，履行發展活動(包含要求分析、設計、測試至驗收(acceptance)的組織。 CNS 14837 A.4 直接測量(direct measure) 屬性的測量，不依賴任何其他屬性的測量。 A.5 評估模組(evaluation module) 一套關於特定軟體品質特性或次特性的評估技術。

31、備考： 這套包括評估方法與技術、待評估的輸入、待量測與收集的資料、驗收準則及支援程序與工具。 A.6 外部測量(external measure) 產品的間接測量，衍生自系統行為的測量，產品是系統的一部分。 備考1. 系統包含任何相關的硬體、軟體(客製軟體(custom software)或現成軟體(off-the-shelf software)與使用者。 2. 因為在電腦系統執行程式的作業期間計算失效(failure)數量，在測試期間所發現的失效數量為程式中失誤(fault)數量的外部測量。 3. 能夠使用外部測量評估品質屬性，該品質屬性接近設計的最後目標。 A.7 外部品質(externa

32、l quality) 當在已規定的條件下使用，產品符合所陳述與所隱含需要的範圍。 A.8 失效(failure) 在事先已規定的限制內，產品履行所需功能之能力的終止，或無能力履行必要功能。 A.9 失誤(fault) 電腦程式中的不正確步驟、處理或資料定義。 備考： 此定義採自IEEE 610.12-1990。 A.10 所隱含需要(implied needs) 當在特定的條件下所使用的個體，或許是尚未陳述的需要，但是實際的需要 備考：所隱含需要為真實需要，其中可能沒有將需要文件化。 A.11 指標(indicator) 12 CNS 15014-3, X 3014-3 能夠用來估計或預測另一

33、測量的測量。 備考1. 已預測之測量可以是相同或不同的軟體品質特性。 2. 可使用指標估計軟體品質屬性，與估計發展過程的屬性。指標是屬性之不精確的間接測量。 A.12 間接測量(indirect measure) 屬性的測量，衍生自一或多個其他屬性的測量。 備考： 當計算環境屬性與軟體屬性將影響測量時，計算系統屬性之外部測量(如使用者輸入的反應時間)是軟體屬性的間接測量。 A.13 中間軟體產品(intermedia software product) 軟體發展過程的產品，其作為另一個軟體發展過程階段的輸入。 備考：在某些情況中，中間產品亦可為最終產品。 A.14 內部測量(internal

34、measure) 產品本身的直接或間接測量。 備考：程式碼的行數、複雜度測量、走覽所發現之失誤數量及Fog指標(Fog Index)是作為產品本身的所有內部測量。 A.15 內部品質(internal quality) 當在已規定條件下所使用之產品屬性的總合性(totality)，決定產品滿足所陳述需要與所隱含需要的能力。 備考1. 本系列標準中使用用語“內部品質”，與“外部品質”相對照，實質上與ISO 8402中“品質”，具有相同的意義。 2. 使用的用語“屬性”與第4.1.1節中用語“特性”具有相同意義，而ISO 9126中使用更具特定意義的用語“特性”。 A.16 維護者(maintai

35、ner) 履行維護活動的組織。 CNS 14837 A.17 量測(動詞)(measure(verb) 作一個測量。 A.18 測量(名詞) (measure(noun) 藉由作測量，指定給個體屬性的數量或種類。 A.19 測量(measurement) 量度的使用，指定從尺度至個體屬性的數值(可以是數量或種類)。 備考： 當使用種類時，測量能夠是定性的。例如：軟體產品的一些重要屬性，如原始程式之語言(ADA、C、COBOL等)為定性的種類。 A.20 量度(metric) 已定義的測量方法與測量尺度。 備考1. 量度能夠是內部或外部的，並且為直接或間接的。 2. 量度包含分類定性資料的方法。

36、 A.21 品質(quality) 13 CNS 15014-3, X 3014-3 個體之特性的總體，傳達一個體滿足其所陳述需要與所隱含需要的能力。 備考1. 在合約的環境中，或受節制的環境中，諸如核子安全領域，需要是被明確規定的；然而在其他環境中，隱含需要宜識別與定義之(CNS 12680，備考1)。 2. 本系列標準第中的相關個體為軟體產品。 A.22 品質評估(quality) 一個範圍的系統化檢查此範圍代表一個個體有能力實現已規定之要求。 備考： 當因合約而為特定的使用者發展產品時，可正規地規定要求，或當不為特定的使用者發展產品時，例如消費者軟體(consumer software)

37、，由發展組織規定要求；或當使用者因比較與選擇目的而評估產品時，要求可以更一般化。 CNS 12680 A.23 品質模型(quality module) 特性集合與特性間之關係，以提供規定品質要求與評估品質的基礎。 A.24 使用中品質(quality in use) 特定使用者所使用的產品符合其需要之範圍，以達成在規定的使用全景中的有效性、生產力、生命財產安全(safety)及滿意度(satisfaction)之已規定目標。 A.25 評定(rating) 對映量測值至適當評定等級的動作，作為決定與軟體的特定品質特性有關的評等等級。 A.26 評定等級(rating level) 可排序尺度

38、上用來分類測量尺度的尺度點。 備考1. 評定等級能使軟體依照所陳述或所隱含需要分級(評定)(參照第10.2節)。 2. 適當的評定等級可結合不同的品質觀點，即“使用者”、“管理者”或“發展者(developer)”。 A.27 尺度(scale) 一組具有定義性質的數值。 備考： 尺度型式的範例：與一組種類對應的名目尺度(nominal scale)；與尺度點之有序集合對應的序數尺度；與具有等距尺度點之已排序尺度(ordered scale)對應的間隔尺度；以及具有等距尺度點與絶對零點的比率尺度(ratio scale)。使用名目或具序數尺度的量度產生定性資料，而使用間隔與比率尺度的量度產生定

39、量資料。 A.28 軟體(software) 資訊處理系統的程式、程序、規則及相聯文件化(documentation)的全部或部分。 備考： 軟體為智能的創造，與記錄它的媒體無關。 CNS 9359 A.29 軟體產品(software product) 電腦程式、程序及可能相關之文件化與資料的集合。 14 CNS 15014-3, X 3014-3 備考： 產品包含中間產品與為使用者，諸如發展者與維護者準備的產品。 CNS 14837 A.30 供應者(supplier) 與獲取者簽訂合約，依據合約內容供應系統、軟體產品或軟體服務的組織。 CNS 14837 A.31 系統(system)

40、由一或多個過程、硬體、軟體、設備及人員所構成之整合的組合，提供滿足所述之需要或目標的能力。 CNS 14837 A.32 使用者(user) 使用軟體產品以履行特定功能的個人。 備考： 使用者可包含運作者、軟體結果的接收者、或軟體的發展者或維護者。 A.33 確認(validation) 經由對客觀證據的檢查與供應，證實對特定預期使用的特定要求已滿足。 備考1. 於設計與發展中，確認是關注於檢查產品的過程，以決定和使用者需要之符合性。 2. 在已定義的操作條件下，於最終產品上履行確認。但在較早階段中，有可能為必要的。 3. “已確認”(validated)作為指定相對應的狀態。 4. 若有其他

41、預圖的使用，可執行多重確認。 CNS 12680 A.34 查證 經由對客觀證據的供應，證實已規定的要求已經滿足。 備考1. 在設計與發展階段中，查證是關注於檢查特定之活動結果的過程，以決定是否滿足活動之已陳述的要求。 2. “查證(verified)”用以指定對應的狀態。 CNS 12680 15 CNS 15014-3, X 3014-3 參考書目 1 CNS 14837 資訊技術軟體生命週期過程 2 CNS 14802 資訊技術系統與軟體完整性層級 3 ISO/IEC 9126-2 Information technology Software product quality Exter

42、nal metrics. 4 ISO/IEC 9126-3 Information technology Software product quality Internal metrics. 5 ISO/IEC 9126-4 Information technology Software product quality Quality in use metrics. 16 CNS 15014-3, X 3014-3 英中名詞對照表 A acceptance 驗收；接受 acquire 獲取 acquirer 獲取者 anomaly 異常 assessment 評鑑 audit 稽核 C con

43、sumer software 消費者軟體 D developer 發展者 documentation 文件化 E effort 工夫 evaluate 評估 evaluation module 評估模組 F failure 失效 fault 失誤 G generic 同屬 I implement 實作 infrastructure 基礎建設 integrity level 完整性層級 M maintainer 維護者 measurement 測量 metric 量度 N 17 CNS 15014-3, X 3014-3 need 需要 nominal scale 名目尺度 O off-the-shelf software 現成軟體 outlier 離群值 - Q - quality model 品質模型 quantitative evaluation 定量評估 R ratio scale 比率尺度 requirement 要求 S safety 生命財產安全 satisfaction 滿意度 supplier 供應者 V validation 確認 verify 查證