141.軟件項目管理

第13章  軟件項目管理

與開發過程並行，一個是技術路線，一個是管理路線

在經歷了若干個大型軟件工程項目的失敗以後，人們才逐漸認識到軟件項目管理的重要性和特殊性。事實上，這些項目的失敗並非因爲從事軟件開發工做的軟件工程師無能，正相反，他們之中的絕大多數是當時傑出的技術專家。這些工程項目的失敗主要是由於管理不善。

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

軟件項目管理先於任何技術活動以前開始，而且貫穿於軟件的整個生命週期之中。

軟件項目管理過程從一組項目計劃活動開始，而制定計劃的基礎是工做量估算和完成期限估算。爲了估算項目的工做量和完成期限，首先須要估算軟件的規模。

 

13.1  估算軟件規模  

13.1.1  代碼行技術

代碼行技術是比較簡單的定量估算軟件規模的方法。這種方法依據以往開發相似產品的經驗和歷史數據，估計實現一個功能所須要的源程序行數。當有以往開發相似產品的歷史數據可供參考時，用這種方法估計出的數值仍是比較準確的。把實現每一個功能所須要的源程序行數累加起來，就可獲得實現整個軟件所須要的源程序行數。

 

爲了使得對程序規模的估計值更接近實際值，能夠由多名有經驗的軟件工程師分別作出估計。每一個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)，分別算出這3種規模的平均值,和以後，再用下式計算程序規模的估計值：

L=        (13.1)

用代碼行技術估算軟件規模時，當程序較小時經常使用的單位是代碼行數（LOC），當程序較大時經常使用的單位是千行代碼數（KLOC）。

 

代碼行技術的主要優勢是，代碼是全部軟件開發項目都有的「產品」，並且很容易計算代碼行數。代碼行技術的缺點是：  源程序僅是軟件配置的一個成分，用它的規模表明整個軟件的規模彷佛不太合理；用不一樣語言實現同一個軟件所須要的代碼行數並不相同；這種方法不適用於非過程語言。爲了克服代碼行技術的缺點，人們又提出了功能點技術。

 

13.1.2  功能點技術

功能點技術依據對軟件信息域特性和軟件複雜性的評估結果，估算軟件規模。這種方法用功能點（FP）爲單位度量軟件規模。

1. 信息域特性

功能點技術定義了信息域的5個特性，分別是輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)、主文件數(Maf)和外部接口數(Inf)。下面講述這5個特性的含義。

（1） 輸入項數：  用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。輸入不一樣於查詢，後者單獨計數，不計入輸入項數中。

（2） 輸出項數：  軟件向用戶輸出的項數，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的數據項不單獨計數。

（3） 查詢數：  查詢便是一次聯機輸入，它致使軟件以聯機輸出方式產生某種即時響應。

（4） 主文件數：  邏輯主文件（即數據的一個邏輯組合，它多是大型數據庫的一部分或是一個獨立的文件）的數目。

（5） 外部接口數：  機器可讀的所有接口（例如，磁盤或磁帶上的數據文件）的數量，用這些接口把信息傳送給另外一個系統。

 

2. 估算功能點的步驟

用下述3個步驟，可估算出一個軟件的功能點數（即軟件規模）。

（1） 計算未調整的功能點數UFP

首先，把產品信息域的每一個特性(即Inp、Out、Inq、Maf和Inf)都分類爲簡單級、平均級或複雜級，並根據其等級爲每一個特性分配一個功能點數（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個複雜級的輸入項分配6個功能點）。

而後，用下式計算未調整的功能點數UFP： UFP=a₁×Inp+a₂×Out+a₃×Inq+a₄×Maf+a₅×Inf

其中，a_i(1≤i≤5)是信息域特性係數，其值由相應特性的複雜級別決定，如表13.1（見書297頁）所示。

(2) 計算技術複雜性因子TCF

這一步驟度量14種技術因素對軟件規模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯機更新等，在表13.2（見書297頁）中列出了所有技術因素，並用F_i(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

功能點數與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。可是，在判斷信息域特性複雜級別和技術因素的影響程度時，存在着至關大的主觀因素。

 

13.2  工做量估算

軟件估算模型使用由經驗導出的公式來預測軟件開發工做量，工做量是軟件規模（KLOC或FP）的函數，工做量的單位一般是人月（pm)。

支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，所以，沒有一個估算模型能夠適用於全部類型的軟件和開發環境。

13.2.1  靜態單變量模型

這類模型的整體結構形式以下： 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.16

(3) Boehm簡單模型

E=3.2×(KLOC)^1.05

(4) Doty模型（在KLOC>9時適用）

E=5.288×(KLOC)^1.047

 

2. 面向FP的估算模型

(1) Albrecht & Gaffney模型

