軟件項目管理的重點知識

1.軟件項目管理概述

1.1項目是什么

項目是為了創造一個唯一的產品或提供一個唯一的服務而進行的臨時性的努力。

1.2常見的項目

生活中的項目

• 生日聚會
• 野餐活動
• 集體婚禮

大項目

• 微軟的操作系統
• 阿波羅計劃
• 神州飛船計劃
• 鴻蒙操作系統
• 開發一個網站
• 運動會

1.3軟件項目的特征

• 復雜性
• 一致性
• 可變性
• 不可見性

1.4軟件項目的三層制約

• 質量
• 進度
• 成本
• 范圍(四重就加上)

1.5項目失敗的原因

• 需求獲取不充分
• 失敗的管理
• 失敗的溝通

1.6軟件項目管理的引入

1.為什么那么多的信息化項目都失敗了？

• 需求經常變動【項目范圍管理】

2.為什么有那么多的豆腐渣工程?

• 獻禮工程【項目進度管理】
• 偷工減料【項目成本管理】
• 層層轉包【項目采購管理】

3.為什么房地產公司注冊資金那么少，而承擔的項目如此之大？——巨人

• 【項目融資管理】

4.為什么房地產剎車失靈？為什么銀行的貸款收不回來？

• 【項目風險管理】

5.為什么很多工程人員流動非常之大，工期一拖再拖？為什么民工會走向極端？

• 【項目人力資源與溝通】

1.7項目管理的知識體系

項目管理領域，目前有兩個廣為流行的知識體系：

最重要的是第一個，項目管理的知識體系

• 項目管理知識體系（Project Management Body of Knowledge，PMBOK）是美國項目管理協會（Project Management Institute, PMI）開發的，目前最新的版本是PMBOK第五版（PMBOK 2012）。
• 受控環境下的項目管理（Projects In Controlled Environments，PRINCE）是英國政府商務辦公室（Office of Government Commerce,OGC）開發的，PRINCE2是1996年推出的第2版。

1.8PMBOX（軟件項目管理知識體系）的十大過程組

1.項目集成管理（Project Integration Management）

2.項目范圍管理（Project Scope Management）

3.項目進度管理（Project Time Management）

4.項目成本管理（Project Cost Management）

5.項目質量管理（Project Quality Management）

6.項目人力資源管理（Project Human Resource Management）

7.項目溝通管理（Project Communication Management）

8.項目風險管理（Project Risk Management）

9.項目采購管理（Project Procurement Management）

10.項目干系人管理

1.9PMBOX（軟件項目管理知識體系）的5個過程組

PMBOK五大過程組是：啟動過程組、規劃過程組、執行過程組、監控過程組、收尾過程組。

1、啟動過程組：作用是設定項目目標，讓項目團隊有事可做；

2、規劃過程組：作用是制定工作路線，讓項目團隊“有法可依”；

3、執行過程組：作用是“按圖索驥”，讓項目團隊“有法必依”；

4、監控過程組：作用是測量項目績效，讓項目團隊“違法必究”，并且盡量做到“防患于未然”；

5、收尾過程組：作用是了結項目（階段）“恩怨”，讓一切圓滿。

1.10項目管理的工具

1.項目業務分析 （業務模型 、需求、設計） EA Visio 2.原型界面和流程設計 Axure RP 3.數據庫設計 ERStudio 4.配置管理 SVN Gitee Git 5.進度計劃 Project 6.項目開發過程管理（項目需求、進度任務、缺陷管理） 禪道 7.項目經營管理：資金、合同、風險、成本管理。 自行開發

2.軟件項目管理工具綜述

2.1 系統建模工具

EA 可以用來設計用例和領域模型、類圖、流程圖。

2.2 原型設計工具

Axure畫出功能頁面

2.3 數據庫設計工具

ERStudio 或者是 Navicat

2.4配置管理工具

SVN/GitHub/Gitee/GitLab

2.5知識庫管理工具

• 項目管理 Project/Zentao禪道
• 知識庫管理 語雀/騰訊在線文檔
• 文檔管理 word/ppt/excel/viso

3.軟件項目的范圍管理

前言

1.項目是啥：西游記，最成功的項目

2.干什么：【你所認為的需求】

3.誰來干：自組織團隊的組建（項目需要一個優秀的團隊）

4.怎么干：指路明燈：項目過程標準：CMMI的講解，以吃飯為例子，串起CMMI，PMBOK，ISO9000等

3.1 軟件項目的范圍管理+WBS

1.概念：項目范圍管理包含一系列子過程，用以確保項目包含且只包含達到項目成功所必需完成的工作。

概念解釋：

• 范圍管理主要關注項目內容的定義和控制，即包括什么、不包括什么。

2.范圍管理常用的方法是：WBS(工作分解結構)

3.2 軟件需求的定義

主要介紹了需求工程的內容

3.2.1需求工程含義

