1、第13章 軟件項目管理13.1 估算軟件規模13.2 工作量估算13.3 進度計劃13.4 人員組織13.5 質量保證13.6 軟件配置管理13.7 能力成熟度模型在經歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認識到軟件項目管理的重要性和特殊性。事實上，這些項目的失敗并不是由于從事軟件開發工作的軟件工程師無能，正相反，他們之中的絕大多數是當時杰出的技術專家。這些工程項目的失敗主要是因為管理不善。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。代碼行技術是比較簡單的定量估算軟件規模的方法。這種方法依據以往開發類似產品的經驗和歷史數據，估計實現一

2、個功能所需要的源程序行數。13.1 估算軟件規模 13.1.1 代碼行技術為了使得對程序規模的估計值更接近實際值，可以由多名有經驗的軟件工程師分別做出估計。每個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)，分別算出這3種規模的平均值、和之后，再用下式計算程序規模的估計值：L=(13.1)用代碼行技術估算軟件規模時，當程序較小時常用的單位是代碼行數（LOC），當程序較大時常用的單位是千行代碼數（KLOC）。代碼行技術的優點：代碼是所有軟件開發項目都有的“產品”，而且很容易計算代碼行數。代碼行技術的缺點： 源程序僅是軟件配置的一個成分，用它的規模代表整個軟件的規模似乎不太合理；

3、用不同語言實現同一個軟件所需要的代碼行數并不相同；這種方法不適用于非過程語言。 功能點技術依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。這種方法用功能點（FP）為單位度量軟件規模。1. 信息域特性功能點技術定義了信息域的5個特性，分別是輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)、主文件數(Maf)和外部接口數(Inf)。13.1.2 功能點技術（1） 輸入項數： 用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不同于查詢，后者單獨計數，不計入輸入項數中。（2） 輸出項數： 軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的

4、數據項不單獨計數。（3） 查詢數： 查詢即是一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。（4） 主文件數： 邏輯主文件（即數據的一個邏輯組合，它可能是大型數據庫的一部分或是一個獨立的文件）的數目。（5） 外部接口數： 機器可讀的全部接口（例如，磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另一個系統。2. 估算功能點的步驟（1） 計算未調整的功能點數UFP把產品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復雜級，并根據其等級為每個特性分配一個功能點數（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個復雜

5、級的輸入項分配6個功能點）。然后，用下式計算未調整的功能點數UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系數，其值由相應特性的復雜級別決定 復雜級別特性系數簡單平均復雜輸入系數a1346輸出系數a2457查詢系數a3346文件系數a471015接口系數a55710(2) 計算技術復雜性因子TCF有14種技術因素對軟件規模會產生影響，包括高處理率、性能標準（例如，響應時間）、聯機更新等。用Fi(1i14)代表這些因素。根據軟件的特點，為每個因素分配一個從0（不存在或對軟件規模無影響）到5（有很大影響）的值。F1數據通信F8聯機更新F

6、2分布數據處理F9復雜的計算F3性能標準F10可重用性F4高負荷的硬件F11安裝方便F5高處理率F12操作方便F6聯機數據輸入F13可移植性F7終端用戶效率F14可維護性技術因素 技術因素對軟件規模的綜合影響程度為： DI= DI的值在070之間。技術復雜性因子TCF由下式計算： TCF=0.65+0.01DI TCF的值在0.651.35之間。3） 計算功能點數FP用下式計算功能點數FP： FP=UFPTCF功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。但是，在判斷信息域特性復雜級別和技術因素的影響程度時，存在著相當大的主觀因素。軟件估算模型使用由經驗導出的公式來預測

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

8、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+15.12FP從上面列出的模型可以看出，對于相同的KLOC或FP值，用不同模型估算將得出不同的結果。主要原因是，這些模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，適用范圍有限。因此，必須根據當前項目的特點選擇適用的估算模型，并且根據需要適

