1、 1 印行年月 94 年 10 月 本標準非經本局同意不得翻印 中華民國國家標準 CNS 總號 類號 ICS 35.080 X301114950經濟部標準檢驗局印行 公布日期 修訂公布日期 94 年 10 月 26 日 年月日 (共 47 頁 )資訊技術CNS14837 (軟體生命週期過程)之指導 Information technology Guide for CNS 14837 (Software Life Cycle Processes) 1. 適用範圍 1.1 目的 本標準之目的在提供 CNS 14837 應用上的指引。 本標準在闡述應用 CNS 14837 時宜考量的因素，並於 CN
2、S 14837 可以在各種方式應用的背景環境中做此考量。本標準並無提供 CNS 14837 需求之原理的意圖。在本標準中提供了三種基本的生命週期模型的討論，以及裁適的範例。 1.2 閱讀者 本標準是為那些將把 CNS 14837，不考慮專案的規模及複雜度，使用或應用在合約狀況下、在組織作為自我評估的方式、或在軟體過程改善提 案的人而撰寫的。 本標準在探討如何視軟體的各種型式使用 CNS 14837，並指出與每一個案相關的過程。 本標準在 CNS 14837 被當成需求件使用，可以對之提供支援，亦可當作指導的樣板來使用 (例如：自發性地把 CNS 14837 當作過程改善演練的一部分 )。雖然對
3、整份標準宜予透徹理解，亦可依特殊情況，參照特定節次。 1.3 前提 使用本標準的前提為： (1) CNS 14837 可以隨時取得運用； (2) CNS 14837； (3) 悉相關的組織政策； (4) 具備軟體管理、軟體工程與軟體生命週期模型的通識。 2. 引用標準 本標準引用到下列標準： CNS 14837 資訊技術 軟體生命週期過程。 ISO/IEC 9126:1991, Information technology Software product evaluation Quality characteristics and guidelines for their use. 2 CN
4、S 14950, X 3011 過程 活動 圖 1繪圖記號ISO/IEC TR 15504 (all parts), Information technology Software process assessment. 3. 記法 描述 CNS 14837 過程與活動的圖示，依循如圖 1 所示， CNS 14837 中所使用的風格。 圖 1 製圖記法 4. CNS 14837 背後的基本概念 4.1 工程學科 與傳統的工程門派相較之下，軟體工程的應用與實務是個相當年輕的學科。結果，通常伴隨傳統工程專案的管制，在軟體上，總是無法達成。 CNS 14837 的基礎哲學乃是，諸如軟體發展及維護的層
5、面，宜以工程學科的展現方式進行。順著這個方式，可以讓與系統工程環境，亦即包括軟體、硬體、人員及業務實務的環境，有明確鏈結的框架得以建立。 4.2 軟體生命週期架構 CNS 14837 建立了一個軟體從概念到汰除之生命週期的頂層架構。該架構是以一組過程及這些過程間之相互關係所構建的。這些過程是立於兩個主要原則之上：模組化與職責。 4.2.1 模組化 CNS 14837 中的過程是模組化的，在其中它們： (1) 內聚強。過程的各個部分均極為相關； (2) 耦合低。過程間的介面數保持在最少的狀況下。 原則上，每個過程是為生命週 期中的某個獨特功能所設計，並可因專門的利用到其他的過程為專門功能 。以下
6、所列，乃是過程識別、範圍界定、以及結構化的規則： (1) 過程必須是模組化的，亦即，該過程在生命週期中宜執行一項，且僅執行一項功能，同時，任何兩個過程間的介面宜最少。 (2) 每個過程在架構中會被調用。 (3) 若過程甲被過程乙，且僅被過程乙所調用，則甲屬於乙。 (4) 若某功能被一個以上的過程所調用，則功能本身變成一個過程。 過程 活動 3 CNS 14950, X 3011 (5) 過程必須可以在生命週期模型中查證任何功能； (6) 每個過程宜有充分定義而可執行的內部結構。 4.2.2 責任 在 CNS 14837 中，組織及合約的其中一方兩詞幾乎為同義。組織乃是為某特定目的而組織起來 的
7、一群人，且可為各種形式的公司、機構、學會、工會或會所。組織的規 模可從一個人至許多人。當一個組織，全部或部分，參與合約時，它就是 合約的其中一方。雖然組織是個別的個體，但是合約的一方可來自相同的組織或不同的組織。 CNS 14837 中的每個過程，可以視為合約一方的責任。一個組織可以執行一個以上的過程。一個過程可 由一個或一個以上的組織來執行，被識別為負有責任之合約一方的組織之 一。執行過程的合約一方，即使可以用不同的人去執行個別的工作，它對整個過程仍負有責任。 生命週期架構的責任特徵，可促進 CNS 14837 對有許多以法定參與之人員的專案的裁適與應用。 4.3 過程的本質 這些過程被分組
8、為三類： - 主要的； - 支援的； - 組織的。 4.3.1 主要的過程 主要的過程有： - 獲取； - 供應； - 發展； - 營運； - 維護。 在實務上，獲取過程引發軟體生命週期的啟始。供應過程依履行發展過程、營運過程及 /或維護過程而回應。 4.3.2 支援的過程 支援的過程有： - 文件化； - 組態管理； - 品質保證； - 查證； - 確認； - 聯合審查； - 稽核； - 問題解決。 4 CNS 14950, X 3011 支援的過程可被另一個過程所利用，而達到以特定目的對前者的支援。 4.3.3 組織的過程 組織的過程有： - 管理； - 基礎建設； - 改善； - 訓練。
9、 組織可在組織中全面利用這些過程，以建立、實作及改善某生命週期過程。 4.3.4 過程精細化 每個過程以其自身所構成的活 動，進一步地定義，每項活動以其構成的工作，進一步定義。在過程中的 活動，是多個內聚力強的工作之集合，本標準中有： 表 1 過程分解 類別 過程 活動 工作 主要的 5 35 135 支援的 8 25 70 組織的 4 14 27 總計 17 74 232 工作是以需求 (requirements) 、自我宣告 (self-declaration) 、建議(recommendation)或許可的行動 (permissible action)等形式來表示的。就此目的， CNS
10、14837 謹慎地運用某些助動詞，以區別工作間的形式： - “應 (shall)”是用以表示合約雙方或多方之間的約束性條款； - “將 (will)”在表示合約單方之目的或意圖的宣告； - “宜 (should)”用以表示其他可能性之中的一項建議； - “可 (may)”用以指示在 CNS 14837 限制內許可的行動 。 4.4 過程與專案 CNS 14837 描述用於大型且 /或複雜軟體專案的過程集。然而， CNS 14837 被設計成可以為任何型式、較小規模及較不複雜的軟體專案所裁適。它亦被設計成可用在無論是獨立個體或整體系統之部分軟體上。 CNS 14837 中的過程、活動及工作，是以
11、它們最普通、自然的序位來排列的。此序位並非規定生命週期模型的順序。其用意是為了讓軟體專案要視應用狀況適度地選擇、排序、裁適及反覆進行過程、活動及工作。 在同一個專案上， CNS 14837 可以分別應用一次以上。例如，在指定的軟體發展專案中，獲取者可以要求供應者與獲取者共同履行軟體發展，而供應者履行CNS 14837 的一項應用。則供應者可要求其下 包商執行全部或部分的軟體發展。供應者 (現處於獲取狀態中 )與其分包商 (處於供應狀態中 )分別 (1)履行 CNS 5 CNS 14950, X 3011 14837 的應用。在這兩種情況下，需要裁適 CNS 14837 以反映出這樣的安排。 進
12、一步細節參閱第 6 節在專案上的應用。 4.5 過程與組織 組織 (或合約的一方 )以其目前履行的過程得其名，例如，組織在執行獲取過程的時候，被稱為獲取者。 CNS 14837 中的過程涵蓋範圍廣泛，以滿足各式各樣的組織。不論大小組織，均可依其營運目的， 挑選適當過程 (及其相關的活動與工作 )的子集以實現該目的。 CNS 14837 是以組織內部，或由兩個或多個組織以合約方式應用之目的而設計。為了使 CNS 14837 應用在組織內部或合約狀況，工作是以合約語言來陳述的。當應用在組織內部時，合約語言就會被解釋成如第 7 節於組織內應用所述的自發性工作。 CNS 14837 要與組織現有的政策
13、及標準相調和。通常，組織已經將其自有的現行標準及專門技巧運用於軟體發展上。因此，在組織中應用 CNS 14837 時，澄清 CNS 14837、組織自有標準、和已經在運用中的各種技巧間的關係，是重要的事。 圖 2 所示為此種關係的可能範例，有助於將 CNS 14837 應用在組織中。 CNS 14837 位於第一階，組織中的標準位於第二階，第三階則是專案專用的詳細發展活動、技巧及工具。在第二階及第三階所定義及使用的用語，必須符合 CNS 14837。 任何衝突留給應用 CNS 14837 的組織去解決， 可訂出對映關係，以填補間隙。 圖 2 與現行文件間的關係 4.6 軟體與系統 4.6.1
14、與系統工程的介面 CNS 14837 在系統的整體與軟體之間建立起一個堅強的連結。 這是可能的，因為 CNS 14837 是植基於一般系統工程為基礎。 CNS 14837 組織內部的標準 領域特有標準 技巧 第一階 第二階 第三階 未定義任何的輸入與輸出 工作是依照每個過程中的項目去完成的。工作是依照事先定義順序的程序去完成的。 程序依特定領域詳予定義。 程序中包括了解決問題的技巧。 提供支援各種技巧的工具。 6 CNS 14950, X 3011 在某種程度上， CNS 14837 是設計於系統工程過程內運作的。當軟體是整體系統的一部分時，軟體從系 統中被隔離、產製、然後整合回到系統中。CN
15、S 14837 的特徵，在缺乏系統層級的標準時，相當有幫助。當軟體是整個關注的重點時，系統層級的 工作可被當成有所助益的指引。無論在哪種狀況下， CNS 14837 對軟體工程在系統工程中的參與提供了深遠的意義。 4.6.2 軟體與系統間的關係 系統乃如圖 3 所示，是硬體、電腦、軟體、材料、人員及設施為特種目的的組合。在現實中，是必須履 行的系統。在母系統中，存在著諸如營運過程之類的過程。軟體在電腦中 ，提供這些過程之某些功能的執行服務。軟體可被存駐於電腦中、嵌入一 片韌體中、或被整合在一項硬體。不論是哪種狀況，軟體的獲取、供應、 發展、營運或維護，都需要與母系統協調與和諧。 圖 3 系統中
16、的軟體 硬體 軟體設施人工作業以電腦為基礎的過 程系統中的營運過程系統 電腦系統 7 CNS 14950, X 3011 如圖 4 所示，在組織中可能有許許多多的系統支持著營運過程。 圖 4 組織中的電腦系統 4.6.3 以軟體為基礎的系統 儘管 CNS 14837 定義了系統，但這個系統僅涵蓋著眼於軟體之系統的發展、營運及維護的生命週期過程。因此，在 CNS 14837 中，並無硬體生命週期過程的定義。 4.6.4 系統類型及軟體活動 在 CNS 14837 中發展過程區分了兩種型式的活動，即系統與軟體。這些活動的範圍，以其命名所反映。 圖 5 所示，這些活動以其型式劃分成兩組，並以 V 表
17、示法，說明系統與軟體活動之間的對稱與相互關係。 就如圖 5 中所示， CNS 14837 發展過程中的系統活動，以第 5.3.2 節系統需求分析為開端，並止於第 5.3.11 節系統資格測試。 本標準第 8 節會描述系統如何以硬體、軟體及人工作業組合起來。系統劃分成這些元件，是透過 CNS 14837 第 5.3.3 節系統架構設計活動所履行的結果。自此 架構設計所演進的軟體活動，依序始於第 5.3.4 節軟體需求分析，而止於第 5.3.9 節軟體資格測試。 活動活動活動活動業務過程活動活動活動活動業務過程活動活動活動活動業務過程事業 A 事業 B事業 C系統系統系統系統系統系統電腦系統組織營
18、運 營運營運 營運 營運營運 8 CNS 14950, X 3011 一旦軟體發展完成，硬體及人工作業就經由 CNS 14837 之第 5.3.10 節系統整合被整合起來，然後執行第 5.3.11 節系統資格測試。根據上述的活動，我們可以推導出，系統活動是軟體活動的母集。 圖 5 CNS 14837 活動分類 CNS 14837 與軟體相關的活動 4.7 管理與規劃 對於每項主要及支援的過程，在專案層級上的過程管理，是依循管理過程的考慮事項完成的。也就是透過管理的過程，使所有其他規劃性事件的規劃、執行與控制得以達成。宜納入規劃的項目被定義在 CNS 14837 的第 7.1.2.1 節中，而第
19、 7.1.3.2 節是為進度的報告做準備，第 7.1.3.3 節則在因應問題回報的需要。 4.7.1 專案管理計畫 在供應過程中， CNS 14837 的第 5.2.4.5 節要求要訂定專案管理計畫，並以第 5.2.5.1 節執行及管制此計畫。第 5.2.5.3 節中的供應過程，進一步以技術績效、成本及時程作為監視與管制的依據。 4.7.2 附屬計畫 CNS 14837 之第 5.2.4.5 節中所列的考量項目，包括與支援及組織過程類別相關的附屬過程。這些過程多 半會要求要訂定計畫，例如，品質保證、查證與訓練等。根據專案的規模 及複雜性，以及本項工作需要部分或全部外5.3.6軟體細部設計5.3
20、.7 軟體編碼與測試 5.3.2 系統需求分析 5.3.3 系統架構設計 5.3.4 軟體需求分析 5.3.5 軟體架構設計 5.3.8軟體整合 5.3.9 軟體資格測試 5.3.10系統整合5.3.11 系統資格測試 CNS 14837 系統相關活動 9 CNS 14950, X 3011 包的考量，這些計畫可以融入到專案管理計畫或個別發展成附屬文件。 在用到分包商時，這些分包商 宜透過納入了強調確保使規劃可以同步而建立適當介面的需要之考量的 CNS 14837 之第 5.2.5.4 節來管理。 附屬計畫集的彙總可取自表 B.2 及表 B.3。 4.7.3 文件管制 管理文件包括計畫之需求在
21、文件製作過程中描述。 4.8 品質管理原則的實作 CNS 14837 實作了品質管理原則，並以三種基本方法實施： 4.8.1 將品質整合到生命週期中 CNS 14837 為涵蓋軟體生命週期之廣泛、整合的過程集提供需求。它透過改善過程讓每個過程有機會進到 plan-do-check-act週期中。它視所有與品質相關的活動為軟體生命週 期不可分割的一部分，並將那些活動供給生命週期的相關過程使用。也就 是說，負責過程履行的每個過程及人員，都被指派了與活動有關的相關過程內部 (process-internal)品質。 4.8.2 品質保證過程 品質保證過程是為保證產品與 服務能遵循其被指定之需求與所建
22、立之計畫而設計的。負責本項過程的人 員要獲得必要的組織自由度與授權。組織自由度的意思乃是不受直接負責 產品產製之人員的約束，而授權則意指主導評估及提出矯正措施的權力。 4.8.3 改善過程 CNS 14837 中的改善過程，在進一步改善組織全面性的品質，亦即，無關乎合約義務。 4.9 對於演化中技術之彈性與回應 CNS 14837 對於演化中之軟體工程學科具備彈性與回應能力。它以提供頂層、開放式架構方式來達成，亦即， CNS 14837 是： (1) 可運用在： - 任何生命週期模型 (例如：瀑布式、漸增式或演化式 )； - 任何軟體工程 方法或技巧 (例如，物件導向設計、結構化編碼、由上而下
23、的測試或雛型法 )； - 任何程式設計語言 (例如： COBOL， Ada 或組合語言 )。 這些運用端視專案及科技的最新狀態而定，其選擇則是 CNS 14837 之使用者的工作。 (2) 從頂層的觀點可獲得彈性，亦即，軟體生命週期過程的 活動與工作是做何事 (what-to-do)項目，而非如何做 (how-to-do)項目。換句話說，某項工作可能是架構設計的發展及文件化 ，但不會是採用由上而下、功能設計方法之架構設計的發展及文件化 。此方案為獲取者在律定最終產品或服務上提供一條康莊大道，同時，讓 賣方具有創意，以及運用適當方法、技巧與工具，以生產產品或提供服務。 10 CNS 14950,
24、 X 3011 (3) 適用於任何當地的業界實務 (例如，軍用或商用 )、或者國家或組織的文化。 4.10 過程與文件化 CNS 14837 並不是文件化的標準，也就是說，就算 CNS 14837 要求過程的某些輸出要以文件記錄之，它也沒有指 定文件的格式或內容。它亦未規定類似性質之輸出的結合方式，例如計畫、規格、 或測試文件。文件化需求的細節，請參閱附錄 B。 4.11 軟體量度 CNS 14837 並未從特定量度和指標的角度去定義或規定軟體的屬性 (例如可靠性或可維護性 )。雖然它提供規定這些軟體屬性的方法，但是把細節留給了 CNS 14837 的使用者。 4.12 遵循 CNS 1483
25、7 可採下列方式遵循： (1) 組織公開宣告一組取自 CNS 14837 的過程、活動及工作為一項交易條件，供應者應遵循之。 (2) 軟體專案依據合約所訂準則，適當地裁適出 所要執行之過程、活動、以及工作。 備考： CNS 14837 容納了一組以應字形式陳述的需求。 CNS 14837 的使用者並未被強制要求對整個文件遵循，也就是說， CNS 14837 中沒有一個應字的陳述，是要求對整個標準遵循的。 此遵循要求將基於雙方的協議。協議的各方可以同意以 CNS 14837 的現狀作為協議的基礎，或者，他們可以同意對 CNS 14837 裁適，以適應他們特殊的需求。 4.13 結語 CNS 14
26、837 並非系統化、紀律化管理，以及軟體系統之工程的替代品。 CNS 14837 提供了一個讓軟體相關之過程、活動、以及工作，可以合理地識別、規劃、與採取行動的框架。 CNS 14837 容納了一組定義完善的積木 (building blocks)(過程 )。 CNS 14837 的使用者須挑選、裁適，並以適於組織與專案，及具有成本效益的方式將之組合起來。在裁適時， CNS 14837 的架構、意向及完整性宜予保留。例如，將元素納入，但標註以不適用 (Not applicable)加上免除理由之方式處理。 5. 實作 CNS 14837 5.1 綜觀 CNS 14837 得因下列理由而被實作：
27、 - 用於特定專案，定義必要的軟體過程、活動與工作； - 由某組織，當作其軟體過程改善的提案； - 作為較大型系統生命週期模型過程的一個組件。 無論實作 CNS 14837 的理由為何，我們建議的實作策略包括下列各項： (1) 規劃實作活動； (2) 裁適 CNS 14837； 11 CNS 14950, X 3011 (3) 執行先導專案； (4) 正規化該方法； (5) 制度化該方法。 本策略是個典型的方法，在組織或專案中導入變 革時，必須要予以遵循。上述的實作策略在額外的過程被敍明及或改善時，可能要在專案內或跨組織重覆數次。 當專案或組織正處於穩定的狀態下時，亦即， CNS 14837
28、的過程已經建立並且制度化時，實作策略的時間可以縮短，並可以納入下列各項： (1) 規劃實作活動； (2) 裁適 CNS 14837 (就工作的風險層級 ) (3) 執行專案。 5.2 規劃實作活動 實作 CNS 14837 宜就特定的專案來考量，並依此規劃。 以下所列，乃規劃此實作專案期間，要考慮之項目的例子： (1) 定義專案範圍。可能性包括： - 單一專案，可以是組織內部的，或是作為雙方所訂合約一部分； - 專注於某些關鍵過程，或甚至是單一的過程，並期望組織從其中獲得一些利益。此方案可以用在先前已發現的弱點，並且可以在未來某個時間點上，導引成 CNS 14837 的全面性實作； - 跨大範
29、圍的專案，以可能的分階段導入方式，採用 CNS 14837。在此刻，組織可能沒有或僅有少數已定義的過程，並將以 CNS 14837 做標準化。 - 跨各個專案，並在整個組織中，採用 CNS 14837。除了非常小的組織外，未必會有任何一個組織採用此方法。雖然對先前已將 CNS 14837 調適到工作實務的現有組織是新的附屬品，但那相關的。 (2) 識別專案目標，以及這些目標配適到組織全面性業務目 標的方法。如果在本專案與組織業務焦點之間未建立明顯的連結，若不能 維持長期的承諾，則專案目標實作的達成將會很困難； (3) 識別專案團隊 /組織的角色與職責，為每個過程指派單一負責人員。在許多情況下，
30、某個個人或組織可能會負責一個以上的過程， 這種情況特別是在小型專案或組織中最常見； (4) 識別 CNS 14837 實作時可以取用的資源，諸如時間、金錢、人員與設備； (5) 訂定並以文件記錄 CNS 14837 實作之專案管理計畫。 5.3 裁適 CNS 14837 當裁適的時刻來臨時，就會用到 CNS 14837 附錄 A 中所定義的裁適過程。對於CNS 14837 在特種應用上的裁適建議，收納在本標準的第 6 節在專案上的應用、第 7 節在組織中的應用及第 8 節以系統生命週期模型應用。 本標準中的裁適建議，在閱讀時，宜與 CNS 14837 附錄 B 中所列之通盤性裁適建議，用與該情
31、況相關的材料來做結合。例如，該等運用可能是在組織之內，同時，也可能涉及系統生命週期模型的各個層面。 12 CNS 14950, X 3011 本標準的圖 6 解析了在 CNS 14837 附錄 A 中已詳細討論之裁適過程之事件的順序。特種裁適的範例，已納在本標準的附錄 D。這些範例有： - 使用情境去定義專案環境； - 必要時，定義額外的活動與工作； - 總結裁適決策，並提出裁適的原理。 圖 6 裁適活動 5.3.1 識別專案環境及特性 組織特性可以就下列議題的思考而判別： - 既有的過程、政策及程序為何？ (認定已獲得成功的現有過程及實務是相 當的重要。這些事項需要融入到整套的必要過程之中。
32、 ) - 本過程是達成組織目標的基礎嗎？ - 其中是否涉及高度的業務風險？ - 問題區域在何處？ - 組織的文化為何？ (是早期的採用者或是反對變革 )？ - 支援需求為何？ 專案特性可以就下列議題的思考而判別： - 將使用到的系統或專案生命週期模型為何？ 開始結束識別專案環境及特性 徵求輸入項 挑選過程、活動與工作 記錄裁適決策與原理 13 CNS 14950, X 3011 - 特定過程的成熟度等級為何？ - 技術風險為何？ - 此為作業安全關鍵系統嗎？ - 要使用到新技術嗎？ 5.3.2 徵求輸入項 從相關業務及合約需要所導出的需求，是 CNS 14837 裁適上的主要驅動力。例如， C
33、NS 14837 可根據供應者與產品採購者之間的合約裁適。客戶可能只要求執行軟體的設計， 而非軟體系統的全面性發展。另一方面，如果客戶需求是作業安全關鍵軟體，而非消費性 軟體，那麼，挑選自 CNS 14837 的工作項數可能會有很大的差異。 受影響的合約各方宜參與裁適 的決策。這些人可以協助確保所得到的裁適後過程是可行、而且有用處的。如果可能的話，納入先前專案的回饋。 5.3.3 挑選過程、活動與工作 識別將被實作之 CNS 14837 中的過程或過程部分，並排定優先次序。通常最好是以能達成最大報酬的過程開始，而不要意圖一次就實作 CNS 14837的所有過程。 CNS 14837 並沒有定義
34、過程、活動及工作的順序，也沒有規定任何特別的軟體生命週期模型。將現行的過程、實務及 /或方法，與 CNS 14837 的過程、活動及工作對映，在本階段是非常有幫助的。 對映的工作可用以查證方法的 完整性，亦即，識別現狀與目標狀況間鴻溝之所在，亦即，選自 CNS 14837 之過程用於何處。 5.3.4 記錄裁適決策與原理 在應用 CNS 14837 時，對映到所選定之軟體生命週期模型的已定義過程、活動及工作，宜伴隨所研判的 關係及採用此方案的理由做成文件。因其提供了評估採用之方法成功與否的參考框架，故此項文 件宜被結合到實作CNS 14837 之專案管理計畫中。 在附錄 D 中提供了數個解說如
35、何記錄對映結果之方式的例子。 5.4 執行先導專案 在組織中跨數個專案導入 CNS 14837 時，在某些關鍵領域中及於某些關鍵過程上做先導運用，將有助於組織中受影響範圍的限定。 CNS 14837 的成功導入通常包括如下所列的方式： (1) 識別可運用選定之過程的先導專案。這些先導專案宜以 高優先次序的工作為選擇的基礎，如此將能產生重大的改善，並有高度的 成功機率，並且預期可以提供快速而明顯的成果； (2) 選擇一組自願者執行先導專案，然後將他們的努力投入公開， 並且給予獎勵。 (3) 訓練所有的參與人員。除了正規的訓練課程外，過程實 作期間定期的進度溝通，有助於意識的提升。 (4) 規劃先
36、導專案，並且識別關鍵成功因素； 14 CNS 14950, X 3011 (5) 對每個先導專案，將選定、經過裁適的過程融合到專案 管理計畫之中。適度地參照或納入本標準第 5.3.4 節中所描述的文件； (6) 執行先導專案，根據關鍵成功因素，追蹤及記錄效能。 記錄整個先導專案的經驗教訓，並將這些經驗教訓融合到修訂後的過程中。 5.5 正規化該方法 正規化涉及跨數個專案及 /或在組織中 導入新的過程。其議題諸如訓練、文件化、此過程所需之支援工具的提供，及新過程使用與接納的追蹤與監督。任何已經啟動並在進行中之專案、轉移至新過程的規劃宜予敍明。 備考： 改善可以在專案中，透過專案層級的監視來進行。
37、也可以透過與另一個專案做比較，以判斷哪些方法是成功的，哪些宜融合到未來的專案中來進行。 5.6 制度化該方法 制度化是專注在確保某個過程在整個專案或組織中，被一致化地、自動地運用的方法。此項活動亦需要量測過程的效能，並視需要再次實作過程的改善。這項作法可能需要調用 CNS 14837 第 7.3 節中所描述的改善過程。 6. 在專案上的應用 本節在提供將 CNS 14837 應用在專案上的額外指引。然而， 此指引並未全面涵蓋，因為每個專案所出現的狀況各有不同。 影響軟體獲取、發展、營運或維護方式的構面包括： - 組織政策與程序的變異； - 專案特有的獲取與供應策略； - 專案規模與複雜性； -
38、 系統需求。 CNS 14837 的撰寫目的就是在為各個專案考慮這類的變異。因此，在降低成本及改善品質的利益上， CNS 14837 可能需要因個別的專案而裁適。與專案有關的各個角色，均宜有機會參與裁適的活動。 6.1 在 CNS 14837 應用方面的因素 接下來的幾個小節，在檢驗把 CNS 14837 應用在專案上時，宜予考量的關鍵因素。這些因素並未全面涵蓋，所代表的是目前的想法，並且視軟體專案的情況，彼此會有互動及相互影響。在考量專案環境時，把這些因素做如下的分組，可能會有所幫助： - 組織性議題； - 專案風險； - 資源的能力 /成熟度。 6.1.1 系統生命週期模型 裁適的程度，以
39、及把 CNS 14837 當作一項需求或指導的運用，端視軟體專案在系統生命週期模型中的相對位置而定。 (典型生命週期模型的摘要，請參閱本標準的附錄 C)。 15 CNS 14950, X 3011 識別軟體所屬系統目前在生命週期所處的位置 (參閱本標準第 8.1 節 )。此 項決定可以協助： - 劃分軟體是屬於系統的一部分或是活動的單獨範圍； - 識別 CNS 14837 是否會被用作執行電腦塑模與模擬的方法； - 識別 CNS 14837 是否用於軟體的發展、營運或維護。 請參閱本標準之本章的後續相 關部分，並確保必要的介面已建立在系統生命週期模型內。 6.1.2 組織的政策與程序 識別參與
40、之組織，特別是獲取 者與供應者所屬，軟體專案需要遵循的相關政策與程序。其例子包括與下列事項相關的政策與程序： - 資訊安全； - 作業安全； - 隱私； - 風險管理； - 獨立查證與確認機構的使用； - 特定電腦程式設計語言的使用； - 硬體資源運用 (hardware resourcing)。 識別任何可能衝擊軟體專案的 相關法律及規定，包括與環境、公共安全及隱私有關的法令規章。這類的 外部資料可能需要持續性地監視，以確保系統能夠遵循。 上述的政策與程序在軟體發展、營運及維護期間，需要適當地考慮。例如，如果有作業安全及資訊安全的 政策，那麼發展過程的需求分析活動，以及營運過程的系統營運活動
41、，就需要融入這些政策。 6.1.3 系統特性 識別系統的次系統及組態項目 至適當的詳細程度。識別系統特性，特別是配置給軟體的特性。包括對系統營運有關鍵性影響之特性的識別。 宜予考慮之系統層級特性 (若配置在軟體中 )的例子包括： - 系統間與系統內部的介面； - 使用者介面； - 軟體錯誤對系統資訊安全與作業安全的衝擊； - 電腦精整 (sizing)與定時 (timing)的強制性要求； - 韌體的存在； - 適用電腦的可用性。 如果系統有許多次系統或組態 項目，則發展過程中的系統層級活動宜審慎地於每個次系統及組態項目上 履行。所有的介面及整合需求宜予考量。對於小型系統，可能不需要相同的嚴謹
42、度。 6.1.4 軟體特性 識別軟體層級的特性。例子包括： 16 CNS 14950, X 3011 - 軟體組態項目的可能數目； - 軟體的型式、規模及關鍵性； - 技術風險； - 文件的型式、程度及媒體； - 是新發展、修改、還是再利用的； - ISO/IEC 9126 所涵蓋的層面，例如可靠性。 如果軟體有許多的組態項目、 組件及單元，發展過程中的軟體層級活動，在每個軟體組態項目上宜審慎 地履行。所有的介面及整合需求宜予考量。對於小型的應用軟體可能不需要相同的嚴謹度。 決定管理控制，以及就關鍵性 系統與軟體特性考量，軟體可能需要的、和評估相關的活動的程度。 6.1.5 軟體維護策略 識別
43、與軟體維護有關的考量事項。典型的考量事項包括： - 預期的維護週期； - 隨時間的變更程度； - 應用上的關鍵性； - 由誰履行維護； - 訓練的程度； - 軟體維護所需的環境，包括測試。 所有的文件化需求宜予考量， 特別是當預期軟體的維護週期很長，或預期做重大變更時。適當的話，文 件化的環境可能需要被保存，以方便未來的檢索。 在維護週期全程讓文件以電子方式提供，是相當有幫助的。 6.1.6 專案的生命週期模型 為專案選擇一個或多個適當的生命週期模型。 (參閱本標準的附錄 C)判斷軟體生命週期模型是系統的生命 週期的一個子部分，或是完整的生命週期模型。 附錄 C 中的每個生命週期模型均含有某些
44、可以循序、重複、以及組合方式履行的過程及活動。 CNS 14837 之過程的活 動宜對映至所選定的生命週期模型。對於漸增式、演化式、劃分建構式及預先規劃式產品改善方法，一生命週期模型活動的輸出項會饋送至下一個活動。在這些情況下，相關的文件化宜在活動結束的時候完成，也就是說，在下一個活動開始前完成。 6.1.7 參與之合約各方的代表性 識別將參與專案的各方，以及 他們將負責之過程。所有與各方間介面相關的 CNS 14837 中的活動與工作宜予考量。 多人參與的大型專案需要顯著 的管理督導與控制。例如，組織內部的與獨立式的評估、審查、稽核、檢 視及報告產生，都是大型專案的重要工具。對於小型專案，這
45、些管制可能過當，應用時應小心謹慎。 17 CNS 14950, X 3011 6.1.8 軟體型式 決定相關軟體的型式，因為不 同型式的軟體需要不同型式的裁適決策。軟體型式的例子有： (1) 新發展的； (2) 現成的； (3) 韌體； (4) 獨立運作 (stand-alone)； (5) 非交付項目 (Non-deliverable)。 下列為對於主要軟體型式的一 些基本指引。要記住的重點是，不同型式的軟體會在一組活動的不同點上，進入發展過程。 (1) 新發展的 此型式軟體從發展過程的開端進入。在發展過程之下的所有的需求均宜予考量。 (2) 現成的 - 以完全的現狀 (as is)使用現成
46、軟體。此型式的軟體已經被設計、編碼及通過測試，但視例如關鍵性之類的因素， 以及使用的歷史，可能需要做更多的測試。由於全面性的發展過程 可能過當，因此它大約會在軟體資格測試時進入發展過程。與軟體相關的效能、文件、專屬權及未來的支援等均宜予評估。 - 不做任何修改地融入現成軟體，但需要例如應用參數之類的組態。所需設定之參數的例子諸如貨幣、日期格式、紙張大小等。此型式的軟體，依適當的判斷，在軟體單元測試或整合時，進入發展過程。全面性的發展過程可能過當。與軟體相關的效能、文件、專屬權及未來的支援等均宜予評估。 - 現成軟體的修改，例如，加入適用的報告格式，或當無文件可供使用時。視關鍵性及預期的未來變更
47、，發展過程宜經由維護過程來使用，並於軟體編碼與測試時進入發展過程。與軟體相關的效能、文件、專屬權及未來的支援等均宜予評估。 (3) 韌體 嵌於系統或屬於系統完整一部分的軟體或韌體。由於這型式的軟體為大型系統的一部分，因此，發展過程中與系統相關的活動宜予考量。在與系統相關的活動中，僅有使用動詞履行 (perform)或支援 (support)的工作需被選用。若軟體或韌體在未來不可能被修改，文件化需要的程度宜予審慎檢驗。 (4) 獨立運作 獨立運作的軟體。由於這種型式的軟體並非最後系 統的一部分，因此，並不需要發展過程中與系統相關的活動。文件化需求，特別是有關於維護的部分，宜予審慎檢驗。 18 C
48、NS 14950, X 3011 (5) 非交付項目 當沒有任何項目被獲取、供應、或發展時， CNS 14837 中除發展過程之第 5.3.1.5 節之外，無條款宜予考量。然而，如果獲取者決定要獲取一項這種型式的軟體，供未來營運與維護使用時，則此軟體宜視作上述 (2)至 (4)的項目處理。 6.1.9 專案規模 數十人或數百人參與的大型專 案相較於，例如說，三個人的專案，存在著更重大的管理問題。大型專案 ，或有多個分包商參與的專案，需要謹慎的管理督導與管制。某些專案是 以聯合審查、稽核、查證、確認及品質保證來達成此項目標。對於小型專 案來說，用上這些管制作為的全部可能會過當。 6.1.10 專
49、案關鍵性 愈依賴軟體正確營運及準時結束的系統，需要有愈高的能見度與管制。相反地，非關鍵性軟體的極端監督與管制，可能是不符成本效益的 (請參閱CNS 14837 的第 6.4.1.1 節有關關鍵性的說明 )。 6.1.11 技術風險 軟體的發展可能存在技術性風險。若使用的軟體技術並不成熟，發展中的軟體沒有前例，或者很複雜，或軟體含有作業安全、資訊安全、或其他關鍵性需求，則可能需要嚴格的規格、設計、測試與評估，而獨立的查證與確認可能就相形重要了。 7. 在組織中的應用 7.1 考量事項與技巧 組織通常會運用 CNS 14837 當作軟體相關過程改善工作的一部分。這可透過標準的使用或結合可用之過程評鑑與能力判斷方法，例如 CNS 14837 在組織中的應用，是基於專案所使用之相同的方法上。組織在使用 CNS 14837 時，要遵循本標準第 6 節所提出之議題的考量事項，以及第 5 節所描述的策略。
