系統集成項目管理工程師

----案例分析大全

第4章項目管理一般知識

4.1項目經理的選擇

閱讀下列說明，回答問題1至問題3，將解答填入答題紙的相應欄內。

【說明】

D公司是一家系統集成商，章某是D公司的一名高級項目經理，現正在負責某市開發

區的辦公網絡項目的管理工作，該項目劃分為綜合布線、網絡工程和軟件開發三個子項目，

需要3個項目經理分別負責。章某不久找到了負責綜合布線、網絡工程的項目經理，而負

責軟件開發的項目經理一直沒有合適的人選。本來由于D公司近年業務快速發展，承攬的

項目逐年增多，現有的項目經理人手不夠。章某建議從在公司工作2年以上業務骨干中選拔

項目經理。結果李某被章某選中負責該項目的軟件開發子項目。在項目初期,依照公司的管

理規定，李某帶領幾名項目團隊成員刻苦工作，項目進展順利。隨著項目的進一步展開，

項目成員的逐步增長，李某在項目團隊管理方面碰到很多困難。他領導的團隊因經常返工而

效率低下、團隊成員對發生的錯誤互相推諉、開會時人員歷來沒有到齊過，甚至李某因忙

于自己負責的模塊開會時都遲到過。大家向李某報告項目的實際進度、成本時往言過其實,

直到李某對自己負責的模塊進行接口調試時才發現這些問題。

【問題1】（5分）請分析項目中出現這些情況的也許因素（100字以內）。

【問題2］（5分）你認為高級項目經理章某應當如何指導和幫助李某（200字以內）。

【問題3】（5分）請說明李某作為項目經理要承擔哪些角色？要成為一名合格的項目經

理要具有哪些知識與技能？（200字以內）

［問題1］（1。分）請分析項目中出現這些情況的也許因素（200字以內）。

答：（1）李某缺少擔任項目經理所需的足夠的能力和經驗

（2）公司對項目經理的培養不重視，對項目經理的選拔任命不規范；

（3）章某對李某的“傳幫帶”做的不夠好;

(4)公司對項目經理的工作缺少指導和監督;

(5)項目工作中的溝通沒有建立有效的機制和方式方法；

(6)缺少有效的項目績效管理機制；

[問題2](10分)你認為高級項目經理章某應當如何指導和幫助李某(300字以內)。

答：(1)章某應明確李某的工作職責，幫助其實現向項目經理角色的轉變；

(2)參與小李組織的周例會，以及時發現問題，予以指導；

(3)對李某提供相關工作的指導或培訓，特別是在項目管理方面；

(4)從整體項目層面對各子項目進行協調和計劃，對子項目提出具體工作規定；

(5)加強對子項目的平常監督，要項目經理以身作則；

(6)針對子項目中出現的問題,及時提出糾正和防止措施；

[問題3](5分)請說明李某作為項目經理要承擔哪些角色？要成為一名合格的項目經

理要具有哪些知識與技能？(300字以內)

答：參與書上147-148頁內容

4.2項目的組織結構

閱讀下面敘述，回答問題1至問題3,將解答填入答題紙的相應欄內。

【說明】

某系統集成商B最近正在爭取某鋼鐵公司A的辦公網絡遷移到外地的項目。李某是系

統集成商B負責捕獲項目機會的銷售經理，鮑某是系統集成商B負責實行的項目經理。由

于以往項目銷售經理的過度承諾給后繼的實行工作帶來了很大困難，本次鮑某積極為該項

目做售前支持。該辦公網絡遷移項目的工作涉及鋼鐵公司A新辦公樓的綜合布線、局域網

絡系統升級、機房建設、遠程視頻會議系統、生產現場的閉路監控系統等5個子系統。鋼

鐵公司A對該項目的招標工作在2023年8月4日開始。該項目規定在2023年12月29日

完畢，否則將嚴重影響鋼鐵公司A的業務。時間已到2023年8月8日，鋼鐵公司A希

望系統集成商B能在8月15日前可以提交項目建議書。鋼鐵公司A對項目的進度非常關

注，這是他們選擇集成商的重要指標之一。根據經驗、鋼鐵公司A的實際情況和現有的資源,

鮑某組織制定了一個初步的項目計劃，通過對該計劃中項目進度的分析預測，鮑某認為按

正常流程很難達成客戶對進度的規定。擬訂的協議中將規定對進度的延誤要處以罰款。但

是銷售經理李某則急于贏得協議，希望能在項目建議書中對客戶做出明確的進度保證，一方

面贏得協議再說。鮑某和李某在對項目進度承諾的問題上產生了分歧，李某認為鮑某不幫

助銷售拿協議，鮑某認為李某亂承諾對以后的項目實行不負責任。本著支持銷售的原則，鮑

某采用了多種措施，組織制訂了一個切實可行的進度計劃，雖然其報價比競爭對手略高，

但評標委員會認為該方案有保證，是可行的，于是系統集成商B中標。系統集成商B中標

后，由其實行部負責項目的實行。

【問題1】（7分）在制訂進度計劃時，鮑某也許會采用哪些措施使制訂的進度計劃滿

足客戶的規定？

【問題2】（5分）實行項目的系統集成商B目前的組織類型是什么?如何改善其項目的

組織方式？如何改善其項目管理的流程？如何減少管理外地

項目的成本？

【問題3】（3分）在項目實行過程中，負責售前工作的李某應繼續承擔哪些工作？

答題思緒:

【問題1]

1)溝通，強調該項目對系統集成商B的重要意義，提高項目優先級。使用開會方式爭取

相關部門的建議、支持和承諾。

2)從現有資源和實際情況出發，優化網絡圖，如重新安排活動之間的順序，壓縮關鍵途

徑長度。

3)增長資源,引入經驗豐富的員工

4)并行，在現有資源下，子任務并行，內部流程優化。

5)趕工，項目員工通過加班來加快項目進度

6)盡也許地調配非關鍵途徑上的資源用于關鍵途徑上的任務

7)優化外包，采購等環境并全程監控

【問題2]

(1)系統集成商B的組織方式是職能式的。

