CNS 14974-2006 Software engineering - Guide for the application of CNS 14837 to project management《软件工程-CNS 14837在项目管理上之应用指导》.pdf
《CNS 14974-2006 Software engineering - Guide for the application of CNS 14837 to project management《软件工程-CNS 14837在项目管理上之应用指导》.pdf》由会员分享,可在线阅读,更多相关《CNS 14974-2006 Software engineering - Guide for the application of CNS 14837 to project management《软件工程-CNS 14837在项目管理上之应用指导》.pdf(36页珍藏版)》请在麦多课文档分享上搜索。
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),以做變的融合,以將對發展時程的衝擊至最小,並使穩定性最大化。 - 介面上的協議宜於專案承上達成,並在整個專案期間處模糊、準確、斷變之長期性問題,或是無法測試的需求與規格。 - 大多的成本模型是以軟體的估計的。其真正的問題在於的決定及對特定專案的模型調整上。要做好此一工作,宜考下事項: - 自先前專案所蒐集到的資。 - 運用專家去運作及解該模型。 - 未依專案的組織經驗做調整,則成本模型誤差可能會達到一倍以上。 - 無如何宜只靠一個成本模型去產生
- 1.请仔细阅读文档,确保文档完整性,对于不预览、不比对内容而直接下载带来的问题本站不予受理。
- 2.下载的文档,不会出现我们的网址水印。
- 3、该文档所得收入(下载+内容+预览)归上传者、原创作者;如果您是本文档原作者,请点此认领!既往收益都归您。
下载文档到电脑,查找使用更方便
10000 积分 0人已下载
下载 | 加入VIP,交流精品资源 |
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CNS149742006SOFTWAREENGINEERINGGUIDEFORTHEAPPLICATIONOFCNS14837TOPROJECTMANAGEMENT 软件工程 CNS14837 项目 管理

链接地址:http://www.mydoc123.com/p-634816.html