系統(tǒng)集成項目管理工程師真題案例分析報告

1、. .36/36系統(tǒng)集成項目管理工程師教程知識體系基礎知識信息化基礎（第 1 章）信息系統(tǒng)服務管理（第 2 章）信息系統(tǒng)集成專業(yè)技術知識（第 3 章）項目管理一般知識（第 4 章）核心知識域整體管理（第 6 章）圍管理（第 7 章）進度管理（第 8 章）成本管理（第 9 章）質(zhì)量管理（第 10 章）信息安全管理（第 17 章）保障域人力資源管理（第 11 章）合同管理（第 13 章）采購管理（第 14 章）信息（文檔）安全管理（第 15 章）風險管理（第 18 章）知識產(chǎn)權管理（第 20 章）法律法規(guī)標準規(guī)（第 21 章）職業(yè)道德規(guī)（第 22 章）伴隨域溝通管理（第 12 章）變更管理（第 1

2、6 章）過程域：科研與立項、啟動、計劃、執(zhí)行、監(jiān)控、收尾項目立項管理（第 5 章）項目收尾管理（第 19 章）一般說來，要把一個項目管理好，至少需要 4 種過程：（1） 技術類工作技術過程要解決“研制特定產(chǎn)品，完成特定成果或提交特定服務的具體技術過程”，要回答怎么在技術上完成？如：信息系統(tǒng)項目的技術過程有需求分析、總體設計、編碼、測試、維護、布線、組網(wǎng)等。（2） 管理類工作按出現(xiàn)得時間先后劃分，管理過程可以被分為啟動、計劃、執(zhí)行、監(jiān)控和收尾過程。（3） 支持類工作配置管理（4） 改進類工作總結經(jīng)驗教訓、部署改進等過程。3第 2 章 信息系統(tǒng)服務管理案例一（IT 服務， 2011 上 試題五）說

3、明 某系統(tǒng)集成企業(yè)最近與某法院信息中心簽訂了一個法院綜合信息系統(tǒng)運維項目合同，并簽訂了服務級別協(xié)議，對服務容和具體要求進行了約定。協(xié)議中要求運維項目從解決問題過程到控制問題過程與發(fā)布過程要與法院服務管理流程很好的銜接，并建立服務臺。而法院信息中心對系統(tǒng)的運維管理非常重視，于2010 年10 月通過ISO20000 的認證。該系統(tǒng)集成企業(yè)的小被任命為該運維項目的項目經(jīng)理。小如何運用學到的項目管理和IT 服務管理方面的知識做好流程梳理和隊伍建設對管理好該項目至關重要。問題 1（5 分）結合本案例，判斷下列選項的正誤（填寫在答題紙的對應欄，正確的選項填寫“”，錯誤的選項填寫“”）（1） GB/T24

4、405.1-2009 與ISO20000.1-2005 容是一致的。（）（2）該運維合同與服務級別協(xié)議沒有關系。 （）（3）服務級別協(xié)議中的服務響應時間是決定服務收費的主要依據(jù)之一。（）（4）運維服務中配置管理完全是系統(tǒng)集成企業(yè)的責任。（）（5）服務臺就是熱線。（）問題 2（3 分）按照 IT 服務管理規(guī)，請指出控制過程和發(fā)布過程包含哪些容。問題 3（3 分）小在流程梳理的前期調(diào)研時，發(fā)現(xiàn)某員工不能發(fā)送。該問題處置過程往往要經(jīng)過：問題提出服務臺記錄問題工程師調(diào)查問題解決問題如果該現(xiàn)象經(jīng)常出現(xiàn)要調(diào)查原因批準和更新設施或軟件。按照IT 服務管理規(guī)，請選擇恰當選項按照順序填入空白處，構成IT 服務管

5、理流程。（1）服務臺（2） _ （3） _ （4）變更管理（5） _備選項： A. 事件管理 B. 能力管理 C. 問題管理 D. 服務報告 E. 發(fā)布管理問題 4（4 分）請簡述 IT 服務管理的業(yè)務價值。答：問題 1（1） （2） （3） （4） （5）問題 2（1）控制過程組：包括配置管理、變更管理。（2）發(fā)布過程組：包括發(fā)布管理。問題 3（2） A （3） C （4） E問題4(1) 確保 IT 流程支撐業(yè)務流程，整體上提高了業(yè)務運營的質(zhì)量；(2) 通過事故管理流程、變更管理流程和服務臺等提供了更可靠的業(yè)務支持；(3) 客戶對 IT 有更合理的期望，并更加清楚為達到這些期望他們所需要的

6、付出；(4) 提高了客戶和業(yè)務人員的生產(chǎn)率；(5) 提供更加與時有效的業(yè)務持續(xù)性服務；(6) 客戶和 IT 服務提供者之間建立更加融洽的工作關系；(7) 提高了客戶滿意度。4第 4 章 項目管理一般知識案例一（項目的組織結構、管理流程、進度計劃）閱讀下面敘述，回答問題 1 至問題 3，將解答填入答題紙的對應欄。說明某系統(tǒng)集成商 B 最近正在爭取某鋼鐵公司 A 的辦公網(wǎng)絡遷移到外地的項目。某是系統(tǒng)集成商 B 負責捕捉項目機會的銷售經(jīng)理，鮑某是系統(tǒng)集成商 B 負責實施的項目經(jīng)理。由于以往項目銷售經(jīng)理的過度承諾給后繼的實施工作帶來了很大困難，此次鮑某主動為該項目做售前支持。該辦公網(wǎng)絡遷移項目的工作包

7、括鋼鐵公司 A 新辦公樓的綜合布線、局域網(wǎng)絡系統(tǒng)升級、機房建設、遠程視頻會議系統(tǒng)、生產(chǎn)現(xiàn)場的閉路監(jiān)控系統(tǒng)等 5 個子系統(tǒng)。鋼鐵公司 A 對該項目的招標工作在 2006 年 8 月 4 日開始。該項目要求在 2006 年 12 月 29 日完成，否則將嚴重影響鋼鐵公司 A 的業(yè)務。 時間已到2006 年 8 月 8 日，鋼鐵公司 A 希望系統(tǒng)集成商 B 能在 8 月 15 日前能夠提交項目建議書。鋼鐵公司 A 對項目的進度非常關注，這是他們選擇集成商的重要指標之一。根據(jù)經(jīng)驗、鋼鐵公司 A 的實際情況和現(xiàn)有的資源，鮑某組織制定了一個初步的項目計劃，通過對該計劃中項目進度的分析預測，鮑某認為按正常流