(2)系統集成商B的組織方式應當改為矩陣型。

(3)最佳的辦法是項目下階段的人員提前介入到前一階段，如在項目的售前階段，負責

項目實行的項目經理正式參與售前工作。

(4)此外，做好項目實行流程間的交接工作，如建立一套完整的項目售前和項目實行

階段之間的交接規范和規定-涉及文檔、培訓、協議等內容。

(5)委托、分包給本地有資質的集成商，或在本地招人。假如材料和服務在本地采購

可減少成本。壓低人員差旅費，事宜虛擬遠程的溝通和售后服務手段。

【問題3]

(1)與客戶高層溝通，了解客戶對項目實行情況的反映，維護客戶關系，發掘新的項

目機會。

(2)參與周例會，或至少每周首一次周報以了解項目的進展和問題。

（3）參與也許發生的變更的前期評審工作。

（4）負責或者協助收款。

4.3項目組織結構

閱讀下面敘述，回答問題1至問題3,將解答填入答題紙的相應欄內。

【說明】

《系統集成項目管理工程師》教程第23章-案例分析23.1.7

答題思緒：

1、強矩陣型組織結構的特點是：它具有很多項目型組織的特性,具有擁有很大職權的

專職項目經理和專職項目行政管理人員。

2、在強矩陣組織中，為協調項目經理和職能部門經理的權責，應：

2.1在公司管理思想和原則上，明確矩陣型組織的特性：

★可以以項目為導向

★有了客戶問題解決中心

★協調工作由項目管理隊伍承擔

★可以明確責任

★資源來自各職能部門，并且這些資源可在不同項目中共享

★專業人員在技術上可互相支持

★各專業員工組織上仍歸屬其職能部門，因此項目結束后，員工“有家可歸”

2.2在公司制度上，明確職能部門和項目經理之間的權責分派關系：

--資源、人員平常歸職能部門經理管理和考核；

--在項目實行期間人員、資源由項目經理全權管理和考核；

2.3建立一個清楚的項目管理流程，明確項目經理在項目實行期間的權力和責任；

定義了相關人員和相關部門在項目活動中的工作范圍、工作過程和職責。這個流程一般由

項目管理部門起草，通過相關部門討論修改，最終由項目管理部門、相關職能部門審批，最后由

公司管理層終批生效。例如：

一一嚴格加強項目章程的規范性和嚴厲性，任命項目經理的必要性

--項目所需資源，由項目經理提出申請，職能經理負責委派人員；

-一項目實行期間的考核由項目經理負責，項目結束后，人員回到職能部門，考核

內容也轉交給職能經理，最終由職能經理負責所有考核

-一項目管理部經理和資源部門經理對等解決項目過程中項目目的和資源提供的決

策問題；

2.4在項目工作安排方面，特別注意管理好各個接口，如項目成員之間或部門之間的

工作交接，技術交接、資源交接

2.5加強項目溝通，適量增長項目信息收集、整理、分析和發布的頻次，這樣能及時

發現項目問題，利于及時采用糾正措施。可以通過電子郵件等手段，及時將項目進展情況、存

在的問題和糾正措施通報給全體項目成員、不要忘掉抄送給項目成員所屬部門的經理，假如

有必要，甚至抄送給公司管理層。

4.4項目生命周期模型2023上

閱讀下列說明，回答問題1至問題3。將解答填入答題紙的相應欄內。

【說明】

小趙是一位優秀的軟件設計師，負責過多項系統集成項目的應用開發，現在公司因人

手緊張，讓他作為項目經理獨自管理一個類似的項目，他使用瀑布模型來管理該項目的全生

命周期，如下所示：

項目進行到實行階段，小趙發現在系統定義階段所制訂的項目計劃估計不準，實行階段

有許多原先沒有估計到的任務現在都冒了出來。項目工期因而一再延期，成本也一直超過。

【問題1】（6分）

根據項目存在的問題，請簡要分析小趙在項目整體管理方面也許存在的問題。

【問題2]（6分）

（1）請簡要敘述瀑布模型的優缺陷。

（2）請簡要敘述其他模型如何填補瀑布模型的局限性。

【問題3】（3分）

針對本案例,請簡要說明項目進入實行階段時，項目經理小趙應當完畢的項目文

檔工作？

【問題1]

1、軟件設計師小趙第一次擔任項目經理，獨立管理一個項目，缺少項目整體管理經驗

和技能;

2、小趙選取瀑布模型作為項目整體管理的生命周期模式，缺少科學的論證和系統的評

估，開發模型的選取沒有進行可行性分析和論證；

3、在系統論證階段制定項目整體計劃時，對進度計劃沒有采用科學的方法，如類比估算

法，專家判斷，三點估算,應急時間等。

4、對項目需求和功能沒有進行嚴格的需求分析、范圍定義；

5、在項目范圍上沒有制定WBS,規劃項目實行范圍；

6、小趙沒有對項目范圍進行嚴格的范圍確認；導致項目范圍界定不清

7、實行階段，沒有對項目范圍進行范圍控制，遵循規范的范圍變更控制管理，導致范

圍蔓延

【問題2】書上162頁

1、瀑布模式的優點是

2、為填補瀑布模型的缺陷,可采用快速原型法、螺旋模型和迭代模型

【問題3]

小趙在項目實行階段應完畢的文檔，分兩大類：

(1)項目管理過程文檔一項目進度計劃(變更)，項目績效報告，項目會議記錄，項目范

圍(變更)說明書、變更控制文檔、質量分析報告，風險評估報告等等。

(2)項目產品實現文檔一概要設計說明書，具體設計說明書，代碼規范，程序編碼設計書,

數據庫模型與設計說明書，測試用例，測試報告等等。

第5章立項管理

5.1項目可行性分析一分析報告

閱讀下列有關項目可行性分析的說明，回答問題1至問題3。將解答填入答題紙的相應欄內。

在項目計劃和選擇的過程中,需要完成的首要工作是對項目進行估算.項

目估算的范圍涉及方方面面，例如項目或產品開發的范圍、投入和回報、項

目風險、作用和意義等.在傳統信息系統工程方法中，是以可行性研究的方

