【文章內(nèi)容簡介】 2020 年 5 月 1 甲啟動(dòng)至 2020 年 10 月 22日全部完工。 B 公司是一家民營高科技信息系統(tǒng)集成企業(yè)，有高級(jí)工程師 2人，軟件、硬件、網(wǎng)絡(luò)工程師共 36 人。B 公司安排高工李工負(fù)責(zé) A 系統(tǒng)的建設(shè)工作。 B 公司的績效考核制度是非常嚴(yán)格的，對(duì)項(xiàng)目負(fù)責(zé)人的考核，項(xiàng)目開工前要制訂項(xiàng)目實(shí)施計(jì)劃，項(xiàng)目完工后要對(duì)項(xiàng)目計(jì)劃的執(zhí)行情況進(jìn)行考核，項(xiàng)目的進(jìn)度、質(zhì) 量、成本三大目標(biāo)都要求控制在計(jì)劃的范圍內(nèi)。 李工于項(xiàng)目正式啟動(dòng)之前兩周開始進(jìn)行項(xiàng)目建設(shè)的準(zhǔn)備工作，對(duì)工程項(xiàng)目進(jìn)行了工作分解，在工作分解的基礎(chǔ)上，編制了項(xiàng)目資源計(jì)劃、人員計(jì)劃、項(xiàng)目質(zhì)量保障計(jì)劃、進(jìn)度計(jì)劃、項(xiàng)目成本預(yù)算和成本控制計(jì)劃等。李工編制完項(xiàng)目資源計(jì)劃后，報(bào)告公??? 11 司審批，包括項(xiàng)目小組組建的計(jì)劃在內(nèi)的項(xiàng)目資源計(jì)劃順利地通過了公司審批。于 2020 年 5 月 1 日項(xiàng)目正式啟動(dòng)時(shí)，項(xiàng)目小組也組建完成。李工所組建的項(xiàng)目小組為 12 人，包括軟件設(shè)計(jì)、編碼工程師 8 人，軟件測試工程師 4 人。 由于軟件項(xiàng)目開發(fā)的主要成本為人力資源成 本，為此，李工制定了詳細(xì)的人力資源成本控制計(jì)劃，人力資源計(jì)劃成本 =12 人 25 周平均人周成本 (1500 元 ) =450 000 元。為了將軟件開發(fā)人力資源費(fèi)用控制在45 萬元內(nèi)，李工制定了詳細(xì)的工程成本管理計(jì)劃。 李工所進(jìn)行的項(xiàng)目工作分解，得到共 24 個(gè)系統(tǒng)功能模塊，分別編號(hào)為 M0 M0??、 M24，并分別為每個(gè)功能模塊制定了工期和成本預(yù)算。如表 48 所示。 在項(xiàng)目開發(fā)的過程中，李工隨時(shí)跟蹤統(tǒng)計(jì)項(xiàng)目的開支情況。李工要求每位軟件工程師每周報(bào)告一次工作進(jìn)度，如某某模塊完成工作量 30％，李工據(jù)此來估算項(xiàng)目的進(jìn)度和 成本績效。如表 49所示。李工根據(jù)表 49 的統(tǒng)計(jì)數(shù)據(jù)計(jì)算累積完工的工程價(jià)值，計(jì)算公式為： ii24 1 完成率模塊單價(jià)累積完工工程價(jià)值＝ ?? ?i。 【問題 1】 (6 分 ) 請(qǐng)以 200 字左右回答，李工的成本預(yù)算存在哪些問題？李工所采取的成本跟蹤管理的方法是什么方法？應(yīng)用軟件系統(tǒng)開發(fā)項(xiàng)目中，使用此方法應(yīng)注意什么特點(diǎn)？ 【問題 2】 (10 分 ) 請(qǐng)以 200 字左右回答，衡量軟件開發(fā)實(shí)際累積人力資源成本的計(jì)算公式是什么？怎樣改進(jìn)上述方法才能控制好人力資源成本？怎樣得到軟件企業(yè)實(shí)際消耗的人力資源成本？ 【問題 3】 (9 分 ) 請(qǐng)以 300 字內(nèi)回答，李工采用此方法的具體措施是否存在不足之處？如存在，請(qǐng)指出不足并說明理由，請(qǐng)給出你的改進(jìn)意見。 案例分析 【問題 1】 掙值管理方法是應(yīng)用非常廣泛的項(xiàng)目成本管理方法。但是， IT 應(yīng)用系統(tǒng)開發(fā)工程項(xiàng)目有其特殊的特點(diǎn)，掙值管理方法的應(yīng)用必須結(jié)合 IT 工程項(xiàng)目的特點(diǎn)進(jìn)行，才能夠收到理想的效果。另外， IT 應(yīng)用系統(tǒng)工程項(xiàng)目的成本預(yù)算也是比較困難的課題，我們往往很難像其他工程項(xiàng)目 (如建筑工程項(xiàng)目 )那樣，將 IT 應(yīng)用系統(tǒng)工程項(xiàng)目的成本預(yù)算做得準(zhǔn)確。 在過去的應(yīng)用軟件工程項(xiàng)目中，很少采用掙值管理來控制項(xiàng)目進(jìn)度款支付。但隨 著 IT 項(xiàng)目管理水平的提高，隨著我國 IT 工程監(jiān)理制度的推廣，將來采用掙值管理控制工程進(jìn)度款支付也是可期待的。項(xiàng)目經(jīng)理應(yīng)當(dāng)熟練掌握掙值管理方法。 軟件項(xiàng)目的合同價(jià)格不等于軟件項(xiàng)目開發(fā)的實(shí)際成本，合同價(jià)格除了承建單位的軟件開發(fā)成本外，還包括銷售成本、行政費(fèi)用、稅金、利潤等，但我們?cè)谶@里探討的主要是項(xiàng)目開發(fā)成本，即工程成本。 在李工的成本估算中，缺少了對(duì)工程量的估算，因此，對(duì)人力資源成本的估算也就缺少了依據(jù)。對(duì)工作量的估算，如 M0l 模塊需要 16“人周”， M02 模塊需要 6“人周”，或以“人月”、“人年”為單位來估算工 作量，各模塊的工作量合起來，就可得到整個(gè)項(xiàng)目的工作量。當(dāng)然，如果要把預(yù)算做得更準(zhǔn)確，還需要估算各模塊的代碼量，以歷史經(jīng)驗(yàn)得到每個(gè)成員的工作效率來計(jì)算各模塊所需的工作量，但這種做法目前 ??? 12 在我國還沒有多少成功的案例，很多 IT 公司均是靠經(jīng)驗(yàn)來進(jìn)行估算的。 【問題 2】 對(duì)于大多數(shù)應(yīng)用軟件開發(fā)項(xiàng)目來說，工程成本的主要構(gòu)成要素是人力資源使用成本。而為了合理有效地控制人力資源使用成本，在組建項(xiàng)目小組的時(shí)候，可以根據(jù)工程項(xiàng)目的進(jìn)度情況，分階段投入人力資源，要做好與其他工程項(xiàng)目協(xié)調(diào)使用人力資源。我們也可用人力資源成本來計(jì)算掙值 ，人力資源使用成本的實(shí)際值可向財(cái)務(wù)查詢所支付的成本，掙值可以這樣計(jì)算： 累積人力資源成本 (掙值 )=??241i模塊工作量 i完成率 i平均人力周成本 這種計(jì)算是在承建單位內(nèi)部的成本控制。 本題的主要考點(diǎn)在于怎樣在軟件開發(fā)項(xiàng)目中合理、有效地進(jìn)行掙值管理。要合理使用掙值管理方法，必須同時(shí)考慮到軟件工程項(xiàng)目的特點(diǎn)。軟件工程項(xiàng)目與建筑工程項(xiàng)目有很大的區(qū)別。軟件工程項(xiàng)目更加類似于科研項(xiàng)目。如表 410 所示。 在建筑工程項(xiàng)目中，工程進(jìn)度與成本之間的線性比例關(guān)系較好，而且進(jìn)度容易測量。因此，掙值管理方法也使用得比較好。 但在軟件工程項(xiàng)目中，要合理、合適地采用掙值分析方法是比較困難的。軟件工程項(xiàng)目的成本控制的困難有以下原因。 (1)需求的不確定性：軟件項(xiàng)目的范圍、需求難以準(zhǔn)確地定義，導(dǎo)致項(xiàng)目開發(fā)過程中存在大量的變更，從而影響進(jìn)度和成本。 (2)規(guī)模和工作量的不確定性：軟件項(xiàng)目的工作量預(yù)算難以估計(jì)準(zhǔn)確。 (3)質(zhì)量鑒定的不確定性：開發(fā)完成并投入運(yùn)行的軟件模塊的質(zhì)量難以鑒定，特別如某個(gè)模塊完成了 30％或 80％的工作量，我們無法去鑒定，或用于鑒定的成本可能很高而使開發(fā)單位難以接受或不愿意去做這樣 的鑒定。 (4)把握需求的不確定性：已經(jīng)編寫完成的軟件代碼，可能隱藏著對(duì)需求理解的嚴(yán)重偏差，可能是廢品，得全部返工。 (5)難易程度的不確定性：已經(jīng)編寫完成的軟件代碼可能是很簡單的，未完成的可能很難，或反之。 (6)人員的不確定性：如果編寫軟件代碼的人員不穩(wěn)定，熟練員工中途流失將給項(xiàng)目進(jìn)度、質(zhì)量管理帶來嚴(yán)重影響。新人中途接手未全面完成的、風(fēng)格不良的軟件代碼，是一件很困難的工作。員工的敬業(yè)精神也難以衡量。 由于以上這些因素的影響，使得在軟件工程項(xiàng)目中對(duì)工程進(jìn)度和工程質(zhì)量的測量變得很困難，因而，我們就不可能像在 建筑項(xiàng)目中那樣使用掙值管理方法了。 【問題 3】 在軟件項(xiàng)目的開發(fā)管理中采用掙值分析時(shí)，可以考察各模塊的完成狀態(tài)，全部完成并且集成測試成功，能夠投入初步運(yùn)行，這樣，可以算本模塊的工作量完成，可以獲得本模塊的全部掙值，否則，本模塊的掙值計(jì) 0?？紤]到工程整體的集成還需要一定成本，因此，在計(jì)算各模塊掙值時(shí)，還應(yīng)當(dāng)扣除一定比例的掙值，作為工程整體集成的工作量的掙值。 但我們?cè)趯?shí)際工作中，也有很多時(shí)候采用估算某模塊完成百分之幾的做法，但這種做法是粗放式的，項(xiàng)目管理人員可以將這信息作為對(duì)項(xiàng)目成本累積的參考，作為粗略估計(jì)項(xiàng) 目進(jìn)度的參考，但不是成本核算的依據(jù)，也不能作為申請(qǐng)工程進(jìn)度款支付的依據(jù)，需知這種信息的可信度和可控性均較差。 參考答案 ??? 13 【問題 1】 (6 分 ) 應(yīng)當(dāng)先估算各模塊的工程量，再以工程量來估算所需要的人力資源，如總工程量“人周”或“人月”或“人年”等。李工的項(xiàng)目小組的建設(shè)應(yīng)分階段進(jìn)行人力資源投入，如設(shè)計(jì)階段所用人力應(yīng)較少，而詳細(xì)設(shè)計(jì)完成后，編碼階段進(jìn)入，則人力投入是高峰期。 人力資源成本的預(yù)算也應(yīng)當(dāng)核算一定比例的浮動(dòng)成本。李工所采用的是掙值管理方法。此方法應(yīng)用到軟件工程項(xiàng)目中，應(yīng)注意軟件開發(fā)掙值與投入的非 線性比例關(guān)系特點(diǎn)。 【問題 2】 (10 分 ) 軟件開發(fā)人力資源成本掙值統(tǒng)計(jì)是能夠做到比較準(zhǔn)確的，衡量軟件開發(fā)人力資源成本的計(jì)算公式： 累積人力資源成本 =??241i模塊工作量 i完成率 i平均人力周成本 李工所采取的方法應(yīng)增加各模塊工程量的估算，就能夠進(jìn)行人力資源成本控制。如表 411 所示。 實(shí)際消耗的人力資源成本可通過財(cái)務(wù)發(fā)放的工資統(tǒng)計(jì)得到。 【問題 3】 (9 分 ) 李工根據(jù)各工程師的進(jìn)度報(bào)告 (進(jìn)度百分比 )來計(jì)算掙值，在軟件開發(fā)中是不可行的。 在軟件開發(fā)中，各模塊的進(jìn)度百 分比通常很難測量準(zhǔn)確，而各工程師的匯報(bào)往往是很粗略的估計(jì)，這種估計(jì)只能提供給項(xiàng)目經(jīng)理控制進(jìn)度時(shí)做參考，但不能作為成本核算或申請(qǐng)工程進(jìn)度款支付的依據(jù)。建議李工以各模塊全面完工來進(jìn)行計(jì)算，即各模塊要么計(jì)算 0％，要么計(jì)算 100%完工，但在進(jìn)行工作分解的時(shí)候，分解的深度和各模塊的粒度要合適，便于進(jìn)行控制。 另外，在核算的時(shí)候，要扣除一定的比例，如 20%～ 30%作為各模塊集成所需要的工程量，待工程全面完工后進(jìn)行核算。 項(xiàng)目 質(zhì)量案例 質(zhì)量是“使實(shí)體具備滿足明確或隱含需求能力的各項(xiàng)特征之總和”，明確或隱含的需求是 指按項(xiàng)目需求制定的基礎(chǔ)性文件。在信息系統(tǒng)項(xiàng)目中，一般把《系統(tǒng)需求規(guī)格說明書》作為項(xiàng)目需求的基礎(chǔ)性文件。 質(zhì)量管理作為項(xiàng)目管理的一部分，具有非常重要的地位。質(zhì)量管理的目的是通過執(zhí)行項(xiàng)目質(zhì)量管理過程，使用一些基本項(xiàng)目管理工具和技術(shù)來保證信息系統(tǒng)的質(zhì)量。時(shí)間、成本、質(zhì)量是項(xiàng)目管理的三大目標(biāo)，如果質(zhì)量不能滿足要求，即使進(jìn)度再快，成本再節(jié)省，項(xiàng)目也沒有意義。 閱讀以下關(guān)于信息系統(tǒng)項(xiàng)目管理過程中項(xiàng)目質(zhì)量管理方面問題的敘述，回答問題 1 至問題 3。 案例場景 金博聯(lián)信息技術(shù)有限公司 (CIU)曾經(jīng)為 K 公司開發(fā)過一套信息系統(tǒng)，該 系統(tǒng)涉及了 K 公司的所有主要業(yè)務(wù)。該系統(tǒng)中關(guān)于組織機(jī)構(gòu)的業(yè)務(wù)規(guī)則如下： (1)組織機(jī)構(gòu)樹通過部門編碼體現(xiàn)層級(jí)和隸屬關(guān)系。即部門 0001 的下屬部門包括 0001000 00010002,依次類推，根據(jù)代碼中包含的層級(jí)關(guān)系確定某 個(gè)部門在組織機(jī)構(gòu)樹中的確切位置，該編碼由公司統(tǒng)一制定。 (2)任意一條業(yè)務(wù)數(shù)據(jù)隸屬于某個(gè)特定的部門。 (3)部門之間存在友好和互斥的關(guān)系。關(guān)系為友好的部門可以共享業(yè)務(wù)數(shù)據(jù)，關(guān)系為互斥的部門互相不能訪問對(duì)方的業(yè)務(wù)數(shù)據(jù)。 后來， K 公司需要調(diào)整部門的組織結(jié)構(gòu)，因此對(duì)系統(tǒng)提出了升級(jí)的要求： (1)系統(tǒng)中的部門編碼需要更新為最新的企業(yè)標(biāo)準(zhǔn)。 ??? 14 (2)組織機(jī)構(gòu)根據(jù)最新的企業(yè)標(biāo)準(zhǔn)重新生成。 (3)組織結(jié)構(gòu)調(diào)整是不能丟失業(yè)務(wù)數(shù)據(jù)。、 (4)系統(tǒng)中可以保留組織機(jī)構(gòu)調(diào)整的痕跡，業(yè)務(wù)數(shù)據(jù)可以追蹤除原屬于哪個(gè)部門，機(jī)構(gòu)調(diào)整后屬于哪個(gè)部門。 (5)部門間友好和互斥的關(guān)系可能會(huì)被重新定義。 (6)升級(jí)后的系統(tǒng)需要能夠適應(yīng)再次的組織機(jī)構(gòu)調(diào)整而不需要再次升級(jí)。 項(xiàng)目經(jīng)理張工接受了這個(gè)項(xiàng)目，經(jīng)過細(xì)致的調(diào)研和分析，發(fā)現(xiàn)原系統(tǒng)存在如下缺陷： (1)原系統(tǒng)中將企業(yè)對(duì)部門的標(biāo)準(zhǔn)編碼設(shè)計(jì)為部門主鍵，修改起來難度很大，容易發(fā)生數(shù)據(jù)不 一致的問題。 (2)新的企業(yè)標(biāo)準(zhǔn)沒有考慮到原有企業(yè)標(biāo)準(zhǔn)，同是一個(gè)部門張工在原標(biāo)準(zhǔn)中為 00010001，在新標(biāo)準(zhǔn)中為00010005,部門的層次也可能發(fā)生變化。 (3)業(yè)務(wù)數(shù)據(jù)中保存了隸屬部門編碼，系統(tǒng)已經(jīng)使用近兩年，保存了大量的歷史業(yè)務(wù)數(shù)據(jù)。 (4)原系統(tǒng)在設(shè)計(jì)時(shí)將部門間的友好與互斥關(guān)系硬編碼在系統(tǒng)代碼中，且涉及面很廣，原系統(tǒng)中 80％以上的程序存在這樣的硬編碼。 (5)不少業(yè)務(wù)邏輯和工作流程是根據(jù)特定的部門編碼進(jìn)行判斷的，部門編碼的變化會(huì)造成業(yè)務(wù)混亂。 (6)原系統(tǒng)在設(shè)計(jì)時(shí)沒有考慮到組織機(jī)構(gòu)調(diào)整的可能，也沒 有對(duì)保留部門變革歷史的功能進(jìn)行設(shè)計(jì)。 張工認(rèn)為，需求已經(jīng)非常明確，對(duì)于這個(gè)項(xiàng)目的關(guān)鍵是設(shè)計(jì)的質(zhì)量，其中包括解決方案的設(shè)計(jì)和業(yè)務(wù)系統(tǒng)的改造兩部分。一旦設(shè)計(jì)出現(xiàn)偏差，返工的工作量會(huì)非常巨大，反之，整個(gè)項(xiàng)目還是容易控制的。但張工在如何提高設(shè)計(jì)質(zhì)量方面卻犯了愁。 【問題 1】 (8 分 ) 試以 300 字內(nèi)回答，張工可以采取哪些措施提高設(shè)計(jì)的質(zhì)量？ 【問題 2】 (9 分 ) 試以 300 字內(nèi)回答，除設(shè)計(jì)外，張工還需要特別注意哪些工程活動(dòng)。 【問題 3】 (8 分 ) 試以 300 字內(nèi)回答，如何提高這些工程活動(dòng)的質(zhì)量。 案例分析 這是一個(gè)開放 式的案例分析題，案例中僅粗略地描述了項(xiàng)目背景的目標(biāo)，針對(duì)如何提高項(xiàng)目質(zhì)量進(jìn)行發(fā)問，難度相對(duì)較大，需要仔細(xì)的分析。 前面一部分對(duì)項(xiàng)目背景和目標(biāo)的描述無非是為了說明這么幾個(gè)問題： (1)這是一個(gè)系統(tǒng)改造的項(xiàng)目。 (2)原系統(tǒng)中存在設(shè)計(jì)缺陷，沒有考慮過組織機(jī)構(gòu)改革的可能性。 (3)需要大量更改原系統(tǒng)的程序，消除硬編碼。 (4)需要更改已有的業(yè)務(wù)數(shù)據(jù)，同時(shí)增加部門變革歷史的功能。 基于這些問題，案例的后半部分給出了張工的觀點(diǎn)：設(shè)計(jì)質(zhì)量是項(xiàng)目的關(guān)鍵，需要提高設(shè)計(jì)的質(zhì)量。結(jié)合案例后的問題，我們不難發(fā)現(xiàn)，案例的前半部分是 引子，后半部分才是關(guān)鍵，也是該案例的題眼：如何提高項(xiàng)目的質(zhì)量，顯然需要用項(xiàng)目質(zhì)量管理的知識(shí)作答。 質(zhì)量管理是項(xiàng)目管理中的一個(gè)知識(shí)域，但在 PMBOK 中并沒有給出具體的質(zhì)量管理的方法，需要結(jié)合軟件開發(fā)和項(xiàng)目的特點(diǎn)給出特定的質(zhì)量管理策略和方法。這也正是這個(gè)案例的用意所在，考察考生在面對(duì)實(shí)際的項(xiàng)目問題時(shí)需要采取哪些措施解決項(xiàng)目的質(zhì)量問題。 我們首先從軟件工程的角度考慮一下軟件質(zhì)量的問題。軟件的質(zhì)量一直是軟件界近幾十年致力解決的問題，針對(duì)使用軟件提高軟件質(zhì)量提出了很多的方法和理論。首先是軟件工程的理論，需要使用工程活 動(dòng)的方法進(jìn)行軟件開發(fā)，從系統(tǒng)定義與分析開始，經(jīng)過設(shè)計(jì)、實(shí)現(xiàn)，最終到驗(yàn)證。在軟件工程中，人們提出了多種軟件開發(fā)模式和工程活動(dòng)方法。