8、程很難達到客戶對進度的要求。擬訂的合同中將規(guī)定對進度的延誤要處以罰款。但是銷售經(jīng)理某則急于贏得合同，希望能在項目建議書中對客戶做出明確的進度保證，首先贏得合同再說。鮑某和某在對項目進度承諾的問題上產(chǎn)生了分歧，某認為鮑某不幫助銷售拿合同，鮑某認為某亂承諾對以后的項目實施不負責任。本著支持銷售的原則，鮑某采取了多種措施， 組織制訂了一個切實可行的進度計劃，雖然其報價比競爭對手略高，但評標委員會認為該方案有保證，是可行的，于是系統(tǒng)集成商 B 中標。系統(tǒng)集成商 B 中標后，由其實施部負責項目的實施。問題 1（7 分） 在制訂進度計劃時，鮑某可能會采取哪些措施使制訂的進度計劃滿足客戶的要求？問題 2（5

9、 分）實施項目的系統(tǒng)集成商 B 目前的組織類型是什么？如何改進其項目的組織方式？如何改進其項目管理的流程？如何降低管理外地項目的成本？問題 3（3 分） 在項目實施過程中，負責售前工作的某應繼續(xù)承擔哪些工作？答題思路：問題 1(1) 溝通，強調(diào)該項目對系統(tǒng)集成商 B 的重要意義，提高項目優(yōu)先級。使用開會方式爭取相關部門的建議、支持和承諾。(2) 從現(xiàn)有資源和實際情況出發(fā)， 優(yōu)化網(wǎng)絡圖，如重新安排活動之間的順序，壓縮關鍵路徑長度。(3) 增加資源，引入經(jīng)驗豐富的員工(4) 并行，在現(xiàn)有資源下，子任務并行，部流程優(yōu)化。(5) 趕工，項目員工通過加班來加快項目進度(6) 盡可能地調(diào)配非關鍵路徑上的資

10、源用于關鍵路徑上的任務(7) 優(yōu)化外包，采購等環(huán)境并全程監(jiān)控問題 2(1) 系統(tǒng)集成商 B 的組織方式是職能式的。（補充：組織方式有 4 種職能型、項目型、5矩陣型、復合型）(2) 系統(tǒng)集成商 B 的組織方式應該改為矩陣型。(3) 最好的辦法是項目下階段的人員提前介入到前一階段，如在項目的售前階段，負責項目實施的項目經(jīng)理正式參與售前工作。 另外，做好項目實施流程間的交接工作，如建立一套完整的項目售前和項目實施階段之間的交接規(guī)和要求包括文檔、培訓、合同等容。(4) 委托、 分包給當?shù)赜匈Y質(zhì)的集成商，或在當?shù)卣腥?。如果材料和服務在當?shù)夭少徔山档统杀?。壓低人員差旅費，事宜虛擬遠程的溝通和售后服務手段

11、。問題 3(1) 與客戶高層溝通，了解客戶對項目實施情況的反映，維護客戶關系，發(fā)掘新的項目機會。(2) 參加周例會，或至少每周首一次周報以了解項目的進展和問題。案例二（項目的組織結構、項目經(jīng)理與職能經(jīng)理的工作）系統(tǒng)集成項目管理工程師教程 第 23 章-案例分析 23.1.7案例場景某軟件公司以產(chǎn)品開發(fā)和項目為其主要業(yè)務。公司目前發(fā)展勢頭良好，正在建設的項目有 5 個左右，已經(jīng)立項的有 10 個左右，還有若干項目正處于驗收和后期維護階段。公司實行的是強矩陣式管理模式，專職的項目經(jīng)理往往一個人帶多個項目，職能部門的部也有擔任項目經(jīng)理工作的人員。但是，資源的調(diào)配成了項目經(jīng)理、職能部門經(jīng)理在項目實施過

12、程中最棘手的問題。項目經(jīng)理每個人都身兼數(shù)職，對項目進度難以控制，而多數(shù)項目在進行時，資源的調(diào)配是由各個職能部門經(jīng)理安排的，職能部門經(jīng)理對質(zhì)量進行監(jiān)督，項目經(jīng)理要做進度控制，可是卻沒有分配資源的權力，從而引發(fā)出關于公司部管理流程和職責定位的問題。問題 在強矩陣式管理模式下，項目經(jīng)理與職能部門經(jīng)理對公司資源的調(diào)用如何協(xié)調(diào)？答題思路：1、強矩陣型組織結構的特點是：它具有很多項目型組織的特征，具有擁有很大職權的專職項目經(jīng)理和專職項目行政管理人員。2、 在強矩陣組織中，為協(xié)調(diào)項目經(jīng)理和職能部門經(jīng)理的權責，應：2.1 在公司管理思想和原則上，明確矩陣型組織的特征： 能夠以項目為導向 有了客戶問題處理中心

13、協(xié)調(diào)工作由項目管理隊伍承擔 能夠明確責任 資源來自各職能部門，并且這些資源可在不同項目中共享 專業(yè)人員在技術上可相互支持 各專業(yè)員工組織上仍歸屬其職能部門，因此項目結束后，員工“有家可歸”2.2 在公司制度上，明確職能部門和項目經(jīng)理之間的權責分配關系：資源、人員日常歸職能部門經(jīng)理管理和考核；6在項目實施期間， 人員、資源由項目經(jīng)理全權管理和考核；2.3 建立一個清晰的項目管理流程，明確項目經(jīng)理在項目實施期間的權力和責任；定義了相關人員和相關部門在項目活動中的工作圍、工作過程和職責。這個流程一般由項目管理部門起草，經(jīng)過相關部門討論修改，最終由項目管理部門、相關職能部門審批，最后由公司管理層終批生

14、效。例如：嚴格加強項目章程的規(guī)性和嚴肅性，任命項目經(jīng)理的必要性項目所需資源，由項目經(jīng)理提出申請，職能經(jīng)理負責委派人員；項目實施期間的考核由項目經(jīng)理負責，項目結束后，人員回到職能部門，考核容也轉交給職能經(jīng)理，最終由職能經(jīng)理負責全部考核項目管理部經(jīng)理和資源部門經(jīng)理對等處理項目過程中項目目標和資源提供的決策問題；2.4 在項目工作安排方面，特別注意管理好各個接口，如項目成員之間或部門之間的工作交接，技術交接、資源交接2.5 加強項目溝通，適量增加項目信息收集、整理、分析和發(fā)布的頻次，這樣能與時發(fā)現(xiàn)項目問題，利于與時采取糾正措施。可以通過電子等手段，與時將項目進展情況、存在的問題和糾正措施通報給全體項

15、目成員、不要忘記抄送給項目成員所屬部門的經(jīng)理，如果有必要，甚至抄送給公司管理層。補充： 組織結構對項目的影響項目特點 職能型組織矩陣型組織項目型組織弱矩陣型組織 平衡矩陣型組織 強矩陣型組織項目經(jīng)理的權利 很小或沒有 有限 小 中等 中等 大 大 全權組織中全職參與項目沒有 0 25 15 60 50 95 85 100工作的職員比例（%）項目經(jīng)理的職位 部分時間 部分時間 全時 全時 全時項目經(jīng)理的一般頭銜項目協(xié)調(diào)員 項目協(xié)調(diào)員 項目經(jīng)理 項目經(jīng)理 項目經(jīng)理/項目主管 /項目主管 /項目主任 /計劃主任 /計劃主任項目經(jīng)理行政人員 部分時間 部分時間 部分時間 全時 全時案例三（項目生命周期

