CMM

CMM

CMM評審過程

組織標準軟件流程

WBS

估算

計劃

風險

PR

軟件過程跟蹤與監控

SCM

涉眾溝通

 

CMM Capability Maturity Model

CMM是一種抽象模型，描述在某個成熟度級別上所要達到的目標，它闡述要求而不指導如何做，通過CMM某個級別認證就是根據部門實際情況和過去的項目開發經驗總結出一套適合的體系同時滿足CMM這個級別包括以下級別所要求所有KPA目標。CMM是軟件過程管理的改進框架，初始級、可重復級、已定義級、可管理級、優化級。

Level	Focus	Kay Process Areas
Level 5 Optimizing	Continuous process improvement	-Defect Prevention -Technology Change Management -Process Change Management
Level 4 Managed	Product and Process quality	-Quantitative Process Management -Software Quality Management
Level 3 Defined	Engineering Processes and organizational support	-Organization Process Focus -Organization Process Definition -Training Program -Integrated Software Management -Software Product Engineering -Inter group Coordination -Peer Review
Level 2 Repeatable	Project management processes	-Requirements Management -Software Project Planning -Software Configuration Management -Software Quality Assurance -Software Project Tracking and Oversight -Software Subcontract Management
Level 1 Initial	Competent people（and heroics）

基於CMM的正式評估的一個專用名稱：CBA IPI

CMM Based Appraisal for Internal Process Improvement

用於内部過程改進的基於CMM的評估

 

KP：關鍵實踐

目標

共同特點：

1 執行約定

2 執行能力

3 執行的活動

4 測量和分析

5 驗證實施

 

持續的過程改進，可以採取SEI推薦的IDEAL模型為參照，代表組織軟件過程改進周期的5個階段：初始化（Initiating），診斷（Diagnosing），建立（Establishing）,行動（Acting），擴充（Leveraging）。

1 CMM作爲軟件過程管理的改進框架，在每一個成熟度等級上都對軟件過程各階段做了特徵描述，以是否滿足這些特徵來對軟件組織作出能力成熟度評估。

2 每個KPA規定了軟件組織為滿足該KPA必須實現的目標。

3 組織實現了一個等級所有的KPA目標，則在項目管理的能力上達到了相應的成熟度級別。

 

原因闡述：

軟件開發的不透明性，給軟件的管理和控制造成了很大困難，所以軟件產品不能按時完成、軟件生産力預算超支以及產品中大量無法克服的錯誤是常有的事，一個項目的成功往往依賴個人的突出能力，這樣的生産方式顯然不適合項目多的大中型組織。雖然新的軟件開發方法和技術不斷產生，但軟件生産率和質量並沒有有效提高，所以人們開始意識到軟件生産過程的成敗更能決定一個項目或企業的成敗。

對成功的軟件過程的復用，對以往經驗或教訓的分析總結，對全部開發文檔的系統編檔存檔就成了一套完整而成熟的軟件過程，建立一個從無序到有序，從人爲到客觀標準，從定性到定量的不斷積累與完善的過程，使軟体開發過程向有紀律的，標準一致的，可預測的方向發展。

 

益處：

提供給管理者對項目狀態和性能的可視性，依靠整個團隊的合作，實現資源共享，調度有序，過程可監控。使得整個軟件開發工作在一種有序，可控的情況下進行。

在实施CMM标准中，软件人员必须填写大量文档，这无疑增加了许多工作量，但磨刀不误砍柴工，这样也带来了很大好处，增加了过程的可视性，保证了软件产品的质量，加强了团队的合作与协调，积累大量经验，很多缺陷问题在一开始就能被找到，减少损失和为弥补损失所带来的工作量，更重要的是在人才流动频繁的软件行业，公司不至于人员的流动而蒙受巨大损失，因为一个好的软件过程已经把软件开发重要经过以文档形式保存下来，人走了经验还在，下一个接手工作人通过文档也很容易上手，不需要从头再来，这就为公司节约了时间和成本，而一个没有良好软件开发过程的组织很有可能在人员流动中蒙受巨大损失。

 

 

