1、第第13章章 軟件項目管理軟件項目管理13.1 估算軟件規模估算軟件規模13.2 工作量估算工作量估算13.3 進度計劃進度計劃13.4 人員組織人員組織13.5 質量保證質量保證13.6 軟件配置管理軟件配置管理13.7 能力成熟度模型能力成熟度模型13.8 小結小結習題習題 在經歷了若干個大型軟件工程項目的失敗之后，在經歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認識到軟件項目管理的重要性和特殊性。人們才逐漸認識到軟件項目管理的重要性和特殊性。 事實上，這些項目的失敗并不是由于從事軟事實上，這些項目的失敗并不是由于從事軟件開發工作的軟件工程師無能，正相反，他們之中件開發工作的軟件工程師

2、無能，正相反，他們之中的絕大多數是當時杰出的技術專家。的絕大多數是當時杰出的技術專家。 這些工程項目的失敗主要是因為管理不善。這些工程項目的失敗主要是因為管理不善。 所謂管理就是通過計劃、組織和控制等一系所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定列活動，合理地配置和使用各種資源，以達到既定目標的過程。目標的過程。 軟件項目管理過程從項目計劃活動開始，而制軟件項目管理過程從項目計劃活動開始，而制定計劃的基礎是工作量估算和完成期限估算。定計劃的基礎是工作量估算和完成期限估算。 為了估算項目的工作量和完成期限，首先需要為了估算項目的工作量和完成期限，首先需要估

3、算軟件的規模。估算軟件的規模。 代碼行技術是比較簡單的定量估算軟件規模的代碼行技術是比較簡單的定量估算軟件規模的方法。方法。 這種方法依據以往開發類似產品的經驗和歷這種方法依據以往開發類似產品的經驗和歷史數據，估計實現一個功能所需要的源程序行數。史數據，估計實現一個功能所需要的源程序行數。 把實現每個功能所需要的源程序行數累加起來，把實現每個功能所需要的源程序行數累加起來，就可得到實現整個軟件所需要的源程序行數。就可得到實現整個軟件所需要的源程序行數。13.1 估算軟件規模估算軟件規模 13.1.1 代碼行技術代碼行技術 為了使得對程序規模的估計值更接近實際值，為了使得對程序規模的估計值更接近

4、實際值，可以由多名有經驗的軟件工程師分別做出估計?？梢杂啥嗝薪涷灥能浖こ處煼謩e做出估計。 每個人都估計程序的最小規模每個人都估計程序的最小規模(a)、最大規模、最大規模(b)和最可能的規模和最可能的規模(m)，分別算出這，分別算出這3種規模的平均值種規模的平均值,和之后，再用下式計算程序規模的估計值：和之后，再用下式計算程序規模的估計值： L= 64bma 用代碼行技術估算軟件規模時用代碼行技術估算軟件規模時: 當程序較小時常用的單位是代碼行數當程序較小時常用的單位是代碼行數LOC （Line of Code ），）， 當程序較大時常用的單位是千行代碼數當程序較大時常用的單位是千行代碼數K

5、LOC ( thousands of lines of code ) 。 (1) 代碼行技術的主要優點是代碼行技術的主要優點是: 代碼是所有軟件開發項目都有的代碼是所有軟件開發項目都有的“產品產品”，而，而且很容易計算代碼行數。且很容易計算代碼行數。 (2) 代碼行技術的缺點是：代碼行技術的缺點是： 源程序僅是軟件配置的一個成分，用它的規源程序僅是軟件配置的一個成分，用它的規模代表整個軟件的規模似乎不太合理；模代表整個軟件的規模似乎不太合理； 用不同語言實現同一個軟件所需要的代碼行用不同語言實現同一個軟件所需要的代碼行數并不相同；數并不相同； 這種方法不適用于非過程語言。這種方法不適用于非過程

6、語言。 為了克服代碼行技術的缺點，人們又提出了功為了克服代碼行技術的缺點，人們又提出了功能點技術。能點技術。 功能點技術依據對軟件信息域特性和軟件復雜功能點技術依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。性的評估結果，估算軟件規模。 這種方法用功能點（這種方法用功能點（Function Point, FP）為單）為單位度量軟件規模。位度量軟件規模。13.1.2 功能點技術功能點技術 1. 信息域特性信息域特性 功能點技術定義了信息域的功能點技術定義了信息域的5個特性，分別是個特性，分別是: 輸入項數輸入項數 (Inp)、 輸出項數輸出項數 (Out)、 查詢數查詢數 (Inq)、

7、 主文件數主文件數 (Maf) 外部接口數外部接口數 (Inf)。2. 估算功能點的步驟估算功能點的步驟 用下述用下述3個步驟，可估算出一個軟件的功能點數個步驟，可估算出一個軟件的功能點數（即軟件規模）。（即軟件規模）。（1） 計算未調整的功能點數計算未調整的功能點數UFP 把每個特性把每個特性(即即Inp、Out、Inq、Maf和和Inf)都分都分類為簡單級、平均級或復雜級類為簡單級、平均級或復雜級. 并根據其等級為每個特性分配一個功能點數并根據其等級為每個特性分配一個功能點數 例如例如: 一個簡單級的輸入項分配一個簡單級的輸入項分配3個功能點，個功能點， 一個平均級的輸入項分配一個平均級的

