軟件工程課件：第13章軟件項(xiàng)目管理

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

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

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

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

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

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

7、軟件開發(fā)工作量.工作量是軟件規(guī)模（KLOC或FP）的函數(shù)工作量的單位通常是人月（pm)支持大多數(shù)估算模型的經(jīng)驗(yàn)數(shù)據(jù)，都是從有限個(gè)項(xiàng)目的樣本集中總結(jié)出來的，因此，沒有一個(gè)估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境。13.2 工作量估算這類模型的總體結(jié)構(gòu)形式如下： E = A+B(ev)CA、B和C：由經(jīng)驗(yàn)數(shù)據(jù)導(dǎo)出的常數(shù)ev是估算變量（KLOC或FP）E是以人月為單位的工作量下面給出幾個(gè)典型的靜態(tài)單變量模型。 13.2.1 靜態(tài)單變量模型 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簡(jiǎn)單模型 E=3.2(KLOC)1.05(4) Doty模型（在KLOC9時(shí)適用） E=5.288(KLOC)1.0472. 面向FP的估算模型(1) Albrecht & Gaffney模型 E=-13.39+0.0545FP(2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP從上面列出的模型可以看出，對(duì)于相同的KLOC或FP值，用不同模型估算將得出不同的結(jié)果。主要原因是，這些模型多數(shù)都是僅根據(jù)若干應(yīng)用領(lǐng)域中有限個(gè)項(xiàng)目的經(jīng)驗(yàn)數(shù)據(jù)推導(dǎo)出來的，適用范圍有限。因此，必須根據(jù)當(dāng)前項(xiàng)目的特點(diǎn)選擇適用的估算模型，并且根據(jù)需要適

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

10、總體過程成熟度及管理水平；使用良好的軟件工程實(shí)踐的程度；使用的程序設(shè)計(jì)語言的級(jí)別；軟件環(huán)境的狀態(tài)；軟件項(xiàng)目組的技術(shù)及經(jīng)驗(yàn)；應(yīng)用系統(tǒng)的復(fù)雜程度。P的典型取值是：開發(fā)實(shí)時(shí)嵌入式軟件時(shí)，P的典型值為2,000；開發(fā)電信系統(tǒng)和系統(tǒng)軟件時(shí)，P=10,000；對(duì)于商業(yè)應(yīng)用系統(tǒng)來說，P=28,000?？梢詮臍v史數(shù)據(jù)導(dǎo)出適用于當(dāng)前項(xiàng)目的生產(chǎn)率參數(shù)值。從（13.2）式可以看出： 開發(fā)同一個(gè)軟件（即LOC固定）的時(shí)候，如果把項(xiàng)目持續(xù)時(shí)間延長一些，則可降低完成項(xiàng)目所需的工作量。COCOMO是構(gòu)造性成本模型（constructive cost model)的英文縮寫。1981年Boehm在軟件工程經(jīng)濟(jì)學(xué)中首次提出了C

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

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

13、.3列出了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。甚低低正常高甚高特高產(chǎn)品因素要求的可靠性0.750.881.001.151.39數(shù)據(jù)庫規(guī)模0.931.001.091.19產(chǎn)品復(fù)雜度要求的可重用性需要的文檔量平臺(tái)因素執(zhí)行時(shí)間約束1.001.111.311.67主存約束平臺(tái)變動(dòng)人員因素分析員能力1.501.221.000.830.67程序員能力應(yīng)用領(lǐng)域經(jīng)驗(yàn)1.221.101.000.890.81平臺(tái)經(jīng)驗(yàn)語言和工具經(jīng)驗(yàn)人員連續(xù)性項(xiàng)目因素使用軟件工具多地點(diǎn)開發(fā)1.251.101.000.920.840.78要求的開發(fā)進(jìn)度與原始的COCOMO模型相比，COCOMO2模型使用的成本因素

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

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

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

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