1.需求工程：是一門學科，專門用于需求的。

3.2.2需求工程內容

1.需求工程內容：包括需求開發和需求管理。

需求開發：

• 需求獲取

• 需求分析
• 需求定義（規格說明）
• 需求驗證

需求管理：

• 需求跟蹤
• 變更管理
• 實現

3.2.3需求的含義

軟件需求并不是要解決軟件系統“如何做”的問題，它的根本任務在于解決目標系統“做什么”的問題。

功能需求是干什么，完成什么樣的操作

性能需求是產品并發數，響應時間等等

1.需求的含義：需求是指用戶對軟件的功能和性能的要求。

• 功能需求是指將用戶需求歸類分解為計算機可以實現的子系統和功能模塊，用設計語言描述和解釋用戶的需求，以達到可以指導程序設計的目的。
• 性能需求是指從多角度對產品的特點進行描述，如系統響應時間，系統能夠同時容納的人數等。

3.2.4開發者對待需求工程的態度

領先型，是需求工程的最高境界。開發者發掘了連用戶自己都沒有意識到的需求，導致用戶跟著新產品跑而不是新產品圍著用戶轉，這叫引導消費。

需求工程做到這個程度上，才能使產品立于不敗之地，長盛不衰。

• 被動型
• 主動型
• 領先型

3.2.5需求類型

1.需求類型：業務需求、用戶需求和功能需求。

• 業務需求：表示組織或客戶高層次的目標。為什么要開發出一個系統，組織希望達到的目標。是一種愿景。
• 用戶需求：用戶要求系統必須能完成的任務。用例、場景描述和事件-響應表都是表達用戶需求的有效途徑。用戶需求描述了用戶能使用系統來做些什么。

• 功能需求：功能需求描述是開發人員需要實現什么。

3.3 軟件需求管理

3.3.1需求開發過程中的四個主要活動

1.需求開發中的四個主要活動

• 需求獲取
• 需求分析
• 需求定義（規格說明）
• 需求驗證

3.3.2需求管理的過程

• 需求確認：需求獲取，需求分析，需求定義（產品規格說明書），需求驗證
• 需求變更：需要變更控制
• 需求跟蹤

3.3.3需求分析說明書和需求規格說明書

https://www.jianshu.com/p/26645058db08

• 需求分析說明書：業務人員和用戶。類似調研報告。

• 需求規格說明書：設計和開發人員。從業務規則說起，偏向的是概要設計。

3.3.4需求獲取方法

• 訪談和調研

• 專題討論會

• 頭腦風暴：也叫做智力激勵法，自由思考法

• 場景串聯

  • 靜態場景串聯：草圖，屏幕快照和ppt演示
  • 動態場景串聯：動畫
  • 交互場景串聯：模擬完成的系統，系統的原型

3.3.5需求分析

1.概念：是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什么數據，要得到什么結果，最后應輸出什么。

解釋：

• 需求分析是做系統之前必做的。

3.3.6需求驗證（評審）

不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以，需求驗證（需求評審）工作必不可少。

3.4 需求變更管理

3.4.1需求變更的原因

• 單純的用戶因素：用戶不斷加深對系統的了解
• 系統因素：如操作系統升級
• 工作環境因素：如工作制度或法規、政策的變更、業務要求變更等
• 需求開發工作缺陷：需求
• 調研、分析、定義、評審工作不夠充分

3.4.2需求變更的影響

• 增加項目的人員、費用開支，影響開發進度
• 影響軟件質量
• 影響開發者與用戶之間的合作關系

3.4.3需求變更的處理原則

• 1、完整性原則 完整的需求變理機制包括需求變更的收集、整理、評審、實施、跟蹤、測試等。 在每一環節上，都必須形成規范的流程、文檔和完整的記錄。
• 2、合理性原則 不能片面地追求先進性、靈活性、用戶體驗，必須建立在IT技術和項目實施隊伍實際能力的基礎上，提出合理的需求變更。 避免抵觸情緒，多從用戶角度出發，想用戶所想

3.4.4需求變更的管理流程

1、提出變更申請

2、審批

3、修改需求文檔

4、重新進行需求確認

5、變更結束

3.5 任務分解-WBS

3.5.1WBS（任務分解結構）

1.簡介：

• 以可交付成果為導向對項目要素進行的分組，它歸納和定義了項目的整個工作范圍每下降一層代表對項目工作的更詳細定義。
• 創建WBS是把項目工作按階段可交付成果分解成較小的，更易于管理的組成部分的過程。

2.WBS的組成部分

• 結構化編碼
• 工作包

3.5.2結構化編碼

編碼是最顯著和最關鍵的WBS構成因子，首先編碼用于將WBS徹底的結構化。 通過編碼體系，我們可以很容易識別WBS元素的層級關系、分組類別和特性。

3.5.3工作包

