第一章.軟件項目管理概述

1.實現項目目標的制約因素有：

項目範圍
成本
進度計劃
客戶滿意度

2.項目管理包括：

啓動過程組
計劃過程組
執行過程組
控制過程組
收尾過程組

3.什麼是項目：

爲了創造一個唯一的產品或者提供一個唯一的服務而進行的臨時性的努力，所以說項目具有臨時性特性

4.過程管理就是對過程進行管理，目的是要讓過程能夠被共享，複用，並得到持續的改進

5.項目與日常運作的區別與共同點：

項目	日常運作
以目標爲導項	通過效率和有效性的體現
通過項目經理及其團隊工作完成的	職能式的線性管理
項目是一次性的	日常運作可以重複進行

共同點：

都需要人來做；而且都受資源限制；都需要規劃，執行，控制

6.項目的特徵：項目均是有時間範圍的，所以最能表現項目特徵的是確定期限

7.請簡述項目管理的 5 個過程組及其關係

（1）啓動過程組：主要是確定一個項目或一個階段可以開始了，並要求着手實行；定義
和授權項目或者項目的某個階段。（2）計劃過程組：爲完成項目所要達到的商業要求而進行
的實際可行的工作計劃的設計、維護，確保實現項目的既定商業目標。計劃基準是後面跟蹤
和監控的基礎。（3）執行過程組：根據前面制定的基準計劃，協調人力和其他資源，去執行
項目管理計劃或相關子計劃。（4）控制過程組：通過監控和檢測過程確保項目達到目標，必
要時採取一些修正措施。集成變更控制是一個重要的過程。（5）收尾過程組：取得項目或階
段的正式認可並且有序地結束該項目或階段。向客戶提交相關產品，發佈相關結束報告，並
且更新組織過程資產並釋放資源。
關係：各個過程組通過其結果進行連接，一個過程組的結果或輸出是另一個過程組的輸入。
其中，計劃過程組、執行過程組、控制過程組是核心管理過程組。

8.項目的特徵是什麼

目標性、相關性、臨時性、獨特性、資源約束性、不確定性

第二章.項目確立

1.項目立項之後，項目負責人會進行自造購買決策，確立待開發產品的哪些部分的應該採購，外包開發，自主研發等

2，項目經理的主要職責是：

開發計劃
組織實施
項目控制

3.在（立項）階段，應該明確項目的目標、時間表、使用的資源和經費，而且得到項目發起人的認可。注意：項目立項是需求方（甲方）提出的需求

4.項目招標階段

甲方過程：

（招標書定義）、（供方選擇）、（合同簽署）

乙方過程：

（項目分析）、（競標）、（合同簽署）
總而言之：甲方：客戶（上帝），乙方：軟件開發方

5.項目建議書是項目立項階段（項目的初始階段）開發的文檔

6.甲方（顧客，需求方）招標階段的任務是：

招標書定義
供方選擇
合同簽署

7.某公司希望開發一套軟件產品，如果選擇自己開發軟件的策略，公司需要花費 30000 元，根據歷史信息，維護這個軟件每個月需要 3500 元。如果選擇購買軟件公司產品的策略，需要 18000 元，同時軟件公司爲每個安裝的軟件進行維護的費用是 4200 元/月。該公司該如何決策？

自制方案：
製造費 30000 元維護費 3500 元/月
購買方案：
購買費 18000 元維護費 4200 元/月
製造差額： 30000-18000=12000 元
服務差額： 4200-3500=700 元
自制方案承受月份： 12000/700=17.14
如果產品在 17 個月以內可以選擇購買方案，如果超過 17 個月選擇自造方案。

8.什麼是項目章程？

項目章程是項目執行組織高層批准的一份以書面簽署的確認項目存在的文件，包括對項
目的確認、對項目經理的授權和項目目標的概述等。

9.招標書主要包括那幾部分內容？

招標書主要包括三部分內容：技術說明、商務說明和投標說明。技術說明主要對採購的
產品或者委託的項目進行詳細的描述，商務說明主要包括合同條款。投標說明主要是對項目
背景、標書的提交格式、內容、提交時間等做出規定。

第三章.生存期模型

1.瀑布模型生存期模型中，要求項目所有的活動都嚴格按照順序進行，一個階段的輸入是下一個階段的輸入。

2.敏捷開發通過迭代和快速用戶反饋應對管理的不確定性和變更

3，每日站立會議是（Scrum）模型敏捷開發實踐

4.瀑布模型適合短期項目

5.增量式模型可以避免一次性投資太多帶來的風險

6.各個模型的優缺點：