9、當地調整（例如，修改模型常數）估算模型。 動態多變量模型也稱為軟件方程式，它是根據從4000多個當代軟件項目中收集的生產率數據推導出來的。該模型把工作量看作是軟件規模和開發時間這兩個變量的函數。 動態多變量估算模型的形式如下： E = (LOCB0.333/P)3(1/t)4 (13.2)其中，E 是以人月或人年為單位的工作量；t 是以月或年為單位的項目持續時間；B 是特殊技術因子，隨著對測試、質量保證、文檔及管理技術的需求的增加而緩慢增加，對于較小程序，B=0.16 ；對于超過70 KLOC的程序，B=0.39;P 是生產率參數，它反映了下述因素對工作量的影響：13.2.2 動態多變量模型

10、總體過程成熟度及管理水平；使用良好的軟件工程實踐的程度；使用的程序設計語言的級別；軟件環境的狀態；軟件項目組的技術及經驗；應用系統的復雜程度。P的典型取值是：開發實時嵌入式軟件時，P的典型值為2,000；開發電信系統和系統軟件時，P=10,000；對于商業應用系統來說，P=28,000。可以從歷史數據導出適用于當前項目的生產率參數值。從（13.2）式可以看出： 開發同一個軟件（即LOC固定）的時候，如果把項目持續時間延長一些，則可降低完成項目所需的工作量。COCOMO是構造性成本模型（constructive cost model)的英文縮寫。1981年Boehm在軟件工程經濟學中首次提出了C

11、OCOMO模型，本書第三版曾對此模型作了介紹。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。13.2.3 COCOMO2模型COCOMO2給出了3個層次的軟件開發工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可以用于同一個項目的不同開發階段。這3個層次的估算模型分別是： （1） 應用系統組成模型。這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。（2） 早期設計模型。這個模型適用于體系結構設計階段。（3） 后體

12、系結構模型。這個模型適用于完成體系結構設計之后的軟件開發階段。下面以后體系結構模型為例，介紹COCOMO2模型。該模型把軟件開發工作量表示成代碼行數（KLOC）的非線性函數： E=(13.3)其中，E是開發工作量（以人月為單位），a是模型系數，KLOC是估計的源代碼行數（以千行為單位），b是模型指數，fi(i=117)是成本因素。每個成本因素都根據它的重要程度和對工作量影響大小被賦予一定數值（稱為工作量系數）。這些成本因素對任何一個項目的開發工作量都有影響，即使不使用COCOMO2模型估算工作量，也應該重視這些因素。Boehm把成本因素劃分成產品因素、平臺因素、人員因素和項目因素等4類。表13

13、.3列出了COCOMO2模型使用的成本因素及與之相聯系的工作量系數。甚低低正常高甚高特高產品因素要求的可靠性0.750.881.001.151.39數據庫規模0.931.001.091.19產品復雜度要求的可重用性需要的文檔量平臺因素執行時間約束1.001.111.311.67主存約束平臺變動人員因素分析員能力1.501.221.000.830.67程序員能力應用領域經驗1.221.101.000.890.81平臺經驗語言和工具經驗人員連續性項目因素使用軟件工具多地點開發1.251.101.000.920.840.78要求的開發進度與原始的COCOMO模型相比，COCOMO2模型使用的成本因素

14、有下述變化，這些變化反映了在過去十幾年中軟件行業取得的巨大進步。 （1） 新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續性（即人員穩定程度）和多地點開發。這個變化表明，這些因素對開發成本的影響日益增加。（2） 略去了原始模型中的2個成本因素（計算機切換時間和使用現代程序設計實踐）?，F在，開發人員普遍使用工作站開發軟件，批處理的切換時間已經不再是問題。而“現代程序設計實踐”已經發展成內容更廣泛的“成熟的軟件工程實踐”的概念，并且在COCOMO2工作量方程的指數b中考慮了這個因素的影響。（3） 某些成本因素（分析員能力、平臺經驗、語言和工具經驗）對生產率的影響（即工作量系數

