CNS 14837-2005 Information technology - Software life cycle processes《信息技术－软件生命周期过程》.pdf

《CNS 14837-2005 Information technology - Software life cycle processes《信息技术－软件生命周期过程》.pdf》由会员分享，可在线阅读，更多相关《CNS 14837-2005 Information technology - Software life cycle processes《信息技术－软件生命周期过程》.pdf（96页珍藏版）》请在麦多课文档分享上搜索。

1、 1 印行年月 94 年 10 月 本標準非經本局同意不得翻印 中華民國國家標準 CNS 總號 類號 ICS 35.080 X300914837經濟部標準檢驗局印行 公布日期 修訂公布日期 93 年 7 月 6 日 94 年 7 月 26 日 (共 96 頁 )資訊技術軟體生命週期過程 Information technology Software life cycle processes 1. 適用範圍 1.1 目的 本標準以定義明確之術語，建立軟體生命週期過程的共同框架，以供軟體業之參考。在獲取包含軟體的系統，獨立軟體產品及軟體服務期間，同時，在軟體產品之供應、發展、營運及維護期間，所要應

2、用到的過程 (process)，活 動 (activity)及工作 (task)均涵蓋於本標準所謂之軟體尚包括韌體中的軟體部分。 本標準亦提供一能用以定義、控制及改善軟體生命週期過程 (software life cycle process)之過程。 1.2 應用領域 本標準應用於組織內部或外部所履行之各項與軟體相關方面，包括：系統、軟體產品及軟體服務等之獲取，軟體產品之供給、發展 (development)、運作及維護，以及韌體中的軟體部分。此外，軟體產品與軟體服務需予提供系統定義的方面亦包括在本標準之應用範圍內。 備考：軟體生命週期所引用的過程需與系統生命週期所引用的過程相容。 本標準係為

3、 具有甲乙兩方 (two-party) 的情況而制訂，即使雙方均來自同一組織亦得應用之。其應用範圍可由非正式的協議 (informal agreement) 到具有法律約束力的合約 (contract)。本標準亦得應用於單一方的自發性 (self-imposed) 工作中。 本節並未排除現成 (off-the-shelf)軟體的供應者或發展者採用本標準。 本標準係為下列各類人員所制定：系統、軟體產品及軟體服務之獲取者，軟體產品之供應者、發展人員、營運人員、維護人員、管理人員、品保人員及軟體產品使用者。 1.3 本標準之裁適 (tailoring) 本標準包含一組可依軟體專案性質而裁適的過程、活

4、動與工作。所謂的裁適即為刪除不適用的過程、活動與工作。 備考：獨特或特殊過程、活動與工作之附帶事項或要求，得於合約中註明。 1.4 符合性 (conformance) 本標準之符合性之定義為：在軟體專案之裁適過程 (附錄 A)中，從本標準所選擇之所有過程、活動及工作的履行。當過程或活動之所有必要工作，已依據事先發展的準則，以及在合約中所規定適用之需求履行時，過程或活動的履行即屬完成。 任何運用本標準作為 貿易條件之組織 (如國立、業界協會、公司 )，應負責指定一組必要之過程、活動與工作的最低組合，並公布週知，此一組合即構成供應 2 CNS 14837, X 3009 1.4.1 對目的與結果的

5、符合性 附錄 F 提供了當所實作的過程，其目的是在達成與本標準所描述相同的目標，但得不實作本標準內文所 規定之條文細節的情況下，相當有用之符合性的特異形式。為了宣稱符合 性，對於組織所宣告之過程集合中的過程，應該要展示，過程的實作，導致附錄 F 中所提供之相關目的與結果的實現。任何一個組織應在考量附錄 F 所建議之過程集合，及其本身的環境參數，定義出組織適用的過程集。本標準的應用允許產生額外的結果。 備考：儘管在舊版標準中，第 1.4 節中所使用的遵循一詞，係與 ISO/IEC 指引 2 ，標準化與相關活動 通用詞彙 (ISO/IEC Guide 2, Standardization and

6、Related Activities General Vocaburary)一致，但就本節而言，使用符合較為適當。符合是由特定需求之產品、過程或服務來滿足。 1.5 限制 本標準雖然描述了軟體生命週期過程的架構，但並未定義實作 (implement)或履行 (perform)過程之活動及工作細節。 本標準之目的並非用來規定所要產生的文件的名稱、格式或明確的內容。然而它可能會要求要製作類別或型式類似的文件，如各種計畫書即為一例；但此並不意謂此等文件需分別的去製作或包裝，或以某種形式組合在一起。其取捨均由本標準的使用者決定之。 本標準並未規 定特定的生命週期模型 (life cycle model

7、)或軟體發展方法。使用本標準的雙方需負責為軟體專案選擇生命週期模型，並將本標準所訂之過程、活動及工作對應到此模型上。同時，雙方亦負有選定及應用軟體發展方法，並履行適用於該軟體專案的各項活動和工作之責。 本標準並無與組織現有政策、規範或程序抵觸之意。然而，任何需予解決的衝突，以及優先條件或情況，則需以文字列舉，以作為引用本標準的例外情形。 本標準中，應 (shall)字係用以表示約束雙方或多方的條款；將 (will)字則用以表示某一方意向 或意圖的宣告；宜 (should)字係用以表示在多種可能選項中的一項建議；而可 (may)字則用以指出本標準範圍內所容許的一項措施。 本標準中提列了許多工作清