18、會(huì)拖后，管理人員應(yīng)該高度關(guān)注關(guān)鍵任務(wù)的進(jìn)展情況。13.3 進(jìn)度計(jì)劃估算出完成給定項(xiàng)目所需的總工作量之后，接下來需要回答的問題就是： 用多長時(shí)間才能完成該項(xiàng)目的開發(fā)工作？對(duì)于一個(gè)估計(jì)工作量為20人月的項(xiàng)目，可能想出下列幾種進(jìn)度表：1個(gè)人用20個(gè)月完成該項(xiàng)目；4個(gè)人用5個(gè)月完成該項(xiàng)目；20個(gè)人用1個(gè)月完成該項(xiàng)目。但是，這些進(jìn)度表并不現(xiàn)實(shí)，實(shí)際上軟件開發(fā)時(shí)間與從事開發(fā)工作的人數(shù)之間并不是簡(jiǎn)單的反比關(guān)系。13.3.1 估算開發(fā)時(shí)間通常，成本估算模型也同時(shí)提供了估算開發(fā)時(shí)間T的方程。與工作量方程不同，各種模型估算開發(fā)時(shí)間的方程很相似，例如： (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是開發(fā)工作量（以人月為單位），T是開發(fā)時(shí)間（以月為單位）。用上列方程計(jì)算出的T值，代表正常情況下的開發(fā)時(shí)間?？蛻敉Ｍs短軟件開發(fā)時(shí)間，顯然，為了縮短開發(fā)時(shí)間應(yīng)該增加從事開發(fā)工作的人數(shù)。但是，經(jīng)驗(yàn)告訴我們，隨著開發(fā)小組規(guī)模擴(kuò)大，個(gè)人生產(chǎn)率將下降，以致開發(fā)時(shí)間與從事開發(fā)工作的人數(shù)并不成反比關(guān)系。出現(xiàn)這種現(xiàn)象主要有下述兩個(gè)原因： 1、當(dāng)小組變得更大時(shí)，每個(gè)人需要用更多時(shí)間與組內(nèi)其他成員討論問題、協(xié)調(diào)工作，因此增加了通信開銷。2、如果在開

20、發(fā)過程中增加小組人員，則最初一段時(shí)間內(nèi)項(xiàng)目組總生產(chǎn)率不僅不會(huì)提高反而會(huì)下降。這是因?yàn)樾鲁蓡T在開始時(shí)不僅不是生產(chǎn)力，而且在他們學(xué)習(xí)期間還需要花費(fèi)小組其他成員的時(shí)間。綜合上述兩個(gè)原因，存在被稱為Brooks規(guī)律的下述現(xiàn)象： 向一個(gè)已經(jīng)延期的項(xiàng)目增加人力，只會(huì)使得它更加延期。下面讓我們研究項(xiàng)目組規(guī)模與項(xiàng)目組總生產(chǎn)率的關(guān)系。項(xiàng)目組成員之間的通信路徑數(shù)，由項(xiàng)目組人數(shù)和項(xiàng)目組結(jié)構(gòu)決定。如果項(xiàng)目組共有P名組員，每個(gè)組員必須與所有其他組員通信以協(xié)調(diào)開發(fā)活動(dòng)，則通信路徑數(shù)為P(P-1)/2。如果每個(gè)組員只需與另外一個(gè)組員通信，則通信路徑數(shù)為P-1。通信路徑數(shù)少于P-1是不合理的，因?yàn)槟菍?dǎo)致出現(xiàn)與任何人都沒有聯(lián)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

40、結(jié)合民主制程序員組和主程序員組的優(yōu)點(diǎn)，并且能用于實(shí)現(xiàn)更大規(guī)模的軟件產(chǎn)品。 使用主程序員組的組織方式時(shí)，主程序員對(duì)每行代碼的質(zhì)量負(fù)責(zé)，因此，他必須參與所有代碼審查工作。由于主程序員同時(shí)又是負(fù)責(zé)對(duì)小組成員進(jìn)行評(píng)價(jià)的管理員，他參與代碼審查工作就會(huì)把所發(fā)現(xiàn)的程序錯(cuò)誤與小組成員的工作業(yè)績聯(lián)系起來，從而使得小組成員不愿意發(fā)現(xiàn)錯(cuò)誤。13.4.3 現(xiàn)代程序員組解決上述問題的方法是，取消主程序員的大部分行政管理工作。前面已經(jīng)指出，很難找到既是高度熟練的程序員又是成功的管理員的人，取消主程序員的行政管理工作，不僅解決了小組成員不愿意發(fā)現(xiàn)程序錯(cuò)誤的心理問題，也使得尋找主程序員的人選不再那么困難。于是，實(shí)際的“主程序