15、最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。為了確定工作量方程中模型指數b的值，原始的COCOMO模型把軟件開發項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應的b值（分別是1.05，1.12和1.20）。COCOMO2采用了更加精細得多的b分級模型，這個模型使用5個分級因素Wi(1i5),其中每個因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個級別，然后用下式計算b的數值：b=(13.4)因此，b的取值范圍為1.011.26。顯然，這種分級模式比原始COCOMO模型的分級模式更精細、更靈活。COCOMO2使用的5個分級因素如下所述：

16、（1） 項目先例性。這個分級因素指出，對于開發組織來說該項目的新奇程度。諸如開發類似系統的經驗，需要創新體系結構和算法，以及需要并行開發硬件和軟件等因素的影響，都體現在這個分級因素中。（2） 開發靈活性。這個分級因素反映出，為了實現預先確定的外部接口需求及為了及早開發出產品而需要增加的工作量。（3） 風險排除度。這個分級因素反映了重大風險已被消除的比例。在多數情況下，這個比例和指定了重要模塊接口（即選定了體系結構）的比例密切相關。（4） 項目組凝聚力。這個分級因素表明了開發人員相互協作時可能存在的困難。這個因素反映了開發人員在目標和文化背景等方面相一致的程度，以及開發人員組成一個小組工作的經驗

17、。（5） 過程成熟度。這個分級因素反映了按照能力成熟度模型（見13.7節）度量出的項目組織的過程成熟度。在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數b之值的影響。工作量方程中模型系數a的典型值為3.0，在實際工作中應該根據歷史經驗數據確定一個適合本組織當前開發的項目類型的數值。不論從事哪種技術性項目，實際情況都是，在實現一個大目標之前往往必須完成數以百計的小任務（也稱為作業）。這些任務中有一些是處于“關鍵路徑”（見13.3.5節）之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；其他任務則處于關鍵路徑之中，如果這些“關鍵任務”的進度拖后，則整個項目的完成日期就

18、會拖后，管理人員應該高度關注關鍵任務的進展情況。13.3 進度計劃估算出完成給定項目所需的總工作量之后，接下來需要回答的問題就是： 用多長時間才能完成該項目的開發工作？對于一個估計工作量為20人月的項目，可能想出下列幾種進度表：1個人用20個月完成該項目；4個人用5個月完成該項目；20個人用1個月完成該項目。但是，這些進度表并不現實，實際上軟件開發時間與從事開發工作的人數之間并不是簡單的反比關系。13.3.1 估算開發時間通常，成本估算模型也同時提供了估算開發時間T的方程。與工作量方程不同，各種模型估算開發時間的方程很相似，例如： (1) Walston_Felix模型T=2.5E0.35(2

19、) 原始的COCOMO模型T=2.5E0.38(3) COCOMO2模型T=3.0E0.33+0.2(b-1.01)(4) Putnam模型T=2.4E1/3 E是開發工作量（以人月為單位），T是開發時間（以月為單位）。用上列方程計算出的T值，代表正常情況下的開發時間?？蛻敉Ｍs短軟件開發時間，顯然，為了縮短開發時間應該增加從事開發工作的人數。但是，經驗告訴我們，隨著開發小組規模擴大，個人生產率將下降，以致開發時間與從事開發工作的人數并不成反比關系。出現這種現象主要有下述兩個原因： 1、當小組變得更大時，每個人需要用更多時間與組內其他成員討論問題、協調工作，因此增加了通信開銷。2、如果在開

20、發過程中增加小組人員，則最初一段時間內項目組總生產率不僅不會提高反而會下降。這是因為新成員在開始時不僅不是生產力，而且在他們學習期間還需要花費小組其他成員的時間。綜合上述兩個原因，存在被稱為Brooks規律的下述現象： 向一個已經延期的項目增加人力，只會使得它更加延期。下面讓我們研究項目組規模與項目組總生產率的關系。項目組成員之間的通信路徑數，由項目組人數和項目組結構決定。如果項目組共有P名組員，每個組員必須與所有其他組員通信以協調開發活動，則通信路徑數為P(P-1)/2。如果每個組員只需與另外一個組員通信，則通信路徑數為P-1。通信路徑數少于P-1是不合理的，因為那將導致出現與任何人都沒有聯