16、模型 2009 上 試題五）閱讀下列說明，回答問題 1 至問題 3。將解答填入答題紙的對應欄。說明小是一位優(yōu)秀的軟件設計師，負責過多項系統(tǒng)集成項目的應用開發(fā)，現(xiàn)在公司因人手緊，讓他作為項目經(jīng)理獨自管理一個類似的項目，他使用瀑布模型來管理該項目的全生命周期，如下所示：項目進行到實施階段，小發(fā)現(xiàn)在系統(tǒng)定義階段所制訂的項目計劃估計不準，實施階段有許多原先沒有估計到的任務現(xiàn)在都冒了出來。項目工期因而一再延期，成本也一直超出。問題 1（6 分）根據(jù)項目存在的問題，請簡要分析小在項目整體管理方面可能存在的問題。問題 2（6 分）（1）請簡要敘述瀑布模型的優(yōu)缺點。7（2）請簡要敘述其他模型如何彌補瀑布模型的

17、不足。問題 3（3 分）針對本案例，請簡要說明項目進入實施階段時，項目經(jīng)理小應該完成的項目文檔工作？問題 11.軟件設計師小第一次擔任項目經(jīng)理，獨立管理一個項目，缺乏項目整體管理經(jīng)驗和技能；2.小選取瀑布模型作為項目整體管理的生命周期模式，缺乏科學的論證和系統(tǒng)的評估，開發(fā)模型的選取沒有進行可行性分析和論證；3.在系統(tǒng)論證階段制定項目整體計劃時，對進度計劃沒有采用科學的方法，如類比估算法，專家判斷，三點估算，應急時間等。4.對項目需求和功能沒有進行嚴格的需求分析、圍定義；5.在項目圍上沒有制定 WBS，規(guī)劃項目實施圍；6.小沒有對項目圍進行嚴格的圍確認；導致項目圍界定不清7.實施階段，沒有對項目

18、圍進行圍控制，遵循規(guī)的圍變更控制管理，導致圍蔓延問題 2 書上 162 頁1、 瀑布模式的優(yōu)點：階段劃分次序清晰，各階段人員的職責規(guī)、明確，便于前后活動的銜接，有利于活動重用和管理瀑布模式的缺點：是一種理想性的線性開發(fā)模式，缺乏靈活性（或風險分析），無法解決需求不明確或不準確的問題2、 為彌補瀑布模型的缺點，可采用快速原型法、螺旋模型和迭代模型。（1） 原型法模型，用于解決需求不明確的情況；（2） 螺旋模型， 是一個演化軟件過程模型，將原型實現(xiàn)的迭代特征與線性順序（瀑布）模型中控制的和系統(tǒng)化的方面結合起來。 4 個象限分別標志每個周期的 4 個階段：制定計劃、風險分析、實施工程和客戶評估。 該

19、模型強調(diào)風險分析，特別適合龐大而復雜的、高風險的系統(tǒng)。（3） 迭代模型：每個階段都執(zhí)行一次傳統(tǒng)的、完整的串行過程串，執(zhí)行一次過程串就是一次迭代，每次迭代涉與的過程都包括不同比例的所有活動。問題 3小在項目實施階段應完成的文檔，分兩大類：1.項目管理過程文檔(1) 項目進度計劃（變更）(2) 項目績效報告(3) 項目會議記錄(4) 項目圍（變更）說明書(5) 變更控制文檔(6) 質(zhì)量分析報告(7) 風險評估報告等等。2.項目產(chǎn)品實現(xiàn)文檔(1) 概要設計說明書8(2) 詳細設計說明書(3) 代碼規(guī)(4) 程序編碼設計書(5) 數(shù)據(jù)庫模型與設計說明書(6) 測試用例(7) 測試報告等等。9第 5 章

20、 立項管理案例一（項目可行性分析 2011 下 試題一）閱讀以下說明，請回答問題1至3，將解答填入答題紙的對應欄。說明某大型企業(yè)集團擬在生產(chǎn)園區(qū)建立一套無線網(wǎng)絡，覆蓋半徑大約1.5公里，要求能夠支持高速數(shù)據(jù)傳輸、無線漫游以與多種類型數(shù)據(jù)業(yè)務等。集團總經(jīng)理責成信息中心主任某負責此事。某找到曾經(jīng)承擔集團部網(wǎng)絡系統(tǒng)工程的系統(tǒng)集成商A公司，提出了集團的需求。 A公司管理層開會研究后命令項目經(jīng)理某積極跟進，與某密切聯(lián)系。某經(jīng)過上網(wǎng)搜索，發(fā)現(xiàn)外企B公司最近推出的一種基于WIMAX技術的無線網(wǎng)絡系統(tǒng)比較符合要求，國外也有類似的成功案例。某親自到B公司的國代理商C公司進行了實地考察， 并在C公司進行了產(chǎn)品演示

21、實驗，感到效果良好。隨后，某和某溝通后， A公司正式與C公司簽訂了采購合同，并很快進行了系統(tǒng)的安裝部署。可是當無線網(wǎng)絡系統(tǒng)正式投入運行后不久，就出現(xiàn)了一系列問題，比如：無線網(wǎng)絡覆蓋存在盲區(qū)，不支持某些類型的數(shù)據(jù)業(yè)務，用戶較多時數(shù)據(jù)傳輸率急劇下降，偶爾發(fā)生莫名其妙的斷網(wǎng)現(xiàn)象，等等。更麻煩的是，當?shù)責o線電管理部門認為他們沒有取得無線電頻使用執(zhí)照，要求該集團立即停止運行該無線網(wǎng)絡，并且要對他們進行處罰。此時C公司傳來消息，稱B公司因為部原因即將退出中國大陸市場，繼續(xù)提供該系統(tǒng)的技術支持服務比較困難。問題1（6分） 在本案例中，某未進行充分的項目可行性研究以致項目出現(xiàn)危機，請指出具體體現(xiàn)在哪些方面（將

22、正確選項對應的字母填入答題紙對應欄，多選扣分）：A.投資必要 B 技術可行性 C財務可行性 D組織可行性 E社會可行性F經(jīng)濟可行性 G風險因素分析與對策問題2（3分） 請簡要列舉進行項目可行性研究的主要步驟。問題3（6分）如果你被A公司任命為該項目的項目經(jīng)理，請用300字以文字簡要敘述你應如何應對目前的困境。答：問題1 B E G問題2項目可行性研究的主要步驟：（1） 初步可行性研究（2） 詳細可行性研究（3） 項目論證（4） 項目評估（5） 項目可行性研究報告的編寫、提交和獲得批準10第 6 章 項目整體（綜合）管理項目整體管理流程圖案例一（項目管理中存在的問題與改進措施）閱讀下列說明，回答