41、員”應(yīng)該由兩個(gè)人共同擔(dān)任： 一個(gè)技術(shù)負(fù)責(zé)人，負(fù)責(zé)小組的技術(shù)活動(dòng)；一個(gè)行政負(fù)責(zé)人，負(fù)責(zé)所有非技術(shù)性事務(wù)的管理決策。技術(shù)組長自然要參與全部代碼審查工作，因?yàn)樗獙?duì)代碼的各方面質(zhì)量負(fù)責(zé)；相反，行政組長不可以參與代碼審查工作，因?yàn)樗穆氊?zé)是對(duì)程序員的業(yè)績進(jìn)行評(píng)價(jià)。圖13.6 現(xiàn)代程序員組的結(jié)構(gòu)把民主制程序員組和主程序員組的優(yōu)點(diǎn)結(jié)合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖13.8所示。這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個(gè)程序員的積極性和主動(dòng)性，集思廣益攻克技術(shù)難關(guān)。這種組織方式對(duì)于適合采用民主方法的那類問題（例如，研究性項(xiàng)目或遇到技術(shù)難題需要用集體智慧攻關(guān)）非常有效。圖13

42、.8 包含分散決策的組織方式概括地說，軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟件質(zhì)量是軟件與明確地?cái)⑹龅墓δ芎托阅苄枨?、文檔中明確描述的開發(fā)標(biāo)準(zhǔn)以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。上述定義強(qiáng)調(diào)了下述的3個(gè)要點(diǎn)： 13.5 質(zhì)量保證 13.5.1 軟件質(zhì)量（1） 軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)量不高。（2） 指定的開發(fā)標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則，如果沒有遵守這些準(zhǔn)則，幾乎肯定會(huì)導(dǎo)致軟件質(zhì)量不高。（3） 通常，有一組沒有顯式描述的隱含需求（例如，軟件應(yīng)該是容易維護(hù)的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求

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

44、。13.5.2 軟件質(zhì)量保證措施任何軟件開發(fā)都是迭代過程，也就是說，在設(shè)計(jì)過程會(huì)發(fā)現(xiàn)需求說明書中的問題，在實(shí)現(xiàn)過程又會(huì)暴露出設(shè)計(jì)中的錯(cuò)誤，。此外，隨著時(shí)間推移客戶的需求也會(huì)或多或少發(fā)生變化。因此，在開發(fā)軟件的過程中，變化（或稱為變動(dòng)）既是必要的，又是不可避免的。但是，變化也很容易失去控制，如果不能適當(dāng)?shù)乜刂坪凸芾碜兓瑒?shì)必造成混亂并產(chǎn)生許多嚴(yán)重的錯(cuò)誤。13.6 軟件配置管理 軟件配置管理是在軟件的整個(gè)生命期內(nèi)管理變化的一組活動(dòng)。具體地說，這組活動(dòng)用來： 標(biāo)識(shí)變化； 控制變化； 確保適當(dāng)?shù)貙?shí)現(xiàn)了變化； 向需要知道這類信息的人報(bào)告變化。 配置管理是在軟件項(xiàng)目啟動(dòng)時(shí)就開始，并且一直持續(xù)到軟件退役后才

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