21、系的組員。因此，通信路徑數大約在PP2/2的范圍內變化。也就是說，在一個層次結構的項目組中，通信路徑數為P，其中12。對于某一個組員來說，他與其他組員通信的路徑數在1（P-1）的范圍內變化。如果不與任何人通信時個人生產率為L，而且每條通信路徑導致生產率減少l，則組員個人平均生產率為Lr=L-l(P-1)r(13.5)其中，r是對通信路徑數的度量，00)。對于一個規模為P的項目組，從（13.5）式導出項目組的總生產率為Ltot=P(L-l(P-1)r)(13.6)對于給定的一組L，l和r的值，總生產率Ltot是項目組規模P的函數。隨著P值增加，Ltot將從0增大到某個最大值，然后再下降。因此，存

22、在一個最佳的項目組規模Popt，這個規模的項目組其總生產率最高。讓我們舉例說明項目組規模與生產率的關系。假設個人最高生產率為500LOC/月（即L=500），每條通信路徑導致生產率下降10%（即l=50)。如果每個組員都必須與組內所有其他組員通信（r=1)，則項目組規模與生產率的關系列在表13.4（見書304頁）中，可見，在這種情況下項目組的最佳規模是5.5人，即Popt=5.5。事實上，做任何事情都需要時間，我們不可能用“人力換時間”的辦法無限縮短一個軟件的開發時間。Boehm根據經驗指出，軟件項目的開發時間最多可以減少到正常開發時間的75%。如果要求一個軟件系統的開發時間過短，則開發成功的

23、概率幾乎為零。Gantt（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工具。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成： 首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限： 只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?13.3.2 Gantt圖一種做法是：首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這

24、樣安排工作在任何時候都有10名工人閑著沒活干。另一種做法：“流水作業法”： 首先由5名工人用刮板刮掉第1面墻上的舊漆(這時其余10名工人休息)，當第1面墻刮凈后，另外5名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉去刮第2面墻上的舊漆)，一旦刮舊漆的工人轉到第3面墻而且刷新漆的工人轉到第2面墻以后，余下的5名工人立即拿起刮刀去清除濺在第1面墻窗戶上的油漆，。 這樣安排每個工人都有活干，因此能夠在較短的時間內完成任務。假設木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍.此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時

25、間最少。 工序墻壁刮舊漆刷新漆清理1面、3面2312面、4面4621234可以使用Gantt圖描繪上述流水作業過程： 在時間為零時開始刮第1面墻上的舊漆，兩小時后刮舊漆的工人轉去刮第2面墻，同時另5名工人開始給第1面墻刷新漆，每當給一面墻刷完新漆之后，第3組的5名工人立即清除濺在這面墻窗戶上的漆。從圖13.1可以看出12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結束。因此全部工程在22小時后結束，如果用前述的第一種做法，則需要36小時。圖13.1 舊木板房刷漆工程的Gantt圖11223344上一小節介紹的Gantt圖能很形象地描繪任務分解情況，以及每個子任務(

26、作業)的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優點，但是Gantt圖也有3個主要缺點： (1) 不能顯式地描繪各項作業彼此間的依賴關系；(2) 進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；(3) 計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。13.3.3 工程網絡當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節省資源又保證進度的計劃，而且還容易發生差錯。工程網絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況

