(2.10)-13章 軟件項目管理

第13章軟件項目管理軟件工程導論（第6版）第13章軟件項目管理

在經歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認識到軟件項目管理的重要性和特殊性。

所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。

軟件項目管理先于任何技術活動之前開始，并且貫穿于軟件的整個生命周期之中。引言章節(jié)目錄13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟模型主要

內容13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.1估算軟件規(guī)模用代碼行技術估算軟件規(guī)模時，當程序較小時常用的單位是代碼行數(shù)（LOC），當程序較大時常用的單位是千行代碼數(shù)（KLOC）。代碼行技術的主要優(yōu)點是，代碼是所有軟件開發(fā)項目都有的“產品”，而且很容易計算代碼行數(shù)。代碼行技術的缺點是：源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理；用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同；這種方法不適用于非過程語言。13.1.1代碼行技術13.1估算軟件規(guī)模13.1.2功能點技術

依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模。這種方法用功能點（FP）為單位度量軟件規(guī)模。信息域特性功能點技術定義了信息域的5個特性:（1）輸入項數(shù):用戶向軟件輸入的項數(shù)，這些輸入給軟件提供面向應用的數(shù)據(jù)。（2）輸出項數(shù):軟件向用戶輸出的項數(shù)，它們向用戶提供面向應用的信息13.1估算軟件規(guī)模2.估算功能點的步驟（1）計算未調整的功能點數(shù)UFP

首先，把產品信息域的每個特性（即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復雜級，并根據(jù)其等級為每個特性分配一個功能點數(shù)（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個復雜級的輸入項分配6個功能點）。13.1估算軟件規(guī)模

然后，用下式計算未調整的功能點數(shù)UFP：UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系數(shù)，其值由相應特性的復雜級別決定，如右表。13.1估算軟件規(guī)模這一步驟度量14種技術因素對軟件規(guī)模的影響程度（2）計算技術復雜性因子TCF（3）計算功能點數(shù)FPFP=UFP×TCF1、代碼行技術2、功能點技術本節(jié)小結主要

內容13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.2工作量估算

軟件估算模型使用由經驗導出的公式來預測軟件開發(fā)工作量，工作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位通常是人月（pm)。

支持大多數(shù)估算模型的經驗數(shù)據(jù)，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境。13.2工作量估算

其中，A、B和C是由經驗數(shù)據(jù)導出的常數(shù)，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.16(3)Boehm簡單模型E=3.2×(KLOC)1.05(4)Doty模型（在KLOC>9時適用）E=5.288×(KLOC)1.04713.2.1靜態(tài)單變量模型總體結構形式如：E=A+B×(ev)C13.2工作量估算2.面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Maston,Barnett和Mellichamp模型E=585.7+15.12FP13.2.1靜態(tài)單變量模型

這些模型多數(shù)都是僅根據(jù)若干應用領域中有限個項目的經驗數(shù)據(jù)推導出來的，適用范圍有限。因此，必須根據(jù)當前項目的特點選擇適用的估算模型，并且根據(jù)需要適當?shù)卣{整（例如修改模型常數(shù)）估算模型。13.2工作量估算

動態(tài)多變量模型也稱為軟件方程式，它是根據(jù)從4000多個當代軟件項目中收集的生產率數(shù)據(jù)推導出來的。該模型把工作量看作軟件規(guī)模和開發(fā)時間這兩個變量的函數(shù)。動態(tài)多變量估算模型的形式如下：13.2.2動態(tài)多變量模型E=(LOC×B0.333/P)3×(1/t)4其中，E是以人月或人年為單位的工作量；t是以月或年為單位的項目持續(xù)時間；B是特殊技術因子，它隨著對測試、質量保證、文檔及管理技術的需求的增加而緩慢增加，對于較小的程序（KLOC=5~15），B=0.16,對于超過70KLOC的程序，B=0.39;13.2工作量估算13.2.2動態(tài)多變量模型其中，P是生產率參數(shù)，它反映了下述因素對工作量的影響。總體過程成熟度及管理水平。使用良好的軟件工程實踐的程度。使用的程序設計語言的級別。軟件環(huán)境的狀態(tài)。軟件項目組的技術及經驗。應用系統(tǒng)的復雜程度。13.2工作量估算13.2.2動態(tài)多變量模型

開發(fā)實時嵌入式軟件時，P的典型值為2000；開發(fā)電信系統(tǒng)和系統(tǒng)軟件時，P=10000；對于商業(yè)應用系統(tǒng)來說，P=28000?？梢詮臍v史數(shù)據(jù)導出適用于當前項目的生產率參數(shù)值。

從上述公式可以看出，開發(fā)同一個軟件（即LOC固定）的時候，如果把項目持續(xù)時間延長一些，則可降低完成項目所需的工作量。13.2工作量估算13.2.3COCOMO2模型COCOMO2給出了3個層次的軟件開發(fā)工作量估算模型：（1）應用系統(tǒng)組成模型。

這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。COCOMO是構造性成本模型（constructivecostmodel)的英文縮寫。1981年Boehm在《軟件工程經濟學》中首次提出了COCOMO模型。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了10多年來在成本估計方面所積累的經驗。13.2工作量估算13.2.3COCOMO2模型（2）早期設計模型。

這個模型適用于體系結構設計階段。（3）

后體系結構模型。

這個模型適用于完成體系結構設計之后的軟件開發(fā)階段。13.2工作量估算13.2.3COCOMO2模型13.2工作量估算13.2.3COCOMO2模型右表列出了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化，這些變化反映了在過去十幾年中軟件行業(yè)取得的巨大進步。13.2工作量估算13.2.3COCOMO2模型

為了確定工作量方程中模型指數(shù)b的值，原始的COCOMO模型把軟件開發(fā)項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應的b值（分別是1.05，1.12和1.20）。13.2工作量估算13.2.3COCOMO2模型COCOMO2使用的5個分級因素如下所述:

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