23、問題 1 至問題 3。將解答填入答題紙的對應欄。說明A 公司是一家中小型系統(tǒng)集成公司，在 2006 年 3 月份正在準備對京發(fā)證券公司數(shù)據(jù)大集中項目進行投標， A 公司副總裁某授權銷售部的林某為本次投標的負責人，來組織和管理整個投標過程。 林某接到任務后，召集了由公司商務部、銷售部、客服部和質(zhì)管部等相關部門參加的啟動說明會，并把各自的分工和進度計劃進行了部署。隨后，在投標前 3 天進行投標文件評審時，發(fā)現(xiàn)技術方案中所配置的設備在以前的項目使用中是存在問題的，必須更換，隨后修改了技術方案。最后 A 公司中標并和客戶簽訂了合同。根據(jù)公司的項目管理流程，林某把項目移交到了實施部門，由他們具體負責項目

24、的執(zhí)行與驗收。 實施部門接手項目后，鮑某被任命為實施項目經(jīng)理，負責項目的實施和驗收工作。鮑某發(fā)現(xiàn)由于項目前期自己沒有介入，許多項目前期的事情都不是很11清楚，而導致后續(xù)跟進速度較慢，影響項目的進度。同時鮑某還發(fā)現(xiàn)設計方案存在一些問題，主要有：方案遺漏一項基本需求，有多項無效需求，沒有書面的需求調(diào)研報告；在項目的工期、系統(tǒng)功能和售后服務等方面，存在過度承諾現(xiàn)象。于是項目組重新調(diào)研用戶需求，編制設計方案，這就增加了實施難度和成本?？墒呛髞碛职l(fā)現(xiàn)采購部仍是按照最初的方案采購設備，導致設備中的模塊配置功能不符合要求的情況。 而在 A 集成公司中，類似現(xiàn)象已多次發(fā)生。問題 1（5 分） 針對說明中所描述

25、的現(xiàn)象，分析 A 公司在項目管理方面存在的問題（150 字以）。問題 2（5 分） 針對 A 公司在該項目管理方面存在的問題，提出補救措施（150字以）。問題 3（5 分）針對 A 公司的項目管理現(xiàn)狀，結合你的實際經(jīng)驗，就 A 公司項目管理工作的持續(xù)改進提出意見和建議（150 字以）。答題思路：問題 11、投標前的項目啟動會議上，沒有邀請技術和實施部門2、沒有把以往的經(jīng)驗教訓，歸納和積累，形成組織知識資產(chǎn)3、沒有建立完善的部評審機制，或雖有評審機制但為有效執(zhí)行4、項目中沒有實現(xiàn)有效的變更管理5、公司級的項目管理體系不健全，或執(zhí)行不好問題 21、改進項目的組織形式，明確項目團隊和職能部門之間的協(xié)

26、作關系和工作程序2、做好項目當前的經(jīng)驗教訓收集、歸納工作3、明確項目工作的交付物，建立和實施項目的質(zhì)量評審機制4、建立項目的變更管理機制，識別變更中的利益相關方并加強溝通5、加強對項目團隊成員和相關人員的項目管理培訓問題 31、建立企業(yè)級的項目管理體系和工作規(guī)2、加強對項目工作記錄的管理3、加強項目質(zhì)量和相應的評審制度4、加強項目經(jīng)驗教訓的收集、歸納、積累和分享工作5、引入合適的項目管理工具平臺，提升項目管理工作效率案例二 （項目整體 2009 上 試題四）閱讀下面敘述，回答問題 1 至問題 3，將解答填入答題紙的對應欄。說明H 某公司是一家專門從事 ERP 系統(tǒng)研發(fā)和實施的 IT 企業(yè)，目前

27、該公司正在進行的一個項目是為某大型生產(chǎn)單位（甲方）研發(fā) ERP 系統(tǒng)。某公司同甲方關系比較密切，但也正因為如此，合同簽的較為簡單，項目執(zhí)行較為隨意。同時甲方組織架構較為復雜，項目需求來源多樣而且經(jīng)常發(fā)生變化，項目12圍和進度經(jīng)常要進行臨時調(diào)整。經(jīng)過項目組的艱苦努力，系統(tǒng)總算能夠進入試運行階段，但是由于各種因素，甲方并不太愿意進行正式驗收，至今項目也未能結項。問題 1（6 分）請從項目管理角度，簡要分析該項目“未能結項”的可能原因。問題 2（5 分）針對該項目現(xiàn)狀，請簡要說明為了促使該項目進行驗收，可采取哪些措施。問題 3（4 分）為了避免以后出現(xiàn)類似情況，請簡要敘述公司應采取哪些有效的管理手段

28、。答：問題 11、 缺乏有效的合同管理制度， 案例中簽訂合同很簡單，沒有在合同中明確甲乙雙方的職責，明確項目的時間要求，圍界定以與合同違約等條款和容；2、 沒有嚴格的進度控制、成本控制和質(zhì)量保證、風險分析等管理措施，案例中項目執(zhí)行較隨意，表明其缺乏規(guī)和嚴格的項目管理制度和方法，規(guī)的項目管理流程；3、 針對甲方組織結構復雜，需求多變的情況，沒有進行事前風險分析和制定風險應對措施，對需求沒有進行嚴格的分析、管理措施，對項目圍也沒有進行確定，4、 針對項目圍、進度、成本的變化， 缺乏必要的變更控制手段和規(guī)的變更控制流程。5、 對應項目的不驗收，缺乏有效的溝通管理制度， 缺少和甲方必須的溝通方法和措施

29、，在合同中沒有規(guī)定驗收的標準和程序；6、 對應項目出現(xiàn)的情況， 缺少應急措施和有效的針對性方法，來解決項目當前的困難。問題 21、 加強和甲方的溝通，針對項目驗收的工作容和方式，流程、時間等問題，積極和甲方進行溝通，爭取和甲方就項目驗收工作達成一致意見；2、 針對合同中沒有明確的驗收標準和流程等問題，可以采用備忘錄或者補充協(xié)議的形式，就項目驗收的標準、流程、時間和責任人等容簽署書面的具有法律效力的文件，以便指導項目驗收工作。3、 在項目組部，加強項目管理工作力度，制定驗收文檔標準，積極準備驗收工作，完善驗收成果文檔，明確項目驗收工作的標準和流程，以與團隊成員的職責。問題 31、 公司應該建立嚴

