第13章-軟件項目管理

第十章軟件項目管理10.1估算軟件規(guī)模10.2工作量估算10.3進度計劃10.4人員組織10.5軟件配置管理10.6能力成熟度模型CMM第10章軟件項目管理項目管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到項目既定目標的過程。軟件項目管理先于任何技術活動之前開始，并且貫穿于軟件的整個生命周期之中。軟件項目管理過程源于項目計劃，主要活動是“估算”。軟件計劃詳盡地描述了軟件過程，包括采用的生命周期模型、開發(fā)組織結構、責任分配、管理目標和優(yōu)先級、所用技術和CASE工具，以及詳細的進度、預算和資源分配。整個計劃的基礎是工作量估算和完成期限估算。PSP訓練軟件度量技術代碼行技術:是一種比較簡單的定量估算軟件規(guī)模的方法。根據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)，估計實現(xiàn)一個功能需要的源程序行數(shù)。把實現(xiàn)每個功能需要的源程序行數(shù)累加起來，就得到實現(xiàn)整個軟件需要的源程序行數(shù)。用代碼行技術度量軟件規(guī)模時，當程序較小時常用的單位是代碼行數(shù)(LOC)，當程序較大時常用的單位是千行代碼數(shù)(KLOC)。為了使得對程序規(guī)模的估計值更接近實際值，可以由多名有經(jīng)驗的軟件工程師分別作出估計。每個人都估計程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m)，分別算出這三種規(guī)模的平均值a，b，和m之后，再用下式計算程序規(guī)模的估計值：----PERT技術優(yōu)點:主要是代碼是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算代碼行數(shù)。缺點是：源程序僅是軟件配置的一個成分，用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同；用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理；這種方法不適用于非過程語言。為了克服代碼行技術的缺點，人們又提出了功能點技術?！霉δ茳c（FP）為單位度量軟件規(guī)模1.信息域特性功能點技術定義了信息域的5個特性，分別是輸入項數(shù)(Inp)、輸出項數(shù)(Out)、查詢數(shù)(Inq)、主文件數(shù)(Maf)和外部接口數(shù)(Inf)。功能點技術：依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模。（1）輸入項數(shù)：用戶向軟件輸入的項數(shù)，這些輸入給軟件提供面向應用的數(shù)據(jù)。輸入不同于查詢，后者單獨計數(shù)，不計入輸入項數(shù)中。（2）輸出項數(shù)：軟件向用戶輸出的項數(shù)，它們向用戶提供面向應用的信息，例如，報表和出錯信息等。報表內的數(shù)據(jù)項不單獨計數(shù)。（3）查詢數(shù)：查詢即是一次聯(lián)機輸入，它導致軟件以聯(lián)機輸出方式產(chǎn)生某種即時響應。（4）主文件數(shù)：邏輯主文件（即數(shù)據(jù)的一個邏輯組合，它可能是大型數(shù)據(jù)庫的一部分或是一個獨立的文件）的數(shù)目。（5）外部接口數(shù)：機器可讀的全部接口（例如磁盤或磁帶上的數(shù)據(jù)文件）的數(shù)量，用這些接口把信息傳送給另一個系統(tǒng)。2.估算功能點的步驟估算出一個軟件的功能點數(shù)（即軟件規(guī)模）：（1）計算未調整的功能點數(shù)CT把產(chǎn)品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或復雜級，并根據(jù)其等級為每個特性分配一個功能點數(shù)（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個復雜級的輸入項分配6個功能點）。未調整的功能點數(shù)UFP：CT=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系數(shù)，其值由相應特性的復雜級別決定。(2)計算技術復雜性因子TCF這一步驟度量14種技術因素對軟件規(guī)模的影響程度。這些因素包括高處理率、性能標準（例如，響應時間）、聯(lián)機更新等，用Fi(1≤i≤14)代表這些因素。根據(jù)軟件的特點，為每個因素分配一個從0（不存在或對軟件規(guī)模無影響）到5（有很大影響）的值。技術因素對軟件規(guī)模的綜合影響程度DI：