基於CMM體系的軟件項目管理分析

雖然CMM關注的焦點是過程改進，但從過程的性質來看，可以分解為不同類型的過程：管理過程，組織過程和工程過程

	管理過程	組織過程	工程過程
優化級		技術變更管理
已管理級	過程變更管理 量化過程管理		缺陷預防 軟件質量管理
已定義級	集成軟件管理 組閒協調	組織過程焦點 組織過程定義 培訓大綱	軟件產品工程 同行評審
可重用級	需求管理 軟件項目計劃 軟件項目跟蹤與監控 子合同管理 軟件質量管理 軟件配置管理
初始級	隨意的過程

 

OSSP：Organization Standard Software Process

組織標準流程對應CMM KPA

Processes			KPA
RDP	Requirement Development Process	需求開發流程	RM
RCMP	Requirement Change Management Process	需求變更管理流程	RM
RT	Requirement Tracking	需求跟蹤	RM
PPP	Project Plan Process	專案計劃流程	SPP
PEP	Project Estimation Process	專案估算流程	SPP
DP	Design Process	設計流程	SPE
ITP	Implementation and Test Process	實現與測試流程	SPE
ATDP	Acceptance Test and Delivery Process	驗收測試與交付流程	SPE
DTP	Defect Tracking Process	缺陷跟蹤流程	SPE
PIP	Project Initial Process	專案立案流程	SPTO
PCP	Project Close Process	專案結案流程	SPTO
PTOP	Project Tracking and Oversight Process	專案跟蹤與監控流程	SPTO
SCMP	Software Configuration Management Process	配置管理流程	SCM
BPP	Baseline Promotion Process	基綫升級流程	SCM
SQAP	Software Quality Assurance Process	軟件品質保證流程	SQA
AP	Audit Process	審計流程	SQA
NCHP	NC Handling Process	NC處理流程	SQA
PR	Peer Review	同行評審	PR
IC	Inter-group Coordination	組閒協調	IC
TP	Training Program	培訓大綱	TP

 

估算

Delphi法

1 角色和職責

        會議協調人：制定Delphi估算活動計劃

                                召集估算專家並提供估算基礎資料

                                主持會議

                                記錄會議結果並通報該結果

        估算專家：    會議前熟悉所獲得的估算基礎資料

                                參加會議

                                提供並修訂自己的估算意見

2 過程描述

        計劃：進行Wide-Delphi估算的第一步要制定一個計劃，要求：

                                確定估算類型

                                選擇一個協調人

                                選擇進行估算的專家

                                制定會議日程

                                組織需要的咨詢（要估算的產品的詳細説明，任務單或WBS）

        估算會議開始： 協調人將以下的估算咨詢提供給估算專家：

                                要估算的產品WBS的詳細説明

                                估算會議要達到的目標

                                假設與限制

                                        估算專家要：

                                復審已有信息

                                確定統一的度量單位

        估算開始：估算者使用如下統一的估算標準進行估算：

                                假設一個人完成全部任務

                                假設所有任務按順序完成

                                假設執行任務中沒有干擾

                                專家獨立地對每個任務作出初始估算

                        將估算結果記錄到Delphi估算表，並註明用到的假設條件。

例：專家對五個任務估算的工作量如下：

統計估算結果：會議協調人收集各專家的估算資料

 

進行討論：協調人組織討論估算的客體，假設及其他相關的任何分歧和問題，討論的時間限制在10~20分鐘

 

調整估算結果：

1 討論后，專家們根據對產品更新的理解以及討論中獲得的新資訊修改個人的估算，並記錄到Delphi估算表中。

2 協調人收集修正的估算，並記錄在同一張估算統計表中，完成一輪估算

