1、第五章信息系統建設的項目管理一、信息系統與項目管理二、信息系統項目的計劃、費用與進度管理三、信息系統項目的人員管理四、信息系統建設的質量管理1本節內容:一、信息系統與項目管理1、項目的定義與特點2、項目管理的定義與特點3、信息系統項目的特點2 通俗地講，項目就是在一定的資源約束下完成既定目標的一次性任務。這個定義包含三層意思：一定資源約束、一定目標、一次性任務。這里的資源包括時間資源、經費資源、人力資源、物質資源，比如工具、設備等 項目具有目的性。 項目具有壽命周期。項目具有一定的獨特性。每個項目都有客戶。 項目組織具有臨時性和開放性。項目具有較強的沖突性。 項目包含一定的不確定性。 1、項目

2、的定義與特點32、項目管理的定義與特點項目管理是通過項目經理和項目組織的努力，運用系統理論和方法對項目及其資源進行計劃、組織、協調、控制，旨在實現項目的特定目標的管理方法體系。如果將時間從資源中單列出來，稱做進度，而將其他資源都看作可以通過采購獲得從而表現為費用或成本的話，那么我們就可以給項目下這么一個定義：在一定的進度和成本約束下，為實現既定的任務，并達到一定的質量，所進行的一次性的任務。 4一般來講，目標、成本、進度三者是互相制約的，其關系如圖5-2所示。當進度要求不變時，質量要求越高或者任務要求越多，則成本越高；當不考慮成本時，質量要求越高或任務要求越多，一般進度越慢；當質量和任務的要求

3、都不變時，進度過快或過慢都會導致成本的增加。項目管理的目的是謀求（任務）多、（進度）快、（質量）好、（成本）省的有機統一。費用高速度快目標任務多質量好圖5-2 項目管理三要素之間的關系5當然，對于一個確定的項目，其任務的范圍是確定的。項目管理就演變為在一定的任務范圍下如何處理好質量、進度與成本三者關系的問題，也就是要處理好好中求快和好中求省的問題。項目管理既是一門科學又是一門藝術。之所以被看作一門科學是因為項目管理是以各種圖表、數學計算以及其他技術手段為依據的；但是項目管理也受到人際關系因素以及組織因素的制約，因而相互溝通、協商談判及解決矛盾等即為項目管理的“藝術”。 這門“藝術”具有其自身的

4、三個基本特點： 項目管理是一項復雜工作。 項目管理具有創造性，充滿著權衡。 項目負責人（或稱項目經理）在項目管理中起著非常重要的作用。 63、信息系統項目的特點信息系統的建設是一類項目。因為信息系統的建設符合項目的幾個特點：首先信息系統的建設是一次性的任務，有一定的任務范圍和質量要求，有時間或進度的要求，有經費或資源的限制。信息系統具有生命周期，這與項目具有壽命周期也是一致的。所以信息系統的建設也是一類項目的建設過程，可以用項目管理的思想和方法來指導信息系統的建設。信息系統的生命周期包括系統規劃、系統分析、系統設計、系統實施、系統運行和維護五個階段。顯然，信息系統項目也可按照上述五個階段進行管

5、理，依次制定各階段的任務范圍、進度、費用安排以及質量要求。從具體構成來看，信息系統項目又可分為客戶需求分析、應用軟件開發、網絡規劃與設計、設備采購以及系統調試與集成等多項內容，在上述幾項內容中，首先是客戶需求分析，在此基礎上進行應用軟件開發和網絡規劃設計，最后才是設備采購和系統調試與集成。7 在隨信息系統項目進行基本分析之后，我們來看看信息系統項目的特點 ：（1）信息系統項目的目標是不精確的，任務的邊界是模糊的，質量要求更多是由項目團隊來定義的。 （2）信息系統項目進行過程中，客戶的需求會不斷被激發，被不斷地進一步明確，導致項目的進度、費用等計劃不斷更改。 （3）信息系統項目是智力密集、勞動密

6、集型的項目，受人力資源影響最大，項目成員的結構、責任心、能力和穩定性對信息系統項目的質量以及是否成功有決定性的影響。8信息系統項目的計劃是用來指導組織、實施、協調和控制信息系統建設的文件，制定一個良好的計劃有諸多好處，比如可以將計劃的假設與前提寫成書面文件，以備發生變更時考察；有助于項目成員之間的交流溝通，有助于大家統一認識；可以確定對項目進行控制和考核工作業績的基準。本節內容：1、信息系統項目成本的構成及預算的一般過程2、軟件開發規模與成本估算方法3、信息系統項目的進度和成本計劃4、信息系統項目計劃的變更管理二、信息系統項目的計劃、費用與進度管理91、信息系統項目成本的構成及預算的一般過程

7、信息系統項目的成本隨著系統的類型、范圍及功能要求的不同而異。但是，我們可以從信息系統生命周期的各階段劃分為開發成本與運行維護成本兩大類，在各類中又根據費用的目的進行逐級細分，如圖5-3所示。10其中，系統開發成本又可分為軟件開發成本、硬件成本和其他成本三大類。信息系統項目的成本測算，就是根據待開發的信息系統的成本特征以及當前能夠獲得的有關數據和情況，運用定量和定性分析方法對信息系統生命周期各階段的成本水平和變動趨勢做出盡可能科學的估計。在圖5-3中，最難確定的是開發成本中的軟件開發成本，而硬件成本和其他成本相對容易估算出來。至于運行維護成本，則可以根據開發成本與運行維護成本比值的經驗數據和測算