在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數(shù)b之值的影響。工作量方程中模型系數(shù)a的典型值為3.0，在實際工作中應該根據(jù)歷史經驗數(shù)據(jù)確定一個適合本組織當前開發(fā)的項目類型的數(shù)值。1、靜態(tài)單變量模型2、動態(tài)多變量模型3、COCOMO2模型本節(jié)小結主要

內容13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.3進度計劃

軟件項目的進度安排是這樣一種活動，它通過把工作量分配給特定的軟件工程任務并規(guī)定完成各項任務的起止日期，從而將估算出的項目工作量分布于計劃好的項目持續(xù)期內。進度計劃將隨著時間的流逝而不斷演化。在項目計劃的早期，首先制定一個宏觀的進度安排表，標識出主要的軟件工程活動和這些活動影響到的產品功能。隨著項目的進展，把宏觀進度表中的每個條目都精化成一個詳細進度表，從而標識出完成一個活動所必須實現(xiàn)的一組特定任務，并安排好實現(xiàn)這些任務的進度。13.3進度計劃

成本估算模型也同時提供了估算開發(fā)時間T的方程。與工作量方程不同，各種模型估算開發(fā)時間的方程很相似，例如：(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是開發(fā)工作量（以人月為單位）；T是開發(fā)時間（以月為單位）。13.3.1估算開發(fā)時間13.3進度計劃

用上列方程計算出的T值，代表正常情況下的開發(fā)時間?？蛻敉Ｍs短軟件開發(fā)時間，顯然，為了縮短開發(fā)時間應該增加從事開發(fā)工作的人數(shù)。

但是，經驗告訴人們，隨著開發(fā)小組規(guī)模的擴大，個人生產率將下降，以致開發(fā)時間與從事開發(fā)工作的人數(shù)并不成反比關系。13.3.1估算開發(fā)時間13.3進度計劃項目組成員之間的通信路徑數(shù)，由項目組人數(shù)和項目組結構決定。如果項目組共有P名組員，每個組員必須與所有其他組員通信以協(xié)調開發(fā)活動，則通信路徑數(shù)為P(P-1)/2。如果每個組員只需與另外一個組員通信，則通信路徑數(shù)為P-1。通信路徑數(shù)少于P-1是不合理的，因為那將導致出現(xiàn)與任何人都沒有聯(lián)系的組員。因此，通信路徑數(shù)大約在P~P2/2的范圍內變化。也就是說，在一個層次結構的項目組中，通信路徑數(shù)為Pα,其中1<α<2。13.3.1估算開發(fā)時間項目組規(guī)模與項目組總生產率的關系13.3進度計劃對于某一個組員來說，他與其他組員通信的路徑數(shù)在1~（P-1）的范圍內變化。如果不與任何人通信時個人生產率為L，而且每條通信路徑導致生產率減少l,則組員個人平均生產率為

Lr=L-l(P-1)r

（13.5）

其中，r是對通信路徑數(shù)的度量，0<r≤1(假設至少有一名組員需要與一個以上的

其

他組員通信，因此r>0)。對于一個規(guī)模為P的項目組，從（13.5）式導出項目組的總生產率為

Ltot=P(L-l(P-1)r)（13.6）對于給定的一組L，l和r的值，總生產率Ltot是項目組規(guī)模P的函數(shù)。隨著P值增加，Ltot將從0增大到某個最大值，然后再下降。因此，存在一個最佳的項目組規(guī)模Popt，這個規(guī)模的項目組其總生產率最高。13.3.1估算開發(fā)時間項目組規(guī)模與項目組總生產率的關系13.3進度計劃

設個人最高生產率為500LOC/月（即L=500），每條通信路徑導致生產率下降10%（即l=50)。如果每個組員都必須與組內所有其他組員通信（r=1)，則項目組規(guī)模與生產率的關系列參見右表，可見，在這種情況下項目組的最佳規(guī)模是5.5人，即Popt=5.5。13.3.1估算開發(fā)時間舉例說明項目組規(guī)模與項目組總生產率的關系Boehm根據(jù)經驗指出，軟件項目的開發(fā)時間最多可以減少到正常開發(fā)時間的75%。如果要求一個軟件系統(tǒng)的開發(fā)時間過短，則開發(fā)成功的概率幾乎為零。本小節(jié)主要講解了如何估算開發(fā)時間。本節(jié)小結13.3進度計劃下面通過一個非常簡單的例子介紹這種工具：

假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?13.3.2Gantt圖Gantt（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具13.3進度計劃

一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時候都有10名工人閑著沒活干。13.3.2Gantt圖大家可能已經想到，應該采用“流水作業(yè)法”，也就是說，首先由5名工人用刮板刮掉第1面墻上的舊漆(這時其余10名工人休息)，當?shù)?面墻刮凈后，另外5名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉去刮第2面墻上的舊漆)，一旦刮舊漆的工人轉到第3面墻而且刷新漆的工人轉到第2面墻以后，余下的5名工人立即拿起刮刀去清除濺在第1面墻窗戶上的油漆，……。這樣安排使每個工人都有活干，因此能夠在較短的時間內完成任務。13.3進度計劃13.3.2Gantt圖

假設木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時間最少。下表列出了估計每道工序需要用的時間。13.3進度計劃13.3.2Gantt圖

可以使用下圖所示的Gantt圖描繪上述流水作業(yè)過程：

在時間為零時開始刮第1面墻上的舊漆，兩小時后刮舊漆的工人轉去刮第2面墻，同時另5名工人開始給第1面墻刷新漆，每當給一面墻刷完新漆之后，第3組的5名工人立即清除濺在這面墻窗戶上的漆。13.3進度計劃13.3.2Gantt圖