8、單；這些清單無一能鉅細靡遺 除非是以應或將字所引介的節次，否則這些工作清單僅作為範例而已。 2. 規範性參考資料 下列標準包含組成本標準的各項規定，本標準付印發行時，下列標準的版本仍屬有效。然而，所有標準均不斷的改版，使用本標準簽定協議的雙方應儘可能運用下列標準的最新版。 IEC 及 ISO 成員會保持國際標準最新有效版本的登錄工作。 備考：附錄 A 及 F 構成本標準不可分割的一部分。 附錄 B、 C、 D、 E、 G 及 H 僅屬參考性。 ISO/AFNOR: 1989, Dictionary of computer science 3 CNS 14837, X 3009 CNS 9359

9、資訊處理詞彙 (第 1 部：基本術語 ) ISO/IEC 2380-20:1990, Information technology Vocabulary Part 20: System Development. ISO/IEC 9126:1991, Information technology Software product evaluation Quality characteristics and guideline for their use. ISO/IEC 15504-2, Software EngineeringSoftware Process assessment Part 2

10、:Performing an assessment CNS 12889品質管理與品質保證詞彙 ( CNS 12680) CNS 12681品質管理系統要求 。 3. 用語釋義 為求達到本標準之目的，下列之定義與 CNS 12889、 CNS 9359 及 ISO/IEC 2382-20所提供之定義併用。 備考：在適當的情況下，可將產品解釋為系統的一部分。 3.1 獲取者 (Acquirer)：向供應者 (supplier)取得或採購一項系統、軟 體產品或軟體服務的組織。 備考：獲取者可能為下列之一：買主、顧客、擁有者、使用者及採購者。 3.2 獲取 (Acquisition)：取得系統、軟體產

11、品或軟體服務的過程。 3.3 協議 (Agreement )：定義履行工作關係之項目與條件。 3.4 稽核 (Audit)：由獲得授權之人員，目的在於提供軟體產品與過程之獨立評鑑評鑑需求之符合性。 3.5 基準版本 (Baseline)：無論其儲存媒體為何，在組態項目生命週期中，正式指定且凍結於某一特定時間的組態項目正式核定版本。 3.6 組態項目 (Configuration item)：一組態中之個體 ，其能滿足最終使用功能，且能在某參考點 (reference point)被唯一地識別。 3.7 合約 (Contract)：為兩造間具約束力的協議，特別是在法律上具有強制性的協議；或純粹為

12、組織裡類似性質的內部協議，其目的在提供軟體服務、或軟體產品的供應、發展、產製、營運 (operation)或維護。 3.8 發展者 (Developer)：在軟體生命週期過程期間，履行軟體發展工作的組織 (包括需求分析、設計、測試到驗收 )。 3.9 評估 (Evaluation)：有系統的評量一個體合乎其規定準則的程度。 3.10 韌體 (Firmware)：硬體設備與電腦指令或電腦資料的結合體，這些電腦指令或電腦資料係以唯讀軟體的方式常駐於 硬體設備上。此軟體無法在程式的控制下輕易地被修改。 3.11 生命週期模型 (Life cycle model)：一個含有軟體產品發 展、運作及維護之

13、過程、活動與工作的架構；此系統的生命由需求定義延伸到其終止使用為止。 3.12 維護者 (Maintainer)：履行維護活動之組織。 3.13 監視 (Monitoring)：獲取者或第三者 (third party)對供應者之活動狀態及其成果所做之檢試 (examination)。 3.14 非交付項目 (Non-deliverable item)：雖於合約中未要求交付，但在軟體產品的 4 CNS 14837, X 3009 發展過程中可能被運用到的硬體或軟體產品。 3.15 現成產品 (Off-the-shelf product)：已發展完成，且可採“現狀 ” (as-is)或經過修改的