8、出來的開發成本一起計算。并且，對于信息系統項目的用戶來講，項目開發成本的不確定性因素較大，而項目的運行維護成本由于多次發生，且在自身的使用中發生，相對來講容易控制一些。所以信息系統項目成本測算的重點是軟件開發成本。 11圖5-4給出了信息系統開發成本測算的一般過程 12從圖中可以看出，信息系統開發成本測算首先應該建立在對過去項目成本情況進行數據分析的基礎上，歷史的經驗和教訓對于成本測算的各個階段均有參考價值；其次，進行硬件成本及用戶方面（培訓、數據收集、系統轉換等）成本的測算，這是因為它們對軟件成本的分析有著一定的影響。比如開發人員對所采用的硬件或數據庫系統的使用經驗將明顯影響軟件生產率，從而

9、影響著軟件成本，對此先做測算可以減少軟件成本測算中的不確定因數。然后是軟件成本測算，通常分兩步走：第一步，測算軟件的規模或程序量；第二步，利用有關的經驗參數模型測算出該種規模的軟件成本。當然，也可運用專家判定等方法將上述兩步合并直接測算成本。在測算軟件開發成本、硬件成本和其他成本的同時，對各種任務所需 的人力、時間等資源也做出安排，即為人力計劃和進度計劃。13軟件開發成本測算出來以后，與硬件成本和其他成本累加則構成信息系統項目的開發成本，在此基礎上，根據運行維護成本與開發成本之間比值的經驗系數導出信息系統的運行維護成本。開發成本與運行維護成本之和即為信息系統項目的總成本。顯然，信息系統項目成本

10、的測算重點在于軟件開發成本的測算，軟件開發成本的測算又離不開軟件規模的測算。所以，我們應對軟件的規模與成本估算的方法予以討論。142、軟件開發規模與成本估算的方法軟件度量的兩種典型方式 軟件代碼行的方式 用軟件的代碼行（LOC）數表示軟件開發的規模是十分自然和直觀的。代碼行數可以用人工或軟件工具直接測量。利用代碼行數不僅能度量軟件的規模，而且還可以度量軟件開發的生產率、開發每行代碼的平均成本、文檔與代碼的比例關系、每千行代碼存在的軟件錯誤個數等。 15軟件開發的生產率： Pl = L / E(5.1)其中：L是應用軟件的總代碼行數。E是應用軟件的工作量，用人月（PM）度量。Pl是軟件開發的生產

11、率，用每人月完成的代碼行數（LOC/PM）度量。每行代碼的平均成本： Cl = S / L（5.2）其中：S是軟件開發的總成本，用人民幣或美元度量。Cl是軟件項目每行代碼的平均成本，用人民幣（或美元）/代碼行度量。 用軟件代碼行數估算軟件的開發規模簡單易行，其缺點也有不少：代碼行數的估算依賴于程序設計語言的功能和表達能力；采用代碼行估算方法會對設計精巧的軟件項目產生不利的影響；在軟件項目開發前或開發初期估算它的代碼行數十分困難；代碼行估算只適用于過程式程序設計語言，對非過程式的程序設計語言不太適用等。16 軟件功能點的方式面向功能的軟件功能點度量與統計代碼行數的直接度量方式不同，是涉及多種因素

12、的間接度量方式。它是根據軟件擬實現的基本功能定義的，因此在系統分析初期就能夠估算出軟件開發的規模。這種方法用6個信息量的“加權和”CT和14個因素的“復雜性調節值”Fi（i=1，2，14）計算功能點FP：17其中：CT按表5-1計算 18 Fi由表5-2給出，Fi取值為0，1，5，表示Fi在FP中起作用的程度。當Fi =0時，表示否定或Fi不起作用，Fi =5時，表示Fi作用最大。19與用代碼行定義軟件的開發效率、成本等度量一樣，用功能點也可以定義相應的概念。 軟件開發的生產率：Pf = FP / E （5.4）其中：Pf表示每人月完成的功能點數。每功能點的平均開發成本：Cf = S / FP

13、 （5.5）其中：Cf表示每功能點的平均開發成本（人民幣或美元）。采用功能點度量的優點：第一，與程序設計語言無關，它不僅適用于過程式語言，也適用于非過程式的語言，這對于面向對象的開發方式尤為有用；第二，由于在信息系統項目啟動時就能基本上確定系統的輸入、輸出等參數，所以功能點度量能用于軟件開發成本在初期的預估。缺點主要是它涉及到的主觀因素比較多，如Fi的選取與評估人的經驗和態度有較大的關系，并且FP的值沒有直接的物理意義。20軟件開發的規模是影響軟件開發成本和工作量的重要因素。應用軟件代碼行和功能點估算是成本和工作量估算的基礎。采用前述四種估算方法可以估算出L或FP的樂觀值a、悲觀值b和一般值m

14、，然后根據下面加權公式計算出期望值e = (a + 4m + b) / 6（5.6）當L或FP的期望值估算出來之后，根據以前開發軟件的數據可知軟件開發平均生產率（LOC / PM或 FP / PM）就可以計算出工作量。例：軟件項目的規模按功能點估算為310FP，假設已知以前完成項目的軟件開發平均生產率為5.5FP / PM，已知目前每人月的開發成本為1萬元，于是：工作量估算為 E = 310/5.5 = 56PM（5.7）軟件開發成本估算為 C = 56 1 = 56 萬元（5.8） 如果當前估算的軟件子項目比以前完成的項目復雜，那么所用的生產率值可以低于平均生產率，反之也可以高于平均生產率。