8、輸入項分配4個功能點，個功能點， 而一個復雜級的輸入項分配而一個復雜級的輸入項分配6個功能點。個功能點。 用下式計算未調整的功能點數用下式計算未調整的功能點數UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，其中，ai (1i5)是信息域特性系數，其值由相應是信息域特性系數，其值由相應特性的復雜級別決定，如表特性的復雜級別決定，如表13.1所示。所示。 輸入項數輸入項數 (Inp)、 輸出項數輸出項數 (Out)、 查詢數查詢數 (Inq)、 主文件數主文件數 (Maf) 、 外部接口數外部接口數 (Inf) 。(2) 計算技術復雜性因子計算技術復雜性因子TC

9、F 這一步驟度量這一步驟度量14種技術因素對軟件規模的影響種技術因素對軟件規模的影響程度。程度。 在表在表13.2中列出了全部技術因素中列出了全部技術因素. 為每個因素分配一個從為每個因素分配一個從0（對軟件規模無影響）（對軟件規模無影響）到到5（有很大影響）的值。（有很大影響）的值。 計算技術因素對軟件規模的計算技術因素對軟件規模的綜合影響程度綜合影響程度DI： DI= 141iiF技術復雜性因子技術復雜性因子TCF由下式計算：由下式計算： TCF=0.65+0.01DI 因為因為DI的值在的值在070之間，所以之間，所以TCF的值在的值在0.651.35之間。之間。（3） 計算功能點數計算

10、功能點數FP FP=UFPTCF功能點數功能點數= 未調整的功能點數未調整的功能點數 X 技術復雜性因子技術復雜性因子 功能點數與所用的編程語言無關，看起來功能功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。點技術比代碼行技術更合理一些。 功能點功能點 代碼行代碼行 粗略換算粗略換算 使用由經驗導出的公式來預測軟件開發工作量，使用由經驗導出的公式來預測軟件開發工作量，工作量是軟件規模（千行代碼數工作量是軟件規模（千行代碼數KLOC或功能點數或功能點數FP）的函數，工作量的單位通常是人月（）的函數，工作量的單位通常是人月（pm)。 支持大多數估算模型的經驗數據，都是從有限個

11、支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發環境。型可以適用于所有類型的軟件和開發環境。13.2 工作量估算工作量估算這類模型的總體結構形式如下：這類模型的總體結構形式如下： E=A+B(ev)C其中，其中， A、B和和C是由經驗數據導出的常數，是由經驗數據導出的常數， E是以人月為單位的工作量，是以人月為單位的工作量， ev是估算變量（是估算變量（KLOC或或FP）。）。 下面給出幾個典型的靜態單變量模型。下面給出幾個典型的靜態單變量模型。13.2.1 靜態單變量模型靜態

12、單變量模型1. 面向面向KLOC的估算模型的估算模型(1) Walston_Felix模型模型 E=5.2(KLOC)0.91(2) Bailey_Basili模型模型 E=5.5+0.73(KLOC)1.16(3) Boehm簡單模型簡單模型 E=3.2(KLOC)1.05(4) Doty模型（在模型（在KLOC9時適用）時適用） E=5.288(KLOC)1.0472. 面向面向FP的估算模型的估算模型(1) Albrecht & Gaffney模型模型 E=-13.39+0.0545FP(2) Maston , Barnett和和 Mellichamp模型模型 E=585.7+1

13、5.12FP 從上面列出的模型可以看出，對于相同的從上面列出的模型可以看出，對于相同的KLOC或或FP值，值，用不同模型估算將得出不同的結用不同模型估算將得出不同的結果果。 主要原因是，這些模型多數都是僅根據若干主要原因是，這些模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，應用領域中有限個項目的經驗數據推導出來的，適用范圍有限。適用范圍有限。 因此，必須根據當前項目的特點選擇適用的因此，必須根據當前項目的特點選擇適用的估算模型。估算模型。 動態多變量模型是根據從動態多變量模型是根據從4000多個當代軟件項多個當代軟件項目中收集的生產率數據推導出來的。目中收集的生產率數據推導出

14、來的。 該模型把工作量看作是軟件規模和開發時間這兩該模型把工作量看作是軟件規模和開發時間這兩個變量的函數。個變量的函數。 E = ( LOCB0.333/P )3(1/t)4 其中，其中， E 是以人月為單位的工作量；是以人月為單位的工作量； t 是以月為單位的項目持續時間；是以月為單位的項目持續時間； B 是特殊技術因子，隨對測試、文檔需求而增加是特殊技術因子，隨對測試、文檔需求而增加 P 是生產率參數是生產率參數13.2.2 動態多變量模型動態多變量模型 COCOMO是構造性成本模型（是構造性成本模型（constructive cost model)的英文縮寫。的英文縮寫。 1981年年B