式米組織對項目的主要估算內容的.在企業實際的業務過程中，可行性研究

通常作為一個重要的環節，被包含在整個項目立項.或項目選擇和確認的過

程中.

可行性研究的范圍可能覆蓋很廣泛的技術、經濟、執行、環境等各種需要

評估的因素,但它并不是最后的精細計劃（例如：項目的時間進度及人步安排）.

通常在進行可行性研究的階段，甚至項目的日標或產品的最終方向也是高度易

變化的.但可行性研究的意義在于，雖然可行性研究不能指出項目最終的精細

計劃和方向，但可行性研究可以在項目定義階段用較小的代價識別出錯誤構思

的系統，從而規避未來更多的資源投入的損失（時間、資金、人力、機會）.

或者因遭遇到無法逾越的技術障礙或環境障礙導致的不可避免的失敗，

對于那些可行性研究表明可執行的軟件項目來說，可行性研究的結果也不

承諾系統的收益一定很巨大,或技術風險和資源投入就定很低，但可行性研

究的結果設立了一個“底線”，即：“如果實施什么，則風險和收益是什么”這

樣的控制范圍。這些評估結果給了未來的項目評估、項目風險捽制，甚至在資

源劇烈變化的情況下有計劃有弱點地削減功能、塞定義項目開發他圍，或者選

擇項目實施的方式提供了非常有價值的方向性指引.

【問題1】（7分）

可行性研究的步驟是什么？請使用列舉的形式，不超過100字回答.

【問題2】（8分）

可行性研究報告是可行性研究的成果體現，請使用列舉的形式，不超過150

字回答,可行性研究報告主要包含什么內容？

【問愿3］（10分）

在可行性研究的基礎匕還需要請第三方根據國家領布的政策、法律法規

等，從項目、國民經濟、社會角度出發，對擬建項H進行各方面的評估.清用

不超過50字的文字回答，項目評估報告主要包含什么內容？

參考答案：

【一?1］（7分）

可行性研究的步驟包括：①確定項目規模和目標：②研究正在運行的系

統：③建立新系統的設輯模型：④導出和評價各種方案；⑤推薦可行性方

案；⑥編寫可行性研究報告；⑦遞交可行性研究報告。

【問題3］（10分）

項目評估報告一般應包括以下內容：

（1）項目概況。

【問題2】（8分）（2）評估目標。

可行性研究報告的編寫內容包括:（3）過估依據.

（1）引才.（4）評估內容.

（2）可行性研究的前提.（5）評估機構與評估專家.

（3）對現有系統的分析.（6）評估過程.

（4）所建議的系統.（7）詳細汗估意見.

（5）可選擇的其他系統方案。<8）存在或遺漏的強大問題.

<6）投資及效益分析.（9）潛在的風險.

（7）社會因素方面的可行性。（10）評估結論.

（8）結論.（11）進一步的建議.

<><><><><>

第6章項目整體管理

6.1項目整體（綜合）管理

閱讀下列說明，回答問題1至問題3。將解答填入答題紙的相應欄內。

【說明】

A公司是一家中小型系統集成公司，在2023年3月份正在準備對京發證券公司數據大

集中項目進行投標，A公司副總裁張某授權銷售部的林某為本次投標的負責人，來組織和

管理整個投標過程。林某接到任務后，召集了由公司商務部、銷售部、客服部和質管部等

相關部門參與的啟動說明會，并把各自的分工和進度計劃進行了部署。

隨后，在投標前3天進行投標文獻評審時，發現技術方案中所配置的設備在以前的項

目使用中是存在問題的，必須更換，隨后修改了技術方案。最后A公司中標并和客戶簽訂了

協議。

根據公司的項目管理流程，林某把項目移交到了實行部門，由他們具體負責項目的執行

與驗收。實行部門接手項目后，鮑某被任命為實行項目經理，負責項目的實行和驗收工作。

鮑某發現由于項目前期自己沒有介入，許多項目前期的事情都不是很清楚，而導致后續跟

進速度較慢，影響項目的進度。同時鮑某還發現設計方案中尚存在一些問題，重要有：方

案漏掉一項基本需求，有多項無效需求，沒有書面的需求調研報告；在項目的工期、系統

功能和售后服務等方面,存在過度承諾現象。于是項目組重新調研用戶需求，編制設計方案,

這就增長了實行難度和成本。可是后來又發現采購部仍是按照最初的方案采購設備,導致設

備中的模塊配置功能不符合規定的情況。而在A集成公司中，類似現象已多次發生。

【問題1】（5分）針對說明中所描述的現象，分析A公司在項目管理方面存在的問題（150

字以內）。

【問題2】（5分）針對A公司在該項目管理方面存在的問題，提出補救措施（150字以內）。

【問題3]（5分）針對A公司的項目管理現狀，結合你的實際經驗，就A公司項目管理工作的

連續改善提出意見和建議（150字以內）。

答題思緒：

【問題1]

1、投標前的項目啟動會議上，沒有邀請技術和實行部門

2、沒有把以往的經驗教訓,歸納和積累，形成組織知識資產

3、沒有建立完善的內部評審機制，或雖有評審機制但為有效執行

4、項目中沒有實現有效的變更管理

5、公司級的項目管理體系不健全，或執行不好

【問題2]

1、改善項目的組織形式，明確項目團隊和職能部門之間的協作關系和工作程序

2、做好項目當前的經驗教訓收集、歸納「作

3、明確項目工作的交付物，建立和實行項目的質量評審機制

4、建立項目的變更管理機制，辨認變更中的利益相關方并加強溝通

5、加強對項目團隊成員和相關人員的項目管理培訓

【問題31

1、建立公司級的項目管理體系和工作規范

2、加強對項目工作記錄的管理

3、加強項目質量和相應的評審制度

4、加強項目經驗教訓的收集、歸納、積累和分享工作

5、引入合適的項目管理工具平臺，提高項目管理工作效率

6.2項目整體2023上

閱讀下面敘述，回答問題1至問題3，將解答填入答題紙的相應欄內。

【說明】

