軟件項目管理

 

第一章 軟件項目管理基本概念

項目定義

項目(Project)是爲了創造一個惟一的產品或提供一 個惟一的服務而進行的臨時性的努力。

項目的特徵

• 有明確的目標
• 項目之間的活動具備相關性
• 限定的週期
• 有獨特性
• 資源成本的約束性
• 項目的不肯定性

項目管理定義

項目管理是一系列的伴隨着項目的進行而進 行的、目的是爲了確保項目可以達到指望的 結果的一系列管理行爲。

軟件項目管理

• 是軟件工程組成部分
• 確保軟件項目知足預算,成本等約束,提交高質量軟件產品

敏捷模型（Agile Development）

• 敏捷組織提出的一個靈活開發方法
• 應對迅速變化需求的快速軟件開發方法
• 是一種迭代、按部就班的開發方法

敏捷宣言——4個價值

• 個體和互動高於流程和工具
• 可工做的軟件高於詳盡的文檔
• 客戶合做高於合同談判
• 響應變化高於遵循計劃

第二章 軟件項目確立

項目立項

明確項目的目標、時間表、項目使用的資源和經費，並且獲得執行該項目的項目經理和項目發起人的承認 。

項目招投標過程

甲方招標書定義——乙方項目分析——招標與競標——合同簽署

項目章程(Project Charter)

確認項目存在的文件，包括對項目的確認、對項目經理的受權和項目目標的概述等。

敏捷項目章程

基本要素:

• 項目目標
• 發佈標準
• 預期的工做流

第三章 生存期模型

生存期模型

• 預測型模型
• 迭代模型
• 增量模型
• 敏捷模型
• 混合模型

軟件開發模型變遷

做坊式——過程控制——敏捷——DevOps

項目生存期選擇

• 預測型:提早進行大量的計劃工做，而後一次性執行；執行是一個連續的過程。
• 迭代型:容許對未完成的工做進行反饋，從而改進和修改該工做。
• 增量型:向客戶提供各個已完成的，能夠當即使用的可交付成果。
• 敏捷型:既有迭代，也有增量，便於完善工做，頻繁交付。

預測型-模型

• 瀑布模型
• V模型

迭代模型Or:原型模型

增量模型

優勢：

• 階段式提交一個可運行的產品
• 關鍵的功能更早出現
• 早期預警問題，避免缺陷蔓延
• 階段性完成能夠下降估計失誤

敏捷方法

敏捷方法是一個囊括了各類框架和方法的涵蓋性術語。

Scrum模型

• 1990年代初，肯·施瓦伯在其公司使用了一種方法Advanced Development Methods（先進開發方法），這種方法後來發展爲Scrum。
• 敏捷模型的表明。

XP(eXtreme Programming)極限編程模型

XP(eXtreme Programming)極限編程是由Kent Beck提出的一套針對業務需求和軟件開發實踐的規則。

精益（Lean）

精益（Lean）模式提倡持續不斷地改進, 減小流程中的浪費。

DevOps: Development和Operations的組合

• 全程敏捷思惟。
• 開發和運維工做緊密合做。

DevOps是一組過程、方法與系統的統稱，用於促進開發、技術運營和質量保障（ QA）部門之間的溝通、協做與整合。

混合模型

第四章 軟件需求管理

軟件需求管理過程

• 需求獲取
• 需求分析
• 需求規格編寫
• 需求驗證
• 需求變動

需求建模的基本方法

• 原型方法
• 基於數據流建模-結構化分析法
• 基於UML建模- 面向對象的用例分析法
• 敏捷需求分析

軟件需求定義

需求是指用戶對軟件的功能和性能的要求。

需求獲取

需求分析

需求分析是爲最終用戶所看到的系統創建一個概念模型，是對需求的抽象描述。

需求規格編寫

需求分析工做完成的一個基本標誌是造成了一份完整的、規範的需求規格說明書。

需求驗證

需求變動管理

① 肯定需求變動控制過程

② 創建變動控制委員會(SCCB)