模型	特點	缺點	使用範圍
瀑布模型	線性,階段計劃分明,以項目的階段評審和文檔控制爲手段有效的對整個開發過程進行指導	缺乏靈活性，無法解決需求不明確或者不準確的情況;（2）由於開發是線性的，只有到末期才能見到開發成果,增加了開發的風險;（3）早期的錯誤到後期才能發現	適用於需求明確，解決方案明確的項目
V模型	糾正了人民不重視測試階段的重要性的錯誤認識,將測試分等級,並且和前面的開發階段對應	仍然將測試作爲一個獨立的階段,並沒有提高抗風險能力	與瀑布模型類似
快速原型模型	有助於增進軟件人員和用戶對系統服務需求的理解	文檔容易被忽略,建立原型的許多工作會被浪費掉，項目難以規劃和管理	適用於需求不明確,動態變化的項目
增量模型	增強了客戶使用的信心，逐步提出對後續增量的需求;增量由高到低的優先級確定保障了系統重要功能部分的可靠性;項目總體失敗的風險比較低	增量粒度選擇問題，確定所有的基本服務比較苦難	適用於需求大部分明確，系統較爲複雜,有一定的技術風險

漸進式模型:

缺點：需要精心規劃各個階段目標，每個階段提交的是正式版本，所以工作量會增加
使用範圍：主要適用於中型或者大型項目，是目前開發中最常用的開發模型
敏捷生存模型：通過迭代和快速的用戶反饋管理不確定性和應對變更
敏捷開發宣言：

個體和交互勝過過程和工具；可以工作的軟件勝過面面俱到的文檔；客戶合作勝過合同談判；相應變化勝過遵循計劃
適用於需求不明確的情況下采用

7.三種你熟悉的生存期模型，並說明這些模型適用於什麼情況下的項目

（1）瀑布模型
適用於軟件需求很明確的軟件項目，即一般適用於功能明確、完成、無重大變化的軟件系統
的開發，即：
1）在項目開始前，項目的需求已經被很好的理解、也很明確，而且項目經理很熟悉爲實現
這一模型所需要的過程。
2）解決方案在項目開始前也很明確。
3）短期項目可採用瀑布模型。
（2）V 模型
適用於項目需求在項目開始前很明確、解決方案在項目開始前也很明確，項目對系統的
安全很嚴格，如航天飛機控制系統、公司的財務系統等。
(3)快速原型模型
適用於項目的需求在項目開始前不明確，需要減少項目的不確定性的時候。

第四章軟件項目範圍計劃——需求管理

1.需求管理包括:

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

2.原型分析方法是其中一種需求建模方法。

3.結構化分析方法是一種自下而上逐步求精的分析方法

4.軟件項目管理需求過程:

需求獲取
需求分析
需求規格編寫

5.數據字典組成部分:

數據項
數據流
數據文件

6.下列不屬於 UML 需求視圖的是?

甘特圖(甘特圖用於做計劃的視圖)
屬於需求的視圖的是：用例圖，狀態圖，順序圖

7.屬於需求建模的方法：

原型方法
面向對象的用例分析方法
功能列表方法

8.（需求變更）軟件項目的一個突出特點，可以導致軟件項目的蔓延

9.結構化方法設計有：

數據流圖
數據字典
系統流程圖

10.我們常常從哪些方面着手處理需求不明確的問題？

(1)讓用戶參與開發
(2)開發用戶界面原型
(3)需求討論會議
(4)強化需求分析和評審

第五章軟件項目範圍規劃——任務分解

1.任務分解是將一個項目分解爲更多的工作細目或者子項目，是項目變得更小、更易管理、更易操作

2.一般來說，進行項目分解時，可以採用清單或圖表兩種形式來表達任務分解的結果。

3.WBS的全稱是任務分解結構：Work Breakdown Structure。

4.WBS最底層次可交付成果是：工作包 work package。

5.WBS提供了項目範圍基線

6. 一個工作包可以分配給另一個項目經理去完成。(注：工作包應當由唯一主體負責，可以分配給另外一位項目經理通過子項目的方式完成。)

7.對於一個沒有做過的項目，開發 WBS時可以採用自底向上方法。

8. 在任務分解結果中，最底層的要素必須是實現項目目標的充分必要條件。

9.任務分解是將一個項目分解爲更多的工作細目或者子項目，使項目變得更小、更易管理和操作。

10.一個工作包應當由唯一主體負責。

11.WBS的最底層任務是能分配到一個人完成的任務。

12…WBS非常重要，因爲：

幫助組織工作,防止遺漏工作,爲項目估算提供依據但是不包括確定團隊成員責任

13.WBS中的每一個具體細目通常都指定唯一的編碼

14.創建 WBS的方法有：

自頂向下 ,自底向上 ,模板參照,不包括控制方法

15.任務分解時，

（自底向上）方法從特殊到一般的方向進行，首先定義一些特殊的任務，然後將這些任務組織起來，形成更高級別的 WBS層。
(自頂向下)方法從一般到特殊的方向進行，從項目的大局着手，然後逐步分解子細目，將項目變爲更細、更完善的部分

16.WBS的定義：

(1)WBS是任務分解的結果;(2)不包括再 WBS中的任務就不是該項目的工作;(3)可以採用清單或者圖表的形式標識WBS的結果

17.檢驗 WBS分解結果的標準：