DI=技術復雜性因子TCF由下式計算：TCF=0.65+0.01×DI因為DI的值在0~70之間，所以TCF的值在0.65~1.35之間。（3）計算功能點數(shù)FPFP=CT×TCF功能點數(shù)與所用的編程語言無關，看起來功能點技術比代碼行技術更合理一些。但是，在判斷信息域特性復雜級別和技術因素的影響程度時，存在著相當大的主觀因素。軟件估算模型使用由經(jīng)驗導出的公式來預測軟件開發(fā)工作量，工作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位通常是人月（pm)。由于支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境。10.2工作量估算這類模型的總體結構形式如下：E=A+B×(ev)C其中，A、B和C是由經(jīng)驗數(shù)據(jù)導出的常數(shù)，E是以人月為單位的工作量，ev是估算變量（KLOC或FP）。下面給出幾個典型的靜態(tài)單變量模型。面向KLOC的估算模型(1)Walston_Felix模型E=5.2×(KLOC)0.91(2)Bailey_Basili模型E=5.5+0.73×(KLOC)1.1610.2.1靜態(tài)單變量模型可以看出，對于相同的KLOC或FP值，用不同模型估算將得出不同的結果。主要原因是，這些模型多數(shù)都是僅根據(jù)若干應用領域中有限個項目的經(jīng)驗數(shù)據(jù)推導出來的，適用范圍有限。因此，必須根據(jù)當前項目的特點選擇適用的估算模型，并且根據(jù)需要適當?shù)卣{整（例如，修改模型常數(shù)）估算模型。

1981年Boehm在《軟件工程經(jīng)濟學》中首次提出了COCOMO模型，COCOMO是構造性成本模型（ConstructiveCostModel)的英文縮寫。1997年Boehm等人提出的COCOMO2模型，是原COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經(jīng)驗。COCOMO2給出了3個層次的軟件開發(fā)工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節(jié)考慮的詳盡程度逐級增加。10.2.2COCOMO2模型這3個層次的估算模型分別是：（1）應用系統(tǒng)組成模型。這個模型主要用于估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。（2）早期設計模型。這個模型適用于體系結構設計階段。（3）后體系結構模型。這個模型適用于完成體系結構設計之后的軟件開發(fā)階段。下面以后體系結構模型為例，介紹COCOMO2模型。該模型把軟件開發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)：E= (3)其中，E是開發(fā)工作量（以人月為單位），

a是模型系數(shù)，KLOC是估計的源代碼行數(shù)，

b是模型指數(shù)，

fi(i=1~17)是成本因素。每個成本因素都根據(jù)它的重要程度和對工作量影響大小被賦予一定數(shù)值（稱為工作量系數(shù)）。Boehm把成本因素劃分成產(chǎn)品因素、平臺因素、人員因素和項目因素等4類。

與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化:（1）新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點開發(fā)。這個變化表明，這些因素對開發(fā)成本的影響日益增加。（2）略去了原始模型中的2個成本因素（計算機切換時間和使用現(xiàn)代程序設計實踐）。（3）某些成本因素（分析員能力、平臺經(jīng)驗、語言和工具經(jīng)驗）對生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。為了確定工作量方程中模型指數(shù)b的值，原始的COCOMO模型把軟件開發(fā)項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應的b值（分別是1.05，1.12和1.20）。COCOMO2采用了更加精細得多的b分級模型，這個模型使用5個分級因素Wi(1≤i≤5),其中每個因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個級別，然后用下式計算b的數(shù)值：b= (4)因此，b的取值范圍為1.01~1.26。顯然，這種分級模式比原始COCOMO模型的分級模式更精細、更靈活。COCOMO2使用的5個分級因素如下所述：（1）項目先例性。這個分級因素指出，對于開發(fā)組織來說該項目的新奇程度。諸如開發(fā)類似系統(tǒng)的經(jīng)驗，需要創(chuàng)新體系結構和算法，以及需要并行開發(fā)硬件和軟件等因素的影響，都體現(xiàn)在這個分級因素中。（2）開發(fā)靈活性。這個分級因素反映出，為了實現(xiàn)預先確定的外部接口需求及為了及早開發(fā)出產(chǎn)品而需要增加的工作量。（3）風險排除度。這個分級因素反映了重大風險已被消除的比例。在多數(shù)情況下，這個比例和指定了重要模塊接口（即選定了體系結構）的比例密切相關。（4）項目組凝聚力。這個分級因素表明了開發(fā)人員相互協(xié)作時可能存在的困難。這個因素反映了開發(fā)人員在目標和文化背景等方面相一致的程度，以及開發(fā)人員組成一個小組工作的經(jīng)驗。（5）過程成熟度。這個分級因素反映了按照能力成熟度模型度量出的項目組織的過程成熟度。在原始的COCOMO模型中，僅粗略地考慮了前兩個分級因素對指數(shù)b之值的影響。工作量方程中模型系數(shù)a的典型值為3.0，在實際工作中應該根據(jù)歷史經(jīng)驗數(shù)據(jù)確定一個適合本組織當前開發(fā)的項目類型的數(shù)值。