工作包（work package）是WBS的最底層元素，一般的工作包是最小的“可交付成果”，這些可交付成果很容易識別出完成它的活動、成本和組織以及資源信息。

3.5.4WBS詞典概念

WBS詞典是在創建工作分解結構的過程中編制的，是工作分解結構的支持性文件，用來對工作分解結構中的控制賬戶和工作包做詳細解釋。

解釋的詳細程度可以根據具體需要加以確定。

控制賬戶是工作分解結構中的要素，是項目經理對項目的管理控制點，即針對控制賬戶的要素對項目的執行情況進行檢查與考核。可以把工作包作為控制賬戶，也可以把更高層的要素作為控制賬戶。

3.5.5WBS詞典的屬性

WBS詞典：包括編碼、工作包描述(內容)、成本預算、時間安排、質量標準或要求、責任人或部門或外部單位(委托項目)、資源配置情況、其他屬性等。

3.5.6WBS的主要用途

項目WBS的主要用途：

1.明確并準確說明項目的范圍

2.為各獨立單元分配人員，進行責任的劃分和指派

3.對各單元進行時間、費用和資源需要量的估算

4.為計劃、預算、進度安排和費用控制奠定基礎

5.將項目工作與項目的財務和會計賬目建立聯系

6.確定工作內容和工作順序

3.5.7任務分解的基本步驟

任務分解的基本步驟：

1.確認并分解項目的組成要素（WBS編號）

2.確定分解標準

3.確定分解是否詳細

4.確定項目交付成果（可以編制WBS字典）

5.驗證分解的正確性

3.5.8工作分解結構應把握的原則

工作結構分解應把握的原則：

?在各層次上保持項目的完整性，避免遺漏必要的組成部分。

?一個工作單元只能從屬于某個上層單元，避免交叉從屬。

?相同層次的工作單元應用相同性質。

?工作單元應能分開不同的責任者和不同工作內容。

?便于項目管理計劃、控制的管理需要。

?最底層工作應該具有可比性，是可管理的，可定量檢查的。

?應包括項目管理工作（因為是項目具體工作的一部分），包括分包出去的工作。

4.軟件項目的成本管理

4.1項目成本管理

4.1.1項目成本管理

1.項目成本管理包括為使項目在批準的預算內完成而對成本進行規劃、估算、預算、融資、籌資、管理和控制的各個過程，從而確保項目在批準的預算內完工。項目成本管理過程包括:

• 規劃成本管理―確定如何估算、預算、管理、監督和控制項目成本的過程。
• 估算成本―對完成項目活動所需貨幣資源進行近似估算的過程。
• 制定預算―匯總所有單個活動或工作包的估算成本，建立一個經批準的成本基準的過程。
• 控制成本―監督項目狀態，以更新項目成本和管理成本基準變更的過程。

4.1.2一個重要的流程

規模估算->工作量估算->開發工期估算->成本估算

4.2規模估算

4.2.1衡量軟件的單位

?源代碼行數（Line of Code，LOC）

?功能點數（Function Point，FP）

4.2.2規模估算–德爾菲（Delphi）方法

1.協調員給每位專家一份規格說明書和一張記錄估計值的表格。

2.協調員召集小組會議，專家與協調員以及專家之間對估計問題進行討論。

3.專家無記名地填寫表格。

4.協調員對專家填寫在表上的估計結果進行小結。

5.協調員召集小組會議，讓專家對差異很大的估計項進行討論。

6.專家重新無記名地填寫表格，該過程要適當地重復多輪。

4.2.3規模估算–類比估算法（自頂向下估算法）

1.概念：類比估算法，又稱自頂向下估算法（Top Down Estimates）。

• 適合評估一些與歷史項目在應用領域、環境和復雜度的相似的項目，通過新項目與歷史項目的比較得到規模估計。

• 類比法估計結果的精確度，取決于歷史項目數據的完整性和準確度，因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數據分析是可信賴的。

2.基本步驟

• （1）整理出項目功能列表和實現每個功能的代碼行。
• （2）標識出每個功能列表與歷史項目的相同點和不同點，特別要注意歷史項目做得不夠的地方。
• （3）通過步驟1和2得出各個功能的估計值。
• （4）產生規模估計。

3.計算等價代碼行

• 等價代碼行=[(重新設計%+重新編碼%+重新測試%)/3]×已有代碼

  • 比如：有10000行代碼，假定30%需要重新設計，50%需要重新編碼，70%需要重新測試，那么其等價的代碼行可以計算為：
  • 等價代碼行=[(30%+50%+70%)/3]×10000=5000。
  • 即：重用這10000代碼相當于編寫5000代碼行的規模。

4.3工作量估算

4.3.1工作量

1.工作量：指在軟件項目建設過程中需要投入的人力和時間，一般用人月數進行度量。

• 由于在軟件項目開發過程中，因需求變更導致工作量改變的情形不可避免，故可分別在立項階段進行工作量預算，在項目完成階段進行工作量核算。