27、以及每項作業的開始時間和結束時間，此外，它還顯式地描繪各個作業彼此間的依賴關系。因此，工程網絡是系統分析和系統設計的強有力的工具。在工程網絡中用箭頭表示作業(例如，刮舊漆，刷新漆，清理等)，用圓圈表示事件(一項作業開始或結束)。注意：事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業通常既消耗資源又需要持續一定時間。圖13.2是舊木板房刷漆工程的工程網絡。圖中表示刮第1面墻上舊漆的作業開始于事件1，結束于事件2。用開始事件和結束事件的編號標識一個作業，因此“刮第1面墻上舊漆”是作業12。12 刮第1面墻上的舊漆 23 刮第2面墻上的舊漆24 給第1面墻刷新漆 35 刮第3面墻上的舊漆4

28、6 給第2面墻刷新漆 47 清理第1面墻窗戶34 虛擬作業，不消耗資源和時間，表示依賴關系畫出類似圖13.2那樣的工程網絡之后，系統分析員就可以借助它的幫助估算工程進度了。為此需要在工程網絡上增加一些必要的信息。首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒有關系，箭頭僅表示依賴關系，它上方的數字才表示作業的持續時間。13.3.4 估算工程進度其次，為每個事件計算下述兩個統計數字： 最早時刻EET和最遲時刻LET。這兩個數字將分別寫在表示事件的圓圈的右上角和右下角，如圖13.3左下角的符號所示。圖13.3 舊木板房刷漆工程的完整的工程網絡事

29、件的最早時刻EET，是該事件可以發生的最早時間。通常工程網絡中第一個事件的最早時刻定義為零。計算最早時刻EET使用下述3條簡單規則：(1) 考慮進入該事件的所有作業；(2) 對于每個作業都計算它的持續時間與起始事件的EET之和；(3) 選取上述和數中的最大值作為該事件的最早時刻EET。例如：事件4有兩個作業進入（2-4和虛擬作業3-4）。只有這兩個作業都完成后，事件4才能出現（事件4代表上述兩個作業的結束）。 事件2的EET=2，作業2-4的持續時間為3； 事件3的EET=6，作業3-4的持續時間為0。 則事件4的EET= max 2+3, 6+0 = 6按照這種方法，沿著工程網絡從左至右順序

30、算出每個事件的最早時刻，標在工程網絡中(每個圓圈內右上角的數字)。事件的最遲時刻LET是在不影響工程竣工時間的前提下，該事件最晚可以發生的時刻。標在每個圓圈內右下角。按慣例，最后一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網絡上從右至左按逆作業流的方向計算。計算最遲時刻LET使用下述3條規則： (1) 考慮離開該事件的所有作業；(2) 從每個作業的結束事件的最遲時刻中減去該作業的持續時間；(3) 選取上述差數中的最小值作為該事件的最遲時刻LET。例如：從事件9開始的作業只有一個：作業9-10，其持續時間為1，結束事件（事件10）的LET為21。 則事件9的LET=

31、21 -1 = 20 事件8的LET = min 21-6，20-0 = 15 按照這種方法，沿著工程網絡從右至左順序算出每個事件的LET，標在工程網絡中(每個圓圈內右下角的數字)。圖13.3中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑。關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的作業(關鍵作業)的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。工程項目的管理人員應該密切注視關鍵作業的進展情況，如果關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業中增加資源才會有效果。13.3.5 關鍵路徑不在關鍵路徑上的作

32、業有一定程度的機動余地： .實際開始時間可以比預定時間晚一些.實際持續時間可以比預定的持續時間長一些而并不影響工程的結束時間。一個作業可以有的全部機動時間是： 機動時間=(LET)結束-(EET)開始-持續時間13.3.6 機動時間在制定進度計劃時仔細考慮和利用工程網絡中的機動時間，往往能夠安排出既節省資源又不影響最終竣工時間的進度表。圖13.4的Gantt圖描繪了其中的一種方案。圖13.4 舊木板房刷漆工程改進的Gantt圖之一（可以僅用10名工人，用同樣的時間完成任務） 這個簡單例子明顯說明了工程網絡比Gantt圖優越的地方： 工程網絡顯式地定義事件及作業之間的依賴關系，Gantt圖只能隱