3 繼續此過程直到已經作了四輪估算；或估算的分佈範圍已小到可以接受的過程；或已到會議時間（通常是2小時）；或專家們都不想改變自己的估算。

得到最後估算結果可以選擇的方法如下：

取平均值

取中

給出一個範圍

給出平均值（樂觀值和悲觀值）

估算的結果確定后，估算的協調人要使大家取得共識，且假設已經形成文檔

 

3 裁減指南：過程可根據需要持續多次，一般3~5輪；或估算的分佈範圍已小到可以接受的程度；或已到會議時間；或專家們都不想改變自己的估算。

 

Pert法

1 角色與職責

        估算協調人：熟悉專案情況

                                根據已經實現的WBS將任務分配給估算責任人

                                整理和通報估算結果，將估算結果歸納入過程數據庫

        估算負責人：負責提交某個估算單元的估算結果

        估算員：        是WBS某個任務的責任主體，負責該任務的開發

估算員凴藉開發經驗和可參考的歷史流程資料庫，對分配的任務進行估算。

1.     描述

1.1     計劃和準備

估算協調員應該確保專案工作分解結構WBS已經分解成適合和均勻的估算的粒度。合適的、均勻的顆粒度例如：對於專案規模KLOC，每個子任務一般不超過1KLOC；對於規模很小的專案，一般不超過 300L OC；對於進度估算，每個子任務一般不超過2周。（此規模資料僅供參考）

1.2     分配估算任務

 估算協調人將每個估算單元分配給估算責任人。每個估算單元至少有一位元估算員，建議2位估算員參加估算。對於規模估算，應該注意一個估算員不應該同時負責多個估算單元的估算，除非是多個模組的負責人.

1.3     進行估算  

估算責任人負責組織本估算單元的估算。給出最小規模、最大規模和最可能規模估算資料，三者之間的差距應該在一個建議的限度之內，（最大規模-最小規模）/最可能規模<40%，記錄估算的限制和假設。

最小規模：最順利情況下的估算；

最大規模：最糟糕情況下的估算；

最可能規模：最有可能實現的估算.

1.4     統計結果

估算協調人收集估算資料，匯總各個子任務到一張表內。該表格自動累積成整個專案的規模。

期望值=（最小規模+最大規模+4*最可能規模）/  6；

標準差=（最大規模-最小規模）/6；

它們的含義是：

期望值E，根據給出的三個值，推算出最可能接近實際情況的估算值；

標準偏差SD，[E-SD,E+SD]是可以接受的規模估算的範圍。如果最終的實際值，落在該範圍內，則認為估算是成功的。在組織使用該方法的初期，該範圍可能比較大，但隨著估算的不斷精確，該範圍應該被有意識的減少，以求得更加準確的估計。

1.5     修正估算結果

估算協調人將最後的結果發佈給所有估算負責人和估算員，讓他們確認自己的估算，如果不存在偏差，這估算到此為止。如果認為原來的估算不恰當，可以提出，並對該子任務進行重新估算，重複上面的步驟，直到估算結果可接受。

WBS

作用：提供一種視圖，清楚表示完成該項目所要完成的活動和產出，界定工作範圍，並為估算提供基礎。按系統或者按階段劃分。

System/Subsystem/Module/Task/Work package/Act/LOE

PR Peer Review同行評審

目的：發現缺陷，並尋找改進契機。

質量並不是免費的，評審不會減慢進度，缺陷卻會，後期發現缺陷會付出昂貴的代價。

 

PR分類：

Inspection 審查

Team Review 小組評審

Walk Through 走查

Pass around 輪查

品質問題重點: 找到Defect

PR目的: 找到Defect

好處: 團隊交流, 技術進步

方法: 作者找出關鍵部份

 

針對高風險工作產品，具有高風險部分的大型產品，以及即將基綫化的工作產品，使用Inspection。那些即使含有未被發現的錯誤，對時程，品質，功能目標影響較小的產品，則可採用較非正式的幾種評審方式。

 