15、21軟件的兩個經驗估算模型應用軟件的估算模型是根據以前完成項目的實際數據導出的，由于導出模型的數據是“從前的”、“局部的”，因此估算模型不可能適用于當前所有的信息系統項目和全部開發環境。這些模型的計算結果僅有一定的參考價值。有的信息系統項目采用專家評分法分別對軟件開發規模、成本、時間和人力投入給出樂觀、悲觀、一般三個值，然后采用類似（5.6）的加權公式直接計算出軟件開發的規模、成本、時間和人力投入 。22常用的估算模型：CoCoMo模型和Putnam模型 CoCoMo模型 CoCoMo模型是“構造性成本模型”（constructive cost model，簡稱，CoCoMo模型）的英文縮寫，

16、分為基本、中間、詳細三個層次，分別用于軟件開發的不同階段。基本CoCoMo模型用于系統開發的初期，估算整個系統的工作量（包括軟件維護）和軟件開發所需要的時間；中間CoCoMo模型用于估算各個子系統的工作量和開發時間；詳細CoCoMo模型用于估算獨立的軟部件，如子系統內部的各個模塊。這里，我們只介紹基本CoCoMo模型的情況。23基本CoCoMo模型是靜態、單變量模型，具有下列形式：E = aLb（5.9）D = cEd（5.10）C = E（5.11）其中：L是項目的代碼行估計值，單位是千行代碼（KLOC）。 E表示工作量，單位是人月（PM）。 D表示開發時間，單位是月。 C表示開發成本，單位

17、是萬元。 表示每人月的人力成本，單位是萬元/人月。 a，b，c，d是常數，取值如表5-3所示。表5-3把軟件劃分為組織型、半獨力型和嵌入型三類，允許不同應用領域和復雜程度的軟件按照上述三類軟件的適用范圍選取相應的參數a，b，c，d。24 Putnam模型Putnam模型是由Putnam提出的大型軟件項目工作量（一般在30人年以上）估算模型。它是一個動態多變量模型，適用于軟件開發的各個階段。估算模型以大型軟件項目的實測數據為基礎，描述了開發工作量、開發時間和軟件代碼行數之間的關系。相應的方程是（5.12）其中：L表示源程序代碼行數。 E表示工作量（以人年計，包括維護）。 td表示開發時間（以年計

18、）。 Ck表示技術狀態常數，它反映出“妨礙程序員進展的限制”，并因開發環境而異，其典型值的選取如表5-4所示。25由式（5.12）有：（5.13）C = E（5.14）其中，C表示開發成本，單位是萬元；表示每人年的人力成本，單位是萬元/人年。式（5.13）表明，開發軟件項目的工作量與交付時間的4次方成反比，將0.9td代替式（5.13）的td計算E。我們發現，提前10%的時間要增加52%的工作量，顯然是降低了軟件開發生產率。因此，軟件開發過程中人員與時間的折衷是一個十分重要的問題。26CoCoMo模型和Putnam模型都是在估算軟件代碼行的方式基礎上，估算出了軟件開發的工作量和軟件開發的成本。

19、對于軟件的開發時間，CoCoMo模型是根據經驗公式估算出來的，對于Putnam模型則是與工作量相權衡的結果。對于軟件的人力投入，兩個模型都可以根據工作量和開發時間的比值測算出來。 兩種方式相比較27軟件的自動估算工具以上介紹的經驗估算模型已經用軟件實現，成為自動估算工具。這種自動估算工具使得管理或計劃人員能夠估算待開發軟件項目的成本和工作量，還可以對人員配置和交付日期等進行估計。它們需要以下一種或多種數據：定量估算軟件項目模型，如用總代碼行數或者用功能點數據；定性地說明項目的特征，諸如復雜性、需要的可靠性或時間的關鍵性；開發人員和（或）開發環境的描述。根據這些數據，由自動估算工具實現的模型就能

20、給出完成軟件項目所需的工作量、成本、人員配備、某些情況下的開發進度和相應風險的估算。 28下面簡要介紹6種有代表性的工具：Gordon集團的BYL（Before You Leep）Wang研究所的WICOMO（Wang Institute Cost Model）DEC公司的DECPlan（基于COCOMO的自動估算工具）SLIM是基于軟件生存期中RayleighNorden曲線和Putnam估算模型的一種自動成本估算工具。ESTIMACS和SPQR/20是根據功能點估算模型開發出來的 29上述每種自動估算工具都能與管理或計劃人員對話，從而得到合用的項目與支持信息，并產生表格式的輸出及在某些情況

21、下產生圖形輸出。國外有學者曾對上述部分工具做過一個比較。他把各種工具都用于同一個項目，發現估算結果中出現了比較大的偏差，而且預測值有時與實際值相比，存在明顯的不同。顯然，不管估算是采用代碼行的方式，還是采用功能點的方式，不管是采用經驗模型還是采用自動估算工具，都離不開摻雜在其中的許多主觀判斷。這是由于軟件開發規模測算過程中不確定的因素太多，必須要采用定性與定量方式結合起來的方法才能測定。到此，我們就討論完了軟件規模、成本、開發時間、人力投入的測算過程。在此基礎上，就可以根據測算的軟件開發成本、硬件成本和信息系統開發期間的其他成本計算出信息系統可開發成本，再根據信息系統開發成本占信息系統總成本比