4.3.2工作量的計算公式

工作量估計公式：

LOC:源代碼的行數

工作量(人月) = {規模(LOC) / 生產率(LOC/人天)} / 22(天/月)

參考歷史項目數據中各階段工作量所占百分比，可估算出各階段工作量：

各階段工作量（人月）= 總工作量（人月）× 各階段工作量的百分比

4.3.3項目建設階段

項目建設階段一般可分為：

• 開發階段
• 實施階段
• 運行維護階段 故工作量需分階段進行估算： 工作量 = 開發工作量 + 實施工作量 + 維護工作量

4.3.4工作量估算-普特納姆模型

這是1978年普特納姆（L. H. Pumam）提出的，一種動態多變量模型，通用的形式為：

• L：源代碼行數（以LOC計）。
• K：整個開發過程所花費的工作量（以人年計）。
• TD：開發持續時間（以年計）。
• Ck：技術狀態常數，它反映“妨礙開發進展的限制”

4.3.5工作量估算-經驗估算模型（COCOMO模型）

lCOCOMO模型主要從兩個方面來構建：以源代碼行（Single Line Of Code，SLOC）統計的軟件規模，成本驅動因子（Cost Driver），這些因素可以被歸入產品，平臺，人員和項目四個方面。

4.3.5工作量估算-功能點計算

1.功能點計算：軟件功能計算中一旦估算出應用程序中每個功能要素的數量后，就可以將每個計數與一個復雜度值（加權因子）相乘，最后進行合計，算出一個初步的總的功能點數（Function Points Count，UFC）。

4.3.6工作量估算-開發階段工作量估算

可以采用的估算方法有：

• 功能點估算法

  • 適用于立項階段需求分析比較詳細的項目或者用于項目完成階段的最終工作量估算。

• 任務估算法

  • 任務估算法，是把軟件項目功能分解為若干個相對獨立的任務，再分別估計完成每個任務需要的人員搭配比例及投入時間，每個人員的工作量之和就是該任務的工作量。
  • 最后，將各個任務的工作量累加起來就得出軟件項目的總工作量。
  • 該方法適用于立項階段的工作量估算。

4.3.7工作量估算-維護階段工作量估算

1.維護階段：

• 軟件項目通過驗收，交付使用后，需進行一年的系統維護。
• 維護內容包括：運行管理、系統平臺維護、應用軟件維護、數據維護等。

• 系統后期維護：系統運行一年之后的系統維護，需另行簽訂系統維護合約。

4.4工期估算

4.5成本估算

4.5.1成本估算概念

1.成本估算：是指對完成項目各項活動所必須的各種資源的成本做出的估算。

4.5.2常見的成本

• 咨詢費：軟件項目立項前期，請專業機構或者專家進行技術咨詢、可行性分析、需求分析，造價評估、方案設計、項目招標代理等方面工作所發生的費用。

• 建設費：包括支付給軟件開發商的進行軟件開發、實施、維護等方面工作的費用。主要依據工作量（完成該項目需要投入的人力，以人月度量）和人月成本進行估算。

  • 建設費=開發費+實施費+運行維護費=（開發工作量+實施工作量+運行維護工作量）×人月成本

• 服務費：

  • 驗收測試費
  • 工程監理費
  • 數據處理費
  • 附加費
  • 需求變更估算

5.軟件項目的進度管理

5.1 任務定義及任務之間的關系

5.1.1項目的進度管理的過程組

項目的進度管理包含兩個過程組，規劃和監控

規劃過程組：

• 規劃進度管理
• 定義活動
• 排列活動順序
• 估算活動資源
• 估算活動持續時間
• 制定進度計劃

監控過程組：

• 控制進度

5.1.2項目進度管理兩大部分內容

項目進度管理包括兩大部分的內容：

• 項目進度計劃的制定
• 項目進度計劃的執行

5.1.3規劃進度管理

• 一般地說，對項目規模、成本和進度的估算，基本上是同步進行的。
• 任務定義活動的主要作用是，將工作包分解為活動，作為對項目工作進行估算、進度規劃、執行、監督和控制的基礎。
• 創建WBS過程已經識別出WBS中最底層的可交付成果，即工作包。
• 工作包通常還應進一步細分為更小的組成部分，即“活動”。

5.2 進度管理圖示方法

甘特圖、里程碑計劃、關鍵路徑、網絡圖等知識點

5.2.1甘特圖

1.概念：

• 甘特圖（Gantt），由美國工程師和社會學家在1916年發明，又稱橫道圖（Bar Chart，也稱條形圖），是各種任務活動與日歷表的對照圖。表示甘特圖有兩種方式，一種是棒狀圖，另一種用三角形表示，其中空心表示計劃時間， 實心表示實際時間。

2.甘特圖類型：

• 一種是（棒狀圖），另一種用三角形表示，其中空心表示計劃時間， 實心表示實際時間。