30、格和規(guī)的合同管理制度，簽訂合同時必須在合同中明確項目的圍、進度以與相關要求，建立完善的合同文本；2、 公司部應該建立規(guī)和完善的項目管理制度，在項目管理上建立合規(guī)的管理流程、方法和標準規(guī)，推行科學的項目管理方法，包括圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理方面；3、 在公司部加強項目管理思想和方法的培訓， 建立全員的、全面的、全過程的項目管理體系和標準。4、 在項目立項時，建立科學和嚴謹?shù)捻椖靠尚行苑治龊驼撟C制度，進行風險分析和風險評估，規(guī)避項目風險。5、 建立良好的溝通機制；136、 引入監(jiān)理機制；7、 做好有效的變更控制。案例三 （項目整體 2010 上 試題四）說明老陸是某系統(tǒng)集

31、成公司資深項目經(jīng)理，在項目建設初期帶領項目團隊確定了項目圍，后因工作安排太忙，無暇顧與本項目，于是他要求：（1） 本項目各小組組長分別制定組成項目管理計劃的子計劃；（2） 本項目各小組組長各自監(jiān)督其團隊成員在整個項目建設過程中子計劃的執(zhí)行情況；（3） 項目組成員堅決執(zhí)行子計劃，且原則上不允許修改。在執(zhí)行三個月后，項目經(jīng)常出現(xiàn)各子項目間無法順利銜接，需要大量工時進行返工等問題，目前項目進度已經(jīng)遠遠滯后于預定計劃。問題 1（4 分）請簡要分析造成項目目前狀況的原因。問題 2（6 分）請簡要敘述項目整體管理計劃應包含哪些容？問題 3（5 分）為了完成該項目，請從整體管理的角度說明老陸和公司可采取哪些

32、補救措施？答：問題 1(1) 項目缺少整體計劃。本案例中的做法只完成了項目管理計劃中的子計劃，并沒有形成真正的項目整體管理計劃，即確定、綜合與協(xié)調(diào)所有子計劃所需要的活動，并形成文件。(2) 項目缺少整體的報告和監(jiān)控機制，各項目小組各自為政。(3) 項目缺少整體變更控制流程和機制。管理計劃本身是通過變更控制過程進行不斷更新和修訂的，不允許修改是不切合實際的。問題 2(1) 所使用的項目管理過程。(2) 每個特定項目管理過程的實施程度。(3) 完成這些項目的工具和技術的描述。(4) 選擇的項目的生命周期和相關的項目階段。(5) 如何用選定的過程來管理具體的項目。包括過程之間的依賴與交互關系和基本的

33、輸入輸出等。(6) 如何執(zhí)行流程來完成項目目標。(7) 如何監(jiān)督和控制變更更。(8) 如何實施配置管理。(9) 如何維護項目績效基線的完整性。(10) 與項目干系人進行溝通的要求和技術。(11) 為項目選擇的生命周期模型，對于多階段項目，要包括所定義階段是如何劃分的。14(12) 為了解決某些遺留問題和未定的決策，對于其容、嚴重程度和緊迫程度進行的關鍵管理評審。問題 3(1) 建立整體管理機制。老陸應分配更多的精力來進行項目管理，或由其他合適的人員來承擔整體管理的工作。(2) 理清各子項目組目前的工作狀態(tài)。例如其工作進度、成本、資源配置等。(3) 重新定義項目的整體管理計劃，并與各子項目計劃建

34、立明確關聯(lián)。(4) 按照計劃要求，重新進行資源平衡。(5) 建立或加強項目的溝通、報告和監(jiān)控機制。(6) 加強項目的整體變更控制。15第 7 章 項目圍管理項目圍管理流程圖（5 過程）案例一（圍管理 教程 p518 23.2.1）系統(tǒng)集成項目管理工程師教程 第 23 章-案例分析 23.2.1 p518M 公司原本是一家專注于企業(yè)信息化的公司，在電子政務如火如荼的時候，開始進軍電子政務行業(yè)，在電子政務的市場中，接到的第一個項目是開發(fā)一套工商審批系統(tǒng)。由于電了政務要求，該系統(tǒng)涉與到兩個互不聯(lián)通的子網(wǎng)：政務網(wǎng)和政務外網(wǎng)。政務網(wǎng)中儲存著全部信息，其中包括部分信息；政務外網(wǎng)可以對公眾開放，開放的信息必

35、須得到授權。系統(tǒng)要求在這兩個了網(wǎng)中的合法用戶都可以訪問到被授權的信息.訪問的信息必須是一致可靠，政務網(wǎng)的信息可以發(fā)布到政務外網(wǎng)，政務外網(wǎng)的信息在經(jīng)過審批后可以進入政務網(wǎng)系統(tǒng)。工是該項目的項目經(jīng)理，在捕獲到這個需求后認為電子政務建設與企業(yè)信息化有很大的不同，有其自身的特殊性，若照搬企業(yè)信息化原有的經(jīng)驗和方案必定會遭到慘敗。因此采用了嚴格爆布模型，并專門招聘了熟悉網(wǎng)絡互通互聯(lián)的技術人員設計了解決方案，在經(jīng)過嚴格評審后實施。在項目交付時，雖然系統(tǒng)完全滿足了性的要求，但用戶對系統(tǒng)用戶界面提出了較大的異議，認為不符合政務信息系統(tǒng)的風格，操作也不夠便捷，要求徹底更換，由于最初設計的缺陷，系統(tǒng)表現(xiàn)層和邏輯層

36、緊密耦合，導致 70%的代碼重寫，而第二版的用戶界面仍不能滿足最終用戶的要求，最終又重寫部分代碼才通過駛收，由于系統(tǒng)的反復變更，項目組成員產(chǎn)生了強烈的挫折感，士氣低落，項目工期也超出原計劃的 100%。16問題 1（5 分）請不超過 150 字，對工的行為進行點評?問題 2（5 分）請從項目圍管理的角度找出該項目實施過程中的主要管理問題？不超 150 字問題 3（5 分）請結合你本人實際項目經(jīng)驗，指出應如何避免類似問題?不超過 150 字問題 1請對工的行為進行點評？工作的優(yōu)點：1、認識到電子政務建設與企業(yè)信息化建設的不同，考慮到了項目的獨特性的特征；2、針對業(yè)務需求中對網(wǎng)、外網(wǎng)的互聯(lián)互通的要

37、求，針對性招聘了網(wǎng)絡互聯(lián)互通的技術人員；3、滿足了用戶性的要求；工作的缺點：1、采用“瀑布模式”的項目生命周期，沒有進行論證，武斷；2、用戶需求調(diào)研的不全面，忽視了系統(tǒng)頁面的需求；并且，進行第二版修正時，沒有針對頁面的需求修改進行確認。3、設計方案沒有進行驗證；表現(xiàn)層耦合的業(yè)務邏輯，增加了修改的代價；4、團隊管理措施不力，成員產(chǎn)生挫折感；問題 2請從項目圍管理的角度找出該項目實施過程中的主要管理問題。1、 沒有建立規(guī)的項目圍管理流程和制度。2、 圍定義和需求分析時，工作不細致，忽視了 B/S 架構下的頁面需求3、 需求圍變更中，沒有對頁面變更進行“確認”，就修改代碼問題 3答題的思路和提綱，請