22、例的經驗數據得出信息系統項目的總成本。相應地，也可以根據軟件開發時間或人力投入占信息系統項目總時間或總人力比例的經驗數據知道信息系統項目建設所需要的總時間和總人力。303、信息系統項目的進度和成本計劃根據上一小節的測算，我們能估測出信息系統項目所需要的工作量、總的項目建設時間和項目成本。現在假設項目經理已經和客戶在上述測算的基礎上經過討價還價，基本達成了一致，并簽訂了開發合同。那么，項目經理就要開始組織隊伍形成項目團隊，繪制專業領域技術編制表，建立一個工作分析結構（WBS），并在此基礎上建立項目組成員的責任矩陣。所謂工作分析結構是指將一個信息系統項目分解成易于管理的幾部分或幾個細目，細目再展開

23、成子細目，任何分支最底層的細目叫工作包。比如對于一個待建系統可以先按照生命周期的各階段展開，然后按照子系統或系統功能點展開。31責任矩陣一旦建立，就可以進行項目各建設活動的工期估計和預算分攤估計。工期估計和預算分攤估計各有兩種辦法，一種是自上而下法，即在項目建設總時間和總成本之內按照每一工作包的相關工作范圍來考察，以項目總時間或總成本的一定比例分攤到各個工作包中。另一種方法是自下而上法，它是由每一工作包的具體負責人來做估計的方法。經驗表明，讓某項工作的具體負責人進行估計是較好的方法，因為這樣做既可以得到該負責人的承諾，對他產生有效的參與激勵，又可以減少由項目經理一個人進行所有活動的工期估計時所

24、產生的偏差。當然，某些情況下，如對一個需花費數年時間、由幾百個人來做不同工作才能完成的大型信息系統項目來說，讓每個人在項目開始時就做出其所要完成活動的各項估計是不實際的。至于工作包各負責人估計的方法，還可以參照上一節中的測算方法，比如中間CoCoMo模型就可用于各個子系統的估計，詳細CoCoMo模型可用于子系統各個模塊的估計。32 在上述估計的基礎上，項目經理進行各工期的累計和分攤預算的累計，與項目總建設時間和總成本比較，根據一定的規則進行調整。實例分析: 現在某企業準備開發一個客戶關系管理的信息系統，合同雙方將系統交付使用作為項目終結的依據，雙方同意維護期間費用另行支付。經上述測算，估算該項

25、目總開發工作量為4人年，項目總開發時間為50周，項目的總成本（包括軟件開發成本、硬件成本和開發中的其他成本）是100萬元人民幣。 根據上述估計和準備，項目經理繪制了如圖5-5所示的甘特圖，項目總開發時間為50周。圖中將該項目劃分為六個大的活動，并明確了各活動的工期：系統規劃（5周）、系統分析（10周）、系統設計（10周）、系統實現（15周）、系統測試（8周）和系統轉換（5周）。333435上述六個大的活動又細分為22項小活動，各項小活動之間的順序關系以及每項小活動的工期估計和預算分攤估計如表5-5所示。在此基礎上，可以畫出該項目的網絡圖，如圖5-6所示。到此為止，已經估計出該項目中每項活動的工

26、期和項目的總時間，為了確定這些活動是否能在要求的時間內完成。我們必須計算出一個項目進度計劃，為每項活動的執行提供一個時間表，這個時間表主要解決以下兩個內容：圖5-6 客戶關系信息系統項目網絡圖36(1)最早開始時間（earliest start time,ES）和最早結束時間（earliest finish time,EF）。它們是指在項目合同開始時間的基礎上，每項活動能夠開始和完成的最早時間。ES和EF是通過網絡圖的正向計算得到的，即從項目開始沿網絡圖到項目完成進行計算。在進行這些正向計算時，必須遵守一條規則：某項活動的最早開始時間（ES）必須相同或晚于直接指向這項活動的所有活動的最早結束時

27、間（EF）中的最晚時間。最早結束時間（EF）則可以在這項活動最早開始時間的基礎上加上這項活動的工期估計計算出來，即：EF=ES+工期估計。37（2）最遲開始時間（latest start time ,LS）和最遲結束時間（latest finish time ,LF）。它們是指為了在項目合同要求完工時間內完成項目，每項活動必須開始和完成的最遲時間。LF和LS可以通過網絡圖的反向推算得出，即從項目完成沿網絡圖到項目的開始進行推算。在進行這類反向計算時，必須遵守一條規則：某項活動的最遲結束時間（LF）必須相同或早于該活動直接指向的所有活動最遲開始時間（LS）的最早時間。最遲開始時間（LS）則可以在

28、這項活動最遲結束時間（LF）的基礎上減去這項活動的工期估計計算出來，即：LS=LF-工期估計。38在此基礎上，可以繪制出附有開始時間和結束時間的進度時間表，如表5-6所示。在網絡圖中也可標出每項活動的上述四個時間，參照圖5-6中每個活動描述框的四個角上的數據。39在這個客戶關系管理項目中，表5-6中最后一項活動“準備系統轉換報告”的最早結束時間和項目的要求完工時間之間有一個9天的差距，這個差距叫做總時差，有時也叫浮動量。總時差可以用每項活動的最遲結束（開始）時間減去它的最早結束（開始）時間算出，即總時差 = LF EF 或 總時差 = LS ES如果某項活動的總時差為正值，表明該項活動花費時間