15、oehm在在軟件工程經濟學軟件工程經濟學中首次提中首次提出了出了COCOMO模型，模型， 1997年年Boehm等人提出的等人提出的COCOMO2模型，模型，是原始的是原始的COCOMO模型的修訂版，它反映了十多模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。年來在成本估計方面所積累的經驗。 13.2.3 COCOMO2模型模型 COCOMO2給出了給出了3個層次的軟件開發工作量個層次的軟件開發工作量估算模型估算模型:（1） 應用系統組成模型應用系統組成模型。 主要用于估算構建原型的工作量，在構建原型時主要用于估算構建原型的工作量，在構建原型時大量使用已有的構件。大量使用已有的構件。

16、（2） 早期設計模型早期設計模型。 適用于體系結構設計階段。適用于體系結構設計階段。（3） 后體系結構模型后體系結構模型。 適用于完成體系結構設計之后的軟件開發階段。適用于完成體系結構設計之后的軟件開發階段。 軟件開發工作量可以表示成代碼行數（軟件開發工作量可以表示成代碼行數（KLOC）的非線性函數：的非線性函數： E= 其中，其中， E 是開發工作量（以人月為單位），是開發工作量（以人月為單位）， a 是模型系數，是模型系數，(典型值為典型值為3.0) KLOC 是估計的源代碼行數是估計的源代碼行數 b 是模型指數，是模型指數，( 取值范圍為取值范圍為1.011.26) fi (i=117)

17、 是成本因素。是成本因素。 171iibfKLOCaP310成本因素成本因素 在實現一個技術性項目大目標之前往往必須完在實現一個技術性項目大目標之前往往必須完成數以百計的小任務（也稱為作業）。成數以百計的小任務（也稱為作業）。 這些任務中有一些是處于這些任務中有一些是處于“關鍵路徑關鍵路徑” 之外的，之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；目的完成時間； 其他任務則處于關鍵路徑之中，如果這些其他任務則處于關鍵路徑之中，如果這些“關鍵關鍵任務任務”的進度拖后，則整個項目的完成日期就會拖的進度拖后，則整個項目的完成日期就會拖后，

18、管理人員應該高度關注關鍵任務的進展情況。后，管理人員應該高度關注關鍵任務的進展情況。13.3 進度計劃進度計劃 項目管理者的目標是定義全部項目任務，識項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延進度的情況。能及時發現拖延進度的情況。 為達到上述目標，管理者必須制定一個足夠為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監督項目進度并控制整個項目。詳細的進度表，以便監督項目進度并控制整個項目。 估算出完成給定項目所需的總工作量之后，接估算出完成給定項目所需的總工作量之后，接下來的問題就是：下來

19、的問題就是： 用多長時間才能完成該項目的用多長時間才能完成該項目的開發工作？開發工作？ 對于一個估計工作量為對于一個估計工作量為20人月的項目，可能想人月的項目，可能想出下列幾種進度表：出下列幾種進度表： 1個人用個人用20個月完成該項目；個月完成該項目； 4個人用個人用5個月完成該項目；個月完成該項目； 20個人用個人用1個月完成該項目。個月完成該項目。13.3.1 估算開發時間估算開發時間 但是，這些進度表并不現實，實際上軟件開發但是，這些進度表并不現實，實際上軟件開發時間與從事開發工作的人數之間并不是簡單的反比時間與從事開發工作的人數之間并不是簡單的反比關系。關系。 通常，成本估算模型也

20、同時提供了估算開發時通常，成本估算模型也同時提供了估算開發時間間T的方程。的方程。 與工作量方程不同，各種模型估算開發時間的與工作量方程不同，各種模型估算開發時間的方程很相似方程很相似例如：例如： (1) Walston_Felix模型模型 T=2.5E0.35(2) 原始的原始的COCOMO模型模型 T=2.5E0.38(3) COCOMO2模型模型 T=3.0E0.33+0.2(b-1.01)(4) Putnam模型模型 T=2.4E1/3其中，其中， E是開發工作量（人月），是開發工作量（人月）， T是開發時間（月）。是開發時間（月）。 客戶往往希望縮短軟件開發時間，顯然，為了客戶往往希

21、望縮短軟件開發時間，顯然，為了縮短開發時間應該增加從事開發工作的人數?？s短開發時間應該增加從事開發工作的人數。 但是，經驗告訴我們，隨著開發小組規模擴大，但是，經驗告訴我們，隨著開發小組規模擴大，個人生產率將下降，以致開發時間與從事開發工作個人生產率將下降，以致開發時間與從事開發工作的人數并不成反比關系。的人數并不成反比關系。出現這種現象主要有下述兩個原因：出現這種現象主要有下述兩個原因： (1) 當小組變得更大時，每個人需要用更多時當小組變得更大時，每個人需要用更多時間與組內其他成員討論問題、協調工作，因此增加間與組內其他成員討論問題、協調工作，因此增加了通信開銷。了通信開銷。 (2) 如果

22、在開發過程中增加小組人員，新成員如果在開發過程中增加小組人員，新成員在開始時不僅不是生產力，而且在他們學習期間還在開始時不僅不是生產力，而且在他們學習期間還需要花費小組其他成員的時間。需要花費小組其他成員的時間。Brooks規律規律 綜合上述兩個原因，存在被稱為綜合上述兩個原因，存在被稱為Brooks規律的規律的下述現象：下述現象： 向一個已經延期的項目增加人力，只會使得它向一個已經延期的項目增加人力，只會使得它更加延期。更加延期。 事實上，做任何事情都需要時間，我們不可能事實上，做任何事情都需要時間，我們不可能用用“人力換時間人力換時間”的辦法無限縮短一個軟件的開發的辦法無限縮短一個軟件的開