③ 進行需求變動影響分析

④ 跟蹤全部受需求變動影響的工做產品

⑤ 創建需求基準版本和需求控制版本文檔

⑥ 維護需求變動的歷史記錄

⑦ 跟蹤每項需求的狀態

⑧ 衡量需求穩定性

需求建模的基本方法介紹

傳統方法: 1. 原型方法 2. 基於數據流建模 3. 基於UML建模

敏捷方法

基於數據流- 結構化分析方法

• 20世紀70年發展起來的面向數據流的方法
• 是一種自頂向下逐步求精的分析方法
• 根據軟件內部數據傳遞、變換的關係進行分析的

基於數據流的技術

• 數據流圖(DFD)
• 數據字典(DD)
• 系統流程圖

基於UML方法

• 基於面向對象的情景分析方法
• 從用戶角度出發考慮的功能需求
• 用例是系統向用戶提供一個有價值的結果的某項功能

UML需求視圖

• 用例圖（Use case Diagram）
• 順序圖（Sequence Diagram）
• 狀態圖（State Diagram）
• 活動圖（Activity Diagram）

基於UML方法綜述

• 識別出系統的Actor
• 描述須要的Use case
• 實現用例視圖
• 實現順序視圖，活動視圖，狀態視圖等

Product Backlog:產品待辦事項列表

• 需求的來源
• 包含產品想法的一個有序列表
• 一個長短不定列表
• 能夠是模糊的或是不具體的
• 逐漸完善，愈來愈明確

Sprint Backlog:待辦事項列表的細化

• 按照迭代計劃,逐步細化需求,造成Story(故事),
• 鼓勵開發人員、測試人員、業務分析人員和產品 負責人合做編寫故事,
• 確保全部的故事都足夠小,能夠持續交付工做。
• 最好天天完成至少一個故事。

第五章 軟件項目任務分解

任務分解

任務分解是項目管理的基礎

過程：將一個項目分解爲更多的工做細目或者子項目，使項目變得更小、更易管理、 更易操做

結果：WBS（ Work Breakdown Structure: 任務分解結構）

工做包（ Work packages）

• WBS的最低層次的可交付成果
• 工做包應當由惟一主體負責

分解方法

• 類比
• 模板參照
• 自上而下
• 自下而上

WBS任務分解建議

• 最低層是可控的和可管理的，可是沒必要要的過細
• 每一個Work package必須有一個提交物
• 定義任務完成的標準
• 有利於責任分配
• 推薦任務分解到40小時之內,敏捷項目分解到小時

第六章 軟件項目成本計劃

關於估算

• 估算不是很準確，有偏差
• 項目經驗數據很是重要
• 不要太迷信某些數學模型

軟件項目規模

軟件項目規模即工做量 例如：軟件規劃，軟件管理，需求，設計，編碼，測試，以及後期的維護等任務。

軟件規模單位

• LOC(Loc of Code)
• 源代碼長度的測量
• FP(Function Point)
• 用系統的功能數量來測量
• 人月
• 人天
• 人年

軟件項目成本

• 完成軟件規模相應付出的代價。
• 待開發的軟件項目須要的資金。
• 人的勞動的消耗所須要的代價 是軟件產品的主要成本
• 貨幣單位

成本估算結果

直接成本

與具體項目相關的成本, 例如：參與項目的人員成本

間接成本

能夠分攤到各個具體項目中的成本，例如：培訓、房租水電、員工福利、市場費用、管理費、其餘等等

傳統估算方法

代碼行估算法

從軟件程序量的角度定義項目規模

1. 與具體的編程語言有關
2. 分解足夠詳細
3. 有必定的經驗數據

代碼行技術的主要優缺點

優勢：代碼是全部軟件開發項目都有的"產品"，並且很容易計算代碼行數。

缺點：1. 對代碼行沒有公認的可接受的標準定義

2. 代碼行數量依賴於所用的編程語言和我的的編程風格.

