1、第十章第十章 軟件項目管理軟件項目管理10.1 估算軟件規模估算軟件規模10.2 工作量估算工作量估算10.3 進度計劃進度計劃10.4 人員組織人員組織10.5 軟件配置管理軟件配置管理10.6 能力成熟度模型能力成熟度模型CMM第第1010章章 軟件項目管理軟件項目管理n項目管理就是通過計劃、組織和控制等一系列活動，合理項目管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到項目既定目標的過程。地配置和使用各種資源，以達到項目既定目標的過程。n軟件項目管理先于任何技術活動之前開始，并且貫穿于軟軟件項目管理先于任何技術活動之前開始，并且貫穿于軟件的整個生命周期之中。件的

2、整個生命周期之中。n軟件項目管理過程源于項目計劃，主要活動是軟件項目管理過程源于項目計劃，主要活動是“估算估算”。n軟件計劃詳盡地描述了軟件過程，包括采用的生命周期模軟件計劃詳盡地描述了軟件過程，包括采用的生命周期模型、開發組織結構、責任分配、管理目標和優先級、所用型、開發組織結構、責任分配、管理目標和優先級、所用技術和技術和CASECASE工具，以及詳細的進度、預算和資源分配。工具，以及詳細的進度、預算和資源分配。n整個計劃的基礎是工作量估算和完成期限估算。整個計劃的基礎是工作量估算和完成期限估算。PSPPSP訓練訓練軟件度量技術軟件度量技術n代碼行技術代碼行技術:是一種比較簡單的定量估算軟

3、件規模的方法。根據以往開發類似產品的經驗和歷史數據，估計實現一個功能需要的源程序行數。把實現每個功能需要的源程序行數累加起來，就得到實現整個軟件需要的源程序行數。n用代碼行技術度量軟件規模時，當程序較小時用代碼行技術度量軟件規模時，當程序較小時常用的單位是代碼行數常用的單位是代碼行數(LOC)(LOC)，當程序較大時，當程序較大時常用的單位是千行代碼數常用的單位是千行代碼數(KLOC)(KLOC)。n為了使得對程序規模的估計值更接近實際值，可以由為了使得對程序規模的估計值更接近實際值，可以由多名有經驗的軟件工程師分別作出估計。多名有經驗的軟件工程師分別作出估計。n每個人都估計程序的最小規模每個

4、人都估計程序的最小規模(a)(a)、最大規模、最大規模(b)(b)和最和最可能的規模可能的規模(m)(m)，分別算出這三種規模的平均值，分別算出這三種規模的平均值a a，b b，和和m m 之后，再用下式計算程序規模的估計值：之后，再用下式計算程序規模的估計值：64bmaL-PERT技術技術優點優點:主要是主要是代碼是所有軟件開發項目都有的代碼是所有軟件開發項目都有的“產品產品”，而且很容易計算代碼行數。，而且很容易計算代碼行數。缺點缺點是：是：源程序僅是軟件配置的一個成分，用不源程序僅是軟件配置的一個成分，用不同語言實現同一個軟件所需要的代碼行數并不相同語言實現同一個軟件所需要的代碼行數并不

5、相同；用它的規模代表整個軟件的規模似乎不太合同；用它的規模代表整個軟件的規模似乎不太合理；這種方法不適用于非過程語言。理；這種方法不適用于非過程語言。為了克服代碼行技術的缺點，人們又提出了功能為了克服代碼行技術的缺點，人們又提出了功能點技術。點技術。用功能點（用功能點（FPFP）為單位度量軟件規模）為單位度量軟件規模1. 1. 信息域特性信息域特性功能點技術定義了信息域的功能點技術定義了信息域的5個特性，分別個特性，分別是輸入項數是輸入項數(Inp)、輸出項數、輸出項數(Out)、查詢數、查詢數(Inq)、主文件數、主文件數(Maf)和外部接口數和外部接口數(Inf)。n功能點技術：功能點技術

6、：依據對軟件信息域特性和依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。軟件復雜性的評估結果，估算軟件規模。（1 1）輸入項數：輸入項數：用戶向軟件輸入的項數，這些輸入給軟用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不同于查詢，后者單獨計件提供面向應用的數據。輸入不同于查詢，后者單獨計數，不計入輸入項數中。數，不計入輸入項數中。（2 2）輸出項數：輸出項數：軟件向用戶輸出的項數，它們向用戶提軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內供面向應用的信息，例如，報表和出錯信息等。報表內的數據項不單獨計數。的數據項不單獨計數。（3 3）

7、查詢數：查詢數： 查詢即是一次聯機輸入，它導致軟件以查詢即是一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。聯機輸出方式產生某種即時響應。（4 4）主文件數：主文件數：邏輯主文件（即數據的一個邏輯組合，邏輯主文件（即數據的一個邏輯組合，它可能是大型數據庫的一部分或是一個獨立的文件）的它可能是大型數據庫的一部分或是一個獨立的文件）的數目。數目。（5 5）外部接口數：外部接口數：機器可讀的全部接口（例如磁盤或磁機器可讀的全部接口（例如磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另帶上的數據文件）的數量，用這些接口把信息傳送給另一個系統。一個系統。2. 2. 估算功能點的步驟估算功

