【正文】 ；針對業(yè)務(wù)需求中對內(nèi)網(wǎng)、外網(wǎng)的互聯(lián)互通的要求，針對性招聘了網(wǎng)絡(luò)互聯(lián)互通的技術(shù)人員；滿足了用戶保密性的要求；工作的缺點(diǎn)：采用“瀑布模式”的項目生命周期，沒有進(jìn)行論證，武斷；用戶需求調(diào)研的不全面，忽視了系統(tǒng)頁面的需求；并且，進(jìn)行第二版修正時，沒有針對頁面的需求修改進(jìn)行確認(rèn)。設(shè)計方案沒有進(jìn)行驗證；表現(xiàn)層內(nèi)耦合的業(yè)務(wù)邏輯，增加了修改的代價；團(tuán)隊管理措施不力，成員產(chǎn)生挫折感；【問題 2】請從項目范圍管理的角度找出該項目實施過程中的主要管理問題。沒有建立規(guī)范的項目范圍管理流程和制度。范圍定義和需求分析時，工作不細(xì)致，忽視了B/S架構(gòu)下的頁面需求需求范圍變更中，沒有對頁面變更進(jìn)行“確認(rèn)”，就修改代碼【問題 3】針對甲方的需求，制定實用的項目范圍管理計劃；做好范圍定義工作（詳細(xì)列出方法）做好需求分析工作（方法、過程、工作步驟）重視范圍確認(rèn)（方法）嚴(yán)格范圍變更（變更流程）建立完善的項目范圍管理制度和規(guī)范的范圍管理流程 需求評審《系統(tǒng)集成項目管理工程師》教程 第23答：軟件需求是軟件開發(fā)的最重要的一個輸入，需求風(fēng)險也常常是軟件開發(fā)過程中最大的則很可能會漏掉了很重要的需求。其次在不同類順利，對項目如期完工很有把握。系統(tǒng)開發(fā)期一個風(fēng)險，降低需求風(fēng)險的一個重要手段就是型的人員中要選擇那些真正和系統(tǒng)相關(guān)的，對系間，S主管和W翻譯忙于在全國各地開拓市場，需求評審，但是需求評審是所有的評審活動中統(tǒng)有足夠了解的人員參與進(jìn)來，否則很可能使評與H公司沒有再進(jìn)行接觸。最難的一個，也是最容易被忽視的一個評審。審的效率降低或者最終不切實際的修改了系統(tǒng)就在系統(tǒng)開發(fā)行將結(jié)束之際，S主管和W翻 的范圍。譯來到H公司查看開發(fā)進(jìn)度。當(dāng)看到楊工演示2 以上的現(xiàn)象可以在很多項目中都可以看 的即將完工的業(yè)務(wù)系統(tǒng)時，S主管卻表示，視頻到。概括起來，在需求評審中常見的問題是：建議五：對評審員進(jìn)行培訓(xùn) 聊天只是系統(tǒng)的一個基本功能，系統(tǒng)的核心功◇ 需求報告很長，短時間內(nèi)評審者根本就在很多情況下，評審員是領(lǐng)域?qū)＜叶皇沁M(jìn)能則是通過視頻聊天實現(xiàn)網(wǎng)上交易的電子商務(wù)不能把需求報告讀懂，想清楚； 行評審活動的專家，他們沒有掌握進(jìn)行評審的方活動，要求H公司完善系統(tǒng)功能并如期交付?！?沒有作好前期準(zhǔn)備工作，需求評審的效法、技巧、過程等，因此需要對評審員進(jìn)行，同楊工拿出系統(tǒng)方案作為證據(jù)，據(jù)理力爭。率很低； 樣對于主持評審的管理者也需要進(jìn)行培訓(xùn)，以便W翻譯承認(rèn)此前他的工作有誤，導(dǎo)致雙方對◇ 需求評審的節(jié)奏無法控制； 于參與評審的人員能夠緊緊圍繞評審的目標(biāo)來項目范圍的認(rèn)識產(chǎn)生了偏差，并說服S主管將◇ 找不到合格的評審員，與會的評審員無進(jìn)行，能夠控制評審活動的節(jié)奏，提高評審效率，交付日期延后2個月。為了完成合同，楊工同法提出深入的問題； 避免發(fā)生案例一和案例二中出現(xiàn)的現(xiàn)象。對評審意對系統(tǒng)功能進(jìn)行擴(kuò)充完善，并重新修訂了系?? 員的培訓(xùn)也可以區(qū)分為簡單培訓(xùn)與詳細(xì)培訓(xùn)2統(tǒng)方案。但是，此后C公司又多次提出范圍變 種。簡單培訓(xùn)可能需要十幾分鐘或者幾十分鐘，更要求。楊工發(fā)現(xiàn)，不斷修訂的系統(tǒng)方案已經(jīng)3 問題所在： 需要將在評審過程中的需要把握的基本原則，需嚴(yán)重偏離了原始方案，系統(tǒng)如期交付已經(jīng)是不 評審缺乏有效依據(jù)和規(guī)范，不能保證評審的要注意的常見問題說清楚。詳細(xì)培訓(xùn)則可能要需可能的任務(wù)了。覆蓋率和有效性。要對評審的方法、技巧、過程進(jìn)行正式的培訓(xùn)，【問題1】（6分）產(chǎn)品經(jīng)理沒有把握好會議主題，評審變成了需要花費(fèi)較長的時間，是一個獨(dú)立的活動。需要請結(jié)合案例簡要說明，詳細(xì)的項目范圍說頭腦風(fēng)暴。注意的是被評審人員也要被培訓(xùn)。明書應(yīng)包含哪些內(nèi)容，并指出C公司和H公司 目標(biāo)性需求沒有溝通好，后面的需求變成空 對哪些方面的理解出現(xiàn)了重大偏差。中樓閣。建議六：充分利用需求評審檢查單 【問題2】（6分）缺乏評審的可操作依據(jù)，遺漏評審內(nèi)容。需求檢查單是很好的評審工具，需求檢查單請指出S主管的要求是否恰當(dāng)？為什么？ 沒有作好前期準(zhǔn)備工作，導(dǎo)致評審時間長，可以分成2類：需求形式的檢查單和需求內(nèi)容的并請結(jié)合本案例簡要分析導(dǎo)致C公司多次提出效率低。檢查單。需求形式的檢查可以由QA人員負(fù)責(zé)，范圍變更的可能原因。沒有選擇合適的評審人員，無法獲得有價值主要是針對需求文擋的格式是否符合質(zhì)量標(biāo)準(zhǔn)【問題3】（3分）的反饋。來提出的，需求內(nèi)容的檢查是由評審員負(fù)責(zé)的，作為項目管理者，楊工此時應(yīng)關(guān)注的范圍 參加人員過多，容易陷入細(xì)枝末節(jié)的討論，主要是檢查需求內(nèi)容是否達(dá)到了系統(tǒng)目標(biāo)、是否變更控制的要點(diǎn)有哪些？ 會議演變成一場人人自由的混戰(zhàn)。有遺漏、是否有錯誤等等，這是需求評審的重點(diǎn)。 檢查單可以幫助評審員系統(tǒng)全面地發(fā)現(xiàn)需求中〔問題1〕4 那么究竟如何做好需求評審呢？ 的問題，檢查單也是隨著工程財富的積累逐漸豐詳細(xì)的項目范圍說明書應(yīng)包含如下內(nèi)容：建議一：分層次評審 富和優(yōu)化的。項目的目標(biāo)；我們知道用戶的需求是可以分層次的，一般而產(chǎn)品（或服務(wù)）的范圍描述； 言可以分成如下的層次：建議七：建立標(biāo)準(zhǔn)的評審流程項目的可交付物；目標(biāo)性需求：定義了整個系統(tǒng)需要達(dá)到的目對正規(guī)的需求評審會需要建立正規(guī)的需求項目邊界； 標(biāo)； 評審流程，按照流程中定義的活動進(jìn)行規(guī)范的評產(chǎn)品驗收標(biāo)準(zhǔn)；功能性需求：定義了整個系統(tǒng)必須完成的任審過程。比如在評審流程定義中可能規(guī)定評審的項目的約束條件； 務(wù)； 進(jìn)入條件，評審需要提交的資料，每次評審會議項目的假定。操作性需求：定義了完成每個任務(wù)的具體的的人員職責(zé)分配，評審的具體步驟，評審?fù)ㄟ^的 人機(jī)交互； 條件等等。通過評審流程執(zhí)行可能會避免出現(xiàn)案C和H在如下幾個方面出現(xiàn)了嚴(yán)重偏差：目標(biāo)性需求是企業(yè)的高層管理人員所關(guān)注例五之類的問題。項目的目標(biāo)：H以為是實現(xiàn)視頻聊天網(wǎng)站，的，功能性需求是企業(yè)的中層管理人員所關(guān)注 而C期望是通過視頻聊天實現(xiàn)網(wǎng)上交易的電的，操作性需求是企業(yè)的具體操作人員所關(guān)注建議八：做好評審后的跟蹤工作 子商務(wù)； 的。對不同層次的需求，其描述形式是有區(qū)別在需求評審后，需要根據(jù)評審人員提出的問項目的可交付物：同上； 的，參與評審的人員也是不同的。如果讓具體題進(jìn)行評價，以確定哪些問題是必須糾正的，哪驗收標(biāo)準(zhǔn)：H把未經(jīng)確認(rèn)的存在嚴(yán)重偏差的的操作人員去評審目標(biāo)性需求，可能會很容易些可以不糾正，并給出充分的客觀的理由與證“系統(tǒng)方案”作為驗收標(biāo)準(zhǔn)。地導(dǎo)致“撿了芝麻，丟了西瓜”的現(xiàn)象，如果據(jù)。當(dāng)確定需要糾正的問題后，要形成書面的需 讓高層的管理人員也去評審那些操作性需求，求變更的申請，進(jìn)入需求變更的管理流程，并確〔問題2〕 無疑是一種資源的浪費(fèi)或者就會出現(xiàn)案例三的保變更的執(zhí)行，在變更完成后，要進(jìn)行復(fù)審。切S主管的要求是恰當(dāng)?shù)?。情形。忌評審?fù)戤吅?，沒有對問題進(jìn)行跟蹤，而無法保因為雙方在需求（項目范圍）理解上存在重大 證評審結(jié)果的落實，使前期的評審努力付之東偏差，而H公司未把詳細(xì)的項目范圍說明書（需建議二：正式評審與非正式評審結(jié)合 流。求分析說明書），提交給C公司（S主管）確認(rèn)正式評審是指通過開評審會的形式，組織 簽字。多個專家，將需求涉及到的人員集合在一起，建議九：充分準(zhǔn)備評審并定義好參與評審人員的角色和職責(zé)，對需求評審質(zhì)量的好壞很大程度上取決于在評審導(dǎo)致C公司多次提出范圍變更的可能原因： 進(jìn)行正規(guī)的會議評審。而非正式的評審并沒有會議前的準(zhǔn)備活動。W翻譯對計算機(jī)相關(guān)技術(shù)知之甚少，未能準(zhǔn)這種嚴(yán)格的組織形式，一般也不需要將人員集常出現(xiàn)的問題是，需求文檔在評審會議前并沒有確轉(zhuǎn)達(dá)S主管的需求； 合在一起評審，而是通過電子郵件、文件匯簽提前下發(fā)給參與評審會議的人員，沒有留出更多楊工收集需求時，理解出現(xiàn)偏差，未能準(zhǔn)確甚至是網(wǎng)絡(luò)聊天等多種形式對需求進(jìn)行評審。2更充分的時間讓參與評審的人員閱讀需求文檔。把握需求； 種形式各有利弊，但往往非正式的評審比正式更有甚者，沒有執(zhí)行需求評審的進(jìn)入條件，在評楊工編制的需求分析說明書，未進(jìn)行內(nèi)部評的評審效率更高，更容易發(fā)現(xiàn)問題。因此在評審文檔中存在大量的低級的錯誤或者沒有在評審； 審時，應(yīng)該更靈活地利用這2種方式。審前進(jìn)行溝通，文檔中存在方向性的錯誤，從而需求分析說明書（或項目范圍說明書）未與 導(dǎo)致評審的效率很低，質(zhì)量很差。對評審的準(zhǔn)備C公司達(dá)成一致，未提交給S主管確認(rèn)簽字；建議三：分階段評審 工作，也應(yīng)當(dāng)定義一個檢查單，在評審之前對照楊工在范圍控制上做得不好。應(yīng)該在需求形成的過程中進(jìn)行分階段的評檢查單落實每項準(zhǔn)備工作。審，而不是在需求最終形成后再進(jìn)行評審。分 〔問題3〕 階段評審可以將原本需要進(jìn)行的大規(guī)模評審拆確定范圍變更是否已經(jīng)產(chǎn)生； 分成各個小規(guī)模的評審，降低了需求返工的風(fēng)對造成范圍變更的因素施加影響，以確保這險，提高了評審的質(zhì)量。 工作分解結(jié)構(gòu) 些變更得到一致的認(rèn)可。性需求后進(jìn)行一次評審，在形成系統(tǒng)的初次概當(dāng)范圍變更發(fā)生時，對實際的變更進(jìn)行管理。要需求后進(jìn)行一次評審， 范圍管理2009下（以上為書本上的，me考試寫的是： 幾個部分，對每個部分進(jìn)行各個評審，最終再C公司是一家從事電子商務(wù)的外國公司，為重新編制項目范圍說明書，與C公司達(dá)成一對整體的需求進(jìn)行評審。了在中國開展業(yè)務(wù)，派出S主管和W翻譯來中國致，并讓S主管確認(rèn)簽字；尋找合適的系統(tǒng)集成商，試圖在中國建設(shè)一套業(yè)建立整體變更控制流程，做好范圍控制。建議四：精心挑選評審員 務(wù)系統(tǒng)。S主管精通軟件開發(fā)，但是不懂漢語，需求評審可能涉及的人員包括：需方的高而W翻譯對計算機(jī)相關(guān)技術(shù)知之甚少。層管理人員、中層管理人員、具體操作人員、W翻譯通過中國朋友介紹，找到了從事系統(tǒng)集成第8章 項目進(jìn)度管理 IT主管、采購主管；供方的市場人員、需求分的H公司。 項目進(jìn)度 析人員、設(shè)計人員、測試人員、質(zhì)量保證人員、目經(jīng)理，與C公司進(jìn)行交流。經(jīng)過需求調(diào)研，楊【說明】 實施人員、項目經(jīng)理以及第三方的領(lǐng)域?qū)＜业裙ふJ(rèn)為，C公司想要建設(shè)一個視頻聊天網(wǎng)站，并某系統(tǒng)集成公司現(xiàn)有員工50多人，業(yè)務(wù)部等。在這些人員中由于大家所處的立場不同，據(jù)此完成了系統(tǒng)方案。在W的翻譯下，S審閱并門分為銷售部、軟件開發(fā)部、系統(tǒng)網(wǎng)絡(luò)部等。經(jīng)對同一個問題的看法是不相同的，有些觀點(diǎn)是認(rèn)可了H公司的系統(tǒng)方案。經(jīng)過進(jìn)一步的談判，過近半年的醞釀后，在今年一月份，公司的銷和系統(tǒng)的目標(biāo)有關(guān)系的，有些是關(guān)系不大的，C公司和H公司簽訂了合同，并把該系統(tǒng)方案作售部直接與某銀行簽訂了一個銀行前置機(jī)的軟不同的觀點(diǎn)可能形成互補(bǔ)的關(guān)系。為了保證評為合同附件，作為將來項目驗收的標(biāo)準(zhǔn)。件系統(tǒng)的項目。合同規(guī)定，6月28日之前系統(tǒng)審的質(zhì)量和效率，需要精心挑選評審員。首先合同簽訂后，楊工迅速組織人力投入系統(tǒng)開必須投入試運(yùn)行。在合同簽訂后，銷售部將此要保證使不同類型的人員的都要參與進(jìn)來，否發(fā)。由于楊工系統(tǒng)集成經(jīng)驗豐富，開發(fā)過程進(jìn)展合同移交給了軟件開發(fā)部，進(jìn)行項目的實施。項目經(jīng)理小丁做過5年的系統(tǒng)分析和設(shè)計工作，但這是他第一次擔(dān)任項目經(jīng)理。小丁兼任系統(tǒng)分析工作，此外項目還有2名有1年工作經(jīng)驗的程序員，1名測試人員，2名負(fù)責(zé)組網(wǎng)和布線的系統(tǒng)工程師。項目組成的成員均全程參加項目。大家稱之為“救火隊長”，而強(qiáng)某也對自己信心十足。但這次和以往不同的是強(qiáng)某還同時管理著另外兩個項目，而這個人口管理系統(tǒng)項目的工期要求緊、他能調(diào)用的人手少。該人口管理系統(tǒng)項目屬于升級項目。原來的系統(tǒng)為J公司日期間因春節(jié)假期也無法組織人員安排模塊聯(lián)調(diào)，項目進(jìn)度拖后已成定局。【問題1】（8 分）請簡要分析項目進(jìn)度拖后的可能原因?【問題2】（4分）請簡要敘述進(jìn)度計劃包括關(guān)鍵鏈法；項目管理軟件；應(yīng)用日歷；調(diào)整時間提前與滯后量；進(jìn)度模型。在承擔(dān)項目之后，小丁組織大家制定了項目的WBS，并依照以往的經(jīng)歷制訂了本項目的進(jìn)度計劃，簡單描述如下：應(yīng)用子系統(tǒng)1）1月5日～2月5日需求分析2）2月6日～3月26日系統(tǒng)設(shè)計和軟件設(shè)計3）3月27日～5月10日編碼4）5月11日～5月30日系統(tǒng)內(nèi)部測試綜合布線2月20日～4月20日完成調(diào)研和布線網(wǎng)絡(luò)子系統(tǒng)4月21日～5月21日設(shè)備安裝、聯(lián)調(diào)系統(tǒng)內(nèi)部調(diào)試、驗收1）6月1日～6月20日試運(yùn)行2）6月28日系統(tǒng)驗收春節(jié)后，在2月17日小丁發(fā)現(xiàn)系統(tǒng)設(shè)計剛剛開始，由此推測3月26日很可能完不成系統(tǒng)設(shè)計?！締栴}1】（4分）請用150字以內(nèi)的文字，分析問題發(fā)生的可能原因。【問題2】（5分）請用150字以內(nèi)的文字，建議小丁應(yīng)該如何做以保證項目整體進(jìn)度不拖延?！締栴}3】（6分）請用200字以內(nèi)的文字，概述典型的信息系統(tǒng)集成項目的進(jìn)度／時間管理的過程和方法以及資源配置對進(jìn)度的制約。答：【問題1】（1）銷售部沒有及時讓軟件開發(fā)部參與項目早期工作，需求分析耗時過長；（2）項目經(jīng)理首次擔(dān)任，經(jīng)驗不足，進(jìn)度估算不準(zhǔn)確；（3）項目資源配置不足，項目經(jīng)理兼任系統(tǒng)分析，缺乏專門的系統(tǒng)分析和設(shè)計人員（4）工作安排沒有充分利用分配的項目資源，資源有閑置；（5）在安排進(jìn)度時可能未考慮法定節(jié)假日的因素【問題 2】（1）向職能經(jīng)理申請增加特定資源，特別是增加系統(tǒng)分析設(shè)計人員；（2）將部分階段的工作改為并行進(jìn)行，以節(jié)約時間；（3）臨時加班/趕工，盡可能補(bǔ)救耽誤的時間；（4）對后續(xù)工作的工期重新進(jìn)行估算，并考慮節(jié)假日問題，修訂計劃，盡量留有余地；（5）加強(qiáng)溝通，爭取客戶能夠?qū)椖糠秶约靶枨?、設(shè)計、驗收標(biāo)準(zhǔn)進(jìn)行確認(rèn)，避免后期頻繁出現(xiàn)變更。（6）加強(qiáng)對階段性工作的檢查和控制，避免后期出現(xiàn)返工。此外，如有可能還可采取外包和縮減范圍等辦法，不過不建議在本案例中采用?！締栴} 3】進(jìn)度管理的過程資源對進(jìn)度的影響（1）一般情況下，項目活動歷時與投入的資源數(shù)量成反比，即投入的資源數(shù)量越多，活動歷時越短。但是，當(dāng)針對某一活動的資源投入數(shù)量達(dá)到一定規(guī)模時，再增加資源的投入不會進(jìn)一步縮短項目活動歷時，也就是資源投入遞減規(guī)律（2）非關(guān)鍵路徑上的活動歷時只對項目產(chǎn)生