某公司是一家專門從事ERP系統研發和實行的IT公司，目前該公司正在進行的一個

項目是為某大型生產單位（甲方）研發ERP系統。

某公司同甲方關系比較密切，但也正由于如此，協議簽的較為簡樸，項目執行較為隨意。同

時甲方組織架構較為復雜，項目需求來源多樣并且經常發生變化，項目范圍和進度經常要進

行臨時調整。

通過項目組的艱苦努力，系統總算可以進入試運營階段，但是由于各種因素，甲方并

不太樂意進行正式驗收，至今項目也未能結項。

【問題1】（6分）

請從項目管理角度，簡要分析該項目“未能結項”的也許因素。

【問題2】（5分）

針對該項目現狀，請簡要說明為了促使該項目進行驗收，可采用哪些措施。

【問題3]（4分）

為了避免以后出現類似情況，請簡要敘述公司應采用哪些有效的管理手段。

答：【問題1]

1、簽訂協議很簡樸，沒有在協議中明確甲乙雙方的職責，明確項目的時間規定，范圍

界定以及協議違約等條款和內容，缺少有效的協議管理制度；

2、項目執行較隨意,表白其缺少規范和嚴格的項目管理制度和方法，規范的項目管理

流程，沒有嚴格的進度控制、成本控制和質量保證、風險分析等管理措施。

3、針對甲方組織結構復雜，需求多變的情況，沒有進行事前風險分析和制定風險應對

措施，對需求沒有進行嚴格的分析、管理措施，對項目范圍也沒有進行擬定，

4、針對項目范圍、進度、成本的變化，缺少必要的變更控制手段和規范的變更控制流

程。

5、相應項目的不驗收，缺少有效的溝通管理制度，缺少和甲方必須的溝通方法和措施,

在協議中沒有規定驗收的標準和程序；

6、相應項目出現的情況，缺少應急措施和有效的針對性方法，來解決項目當前的困難。

【問題2]

1、加強和甲方的溝通，針對項目驗收的工作內容和方式,流程、時間等問題，積極和甲

方進行溝通，爭取和甲方就項目驗收工作達成一致意見；

2、針對協議中沒有明確的驗收標準和流程等問題，可以采用備忘錄或者補充協議的形

式，就項目驗收的標準、流程、時間和負責人等內容簽署書面的具有法律效力的文

獻，以便指導項目驗收工作。

3、在項目組內部，加強項目管理工作力度，制定驗收文檔標準,積極準備驗收工作，

完善驗收成果文檔，明確項目驗收工作的標準和流程，以及團隊成員的職責。

【問題3]

1、公司應當建立嚴格和規范的協議管理制度，簽訂協議時必須在協議中明確項目的

范圍、進度以及相關規定，建立完善的協議文本；

2、公司內部應當建立規范和完善的項目管理制度，在項目管理上建立合規的管理流

程、方法和標準規范，推行科學的項目管理方法，涉及范圍管理、時間管理、成本

管理、質量管理、人力資源管理方面；

3、在公司內部加強項目管理思想和方法的培訓,建立全員的、全面的、全過程的項目

管理體系和標準。

4、在項目立項時，建立科學和嚴謹的項目可行性分析和論證制度，進行風險分析和

風險評估，規避項目風險。

第7章項目范圍管理

7.1范圍定義

《系統集成項目管理工程師》教程第23章-案例分析23.2.1

M公司原本是一家專注于公司信息化的公司，在電子政務如火如荼的時候，開始進軍電

子政務行業,在電子政務的市場中，接到的第一個項目是開發一套工商審批系統。由于電了政

務保密規定，該系統涉及到兩個互不聯通的子網:政務內網和政務外網。政務內網中儲存著所

有信息，其中涉及部分機密信息;政務外網可以對公眾開放，開放的信息必須御到授權。系統規

定在這兩個了網中的合法用戶都可以訪問到被授權的信息.訪問的信息必須是一致可靠，政

務內網的信息可以發布到政務外網，政務外網的信息在通過審批后可以進入政務內網系統。

張工是該項目的項目經理，在捕獲到這個需求后認為電子政務建設與公司信息化有很

大的不同,有其自身的特殊性，若照搬公司信息化原有的經驗和方案必然會遭到慘敗。因此

采用了嚴格爆布模型，并專門招聘了熟悉網絡互通互聯的技術人員設計了解決方案，在通

過嚴格評審后實行。在項目交付時，雖然系統完全滿足了保密性的規定，但用戶對系統用戶

界面提出了較大的異議，認為不符合政務信息系統的風格，操作也不夠便捷，規定徹底更換，

由于最初設計的缺陷，系統表現層和邏輯層緊密耦合，導致70%的代碼重寫，而第二版的用

戶界面仍不能滿足最終用戶的規定，最終又重寫部分代碼才通過駛收，由于系統的反復變

更,項目組成員產生了強烈的挫折感，士氣低落，項目工期也超過原計劃的100%。

【問題1］（5分）

請不超過150字，對張工的行為進行點評？

【問題2】（5分）

請從項目范圍管理的角度找出該項目實行過程中的重要管理問題?不超150字

【問題3】（5分）

請結合你本人實際項目經驗，指出應如何避免類似問題？不超過150字

【問題1】請對張工的行為進行點評?

工作的優點:1、結識到電子政務建設與公司信息化建設的不同，考慮到了項目的獨特性

的特性；

2、針對業務需求中對內網、外網的互聯互通的規定，針對性招聘了

網絡互聯互通的技術人員；

3、滿足了用戶保密性的規定；

工作的缺陷：

1、采用“瀑布模式”的項目生命周期，沒有進行論證，武斷；

2、用戶需求調研的不全面，忽視了系統頁面的需求;并且，進行第二版修正時，沒

有針對頁面的需求修改善行確認。

3、設計方案沒有進行驗證;表現層內耦合的業務邏輯,增長了修改的代價；

4、團隊管理措施不力，成員產生挫折感；

【問題2]請從項目范圍管理的角度找出該項目實行過程中的重要管理問題。

1、沒有建立規范的項目范圍管理流程和制度。

2、范圍定義和需求分析時，工作不細致，忽視了B/S架構下的頁面需求