從左圖可以看出，12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結束。因此全部工程在22小時后結束，如果用前述的第一種做法，則需要36小時。主要講解了Gantt圖的基本概念，并用實例給出Gantt圖的具體用法。本節(jié)小結Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業(yè))的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是Gantt圖也有3個主要缺點。(1)不能顯式地描繪各項作業(yè)彼此間的依賴關系。(2)進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象。(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。13.3進度計劃13.3.3工程網(wǎng)絡

當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。13.3進度計劃13.3.3工程網(wǎng)絡

工程網(wǎng)絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業(yè)的開始時間和結束時間，此外，它還顯式地描繪各個作業(yè)彼此間的依賴關系。因此，工程網(wǎng)絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。

在工程網(wǎng)絡中用箭頭表示作業(yè)(例如，刮舊漆，刷新漆，清理等)，用圓圈表示事件(一項作業(yè)開始或結束)。注意，事件僅僅是可以明確定義的時間點，它并不消耗時間和資源。作業(yè)通常既消耗資源又需要持續(xù)一定時間。右圖是舊木板房刷漆工程的工程網(wǎng)絡。圖中表示刮第1面墻上舊漆的作業(yè)開始于事件1，結束于事件2。用開始事件和結束事件的編號標識一個作業(yè)，因此“刮第1面墻上舊漆”是作業(yè)1-2。13.3進度計劃13.3.3工程網(wǎng)絡1—2刮第1面墻上的舊漆；2—3刮第2面墻上的舊漆；2—4給第1面墻刷新漆；3—5刮第3面墻上舊漆；4—6給第2面墻刷新漆；4—7清理第1面墻窗戶；5—8刮第4面墻上舊漆；6—8給第3面墻刷新漆；7—9清理第2面墻窗戶；8—10給第4面墻刷新漆；9—10清理第3面墻窗戶；10—11清理第4面墻窗戶；

虛擬作業(yè)：3—4；5—6；6—7；8—9。13.3進度計劃13.3.3工程網(wǎng)絡

在右圖中還有一些虛線箭頭，它們表示虛擬作業(yè)，也就是事實上并不存在的作業(yè)。引入虛擬作業(yè)是為了顯式地表示作業(yè)之間的依賴關系。13.3進度計劃13.3.3工程網(wǎng)絡

例如，事件4既是給第1面墻刷新漆結束，又是給第2面墻刷新漆開始(作業(yè)4—6)。但是，在開始給第2面墻刷新漆之前，不僅必須已經給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經刮凈(事件3)。也就是說，在事件3和事件4之間有依賴關系，或者說在作業(yè)2—3(刮第2面墻上舊漆)和作業(yè)4—6(給第2面墻刷新漆)之間有依賴關系，虛擬作業(yè)3—4明確地表示了這種依賴關系。注意，虛擬作業(yè)既不消耗資源也不需要時間。讀者可以研究圖下面對各項作業(yè)的描述，解釋引入其他虛擬作業(yè)的原因。13.3進度計劃13.3.3工程網(wǎng)絡主要講解了工程網(wǎng)絡圖的基本概念，并用實例給出工程網(wǎng)絡圖的具體用法。本節(jié)小結

首先，把每個作業(yè)估計需要使用的時間寫在表示該項作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時間沒有關系，箭頭僅表示依賴關系，它上方的數(shù)字才表示作業(yè)的持續(xù)時間。13.3進度計劃13.3.4估算工程進度

畫出工程網(wǎng)絡之后，系統(tǒng)分析員就可以借助它的幫助估算工程進度了。為此需要在工程網(wǎng)絡上增加一些必要的信息。

其次，為每個事件計算下述兩個統(tǒng)計數(shù)字：

最早時刻EET和最遲時刻LET。這兩個數(shù)字將分別寫在表示事件的圓圈的右上角和右下角，如右圖左下角的符號所示。13.3進度計劃13.3.4估算工程進度

通常工程網(wǎng)絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網(wǎng)絡上從左至右按事件發(fā)生順序計算。計算最早時刻EET使用下述3條簡單規(guī)則。(1)考慮進入該事件的所有作業(yè)。(2)對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和。(3)選取上述和數(shù)中的最大值作為該事件的最早時刻EET。13.3進度計劃13.3.4估算工程進度事件的最早時刻是該事件可以發(fā)生的最早時間。

例如，從圖13.3中可以看出事件2只有一個作業(yè)(作業(yè)1—2)進入，就是說，僅當作業(yè)1—2完成時事件2才能發(fā)生，因此事件2的最早時刻就是作業(yè)1—2最早可能完成的時刻。定義事件1的最早時刻為零，據(jù)估計，作業(yè)1—2的持續(xù)時間為2小時，也就是說，作業(yè)1—2最早可能完成的時刻為2，因此，事件2的最早時刻為2。同樣，只有一個作業(yè)(作業(yè)2—3)進入事件3，這個作業(yè)的持續(xù)時間為4小時，所以事件3的最早時刻為2+4=6。13.3進度計劃13.3.4估算工程進度事件的最早時刻是該事件可以發(fā)生的最早時間。

事件4有兩個作業(yè)(2—4和3—4)進入，只有這兩個作業(yè)都完成之后，事件4才能出現(xiàn)(事件4代表上述兩個作業(yè)的結束)。已知事件2的最早時刻為2，作業(yè)2—4的持續(xù)時間為3小時；事件3的最早時刻為6，作業(yè)3—4(這是一個虛擬作業(yè))的持續(xù)時間為0，按照上述3條規(guī)則，可以算出事件4的最早時刻為EET=max{2+3,6+0}=6

按照這種方法，不難沿著工程網(wǎng)絡從左至右順序算出每個事件的最早時刻，計算結果標在圖13.3的工程網(wǎng)絡中(每個圓圈內右上角的數(shù)字)。13.3進度計劃13.3.4估算工程進度

按照慣例，最后一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網(wǎng)絡上從右至左按逆作業(yè)流的方向計算。計算最遲時刻LET使用下述3條規(guī)則。(1)考慮離開該事件的所有作業(yè)。(2)從每個作業(yè)的結束事件的最遲時刻中減去該作業(yè)的持續(xù)時間。(3)選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。13.3進度計劃13.3.4估算工程進度

事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。

例如，按照慣例，圖13.3中事件11的最遲時刻和最早時刻相同，都是23。逆作業(yè)流方向接下來應該計算事件10的最遲時刻，離開這個事件的只有作業(yè)10—11，該作業(yè)的持續(xù)時間為2小時，它的結束事件(事件11)的LET為23，因此，事件10的最遲時刻為LET=23-2=21類似地，事件9的最遲時刻為LET=21-1=20事件8的最遲時刻為LET=min{21-6,20-0}=15圖13.3中每個圓圈內右下角的數(shù)字就是該事件的最遲時刻。13.3進度計劃13.3.4估算工程進度主要講解了工程網(wǎng)絡圖的改進及基于改進后的工程網(wǎng)絡的工程進度估算方法。本節(jié)小結右圖中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。

關鍵路徑上的事件(關鍵事件)必須準時發(fā)生，組成關鍵路徑的作業(yè)(關鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準時結束。13.3進度計劃13.3.5關鍵路徑

工程項目的管理人員應該密切注視關鍵作業(yè)的進展情況，如果關鍵事件出現(xiàn)的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業(yè)中增加資源才會有效果。

一個作業(yè)可以有的全部機動時間等于它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業(yè)的持續(xù)時間：

機動時間=(LET)結束-(EET)開始-持續(xù)時間13.3進度計劃13.3.6機動時間

不在關鍵路徑上的作業(yè)有一定程度的機動余地——實際開始時間可以比預定時間晚一些，或者實際持續(xù)時間可以比預定的持續(xù)時間長一些，而并不影響工程的結束時間。13.3進度計劃13.3.6機動時間

對于前述油漆舊木板房的例子，計算得到的非關鍵作業(yè)的機動時間見下表：13.3進度計劃13.3.6機動時間

在工程網(wǎng)絡中每個作業(yè)的機動時間寫在代表該項作業(yè)的箭頭下面的括號里。在制定進度計劃時仔細考慮和利用工程網(wǎng)絡中的機動時間，往往能夠安排出既節(jié)省資源又不影響最終竣工時間的進度表。

例如，研究圖13.3(或表13.6)可以看出，清理前三面墻窗戶的作業(yè)都有相當多機動時間，也就是說，這些作業(yè)可以晚些開始或者持續(xù)時間長一些(少用一些資源)，并不影響竣工時間。13.3進度計劃13.3.6機動時間

此外，刮第3、第4面墻上舊漆和給第1面墻刷新漆的作業(yè)也都有機動時間，而且這后三項作業(yè)的機動時間之和大于清理前三面墻窗戶需要用的工作時間。因此，有可能僅用10名工人在同樣時間內(23小時)完成舊木板房刷漆工程。

進一步研究圖13.3中的工程網(wǎng)絡可以看出，確實能夠只用10名工人在同樣時間內完成這項任務，而且可以安排出幾套不同的進度計劃，都可以既減少5名工人又不影響竣工時間。13.3進度計劃13.3.6機動時間圖13.4舊木板房刷漆工程改進的Gantt圖之一圖13.1舊木板房刷漆工程的Gantt圖13.3進度計劃13.3.6機動時間

圖13.4中：粗實線代表由甲組工人完成的作業(yè)；斜劃線代表由乙組工人完成的作業(yè)。圖13.4的方案不僅比圖13.1的方案明顯節(jié)省人力，而且改正了圖13.1中的一個錯誤：因為給第2面墻刷新漆的作業(yè)4—6不僅必須在給第1面墻刷完新漆之后(作業(yè)2—4結束)，而且還必須在把第2面墻上的舊漆刮凈之后(作業(yè)2—3和虛擬作業(yè)3—4結束)才能開始，所以給第1面墻刷完新漆之后不能立即開始給第2面墻刷新漆的作業(yè)，需等到把第2面墻上舊漆刮凈之后才能開始，也就是說，全部工程需要23個小時而不是22個小時。13.3進度計劃13.3.6機動時間

上述的簡單例子明顯說明了工程網(wǎng)絡比Gantt圖優(yōu)越的地方：它顯式地定義事件及作業(yè)之間的依賴關系，Gantt圖只能隱含地表示這種關系。但是Gantt圖的形式比工程網(wǎng)絡更簡單更直觀，為更多的人所熟悉，因此，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。13.3進度計劃13.3.6機動時間

以上通過舊木板房刷新漆工程的簡單例子，介紹了制訂進度計劃的兩個重要工具和方法。軟件工程項目雖然比這個簡單例子復雜得多，但是計劃和管理的基本方法仍然是自頂向下分解，也就是把項目分解為若干個階段，每個階段再分解成許多更小的任務，每個任務又可進一步分解為若干個步驟等。這些階段、任務和步驟之間有復雜的依賴關系，因此，工程網(wǎng)絡和Gantt圖同樣是安排進度和管理工程進展情況的強有力的工具。主要講解了工程網(wǎng)絡圖中的關鍵路徑和機動時間兩個基本概念。本節(jié)小結主要

內容13.1估算軟件規(guī)模13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟模型13.4人員組織

軟件項目成功的關鍵是有高素質的軟件開發(fā)人員。然而大多數(shù)軟件的規(guī)模都很大，單個軟件開發(fā)人員無法在給定期限內完成開發(fā)工作，因此，必須把多名軟件開發(fā)人員合理地組織起來，使他們有效地分工協(xié)作共同完成開發(fā)工作。

現(xiàn)有的軟件項目組的組織方式很多，通常，組織軟件開發(fā)人員的方法，取決于所承擔的項目的特點、以往的組織經驗以及管理者的看法和喜好。下面介紹3種典型的組織方式。13.4人員組織小組成員之間的通信是平行的，如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。程序設計小組的人數(shù)不能太多,否則組員間彼此通信的時間將多于程序設計時間。一般說來，程序設計小組的規(guī)模應該比較小,以2～8名成員為宜。小組規(guī)模小,不僅可以減少通信問題,而且還有其他好處。例如,容易確定小組的質量標準,而且用民主方式確定的標準更容易被大家遵守;組員間關系密切,能夠互相學習等。13.4.1民主制程序員組

民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協(xié)商做出技術決策。13.4人員組織通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。主要優(yōu)點是，組員們對發(fā)現(xiàn)程序錯誤持積極的態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導致高質量的代碼。另一個優(yōu)點是，組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。因此，當有技術難題需要解決時，也就是說，當所要開發(fā)的軟件的技術難度較高時，采用民主制程序員組是適宜的。13.4.1民主制程序員組

如果組內多數(shù)成員是經驗豐富技術熟練的程序員,那么上述非正式的組織方式可能會非常成功。13.4人員組織

用這種組織方式主要出于下述幾點考慮：(1)軟件開發(fā)人員多數(shù)比較缺乏經驗。(2)程序設計過程中有許多事務性的工作，例如，大量信息的存儲和更新。(3)多渠道通信很費時間，將降低程序員的生產率。

主程序員組用經驗多、技術好、能力強的程序員作為主程序員，同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。

13.4.2主程序員組IBM在20世紀70年代初期開始采用主程序員組的組織方式13.4人員組織

這種組織方式類似于外科手術小組的組織：主刀大夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協(xié)助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫(yī)生或婦產科醫(yī)生）協(xié)助。

上述比喻突出了主程序員組的兩個重要特性。（1）專業(yè)化。該組每名成員僅完成他們受過專業(yè)訓練的那些工作。（2）層次性。主刀大夫指揮每名組員工作，并對手術全面負責。13.4.2主程序員組13.4人員組織

當時，典型的主程序員組的組織形式如下圖所示。該組由主程序員、后備程序員、編程秘書以及1~3名程序員組成。在必要的時候，該組還有其他領域的專家協(xié)助。13.4.2主程序員組13.4人員組織接下來介紹主程序員組的結構主程序員組核心人員的分工：（1）主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或復雜部分）的詳細設計，并且負責指導其他程序員完成詳細設計和編碼工作。如圖所示，程序員之間沒有通信渠道，所有接口問題都由主程序員處理。主程序員對每行代碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。13.4.2主程序員組13.4人員組織（2）后備程序員也應該技術熟練而且富于經驗，他協(xié)助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優(yōu)秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。13.4.2主程序員組13.4人員組織（2）后備程序員也應該技術熟練而且富于經驗，他協(xié)助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優(yōu)秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。（3）編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執(zhí)行源程序和測試用例。13.4.2主程序員組13.4人員組織首先，主程序員應該是高級程序員和優(yōu)秀管理者的結合體。承擔主程序員工作需要同時具備這兩方面的才能，但是，在現(xiàn)實社會中這樣的人才并不多見。通常，既缺乏成功的管理者也缺乏技術熟練的程序員。其次，后備程序員更難找。人們期望后備程序員像主程序員一樣優(yōu)秀，但是，他們必須坐在“替補席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。13.4.2主程序員組

主程序員組的組織方式說起來有不少優(yōu)點，但是，它在許多方面卻是不切實際的。13.4人員組織再次，編程秘書也很難找到。專業(yè)的軟件技術人員一般都厭煩日常的事務性工作，但是，人們卻期望編程秘書整天只干這類工作。13.4.2主程序員組

人們需要一種更合理、更現(xiàn)實的組織程序員組的方法，這種方法應該能充分結合民主制程序員組和主程序員組的優(yōu)點，并且能用于實現(xiàn)更大規(guī)模的軟件產品。13.4人員組織

民主制程序員組的一個主要優(yōu)點，是小組成員都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。但是，使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發(fā)現(xiàn)的程序錯誤與小組成員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯誤的心理。13.4.3現(xiàn)代程序員組

解決上述問題的方法是，取消主程序員的大部分行政管理工作。

實際的“主程序員”應該由兩個人共同擔任：

一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術性事務的管理決策。13.4人員組織組織結構如右圖所示：

技術組長要參與全部代碼審查工作。相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業(yè)績進行評價。行政組長應該在常規(guī)調度會議上了解每名組員的技術能力和工作業(yè)績。13.4.3現(xiàn)代程序員組13.4人員組織

在開始工作之前明確劃分技術組長和行政組長的管理權限是很重要的。但是，即使已經做了明確分工，有時也會出現(xiàn)職責不清的矛盾。例如，考慮年度休假問題，行政組長有權批準某個程序員休年假的申請，因為這是一個非技術性問題，但是技術組長可能馬上否決了這個申請，因為已經接近預定的項目結束日期，目前人手非常緊張。解決這類問題的辦法是求助于更高層的管理人員，對行政組長和技術組長都認為是屬于自己職責范圍內的事務，制定一個處理方案。13.4.3現(xiàn)代程序員組13.4人員組織

由于程序員組成員人數(shù)不宜過多，當軟件項目規(guī)模較大時，應該把程序員分成若干個小組，采用下圖所示的組織結構。13.4.3現(xiàn)代程序員組13.4人員組織13.4.3現(xiàn)代程序員組

上圖描繪的是技術管理組織結構，非技術管理組織結構與此類似。由圖可以看出，產品開發(fā)作為一個整體是在項目經理的指導下進行的，程序員向他們的組長匯報工作，而組長則向項目經理匯報工作。當產品規(guī)模更大時，可以適當增加中間管理層次。13.4人員組織

把民主制程序員組和主程序員組的優(yōu)點結合起來的另一種方法，是在合適的地方采用分散做決定的方法，如下圖所示。13.4.3現(xiàn)代程序員組13.4人員組織13.4.3現(xiàn)代程序員組這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個程序員的積極性和主動性，集思廣益攻克技術難關。這種組織方式對于適合采用民主方法的那類問題（例如研究性項目或遇到技術難題需要用集體智慧攻關）非常有效。盡管這種組織方式適當?shù)匕l(fā)揚了民主，但是上下級之間的箭頭（即管理關系）仍然是向下的，也就是說，是在集中指導下發(fā)揚民主。顯然，如果程序員可以指揮項目經理，則只會引起混亂。1、民主制程序員組2、主程序員組3、現(xiàn)代程序員組本節(jié)小結主要

內容13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟模型13.5質量保證那么，什么是軟件的質量呢？怎樣在開發(fā)過程中保證軟件的質量呢？本節(jié)著重討論這兩個問題：1.軟件質量2.軟件質量保證措施

質量是產品的生命，不論生產何種產品，質量都是極端重要的。軟件產品開發(fā)周期長，耗費巨大的人力和物力，更必須特別注意保證質量。13.5質量保證13.5.1軟件質量

概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發(fā)標準以及任何專業(yè)開發(fā)的軟件產品都應該具有的隱含特征相一致的程度。13.5質量保證13.5.1軟件質量上述定義強調了下述的3個要點。（1）

軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。（2）指定的開發(fā)標準定義了一組指導軟件開發(fā)的準則，如果沒有遵守這些準則，肯定會導致軟件質量不高。（3）

通常，有一組沒有顯式描述的隱含需求（例如，軟件應該是容易維護的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質量仍然是值得懷疑的。13.5質量保證13.5.1軟件質量

雖然軟件質量是難于定量度量的軟件屬性，但是仍然能夠提出許多重要的軟件質量指標(其中絕大多數(shù)目前還處于定性度量階段)。

本節(jié)介紹影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。可以把這些質量因素分成3組，分別反映用戶在使用軟件產品時的3種不同傾向或觀點。13.5質量保證13.5.1軟件質量

這3種傾向是：

產品運行、產品修改和產品轉移。右圖描繪了軟件質量因素和上述3種傾向(或產品活動)之間的關系，下頁表列出了軟件質量因素的簡明定義。13.5質量保證13.5.1軟件質量主要講解了軟件質量的定義、內涵、要點及軟件質量的組成等。本節(jié)小結13.5質量保證13.5.2軟件質量保證措施

軟件質量保證（softwarequalityassurance,SQA）的措施主要有：基于非執(zhí)行的測試（也稱為復審或評審），基于執(zhí)行的測試（即以前講過的軟件測試）和程序正確性證明。

復審主要用來保證在編碼之前各階段產生的文檔的質量；基于執(zhí)行的測試需要在程序編寫出來之后進行，它是保證軟件質量的最后一道防線；程序正確性證明使用數(shù)學方法嚴格驗證程序是否與對它的說明完全一致。13.5質量保證13.5.2軟件質量保證措施參加軟件質量保證工作的人員，可以劃分成下述兩類：

軟件工程師，通過采用先進的技術方法和度量，進行正式的技術復審以及完成計劃周密的軟件測試來保證軟件質量。SQA小組，職責是輔助軟件工程師以獲得高質量的軟件產品。其從事的軟件質量保證活動主要是：

計劃，監(jiān)督，記錄，分析和報告。簡而言之，SQA小組的作用是，通過確保軟件過程的質量來保證軟件產品的質量。13.5質量保證1.技術復審的必要性

正式技術復審的顯著優(yōu)點是，能夠較早發(fā)現(xiàn)軟件錯誤，從而可防止錯誤被傳播到軟件過程的后續(xù)階段。

統(tǒng)計數(shù)字表明，在大型軟件產品中檢測出的錯誤，60%~70%屬于規(guī)格說明錯誤或設計錯誤，而正式技術復審在發(fā)現(xiàn)規(guī)格說明錯誤和設計錯誤方面的有效性高達75%。由于能夠檢測出并排除掉絕大部分這類錯誤，復審可大大降低后續(xù)開發(fā)和維護階段的成本。

實際上，正式技術復審是軟件質量保證措施的一種，包括走查（walkthrough)和審查（inspection）等具體方法。走查的步驟比審查少，而且沒有審查正規(guī)。13.5質量保證2.走查