3. 在項目早期,需求不穩定、設計不成熟、實現不肯定的 狀況下很難準確地估算代碼量.

4. 代碼行強調編碼的工做量,只是項目實現階段的一部分

功能點估算法

• 與實現的語言和技術沒有關係
• 用系統的功能數量來測量其規模
• 經過評估、加權、量化得出功能點

Albrecht功能點估算

• 1979年, Alan Albrecht 提出
• 也稱爲IFPUG(國際功能點用戶組織)功能點
• 適用於信息系統

功能點公式

FP =UFC*TCF

UFC：未調整功能點計數

TCF：技術複雜度因子

外部輸入(External Inputs： EI)

給軟件提供面向應用的數據的項（如屏幕、表單、對話 框、控件，文件等）；在這個過程當中，數據穿越外部邊界進入到系統內部。

外部輸出(External Outputs EO)

向用戶提供(通過處理的)面向應用的信息，例如， 報表和出錯信息等。

外部查詢(External Inquiry EQ)

外部查詢是一個輸入引出一個即時的簡單輸出。 沒有處理過程。

外部接口文件（External Interface Files EIF's）

外部接口文件是用戶能夠識別的一組邏輯相關數據， 這組數據只能被引用。用這些接口把信息傳送給另外一個系統。

內部邏輯文件(Internal Logical Files： ILF'S)

用戶能夠識別的一組邏輯相關的數據，並且徹底存在於應用的邊界以內，而且經過外部輸入維護，是邏輯主文件的數目。

其餘功能點方法

• Mark II 功能點(主要應用在英國)
• COSMIC – FFP 功能點(適用實時系統或者嵌入式系統)

用例點估算法

用例點估算方法的基本步驟

1. 計算未調整的角色權值UAW;

2. 計算未調整的用例權值UUCW ;

3. 計算未調整的用例點UUCP;

4. 計算技術和環境因子TEF;

5. 計算調整的用例點UCP ;

6. 計算工做量( man－hours) 。

類比 (自頂向下)估算法

估算人員根據以往的完成相似項目所消耗的總成本（或工做量），來推算將要開發的軟件的總成本（或工做量）。是一種自上而下的估算形式。

類比估算—使用狀況

• 有相似的歷史項目數據
• 信息不足（例如市場招標）的時候
• 要求不是很是精確估算的時候

自下而上估算法

利用任務分解圖(WBS),對各個具體工做包進行詳細的成本估算,而後將結果累加起來得出項目總成本。

特色

1. 相對比較準確，它的準確度來源於每一個任務的估算狀況
2. 花費時間

三點估算法

基於任務成本的三種估算值來計算預期成本的方法.

三種估算值

最可能成本（CM）:比較現實的估算成本。

最樂觀成本（CO）:最好狀況所獲得的估算成本。

最悲觀成本（CP）:最差狀況所獲得的估算成本。

參數估算法

• 經過項目數據,進行迴歸分析,得出迴歸模型
• 經過參數模型估算(規模)成本的方法。

參數模型綜述

• 根據項目數據進行迴歸分析，得出迴歸模型做爲參數模型。
• 迴歸分析方法：線性迴歸，多項式迴歸，邏輯迴歸，神經網絡，集成方法等。
• 參數模型能夠是線性也能夠是非線性的。

使用條件

1. 具備良好的項目數據爲基礎
2. 存在成熟的項目估算模型

特色

1. 比較簡單,並且也比較準確
2. 若是模型選擇不當或者數據不許, 也會致使誤差

專家估算法

由多位專家進行成本估算，一個專家可能會有偏見，最好由多位專家進行估算，取得多個估算值, 最後得出綜合的估算值。

專家估算法-Deiphi

1. 組織者肯定專家，這些專家互相不見面

2. 組織者發給每位專家一份軟件規格說明

3. 專家以無記名對該軟件給出3個規模的估算值

① 最小ai

② 最可能的mi

③ 最大bi

4. 組織者計算每位專家的Ei=(ai+4mi+bi)/6

5. 最終能夠得到一個多數專家共識的軟件規模： E=E1+E2+…En/n（n:表示n 個專家）

6. 若是各個專家的估算差別超出規定的範圍（例如： 15%），則需重複上述過程

敏捷估算思惟

• 採用輕量級估算方法快速生成高層級估算
• 短時間規劃能夠進行詳細的估算

Story point估算方法

Story point（故事點）用來度量實現一個Story 須要付 出的工做量的相對估算。

成本預算

• 成本預算是將項目的總成本按照項目的進度分攤到各個工做單元中去
• 成本預算的目的是產生成本基線

分配項目成本預算包括三種狀況：

1. 給任務分配資源成本

2. 給任務分配固定資源成本

3. 給任務分配固定成本

分配固定資源成本

當一個項目的資源須要固定數量的資金時，能夠向任務分配固定資源成本。

第七章 軟件項目進度計劃

進度計劃的重要性

1. 按時完成項目是項目經理最大的挑戰之一
2. 時間是項目規劃中靈活性最小的因素
3. 進度問題是項目衝突的主要緣由

進度的定義

進度是對執行的活動和里程碑制定的工做計劃日期表

任務定義（Defining Activities）

肯定爲完成項目的各個交付成果所必須進行的諸項具體活動

項目任務的關聯關係

項目各項活動之間存在必定的關聯關係，根據這些關係安排任務之間的順序

前置活動（任務）→後置活動（任務）

任務之間的關係

任務之間關聯關係的依據

• 強制性依賴關係
• 軟邏輯關係
• 外部依賴關係
• 內部依賴關係

進度管理圖示

• 網絡圖
• 甘特圖
• 里程碑圖
• 資源圖
• 燃盡圖(Burndown Chart)
• 燃起圖(Burnup Chart)

網絡圖

• 網絡圖是活動排序的一個輸出
• 展現項目中各個活動以及活動之間的邏輯關係

經常使用的網絡圖

PDM (Precedence Diagramming Method）

優先圖法 ,節點法 (單代號)網絡圖

ADM (Arrow Diagramming Method )

箭線法 (雙代號)網絡圖

PDM圖例

PDM(Precedence Diagramming Method)

• 構成PDM網絡圖的基本特色是節點(Box)
• 節點(Box)表示活動（任務）
• 用箭線表示各活動(任務)之間的邏輯關係.
• 能夠方便的表示活動之間的各類邏輯關係。

ADM圖例

ADM（ Arrow Diagramming Method ）

• ADM也稱爲雙代號項目網絡圖
• 在ADM網絡圖中,箭線表示活動(任務)
• 兩個代號惟一肯定一個任務
• 代號表示前一任務的結束,同時也表示後一任務的開始.

ADM圖例-虛活動

虛活動

• 爲了定義活動
• 爲了表示邏輯關係
• 不消耗資源的

歷時估算

估計任務、路徑、項目的持續時間

歷時估算的基本方法 - 傳統

• 定額估算法
• 經驗導出模型
• CPM(關鍵路徑法估計)
• PERT(工程評估評審技術)
• 預留分析
• 其餘
  • Jones的一階估算準則
  • 類比估算
  • 專家判斷
  • 基於承諾的估計

定額估算法

T=Q/(R*S)

T:活動歷時

Q:任務工做量

R:人力數量

S:工做效率（貢獻率）

e.g: Q=6人天 ,R=2人,S=1 則：T=3天

Q=6人天 ,R=2,S=0.5 則：T=6天

經驗導出模型

D:進度(以月單位)

E:工做量(以人月單位)

a:2—4之間

b:1/3左右:依賴於項目的天然屬性

建議掌握模型

Walston-Felix模型：

基本COCOMO:

關鍵路徑法估計

• 肯定項目網絡圖
• 每一個任務有單一的歷時估算
• 肯定網絡圖中任務的邏輯關係
• 關鍵路徑是網絡圖中最長的路徑
• 關鍵路徑能夠肯定項目完成時間

工程評估評審技術（PERT)

• (Program Evaluation and Review Technique)利用網絡順序圖邏輯關係
• 項目中某項單獨的活動，存在很大的不肯定性
• 加權算法估算任務歷時
• 利用網絡圖邏輯關係，肯定路徑、項目歷時

工程評估評審技術（PERT)-加權算法