不論從事哪種技術性項目，實際情況都是，在實現(xiàn)一個大目標之前往往要把它分解成一系列的比較容易管理的子項目（也稱為作業(yè)）。這些任務中有一些是處于“關鍵路徑”之外的，其完成時間如果沒有嚴重拖后，就不會影響整個項目的完成時間；其他任務則處于關鍵路徑之中，如果這些“關鍵任務”的進度拖后，則整個項目的完成日期就會拖后，管理人員應該高度關注關鍵任務的進展情況。

項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發(fā)現(xiàn)拖延進度的情況。為達到上述目標，管理者必須制定一個足夠詳細的進度表，以便監(jiān)督項目進度并控制整個項目。10.3進度計劃Gantt（甘特）圖是歷史悠久、應用廣泛的制定進度計劃的工具，下面通過一個非常簡單的例子介紹這種工具。假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限：只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。怎樣安排才能使工作進行得更有效呢?10.3.1Gantt圖一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法，因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時候都有10名工人閑著沒活干。讀者可能已經(jīng)想到，應該采用“流水作業(yè)法”，也就是說，首先由5名工人用刮板刮掉第1面墻上的舊漆(這時其余10名工人休息)，當?shù)?面墻刮凈后，另外5名工人立即用刷子給這面墻刷新漆(與此同時拿刮板的5名工人轉去刮第2面墻上的舊漆)，一旦刮舊漆的工人轉到第3面墻而且刷新漆的工人轉到第2面墻以后，余下的5名工人立即拿起刮刀去清除濺在第1面墻窗戶上的油漆，……。這樣安排每個工人都有活干，因此能夠在較短的時間內完成任務。假設木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時間最少?？梢允褂脠D1中的Gantt圖描繪上述流水作業(yè)過程：在時間為零時開始刮第1面墻上的舊漆，兩小時后刮舊漆的工人轉去刮第2面墻，同時另5名工人開始給第1面墻刷新漆，每當給一面墻刷完新漆之后，第3組的5名工人立即清除濺在這面墻窗戶上的漆。從圖1可以看出12小時后刮完所有舊漆，20小時后完成所有墻壁的刷漆工作，再過2小時后清理工作結束。因此全部工程在22小時后結束，如果用前述的第一種做法，則需要36小時。工序墻面刮舊漆刷新漆清理1或32312或4462圖9.1舊木板房刷漆工程的Gantt圖刮第1面墻柒第1面墻刮第3面墻柒第3面墻刮第2面墻刮第4面墻柒第2面墻柒第4面墻Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業(yè))的開始時間和結束時間，因此,它是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是Gantt圖也有3個主要缺點：(1)不能顯式地描繪各項作業(yè)彼此間的依賴關系；(2)進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象；(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。10.3.3工程網(wǎng)絡當把一個工程項目分解成許多子任務，它們彼此間的依賴關系又比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。工程網(wǎng)絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業(yè)的開始時間和結束時間，此外，它還顯式地描繪各個作業(yè)彼此間的依賴關系。因此，工程網(wǎng)絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。圖9.2舊木板房刷漆工程的工程網(wǎng)絡畫出類似圖2那樣的工程網(wǎng)絡之后，系統(tǒng)分析員就可以借助它的幫助估算工程進度了。為此需要在工程網(wǎng)絡上增加一些必要的信息。首先，把每個作業(yè)估計需要使用的時間寫在表示該項作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時間沒有關系，箭頭僅表示依賴關系，它上方的數(shù)字才表示作業(yè)的持續(xù)時間。10.3.4估算工程進度其次，為每個事件計算下述兩個統(tǒng)計數(shù)字：最早時刻EET和最遲時刻LET。這兩個數(shù)字將分別寫在表示事件的圓圈的右上角和右下角，如圖3左下角的符號所示。事件的最早時刻是該事件可以發(fā)生的最早時間。通常工程網(wǎng)絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網(wǎng)絡上從左至右按事件發(fā)生順序計算。計算最早時刻EET使用下述3條簡單規(guī)則：圖13.3舊木板房刷漆工程的完整的工程網(wǎng)絡(1)考慮進入該事件的所有作業(yè)；(2)對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和；(3)選取上述和數(shù)中的最大值作為該事件的最早時刻EET按照這種方法，不難沿著工程網(wǎng)絡從左至右順序算出每個事件的最早時刻，計算結果標在圖3的工程網(wǎng)絡中(每個圓圈內右上角的數(shù)字)。事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。按慣例，最后一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網(wǎng)絡上從右至左按逆作業(yè)流的方向計算。計算最遲時刻LET使用下述3條規(guī)則：(1)考慮離開該事件的所有作業(yè)；(2)從每個作業(yè)的結束事件的最遲時刻中減去該作業(yè)的持續(xù)時間；(3)選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。圖10.3中有幾個事件的最早時刻和最遲時刻相同，這些事件即為關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。關鍵路徑上的事件(關鍵事件)必須準時發(fā)生，組成關鍵路徑的作業(yè)(關鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準時結束。工程項目的管理人員應該密切注視關鍵作業(yè)的進展情況，如果關鍵事件出現(xiàn)的時間比預計的時間晚，則會使最終完成項目的時間拖后；如果希望縮短工期，只有往關鍵作業(yè)中增加資源才會有效果。10.3.5關鍵路徑不在關鍵路徑上的作業(yè)有一定程度的機動余地——實際開始時間可以比預定時間晚一些，或者實際持續(xù)時間可以比預定的持續(xù)時間長一些，而并不影響工程的結束時間。

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

機動時間=(LET)結束-持續(xù)時間-(EET)開始10.3.6機動時間圖13.4舊木板房刷漆工程改進的Gantt圖之一工程網(wǎng)絡比Gantt圖優(yōu)越的地方：它顯式地定義事件及作業(yè)之間的依賴關系，Gantt圖只能隱含地表示這種關系。但是Gantt圖的形式比工程網(wǎng)絡更簡單更直觀，為更多的人所熟悉，因此，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。

總之,工作量估計技術可以幫助我們估計每項任務的工作量，根據(jù)人力分配情況，可以進一步確定每項任務的持續(xù)時間。從這些基本數(shù)據(jù)出發(fā)，根據(jù)作業(yè)之間的依賴關系，利用工程網(wǎng)絡和Gantt圖可以制定出合理的進度計劃，并且能夠科學地管理軟件開發(fā)工程的進展情況。軟件項目成功的關鍵是有高素質的軟件開發(fā)人員。然而大多數(shù)軟件的規(guī)模都很大，單個軟件開發(fā)人員無法在給定期限內完成開發(fā)工作，因此，必須把多名軟件開發(fā)人員合理地組織起來，使他們有效地分工協(xié)作共同完成開發(fā)工作。經(jīng)驗表明，項目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)品質量也越好。除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。一個有高度凝聚力的小組，由一批團結得非常緊密的人組成，他們的整體力量大于個體力量的總和。一旦項目組具有了凝聚力，成功的可能性就大大增加了。10.4人員組織其特點是，小組成員完全平等，享有充分民主，通過協(xié)商做出技術決策。因此，小組成員之間的通信是平行的，如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。

程序設計小組的人數(shù)不能太多,否則組員間彼此通信的時間將多于程序設計時間。此外,通常不能把一個軟件系統(tǒng)劃分成大量獨立的單元,因此,如果程序設計小組人數(shù)太多,則每個組員所負責開發(fā)的程序單元與系統(tǒng)其他部分的界面將是復雜的,不僅出現(xiàn)接口錯誤的可能性增加,而且軟件測試將既困難又費時間。10.4.1民主制程序員組優(yōu)點:組員們對發(fā)現(xiàn)程序錯誤持積極的態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導致高質量的代碼。組員們享有充分民主，小組有高度凝聚力，組內學術空氣濃厚，有利于攻克技術難關。因此，當有難題需要解決時，也就是說，當所要開發(fā)的軟件的技術難度較高時，采用民主制程序員組是適宜的。缺點：

由于沒有明確的權威指導開發(fā)工程的進行,組員間將缺乏必要的協(xié)調,最終可能導致工程失敗。為了使少數(shù)經(jīng)驗豐富、技術高超的程序員在軟件開發(fā)過程中能夠發(fā)揮更大作用，程序設計小組也可以采用下一小節(jié)中介紹的另外一種組織形式。美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮：(1)軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗；(2)程序設計過程中有許多事務性的工作，例如大量信息的存儲和更新；(3)多渠道通信很費時間，將降低程序員的生產(chǎn)率。10.4.2主程序員組主程序員組用經(jīng)驗多、技術好、能力強的程序員作為主程序員，同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個人進行。這種組織方式類似于外科手術小組組織：主刀大夫對手術全面負責，并且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協(xié)助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫(yī)生或婦產(chǎn)科醫(yī)生）協(xié)助。主程序員組的兩個重要特性：（1）專業(yè)化，該組每名成員僅完成他們受過專業(yè)訓練的那些工作。（2）層次性，主刀大夫指揮每名組員工作，并對手術全面負責。典型的主程序員組的組織形式如圖9.5所示。該組由主程序員、后備程序員、編程秘書以及1~3名程序員組成。在必要的時候，該組還有其他領域的專家協(xié)助。圖11.1主程序員組的結構主程序員組核心人員的分工如下所述：（1）主程序員既是成功的管理人員又是經(jīng)驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分（或復雜部分）的詳細設計，并且負責指導其他程序員完成詳細設計和編碼工作。所有接口問題都由主程序員處理。主程序員對每行代碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。

（2）后備程序員也應該技術熟練而且富于經(jīng)驗，他協(xié)助主程序員工作并且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。因此，后備程序員必須在各方面都和主程序員一樣優(yōu)秀，并且對本項目的了解也應該和主程序員一樣深入。平時，后備程序員的工作主要是，設計測試方案、分析測試結果及獨立于設計過程的其他工作。（3）編程秘書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執(zhí)行源程序和測試用例。主程序員應該是高級程序員和優(yōu)秀管理者的結合體,承擔主程序員工作需要同時具備這兩方面的才能。其次后備程序員更難找。人們期望后備程序員像主程序員一樣優(yōu)秀，但是，他們必須坐在“替補席”上，拿著較低的工資等待隨時接替主程序員的工作。幾乎沒有一個高級程序員或高級管理人員愿意接受這樣的工作。第三，編程秘書也很難找到。專業(yè)的軟件技術人員一般都厭煩日常的事務性工作，但是，人們卻期望編程秘書整天只干這類工作。我們需要一種更合理、更現(xiàn)實的組織程序員組的方法，這種方法應該能充分結合民主制程序員組和主程序員組的優(yōu)點，并且能用于實現(xiàn)更大規(guī)模的軟件產(chǎn)品。優(yōu)點：小組成員都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。但是，使用主程序員組的組織方式時，主程序員對每行代碼的質量負責，因此，他必須參與所有代碼審查工作。由于主程序員同時又是負責對小組成員進行評價的管理員，他參與代碼審查工作就會把所發(fā)現(xiàn)的程序錯誤與小組成員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯誤的心理。10.4.3現(xiàn)代程序員組解決方法:取消主程序員的大部分行政管理工作。前面已經(jīng)指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發(fā)現(xiàn)程序錯誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實際的“主程序員”應該由兩個人共同擔任：一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術性事務的管理決策。這樣的組織結構如圖9.6所示。技術組長自然要參與全部代碼審查工作，因為他要對代碼的各方面質量負責；相反，行政組長不可以參與代碼審查工作，因為他的職責是對程序員的業(yè)績進行評價。行政組長應該在常規(guī)調度會議上了解每名組員的技術能力和工作業(yè)績。圖11.2現(xiàn)代程序員組的結構

在開始工作之前明確劃分技術組長和行政組長的管理權限是很重要的。但是，即使已經(jīng)做了明確分工，有時也會出現(xiàn)職責不清的矛盾。例如，考慮年度休假問題，行政組長有權批準某個程序員休年假的申請，因為這是一個非技術性問題，但是技術組長可能馬上否決了這個申請，因為已經(jīng)接近預定的項目結束日期，目前人手非常緊張。解決這類問題的辦法是求助于更高層的管理人員w為行政組長和技術組長都認為是屬于自己職責范圍內的事務，制定一個處理方案。圖11.3大型項目的技術管理組織結構程序員組成員人數(shù)不宜過多，當軟件項目規(guī)模較大時，應該把程序員分成若干個小組，采用圖11.3所示的組織結構,描繪的是技術管理組織的結構，非技術管理組織的結構與此類似。在項目經(jīng)理的指導下進行的，程序員向他們的組長匯報工作，而組長向項目經(jīng)理匯報工作。把民主制程序員組和主程序員組的優(yōu)點結合起來的另一種方法，是在合適的地方采用分散做決定的方法。這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個程序員的積極性和主動性，集思廣益攻克技術難關。這種組織方式對于適合采用民主方法的那類問題（例如，研究性項目或遇到技術難題需要用集體智慧攻關）非常有效。盡管這種組織方式適當?shù)匕l(fā)揚了民主，但是上下級之間的箭頭（即管理關系）仍然是向下的，也就是說，是在集中指導下發(fā)揚民主。顯然，如果程序員可以指揮項目經(jīng)理，則只會引起混亂。圖13.4包含分散決策的組織方式