最底層的要素是否是實現目標的充分必要條件
最底層元素是否有重複
最底層要素是否有清晰完整定義

18.WBS是對項目由粗到細的分解過程，它的結構是:分級的樹形結構

19.任務分解的方法和步驟

任務分解的基本步驟：

確認並分解項目的組成要素 (WBS編號 ) 。
確定分解標準，按照項目實施管理的方法分解，而且分解的標準要統一。
確認分解是否詳細，是否可以作爲費用和時間估計的標準，明確責任。
確定項目交付成果（可以編制 WBS字典）。
驗證分解正確性。驗證分解正確後，建立一套編號系統。

任務分解方法：

模板參照方法
類比方法
自上而下
自下而上

20.當項目過於複雜是，可以對項目進行任務分解，這樣做的好處是什麼?

將一個項目分解爲更多的工作細目或者子項目，使項目變得更小、更易管理、更易操作，這樣可以提高估算成本、時間和資源的準確性，使工作變得更易操作，責任分工更加明確。

21.檢驗任務分解結果的標準是什麼？

檢驗任務分解結果的標準有：

最底層的要素是否是實現目標的充分必要條件

最底層要素是否有重複的

每個要素是否清晰完整定義

最底層要素是否有定義清晰的責任人

是否可以進行成本估算和進度安排

第六章項目成本計劃

1.軟件項目成本包括直接成本和間接成本，一般而言，項目人力成本歸屬於直接成本。

2.再在項目初期，一般採用的成本估算方法是類比估算法。

3.功能點方法中 5 類功能組件的計數項是外部輸入、外部輸出、外部查詢、內部邏輯文件、外部接口文件。

4.軟件項目的主要成本是人的勞動的消耗所需要的代價。

5.用例點方法通過分析用例角色、場景和技術與環境因子等來進行軟件估算

6.人的勞動消耗所付出的代價是軟件產品的主要成本。

7.估算時既要考慮直接成本又要考慮間接成本。

8.（規模）是成本的主要因素，是成本估算的基礎

9.常見的成本估算方法：

代碼行，功能點，類比法；記住不包括關鍵路徑法

10.UFC的功能計數項：

UFC:未調整功能點計數
包括：外部輸出，外部文件，內部文件

11.成本預算的目的是：產生成本基線

12.估算的基本方法包括：

1）代碼行，功能點；2）參數估算法；3）專家估算法；記住不包括函數估算法

13.在項目初期，進行競標合同時，一般採用的成本估算方法是類比估算法

14.軟件項目規模單位有：

代碼長度（LOC）
功能點（FP）
人天，人月，人年
不包括小時

15.在成本管理過程中，每個時間段中等各個工作單元的成本是（預算）

16.項目經理正在進行一個圖書館信息查詢系統的項目估算，他採用 Delphi 的專家估算方法，邀請了 3 位專家進行估算，第一位專家給出了 2 萬元、 7 萬元、 12 萬元的估算值，第二位專家給出了 4 萬元、 6 萬元、 8 萬元的估算值，第三位專家給出了 2 萬元、 6 萬元、 10 萬元的估算值，試計算這個項目的成本估算值

專家一： Ei=(ai+4mi+bi)/6= （2+47+12）/6=7
專家二： Ei=(ai+4mi+bi)/6=（4+46+8）/6=6
專家三： Ei=(ai+4mi+bi)/6= （2+4*6+10 ）/6=6
Ei=（7+6+6）/3=6.33 （萬元）

17.如果某軟件公司正在進行一個項目，預計有 50KLOC的代碼量，項目是中等規模的半嵌入型的項目，採用中等 COCOMO模型，項目屬性中只有可靠性爲很高級別（即取值爲 1.3），其他屬性爲正常（書上說，正常就是 1），計算項目是多少人月的規模，如果是 2 萬元 /人月，則項目的費用是多少？

Effort=a* (KLOC)b F
查表 a=3，b=1.12，F=1
Effort=3.050
1.12 1.31=311.82 （人月）
所以項目的費用爲 2* Effort=623.64 萬元

18.已知某項目使用 C語言完成，該項目共有 85 個功能點，請用 IBM 模型估算源代碼行數、工作量項目持續時間、人員需要量以及文檔數量。

C 語言代碼行與功能點的關係近似爲 150LOC/FP，所以， 85 個功能點代碼行數爲
L=85150=12750 行=12.75KLOC,則:工作量估算 E=(5.2L)的0.91次方 =（5.212.75）的0.91次方≈52.725（人月）
項目時間 D=（4.1L）的0.36次方 =(4.112.75)的 0.36次方 ≈10.25（月）
人員需求量 S=（0.54E）的 0.6次方 =0.5452.725的0.6次方 ≈5.829（人）
文檔數量 DOC=49L 的1.01次方 =49*12.75的1.01次方≈640.857（頁）

第七章軟件項目進度計劃

1.關鍵路徑決定了項目在給定的金錢關係和資源條件下完成項目所需的最短時間