• 選定3個估算值
  • O是最小估算值:樂觀(Optimistic)
  • P是最大估算值:悲觀(Pessimistic)
  • M是最大可能估算(Most Likely)
• 採用加權平均獲得指望值E=(O+4m+P)/6

PERT的風險指標

• 標準差δ =(最大估算值-最小估算值)/6
• 方差δ² = [(最大估算值-最小估算值)/6]²

PERT估算舉例

PERT估算評價舉例

預留分析

應急預留

應急預留是包含在進度基準中的一段儲備時間， 用來應對已經接受的已識別風險, 以應對進度方面的不肯定性 。

管理預留

管理預留是爲管理控制的目的而特別留出的項 目預算，用來應對項目範圍中不可預見的風險。

Jones的一階估算準則

• 估算項目功能點
• 從冪次表中選擇合適的冪次將功能點升冪

類比估算

以過去相似項目的實際持續時間爲依據，來估算當前項目的持續時間.

專家判斷

根據下面專業知識而作出的歷時估算

• 進度計劃
• 有關估算
• 學科或應用知識

基於承諾的進度估算

• 要求開發人員作出進度承諾
• 進行中間的工做量（規模）估計

優勢：有利於開發者對進度的關注

歷時估算的基本方法 - 敏捷

開發速度穩定前- 舉手表決