E=-13.39+0.0545FP

(2) Maston,Barnett和Mellichamp模型

E=585.7+15.12FP

 

從上面列出的模型能夠看出，對於相同的KLOC或FP值，用不一樣模型估算將得出不一樣的結果。主要緣由是，這些模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，適用範圍有限。所以，必須根據當前項目的特色選擇適用的估算模型，而且根據須要適當地調整（例如，修改模型常數）估算模型。

 

13.2.2  動態多變量模型

動態多變量模型也稱爲軟件方程式，它是根據從4000多個當代軟件項目中收集的生產率數據推導出來的。該模型把工做量看做是軟件規模和開發時間這兩個變量的函數。動態多變量估算模型的形式以下：

E=(LOC×B^0.333/P)³×(1/t)⁴          (13.2)

其中，

E是以人月或人年爲單位的工做量；

t是以月或年爲單位的項目持續時間；

B是特殊技術因子，它隨着對測試、質量保證、文檔及管理技術的需求的增長而緩慢增長，對於較小的程序（KLOC=5~15），B=0.16,對於超過70 KLOC的程序，B=0.39;

P是生產率參數，它反映了下述因素對工做量的影響：

　　整體過程成熟度及管理水平；

　　使用良好的軟件工程實踐的程度；

　　使用的程序設計語言的級別；

　　軟件環境的狀態；

　　軟件項目組的技術及經驗；

 

應用系統的複雜程度。

開發實時嵌入式軟件時，P的典型值爲2000；開發電信系統和系統軟件時，P=10000；對於商業應用系統來講，P=28000。能夠從歷史數據導出適用於當前項目的生產率參數值。

從（13.2）式能夠看出，開發同一個軟件（即LOC固定）的時候，若是把項目持續時間延長一些，則可下降完成項目所需的工做量。

 

 

13.2.3  COCOMO2模型

COCOMO是構造性成本模型（constructive cost model)的英文縮寫。1981年Boehm在《軟件工程經濟學》中首次提出了COCOMO模型，本書第三版曾對此模型做了介紹。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。

 

COCOMO2給出了3個層次的軟件開發工做量估算模型，這3個層次的模型在估算工做量時，對軟件細節考慮的詳盡程度逐級增長。這些模型既能夠用於不一樣類型的項目，也能夠用於同一個項目的不一樣開發階段。這3個層次的估算模型分別是：

（1） 應用系統組成模型。這個模型主要用於估算構建原型的工做量，模型名字暗示在構建原型時大量使用已有的構件。

（2） 早期設計模型。這個模型適用於體系結構設計階段。

（3） 後體系結構模型。這個模型適用於完成體系結構設計以後的軟件開發階段。

 

下面之後體系結構模型爲例，介紹COCOMO2模型。該模型把軟件開發工做量表示成代碼行數（KLOC）的非線性函數：

 E=       (13.3)

其中，

E是開發工做量（以人月爲單位），

a是模型係數，

KLOC是估計的源代碼行數（以千行爲單位），

b是模型指數，