33、含地表示這種關系。 但是Gantt圖的形式比工程網絡更簡單更直觀，為更多的人所熟悉。 因此，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。下面介紹3種典型的組織方式。13.4 人員組織民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協商做出技術決策。因此，小組成員之間的通信是平行的，如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。程序設計小組的人數不能太多,否則組員間彼此通信的時間將多于程序設計時間。此外,通常不能把一個軟件系統劃分成大量獨立的單元,因此,如果程序設計小組人數太多,則每個組員所負責開發的程序單元與系統其他部分的界面將是復雜的

34、,不僅出現接口錯誤的可能性增加,而且軟件測試將既困難又費時間。13.4.1 民主制程序員組一般說來，程序設計小組的規模應該比較小,以28名成員為宜。如果項目規模很大,用一個小組不能在預定時間內完成開發任務,則應該使用多個程序設計小組,每個小組承擔工程項目的一部分任務，在一定程度上獨立自主地完成各自的任務。系統的總體設計應該能夠保證由各個小組負責開發的各部分之間的接口是良好定義的,并且是盡可能簡單的。民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。在這樣的小組中，由全體討論協商決定應該完成的工作，并且根據每個人的能力和經驗分配適當的任務

35、。民主制程序員組的主要優點：1、組員們對發現程序錯誤持積極的態度，這種態度有助于更快速地發現錯誤，從而導致高質量的代碼。2、組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。因此，當有難題需要解決時，也就是說，當所要開發的軟件的技術難度較高時，采用民主制程序員組是適宜的。美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮： (1) 軟件開發人員多數比較缺乏經驗；(2) 程序設計過程中有許多事務性的工作，例如，大量信息的存儲和更新；(3) 多渠道通信很費時間，將降低程序員的生產率。13.4.2 主程序員組主程序員組用經

36、驗多、技術好、能力強的程序員作為主程序員，同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。這種組織方式類似于外科手術小組的組織： 主刀大夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫生或婦產科醫生）協助。主程序員組的兩個重要特性： （1） 專業化。該組每名成員僅完成他們受過專業訓練的那些工作。（2） 層次性。主刀大夫指揮每名組員工作，并對手術全面負責。當時，典型的主程序員組的組織形式如圖13.5所示。該組由主程序員、后備程序員

37、、編程秘書以及13名程序員組成。在必要的時候，該組還有其他領域的專家協助。圖13.5 主程序員組的結構主程序員組核心人員的分工如下所述： （1） 主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或復雜部分）的詳細設計，并且負責指導其他程序員完成詳細設計和編碼工作。如圖13.5所示，程序員之間沒有通信渠道，所有接口問題都由主程序員處理。主程序員對每行代碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。（2） 后備程序員也應該技術熟練而且富于經驗，他協助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，

38、后備程序員必須在各方面都和主程序員一樣優秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。（3） 編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執行源程序和測試用例。注意，上面介紹的是20世紀70年代初期的主程序員組組織結構，現在的情況已經和當時大不相同了，程序員已經有了自己的終端或工作站，他們自己完成代碼的輸入、編輯、編譯、鏈接和測試等工作，無須由編程秘書統一做這些工作。典型的主程序員組的現代形式將在下一小節介紹。雖然圖13.5所示的主程序員組的組織方式說起來有不少優點

39、，但是，它在許多方面卻是不切實際的。首先，如前所述，主程序員應該是高級程序員和優秀管理者的結合體。承擔主程序員工作需要同時具備這兩方面的才能，但是，在現實社會中這樣的人才并不多見。通常，既缺乏成功的管理者也缺乏技術熟練的程序員。其次，后備程序員更難找。人們期望后備程序員像主程序員一樣優秀，但是，他們必須坐在“替補席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。第三，編程秘書也很難找到。專業的軟件技術人員一般都厭煩日常的事務性工作，但是，人們卻期望編程秘書整天只干這類工作。我們需要一種更合理、更現實的組織程序員組的方法，這種方法應該能充分