8、能點的步驟估算出一個軟件的功能點數（即軟件規模）：估算出一個軟件的功能點數（即軟件規模）：（1） 計算未調整的功能點數計算未調整的功能點數CT 把產品信息域的每個特性把產品信息域的每個特性(即即Inp、Out、Inq、Maf和和Inf)都分類為簡單級、平均級或復雜級，并根據其等級為都分類為簡單級、平均級或復雜級，并根據其等級為每個特性分配一個功能點數每個特性分配一個功能點數（例如，一個簡單級的輸入項分配（例如，一個簡單級的輸入項分配3個功能點，一個平均個功能點，一個平均級的輸入項分配級的輸入項分配4個功能點，而一個復雜級的輸入項分配個功能點，而一個復雜級的輸入項分配6個功能點）。個功能點）。

9、未調整的功能點數未調整的功能點數UFP： CT=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，其中，ai(1i5)是信息域特性系數，其值由相應特性的復是信息域特性系數，其值由相應特性的復雜級別決定。雜級別決定。(2) 計算技術復雜性因子計算技術復雜性因子TCF這一步驟度量這一步驟度量14種技術因素對軟件規模的影響程度。這些種技術因素對軟件規模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯機因素包括高處理率、性能標準（例如，響應時間）、聯機更新等，用更新等，用Fi(1i14)代表這些因素。代表這些因素。根據軟件的特點，為每個因素分配一個從根據軟件的特點，為每個

10、因素分配一個從0（不存在或對軟（不存在或對軟件規模無影響）到件規模無影響）到5（有很大影響）的值。（有很大影響）的值。技術因素對軟件規模的綜合影響程度技術因素對軟件規模的綜合影響程度DI： DI=技術復雜性因子技術復雜性因子TCF由下式計算：由下式計算： TCF=0.65+0.01DI因為因為DI的值在的值在070之間，所以之間，所以TCF的值在的值在0.651.35之間。之間。 141iiF（3 3） 計算功能點數計算功能點數FPFP FP=CTTCF功能點數與所用的編程語言無關，看起來功能點技術比代功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。但是，在判斷信息域特性

11、復雜級別碼行技術更合理一些。但是，在判斷信息域特性復雜級別和技術因素的影響程度時，存在著相當大的主觀因素。和技術因素的影響程度時，存在著相當大的主觀因素。軟件估算模型使用由經驗導出的公式來預測軟件開軟件估算模型使用由經驗導出的公式來預測軟件開發工作量，工作量是軟件規模（發工作量，工作量是軟件規模（KLOC或或FP）的函）的函數，工作量的單位通常是人月（數，工作量的單位通常是人月（pm)。由于支持大多數估算模型的經驗數據，都是從有限由于支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估個項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開

12、發環境。算模型可以適用于所有類型的軟件和開發環境。10.2 10.2 工作量估算工作量估算這類模型的總體結構形式如下：這類模型的總體結構形式如下： E=A+B(ev)C其中，其中，A、B和和C是由經驗數據導出的常數，是由經驗數據導出的常數，E是以人月為是以人月為單位的工作量，單位的工作量，ev是估算變量（是估算變量（KLOC或或FP）。下面給）。下面給出幾個典型的靜態單變量模型。出幾個典型的靜態單變量模型。面向面向KLOC的估算模型的估算模型(1) Walston_Felix模型模型 E=5.2(KLOC)0.91(2) Bailey_Basili模型模型 E=5.5+0.73(KLOC)1.

13、1610.2.1 10.2.1 靜態單變量模型靜態單變量模型可以看出，對于相同的可以看出，對于相同的KLOC或或FP值，用不同模型估算將值，用不同模型估算將得出不同的結果。主要原因是，這些模型多數都是僅根據得出不同的結果。主要原因是，這些模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，適用若干應用領域中有限個項目的經驗數據推導出來的，適用范圍有限。范圍有限。 因此，必須根據當前項目的特點選擇適用的估算模型，因此，必須根據當前項目的特點選擇適用的估算模型，并且根據需要適當地調整（例如，修改模型常數）估算模并且根據需要適當地調整（例如，修改模型常數）估算模型。型。 1981年年Bo

14、ehm在在軟件工程經濟學軟件工程經濟學中首次提出了中首次提出了COCOMO模型，模型， COCOMO是構造性成本模型（是構造性成本模型（Constructive Cost Model)的英文縮寫。的英文縮寫。 1997年年Boehm等人提出的等人提出的COCOMO2模型，是原模型，是原COCOMO模型的修訂版，它反映了十多年來在成本估計方模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。面所積累的經驗。 COCOMO2給出了給出了3個層次的軟件開發工作量估算模型，個層次的軟件開發工作量估算模型，這這3個層次的模型在估算工作量時，對軟件細節考慮的詳盡個層次的模型在估算工作量時，對軟件細節

15、考慮的詳盡程度逐級增加。程度逐級增加。10.2.2 COCOMO2模型模型這這3個層次的估算模型分別是：個層次的估算模型分別是： （1） 應用系統組成模型。這個模型主要用于估算應用系統組成模型。這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。量使用已有的構件。（2） 早期設計模型。這個模型適用于體系結構設早期設計模型。這個模型適用于體系結構設計階段。計階段。（3） 后體系結構模型。這個模型適用于完成體系后體系結構模型。這個模型適用于完成體系結構設計之后的軟件開發階段。結構設計之后的軟件開發階段。下面以下面以后體系結構