走查組由4~6名成員組成。以走查規(guī)格說明的小組為例，成員至少包括一名負責起草規(guī)格說明的人，一名負責該規(guī)格說明的管理員，一位客戶代表，以及下階段開發(fā)組（在本例中是設計組）的一名代表和SQA小組的一名代表。其中SQA小組的代表應該作為走查組的組長。

為了能發(fā)現(xiàn)重大錯誤，走查組成員最好是經驗豐富的高級技術人員。必須把被走查的材料預先分發(fā)給走查組每位成員。走查組成員應該仔細研究材料并列出兩張表：

一張表是他不理解的術語，另一張是他認為不正確的術語。13.5質量保證2.走查

走查組組長引導該組成員走查文檔，力求發(fā)現(xiàn)盡可能多的錯誤。走查組的任務僅僅是標記出錯誤而不是改正錯誤，改正錯誤的工作應該由該文檔的編寫組完成。走查的時間最長不要超過2小時，這段時間應該用來發(fā)現(xiàn)和標記錯誤，而不是改正錯誤。13.5質量保證2.走查走查主要有下述兩種方式：（1）參與者驅動法。參與者按照事先準備好的列表，提出他們不理解的術語和認為不正確的術語。文檔編寫組的代表必須回答每個質疑，要么承認確實有錯誤，要么對質疑做出解釋。（2）