29、總量可以適當延長，而不必擔心會出現在要求完工時間內活動無法完成的窘況。反之，如果總時差為負值，則表明該項活動要加速完成以減少花費的時間。在本例中，項目的總時差為負值（參見表5-6），表明完成這個項目缺少時間余量。要對項目的進度做到較好的控制，必須找到項目網絡圖中的關鍵路徑。一個大的網絡圖從開始到完成可以有很多條路徑。一些路徑可以有正的總時差，另一些可能有負的總時差。那些具有正的總時差的路徑被稱為非關鍵路徑，而那些總時差為零或負值的路徑被稱為關鍵路徑，并且將耗時最長的關鍵路徑經常稱為最關鍵路徑。在表5-6中用陰影標示出該項目的關鍵路徑。由于客戶關系信息系統整個項目的總時差為-9，也就是說，開發本

30、項目需要59周，而不僅僅是合同規定的50周。我們從表5-5中也看到項目各活動的預算分攤累計的最后結果是102萬元，而不是合同規定的100萬元。40這時，項目經理需要與各活動的負責人特別是關鍵路徑上的負責人進一步核實，看是否能夠壓縮相應工期和預算分攤，然后對進度和成本計劃進行相應調整，調整的原則和方法在下一小節中詳細講解。在本例中，假設各負責人均表示已經沒有壓縮的意義，那么，項目經理需向項目建設的委托方申請將項目建設總時間延長到59周。當然，也可以采取折衷的辦法，一邊申請延期，一邊調整進度計劃。至于費用，除非嚴重超過合同款項或者說合同中的預算被嚴重低估；否則，合同雙方很難再就合同款項進行談判。比

31、如本例中僅超過2萬元，占合同總價款的2%，就只能在項目團隊成本的內部控制上下功夫。上面提到的進度表、網絡圖以及預算分攤，不但可以在活動這一層次進行，對于每個活動的負責人來講，他也可以將自己負責的活動進行分解，在自己活動內部使用上述計劃的方法。另外，為了實現成本控制，除在表5-5中列出預算分攤和分攤累計進行控制外，還可以在預算分攤和活動進度表的基礎上，制定一個在50周范圍內每周的預算分攤表。實例總結414、信息系統項目計劃的變更管理項目執行過程中，也會經常出現到某一個項目的里程碑或報告期時，項目的進度早于或晚于計劃進度及已經發生的實際成本低于或高于計劃成本，這時都需要對相應的計劃進行調整。項目控

32、制或調整的過程如圖5-7所示。42如果發現項目的進度計劃或預算計劃需要調整，那么，調整的重點應放在如下三個方面：第一，對近期內即將發生的活動加強控制，積極挽回時間和成本，這是因為早控制早主動；第二，工期估計最長或預算估計最大的活動應進一步審核預估依據，并做好該活動壓縮時間和費用的準備工作，因為估計值越大的項目更有壓縮的可能；第三、將某些可以再分的活動進一步細分，研究細分活動之間并行工作或知識重用的可能性，如可行，則可以有效地壓縮時間和費用。43至于信息系統項目計劃調整的方法，下面詳細講解比較重要的一種，即時間成本平衡法。時間與成本之間在一定的范圍內有一定的替代性（參見圖5-2）。時間成本平衡法

33、就是一種用最低的相關成本的增加來縮短項目工期的方法。該方法基于以下假設：（）每項活動有兩組工期和成本估計：正常的和應急的。正常時間是指在正常條件下完成某項活動需要的估計時間；正常成本是指在正常時間內完成某項活動的預計成本。應急時間是指完成某項活動的最短估計時間；應急成本是指在應急時間內完成某項活動的預計成本。44在圖5-8中，四個活動均有一組正常時間和成本估計，一組應急時間和成本估計。活動A的正常估計時間為7周，正常預計成本為50，000元；應急時間是5周，在此期間內完成活動的應急成本為62，000元。45時間成本平衡法基于的假設條件（2）一項活動的工期可以通過從正常時間減至應急時間得到有效的

34、縮減，這要靠投入更多的資源來實現指派更多的人、延長工作時間、使用更多的設備等。成本的增加是與加快活動進程相聯系的。（3）應急時間是確保活動按質量完成的時間下限。無論對一項活動投入多少額外的資源，也不可能在比應急時間短的時間內完成這項活動。例如，無論投入多少資源，無論花費多少成本，也不能在少于5周的時間內完成活動A。（）當需要將活動的預計工期從正常時間縮短至應急時間時，必須有足夠的資源作保證。46時間成本平衡法基于的假設條件（）在活動的正常點和應急點之間，時間和成本的關系是線性的。為了將活動的工期從正常時間縮短至應急時間，每項活動都有自己的單位時間加急成本。縮短工期的單位時間加急成本可用如下公式

35、計算： （5.15） 47例如，在圖5-8中，將活動A的工期從正常時間縮短至應急時間，在縮短的這段時間內的每周成本為圖5-8的網絡圖從開始到完成有兩條路徑：路徑AB和路徑CD。如果我們僅考慮正常工期估計，路徑AD需要16周完成，而路徑CD需要18周完成。因此，根據以上這些時間估計可知，該項目的最早結束時間為18周由C和D構成的關鍵路徑的時間長度。根據正常時間內完成活動的成本可計算出項目總成本為50 000 + 80 000 + 40 000 + 30 000 = 200 000（元）如果全部活動均在它們各自的應急時間內完成，路徑AB將用11周時間，路徑CD將用15周時間。按應急時間估計計算，項