3.繪制甘特圖步驟

• （1）明確項目牽涉到的各項活動、項目。內容包括項目名稱（包括順序）、開始時間、工期，任務類型（依物決定性）和依賴于哪一項任務。
• （2）創建甘特圖草圖。將所有的項目按照開始時間、工期標注到甘特圖上。
• （3）確定項目活動依賴關系及時序進度。使用草圖，并且按照項目的類型將項目聯系起來，并且安排。此步驟將保證在未來計劃有所調整的情況下，各項活動仍然能夠按照正確的時序進行，也就是確保所有依賴性活動能并且只能在決定性活動完成之后按計劃展開，同時避免關鍵性路徑過長。
• （4）計算單項活動任務的工時量。
• （5）確定活動任務的執行人員及適時按需調整工時。
• （6）計算整個項目時間。

4.甘特圖優缺點

優點：

• 甘特圖清楚地表明了項目的計劃進度，并能動態地反映當前開發緊張情況

缺點：

• 不能表達出各任務之間復雜的邏輯關系
• 甘特圖大多用于小型項目。

5.2.2網絡圖法

1.簡介：

• 網絡圖是以箭線和節點來表示各項工作及流程的有向、有序的網狀圖形。

2.網絡圖類型：網絡圖按其表示方法的不同可分為兩種。

雙代號的工作是線來表示，單代號的是用節點進行表示的

• 1.雙代號（Active On the Arrow，AOA）網絡圖

• 2.單代號（Activity On Node，AON）網絡圖（又稱前導圖法（Precedence Diagramming Method，PDM））

5.2.3網絡圖法---雙代號AOA

雙代號網絡圖（Active On the Arrow，AOA）中的工作由帶有兩個節點的箭線來表示

5.2.4網絡圖法---單代號-AON或前導圖法-PDM

單代號網絡圖（Activity On Node，AON）中的工作用節點表示

5.2.5里程碑圖

1.里程碑法（Milestone）也稱可交付成果法，是在橫道圖上或網絡圖上標示出一些關鍵事項。

2.里程碑圖：里程碑圖僅標出主要可交付成果和關鍵外部接口的計劃開始或完成日期。

3.里程碑圖的繪制步驟：

（1）認可最終的里程碑。

（2）集體討論所有可能的里程碑。

（3）審核備選里程碑。

（4）對結果路徑進行實驗。

（5）用連線表示里程碑之間的邏輯關系。

（6）確定最終的里程碑計劃。

5.2.6三個與時間相關的重要概念-檢查點，里程碑和基線

軟件開發項目生命周期中有三個與時間相關的重要概念：檢查點、里程碑、基線

• 1.檢查點：是指在規定的時間間隔內對項目進行檢查，比較實際進度與估算進度計劃之間的差異，并根據差異做出調整。

• 2.里程碑：是指一個具有歷史意義的事件，通常代表項目工作中一個重要階段的完成。

• 3.基 線：則是指一個配置在項目不同時間點上通過正式評審而進入正式受控的一種（里程碑）狀態。

三者的關系：重要的檢查點是里程碑，重要的需要客戶確認的里程碑就是基線。

5.3 任務歷時估算

5.3.1任務歷時估算

1.什么是任務歷時估算？

• 任務歷時估計是基于資源估算的結果，估算完成單項活動所需工作時段數的過程。

• 本過程的主要作用是確定完成每個活動所需花費的時間量，為制定進度計劃過程提供主要的輸入。

2.常用的任務歷時估算的方法

• 1.參數估算法
• 2.經驗導出模型
• 3.PERT工程評估技術
• 4.類比估算法

5.3.2參數估算法

參數估算法也稱為定額估算法，是一種基于歷史數據和項目參數，使用某種算法來計算成本或持續時間的估算技術。公式：

• T：活動歷時
• Q：任務工作量
• R：人力數量
• S：工作效率（貢獻率）

5.3.3任務歷時估算---經驗導出模型

經驗導出模型是根據大量的數據統計分析結果得出的經驗公式：

• D：歷時估計值，以月為單位
• E：工作量，以人月為單位
• a和b分別是參數，a取值在2~4，b取值為1/3左右。

5.3.4任務歷時估算---PERT工程評估技術

1.簡介：

• PERT(Program Evaluation and Review Technique)即計劃評審技術，最早是由美國海軍在計劃和控制北極星導彈的研制時發展起來的。PERT技術使原先估計的、研制北極星潛艇的時間縮短了兩年。

• 簡單地說，PERT是利用網絡分析制定計劃以及對計劃予以評價的技術。它能協調整個計劃的各道工序，合理安排人力、物力、時間、資金，加速計劃的完成。

• PERT網絡是一種類似流程圖的箭線圖。它描繪出項目包含的各種活動的先后次序，標明每項活動的時間或相關的成本。

