第13章軟件項目管理13.1估算軟件規模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟度模型13.8小結習題在經歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認識到軟件項目管理的重要性和特殊性。事實上，這些項目的失敗并不是由于從事軟件開發工作的軟件工程師無能，正相反，他們之中的絕大多數是當時杰出的技術專家。這些工程項目的失敗主要是因為管理不善。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。軟件項目管理先于任何技術活動之前開始，并且貫穿于軟件的整個生命周期之中。軟件項目管理過程從一組項目計劃活動開始，而制定計劃的基礎是工作量估算和完成期限估算。為了估算項目的工作量和完成期限，首先需要估算軟件的規模。代碼行技術是比較簡單的定量估算軟件規模的方法。這種方法依據以往開發類似產品的經驗和歷史數據，估計實現一個功能所需要的源程序行數。當有以往開發類似產品的歷史數據可供參考時，用這種方法估計出的數值還是比較準確的。把實現每個功能所需要的源程序行數累加起來，就可得到實現整個軟件所需要的源程序行數。13.1估算軟件規模

13.1.1代碼行技術為了使得對程序規模的估計值更接近實際值，可以由多名有經驗的軟件工程師分別做出估計。每個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)，分別算出這3種規模的平均值,和之后，再用下式計算程序規模的估計值： L= (13.1)用代碼行技術估算軟件規模時，當程序較小時常用的單位是代碼行數（LOC），當程序較大時常用的單位是千行代碼數（KLOC）。代碼行技術的主要優點是，代碼是所有軟件開發項目都有的“產品”，而且很容易計算代碼行數。代碼行技術的缺點是：源程序僅是軟件配置的一個成分，用它的規模代表整個軟件的規模似乎不太合理；用不同語言實現同一個軟件所需要的代碼行數并不相同；這種方法不適用于非過程語言。為了克服代碼行技術的缺點，人們又提出了功能點技術。功能點技術依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。這種方法用功能點（FP）為單位度量軟件規模。1.信息域特性功能點技術定義了信息域的5個特性，分別是輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)、主文件數(Maf)和外部接口數(Inf)。下面講述這5個特性的含義。13.1.2功能點技術（1）輸入項數：用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不同于查詢，后者單獨計數，不計入輸入項數中。（2）輸出項數：軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的數據項不單獨計數。（3）查詢數：查詢即是一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。（4）主文件數：邏輯主文件（即數據的一個邏輯組合，它可能是大型數據庫的一部分或是一個獨立的文件）的數目。（5）外部接口數：機器可讀的全部接口（例如，磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另一個系統。2.估算功能點的步驟用下述3個步驟，可估算出一個軟件的功能點數（即軟件規模）。（1）計算未調整的功能點數UFP首先，把產品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復雜級，并根據其等級為每個特性分配一個功能點數（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個復雜級的輸入項分配6個功能點）。然后，用下式計算未調整的功能點數UFP：UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系數，其值由相應特性的復雜級別決定，如表13.1（見書297頁）所示。(2)計算技術復雜性因子TCF這一步驟度量14種技術因素對軟件規模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯機更新等，在表13.2（見書297頁）中列出了全部技術因素，并用Fi(1≤i≤14)代表這些因素。根據軟件的特點，為每個因素分配一個從0（不存在或對軟件規模無影響）到5（有很大影響）的值。然后，用下式計算技術因素對軟件規模的綜合影響程度DI：

DI=技術復雜性因子TCF由下式計算：TCF=0.65+0.01×DI因為DI的值在0~70之間，所以TCF的值在0.65~1.35之間。（3）計算功能點數FP用下式計算功能點數FP：FP=UFP×TCF功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。但是，在判斷信息域特性復雜級別和技術因素的影響程度時，存在著相當大的主觀因素。軟件估算模型使用由經驗導出的公式來預測軟件開發工作量，工作量是軟件規模（KLOC或FP）的函數，工作量的單位通常是人月（pm)。支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發環境。13.2工作量估算這類模型的總體結構形式如下：E=A+B×(ev)C其中，A、B和C是由經驗數據導出的常數，E是以人月為單位的工作量，ev是估算變量（KLOC或FP）。下面給出幾個典型的靜態單變量模型。1.面向KLOC的估算模型(1)Walston_Felix模型E=5.2×(KLOC)0.91(2)Bailey_Basili模型E=5.5+0.73×(KLOC)1.1613.2.1靜態單變量模型(3)Boehm簡單模型E=3.2×(KLOC)1.05(4)Doty模型（在KLOC>9時適用）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值，用不同模型估算將得出不同的結果。主要原因是，這些模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，適用范圍有限。因此，必須根據當前項目的特點選擇適用的估算模型，并且根據需要適當地調整（例如，修改模型常數）估算模型。動態多變量模型也稱為軟件方程式，它是根據從4000多個當代軟件項目中收集的生產率數據推導出來的。該模型把工作量看作是軟件規模和開發時間這兩個變量的函數。動態多變量估算模型的形式如下：E=(LOC×B0.333/P)3×(1/t)4 (13.2)其中，E是以人月或人年為單位的工作量；t是以月或年為單位的項目持續時間；13.2.2動態多變量模型B是特殊技術因子，它隨著對測試、質量保證、文檔及管理技術的需求的增加而緩慢增加，對于較小的程序（KLOC=5~15），B=0.16,對于超過70KLOC的程序，B=0.39;P是生產率參數，它反映了下述因素對工作量的影響：總體過程成熟度及管理水平；使用良好的軟件工程實踐的程度；使用的程序設計語言的級別；軟件環境的狀態；軟件項目組的技術及經驗；應用系統的復雜程度。開發實時嵌入式軟件時，P的典型值為2000；開發電信系統和系統軟件時，P=10000；對于商業應用系統來說，P=28000。可以從歷史數據導出適用于當前項目的生產率參數值。從（13.2）式可以看出，開發同一個軟件（即LOC固定）的時候，如果把項目持續時間延長一些，則可降低完成項目所需的工作量。COCOMO是構造性成本模型（constructivecostmodel)的英文縮寫。1981年Boehm在《軟件工程經濟學》中首次提出了COCOMO模型，本書第三版曾對此模型作了介紹。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。13.2.3COCOMO2模型COCOMO2給出了3個層次的軟件開發工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節考慮的詳盡程度逐級增加。這些模型既可以用于不同類型的項目，也可以用于同一個項目的不同開發階段。這3個層次的估算模型分別是：（1）應用系統組成模型。這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。（2）早期設計模型。這個模型適用于體系結構設計階段。（3）后體系結構模型。這個模型適用于完成體系結構設計之后的軟件開發階段。下面以后體系結構模型為例，介紹COCOMO2模型。該模型把軟件開發工作量表示成代碼行數（KLOC）的非線性函數：