f_i(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  進度計劃

不論從事哪一種技術性項目，實際狀況都是，在實現一個大目標以前每每必須完成數以百計的小任務（也稱爲做業）。這些任務中有一些是處於「關鍵路徑」（見13.3.5節）以外的，其完成時間若是沒有嚴重拖後，就不會影響整個項目的完成時間；其餘任務則處於關鍵路徑之中，若是這些「關鍵任務」的進度拖後，則整個項目的完成日期就會拖後，管理人員應該高度關注關鍵任務的進展狀況。

 

沒有一個廣泛適用於全部軟件項目的任務集合，所以，一個有效的軟件過程應該定義一個適用於當前項目的任務集合。一個任務集合包括一組軟件工程工做任務、里程碑和可交付的產品。爲一個項目所定義的任務集合，必須包括爲得到高質量的軟件產品而應該完成的全部任務，可是同時又不能讓項目組承擔沒必要要的工做。

項目管理者的目標是定義所有項目任務，識別出關鍵任務，跟蹤關鍵任務的進展情況，以保證能及時發現拖延進度的狀況。爲達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監督項目進度並控制整個項目。

 

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

13.3.1  估算開發時間

估算出完成給定項目所需的總工做量以後，接下來須要回答的問題就是：  用多長時間才能完成該項目的開發工做？對於一個估計工做量爲20人月的項目，可能想出下列幾種進度表：

1我的用20個月完成該項目；

4我的用5個月完成該項目；

20我的用1個月完成該項目。

可是，這些進度表並不現實，實際上軟件開發時間與從事開發工做的人數之間並非簡單的反比關係。

 

一般，成本估算模型也同時提供了估算開發時間T的方程。與工做量方程不一樣，各類模型估算開發時間的方程很類似，例如：

(1) Walston_Felix模型

T=2.5E^0.35

(2) 原始的COCOMO模型

T=2.5E^0.38

(3) COCOMO2模型

T=3.0E^{0.33+0.2×(b-1.01)}

(4) Putnam模型

T=2.4E^1/3

 

其中，

E是開發工做量（以人月爲單位），

T是開發時間（以月爲單位）。

用上列方程計算出的T值，表明正常狀況下的開發時間。客戶每每但願縮短軟件開發時間，顯然，爲了縮短開發時間應該增長從事開發工做的人數。可是，經驗告訴咱們，隨着開發小組規模擴大，我的生產率將降低，以至開發時間與從事開發工做的人數並不成反比關係。出現這種現象主要有下述兩個緣由：

 

當小組變得更大時，每一個人須要用更多時間與組內其餘成員討論問題、協調工做，所以增長了通訊開銷。

若是在開發過程當中增長小組人員，則最初一段時間內項目組總生產率不只不會提升反而會降低。這是由於新成員在開始時不只不是生產力，並且在他們學習期間還須要花費小組其餘成員的時間。

綜合上述兩個緣由，存在被稱爲Brooks規律的下述現象：  向一個已經延期的項目增長人力，只會使得它更加延期。

 

下面讓咱們研究項目組規模與項目組總生產率的關係。

項目組成員之間的通訊路徑數，由項目組人數和項目組結構決定。若是項目組共有P名組員，每一個組員必須與全部其餘組員通訊以協調開發活動，則通訊路徑數爲P(P-1)/2。若是每一個組員只需與另一個組員通訊，則通訊路徑數爲P-1。通訊路徑數少於P-1是不合理的，由於那將致使出現與任何人都沒有聯繫的組員。

 

所以，通訊路徑數大約在P~P²/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）式導出項目組的總生產率爲

L_tot=P(L-l(P-1)^r)        (13.6)

對於給定的一組L，l和r的值，總生產率L_tot是項目組規模P的函數。隨着P值增長，L_tot將從0增大到某個最大值，而後再降低。所以，存在一個最佳的項目組規模P_opt，這個規模的項目組其總生產率最高。

 

讓咱們舉例說明項目組規模與生產率的關係。假設我的最高生產率爲500LOC/月（即L=500），每條通訊路徑致使生產率降低10%（即l=50)。若是每一個組員都必須與組內全部其餘組員通訊（r=1)，則項目組規模與生產率的關係列在表13.4（見書304頁）中，可見，在這種狀況下項目組的最佳規模是5.5人，即Popt=5.5。

事實上，作任何事情都須要時間，咱們不可能用「人力換時間」的辦法無限縮短一個軟件的開發時間。Boehm根據經驗指出，軟件項目的開發時間最多能夠減小到正常開發時間的75%。若是要求一個軟件系統的開發時間太短，則開發成功的機率幾乎爲零。

 

13.3.2  Gantt圖

Gantt（甘特）圖是歷史悠久、應用普遍的制定進度計劃的工具，下面經過一個很是簡單的例子介紹這種工具。

假設有一座陳舊的矩形木板房須要從新油漆。這項工做必須分3步完成： 首先刮掉舊漆，而後刷上新漆，最後清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工做，然而工具卻頗有限： 只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工做進行得更有效呢?

 

一種作法是首先刮掉四面牆壁上的舊漆，而後給每面牆壁都刷上新漆，最後清除濺在每一個窗戶上的油漆。顯然這是效率最低的作法，由於總共有15名工人，然而每種工具卻只有5件，這樣安排工做在任什麼時候候都有10名工人閒着沒活幹。

 

讀者可能已經想到，應該採用「流水做業法」，也就是說，首先由5名工人用刮板刮掉第1面牆上的舊漆(這時其他10名工人休息)，當第1面牆刮淨後，另外5名工人當即用刷子給這面牆刷新漆(與此同時拿刮板的5名工人轉去刮第2面牆上的舊漆)，一旦刮舊漆的工人轉到第3面牆並且刷新漆的工人轉到第2面牆之後，餘下的5名工人當即拿起刮刀去清除濺在第1面牆窗戶上的油漆，……。這樣安排每一個工人都有活幹，所以可以在較短的時間內完成任務。

 

假設木板房的第二、4兩面牆的長度比第一、3兩面牆的長度長一倍，此外，不一樣工做須要用的時間長短也不一樣，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)須要的時間最少。表13.5（見書305頁）列出了估計每道工序須要用的時間。能夠使用圖13.1中的Gantt圖描繪上述流水做業過程： 在時間爲零時開始刮第1面牆上的舊漆，兩小時後刮舊漆的工人轉去刮第2面牆，同時另5名工人開始給第1面牆刷新漆，每當給一面牆刷完新漆以後，第3組的5名工人當即清除濺在這面牆窗戶上的漆。從圖13.1能夠看出12小時後刮完全部舊漆，20小時後完成全部牆壁的刷漆工做，再過2小時後清理工做結束。所以所有工程在22小時後結束，若是用前述的第一種作法，則須要36小時。

 

