軟考：高級軟件架構師學習筆記——項目管理

學前說兩句

項目管理是非常重要的一個章節，你可以理解為整個項目管理貫穿于整個軟件開發的周期，無論是需求、設計、開發、測試等等，這個章節會有一些計算題，還會有關鍵路徑的計算，這是必須要掌握的。

盈虧平衡分析

盈虧平衡的時候，說明利潤為0

稅費=銷售額*稅率

固定成本：無論賣多少臺電腦，都要花費240w

可變成本和賣的設備數量有關系，賣2w臺設備會變為3000w的成本，那么一臺成本在1500塊

此時假設A臺會平衡

2500*A=2400000+1500*A+2500*A*0.16

A=4000

進度管理工作分解結構【WBS】

工作分解結構（Work Breakdown Structure，簡稱WBS）是項目管理中的核心工具，用于將項目整體目標分解為可管理、可交付的具體任務或工作包。

進度管理

WBS工作包確定好之后，就可以作為進度管理的輸入了

活動定義

就是在這個項目中應該開展的工作

活動排序

就是給工作定義依賴關系，比如先干什么后干什么，因為有些工作需要依賴其它的工作，必須要有先后順序

B和D依賴A，所以B需要在A完成之后，才能開始進行

活動資源估算

每項工作是多少人/日

活動歷時估算

可以估算出需要多少時間完成，比如評估10/人日，那么安排5個人來做，差不多就是2天了

制定進度計劃制定進度計劃（關鍵路徑法）

基于關鍵路徑法，可以將整個項目中的每一個節點計算出：最早開始時間、最早完成日期、最遲開始時間、最遲完成日期，然后再此基礎上計算出松弛時間，并且規劃出最長路徑。

關鍵路徑是最長路徑，最長路徑對應最短工期

A->H有多條路徑，怎樣才算把整個項目完成了呢，應該是A到H中的每個節點的任務都完成了。所以當你把最長的路徑的活干完了，那么就意味著，從A到H的所有節點都完成了，所以關鍵路徑是最長路徑，此時對應的是最短工期。并不是最短路徑，最短路徑意味著可能把一些節點給丟掉了

如何求解最長路徑？

笨方法：只需要把A到H的所有的路徑全部列出來，此時求最大的，就是真個項目的最長路徑

好方法：每個節點的總時差是LS-ES或者LF-EF，然后把總時差為0的節點連起來，就構成了關鍵路徑

關鍵路徑可能有多條，項目管理人員不希望有多條關鍵路徑，關鍵路徑的資源是必須要保證的

總時差越大說明寬松時間是比較高的，總時差越小說明時間越緊張

實例：

為了便于講解，我將一個節點的6個數字，分別表示為節點名+左上、節點名+上、節點名+右上、節點名+左下、節點名+下、節點名+右下，以A節點舉例：

A+左上 0

A+上 5

A+右上 5

A+左下 0

A+下 0

A+右下 5

關鍵計算路徑是這樣的：

第一步：構建初始的項目圖，只有每個項目節點的估算的工作量

第二步：從左到右，計算每個項目節點的最早開始時間和最早完成時間，也就是每個項目節點的左上和右上兩個節點的值

首先A作為起始點，那么A的最早開始時間肯定是0，那么A的最早結束時間是0+5=5

B和C依賴A：

先看B,A在5的時候開始完成，那么5就是B的最早開始時間，B的最早結束時間就是5+2=7

再看C,C在5的時候開始完成，那么5就是C的最早開始時間，C的最早結束時間就是5+8=13

E依賴C，那么E的最早開始時間就是13，E的最早結束時間就是18

D依賴B和C，那么C比B要完成的晚，所以D的最早開始時間只能是13，最早結束時間為23

F依賴D，那么F的最早開始時間為23，那么最早結束時間為23+10=33

G依賴D，那么D的最早開始時間為23，那么最早結束時間為23+15=38

H依賴F和G，那么H的最早開始時間為38，那么最早結束時間為38+10=48

此時就正向算完了，我們可以得到下面的圖：

第三步：

從右到左。