任何軟件開發(fā)都是迭代過程，也就是說，在設計過程會發(fā)現(xiàn)需求說明書中的問題，在實現(xiàn)過程又會暴露出設計中的錯誤，……。此外，隨著時間推移客戶的需求也會或多或少發(fā)生變化。因此，在開發(fā)軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當?shù)乜刂坪凸芾碜兓?，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。10.5軟件配置管理

軟件配置管理是在軟件的整個生命期內管理變化的一組活動。具體地說，這組活動用來：①標識變化；②控制變化；③確保適當?shù)貙崿F(xiàn)了變化；④向需要知道這類信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而配置管理是在軟件項目啟動時就開始，一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。1.軟件配置項軟件過程的輸出信息可以分為3類：①計算機程序（源代碼和可執(zhí)行程序）；②描述計算機程序的文檔（供技術人員或用戶使用）；③數(shù)據(jù)（程序內包含的或在程序外的）。這些項組成了在軟件過程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。10.5.1軟件配置為了開發(fā)出高質量的軟件產(chǎn)品，軟件開發(fā)人員不僅要努力保證每個軟件配置項正確，而且必須保證一個軟件的所有配置項是完全一致的。可以把軟件配置管理看作是應用于整個軟件過程的軟件質量保證活動，是專門用于管理變化的軟件質量保證活動。2.基線

