【正文】 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 37 / 70 進(jìn)度控制 2021 年上 閱讀下列說明，針對項(xiàng)目的進(jìn)度管理，回答問題 1至問題 3。 （ 3）確定項(xiàng)目里程碑，并建立有效的評審機(jī)制。 （ 2）制定出合理可靠的技術(shù)方案，對其中不熟悉的部分采用外包方式 （ 3）清晰定義各功能模塊之間的接口，然后可以加大并行工作的程度 （ 4）明確目標(biāo)，責(zé)任何獎勵機(jī)制，提高員工工作效率 （ 5）必要時進(jìn)行趕工 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 36 / 70 [問題 3] 答：（ 1）基于 WBS 和工時估算 制定活動網(wǎng)絡(luò)圖，制定項(xiàng)目進(jìn)度計劃 （ 2）建立對項(xiàng)目工作的監(jiān)督和測量機(jī)制。 【 問題 1】 （ 5 分） 請說明強(qiáng)某可以用什么方法和技術(shù)來估算項(xiàng)目的工期（ 150 字以內(nèi)）？ 【 問題 2】 （ 5 分） 請說明強(qiáng)某可以采取哪些方法來壓縮工期，以使項(xiàng)目能夠在 2021 年 7 月 1 日之前交付（ 150 字以內(nèi)）？ 【 問題 3】 （ 5 分） 請說明強(qiáng)某可以采用哪些方法來跟蹤項(xiàng)目的進(jìn)度，以確保項(xiàng)目能夠 按進(jìn)度計劃完成？ 【 問題 1】 答：（ 1）明確定義項(xiàng)目的工作分解結(jié)構(gòu) （ 2）由于是升級項(xiàng)目，所以部分工作的工期估算方法可以采用類比估算法 （ 3）對于新增的移動接入模塊，可以聯(lián)系業(yè)內(nèi)專家，采用專家判斷或者德爾菲法進(jìn) 行估算 （ 4）對于 WBS進(jìn)行足夠的細(xì)化后，可以依據(jù)歷史數(shù)據(jù)采用 “參數(shù)估算 ”或 “三點(diǎn)估算 ”進(jìn)行進(jìn)一步歷時估算。公安局要求新系統(tǒng)能夠支持移動接入，而項(xiàng)目團(tuán)隊(duì)中沒有一人接觸過移動接入技術(shù)。該項(xiàng)目從技術(shù)角度可分為網(wǎng)絡(luò)改造和軟件開發(fā)，而軟件又分界面、業(yè)務(wù)流程和數(shù)據(jù)庫三個子系統(tǒng)。原來的系統(tǒng)為 J公司開發(fā)，是 C/S結(jié)構(gòu)，只能管理本地城區(qū)常住人口。但這次和以往不同的是強(qiáng)某還同時管理著另外兩個項(xiàng)目，而這個人口管理系統(tǒng)項(xiàng)目的工期要求緊、他能調(diào)用的人手少。 【說明】 J 公司 2021 年 3 月中標(biāo)某市公安局的人口管理系統(tǒng)開發(fā)項(xiàng)目，因該市要在 2021 年 11月舉辦某大型國際會議，因此公安局要求 人口管理系統(tǒng)一定要在 2021年 7月 1日之前投入使用。 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 35 / 70 項(xiàng)目進(jìn)度 閱讀下列說明，回答問題 1至問題 3。但是，當(dāng)針 對某一活動的資源投入數(shù)量達(dá)到一定規(guī)模時，再增加資源的投入不會進(jìn)一步縮短項(xiàng)目活動歷時，也就是資源投入遞減規(guī)律 （ 2）非關(guān)鍵路徑上的活動歷時只對項(xiàng)目產(chǎn)生較小的影響或不產(chǎn)生影響，而關(guān)鍵路徑上活動歷時的延誤，則會直接影響到項(xiàng)目工期。 （ 6）加強(qiáng)對階段性工作的檢查和控制，避免后期出現(xiàn)返工。 【 問題 3】 （ 6 分） 請用 200字以內(nèi)的文字，概述典型的信息系統(tǒng)集成項(xiàng)目的進(jìn)度／時間管理的過程 和方法以及資源配置對進(jìn)度的制約。 【 問題 1】 （ 4 分） 請用 150 字以內(nèi)的文字，分析問題發(fā)生的可能原因。項(xiàng)目組成的成員均全程參加項(xiàng)目。 項(xiàng)目經(jīng)理小丁做過 5 年的系統(tǒng)分析和設(shè)計工作，但這是他第一次擔(dān)任項(xiàng)目經(jīng)理。合同規(guī)定， 6 月 28 日之前系統(tǒng)必須投入試運(yùn)行。 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 33 / 70 第 8 章 項(xiàng)目進(jìn)度管理 項(xiàng)目進(jìn)度 【 說明 】 某系統(tǒng)集成公司現(xiàn)有員工 50 多人，業(yè)務(wù)部門分為銷售部、軟件開發(fā)部、系統(tǒng)網(wǎng)絡(luò)部等。 當(dāng)范圍變更發(fā)生時，對實(shí)際的變更進(jìn)行管理。 導(dǎo)致 C 公司多次提出范圍變更的可能原因： W 翻譯對計算機(jī)相關(guān)技術(shù)知之甚少，未能準(zhǔn)確轉(zhuǎn)達(dá) S 主管的需求； 楊工收集需求時，理解出現(xiàn)偏差，未能準(zhǔn)確把握需求； 楊工編制的需求分析說明書，未進(jìn)行內(nèi)部評審； 需求分析說明書（或項(xiàng)目范圍說明書）未與 C 公司達(dá)成一致，未提交給 S 主管確認(rèn)簽字； 楊工在范圍控制上做得不好。 〔問題 2〕 S 主管的要求是恰當(dāng)?shù)摹? 【問題 3】（ 3 分） 作為項(xiàng)目管理者，楊工此時應(yīng)關(guān)注的范圍變更控制的要點(diǎn)有哪些？ 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 31 / 70 〔問題 1〕 詳細(xì)的項(xiàng)目范圍說明書應(yīng)包含如下內(nèi)容： 項(xiàng)目的目標(biāo)； 產(chǎn)品（或服務(wù)）的范圍描述； 項(xiàng)目的可交付物； 項(xiàng)目邊界； 產(chǎn)品驗(yàn)收標(biāo)準(zhǔn)； 項(xiàng)目的約束條件； 項(xiàng)目的假定。 【問題 1】（ 6 分） 請結(jié)合案例簡要說明，詳細(xì)的項(xiàng)目范圍說明書應(yīng)包含哪些內(nèi)容，并指出 C公司和 H 公司對哪些方面的理解出現(xiàn)了重大偏差。但是，此后 C 公司又多次提出范圍變更要求。 W 翻譯承認(rèn)此前他的工作有誤，導(dǎo)致雙方對項(xiàng)目范圍的認(rèn)識產(chǎn)生了偏差，并說服 S 主管將交付日期延后 2 個月。當(dāng)看到楊工演示的即將完工的業(yè)務(wù)系統(tǒng)時， S 主管卻表示，視頻聊天只是系統(tǒng)的一個基本功能，系統(tǒng)的核心功能則是通過視頻聊天實(shí)現(xiàn)網(wǎng)上交易的電子商務(wù)活動，要求 H 公司完善系統(tǒng)功能并如期交付。系統(tǒng)開發(fā)期間， S 主管和 W 翻譯忙于在全國各地開拓市場，與 H 公司沒有再進(jìn)行接觸。 合同簽訂后，楊工迅速組織人力投入系統(tǒng)開發(fā)。在 W 的翻譯下， S審閱并認(rèn)可了 H 公司的系統(tǒng)方案。 H公司指派楊工為該業(yè)務(wù)系統(tǒng)建設(shè)項(xiàng)目經(jīng)理，與 C 公司進(jìn)行交流。 S主管精通軟件開發(fā)，但是不懂漢語，而 W 翻譯對計算機(jī)相關(guān)技術(shù)知之甚少。 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 29 / 70 工作分解結(jié)構(gòu) 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 30 / 70 范圍 管理 2021 下 閱讀下列說明，針對項(xiàng)目的范圍管理，回答問題 1 至問題 3，將解答填入答題紙 的對應(yīng)欄內(nèi)。更有甚者，沒有執(zhí)行需求評審的進(jìn)入條件，在評審文檔中存在大量的低級的錯誤或者沒有在評審前進(jìn)行溝通，文檔中存在方向性的錯誤，從而導(dǎo)致評審的效率很低，質(zhì)量很差。 建議九：充分準(zhǔn)備評審 評審質(zhì)量的好壞很大程度上取決于在評審會議前的準(zhǔn)備活動。當(dāng)確定需要糾正的問題后，要形成書面的需求變更的申請，進(jìn)入需求變更的管理流程，并確保變更的執(zhí)行，在變更完成后，要進(jìn)行復(fù)審。通過評審流程 執(zhí)行可能會避免出現(xiàn)案例五之類的問題。 建議七：建立標(biāo)準(zhǔn)的評審流程 對正規(guī)的需求評審會需要建立正規(guī)的需求評審流程，按照流程中定義的活動進(jìn)行規(guī)范的評審過程。需求形式的檢查可以由 QA 人員負(fù)責(zé)，主要是針對需求文擋的 格式是否符合質(zhì)量標(biāo)準(zhǔn)來提出的，需求內(nèi)容的檢查是由評審員負(fù)責(zé)的，主要是檢查需求內(nèi)容是否達(dá)到了系統(tǒng)目標(biāo)、是否有遺漏、是否有錯誤等等，這是需求評審的重點(diǎn)。需要注意的是被評審人員也要被培訓(xùn)。簡單培訓(xùn)可能需要十幾分鐘或者幾十分鐘，需要將在評審過程中的需要把握的基本原則，需要注意的常見問題說清楚。 建議五：對評審員進(jìn)行培訓(xùn) 在很多情況下，評審員是領(lǐng)域?qū)＜叶皇沁M(jìn)行評審活動的專家，他們沒有掌握進(jìn)行評審的方法、技巧、過程等，因此需要對評審員進(jìn)行，同樣對于主持評審的管理者也需要進(jìn)行培訓(xùn)，以便于參與評審的人員能夠緊緊圍繞評審的目標(biāo)來進(jìn)行，能夠控制評審活動的節(jié)奏，提高評審效率， 避免發(fā)生案例一和案例二中出現(xiàn)的現(xiàn)象。首先要保證使不同類型的人員的都要參與進(jìn)來，否則很可能會漏掉了很重要的需求。在這些人員中由于大家所處的立場不同，對同一個問題的看法是不相同的，有些觀點(diǎn)是和系統(tǒng)的目標(biāo)有關(guān)系的，有些是關(guān)系不大的，不同的觀點(diǎn)可能形成互補(bǔ)的關(guān)系。比如可以在形成目標(biāo)性需求后進(jìn)行一次評審，在形成系統(tǒng)的初次概要需求后進(jìn)行一次評審， 當(dāng)對概要需求細(xì)分成幾個部分，對每個部分進(jìn)行各個評審，最終再對整體的需求進(jìn)行評審。 建議三：分階段評審 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 27 / 70 應(yīng)該在需求形成的過程中進(jìn)行分階段的評審，而不是在需求最終形成后再進(jìn)行評審。 2種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發(fā)現(xiàn)問題。 建議二：正式評審與非正式評審結(jié)合 正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責(zé)，對需求進(jìn)行正規(guī)的會議評審。對不同層次的需求，其描述形式是有區(qū)別的，參與評審的人員也是不同的。 ? 參加人員過多，容易陷入細(xì)枝末節(jié)的討論，會議演變成一場人人自由的混戰(zhàn)。 ? 沒有作好前期準(zhǔn)備工作，導(dǎo)致評審時間長，效率低。 ? 目標(biāo)性需求沒有溝通好，后面的需求變成空中樓閣。概括起來，在需求評審中常見的問題是： ◇ 需求 報告很長，短時間內(nèi)評審者根本就不能把需求報告讀懂，想清楚； ◇ 沒有作好前期準(zhǔn)備工作，需求評審的效率很低； ◇ 需求評審的節(jié)奏無法控制； ◇ 找不到合格的評審員，與會的評審員無法提出深入的問題； …… 上述案例的原因分析 3 問題所在： ? 評審缺乏有效依據(jù)和規(guī)范，不能保證評審的覆蓋率和有效性。 范圍定義和需求分析時，工作不細(xì)致，忽視了 B/S 架構(gòu)下的頁面需求 需求范圍變更中，沒有對頁面變更進(jìn)行 “確認(rèn) ”，就修改代碼 【問題 3】 答題的思路和提綱，請將下列答題點(diǎn)細(xì)化 針對甲方的需求，制定實(shí)用的項(xiàng)目范圍管理計劃； 做好范圍定義工作（詳細(xì)列出方法） 做好需求分析工作（方法、過程、工作步驟） 重視范圍確認(rèn)（方法） 嚴(yán)格范圍變更（變更流程） 建立完善的項(xiàng)目范圍管理制度和規(guī)范的范圍管理流程 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 26 / 70 需求評審 《系統(tǒng)集成項(xiàng)目管理工程師》教程 第 23 章 案例分析 答： 軟件需求的定義 軟件需求是軟件開發(fā)的最重要的一個輸入，需求風(fēng)險也常常是軟件開發(fā)過程中最大的一個風(fēng)險，降低需求風(fēng)險的一個重要手段就是需求評審，但是需求評審是所有的評審活動中最難的一個，也是最容易被忽視的一個評審。 設(shè)計方案沒有進(jìn)行驗(yàn)證；表現(xiàn)層內(nèi)耦合的業(yè)務(wù)邏輯，增加了修改的代價； 團(tuán)隊(duì)管理措施不力，成員產(chǎn)生挫折感； 【問題 2】請從項(xiàng)目范圍管理的角度找出該項(xiàng)目實(shí)施過程中的主要管理問題。在項(xiàng)目交付時，雖然系統(tǒng)完全滿足了保密性的要求，但用戶對系統(tǒng)用戶界面提出了較大的異議，認(rèn)為不符合政務(wù)信息系統(tǒng)的風(fēng)格，操作也不夠便捷，要求徹底更換，由于最初設(shè)計的缺陷，系統(tǒng)表現(xiàn)層和邏輯層緊密耦合，導(dǎo)致 70%的代碼重寫，而第二版的用戶界面仍不能滿足最終用戶的要求，最終又重寫部分代碼才通過駛收，由于系統(tǒng)的反復(fù)變更，項(xiàng) 目組成員產(chǎn)生了強(qiáng)烈的挫折感，士氣低落，項(xiàng)目工期也超出原計劃的100%。 張工是該項(xiàng)目的項(xiàng)目經(jīng)理，在捕獲到這個需求后認(rèn)為電 子政務(wù)建設(shè)與企業(yè)信息化有很大的不同，有其自身的特殊性，若照搬企業(yè)信息化原有的經(jīng)驗(yàn)和方案必定會遭到慘敗。政務(wù)內(nèi)網(wǎng)中儲存著全部信息，其中包括部分機(jī)密信息；政務(wù)外網(wǎng)可以對公眾開放，開放的信息必須御到授權(quán)。 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 24 / 70 第 7 章 項(xiàng)目范圍管理 范圍定義 《系統(tǒng)集成項(xiàng)目管理工程師》教程 第 23 章 案例分析 M 公司原本是一家專注于企業(yè)信息 化的公司，在電子政務(wù)如火如荼的時候，開始進(jìn)軍電子政務(wù)行業(yè)，在電子政務(wù)的市場中，接到的第一個項(xiàng)目是開發(fā)一套工商審批系統(tǒng)。 系統(tǒng)集成項(xiàng)目管理工程師－案例分析 23 / 70 【問題 3】 公司應(yīng)該建立嚴(yán)格和規(guī)范的合同管理制度，簽訂合同時必須在合同中明確項(xiàng)目的范圍、進(jìn)度以及相關(guān)要求，建立完善的合同文本； 公司 內(nèi)部應(yīng)該建立規(guī)范和完善的項(xiàng)目管理制度，在項(xiàng)目管理上建立合規(guī)的管理流程、方法和標(biāo)準(zhǔn)規(guī)范，推行科學(xué)的項(xiàng)目管理方法，包括范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理方面； 在公司內(nèi)部加強(qiáng)項(xiàng)目管理思想和方法的培訓(xùn)，建立全員的、全面的、全過程的項(xiàng)目管理體系和標(biāo)準(zhǔn)。 【問題 2】 加強(qiáng)和甲方的溝通，針對項(xiàng)目驗(yàn)收的工作內(nèi)容和方式，流程、時間等問題 ，積極和甲方進(jìn)行溝通，爭取和甲方就項(xiàng)目驗(yàn)收工作達(dá)成一致意見； 針對合同中沒有明確的驗(yàn)收標(biāo)準(zhǔn)和流程等問題，可以采用備忘錄或者補(bǔ)充協(xié)議的形式，就項(xiàng)目驗(yàn)收的標(biāo)準(zhǔn)、流程、時間和責(zé)任人等內(nèi)容簽署書面的具有法律效力的文件，以便指導(dǎo)項(xiàng)目驗(yàn)收工作。 針對甲方組織結(jié)構(gòu)復(fù)雜，需求多變的情況，沒有進(jìn)行事前風(fēng)險分析和制定風(fēng)險應(yīng)對措施，對需求沒有進(jìn)行嚴(yán)格的分析、管理措施，對項(xiàng)目范圍也沒有進(jìn)行確定， 針對項(xiàng)目范圍、進(jìn)度、成本的變化，缺乏必要的變更控制手段和規(guī)范的變更控制流程。 【 問題 3】 （ 4分） 為了避免以后出現(xiàn)類似情況，請簡要敘述公司應(yīng)采取哪些