3、需求范圍變更中，沒有對頁面變更進行“確認”，就修改代碼

（I）張工沒有挖掘到系統的全部隱性需求，缺乏精確的范圍定義.（3分）

（2）在發生第一次變更時，張工仍沒有有效的范明管理，從而造成系統的

二次變更a（3分）

C3）重旦的系統變更說明張工對系統范用控制不足,導致一而再再而三的

反復°（3分）

【問題3]

答題的思緒和提綱,請將下列答題點細化

1、針對甲方的需求，制定實用的項目范圍管理計劃；

2、做好范圍定義工作（具體列出方法）

3、做好需求分析工作（方法、過程、工作環節）

4、重視范圍確認（方法）

5、嚴格范圍變更（變更流程）

6、建立完善的項目范圍管理制度和規范的范圍管理流程

有效的范困管理包括了從范圍定義到范國控制等多方面的工作，每一項工

作都是重要的。對于本案例，要結合行業特點進行需求分析，挖掘系統潛在的

俞求，同時通過原型等方法來輔助需求的定義，避免范圍定義不清晰的問題。

在發生需求變更時需要進行有效的需求控制,盡量在滿足用戶需求的前提卜縮><><>

小需求范圍，堅決避免需求的再次變更。

7.2需求評審

《系統集成項目管理工程師》教程第23章-案例分析23.1.5

答：<軟件需求的定義〉

1、軟件需求是軟件開發的最重要的一個輸入，需求風險也經常是軟件開發過程中最大的

一個風險，減少需求風險的一個重要手段就是需求評審，但是需求評審是所有的評審活動

中最難的一個，也是最容易被忽視的一個評審。

〈上述案例的問題小結》

2以上的現象可以在很多項目中都可以看到。概括起來，在需求評審中常見的問題是：

O需求報告很長，短時間內評審者主線就不能把需求報告讀懂，想清楚；

O沒有作好前期準備工作，需求評審的效率很低；

?需求評審的節奏無法控制；

?找不到合格的評審員，與會的評審員無法提出進一步的問題；

〈上述案例的因素分析〉

3問題所在：

?評審缺少有效依據和規范,不能保證評審的覆蓋率和有效性。

?產品經理沒有把握好會議主題，評審變成了頭腦風暴。

?目的性需求沒有溝通好，后面的需求變成空中樓閣。

?缺少評審的可操作依據，漏掉評審內容。

?沒有作好前期準備工作，導致評審時間長，效率低。

?沒有選擇合適的評審人員，無法獲得有價值的反饋。

?參與人員過多，容易陷入細枝末節的討論，會議演變成一場人人自由的混戰。

〈針對以上問題，提出一些建議》

4那么究竟如何做好需求評審呢？

建議一:分層次評審

我們知道用戶的需求是可以分層次的，一般而言可以提成如下的層次:

＞目的性需求：定義了整個系統需要達成的目的；

＞功能性需求:定義了整個系統必須完畢的任務；

＞操作性需求:定義了完畢每個任務的具體的人機交互；

目的性需求是公司的高層管理人員所關注的，功能性需求是公司的中層管理人員所關注

的，操作性需求是公司的具體操作人員所關注的。對不同層次的需求，其描述形式是有區

別的，參與評審的人員也是不同的。假如讓具體的操作人員去評審目的性需求,也許會很容易

地導致“撿了芝麻，丟了西瓜”的現象,假如讓高層的管理人員也去評審那些操作性需求，無疑

是一種資源的浪費或者就會出現案例三的情形。

建議二：正式評審與非正式評審結合

正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并

定義好參與評審人員的角色和職責，對需求進行正規的會議評審。而非正式的評審并沒有

這種嚴格的組織形式，一般也不需要將人員集合在一起評審,而是通過電子郵件、文獻匯簽

甚至是網絡聊天等多種形式對需求進行評審。2種形式各有利弊，但往往非正式的評審比正

式的評審效率更高，更容易發現問題。因此在評審時，應當更靈活地運用這2種方式。

建議三:分階段評審

應當在需求形成的過程中進行分階段的評審，而不是在需求最終形成后再進行評審。分階

段評審可以將原本需要進行的大規模評審拆提成各個小規模的評審，減少了需求返工的風

險,提高了評審的質量。比如可以在形成目的性需求后進行一次評審，在形成系統的初次概要

需求后進行一次評審，當對概要需求細提成幾個部分，對每個部分進行各個評審，最終再對整

體的需求進行評審。

建議四:精心挑選評審員

需求評審也許涉及的人員涉及:需方的高層管理人員、中層管理人員、具體操作人員、IT

主管、采購主管;供方的市場人員、需求分析人員、設計人員、測試人員、質量保證人員、

實行人員、項目經理以及第三方的領域專家等等。在這些人員中由于大家所處的立場不同,

對同一個問題的見解是不相同的，有些觀點是和系統的目的有關系的,有些是關系不大的,

不同的觀點也許形成互補的關系。為了保證評審的質量和效率，需要精心挑選評審員。一方

面要保證使不同類型的人員的都要參與進來，否則很也許會漏掉了很重要的需求。另一方面

在不同類型的人員中要選擇那些真正和系統相關的，對系統有足夠了解的人員參與進來，否

則很也許使評審的效率減少或者最終不切實際的修改了系統的范圍。

建議五:對評審員進行培訓

在很多情況下，評審員是領域專家而不是進行評審活動的專家，他們沒有掌握進行評審的

方法、技巧、過程等，因此需要對評審員進行，同樣對于主持評審的管理者也需要進行培

訓，以便于參與評審的人員可以緊緊圍繞評審的目的來進行，可以控制評審活動的節奏，提

高評審效率，避免發生案例一和案例二中出現的現象。對評審員的培訓也可以區分為簡樸

培訓與具體培訓2種。簡樸培訓也許需要十幾分鐘或者幾十分鐘，需要將在評審過程中的需

要把握的基本原則，需要注意的常見問題說清楚。具體培訓則也許要需要對評審的方法、

技巧、過程進行正式的培訓，需要花費較長的時間,是一個獨立的活動。需要注意的是被評審