16、模型后體系結構模型為例，介紹為例，介紹COCOMO2模型。模型。該模型把該模型把軟件開發工作量表示成代碼行數軟件開發工作量表示成代碼行數（KLOC）的）的非線性函數：非線性函數： E=(3)其中，其中， E是開發工作量（以人月為單位），是開發工作量（以人月為單位）， a是模型系數，是模型系數， KLOC是估計的源代碼行數，是估計的源代碼行數， b是模型指數，是模型指數， fi(i=117)是成本因素。是成本因素。 171iibfKLOCa 每個成本因素都根據它的重要程度和對工作量影響每個成本因素都根據它的重要程度和對工作量影響大小被賦予一定數值（稱為工作量系數）。大小被賦予一定數值（稱為工作量

17、系數）。Boehm把成把成本因素劃分成本因素劃分成產品因素、平臺因素、人員因素和項目因素產品因素、平臺因素、人員因素和項目因素等等4類。類。 與原始的與原始的COCOMO模型相比，模型相比，COCOMO2模型使用模型使用的成本因素有下述變化的成本因素有下述變化:（1） 新增加了新增加了4個成本因素，它們分別是要求的個成本因素，它們分別是要求的可重用可重用性、需要的文檔量、人員連續性性、需要的文檔量、人員連續性（即人員穩定程度）和（即人員穩定程度）和多多地點開發地點開發。這個變化表明，這些因素對開發成本的影響日。這個變化表明，這些因素對開發成本的影響日益增加。益增加。（2） 略去了原始模型中的略

18、去了原始模型中的2個成本因素（計算機切換時個成本因素（計算機切換時間和使用現代程序設計實踐）。間和使用現代程序設計實踐）。（3） 某些成本因素（分析員能力、平臺經驗、語言和工具某些成本因素（分析員能力、平臺經驗、語言和工具經驗）對生產率的影響（即工作量系數最大值與最小值的經驗）對生產率的影響（即工作量系數最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減比率）增加了，另一些成本因素（程序員能力）的影響減小了。小了。 為了確定工作量方程中模型指數為了確定工作量方程中模型指數b的值，原始的的值，原始的COCOMO模型把軟件開發項目劃分成組織式、半獨立式和模型把軟件開發項目劃分成組織

19、式、半獨立式和嵌入式這樣嵌入式這樣3種類型，并指定每種項目類型所對應的種類型，并指定每種項目類型所對應的b值（值（分別是分別是1.05，1.12和和1.20）。）。COCOMO2采用了更加精細采用了更加精細得多的得多的b分級模型，這個模型使用分級模型，這個模型使用5個分級因素個分級因素Wi(1i5),其其中每個因素都劃分成從甚低（中每個因素都劃分成從甚低（Wi=5)到特高（到特高（Wi=0)的的6個級個級別，然后用下式計算別，然后用下式計算b的數值：的數值： b=(4)因此，因此，b的取值范圍為的取值范圍為1.011.26。顯然，這種分級模式比。顯然，這種分級模式比原始原始COCOMO模型的分

20、級模式更精細、更靈活。模型的分級模式更精細、更靈活。COCOMO2使用的使用的5個分級因素如下所述：個分級因素如下所述： （1） 項目先例性。這個分級因素指出，對于開發組織來說項目先例性。這個分級因素指出，對于開發組織來說該項目的新奇程度。諸如開發類似系統的經驗，需要創新該項目的新奇程度。諸如開發類似系統的經驗，需要創新體系結構和算法，以及需要并行開發硬件和軟件等因素的體系結構和算法，以及需要并行開發硬件和軟件等因素的影響，都體現在這個分級因素中。影響，都體現在這個分級因素中。5101. 101. 1iiW（2） 開發靈活性。這個分級因素反映出，為了實現預先確開發靈活性。這個分級因素反映出，為

21、了實現預先確定的外部接口需求及為了及早開發出產品而需要增加的工定的外部接口需求及為了及早開發出產品而需要增加的工作量。作量。（3） 風險排除度。這個分級因素反映了重大風險已被消除風險排除度。這個分級因素反映了重大風險已被消除的比例。在多數情況下，這個比例和指定了重要模塊接口的比例。在多數情況下，這個比例和指定了重要模塊接口（即選定了體系結構）的比例密切相關。（即選定了體系結構）的比例密切相關。（4） 項目組凝聚力。這個分級因素表明了開發人員相互協項目組凝聚力。這個分級因素表明了開發人員相互協作時可能存在的困難。這個因素反映了開發人員在目標和作時可能存在的困難。這個因素反映了開發人員在目標和文化

22、背景等方面相一致的程度，以及開發人員組成一個小文化背景等方面相一致的程度，以及開發人員組成一個小組工作的經驗。組工作的經驗。（5） 過程成熟度。這個分級因素反映了按照能力成熟過程成熟度。這個分級因素反映了按照能力成熟度模型度量出的項目組織的過程成熟度。度模型度量出的項目組織的過程成熟度。 在原始的在原始的COCOMO模型中，僅粗略地考慮了前兩個模型中，僅粗略地考慮了前兩個分級因素對指數分級因素對指數b之值的影響。之值的影響。 工作量方程中模型系數工作量方程中模型系數a的典型值為的典型值為3.0，在實際工，在實際工作中應該根據歷史經驗數據確定一個適合本組織當前開作中應該根據歷史經驗數據確定一個適