46、單獨(dú)命名每個(gè)配置項(xiàng)，然后用面向?qū)ο蠓椒ńM織它們?？梢詷?biāo)識(shí)出兩類對(duì)象： 基本對(duì)象和聚集對(duì)象（可以把聚集對(duì)象作為代表軟件配置完整版本的一種機(jī)制）?；緦?duì)象是軟件工程師在分析、設(shè)計(jì)、編碼或測(cè)試過程中創(chuàng)建出來的“文本單元”，例如，需求規(guī)格說明的一個(gè)段落、一個(gè)模塊的源程序清單或一組測(cè)試用例。聚集對(duì)象是基本對(duì)象和其他聚集對(duì)象的集合。每個(gè)對(duì)象都有一組能惟一地標(biāo)識(shí)它的特征： 名字、描述、資源表和“實(shí)現(xiàn)”。其中，對(duì)象名是無二義性地標(biāo)識(shí)該對(duì)象的一個(gè)字符串。在設(shè)計(jì)標(biāo)識(shí)軟件對(duì)象的模式時(shí)，必須認(rèn)識(shí)到對(duì)象在整個(gè)生命周期中一直都在演化，因此，所設(shè)計(jì)的標(biāo)識(shí)模式必須能無歧義地標(biāo)識(shí)每個(gè)對(duì)象的不同版本。2. 版本控制版本控制聯(lián)合使

47、用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對(duì)象的不同版本。借助于版本控制技術(shù)，用戶能夠通過選擇適當(dāng)?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實(shí)現(xiàn)這個(gè)目標(biāo)的方法是，把屬性和軟件的每個(gè)版本關(guān)聯(lián)起來，然后通過描述一組所期望的屬性來指定和構(gòu)造所需要的配置。上面提到的“屬性”，既可以簡(jiǎn)單到僅是賦給每個(gè)配置對(duì)象的具體版本號(hào)，也可以復(fù)雜到是一個(gè)布爾變量串，其指明了施加到系統(tǒng)上的功能變化的具體類型。3. 變化控制對(duì)于大型軟件開發(fā)項(xiàng)目來說，無控制的變化將迅速導(dǎo)致混亂。變化控制把人的規(guī)程和自動(dòng)工具結(jié)合起來，以提供一個(gè)控制變化的機(jī)制。典型的變化控制過程如下： 接到變化請(qǐng)求之后，首先評(píng)估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作

48、用、對(duì)其他配置對(duì)象和系統(tǒng)功能的整體影響以及估算出的修改成本。評(píng)估的結(jié)果形成“變化報(bào)告”，該報(bào)告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個(gè)人也可以由一組人組成，其對(duì)變化的狀態(tài)和優(yōu)先級(jí)做最終決策。為每個(gè)被批準(zhǔn)的變化都生成一個(gè)“工程變化命令”，其描述將要實(shí)現(xiàn)的變化，必須遵守的約束以及復(fù)審和審計(jì)的標(biāo)準(zhǔn)。把要修改的對(duì)象從項(xiàng)目數(shù)據(jù)庫中“提?。╟heck out）”出來，進(jìn)行修改并應(yīng)用適當(dāng)?shù)腟QA活動(dòng)。最后，把修改后的對(duì)象“提交（check in）”進(jìn)數(shù)據(jù)庫，并用適當(dāng)?shù)陌姹究刂茩C(jī)制創(chuàng)建該軟件的下一個(gè)版本。“提交”和“提取”過程實(shí)現(xiàn)了變化控制的兩個(gè)主要功能訪問控制和同步控制。訪問控制決定哪個(gè)軟件

49、工程師有權(quán)訪問和修改一個(gè)特定的配置對(duì)象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會(huì)相互覆蓋。4. 配置審計(jì)軟件配置審計(jì)通過評(píng)估配置對(duì)象的那些通常不在復(fù)審過程中考慮的特征（例如，修改時(shí)是否遵循了軟件工程標(biāo)準(zhǔn)，是否在該配置項(xiàng)中顯著地標(biāo)明了所做的修改，是否注明了修改日期和修改者，是否適當(dāng)?shù)馗铝怂邢嚓P(guān)的軟件配置項(xiàng)，是否遵循了標(biāo)注變化、記錄變化和報(bào)告變化的規(guī)程），而成為對(duì)正式技術(shù)復(fù)審的補(bǔ)充。5. 狀態(tài)報(bào)告書寫配置狀態(tài)報(bào)告是軟件配置管理的一項(xiàng)任務(wù)，它回答下述問題： 發(fā)生了什么事？ 誰做的這件事？這件事是什么時(shí)候發(fā)生的？它將影響哪些其他事物？配置狀態(tài)變化對(duì)大型軟件開發(fā)項(xiàng)目的成功有重大影響

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

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

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