人員也要被培訓。

建議六:充足運用需求評審檢查單

需求檢查單是很好的評審工具，需求檢查單可以提成2類：需求形式的檢查單和需求內

容的檢查單。需求形式的檢查可以由QA人員負責，重要是針對需求文擋的格式是否符合質

量標準來提出的,需求內容的檢查是由評審員負責的，重要是檢查需求內容是否達成了系統

目的、是否有漏掉、是否有錯誤等等，這是需求評審的重點。檢查單可以幫助評審員系統

全面地發現需求中的問題，檢查單也是隨著工程財富的積累逐漸豐富和優化的。

建議七:建立標準的評審流程

對正規的需求評審會需要建立正規的需求評審流程,按照流程中定義的活動進行規范的

評審過程。比如在評審流程定義中也許規定評審的進入條件，評審需要提交的資料，每次評

審會議的人員職責分派，評審的具體環節，評審通過的條件等等。通過評審流程執行也許

會避免出現案例五之類的問題。

建議八：做好評審后的跟蹤工作

在需求評審后，需要根據評審人員提出的問題進行評價，以擬定哪些問題是必須糾正的，

哪些可以不糾正，并給出充足的客觀的理由與證據。當擬定需要糾正的問題后，要形成書

面的需求變更的申請，進入需求變更的管理流程,并保證變更的執行，在變更完畢后，要進行

復審。切忌評審完畢后，沒有對問題進行跟蹤，而無法保證評審結果的貫徹，使前期的評審努

力付之東流。

建議九:充足準備評審

評審質量的好壞很大限度上取決于在評審會議前的準備活動。

常出現的問題是，需求文檔在評審會議前并沒有提前下發給參與評審會議的人員，沒有留出

更多更充足的時間讓參與評審的人員閱讀需求文檔。更有甚者，沒有執行需求評審的進入條

件，在評審文檔中存在大量的低檔的錯誤或者沒有在評審前進行溝通，文檔中存在方向性的錯

誤，從而導致評審的效率很低，質量很差。對評審的準備工作，也應當定義一個檢查單，在評審之

前對照檢查單貫徹每項準備工作。

7.4范圍管理2023下

閱讀下列說明，針對項目的范圍管理，回答問題1至問題3,將解答填入答題

紙的相應欄內。

【說明】

C公司是一家從事電子商務的外國公司，為了在中國開展業務，派出S主

管和W翻譯來中國尋找合適的系統集成商，試圖在中國建設一套業務系統。S

主管精通軟件開發，但是不懂漢語，而W翻譯對計算機相關技術知之甚少。

w翻譯通過中國朋友介紹，找到了從事系統集成的H公司。H公司指派楊工為該

業務系統建設項目經理，與C公司進行交流。通過需求調研，楊工認為,C公司想

要建設一個視頻聊天網站，并據此完畢了系統方案。在W的翻譯下，S審閱并

認可了H公司的系統方案。通過進一步的談判，C公司和H公司簽訂了協議，

并把該系統方案作為協議附件，作為將來項目驗收的標準。

協議簽訂后,楊工迅速組織人力投入系統開發。由于楊工系統集成經驗豐富,

開發過程進展順利，對項目如期竣工很有把握。系統開發期間,S主管和W翻譯忙

于在全國各地開拓市場，與H公司沒有再進行接觸。

就在系統開發行將結束之際,S主管和W翻譯來到H公司查看開發進度。當

看到楊工演示的即將竣工的業務系統時，S主管卻表達，視頻聊天只是系統的一

個基本功能，系統的核心功能則是通過視頻聊天實現網上交易的電子商務活動,

規定H公司完善系統功能并如期交付。楊工拿出系統方案作為證據，據理力爭。

W翻譯認可此前他的工作有誤，導致雙方對項目范圍的結識產生了偏差，

并說服S主管將交付日期延后2個月。為了完畢協議，楊工批準對系統功能進

行擴充完善，并重新修訂了系統方案。但是，此后C公司又多次提出范圍變更規

定。楊工發現，不斷修訂的系統方案已經嚴重偏離了原始方案，系統如期交付已經

是不也許的任務了。

【問題1】（6分）

請結合案例簡要說明，具體的項目范圍說明書應包含哪些內容，并指出C公

司和H公司對哪些方面的理解出現了重大偏差。

【問題2】（6分）

請指出S主管的規定是否恰當？為什么?并請結合本案例簡要分析導致C公

司多次提出范圍變更的也許因素。

【問題3】（3分）

作為項目管理者，楊工此時應關注的范圍變更控制的要點有哪些？

（問題1）

具體的項目范圍說明書應包含如下內容：

1、項目的目的；

2、產品（或服務）的范圍描述；

3、項目的可交付物；

4、項目邊界；

5、產品驗收標準；

6、項目的約束條件；

7、項目的假定。

C和H在如下幾個方面出現了嚴重偏差：

1、項目的目的：H認為是實現視頻聊天網站，而C盼望是通過視頻聊天實現網

上交易的電子商務；

2、項目的可交付物:同上；

3、驗收標準：H把未經確認的存在嚴重偏差的“系統方案”作為驗收標準。

（問題2）

S主管的規定是恰當的。

由于雙方在需求（項目范圍）理解上存在重大偏差，而H公司未把具體的項目范

圍說明書（需求分析說明書），提交給C公司（S主管）確認簽字。

導致C公司多次提出范圍變更的也許因素:

I、W翻譯對計算機相關技術知之甚少,未能準確轉達S主管的需求；

2、楊工收集需求時，理解出現偏差，未能準確把握需求；

3、楊工編制的需求分析說明書，未進行內部評審；

4、需求分析說明書（或項目范圍說明書）未與C公司達成一致，未提交給S主管

確認簽字；

5、楊工在范圍控制上做得不好。

（問題3）

1、擬定范圍變更是否已經產生；

2、對導致范圍變更的因素施加影響,以保證這些變更得到一致的認可。

3、當范圍變更發生時，對實際的變更進行管理。

（以上為書本上的，me考試寫的是：