圖13.1 舊木板房刷漆工程的Gantt圖

 

13.3.3  工程網絡

上一小節介紹的Gantt圖能很形象地描繪任務分解狀況，以及每一個子任務(做業)的開始時間和結束時間，所以是進度計劃和進度管理的有力工具。它具備直觀簡明和容易掌握、容易繪製的優勢，可是Gantt圖也有3個主要缺點：

(1) 不能顯式地描繪各項做業彼此間的依賴關係；

(2) 進度計劃的關鍵部分不明確，難於斷定哪些部分應當是主攻和主控的對象；

(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.3.4  估算工程進度

畫出相似圖13.2那樣的工程網絡以後，系統分析員就能夠藉助它的幫助估算工程進度了。爲此須要在工程網絡上增長一些必要的信息。

首先，把每一個做業估計須要使用的時間寫在表示該項做業的箭頭上方。注意，箭頭長度和它表明的做業持續時間沒有關係，箭頭僅表示依賴關係，它上方的數字才表示做業的持續時間。

其次，爲每一個事件計算下述兩個統計數字： 最先時刻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.5  關鍵路徑

圖13.3中有幾個事件的最先時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的做業(關鍵做業)的實際持續時間不能超過估計的持續時間，不然工程就不能準時結束。

工程項目的管理人員應該密切注視關鍵做業的進展狀況，若是關鍵事件出現的時間比預計的時間晚，則會使最終完成項目的時間拖後；若是但願縮短工期，只有往關鍵做業中增長資源纔會有效果。

 

13.3.6  機動時間

不在關鍵路徑上的做業有必定程度的機動餘地——實際開始時間能夠比預約時間晚一些，或者實際持續時間能夠比預約的持續時間長一些，而並不影響工程的結束時間。一個做業能夠有的所有機動時間等於它的結束事件的最遲時刻減去它的開始事件的最先時刻，再減去這個做業的持續時間：

機動時間=(LET)_結束-(EET)_開始-持續時間

對於前述油漆舊木板房的例子，計算獲得的非關鍵做業的機動時間列在表13.6（見書308頁）中。

在工程網絡中每一個做業的機動時間寫在表明該項做業的箭頭下面的括弧裏(參看圖13.3)。

在制定進度計劃時仔細考慮和利用工程網絡中的機動時間，每每可以安排出既節省資源又不影響最終竣工時間的進度表。在圖13.4中的Gantt圖描繪了其中的一種方案。

 

圖13.4 舊木板房刷漆工程改進的Gantt圖之一

 

這個簡單例子明顯說明了工程網絡比Gantt圖優越的地方： 它顯式地定義事件及做業之間的依賴關係，Gantt圖只能隱含地表示這種關係。可是Gantt圖的形式比工程網絡更簡單更直觀，爲更多的人所熟悉，所以，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。

 

以上經過舊木板房刷新漆工程的簡單例子，介紹了制訂進度計劃的兩個重要工具和方法。軟件工程項目雖然比這個簡單例子複雜得多，可是計劃和管理的基本方法仍然是自頂向下分解，也就是把項目分解爲若干個階段，每一個階段再分解成許多更小的任務，每一個任務又可進一步分解爲若干個步驟等等。這些階段、任務和步驟之間有複雜的依賴關係，所以，工程網絡和Gantt圖一樣是安排進度和管理工程進展狀況的強有力的工具。

 

第13.2節中介紹的工做量估計技術能夠幫助咱們估計每項任務的工做量，根據人力分配狀況，能夠進一步肯定每項任務的持續時間。從這些基本數據出發，根據做業之間的依賴關係，利用工程網絡和Gantt圖能夠制定出合理的進度計劃，而且可以科學地管理軟件開發工程的進展狀況。

 

13.4  人員組織

軟件項目成功的關鍵是有高素質的軟件開發人員。然而大多數軟件的規模都很大，單個軟件開發人員沒法在給按期限內完成開發工做，所以，必須把多名軟件開發人員合理地組織起來，使他們有效地分工協做共同完成開發工做。

爲了成功地完成軟件開發工做，項目組成員必須以一種有意義且有效的方式彼此交互和通訊。如何組織項目組是一個重要的管理問題，管理者應該合理地組織項目組，使項目組有較高生產率，可以按預約的進度計劃完成所承擔的工做。經驗代表，項目組組織得越好，其生產率越高，並且產品質量也越好。

除了追求更好的組織方式以外，每一個管理者的目標都是創建有凝聚力的項目組。一個有高度凝聚力的小組，由一批團結得很是緊密的人組成，他們的總體力量大於個體力量的總和。一旦項目組具備了凝聚力，成功的可能性就大大增長了。

現有的軟件項目組的組織方式不少，一般，組織軟件開發人員的方法，取決於所承擔的項目的特色、以往的組織經驗以及管理者的見解和喜愛。下面介紹3種典型的組織方式。

 

13.4.1  民主製程序員組

民主製程序員組的一個重要特色是，小組成員徹底平等，享有充分民主，經過協商作出技術決策。所以，小組成員之間的通訊是平行的，若是小組內有n個成員，則可能的通訊信道共有n(n-1)/2條。

程序設計小組的人數不能太多,不然組員間彼此通訊的時間將多於程序設計時間。此外,一般不能把一個軟件系統劃分紅大量獨立的單元,所以,若是程序設計小組人數太多,則每一個組員所負責開發的程序單元與系統其餘部分的界面將是複雜的,不只出現接口錯誤的可能性增長,並且軟件測試將既困難又費時間。

通常說來，程序設計小組的規模應該比較小,以2～8名成員爲宜。若是項目規模很大,用一個小組不能在預約時間內完成開發任務,則應該使用多個程序設計小組,每一個小組承擔工程項目的一部分任務，在必定程度上獨立自主地完成各自的任務。系統的整體設計應該可以保證由各個小組負責開發的各部分之間的接口是良好定義的,而且是儘量簡單的。

小組規模小,不只能夠減小通訊問題,並且還有其餘好處。例如,容易肯定小組的質量標準,並且用民主方式肯定的標準更容易被你們遵照;組員間關係密切,可以互相學習等等。

民主製程序員組一般採用非正式的組織方式，也就是說，雖然名義上有一個組長，可是他和組內其餘成員完成一樣的任務。在這樣的小組中，由全體討論協商決定應該完成的工做，而且根據每一個人的能力和經驗分配適當的任務。

民主製程序員組的主要優勢是，組員們對發現程序錯誤持積極的態度，這種態度有助於更快速地發現錯誤，從而致使高質量的代碼。

民主製程序員組的另外一個優勢是，組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利於攻克技術難關。所以，當有難題須要解決時，也就是說，當所要開發的軟件的技術難度較高時，採用民主製程序員組是適宜的。

若是組內多數成員是經驗豐富技術熟練的程序員,那麼上述非正式的組織方式可能會很是成功。在這樣的小組內組員享有充分民主,經過協商,在自願的基礎上做出決定,所以可以加強團結、提升工做效率。可是,若是組內多數成員技術水平不高,或是缺少經驗的新手,那麼這種非正式的組織方式也有嚴重缺點： 因爲沒有明確的權威指導開發工程的進行,組員間將缺少必要的協調,最終可能致使工程失敗。

爲了使少數經驗豐富、技術高超的程序員在軟件開發過程當中可以發揮更大做用，程序設計小組也能夠採用下一小節中介紹的另一種組織形式。

 

13.4.2  主程序員組

美國IBM公司在20世紀70年代初期開始採用主程序員組的組織方式。採用這種組織方式主要出於下述幾點考慮：

(1) 軟件開發人員多數比較缺少經驗；

(2) 程序設計過程當中有許多事務性的工做，例如，大量信息的存儲和更新；

(3) 多渠道通訊很費時間，將下降程序員的生產率。

 

主程序員組用經驗多、技術好、能力強的程序員做爲主程序員，同時，利用人和計算機在事務性工做方面給主程序員提供充分支持，並且全部通訊都經過一兩我的進行。這種組織方式相似於外科手術小組的組織： 主刀大夫對手術全面負責，而且完成制訂手術方案、開刀等關鍵工做，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工做。此外，必要時手術組還要請其餘領域的專家（例如，心臟科醫生或婦產科醫生）協助。

 

上述比喻突出了主程序員組的兩個重要特性：

（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 包含分散決策的組織方式

 

13.5  質量保證  

13.5.1  軟件質量

歸納地說，軟件質量就是「軟件與明確地和隱含地定義的需求相一致的程度」。更具體地說，軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具備的隱含特徵相一致的程度。上述定義強調了下述的3個要點：

（1） 軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。

（2） 指定的開發標準定義了一組指導軟件開發的準則，若是沒有遵照這些準則，幾乎確定會致使軟件質量不高。

（3） 一般，有一組沒有顯式描述的隱含需求（例如，軟件應該是容易維護的）。若是軟件知足明確描述的需求，但卻不知足隱含的需求，那麼軟件的質量仍然是值得懷疑的。

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

本節介紹影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。能夠把這些質量因素分紅3組，分別反映用戶在使用軟件產品時的3種不一樣傾向或觀點。這3種傾向是： 產品運行、產品修改和產品轉移。圖13.9描繪了軟件質量因素和上述3種傾向(或產品活動)之間的關係，表13.7（見書315頁）列出了軟件質量因素的簡明定義。

 

圖13.9 軟件質量因素與產品活動的關係

 

13.5.2  軟件質量保證措施

軟件質量保證（software quality assurance,SQA）的措施主要有：  基於非執行的測試（也稱爲複審或評審），基於執行的測試（即之前講過的軟件測試）和程序正確性證實。複審主要用來保證在編碼以前各階段產生的文檔的質量；基於執行的測試須要在程序編寫出來以後進行，它是保證軟件質量的最後一道防線；程序正確性證實使用數學方法嚴格驗證程序是否與對它的說明徹底一致。

 

參加軟件質量保證工做的人員，能夠劃分紅下述兩類：

軟件工程師經過採用先進的技術方法和度量，進行正式的技術複審以及完成計劃周密的軟件測試來保證軟件質量。

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  軟件配置管理

任何軟件開發都是迭代過程，也就是說，在設計過程會發現需求說明書中的問題，在實現過程又會暴露出設計中的錯誤。此外，隨着時間推移客戶的需求也會或多或少發生變化。所以，在開發軟件的過程當中，變化（或稱爲變更）既是必要的，又是不可避免的。可是，變化也很容易失去控制，若是不能適當地控制和管理變化，勢必形成混亂併產生許多嚴重的錯誤。

軟件配置管理是在軟件的整個生命期內管理變化的一組活動。具體地說，這組活動用來： 

①標識變化； ②控制變化； ③確保適當地實現了變化； ④向須要知道這類信息的人報告變化。

軟件配置管理不一樣於軟件維護。維護是在軟件交付給用戶使用後才發生的，而配置管理是在軟件項目啓動時就開始，而且一直持續到軟件退役後才終止的一組跟蹤和控制活動。
軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減小所需花費的工做量。

13.6.1  軟件配置

1. 軟件配置項

軟件過程的輸出信息能夠分爲3類： 

①計算機程序（源代碼和可執行程序）； ②描述計算機程序的文檔（供技術人員或用戶使用）； ③數據（程序內包含的或在程序外的）。 上述這些項組成了在軟件過程當中產生的所有信息，咱們把它們統稱爲軟件配置，而這些項就是軟件配置項。

隨着軟件開發過程的進展，軟件配置項的數量迅速增長。不幸的是，因爲前述的種種緣由，軟件配置項的內容隨時均可能發生變化。爲了開發出高質量的軟件產品，軟件開發人員不只要努力保證每一個軟件配置項正確，並且必須保證一個軟件的全部配置項是徹底一致的。

能夠把軟件配置管理看做是應用於整個軟件過程的軟件質量保證活動，是專門用於管理變化的軟件質量保證活動。

 

2. 基線

基線是一個軟件配置管理概念，它有助於咱們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義爲： 已經經過了正式複審的規格說明或中間產品，它能夠做爲進一步開發的基礎，而且只有經過正式的變化控制過程才能改變它。
簡而言之，基線就是經過了正式複審的軟件配置項。在軟件配置項變成基線以前，能夠迅速而非正式地修改它。一旦創建了基線以後，雖然仍然能夠實現變化，可是，必須應用特定的、正式的過程（稱爲規程）來評估、實現和驗證每一個變化。
除了軟件配置項以外，許多軟件工程組織也把軟件工具置於配置管理之下，也就是說，把特定版本的編輯器、編譯器和其餘CASE工具，做爲軟件配置的一部分「固定」下來。由於當修改軟件配置項時必然要用到這些工具，爲防止不一樣版本的工具產生的結果不一樣，應該把軟件工具也基線化，而且列入到綜合的配置管理過程之中。

 

13.6.2  軟件配置管理過程

軟件配置管理是軟件質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各類版本的標識、軟件配置審計以及對軟件配置發生的任何變化的報告。
具體來講，軟件配置管理主要有5項任務：  標識、版本控制、變化控制、配置審計和報告。

1. 標識軟件配置中的對象

爲了控制和管理軟件配置項，必須單獨命名每一個配置項，而後用面向對象方法組織它們。能夠標識出兩類對象：  基本對象和彙集對象（能夠把彙集對象做爲表明軟件配置完整版本的一種機制）。基本對象是軟件工程師在分析、設計、編碼或測試過程當中建立出來的「文本單元」，例如，需求規格說明的一個段落、一個模塊的源程序清單或一組測試用例。彙集對象是基本對象和其餘彙集對象的集合。
每一個對象都有一組能唯一地標識它的特徵：  名字、描述、資源表和「實現」。其中，對象名是無二義性地標識該對象的一個字符串。
在設計標識軟件對象的模式時，必須認識到對象在整個生命週期中一直都在演化，所以，所設計的標識模式必須能無歧義地標識每一個對象的不一樣版本。

2. 版本控制

版本控制聯合使用規程和工具，以管理在軟件工程過程當中所建立的配置對象的不一樣版本。藉助於版本控制技術，用戶可以經過選擇適當的版原本指定軟件系統的配置。實現這個目標的方法是，把屬性和軟件的每一個版本關聯起來，而後經過描述一組所指望的屬性來指定和構造所須要的配置。
上面提到的「屬性」，既能夠簡單到僅是賦給每一個配置對象的具體版本號，也能夠複雜到是一個布爾變量串，其指明瞭施加到系統上的功能變化的具體類型。
非發行版本，只要變化的版本，每一版不能覆蓋

3. 變化控制

對於大型軟件開發項目來講，無控制的變化將迅速致使混亂。變化控制把人的規程和自動工具結合起來，以提供一個控制變化的機制。典型的變化控制過程以下：  接到變化請求以後，首先評估該變化在技術方面的得失、可能產生的反作用、對其餘配置對象和系統功能的總體影響以及估算出的修改爲本。評估的結果造成「變化報告」，該報告供「變化控制審批者」審閱。所謂變化控制審批者既能夠是一我的也能夠由一組人組成，其對變化的狀態和優先級作最終決策。

爲每一個被批准的變化都生成一個「工程變化命令」，其描述將要實現的變化，必須遵照的約束以及複審和審計的標準。把要修改的對象從項目數據庫中「提取（check out）」出來【給遷出項目對象加鎖，其餘人不能修改】，進行修改並應用適當的SQA活動。最後，把修改後的對象「提交（check in）」進數據庫【解鎖，其餘人能夠修改】，並用適當的版本控制機制建立該軟件的下一個版本。
「提交」和「提取」過程實現了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪一個軟件工程師有權訪問和修改一個特定的配置對象，同步控制有助於保證由兩名不一樣的軟件工程師完成的並行修改不會相互覆蓋。

在一個軟件配置項變成基線以前，僅需應用非正式的變化控制。該配置對象的開發者能夠對它進行任何合理的修改（只要修改不會影響到開發者工做範圍以外的系統需求）。一旦該對象通過了正式技術複審並得到批准，就建立了一個基線。而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制。如今，爲了進行修改開發者必須得到項目管理者的批准（若是變化是「局部的」），若是變化影響到其餘軟件配置項，還必須獲得變化控制審批者的批准。在某些狀況下，能夠省略正式的變化請求、變化報告和工程變化命令，可是，必須評估每一個變化而且跟蹤和複審全部變化。

4. 配置審計
爲了確保適當地實現了所須要的變化，一般從下述兩方面採起措施：  ①正式的技術複審； ②軟件配置審計。
正式的技術複審（見13.5.2節）關注被修改後的配置對象的技術正確性。複審者審查該對象以肯定它與其餘軟件配置項的一致性，並檢查是否有遺漏或反作用。

軟件配置審計經過評估配置對象的那些一般不在複審過程當中考慮的特徵（例如，修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明瞭所作的修改，是否註明了修改日期和修改者，是否適當地更新了全部相關的軟件配置項，是否遵循了標註變化、記錄變化和報告變化的規程），而成爲對正式技術複審的補充。

 

5. 狀態報告
書寫配置狀態報告是軟件配置管理的一項任務，它回答下述問題：  ①發生了什麼事？ ②誰作的這件事？③這件事是何時發生的？④它將影響哪些其餘事物？
配置狀態變化對大型軟件開發項目的成功有重大影響。當大量人員在一塊兒工做時，可能一我的並不知道另外一我的在作什麼。兩名開發人員可能試圖按照相互衝突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾我的月的工做量根據過期的硬件規格說明開發軟件；察覺到所建議的修改有嚴重反作用的人可能還不知道該項修改正在進行。配置狀態報告經過改善全部相關人員之間的通訊，幫助消除這些問題。

 

13.7  能力成熟度模型

美國卡內基梅隆大學軟件工程研究所在美國國防部資助下於20世紀80年代末創建的能力成熟度模型（capability maturity model，CMM)，是用於評價軟件機構的軟件過程能力成熟度的模型。最初，創建此模型的目的主要是，爲大型軟件項目的招投標活動提供一種全面而客觀的評審依據，發展到後來，此模型又同時被應用於許多軟件機構內部的過程改進活動中。