5.3.5任務歷時估算---PERT工程評估技術的三個重要概念

需要明確三個概念：事件、活動和關鍵路線。

1、事件（Events）表示主要活動結束的那一點；

2、活動（Activities）表示從一個事件到另一個事件之間的過程；

3、關鍵路線（Critical Path）是PERT網絡中花費時間最長的事件和活動的序列。

5.3.6任務歷時估算---PERT工程評估技術的計算方法

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

• 它是基于對某項任務的樂觀，悲觀以及最可能的概率時間估計

• 采用加權平均得到期望值

• O：最小估算值：樂觀(Optimistic)
• P：最大估算值：悲觀(Pessimistic)
• M：最大可能估算(Most Likely)。
• 標準差：σ = （最大估算值-最小估算值）/ 6
• 方 差：σ2 = [(最大估算值-最小估算值）/ 6]2

2.對于一個項目而言，需要估算網絡圖中串聯的若干活動的歷時。

期望值和標準差的計算方法如下：

期望值：

方差：

標準差：

3.根據概率分布理論，對于遵循正態概率分布的均值E而言，"E"±𝜎的概率分布是68.3%， "E"±2𝜎的概率分布是95.5%， "E"±3𝜎的概率分布是99.7%。

5.3.5任務歷時估算---類比估算法

類比估算是一種使用相似活動或項目的歷史數據估算當前活動或項目的持續時間或成本的技術。

類比估算以過去類似項目的參數值（如持續時間、預算、規模、質量和復雜性等）為基礎來估算未來項目的同類參數或指標。

相對于其他估算技術，類比估算通常成本較低、耗時較少，但準確性也較低。

5.4 進度計劃編排

5.4.1進度計劃編排---關鍵路徑法

1.關鍵路徑法（Critical Path Method，CPM）是一項用于確定軟件項目的起始時間和完工時間的方法。 CPM是一種最常用的數學分析技術，即根據指定的網絡順序邏輯關系和單一的歷時估算，計算每一個活動的單一的、確定的最早和最遲開始和完成日期。

5.4.2進度計劃編排---關鍵路徑法特征

關鍵路徑具有下列特征：

• 網絡圖上至少存在一條關鍵路徑。
• 關鍵路徑是網絡圖中的最長路徑。
• 關鍵路徑的工期是完成項目的最短工期。
• 關鍵路徑是動態變化的，隨著項目的進展，非關鍵路徑可能會變成關鍵路徑。
• 關鍵路徑上的活動是關鍵活動，任何關鍵活動的延遲都會導致整個項目完成的延遲。

5.4.3進度計劃編排---關鍵路徑法例題

1.題目內容：字母A、B、C、D、E、F、G、H、I、J代表了項目中需要進行的子項目或工作包，連線箭頭則表明了工作包之間的關系，節點數字1，2，3，4，5，6，7，8則表明的是一種狀況，從1開始，到8結束，中間的數字則表明上一工作包的結束和下一工作包的開始。

解答：

• A+D+H+J=1+4+6+3=14（天）
• B+E+H+J=2+5+6+3=16（天） 最長
• B+F+J=2+4+3=9（天）
• C+G+I+J=3+6+2=3=14（天）

關鍵路徑是該圖中最長的路徑，即路徑2，由B，E，H，J組成，歷時16天。

關鍵路徑反映了完成項目需要的最短時間，其所有的組成工作包的執行情況都應給與密切關注，避免項目的延期完成。

關鍵活動在資源管理上享有最高的優先權。

5.4.3進度計劃編排---關鍵路徑法和計劃評審技術（PERT）比較

1.計劃評審技術（PERT）和關鍵路徑法（CPM）基本上一樣，唯一的區別是計劃評審技術的每個活動的工期不是確定的，而是包括了悲觀值，樂觀值和最有可能值三個值。

2.關鍵路徑法是用尋找關鍵路徑及其時間長度來確定項目的完成日期與總工期的方法。

3.根據繪制方法的不同，關鍵路徑法可以分為兩種：即箭線圖（ADM）和前導圖（PDM）。

• 箭線圖（ADM）法又稱為雙代號網絡圖法

• 前導圖（PDM）法又稱為單代號網絡圖法

6.質量管理與配置管理

6.1項目質量的定義

6.1.1三體系認證是什么

三體系認證：即ISO9001認證、ISO14001認證和OHSAS18001認證的統稱。

• ISO9001：質量管理體系認證
• ISO14001：環境管理體系認證
• OHSAS18001：職業健康安全管理體系

6.1.2質量管理的8大原則

以顧客為關注焦點

領導作用

全員參與

過程方法

管理的系統方法

持續跟進

互利的供方關系

6.1.3推行ISO9001有如下五個必不可少的過程

知識準備－立法－宣貫－執行－監督、改進。

6.1.4質量的定義

ISO9000的定義是：一組固有特性滿足需求的程度。 需求指明示的、通常隱含的或必須履行的需求或期望 特性是指可區分的特征，可以是固有的或賦予的、定性的或定量的、有各種類別的（物理的、感官的、行為的、時間的、功能的等）

一般說來，質量的內涵包括功能、美學性、特殊性、一致性、安全性、可靠性、壽命、售后服務等多方面。

6.1.5項目的質量管理

項目質量管理主要包括質量規劃、質量保證及質量控制等三個過程。

• 質量計劃：確定適合于項目的質量標準并決定如何滿足這些標準。

• 質量保證：用于有計劃、系統的質量活動（例如審計或同行審查），確保項目中的所有必須過程滿足項目干系人的期望。

• 質量控制：監控具體項目結果以確定其是否符合相關質量標準，制定有效方案，以消除產生質量問題的原因。

6.1.6質量的形成

質量形成于產品或者服務的開發過程中，而不是事后的檢查（測試）把關等。

6.1.7質量成本

質量成本是由于產品的第一次工作不正常而衍生的附加花費，包括兩部分

• 預防成本
• 缺陷成本

6.1.8質量管理的對象

過程的質量 產品的質量

6.2質量規劃

6.2.1質量規劃

確定項目應達到的質量標準(目標) 決定如何滿足質量標準的計劃安排和方法

6.2.2質量計劃方法

• 成本/效益分析
• 基準分析
• 實驗設計
• 質量成本

6.3質量保證

6.3.1質量保證的要點

1.對項目進行評價

2.推測能否達到質量指標

3.建立對項目的信心

6.3.2質量保證活動-審計

• 審計(Audit) 是對過程或者產品的一次獨立評估。將審核的主體與為該主體以前建立的一組規程和標準進行比較。
• 目的是確保真正的遵循了這一個過程，產生了合適的文檔和精確反映實際項目的報告。
• 可以預先規劃的，也可以是臨時決定的。

6.3.3軟件項目中常用的質量保證活動

項目執行過程審計 項目產品審計

6.4質量控制

6.4.1質量控制要點

1.檢查工作結果

2.按照標準跟蹤檢查

3.確定措施消滅質量問題

6.4.2質量控制活動

• 技術評審
• 代碼走查
• 測試
• 返工

補充A1-功能點估算

A1.1概念

1.1.1識別功能點的重要

功能點估算法是軟件項目管理眾多知識中比較有技術含量的一個。在軟件項目管理中項目計劃制定的優劣直接關系到項目的成敗，項目計劃中對項目范圍的估算又尤為重要，如果項目負責人對項目的規模沒有一個比較客觀的認識，沒有對工作量、所需資源、完工時間等因素進行估算，那么項目計劃也就沒有存在的意義。

1.1.2適用范圍

適合： -以數據和交互處理為中心 -以功能多少為主要造價格制約因素 -如：電子政務、銀行電信的用戶和業務管理系統 不適合： -數據處理過程復雜 -創意型軟件 -對性能和質量有特殊要求的 -如：視頻和圖像處理軟件，殺毒軟件、網絡游戲

1.1.3是被項目的類型

國際IFPUG組織將軟件項目分為三類，功能點估算法適用于任何一類項目：

• 新開發項目
• 二次開發的項目
• 功能增強的項目

從使用者的角度，而非制造者的角度

• --存儲哪些數據信息
• --如何來處理這些數據

A1.2估算步驟

1.2.1估算步驟

具體步驟包括：

識別功能點的類型。

識別待估算應用程序的邊界和范圍。

計算數據類型功能點所提供的未調整的功能點數量。

計算人機交互功能所提供的未調整的功能點數量。

確定調整因子。

計算調整后的功能點數量。

補充A2-掙值

1.1“掙值”

1.1.1什么是”掙值“

白話：活兒干了一部分，實際干了的這部分活兒按計劃應該花多少錢，是掙值。

1.掙值（EV，Earned Value），指項目實施過程中某階段實際完成工作量及按預算定額計算出來的工時（或費用）。又叫已完成工作量的預算成本（BCWP，Budgeted Cost for Work Performed）。

2.掙值的計算公式：

EV=BCWP=已完成工作量*預算定額

1.1.2掙值的案例

白話：活兒干了一部分，實際干了的這部分活兒按計劃應該花多少錢，就是掙值。

1.問：按計劃做一套煎餅果子要5元，今天做了100套，掙值是多少？

• 答：EV=5*100=500

2.問:按計劃，做一套煎餅果子要5塊錢，不過今天雞蛋便宜，現在實際上一套成本只要4塊錢。原計劃今天做100套，實際上偷了會兒懶兒，只做了90套。掙值是多少?

• 答：EV= 5*90=450

1.2掙值方法的基本參數

1.2.1ACWP（已完成工作量的實際費用

ACWP白話解釋：到目前為止所完成工作的實際成本。它表示“到日期為止所完成工作的實際成本。”說明了“到該日期為止實際花了多少錢”) 如：4*90=360