38、將下列答題點細化1、 針對甲方的需求，制定實用的項目圍管理計劃；2、 做好圍定義工作（詳細列出方法）3、 做好需求分析工作（方法、過程、工作步驟）4、 重視圍確認（方法）5、 嚴格圍變更（變更流程）6、 建立完善的項目圍管理制度和規(guī)的圍管理流程案例二（需求評審 教程 p514 23.1.5）系統(tǒng)集成項目管理工程師教程 p514 第 23 章-案例分析 23.1.5答： 1、軟件需軟件開發(fā)的最重要的一個輸入，需求風險也常常是軟件開發(fā)過程中最大的一個風險，降低需求風險的一個重要手段就是需求評審，但是需求評審是所有的評審活動中最難的一個，也是最容易被忽視的一個評審。2 以上的現(xiàn)象可以在很多項目中都可

39、以看到。概括起來，在需求評審中常見的問題是：17 需求報告很長，短時間評審者根本就不能把需求報告讀懂，想清楚； 沒有作好前期準備工作，需求評審的效率很低； 需求評審的節(jié)奏無法控制； 找不到合格的評審員，與會的評審員無法提出深入的問題；3 問題所在：評審缺乏有效依據(jù)和規(guī)，不能保證評審的覆蓋率和有效性。產(chǎn)品經(jīng)理沒有把握好會議主題，評審變成了頭腦風暴。目標性需求沒有溝通好，后面的需求變成空中樓閣。缺乏評審的可操作依據(jù)，遺漏評審容。沒有作好前期準備工作，導致評審時間長，效率低。沒有選擇合適的評審人員，無法獲得有價值的反饋。參加人員過多，容易陷入細枝末節(jié)的討論，會議演變成一場人人自由的混戰(zhàn)。4 那么究竟

40、如何做好需求評審呢？建議一：分層次評審我們知道用戶的需可以分層次的，一般而言可以分成如下的層次：目標性需求：定義了整個系統(tǒng)需要達到的目標；功能性需求：定義了整個系統(tǒng)必須完成的任務；操作性需求：定義了完成每個任務的具體的人機交互；目標性需企業(yè)的高層管理人員所關注的，功能性需企業(yè)的中層管理人員所關注的，操作性需企業(yè)的具體操作人員所關注的。對不同層次的需求，其描述形式是有區(qū)別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會很容易地導致“撿了芝麻，丟了西瓜”的現(xiàn)象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費或者就會出現(xiàn)案例三的情形。建議二：正式評審與非正

41、式評審結合正式評審是指通過開評審會的形式，組織多個專家，將需求涉與到的人員集合在一起，并定義好參與評審人員的角色和職責，對需求進行正規(guī)的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子、文件匯簽甚至是網(wǎng)絡聊天等多種形式對需求進行評審。 2 種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發(fā)現(xiàn)問題。因此在評審時，應該更靈活地利用這 2 種方式。建議三：分階段評審應該在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。分階段評審可以將原本需要進行的大規(guī)模評審拆分成各個小規(guī)模的評審，降低了需求返工的風險，提高了評審的質(zhì)量

42、。比如可以在形成目標性需求后進行一次評審，在形成系統(tǒng)的初次概要需求后進行一次評審，當對概要需求細分成幾個部分，對每個部分進行各個評審，最終再對整體的需求進行評審。建議四：精心挑選評審員18需求評審可能涉與的人員包括：需方的高層管理人員、中層管理人員、具體操作人員、 IT 主管、采購主管；供方的市場人員、需求分析人員、設計人員、測試人員、質(zhì)量保證人員、實施人員、項目經(jīng)理以與第三方的領域專家等等。在這些人員中由于大家所處的立場不同，對同一個問題的看法是不一樣的，有些觀點是和系統(tǒng)的目標有關系的，有些是關系不大的，不同的觀點可能形成互補的關系。為了保證評審的質(zhì)量和效率，需要精心挑選評審員。首先要保證使

43、不同類型的人員的都要參與進來，否則很可能會漏掉了很重要的需求。其次在不同類型的人員中要選擇那些真正和系統(tǒng)相關的，對系統(tǒng)有足夠了解的人員參與進來，否則很可能使評審的效率降低或者最終不切實際的修改了系統(tǒng)的圍。建議五：對評審員進行培訓在很多情況下，評審員是領域專家而不是進行評審活動的專家，他們沒有掌握進行評審的方法、技巧、過程等，因此需要對評審員進行，同樣對于主持評審的管理者也需要進行培訓，以便于參與評審的人員能夠緊緊圍繞評審的目標來進行，能夠控制評審活動的節(jié)奏，提高評審效率，避免發(fā)生案例一和案例二中出現(xiàn)的現(xiàn)象。對評審員的培訓也可以區(qū)分為簡單培訓與詳細培訓 2 種。簡單培訓可能需要十幾分鐘或者幾十分

44、鐘，需要將在評審過程中的需要把握的基本原則，需要注意的常見問題說清楚。詳細培訓則可能要需要對評審的方法、技巧、過程進行正式的培訓，需要花費較長的時間，是一個獨立的活動。需要注意的是被評審人員也要被培訓。建議六：充分利用需求評審檢查單需求檢查單是很好的評審工具，需求檢查單可以分成 2 類：需求形式的檢查單和需求容的檢查單。需求形式的檢查可以由 QA 人員負責，主要是針對需求文擋的格式是否符合質(zhì)量標準來提出的，需求容的檢查是由評審員負責的，主要是檢查需求容是否達到了系統(tǒng)目標、是否有遺漏、是否有錯誤等等，這是需求評審的重點。檢查單可以幫助評審員系統(tǒng)全面地發(fā)現(xiàn)需求中的問題，檢查單也是隨著工程財富的積累

45、逐漸豐富和優(yōu)化的。建議七：建立標準的評審流程對正規(guī)的需求評審會需要建立正規(guī)的需求評審流程，按照流程中定義的活動進行規(guī)的評審過程。比如在評審流程定義中可能規(guī)定評審的進入條件，評審需要提交的資料，每次評審會議的人員職責分配，評審的具體步驟，評審通過的條件等等。通過評審流程執(zhí)行可能會避免出現(xiàn)案例五之類的問題。建議八：做好評審后的跟蹤工作在需求評審后，需要根據(jù)評審人員提出的問題進行評價，以確定哪些問題是必須糾正的，哪些可以不糾正，并給出充分的客觀的理由與證據(jù)。當確定需要糾正的問題后，要形成書面的需求變更的申請，進入需求變更的管理流程，并確保變更的執(zhí)行，在變更完成后，要進行復審。切忌評審完畢后，沒有對問