2.時間是一種特殊的資源，以其單向性、不可重複性、不可替代性而有別於其他資源，是項目計劃中靈活性最小的因素。

3.在 ADM 網絡圖中，箭線表示活動（任務）,結點表示前一個任務的結束，同時表示後一個任務的開始。

4.應急法和平行作業法都是時間壓縮法。

5.任務（活動）之間的排序依據主要有強制性依賴關係、軟邏輯關係、外部依賴關係等。

6.工程評估評審技術採用加權平均的公式是 PERT歷時 =(O+P+4M)/6 ，其中 O 是樂觀值， P是悲觀值， M 是最可能值。

7.一個工作也可以通過多個活動完成。

8.在項目進行過程中，關鍵路徑是可變的

9.在 PDM 網絡圖中，箭線表示的是任務之間的邏輯關係，節點表示的是活動。

10.在資源衝突問題中，過度分配也屬於資源衝突。

11.浮動是在不增加項目成本的條件下，一個活動可以延遲的時間量

12.在使用應急法壓縮時間時，要在關鍵路徑上選擇活動來進行壓縮，因爲能夠壓縮的都是關鍵路徑。

13.時間是項目規劃中靈活性最小的因素。

14.常用的公式：

EF(最早完成時間)=ES(最早開始時間)+duration(任務的歷時時間)
LS(最晚開始時間)=LF(最晚完成時間)-duration(任務的歷時時間)
TF(總浮動：在不影響項目最早完成時間)=LS(最晚開始時間)-ES(最早開始時間)=LF(最晚完成時間)-EF(最早完成時間)
FF(自由浮動：在不影響後置任務最早開始的時間)=ES(最早開始時間)-EF(最早完成時間)-lag(本任務與後置任務之間的之後時間)

15.常見的依賴關係：

強制性依賴關係
軟邏輯關係
外部依賴關係
里程碑

16.（甘特圖）可以顯示任務的基本信息，使用該類圖能方便的查看任務的工期、開始時間、結束時間以及資源的信息。

17.(進度問題)是項目衝突的主要原因，尤其在項目後期。

18.編制進度的基本方法：

關鍵路徑法
時間壓縮法
資源平衡法
注：系統圖法不是

19.快速跟進是指採用並行執行任務，加速項目進展

20.（lag）將延長項目的進度

21.(總浮動)可以決定進度的靈活性

22.對一個任務進行進度估算時， A 是樂觀者，估計用 6 天完成， B 是悲觀者，估計用 24天完成， C是有經驗者，認爲最有可能用 12 天完成，那麼這個任務的歷時估算介於 10天到 16 天的概率是多少？

E=(6+24+4*12)/6=13 ， δ=(24-6)/6=3
E-δ =10
E+δ=16
查表(p139)得任務歷時估算介於 10—— 16 天的概率爲： 68.3%

23.請將下圖所示的 PDM（優先圖法）網絡圖改畫爲 ADM（箭線法）網絡圖。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RbSNI3en-1589334555768)(1.png)]

上圖對應的 ADM 圖如下所示：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-wJ2BirqS-1589334555770)(2.png)]

24.根據下面任務流程圖和下表給出的項目歷時估算值，採用 PERT方法估算，求出項目在14-57 天內完成的概率的近似值。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Tpm3FGPR-1589334555772)(3.png)]
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-p2qjSfsr-1589334555774)(4.png)]

標準差：δ=（P-O）/6;

第八章軟件項目質量計劃

1.（審計）是對過程或產品的一次獨立質量評估。

2.質量成本包括預防成本和（缺陷成本）。

3.質量管理包括（軟件質量計劃）、（軟件質量保證）、（軟件質量控制）等過程。

4.（軟件質量）是軟件滿足明確說明或者隱含的需求的程度。

4.McCall 質量模型關注的 3 個方面是（產品運行）、（產品轉移）、（產品修改）。

5.質量管理總是圍繞着(質量保證)和（質量控制）過程兩個方面進行。

6.質量保證的主要活動是（項目執行過程審計）和（項目產品審計）

7.質量是滿足要求的程度 ,包括符合規定的要求和滿足顧客隱含需求

8. 軟件質量是軟件滿足明確說明或者隱含的需求的程度。

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

10.質量計劃可以確定質量保證人員的特殊彙報渠道。

11.質量管理過程：

質量計劃
質量保證
質量控制

12.項目質量管理的目標是滿足（項目）的需要

13.質量成本：

預防成本（評估費用和評估費用）
缺陷成本（內部費用和外部費用）

14.軟件質量模型：

Boehm 質量模型
McCall 質量模型
ISO/IEC 9216質量模型

15.質量控制非常重要，但是進行質量控制也需要一定的成本，（使用抽樣統計）可以降低質量控制的成本。

16.McCall 質量模型包含：

產品修改
產品轉移
產品運行
不包括產品特點

17.質量計劃中可以採用哪些方法？