開發速度穩定後

• 基於故事點生產率的估算
• 基於迭代生產率的估算

傳統估算方法:

1. 定額估算法
2. 經驗導出模型
3. CPM(關鍵路徑法估計)
4. PERT(工程評估評審技術)
5. 基於承諾的進度估計
6. Jones的一階估算準則

敏捷估算方法:

1. 舉手表決
2. 基於故事點生產率的估算
3. 基於迭代生產率的估算

進度編制的基本方法

任務滯後(Lag)

任務超前(Lead)

做用：

1）解決任務的搭接

2）對任務能夠進行合理的拆分

3）縮短項目工期

關鍵路徑法

• 最先開始時間(Early start)
• 最晚開始時間(Late start)
• 最先完成時間(Early finish)
• 最晚完成時間(Late finish)
• 總浮動（ Total Float）
• 自由浮動（Free Float）

浮動時間(Float)：浮動時間是一個任務的機動性,它是一個任務在不影響其它任務或者項目完成的狀況下能夠延遲的時間量。

總浮動與自由浮動

總浮動（ Total Float）： 在不影響項目最先完成時間的前提下，一個任務能夠延遲的時間

自由浮動（Free Float）：在不影響後置任務最先開始時間的前提下，一個任務能夠延遲的時間

關鍵路徑（Critical Path ）

• 網絡圖中最長的路徑
• 關鍵路徑是決定項目完成的最短期。
• 時間浮動爲0（Float=0）的路徑
• 關鍵路徑上任何活動延遲，都會致使整個項目完成時間的延遲
• 關鍵路徑可能不止一條

時間壓縮法

時間壓縮法是在不改變項目範圍的前提下縮短項目工期的方法

應急法--趕工（Crash）

• 在最小相關成本增長的條件下，壓縮關鍵路經上的關鍵活動歷時的方法
• 趕工也稱爲時間-成本平衡方法

1. 進度壓縮單位成本方法線性關係

進度壓縮單位成本=（壓縮成本-正常成本）/(正常進度-壓縮進度)

2. Charles Symons(1991)方法進度壓縮比普通進度短的時候，費用迅速上漲

進度壓縮因子=壓縮進度/正常進度

壓縮進度的工做量=正常工做量/進度壓縮因子

平行做業法--快速跟進

改變活動間的邏輯關係，並行開展某些活動.

提早量方法

資源優化