文檔驅動法。文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質疑。這種方法可能比第一種方法更有效，往往能檢測出更多錯誤。經驗表明，使用文檔驅動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。13.5質量保證3.審查通常，審查過程包括下述5個基本步驟：

（1）綜述。由負責編寫文檔的一名成員向審查組綜述該文檔。在綜述會結束時把文檔分發(fā)給每位與會者。（2）準備。評審員仔細閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作。這些列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。審查的范圍比走查廣泛得多，它的步驟也比較多13.5質量保證3.審查（3）審查。評審組仔細走查整個文檔。和走查一樣，這一步的目的也是發(fā)現(xiàn)文檔中的錯誤，而不是改正它們。通常每次審查會不超過90分鐘。審查組組長應該在一天之內寫出一份關于審查的報告。（4）返工。文檔的作者負責解決在審查報告中列出的所有錯誤及問題。13.5質量保證3.審查（5）

跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認為是錯誤的條目）。必須仔細檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該由審查組再對文檔全面地審查一遍。

通常，審查組由4人組成。組長既是審查組的管理人員又是技術負責人。審查組必須包括負責當前階段開發(fā)工作的項目組代表和負責下一階段開發(fā)工作的項目組代表，此外，還應該包括一名SQA小組的代表。13.5質量保證3.審查