23、發時間。時間。 Boehm根據經驗指出，軟件項目的開發時間最根據經驗指出，軟件項目的開發時間最多可以減少到正常開發時間的多可以減少到正常開發時間的75%。 如果要求一個軟件系統的開發時間過短，則開如果要求一個軟件系統的開發時間過短，則開發成功的概率幾乎為零。發成功的概率幾乎為零。 Gantt（甘特）圖是歷史悠久、應用廣泛的制（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具定進度計劃的工具. 例子例子: 假設有一座陳舊的矩形木板房需要重新油漆。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分這項工作必須分3步完成：步完成： 1. 首先刮掉舊漆，首先刮掉舊漆，2. 然后刷上新漆，然后刷上新

24、漆，3. 最后清除濺在窗戶上的油漆。最后清除濺在窗戶上的油漆。13.3.2 Gantt圖圖 假設一共分配了假設一共分配了15名工人去完成這項工作，然名工人去完成這項工作，然而工具卻很有限：而工具卻很有限： 5把刮舊漆用的刮板，把刮舊漆用的刮板， 5把刷漆用的刷子，把刷漆用的刷子， 5把清除濺在窗戶上的油漆用的小刮刀。把清除濺在窗戶上的油漆用的小刮刀。 怎樣安排才能使工作進行得更有效呢怎樣安排才能使工作進行得更有效呢? 1. 一種做法是首先刮掉四面墻壁上的舊漆，一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。

25、戶上的油漆。 顯然這是效率最低的做法，因為總共有顯然這是效率最低的做法，因為總共有15名工名工人，然而每種工具卻只有人，然而每種工具卻只有5件，這樣安排工作在任件，這樣安排工作在任何時候都有何時候都有10名工人閑著沒活干。名工人閑著沒活干。2. 采用采用“流水作業法流水作業法”， (1) 首先由首先由5名工人用刮板刮掉第名工人用刮板刮掉第1面墻上的舊漆面墻上的舊漆(這時其余這時其余10名工人休息名工人休息)， (2) 當第當第1面墻刮凈后，另外面墻刮凈后，另外5名工人立即用刷子名工人立即用刷子給這面墻刷新漆給這面墻刷新漆(與此同時拿刮板的與此同時拿刮板的5名工人轉去名工人轉去刮第刮第2面墻上的

26、舊漆面墻上的舊漆)， (3) 一旦刮舊漆的工人轉到第一旦刮舊漆的工人轉到第3面墻而且刷新漆的面墻而且刷新漆的工人轉到第工人轉到第2面墻以后，余下的面墻以后，余下的5名工人立即拿起刮名工人立即拿起刮刀去清除濺在第刀去清除濺在第1面墻窗戶上的油漆，面墻窗戶上的油漆，。 這樣安排每個工人都有活干，因此能夠在較這樣安排每個工人都有活干，因此能夠在較短的時間內完成任務。短的時間內完成任務。 假設木板房的第假設木板房的第2、4兩面墻的長度比第兩面墻的長度比第1、3兩兩面墻的長度長一倍，此外，不同工作需要用的時間面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清長短也不

27、同，刷新漆最費時間，其次是刮舊漆，清理理(即清除濺在窗戶上的油漆即清除濺在窗戶上的油漆)需要的時間最少。需要的時間最少。 表表13.5（見書（見書305頁）列出了估計每道工序需頁）列出了估計每道工序需要用的時間。要用的時間。 圖圖13.1 舊木板房刷漆工程的舊木板房刷漆工程的Gantt圖圖 Gantt圖描繪上述流水作業過程全部工程在圖描繪上述流水作業過程全部工程在22小時小時后結束，如果用前述的第一種做法，則需要后結束，如果用前述的第一種做法，則需要36小時。小時。Gantt圖的主要缺點：圖的主要缺點： (1) 不能確定各項作業彼此間的依賴關系；不能確定各項作業彼此間的依賴關系；(2) 關鍵部

28、分不明確，難于判定哪些部分應當是主關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；攻和主控的對象； 工程網絡是制定進度計劃時另一種常用的圖形工程網絡是制定進度計劃時另一種常用的圖形工具工具. 它克服了上述缺點。它克服了上述缺點。13.3.3 工程網絡工程網絡 在工程網絡中用在工程網絡中用箭頭表示作業箭頭表示作業(例如，刮舊漆，例如，刮舊漆，刷新漆等刷新漆等)，用，用圓圈表示事件圓圈表示事件(一項作業開始或結束一項作業開始或結束)。 事件僅僅是可以明確定義的時間點，它并不事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。消耗時間和資源。 作業通常既消耗資源又需要持續一定時間。作業通常