23、合本組織當前開發的項目類型的數值。發的項目類型的數值。 不論從事哪種技術性項目，實際情況都是，在實現不論從事哪種技術性項目，實際情況都是，在實現一個大目標之前往往要把它分解成一系列的比較容易管理一個大目標之前往往要把它分解成一系列的比較容易管理的子項目（也稱為作業）。的子項目（也稱為作業）。這些任務中有一些是處于這些任務中有一些是處于“關關鍵路徑鍵路徑”之外的，其完成時間如果沒有嚴重拖后，就不會之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；影響整個項目的完成時間；其他任務則處于關鍵路徑之中其他任務則處于關鍵路徑之中，如果這些，如果這些“關鍵任務關鍵任務”的進度拖后，則整個項

24、目的完成的進度拖后，則整個項目的完成日期就會拖后，管理人員應該高度關注關鍵任務的進展情日期就會拖后，管理人員應該高度關注關鍵任務的進展情況。況。 項目管理者的目標項目管理者的目標是是定義全部項目任務，識別出關鍵定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延進度的情況。進度的情況。為達到上述目標，管理者必須制定一個足夠為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監督項目進度并控制整個項目。詳細的進度表，以便監督項目進度并控制整個項目。10.3 10.3 進度計劃進度計劃 Gantt（甘特）圖是歷史悠久、

25、應用廣泛的制定進度（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工計劃的工具，下面通過一個非常簡單的例子介紹這種工具。具。 假設有一座陳舊的矩形木板房需要重新油漆。這項假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分工作必須分3步完成：步完成： 首先刮掉舊漆，然后刷上新漆，最首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了后清除濺在窗戶上的油漆。假設一共分配了15名工人去名工人去完成這項工作，然而工具卻很有限：完成這項工作，然而工具卻很有限： 只有只有5把刮舊漆用的把刮舊漆用的刮板，刮板，5把刷漆用的刷子，把刷漆用的刷子，5把清

26、除濺在窗戶上的油漆用把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢的小刮刀。怎樣安排才能使工作進行得更有效呢?10.3.1 Gantt圖圖一種做法是首先刮掉四面墻壁上的舊漆，然后給一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有名工人，然而每種工具卻只有5件，這樣安排件，這樣安排工作在任何時候都有工作在任何時候都有10名工人閑著沒活干。名工人閑著沒活干。讀者可能已經想到，應該采用讀者可

27、能已經想到，應該采用“流水作業法流水作業法”，也就是說，首先由，也就是說，首先由5名名工人用刮板刮掉第工人用刮板刮掉第1面墻上的舊漆面墻上的舊漆(這時其余這時其余10名工人休息名工人休息)，當第，當第1面墻面墻刮凈后，另外刮凈后，另外5名工人立即用刷子給這面墻刷新漆名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的與此同時拿刮板的5名工人轉去刮第名工人轉去刮第2面墻上的舊漆面墻上的舊漆)，一旦刮舊漆的工人轉到第，一旦刮舊漆的工人轉到第3面墻而且面墻而且刷新漆的工人轉到第刷新漆的工人轉到第2面墻以后，余下的面墻以后，余下的5名工人立即拿起刮刀去清除名工人立即拿起刮刀去清除濺在第濺在第1面墻窗戶上的

28、油漆，面墻窗戶上的油漆，。這樣安排每個工人都有活干，因此。這樣安排每個工人都有活干，因此能夠在較短的時間內完成任務。能夠在較短的時間內完成任務。假設木板房的假設木板房的第第2、4兩面墻的長度比第兩面墻的長度比第1、3兩面墻的長度長一倍，兩面墻的長度長一倍，此此外，不同工作需要用的時間長短也不同，外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊刷新漆最費時間，其次是刮舊漆，清理漆，清理(即清除濺在窗戶上的油漆即清除濺在窗戶上的油漆)需要的時間最少。需要的時間最少?？梢允褂脠D可以使用圖1中的中的Gantt圖描繪上述流水作業過程：圖描繪上述流水作業過程： 在時間在時間為零時開始為零時開

29、始刮第刮第1面墻上的舊漆面墻上的舊漆，兩小時后，兩小時后刮舊漆的工人轉刮舊漆的工人轉去刮第去刮第2面墻面墻，同時另，同時另5名工人開始給第名工人開始給第1面墻刷新漆，每當面墻刷新漆，每當給一面墻刷完新漆之后，第給一面墻刷完新漆之后，第3組的組的5名工人立即清除濺在這名工人立即清除濺在這面墻窗戶上的漆。從圖面墻窗戶上的漆。從圖1可以看出可以看出12小時后刮完所有舊漆，小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過小時后完成所有墻壁的刷漆工作，再過2小時后清理工作小時后清理工作結束。因此全部工程在結束。因此全部工程在22小時后結束，如果用前述的第一小時后結束，如果用前述的第一種做法，則