審查過程不僅步數(shù)比走查多，而且每個步驟都是正規(guī)的。審查的正規(guī)性體現(xiàn)在：仔細劃分錯誤類型，并把這些信息運用在后續(xù)階段的文檔審查中以及未來產品的審查中。

審查是檢測軟件錯誤的一種好方法，利用審查可以在軟件過程的早期階段發(fā)現(xiàn)并改正錯誤，也就是說，能在修正錯誤的代價變得很昂貴之前就發(fā)現(xiàn)并改正錯誤。因此，審查是一種經濟有效的錯誤檢測方法。13.5質量保證4.程序正確性證明

一旦研究出實用的正確性證明程序，軟件可靠性將更有保證，測試工作量將大大減少。但是，即使有了正確性證明程序，軟件測試也仍然是需要的，因為程序正確性證明只證明程序功能是正確的，并不能證明程序的動態(tài)特性是符合要求的，此外，正確性證明過程本身也可能發(fā)生錯誤。

測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段；但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因此，對于保證軟件可靠性來說，測試是一種不完善的技術，人們自然希望研究出完善的正確性證明技術。13.5質量保證4.程序正確性證明

正確性證明的基本思想是證明程序能完成預定的功能。因此，應該提供對程序功能的嚴格數(shù)學說明，然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。

