第一章 軟體專案管理基本概念
專案定義
專案(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. 在專案早期,需求不穩定、設計不成熟、實作不確定的 情況下很難準確地估算代碼量.
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),對各個具體作業包進行詳細的成本估算,然后將結果累加起來得出專案總成本，
特點
- 相對比較準確，它的準確度來源于每個任務的估算情況
- 花費時間
三點估演算法
基于任務成本的三種估算值來計算預期成本的方法.
三種估算值
最可能成本（CM）:比較現實的估算成本，
最樂觀成本（CO）:最好情況所得到的估算成本，
最悲觀成本（CP）:最差情況所得到的估算成本，
引數估演算法
- 通過專案資料,進行回歸分析,得出回歸模型
- 通過引數模型估算(規模)成本的方法，
引數模型綜述
- 根據專案資料進行回歸分析，得出回歸模型作為引數模型，
- 回歸分析方法：線性回歸，多項式回歸，邏輯回歸，神經網路，集成方法等，
- 引數模型可以是線性也可以是非線性的，
使用條件
- 具有良好的專案資料為基礎
- 存在成熟的專案估算模型
特點
- 比較簡單,而且也比較準確
- 如果模型選擇不當或者資料不準, 也會導致偏差
專家估演算法
由多位專家進行成本估算，一個專家可能會有偏見，最好由多位專家進行估算，取得多個估算值, 最后得出綜合的估算值，
專家估演算法-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. 給任務分配固定成本
分配固定資源成本
當一個專案的資源需要固定數量的資金時，可以向任務分配固定資源成本，
第七章 軟體專案進度計劃
進度計劃的重要性
- 按時完成專案是專案經理最大的挑戰之一
- 時間是專案規劃中靈活性最小的因素
- 進度問題是專案沖突的主要原因
進度的定義
進度是對執行的活動和里程碑制定的作業計劃日期表
任務定義（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的一階估算準則
- 估算專案功能點
- 從冪次表中選擇合適的冪次將功能點升冪
類比估算
以過去類似專案的實際持續時間為依據，來估算當前專案的持續時間.
專家判斷
根據下面專業知識而做出的歷時估算
- 進度計劃
- 有關估算
- 學科或應用知識
基于承諾的進度估算
- 要求開發人員做出進度承諾
- 進行中間的作業量（規模）估計
優點：有利于開發者對進度的關注
歷時估算的基本方法 - 敏捷
開發速度穩定前- 舉手表決
開發速度穩定后
- 基于故事點生產率的估算
- 基于迭代生產率的估算
傳統估算方法:
- 定額估演算法
- 經驗匯出模型
- CPM(關鍵路徑法估計)
- PERT(工程評估評審技術)
- 基于承諾的進度估計
- Jones的一階估算準則
敏捷估算方法:
- 舉手表決
- 基于故事點生產率的估算
- 基于迭代生產率的估算
進度編制的基本方法
任務滯后(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. 自留風險
回避風險
回避風險是對可能發生的風險盡可能的規避，采取主動放棄或者拒絕使用導致風險的方案
例如：放棄采用新技術
轉移風險
轉移風險是為了避免承擔風險損失，有意識將損失或與損失有關的財務后果轉嫁出去的方法，
例如：分包、開脫責任合同、保險
損失控制
損失預防
例如：專案技術培訓，預防技術失敗損失預防
損失抑制
例如：專案人員儲備，抑制人員流失的損失
自留風險
由專案組織自己承擔風險事故所致損失的措施，
敏捷專案風險計劃
敏捷專案風險應對方法
損失預防與損失抑制策略
跨職能專案團隊(識別風險)
選擇迭代內容 (選擇風險小的)
頻繁評審增量產品
持續測驗可以及早發現問題
客戶參與可以減少需求變更的風險
敏捷專案存在風險
沒有長期計劃,識別一些風險比較困難.
沒有長期規劃，存在變更
第十四章 專案核心計劃執行控制
范圍管理 - 傳統與敏捷
范圍管理
范圍執行控制是監督專案的范圍狀態，管理范圍基準變更的程序，
分析技術
- 偏差分析
- 趨勢分析
范圍控制要點
防止不合理的范圍擴張
- 蔓延(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)
網路圖分析
分析網路圖中某任務的進度成本情況
可以采用貝葉斯網路解決專案中的不確定性問題
敏捷方法
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/978.html
標籤：其他
上一篇：研發效能度量案例