30、需要種做法，則需要36小時。小時。工序墻面刮舊漆刷新漆清理1或32312或4462圖9.1 舊木板房刷漆工程的Gantt圖刮第1面墻柒第1面墻刮第3面墻柒第3面墻刮第2面墻刮第4面墻柒第2面墻柒第4面墻 Gantt圖能很形象地描繪任務分解情況，以及每個子任圖能很形象地描繪任務分解情況，以及每個子任務務(作業作業)的開始時間和結束時間，因此的開始時間和結束時間，因此,它是進度計劃和進它是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優點，但是制的優點，但是Gantt圖也有圖也有3個主要缺點：個主要缺點： (1) 不能顯式地描繪

31、各項作業彼此間的依賴關系；不能顯式地描繪各項作業彼此間的依賴關系；(2) 進度計劃的關鍵部分不明確，難于判定哪些部分應當是進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；主攻和主控的對象；(3) 計劃中有潛力的部分及潛力的大小不明確，往往造成潛計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。力的浪費。10.3.3 10.3.3 工程網絡工程網絡 當把一個工程項目分解成許多子任務，它們彼此間的當把一個工程項目分解成許多子任務，它們彼此間的依賴關系又比較復雜時，僅僅用依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的圖作為安排進度的工具是不夠的，不僅難于做出既節省資

32、源又保證進度的計工具是不夠的，不僅難于做出既節省資源又保證進度的計劃，而且還容易發生差錯。劃，而且還容易發生差錯。 工程網絡是制定進度計劃時另一種常用的圖形工具，工程網絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業的開始時間和結它同樣能描繪任務分解情況以及每項作業的開始時間和結束時間，此外，它還顯式地描繪各個作業彼此間的依賴關束時間，此外，它還顯式地描繪各個作業彼此間的依賴關系。因此，工程網絡是系統分析和系統設計的強有力的工系。因此，工程網絡是系統分析和系統設計的強有力的工具。具。圖圖9.2 舊木板房刷漆工程的工程網絡舊木板房刷漆工程的工程網絡畫出類似圖畫出類似圖

33、2那樣的工程網絡之后，系統分析員就可以借助那樣的工程網絡之后，系統分析員就可以借助它的幫助估算工程進度了。為此需要在工程網絡上增加一它的幫助估算工程進度了。為此需要在工程網絡上增加一些必要的信息。些必要的信息。首先，把每個作業估計需要使用的時間寫在表示該項作業首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒有關系，箭頭僅表示依賴關系，它上方的數字才表示作業有關系，箭頭僅表示依賴關系，它上方的數字才表示作業的持續時間。的持續時間。10.3.4 10.3.4 估算工程進度估算工程進度其次，為每個事

34、件計算下述兩個統計數字：其次，為每個事件計算下述兩個統計數字： 最早時刻最早時刻EET和最遲時刻和最遲時刻LET。這兩個數字將分別寫在表示事件的圓圈。這兩個數字將分別寫在表示事件的圓圈的右上角和右下角，如圖的右上角和右下角，如圖3左下角的符號所示。左下角的符號所示。事件的最早時刻是該事件可以發生的最早時間。通常工程事件的最早時刻是該事件可以發生的最早時間。通常工程網絡中第一個事件的最早時刻定義為零，其他事件的最早網絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網絡上從左至右按事件發生順序計算。計算最時刻在工程網絡上從左至右按事件發生順序計算。計算最早時刻早時刻EET使用下述使用下述

35、3條簡單規則：條簡單規則： 圖圖13.3 舊木板房刷漆工程的完整的工程網絡舊木板房刷漆工程的完整的工程網絡(1) 考慮進入該事件的所有作業；考慮進入該事件的所有作業；(2) 對于每個作業都計算它的持續時間與起始事件的對于每個作業都計算它的持續時間與起始事件的EET之和；之和；(3) 選取上述和數中的最大值作為該事件的最早時刻選取上述和數中的最大值作為該事件的最早時刻EET 按照這種方法，不難沿著工程網絡從左至右順序算按照這種方法，不難沿著工程網絡從左至右順序算出每個事件的最早時刻，計算結果標在圖出每個事件的最早時刻，計算結果標在圖3的工程網絡中的工程網絡中(每個圓圈內右上角的數字每個圓圈內右上

36、角的數字)。事件的事件的最遲時刻最遲時刻是在不影響工程竣工時間的前提下，該事是在不影響工程竣工時間的前提下，該事件最晚可以發生的時刻。件最晚可以發生的時刻。 按慣例，最后一個事件按慣例，最后一個事件(工程結束工程結束)的最遲時刻就是它的最遲時刻就是它的最早時刻。其他事件的的最早時刻。其他事件的最遲時刻最遲時刻在工程網絡上從右至左在工程網絡上從右至左按逆作業流的方向計算。計算最遲時刻按逆作業流的方向計算。計算最遲時刻LET使用下述使用下述3條規條規則：則： (1) 考慮離開該事件的所有作業；考慮離開該事件的所有作業；(2) 從每個作業的結束事件的最遲時刻中減去該作業的持續從每個作業的結束事件的最

37、遲時刻中減去該作業的持續時間；時間；(3) 選取上述差數中的選取上述差數中的最小值最小值作為該事件的最遲時刻作為該事件的最遲時刻LET。 圖10.3中有幾個事件的最早時刻和最遲時刻相同，這些事件即為關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的作業(關鍵作業)的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。 工程項目的管理人員應該密切注視關鍵作業的進展情況，如果關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業中增加資源才會有效果。10.3.5 10.3.5 關鍵路徑關鍵路徑 不在關鍵