29、既消耗資源又需要持續一定時間。圖圖13.2 舊木板房刷漆工程的工程網絡舊木板房刷漆工程的工程網絡 圖中表示刮第圖中表示刮第1面墻上舊漆的作業開始于事件面墻上舊漆的作業開始于事件1，結束，結束于事件于事件2。 用開始事件和結束事件的編號標識一個作業，因此用開始事件和結束事件的編號標識一個作業，因此“刮第刮第1面墻上舊漆面墻上舊漆”是作業是作業12。刮舊漆刮舊漆 1-2-3-5-8刷漆刷漆 2-4-6-8-10清理窗戶清理窗戶 4-7-9-10-11虛線箭頭表示虛擬作虛線箭頭表示虛擬作業，表示作業之間的業，表示作業之間的依賴關系依賴關系 圖圖13.2中事件中事件2既是作業既是作業12(刮第刮第1面

30、墻上的舊面墻上的舊漆漆)的結束，又是作業的結束，又是作業23(刮第刮第2面墻上舊漆面墻上舊漆)和作和作業業24(給第給第1面墻刷新漆面墻刷新漆)的開始。的開始。 也就是說，只有第也就是說，只有第1面墻上的舊漆刮完之后，面墻上的舊漆刮完之后，才能開始刮第才能開始刮第2面墻上舊漆和給第面墻上舊漆和給第1面墻刷新漆這兩面墻刷新漆這兩個作業。個作業。 因此，工程網絡顯式地表示了作業之間的依因此，工程網絡顯式地表示了作業之間的依賴關系。賴關系。 畫出類似圖畫出類似圖13.2那樣的工程網絡之后，系統分那樣的工程網絡之后，系統分析員就可以借助它的幫助估算工程進度了。析員就可以借助它的幫助估算工程進度了。 首

31、先，把每個作業估計需要使用的時間寫在表首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。示該項作業的箭頭上方。 其次，為每個事件計算下述兩個統計數字：其次，為每個事件計算下述兩個統計數字： 最早時刻最早時刻EET和和最遲時刻最遲時刻LET。 這兩個數字將分別寫在表示事件的圓圈的右上這兩個數字將分別寫在表示事件的圓圈的右上角和右下角。角和右下角。13.3.4 估算工程進度估算工程進度圖圖13.3 舊木板房刷漆工程的完整的工程網絡舊木板房刷漆工程的完整的工程網絡 事件的事件的最早時刻最早時刻是該事件可以發生的最早時是該事件可以發生的最早時間。間。 通常工程網絡中第一個事件的最早時刻定義

32、通常工程網絡中第一個事件的最早時刻定義為零，不難沿著工程網絡從左至右順序算出每個事為零，不難沿著工程網絡從左至右順序算出每個事件的最早時刻，件的最早時刻， 計算結果標在圖計算結果標在圖13.3的工程網絡中的工程網絡中(每個圓圈內每個圓圈內右上角的數字右上角的數字)。圖圖13.3 舊木板房刷漆工程的完整的工程網絡舊木板房刷漆工程的完整的工程網絡 事件的事件的最遲時刻最遲時刻是在不影響工程竣工時間的前是在不影響工程竣工時間的前提下，該事件最晚可以發生的時刻。提下，該事件最晚可以發生的時刻。 按慣例，最后一個事件按慣例，最后一個事件(工程結束工程結束)的最遲時刻的最遲時刻就是它的最早時刻。就是它的最

33、早時刻。 其他事件的最遲時刻在工程網絡上從右至左按其他事件的最遲時刻在工程網絡上從右至左按逆作業流的方向計算。逆作業流的方向計算。 圖圖13.3中每個圓圈內右下角的數字就是該事件中每個圓圈內右下角的數字就是該事件的最遲時刻。的最遲時刻。圖圖13.3 舊木板房刷漆工程的完整的工程網絡舊木板房刷漆工程的完整的工程網絡 圖圖13.3中有幾個事件的最早時刻和最遲時刻相中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。粗線箭頭表示。 關鍵路徑上的事件關鍵路徑上的事件(關鍵事件關鍵事件)必須準時發生，必須準時發生，組成關

34、鍵路徑的作業組成關鍵路徑的作業(關鍵作業關鍵作業)的實際持續時間不的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。能超過估計的持續時間，否則工程就不能準時結束。13.3.5 關鍵路徑關鍵路徑圖圖13.3 舊木板房刷漆工程的完整的工程網絡舊木板房刷漆工程的完整的工程網絡 工程項目的管理人員應該密切注視關鍵作業的工程項目的管理人員應該密切注視關鍵作業的進展情況，進展情況，1. 如果關鍵事件出現的時間比預計的時間晚，如果關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖后；則會使最終完成項目的時間拖后；2. 如果希望縮短工期，只有往關鍵作業中增加如果希望縮短工期，只有往關鍵作

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

36、始開始-持續時間持續時間13.3.6 機動時間機動時間 對于前述油漆舊木板房的例子，計算得到的對于前述油漆舊木板房的例子，計算得到的非關鍵作業的機動時間列在表非關鍵作業的機動時間列在表13.6中。中。 在工程網絡中每個作業的機動時間寫在代表該在工程網絡中每個作業的機動時間寫在代表該項作業的箭頭下面的括弧里。項作業的箭頭下面的括弧里。圖圖13.4 舊木板房刷漆工程改進的舊木板房刷漆工程改進的Gantt圖之一圖之一 經驗表明，項目組組織得越好，其生產率越高，經驗表明，項目組組織得越好，其生產率越高，而且產品質量也越好。而且產品質量也越好。 一個有高度凝聚力的小組，他們的整體力量大一個有高度凝聚力的