多年來，軟件危機一直困擾着許多軟件開發機構。很多人試圖經過採用新的軟件開發技術來解決在軟件生產率和軟件質量等方面存在的問題，但效果並不使人十分滿意。上述事實促令人們進一步考察軟件過程，從而發現關鍵問題在於對軟件過程的管理不盡人意。事實證實，在無規則和混亂的管理之下，先進的技術和工具並不能發揮出應有的做用。人們逐漸認識到，改進對軟件過程的管理是消除軟件危機的突破口，不再能忽視在軟件過程當中管理的關鍵做用了。

能力成熟度模型的基本思想是，因爲問題是由咱們管理軟件過程的方法不當引發的，因此新軟件技術的運用並不會自動提升軟件的生產率和質量。能力成熟度模型有助於軟件開發機構創建一個有規律的、成熟的軟件過程。改進後的軟件過程將開發出質量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。

軟件過程包括各類活動、技術和工具，所以，它實際上既包括了軟件開發的技術方面又包括了管理方面。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級的所有特徵。

這一級的軟件機構能夠經過對過程實例性能的分析和肯定產生某一缺陷的緣由，來防止再次出現這種類型的缺陷；經過對任何一個過程實例的分析所得到的經驗教訓均可以成爲該軟件機構優化其過程模型的有效依據，從而使其餘項目的過程實例獲得優化。這樣的軟件機構能夠經過從過程實施中得到的定量的反饋信息，在採用新思想和新技術的同時測試它們，以不斷地改進和優化軟件過程。