38、路徑上的作業有一定程度的機動余地不在關鍵路徑上的作業有一定程度的機動余地實際開始時間可以比預定時間晚一些，或者實實際開始時間可以比預定時間晚一些，或者實際持續時間可以比預定的持續時間長一些，而并不際持續時間可以比預定的持續時間長一些，而并不影響工程的結束時間。影響工程的結束時間。 一個作業可以有的全部機動時間等于它的結束事件的最遲時刻一個作業可以有的全部機動時間等于它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業的持續時間：減去它的開始事件的最早時刻，再減去這個作業的持續時間： 機動時間機動時間=(LET)結束結束-持續時間持續時間-(EET)開始開始10.3.6 機動時間機動

39、時間圖圖13.4 舊木板房刷漆工程改進的舊木板房刷漆工程改進的Gantt圖之一圖之一工程網絡比工程網絡比Gantt圖優越的地方：圖優越的地方： 它顯式地定義事件及它顯式地定義事件及作業之間的依賴關系，作業之間的依賴關系，Gantt圖只能隱含地表示這種關圖只能隱含地表示這種關系。系。但是但是Gantt圖的形式比工程網絡更簡單更直觀，為圖的形式比工程網絡更簡單更直觀，為更多的人所熟悉，更多的人所熟悉，因此，應該因此，應該同時使用這兩種工具制訂同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短和管理進度計劃，使它們互相補充取長補短。 總之總之, 工作量估計技術可以幫助我們估計每項任務工作量

40、估計技術可以幫助我們估計每項任務的工作量，根據人力分配情況，可以進一步確定每項任的工作量，根據人力分配情況，可以進一步確定每項任務的持續時間。從這些基本數據出發，根據作業之間的務的持續時間。從這些基本數據出發，根據作業之間的依賴關系，利用工程網絡和依賴關系，利用工程網絡和Gantt圖可以制定出合理的圖可以制定出合理的進度計劃，并且能夠科學地管理軟件開發工程的進展情進度計劃，并且能夠科學地管理軟件開發工程的進展情況。況。 軟件項目成功的關鍵是有高素質的軟件開發人員。然軟件項目成功的關鍵是有高素質的軟件開發人員。然而大多數軟件的規模都很大，單個軟件開發人員無法在給而大多數軟件的規模都很大，單個軟件

41、開發人員無法在給定期限內完成開發工作，因此，必須把多名軟件開發人員定期限內完成開發工作，因此，必須把多名軟件開發人員合理地組織起來，使他們有效地分工協作共同完成開發工合理地組織起來，使他們有效地分工協作共同完成開發工作。作。 經驗表明，項目組組織得越好，其生產率越高，而且經驗表明，項目組組織得越好，其生產率越高，而且產品質量也越好。產品質量也越好。 除了追求更好的組織方式之外，每個管理者的目標都除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。一個有高度凝聚力的小組，由是建立有凝聚力的項目組。一個有高度凝聚力的小組，由一批團結得非常緊密的人組成，他們的整體力量大于個體一批團

42、結得非常緊密的人組成，他們的整體力量大于個體力量的總和。一旦項目組具有了凝聚力，成功的可能性就力量的總和。一旦項目組具有了凝聚力，成功的可能性就大大增加了。大大增加了。10.4 人員組織人員組織 其特點是，小組成員完全平等，享有充分民主，其特點是，小組成員完全平等，享有充分民主，通過協商做出技術決策。因此，小組成員之間的通信通過協商做出技術決策。因此，小組成員之間的通信是平行的，如果小組內有是平行的，如果小組內有n個成員，則可能的通信信個成員，則可能的通信信道共有道共有n(n-1)/2條。條。 程序設計小組的人數不能太多程序設計小組的人數不能太多, ,否則組員間彼此否則組員間彼此通信的時間將多

43、于程序設計時間。通信的時間將多于程序設計時間。此外此外,通常不能把一通常不能把一個軟件系統劃分成大量獨立的單元個軟件系統劃分成大量獨立的單元,因此因此,如果程序設如果程序設計小組人數太多計小組人數太多,則每個組員所負責開發的程序單元與則每個組員所負責開發的程序單元與系統其他部分的界面將是復雜的系統其他部分的界面將是復雜的,不僅出現接口錯誤的不僅出現接口錯誤的可能性增加可能性增加,而且軟件測試將既困難又費時間。而且軟件測試將既困難又費時間。10.4.1 10.4.1 民主制程序員組民主制程序員組優點優點: :組員們對發現程序錯誤持積極的態度，這種態度有助于組員們對發現程序錯誤持積極的態度，這種態

44、度有助于更快速地發現錯誤，從而導致高質量的代碼。更快速地發現錯誤，從而導致高質量的代碼。組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。因此，當有難題需要解決時，也厚，有利于攻克技術難關。因此，當有難題需要解決時，也就是說，當所要開發的軟件的技術難度較高時，采用民主制就是說，當所要開發的軟件的技術難度較高時，采用民主制程序員組是適宜的。程序員組是適宜的。缺點：缺點： 由于沒有明確的權威指導開發工程的進行由于沒有明確的權威指導開發工程的進行,組員間將缺組員間將缺乏必要的協調乏必要的協調,最終可能導致工程失敗。最終可能