1、重新編制項目范圍說明書，與C公司達成一致，并讓S主管確認簽字；

2、建立整體變更控制流程，做好范圍控制。

第8章項目進度管理

8.1項目進度

【說明】

某系統集成公司現有員工50多人，業務部門分為銷售部、軟件開發部、系統網絡部等。

通過近半年的醞釀后，在今年一月份，公司的銷售部直接與某銀行簽訂了一個銀行前置機的

軟件系統的項目。協議規定，6月28日之前系統必須投入試運營。在協議簽訂后，銷售部將

此協議移交給了軟件開發部，進行項目的實行。

項目經理小丁做過5年的系統分析和設計工作，但這是他第一次擔任項目經理。小丁兼

任系統分析工作，此外項目尚有2名有1年工作經驗的程序員,1名測試人員,2名負責組網

和布線的系統工程師。項目組成的成員均全程參與項目。

在承擔項目之后，小丁組織大家制定了項目的WBS,并依照以往的經歷制訂了本項目的

進度計劃，簡樸描述如下：

1、應用子系統

1)1月5日~2月5日需求分析

2)2月6日~3月26日系統設計和軟件設計

3)3月27日?5月10日編碼

4)5月11日?5月30日系統內部測試

2、綜合布線

2月20日~4月20日完畢調研和布線

3、網絡子系統

4月21日~5月21日設備安裝、聯調

4、系統內部調試、驗收

D6月1日~6月20日試運營

2)6月28日系統驗收

春節后，在2月17日小丁發現系統設計剛剛開始，由此推測3月26日很也許完不成系統

設計。

【問題1］（4分）

請用150字以內的文字，分析問題發生的也許因素。

【問題2］（5分）

請用150字以內的文字，建議小丁應當如何做以保證項目整體進度不遲延。

【問題3】（6分）

請用200字以內的文字，概述典型的信息系統集成項目的進度/時間管理的過程

和方法以及資源配置對進度的制約。

答：

【問題1】

（1）銷售部沒有及時讓軟件開發部參與項目初期工作,需求分析耗時過長；

（2）項目經理初次擔任，經驗局限性，進度估算不準確；

（3）項目資源配置局限性，項目經理兼任系統分析，缺少專門的系統分析和設計人員

（4）工作安排沒有充足運用分派的項目資源,資源有閑置；

（5）在安排進度時也許未考慮法定節假日的因素

【問題2］

（1）向職能經理申請增長特定資源，特別是增長系統分析設計人員；

（2）將部分階段的工作改為并行進行，以節約時間

（3）臨時加班/趕工，盡也許補救耽誤的時間

（4）對后續工作的工期重新進行估算，并考慮節假日問題，修訂計劃，盡量留有余地

（5）加強溝通，爭取客戶可以對項目范圍以及需求、設計、驗收標準進行確認，避免

后期頻繁出現變更。

（6）加強對階段性工作的檢查和控制，避免后期出現返工。

此外，如有也許還可采用外包和縮減范圍等辦法，但是不建議在本案例中采用

【問題3】

1、進度管理的過程

2、資源對進度的影響

(1)一般情況下，項目活動歷時與投入的資源數量成反比，即投入的資源數量越多，

活動歷時越短。但是，當針對某一活動的資源投入數量達成一定規模時，再增長資源的投入

不會進一步縮短項目活動歷時，也就是資源投入遞減規律

(2)非關鍵途徑上的活動歷時只對項目產生較小的影響或不產生影響，而關鍵途徑

上活動歷時的延誤，則會直接影響到項目工期。因此每當縮短項目工期時，應對一方面考慮

在關鍵途徑活動上增長資源。

8.2項目進度

閱讀下列說明，回答問題1至問題3。將解答填入答題紙的相應欄內。

【說明】

J公司2023年3月中標某市公安局的人口管理系統開發項目，因該市要在2023年11月

舉辦某大型國際會議，因此公安局規定人口管理系統一定要在2023年7月1日之前投入使

用。強某是負責這個項目的項目經理，雖然他進公司才不到3年,但他已成功地管理過2個

類似的項目，被大家稱之為“救火隊長”，而強某也對自己信心十足。但這次和以往不同的是

強某還同時管理著此外兩個項目，而這個人口管理系統項目的工期規定緊、他能調用的人手

少。該人口管理系統項目屬于升級項目。本來的系統為J公司開發，是C/S結構，只能管理

本地城區常住人口。新的人口管理系統規定是B/S結構,要既能管理城區常住人口又能管理

郊區常住人口、市轄縣常住人口和流動人口，而公安局規定該新系統一方面把流動人口管理

起來。該項目從技術角度可分為網絡改造和軟件開發，而軟件又分界面、業務流程和數據

庫三個子系統。他們團隊有6人，其中有人做過類似的C/S結構的項目，而公司剛結束的

一個網絡項目與本次承擔的網絡改造項目在技術架構方面幾近相同，只是規模不同。公安局

規定新系統可以支持移動接入，而項目團隊中沒有一人接觸過移動接入技術。強某憑直覺

知道依現有的人員在2023年7月1日之前完畢項目是不也許的。

【問題1】（5分）請說明強某可以用什么方法和技術來估算項目的工期（150字以內）？

【問題2】（5分）請說明強某可以采用哪些方法來壓縮工期，以使項目可以在2023

年7月1日之前交付（150字以內）？

【問題3】（5分）請說明強某可以采用哪些方法來跟蹤項目的進度，以保證項目可以

按進度計劃完畢？

【問題1】

答：（1）明擬定義項目的工作分解結構

（2）由于是升級項目，所以部分工作的工期估算方法可以采用類比估算法

(3)對于新增的移動接入模塊，可以聯系業內專家，采用專家判斷或者德爾菲法進

行估算

(4)對于WBS進行足夠的細化后，可以依據歷史數據采用“參數估算”或“三點估

算”進行進一步歷時估算。

[問題2]

答：(1)與客戶溝通，梳理業務中的關鍵需求，與客戶協商能否在期限前完畢關鍵需求即可,

其他部分分期交付。

(2)制定出合理可靠的技術方案，對其中不熟悉的部分采用外包方式