處於5級成熟度的軟件機構的過程能力能夠歸納爲，軟件過程是可優化的。這一級的軟件機構可以持續不斷地改進其過程能力，既對現行的過程實例不斷地改進和優化，又藉助於所採用的新技術和新方法來實現將來的過程改進。
一些統計數字代表，提升一個完整的成熟度等級大約須要花18個月到3年的時間，可是從第1級上升到第2級有時要花3年甚至5年時間。這說明要向一個迄今仍處於混亂的和被動的行動方式的軟件機構灌輸系統化的方式，將多麼困難。

 

13.8  小結

 

軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合的產物。只有在科學而嚴格的管理之下，先進的技術方法和優秀的軟件工具才能真正發揮出威力。所以，有效的管理是大型軟件工程項目成功的關鍵。
軟件項目管理始於項目計劃，而第一項計劃活動就是估算。爲了估算項目工做量和完成期限，首先須要預測軟件規模。

度量軟件規模的經常使用技術主要有代碼行技術和功能點技術。這兩種技術各有優缺點，應該根據項目特色及從事計劃工做的人對這兩種技術的熟悉程度，選用適用的技術。

根據軟件規模能夠估算出完成該項目所需的工做量，經常使用的估算模型爲靜態單變量模型、動態多變量模型和COCOMO2模型。爲了使估算結果更接近實際值，一般至少同時使用上述3種模型中的兩種。經過比較和協調使用不一樣模型得出的估算值，有可能獲得比較準確的估算結果。成本估算模型一般也同時提供了估算軟件開發時間的方程式，這樣估算出的開發時間是正常開發時間，經驗代表，用增長開發人員的方法最多能夠把開發時間減小到正常開發時間的75%。

 