質量計劃中可以採用以下幾種方法：
（1）試驗設計：試驗設計是一種統計學方法，確定哪些因素可能會對特定變量產生影響。
（2）基準對照：是一種尋找最佳實踐的方法，是利用其他項目的實施情況作爲當前項目性能衡量的標準。
（3）質量成本分析：質量計劃必須進行質量成本的綜合分析，以便決定質量活動。
（4）流程圖方法：可以顯示系統的各種成分是相互的關係，幫助我們預測在何處可能發生何種質量問題。
（5）因果分析圖：也稱魚刺圖。描述相關的各種原因和子原因如何產生潛在問題或影響，將影響質量問題的 “人員、設備、參考資料、方法、環境”等各方面的原因進行細緻的分解，方便地在質量計劃中制定相應的預防措施。

18. 簡述質量保證的主要活動，以及質量保證的要點。

質量保證的主要活動是項目執行過程審計和項目產品審計。
質量保證的要點是：對項目進行評價、推測能否達到質量指標、建立對項目的信心

19.簡述質量保證與質量控制的關係。

質量保證（ QA）是通過評價項目整體績效 ,建立對質量要求的信任，提供項目和產品可
視化的管理報告。這個任務本身並不能提高產品的質量，但是通過質量保證的一系列工作可
以間接地提高產品的質量。質量保證一般由質量保證部門人員實施。
質量控制（ QC）是確定項目結果與質量標準是否相符 ,同時 ,確定消除不符的原因和方法，它
控制產品的質量，及時糾正缺陷。這個任務本身提高產品的質量，一般由開發人員實施。
質量保證是後期質量活動，質量控制是前期質量活動。它們是有區別的 :質質量保證是針對
項目實施過程的管理手段，質量控制是針對項目產品的技術手段 ;實施質量保證是針對過程
改進和審計的，強調的是過程改進和信心保證。實施質量控制是按照質量要求，檢查具體可
交付成果的質量，強調的是具體的可交付成果。

第九章軟件配置管理計劃

1. 配置管理最終保證軟件產品的（完整性）、（一致性）、（追溯性）、（可控性）。

2.（完整性和可跟蹤性）是軟件配置管理的核心功能。

3.（基線）標誌開發過程中一個階段的結束和里程碑。

4. 基線變更控制包括（變更請求）、（變更控制）、（變更批准 /拒絕）、（變更實現）等步驟。

5.（版本管理）、（變更管理）是配置管理的主要功能。

6. 基線變更時，需要經過（ SCCB）授權。

7. SCCB的全稱是（軟件配置控制委員會）。

8.基線提供了軟件生存期中各個開發階段的一個特定點(記住是各個開發階段，不是單獨的某一個開發階段)

9.一個（些）配置項形成並通過審覈，即形成基線。

10.變更控制系統包括從項目變更申請、變更評估、變更審批到變更實施的文檔化流程。

11. 基線修改應受到控制，而且一定要經 SCCB授權。

12.基線產品是可以修改的

13.基線的修改需要每次都按照正式的程序執行。

14. 軟件配置項是項目需定義其受控於軟件配置管理的款項，每個項目的配置項不一定是相同的。

15.SCCB的職責：

評估變更
與項目管理層溝通
對變更進行反饋
注意：提出變更申請不是sccb的職責

16.爲了更好地管理變更，需要定義項目基線，關於基線:

可以變化，但是必須通過基線變更控制流程處理

17.軟件配置管理可以確保軟件產品完整性，一致性，可控性，但是無法確保產品的正確性

18.變更控制需要關注的是：標識變更，提出變更，管理變更

19.配置管理的基本過程：

（1）配置項標識、跟蹤；（ 2）配置管理環境建立；（3）基線變更管理；（4）配置管理審
計；（5）配置狀態統計；（ 6）配置管理計劃。

20.軟件配置控制委員會（ SCCB）的基本職責：

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

21.配置管理在軟件開發中的作用，並列舉至少兩種配置管理工具

軟件配置管理是軟件項目管理的重要內容，也是保證軟件質量的重要手段。它能
夠對軟件開發過程進行有效管理和控制，從而實現軟件產品的完整性、一致性、可控性，使
產品極大程度地與用戶需求相吻合。它能夠控制、記錄、追蹤對軟件的修改並形成規範文檔，
方便日後維護和升級，更重要的是能夠保護代碼資源，積累軟件財富，提高軟件重用率。
配置管理工具有： Harvest、 Perforce、ClearCase、PVCS、CVS\SVN、 VSS

22.寫出幾個常見的軟件配置項

軟件項目計劃、需求分析結果、軟件需求規格說明書、設計規格說明書、源代碼清
單、廁所規格說明書、測試計劃、測試用例與實驗結果、可執行程序、用戶手冊、維護文檔。

第十章軟件項目人員與溝通計劃

1. 溝通管理的基本原則是及時性、準確性、完整性、可理解性。

2.可以充分發揮部門資源優勢集中的組織結構爲職能型組織結構