45、導致工程失敗。 為了使少數經驗豐富、技術高超的程序員在軟件開發過為了使少數經驗豐富、技術高超的程序員在軟件開發過程中能夠發揮更大作用，程序設計小組也可以采用下一小節程中能夠發揮更大作用，程序設計小組也可以采用下一小節中介紹的另外一種組織形式。中介紹的另外一種組織形式。美國美國IBM公司在公司在20世紀世紀70年代初期開始采用主程年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于序員組的組織方式。采用這種組織方式主要出于下述幾點考慮：下述幾點考慮： (1) 軟件開發人員多數比較缺乏經驗；軟件開發人員多數比較缺乏經驗；(2) 程序設計過程中有許多事務性的工作，例如程序設計過程中有許多事

46、務性的工作，例如大量信息的存儲和更新；大量信息的存儲和更新；(3) 多渠道通信很費時間，將降低程序員的生產多渠道通信很費時間，將降低程序員的生產率。率。10.4.2 10.4.2 主程序員組主程序員組 主程序員組用經驗多、技術好、能力強的程序員主程序員組用經驗多、技術好、能力強的程序員作為主程序員，同時，利用人和計算機在事務性工作作為主程序員，同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。一兩個人進行。 這種組織方式類似于外科手術小組組織：這種組織方式類似于外科手術小組組織： 主刀大主刀大夫對手術全面負

47、責，并且完成制訂手術方案、開刀等夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工作。此外，必要時手術組還門人員協助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫生或婦產科醫要請其他領域的專家（例如，心臟科醫生或婦產科醫生）協助。生）協助。主程序員組的兩個重要特性：主程序員組的兩個重要特性： （1） 專業化，該組每名成員僅完成他們受過專業訓練的那專業化，該組每名成員僅完成他們受過專業訓練的那些工作。些工作。（2） 層次性，主刀大夫指揮每名組員工作，并對手術全面層

48、次性，主刀大夫指揮每名組員工作，并對手術全面負責。負責。 典型的主程序員組的組織形式如圖典型的主程序員組的組織形式如圖9.5所示。該組由主所示。該組由主程序員、后備程序員、編程秘書以及程序員、后備程序員、編程秘書以及13名程序員組成。在名程序員組成。在必要的時候，該組還有其他領域的專家協助。必要的時候，該組還有其他領域的專家協助。圖圖11.1 主程序員組的結構主程序員組的結構主程序員組核心人員的分工如下所述：主程序員組核心人員的分工如下所述： （1） 主程序員既是成功的管理人員又是經驗豐主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系富、技術好、能力強的高級程序員，

49、負責體系結構設計和關鍵部分（或復雜部分）的詳細設結構設計和關鍵部分（或復雜部分）的詳細設計，并且負責指導其他程序員完成詳細設計和計，并且負責指導其他程序員完成詳細設計和編碼工作。所有接口問題都由主程序員處理。編碼工作。所有接口問題都由主程序員處理。主程序員對每行代碼的質量負責，因此，他還主程序員對每行代碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。要對組內其他成員的工作成果進行復查。 （2） 后備程序員也應該技術熟練而且富于經驗，他協助主后備程序員也應該技術熟練而且富于經驗，他協助主程序員工作并且在必要時（例如，主程序員生病、出差或程序員工作并且在必要時（例如，主程序員生病、出差

50、或“跳槽跳槽”）接替主程序員的工作。因此，后備程序員必須）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優秀，并且對本項目的了解也在各方面都和主程序員一樣優秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。他工作。（3） 編程秘書負責完成與項目有關的全部事務性工作，例編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執行源程如，維護項目資料庫和項目文檔，編譯、

51、鏈接、執行源程序和測試用例。序和測試用例。 主程序員應該是高級程序員和優秀管理者的結合體主程序員應該是高級程序員和優秀管理者的結合體, 承擔主程序員工作需要同時具備這兩方面的才能。其次承擔主程序員工作需要同時具備這兩方面的才能。其次后備程序員更難找。人們期望后備程序員像主程序員一后備程序員更難找。人們期望后備程序員像主程序員一樣優秀，但是，他們必須坐在樣優秀，但是，他們必須坐在“替補席替補席”上，拿著較低上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。第三，級程序員或高級管理人員愿意接受這樣的

52、工作。第三，編程秘書也很難找到。專業的軟件技術人員一般都厭煩編程秘書也很難找到。專業的軟件技術人員一般都厭煩日常的事務性工作，但是，人們卻期望編程秘書整天只日常的事務性工作，但是，人們卻期望編程秘書整天只干這類工作。干這類工作。 我們需要一種更合理、更現實的組織程序員組的方我們需要一種更合理、更現實的組織程序員組的方法，這種方法應該能充分結合民主制程序員組和主程序法，這種方法應該能充分結合民主制程序員組和主程序員組的優點，并且能用于實現更大規模的軟件產品。員組的優點，并且能用于實現更大規模的軟件產品。優點：優點：小組成員都對發現程序錯誤持積極、主動的態小組成員都對發現程序錯誤持積極、主動的態度

53、。但是，使用主程序員組的組織方式時，主程序員度。但是，使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發現行評價的管理員，他參與代碼審查工作就會把所發現的程序錯誤與小組成員的工作業績聯系起來，從而造的程序錯誤與小組成員的工作業績聯系起來，從而造成小組成員出現不愿意發現錯誤的心理。成小組成員出現不愿意發現錯誤的心理。10.4.3 10.4.3 現代程序員組現代程序員組解決方法解決方法:

54、取消主程序員的大部分行政管理工作。取消主程序員的大部分行政管理工作。前面已前面已經指出，很難找到既是高度熟練的程序員又是成功的管經指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發現程序錯誤的心理問題，也使得尋找小組成員不愿意發現程序錯誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實際的主程序員的人選不再那么困難。于是，實際的“主程序主程序員員”應該由兩個人共同擔任：應該由兩個人共同擔任： 一個一個技術負責人技術負責人，負責，負責小組的技術活動；一個小組的技術活動；一個行政負

55、責人行政負責人，負責所有非技術性，負責所有非技術性事務的管理決策。這樣的組織結構如圖事務的管理決策。這樣的組織結構如圖9.6所示。技術所示。技術組長自然要參與全部代碼審查工作，因為他要對代碼的組長自然要參與全部代碼審查工作，因為他要對代碼的各方面質量負責；相反，行政組長不可以參與代碼審查各方面質量負責；相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業績進行評價。行政工作，因為他的職責是對程序員的業績進行評價。行政組長應該在常規調度會議上了解每名組員的技術能力和組長應該在常規調度會議上了解每名組員的技術能力和工作業績。工作業績。圖11.2 現代程序員組的結構 在開始工作之前明確劃

56、分技術組長和行政組長的在開始工作之前明確劃分技術組長和行政組長的管理權限是很重要的。但是，即使已經做了明確分工，管理權限是很重要的。但是，即使已經做了明確分工，有時也會有時也會出現職責不清的矛盾出現職責不清的矛盾。例如，考慮年度休假問。例如，考慮年度休假問題，行政組長有權批準某個程序員休年假的申請，因為題，行政組長有權批準某個程序員休年假的申請，因為這是一個非技術性問題，但是技術組長可能馬上否決了這是一個非技術性問題，但是技術組長可能馬上否決了這個申請，因為已經接近預定的項目結束日期，目前人這個申請，因為已經接近預定的項目結束日期，目前人手非常緊張。手非常緊張。 解決這類問題的辦法是求助于解決

57、這類問題的辦法是求助于更高層的管理人員更高層的管理人員w為行政組長和技術組長都認為是屬于自己職責范圍內的為行政組長和技術組長都認為是屬于自己職責范圍內的事務，制定一個處理方案。事務，制定一個處理方案。圖11.3 大型項目的技術管理組織結構程序員組成員人數不宜過多，當軟件項目規模較大時，應該程序員組成員人數不宜過多，當軟件項目規模較大時，應該把程序員分成若干個小組，采用圖把程序員分成若干個小組，采用圖11.3所示的組織結構所示的組織結構,描繪描繪的是技術管理組織的結構，非技術管理組織的結構與此類似。的是技術管理組織的結構，非技術管理組織的結構與此類似。在項目經理的指導下進行的，程序員向他們的組長

58、匯報工作，在項目經理的指導下進行的，程序員向他們的組長匯報工作，而組長向項目經理匯報工作。而組長向項目經理匯報工作。把民主制程序員組和主程序員組的優點結合起來的另一種方把民主制程序員組和主程序員組的優點結合起來的另一種方法，是法，是在合適的地方采用分散做決定的方法在合適的地方采用分散做決定的方法。這樣做有利于。這樣做有利于形成暢通的通信渠道，以便充分發揮每個程序員的積極性和形成暢通的通信渠道，以便充分發揮每個程序員的積極性和主動性，集思廣益攻克技術難關。主動性，集思廣益攻克技術難關。這種組織方式對于適合采用民主方法的那類問題（例如，研這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目

59、或遇到技術難題需要用集體智慧攻關）非常有效。究性項目或遇到技術難題需要用集體智慧攻關）非常有效。盡管這種組織方式適當地發揚了民主，但是上下級之間的箭盡管這種組織方式適當地發揚了民主，但是上下級之間的箭頭（即管理關系）仍然是向下的，也就是說，是頭（即管理關系）仍然是向下的，也就是說，是在集中指導在集中指導下發揚民主下發揚民主。顯然，如果程序員可以指揮項目經理，則只會。顯然，如果程序員可以指揮項目經理，則只會引起混亂。引起混亂。圖圖13.4 包含分散決策的組織方式包含分散決策的組織方式 任何軟件開發都是迭代過程，也就是說，在設計過程任何軟件開發都是迭代過程，也就是說，在設計過程會發現需求說明書中的

60、問題，在實現過程又會暴露出設計會發現需求說明書中的問題，在實現過程又會暴露出設計中的錯誤，中的錯誤，。此外，隨著時間推移客戶的需求也會或。此外，隨著時間推移客戶的需求也會或多或少發生變化。因此，多或少發生變化。因此，在開發軟件的過程中，變化（或在開發軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。稱為變動）既是必要的，又是不可避免的。但是，變化也但是，變化也很容易失去控制，如果不能適當地控制和管理變化，勢必很容易失去控制，如果不能適當地控制和管理變化，勢必造成混亂并產生許多嚴重的錯誤。造成混亂并產生許多嚴重的錯誤。10.5 10.5 軟件配置管理軟件配置管理 軟件配置管理軟件配置管