14、方式使用之產品。 3.16 營運者 (Operator)：營運系統的組織。 3.17 過程 (Process)：將輸入轉換成輸出的一組相互關連的活動。 備考：活動 (activities)一詞的意義包含資源的使用。 3.18 資格 (Qualification)：展現一個實體能否達成特定要求的過程。 (參閱 CNS 12889 第 2.13 節 ) 3.19 資格需求 (Qualification requirement)：為證明軟體產品遵守其規格，並已完成於目標環境中使用之準備，所需符合的一組準則或條件。 3.20 資格測試 (Qualification testing) (CNS 1288

15、9 第 3.5 節 )：在適當時機，由發展者履行，獲取者見證的測試，以展示軟 體產品符合其規格，並已完成於目標環境中使用之準備。 3.21 品質保證 (Quality assurance)：在品質系統 (quality system)中履行之所有規劃與系統化之活動，並依需要展示，以提供一個體將滿足品質需求的充分信心。 備考 1. 品質保證有內部及外部兩種目的： (a) 內部品質保證 (Internal quality assurance)：在組織內部，品質保證給予管理者信心。 (b) 外部品質保證 (External quality assurance)：在合約情況下，品質保證給予顧客或其他人

16、員信心。 2. 某些品質管制與品質保證措施是相互關連的。 3. 除非品質的要求充分反映使用者 的需要，否則品質保證可能無法提供足夠的信心。 3.22 發行版 (Release)：為特定目的而製作之組態項目的特別版本 (如測試版 (test release)。 3.23 招標書 (Request for proposal)：獲取者用以告知可能的競標者其獲取某特定系統、軟體產品或軟體服務之意圖的一種文件。 3.24 汰除 (Retirement)：營運及維護組織對現行支援的撤除、以新系統局部或全部汰換、或系統昇級版之安裝。 3.25 資訊安全 (Security)：對資訊或資料的保護，使未經授權的

17、人員或系統或無法閱讀或更改，而獲授權的人員或系統不被拒絕存取。 3.26 軟體產品 (Software product)：一組電腦程式、程序、及其可能相關的文 件與資料。 3.27 軟體服務 (Software service)：與軟體產品相關的活動、工作或責任之履行，如軟體產品的發展、維護及營運。 3.28 軟體單元 (Software unit)：可以個別編譯的程式碼。 3.29 工作說明 (Statement of work)：為一份文件，獲取者所使用的文件，作為描述與規定合約中待履行工作之憑藉。 3.30 供應者 (Supplier)：與獲取者簽訂合約，依據合約條款供應系統、軟體產品或

18、 5 CNS 14837, X 3009 軟體服務的組織。 備考 1. 供應者的同義詞為合約商、生產者、銷貨員、賣主或廠商。 2. 獲取者可指定其組織之一部分為供應者。 3.31 系統 (System)：由一個以上之過程、硬體、軟體、設施與人員所構成，能提供滿足所述需求的或目標之能力的綜合體。 3.32 測試涵蓋率 (Test coverage)：測試個案所測試之系統或軟體產品的範圍。 3.33 可測試性 (Testability)：設計客觀及可行測試的範圍，用以決定是否滿足某項需求。 3.34 使用者 (User)：運用營運之系統，以履行特定功能的個人或組織。 備考：使用者得扮演其他角色，如

19、獲取者、發展者、或維護者。 3.35 確認 (Validation) (CNS 12889 第 2.18 節 )：由檢查與提出客觀證據，以證實某一特定預期用途之特別要求已被達成。 備考 1. 在設計與發展階段，確認乃是關注檢查某一產品的 過程，以決定是否符合使用者的需求。 2. 確認通常是在規定的活動條件下 ，對最終產品實施。但在較早階段可能也有必要。 3. 已確認 (validated)一詞，是用來指明相符合狀態。 4. 若有多項不同預期用途，可作多重確認。 3.36 查證 (Verification) (CNS 12889 第 2.17 節 )：由檢查與提出客觀證據，以證實規定之要求已被達

20、成。 備考 1.在設計與發展階段，查證乃是關注該 工作的結果之檢查過程，以決定該活動明訂之要求是否符合。 2. 已查證 (verified)一詞，用以指明相符合狀態。 3.37 版本 (Version)：一個項目中經識別之實例。 備考：對軟體產品的版本修改而產生新版本，需進行組態管理。 3.38 過程目的 (Process purpose)：履行過程的高階目標，以及過程有效實作的可能結果。過程的實作宜能對利害關係人 (stake holders)提供實質的利益。 3.39 過程結果 (Process outcome)：過程目的成功達成時可察覺的結果。 備考：結果聲明 (Outcome stat

21、ement)可以描述下列事項之一： 人工製品 (artifact)的產出。 狀態發生顯著的改變。 滿足指定的限制，例如：需求及目標等。 備考：主要過程結果清單乃是參考模型的每一項過程的一部分。 4. 本標準之應用 本節呈現可用於獲取、供應、發展、營運、 及維護軟體產品之軟體生命週期過程。其目的在提供本標準之使用者路徑圖，使之能導正方向並正確的應用本標準。 4.1 本標準之結構 4.1.1 生命週期過程 6 CNS 14837, X 3009 本標準把得於軟體生命週期間 實行之活動劃分成五項主要過程、八項支援性過程、及四項組織性過程。 各類生命週期過程均區分成一組活動，每一活動亦進一步分成一組工

22、作 (task)。小節以 a.b 編號者，表示為一項過程，a.b.c 表示為一項活動， a.b.c.d 表示為一項工作。這些生命週期過程將介紹如後，並描述於圖 1 中。 4.1.1.1 主要生命週期過程 主要生命週期過程 (第 5 節 )包括五項過程，這些過程在軟體生命週期間，適用於主要的契約方。而所謂主要的參與者 (primary party)乃發起或履行發展、營運或維護軟體產品者。這些主要參與者為軟體產品的獲取者、供應者、發展者、營運者及維護者。主要過程為： (1) 獲取過程 (Acquisition process)(第 5.1 節 )：定義獲取者的活動，此獲取者係指獲取一項系統、軟體產

23、品或軟體服務的組織。 (2) 供應過程 (Supply process)(第 5.2 節 )：定義供應者的活動，此供應者係指提供系統、軟體產品或軟體服務給獲取者的組織。 (3) 發展過程 (Development process) (第 5.3 節 )：定義發展者的活動，此發展者係指定義及發展軟體產品的組織。 (4) 營運過程 (Operation process) (第 5.4 節 )：定義營運者的活動，此營運者係指在電腦系統的作用環境中，營運 電腦系統，對電腦系統的使用者提供服務的組織。 (5) 維護過程 (Maintenance process)(第 5.5 節 )：定義維護者的活動，此

24、維護者係指提供軟體產品維護服務的組織 。亦即為保持軟體產品新穎及適於營運之修改的管理。本 項過程包括軟體產品的移植(migration)與汰除。 7 CNS 14837, X 3009 圖 1 本標準結構 4.1.1.2 支援性生命週期過程 支援性生命週期過程 (第 6 節 )由八項過程組成。支援性過程以明確的目標，做為另一過程不可分割的一部分，以支援該過程，並對軟體專案的成功與品質作出貢獻。支援性過程在必要時始由另一項過程引用與履行。各項支援性過程如下： (1) 文件活動過程 (第 6.1 節 )：定義用以記錄生命週期過程所產生之資訊的活動。 (2) 組態管理過程 (第 6.2 節 )：定義

25、組態管理活動。 (3) 品質保證過程 (第 6.3 節 )：定義各項活動，以期客觀地保證軟體產品及各項過程符合規定的需求，並遵循原 定的發展計畫。聯合審查、稽核、查證與確認得用以作為品質保證的手段。 (4) 查證過程 (第 6.4 節 )：為獲取者、供應者，或一獨立的契約方定義各項活動，以查證軟體產品及各項服務， 其查證的深度視軟體專案而定。 (5) 確認過程 (第 6.5 節 )：為獲取者、供應者，或一獨立的契約方定義各項活動，以確認軟體專案的軟體產品。 (6) 聯合審查過程 (第 6.6 節 )：定義各項活動，以評估某項活動的狀態及產品。本項過程得由任兩契約方所引用，於聯合 的公開討論中，

26、由其中一方 (審查方 )審查另一方 (被審查方 )。 (7) 稽核過程 (第 6.7 節 )：定義各項活動以確定是否符合需求、計畫及合約之規定。本項過 程得由合約中任何兩方引用，由其中一方 (稽5.2 供應5.主要生命週期過程 5.1 獲取 5.3發展5.4 營運5.5維護6.支援性生命週期過程 6.1 文件活動 6.2 組態管理 6.3 品質保證 6.4 查證 6.5 確認 6.6 聯合審查 6.7 稽核 6.8 問題解決 7 組織性生命週期過程 7.1 管理 7.3 改善 7.2 基礎建設 7.4 人力資源 8 CNS 14837, X 3009 核方 )稽核另一方 (被稽核方 )之軟體產

27、品及活動。 (8) 問題解決過程 (第 6.8 節 )：定義用以分析及排除問題 (包括不符合事項 (nonconformances)的過程，這類問 題係發生於發展、營運、維護或其他過程的履行期間。 4.1.1.3 組織性生命週期過程 組織性生命週期過程 (第 7 節 )包括四個過程。組織用之以建立、實作由相關生命週期過程與人員所構成的基礎結構，並對結構與過程做持續改善。這些過程的應用通常超越了特定專案與合約的範圍；然而，從這些專案與合約獲得的經驗教訓，將有助於組織的改善。組織的程序有： (1) 管理過程 (第 7.1 節 )。定義管理與生命週期過程履行有關的管理基本活動 (包括專案管理 )。

28、(2) 基礎建設過程 (第 7.2 節 )。定義建立生命週期過程基礎結構的基本活動。 (3) 改善過程 (第 7.3 節 )。定義組織 (亦即獲取者、供應者、發展者、營運者、維護者或其他 過程的管理者 )為建立、測定、控制與改善其生命週期過程，所履行的各項基本活動。 (4) 人力資源過程 (第 7.4 節 )。定義提供充分完訓人員的活動。 4.1.2 裁適過程 (Tailoring process)。附錄 A 屬於規範性的內容，定義行本標準裁適時，需履行的基本活動。附錄 B 含有裁適本標準之要求簡要指導，文中列示了下達裁適決策的關鍵因素。 4.1.3 過程和組織之間的關係 本標準包含了各類組織

29、，依據 其需要與目標，應用於軟體生命週期全程的各種過程。為了便於瞭解，在附錄 C 中，提示了生命週期過程與相關契約方之間的闗係。 4.2 附錄 F 與本標準本文間的關係 附錄 F 定義了較本標準本文所包含之細部需求更高之抽象層次的過程參考模型(Process Reference Model, PRM)。 PRM 可以應用於在正進行自我過程評鑑的組織當中，以判斷這些過程的能力。附錄 F 中所提供的目的與結果，是每項過程的績效目標聲明。此一目標聲明，讓過程有效性評鑑，以不同於單純符合評估的方式進行。例如：新的過程定義可以依據附錄 F 中的目的及結果聲明評估，而不是依據本標準本文所列細部條款評估。

30、備考 1. 過程參考模型一詞的用法，與 ISO/IEC 15504-2 規畫修訂版的意義相同。 2. PRM 的目的係用以發展使用 ISO/IEC 15504-2 做過程評鑑的評鑑模型。 3. 附錄 F 所描述的過程，包含了延伸、詳細解說，以及一些未在本標準前一版中，相對發展 其活動與工作的新過程。此將於本標準的全面性修訂版本中校正。於此同時，新增第 6.9 節、第 7.1.6 節及第 7.4 節到 9 CNS 14837, X 3009 第 7.7 節。附錄 F 中則提供了新增過程的活動與工作。 5. 主要生命週期過程 本節定義以下主要的生命週期過程： (1) 獲取過程。 (2) 供應過程。

31、 (3) 發展過程。 (4) 營運過程。 (5) 維護過程。 主要過程中的活動與工作為發起與履行該項過程之組織應負之責。此組織要確保過程有效運作。 5.1 獲取過程 獲取過程包括獲取者的活動與工作。此項過程以界定獲取系統、軟體產品或軟體服務之需要起始。繼之以：招標書的準備與發出、供應者之選定，獲取過程的管理，以迄系統、軟體產品或軟體服務之驗收。 有此需要之個別組織得稱之為所有者 。所有人得將任何或全 部獲取活動，以合約委託給代理者，該代理者將會依據獲取過程，循序進行這些活動。本小節中所謂之獲取者可為所有者或是代理者。 獲取者遵循本過程所列之管理過程 (第 7.1 節 )，於專案層級 (proj

32、ect level)管理獲取過程；依據第 7.2 節基礎建設過程建立此過程之基礎建設；依照附錄A 之裁適過程，對本過程進行裁適，以適應專案；遵循改善過程 (第 7.3 節 )與人力資源過程 (第 7.4 節 )，於組織層級 (organizational level)管理獲取過程。 活動清單：本過程包含下列活動： 啟始。 準備招標書。 合約書準備與更新。 供應者之監視。 驗收與結案。 5.1.1 啟始 本活動包含下列工作： 5.1.1.1 獲取者以描述系統、軟體產品或軟體服務之獲取、發展、或提昇的概念或需要，開始獲取過程。 5.1.1.2 獲取者將定義及分析系統之需求。系統需求宜包括事業組織、

33、使用者以及資訊安全與其它關鍵性等方面的需求，並同時考量相關的設計、測試、及遵循的標準和程序。 5.1.1.3 若獲取者雇請供應者來履行系統需求分析工作，則獲取者需核准需求分析之結果。 5.1.1.4 獲取者得自行實施軟體需求定義與分析之工作，或雇請供應者履行之。 5.1.1.5 宜使用發展過程 (第 5.3 節 )以履行第 5.1.1.2 節及第 5.1.1.4 節的工作。 10 CNS 14837, X 3009 獲取者可使用附錄 F 中所描述的需求誘導 (requirements elicitation)子過程，建立客戶需求。 5.1.1.6 獲取者需依據適切準則的分析 ，考量獲取選項，包

34、括每個選項的風險、成本及利益。這些選項包括： (1) 購買滿足需求的現成軟體產品。 (2) 由組織自行發展軟體產品，或取得軟體服務。 (3) 透過合約發展軟體產品，或取得軟體服務。 (4) 上述 (1), (2), (3)選項的組合。 (5) 提昇現存的軟體產品或服務。 5.1.1.7 當所獲取之軟體為現成套裝軟體產品時，獲取者需確認下列條件是否已滿足： (1) 能滿足對軟體產品的需求。 (2) 有現成的文件。 (3) 具財產權、使用權、所有權、保證書及授權書。 (4) 軟體產品之未來支援服務已列入規劃。 5.1.1.8 獲取者宜擬訂獲取計畫，以文件記載之，並履行之。此計畫宜包含下列各項： (

35、1) 系統之需求。 (2) 已規劃之系統運用方式。 (3) 將採用之合約型式。 (4) 參與獲取之各組織的職責。 (5) 將採用之支援概念。 (6) 考量之風險及風險管理之方法。 5.1.1.9 獲取者宜定義並以文件記載驗收的策略和條件 (準則 )。 5.1.2 擬訂招標書 邀標書 本活動包含下列工作： 5.1.2.1 獲取者宜將獲取需求以文件記載 (如：招標書 )，其內容依第 5.1.1.6 節所擇定之獲取選項而定。獲取文件依其所適，宜包含下列內容： (1) 系統需求。 (2) 範圍說明。 (3) 投標者指引。 (4) 軟體產品清單。 (5) 期程與條件。 (6) 轉包合約的控管。 (7)

36、技術性之限制 (如：目標環境 )。 5.1.2.2 獲取者宜決定本標準之那些過程、活動與工作，適用於該專案，並依需要加以裁適。尤其獲取者宜指明適用的支援過程 (第 6 節 )及履行這些過程的組織，包括其責任歸屬 (若有異於供應者 )，俾便供應者得於 11 CNS 14837, X 3009 其計畫書中，界定履行支援過程的方法。獲取者將依據合約來定義這些工作的範圍。 5.1.2.3 獲取文件中，亦需定義合約里程碑，在里程碑上，供應者的進度將接受審查與稽核，以做為獲取的監視工作項目 (參閱第 6.6 節及第 6.7 節 )。 5.1.2.4 獲取需求宜交付給獲選履行獲取活動的組織。 5.1.3 合

37、約書準備與修正 本活動包含下列工作： 5.1.3.1 獲取者宜發展供應商評選程序，包括計畫書的評估準則及符合計畫需求之程度的配分方式。 5.1.3.2 獲取者宜依據對供應者計畫書、能力及其他應考慮因素之評估結果，來選擇供應者。 5.1.3.3 獲取者得於合約送出前，與其他參與者，包括可能的供應商，共同依專案的需要，對本標準進行裁適。而，獲取者需對這項裁適作最後的決定。獲取者將在合約中納入或參用此裁適過的標準。 5.1.3.4 獲取者需與供應者商議合約之內容，並在合約中註明應交付之軟體產品或服務的獲取需求，包括成本、時程等。合約需備考明與可再利用之現成軟體產品有關之財產權、使用權、所有權、保證書

38、及授權書等事項。 5.1.3.5 一旦合約開始履行，獲取者需透過與供應者協商之方式，以控制合約內容之變更，並做為變更控制機制的一部分。對於合約之變更，應研究其對專案計畫、成本、效益、品質及時程所造成之影響。 備考：在應用本標準時，採用合約 (contract)或協議 (agreement)，由獲取者決定。 5.1.4 供應者之監視 本活動應包含下列工作： 5.1.4.1 獲取者需依照聯合審查過程 (第 6.6 節 )及稽核過程 (第 6.7 節 )來監視供應者之活動，如有必要，獲取者宜以查證過程 (第 6.4 節 )及確認過程 (第6.5 節 )來彌補監視之不足。 5.1.4.2 獲取者將與供

39、應者合作，即時提供所有需要的資訊，與解決所有待決項目。 5.1.5 驗收與結案 本活動應包含下列工作： 5.1.5.1 獲取者宜依照已定義的驗收策略與準則，來準備驗收過程。準備事項宜包含測試個案、測試資料、測試程序與測試環境。供應者參與程度，宜予事先定義。 5.1.5.2 獲取者需進行可交付的軟體產品或服務之驗收審查與驗收測試，並需於所有驗收條件均獲滿足時，自供應者處接收此軟體產品或服務。驗收程序宜符合第 5.1.1.9 節之規定。 12 CNS 14837, X 3009 5.1.5.3 驗收完成後，獲取者宜負起已交付軟體產品組態管理之責任 (參閱第6.2 節 )。 備考：獲取者得依照供應者

40、定義之指示來安裝軟體 產品或履行軟體服務。 5.2 供應過程 (supply process) 供應過程包含供應者的活動與工作。本項過程得啟始於決定製作計畫書以回應獲取者的招標書，或與獲取者簽訂合約以提供系統、軟體產品或軟體服務。其後續過程是為管理與確保專案進行所需的程序與資源決定；包括專案計畫的擬訂與計畫的履行，一直到系統、軟體產品或軟體服務交付至獲取者為止。 供應者於專案層級遵循列舉於本過程之第 7.1 節管理過程，管理供應過程；遵循第 7.2 節基礎建設過程建立基礎建設；依據附錄 A 裁適過程，對本過程進行裁適，以適應專案；同時於組織層級，依第 7.3 節改善過程與第 7.4 節人力資源

41、過程管理本項過程。 活動清單：本過程包含下列活動 (1) 啟始。 (2) 回應的準備。 (3) 合約簽訂。 (4) 規劃。 (5) 履行與控管。 (6) 審查與評估。 (7) 交付與結案。 5.2.1 啟始 本活動包含下列工作： 5.2.1.1 供應者應從組織政策與規章的觀點，對招標書中的需求進行審查。 5.2.1.2 供應者宜做成參加投標或接受合約的決定。 5.2.2 回應之準備 本活動包含下列工作： 5.2.2.1 供應者宜擬訂建議書以回應招標書 ，並納入對本標準的裁適建議。 5.2.3 合約簽訂 本活動包含下列工作： 5.2.3.1 供應者應和獲取組織商議，並簽訂合約，以提供軟體產品與服

42、務。 5.2.3.2 供應者得要求合約內容之修改，做為變更控制機制的一部分。 5.2.4 規劃 本活動包含下列工作： 5.2.4.1 供應者應進行獲取需求審查，以界定專案管理、專案保證、及確保可交付的軟體產品或服務品質之框架。 5.2.4.2 若在合約中未約定，供應者應定義或選擇一個適於專案的範圍、大小與複雜性的軟體生命週期模型。供應者應自本標準中選出過程、活動與工作，並將之對應到擇定的生命週期模型上。 13 CNS 14837, X 3009 5.2.4.3 供應者應發展計畫需求，以管理及保證專案，並確保可交付軟體產品或服務之品質。計畫需求宜包含資源需求及獲取者之參與。 5.2.4.4 一旦

43、確立規劃需求，供應者應就每選項的相關風險分析，來考量軟體產品發展或提供軟體服務的各種選項。這些選項包括： (1) 使用內部資源來發展軟體產品或提供軟體服務。 (2) 藉由轉包合約來發展軟體產品或提供軟體服務。 (3) 從內部或外部來源，獲得現成軟體產品。 (4) 上述 (1)、 (2)、及 (3)的組合。 5.2.4.5 供應者應依據規劃需求及在第 5.2.4.4 節擇定的選項，發展專案管理計畫，並以文件記載。計畫中應考量的項目，包括 (但不限於 )下列各項： (1) 專案組織的結構，以及每個組織的權責，包括外部組織。 (2) 用以發展、營運或維護的工程環境；包括 測試環境、程式館、裝備、設施

44、、標準、程序及工具等。 (3) 生命週期過程及活動的工作劃分結 構圖，包括將實現之軟體產品、軟體服務和非交付的項目，及其執行 之預算、人力運用、實體資源、軟體規模、和工作的時程。 (4) 軟體產品或服務之品質特性的管理，品質計畫得另行擬訂之。 (5) 軟體產品或服務的安全、資訊安全及其他 重要需求的管理，安全與資訊安全的計畫得另行擬訂之。 (6) 分包商的管理 (若有分包商 )；包括分包商的評選，以及分包商與獲取者間的關係。 (7) 品質保證 (參見第 6.3 節 )。 (8) 查證 (參見第 6.4 節 )與確認 (參見第 6.5 節 )；包括與查證及確認組織 (若有的話 )之溝通方法。 (

45、9) 獲取者的參與；亦即，採取聯合審查 (參見第 6.6 節 )、稽核 (參見第6.7 節 )非正式會議、回報、修改與變更等方式；實施、核可、驗收與進入供應者的設施等。 (10) 使用者的參與；透過需求、設定的演練、雛型展示與評估等。 (11) 風險管理；亦即專案範圍的管理，包括潛在的技術、成本及時程的風險。 (12) 資訊安全政策；即對不同專案組織層級 “僅知道 “與 “對資訊存取 “之規則。 (13) 依據規章、必要的認證、財產權、使用權、所有權、保證及授權書等所要求的審核。 (14) 發展時程、追蹤與報告之方法。 (15) 人員訓練 (參見第 7.4 節 )。 5.2.5 履行與控管 本

46、活動包含下列工作： 14 CNS 14837, X 3009 5.2.5.1 供應者宜履行並履行以活動第 5.2.4 節擬定之專案管理計畫。 5.2.5.2 供應者應： (1) 依據發展過程 (第 5.3 節 )發展軟體產品。 (2) 依據營運過程 (第 5.4 節 )營運軟體產品。 (3) 依據維護過程 (第 5.5 節 )維護軟體產品。 5.2.5.3 在整個生命週期中，供應者應監視並控制專案之軟體產品或服務的進度與品質，此為一個持續的、選代性的工作。此種工作應應用於： (1) 技術效能、成本和時程進展的監視，及專案狀態之報告。 (2) 問題的認定、記錄、分析與解決。 5.2.5.4 供應

47、者應依據獲取過程 (第 5.1 節 )管理並控制分包商。供應者應將所有合約需求轉知分包商，以確保交付至獲取者之軟體產品或服務依據主合約的需求進行發展或履行。 5.2.5.5 供應者應與合約及專案計畫中規定的獨立查證、確認或測試人員建立溝通管道。 5.2.5.6 供應者應與合約和專案計畫中規定的其他參與者建立溝通管道。 5.2.6 審查與評估 本活動包含下列工作： 5.2.6.1 供應者應與獲取組織協調合約審查活動、溝通管道，及溝通。 5.2.6.2 供應者應依合約和專案計畫所規定，支援或與獲取者共同履行非正式會議、驗收審查、驗收測試、聯合審查與稽核過程。聯合審查過程應依據第 6.6 節履行，稽

48、核過程應依據第 6.7 節履行。 5.2.6.3 供應者應分別依據第 6.4 節及第 6.5 節履行查證與確認，以展現軟體產品或服務及程序，能完全滿足各自的需求。 5.2.6.4 供應者應依合約所定，提供獲取者評估、審查、稽核、測試及問題解決的報告。 5.2.6.5 供應者應依合約及專案計畫所定，讓獲取者進入供應者及分包商之設施，俾對軟體產品或服務進行審查。 5.2.6.6 供應者應依據第 6.3 節來履行軟體品質保證活動。 5.2.7 交付與結案 本活動包含下列工作： 5.2.7.1 供應者應交付合約規定之軟體產品或服務。 5.2.7.2 供應者應依合約規定對獲取者提供協助，以對已交付的軟體

49、產品及服務提供支援。 5.3 發展過程 發展過程包括發展者的活動與工作。本項過程包括需求分析、設計、編碼、整合、測試與安裝以及與軟體產品驗收有關的活動。若合約中有規定，本過程亦得包括與系統有關的活動。發展者依據合約，履行或支援本過程中的活動。 發展者在專案層級上，遵循列舉於此過程之管理過程 (第 7.1 節 )管理發展過程； 15 CNS 14837, X 3009 依據第 7.2 節基礎建設過程，建立過程之下的基礎建設；依照附錄 A 之裁適過程，對本過程進行裁適，以適應專案；於組織層級，遵循改善過程 (第 7.3 節 )與人力資源過程 (第 7.4 節 )管理發展過程；當發展者同時也是軟體產品的供應者時，發展者應履行供應過程 (第 5.2 節 )。 活動清單：本過程包含下列活動： (1) 過程的實作。 (2) 系統需求分析。 (3) 系統架構設計。 (4) 軟體需求分析。 (5) 軟體架構設計。 (6) 軟體細部設計。 (7) 軟體編碼與測試。 (8) 軟體整合。 (9) 軟體資格測試。 (10) 系統整合。 (11)