3. 溝通計劃用於確定誰需要信息，需要什麼信息，何時需要信息，以及如何將信息分發給他們。

4. 組織結構的主要類型:

職能型(適用於主要由一個部門完成的項目或技術比較成熟的項目組織結構，是目前最普遍的項目組織形式，它是一個標準的金字塔型組織形式)
項目型(在這種組織結構中項目成員沒有安全感)
矩陣型(項目涉及多的領域和特性)

5. 會議形式溝通最有可能協助解決複雜的問題。

6.當項目中有 20 個人時，溝通渠道最多有 190。

公式：N(N-1)/2  其中N:表示人員總數

7.項目干係人是項目計劃的一部分。

8.項目溝通的基本原則是及時性、準確性、完整性和可理解性

9.在 IT 項目中，成功的最大威脅是溝通的失敗

10.責任分配矩陣是明確項目團隊成員的角色與職責的有效工具

11.對於緊急的信息，應該通過口頭的方式溝通；對於重要的信息，應採用書面的方式溝通

12.人員計劃描述項目的團隊人員什麼時候，以及如何加入和離開團隊

13.溝通計劃包括確定誰需要信息，需要什麼信息，何時需要信息，以及如何接收信息等

14.人員管理計劃沒有明確的具體體現形式，作爲項目計劃的一部分，其詳細程度因項目而異

15.項目經理花在溝通上的時間是 75%-90%

16.干係人：

影響項目決策的個人、羣體或者組織
影響項目活動的個人、羣體或者組織
影響項目結果的個人、羣體或者組織
注意只有這三種，並不是適應所有的項目人員

17.編制溝通計劃的基礎是溝通需求分析

18. 團隊：

是一定數量的個體成員的集合
團隊應注重個人發揮，應該將某項任務分工給擅長該技術的職員
團隊的目的是開發出高質量的產品
團隊包括自己組織的人、供應商、分包商，注意沒有客戶

19.寫出 5 種以上項目溝通方式

溝通方式主要有書面溝通和口頭溝通、語言溝通和非語言溝通、正式溝通和非正式溝通、
單向溝通和雙向溝通、網絡溝通等

20.矩陣型項目組織結構的優缺點是什麼

優點是： 1、專職的項目經理負責整個項目，以項目爲中心，能迅速解決問題。在最短的時間內調配人才，組成一個團隊，把不同職能的人才集中在一起。
2、多個項目可以共享各個職能部門的資源。在矩陣管理中，人力資源得到了更有效的利用，減少了人員冗餘。
3、既有利於項目目標的實現，也有利於公司目標方針的貫徹
4、項目成員的顧慮減少了，因爲項目完成後，他們任然可以回到原來的職能部門，不用擔心被解散，而且他們能有更多機會接觸自己企業的不同部門。
缺點是 1、容易引起職能經理和項目經理權利的衝突。
2、資源共享可能引起項目之間的衝突
3、項目成員有多位領導，即員工必須要接受雙重領導，因此經常有焦慮與壓力

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

1.風險評估的方法包括

定性風險分析
定量風險分析。

2.決策樹分析是一種形象化的圖表分析方法。

3.項目風險的三要素是

風險事件
風險事件發生的概率
風險造成的影響

4.(迴避)風險是指儘可能地規避可能發生的風險，採取主動放棄或者拒絕使用導致風險的方案

5.風險規劃的主要策略(應對風險的常見策略)是:

迴避風險
轉移風險
損失控制
自留風險

6.軟件項目風險識別常採用德爾菲方法、頭腦風暴法、情景分析法、風險條目檢查表、其他等方法。

7.定量風險評估主要包括訪談、盈虧平衡分析、決策樹分析、模擬法、敏感性分析等方法。

8.風險管理的 4 個過程:

風險識別
風險評估
風險規劃
風險控制

9.風險的三要素:

一個事件
事件發生的概率
事件的影響

10.險評估方法:

盈虧平衡分析
模擬法
決策樹分析

11.一個項目在進行規劃的時候，碰到了一個風險問題，項目經理決定是否採用方案 A。如果採用方法 A 需要使用一個新的開發工具，而能夠掌握這個工具的概率是 30%，通過使用這個工具可以獲利 5 萬元，如果採用方案 A 而不能掌握這個工具，將損失 1 萬元。利用決策樹分析技術說明這個項目經理是否應該採用這個方案 A？（繪製決策樹）

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tZxOV8Nj-1589334555777)(5.png)]
EMV:損益期望值
公式:EMV=(outcome(回報)*成功概率-虧本 * 虧本概率)
EMV=(50000 * 30%-10000 * 70%) =8000

12.某企業在今年有甲乙兩種產品方案可以選擇，每種方案的狀態、收益和概率如表 11-11 所示，繪製決策樹時，判斷哪種方案將有更大收益。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ya7FxaAB-1589334555778)(6.png)]
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-M7GW4oxz-1589334555780)(7.png)]

第十二章軟件項目合同計劃