(3)清楚定義各功能模塊之間的接口，然后可以加大并行工作的限度

(4)明確目的，責任何獎勵機制，提高員工工作效率

(5)必要時進行趕工

[問題3]

答：(1)基于WBS和工時估算制定活動網絡圖，制定項目進度計劃

(2)建立對項目工作的監督和測量機制。依據項目進度基線和平常項目進展報告，比較

進度偏差(SV)和進度效率指數(SPI),進行偏差分析。

(3)擬定項目里程碑，并建立有效的評審機制。

(4)對項目中發現的問題，及時采用糾正措施，并進行有效的變更管理

(5)使用有效的項目管理工具,提醒項目管理的工作效率。

8.3進度控制2023年上

閱讀下列說明，針對項目的進度管理，回答問題1至問題3。將解答填入答題紙的相應

欄內。

【說明】

B市是北方的一個超大型城市，最近市政府有關部門提出需要加強對全市交通的管

理與控制。

2023年9月19BB市政府決定實行智能交通管理系統項目,對路面人流和車流實

現實時的、量化的監控和管理。項目規定于2023年2月1日完畢。

該項目由某公司承建，小李作為該公司項目經理，在2023年10月20日接到項

目任務后，立即以曾經管理過的道路監控項目為參考，估算出項目歷時大體為100天,并把該

項目提成五大模塊分別分派給各項目小組，同時規定:項目小組在2023年1月20日前

完畢任務，1月21日至28日各模塊聯調，1月29日至31日機動。小李隨后在原道路監

控項目解決方案的基礎上組織制定了智能交通管理系統項目的技術方案。

可是到了2023年1月20日,小李發現有兩個模塊的進度落后于計劃，并且即使這

五個模塊所有準時完畢，在預定的1月21日至28日期間因春節假期也無法組織人員安排模

塊聯調，項目進度拖后已成定局。

【問題1】（8分）請簡要分析項目進度拖后的也許因素？

【問題2］（4分）請簡要敘述進度計劃涉及的種類和用途。

【問題3】（3分）請簡要敘述“滾動波浪式計劃”方法的特點和擬定滾動周期的依據。

針對本試題說明中所述項目，說明采用多長的滾動周期比較恰當。

［問題1］答：

（1）歷時估算不準確；

（2）沒有考慮到法定節假日，這些不應當計算在節假日內；

（3）沒有安排應急時間；

（4）沒有做好進度控制。

［問題2］書267頁

［問題3］答：

完畢項目當前階段所需完畢的工作細節，并且要為后續階段要完畢的工作做出初步描

述。對項目計劃的這種逐步進一步的描述方式通常稱為滾動波浪式計劃。而周期則應當根

據階段來擬定，一般地一個階段為一個滾動周期。歷時100天,我認為20天的周期比較好,

這樣正好5個周期，大小合適。

8.4進度管理2023年下

閱讀下列說明，回答問題1至問題3,將解答填入答題紙的相應欄內。

【說明】

F公司成功中標S市的電子政務工程。F公司的項目經理李工組織相關人員對該項目

的工作進行了分解,并參考以前曾經成功實行的W市電子政務工程項目，估算該項目的工作

量為120人月，計劃工期為6個月。項目開始不久，為便于應對突發事件，經業主與F公司協

商，批準該電子政務工程必須在當年年終之前完畢，并且還要保質保量。這意味著，項目工期要

縮短為4個月，而項目工作量不變。

李工按照4個月的工期重新制定了項目計劃，向公司申請盡量多增派開發人員，并規

定所有的開發人員加班加點工作以便向前趕進度。由于公司有多個項目并行實行，給李工增

派的開發人員都是剛招進公司的新人。為節省時間,李工還決定項目組取消每日例會，改為

每周例會。同時，李工還允許需求調研和方案設計部分重疊進行，允許需求未經確認即可進行

方案設計。

最后，該項目不僅沒能4個月完畢，反而一再延期，遲遲不能交付。最終導致S市

政府嚴重不滿，項目組人員也多有抱怨。

【問題1】（6分）

請簡要分析該項目一再拖期的重要因素。

【問題2】（6分）

請簡要說明項目進度控制可以采用的技術和工具。

【問題3】（3分）

請簡要說明李工可以提出哪些措施以有效縮短項目工期。

（問題1）

項目一再拖期的重要因素：

1、李工的項目工作量也許估算不準，編制的項目計劃有問題，或未通過評審；

2、新增派的開發人員是新人,經驗局限性，生產率低，開發質量有問題;

3、所有開發人員加班加點，導致過度疲勞，生產率減少，質量下降;

4、取消每日例會，改為周例會，也許導致不能及時發現偏差，不能及時糾偏;

5、需求調研和方案設計部分重疊，導致設計缺陷和變更；

6、需求未經確認，導致需求變更嚴重。

（問題2）書264頁1-10

1,進度網絡分析

2,關鍵線路法

3,進度壓縮

4,假設情景分析

5,資源平衡

6,關鍵鏈

7,項目管理軟件

8,應用日歷

9,調整時間提前與滯后量

10,進度模型

（問題3）書270頁與263頁

第9章項目成本管理

9.1成本估算

9.2成本控制2023下

試題四（15分）

閱讀下列說明，針對項目的成本管理，回答問題1至問題2,將解答填入答題紙的相應欄

內。

【說明】

某信息系統開發項目由系統集成商A公司承建，工期1年，項目總預算20萬元。目前項

目實行己進行到第8個月末。在項目例會上,項目經理就當前的項目進展情況進行了分析和

報告。截止第8個月末項目執行情況分析表如下:

活動計劃成本值（元）實際成木值（元）完成百分比

項目啟動20002100100%

令2可行性研究50004500100%

3需求調研與分析1000012000100%

4設計選型750008600090%

5集成實施650006000070%

6測試200001500035%

【問題1］（8分）

請計算截止到第8個月末該項目的成本偏差（CV）、進度偏差（SV）、成本執行指數

（CPI）和進度執行指數（SPI）;判斷項目當前在成本和進度方面的執行情況。

【問題2】（7分）

請簡