管理者必須制定出一個足夠詳細的進度表，以便監督項目進度並控制整個項目。經常使用的制定進度計劃的工具備Gantt圖和工程網絡，這兩種工具各有優缺點，一般，聯合使用Gantt圖和工程網絡來制定進度計劃並監督項目進展情況。
高素質的開發人員和合理的項目組組織結構，是軟件項目取得成功的關鍵。比較典型的組織結構有民主製程序員組、主程序員組和現代程序員組等3種，這3種組織方式的適用場合並不相同。

 

軟件質量保證是在軟件過程當中的每一步都進行的活動。軟件質量保證措施主要有基於非執行的測試（也稱爲複審）、基於執行的測試（即一般所說的測試）和程序正確性證實。軟件複審是最重要的軟件質量保證活動之一，它的優勢是在改正錯誤的成本相對比較低時就能及時發現並排除軟件錯誤。
軟件配置管理是應用於整個軟件過程當中的保護性活動，是在軟件整個生命期內管理變化的一組活動。軟件配置管理的目標是，使變化可以更正確且更容易被適應，在須要修改軟件時減小爲此而花費的工做量。

能力成熟度模型（CMM）是改進軟件過程的有效策略。它的基本思想是，由於問題是管理軟件過程的方法不恰當形成的，因此採用新技術並不會自動提升軟件生產率和軟件質量，應該下大力氣改進對軟件過程的管理。事實上對軟件過程的改進不可能一蹴而就，所以，CMM以增量方式逐步引入變化，它明確地定義了5個成熟度等級，一個軟件開發組織能夠用一系列小的改良性步驟邁入更高的成熟度等級。