1.ACWP（已完成工作量的實際費用）:ACWP指項目實施過程中某階段實際完成的工作量所消耗的工時（或費用）。ACWP主要反映項目執行的實際消耗指標。(ACMP也稱為AC，即實際成本)

1.2.2BCWP（已完工作量的預算成本）

BCWP白話解釋：已完成工作的預算成本，到目前為止已經完成的工作的原來預期成本。

它表示“到該日期為止完成了多少工作？” 如：5*90=450

BCWP（已完工作量的預算成本）:BCWP是指項目實施過程中某階段按實際完成工作量及按預算定額計算出來的費用，即掙得值(Earned Value),或稱掙值、盈值和掙得值。(BCMP也稱為EV，即掙值)

BCWP的計算公式為：ＢＣＷＰ=已完工作量×預算定額。(實質是將已完成的工作量用預算費用來度量)

1.2.3BCWS（計劃工作量的預算費用）

BCWS白話解釋：到目前為止的總預算成本。

它表示“到目前為止原來計劃成本是多少？”或者“到該日期為止應該完成的工作是多少？” 如：5*100=500

BCWS（計劃工作量的預算費用）:BCWS是指項目實施過程中某階段計劃要求完成的工作量所需的預算費用。計算公式為：BCWS=計劃工作量×預算定額。BCWS主要是反映進度計劃應當完成的工作量(用費用表示)。