E=

(13.3)其中，E是開發工作量（以人月為單位），a是模型系數，KLOC是估計的源代碼行數（以千行為單位），b是模型指數，fi(i=1~17)是成本因素。每個成本因素都根據它的重要程度和對工作量影響大小被賦予一定數值（稱為工作量系數）。這些成本因素對任何一個項目的開發工作量都有影響，即使不使用COCOMO2模型估算工作量，也應該重視這些因素。Boehm把成本因素劃分成產品因素、平臺因素、人員因素和項目因素等4類。表13.3（見書300頁）列出了COCOMO2模型使用的成本因素及與之相聯系的工作量系數。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化，這些變化反映了在過去十幾年中軟件行業取得的巨大進步。（1）新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續性（即人員穩定程度）和多地點開發。這個變化表明，這些因素對開發成本的影響日益增加。（2）略去了原始模型中的2個成本因素（計算機切換時間和使用現代程序設計實踐）。現在，開發人員普遍使用工作站開發軟件，批處理的切換時間已經不再是問題。而“現代程序設計實踐”已經發展成內容更廣泛的“成熟的軟件工程實踐”的概念，并且在COCOMO2工作量方程的指數b中考慮了這個因素的影響。（3）某些成本因素（分析員能力、平臺經驗、語言和工具經驗）對生產率的影響（即工作量系數最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。為了確定工作量方程中模型指數b的值，原始的COCOMO模型把軟件開發項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應的b值（分別是1.05，1.12和1.20）。COCOMO2采用了更加精細得多的b分級模型，這個模型使用5個分級因素Wi(1≤i≤5),其中每個因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個級別，然后用下式計算b的數值：b= (13.4)因此，b的取值范圍為1.01~1.26。顯然，這種分級模式比原始COCOMO模型的分級模式更精細、更靈活。COCOMO2使用的5個分級因素如下所述：（1）項目先例性。這個分級因素指出，對于開發組織來說該項目的新奇程度。諸如開發類似系統的經驗，需要創新體系結構和算法，以及需要并行開發硬件和軟件等因素的影響，都體現在這個分級因素中。（2）開發靈活性。這個分級因素反映出，為了實現預先確定的外部接口需求及為了及早開發出產品而需要增加的工作量。（3）風險排除度。這個分級因素反映了重大風險已被消除的比例。在多數情況下，這個比例和指定了重要模塊接口（即選定了體系結構）的比例密切相關。（4）項目組凝聚力。這個分級因素表明了開發人員相互協作時可能存在的困難。這個因素反映了開發人員在目標和文化背景等方面相一致的程度，以及開發人員組成一個小組工作的經驗。（5）過程成熟度。這個分級因素反映了按照能力成熟度模型（見13.7節）度量出的項目組織的過程成熟度。在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數b之值的影響。工作量方程中模型系數a的典型值為3.0，在實際工作中應該根據歷史經驗數據確定一個適合本組織當前開發的項目類型的數值。不論從事哪種技術性項目，實際情況都是，在實現一個大目標之前往往必須完成數以百計的小任務（也稱為作業）。這些任務中有一些是處于“關鍵路徑”（見13.3.5節）之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；其他任務則處于關鍵路徑之中，如果這些“關鍵任務”的進度拖后，則整個項目的完成日期就會拖后，管理人員應該高度關注關鍵任務的進展情況。13.3進度計劃沒有一個普遍適用于所有軟件項目的任務集合，因此，一個有效的軟件過程應該定義一個適用于當前項目的任務集合。一個任務集合包括一組軟件工程工作任務、里程碑和可交付的產品。為一個項目所定義的任務集合，必須包括為獲得高質量的軟件產品而應該完成的所有任務，但是同時又不能讓項目組承擔不必要的工作。項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延進度的情況。為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監督項目進度并控制整個項目。軟件項目的進度安排是這樣一種活動，它通過把工作量分配給特定的軟件工程任務并規定完成各項任務的起止日期，從而將估算出的項目工作量分布于計劃好的項目持續期內。進度計劃將隨著時間的流逝而不斷演化。在項目計劃的早期，首先制定一個宏觀的進度安排表，標識出主要的軟件工程活動和這些活動影響到的產品功能。隨著項目的進展，把宏觀進度表中的每個條目都精化成一個詳細進度表，從而標識出完成一個活動所必須實現的一組特定任務，并安排好了實現這些任務的進度。估算出完成給定項目所需的總工作量之后，接下來需要回答的問題就是：用多長時間才能完成該項目的開發工作？對于一個估計工作量為20人月的項目，可能想出下列幾種進度表：1個人用20個月完成該項目；4個人用5個月完成該項目；20個人用1個月完成該項目。但是，這些進度表并不現實，實際上軟件開發時間與從事開發工作的人數之間并不是簡單的反比關系。13.3.1估算開發時間通常，成本估算模型也同時提供了估算開發時間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是開發時間（以月為單位）。用上列方程計算出的T值，代表正常情況下的開發時間。客戶往往希望縮短軟件開發時間，顯然，為了縮短開發時間應該增加從事開發工作的人數。但是，經驗告訴我們，隨著開發小組規模擴大，個人生產率將下降，以致開發時間與從事開發工作的人數并不成反比關系。出現這種現象主要有下述兩個原因：當小組變得更大時，每個人需要用更多時間與組內其他成員討論問題、協調工作，因此增加了通信開銷。如果在開發過程中增加小組人員，則最初一段時間內項目組總生產率不僅不會提高反而會下降。這是因為新成員在開始時不僅不是生產力，而且在他們學習期間還需要花費小組其他成員的時間。綜合上述兩個原因，存在被稱為Brooks規律的下述現象：向一個已經延期的項目增加人力，只會使得它更加延期。下面讓我們研究項目組規模與項目組總生產率的關系。項目組成員之間的通信路徑數，由項目組人數和項目組結構決定。如果項目組共有P名組員，每個組員必須與所有其他組員通信以協調開發活動，則通信路徑數為P(P-1)/2。如果每個組員只需與另外一個組員通信，則通信路徑數為P-1。通信路徑數少于P-1是不合理的，因為那將導致出現與任何人都沒有聯系的組員。因此，通信路徑數大約在P~P2/2的范圍內變化。也就是說，在一個層次結構的項目組中，通信路徑數為Pα，其中1<α<2。對于某一個組員來說，他與其他組員通信的路徑數在1~（P-1）的范圍內變化。如果不與任何人通信時個人生產率為L，而且每條通信路徑導致生產率減少l，則組員個人平均生產率為Lr=L-l(P-1)r (13.5)其中，r是對通信路徑數的度量，0<r≤1(假設至少有一名組員需要與一個以上的其他組員通信，因此r>0)。對于一個規模為P的項目組，從（13.5）式導出項目組的總生產率為Ltot=P(L-l(P-1)r) (13.6)對于給定的一組L，l和r的值，總生產率Ltot是項目組規模P的函數。隨著P值增加，Ltot將從0增大到某個最大值，然后再下降。因此，存在一個最佳的項目組規模Popt，這個規模的項目組其總生產率最高。讓我們舉例說明項目組規模與生產率的關系。假設個人最高生產率為500LOC/月（即L=500），每條通信路徑導致生產率下降10%（即l=50)。如果每個組員都必須與組內所有其他組員通信（r=1)，則項目組規模與生產率的關系列在表13.4（見書304頁）中，可見，在這種情況下項目組的最佳規模是5.5人，即Popt=5.5。事實上，做任何事情都需要時間，我們不可能用“人力換時間”的辦法無限縮短一個軟件的開發時間。Boehm根據經驗指出，軟件項目的開發時間最多可以減少到正常開發時間的75%。如果要求一個軟件系統的開發時間過短，則開發成功的概率幾乎為零。Gantt（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工具。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?13.3.2Gantt圖一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時候都有10名工人閑著沒活干。讀者可能已經想到，應該采用“流水作業法”，也就是說，首先由5名工人用刮板刮掉第1面墻上的舊漆(這時其余10名工人休息)，當第1面墻刮凈后，另外5名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉去刮第2面墻上的舊漆)，一旦刮舊漆的工人轉到第3面墻而且刷新漆的工人轉到第2面墻以后，余下的5名工人立即拿起刮刀去清除濺在第1面墻窗戶上的油漆，……。這樣安排每個工人都有活干，因此能夠在較短的時間內完成任務。假設木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時間最少。表13.5（見書305頁）列出了估計每道工序需要用的時間。可以使用圖13.1中的Gantt圖描繪上述流水作業過程：在時間為零時開始刮第1面墻上的舊漆，兩小時后刮舊漆的工人轉去刮第2面墻，同時另5名工人開始給第1面墻刷新漆，每當給一面墻刷完新漆之后，第3組的5名工人立即清除濺在這面墻窗戶上的漆。從圖13.1可以看出12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結束。因此全部工程在22小時后結束，如果用前述的第一種做法，則需要36小時。圖13.1舊木板房刷漆工程的Gantt圖上一小節介紹的Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業)的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優點，但是Gantt圖也有3個主要缺點：(1)不能顯式地描繪各項作業彼此間的依賴關系；(2)進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。13.3.3工程網絡當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節省資源又保證進度的計劃，而且還容易發生差錯。工程網絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業的開始時間和結束時間，此外，它還顯式地描繪各個作業彼此間的依賴關系。因此，工程網絡是系統分析和系統設計的強有力的工具。在工程網絡中用箭頭表示作業(例如，刮舊漆，刷新漆，清理等)，用圓圈表示事件(一項作業開始或結束)。注意，事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業通常既消耗資源又需要持續一定時間。圖13.2是舊木板房刷漆工程的工程網絡。圖中表示刮第1面墻上舊漆的作業開始于事件1，結束于事件2。用開始事件和結束事件的編號標識一個作業，因此“刮第1面墻上舊漆”是作業1—2。圖13.2舊木板房刷漆工程的工程網絡在工程網絡中的一個事件，如果既有箭頭進入又有箭頭離開，則它既是某些作業的結束又是另一些作業的開始。例如，圖13.2中事件2既是作業1—2(刮第1面墻上的舊漆)的結束，又是作業2—3(刮第2面墻上舊漆)和作業2—4(給第1面墻刷新漆)的開始。也就是說，只有第1面墻上的舊漆刮完之后，才能開始刮第2面墻上舊漆和給第1面墻刷新漆這兩個作業。因此，工程網絡顯式地表示了作業之間的依賴關系。在圖13.2中還有一些虛線箭頭，它們表示虛擬作業，也就是事實上并不存在的作業。引入虛擬作業是為了顯式地表示作業之間的依賴關系。例如，事件4既是給第1面墻刷新漆結束，又是給第2面墻刷新漆開始(作業4—6)。但是，在開始給第2面墻刷新漆之前，不僅必須已經給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經刮凈(事件3)。也就是說，在事件3和事件4之間有依賴關系，或者說在作業2—3(刮第2面墻上舊漆)和作業4—6(給第2面墻刷新漆)之間有依賴關系，虛擬作業3—4明確地表示了這種依賴關系。注意，虛擬作業既不消耗資源也不需要時間。畫出類似圖13.2那樣的工程網絡之后，系統分析員就可以借助它的幫助估算工程進度了。為此需要在工程網絡上增加一些必要的信息。首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒有關系，箭頭僅表示依賴關系，它上方的數字才表示作業的持續時間。13.3.4估算工程進度其次，為每個事件計算下述兩個統計數字：最早時刻EET和最遲時刻LET。這兩個數字將分別寫在表示事件的圓圈的右上角和右下角，如圖13.3左下角的符號所示。事件的最早時刻是該事件可以發生的最早時間。通常工程網絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網絡上從左至右按事件發生順序計算。計算最早時刻EET使用下述3條簡單規則：圖13.3舊木板房刷漆工程的完整的工程網絡(1)考慮進入該事件的所有作業；(2)對于每個作業都計算它的持續時間與起始事件的EET之和；(3)選取上述和數中的最大值作為該事件的最早時刻EET。按照這種方法，不難沿著工程網絡從左至右順序算出每個事件的最早時刻，計算結果標在圖13.3的工程網絡中(每個圓圈內右上角的數字)。事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發生的時刻。按慣例，最后一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網絡上從右至左按逆作業流的方向計算。計算最遲時刻LET使用下述3條規則：(1)考慮離開該事件的所有作業；(2)從每個作業的結束事件的最遲時刻中減去該作業的持續時間；(3)選取上述差數中的最小值作為該事件的最遲時刻LET。圖13.3中每個圓圈內右下角的數字就是該事件的最遲時刻。圖13.3中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的作業(關鍵作業)的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。工程項目的管理人員應該密切注視關鍵作業的進展情況，如果關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業中增加資源才會有效果。13.3.5關鍵路徑不在關鍵路徑上的作業有一定程度的機動余地——實際開始時間可以比預定時間晚一些，或者實際持續時間可以比預定的持續時間長一些，而并不影響工程的結束時間。一個作業可以有的全部機動時間等于它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業的持續時間：機動時間=(LET)結束-(EET)開始-持續時間對于前述油漆舊木板房的例子，計算得到的非關鍵作業的機動時間列在表13.6（見書308頁）中。13.3.6機動時間在工程網絡中每個作業的機動時間寫在代表該項作業的箭頭下面的括弧里(參看圖13.3)。在制定進度計劃時仔細考慮和利用工程網絡中的機動時間，往往能夠安排出既節省資源又不影響最終竣工時間的進度表。在圖13.4中的Gantt圖描繪了其中的一種方案。圖13.4舊木板房刷漆工程改進的Gantt圖之一這個簡單例子明顯說明了工程網絡比Gantt圖優越的地方：它顯式地定義事件及作業之間的依賴關系，Gantt圖只能隱含地表示這種關系。但是Gantt圖的形式比工程網絡更簡單更直觀，為更多的人所熟悉，因此，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。以上通過舊木板房刷新漆工程的簡單例子，介紹了制訂進度計劃的兩個重要工具和方法。軟件工程項目雖然比這個簡單例子復雜得多，但是計劃和管理的基本方法仍然是自頂向下分解，也就是把項目分解為若干個階段，每個階段再分解成許多更小的任務，每個任務又可進一步分解為若干個步驟等等。這些階段、任務和步驟之間有復雜的依賴關系，因此，工程網絡和Gantt圖同樣是安排進度和管理工程進展情況的強有力的工具。第13.2節中介紹的工作量估計技術可以幫助我們估計每項任務的工作量，根據人力分配情況，可以進一步確定每項任務的持續時間。從這些基本數據出發，根據作業之間的依賴關系，利用工程網絡和Gantt圖可以制定出合理的進度計劃，并且能夠科學地管理軟件開發工程的進展情況。軟件項目成功的關鍵是有高素質的軟件開發人員。然而大多數軟件的規模都很大，單個軟件開發人員無法在給定期限內完成開發工作，因此，必須把多名軟件開發人員合理地組織起來，使他們有效地分工協作共同完成開發工作。13.4人員組織為了成功地完成軟件開發工作，項目組成員必須以一種有意義且有效的方式彼此交互和通信。如何組織項目組是一個重要的管理問題，管理者應該合理地組織項目組，使項目組有較高生產率，能夠按預定的進度計劃完成所承擔的工作。經驗表明，項目組組織得越好，其生產率越高，而且產品質量也越好。除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。一個有高度凝聚力的小組，由一批團結得非常緊密的人組成，他們的整體力量大于個體力量的總和。一旦項目組具有了凝聚力，成功的可能性就大大增加了。現有的軟件項目組的組織方式很多，通常，組織軟件開發人員的方法，取決于所承擔的項目的特點、以往的組織經驗以及管理者的看法和喜好。下面介紹3種典型的組織方式。民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協商做出技術決策。因此，小組成員之間的通信是平行的，如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。程序設計小組的人數不能太多,否則組員間彼此通信的時間將多于程序設計時間。此外,通常不能把一個軟件系統劃分成大量獨立的單元,因此,如果程序設計小組人數太多,則每個組員所負責開發的程序單元與系統其他部分的界面將是復雜的,不僅出現接口錯誤的可能性增加,而且軟件測試將既困難又費時間。13.4.1民主制程序員組一般說來，程序設計小組的規模應該比較小,以2～8名成員為宜。如果項目規模很大,用一個小組不能在預定時間內完成開發任務,則應該使用多個程序設計小組,每個小組承擔工程項目的一部分任務，在一定程度上獨立自主地完成各自的任務。系統的總體設計應該能夠保證由各個小組負責開發的各部分之間的接口是良好定義的,并且是盡可能簡單的。小組規模小,不僅可以減少通信問題,而且還有其他好處。例如,容易確定小組的質量標準,而且用民主方式確定的標準更容易被大家遵守;組員間關系密切,能夠互相學習等等。民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。在這樣的小組中，由全體討論協商決定應該完成的工作，并且根據每個人的能力和經驗分配適當的任務。民主制程序員組的主要優點是，組員們對發現程序錯誤持積極的態度，這種態度有助于更快速地發現錯誤，從而導致高質量的代碼。民主制程序員組的另一個優點是，組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。因此，當有難題需要解決時，也就是說，當所要開發的軟件的技術難度較高時，采用民主制程序員組是適宜的。如果組內多數成員是經驗豐富技術熟練的程序員,那么上述非正式的組織方式可能會非常成功。在這樣的小組內組員享有充分民主,通過協商,在自愿的基礎上作出決定,因此能夠增強團結、提高工作效率。但是,如果組內多數成員技術水平不高,或是缺乏經驗的新手,那么這種非正式的組織方式也有嚴重缺點：由于沒有明確的權威指導開發工程的進行,組員間將缺乏必要的協調,最終可能導致工程失敗。為了使少數經驗豐富、技術高超的程序員在軟件開發過程中能夠發揮更大作用，程序設計小組也可以采用下一小節中介紹的另外一種組織形式。美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮：(1)軟件開發人員多數比較缺乏經驗；(2)程序設計過程中有許多事務性的工作，例如，大量信息的存儲和更新；(3)多渠道通信很費時間，將降低程序員的生產率。13.4.2主程序員組主程序員組用經驗多、技術好、能力強的程序員作為主程序員，同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。這種組織方式類似于外科手術小組的組織：主刀大夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫生或婦產科醫生）協助。上述比喻突出了主程序員組的兩個重要特性：（1）專業化。該組每名成員僅完成他們受過專業訓練的那些工作。（2）層次性。主刀大夫指揮每名組員工作，并對手術全面負責。當時，典型的主程序員組的組織形式如圖13.5所示。該組由主程序員、后備程序員、編程秘書以及1~3名程序員組成。在必要的時候，該組還有其他領域的專家協助。圖13.5主程序員組的結構主程序員組核心人員的分工如下所述：（1）主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或復雜部分）的詳細設計，并且負責指導其他程序員完成詳細設計和編碼工作。如圖13.5所示，程序員之間沒有通信渠道，所有接口問題都由主程序員處理。主程序員對每行代碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。（2）后備程序員也應該技術熟練而且富于經驗，他協助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。（3）編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執行源程序和測試用例。注意，上面介紹的是20世紀70年代初期的主程序員組組織結構，現在的情況已經和當時大不相同了，程序員已經有了自己的終端或工作站，他們自己完成代碼的輸入、編輯、編譯、鏈接和測試等工作，無須由編程秘書統一做這些工作。典型的主程序員組的現代形式將在下一小節介紹。雖然圖13.5所示的主程序員組的組織方式說起來有不少優點，但是，它在許多方面卻是不切實際的。首先，如前所述，主程序員應該是高級程序員和優秀管理者的結合體。承擔主程序員工作需要同時具備這兩方面的才能，但是，在現實社會中這樣的人才并不多見。通常，既缺乏成功的管理者也缺乏技術熟練的程序員。其次，后備程序員更難找。人們期望后備程序員像主程序員一樣優秀，但是，他們必須坐在“替補席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。第三，編程秘書也很難找到。專業的軟件技術人員一般都厭煩日常的事務性工作，但是，人們卻期望編程秘書整天只干這類工作。我們需要一種更合理、更現實的組織程序員組的方法，這種方法應該能充分結合民主制程序員組和主程序員組的優點，并且能用于實現更大規模的軟件產品。民主制程序員組的一個主要優點，是小組成員都對發現程序錯誤持積極、主動的態度。但是，使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發現的程序錯誤與小組成員的工作業績聯系起來，從而造成小組成員出現不愿意發現錯誤的心理。13.4.3現代程序員組解決上述問題的方法是，取消主程序員的大部分行政管理工作。前面已經指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發現程序錯誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實際的“主程序員”應該由兩個人共同擔任：一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術性事務的管理決策。這樣的組織結構如圖13.6所示。技術組長自然要參與全部代碼審查工作，因為他要對代碼的各方面質量負責；相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業績進行評價。行政組長應該在常規調度會議上了解每名組員的技術能力和工作業績。圖13.6現代程序員組的結構在開始工作之前明確劃分技術組長和行政組長的管理權限是很重要的。但是，即使已經做了明確分工，有時也會出現職責不清的矛盾。例如，考慮年度休假問題，行政組長有權批準某個程序員休年假的申請，因為這是一個非技術性問題，但是技術組長可能馬上否決了這個申請，因為已經接近預定的項目結束日期，目前人手非常緊張。解決這類問題的辦法是求助于更高層的管理人員，對行政組長和技術組長都認為是屬于自己職責范圍內的事務，制定一個處理方案。由于程序員組成員人數不宜過多，當軟件項目規模較大時，應該把程序員分成若干個小組，采用圖13.7所示的組織結構。該圖描繪的是技術管理組織結構，非技術管理組織結構與此類似。由圖可以看出，產品開發作為一個整體是在項目經理的指導下進行的，程序員向他們的組長匯報工作，而組長則向項目經理匯報工作。當產品規模更大時，可以適當增加中間管理層次。圖13.7大型項目的技術管理組織結構把民主制程序員組和主程序員組的優點結合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖13.8所示。這樣做有利于形成暢通的通信渠道，以便充分發揮每個程序員的積極性和主動性，集思廣益攻克技術難關。這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目或遇到技術難題需要用集體智慧攻關）非常有效。盡管這種組織方式適當地發揚了民主，但是上下級之間的箭頭（即管理關系）仍然是向下的，也就是說，是在集中指導下發揚民主。顯然，如果程序員可以指揮項目經理，則只會引起混亂。圖13.8包含分散決策的組織方式概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特征相一致的程度。上述定義強調了下述的3個要點：13.5質量保證