• 根據資源供需狀況，調整活動的開始和完成日期。
• 資源優化配置，造成最有效的利用資源
  • 使資源閒置的時間最小化
  • 儘可能避免超出資源能力

資源平衡

• 爲了在資源需求與資源供給之間取得平衡，根據資源制約因素對開始日期和完成日期進行調整的一種技術。
• 經過調整任務的時間來協調資源的衝突
• 資源平衡每每致使關鍵路徑改變

資源平滑法

資源平滑法是在項目編排中進行資源的優化配置， 保證資源最優化、最優效 。

資源平滑不會改變項目關鍵路徑，完工日期也不會延遲。活動只在其自由和總浮動時間內延遲.

Agile Planning:敏捷計劃

Release planning - 發佈計劃 – 遠期計劃 – 粗計劃.

Iteration planning - 迭代計劃 – 近期計劃 – 細計劃

軟件項目進度問題(SPSP)模型

軟件項目進度問題（Software Project Scheduling Problem，SPSP）模型是在給定的項目任務工做量及其關係和資源限制下，對項目肯定合適的人員安排，以保證項目的時間最短、成本最小。

目標：時間最短、 成本最低

目標函數：

目標結果：f(x)達到最小

第九章 軟件項目配置管理計劃

軟件配置管理基本概念

配置管理定義

• 記錄軟件產品的演化過程
• 獲得精確的產品配置
• 最終保證軟件產品的完整性、一致性、追朔性、可控性

配置管理的主要功能

• 版本管理
• 變動管理

軟件配置項

SCI:software configration item

受控於軟件配置管理的款項

基線定義

• 基線提供了軟件生存期中各個開發階段的一個特定點, 標誌開發過程一個階段的結束,或者里程碑
• 一個(些)配置項造成並經過審覈，即造成基線
• 基線修改須要按照正式的程序執行

軟件配置控制委員會(SCCB)

• 評估變動
• 批准變動申請
• 在生存期內規範變動申請流程
• 對變動進行反饋
• 與項目管理層溝通

軟件配置管理過程

配置管理基本過程

1.配置項標識、跟蹤

將軟件項目中須要進行控制的部分拆分紅SCI

創建配置項的對應關係，以便於進行跟蹤和版本控制.實現數字化管理

2.配置管理環境創建

創建配置管理庫

軟件配置管理庫是用來存儲全部基線配置項及相關文件的等內容的系統，是在軟件產品的整個生存期中創建和維護軟件產品完整性的主要手段。

3.基線變動管理

基線修改應受到控制，這種變化要經SCCB受權，按程序進行控制並記錄基線修改的過程。

• 變動請求
• 變動評估
• 變動批准/拒絕
• 變動實現

4.配置管理審計

• 配置管理過程審計
• 基線審計

5.配置狀態統計

• 被批准的配置項
• 變動請求的數量
• 配置項的全部請求的變化狀態
• 配置項全部被批准的變動實現狀態
• 配置管理系統以及SCCB在運做中發生異常的次數等等

6.配置管理計劃

• 人員職責（肯定SCCB等）
• 配置項定義
• 基線定義
• 版本控制（說明配置管理工具）
• 定義變動控制系統

敏捷項目配置管理

• 敏捷的一個重要特徵是持續交付，所以，配置管理是重要的要素
• 敏捷須要全面配置管理

全面配置管理的基本要求

• 代碼和編譯構建產物的配置管理
• 應用的配置管理
• 環境的配置管理

代碼和編譯構建產物的配置管理

• 制定有效的分支管理策略
• 配置管理工具

制定有效的分支管理策略

• 基於分支的開發
• 基於主幹的開發

基於分支的開發

開發都在分支上提交，而且可能有多個並行分支，直到快要上線時甚至上線後才合併到主幹

基於主幹的開發

全部提交到主幹上，提交後自動觸發持續集成進行驗證和快速反饋

持續交付更傾向使用基於主幹的開發模式

第十章 軟件項目團隊計劃

人員職責計劃

組織結構的主要類型