40、結合民主制程序員組和主程序員組的優點，并且能用于實現更大規模的軟件產品。 使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發現的程序錯誤與小組成員的工作業績聯系起來，從而使得小組成員不愿意發現錯誤。13.4.3 現代程序員組解決上述問題的方法是，取消主程序員的大部分行政管理工作。前面已經指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發現程序錯誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實際的“主程序

41、員”應該由兩個人共同擔任： 一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術性事務的管理決策。技術組長自然要參與全部代碼審查工作，因為他要對代碼的各方面質量負責；相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業績進行評價。圖13.6 現代程序員組的結構把民主制程序員組和主程序員組的優點結合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖13.8所示。這樣做有利于形成暢通的通信渠道，以便充分發揮每個程序員的積極性和主動性，集思廣益攻克技術難關。這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目或遇到技術難題需要用集體智慧攻關）非常有效。圖13

42、.8 包含分散決策的組織方式概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度。上述定義強調了下述的3個要點： 13.5 質量保證 13.5.1 軟件質量（1） 軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。（2） 指定的開發標準定義了一組指導軟件開發的準則，如果沒有遵守這些準則，幾乎肯定會導致軟件質量不高。（3） 通常，有一組沒有顯式描述的隱含需求（例如，軟件應該是容易維護的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求

43、，那么軟件的質量仍然是值得懷疑的。 影響軟件質量的主要因素，是從管理角度對軟件質量的度量?？梢园堰@些質量因素分成3組，分別反映用戶在使用軟件產品時的3種不同傾向或觀點： 產品運行產品修改產品轉移圖13.9 軟件質量因素與產品活動的關系軟件質量保證（software quality assurance,SQA）的措施主要有： 基于非執行的測試（也稱為復審或評審）基于執行的測試（即以前講過的軟件測試）程序正確性證明復審主要用來保證在編碼之前各階段產生的文檔的質量；基于執行的測試需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；程序正確性證明使用數學方法嚴格驗證程序是否與對它的說明完全一致

44、。13.5.2 軟件質量保證措施任何軟件開發都是迭代過程，也就是說，在設計過程會發現需求說明書中的問題，在實現過程又會暴露出設計中的錯誤，。此外，隨著時間推移客戶的需求也會或多或少發生變化。因此，在開發軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當地控制和管理變化，勢必造成混亂并產生許多嚴重的錯誤。13.6 軟件配置管理 軟件配置管理是在軟件的整個生命期內管理變化的一組活動。具體地說，這組活動用來： 標識變化； 控制變化； 確保適當地實現了變化； 向需要知道這類信息的人報告變化。 配置管理是在軟件項目啟動時就開始，并且一直持續到軟件退役后才

45、終止的一組跟蹤和控制活動。 軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量?！败浖渲谩笔侵傅囊韵逻@些“軟件配置項”: 程序（源代碼和可執行程序）； 描述程序的文檔（供技術人員或用戶使用）； 數據（程序內包含的或在程序外的）。 13.6.1 軟件配置軟件配置管理是軟件質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發生的任何變化的報告。具體來說，軟件配置管理主要有5項任務： 標識版本控制變化控制配置審計報告13.6.2 軟件配置管理過程1. 標識軟件配置中的對象為了控制和管理軟件配置項，必須

46、單獨命名每個配置項，然后用面向對象方法組織它們?？梢詷俗R出兩類對象： 基本對象和聚集對象（可以把聚集對象作為代表軟件配置完整版本的一種機制）?；緦ο笫擒浖こ處熢诜治?、設計、編碼或測試過程中創建出來的“文本單元”，例如，需求規格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。每個對象都有一組能惟一地標識它的特征： 名字、描述、資源表和“實現”。其中，對象名是無二義性地標識該對象的一個字符串。在設計標識軟件對象的模式時，必須認識到對象在整個生命周期中一直都在演化，因此，所設計的標識模式必須能無歧義地標識每個對象的不同版本。2. 版本控制版本控制聯合使