46、題進行跟蹤，而無法保證評審結果的落實，使前期的評審努力付之東流。建議九：充分準備評審評審質(zhì)量的好壞很大程度上取決于在評審會議前的準備活動。常出現(xiàn)的問題是，需求文檔在評審會議前并沒有提前下發(fā)給參與評審會議的人員，沒19有留出更多更充分的時間讓參與評審的人員閱讀需求文檔。更有甚者，沒有執(zhí)行需求評審的進入條件，在評審文檔中存在大量的低級的錯誤或者沒有在評審前進行溝通，文檔中存在方向性的錯誤，從而導致評審的效率很低，質(zhì)量很差。對評審的準備工作，也應當定義一個檢查單，在評審之前對照檢查單落實每項準備工作。案例三（圍管理 2009 下 試題二）閱讀下列說明，針對項目的圍管理，回答問題 1 至問題 3，將解

47、答填入答題紙的對應欄。說明C 公司是一家從事電子商務的外國公司，為了在中國開展業(yè)務，派出 S 主管和 W翻譯來中國尋找合適的系統(tǒng)集成商，試圖在中國建設一套業(yè)務系統(tǒng)。 S 主管精通軟件開發(fā)，但是不懂漢語，而 W 翻譯對計算機相關技術知之甚少。W 翻譯通過中國朋友介紹，找到了從事系統(tǒng)集成的 H 公司。 H 公司指派工為該業(yè)務系統(tǒng)建設項目經(jīng)理，與 C 公司進行交流。經(jīng)過需求調(diào)研，工認為， C 公司想要建設一個視頻聊天，并據(jù)此完成了系統(tǒng)方案。在 W 的翻譯下， S 審閱并認可了 H公司的系統(tǒng)方案。經(jīng)過進一步的談判， C 公司和 H 公司簽訂了合同，并把該系統(tǒng)方案作為合同附件，作為將來項目驗收的標準。合

48、同簽訂后，工迅速組織人力投入系統(tǒng)開發(fā)。由于工系統(tǒng)集成經(jīng)驗豐富，開發(fā)過程進展順利， 對項目如期完工很有把握。系統(tǒng)開發(fā)期間， S 主管和 W 翻譯忙于在全國各地開拓市場，與 H 公司沒有再進行接觸。就在系統(tǒng)開發(fā)行將結束之際， S 主管和 W 翻譯來到 H 公司查看開發(fā)進度。當看到工演示的即將完工的業(yè)務系統(tǒng)時， S 主管卻表示，視頻聊天只是系統(tǒng)的一個基本功能，系統(tǒng)的核心功能則是通過視頻聊天實現(xiàn)網(wǎng)上交易的電子商務活動，要求 H 公司完善系統(tǒng)功能并如期交付。工拿出系統(tǒng)方案作為證據(jù)，據(jù)理力爭。W 翻譯承認此前他的工作有誤，導致雙方對項目圍的認識產(chǎn)生了偏差，并說服S 主管將交付日期延后 2 個月。為了完成合

49、同，工同意對系統(tǒng)功能進行擴充完善，并重新修訂了系統(tǒng)方案。但是，此后 C 公司又多次提出圍變更要求。工發(fā)現(xiàn)，不斷修訂的系統(tǒng)方案已經(jīng)嚴重偏離了原始方案，系統(tǒng)如期交付已經(jīng)是不可能的任務了。問題 1（6 分）請結合案例簡要說明，詳細的項目圍說明書應包含哪些容，并指出 C 公司和H 公司對哪些方面的理解出現(xiàn)了重大偏差。問題 2（6 分）請指出 S主管的要否恰當？為什么？并請結合本案例簡要分析導致 C公司多次提出圍變更的可能原因。問題 3（3 分）作為項目管理者，工此時應關注的圍變更控制的要點有哪些？問題 1詳細的項目圍說明書應包含如下容：1、項目的目標；2、產(chǎn)品（或服務）的圍描述；3、項目的可交付物；4

50、、項目邊界；205、產(chǎn)品驗收標準；6、項目的約束條件；7、項目的假定。C 和 H 在如下幾個方面出現(xiàn)了嚴重偏差：1、項目的目標： H 以為是實現(xiàn)視頻聊天，而 C 期望是通過視頻聊天實現(xiàn)網(wǎng)上交易的電子商務；2、項目的可交付物：同上；3、驗收標準： H 把未經(jīng)確認的存在嚴重偏差的“系統(tǒng)方案”作為驗收標準。問題 2S 主管的要恰當?shù)?。因為雙方在需求（項目圍）理解上存在重大偏差，而 H 公司未把詳細的項目圍說明書（需求分析說明書），提交給 C 公司（S 主管）確認簽字?；颍篠 主管的要不恰當?shù)?，因為雙方已簽訂了合同， H 公司按照合同進行開發(fā)，并無不妥。導致 C 公司多次提出圍變更的可能原因：1、 W

51、 翻譯對計算機相關技術知之甚少，未能準確轉達 S 主管的需求；2、工收集需求時，理解出現(xiàn)偏差，未能準確把握需求；3、工編制的需求分析說明書，未進行部評審；4、需求分析說明書（或項目圍說明書）未與 C 公司達成一致，未提交給 S 主管確認簽字；5、工在圍控制上做得不好。問題 31、 確定圍變更是否已經(jīng)產(chǎn)生；2、對造成圍變更的因素施加影響，以確保這些變更得到一致的認可。3、當圍變更發(fā)生時，對實際的變更進行管理。案例四（涉與圍管理、進度管理和變更管理 2010 下 試題一）試題一說明某信息系統(tǒng)集成公司（承建方）成功中標當?shù)卣巢块T（建設方）辦公場所的一信息系統(tǒng)軟件升級改造項目。項目自 2 月份初開

52、始，工期 1 年。承建方項目經(jīng)理制訂了相應的進度計劃，將項目工期分為四個階段：需求分析階段計劃 8 月底結束；設計階段計劃 9 月底結束；編碼階段計劃 11 月底結束； 安裝、測試、調(diào)試和運行階段計劃次年 2 月底結束。當年 2 月底，建設方通知承建方， 6 月至 8 月這 3 個月期間因某種原因，無法配合項目實施。經(jīng)雙方溝通后達成一致，項目仍按原合同約定的工期執(zhí)行。由于該項目的按時完成對承建方非常重要，在雙方就合同達成一致后，承建方領導立刻對項目經(jīng)理做出指示：21（1）招聘新人，加快需求分析的進度，趕在 6 月底之前完成需求分析；（2） 6 月至 8 月期間在本單位部完成系統(tǒng)設計工作。項目經(jīng)

