1、 1 印月 94 10 月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X6045-2 14785-2 經濟部標準檢驗局印 公布日期 修訂公布日期 92 11 月 27 日 月日 資訊技術 軟體過程評鑑 第 2 部：過程和過程能力的參考模型 (共 42 頁)Information technology Software process assessment Part 2 : A reference model for processes and process capability 目 頁 1. 適用範圍 . 3 2. 考文件 . 3 3. 用語釋義與縮
2、寫 . 4 4. 考模型之結構 . 4 4.1 過程維 4 4.2 過程能維 . 5 5. 過程維 . 6 5.1 主要生命週期過程 10 5.1.1 客戶 -供應者過程別 (CUS) .10 5.1.2 工程技術過程別 (ENG)12 5.2 支援生命週期過程 16 5.2.1 支援過程別 (SUP) .16 5.3 組織生命週期過程 19 5.3.1 管過程別 (MAN)19 5.3.2 組織過程別 (ORG) 19 6. 能維 24 6.1 第 0 級：未完成過程 .25 6.2 第 1 級：已執過程 .25 6.2.1 PA 1.1 過程效能屬性 .25 6.3 第 2 級：已管過程
3、.25 6.3.1 PA 2.1 效能管屬性 .25 6.3.2 PA 2.2 工作產出管屬性 25 6.4 第 3 級：已建過程 .26 6.4.1 PA 3.1 過程定義屬性 .26 6.4.2 PA 3.2 過程資源屬性 .26 6.5 第 4 級：可預測過程 .26 6.5.1 PA 4.1 測屬性 26 6.5.2 PA 4.2 過程控制屬性 .26 6.6 第 5 級：最佳化過程 .27 2 CNS 14785-2, X 6045-2 6.6.1 PA 5.1 過程變更屬性 27 6.6.2 PA 5.2 持續改善屬性 27 6.7 分級過程屬性 27 6.7.1 過程屬性的分級尺
4、度 27 6.7.2 過程屬性分級尺度的校準 . 27 6.7.3 過程屬性的分級 . 28 6.7.4 過程屬性分級的參考資料 . 28 7. 參考模型的相容性 29 7.1 概述 29 7.2 模型目的 . 30 7.3 模型範圍 . 30 7.4 模型元件和指示符 30 7.5 對應 . 30 7.6 轉換 . 30 附錄 A(參考 )CNS_(ISO/IEC12207)與參考模型之對映 31 附錄 B(參考 )過程和過程屬性表 . 35 附錄 C(參考 )定義過程之式樣指導 38 引用標準 . 40 英中名詞對照表 . 41 3 CNS 14785-2, X 6045-21. 適用範圍
5、：本標準定義了軟體過程和過程能力的參考模型，它是組成軟體過程評鑑的基礎。參考模型是以高階化方式來定義，以達成良好軟體工程所需之基本目標，而此高階化目標說明了應達成何種目標，而非探討如何達成。 此參考模型適用於任何期望建置軟體採購 (acquisition)、供應 (supply)、發展(develop)、運作 (operation)、演進 (evolution)和支援 (support)等過程及後續改善其能力的軟體組織，但該模型並未假設特定的組織架構、管理哲學、軟體生命週期模型、軟體技術或發展方法。 此參考模型的架構將各過程予以適當地編排，以協助軟體人員了解和使用它們，並能持續改善軟體過程的管
6、理。 對於軟體過程評鑑而言，評鑑員 (assessor)能使用與此參考模型相容且更詳細的模型，包含一組廣泛的過程效能和過程能力的廣泛指示符，以判斷該組織各過程的能力。本標準規定了欲達到與參考模型相容之模型所必須符合的需求。 本系列標準並不適用於驗證 /登錄所有組織過程能力的任何方案。 表 1 顯示了本標準的主要讀者，其中包含每一個團體為何、何時及如何需要使用該參考模型。 2. 參考文件：下列參考文件包含了構成本標準的各種規定 (透過參考本文內容 )。對於任何標明日期的參考文件、後續修正或修訂版本並不適用於這些出版物。因此，為了鼓勵根據本標準的協議團體查明應使用下列參考文件最新版本的可能性，而對
7、於未標日期的參考文件，是認定該參考文件的最新版本能適用。 CNS 12681：品質制度 設計、發展、生產、安裝和服務等品質保證模式 CNS_(ISO/IEC 12207)： 1995，資訊技術 軟體生命週期過程 CNS_(ISO/IEC TR 15504-9)： 1998，資訊技術 軟體過程評鑑 第 9 部：詞彙 備考：本系列標準使用者應注意相關標準之最新版本。 4 CNS 14785-2, X 6045-2 表 1 參考模型之使用 何人 (Who) 為何 (Why) 如何 (How) 何時 (When) 評鑑模型發展者 發展與參考模型相容的模型 證明發展模型與參考模型具相容性 作為模型結構的
8、參考資料 作為證明能力的一組準則 在模型發展期間 在發展之後，且在使用於實作評鑑之前 軟體組織 了解改善軟體過程要進行事宜為何 判定各過程的能力並向客戶證明 了解評鑑員可能評估的過程和能力 作為管理欲實作的相關軟體過程和能力之工作指導 作為強調過程和過程能力考量事項之參考指導作為技術訓練文件 作為允許有效的比較基礎之參考框架 作為過程和過程能力的核對清單 在組織的軟體過程實作期間 在組織的軟體過程發展 /檢視期間，並作為持續改善活動的一部分 在組織的軟體過程發展 /審查期間，並作為持續改善活動的一部分 作為開展內部的市場分析活動 在要約徵詢期限 在評鑑之前 軟體過程評鑑員 執行符合組織的軟體過
9、程評鑑 建立評鑑模型之相容性 作為過程和過程能力核對清單以及發展參考模型的知識 作為使用於執行模型相容性目的之參考資料 在軟體過程評鑑之前和評鑑期間 在評鑑或評鑑計畫之前 工具發展者 發展軟體過程評鑑工具 作為評鑑工具的參考資料和需求 在發展評鑑工具之前和發展期間 3. 用語釋義與定義：本標準適用本系列標準第 9 部所提供的用語和定義。 4. 參考模型之結構 它係由二種維度所構成： 過程維度 (process dimension)，依過程目的陳述來區分特性，其為過程必要的可量測目的； 過程能力維度 (process capability dimension)，依據一組過程屬性來區分特性，可適用
10、於任何過程，代表在管理過程和改善其執行能力上必要的 可量測特性。 4.1 過程維度 參考模型將過程維度裡的各種過程，依照其所指定的活動型式，分為三組生命週期過程群 (groupings)，其中包含有五種過程種類 (categories)。 5 CNS 14785-2, X 6045-2主要生命週期過程 (Primary life cycle processes)包含的過程種類有客戶 -供應者 (Customer-Supplier)及工程技術 (Engineering)兩種，並說明如下： 客戶 -供應者 (Customer-Supplier)過程種類包含直接影響客戶、支援發展和移轉 (trans
11、ition)軟體至客戶的過程，並提供軟體產品及 /或服務的正確運作和使用。 工程技術 (Engineering)過程種類包含直接規定、實作或維護軟體產品的過程，它與系統及其客戶的文件有關。 支援生命週期過程 (Supporting life cycle processes) 所包含的過程為支援(Support)種類，並說明如下： 支援 (Support)過程種類包含在軟體生命週期不同時間點所可能被任何另一過程 (包括其他的支援過程 )運用的過程。 組織生命週期過程 (Organizational life cycle processes)則包含管理 (Management)和組織 (Organ
12、ization)兩個過程種類，並說明如下： 管理 (Management)過程種類係由包含在軟體生命週期中，管理任何專案或過程型式的任何人員所可能使用一般化實務性質的過程所組成。 組織 (Organization)過程種類包含各種建立組織營運目標和發展過程、產品和資源資產的過程，有助於該組織在專案使用時能達成其營運目標。 過程種類和各種過程依其活動型式提供一種分組的方式。在參考模型裡的每一個過程是根據其目的陳述 (purpose statement)來加以說明。當建置於特定環境時，這些陳述包含該過程的唯一功能性目的，而目的陳述包括了識別該過程成功實作結果的額外資訊。滿足過程目的表示在建立過程能
13、力上邁出了第一步。 參考模型並未定義要如何或以何種順序來達成過程目的陳述之元件。在組織中的過程將經由產生的工作產出所需之各種詳細活動 (activities)、任 務 (tasks)和實務 (practices)來達成其目的。這些執行任務、活動和實務及所產生的工作產出之特性，係證明是否能達成特定過程目的之指示符。 4.2 過程能力維度 演進中的過程能力係根據被分類成各能力等級的過程屬性 (process attributes)來表示。過程屬性為一個過程的特徵，它可依達成的尺度來評估，以提供該過程能力之量測 (measurement)，並且適用於所有的過程。每一個過程屬性係說明在達成其目的和有助
14、於組織營運目標上，在管理和改善過程有效性的整體能力。 能力等級係由一組屬性來區分其特性，該屬性彼此配合以提供履行過程的主要加強能力。每一個等級可提供在過程效能上主要加強的能力，而各等級係透過改善任何過程的能力以達成合理的進展方式。 參考模型分六個能力等級 (capability levels)： 第 0 級：不完全 (Incomplete) 未能達成過程目的。該過程僅有極少或欠缺容易證實的工作產出 (work product) 或輸出。 6 CNS 14785-2, X 6045-2 第 1 級：已履行 (Performed) 通常已經達成過程目的，但該成果可能未詳細規劃和追蹤。在組織裡的個人
15、所認知應該履行的行動，且在必要時具有執行該行動的一般協議。此過程具有可識別的工作產出，並能用來證明達成目的。 第 2 級：已管理 (Managed) 該過程經詳細計畫和追蹤並依規定過程交出工作產出，且其必須符合規定的標準和需求。它與已履行等級的主要區別是該過程效能現在可依定義的時程表和資源需求交出滿足所表示品質需求的工作產出。 第 3 級：已建立 (Established) 該過程係使用基於良好軟體工程原則的既定過程 (defined process)加以履行和管理。該過程的個別實作係使用經核准、修改版的標準、書面過程，以達成其過程結果。建置該過程定義所必需的資源亦將會在適當時候說明之。它與已
16、管理等級的主要區別是該已建置等級的過程係使用能夠達成其過程結果的既定過程。 第 4 級：可預測 (Predictable) 既定過程在實務上係一致地在所定義的控管限制內履行，以達成其既定的過程目標。收集和分析詳細的效能量測會導致對過程能力的量化瞭解，以及能預知和管理已改善的能力。效能係定量地接受管理，且工作產出的品質亦以定量來認知。它與已建立等級的主要區別是既定過程係一致地在所定義的限制內履行，以達成其既定過程的結果。 第 5 級：最佳化 (Optimizing) 促使該過程效能達到最佳化以符合目前和未來的營運要求，且該過程可達到重複性以符合其所定義的營運目標，並基於該組織的營運目標，建立可量
17、化地過程有效性 (effectiveness)及效率性 (efficiency)的效能目標。針對這些目標的持續過程監視係藉由獲得定量回饋而達到，且藉由結果的分析而達成改善。過程最佳化包括將引導創新理想和技術及變更非有效的過程，以符合所定義目標或目的。它與可預期等級的主要區別是既定和標準的過程現在可動態變更和調整，以有效地符合目前和未來的營運目標。 個別的參考模型因為其詳細度不夠，而無法用來作為執行過程能力之可靠度(reliability)和一致性 (consistency)評鑑的基礎。參考模型裡的過程目的和能力屬性的說明，尚需要廣泛的過程效能和能力指示符組的支援。這樣，方可達成過程能力的一致性
18、分級。結合該指示符組的模範模型提供於本系列標準第 5 部。本標準第 7 節訂定欲與參考模型相容的評鑑模型中之其他過程所應符合的需求。 5. 過程維度 (Process dimension) 本節提供一般各組織所執行相關於軟體發展、維護、採購、供應和運作的過程分類。該分類承認五種過程種類，而且每一種都包含了許多的過程。該過程種類和過程強烈符合 CNS_(ISO/IEC 12207)資訊技術軟體生命週期過程的定義 (本系列 7 CNS 14785-2, X 6045-2標準與 CNS_(ISO/IEC 12207)對應關係請參照附錄 A )，但也會另外介紹了某些不包含在 CNS_(ISO/IEC
19、12207)中的附加過程。 圖 1 提供過程維度結構的概述。它顯示 CNS_(ISO/IEC 12207)所定義生命週期過程的主要、支援和組織共三種主要群組，並且顯示每一個群組內的過程種類及各過程。圖 1 係以類似 CNS_(ISO/IEC 12207)的格式來設計，以使得能明顯表示兩模型間的相似性和差異。特別地，可看出在品質保證和品質管制相關的支援過程間的連結關係。 8 CNS 14785-2, X 6045-2 圖 1 過程維度內的各種過程 組織生命週期過程支援生命週期過程主要生命週期過程CUS.4 作業CUS.2 供應ENG.1 發展CUS.3需求析出作業使用客戶支援CUS.1 需用採購
20、準備供應商選取供應商監督客戶驗收系統需求分析及設計 軟體整合軟體需求分析 軟體測試軟體設計 系統整合軟體建構 及測試ENG.2 系統及軟體維護SUP.1 文件SUP.5 確認SUP.4 查證SUP.3 品質保證SUP.2 組態管理SUP.7 稽核SUP.6 聯合審查SUP.8 問題解決MAN.1 管理MAN.4 風險管理MAN.3 品質管理MAN.2 專案管理ORG.1 組織定位ORG.2 改善過程建立過程評鑑過程改善ORG.3 人力資源管理ORG.4 基礎建設ORG.5 量測ORG.6 再使用 9 CNS 14785-2, X 6045-2圖 1 所示的主要明顯差異係在此參考模型內存在有許多
21、的額外過程及過程定義的兩種階層定義。稍後將在本章作進一步說明其差異的細節，而該模型內的過程種類和過程之完整清單將提供於附錄 B。 三種生命週期過程群組為： 主要生命週期過程包含工程技術和客戶 -供應者的過程種類。 支援生命週期過程包含支援的過程種類。 組織生命週期過程包含管理和組織的過程種類。 五種過程種類為： CUS 客戶 -供應者 MAN 管理 ENG 工程技術 ORG 組織 SUP 支援 每一過程種類的說明包括了該過程所包含的特性描述，並緊接著一系列的過程名稱。 以下係根據六項元件來說明個別的過程： 過程識別符 該項目辨識過程種類及其在種類裡的序列編號。編號系統會區別出最高等級過程和第二
22、等級過程。識別編號包含兩個部分：過程種類縮寫 (例如： ENG 為工程技術過程類別 )和數字 (例如： CUS.1表示採購過程，且 CUS.1.2 表示供應者選擇的過程，其第二等級的過程係採購過程的一個組件過程 )。 過程名稱 說明性之片語縮寫以表示該過程的主要內容 (例如：供應者的選擇 )。 過程型式 共有五類過程。最高等級三類 (基本、擴充和新增 )以及第二等級兩類 (組件和擴充組件 )，分別說明如下： 1. 基本過程係與 CNS_(ISO/IEC 12207)內過程的含義相同。 2. 擴充過程係 CNS_(ISO/IEC 12207)過程的擴充。 3. 新增過程係超出 CNS_(ISO/
23、IEC 12207)的範圍。 4. 組件過程 (在 CNS_(ISO/IEC 12207)相同過程內的一個或多個的活動 )。 5. 擴充組件過程係在 CNS_(ISO/IEC 12207)相同過程內一個或多個的活動，並具有附加的資料。一般來說，這些均為擴充過程的組件過程。 過程目的 以高階方式來表示履行該過程總體目標過程目的之陳述段落。可選擇包含附加的段落以進一步定義該目的陳述。 過程結果 過程結果係成功實作過程後的可預見結果。每一過程的過程結果皆包含在一列表中，該清單出現在每一過程的說明之中，並緊接在作為成功實作過程的結果詞語之後。 過程備註 關於該過程以及它與其它過程之間關係之參考背考的選
24、項列表。 當擴充過程的定義或定義新的過程時，可能會使用的指引文件是列明在附錄 C 的 10 CNS 14785-2, X 6045-2 式樣指導中。 5.1 主要生命週期過程 主要生命週期過程包含兩種過程種類： CUS 客戶 -供應者 ENG 工程技術 5.1.1 客戶 -供應者過程類別 (CUS) 客戶 -供應者過程類別包含直接影響客戶、支援發展和轉移軟體至客戶的過程，並提供該過程用於軟體產品及 /或服務的正確運作和使用。 屬於客戶 -供應者過程類別的過程有： CUS.1 採購過程 CUS.1.1 採購準備過程 CUS.1.2 供應者選擇過程 CUS.1.3 供應者監視過程 CUS.1.4
25、客戶驗收過程 CUS.2 供應過程 CUS.3 需求引出過程 CUS.4 運作過程 CUS.4.1 運作使用過程 CUS.4.2 客戶支援過程 5.1.1.1 CUS.1 採購過程 基本過程 採購過程的目的是獲得可滿足客戶所表達需求的產品或服務。過程始於識別客戶需求且結束於客戶接受所需要的產品及 /或服務。作為成功實作過程的結果： 將定義採購需求、目標、驗收準則和採購策略。 將發展適當的合約以清楚表達客戶和供應者兩者的期望、職責和義務。 將生產滿足客戶所述需求的產品及 /或服務。 將適當監視採購，以符合規定條件諸如成本、時程和品質的要求。 將驗收供應者交付項。 5.1.1.2 CUS.1.1
26、採購準備過程 CUS.1 採購過程的組件過程 採購準備過程的目的係建立採購需求和目標。作為成功實作過程的結果： 將建立採購、發展或強化系統、軟體產品或軟體過程的觀念或需要。 將產生客戶所需的軟體及 /或系統。 11 CNS 14785-2, X 6045-2 將發展採購策略。 將定義驗收準則。 5.1.1.3 CUS.1.2 供應者選擇過程 CUS.1 採購過程的組件過程 供應者選擇過程的目的係選擇將負責實作 CUS.1.1 所定義之專案的組織。作為成功實作過程的結果： 將產生採購需求 (例如：要求建議方案 )。 基於評估供應者建議方案以選擇供應者。 在客戶和供應者之間建立並折衷合約。 5.1
27、.1.4 CUS.1.3 供應者監視過程 CUS.1 採購過程的組件過程 供應者監視過程的目的係在軟體產品或服務的發展期間監視的供應者的活動。成功實作該過程的結果為： 視需要執行在客戶和供應者之間的聯合活動。 將會定期與供應者交換技術進展上的資訊。 依協議的需求監視供應者的效能。 5.1.1.5 CUS.1.4 客戶驗收過程 CUS.1 採購過程的組件過程 客戶驗收過程的目的係當滿足所有的合格條件時，能核准供應者的交付。成功實作過程的結果為： 將基於採購策略並依照協議的驗收準則執行驗收。 將依協議的需求評估交付的軟體產品及 /或服務。 5.1.1.6 CUS.2 供應過程 基本過程 供應過程的
28、目的係提供符合協議需求的軟體給客戶。成功實作過程的結果為： 將會對客戶的要求產生回應。 將會在客戶和供應者之間建立合約，以發展、套裝、遞送和安裝軟體產品及 /或服務。 供應者將發展符合協議需求的軟體產品及 /或服務。 將軟體產品及 /或服務交付給客戶並遵照協議需求安裝。 5.1.1.7 CUS.3 需求引出過程 新增過程 需求引出過程的目的係在整個軟體產品或服務的生命期間中，收集、處理和追蹤目前進展中的客戶需求，以便建立需求標準以作為定義所需要軟體工作產出的基礎。作為成功實作過程的結果： 將建立與客戶的持續溝通。 將定義客戶需求的協議。 12 CNS 14785-2, X 6045-2 將建立
29、能結合新的客戶需求至已建立的需求基準的機制。 將建立能連續監視客戶需求的機制。 將建立確保客戶可容易地決定其需求狀態和處置的機制。 將強化技術變更及客戶需求的識別及管理其所造成衝擊的能力。 5.1.1.8 CUS.4 運作過程 擴充過程 運作過程的目的係在其欲使用的環境下運作軟體產品，並提供支援給該軟體產品的客戶。作為成功實作過程的結果： 將評估在其欲使用的環境下軟體的正確運作。 將在其欲使用的環境下運作該軟體。 將提供使用該軟體產品的客戶相關的協助和諮詢。 5.1.1.9 CUS.4.1 運作使用過程 CUS.4 運作過程的擴充組件過程 運作用途過程的目的係確保在欲使用期間和安裝環境下正確和
30、有效運作該軟體產品。作為成功實作過程的結果： 將識別和監視軟體入門和運作的運作風險。 軟體將依照需求條件在其欲使用的環境下運作。 將提供足以符合客戶需求之軟體能力的保證。 5.1.1.10 CUS.4.2 客戶支援過程 CUS.4 運作過程的擴充組件過程 客戶支援過程的目的係建立和維持可達到客戶可接受之服務水準，以支援該軟體產品的有效使用。依要求提供對客戶的協助和諮詢以支援軟體產品的運作。作為成功實作過程的結果： 將在不斷進展的基礎上識別和監視客戶支援服務的需要。 將在不斷進展的基礎上來評估所提供的支援服務和產品本身的客戶滿意度。 將藉由所提供的運作支援來解決運作問題和處理客戶的質詢和請求。
31、經由交付適當的服務將符合客戶需求。 5.1.2 工程技術過程類別 (ENG) 工程技術過程類別包含直接規定、實作或維護軟體產品的過程、其與系統的關係以及客戶文件。 在完全由軟體組成的系統環境下，工程技術過程僅處理此類軟體的建構和維護。 屬於工程技術過程類別的過程為： ENG.1 發展過程 ENG.1.1 系統需求分析與設計過程 ENG.1.2 軟體需求分析過程 13 CNS 14785-2, X 6045-2ENG.1.3 軟體設計過程 ENG.1.4 軟體建構過程 ENG.1.5 軟體整合過程 ENG.1.6 軟體測試過程 ENG.1.7 系統整合與測試過程 ENG.2 系統和軟體維護過程
32、5.1.2.1 ENG.1 發展過程 基本過程 發展過程的目的係將一組需求轉換成符合客戶所述需求的功能性軟體產品或以軟體為基礎的系統。作為成功實作過程的結果： 將發展軟體產品或以軟體為基礎的系統。 將發展可證明最後產出係基於需求條件的中間工作產出。 將在需求和設計之間建立一致性。 將提供適當證據 (例如，測試證據 )以證明最後產出符合需求。 完成產品將安裝在目標運作環境中，且能被客戶所接受。 備考：需求可由採購過程 (CUS.1)或需求引出過程 (CUS.3)的運作提供。 5.1.2.2 ENG.1.1 系統需求分析和設計過程 ENG.1 發展過程的組件過程 系統需求分析和設計過程的目的係建立
33、系統 (功能性和非功能性 )的需求，並架構、識別系統需求應分配至系統哪一個元件和哪一個版本中。作為成功實作過程的結果： 將發展符合客戶所述的系統需求。 將提議適當解決方案以識別系統的主要元件。 需求條件將分配至系統的每一主要元件。 將發展版本策略以定義實作系統需求的優先等級。 系統需求條件將被核准並可視需要進行更新。 將與所有的受影響單位溝通需求條件、建議解決方案以及其間的關係。 5.1.2.3 ENG.1.2 軟體需求分析過程 ENG.1 發展過程的組件過程 軟體需求分析過程的目的係建立該系統軟體元件的需求。作為成功實作過程的結果： 需求將分配至系統的軟體元件，且定義其介面以符合客戶所述需求
34、。 將發展經分析、改正和可測試的軟體需求。 將了解軟體需求對運作環境的影響。 將發展適當的軟體版本策略，以定義實作軟體需求的優先次序。 14 CNS 14785-2, X 6045-2 軟體需求將被核准並視需要進行更新。 將在系統需求及設計和軟體需求之間建立一致性。 將與所有受影響單位溝通軟體的需求。 5.1.2.4 ENG.1.3 軟體設計過程 ENG.1 發展過程的組件過程 軟體設計過程的目的係定義適當的軟體設計，以實現其需求條件並可依該需求來進行測試。作為成功實作過程的結果： 將發展架構性設計，以說明將實作軟體需求的主要軟體元件。 將定義每一軟體元件的內部和外部介面。 將發展細部的設計，
35、以說明可製作和測試的軟體單元。 將在軟體需求和軟體設計之間建立一致性。 5.1.2.5 ENG.1.4 軟體建構過程 ENG.1 發展過程的組件過程 軟體建構過程的目的係生產可執行的軟體單元，並查證其能適當地反應軟體的設計。作為成功實作過程的結果： 將依個別需求，定義所有的軟體單元的查證準則。 將生產由該設計所定義的軟體單元。 將在軟體設計和軟體元件之間建立一致性。 將完成查證軟體單元的軟體設計。 備考：此過程的部分內容類似過程中之查證過程 (SUP.4)。 5.1.2.6 ENG.1.5 軟體整合過程 ENG.1 發展過程的組件過程 軟體整合過程的目的係組合軟體單元及產生整合軟體項目，並查證
36、整合軟體單元能適當地反映軟體的設計。作為成功實作過程的結果： 將發展整合策略以使軟體單元符合版本策略。 將發展各軟體項目的查證準則，以確保能符合分配到該項目的軟體需求。 將生產整合策略所定義的軟體項目。 將使用既定的驗收準則來查證軟體項目。 將記錄整合測試的結果。 將在軟體需求和軟體項目之間建立一致性。 將發展迴歸策略 (regression strategy)，以重新查證軟體單元的軟體項目是否發生變更。 必要時將執行迴歸測試。 備考：此過程的部分內容類似過程中之查證過程 (SUP.4)。 5.1.2.7 ENG.1.6 軟體測試過程 ENG.1 發展過程的組件過程 軟體測試過程的目的係測試用
37、來生產產品的整合軟體會滿足軟體需 15 CNS 14785-2, X 6045-2求。作為成功實作過程的結果： 將使用既定的驗收準則來查證整合軟體。 將記錄測試結果。 將發展迴歸策略，以重新測試整合軟體是否應該執行軟體項目的變更。 必要時將執行迴歸測試。 5.1.2.8 ENG.1.7 系統整合和測試過程 ENG.1 發展過程的組件過程 系統整合和測試過程的目的係將軟體元件與其他元件整合 (諸如手動作業或硬體 )，以產生一個完整的系統，並滿足系統需求所述的客戶期望。分配至系統整合的資源應該包括熟悉該軟體元件的人員。成功實作過程的結果： 將發展能依照版本策略所建立系統單位集合的整合策略。 將發展
38、每一集合的驗收準則，以查證符合分配至該單元的系統需求。 將使用既定的驗收準則來查證系統集合。 將建置整合的系統以展示能符合系統的 (功能性、非功能性、運作和維護 )需求，並查證存在一組完整可使用的交付組件。 將記錄測試結果。 將發展迴歸策略，以重新測試集合或整合系統是否應該執行現存項目的變更。 必要時將執行迴歸測試。 備考：此過程部分內容類似過程中之查證過程 (SUP.4)和確認過程(SUP.5)。 5.1.2.9 ENG.2 系統和軟體維護過程 基本過程 系統和軟體維護過程的目的係管理系統元件 (諸如硬體、軟體、手動作業和網路 )的修改、變遷和作廢以回應客戶的要求。該要求的起因可能是發現問題
39、或改善需求或調適需要。其目的係修改或作廢已存在的系統及 /或軟體，同時能保持組織運作的完整性。作為成功實作過程的結果： 將發展能依照版本策略來管理系統元件的修改、變遷和作廢的維護策略。 將定義對現存系統在運作上的組織、作業和介面影響。 將更新規格、設計文件和測試策略。 將發展已修正的系統元件，並以相關的測試來證明無損於系統需求。 系統和軟體的更新將移設於客戶的環境中。 16 CNS 14785-2, X 6045-2 可根據客戶的要求，將以管制方式來作廢軟體和系統，以使客戶影響降至最低。 備考 1. 初始定義的需求可由需求引出過程 (CUS.3)提供。 2. 該過程與其他過程互相影響，諸如運作
40、過程 (CUS.4)、客戶支援過程 (CUS.4.2)和問題解決方案過程 (SUP.8)。 5.2 支援生命週期過程 支援生命週期過程包含一個過程種類： SUP 支援 5.2.1 支援過程類別 (SUP) 支援過程類別包含在軟體生命週期不同時間點所可能被任何另一過程 (包括其他的支援過程 )運用的過程。 屬於支援過程類別的過程為： SUP.1 文件製作過程 SUP.2 組態管理過程 SUP.3 品質保證過程 SUP.4 查證過程 SUP.5 確認過程 SUP.6 共同審查過程 SUP.7 稽核過程 SUP.8 問題解決過程 5.2.1.1 SUP.1 文件製作過程 擴充過程 文件製作過程的目的
41、係發展和維護紀錄過程或運作所產生資訊的文件。作為成功實作過程的結果： 將發展能識別在軟體產品生命週期間所應產生文件的策略。 將識別應用於發展文件的標準。 將識別由過程或專案所產生的所有文件。 將規定、審查和核可所有文件的內容和目的。 將遵照識別的準則來發展和出版所有的文件。 將遵照規定準則維護所有的文件。 備考：在調用該過程的例證中，該過程支援過程屬性 2.2 的效能。 5.2.1.2 SUP.2 組態管理過程 基本過程 組態管理過程的目的係建立和維護過程或專案所有工作產出的完整性。作為成功實作過程的結果： 將發展組態管理的策略。 將識別、定義和基準化該過程或專案應產生的所有項目。 將管制該項
42、目的修改和版本。 17 CNS 14785-2, X 6045-2 將記錄和報告該項目的狀態和修改要求。 將確保該項目的完全性和一致性。 將管制該項目的儲存、處置和交付。 備考：在調用該過程的例證中，該過程支援過程屬性 2.2 的效能。 5.2.1.3 SUP.3 品質保證過程 基本過程 品質保證過程的目的係提供過程或專案工作產出的保證，使過程能符合其特定需求且遵從其已建立的計畫。作為成功實作過程的結果： 將發展、實作和維護執行品質保證過程活動和任務的策略。 將產生和維護品質保證活動和任務的證據。 將識別與合約需求不符合或有問題的項目。 將客觀地查證軟體產品、過程和活動對於適用標準、程序和需求
43、的符合性。 備考 1. 為求公正，品質保證必須直接由發展軟體產品或執行過程的組織獨立和具備權威的人員負責。 2. 品質保證應為協調及利用其他支援過程的結果，諸如查證、確認、共同審查、稽核和問題解決方案。 3. 遵照 CNS 12681 來建置品質管理系統，將會建立具有品質保證能力的過程。 4. 在調用該過程的例證中，此過程支援過程屬性 2.1 和 2.2 的效能。 5.2.1.4 SUP.4 查證過程 基本過程 查證過程的目的係確認過程或專案的每一軟體工作產出及 /或服務能適當地反映特定的需求。作為成功實作過程的結果： 將發展和實作一查證策略。 將識別所有必要軟體工作產出的查證準則。 將履行必
44、要的查證活動。 將從軟體工作產出發現和移除可識別的瑕疵。 將使查證活動的結果適用於客戶和其他參與的組織。 備考 1. 在調用該過程的例證中，此過程支援過程屬性 2.1 和 2.2 的效能。 2. 該過程一般包括工作產出的測試效能，以確保其實踐其預期目的。 3. 該過程與軟體測試過程 (ENG.1.6)和系統整合和測試過程(ENG.1.7)的效能緊密相關。 4. CNS_(ISO/IEC 12207)含有查證計畫內容的特定需求。 5. CNS_(ISO/IEC 12207)含有查證活動的特定準則，它取決於查 18 CNS 14785-2, X 6045-2 證活動的目的。 6. 該過程可能包含技
45、術效能，包括同僚審查 (peer review)、正規證明和可追溯性分析。 5.2.1.5 SUP.5 確認過程 基本過程 確認過程的目的係確認實現該軟體工作產出之特定意欲使用的需求。作為成功實作過程的結果： 將發展和實作確認的策略。 將識別所有必要工作產出的確認準則。 將履行必要的確認活動。 將解決所有已識別出的問題。 將提供證據以證明軟體工作產出是經過適當發展，並適用於其預期目的。 將使確認活動的結果適用於客戶和其他參與的組織。 備考 1. 此過程與系統整合和測試過程 (ENG.1.7)的效能緊密相關。 2. 該過程一般包括工作產出的測試效能以確保實踐其預期目的。 5.2.1.6 SUP.
46、6 共同審查過程 基本過程 共同審查過程的目的係來維持與客戶對合約目的及該做之事項能有一共識，以協助並確保能發展滿足客戶的產品。共同審查係於整個專案生命期間針對專案管理和技術兩個層面來辦理。作為成功實作過程的結果： 將於預定時程內舉辦定期審查。 將經由在客戶、供應者和其他購買者 (或利益團體 )之間共同審查的活動，以評估過程的活動狀態和產品。 將審查結果應讓所有的受影響單位知悉。 將追蹤審查所產生的行動項目直至結案為止。 備考 1. 在調用該過程的例證中，此過程支援過程屬性 2.1 的效能。 2. 此過程最常調用於專案效能受到合約形式管制的環境。 3. CNS_(ISO/IEC 12207)包
47、含專案管理審查和技術審查所需的特定需求。 5.2.1.7 SUP.7 稽核過程 基本過程 稽核過程的目的係依照適當的需求、計畫和合約，獨立判斷所選擇產品和過程的符合性。成功實作該過程的結果為： 將發展和實作稽核的策略。 將依預定時程舉辦稽核。 19 CNS 14785-2, X 6045-2 將依照稽核策略判斷所選擇軟體工作產出及 /或服務或過程能符合需求、計畫和合約。 將安排適當的獨立單位執行稽核。 將識別在稽核期間發現的問題，連繫負責矯正措施的單位並解決。 備考 1. 在調用該過程的例證中，此過程支援過程屬性 2.1 的效能。 2. 此過程可由任兩單位來運用，其中一方 (稽核方 )稽核另一
48、方 (受稽核方 )的軟體產品或活動。 3. CNS_(ISO/IEC 12207)識別出應受稽核的特定軟體工作產出 (和活動結果 )。 5.2.1.8 SUP.8 問題解決過程 基本過程 問題解決過程的目的係確保所有發現的問題已被分析與解決，並認知該趨勢。作為成功實作過程的結果： 將識別問題解決活動，以確保分析和解決所有發現的問題。 在發現軟體產品或活動裡的 (包括不合格 )問題時將準備報告問題。 將提供認知和解決所識別之問題趨勢的機制。 備考：在調用該過程的例證中，該過程支援過程屬性 2.1 和 2.2 的效能。 5.3 組織生命週期過程 組織生命週期過程包含兩過程種類： MAN 管理 ORG 組織 5.3.1 管理過程類別 (MAN) 管理過程類別是由包含在軟體生命週期進行管理任何型式專案時任何人所可能使用的一般本質實務。 屬於管理過程類別過程為： MAN.1 管理過程 MAN.2 專案管理過程 MAN.3 品質管理 MAN.4 風險管理 5.3.1.1 MAN.1 管理過程 基本過程 管理過程的目的係組織、監視、和控制組織內任何過程或功能的起始和效能，以依照有效方式來達成其目標和該組織的營運目標。作為成功實作過程的結果：