13.5.1軟件質量（1）軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。（2）指定的開發標準定義了一組指導軟件開發的準則，如果沒有遵守這些準則，幾乎肯定會導致軟件質量不高。（3）通常，有一組沒有顯式描述的隱含需求（例如，軟件應該是容易維護的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質量仍然是值得懷疑的。雖然軟件質量是難于定量度量的軟件屬性，但是仍然能夠提出許多重要的軟件質量指標(其中絕大多數目前還處于定性度量階段)。本節介紹影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。可以把這些質量因素分成3組，分別反映用戶在使用軟件產品時的3種不同傾向或觀點。這3種傾向是：產品運行、產品修改和產品轉移。圖13.9描繪了軟件質量因素和上述3種傾向(或產品活動)之間的關系，表13.7（見書315頁）列出了軟件質量因素的簡明定義。圖13.9軟件質量因素與產品活動的關系軟件質量保證（softwarequalityassurance,SQA）的措施主要有：基于非執行的測試（也稱為復審或評審），基于執行的測試（即以前講過的軟件測試）和程序正確性證明。復審主要用來保證在編碼之前各階段產生的文檔的質量；基于執行的測試需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；程序正確性證明使用數學方法嚴格驗證程序是否與對它的說明完全一致。13.5.2軟件質量保證措施參加軟件質量保證工作的人員，可以劃分成下述兩類：軟件工程師通過采用先進的技術方法和度量，進行正式的技術復審以及完成計劃周密的軟件測試來保證軟件質量。SQA小組的職責，是輔助軟件工程師以獲得高質量的軟件產品。其從事的軟件質量保證活動主要是：計劃，監督，記錄，分析和報告。簡而言之，SQA小組的作用是，通過確保軟件過程的質量來保證軟件產品的質量。1.技術復審的必要性正式技術復審的顯著優點是，能夠較早發現軟件錯誤，從而可防止錯誤被傳播到軟件過程的后續階段。統計數字表明，在大型軟件產品中檢測出的錯誤，60%~70%屬于規格說明錯誤或設計錯誤，而正式技術復審在發現規格說明錯誤和設計錯誤方面的有效性高達75%。由于能夠檢測出并排除掉絕大部分這類錯誤，復審可大大降低后續開發和維護階段的成本。實際上，正式技術復審是軟件質量保證措施的一種，包括走查（walkthrough)和審查（inspection）等具體方法。走查的步驟比審查少，而且沒有審查正規。2.走查走查組由4~6名成員組成。以走查規格說明的小組為例，成員至少包括一名負責起草規格說明的人，一名負責該規格說明的管理員，一位客戶代表，以及下階段開發組（在本例中是設計組）的一名代表和SQA小組的一名代表。其中SQA小組的代表應該作為走查組的組長。為了能發現重大錯誤，走查組成員最好是經驗豐富的高級技術人員。必須把被走查的材料預先分發給走查組每位成員。走查組成員應該仔細研究材料并列出兩張表：一張表是他不理解的術語，另一張是他認為不正確的術語。走查組組長引導該組成員走查文檔，力求發現盡可能多的錯誤。走查組的任務僅僅是標記出錯誤而不是改正錯誤，改正錯誤的工作應該由該文檔的編寫組完成。走查的時間最長不要超過2小時，這段時間應該用來發現和標記錯誤，而不是改正錯誤。走查主要有下述兩種方式：（1）參與者驅動法。參與者按照事先準備好的列表，提出他們不理解的術語和認為不正確的術語。文檔編寫組的代表必須回答每個質疑，要么承認確實有錯誤，要么對質疑做出解釋。（2）文檔驅動法。文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發現的問題提出質疑。這種方法可能比第一種方法更有效，往往能檢測出更多錯誤。經驗表明，使用文檔驅動法時許多錯誤是由文檔講解者自己發現的。3.審查審查的范圍比走查廣泛得多，它的步驟也比較多。通常，審查過程包括下述5個基本步驟：（1）綜述。由負責編寫文檔的一名成員向審查組綜述該文檔。在綜述會結束時把文檔分發給每位與會者。（2）準備。評審員仔細閱讀文檔。最好列出在審查中發現的錯誤的類型，并按發生頻率把錯誤類型分級，以輔助審查工作。這些列表有助于評審員們把注意力集中到最常發生錯誤的區域。（3）審查。評審組仔細走查整個文檔。和走查一樣，這一步的目的也是發現文檔中的錯誤，而不是改正它們。通常每次審查會不超過90分鐘。審查組組長應該在一天之內寫出一份關于審查的報告。（4）返工。文檔的作者負責解決在審查報告中列出的所有錯誤及問題。（5）跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認為是錯誤的條目）。必須仔細檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該由審查組再對文檔全面地審查一遍。通常，審查組由4人組成。組長既是審查組的管理人員又是技術負責人。審查組必須包括負責當前階段開發工作的項目組代表和負責下一階段開發工作的項目組代表，此外，還應該包括一名SQA小組的代表。審查過程不僅步數比走查多，而且每個步驟都是正規的。審查的正規性體現在：仔細劃分錯誤類型，并把這些信息運用在后續階段的文檔審查中以及未來產品的審查中。審查是檢測軟件錯誤的一種好方法，利用審查可以在軟件過程的早期階段發現并改正錯誤，也就是說，能在修正錯誤的代價變得很昂貴之前就發現并改正錯誤。因此，審查是一種經濟有效的錯誤檢測方法。4.程序正確性證明測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段；但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因此，對于保證軟件可靠性來說，測試是一種不完善的技術，人們自然希望研究出完善的正確性證明技術。一旦研究出實用的正確性證明程序(即，能自動證明其他程序的正確性的程序)，軟件可靠性將更有保證，測試工作量將大大減少。但是，即使有了正確性證明程序，軟件測試也仍然是需要的，因為程序正確性證明只證明程序功能是正確的，并不能證明程序的動態特性是符合要求的，此外，正確性證明過程本身也可能發生錯誤。正確性證明的基本思想是證明程序能完成預定的功能。因此，應該提供對程序功能的嚴格數學說明，然后根據程序代碼證明程序確實能實現它的功能說明。在20世紀60年代初期，人們已經開始研究程序正確性證明的技術，提出了許多不同的技術方法。雖然這些技術方法本身很復雜，但是它們的基本原理卻是相當簡單的。如果在程序的若干個點上，設計者可以提出關于程序變量及它們的關系的斷言，那么在每一點上的斷言都應該永遠是真的。假設在程序的P1,P2,…，Pn等點上的斷言分別是a(1),a(2)，…，a(n)，其中a(1)必須是關于程序輸入的斷言，a(n)必須是關于程序輸出的斷言。為了證明在點Pi和Pi+1之間的程序語句是正確的，必須證明執行這些語句之后將使斷言a(i)變成a(i+1)。如果對程序內所有相鄰點都能完成上述證明過程，則證明了輸入斷言加上程序可以導出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實是可以終止的(不包含死循環)，則上述過程就證明了程序的正確性。人工證明程序正確性，對于評價小程序可能有些價值，但是在證明大型軟件的正確性時，不僅工作量太大，更主要的是在證明的過程中很容易包含錯誤，因此是不實用的。為了實用的目的，必須研究能證明程序正確性的自動系統。目前已經研究出證明PASCAL和LISP程序正確性的程序系統，正在對這些系統進行評價和改進。現在這些系統還只能對較小的程序進行評價，毫無疑問還需要做許多工作，這樣的系統才能實際用于大型程序的正確性證明。任何軟件開發都是迭代過程，也就是說，在設計過程會發現需求說明書中的問題，在實現過程又會暴露出設計中的錯誤，……。此外，隨著時間推移客戶的需求也會或多或少發生變化。因此，在開發軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當地控制和管理變化，勢必造成混亂并產生許多嚴重的錯誤。13.6軟件配置管理軟件配置管理是在軟件的整個生命期內管理變化的一組活動。具體地說，這組活動用來：①標識變化；②控制變化；③確保適當地實現了變化；④向需要知道這類信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發生的，而配置管理是在軟件項目啟動時就開始，并且一直持續到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。1.軟件配置項軟件過程的輸出信息可以分為3類：①計算機程序（源代碼和可執行程序）；②描述計算機程序的文檔（供技術人員或用戶使用）；③數據（程序內包含的或在程序外的）。上述這些項組成了在軟件過程中產生的全部信息，我們把它們統稱為軟件配置，而這些項就是軟件配置項。13.6.1軟件配置隨著軟件開發過程的進展，軟件配置項的數量迅速增加。不幸的是，由于前述的種種原因，軟件配置項的內容隨時都可能發生變化。為了開發出高質量的軟件產品，軟件開發人員不僅要努力保證每個軟件配置項正確，而且必須保證一個軟件的所有配置項是完全一致的。可以把軟件配置管理看作是應用于整個軟件過程的軟件質量保證活動，是專門用于管理變化的軟件質量保證活動。2.基線基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經通過了正式復審的規格說明或中間產品，它可以作為進一步開發的基礎，并且只有通過正式的變化控制過程才能改變它。簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現變化，但是，必須應用特定的、正式的過程（稱為規程）來評估、實現和驗證每個變化。除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他CASE工具，作為軟件配置的一部分“固定”下來。因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產生的結果不同，應該把軟件工具也基線化，并且列入到綜合的配置管理過程之中。軟件配置管理是軟件質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發生的任何變化的報告。具體來說，軟件配置管理主要有5項任務：標識、版本控制、變化控制、配置審計和報告。13.6.2軟件配置管理過程1.標識軟件配置中的對象為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向對象方法組織它們。可以標識出兩類對象：基本對象和聚集對象（可以把聚集對象作為代表軟件配置完整版本的一種機制）。基本對象是軟件工程師在分析、設計、編碼或測試過程中創建出來的“文本單元”，例如，需求規格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。每個對象都有一組能惟一地標識它的特征：名字、描述、資源表和“實現”。其中，對象名是無二義性地標識該對象的一個字符串。在設計標識軟件對象的模式時，必須認識到對象在整個生命周期中一直都在演化，因此，所設計的標識模式必須能無歧義地標識每個對象的不同版本。2.版本控制版本控制聯合使用規程和工具，以管理在軟件工程過程中所創建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當的版本來指定軟件系統的配置。實現這個目標的方法是，把屬性和軟件的每個版本關聯起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。上面提到的“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復雜到是一個布爾變量串，其指明了施加到系統上的功能變化的具體類型。3.變化控制對于大型軟件開發項目來說，無控制的變化將迅速導致混亂。變化控制把人的規程和自動工具結合起來，以提供一個控制變化的機制。典型的變化控制過程如下：接到變化請求之后，首先評估該變化在技術方面的得失、可能產生的副作用、對其他配置對象和系統功能的整體影響以及估算出的修改成本。評估的結果形成“變化報告”，該報告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個人也可以由一組人組成，其對變化的狀態和優先級做最終決策。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現的變化，必須遵守的約束以及復審和審計的標準。把要修改的對象從項目數據庫中“提取（checkout）”出來，進行修改并應用適當的SQA活動。最后，把修改后的對象“提交（checkin）”進數據庫，并用適當的版本控制機制創建該軟件的下一個版本。“提交”和“提取”過程實現了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪個軟件工程師有權訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。在一個軟件配置項變成基線之前，僅需應用非正式的變化控制。該配置對象的開發者可以對它進行任何合理的修改（只要修改不會影響到開發者工作范圍之外的系統需求）。一旦該對象經過了正式技術復審并獲得批準，就創建了一個基線。而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制。現在，為了進行修改開發者必須獲得項目管理者的批準（如果變化是“局部的”），如果變化影響到其他軟件配置項，還必須得到變化控制審批者的批準。在某些情況下，可以省略正式的變化請求、變化報告和工程變化命令，但是，必須評估每個變化并且跟蹤和復審所有變化。4.配置審計為了確保適當地實現了所需要的變化，通常從下述兩方面采取措施：①正式的技術復審；②軟件配置審計。正式的技術復審（見13.5.2節）關注被修改后的配置對象的技術正確性。復審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。軟件配置審計通過評估配置對象的那些通常不在復審過程中考慮的特征（例如，修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當地更新了所有相關的軟件配置項，是否遵循了標注變化、記錄變化和報告變化的規程），而成為對正式技術復審的補充。5.狀態報告書寫配置狀態報告是軟件配置管理的一項任務，它回答下述問題：①發生了什么事？②誰做的這件事？③這件事是什么時候發生的？④它將影響哪些其他事物？配置狀態變化對大型軟件開發項目的成功有重大影響。當大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據過時的硬件規格說明開發軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態報告通過改善所有相關人員之間的通信，幫助消除這些問題。美國卡內基梅隆大學軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capabilitymaturitymodel，CMM)，是用于評價軟件機構的軟件過程能力成熟度的模型。最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據，發展到后來，此模型又同時被應用于許多軟件機構內部的過程改進活動中。13.7能力成熟度模型多年來，軟件危機一直困擾著許多軟件開發機構。不少人試圖通過采用新的軟件開發技術來解決在軟件生產率和軟件質量等方面存在的問題，但效果并不令人十分滿意。上述事實促使人們進一步考察軟件過程，從而發現關鍵問題在于對軟件過程的管理不盡人意。事實證明，在無規則和混亂的管理之下，先進的技術和工具并不能發揮出應有的作用。人們逐漸認識到，改進對軟件過程的管理是消除軟件危機的突破口，再也不能忽視在軟件過程中管理的關鍵作用了。能力成熟度模型的基本思想是，由于問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術的運用并不會自動提高軟件的生產率和質量。能力成熟度模型有助于軟件開發機構建立一個有規律的、成熟的軟件過程。改進后的軟件過程將開發出質量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。軟件過程包括各種活動、技術和工具，因此，它實際上既包括了軟件開發的技術方面又包括了管理方面。CMM的策略是，力圖改進對軟件過程的管理，而在技術方面的改進是其必然的結果。CMM在改進軟件過程中所起的作用主要是，指導軟件機構通過確定當前的過程成熟度并識別出對過程改進起關鍵作用的問題，從而明確過程改進的方向和策略。通過集中開展與過程改進的方向和策略相一致的一組過程改進活動，軟件機構便能穩步而有效地改進其軟件過程，使其軟件過程能力得到循序漸進的提高。對軟件過程的改進，是在完成一個又一個小的改進步驟基礎上不斷進行的漸進過程，而不是一蹴而就的徹底革命。CMM把軟件過程從無序到有序的進化過程分成5個階段，并把這些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個有序的尺度，用以測量軟件機構的軟件過程成熟度和評價其軟件過程能力，這些等級還能幫助軟件機構把應做的改進工作排出優先次序。成熟度等級是妥善定義的向成熟軟件機構前進途中的平臺，每個成熟度等級都為軟件過程的繼續改進提供了一個臺階。CMM對5個成熟度級別特性的描述，說明了不同級別之間軟件過程的主要變化。從“1級”到“5級”，反映出一個軟件機構為了達到從一個無序的、混亂的軟件過程進化到一種有序的、有紀律的且成熟的軟件過程的目的，必須經歷的過程改進活動的途徑。每一個成熟度級別都是該軟件機構沿著改進其過程的途徑前進途中的一個臺階，后一個成熟度級別是前一個級別的軟件過程的進化目標。CMM的每個成熟度級別中都包含一組過程改進的目標，滿足這些目標后一個機構的軟件過程就從當前級別進化到下一個成熟度級別；每達到成熟度級別框架的下一個級別，該機構的軟件過程都得到一定程度的完善和優化，也使得過程能力得到提高；隨著成熟度級別的不斷提高，該機構的過程改進活動取得了更加顯著的成效，從而使軟件過程得到進一步的完善和優化。CMM就是以上述方式支持軟件機構改進其軟件過程的活動。CMM通過定義能力成熟度的5個等級，引導軟件開發機構不斷識別出其軟件過程的缺陷，并指出應該做哪些改進，但是，它并不提供做這些改進的具體措施。能力成熟度的5個等級從低到高依次是：初始級（又稱為1級），可重復級（又稱為2級），已定義級（又稱為3級），已管理級（又稱為4級）和優化級（又稱為5級）。下面介紹這5個級別的特點。1.初始級軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經過定義的（即沒有一個定型的過程模型），項目能否成功完全取決于開發人員的個人能力。處于這個最低成熟度等級的軟件機構，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備，所以具有不可預測性，人員變了過程也隨之改變。如果一個項目碰巧由一個杰出的管理者和一支有經驗、有能力的開發隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由于缺乏健全的管理和周密的計劃，延期交付和費用超支的情況經常發生，結果，大多數行動只是應付危機，而不是完成事先計劃好的任務。總之，處于1級成熟度的軟件機構，其過程能力是不可預測的，其軟件過程是不穩定的，產品質量只能根據相關人員的個人工作能力而不是軟件機構的過程能力來預測。2.可重復級軟件機構建立了基本的項目管理過程(過程模型),可跟蹤成本、進度、功能和質量。已經建立起必要的過程規范，對新項目的策劃和管理過程是基于以前類似項目的實踐經驗，使得有類似應用經驗的軟件項目能夠再次取得成功。達到2級的一個目標是使項目管理過程穩定，從而使得軟件機構能重復以前在成功項目中所進行過的軟件項目工程實踐。處于2級成熟度的軟件機構，針對所承擔的軟件項目已建立了基本的軟件管理控制制度。通過對以前項目的觀察和分析，可以提出針對現行項目的約束條件。項目負責人跟蹤軟件產品開發的成本和進度以及產品的功能和質量，并且識別出為滿足約束條件所應解決的問題。已經做到軟件需求條理化，而且其完整性是受控制的。已經制定了項目標準，并且軟件機構能確保嚴格執行這些標準。項目組與客戶及承包商已經建立起一個穩定的、可管理的工作環境。處于2級成熟度的軟件機構的過程能力可以概括為，軟件項目的策劃和跟蹤是穩定的，已經為一個有紀律的管理過程提供了可重復以前成功實踐的項目環境。軟件項目工程活動處于項目管理體系的有效控制之下，執行著基于以前項目的準則且合乎現實的計劃。3.已定義級軟件機構已經定義了完整的軟件過程（過程模型），軟件過程已經文檔化和標準化。所有項目組都使用文檔化的、經過批準的過程來開發和維護軟件。這一級包含了第2級的全部特征。在第3級成熟度的軟件機構中，有一個固定的過程小組從事軟件過程工程活動。當需要時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，并投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構的過程改進活動。在該軟件機構內實施了培訓計劃，能夠保證全體項目負責人和項目開發人員具有完成承擔的任務所要求的知識和技能。處于3級成熟度的軟件機構的過程能力可以概括為，無論是管理活動還是工程活動都是穩定的。軟件開發的成本和進度以及產品的功能和質量都受到控制，而且軟件產品的質量具有可追溯性。這種能力是基于在軟件機構中對已定義的過程模型的活動、人員和職責都有共同的理解。4.已管理級軟件機構對軟件過程（過程模型和過程實例）和軟件產品都建立了定量的質量目標，所有項目的重要的過程活動都是可度量的。該軟件機構收集了過程度量和產品度量的方法并加以運用，可以定量地了解和控制軟件過程和軟件產品，并為評定項目的過程質量和產品質量奠定了基礎。這一級包含了第3級的全部特征。處于4級成熟度的軟件機構的過程能力可以概括為，軟件過程是可度量的，軟件過程在可度量的范圍內運行。這一級的過程能力允許軟件機構在定量的范圍內預測過程和產品質量趨勢，在發生偏離時可以及時采取措施予以糾正，并且可以預期軟件產品是高質量的。5.優化級軟件機構集中精力持續不斷地改進軟件過程。這一級的軟件機構是一個以防止出現缺陷為目標的機構，它有能力識別軟件過程要素的薄弱環節，并有足夠的手段改進它們。在這樣的機構中，可以獲得關于軟件過程有效性的統計數據，利用這些數據可以對新技術進行成本/效益分析，并可以優化出在軟件工程實踐中能夠采用的最佳新技術。這一級包含了第4級的全部特征。這一級的軟件機構可以通過