37、小組，他們的整體力量大于個體力量的總和。一旦項目組具有了凝聚力，成于個體力量的總和。一旦項目組具有了凝聚力，成功的可能性就大大增加了。功的可能性就大大增加了。 下面介紹下面介紹3種典型的組織方式。種典型的組織方式。13.4 人員組織人員組織 小組成員完全平等，享有充分民主，通過協商小組成員完全平等，享有充分民主，通過協商做出技術決策。做出技術決策。 因此，小組成員之間的通信是平行的，如果小因此，小組成員之間的通信是平行的，如果小組內有組內有n個成員，則可能的通信信道共有個成員，則可能的通信信道共有n(n-1)/2條。條。 程序設計小組的人數不能太多程序設計小組的人數不能太多,否則組員間彼此否則

38、組員間彼此通信的時間將多于程序設計時間。通信的時間將多于程序設計時間。13.4.1 民主制程序員組民主制程序員組1. 一般說來，程序設計小組的規模應該比較小一般說來，程序設計小組的規模應該比較小,以以28名成員為宜。名成員為宜。2. 如果項目規模很大如果項目規模很大, 則應該使用多個程序設計小則應該使用多個程序設計小組組,每個小組承擔工程項目的一部分任務，在一每個小組承擔工程項目的一部分任務，在一定程度上獨立自主地完成各自的任務。定程度上獨立自主地完成各自的任務。3. 小組規模小小組規模小,不僅可以減少通信問題不僅可以減少通信問題,而且還有其而且還有其他好處。例如他好處。例如, 用民主方式確定

39、的標準更容易被用民主方式確定的標準更容易被大家遵守大家遵守;組員間關系密切組員間關系密切,能夠互相學習等等。能夠互相學習等等。 民主制程序員組雖然名義上有一個組長，但民主制程序員組雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。是他和組內其他成員完成同樣的任務。 在小組中，由全體討論協商決定應該完成的在小組中，由全體討論協商決定應該完成的工作，并且根據每個人的能力和經驗分配適當的任工作，并且根據每個人的能力和經驗分配適當的任務。務。 主要優點是，組員們對發現程序錯誤持積極的主要優點是，組員們對發現程序錯誤持積極的態度，這種態度有助于更快速地發現錯誤，從而導態度，這種態度有助于更快速地

40、發現錯誤，從而導致高質量的代碼。致高質量的代碼。 民主制程序員組的另一個優點是，組員們享民主制程序員組的另一個優點是，組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。厚，有利于攻克技術難關。 因此，當有難題需要解決時，也就是說，當因此，當有難題需要解決時，也就是說，當所要開發的軟件的技術難度較高時，采用民主制程所要開發的軟件的技術難度較高時，采用民主制程序員組是適宜的。序員組是適宜的。 如果組內多數成員是經驗豐富技術熟練的程序如果組內多數成員是經驗豐富技術熟練的程序員員,那么上述非正式的組織方式可能會非常成功。那么上述非正

41、式的組織方式可能會非常成功。 但是但是,如果組內多數成員技術水平不高如果組內多數成員技術水平不高,那么這那么這種非正式的組織方式也有嚴重缺點：種非正式的組織方式也有嚴重缺點： 由于沒有明確的權威指導開發工程的進行由于沒有明確的權威指導開發工程的進行,組組員間將缺乏必要的協調員間將缺乏必要的協調,最終可能導致工程失敗。最終可能導致工程失敗。 美國美國IBM公司在公司在20世紀世紀70年代初期開始采用主年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮：下述幾點考慮： (1) 軟件開發人員多數比較缺乏經驗；軟件開發人員多數比較缺乏

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

43、：這種組織方式類似于外科手術小組的組織： 主刀大夫對手術全面負責，并且完成制訂手術方案、主刀大夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工作。熟練的專門人員協助和配合他的工作。圖圖13.5 主程序員組的結構主程序員組的結構主程序員組核心人員的分工如下所述：主程序員組核心人員的分工如下所述： （1） 主程序員既是成功的管理人員又是經驗豐富、主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或復雜

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

45、病、出差或“跳槽跳槽”）接替主程序員的工作。）接替主程序員的工作。 平時，后備程序員的工作主要是，設計測試方平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。案、分析測試結果及獨立于設計過程的其他工作。（3） 編程秘書負責完成與項目有關的全部事務性編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執行源程序和測試用例。鏈接、執行源程序和測試用例。 主程序員組的組織方式主程序員組的組織方式 在許多方面卻是不切實際的。在許多方面卻是不切實際的。1. 主程序員應該是高級程序員和優秀管理