36、目的最早結束時間是15周，比在正常時間內完成這些活動提前3周。實例分析48顯然，縮短全部活動的工期通常是不必要的，甚至是沒有好處的。這是因為關鍵路徑的工期決定著項目的總工期。換句話說，加速非關鍵路徑上活動的進展不會縮短項目的完成時間，卻會增加項目的總成本。 時間成本平衡法的目標是通過壓縮那些使總成本增加最少的活動的工期，來確定項目最低的完成時間。為了實現這個目標，應在每次平衡一個時間段的前提下，壓縮關鍵路徑上那些有最低單位時間加急成本的活動。實例小結49在圖5-8上，根據正常時間和成本估計，我們首先確定項目的最早結束時間為18周（由關鍵路徑CD決定），項目的總成本是200，000元，每項活動的

37、每周加急成本可根據公式（5-15）分別計算出來：活動A：6 000元/周活動B：10 000元/周活動C：5 000元/周活動D： 6 000元/周為了將項目的工期從18周減至17周，首先必須找出關鍵路徑CD，然后，才能確定關鍵路徑上哪項活動能以最低的每周加急成本被加速。加速活動C的進程每周需要5，000元，加速活動D的進程每周需要6，000元。如果將活動C縮短1周，項目總工期可從18周縮短至17周，但項目總成本增加了5 000元（C的每周加急成本），達205，000元。實例應用50為了再縮短一個時間段，從17周縮短至16周，必須再次找出關鍵路徑，兩路徑的工期分別是AB為16周，CD為17周，

38、因此關鍵路徑仍是CD，它必須再次被減少。觀察一下關鍵路徑CD，我們意識到盡管活動C比活動D每周加急成本低，卻不能再加速活動C的進程了，英文當將項目的工期從18周減至17周時，活動C已達到它的應急時間9周了。因此，僅有的選擇是加速活動D的進程，使其工期減少1周，從8周減至7周。這就將關鍵路徑CD的工期減至16周了，但總項目成本卻增加了6 000元，從205 000元增至211 000元。我們再次將項目工期縮短1周，從16周降至15周。觀察兩條路徑，我們會發現它們現在有相同的工期16周。因此，我們現在有兩條關鍵路徑。為了將項目總工期從16周減至15周，必須將每個路徑都加速1周。觀察路徑CD，我們意

39、識到只有活動D 仍有剩余時間可以被壓縮，它還可以再壓縮1周，從7周降至6周，同時增加6，000元成本。為了使路徑AB加速1周，我們可以壓縮活動A或活動B。加速活動A每周增加6 000元，使活動B的每周加急成本為10 000元。因此，為了將項目總工期從16周縮短至15周，我們需將活動D和活動A各壓縮1周。這使項目成本增加了12，000元，從211 000元增至223，000元。51讓我們再次盡力將項目總工期縮短1周，從15周降至14周。我們又一次有兩條相同的關鍵路徑。因此，我們必須將兩條路徑同時加速1周。然而，觀察路徑CD，我們發現兩項活動均已達到它們的應急時間分別為9周和6周，不能再進一步加速

40、這兩個活動的進程了。加速路徑AB的進程因此會毫無意義，因為這只能增加項目的總成本，卻不能縮短項目的總工期。我們縮短項目總工期的能力由于路徑CD的工期不能再進一步縮短而受到限制。5253表5-7表明項目總工期減少1周，項目總成本將增加5，000元；項目工期減少2周，項目總成本將增加11，000元；項目工期減少3周，項目總成本將增加23，000元。很顯然，總成本增加的速度遠遠大于工期的縮短速度。如果四項活動均達到應急時間，項目總成本將達到259，000元，而項目的完成時間仍不會少于15周。用時間成本平衡法，我們可以通過壓縮關鍵路徑上有最低單位時間加急成本的活動，用增加23，000元的加急成本將項目

41、的工期從18周降至15周。由于項目總工期不會少于15周，壓縮全部活動至應急時間將會浪費36，000元。54人在信息系統項目中既是成本，又是資本。人力成本通常都是信息系統項目成本構成中最大的一塊，這就要求我們對人力資源從成本上去衡量，盡量使人力資源的投入最小；人力資源作為資本，我們就要盡量去發揮資本的價值，使人力資源的產出最大。因而，本節主要從人力資源平衡和項目團隊激勵這樣兩個方面去討論信息項目的人員管理問題。本節主要知識點：信息系統項目的人力資源平衡 信息系統項目的團隊三、信息系統項目的人員管理55、信息系統項目的人力資源平衡 人員進度權衡定律在前面講到Putnam模型時得到公式（5.13）：

42、，從這個公式可知開發軟件項目的工作量（E）與交付時間（td）的4次方成反比，公式中工作量的單位是人年，進度的單位是年，顯然，軟件開發過程中人員與時間的折衷是一個十分重要的問題。Putnam將這一結論稱為“軟件開發的權衡定律”。 Brooks定律曾擔任IBM公式操作系統項目經理的F.Brooks，從大量的軟件開發實踐中得出了另一條理論：“向一個已經拖延的項目追加開發人員，可能使它完成得更晚”。鑒于這一發現的重要性，許多文獻稱之為Brooks定律。這里，Brooks從另一個角度說明了“時間與人員不能線性互換”這一原則。兩個重要定律56上述兩個定律的合理解釋是，當開發人員以算術級數增長時，人員之間的

43、通信將以幾何級數增長，從而可能導致“得不償失”的結果。一般說來，由N個開發人員組成的小組，要完成既定的工作，相互之間的通信路徑總數為，而通信是需要時間的。所以，當新的開發人員加入項目組之后，原有的開發人員必須向新來的成員詳細講解某個活動或工作包的來龍去脈。并且由于信息系統開發具有較強的個人風格，所以交流溝通的時間更容易拉長，而后來者還不一定能達到原來開發人員的工作質量。57用作人力計劃的Rayleigh Norden 曲線圖5-10中以橫坐標表示距開發起點的時間，縱坐標代表在不同時間點需要的人力。圖中用虛線畫出的矩形，顯示了平均使用人力所造成的問題：開始階段人力過剩，造成浪費（圖中），到開發后