基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為：已經(jīng)通過了正式復審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎，并且只有通過正式的變化控制過程才能改變它。簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應用特定的、正式的過程（稱為規(guī)程）來評估、實現(xiàn)和驗證每個變化。

除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他CASE工具，作為軟件配置的一部分“固定”下來。因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產(chǎn)生的結果不同，應該把軟件工具也基線化，并且列入到綜合的配置管理過程之中。軟件配置管理是軟件質量保證的重要一環(huán)，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。具體來說，軟件配置管理主要有5項任務：

標識版本控制變化控制配置審計報告10.5.2軟件配置管理過程1.標識軟件配置中的對象可以標識出兩類對象：基本對象和聚集對象（可以把聚集對象作為代表軟件配置完整版本的一種機制）?；緦ο笫擒浖こ處熢诜治?、設計、編碼或測試過程中創(chuàng)建出來的“文本單元”，例如，需求規(guī)格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。對象名是無二義性地標識該對象的一個字符串。所設計的標識模式必須能無歧義地標識每個對象的不同版本。2.版本控制版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)方法：把屬性和軟件的每個版本關聯(lián)起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。這些“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復雜到是一個布爾變量串，其指明施加到系統(tǒng)上的功能變化的具體類型。3.變化控制對于大型軟件開發(fā)項目來說，無控制的變化將迅速導致混亂。變化控制把人的規(guī)程和自動工具結合起來，以提供一個控制變化的機制。典型的變化控制過程如下：接到變化請求之后，首先評估該變化在技術方面的得失、可能產(chǎn)生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結果形成“變化報告”，該報告供“變化控制審批者”審閱。變化控制審批者既可以是一個人也可以由一組人組成。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現(xiàn)的變化，必須遵守的約束以及復審和審計的標準。把要修改的對象從項目數(shù)據(jù)庫中“提取（checkout）”出來，進行修改并應用適當?shù)腟QA活動。最后，把修改后的對象“提交（checkin）”進數(shù)據(jù)庫，并用適當?shù)陌姹究刂茩C制創(chuàng)建該軟件的下一個版本?！疤峤弧焙汀疤崛　边^程實現(xiàn)了變化控制的兩個主要功能——訪問控制和同步控制。訪問控制決定哪個軟件工程師有權訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。在一個軟件配置項變成基線之前，僅需應用非正式的變化控制，該配置對象的開發(fā)者可以對它進行任何合理的修改。一旦該對象經(jīng)過了正式技術復審并獲得批準，就創(chuàng)建了一個基線，而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制。這時，為了進行修改開發(fā)者必須獲得項目管理者的批準（如果變化是“局部的”），如果變化影響到其他軟件配置項，還必須得到變化控制審批者的批準。每個變化必須再次評估，并且要跟蹤和復審所有變化。4.配置審計為了確保實現(xiàn)所需要的變化，通常從下述兩方面采取措施：①正式的技術復審；②軟件配置審計。正式的技術復審關注被修改后的配置對象的技術正確性。復審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。軟件配置審計通過評估配置對象的那些通常不在復審過程中考慮的特征（例如，修改時是否遵循了軟件工程標準，是否在該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當?shù)馗铝怂邢嚓P的軟件配置項，是否遵循了標注變化、記錄變化和報告變化的規(guī)程），而成為對正式技術復審的補充。5.狀態(tài)報告配置狀態(tài)報告它回答下述問題：①發(fā)生了什么事？②誰做的這件事？③這件事是什么時候發(fā)生的？④它將影響哪些其他事物？配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重大影響。如兩名開發(fā)人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量根據(jù)過時的硬件規(guī)格說明開發(fā)軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態(tài)報告通過改善所有相關人員之間的通信，幫助消除這些問題。10.6國際標準--能力成熟度模型ISO9000質量標準強調質量并不是在產(chǎn)品檢驗中得到的，而是在生產(chǎn)的全過程中形成的。ISO9000-3的全稱是“質量管理和質量保證標準第三部分：在軟件開發(fā)、供應和維護中的使用指南”。ISO9000-3要求軟件開發(fā)機構建立質量管理體系ISO9000-3闡述了供方和需方應該怎樣進行有組織的質量管理活動，才能得到較為滿意的軟件產(chǎn)品；規(guī)定了從雙方簽訂開發(fā)合同到設計、實現(xiàn)和維護的整個軟件生命周期中應該實施的質量管理活動，但是，并沒有規(guī)定具體的質量管理和質量檢驗的方法和步驟。13.6國際標準--能力成熟度模型ISO/IEC12207軟件生命周期過程標準指導軟件過程實施的一個標準，從多個角度闡述了軟件生命周期各個過程中的活動，對規(guī)范軟件開發(fā)過程，協(xié)調各類人員之間的關系，都具有指導作用。建立了一個最高層次的軟件生命周期體系結構生命周期從一個設想或需求開始，直至軟件被廢棄(退役)時終止。體系結構由一組相互關聯(lián)的過程集組成，所有過程都遵守了兩條基本原則：模塊化和責任。標準中的過程被分成三大類：主要過程，支持過程和組織過程。主要過程是生命周期中的原動力，它們是：獲取、供應、開發(fā)、運行和維護。ISO/IEC12207是從過程實施的角度對軟件生命周期過程進行規(guī)范的標準10.6國際標準--能力成熟度模型ISO/IECTR15504軟件過程評估標準是從過程評估的角度對軟件過程進行規(guī)范的標準。為軟件過程評估提供了一個框架，并為實施評估以確保各種級別的一致性和可重復性提出了一個最小需求。具有兩維結構：一個是過程維（客戶——供應者、工程過程、支持過程、管理過程、組織過程），另一個是能力維（第0級——不完全級、可實施級、有管理級、可創(chuàng)建級、可預測級、優(yōu)化級）。融合進了能力成熟度模型(CMM)類似的能力等級。用戶可以通過不斷提高能力等級的方法，提高自己的軟件過程能力。10.6國際標準--能力成熟度模型能力成熟度模型軟件質量問題是由我們管理軟件過程的方法不當引起的。新軟件技術的運用并不會自動提高生產(chǎn)率和軟件質量。有助于軟件開發(fā)組織建立一個有規(guī)律的、成熟的軟件過程。軟件過程既包括了軟件生產(chǎn)的技術方面又包括了管理方面。CMM策略力圖改進軟件過程的管理，而在技術方面的改進是其必然的結果。對軟件過程的改進不可能在一夜之間完成，CMM是以增量方式逐步引入變化的。CMM明確地定義了5個不同的成熟度等級，一個軟件開發(fā)組織可用一系列小的改良性步驟向更高的成熟度等級邁進。10.6國際標準--能力成熟度模型能力成熟度模型的結構成熟度等級(MaturityLevels)：五個成熟度等級構成了CMM的頂層結構。過程能力(ProcessCapability)：軟件過程能力描述，通過遵循軟件過程能實現(xiàn)預期結果的程度。關鍵過程域(KeyProcessAreas,KPA)：每個成熟度等級由若干關鍵過程域組成。每個關鍵過程域都標識出一串相關的活動，當把這些活動都完成時所達到的一組目標，對建立該過程成熟度等級是至關重要的。目標(Goals)：目標概括了關鍵過程域中的關鍵實踐，并可用于確定一個組織或項目是否已有效地實施了該關鍵過程域。目標表示每個關鍵過程域的范圍、邊界和意圖。公共特性(CommonFeatures)：能指示一個關鍵過程域的實施和規(guī)范化是否是有效的、可重復的和持久的屬性。關鍵實踐(KeyPractices)：每個關鍵過程域都用若干關鍵實踐描述，關鍵實踐描述是對關鍵過程域的有效實施和規(guī)范化貢獻最大的基礎設施和活動。圖13.4CMM結構能力成熟度等級1.初始級：軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的，項目能否成功完全取決于個人能力。2.可重復級：建立了基本的項目管理過程，以追蹤成本、進度和功能性。已建立必要的過程規(guī)范，可以重復以前類似項目所取得的成功。3.定義級：用于管理工程活動的軟件過程已經(jīng)文檔化和標準化，并且已經(jīng)集成到整個組織的軟件過程中。這一級包含了第2級的所有特征。4.管理級：已收集了軟件過程和產(chǎn)品質量的詳細度量數(shù)據(jù)，使用這些詳細的度量數(shù)據(jù)，能夠定量地理解和控制軟件過程和產(chǎn)品。這一級包含了第3級的所有特征。5.優(yōu)化級：通過定量的反饋能夠實現(xiàn)持續(xù)的過程改進，這些反饋是從過程及對新想法和技術的測試中獲得的。這一級包含了第4級的所有特征。軟件過程成熟度模型的關鍵子過程域*表示個體軟件過程PSP的關鍵子過程域。軟件過程能力描述遵循一個軟件過程所能達到的期望結果的范圍。軟件過程性能是指遵循一個軟件過程所能得到的實際結果。軟件過程成熟度是指一個特定的過程被明確定義、管理、度量、控制以及有效的程度。1級-初始層2級-可重復層軟件配置管理軟件質量保證軟件子同合管理*軟件項目追蹤與監(jiān)控*軟件項目計劃需求管理3級-定義層*同級評審組間協(xié)作*軟件產(chǎn)品工程*軟件集成管理培訓計劃*軟件過程定義*軟件過程要點5級-優(yōu)化層*過程更改管理*技術更改管理*缺陷預防4級-管理層*質量管理*過程量化管理個體軟件過程PSPPSP是由美國CMU/SEI的WattsHumphrey領導開發(fā)的。他對104位參與PSP培訓的軟件人員的統(tǒng)計數(shù)據(jù)表明(程序規(guī)模從50至5000行不等)，在應用PSP后：總的差錯減少58.0%，在測試階段發(fā)現(xiàn)的差錯減少71.9%，生產(chǎn)效率提高20.8%。PSP的結果表明，軟件缺陷絕大多數(shù)是由于對問題的錯誤理解或簡單的失誤所造成，只有很少一部分是由于復雜的邏輯關系所產(chǎn)生。PSP的結果還表明，在編程階段的缺陷引入率是設計階段的3.5倍。因此，保障軟件產(chǎn)品質量的一個重要途徑是提高設計質量。在軟件設計階段，PSP的著眼點在于軟件缺陷的預防。具體的途徑是強化設計結束準則，而不是設計方法的選擇。個體軟件過程的成熟度與關鍵子過程域個體管理基線PSP0當前的過程工作時間記錄程序差錯記錄程序差錯類型標準PSP0.1編碼標準軟件規(guī)模度量過程改善建議個體過程循環(huán)PSP3循環(huán)開發(fā)個體質量管理個體規(guī)劃過程PSP1程序規(guī)模估計測試報告PSP1.1任務規(guī)劃