46、者的結合體。主程序員應該是高級程序員和優秀管理者的結合體。承擔主程序員工作需要同時具備這兩方面的才能，承擔主程序員工作需要同時具備這兩方面的才能，但是，在現實社會中這樣的人才并不多見。但是，在現實社會中這樣的人才并不多見。2. 后備程序員更難找。人們期望后備程序員像主程后備程序員更難找。人們期望后備程序員像主程序員一樣優秀，但是，他們必須坐在序員一樣優秀，但是，他們必須坐在“替補席替補席”上，上，拿著較低的工資。幾乎沒有一個高級程序員或高級拿著較低的工資。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。管理人員愿意接受這樣的工作。3. 編程秘書也很難找到。編程秘書也很難找到。 專業的軟

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

48、 使用主程序員組時，主程序員對每行代碼的質使用主程序員組時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。量負責，因此，他必須參與所有代碼審查工作。 由于主程序員同時又是負責對小組成員進行評由于主程序員同時又是負責對小組成員進行評價的管理員，他價的管理員，他 會把所發現的程序錯誤與小組成會把所發現的程序錯誤與小組成員的工作業績聯系起來，從而造成小組成員出現不員的工作業績聯系起來，從而造成小組成員出現不愿意發現錯誤的心理。愿意發現錯誤的心理。13.4.3 現代程序員組現代程序員組 解決上述問題的方法是，取消主程序員的大部解決上述問題的方法是，取消主程序員的大部分行政管理工作。分

49、行政管理工作。 實際的實際的“主程序員主程序員”應該由兩個人共同擔任：應該由兩個人共同擔任： 一個技術負責人，負責小組的技術活動；一個技術負責人，負責小組的技術活動； 一個行政負責人，負責非技術性事務的管理決策。一個行政負責人，負責非技術性事務的管理決策。 由于程序員組成員人數不宜過多，當軟件項目由于程序員組成員人數不宜過多，當軟件項目規模較大時，應該把程序員分成若干個小組。規模較大時，應該把程序員分成若干個小組。 產品開發作為一個整體是在項目經理的指導下產品開發作為一個整體是在項目經理的指導下進行的，程序員向他們的組長匯報工作，而組長則進行的，程序員向他們的組長匯報工作，而組長則向項目經理匯

50、報工作。向項目經理匯報工作。圖圖13.7 大型項目的技術管理組織結構大型項目的技術管理組織結構 另一種方法，是在合適的地方采用分散做決定另一種方法，是在合適的地方采用分散做決定的方法，如圖的方法，如圖13.8所示。所示。 這樣做有利于形成暢通的通信渠道，充分發揮這樣做有利于形成暢通的通信渠道，充分發揮每個程序員的積極性和主動性，每個程序員的積極性和主動性， 攻克技術難關。攻克技術難關。圖圖13.8 包含分散決策的組織方式包含分散決策的組織方式 軟件質量就是軟件質量就是“軟件與明確地和隱含地定義的需軟件與明確地和隱含地定義的需求相一致的程度求相一致的程度”。 這一定義強調了下述的這一定義強調了下

51、述的3個要點：個要點：（1） 與軟件需求不一致就是質量不高。與軟件需求不一致就是質量不高。（2） 沒有遵守指定的開發標準，肯定會導致軟件質沒有遵守指定的開發標準，肯定會導致軟件質量不高。量不高。（3） 如果軟件不滿足隱含的需求（例如，軟件應該如果軟件不滿足隱含的需求（例如，軟件應該是容易維護的）是容易維護的） ，那么軟件的質量仍然是值得懷疑，那么軟件的質量仍然是值得懷疑的。的。13.5 質量保證質量保證 13.5.1 軟件質量軟件質量圖圖13.9 軟件質量因素與產品活動的關系軟件質量因素與產品活動的關系軟件質量保證（軟件質量保證（software quality assurance,SQA）措

52、施主要有：措施主要有： 基于非執行的測試（復審或評審），基于執基于非執行的測試（復審或評審），基于執行的測試（軟件測試）和程序正確性證明。行的測試（軟件測試）和程序正確性證明。1. 復審復審主要用來保證在編碼之前各階段產生的文檔主要用來保證在編碼之前各階段產生的文檔的質量；的質量；2. 軟件測試軟件測試需要在程序編寫出來之后進行，它是保需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；證軟件質量的最后一道防線；3. 正確性證明正確性證明使用數學方法嚴格驗證程序是否與對使用數學方法嚴格驗證程序是否與對它的說明完全一致。它的說明完全一致。13.5.2 軟件質量保證措施軟件質量保證措施1.

53、 技術復審的必要性技術復審的必要性 正式技術復審的顯著優點是，能夠較早發現軟正式技術復審的顯著優點是，能夠較早發現軟件錯誤，從而可防止錯誤被傳播到軟件過程的后續件錯誤，從而可防止錯誤被傳播到軟件過程的后續階段。階段。 正式技術復審在發現規格說明錯誤和設計錯誤正式技術復審在發現規格說明錯誤和設計錯誤方面的有效性高達方面的有效性高達75%。 由于能夠檢測出并排除掉絕大部分這類錯誤，由于能夠檢測出并排除掉絕大部分這類錯誤，復審可大大降低后續開發和維護階段的成本。復審可大大降低后續開發和維護階段的成本。2.測試測試 測試可以暴露程序中的錯誤，但是，測試只能測試可以暴露程序中的錯誤，但是，測試只能證明程