53、理雖有不同意見，但還是根據(jù)領導的指示立即修改了進度管理計劃并招募了新人，要求項目組按新計劃執(zhí)行，但項目進展緩慢。直到 7 月底項目組才剛剛完成需求分析和初步設計。問題 1（3 分）除案例中描寫的具體事項外，承建方項目經(jīng)理在進度管理方面可以采取哪些措施？A、開發(fā)拋棄型原型 B、績效評估 C、偏差分析D、編寫項目進度報告 E、確認項目圍 F、發(fā)布新版項目章程問題 2（6 分）基于你的經(jīng)驗，請指出承建方領導的指示中可能存在的風險，并簡要敘述進行變更的主要步驟。問題 3（6 分）針對項目現(xiàn)狀，請簡述項目經(jīng)理可以采用的進度壓縮技術，并分析利弊。答案：問題 1 B C D問題 2（4） 盲目增加人力未必可

54、以加快項目進度，尤其是增加沒有經(jīng)驗的員工，反而可能會拖延進度。（5） 項目的風險是否能夠規(guī)避，需要按照風險管理的方法進行風險識別、風險分析和風險監(jiān)控。進行變更控制：（1） 根據(jù)領導指示的容，向變更控制委員會提出相關變更申請；（2） 推動變更控制委員會對變更進行評估，分析變更造成的影響和風險；（3） 根據(jù)變更決策推動變更的實施，包括更新進度計劃、招聘新人和相關活動；（4） 執(zhí)行或推動變更的確認，開展變更后的項目活動。問題 3進度壓縮的技術有以下兩種：（1）趕進度：對費用和進度進行權衡，確定如何在盡量減少費用的前提下縮短項目所需時間.利：有可能在盡量減少費用的前提下縮短項目所需的時間；弊： 趕進度

55、并非總能產(chǎn)生可行的方案，有可能反而使費用增加；（2）快速跟進：同時進行按先后順序的階段或活動。利：適當增加費用，可以縮短項目所需的時間；弊：以增加費用為代價換取時間，并因縮短項目進度時間而增加風險。案例五（圍管理 2010 下 試題四）說明某公司為當?shù)匾患視觊_發(fā)圖書資料垂直搜索引擎產(chǎn)品，雙方詳細約定了合同條款，包括合同金額、產(chǎn)品驗收標準等。此項目是該公司獨立承擔的一個小型項目，項目經(jīng)理小兼任項目技術負責人，項目進行到設計階段后，由于小從未參與過垂直搜索引擎的產(chǎn)品開發(fā)，產(chǎn)品設計方案經(jīng)過兩次評審后仍未能通過。公司決定將小從22該項目組調(diào)離，由小接任該項目的項目經(jīng)理兼項目技術負責人。小仔細查閱了小

56、組織撰寫的項目圍說明書和產(chǎn)品設計方案后，進行了修改。小將原定從頭開發(fā)的方案修改為通過學習和重用開源代碼來實現(xiàn)的方案。小還相應地修改了小組織編寫的項目圍說明書，將其中按照項目生命周期分解得到的大型分解目錄列表形式的 WBS 改為按照主要可交付物分解的樹形結構圖形式，減少了 WBS 的層次。小提出的涉與方案和項目圍說明書得到了項目干系人的認可，通過了評審。問題 1（5 分）結合本案例，判斷下列選項的正誤。（4） 項目圍控制需要按照項目整體變更控制過程來處理。 （）（5） 項目圍說明書通過了評審，標志著完成了項目圍確認工作。（）（6） 小修改了項目圍說明書，但原有的項目圍管理計劃不需要變更。（）（7

57、） 小編寫的項目圍說明書中應該包括產(chǎn)品驗收標準等重要合同條款。（）（8） 通過評審后，新項目圍說明書將成為該項目的圍基準。（）問題 2（4 分）請簡述小組織編寫的項目圍說明書中 WBS 的表示形式與小組織編寫的項目圍說明書中 WBS 的表示形式各自的優(yōu)缺點與適用場合。問題 3（6 分）結合項目現(xiàn)狀，請簡述在項目后續(xù)工作中小應如何做好圍控制工作。答：問題 1（1） （2） （3） （4） （5）問題 2小組織編寫的項目圍說明書中 WBS 的表示形式為分級的樹型結構圖。（1） 樹型結構圖的 WBS 層次清晰，非常直觀，結構性很強，但是不易修改；對于大的，復雜的項目也很難表示出項目的全景。（2） 由

58、于其直觀性，一般在一些中小型的應用項目中用的比較多。小組織編寫的項目圍說明書中 WBS 的表示形式為分級目錄（列表形式）。（1） 該表格能反映出項目所有的工作要素，但直觀性差，有些項目分解后容分類較多，容量較大。（2） 常用在一些大的，復雜的項目中。問題 3（1）小首先要負責建立項目的圍基準；（2）維護項目的圍基準，必要時按照公司變更流程變更項目圍；（3）還要負責組織實施項目圍變更、確認變更結果，以與后續(xù)項目圍控制。案例六（圍管理 2011 上 試題一）說明 M 公司承擔了某大學圖書館存儲與管理系統(tǒng)的開發(fā)任務，任務周期 4 個月。小是 M 公司的員工，半年前入職。在校期間，小跟隨導師做過兩年的

59、軟件開發(fā)，具有很好的軟件開發(fā)基礎。領導對小很信任，任命小擔任該項目的項目經(jīng)理。項目立項前，小參與了用戶前期溝通會議，并承擔了需求分析工作。會議結束后，相關部門按照要求整理會議所形成的決議和共識，并發(fā)給客戶等待23確認。為了節(jié)約時間，小根據(jù)自己在溝通會議上記錄的結果，當晚組織有關人員撰寫了軟件需求規(guī)格說明。次日便要求設計人員開始進行系統(tǒng)設計，并指出項目組成員必須嚴格按照進度計劃執(zhí)行，以不辜負領導的期望與囑托。項目進行了 2 個月后，校方主管此業(yè)務的新領導上任，并提出了新的信息化管理要求。小進行變更影響分析，認為成本超支嚴重，于是小決定不進行圍變更，并將結果通知客戶，引起了客戶的不滿。項目進入測試

60、階段后， M 公司開展部管理審查活動，此項目作為在建項目接受了審查，項目審查員給該項目提出了多個問題，圍管理方面的問題尤為突出。問題 1（5 分）結合本案例，分析小在此項目中項目圍管理方面可能存在的不足。問題 2（6 分）小組織人員撰些項目 WBS 如下*大學圖書館存儲與管理系統(tǒng)110確認需求 120設計 130編碼 140測試 150安裝和測試111初步需求112詳細需求121功能設計122系統(tǒng)設計131模塊定義132接口定義141部測試142集成測試151軟件安裝152系統(tǒng)測試133程序編碼 143報告制定 153培訓（1） 請說明上述 WBS 結構是將 作為第一層進行分解，除了上述方法，