1. 職能型

2. 項目型

3. 矩陣型

人員職責計劃

責任分配矩陣(RAM)

組織分解結構 (OBS)

其它,例如文本型

干係人管理計劃

干係人（Stakholder）

干係人（stakeholder）是能影響項目決策、活動或者結果的我的、羣體或者組織，以及會受到或者自認爲會受到項目決策、活動或者結果影響的我的、 羣體或者組織。

溝通計劃

項目溝通的方式

1. 書面溝通和口頭溝通

2. 語言溝通和非語言溝通

3. 正式溝通和非正式溝通

4. 單向溝通和雙向溝通

5. 網絡溝通

項目溝通活動的分類

• 內部與外部
• 正式和非正式
• 渠道（上級溝通,下級溝通,橫向溝通）
• 書面與口頭

項目溝通計劃

溝通計劃是肯定誰須要信息，須要什麼信息， 什麼時候須要信息，以及如何將信息分發給他們。

敏捷團隊規劃

敏捷的角色

產品負責人(Product owner )

團隊促進者(Team facilitator )

跨職能團隊成員(Crossfunctional team member )

Scrum 角色

Product Owner（產品負責人）

Scrum Master （ Scrum主管）

開發團隊

敏捷團隊

最有效的敏捷團隊每每由三到九個成員組成。(黃金人 數5-9人)

理想狀況下，敏捷團隊應該集中在一個工做場所工做。

團隊成員100%爲專職成員, 協同工做

敏捷鼓勵自我管理團隊

僕人式領導

僕人式領導是經過對團隊服務來領導團隊的

注重理解和關注團隊成員的須要和發展

僕人式領導爲團隊賦權

旨在使團隊儘量達到最高績效。

敏捷方法提倡高度透明

邀請全部相關方參與項目會議和審查

將項目信息發佈到公共空間

第十一章 軟件項目風險計劃

風險管理過程

風險定義

風險是對潛在的、將來可能發生損害的一種度量， 若是風險確實發生了，則會對項目產生有害的或者負面的影響。

軟件風險對軟件開發過程及軟件產品自己可能形成的傷害或損失

風險類型

預測角度

已知風險－Known known

可預測風險-Known unknown

不可預測風險-unknown unknown

範圍角度

商業風險、管理風險、人員風險、技術風險、開發環境風險、客戶風險、過程風險、產品規模風險等。

項目風險的三要素

風險事件

事件機率

事件影響

風險管理的四個過程

1)風險識別

風險識別是識別風險事件, 系統化地肯定對項目計劃的威脅，識別已知和可預測的風險。

2)風險評估

對風險事件發生機率的評估，對項目風險影響的評估，給出項目風險排序。

3)風險規劃

針對風險分析的結果，制定必定的行動和策略來對付、減小、以致於消滅風險事件形成的影響

4)風險控制

風險控制是在項目執行過程當中實施和監控風險計劃，同時，不斷進行風險識別、風險分析、風險規劃的過程。

風險管理計劃

風險識別方法

• 德爾菲方法
• 頭腦風暴法
• 情景分析法
• 利用風險條目檢查表

風險評估

分析

風險發生的機率（P）

風險對項目的影響（I）

風險值，R=F(P,I)

肯定優先次序

按風險值排序

肯定最須要關注的TOP風險

風險評估的方法-定性風險評估

定性評估風險機率及後果

風險機率

風險機率度量：

• 高、中、低
• 極高、高、中、低、極低
• 不可能，不必定，可能和很可能

風險影響

風險影響度量

• 高、中、低
• 極高、高、中、低、極低
• 災難，嚴重，輕微，可忽略

風險評估的方法-定量風險評估

1. 盈虧平衡分析

2. 敏感性分析

3. 模擬

4. 決策樹分析

決策樹分析

決策樹分析是一種圖表分析方法

提供項目全部可供選擇的行動方案，行動方案之間的關係，行動方案的後果以及發生的機率

提供選擇一個最佳的方案的依據

