1、 1 印月 95 2 月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.080 X301214974經濟部標準檢驗局印 公布日期 修訂公布日期 95 2 月 27 日 月日 (共 36 頁 )軟體工程CNS 14837 在專案管理上 之 應用指導Software engineering Guide for the application of CNS 14837 to project management 1. 適用範圍 本標準在提供 CNS 14837資訊技術軟體生命週期過程 在管過程域中的補充 (以下稱為軟體專案管或 SPM（ Software Project
2、 Management） 。因此，在本標準中，SPM 指的是一個人，而是一項過程 )。本標準是由下事項所發展出的 (閱圖 1)： - 將 CNS 14837 的管過程應用到 SPM。 - 使用專案管知主體指導專書 (A Guide to the Project Management Body of KnowledgeTM， PMBOKTM)11以定義及描述可應用在 SPM 的管知域。 - 使用 CNS 14485，品質管 -專案管品質指導綱要 5。 本標準在對負責管 CNS14837 軟體生命週期主要過程：獲取、供應、發展、營運及維護之執的人員提供指引。指引內陳述： - SPM 有關 CNS1
3、4837 第 7.1 節管活動對每一主要過程提供支援時的一般性指引。 - SPM 對於每一主要過程的可應用性。 - 可以跨 SPM 範圍的關鍵域。 - 軟體專案管 (PM)有關自下項目有關管工作的擴充指引： -11： 通盤性地別及描述被普遍接受的 PMBOKTM子集。被大眾所接受的意思是，所描述的知與實務，在大多 時間中可應用在大多的專案上，且其價值與可用性有遍普的共。 -5： 對一定要實作，且會對專案管實務造成影響之品質系統元素、概及實務提供指引。 本標準述及軟體特定或 CNS 14837 主要過程用在軟體專案常常引發問題之專案管構面。如，眾所週知軟體專案常常延遲及 /或超支預算，或者沒有辦
4、法符合獲取者的需求或期望。儘管這對於軟體是怪怪，但有項軟體特定 的屬性會引發這種問題。 圖 1 解析 CNS 14837、 11與 5在本標準發展上的關係。 1.1 閱者 本標準是為專案範圍、產品、方法、規模或複雜性，使用或計畫使用CNS 14837 於軟體專案之人員所撰寫的。本標準的撰寫，主要在輔助軟體專案經，能確保管過程符合 CNS 14837，特別是： - 負責 CNS 14837 軟體生命週期過程建及持續改善的經。 - 負責於專案層級執任何 CNS 14837 軟體生命週期過程的管者。 2 CNS 14974, X 3012 - 外包 SPM 工作投入的組織或個人。 提供考給下況之人員
5、： - 從事軟體專案工作，但未擔任軟體專案經。 - 目前是非軟體的專案經，但正轉換成軟體專案經中。 本標準在從軟體專案經觀點，呈現 CNS 14837 軟體生命週期過程，並提供有關將可由從業人員應用在管工作上之最佳實 務及建議事項的建議 (依據經驗、經驗教訓等 )。最後，本技術報告使得工程 、技術及其他支援人員，解其工作投入在完整軟體生命週期中整合的方式。 1.2 前提 使用本標準的前提為： - 擁有並熟悉 CNS 14837。 - 熟悉相關的組織政策與程序。 - 解害關係人及合約的需求 (需要與期望 )。 圖 1 使用 CNS 14837、 PMBOKTM指導及 CNS 14485，以創作本
6、標準 2. 符合性 本標準無符合性需求。 3. 引用標準 CNS 14837 資訊技術軟體生命週期過程。 4. 用語釋義 就本標準的目的，使用到 CNS 14837、 11及 5中的定義，並以其階層順序排。 5. 符號與縮寫 本標準所使用的符號及縮寫示如下 CCB* 組態 /變控制委員會（ Configuration/Change Control Board） ICWG* 介面控制工作組 IEC 國際電子技術協會 ISO 國際標準組織 PM 專案經 CNS14837軟體生命週期過程 CNS 14485-品質管 -專案管品質指導綱要 PMBOKTM指導 專案管知域 本標準 最佳實務、經驗教訓等
7、3 CNS 14974, X 3012 SEE 軟體工程環境 SPM 軟體專案管 WBS 工作拆解結構 註 *：根據專案的規模及複雜性，可以是一組人，單人或一項功能。 6. 指引 6.1 軟體專案管簡介 專案是暫時性的意圖，進以創造獨特的產品或服務 11。根據其詞意，專案與一群人、資源及事件有關，並具有下的共同特性： - 其主要目標是創造出產品、服務及結果。 - 專案的啟止時間已知，亦即，專案是暫時性的。 - 專案是多組織正常的持續性營運的一部分，也就是，專案具有獨特的需求。某些組織 (如，研究與發展 )其存在只是為執專案。 軟體專案是一種專案，以其產品、服務或結果為軟體強調。那麼，軟體與其他
8、專案產品、服務或結果有何同？就如 Watts Humphrey17所： - 軟體一般為複雜。 - 軟體的變可相對容進。 - 許多後期發現的硬體問題，採用軟體變處。 - 由於其複製成本低，軟體並無釋出以製造的自然。 - 軟體紀並非以自然科學為基礎，它在可性測試及設計塑模上缺乏現成的技巧。 - 軟體常是整合成完整系統的元素，如此增加複雜性，並對稍晚的變造成影響。 - 軟體的可通常最高，因此最會受到需求變的影響，並最會受到使用者的抱怨。 由於軟體與非軟體產品、服務與結果有所同，軟體專案的管也相同。這並是 SPM 全然同於非軟體專案的管。其關鍵事項乃是在 SPM 及一般專案管中有其特有域，管階層必須注
9、意，俾能達成專案目標，同時防範問題。 11提供與管專案有關的重要資訊。 CNS 14837 則提供第 5.2 節 (供應過程 )有關軟體專案的重要資訊，並描述將予執 之多個活動與工作。 5提供如何改善專案管之品質的方法。本標準的主要目的，在強調上述的差如何對軟體專案經造成衝擊，明這三份文件如何相互輔助，以協助專案經管軟體專案，能成功地完成。 軟體學科中快速的科技變革正超越管與過程技巧。這種情況因為專案管工具的範圍，以及軟體工程師所能使用的技術，相較於其他工程學科的夠完整，而是雪上加霜。 SPM 方法實作由許多因素所決 定，如，人員、組織及合約的需求、以及 4 CNS 14974, X 3012
10、 專案的複雜性。 軟體專案經要決定專案所採用的方法及技術，且宜被要求要： - 預問題的發生，以能防範問題的負面影響或將之減至最低。 - 及時及堅定地下達決心。 - 在問題發生時解決問題。 - 為專案的動、過程、資源、產品及結果負起責任。 在成為重覆進的意圖時，軟體專案經 在某個會影響到其他域的域中，著手某個動時，如，一項動、或無法反應，必須考慮任何系統化的衝擊。 6.2 管過程 本節在檢驗 CNS 14837 的 (第 7.1 節 )管過程。 CNS 14837 定義一項可由任何一方在管其過程時，所用之一般性的管過程 (而非 SPM)。本節在討CNS 14837 管過程在軟體專案之管 (SPM
11、)上的應用方式。 我們認知到已別的過程、活動及工作可能需要反覆動作，以達成專案的需求 /目標。如，根據所使用的軟體生命週期模型 ，過程、活動及工作可以同時使用；他們可以是相依的；或他們可與工 作拆解結構 (Work Breakdown Structure,WBS)相依性所組織起的序，在整個軟體專案生命週期中相互協調。 CNS 14837 7.1 管過程 。管過程包括一般的活動與工作，得為需管其相關過 程的任何當事人所運用。管者負責產品管、專案管及適用過程的工作管；如：獲取、供應、發展、營運、維護或支援性過程。 CNS 14837(第 7.1 節 )談及“適用過程的，因為專案可能會牽涉主要過程的
12、全部過程。如，某專案可能僅與產品的發展或維護有關，但涉及產品的營運。 SPM 宜定義 (及軟體專案經控制 )確保產品依合約指定交付所需之活動，亦即，確保軟體專案納入所有必要的工作，而且僅納入必要的工作，以成功地完成專案及產品。 6.2.1 啟始及範圍定義 CNS 14837 7.1.1 啟始與範圍界定 本活動包括下工作： 7.1.1.1 管過程應由建將著手之過程的需求開始。 7.1.1.2 在需求確定後，管者應透 過對執與管過程所需之資源 (人員、素、科技與環境 )的可用性、充分性與適性，以及完成時限的可達成性的檢驗，確定過程的可性。 7.1.1.3 必要時 (及透過所有與單位所達成的共 )，
13、過程的需求得於此時修改，以完成結案的規範。 啟始及範圍定義乃是過程可動的判斷，以確保人員、材、設施、軟體工 5 CNS 14974, X 3012 程環境 (Software Engineering Environment,SEE)及執與管專案所需要之技術，均可取用、充分及適當；以及預定完成時間是可達成、及時與經濟的。這包括軟體發展策 (如，專案可能是由現成 軟體、機構內發展之軟體、外包軟體，或是這些軟體的組合所構成的 )。 與範圍 (如，專案產品、產品特性、以及產品特性之測與評鑑方法的描述 )相關項目的目標在於： - 以文件記專案的由，標的 (goal)與目標 (objective)。 -
14、將害關係人之需求轉變為專案的交付項目，以及達成及安排專案所將實的活動。 - 確保人員的工作會脫範圍。 - 評估活動的結果，以促使結果符合範圍的需求。 在最佳情況的情境中，新軟體專案與組 織先前所管的專案有許多的相似處。如此可以提供組織有能成功執軟體專案的高保證。 啟始與範圍定義對於無前 (亦即，組織先前沒有執過 )的新專案可能是難以執的。對於無前的專案，宜予特別關照，以確保能夠適當地劃定範圍及受到監視。此一目標宜以經常性的審查及評估，審查最佳實務，以及得自有點相關的專案的經驗教訓，及尋求專家的建議等完成。 啟動與範圍定義的重點在建及以文件記載軟體專案的廣泛範圍及需求。此重點牽涉害關係人需求的別
15、與解，以及廣泛需求的評估與協商。在整個軟體專案生命週期內，對範圍與需求變的管宜予特別關照。範圍與需求的所有變，宜對成本、時程、風險及績效的衝擊謹慎地評估。所有的害關係人宜與軟體專案的需求定義。 對於品質特性 19的定義與文件記載宜特別關照；如，軟體將於何時嵌入較高階的系統，或者功能要在軟體與硬體間，或軟體與外部介接軟體或系統間做配置。 獲得害關係人在專案需求上之協議的責任宜予決定。協議乃是在軟體專案生命週期全程所使用之反覆過程的結果。風險、害關係人需求、環境、專案預算與時程上的變、以及持續演進的設計，使得有必要對協議及承，斷重新評鑑及再確認，以應要求對專案範圍做適當的變。 訂定結案準則是非常重
16、要的工作。其目的是在 11的支援下，判斷專案、活動或工作是否已經成功地完成。 常被軟體專案經所忽的業務需求乃是版權、專等的處。如，獲取者何時可以擁有發展中之產品？或是，如果供應者在最終產品交付前，無法繼續經營，獲取者會得到麼？ 軟體特定建議 - 軟體複製、分發、安裝及測試宜謹慎決定。 - 系統與軟體需求間、軟體需求與設計間、軟體需求與測試間的追溯性，宜建及維護。 6 CNS 14974, X 3012 - 介面宜當成軟體規格及介面明文件整體一部分般地予以定及控管。 - 由於軟體發展的複雜性，要證明軟體滿足使用者的全部需求 (需要與期許 )是件困難的工作。 - 工作的預估係根據專案型式而定：新發
17、展、嵌入或整合到系統中、現成軟體產品的修改、轉移至同的作業系統上等。 6.2.2 規劃 CNS 14837 7.1.2 規劃。 本活動包括下工作： 7.1.2.1 管者應備過程的計畫。與過程相關的計畫，應包括相關活動與工作的明，以及打算提供之軟體產品的別，這些計畫應包括，但限於，下各項： (1) 準時完工之時程表。 (2) 投入精之預估。 (3) 工作所需之充分資源。 (4) 工作分配。 (5) 責任分派； (6) 與工作或過程本身有關之風險的化。 (7) 過程全程將採用之品管手段。 (8) 與過程有關之成本。 (9) 環境與基礎建設之提供。 計畫準備及核准的職責宜予定義。 計畫宜別軟體生命週
18、期模型、工作、工作指派、承及資源。軟體專案宜有一主時程，所有的從屬時程宜予整合與主時程一致。 WBS 可以有效地測軟體專案的進，及提供對過程及產品的可。我們強建議運用 WBS 技巧，因為它能安排及定義 專案的整個範圍 11。 WBS 的建構宜可讓軟體專案能在與軟體專案規模、複雜性、關鍵性及風險相稱的適當精密程上受到管；對於將使用到之技術的熟悉是必要的。 規劃時使用到的專案估算宜包括： - 與過程相關的成本。 - 基礎建設。 - 對於資源的需要，包括相關的管與控制。 - 品質保證及控制。 - 風險管。 - SEE 的提供。 - 每個過程及 /或活動中將的工作。 軟體專案經宜儘可能嘗試使用組織現有
19、的基礎建設。現有的基礎建設並足以支持專案，則對現有基礎建設的調整或擴充宜明智地處。此項可能 7 CNS 14974, X 3012 需要採用外包的方式，以填補基礎建設的足。顧問可以協助在各種同的事情上達成協議。 規劃是項反覆進的活動，據此，軟體專案可以視需要隨著專案進，被評鑑、改善以及修訂。軟體 專案經 宜安排好過程，以促使在整個軟體專案生命週期中，重新規劃及估算事項的精算。每個軟體專案上都有許多的相依事項，就算是最初的 SPM 計畫，通常也需要次的規劃循環才能獲得。對於 SPM 計畫所需，但是卻是由其他計畫所提供的資訊， SPM 計畫可以照到其他的計畫上。 計畫宜予新，且至少要包含： - 角
20、色與職責。 - 將的活動與工作。 - WBS 中所別的專案交付項目。 - 結案準則。 - 結案報告。 - 成本與時程報告。 - 提案的方法以方針、產品或時基 (time-based)。 - 進報告的頻與方法。 - 問題或外事項報告。 - 資源需求與態。 由於支援性過程 (如，組態管、文件化、品質保證 )一般是專案的一部分，因此支援性過程的管者宜擬訂書面化的計畫。支援性過程計畫宜對 SPM 計畫校準並且支援它或者可為個別的計畫或納入 SPM 計畫之中。這些書面化的計畫宜由軟體專案經核准，並由專案變控制機制納管。 與支援性過程相關的活動報告宜直接或透過組織的管階層向軟體專案經提出。問題或外事項報告
21、宜就專案成本、時程、範圍及品質的衝擊分析，以引起軟體專案經的注意。在專案中宜建衝突解決或升高的機制，以組織管階層適當的權層級，可以解決軟體專案經與支援性過程的管階層間的歧。 在排定程碑之處，程碑的達成是依靠自支援性過程的多項報告及 /或產出，重要的是，這些成就是依據核准的計畫，以準確且及時的方式回報的。由於通常程碑在合約上是與支援性過程 (如，特定基準的達成 )的相結的，計畫的同步是非常要緊的，而軟體專案經要儘快注意到在完成指定工作時，支援性過程的任何困難經驗。 何時，在軟體專案經所直接掌控之組織支援性過程時，解下者間所存在之關係是很重要的： (1)軟體專案經及支援性過程管階層，以及 (2)被
22、支援及提供支援之組織的管階層。軟體專案經在考規劃、實作、控制，以及透過明確定義之技術與管階層報告、資訊及爭議解決的報告等層面時，宜有此認知。計畫的同步在外包協議與派工的情況下加困難，但可以用主計畫輔助。 8 CNS 14974, X 3012 史性的專案資是分析及解組織過程能及效、組織專案績效及經驗教訓的主要源。這些史性資形成全面性資庫，組織宜用以持續地改善組織的生命週期過程。相同的資庫宜支援個別軟體專案的管過程的。每個組織宜建正規的制，以蒐集、分析、摘要、歸檔及檢史性的專案資。 軟體特定建議 - 有效的組態管策對於軟體專案相當重要，故下的策可用以當作變控制過程的一部分，以控制變： - 宜建變
23、的門檻，讓任何軟體變成本估計的總和，低於某一個需要修改合約的指定額。 - 宜採用變的批次變分組 (batch-for-change grouping)，以做變的融合，以將對發展時程的衝擊至最小，並使穩定性最大化。 - 介面上的協議宜於專案承上達成，並在整個專案期間處模糊、準確、斷變之長期性問題，或是無法測試的需求與規格。 - 大多的成本模型是以軟體的估計的。其真正的問題在於的決定及對特定專案的模型調整上。要做好此一工作，宜考下事項： - 自先前專案所蒐集到的資。 - 運用專家去運作及解該模型。 - 未依專案的組織經驗做調整，則成本模型誤差可能會達到一倍以上。 - 無如何宜只靠一個成本模型去產生
24、最後的成本估算。 - 軟體系統是很難被看得的，如此，使得變的效果難預測及管。 - 軟體需要被包裝 (packaged)，以於有效及有效果的複製、分發、安裝、測試及營運。 - 軟體計畫宜緊密地與硬體結合且必須一起處，儘管事實是如此，他們還是分由同的組織。特別是，程碑必須被結起，並由硬體及軟體發展者間的全面性諮詢決定，以遏制某一域造成專案延遲的可能性。 - 軟體的計畫需與客戶之計畫緊密結合，主要是硬體及環境。 - 當採購軟體資源時，要判斷： - 維護與版本新是否是免費的。 - 擁有權，如，保固、智慧財產權、專及版權。 6.2.3 與控制 CNS 14837 7.1.3 與控制。 本活動包括下工作：
25、 7.1.3.1 管者應啟動計畫的施，以滿足預設之目標與規範之組合，並對過程進控管。 7.1.3.2 管者應監視過程的，並提出內部之過程進報告，以及依合約 9 CNS 14974, X 3012 規定，對外向獲取者提出報告。 7.1.3.3 管者對過程期間所發現的問題，應進調查、分析並解決。問題解決方案可能造成計畫的變。管者有責任確保任何變所造成的衝擊，均可被測定、控管與監視。問題及其解決方案應予記。 7.1.3.4 管者應於共同認定的時點上，提出過程進報告，明依照計畫的部分，以及對未趕上進的部分，提出解決方法。這些報告包括組織程序與合約所要求的對內與對外報告。 本活動一般是在軟體專案經授權基
26、的花費 (或額外的花費 )時開始。 軟體專案經宜負責本活動控制部分中有關工作投入的監視，以確保書面預劃績效的任何偏可迅速地別與分析，並採取適當的矯正措施，以讓過程回到受控制的態。軟體專案經宜使用本 活動的控制部分，採取矯正措施，以解決正在浮現中的問題，及採取預防措施，以過程的防範預期問題的發生。軟體測 (如， )、變控制過程、以及軟體產品與過程的評估與稽核，是專案監視與控制的工具。軟體測可用將完成的服務確認預期之軟體產品功能。 備考以介面控制工作組 (ICWG)為，它對於成功的、介面強制性要求的評估及軟體專案的控制都是可或缺的。 ICWG 宜由每個受到介面影響的組織派代表組成。 ICWG 提供
27、一討軟體與系統介面，探選項及達成實作介面最佳方式之協議的壇。 ICWG 所提需對專案變的建議，在實作之前，應送組態控制委員會 (CCB)核准。 軟體專案經宜負責滿足溝通的需求，包括視需要及時地向害關係人報告進、發布計畫及工作權責的修訂版本、報告及記偏事項。集中式、最新的資庫，對促進人與人間的交有所助益。 軟體專案經宜確保軟體專案於商訂的時限內完成，以滿足害關係人的需求。軟體專案經宜與害關係人一起決定軟體專案的首要目標。專案的終極目標可能會達到確保以最少時間及最低成本的選項，如，作業安全關係性系統需要密集的測試。 與風險相關的過程 (專案風險的管 )在應付專案全程規劃中的確定性，並且需要結構化的
28、方法。風險相關過程的目標是要將潛在之負面事件的衝擊減至最低，並善加用所有的改善機會。風險與專案過程或工具，或者產品對專案目標之遵循有關。 軟體特定建議 - 從時程失衡中回需予謹慎評鑑，且宜期望會對績效、成本或風險產生負面衝擊。 - 在已經延誤的軟體專案增加人手，可能會使之延誤多，這取決於新增人的能。 - 為減輕風險，實際演可以讓獲取者及顧客，在選定供應者前，親身經 10 CNS 14974, X 3012 軟體產品的能。 - 使用雛型製作法發展軟體部分的功能，以證實功能可以適地。 - 關鍵性系統的工程投入在缺乏充分的軟體工程專業下，宜進。 - 在與害關係人協同下，於專案全程中，定期審查軟體需求
29、基準，以確保遵循專案目標 (成本、時間及績效 )，或向專案目標修正。 - 專案的人員與團隊目宜與預算及時程建結關係，正常的控制約束宜過。 - 由於軟體難以看透，致使進的評估存在著許多的困難點。管者宜定義及改善研判進的技巧，以能早期偵知成本或時程超出估算。 - 由於軟體發展及維護活動通常依賴個人的技能及經驗，管者宜嘗試防範正在進中的工作項目作必要地人員換。 - 常常與害關係人溝通，對於讓績效、成本及時程發生出人意表結果的況減至最低是可或缺的。 6.2.4 審查與評估 CNS 14837 7.1.4 審查與評估。 本活動包括下工作： 7.1.4.1 管者應確保軟體產品與計畫的評估，係基於需求的滿足
30、而進。 7.1.4.2 管者應對過程期間完成的軟體產品、 活動與工作的評估結果，就目標的達成與計畫的完成進評估。 CNS 14837 的支援性過程 (如合審查與稽核過程 )可補充審查與評估活動。 軟體專案經宜負責確保軟體產品與計畫就下各項受到評估： - 評鑑軟體產品、活動及工作的審查結果。 - 遵循 SPM 的計畫、哲學、方法及技術。 - 以文件記載計畫及承。 - 滿足需求。 - 進至下一個過程、活動或工作的備妥。 軟體專案經宜與重要的審查活動。 SPM 計畫宜作為追蹤軟體專案過程與活動的基礎。事件驅動及時程驅動 (event- and schedule-driven)準則的組合，可用以管審查
31、活動。 半成品 (work-in-process)及尚待完成之工作 (work-to-be-completed)的定期審查與評估，是成功之軟體專案可或缺的元素。軟體專案經宜相對於將的服務，確認期望的軟體產品功能。軟體專案經宜挑選一組軟體測項，以提供對整個軟體生命週期進展之有意義察。過程宜以軟體工作產品規模、工作投入、成本、時程、完成的單元、或建構內容的實際測值，與記載於 SPM 計畫中的估算值做比較為主，判斷將完成的工作。軟體專案經宜主導軟體專案團隊的績效審查，且宜提供定期的進審查，以向害關係人提供專案的態。適當工具的使用，對審查及評估活動有極大的幫助。 11 CNS 14974, X 301
32、2 半成品的評估最好由熟悉專案需求、所涉技術、產品、需求及使用之過程及基礎建設的人員。管審查宜涵蓋支援軟體生命週期的專案活動。頂層審查宜以功能 /技術層次的審查為主，且宜用以形成完整的軟體專案評鑑。 時程績效的管審查，特別是軟體套裝的進，宜予結構化及，以做為實質的評鑑。軟體測的使用；實獲值分析 (earned value analysis)；以及從檢視 (inspections)、走覽 (walkthroughs)、以及合及同儕審查等的結果，乃是支援準確之專案評鑑之有意義的軟體套裝評鑑可或缺的事項。 以文件記載源自審查及評估的重大議題、待辦事項 (action items)及決策宜予要求。待辦
33、事項及重大議題宜予追蹤至結案為止，所別出的問題，宜予輸入專案矯正措施系統中。 軟體測與變控制是軟體專案之管與控制的 工具化(instrumental) 。軟體專案經宜制訂軟體測計畫，以作為風險別、化與評鑑的框架。軟體 PM 宜挑選適當的軟體風險測項，以在整個軟體生命週期中提供軟體專案風險的有意義的察。一般，審查與評估宜予以，以判斷技術及營運的風險域。 對於品質制元素、觀及常規的指引，對於專案管的實務很重要，也對專案管實務造成衝擊。專案包含有過程及過程中的動，通常會影響到其他的過程。專案過程間相依性的整體管乃是軟體專案經的責任。 軟體特定建議 - 測試開始前的任何時程動，對於交付日期沒有相應的動
34、，可能造成專案無法照計畫完成測試。 - 於軟體專案生命週期的初期訂定廣泛的測試計畫。 - 對於程式的註冊、儲存、新、備份及維護、測試資及測試環境要訂定嚴格的規則。 - 對修改部分的測試訂定迴歸策。 - 訂定整合計畫，以依據釋出策建構系統及軟體單元。 - 軟體及主系統容的實據宜予提供，以能顯示這些容足以符合客戶目前及規劃的需要。 - 發展過程使用的測試個案及結果，宜予保存，以能對維護過程提供協助。 6.2.5 結案 CNS 14837 7.1.5 結案 。本活動包括下工作： 7.1.5.1 當所有的軟體產品、活動與工作均完成時，管者應考合約所訂準則或組織之程序，以確定過程是否完整。 7.1.5.
35、2 管者應檢驗軟體產品、活動與工作所運用之產出與紀，以瞭解其完整性。這些產出與紀應依約歸檔至適當的環境中。 12 CNS 14974, X 3012 SPM 宜負責專案完成的評鑑， 以及負責確保專案需求、準則及程序已被滿足。此決定於軟體產品、過程、活動或工作已成功地完成時做成。軟體產品、過程、活動或工作的結果或紀宜就其完整性查核；而一旦被視為完成後，宜依照合約及 /或組織的需求予以歸檔。 結案活動宜使用下事項 (如 )的結果及相關的資與報告： - 軟體驗收測試、查證、確認及軟體測項。 - 軟體品質保證報告及營運性測試。 - 軟體故障報告。 - 稽核。 - 驗收及簽結。 - 害關係人評述 /回饋
36、。 結案後基準、文件及紀的維護，如，位置、媒體，以及資訊要保存多久等，宜儘早期考。 結案可於過程 、活動及工作間發生。就如 11(對於 CNS 14837，以階段一詞，代替過程、活動或工作所： 專案階段的結束通常對 重要交付項目及專案績效者的審查劃下點，以 (a)決定專案是否宜繼續進到下一個階段，以及 (b)有成本效益地偵知及矯正錯誤。 在每個專案結案時或結案期間，重要的是，經驗與教訓僅要予以擷取及分析，還要讓整個組織都可取用，以促進過程的改善。此將有助於管階層及過程技巧處斷變革中的技術。 相對應國際標準： ISO/IEC 16326 (1999) Software engineering G
37、uide for the application of ISO 12207 to project management 引用標準： CNS 14837 資訊技術軟體生命週期過程 13 CNS 14974, X 3012 附 A (考 ) CNS 14837 管過程的支援 表 A.1 別 CNS 14837 的五項主要生命週期過程支援管過程的活動。 備考 1. 於高階 (如第 5.2 節 )對映，向下至所有較低的層級 (如第 5.2.3 節 )。 2. 在本表中： X=客觀對映， O=主觀對映 (可能有歧存在 )。 表 A.1 CNS 14837 支援 CNS 14837 管過程活動 5. 主要
38、生命週期過程 7.1 管過程活動 7.1.1啟始及範圍定義 7.1.2規劃 7.1.3與控制 7.1.4審查與評估 7.1.5結案 5.1 獲取過程 5.1.1 啟始 X 5.1.1.5 使用發展過程 X 5.1.1.8 獲取計畫 X 5.1.2 招標書準備 X X 5.1.3 合約準備及新 X X 5.1.3.5 控制及評估變 X 5.1.4 供應者監視 X X 5.1.5 驗收與結案 X X 5.2 供應過程 5.2.1 啟始 X 5.2.2 回應準備 X 5.2.3 簽訂合約 X O 5.2.4 規劃 X 5.2.5 與控制 X O 5.2.6 審查與評估 X 5.2.7 交付與結案 X
39、 5.3 發展過程 X 5.3.1 過程實作 X 5.3.1.1 選擇生命週期模型及對映活動 X 5.3.1.4 發展與過程計畫 X 5.3.2.2 評估系統需求 X 14 CNS 14974, X 3012 5. 主要生命週期過程 7.1 管過程活動 7.1.1啟始及範圍定義 7.1.2規劃 7.1.3與控制 7.1.4審查與評估 7.1.5結案 5.3.3.2 評估系統架構與需求 X 5.3.4.2 評估軟體需求 X 5.3.4.3 舉軟體需求合審查 X 5.3.5.6 評估軟體項目架構 、 及介面與資庫設計 X 5.3.5.7 舉軟體架構設計合審查 X 5.3.6.7 評估軟體細部設計及
40、測試需求 X 5.3.6.8 舉軟體細部設計合審查 X 5.3.7.5 評估軟體編碼與測試結果 X 5.3.8.1 發展整合計畫 X 5.3.8.5 評估整合計畫、設計、程式碼、測試、測試結果及使用者文件 X 5.3.8.6 舉軟體整合合審查 X 5.3.9.3 評估設計、程式碼、測試、測試結果及使用者文件 X 5.3.9.4 支援軟體資格測試稽核 X 5.3.10.3 評估整合後的系統 X 5.3.11.2 評估系統 X 5.3.11.3 支援系統資格測試稽核 X 5.3.12.1 發展軟體安裝計畫 O X 5.3.13.1 支援獲取者的驗收審查及軟體產品測試 X 5.4 營運過程 X 5.
41、4.1 過程實作 X 5.5 維護過程 5.5.1 過程實作 X 5.5.1.1 發展及維護計畫X 15 CNS 14974, X 3012 5. 主要生命週期過程 7.1 管過程活動 7.1.1啟始及範圍定義 7.1.2規劃 7.1.3與控制 7.1.4審查與評估 7.1.5結案 及程序 5.5.1.2 建問題報告及修改請求之接收、記及追蹤的程序；並提供回饋 X 5.5.2 問題及修改分析 X 5.5.2.1 分析問題報告或修改請求 X 5.5.2.3 考修改實作的選項 X 5.5.3 修改實作 X 5.5.4 維護審查 /驗收 X 5.5.5 移植 X 5.5.5.2 發展及移植計畫 X
42、5.5.5.6 後的營運審查 X 5.5.6 軟體汰除 X X 5.5.6.1 發展及汰除計畫 X 16 CNS 14974, X 3012 附 B (考 ) SPM 活動對映至管過程活動 表 B.1 別 11應用至 CNS 14837 管過程活動的過程 表 B.1 專案管知域過程支援 CNS 14837 管過程活動 7.1 管過程活動 專案管知域 專案管知域過程 7.1.1 啟始及範圍定義 7.1.2規劃 .3與控制 .4審查與評估 7.1.5結案4.1 專案計畫發展 X X 4.2 專案計畫 X X 4. 專案整合管 4.3 整體變控制 X X 5.1 啟始 X 5.2 範圍規劃 X X
43、5.3 範圍定義 X X 5.4 範圍查證 X X X 5. 專案範圍管 5.5 範圍變控制 X X X X 6.1 活動定義 X X 6.2 活動排序 X 6.3 活動持續期間估算 X X X 6.4 時程發展 X 6. 專案時間管 6.5 時程控制 X X 7.1 資源規劃 X X 7.2 成本估算 X X X 7.3 成本預算編製 X 7. 專案成本管 7.4 成本控制 X X 8.1 品質規劃 X X 8.2 品質保證 X X 8. 專案品質管 8.3 品質控制 X X 9.1 組織規劃 X X X 9.2 成員獲取 X X 9. 專案人資源管 9.3 團隊發展 X X 10. 專案溝
44、通管 10.1 溝通規劃 X X 17 CNS 14974, X 3012 7.1 管過程活動 專案管知域 專案管知域過程7.1.1 啟始及範圍定義 7.1.2規劃 .3與控制 .4審查與評估 7.1.5結案10.2 資訊分發 X 10.3 績效報告 X X 10.4 政管結案 X X 11.1 風險別 X X 11.2 風險化 X X 11.3 風險回應發展 X X X 11. 專案風險管 11.4 風險回應控制 X X X X 12.1 採購規劃 X X 12.2 徵求規劃 X X 12.3 徵求 X X 12.4 貨源選擇 X X X 12.5 合約政管 X X 12. 專案採購管 12
45、.6 合約結清 X X 18 CNS 14974, X 3012 附 C (考 ) 專案管過程對映至 CNS 14837 管過程活動 表 C.1 別 5中應用到 CNS 14837 管過程活動的專案管過程。 備考：在本表中： X=客觀對映，而 O=主觀對映 (可能有些歧存在 ) 表 C.1 專案管過程對 CNS 14837 管過程活動的支援 CNS 14485 7.1 管過程活動 專案管過程分組 專案管過程 7.1.1啟始及範圍定義 7.1.2規劃 7.1.3 與控制 7.1.4 審查與評估 7.1.5結案 5.3.1 專案啟始及專案計畫發展 X X X 5.3.2 互動管 X X X 5.3
46、.3 變管 X X X 5.3 相互依賴性管過程 5.3.4 結案 X X 5.4.1 概發展 X 5.4.2 範圍發展與控制 X X X 5.4.3 活動定義 X 5.4 範圍相關過程 5.4.4 活動控制 X X 5.5.1 活動相依性規劃 X X 5.5.2 持續期間的估算 X 5.5.3 時程發展 X 5.5 時間相關 過程 5.5.4 時程控制 X X X 5.6.1 成本估算 X 5.6.2 預算編 X 5.6 成本相關 過程 5.6.3 成本控制 X X X 5.7.1 資源規劃 X 5.7 資源相關 過程 5.7.2 資源控制 X X X 5.8.1 專案組織結構定義 X 5.8.2 人員配置 X O 5.8 人員相關 過程 5.8.3 團隊發展 O 5.9.1 溝通規劃 O O 5.9.2 資訊管 X X 5.9 溝通相關 過程 5.9.3 溝通控制 O O 19 CNS 14974, X