1.買房風險最高的合同類型： FFP（固定總價合同）

2.爲執行項目而從項目團隊外獲取產品、服務或者成果的過程稱爲：採購

3.合同雙方當事人承擔不同角色，這些角色包括：甲方、乙方

4.軟件外包的基本步驟：競標邀請、評估候選乙方的綜合能力、確定承包商

5.如果 CPPC合同類型中成本百分比是 10%，估計成本是 10 萬元，當實際成本是 20 萬元是，合同金額應該爲： 22 萬元

20+10% * 20=22萬

6.一個 CPFF合同類型，估計成本是 10 萬元，固定費用是成本 1.5 萬元，當成本提高至 20萬元是，合同金額爲： 21.5 萬元

20+1.5=21.5萬

7.合同類型有：

成本補償類合同(CPCC)
固定價格類合同(FFP)
單價類合同()
成本加獎金（ CPIF）合同
成本加成本百分比(CPPC)
固定成本加獎金(FPIF)

8.招標書可以是合同計劃的輸出

9.對於甲方來說，風險最高的是 CPCC合同類型，風險最低的是 FFP合同類型，乙方則相反

10.某項目採用成本加獎金的成本補償類合同，當預算成本爲 20 萬元，利潤 4 萬元，且獎勵分配爲 80/20 時，如果實際成本降至 16 萬元，則項目總價爲

項目總價=成本+獎金（節約成本 * 20%）+利潤=16+（節約成本=20-16=4）4 * 20%+4=20.8萬

11.合同是需要靠（相關法律法規）約束的

12.項目預計成本 10 萬，成本百分比 20%，如實際成本 8 萬，則合同金額：

8+20%*8=9.6

13.成本加獎金合同，激勵比 80/20; 估計成本 12 萬，利潤 1 萬。如實際成本 12 萬，則合同金額爲： 12+1=13 萬；如實際成本爲 11 萬，則合同金額爲

11+1+（12-11）20%=12.2

第十三章項目集成計劃

1.軟件項目管理最終要的 4 個要素是：

範圍
質量
進度
成本

2.質量和成本成一定的正比關係,進度和成本成一定的反比關係,範圍和成本成一定的正比關係

3.爲了加快項目進度，可以適當見減低過程中的質量標準

4.項目集成管理包括:

對計劃的集成管理和項目跟蹤控制的集成管理
保證項目各要素協調
在相互影響的項目目標和方案中做出權衡
沒有軟件設計文檔

5.設成本 C 是範圍 S、質量 Q、進度 T的一個函數 C=F（S，Q，T），在成本或時間不充足的情況下，可以通過減小範圍或者（降低質量）來解決。

6.項目管理過程中的進度目標，成本目標，質量目標，範圍目標等各個目標之間是(相互關聯和制約的)

7.軟件項目管理要素:

範圍
質量
成本
不包含交互

8.項目集成計劃的特點：

綜合性
全局性
內外兼顧性
不包含針對性

第十四章項目集成計劃執行控制

1.項目執行控制的基本步驟：

1）建立計劃標準； 2）觀察項目的性能； 3）測量和分析結果； 4）採取必要措施； 5）做好計劃修訂工作，控制反饋。

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

1.軟件項目中的軟件開發成本是總成本的主要部分。

2.當 SV=BCWP-BSWS<0時，表示項目進度落後。

3.代碼評審由一組人對程序進行閱讀、討論和爭議，它是質量控制過程。

4.掙值分析法也稱爲已獲取價值分析，是對項目的實施進度、成本狀態進行績效評估的有效方法。

5.從質量控制圖的控制上限和控制下線，可以知道接受的過程的偏差範圍。

6.範圍控制的重點是避免需求的變更。

7. 一個任務原計劃 3 個人全職工作 2 周完成，而實際上只有 2 個人參與這個任務，到第二週末完成了任務的 50%，則 CPI=？

CPI(成本效能指標)=BCWP(已經完成工作的成本預算)/ACWP（到目前爲止花了多少錢） * 100%
*　ＣＰＩ＞１：低於預算；＝１：按照計劃進行；＜１：超過預算

8.記錄反映當前項目狀態的項目性能數據是控制項目的基礎。

9. 項目進度成本控制的基本目標是在給定的限制條件下，用最短時間、最小成本、以最小風險完成項目工作。

10.代碼走查是在代碼編寫階段，開發人員自己檢查自己的代碼。

11. 在使用應急法壓縮進度時，能夠進行壓縮的只有關鍵路徑。

12. 累計費用曲線中某時間點 ACWP(到目前爲止花了多少錢)比 BCWS（到目前爲止本應該完成的工作是多少）高，意味着在這個時間點爲止，實際的成本要比計劃的高，二者之間的差值就是成本差異。

13. 技術評審的目的是儘早發現工作成果中的缺陷，並幫助開發人員技師消除缺陷，從而有效的提高產品質量。