決策樹分析與EMV ( Expected Monetary Value)

EMV (損益指望值)是決策樹的一種計算值

根據預期結果、發生的機率計算出一種指望的損益

例如： 某行動方案成功的機率是50%，收益是10 。EMV=10*50%=5

風險規劃的主要策略

1. 迴避風險

2. 轉移風險

3. 損失控制

4. 自留風險

迴避風險

迴避風險是對可能發生的風險儘量的規避，採起主動放棄或者拒絕使用致使風險的方案

例如：放棄採用新技術

轉移風險

轉移風險是爲了不承擔風險損失，有意識將損失或與損失有關的財務後果轉嫁出去的方法。

例如：分包、開脫責任合同、保險

損失控制

損失預防

例如：項目技術培訓，預防技術失敗損失預防

損失抑制

例如：項目人員儲備，抑制人員流失的損失

自留風險

由項目組織本身承擔風險事故所致損失的措施。

敏捷項目風險計劃

敏捷項目風險應對方法

損失預防與損失抑制策略

跨職能項目團隊(識別風險)

選擇迭代內容 (選擇風險小的)

頻繁評審增量產品

持續測試能夠及早發現問題

客戶參與能夠減小需求變動的風險

敏捷項目存在風險

沒有長期計劃,識別一些風險比較困難.

沒有長期規劃，存在變動

第十四章 項目核心計劃執行控制

範圍管理 - 傳統與敏捷

範圍管理

範圍執行控制是監督項目的範圍狀態，管理範圍基準變動的過程。

分析技術

1. 誤差分析
2. 趨勢分析

範圍控制要點

防止不合理的範圍擴張

• 蔓延(Scope Creeping)
• 鍍金(Gold-plating)

敏捷項目範圍管理

把需求列入未完項

不斷構建和評審原形系統

經過發佈多個版原本明確需求

性能分析的主要技術

• 圖解控制法
• 掙值分析法
• 網絡圖分析
• 敏捷方法

圖解控制法

資源圖、進度圖、成本圖

1）項目甘特圖

2）延遲圖

3）時間線

4）費用曲線圖

5）資源圖誤差

誤差分析與控制

精確記錄任務消耗的實際時間

量化任務的計劃誤差

持續時間誤差 (%) =(( 實際持續時間 - 計劃持續時 間 )/ 計劃持續時間 )*100

進度誤差 (%)=(( 實際結束時間 - 計劃結束時間 )/ 計劃持續時間 )*100

對計劃誤差進行根因分析

掙值分析法

輸入

① BAC(Budget At Completion) 預算總值（估算結果）

② TAC(Time At Completion) 預計完成時間

③ BCWS(Budgeted cost of work scheduled) 計劃工做成本

④ ACWP(Actual cost of work performed) 實際工做成本

⑤ BCWP(Budgeted cost of work performed) 已獲值(Earned Value)

掙值分析輸出

進度差別:SV（Schedule Variance）=BCWP-BCWS

=0：按照計劃進度進行

<0：落後於進度

>0：超前於進度

成本差別:CV（Cost Variance )=BCWP-ACWP

=0：按照計劃預算進行

<0：比預算差

>0：比預算好

進度效能指標 SPI (Schedule Performance Index)= BCWP/BCWS

=1：按照計劃進度進行

>1：超前於進度

<1：落後於進度

成本效能指標 CPI (Cost Performance Index)= BCWP/ACWP

=1：按照計劃預算進行

>1：低於預算

<1：超出預算

EAC (Estimate At Completion)=BAC/CPI 預測項目完成成本

SAC(Schedule At Completion )=TAC/SPI 預測項目完成時間

成本誤差:VAC=BAC-EAC

時間誤差:VAT=SAC-TAC

未完工指數 TCPI=剩餘工做/剩餘成本 =(BAC-BCWP)/(Goal-ACWP)

網絡圖分析

分析網絡圖中某任務的進度成本狀況

能夠採用貝葉斯網絡解決項目中的不肯定性問題

敏捷方法