H的最早完成時間為48,那么H的最晚結束時間也要為48，此時H的最晚開始時間就是48-10=38

F和G依賴H，那么F和G的最晚結束時間為38，此時F的最晚開始時間為38-10=28，G的最晚開始時間為38-15=23

D依賴F和G，那么D的最晚結束時間為23（取F和G的最早開始時間中最小的），D的最晚開始時間為13

E依賴G，所以E的最晚結束時間為23，最晚開始時間為18

B依賴D,B的最晚結束時間為13，B的最晚開始時間為11
C依賴E和D，C的最晚結束時間為13，C的最晚開始時間為13-8=5

A依賴B和C，A的最晚結束時間為5，A的最晚開始時間為0

所以此時可以得到：

第四步：計算出松弛時間

第五步：得到關鍵路徑

關鍵路徑就是路徑上為松弛時間為0的節點的連接線，我們可以看到B的松弛時間為6，也就意味著B項目的人員摸魚6天都是可以的，不會影響到整個項目的推進。

這個項目最終的節點有E和F，由于E的最早完成時間為14大于F的最早完成時間，所E和F的最晚結束時間應該為14

首先我們必須可以得到的是，整個項目的網絡圖，那么關鍵路徑就很好算了，目前來看只有兩條路徑：

A-B 10天

A-C-D 12天

此時可以說明A-C-D就是關鍵路徑，此時的總花費為

12*5=60 （間接費用）

10+15+12+18=55 （A B C D 的總費用）

總共115

現在我們的思路很簡單，就是先想辦法改變關鍵路徑

首先可以修改D，將D的總時間從5天縮短為2天，此時A-C-D的總時長變為了9天

A-B 10天

A-C-D 9天

此時的關鍵路徑就是A-B了，此時的總花費為

10*5=50

10+15+12+18+2*3=61（A B C D 的總費用，包含D的加班費用）

此時總花費為111

現在要考慮A-B，假設改變B，將B的工時縮短兩天（不能再縮短了，縮短也沒有意義了，因為關鍵路徑變為A-C-D了），此時A-B為8，

A-B 8天

A-C-D 9天

此時，關鍵路徑變為了A-C-D 9天了，此時總花費為

9*5=45

10+15+12+18+2*3+2*2=65

此時總花費為110

現在考慮A-C-D，只能修改A和C，先來看C，如果將C縮短至2天，此時關鍵路徑為A-B，為8，

A-B 8天

A-C-D 7天

此時的費用為

8*5=40

10+15+12+18+2*3+2*2+2*4=71

總費用為111，不降反升，說明不能修改C

再來看A，A只要降低，會影響到所有，直接將A降低至1天，此時關鍵路徑A-C-D為7，

A-B 6天

A-C-D 7天

此時花費為

7*5=35

10+15+12+18+2*3+2*2+4*2=73

總費用為108

現在能降低的都已經降低了，現在看看能不嫩將A-B中的B升高掉，將B由降低兩天變為降低一天，這樣就可以再次減少2w的花費

A-B 7天

A-C-D 7天

7*5=35

10+15+12+18+2*3+2*2+4*2-2=71

總花費為106

一些項目節點關系的說明

F表示完成，S表示開始，FS表示完成開始，以此類推

FS：A完成B開始

FF：A完成B完成

SS：A開始B開始

SF：A開始B完成

以上表示活動和活動之間的關系

進度計劃的工作（甘特圖Gantt）

細線代表估計完成的時間安排

粗線代表目前的現狀

甘特圖的缺陷就是關鍵路徑法網絡圖的優點

進度控制

已經排了計劃，但是計劃執行過程中可能會存在一些問題，使得某些活動延誤了。

比如某個活動延誤了，我們需要確定它是不是關鍵活動，如果是關鍵活動，那么延誤了2天，就有可能造成整個項目延遲2天了。那么不是關鍵活動是不是就可以隨便延誤了，其實要看單個活動的松弛時間，以及整個項目的總時差，如果在這個允許的范圍內，那么不會對項目造成影響的。如果超過了，那么這個節點就會從非關鍵路徑的節點到關鍵路徑上的節點了，此時就不得不考慮它了