在20世紀60年代初期，人們已經開始研究程序正確性證明的技術，提出了許多不同的技術方法。雖然這些技術方法本身很復雜，但是它們的基本原理卻是相當簡單的。

如果在程序的若干個點上，設計者可以提出關于程序變量及它們的關系的斷言，那么在每一點上的斷言都應該永遠是真的。假設在程序的P1,P2,…，Pn等點上的斷言分別是a(1),a(2)，…，a(n)，其中a(1)必須是關于程序輸入的斷言，a(n)必須是關于程序輸出的斷言。13.5質量保證4.程序正確性證明

為了證明在點Pi和Pi+1之間的程序語句是正確的，必須證明執(zhí)行這些語句之后將使斷言a(i)變成a(i+1)。如果對程序內所有相鄰點都能完成上述證明過程，則證明了輸入斷言加上程序可以導出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。13.5質量保證4.程序正確性證明

人工證明程序正確性，對于評價小程序可能有些價值，但是在證明大型軟件的正確性時，不僅工作量太大，更主要的是在證明的過程中很容易包含錯誤，因此是不實用的。為了實用的目的，必須研究能證明程序正確性的自動系統(tǒng)。

目前已經研究出證明PASCAL和LISP程序正確性的程序系統(tǒng)，正在對這些系統(tǒng)進行評價和改進?，F(xiàn)在這些系統(tǒng)還只能對較小的程序進行評價，毫無疑問還需要做許多工作，這樣的系統(tǒng)才能實際用于大型程序的正確性證明。主要講解了軟件質量保證措施，包括技術復審、走查、審查、程序正確性證明等。本節(jié)小結主要

內容

13.2工作量估算13.3進度計劃13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟模型13.6軟件配置管理軟件配置管理是在軟件的整個生命期內管理變化的一組活動。

具體地說，這組活動用來：

（1）標識變化。（2）控制變化。（3）確保適當?shù)貙崿F(xiàn)了變化。（4）向需要知道這類信息的人

報告變化。13.6軟件配置管理

軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。

軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。13.6軟件配置管理

軟件過程的輸出信息可以分為3類：

（1）計算機程序（源代碼和可執(zhí)行程序）。（2）描述計算機程序的文檔（供技術人員或用戶使用）。（3）數(shù)據(jù)（程序內包含的或在程序外的）。

上述這些項組成了在軟件過程中產生的全部信息，人們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。13.6.1軟件配置1.軟件配置項13.6軟件配置管理

隨著軟件開發(fā)過程的進展，軟件配置項的數(shù)量迅速增加。不幸的是，由于前述的種種原因，軟件配置項的內容隨時都可能發(fā)生變化。為了開發(fā)出高質量的軟件產品，軟件開發(fā)人員不僅要努力保證每個軟件配置項正確，而且必須保證一個軟件的所有配置項是完全一致的。

可以把軟件配置管理看作是應用于整個軟件過程的軟件質量保證活動，是專門用于管理變化的軟件質量保證活動。13.6軟件配置管理

簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應用特定的、正式的過程（稱為規(guī)程）來評估、實現(xiàn)和驗證每個變化。2.基線

基線是一個軟件配置管理概念，它有助于人們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經通過了正式復審的規(guī)格說明或中間產品，它可以作為進一步開發(fā)的基礎，并且只有通過正式的變化控制過程才能改變它。13.6軟件配置管理

除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他CASE工具，作為軟件配置的一部分“固定”下來。

因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產生的結果不同，應該把軟件工具也基線化，并且列入到綜合的配置管理過程之中。主要講解了軟件配置的基本概念，及軟件配置項和基線的概念。本節(jié)小結13.6軟件配置管理

軟件配置管理是軟件質量保證的重要一環(huán)，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。

具體來說，軟件配置管理主要有5項任務：

標識、版本控制、變化控制、配置審計和報告。13.6.2

軟件配置管理過程13.6軟件配置管理

為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向對象方法組織它們?？梢詷俗R出兩類對象：基本對象和聚集對象?；緦ο笫擒浖こ處熢诜治?、設計、編碼或測試過程中創(chuàng)建出來的或“文本單元”。1.標識軟件配置中的對象

每個對象都有一組能唯一地標識它的特征：名字、描述、資源表和“實現(xiàn)”。其中，對象名是無二義性地標識該對象的一個字符串。13.6軟件配置管理