44、期需要人力時，又顯得人手不足（圖中），以后再來補償，已為時過晚了（圖中），甚至可能如Brooks定律所說，導致越幫越忙的結果。58人力資源計劃的平衡經驗表明，信息系統項目的人力分配也大致符合Rayleigh-Norden曲線的分布，呈現出前后用人少、中間用人多的不穩定人員需求情況。但是，信息系統開發人員作為技術工種，可不是一旦需要就馬上找得到的，那么在制定人力資源計劃時，就要在基本按照上述曲線配備人力的同時，盡量使某個階段的人力穩定，并且確保整個項目期人員的波動不要太大。我們稱這樣的過程為人力資源計劃的平衡。59人力資源平衡法是制定使人力資源需求波動最小化的進度計劃的一種方法。這種平衡人力資源

45、的方法是為盡可能均衡地利用人力資源并滿足項目要求完成的進度。人力資源平衡是在不延長項目完工時間的情況下建立人力資源均衡利用的進度計劃。為了說明人力資源計劃平衡的方法，下面舉例具體說明。現有一個學籍信息管理系統已經立項，由于系統較小，準備采用原型法開發，并擬訂了一個帶有活動工期和人力需求的網絡圖，如圖5-11所示。為了討論的方便，我們假設參加這個項目的所有成員都是多面手，也就是說，項目成員之間是可以相互替代的。60圖5-11 反映學籍信息管理系統項目人力資源需求的網絡圖原型法軟件開發8周2個信息技術人員文檔寫作2周1個信息技術人員網絡設計與實現5周1個信息技術人員設備采購3周1個信息技術人員系統

46、測試與轉換3周2個信息技術人員人員培訓1周1個信息技術人員項目開始項目結束61如果不采用項目管理的思想，一般人們都會希望各項活動盡可能早開始、盡可能早結束。現在我們就假設網絡圖中每一活動在其最早開始時間執行，基于此，我們可以繪制相應的人力資源分配圖（見圖5-12）。圖5-12 基于活動最早開始時間的人力資源計劃 62從圖5-12（a）中可以看出，學籍信息系統項目總共需要13周的時間，總的工作量為33人周；從圖5-12（b）中可以看出，前3周需要4個開發人員，第4、5周需要3各開發人員，第6至12周只需要2個開發人員，第13周需要1個開發人員。顯然，該項目的人力需求波動較大。為了使人力資源盡可能

47、地平衡我們來考察該項目的網絡圖從圖5-11中可以看出，該項目的關鍵路徑是原型法軟件開發、系統測試與轉換、文檔寫作三個活動。而其他三個活動處于非關鍵路徑上，我們可以將設備采購活動推遲在第6周開始，這樣，得到調整后的人力資源分配圖，如圖5-13所示。63從圖5-13（a）中可以看出，學籍信息系統項目總共還是需要13周的時間，總的工作量仍為33人周，也就是說，雖然調整了人力資源的分配，但并未影響進度。從圖5-13（b）中可以看出，前8周需要3個開發人員，第9至12周只需要2個開發人員，第13周需要1個開發人員。顯然，相對圖5-12（b）來講，調整后該項目的人力需求波動較小。圖5-13 基于資源平衡的

48、人力計劃圖 64示例小結這里要解釋的是，由于采用原型法開發該項目，系統調研、原型制作和原型改造都在項目前期進行，用的人力較多，所以是直接從Rayleigh-Norden曲線分布的中部開始，從這個意義上說，本項目的人力使用也基本遵守上述曲線的分布。上面的例子是在資源沒有約束的情況下討論的，如果資源有約束，比如上述的項目只能找到兩個開發人員，那么在這種人力資源有約束的情況下進行人力平衡，方法是同上的，也就是通過推遲非關鍵路徑上的活動使資源需求盡可能平衡，不過，進度可能就會有較大的變化，比如上述項目33人周，如果兩個人開發，則至少需要16.5周才能完成，顯然大于13周的計劃進度。652、信息系統項目

49、的團隊項目小組的具體構成形式 項目小組，是指項目團隊的基層單位 。一般說來，每個項目小組的規模應該比較小，以28名成員為宜。如果項目屬于中小型規模且建設時間在一年以內，那么項目小組的成員可以是活動負責人制。如果項目屬于大中型規模，建設時間在一年以上，那么就必須考慮項目建設人員因各種原因發生變動的情況。 66 這時項目小組推薦的具體構成是這樣的：一個高級系統開發人員帶兩個中級系統開發人員，每個中級開發人員再帶2個初級開發人員，參見圖5-14（a）。這里的系統開發人員既包括程序員，也包括測試員。比如圖5-14（b）就是測試小組的構成。 1名高級系統開發員1名初級系統開發員1名中級系統開發員1名中級

50、系統開發員1名初級系統開發員1名初級系統開發員1名初級系統開發員（a）圖5-14 大型信息系統項目基層項目小組的具體構成及舉例1名高級系統測試員1名初級系統測試員1名中級系統測試員1名中級系統測試員1名初級系統測試員1名初級系統測試員1名初級系統測試員（b）67采用這種按技術水平分層的具體構成模式，主要基于兩點考慮：第一，信息系統的建設工作中既有創造性很強的事務，也有經驗性很強的事務和照葫蘆畫瓢的簡單性事務，如果所有活動都讓高級人員去完成，那么成本很高，是人力資源的極大浪費，還會引起高級人員的不滿，而上述三類活動剛好適合三類人員去完成，做到人盡其能；第二，由于項目建設時間太長，容易發生人員更替