47、用規程和工具，以管理在軟件工程過程中所創建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當的版本來指定軟件系統的配置。實現這個目標的方法是，把屬性和軟件的每個版本關聯起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。上面提到的“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復雜到是一個布爾變量串，其指明了施加到系統上的功能變化的具體類型。3. 變化控制對于大型軟件開發項目來說，無控制的變化將迅速導致混亂。變化控制把人的規程和自動工具結合起來，以提供一個控制變化的機制。典型的變化控制過程如下： 接到變化請求之后，首先評估該變化在技術方面的得失、可能產生的副作

48、用、對其他配置對象和系統功能的整體影響以及估算出的修改成本。評估的結果形成“變化報告”，該報告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個人也可以由一組人組成，其對變化的狀態和優先級做最終決策。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現的變化，必須遵守的約束以及復審和審計的標準。把要修改的對象從項目數據庫中“提?。╟heck out）”出來，進行修改并應用適當的SQA活動。最后，把修改后的對象“提交（check in）”進數據庫，并用適當的版本控制機制創建該軟件的下一個版本?！疤峤弧焙汀疤崛　边^程實現了變化控制的兩個主要功能訪問控制和同步控制。訪問控制決定哪個軟件

49、工程師有權訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。4. 配置審計軟件配置審計通過評估配置對象的那些通常不在復審過程中考慮的特征（例如，修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當地更新了所有相關的軟件配置項，是否遵循了標注變化、記錄變化和報告變化的規程），而成為對正式技術復審的補充。5. 狀態報告書寫配置狀態報告是軟件配置管理的一項任務，它回答下述問題： 發生了什么事？ 誰做的這件事？這件事是什么時候發生的？它將影響哪些其他事物？配置狀態變化對大型軟件開發項目的成功有重大影響

50、。當大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據過時的硬件規格說明開發軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態報告通過改善所有相關人員之間的通信，幫助消除這些問題。文檔標準化：1、文檔標準：文檔的結構和表達方式（結構、標識、書寫等）2、文檔過程標準： 生成和更改文檔應當遵循的過程。3、文檔轉換標準：確保文檔的所有電子拷貝都相容。美國卡內基梅隆大學軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capability m

51、aturity model，CMM)，是用于評價軟件機構的軟件過程能力成熟度的模型。最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據，發展到后來，此模型又同時被應用于許多軟件機構內部的過程改進活動中。13.7 能力成熟度模型能力成熟度模型的基本思想是，由于問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術的運用并不會自動提高軟件的生產率和質量。能力成熟度模型有助于軟件開發機構建立一個有規律的、成熟的軟件過程。改進后的軟件過程將開發出質量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。軟件過程包括各種活動、技術和工具，因此，它實際上既包括了軟件開發的

52、技術方面又包括了管理方面。CMM的策略是，力圖改進對軟件過程的管理，而在技術方面的改進是其必然的結果。不成熟的軟件組織成熟的軟件組織軟件過程臨時拼湊，不能貫徹有統一標準，且切實可行，并不斷改進；通過培訓，全員理解，各司其職，紀律嚴明管理方式反應式（消防式）主動式，監控產品質量和顧客滿意程度進度、經費的估計無實際根據。 硬性限定時，常在質量上讓步有歷史數據和客觀依據，比較準確質量管理問題判斷無基礎，難預測； 進度滯后時，常減少或取消評審、測試等保證質量的活動產品質量有保證，軟件過程有紀律，有必要的支持性基礎設施CMM通過定義能力成熟度的5個等級，引導軟件開發機構不斷識別出其軟件過程的缺陷，并指出應該做哪些改進，但是，它并不提供做這些改進的具體措施。能力成熟度的5個等級從低到高依次是： 初始級（又稱為1級）可重復級（又稱為2級）已定義級（又稱為3級）已管理級（又稱為4級）優化級（又稱為5級）1. 初始級軟件過程的特征是無序的，有時甚至是混亂的。