【正文】 了密切的合作關(guān)系，李工也參加了原系統(tǒng)的需求開發(fā)，對業(yè)務(wù)的系統(tǒng)比較熟悉，因此定義的需求是清晰的。進入編碼階段后，李工因故移民加拿大，需要離開項目組。在系統(tǒng)交付的時候，M公司的業(yè)務(wù)代表認為已經(jīng)提出的需求很多沒有實現(xiàn)，實現(xiàn)的需求也有很多不能滿足業(yè)務(wù)的要求，必須全部實現(xiàn)這些需求后才能驗收。最終系統(tǒng)需求發(fā)生重大變更，項目延期超過50%, M的業(yè)務(wù)代表也因為系統(tǒng)的延期表示了強烈的不滿。【問題2】(9分)請從項目范圍管理的角度找出該項目實施過程中的問題，以500字內(nèi)回答。案例分析這是一個失敗的軟件項目，與很多失敗的軟件項目一樣，在系統(tǒng)需求上栽了跟頭。案例中的項目經(jīng)理張工就是既重視需求又沒有控制好需求的一個例子。對于這樣的項目，首先需要熟悉原有的系統(tǒng)，然后才能談升級的問題。這無疑是一個很好的辦法，可以快速準(zhǔn)確地把握新系統(tǒng)的需求。李工也沒有讓張工失望，很快就整理出了新系統(tǒng)的需求，并進入了設(shè)計和編碼階段，除了客戶太忙沒有時間確認需求外，一切盡在張工的掌握之中。就如同大多數(shù)經(jīng)典的悲劇故事一樣，故事的序幕是美好的。不過僅僅是一片烏云而已，并沒有下起雨來。經(jīng)過項目組努力，項目終于完成開發(fā)，準(zhǔn)備發(fā)布了?？蛻舨徽J可項目組的工作，認為很多需求沒有實現(xiàn)，實現(xiàn)的功能也與需求不符。至多可以在雙發(fā)的協(xié)商下少一些變更，項目延期不是50%,而是30％而已。從項目管理的角度來說，項目范圍直接決定了工作量和工作目標(biāo)，所以項目經(jīng)理必須管理項目的范圍。范圍定義是基礎(chǔ)的活動，不進行范圍定義就不能進行范圍確認和范圍控制。范圍控制的作用在于減少變更，保持項目范圍的穩(wěn)定性。在軟件系統(tǒng)的開發(fā)中，系統(tǒng)需求就是項目的范圍。因此需求確認或者說是范圍確認就顯得更為重要。以現(xiàn)在軟件行業(yè)的情況，這種說法是不無道理的。召集客戶的業(yè)務(wù)代表對需求進行評審、詳細記錄最原始的調(diào)研材料，讓客戶確認調(diào)研報告、采用迭代開發(fā)逐步確認系統(tǒng)需求，都是可以采用的方法。再回到這個案例，項目經(jīng)理張工樂觀認為李工開發(fā)的需求沒有什么問題，也誤認為雙方已經(jīng)有良好的合作，在不緊逼要求客戶代表簽字顯得不近人情，于是就抱著僥幸信息進入了開發(fā)。有了上面的分析，后面問題的答案就不難得出。前面已經(jīng)提到，張工注意到了需求的問題，專門找到了原系統(tǒng)需求負責(zé)人李工進行需求開發(fā)，這是對項目有利的一面。對于第二題，聯(lián)系范圍管理的知識，我們不難發(fā)現(xiàn)張工在范圍確認和范圍控制中都有重大的缺陷，在范圍定義中也由于缺乏評審造成需求的質(zhì)量問題。參考答案【問題1】(8分)(1)張工為了更明確地把握系統(tǒng)需求，聘請了原系統(tǒng)的需求調(diào)研人員李工，提高了需求定義的效率和質(zhì)量。(3)張工沒有要求用戶對已經(jīng)定義的需求進行確認，從而導(dǎo)致需求理解的偏差。(3分)(2)在范圍確認中，張工沒有主動地要求用戶對需求進行確認。(3分)【問題3】(8分)對于本案例，項目經(jīng)理需要對需求定義的結(jié)果進行質(zhì)量控制，采取評審等方式減少需求中的問題。在發(fā)生需求變更時，也應(yīng)該采取靈活的手段，在滿足用戶需求的前提下，盡量減少需求變更的范圍。在給定的時間完成項目是項目的重要約束性目標(biāo)，能否按進度交付是衡量項目是否成功的重要標(biāo)志。同時，由于項目管理是一個帶有創(chuàng)造性的過程，項目不確定性很大，項目的進度控制是項目管理中的最大難點。案例場景A公司計劃把現(xiàn)有的骨干系統(tǒng)改建成新的系統(tǒng)，該項目中是一個大型項目。用項目網(wǎng)絡(luò)圖表示對進度的估計，如圖38所示。【問題2】(15分)由于市場發(fā)生變化，A公司想把此項目的進度縮短兩個月。此時應(yīng)該采取什么措施，并簡述其理由。圖39,圖310表示的是同一項目網(wǎng)絡(luò)圖的兩種不同畫法。網(wǎng)絡(luò)圖應(yīng)伴有一個簡潔說明，以描述基本排序方法。 (1)前導(dǎo)圖法(PDM )是編制項目網(wǎng)絡(luò)圖的一種方法，利用節(jié)點代表活動而用節(jié)點間箭頭表示活動的相關(guān)性。PDM法可用手算也可用計算機實現(xiàn)。①結(jié)束一開始：某活動必須結(jié)束，然后另一活動才能開始。③開始一開始：某活動必須在另一活動開始前開始。在PDM法，結(jié)束一開始是最常見邏輯關(guān)系，開始一結(jié)束關(guān)系極少使用。 (2)箭頭圖方法(ADM)是項目網(wǎng)絡(luò)圖的另一種方法，箭線表示活動，用節(jié)點連接箭線，以示相關(guān)性。這種技巧也叫箭線代表活動(AOA)，雖比PDM法較少使用，但在某些應(yīng)用領(lǐng)域仍是一種可供選擇的技巧。ADM法可手算也可在計算機上實現(xiàn)。實際上，PERT圖是一類特殊類型的項目網(wǎng)絡(luò)圖，今日這種圖很少應(yīng)用了。畫好的項目網(wǎng)絡(luò)圖如圖311所示。【問題2】圖311的關(guān)鍵路徑是A3B3C5P8Q10H4R2(用粗線表示)。但是，與移交有關(guān)的工作和單元測試以后的工作不能縮短，也就是說P8Q10H4R2不能縮短，能夠縮短的只有A3B3C5。 (2)新的系統(tǒng)是在“現(xiàn)有的骨干系統(tǒng)”的基礎(chǔ)上改建的?？晒┛紤]的措施，只有把P8提前到B3之后(④)開始，而不是在C5之后。根據(jù)上述內(nèi)容，我們可以這樣說：①應(yīng)該移交的內(nèi)容在概要設(shè)計完成后就已經(jīng)清楚了。那么這樣做之后是否能夠縮短兩個月呢？從④到⑩，修改前需要23個月。還應(yīng)該注意的是，PQ路徑以前限制在18個月內(nèi)完成，現(xiàn)在可以放寬到21個月了。參考答案【問題1】(10分)(圖313)【問題2】(15分)措施：在概要設(shè)計B完成后即開始制定移交計劃P。b. 不能縮短，而縮短設(shè)計工作的時間又會產(chǎn)生不良的后果。這樣做可以允許多用3個月的時間把移交計劃和移交工作做得更好。項目的成本管理對于組織來說非常重要，成本管理并不只是把項目的成本進行監(jiān)控和記錄，而是需要對成本數(shù)據(jù)進行分析，以發(fā)現(xiàn)項目的成本隱患和問題，在項目遭受可能的損失之前采取必要的行動。例如：在信息系統(tǒng)項目中，減少測試無疑能夠減少項目的費用，但沒有測試，如同許多曾經(jīng)進行過的信息系統(tǒng)一樣，把用戶當(dāng)做測試者，可能對項目造成災(zāi)難性的后果，最終，或者使得項目的成本大為提高，或者讓項目走向失敗的邊緣。案例場景某A單位的電力信息應(yīng)用系統(tǒng)(簡稱A系統(tǒng))，系統(tǒng)建設(shè)總投資是1100萬元，其中主機采購、存儲系統(tǒng)采購、網(wǎng)絡(luò)設(shè)備采購、配件采購等花費500萬元，應(yīng)用軟件開發(fā)600萬元。項目總工期為25周，計劃從2005年5月1甲啟動至2005年10月22日全部完工。B公司安排高工李工負責(zé)A系統(tǒng)的建設(shè)工作。李工于項目正式啟動之前兩周開始進行項目建設(shè)的準(zhǔn)備工作，對工程項目進行了工作分解，在工作分解的基礎(chǔ)上，編制了項目資源計劃、人員計劃、項目質(zhì)量保障計劃、進度計劃、項目成本預(yù)算和成本控制計劃等。于2005年5月1日項目正式啟動時，項目小組也組建完成。由于軟件項目開發(fā)的主要成本為人力資源成本，為此，李工制定了詳細的人力資源成本控制計劃，人力資源計劃成本=12人25周平均人周成本(1500元) =450 000元。李工所進行的項目工作分解，得到共24個系統(tǒng)功能模塊，分別編號為M0M0……、M24，并分別為每個功能模塊制定了工期和成本預(yù)算。在項目開發(fā)的過程中，李工隨時跟蹤統(tǒng)計項目的開支情況。如表49所示?！締栴}1】(6分)請以200字左右回答，李工的成本預(yù)算存在哪些問題？李工所采取的成本跟蹤管理的方法是什么方法？應(yīng)用軟件系統(tǒng)開發(fā)項目中，使用此方法應(yīng)注意什么特點？【問題2】(10分)請以200字左右回答，衡量軟件開發(fā)實際累積人力資源成本的計算公式是什么？怎樣改進上述方法才能控制好人力資源成本？怎樣得到軟件企業(yè)實際消耗的人力資源成本？【問題3】(9分)請以300字內(nèi)回答，李工采用此方法的具體措施是否存在不足之處？如存在，請指出不足并說明理由，請給出你的改進意見。但是，IT應(yīng)用系統(tǒng)開發(fā)工程項目有其特殊的特點，掙值管理方法的應(yīng)用必須結(jié)合IT工程項目的特點進行，才能夠收到理想的效果。在過去的應(yīng)用軟件工程項目中，很少采用掙值管理來控制項目進度款支付。項目經(jīng)理應(yīng)當(dāng)熟練掌握掙值管理方法。在李工的成本估算中，缺少了對工程量的估算，因此，對人力資源成本的估算也就缺少了依據(jù)。當(dāng)然，如果要把預(yù)算做得更準(zhǔn)確，還需要估算各模塊的代碼量，以歷史經(jīng)驗得到每個成員的工作效率來計算各模塊所需的工作量，但這種做法目前在我國還沒有多少成功的案例，很多IT公司均是靠經(jīng)驗來進行估算的。而為了合理有效地控制人力資源使用成本，在組建項目小組的時候，可以根據(jù)工程項目的進度情況，分階段投入人力資源，要做好與其他工程項目協(xié)調(diào)使用人力資源。本題的主要考點在于怎樣在軟件開發(fā)項目中合理、有效地進行掙值管理。軟件工程項目與建筑工程項目有很大的區(qū)別。如表410所示。因此，掙值管理方法也使用得比較好。軟件工程項目的成本控制的困難有以下原因。(2)規(guī)模和工作量的不確定性：軟件項目的工作量預(yù)算難以估計準(zhǔn)確。(4)把握需求的不確定性：已經(jīng)編寫完成的軟件代碼，可能隱藏著對需求理解的嚴重偏差，可能是廢品，得全部返工。(6)人員的不確定性：如果編寫軟件代碼的人員不穩(wěn)定，熟練員工中途流失將給項目進度、質(zhì)量管理帶來嚴重影響。員工的敬業(yè)精神也難以衡量。【問題3】在軟件項目的開發(fā)管理中采用掙值分析時，可以考察各模塊的完成狀態(tài)，全部完成并且集成測試成功，能夠投入初步運行，這樣，可以算本模塊的工作量完成，可以獲得本模塊的全部掙值，否則，本模塊的掙值計0。但我們在實際工作中，也有很多時候采用估算某模塊完成百分之幾的做法，但這種做法是粗放式的，項目管理人員可以將這信息作為對項目成本累積的參考，作為粗略估計項目進度的參考，但不是成本核算的依據(jù)，也不能作為申請工程進度款支付的依據(jù)，需知這種信息的可信度和可控性均較差。李工的項目小組的建設(shè)應(yīng)分階段進行人力資源投入，如設(shè)計階段所用人力應(yīng)較少，而詳細設(shè)計完成后，編碼階段進入，則人力投入是高峰期。李工所采用的是掙值管理方法?！締栴}2】(10分)軟件開發(fā)人力資源成本掙值統(tǒng)計是能夠做到比較準(zhǔn)確的，衡量軟件開發(fā)人力資源成本的計算公式： 累積人力資源成本=模塊工作量i完成率i平均人力周成本李工所采取的方法應(yīng)增加各模塊工程量的估算，就能夠進行人力資源成本控制。實際消耗的人力資源成本可通過財務(wù)發(fā)放的工資統(tǒng)計得到。在軟件開發(fā)中，各模塊的進度百分比通常很難測量準(zhǔn)確，而各工程師的匯報往往是很粗略的估計，這種估計只能提供給項目經(jīng)理控制進度時做參考，但不能作為成本核算或申請工程進度款支付的依據(jù)。另外，在核算的時候，要扣除一定的比例，如20%～30%作為各模塊集成所需要的工程量，待工程全面完工后進行核算。在信息系統(tǒng)項目中，一般把《系統(tǒng)需求規(guī)格說明書》作為項目需求的基礎(chǔ)性文件。質(zhì)量管理的目的是通過執(zhí)行項目質(zhì)量管理過程，使用一些基本項目管理工具和技術(shù)來保證信息系統(tǒng)的質(zhì)量。閱讀以下關(guān)于信息系統(tǒng)項目管理過程中項目質(zhì)量管理方面問題的敘述，回答問題1至問題3。該系統(tǒng)中關(guān)于組織機構(gòu)的業(yè)務(wù)規(guī)則如下：(1)組織機構(gòu)樹通過部門編碼體現(xiàn)層級和隸屬關(guān)系。(2)任意一條業(yè)務(wù)數(shù)據(jù)隸屬于某個特定的部門。關(guān)系為友好的部門可以共享業(yè)務(wù)數(shù)據(jù)，關(guān)系為互斥的部門互相不能訪問對方的業(yè)務(wù)數(shù)據(jù)。(2)組織機構(gòu)根據(jù)最新的企業(yè)標(biāo)準(zhǔn)重新生成。、(4)系統(tǒng)中可以保留組織機構(gòu)調(diào)整的痕跡，業(yè)務(wù)數(shù)據(jù)可以追蹤除原屬于哪個部門，機構(gòu)調(diào)整后屬于哪個部門。(6)升級后的系統(tǒng)需要能夠適應(yīng)再次的組織機構(gòu)調(diào)整而不需要再次升級。(2)新的企業(yè)標(biāo)準(zhǔn)沒有考慮到原有企業(yè)標(biāo)準(zhǔn)，同是一個部門張工在原標(biāo)準(zhǔn)中為00010001，在新標(biāo)準(zhǔn)中為00010005,部門的層次也可能發(fā)生變化。(4)原系統(tǒng)在設(shè)計時將部門間的友好與互斥關(guān)系硬編碼在系統(tǒng)代碼中，且涉及面很廣，原系統(tǒng)中80％以上的程序存在這樣的硬編碼。(6)原系統(tǒng)在設(shè)計時沒有考慮到組織機構(gòu)調(diào)整的可能，也沒有對保留部門變革歷史的功能進行設(shè)計。一旦設(shè)計出現(xiàn)偏差，返工的工作量會非常巨大，反之，整個項目還是容易控制的。【問題1】(8分)試以300字內(nèi)回答，張工可以采取哪些措施提高設(shè)計的質(zhì)量？【問題2】(9分)試以300字內(nèi)回答，除設(shè)計外，張工還需要特別注意哪些工程活動。案例分析這是一個開放式的案例分析題，案例中僅粗略地描述了項目背景的目標(biāo)，針對如何提高項目質(zhì)量進行發(fā)問，難度相對較大，需要仔細的分析。(2)原系統(tǒng)中存在設(shè)計缺陷，沒有考慮過組織機構(gòu)改革的可能性。(4)需要更改已有的業(yè)務(wù)數(shù)據(jù)，同時增加部門變革歷史的功能。結(jié)合案例后的問題，我們不難發(fā)現(xiàn)，案例的前半部分是引子，后半部分才是關(guān)鍵，也是該案例的題眼：如何提高項目的質(zhì)量，顯然需要用項目質(zhì)量管理的知識作答。這也正是這個案例的用意所在，考察考生在面對實際的項目問題時需要采取哪些措施解決項目的質(zhì)量問題。軟件的質(zhì)量一直是軟件界近幾十年致力解決的問題，針對使用軟件提高軟件質(zhì)量提出了很多的方法和理論。在軟件工程中，人們提出了多種軟件開發(fā)模式和工程活動方法。除此之外，還有一系列的軟件驗證方法，如軟件復(fù)審與軟件測試。因為在軟件開發(fā)過程中，還有一個很明顯的特點，就是在分析、設(shè)計、實現(xiàn)和測試這些過程中，每一步都可能引入缺陷，且難以發(fā)現(xiàn)，而這些缺陷暴露得越晚，造成的后果就越嚴重，修改的代價就越高昂。題目中問的是如何提高設(shè)計的質(zhì)量，設(shè)計是承接分析、指導(dǎo)開發(fā)的一個關(guān)鍵環(huán)節(jié)，在這個環(huán)節(jié)中很容易引入難以發(fā)現(xiàn)的缺陷，而這些缺陷往往又會造成嚴重的后果。提高設(shè)計質(zhì)量包括兩個層面的工作：在設(shè)計過程中提高設(shè)計的質(zhì)量；在設(shè)計完成后對設(shè)計結(jié)果的質(zhì)量檢查。設(shè)計工作在分析工作之后，因此，充分的分析是保證設(shè)計質(zhì)量的前提。因此要想提高設(shè)計的質(zhì)量，首先要充分了解原系統(tǒng)。不過在這方面，案例中給出的信息甚少，顯然不是答題的重點。因此張工需要制定出相應(yīng)的溝通計劃，組織必要的會議進行方案討論，若有必要還需要客戶和原系統(tǒng)的開發(fā)者參加。評審和走查可以比測試更早地找出工作產(chǎn)品中的缺陷，用來檢查設(shè)計質(zhì)量非常合適，可以避免缺陷在系統(tǒng)測試階段才被發(fā)現(xiàn)