BCWS是與時間相聯系的，當考慮資金累計曲線時，是在 項目預算s曲線上的某一點的值。當考慮某一項作業或某一時間段時，例如某一月份，bcws是該作業或該月份包含作業的預算費用。(BCWS也稱為PV,即計劃值)

1.3掙值分析法的四個評價指標

四個評價指標：進度偏差（SV）、成本偏差（CV）、成本執行指數（CPI）和進度執行指標（SPI）

1.3.1進度偏差

進度偏差（SV，Schedule Variance）SV是指檢查日期EV和PV之間的差異： SV=EV-PV=BCWP-BCWS 當SV為正值時，表示進度提前； 當SV等于零時，表示實際與計劃相符。 當SV為負值時，表示進度延誤。

1.3.2成本偏差

成本偏差（CV，Cost Variance）。CV是指檢查期間EV和AC之間的差異： CV=EV-AC=BCWP-ACWP 當CV為正值時，表示實際消耗的人工（或費用）低于預算值，即有結余或效率高； 當CV等于零時，表示實際消耗的人工（或費用）等預算值； 當CV為負值時，表示實際消耗的人工（或費用）超出預算值或超支。

1.3.3成本執行指數（CPI）

費用執行指標（CPI，Cost Performed Index）。指預算費用與實際費用之比（或工時值之比）： CPI=EV/AC=BCWP/ACWP 當CPI>1時，表示低于預算，即實際費用低于預算費用； 當CPI=1時，表示實際費用與預算費用溫和； 當CPI<1時，表示超出預算，即實際費用高于預算費用；

1.3.4和進度執行指標（SPI）

進度績效指標（Shedul Performed Index）。指項目掙值與計劃值之比： SPI=EV/PV=BCWP/BCWS ,

當SPI>1時，表示進度超前 當SPI=1時，表示實際進度與計劃進度相同 當SPI<1時，表示進度延誤

1.4掙值管理

• 掙值管理是項目管理的一種方法，主要用于項目成本和進度的監控 掙值通過項目開始時的計劃與所完成的工作進行比較，給出了一個項目何時完工的估算，通過從項目已經完工的部分進行推算，項目經理可以估計出項目完工的時候，將會花費多少資源。 這項技術基于關鍵路徑的概念。

• 另一個項目績效測量和管理技術是關鍵鏈，它使用的是緩沖管理。原因是掙值管理方法不能區別基于項目約束（例如：項目的關鍵鏈）的進度和基于非約束（例如：項目路徑網絡中的其他路徑）的進度，這在某些時候會造成項目經理為了追求更好的掙值測量，而以關鍵任務成本來急于完成非關鍵的任務，導致項目完工的推延。這是一個局部最優的例子，問題在于缺乏局部測量與整體測量的從屬關系。

1.5掙值管理的使用

項目經理需要下列首要數據：

• 工作分解結構 (WBS): 以層次化分解的所有任務的列表。
• 項目主進度計劃(PMS): 關于那些任務將完成以及誰完成的甘特圖
• 計劃完成的工作的預計成本(計劃值): 每一個周期預計當前完成的工作的預算。
• 實際完成的工作的預計成本(掙值): 每一個周期當前實際完成的工作的預算。
• 實際完成的工作的實際成本(實際成本): 每一個周期工作的實際成本。
• 項目總預算(BAC): 預計用于完成項目所花費的總預算。

總結

以上是生活随笔為你收集整理的软件项目管理的重点知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。