軟件質量影響軟件質量的3組因素

軟件質量控制與質量保證

質量保證是QA，指令控制是QC

質量保證是過程中管理

質量控制是結果的審核

軟件能力成熟度模型集成(CMMI）

隨便給一個特點，需要知道是哪個等級

軟件配置管理

軟件變更控制

軟件再變更過程中需要依據一定的流程和規則，不能隨便變更

軟件版本控制

1.1不能直接跳轉到1.5

1.1也不能直接跳轉到2.1，只能到2.0

軟件工具

思維導圖

### 項目管理 ├── 0? 軟件項目管理的主要管理要素 │ ├── 人員 │ ├── 產品 │ ├── 過程 │ └── 項目 ├── 1? 盈虧平衡分析（★） │ ├── 基本概念 │ │ ├── 正常情況下：銷售額 = 固定成本 + 可變成本 + 稅費 + 利潤 │ │ └── 盈虧平衡時：銷售額 = 固定成本 + 可變成本 + 稅費 │ ├── 關鍵術語 │ │ ├── 固定成本：不隨產量變化（如設備折舊、租金、管理人員的工資、辦公費、 固定資產折舊費 、員工培訓費） │ │ │ ├── 分類 │ │ │ │ ├── 酌量性固定成本 ：管理層的決策可以影響其數額（如廣告費、員工培訓費、技術開發經費） │ │ │ │ └── 約束性固定成本：管理層無法決定其數額，必須開支（如辦公場地及機器設備的折舊費、房屋及設備租金、管理人員的工資） │ │ ├── 可變成本：隨產量變化，與銷售額成比例。在一定時期和一定業務量范圍內其總額隨著業務量的變動而成正比例變動 │ │ │ ├── 示例： 直接材料費 、產品包裝費、外包費用、開發獎金 │ │ │ ├── 分類 │ │ │ │ ├── 酌量性變動成本 ：如開發獎金、外包費用 │ │ │ │ └── 約束性變動成本：通常表現為系統建設的直接物耗成本，以 直接材料成本 最為典型 │ │ └── 稅費：按銷售額的一定比例計算 │ ├── 示例 │ │ └── 某公司支出20萬元購買了某市場預測信息，由于此信息的采納，公司多得到了100萬元的利潤，對公司而言，這個市場預測信息的利潤是80萬元 │ └── 計算步驟（★★★） │ ├── 第一步：計算單件商品的可變成本 │ │ ├── 已知：總商品數、 總可變成本 │ │ └── 公式：單件可變成本 = 總可變成本 ÷ 總商品數 │ ├── 第二步：設定變量 │ │ └── 設盈虧平衡時的銷售數量為 x（臺/件） │ ├── 第三步：建立方程 │ │ ├── 銷售額 = 單價 × x │ │ ├── 可變成本總額 = 單件可變成本 × x │ │ ├── 稅費總額 = 單價 × x × 稅率 │ │ └── 方程：單價 × x = 固定成本 + (單件可變成本 × x) + (單價 × x × 稅率) │ └── 第四步： 解方程 求 x │ ├── 移項合并同類項 │ ├── 解得 x = 固定成本 ÷ [單價 × (1 ? 稅率) ? 單件可變成本] │ └── 注：注意單位統一（元/萬元） ├── 2? 進度管理（★★★）：對時間的管理 │ ├── 項目時間管理中的過程包括 │ │ ├── 活動定義：工作分解結構WBS │ │ │ └── WBS分解原則 │ │ │ ├── WBS的工作包應該是可控和可管理的，不能過于復雜 │ │ │ ├── 任務分解不能過細，一般原則是WBS的樹形結構不超過6層 │ │ │ ├── 每個工作包應該有一個交付成果，而不是多個 │ │ │ └── 每個任務必須有明確定義的完成標準 │ │ ├── 活動排序 │ │ ├── 活動資源估算 │ │ ├── 活動歷時估算 │ │ │ ├── 專家判斷法 │ │ │ ├── 三點估算法：（樂觀時間 + 悲觀時間 + 最可能時間 × 4）/ 6 │ │ │ ├── 功能點估算法 │ │ │ ├── 自上而下估算 │ │ │ └── 自下而上估算 │ │ ├── 制定進度計劃 │ │ │ ├── 判斷是否為關鍵活動 │ │ │ ├── 關鍵活動的核心特征是總時差為0且自由時差為0 │ │ │ ├── 偏差是否大于總時差 │ │ │ └── 偏差是否大于自由時差 │ │ └── 進度控制 │ │ ├── 趕工：增加資源壓縮工期 │ │ └── 快速跟進：活動并行執行 │ │ │ └── 進度管理工具【制定進度計劃、進度控制】 │ ├── 關鍵路徑法 │ │ ├── 定義：不考慮資源限制，計算最早/最晚時間 │ │ ├── 最早開始時間（ES） │ │ ├── 最早完成時間（EF） │ │ ├── 最遲開始時間（LS） │ │ ├── 最遲完成時間（LF） │ │ └── 總時差（松弛時間） │ │ ├── 公式：LS ? ES 或 LF ? EF │ │ └── 意義：活動可延遲時間，不影響總工期 │ └── 甘特圖（Gantt） │ ├── 特點：能清晰描述每個任務的開始和截止時間，能有效獲得 任務并行 進行的信息 │ ├── 優點：直觀、簡單、易制作、便于理解 │ ├── 適用：小型項目、WBS任意層次、進度控制、資源優化 │ └── 缺點：不能表示各任務之間的依賴關系 ├── 3? 軟件 質量管理 （★★） │ ├── 影響軟件質量的三大因素 │ │ ├── 產品運行 │ │ │ ├── 正確性：是否按需求工作 │ │ │ ├── 健壯性：對意外環境的響應 │ │ │ ├── 效率：資源消耗情況 │ │ │ ├── 完整性：安全性 │ │ │ ├── 可用性：是否易用 │ │ │ └── 風險：是否按計劃完成 │ │ ├── 產品修改 │ │ │ ├── 可理解性：是否易于理解 │ │ │ ├── 可維修性：是否易于修復 │ │ │ ├── 靈活性：是否易于變更 │ │ │ └── 可測試性：是否易于測試 │ │ └── 產品轉移 │ │ ├── 可移植性：是否可在其他環境運行 │ │ ├── 可再用性：是否可復用部分組件 │ │ └── 互運行性：是否可與其他系統集成 │ │ │ ├── 軟件質量控制 │ │ ├── 定義： 實時監控 ，判斷是否符合軟件質量標準 │ │ ├── 目的：制定有效方案，消除質量產生的原因 │ │ └── 特點：實時性、監控性、糾偏性 │ ├── 軟件質量保證 │ │ ├── 定義：周期性執行的質量管理活動 │ │ ├── 特點：事前預防，不讓缺陷擴散到下一階段 │ │ ├── 作用：作用于過程，貫穿于活動之中 │ │ └── 主要活動 │ │ ├── 質量審計（代碼評審） │ │ └── 過程分析 │ │ │ ├── 軟件能力成熟度模型集成（CMMI） │ │ ├── 成熟度等級（階段式） │ │ │ ├── 初始級（L1）：隨意、混亂、依賴個人能力 │ │ │ ├── 已管理級（L2）：項目級可重復，建立項目級控制過程 │ │ │ ├── 已定義級（L3）：組織級文檔化、標準化，到公司層面了 │ │ │ ├── 定量管理級（L4）：量化式管理，過程性能可預測 │ │ │ └── 優化級（L5）：持續優化 │ │ ├── 文件體系 │ │ │ ├── 方針文件：過程文件及其他相關文件都應遵循方針文件 │ │ │ ├── 過程文件：根據過程文件模板編制各 PA 過程文件，并對流程進行描述 │ │ │ ├── 指南/規范文件：結合相應模板清晰說明如何完成這項工作，并標明對應的標準和需求 │ │ │ └── 模板文件：模板分為兩類，一類是 word 文檔模板，一類是 excel 表格模板 │ │ └── 注：連續式與階段式本質一致 │ │ │ ├── 數據管理能力成熟度模型 （DCMM） │ │ ├── 核心能力域（8個） │ │ │ ├── 數據戰略 │ │ │ ├── 數據治理 │ │ │ ├── 數據架構 │ │ │ ├── 數據應用 │ │ │ ├── 數據安全 │ │ │ ├── 數據質量 │ │ │ ├── 數據標準 │ │ │ └── 數據生存 周期 │ │ ├── 成熟度等級（5級） │ │ │ ├── L1 初始級：數據 需求管理 是項目級體現；無統一流程；被動式管理 │ │ │ ├── L2 受管理級：組織意識到數據是資產；按策略制定流程；指定人員初步管理 │ │ │ ├── L3 穩健級：數據是 績效目標 資產；組織層面建立標準化流程，促進規范化管理 │ │ │ ├── L4 量化管理級：數據是 競爭優勢 資源；效率可 量化分析 和監控 │ │ │ └── L5 優化級：數據是組織生存發展的基礎；管理流程可實時優化；行業最佳實踐分享 │ │ ├── 核心價值點 │ │ │ ├── 數據地位升級：從“項目附屬品” → “戰略資產” → “競爭優勢源泉” │ │ │ ├── 管理方式進化：從“被動/零散” → “主動/規范” → “量化/智能優化” │ │ │ └── 組織影響深化：從“局部執行” → “部門協同” → “全組織標準化” → “行業標桿” │ │ ├── 適用對象與用途 │ │ │ ├── 適用于企業、政府機構等組織進行數據管理能力自評或第三方評估 │ │ │ ├── 用于指導數據治理體系建設、數字化轉型路徑規劃 │ │ │ └── 是衡量數據驅動型組織成熟度的重要標尺 │ │ └── 總結：DCMM 提供了一個從 L1 到 L5 的五級成熟度模型，幫助組織系統評估并提升其在數據戰略、治理、架構、應用、安全、質量、標準及生命周期等方面的綜合管理能力，最終實現數據驅動的價值最大化 │ │ │ └── 數據安全治理體系 │ ├── 三大目標（前提） │ │ ├── 滿足合規要求 │ │ ├── 管理數據 安全風險 │ │ └── 促進 數據開發 利用 │ ├── 目標雙重性：既保障安全，又推動業務發展 │ ├── 能力框架（三個維度） │ │ ├── 評估維度（左側）——“從哪方面看能力？” │ │ │ ├── 組織架構 │ │ │ ├── 制度流程 │ │ │ ├── 技術工具 │ │ │ └── 人員能力 │ │ ├── 評估框架（中間 金字塔結構 ）——“能力如何分層構建？” │ │ │ ├── 頂層：數據安全戰略 │ │ │ │ ├── 數據安全規劃 │ │ │ │ └── 機構人員管理 │ │ │ ├── 中層：數據全生命周期安全 │ │ │ │ ├── 數據采集 │ │ │ │ ├── 數據傳輸 │ │ │ │ ├── 數據存儲 │ │ │ │ ├── 數據使用 │ │ │ │ ├── 數據共享 │ │ │ │ └── 數據銷毀 │ │ │ └── 底層：基礎安全 │ │ │ ├── 數據分類 分級 │ │ │ ├── 合規管理 │ │ │ ├── 合作方管理 │ │ │ ├── 監控審計 │ │ │ ├── 身份認證及 訪問控制 │ │ │ ├── 安全風險分析 │ │ │ └── 安全事件應急 │ │ └── 評估等級（右側）——“能力達到什么水平？” │ │ ├── 初始級 │ │ ├── 重點執行級 │ │ ├── 全面治理級 │ │ ├── 量化評估級 │ │ └── 持續優化級 ├── 4? 軟件配置管理（SCM）（★★） │ ├── 配置管理定義：配置管理是PMBOK?、ISO9000和CMMI中的重要組成元素，它在產品開發的生命周期中，提供了結構化的、有序化的、產品化的管理方法，是項目管理的基礎工作。配置管理是通過技術和 行政手段 對產品及其開發過程和生命周期進行控制、規范的一系列措施和過程。 信息系統 開發過程中的變更以及相應的返工會對產品的質量有很大的影響。 │ ├── 基本概念 │ │ ├── 產品配置：一個產品在其生命周期各個階段所產生的各種形式（機器可讀或人工可讀）和各種版本的文檔、計算機程序、部件及數據的集合。該集合中的每一個元素稱為該產品配置中的一個配置項（Configuration Item，CI）。配置項主要有兩大類： │ │ │ ├── 屬于產品組成部分的工作成果，如需求文檔、設計文檔、 源代碼 、測試用例等 │ │ │ └── 屬于項目管理和機構支撐過程域產生的文檔，如工作計劃、項目質量報告、項目跟蹤報告等。這些文檔雖然不是產品的組成部分，但是值得保存。 │ │ └── 配置項 │ │ ├── 定義：軟件生存周期各個階段活動的產物經審批后即可稱之為軟件配置項 │ │ ├── 基線配置項：需求文檔、設計文檔、源代碼、可執行代碼、測試用例、運行數據 │ │ └── 非基線配置項：各類計劃（項目管理計劃、進度管理計劃）、各類報告 │ ├── 配置項的狀態 │ │ ├── 草稿 │ │ ├── 正式發布 │ │ └── 正在修改 │ ├── 核心內容 │ │ ├── 版本控制 │ │ └── 變更控制 │ ├── 配置庫的類型 │ │ ├── 受控庫：也稱為主庫或系統庫，用于管理當前基線和控制對基線的變更。不允許自由修改，需要適當的權限授權 │ │ ├── 動態庫 ：也稱為開發庫、程序員庫或工作庫，用于保存開發人員當前正在開發的配置實體。允許開發人員自由修改 │ │ └── 靜態庫 ：也稱為軟件倉庫或 軟件產品 庫，用于存檔各種廣泛使用的已發布的基線。不允許修改 │ ├── 版本控制規則 │ │ ├── 版本狀態與編號規則 │ │ │ ├── 草稿狀態：0.YZ（YZ：01~99，遞增） │ │ │ │ └── 示例：版本號從0.01變為0.05，符合草稿狀態的版本號規則 │ │ │ ├── 正式狀態：X.Y（首次發布：1.0） │ │ │ │ ├── 小改動：Y 值增加 │ │ │ │ └── 大改動：X 值增加 │ │ │ └── 修改狀態：X.YZ（Z 值增加，X.Y 不變） │ │ └── 版本狀態流轉 │ │ ├── 草稿 → 正式 │ │ └── 正式 → 修改 → 正式 │ ├── 版本控制流程 │ │ ├── ② 創建配置項 │ │ ├── ④ 對工作狀態的配置項進行修改 │ │ ├── ⑤ 提交評審或審批 │ │ ├── ① 通過后正式發布 │ │ └── ③ 因變更更新版本號 │ └── 包括配置管理的體系 │ ├── ISO9000：包括配置管理。ISO9000 是一個質量管理標準系列，其中包括對配置管理的要求，如在軟件開發中管理質量相關的文檔和配置項。 │ ├── PMBOK：包括配置管理。PMBOK 是項目管理的 知識體系 ，其中包含配置管理相關內容，例如配置變更控制過程。 │ └── CMMI：包括配置管理。CMMI 涵蓋了 軟件工程 的多個方面，其中專門有一部分內容（配置管理過程域）用于指導配置管理的實施。 ├── 5? 軟件工具分類 │ └── 按軟件過程活動分類 │ ├── 軟件開發工具 │ │ ├── 需求分析 工具 │ │ ├── 設計工具 │ │ └── 編碼與排錯工具 │ ├── 軟件維護工具 │ │ ├── 版本控制工具（VSS、CVS、SCCS、SVN） │ │ │ └── 描述：版本控制就是用來管理多個版本變遷的工具 │ │ ├── 文檔分析工具 │ │ ├── 開發信息庫工具 │ │ ├── 逆向工具 │ │ └── 再工程工具 │ └── 軟件管理和軟件支持工具 │ ├── 項目管理工具 │ ├── 配置管理工具 │ │ ├── 常見功能：版本控制、 變更管理 、配置狀態管理、訪問控制和 安全控制 │ │ └── 說明：配置管理工具包含了版本控制工具 │ └── 軟件評價工具 ├── 6? 范圍管理 │ ├── 產品范圍：信息系統產品或者服務所應該包含的功能 │ ├── 項目范圍：為了能夠交付 信息系統項目 所必須做的工作 │ ├── 關系：產品范圍是項目范圍的基礎 │ ├── 產品范圍定義：信息系統要求的度量 │ ├── 項目范圍定義：生產項目計劃的基礎 │ ├── 產品范圍描述：是 項目范圍說明書 的重要組成部分 │ └── 項目范圍定義的輸入 │ ├── 范圍管理計劃：范圍管理計劃是項目管理計劃的組成部分，確定了制定、監督和控制項目范圍的各種活動。 │ ├── 項目章程：項目章程中包含對項目和產品特征的概括性描述，以及項目審批要求。如果執行組織不使用項目章程，則應取得或編制類似的信息，并用作制定詳細范圍說明書的基礎。 │ ├── 需求文件：使用需求文件來選擇哪些需求將包含在項目中。 │ ├── 批準的變更申請 │ └── 組織過程資產：可能影響定義范圍過程的組織過程資產包括（但不限于）： │ ├── 1、用于制定項目范圍說明書的政策、程序和模板 │ ├── 2、以往項目的項目檔案 │ └── 3、以往階段或項目的經驗教訓 ├── 7? 風險管理 │ ├── 項目風險定義：一種不確定的事件或條件，可能對項目目標產生正面或負面影響 │ └── 軟件風險分類 │ ├── 項目風險 │ ├── 技術風險 │ └── 商業風險 │ └── 主要包括5個方面 │ ├── 開發了一個沒有人真正使用的優良產品或系統 │ ├── 開發的產品不符合公司的整體策略 │ ├── 開發了一個銷售部不知如何銷售的軟件 │ ├── 失去了高層管理人員的支持 │ └── 沒有得到預算或人員的保證 ├── 8? 軟件文檔管理 │ ├── 軟件系統的文檔可以分為用戶文檔和系統文檔兩類 │ │ ├── 用戶文檔：主要描述系統功能和使用方法，并不關心這些功能是怎樣實現的 │ │ └── 系統文檔：描述 系統設計 、實現和測試等各方面的內容 │ ├── 用戶文檔 │ │ ├── 用戶文檔是用戶了解系統的第一步，它可以讓用戶獲得對系統的準確的初步印象 │ │ └── 用戶文檔至少應該包括下述5方面的內容 │ │ ├── （1）功能描述：說明系統能做什么 │ │ ├── （2）安裝文檔：說明怎樣安裝這個系統以及怎樣使系統適應特定的 硬件配置 │ │ ├── （3）使用手冊：簡要說明如何著手使用這個系統（通過豐富的例子說明怎樣使用常用的系統功能，并說明用戶操作錯誤時怎樣恢復和重新啟動） │ │ ├── （4）參考手冊：詳盡描述用戶可以使用的所有系統設施以及它們的使用方法，并解釋系統可能產生的各種出錯信息的含義（對參考手冊最主要的要求是完整，因此通常使用形式化的描述技術） │ │ └── （5）操作員指南（如果需要有 系統操作員 的話）：說明操作員應如何處理使用中出現的各種情況 │ └── 系統文檔 │ └── 所謂系統文檔指從問題定義、需求說明到 驗收測試 計劃這樣一系列和系統實現有關的文檔。描述系統設計、實現和測試的文檔對于理解程序和維護程序來說是非常重要的。 └── 9? 成本管理 └── 成本預算：在項目的成本管理中，成本預算是將總的 成本估算 分配到各項活動和工作包上的過程，以此來建立一個成本的基線。成本預算是成本管理的一個關鍵步驟，它涉及將項目的總體成本估算細分為各個工作包或活動的成本估算，為項目的成本控制提供了基準。