54、序中有錯誤，并不能證明程序中沒有錯誤。證明程序中有錯誤，并不能證明程序中沒有錯誤。 因此，對于保證軟件可靠性來說，測試是一種因此，對于保證軟件可靠性來說，測試是一種不完善的技術。不完善的技術。3. 程序正確性證明程序正確性證明 一旦研究出實用的正確性證明程序一旦研究出實用的正確性證明程序(即，能自動即，能自動證明其他程序的正確性的程序證明其他程序的正確性的程序)，軟件可靠性將更有，軟件可靠性將更有保證，測試工作量將大大減少。保證，測試工作量將大大減少。 目前已經研究出證明目前已經研究出證明PASCAL和和LISP程序正確程序正確性的程序系統，正在對這些系統進行評價和改進。性的程序系統，正在對這

55、些系統進行評價和改進。 隨著時間推移客戶的需求也會發生變化。隨著時間推移客戶的需求也會發生變化。 在設計過程會發現需求說明書中的問題，在實在設計過程會發現需求說明書中的問題，在實現過程又會暴露出設計中的錯誤，現過程又會暴露出設計中的錯誤，。 因此，在開發軟件的過程中，變化是不可避免因此，在開發軟件的過程中，變化是不可避免的。的。 但是，變化也很容易失去控制，如果不能適當但是，變化也很容易失去控制，如果不能適當地控制和管理變化，勢必造成混亂并產生許多嚴重地控制和管理變化，勢必造成混亂并產生許多嚴重的錯誤。的錯誤。13.6 軟件配置管理軟件配置管理1. 軟件配置項軟件配置項軟件過程的輸出信息可以分

56、為軟件過程的輸出信息可以分為3類：類： 計算機程序（源代碼和可執行程序）；計算機程序（源代碼和可執行程序）； 描述計算機程序的文檔（供技術人員或用戶使描述計算機程序的文檔（供技術人員或用戶使用）；用）； 數據（程序內包含的或在程序外的）。數據（程序內包含的或在程序外的）。 上述這些項組成了在軟件過程中產生的全部信上述這些項組成了在軟件過程中產生的全部信息，我們把它們統稱為軟件配置，而這些項就是軟息，我們把它們統稱為軟件配置，而這些項就是軟件配置項。件配置項。13.6.1 軟件配置軟件配置2. 基線基線 基線是一個軟件配置管理概念?；€是一個軟件配置管理概念。 IEEE把基線定義為：把基線定義為

57、： 已經通過了正式復審的已經通過了正式復審的規格說明或中間產品，它可以作為進一步開發的基規格說明或中間產品，它可以作為進一步開發的基礎，并且只有通過正式的變化控制過程才能改變它。礎，并且只有通過正式的變化控制過程才能改變它。 簡而言之，基線就是通過了正式復審的軟件簡而言之，基線就是通過了正式復審的軟件配置項。配置項。 除了軟件配置項之外，許多軟件工程組織也把除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他本的編輯器、編譯器和其他CASE工具，作為軟件工具，作為軟件配置的一部分配置的一部分“固

58、定固定”下來。下來。 因為當修改軟件配置項時必然要用到這些工因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產生的結果不同，應該具，為防止不同版本的工具產生的結果不同，應該把軟件工具也基線化，并且列入到綜合的配置管理把軟件工具也基線化，并且列入到綜合的配置管理過程之中。過程之中。 軟件配置管理是軟件質量保證的重要一環，它軟件配置管理是軟件質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟件配置的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、審計以及對軟件配置發項和軟件各種版本的標識、審計以及對軟件配置發生的任何變化的報告。生的任何變化的報告。 軟件配

59、置管理主要有軟件配置管理主要有5項任務：項任務： 標識、版本控制、變化控制、配置審計和報告。標識、版本控制、變化控制、配置審計和報告。13.6.2 軟件配置管理過程軟件配置管理過程 配置狀態變化對大型軟件開發項目的成功有重配置狀態變化對大型軟件開發項目的成功有重大影響。大影響。 當大量人員在一起工作時，可能一個人并不知道當大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發人員可能試圖按照相另一個人在做什么。兩名開發人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；互沖突的想法去修改同一個軟件配置項； 軟件工程隊伍可能耗費幾個人月的工作量根據軟件工程隊伍可能耗費幾個人月的工作

60、量根據過時的硬件規格說明開發軟件；過時的硬件規格說明開發軟件； 察覺到所建議的修改有嚴重副作用的人可能還察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。不知道該項修改正在進行。 配置狀態報告通過改善所有相關人員之間的通配置狀態報告通過改善所有相關人員之間的通信，幫助消除這些問題。信，幫助消除這些問題。 美國卡內基梅隆大學軟件工程研究所在美國國美國卡內基梅隆大學軟件工程研究所在美國國防部資助下于防部資助下于20世紀世紀80年代末建立的能力成熟度模年代末建立的能力成熟度模型（型（capability maturity model，CMM)，是用于評，是用于評價軟件機構的軟件過程能力成熟度的