【正文】 迭代的方法驗證設(shè)計的正確性，提高設(shè)計的質(zhì)量。參考答案【問題1】(8分)張工可以采取以下措施提高設(shè)計的質(zhì)量：(1)充分分析問題域是保證設(shè)計質(zhì)量前提。除了這些方法外，對分析的結(jié)果進行評審也是保證分析質(zhì)量的一種有效的方法。對原設(shè)計方案的分析出了參考設(shè)計文檔外，最好能夠同原系統(tǒng)的開發(fā)者進行溝通，這樣的溝通往往能獲取到文檔之外的寶貴信息。對原系統(tǒng)的分析可以包括對原有業(yè)務(wù)功能、原設(shè)計方案和原程序的分析。有了第二個問題的答案，第三個問題就比較容易了。除了分析和測試外，其余的工程活動也是不可或缺的，不過相比之下，分析和測試工作更具特殊性，是張工必須特別注意的。這些程序在修改后首先需要滿足同原系統(tǒng)功能一致，可以通過原系統(tǒng)測試用例的測試；其次還要保證與系統(tǒng)升級的目標一致，能夠滿足設(shè)計的 要求，這就需要開發(fā)新的測試用例進行測試。同原系統(tǒng)開發(fā)相比，系統(tǒng)改造的總工作量相對較少，但測試的工作量卻應(yīng)該超過原系統(tǒng)開始時的測試工作量。因此充分、細致地分析原系統(tǒng)是保證設(shè)計質(zhì)量的前提。在分析第一個問題是我們已經(jīng)找到了一部分答案—分析。如果能夠做好上述工作，設(shè)計就不會產(chǎn)生重大的偏差，保證設(shè)計的質(zhì)量。除了評審和走查外，對設(shè)計過程進行迭代也可以提前暴露設(shè)計的缺陷，并將這些缺陷反饋到后續(xù)的設(shè)計過程中，從總體上減少缺陷數(shù)，提高設(shè)計的質(zhì)量。在設(shè)計完成后還需要對設(shè)計結(jié)果進行質(zhì)量檢查，對應(yīng)這類活動，我們通常采用評審和走查的方式。根據(jù)項目背景的描述，這個設(shè)計工作并不簡單，需要論證的過程，設(shè)計方案的討論也是必需的。在設(shè)計時還應(yīng)該選擇恰當?shù)脑O(shè)計方法，如有可能可以考慮復(fù)用已有的解決案例，如分析模式與設(shè)計模式等。對于這種改造型項目，原系統(tǒng)的功能、設(shè)計和實現(xiàn)的情況直接影響了設(shè)計的結(jié)果，原系統(tǒng)的情況就是要解決的問題域，’如果對原系統(tǒng)了解不足必然導(dǎo)致設(shè)計上的偏差。在答題中需要分別給出相應(yīng)的策略。因此提高設(shè)計的質(zhì)量是每個軟件項目都會遇到的問題，也是每個項目經(jīng)理都會思考的問題。開發(fā)活動需要盡量提前發(fā)現(xiàn)潛在的缺陷，驗證手段必不可少。縱觀這些林林總總的模式與方法，人們無非是想解決兩個問題：一是通過恰當?shù)墓こ袒顒犹岣吖ぷ鳟a(chǎn)品的質(zhì)量；二是在工作產(chǎn)品完成后通過恰當?shù)墓こ袒顒觼肀ＷC該產(chǎn)品的質(zhì)量。在開發(fā)模式中，有瀑布模型、螺旋模型、迭代模型、噴泉模型等；在工程活動方法中，有自頂向下、結(jié)構(gòu)化分析、面向?qū)ο蠓治觥⒓軜?gòu)風格，等等。首先是軟件工程的理論，需要使用工程活動的方法進行軟件開發(fā)，從系統(tǒng)定義與分析開始，經(jīng)過設(shè)計、實現(xiàn)，最終到驗證。我們首先從軟件工程的角度考慮一下軟件質(zhì)量的問題。質(zhì)量管理是項目管理中的一個知識域，但在PMBOK中并沒有給出具體的質(zhì)量管理的方法，需要結(jié)合軟件開發(fā)和項目的特點給出特定的質(zhì)量管理策略和方法?；谶@些問題，案例的后半部分給出了張工的觀點：設(shè)計質(zhì)量是項目的關(guān)鍵，需要提高設(shè)計的質(zhì)量。(3)需要大量更改原系統(tǒng)的程序，消除硬編碼。前面一部分對項目背景和目標的描述無非是為了說明這么幾個問題：(1)這是一個系統(tǒng)改造的項目?！締栴}3】 (8分)試以300字內(nèi)回答，如何提高這些工程活動的質(zhì)量。但張工在如何提高設(shè)計質(zhì)量方面卻犯了愁。張工認為，需求已經(jīng)非常明確，對于這個項目的關(guān)鍵是設(shè)計的質(zhì)量，其中包括解決方案的設(shè)計和業(yè)務(wù)系統(tǒng)的改造兩部分。(5)不少業(yè)務(wù)邏輯和工作流程是根據(jù)特定的部門編碼進行判斷的，部門編碼的變化會造成業(yè)務(wù)混亂。(3)業(yè)務(wù)數(shù)據(jù)中保存了隸屬部門編碼，系統(tǒng)已經(jīng)使用近兩年，保存了大量的歷史業(yè)務(wù)數(shù)據(jù)。項目經(jīng)理張工接受了這個項目，經(jīng)過細致的調(diào)研和分析，發(fā)現(xiàn)原系統(tǒng)存在如下缺陷：(1)原系統(tǒng)中將企業(yè)對部門的標準編碼設(shè)計為部門主鍵，修改起來難度很大，容易發(fā)生數(shù)據(jù)不一致的問題。(5)部門間友好和互斥的關(guān)系可能會被重新定義。(3)組織結(jié)構(gòu)調(diào)整是不能丟失業(yè)務(wù)數(shù)據(jù)。后來，K公司需要調(diào)整部門的組織結(jié)構(gòu)，因此對系統(tǒng)提出了升級的要求：(1)系統(tǒng)中的部門編碼需要更新為最新的企業(yè)標準。(3)部門之間存在友好和互斥的關(guān)系。即部門0001的下屬部門包括000100000010002,依次類推，根據(jù)代碼中包含的層級關(guān)系確定某 個部門在組織機構(gòu)樹中的確切位置，該編碼由公司統(tǒng)一制定。案例場景金博聯(lián)信息技術(shù)有限公司(CIU)曾經(jīng)為K公司開發(fā)過一套信息系統(tǒng)，該系統(tǒng)涉及了K公司的所有主要業(yè)務(wù)。時間、成本、質(zhì)量是項目管理的三大目標，如果質(zhì)量不能滿足要求，即使進度再快，成本再節(jié)省，項目也沒有意義。質(zhì)量管理作為項目管理的一部分，具有非常重要的地位。質(zhì)量是“使實體具備滿足明確或隱含需求能力的各項特征之總和”，明確或隱含的需求是指按項目需求制定的基礎(chǔ)性文件。建議李工以各模塊全面完工來進行計算，即各模塊要么計算0％，要么計算100%完工，但在進行工作分解的時候，分解的深度和各模塊的粒度要合適，便于進行控制?！締栴}3】(9分)李工根據(jù)各工程師的進度報告(進度百分比)來計算掙值，在軟件開發(fā)中是不可行的。如表411所示。此方法應(yīng)用到軟件工程項目中，應(yīng)注意軟件開發(fā)掙值與投入的非線性比例關(guān)系特點。人力資源成本的預(yù)算也應(yīng)當核算一定比例的浮動成本。參考答案【問題1】(6分)應(yīng)當先估算各模塊的工程量，再以工程量來估算所需要的人力資源，如總工程量“人周”或“人月”或“人年”等。考慮到工程整體的集成還需要一定成本，因此，在計算各模塊掙值時，還應(yīng)當扣除一定比例的掙值，作為工程整體集成的工作量的掙值。由于以上這些因素的影響，使得在軟件工程項目中對工程進度和工程質(zhì)量的測量變得很困難，因而，我們就不可能像在建筑項目中那樣使用掙值管理方法了。新人中途接手未全面完成的、風格不良的軟件代碼，是一件很困難的工作。(5)難易程度的不確定性：已經(jīng)編寫完成的軟件代碼可能是很簡單的，未完成的可能很難，或反之。(3)質(zhì)量鑒定的不確定性：開發(fā)完成并投入運行的軟件模塊的質(zhì)量難以鑒定，特別如某個模塊完成了30％或80％的工作量，我們無法去鑒定，或用于鑒定的成本可能很高而使開發(fā)單位難以接受或不愿意去做這樣的鑒定。(1)需求的不確定性：軟件項目的范圍、需求難以準確地定義，導(dǎo)致項目開發(fā)過程中存在大量的變更，從而影響進度和成本。但在軟件工程項目中，要合理、合適地采用掙值分析方法是比較困難的。在建筑工程項目中，工程進度與成本之間的線性比例關(guān)系較好，而且進度容易測量。軟件工程項目更加類似于科研項目。要合理使用掙值管理方法，必須同時考慮到軟件工程項目的特點。我們也可用人力資源成本來計算掙值，人力資源使用成本的實際值可向財務(wù)查詢所支付的成本，掙值可以這樣計算：累積人力資源成本(掙值)=模塊工作量i完成率i平均人力周成本這種計算是在承建單位內(nèi)部的成本控制。【問題2】對于大多數(shù)應(yīng)用軟件開發(fā)項目來說，工程成本的主要構(gòu)成要素是人力資源使用成本。對工作量的估算，如M0l模塊需要16“人周”，M02模塊需要6“人周”，或以“人月”、“人年”為單位來估算工作量，各模塊的工作量合起來，就可得到整個項目的工作量。軟件項目的合同價格不等于軟件項目開發(fā)的實際成本，合同價格除了承建單位的軟件開發(fā)成本外，還包括銷售成本、行政費用、稅金、利潤等，但我們在這里探討的主要是項目開發(fā)成本，即工程成本。但隨著IT項目管理水平的提高，隨著我國IT工程監(jiān)理制度的推廣，將來采用掙值管理控制工程進度款支付也是可期待的。另外，IT應(yīng)用系統(tǒng)工程項目的成本預(yù)算也是比較困難的課題，我們往往很難像其他工程項目(如建筑工程項目)那樣，將IT應(yīng)用系統(tǒng)工程項目的成本預(yù)算做得準確。案例分析【問題1】掙值管理方法是應(yīng)用非常廣泛的項目成本管理方法。李工根據(jù)表49的統(tǒng)計數(shù)據(jù)計算累積完工的工程價值，計算公式為： 。李工要求每位軟件工程師每周報告一次工作進度，如某某模塊完成工作量30％，李工據(jù)此來估算項目的進度和成本績效。如表48所示。為了將軟件開發(fā)人力資源費用控制在45萬元內(nèi)，李工制定了詳細的工程成本管理計劃。李工所組建的項目小組為12人，包括軟件設(shè)計、編碼工程師8人，軟件測試工程師4人。李工編制完項目資源計劃后，報告公司審批，包括項目小組組建的計劃在內(nèi)的項目資源計劃順利地通過了公司審批。B公司的績效考核制度是非常嚴格的，對項目負責人的考核，項目開工前要制訂項目實施計劃，項目完工后要對項目計劃的執(zhí)行情況進行考核，項目的進度、質(zhì)量、成本三大目標都要求控制在計劃的范圍內(nèi)。B公司是一家民營高科技信息系統(tǒng)集成企業(yè)，有高級工程師2人，軟件、硬件、網(wǎng)絡(luò)工程師共36人。2005年4月工程雙方簽訂項目開發(fā)合同，由B公司負責承建。閱讀以下關(guān)于信息系統(tǒng)項目管理過程中成本控制方面問題的敘述，回答問題1一問題3。項目成本管理希望節(jié)約項目的費用，但并不意味著要一味減少成本。項目的成本是項目的全過程所耗用的各種費用的總和。，在概要設(shè)計完成后就完全可以著手制定移交計劃。理由：a．原有計劃的關(guān)鍵路徑是，只有設(shè)法縮短這條路徑才行。因此，可以斷定上述措施是切實可行的。修改后，關(guān)鍵路徑變成C5D5E4F3G4，需要有21個，正好縮短了兩個月。②即使需要做一些小的調(diào)整，在C5完成之后也來得及。我們需要找出能夠這樣做的理由。這就是總量的關(guān)鍵所在，也是這個題目不像看上去那么容易的原因所在。此時必須注意以下兩點： (1)縮短設(shè)計工作的時間，往往會在以后發(fā)生重大問題。所需時間是35個月。英文字母后面的數(shù)字是所需時間(月數(shù))?！締栴}1】不管怎樣，首先要完成項目網(wǎng)絡(luò)圖，由于這是常畫的圖，總能夠正確地畫出來。項目網(wǎng)絡(luò)圖經(jīng)常不正確地被稱為PERT圖 (計劃評審技術(shù)) 。ADM僅利用結(jié)束一開始關(guān)系以及用虛工作線表示活動間邏輯關(guān)系。圖310表示用ADM法制作的一個簡單項目網(wǎng)絡(luò)圖。(也許只有職業(yè)進度計劃工程師使用)對管理軟件，如果用開始一開始、結(jié)束一結(jié)束或開始一結(jié)束關(guān)系會產(chǎn)生混亂的結(jié)果，因為很多管理軟件編制時并沒有對這三種類型的相關(guān)性加以考慮。④開始一結(jié)束：某活動結(jié)束前另一活動必須開始。②結(jié)束一結(jié)束：某活動結(jié)束前，另一活動必須結(jié)束。有四種相關(guān)的前驅(qū)關(guān)系。圖39表示一個用PDM法編制的簡單網(wǎng)絡(luò)圖，這種方法也叫活動在節(jié)點法(AON)是大多數(shù)項目管理軟件包所采用的方法。但對不平常排序應(yīng)充分地加以敘述。網(wǎng)絡(luò)圖可手工編制，也可用計算機實現(xiàn)。案例分析項目網(wǎng)絡(luò)圖是項目所有活動，以及它們之間邏輯關(guān)系(相關(guān)性)的一個圖解表示。在此假定前提下，系統(tǒng)的規(guī)模不能縮小，移交計劃和工作，以及部件測試以后的工作不能縮短。【問題1】(10分)用進度估計表中的字母代號把未寫進項目網(wǎng)絡(luò)圖中的工作寫進項目網(wǎng)絡(luò)圖中去。王總對該項目的進度估計如表316所示。閱讀以下關(guān)于信息系統(tǒng)項目管理過程中項目進度估計問題的敘述，回答問題1至問題2。因此，進度控制是項目控制的首要內(nèi)容，是項目的靈魂。項目管理的首要任務(wù)是制定一個構(gòu)思良好的項目計劃，以確定項目的范圍、進度和費用。對已經(jīng)定義的需求需要與用戶進行確認，保證雙方理解的一致。(3分)(3)在范圍控制中，張工無法進行有效的范圍控制，最終造成了重大的需求變更。(2分)(4)張工對需求的不能進行缺乏有效控制，最終造成項目延期50%.(2分)【問題2】(9分)該項目實施過程中的主要問題包括：(1)在范圍定義中，張工沒有對李工定義的需求進行評審，造成需求中的質(zhì)量缺陷沒有被及時發(fā)現(xiàn)。(2分)(2)張工沒有對李工開發(fā)的系統(tǒng)需求進行評審和復(fù)查，從而使得需求的缺陷沒有被及時發(fā)現(xiàn)。在完成第二題后，第三題就水到渠成了，第三題的要點見參考答案，此處不再贅述。但由于缺少需求評審和確認的過程，造成需求中的缺陷沒有被及時發(fā)現(xiàn)，系統(tǒng)需求沒有與客戶確認，造成缺少需求控制的基準，最終導(dǎo)致需求的重大變更。首先看第一個問題，對張工的行為進行點評。然而最終的結(jié)果是，項目延期嚴重，業(yè)務(wù)代表反而更不滿意，張工也要承擔項目延期造成的成本增加的責任。這些方法雖然沒有直接確認需求分析報告，但至少可以讓現(xiàn)有需求在項目組和客戶之間達成一致，提供范圍控制的基準，一樣可以達到范圍確認的目的。讓客戶在需求上簽字很困難，但并不等于就不需要進行范圍確認，而且范圍確認的方法也不僅僅只有需求簽字這一種方法。有人可能會說，很難說服客戶在需求上簽字，很難讓客戶為需求的缺陷負責。從軟件誕生至今的幾十年中，人們探索出了很多獲取系統(tǒng)需求的方法，但是熟悉軟件開發(fā)的人都知道，無論哪種方法都不可能定義出完美無誤的需求，需求中的缺陷必然存在，無法完全避免。在案例中，由于張工沒有進行范圍確認，最后的范圍控制也就變成了無本之木，控制過程肯定變成了討價還價，失去本身的意義。范圍確認則是基線化已定義的范圍，是范圍控制的依據(jù)。在范圍管理中，范圍定義、范圍確認和范圍控制又是最核心的三項活動，缺一不可。如果非要區(qū)分50％和30％的區(qū)別，也不過是五十步笑百步而已。誰是這個項目組的罪人呢？李工？還是張工？換一個思路考慮一下，如果李工沒有離開項目組，結(jié)果又會是什么樣呢？客戶會因為李工還在項目組就認可這個系統(tǒng)嗎？很顯然，不會。這時，烏云開始下雨，問題爆發(fā)了。開發(fā)出的需求都已經(jīng)過設(shè)計，一些編碼工作也已經(jīng)開始，李工的工作已近圓滿完成，畢竟，一些細枝末節(jié)的問題還可以同客戶直接溝通。晴朗的天空飄來一塊烏云，李工要移民加拿大。這是一個陽光燦爛的開端，如果一切順利的話，項目的成功也就是早晚的事情。從這一點上來說，張工是成功的，找到了合適的資源進行需求的開發(fā)與定義。因此張工專門找到了原系統(tǒng)的需求調(diào)研人員李工來解決新系統(tǒng)的需求問題。?在案例中，張工接手了一個系統(tǒng)升級的軟件項目。開發(fā)與定義軟件系統(tǒng)的需求在整個軟件開發(fā)過程中是最重要的一環(huán)，這是每個從事信息系統(tǒng)建設(shè)的項目經(jīng)理都清楚的事情，但往往又因為一時的疏忽而造成