51、，并且由于信息系統開發技術主要是“干中學”的知識，中級和初級開發人員在系統建設的過程中會成長起來，如果一旦發生上一層次的人員的變動，下層人員由于一直參與項目的研發，基本上可以“無縫”地把工作承接起來。68如果項目小組成員不發生人員更替，那更好，項目小組的整體素質將會隨著時間的推移而提高得很快，從而使項目的進度加快。初、中、高級人員最初的薪水水平可以按類似0.3：0.7：1.0的比例定位。當然，隨著初中級人員技術水平的提高，他們的薪水也應該不斷提高，因為他們在同等的時間可以完成更多更復雜的工作，并且會有更好的質量。還有，這里上下層的開發人員之間的比例定為2，這個比例也可以隨不同項目小組的情況具體

52、調整，比如為1或3，但最好不要超過3個。69項目團隊的成長與激勵 信息系統項目團隊的成長與其他項目一樣，一般需要經過如下四個階段： 形成（forming）階段形成階段促使個體轉變為團隊成員。這一階段的情緒特點包括激動、希望、懷疑、焦急和猶豫。在這個階段中，團隊要建立起整體形象，需要明確方向，并試圖對要完成的工作明確劃分并制定計劃。在這個階段，對于項目成員采取的激勵方式主要為預期激勵、信息激勵和參與激勵。 震蕩（storming）階段這一階段，成員們開始運用技能著手執行分配到的任務，開始緩慢推進工作。現實也許會與個人當初的設想不一致。震蕩階段的特點是人們有挫折、怨憤或者對立的情緒。在這個階段，項

53、目經理要對每個人的職責及團隊成員相互間的行為進行明確和分類，使每個成員明白無誤，還要使團隊參與一道解決問題，共同做出決策。在這個階段，對于項目成員采取的激勵方式主要有參與激勵、責任激勵和信息激勵。 70 正規（norming）階段經受了震蕩階段的考驗后，項目團隊就進入了發展的正規階段。團隊成員之間、團隊與項目經理之間的關系已確立好了。項目團隊逐漸接受了現有的工作環境，項目規程也得以改進和規范化。團隊經過這個社會化的過程后，建立了忠誠和友誼，也有可能建立超出工作范圍的友誼。在正規階段，項目經理采取的激勵方式除參與激勵外，還有兩個重要方式：一是發掘每個成員的自我成就感和責任意識，誘導員工進行自我激

54、勵；二是盡可能地多創造團隊成員之間互相溝通、互相學習的好環境，以及從項目外部聘請專家講解與項目有關的新知識和新技術，給員工充分的知識激勵。 表現（performing）階段團隊成長的最后一個階段是表現階段。這時，項目團隊積極工作，急于實現項目目標。這一階段的工作績效很高，團隊有集體感和榮譽感，信心十足。項目團隊能開放、坦誠、及時地進行溝通。團隊相互依賴度高，他們經常合作，并在自己的工作任務外盡力相互幫助。這一階段，項目經理集中注意關于預算、進度計劃、工作范圍及計劃方面的項目業績。如果實際進程落后于計劃進程，項目經理的任務就是協助支持修正行動的制定與執行，因而這一階段激勵的主要方式是危機激勵、目

55、標激勵和知識激勵。71信息系統項目成長階段與激勵的關系示意圖參見圖5-15。 72上述四個階段分別列舉的激勵方式都是該階段的主要方式，其他階段的激勵方式也可以同時被很好地采用。要強調的是，對于信息系統建設人才，要更多地引導他們進行自我激勵，要更多地對他們進行知識激勵。當然，足夠的物質激勵是不言而喻的、自始至終的、最有效的激勵。激勵的結果是使參與信息系統的所有成員組織成一個工作富有成效的項目團隊。有成效的項目團隊具有如下特點：能清晰理解項目的目標；每位成員的角色和職責有明確的期望；以項目的目標為行為的導向；項目成員之間高度信任，高度地合作互助等。表5-8提供了一些問題，以幫助項目經理檢查自己的團

56、隊是否有效。表中的得分采取5分制，5分表示最好，4分表示較好，3分表示一般，2分表示較差，1分表示最差。總分100。 7374前面多次講過，信息系統項目建設的目的是在一定的時間和一定費用下完成一定的任務，并且這些任務必須達到一定的質量要求。因而信息系統項目管理的一個很重要方面就是信息系統建設的質量管理。從另外一個意義上說，信息系統也是一個產品，而質量是產品的生命。因而我們必須重視信息系統建設的質量管理。本節主要內容1、信息系統建設需要全面質量控制2、信息系統質量的指標體系 3、信息系統實施全面質量控制的辦法四、信息系統的質量管理751、信息系統建設需要全面質量控制信息系統質量管理不僅僅是項目開發完成后的最終評價，而是信息系統開發過程中的全面質量控制。也就是說，不僅包括系統實現時的質量控制，也包括系統分析、系統設計時的質量控制；不僅包括對系統實現時軟件的質量控制，而且還包括對文檔、開發人員和用戶培訓的質量控制。之所以對信息系統采取全面質量控制，是因為在信息系統生命周期的各個階段，對上一階段的理解和本階段的設計與實現上都存在著這樣那樣的問題，如圖5-16所示。在該圖中階段之間的接口至少存在列出來的