1. 程式人生 > >軟體專案管理考前複習資料

軟體專案管理考前複習資料

可以直接進入的github上面下載試卷,課後答案,以及對應的筆記總結,點選進入

第一章.軟體專案管理概述

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+4
6+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.0
50
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.1
L)的0.36次方 =(4.112.75)的 0.36次方 ≈10.25(月)
人員需求量 S=(0.54
E)的 0.6次方 =0.5452.725的0.6次方 ≈5.829(人)
文件數量 DOC=49
L 的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(箭線法)網路圖。

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

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


標準差:δ=(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?(繪製決策樹)


EMV:損益期望值
公式:EMV=(outcome(回報)*成功概率-虧本 * 虧本概率)
EMV=(50000 * 30%-10000 * 70%) =8000

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


第十二章軟體專案合同計劃

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%
* CPI>1:低於預算 ;=1:按照計劃進行;<1:超過預算

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 週末,各項工作在其工期內的每週計劃成本、每週實際成本和計劃工作量完成情況下表所示:

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 計劃是按順序執行的,表中也給出了計劃完成時間和實際的執行情況。

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.專案成功與失敗的標準是:

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

12. 在專案的末期,與賣方的合同還有尚未解決的索賠,專案經理(進行合同收尾,合同收尾之後,可能採取法律行動)。