14. 項目原來預計於 2014.5.23 完成 1000 元的工作，但到 2014.5.23 只完成 850 元工作，而爲了這些工作花費 900 元，則成本偏差和進度偏差分別是

SV(進度差異)=BCWP(到目前爲止實現了多少價值)-BCWS(到目前爲止應該完成多少)
所以SV=850-1000=-150
CV(費用差異)=BCWP(到目前爲止實現了多少價值)-ACWP(到目前爲止花了多少錢)
所以CV=900-850=50

15.如果成本效能指標 CPI=90%，他說明投入 1 元產生 0.9 元的效果

16.進度控制重要的一個組成部分是確定進度偏差是否需要採取糾正措施

17.資源平衡最好用於（非關鍵路徑）活動

18.當項目進展到（20%）左右時， CPI處於穩定

19.抽樣統計的方法中,以小批量的抽樣爲基準進行檢驗

20.質量控制的3 個要點：

檢查項目結果
依據相關質量標準進行跟蹤檢查
確定消滅質量問題的措施

21.某項目由 1、2、3、4 四個任務構成，該項目目前執行到第 6 週末，各項工作在其工期內的每週計劃成本、每週實際成本和計劃工作量完成情況下表所示：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-8g7YrGmu-1589334555781)(8.png)]

1.根據提供的信息，計算截至第 6 週末該項目的 BCWS、ACWP、BCWP

BCWS=10+15+5+10+10+10+20+10+10+5+5=100;
ACWP=10+16+8+10+10+12+24+12+5+5=112
BCWP=10+15+5+(10+10+10+20+10+10)/2+(5+5+25+5)/2=95

2.計算第 6 週末的成本偏差 CV、進度偏差 SV，說明結果的實際意義

CV=BCWP-ACWP= -17
SV=BCWP-BCWS= -5

3.照目前情況，計算完成整個項目實際需要投入多少資金？寫出計算公式。

CPI=BCWP/ACWP=84%
EAC=BAC/CPI=170/84% = 202

22.某項目正在進行中，下表是項目當前運行狀況的數據，任務 1、2、3、4、5、6 計劃是按順序執行的，表中也給出了計劃完成時間和實際的執行情況。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Pqy65eOI-1589334555782)(9.png)]

1.計算 BAC

BAC=5+25+120+40+60+80=330

2.計算截至 2014 年 4 月 1 日的 BCWP、BCWS、 ACWP、 SV、SPI 、 CV、CPI等指標。

BCWP=5+25+40=70
BCWS=10+20=30
ACWP=10+20+50=80
SV=BCWP-BCWS=40
SPI=BCWP/BCWS=175%
CV=BCWP-ACWP=-10
CPI=BCWP/ACWP=87.5%

23.試述 Pareto 規則

80%的問題是由 20%的原因引起。

第十六章項目輔助計劃執行控制

1.項目周例會是一種正式溝通方式。

2.在馬斯洛的需求層次理論中，最高層需求是自我實現。

3. Y理論屬於參與理論

4.風險管理是連續的過程。

5.管理干係人蔘與和控制干係人蔘與都是干係人管理的任務。

6.敏捷生存期模型中的每天站立會議是很有效的一種溝通方式。

7.對於衝突而言，衝突常常是有利的事情

8.項目培訓特點：

時間短
針對性強
見效快

9.衝突解決方法:

解決問題（ confrontationorproblemsolving ）
妥協（ compromise ）
強迫方式（ forcingmode ）
撤退（ withdrowal ）

10.項目中的小組成員要同時離開公司，項目經理首先應該（實施風險計劃）。

11.一個軟件項目團隊中一般有哪些人員角色？

項目經理、架構分析師、系統分析師、 DBA、程序開發人員、測試人員、系統工程師、
質量管理人員

十七章項目結束過程

1.項目目標已經成功實現，可交付成果已經出現；或者項目無法繼續進行，這時項目可以終止了。

2.項目結束過程包括

制定結束計劃
完成收尾工作
項目最後評審。

3.是否在預算成本內完成項目、是否實現目標、是否達到項目客戶的期望等都是檢驗項目成功與失敗的標準。

4. 項目驗收過程是甲方對乙方交付的產品或服務進行驗收檢驗，以保證它滿足合同條款的要求。

5. 項目計劃中確定的可交付成果已經出現，項目的目標已經成功實現時，可終止項目。

6.一個項目的交付驗收，意味着項目的結束

7.當一個項目的目標已經實現，或者明確看到目標已經不可能實現時，項目就應該終止。

8. 客戶接受項目的交付結果之前，項目經理應該檢查交付結果的質量

9.不包括在項目驗收過程中的是項目總結

10.項目終止的條件:

項目計劃中確定的可交付成果已經出現，項目的目標已經成功實現
項目已經不具備實用價值
項目由於各種原因而導致無限期拖長
不包括項目需求發生了變化

11.項目成功與失敗的標準是：

是否實現目標
可交付成功如何
是否達到項目客戶的期望
不包括項目人數龐大

軟件項目管理筆記