參與角色

1 前置文件或規格的作者

2 必須把他們的隨後的工作建立在這項工作產品上的人

3 作者的同事

4 與此工作產品界面相關的組件負責人

工作產品類型	建議參與角色
架構或概要設計	Architect，RA，SA，PM，整合測試工程師
詳細設計	SA，Architect，程式員，整合測試工程師
流程文件	SEPG組長及成員，管理層級的Process Owner，流程執行者
專案計畫	PM，Business Sponsor，Marketing或Sales代表，技術組長，QA經理
需求規格說明書	RA，PM，Architect，SA，系統測試工程師，QA經理，用戶或Marketing代表，文件編寫人員，內容專家，技術支持代表
源代碼	程式員，SA，單元測試工程師，maintainer，RA，編程標準專家
系統技術文件	作者，PM，maintainer，程式員
測試文件	測試工程師，程式員（單元測試）或者Architect（整合測試）或者RA（系統測試），QA代表
用戶界面設計	用戶界面設計者，RA，用戶，應用領域專家，可用性或者人因工程專家，系統測試工程師
使用手冊	文件編寫人員，RA，用戶或Marketing代表，系統測試工程師，maintainer，SA，教育訓練的設計者及講師，技術支持代表

 

 

Inspection

角色:

1 作者

2 仲裁人

3 宣讀人

4 記錄員

5 評審員

6 驗證者

7 同行評審協調員

 

階段                步驟:

計劃                作者提出PR, 向仲裁人交付評審工作產品和相關文件

                        選擇評審員, 分配角色, 確認同意參加

                        排定評審會議和內容概述會議, 並發出會議通知

                        在評審會議之前至少三個工作日將評審包法給參加者

概述                把工作產品的重要特徵報告評審團隊. 說明評審目標

                        研究工作產品的前提, 歷史本文

準備                紀錄所發現的缺陷, 在評審會議中或之前交付給作者.包括排版錯誤或者風格不一致等.

評審會議        仲裁人說明角色及評審目標, 集中缺陷.

                                宣讀工作產品

                                評審員提出缺陷和問題

                                記錄員紀錄問題, 缺陷紀錄表(每個缺陷的訊息: 來源, 類型, 嚴重程度, 位置, 描述)

                                評審員決定工作產品的評價(照原樣接受, 優條件的接受, 重工後重新檢閱, 檢閱未完成)

                                評審員簽署摘要報告, 以見證此次評審結果

                                仲裁人收集評審回饋

改正                        作者修正缺陷

                                仲裁人紀錄工作量

後續追蹤        驗證者驗證缺陷處理完成

                                將工作產品基線化

                                同行評審協調員收集數據, 找到及改正的缺陷數, 評審摘要報告

 

交付標的        基線化的工作產品

                                完成評審摘要報告

                                完成缺陷紀錄表

                                完成排版問題清單

                                發現的缺陷數和改正的缺陷數

 

Team Review, Walk Through與Inspection共同與區別

共同:

1 都需事前準備

2 都由作者發起

 

不同點

Team Review

評審員發回Issue log給作者, 如果有爭議須調整則舉行會議

集中討論Issue, 不用一行一行讀

 

Walk Through

準備時間短, 作者兼仲裁者

 

風險

風險是一種不確定的事件或條件, 如果它發生, 將會對項目目標造成正面或者負面的影響.

風險的屬性:

                        1 一個事件

                        2 發生概率

                        3 造成影響(範圍, 時間跨度)

                        4 發生的頻率

風險的表現形式一般是以最終產品的質量問題或成本增加或項目延誤, 甚至是項目整體失敗.

 

風險管理是對項目風險進行識別, 分析和應對的系統化過程

1 風險管理計畫的編制

2 風險識別

3 風險定性分析

4 風險定量分析

5 風險應對計畫編制

6 風險監控

 

參與風險識別人員:

風險管理團隊成員, 客戶, 最終用戶, 項目幹系人, 其他項目經理, 專家

 

何時識別風險

1 在項目開始時就進行風險識別, 並且在每一個階段, 特別是在每個階段的開始進行風險識別

2 反覆執行

 

風險識別的方法

1 歷史信息或類似項目

2 專家

3 頭腦風暴 Delphi

4 編制風險列表

 

風險發生概率(高/中/低)

對影響的評估(大/中/小)

風險評分 risk score = 概率 x 影響

 

需要管理的風險類型

1 有很大影響/發生概率很高

2 影響不大/發生概率很高

3有很大影響/發生概率很小

 

風險應對計畫

1 風險規避: 重新制定計劃, 改變項目範圍等, 消除風險起因, 已規避風險

2 風險轉移: 通過責任分配, 保險, 制定合同, 外包等方式使其他人對風險負責.

3 風險緩解: 設法減輕風險的負面影響或減小其發生概率

4 風險接受: 如果風險發生, 什麼措施也不採取, 接受之; 或者採取應急計劃.

 

風險應對策略

1 保險: 將不可知的風險轉化為可知風險和成本

2 簽訂合同: 如果對方更有經驗, 是減輕風險, 如果通過合同使對方接受風險, 則是風險轉移.

3 應急儲備: 可以是時間或資金, 以備風險發生預留.

 

關於風險經常問題

Q: 對於非常嚴重的風險你如何處理

A: 列在風險清單裏, 經常重新評估

 

Q: 你只會採用一種風險管理策略嗎?

A: 不, 應該根據實際情況做出合理的組合

 

Q: 在項目執行階段, 你要做什麼風險管理活動

A: 監控風險(包括對非嚴重風險)和執行風險管理計畫

 

Q: 什麼是項目會議最重要的議題?

A: 風險

 

Q: 如何在會議上考慮風險

A: 依次詢問每一個已識別的風險的情況, 問題由所有者回答, 同時詢問有沒有新的風險

 

軟件過程跟蹤與監控

跟蹤與監控的目的: 及時反應專案的進度, 成本, 風險, 規模, 關鍵計算機資源及工作量等情況, 通過對跟蹤結果的分析, 依據跟蹤與監控策略採取有效的行動, 使專案組能在既定的時間, 成本, 品質要求等情況下完成專案. 專案成功的保障.

 

步驟:: 計畫, 執行, 與專案計畫比較, 修正偏差

1 六大跟蹤要素

2 跟蹤頻率

3 確定偏差計算公式, 偏差範圍(實際值-估計值)/實際值

4 明確數據資料收集方式(email或例會), 明確每項跟蹤數據的提供者.

5明確偏差的處理措施,一般情況下,若偏差超出域值範圍,應對規模,工作量,成本進行重新估算,應重新調整專案進度,重新計畫專案任務,重新分配專案任務;對風險應該按照風險管理策略來執行;對於關鍵計算機資源應根據實際情況調整資源計劃.

 

專案例會目的: 為了跟蹤專案活動以及評審專案六大跟蹤項的跟蹤結果. 在會議之前, 要將上週專案的追蹤資料, 例會上將要討論的內容以及下週將要進行的工作匯總到例會報告中, 作為專案例會討論的基本內容.

專案例會中除了確認專案跟蹤資料, 還要討論的內容包括: 專案議題/動議, SQA報告, PM相關報告, Issue log, 風險, NC, 需求變更, 控制項變更.

 

里程碑會議

在有重要交付產品或者專案重要階段過度時召開

會議目的: 評審專案流程活動及其交付產品, 專案經理檢查里程碑點產品的技術評審結果, 評估專案風險, 判斷專案是否能繼續進行併評審下一階段的計畫.

提交會議資料: 專案經理提交專案相關計畫(如專案計畫, 開發計畫), 里程碑報告, 里程碑交付產品的技術評審結果; SQA人員提交SQA報告.