在設計標識軟件對象的模式時，必須認識到對象在整個生命周期中一直都在演化，因此，所設計的標識模式必須能無歧義地標識每個對象的不同版本。1.標識軟件配置中的對象13.6軟件配置管理

版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)這個目標的方法是，把屬性和軟件的每個版本關聯(lián)起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。2.版本控制

上面提到的“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復雜到是一個布爾變量串，其指明了施加到系統(tǒng)上的功能變化的具體類型。13.6軟件配置管理典型的變化控制過程如下：

接到變化請求之后，首先評估該變化在技術方面的得失、可能產生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結果形成“變化報告”，該報告供“變化控制審批者”審閱。3.變化控制

對于大型軟件開發(fā)項目來說，無控制的變化將迅速導致混亂。變化控制把人的規(guī)程和自動工具結合起來，以提供一個控制變化的機制。13.6軟件配置管理

所謂變化控制審批者既可以是一個人也可以由一組人組成，其對變化的狀態(tài)和優(yōu)先級做最終決策。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現(xiàn)的變化，必須遵守的約束以及復審和審計的標準。把要修改的對象從項目數(shù)據(jù)庫中“提?。╟heckout）”出來，進行修改并應用適當?shù)腟QA活動。

最后，把修改后的對象“提交（checkin）”進數(shù)據(jù)庫，并用適當?shù)陌姹究刂茩C制創(chuàng)建該軟件的下一個版本。3.變化控制13.6軟件配置管理

在一個軟件配置項變成基線之前，僅需應用非正式的變化控制。該配置對象的開發(fā)者可以對它進行任何合理的修改（只要修改不會影響到開發(fā)者工作范圍之外的系統(tǒng)需求）。一旦該對象經過了正式技術復審并獲得批準，就創(chuàng)建了一個基線。3.變化控制

“提交”和“提取”過程實現(xiàn)了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪個軟件工程師有權訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。13.6軟件配置管理

而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制?，F(xiàn)在，為了進行修改開發(fā)者必須獲得項目管理者的批準（如果變化是“局部的”），如果變化影響到其他軟件配置項，還必須得到變化控制審批者的批準。在某些情況下，可以省略正式的變化請求、變化報告和工程變化命令，但是，必須評估每個變化并且跟蹤和復審所有變化。3.變化控制13.6軟件配置管理

為了確保適當?shù)貙崿F(xiàn)了所需要的變化，通常從下述兩方面采取措施：

①正式的技術復審；②軟件配置審計。正式的技術復審（見13.5.2節(jié)）關注被修改后的配置對象的技術正確性。復審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。4.配置審計13.6軟件配置管理

軟件配置審計通過評估配置對象的那些通常不在復審過程中考慮的特征（例如修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當?shù)馗铝怂邢嚓P的軟件配置項，是否遵循了標注變化、記錄變化和報告變化的規(guī)程），而成為對正式技術復審的補充。4.配置審計13.6軟件配置管理5.狀態(tài)報告

書寫配置狀態(tài)報告是軟件配置管理的一項任務，它回答下述問題：①發(fā)生了什么事？②誰做的這件事？③這件事是什么時候發(fā)生的？④它將影響哪些其他事物？13.6軟件配置管理5.狀態(tài)報告

軟件配置審計通過評估配置對象的那些通常不在復審過程配置狀態(tài)報告對大型軟件開發(fā)項目的成功有重大貢獻。當大量人員在一起工作時，可能一個人并不知道另一個人在做什么。兩名開發(fā)人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據(jù)過時的硬件規(guī)格說明開發(fā)軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態(tài)報告通過改善所有相關人員之間的通信，幫助消除這些問題。主要講解了軟件配置管理過程，包括：標識、版本控制、變化控制、配置審計和報告。本節(jié)小結主要

內容

13.4人員組織13.5質量保證13.6軟件配置管理13.7能力成熟模型13.7能力成熟模型

最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據(jù)，發(fā)展到后來，此模型又同時被應用于許多軟件機構內部的過程改進活動中。

美國卡內基梅隆大學軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capabilitymaturitymodel,CMM)，是用于評價軟件機構的軟件過程能力成熟度的模型。13.7能力成熟模型

多年來，軟件危機一直困擾著許多軟件開發(fā)機構。不少人試圖通過采用新的軟件開發(fā)技術來解決在軟件生產率和軟件質量等方面存在的問題，但效果并不令人十分滿意。

事實證明，在無規(guī)則和混亂的管理之下，先進的技術和工具并不能發(fā)揮出應有的作用。人們逐漸認識到，改進對軟件過程的管理是消除軟件危機的突破口，再也不能忽視在軟件過程中管理的關鍵作用了。13.7能力成熟模型

軟件過程包括各種活動、技術和工具，因此，它實際上既包括了軟件開發(fā)的技術方面又包括了管理方面。CMM的策略是，力圖改進對軟件過程的管理，而在技術方面的改進是其必然的結果。

能力成熟度模型的基本思想是，由于問題是由人們管理軟件過程的方法不當引起的，所以新軟件技術的運用并不會自動提高軟件的生產率和質量。13.7能力成熟模型CMM把軟件過程從無序到有序的進化過程分成5個階段，并把這些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個有序的尺度，用以測量軟件機構的軟件過程成熟度和評價其軟件過程能力，這些等級還能幫助軟件機構把應做的改進工作排出優(yōu)先次序。13.7能力成熟模型CMM對5個成熟度級別特性的描述，說明了不同級別之間軟件過程的主要變化。從“1級”到“5級”，反映出一個軟件機構為了達到從一個無序的、混亂的軟件過程進化到一種有序的、有紀律的且成熟的軟件過程的目的，必須經歷的過程改進活動的途徑。CMM通過定義能力成熟度的5個等級，引導軟件開發(fā)機構不斷識別出其軟件過程的缺陷，并指出應該做哪些改進，但是，它并不提供做這些改進