1、第13章 軟件項(xiàng)目管理13.1 估算軟件規(guī)模估算軟件規(guī)模13.2 工作量估算工作量估算13.3 進(jìn)度計(jì)劃進(jìn)度計(jì)劃13.4 人員組織人員組織13.5 質(zhì)量保證質(zhì)量保證13.6 軟件配置管理軟件配置管理13.7 能力成熟度模型能力成熟度模型13.8 小結(jié)小結(jié)上次課內(nèi)容回顧n面向?qū)ο蟮姆椒▽W(xué)？OO=objects +classes +inheritance+communication with messagesn面向?qū)ο蠓椒▽W(xué)的優(yōu)點(diǎn)？n與人類習(xí)慣的思維方法一致；穩(wěn)定性好；可重用性好；較易開發(fā)大型軟件產(chǎn)品；可維護(hù)性好n面向?qū)ο蠼?n根據(jù)面向?qū)ο笥^點(diǎn)(模擬人類習(xí)慣的思維方式)建立問題的解模式. 面向?qū)?/p>

2、象的實(shí)現(xiàn)能將此模式在計(jì)算機(jī)上實(shí)施.n大型軟件項(xiàng)目的失敗并不是由于軟件工程師的無能，其主要原因是管理不善管理不善。n管理就是管理就是通過計(jì)劃、組織和控制等一系列活通過計(jì)劃、組織和控制等一系列活動(dòng)，合理地配置和使用各種資源，以達(dá)到既定動(dòng)，合理地配置和使用各種資源，以達(dá)到既定目標(biāo)的過程目標(biāo)的過程。n軟件項(xiàng)目管理先于先于任何技術(shù)活動(dòng)之前開始，并且貫穿于軟件的整個(gè)生命周期之中貫穿于軟件的整個(gè)生命周期之中。n軟件項(xiàng)目管理過程從一組項(xiàng)目計(jì)劃活動(dòng)開始，而制定計(jì)劃的基礎(chǔ)是工作量估算和完成期限估制定計(jì)劃的基礎(chǔ)是工作量估算和完成期限估算算。n為了估算項(xiàng)目的工作量和完成期限，首先需要首先需要估算軟件的規(guī)模。估算軟件的

3、規(guī)模。13.1 估算軟件規(guī)模 13.1.1 代碼行技術(shù)n代碼行技術(shù)是簡(jiǎn)單的定量估算軟件規(guī)模的方法。n它依據(jù)開發(fā)類似產(chǎn)品的經(jīng)驗(yàn)和歷史數(shù)據(jù)，估計(jì)依據(jù)開發(fā)類似產(chǎn)品的經(jīng)驗(yàn)和歷史數(shù)據(jù)，估計(jì)實(shí)現(xiàn)一個(gè)功能所需要的源程序行數(shù)實(shí)現(xiàn)一個(gè)功能所需要的源程序行數(shù)。n在有大量數(shù)據(jù)時(shí)，這種方法估計(jì)出的數(shù)值還是比較準(zhǔn)確的。n把實(shí)現(xiàn)每個(gè)功能所需要的源程序行數(shù)累加起來，就可得到實(shí)現(xiàn)整個(gè)軟件所需要的源程序行數(shù)整個(gè)軟件所需要的源程序行數(shù)。13.1.1 代碼行技術(shù)n為了使得對(duì)程序規(guī)模的估計(jì)值更接近實(shí)際值，可以由多名有經(jīng)驗(yàn)的軟件工程師分別做出估計(jì)多名有經(jīng)驗(yàn)的軟件工程師分別做出估計(jì)。n分別估計(jì)程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能

4、的規(guī)模(m)，算出這3種規(guī)模的平均值平均值之后，再用下式計(jì)算程序規(guī)模的估計(jì)值： L=(13.1)n當(dāng)程序較小時(shí)常用的單位是代碼行數(shù)（代碼行數(shù)（LOCLOC），當(dāng)程序較大時(shí)常用的單位是千行代碼數(shù)（千行代碼數(shù)（KLOCKLOC）。64bma 13.1.1 代碼行技術(shù)n代碼行技術(shù)的優(yōu)點(diǎn)是，代碼是所有軟件開發(fā)項(xiàng)目都有的“產(chǎn)品”，而且很容易計(jì)算代碼行數(shù)。n代碼行技術(shù)的缺點(diǎn)缺點(diǎn)是： n源程序僅是軟件配置的一個(gè)成分，用它的規(guī)模代表整個(gè)軟件的規(guī)模似乎不太合理；n用不同語言實(shí)現(xiàn)同一個(gè)軟件所需要的代碼行數(shù)并不相同；n這種方法不適用于非過程語言。13.1.2 功能點(diǎn)技術(shù)n功能點(diǎn)技術(shù)依據(jù)對(duì)軟件依據(jù)對(duì)軟件信息域特性信息

5、域特性和和軟件復(fù)雜軟件復(fù)雜性的評(píng)估結(jié)果性的評(píng)估結(jié)果，估算軟件規(guī)模，估算軟件規(guī)模。n這種方法用功能點(diǎn)（FP）為單位度量軟件規(guī)模。1. 1. 信息域特性信息域特性n功能點(diǎn)技術(shù)定義了信息域的5個(gè)特性u(píng)輸入項(xiàng)數(shù)輸入項(xiàng)數(shù)(Inp)(Inp)u輸出項(xiàng)數(shù)輸出項(xiàng)數(shù)(Out)(Out)u查詢數(shù)查詢數(shù)(Inq)(Inq)u主文件數(shù)主文件數(shù)(Maf)(Maf)u外部接口數(shù)外部接口數(shù)(Inf)(Inf)13.1.2 功能點(diǎn)技術(shù)（1 1） 輸入項(xiàng)數(shù)輸入項(xiàng)數(shù)：用戶向軟件輸入的項(xiàng)數(shù)，這些輸入給軟件提供面向應(yīng)用的數(shù)據(jù)。輸入不同于查詢，后者單獨(dú)計(jì)數(shù)，不計(jì)入輸入項(xiàng)數(shù)中。（2 2） 輸出項(xiàng)數(shù)輸出項(xiàng)數(shù)：軟件向用戶輸出的項(xiàng)數(shù)，它們向用

6、戶提供面向應(yīng)用的信息，例如，報(bào)表和出錯(cuò)信息等。報(bào)表內(nèi)的數(shù)據(jù)項(xiàng)不單獨(dú)計(jì)數(shù)。（3 3） 查詢數(shù)查詢數(shù)：查詢即是一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出方式產(chǎn)生某種即時(shí)響應(yīng)。（4 4） 主文件數(shù)主文件數(shù)：邏輯主文件（即數(shù)據(jù)的一個(gè)邏輯組合，它可能是大型數(shù)據(jù)庫的一部分或一個(gè)獨(dú)立的文件）的數(shù)目。（5 5） 外部接口數(shù)外部接口數(shù)： 機(jī)器可讀的全部接口（例如，磁盤或磁帶上的數(shù)據(jù)文件）的數(shù)量，用這些接口把信息傳送給另一個(gè)系統(tǒng)。13.1.2 功能點(diǎn)技術(shù)2. 2. 估算功能點(diǎn)的步驟估算功能點(diǎn)的步驟n用下述3個(gè)步驟，可估算出一個(gè)軟件的功能點(diǎn)數(shù)。nStep1: 計(jì)算未調(diào)整的功能點(diǎn)數(shù)UFPUFPnStep2: 計(jì)算技術(shù)復(fù)雜性因

7、子TCFTCFnStep3: 計(jì)算功能點(diǎn)數(shù)FPFP13.1.2 功能點(diǎn)技術(shù)（1 1） 計(jì)算未調(diào)整的功能點(diǎn)數(shù)計(jì)算未調(diào)整的功能點(diǎn)數(shù)UFPUFPn把產(chǎn)品信息域的每個(gè)特性(即Inp、Out、Inq、Maf和Inf)都分類為簡(jiǎn)單級(jí)、平均級(jí)或復(fù)雜級(jí)，并根據(jù)其等級(jí)為每個(gè)特性分配一個(gè)功能點(diǎn)數(shù)。n例如，一個(gè)簡(jiǎn)單級(jí)的輸入項(xiàng)分配3個(gè)功能點(diǎn)，一個(gè)平均級(jí)的輸入項(xiàng)分配4個(gè)功能點(diǎn)，而一個(gè)復(fù)雜級(jí)的輸入項(xiàng)分配6個(gè)功能點(diǎn)。n用下式計(jì)算未調(diào)整的功能點(diǎn)數(shù)UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf，其中，ai(1i5)是信息域特性系數(shù)，其值由相應(yīng)特性的復(fù)雜級(jí)別決定，如下表所示。13.1.2 功能點(diǎn)技術(shù)

8、 復(fù)雜級(jí)別復(fù)雜級(jí)別特性系數(shù)特性系數(shù)簡(jiǎn)單簡(jiǎn)單平均平均復(fù)雜復(fù)雜輸入系數(shù)輸入系數(shù)a1346輸出系數(shù)輸出系數(shù)a2457查詢系數(shù)查詢系數(shù)a3346文件系數(shù)文件系數(shù)a471015接口系數(shù)接口系數(shù)a5571013.1.2 功能點(diǎn)技術(shù)(2) (2) 計(jì)算技術(shù)復(fù)雜性因子計(jì)算技術(shù)復(fù)雜性因子TCFTCFn度量14種技術(shù)因素對(duì)軟件規(guī)模的影響程度。這些因素包括高處理率、性能標(biāo)準(zhǔn)（例如，響應(yīng)時(shí)間）、聯(lián)機(jī)更新等，在表表13.213.2中列出了全部技術(shù)因素，并用Fi(1i14)代表這些因素。根據(jù)軟件的特點(diǎn)，為每個(gè)因素分配一個(gè)從0 0（不存在或?qū)浖?guī)模無影響）（不存在或?qū)浖?guī)模無影響）到5 5（有很大影響）（有很大影響）的

9、值。然后，用下式計(jì)算技術(shù)因素對(duì)軟件規(guī)模的綜合影響程度DI：n DI= 141iiF13.1.2 功能點(diǎn)技術(shù)n技術(shù)復(fù)雜性因子TCF由下式計(jì)算： TCF=0.65+0.01DIn因?yàn)镈I的值在070之間，所以TCF的值在0.651.35之間。（3 3） 計(jì)算功能點(diǎn)數(shù)計(jì)算功能點(diǎn)數(shù)FPFPn用下式計(jì)算功能點(diǎn)數(shù)FP： FP=UFPTCFn功能點(diǎn)數(shù)與所用的編程語言無關(guān)，似乎更合理一些。但是，在判斷信息域特性復(fù)雜級(jí)別和技術(shù)因素的影響程度時(shí)，存在著相當(dāng)大的主觀因素相當(dāng)大的主觀因素。13.2 工作量估算n軟件估算模型使用由經(jīng)驗(yàn)導(dǎo)出的公式來預(yù)測(cè)軟件開發(fā)工作量，工作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位

10、通常是人月（pm)。n沒有一個(gè)估算模型可以適用于所有類型的軟件和開發(fā)環(huán)境。n要根據(jù)項(xiàng)目的特點(diǎn)選擇合理的估算模型。13.2.1 靜態(tài)單變量模型n這類模型的總體結(jié)構(gòu)形式如下 E=A+B(ev)Cn其中，A、B和C是由經(jīng)驗(yàn)數(shù)據(jù)導(dǎo)出的常數(shù)，E是以人月為單位的工作量，ev是估算變量（KLOC或FP）。下面給出幾個(gè)典型的靜態(tài)單變量模型。1. 1. 面向面向KLOCKLOC的估算模型的估算模型(1) Walston_Felix模型 E=5.2(KLOC)0.91(2) Bailey_Basili模型 E=5.5+0.73(KLOC)1.16(3) Boehm簡(jiǎn)單模型 E=3.2(KLOC)1.05(4) D

11、oty模型（在KLOC9時(shí)適用） E=5.288(KLOC)1.04713.2.1 靜態(tài)單變量模型2. 2. 面向面向FPFP的估算模型的估算模型(1) Albrecht & Gaffney模型 E=-13.39+0.0545FP(2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP13.2.2 動(dòng)態(tài)多變量模型n動(dòng)態(tài)多變量模型也稱為軟件方程式，它是根據(jù)它是根據(jù)從從40004000多個(gè)多個(gè)當(dāng)代軟件項(xiàng)目中收集的生產(chǎn)率數(shù)據(jù)當(dāng)代軟件項(xiàng)目中收集的生產(chǎn)率數(shù)據(jù)推導(dǎo)出來的推導(dǎo)出來的。n該模型把工作量看作是工作量看作是軟件規(guī)模軟件規(guī)模和和開發(fā)時(shí)間開發(fā)時(shí)間這這兩個(gè)變

12、量的函數(shù)兩個(gè)變量的函數(shù)。其表達(dá)形式如下： E=(LOCB0.333/P)3(1/t)4其中，E是以人月或人年為單位的工作量；t是以月或年為單位的項(xiàng)目持續(xù)時(shí)間；13.2.2 動(dòng)態(tài)多變量模型nB B是特殊技術(shù)因子是特殊技術(shù)因子，它隨著對(duì)測(cè)試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加緩慢增加，對(duì)于較小的程序（KLOC=515），B=0.16,對(duì)于超過70 KLOC的程序，B=0.39;nP P生產(chǎn)率參數(shù)生產(chǎn)率參數(shù)，它反映了下述因素對(duì)工作量的影響： n總體過程成熟度及管理水平；總體過程成熟度及管理水平；n使用良好的軟件工程實(shí)踐的程度；使用良好的軟件工程實(shí)踐的程度；n使用的程序設(shè)計(jì)語言的級(jí)別；使用

13、的程序設(shè)計(jì)語言的級(jí)別；n軟件環(huán)境的狀態(tài)；軟件環(huán)境的狀態(tài)；n軟件項(xiàng)目組的技術(shù)及經(jīng)驗(yàn)；軟件項(xiàng)目組的技術(shù)及經(jīng)驗(yàn)；n應(yīng)用系統(tǒng)的復(fù)雜程度。應(yīng)用系統(tǒng)的復(fù)雜程度。13.2.2 動(dòng)態(tài)多變量模型n開發(fā)實(shí)時(shí)嵌入式軟件時(shí)，P的典型值為2000；開發(fā)電信系統(tǒng)和系統(tǒng)軟件時(shí)，P=10000；對(duì)于商業(yè)應(yīng)用系統(tǒng)來說，P=28000。n可以從歷史數(shù)據(jù)導(dǎo)出適用于當(dāng)前項(xiàng)目的生產(chǎn)率參數(shù)值。n開發(fā)同一個(gè)軟件（即LOC固定）的時(shí)候，如果把項(xiàng)目持續(xù)時(shí)間延長一些，則可降低完成項(xiàng)目把項(xiàng)目持續(xù)時(shí)間延長一些，則可降低完成項(xiàng)目所需的工作量所需的工作量。和時(shí)間和時(shí)間成反比成反比13.2.3 COCOMO2模型nCOCOMO是構(gòu)造性成本模型（const

14、ructive cost model)的英文縮寫。n1981年Boehm在軟件工程經(jīng)濟(jì)學(xué)中首次提出了COCOMO模型。n1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計(jì)方面所積累的經(jīng)驗(yàn)。13.2.3 COCOMO2模型nCOCOMO2給出了3個(gè)層次的軟件開發(fā)工作量估算模型。n這3個(gè)層次的模型在估算工作量時(shí)，對(duì)軟件細(xì)節(jié)考慮的詳盡程度逐級(jí)增加。n這些模型既可以用于不同類型的項(xiàng)目，也可以用于同一個(gè)項(xiàng)目的不同開發(fā)階段。13.2.3 COCOMO2模型n這3個(gè)層次的估算模型分別是： （1） 應(yīng)用系統(tǒng)組成模型。它主要用于估算構(gòu)建原型的工作量，模

15、型名字暗示在構(gòu)建原型時(shí)大量使用已有的構(gòu)件。（2） 早期設(shè)計(jì)模型。這個(gè)模型適用于體系結(jié)構(gòu)設(shè)計(jì)階段。（3） 后體系結(jié)構(gòu)模型。這個(gè)模型適用于完成體系結(jié)構(gòu)設(shè)計(jì)之后的軟件開發(fā)階段。13.2.3 COCOMO2模型n以后體系結(jié)構(gòu)模型為例，介紹COCOMO2模型。該模型把軟件開發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)：n E=(13.3)nE是開發(fā)工作量（以人月為單位），a是模型系數(shù)，KLOC是估計(jì)的源代碼行數(shù)（以千行為單位），b是模型指數(shù)，fi(i=117)是成本因素。 171iibfKLOCa13.2.3 COCOMO2模型n工作量方程中模型系數(shù)a a的典型值為的典型值為3.03.0，在實(shí)際工作中

16、應(yīng)該根據(jù)歷史經(jīng)驗(yàn)數(shù)據(jù)確定一個(gè)適合本組織當(dāng)前開發(fā)的項(xiàng)目類型的數(shù)值。13.2.3 COCOMO2模型n為了確定工作量方程中模型指數(shù)b的值，原始的COCOMO模型把軟件開發(fā)項(xiàng)目劃分成組織式、半獨(dú)立式和嵌入式這樣3種類型，并指定每種項(xiàng)目類型所對(duì)應(yīng)的b值（分別是1.05，1.12和1.20）。nCOCOMO2采用了更加精細(xì)得多的b分級(jí)模型，這個(gè)模型使用5個(gè)分級(jí)因素Wi(1i5),其中每個(gè)因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個(gè)級(jí)別，然后用下式計(jì)算b的數(shù)值：nb=nb的取值范圍為1.011.26。這種分級(jí)模式比原始COCOMO模型的分級(jí)模式更精細(xì)、更靈活。 5101. 101. 1iiW13

17、.2.3 COCOMO2模型nCOCOMO2使用的5個(gè)分級(jí)因素如下所述： （1 1） 項(xiàng)目先例性。項(xiàng)目先例性。該因素指出，對(duì)于開發(fā)組織來說該項(xiàng)目的新奇程度。諸如開發(fā)類似系統(tǒng)的經(jīng)驗(yàn)，需要?jiǎng)?chuàng)新體系結(jié)構(gòu)和算法，以及需要并行開發(fā)硬件和軟件等因素的影響，都體現(xiàn)在這個(gè)分級(jí)因素中。（2 2） 開發(fā)靈活性。開發(fā)靈活性。這個(gè)分級(jí)因素反映出，為了實(shí)現(xiàn)預(yù)先確定的外部接口需求及為了及早開發(fā)出產(chǎn)品而需要增加的工作量。13.2.3 COCOMO2模型（3 3） 風(fēng)險(xiǎn)排除度。風(fēng)險(xiǎn)排除度。這個(gè)分級(jí)因素反映了重大風(fēng)險(xiǎn)已被消除的比例。在多數(shù)情況下，這個(gè)比例和指定了重要模塊接口（即選定了體系結(jié)構(gòu)）的比例密切相關(guān)。（4 4） 項(xiàng)目組

18、凝聚力。項(xiàng)目組凝聚力。這個(gè)分級(jí)因素表明了開發(fā)人員相互協(xié)作時(shí)可能存在的困難。這個(gè)因素反映了開發(fā)人員在目標(biāo)和文化背景等方面相一致的程度，以及開發(fā)人員組成一個(gè)小組工作的經(jīng)驗(yàn)。（5 5） 過程成熟度。過程成熟度。這個(gè)分級(jí)因素反映了按照能力成熟度模型（見13.7節(jié)）度量出的項(xiàng)目組織的過程成熟度。13.2.3 COCOMO2模型n每個(gè)成本因素都根據(jù)它的重要程度和對(duì)工作量影響大小被賦予一定數(shù)值（稱為工作量系數(shù)）。這些成本因素對(duì)任何一個(gè)項(xiàng)目的開發(fā)工作量都有影響，即使不使用COCOMO2模型估算工作量，也應(yīng)該重視這些因素。nBoehm把成本因素劃分成產(chǎn)品因素、平臺(tái)因素、人員因素和項(xiàng)目因素等4類。n表13.3列出

19、了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化： 13.2.3 COCOMO2模型（1） 新增加了4個(gè)成本因素。即可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點(diǎn)開發(fā)。這個(gè)變化表明，這些因素對(duì)開發(fā)成本的影響日益增加。（2） 略去了原始模型中的2個(gè)成本因素（計(jì)算機(jī)切換時(shí)間和使用現(xiàn)代程序設(shè)計(jì)實(shí)踐）。并且在COCOMO2工作量方程的指數(shù)b中考慮了這個(gè)因素的影響。（3） 調(diào)整成本因素的影響力。某些成本因素（分析員能力、平臺(tái)經(jīng)驗(yàn)、語言和工具經(jīng)驗(yàn)）對(duì)生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一

20、些成本因素（程序員能力）的影響減小了。13.3 進(jìn)度計(jì)劃n實(shí)際軟件項(xiàng)目中，在實(shí)現(xiàn)一個(gè)大目標(biāo)之前往往必須完成數(shù)以百計(jì)的小任務(wù)。n一些任務(wù)處于“關(guān)鍵路徑”之外，其完成時(shí)間如果沒有嚴(yán)重拖后，都不會(huì)影響項(xiàng)目的完成時(shí)間；n另一些任務(wù)處于“關(guān)鍵路徑”之中，如果這些“關(guān)鍵任務(wù)”的進(jìn)度拖后，則整個(gè)項(xiàng)目的完成日期就會(huì)拖后。n管理人員應(yīng)該高度關(guān)注關(guān)鍵任務(wù)的進(jìn)展情況。13.3 進(jìn)度計(jì)劃n一個(gè)有效的軟件過程應(yīng)該定義一個(gè)適用于當(dāng)前項(xiàng)目的定義一個(gè)適用于當(dāng)前項(xiàng)目的任務(wù)集合任務(wù)集合。一個(gè)任務(wù)集合包括一組軟件工程工作任務(wù)、里程碑和可交付的產(chǎn)品。n為一個(gè)項(xiàng)目所定義的任務(wù)集合，必須包括為獲得高質(zhì)包括為獲得高質(zhì)量的軟件產(chǎn)品而應(yīng)該完成

21、的所有任務(wù)，但是同時(shí)又不量的軟件產(chǎn)品而應(yīng)該完成的所有任務(wù)，但是同時(shí)又不能讓項(xiàng)目組承擔(dān)不必要的工作能讓項(xiàng)目組承擔(dān)不必要的工作。n項(xiàng)目管理者的目標(biāo)是定義全部項(xiàng)目任務(wù)，識(shí)別出關(guān)鍵任務(wù)，跟蹤關(guān)鍵任務(wù)的進(jìn)展?fàn)顩r，以保證能及時(shí)發(fā)現(xiàn)拖延進(jìn)度的情況。n為達(dá)到上述目標(biāo)，管理者必須制定一個(gè)足夠詳細(xì)的進(jìn)管理者必須制定一個(gè)足夠詳細(xì)的進(jìn)度表，以便監(jiān)督項(xiàng)目進(jìn)度并控制整個(gè)項(xiàng)目度表，以便監(jiān)督項(xiàng)目進(jìn)度并控制整個(gè)項(xiàng)目。13.3.1 估算開發(fā)時(shí)間n估算出完成給定項(xiàng)目所需的總工作量之后，接下來需要回答：用多長時(shí)間才能完成該項(xiàng)目的用多長時(shí)間才能完成該項(xiàng)目的開發(fā)工作？開發(fā)工作？對(duì)于一個(gè)估計(jì)工作量為20人月的項(xiàng)目，可能想出下列幾種進(jìn)度表：

22、n1個(gè)人用20個(gè)月完成該項(xiàng)目；n4個(gè)人用5個(gè)月完成該項(xiàng)目；n20個(gè)人用1個(gè)月完成該項(xiàng)目。n但是，這些進(jìn)度表并不現(xiàn)實(shí)，實(shí)際上軟件開發(fā)軟件開發(fā)時(shí)間與從事開發(fā)工作的人數(shù)之間并不是簡(jiǎn)單的時(shí)間與從事開發(fā)工作的人數(shù)之間并不是簡(jiǎn)單的反比關(guān)系反比關(guān)系。13.3.1 估算開發(fā)時(shí)間n成本估算模型也同時(shí)提供了估算開發(fā)時(shí)間T的方程。例如： (1) Walston_Felix(1) Walston_Felix模型模型 T=2.5ET=2.5E0.350.35(2) (2) 原始的原始的COCOMOCOCOMO模型模型 T=2.5ET=2.5E0.380.38(3) COCOMO2(3) COCOMO2模型模型 T=3.

23、0ET=3.0E0.33+0.20.33+0.2(b-1.01)(b-1.01)(4) Putnam(4) Putnam模型模型 T=2.4ET=2.4E1/31/3其中，E是開發(fā)工作量（以人月為單位），T是開發(fā)時(shí)間（以月為單位）。13.3.1 估算開發(fā)時(shí)間n用上列方程計(jì)算出的T值，代表正常情況下的正常情況下的開發(fā)時(shí)間開發(fā)時(shí)間。n客戶往往希望縮短軟件開發(fā)時(shí)間，顯然，為了為了縮短開發(fā)時(shí)間應(yīng)該縮短開發(fā)時(shí)間應(yīng)該增加從事開發(fā)工作的人數(shù)增加從事開發(fā)工作的人數(shù)。n但是，隨著開發(fā)小組規(guī)模擴(kuò)大，個(gè)人生產(chǎn)率將下降，以致開發(fā)時(shí)間與從事開發(fā)工作的人數(shù)并不成反比關(guān)系。出現(xiàn)此種情況的原因： 13.3.1 估算開發(fā)時(shí)間n

24、當(dāng)小組變得更大時(shí)，增加了通信開銷。n當(dāng)小組變得更大時(shí)，新成員在開始時(shí)不僅不是生產(chǎn)力，而且在他們學(xué)習(xí)期間還需要花費(fèi)小組其他成員的時(shí)間。n因此，存在被稱為Brooks規(guī)律的下述現(xiàn)象： 向一個(gè)已經(jīng)延期的項(xiàng)目增加人力，只會(huì)使得它向一個(gè)已經(jīng)延期的項(xiàng)目增加人力，只會(huì)使得它更加延期。更加延期。13.3.1 估算開發(fā)時(shí)間n項(xiàng)目組成員之間的通信路徑數(shù)由項(xiàng)目組人數(shù)和項(xiàng)目組結(jié)構(gòu)決定。n如果項(xiàng)目組共有P名組員，每個(gè)組員必須與所有其他組員通信以協(xié)調(diào)開發(fā)活動(dòng)，則通信路徑數(shù)為P(P-1)/2。n如果每個(gè)組員只需與另外一個(gè)組員通信，則通信路徑數(shù)為P-1。通信路徑數(shù)少于P-1是不合理的，因?yàn)槟菍?dǎo)致出現(xiàn)與任何人都沒有聯(lián)系的組員

25、。13.3.1 估算開發(fā)時(shí)間n通信路徑數(shù)大約在PP2/2的范圍內(nèi)。在一個(gè)層次結(jié)構(gòu)的項(xiàng)目組中，通信路徑數(shù)為 P P，其中，其中1212。n對(duì)于某一個(gè)組員來說，他與其他組員通信的路徑數(shù)在他與其他組員通信的路徑數(shù)在11（P-1P-1）的范圍內(nèi)變化。如果不與任何人通信時(shí)如果不與任何人通信時(shí)個(gè)人個(gè)人生產(chǎn)率為生產(chǎn)率為L L，每條通信路徑導(dǎo)致每條通信路徑導(dǎo)致生產(chǎn)率減少生產(chǎn)率減少l l，則組員個(gè)人平均生產(chǎn)率為： Lr=L-l(P-1)rnr是對(duì)通信路徑數(shù)的度量，00)。13.3.1 估算開發(fā)時(shí)間n對(duì)于一個(gè)規(guī)模為P的項(xiàng)目組，項(xiàng)目組的總生產(chǎn)率為 Ltot=P(L-l(P-1)r)n對(duì)于給定的一組L，l和r的值，總

26、生產(chǎn)率Ltot是項(xiàng)目組規(guī)模P的函數(shù)。隨著P值增加，Ltot將從0增大到某個(gè)最大值，然后再下降。因此，存在一個(gè)最佳的項(xiàng)目組規(guī)模最佳的項(xiàng)目組規(guī)模P Poptopt，這個(gè)規(guī)模的項(xiàng)目組其總生產(chǎn)率最高。參見表表13.413.4。13.3.1 估算開發(fā)時(shí)間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中。nBoehm根據(jù)經(jīng)驗(yàn)指出，軟件項(xiàng)目的開發(fā)時(shí)間最多軟件項(xiàng)目的開發(fā)時(shí)間最多可以減少到正常開發(fā)時(shí)間的可以減少到正常開發(fā)時(shí)間的75%75%。如果要求一個(gè)軟件系統(tǒng)的開

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

28、總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何時(shí)候都有10名工人閑著沒活干。n所以，應(yīng)該采用“流水作業(yè)法流水作業(yè)法”。工廠流水線工廠流水線13.3.2 Gantt圖n假設(shè)木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍，此外，不同工作需要用的時(shí)間長短也不同，刷新漆最費(fèi)時(shí)間，其次是刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時(shí)間最少。n表表13.513.5列出了估計(jì)每道工序需要用的時(shí)間。可以使用圖13.1中的Gantt圖描繪上述流水作業(yè)過程。13.3.3 工程網(wǎng)絡(luò)nGantt圖能很形象地描繪任務(wù)分解情況，以及每個(gè)子任務(wù)的開始時(shí)間和結(jié)束時(shí)間，因此是進(jìn)度計(jì)劃和進(jìn)度管理的有力工具

29、。它具有直觀簡(jiǎ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ò)n工程網(wǎng)絡(luò)是制定進(jìn)度計(jì)劃時(shí)另一種常用的圖形工具，它同樣能描繪任務(wù)分解情況以及每項(xiàng)作業(yè)的開始時(shí)間和結(jié)束時(shí)間。n此外，它還顯式地描繪各個(gè)作業(yè)彼此間的依賴關(guān)系。因此，工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計(jì)的強(qiáng)有力的工具。13.3.3 工程網(wǎng)絡(luò)n在工程網(wǎng)絡(luò)中用箭頭表示作業(yè)(例如，刮舊漆，刷新漆，清理

30、等)，用圓圈表示事件(一項(xiàng)作業(yè)開始或結(jié)束)。n事件是明確定義的時(shí)間點(diǎn)，它并不消耗時(shí)間和資源。作業(yè)通常既消耗資源又需要持續(xù)一定時(shí)間。13.3.3 工程網(wǎng)絡(luò)n在工程網(wǎng)絡(luò)中的一個(gè)事件，如果既有箭頭進(jìn)入又有箭頭離開，則它既是某些作業(yè)的結(jié)束又是另一些作業(yè)的開始。n例如，圖13.2中事件2既是作業(yè)12(刮第1面墻上的舊漆)的結(jié)束，又是作業(yè)23(刮第2面墻上舊漆)和作業(yè)24(給第1面墻刷新漆)的開始。n即只有第1面墻上的舊漆刮完之后，才能開始刮第2面墻上舊漆和給第1面墻刷新漆這兩個(gè)作業(yè)。因此，工程網(wǎng)絡(luò)顯式地表示了作業(yè)之間的依賴關(guān)系。13.3.3 工程網(wǎng)絡(luò)n在圖13.2中還有一些虛線箭頭，它們表示虛擬作業(yè)，也

31、就是事實(shí)上并不存在的作業(yè)。引入虛擬作業(yè)是為了顯式地表示作業(yè)之間的依賴關(guān)系。n例如，事件4既是給第1面墻刷新漆結(jié)束，又是給第2面墻刷新漆開始(作業(yè)46)。但是，在開始給第2面墻刷新漆之前，不僅必須已經(jīng)給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經(jīng)刮凈(事件3)。也就是說，在事件3和事件4之間有依賴關(guān)系，或者說在作業(yè)23(刮第2面墻上舊漆)和作業(yè)46(給第2面墻刷新漆)之間有依賴關(guān)系，虛擬作業(yè)34明確地表示了這種依賴關(guān)系。虛擬作業(yè)既不消耗資源也不需要時(shí)間。13.3.4 估算工程進(jìn)度n畫出類似圖13.2那樣的工程網(wǎng)絡(luò)之后，系統(tǒng)分析員就可以借助它的幫助估算工程進(jìn)度了。為此需要在工程網(wǎng)絡(luò)上增加一些

32、必要的信息。n首先，把每個(gè)作業(yè)估計(jì)需要使用的時(shí)間寫在表示該項(xiàng)作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時(shí)間沒有關(guān)系，箭頭僅表示依賴關(guān)系，它上方的數(shù)字才表示作業(yè)的持續(xù)時(shí)間。13.3.4 估算工程進(jìn)度n其次，為每個(gè)事件計(jì)算下述兩個(gè)統(tǒng)計(jì)數(shù)字： 最早時(shí)刻EET和最遲時(shí)刻LET。這兩個(gè)數(shù)字將分別寫在表示事件的圓圈的右上角和右下角。n事件的最早時(shí)刻是該事件可以發(fā)生的最早時(shí)間。事件的最早時(shí)刻是該事件可以發(fā)生的最早時(shí)間。工程網(wǎng)絡(luò)中第一個(gè)事件的最早時(shí)刻定義為零，其他事件的最早時(shí)刻在工程網(wǎng)絡(luò)上從左至右按事件從左至右按事件發(fā)生順序計(jì)算發(fā)生順序計(jì)算。計(jì)算最早時(shí)刻EET使用下述3條簡(jiǎn)單規(guī)則： 15-8-4=315

33、8413.3.4 估算工程進(jìn)度(1) 考慮進(jìn)入該事件的所有作業(yè)；(2) 計(jì)算每個(gè)作業(yè)的持續(xù)時(shí)間與起始事件的EET之和；(3) 選取上述和數(shù)中的最大值作為該事件的最早時(shí)刻EET。13.3.4 估算工程進(jìn)度n事件的最遲時(shí)刻是在不影響工程竣工時(shí)間的前事件的最遲時(shí)刻是在不影響工程竣工時(shí)間的前提下，該事件最晚可以發(fā)生的時(shí)刻。提下，該事件最晚可以發(fā)生的時(shí)刻。n最后一個(gè)事件(工程結(jié)束)的最遲時(shí)刻就是它的最早時(shí)刻。其他事件的最遲時(shí)刻在工程網(wǎng)絡(luò)上從從右至左按逆作業(yè)流的方向計(jì)算右至左按逆作業(yè)流的方向計(jì)算。計(jì)算最遲時(shí)刻LET使用下述3條規(guī)則： (1) 考慮離開該事件的所有作業(yè)；(2) 從每個(gè)作業(yè)的結(jié)束事件的最遲時(shí)刻

34、中減去該作業(yè)的持續(xù)時(shí)間；(3) 選取上述差數(shù)中的最小值作為該事件的最遲時(shí)刻LET。13.3.5 關(guān)鍵路徑n圖中有幾個(gè)事件的最早時(shí)刻和最遲時(shí)刻相同，最早時(shí)刻和最遲時(shí)刻相同，這些事件定義了關(guān)鍵路徑這些事件定義了關(guān)鍵路徑。n關(guān)鍵路徑上的事件必須準(zhǔn)時(shí)發(fā)生，組成關(guān)鍵路徑的作業(yè)的實(shí)際持續(xù)時(shí)間不能超過估計(jì)的持續(xù)時(shí)間，否則工程就不能準(zhǔn)時(shí)結(jié)束。n項(xiàng)目管理人員應(yīng)該注視關(guān)鍵作業(yè)的進(jìn)展情況，u如果關(guān)鍵事件出現(xiàn)的時(shí)間比預(yù)計(jì)的時(shí)間晚，則會(huì)使最終完成項(xiàng)目的時(shí)間拖后；u如果希望縮短工期，只有往關(guān)鍵作業(yè)中增加資源才會(huì)有效果。13.3.6 機(jī)動(dòng)時(shí)間n不在關(guān)鍵路徑上的作業(yè)有一定程度的機(jī)動(dòng)余地實(shí)際開始時(shí)間可以比預(yù)定時(shí)間晚一些，或者實(shí)

35、際持續(xù)時(shí)間可以比預(yù)定的持續(xù)時(shí)間長一些，而并不影響工程的結(jié)束時(shí)間。n一個(gè)作業(yè)可以有的全部機(jī)動(dòng)時(shí)間： 機(jī)動(dòng)時(shí)間機(jī)動(dòng)時(shí)間=(LET)=(LET)結(jié)束結(jié)束-(EET)-(EET)開始開始- -持續(xù)時(shí)間持續(xù)時(shí)間n對(duì)于前述油漆舊木板房的例子，計(jì)算得到的非關(guān)鍵作業(yè)的機(jī)動(dòng)時(shí)間列在表13.6中。13.3.6 機(jī)動(dòng)時(shí)間n在工程網(wǎng)絡(luò)中每個(gè)作業(yè)的機(jī)動(dòng)時(shí)間寫在代表該項(xiàng)作業(yè)的箭頭下面的括弧里。n在制定進(jìn)度計(jì)劃時(shí)仔細(xì)考慮和利用工程網(wǎng)絡(luò)中的機(jī)動(dòng)時(shí)間，往往能夠安排出既節(jié)省資源又不影響最終竣工時(shí)間的進(jìn)度表。在圖13.4中的Gantt圖描繪了其中的一種方案。13.3.6 機(jī)動(dòng)時(shí)間n這個(gè)例子說明了工程網(wǎng)絡(luò)比Gantt圖優(yōu)越的地方：

36、它顯式地定義事件及作業(yè)之間的依賴關(guān)系，Gantt圖只能隱含地表示這種關(guān)系。n但是Gantt圖的形式比工程網(wǎng)絡(luò)更簡(jiǎn)單更直觀，為更多的人所熟悉，因此，應(yīng)該同時(shí)使用這兩種工具制訂和管理進(jìn)度計(jì)劃，使它們互相補(bǔ)充取長補(bǔ)短。13.3.6 機(jī)動(dòng)時(shí)間n第13.2節(jié)中介紹的工作量估計(jì)技術(shù)可以幫助我們估計(jì)每項(xiàng)任務(wù)的工作量，根據(jù)人力分配情況，可以進(jìn)一步確定每項(xiàng)任務(wù)的持續(xù)時(shí)間。n從這些基本數(shù)據(jù)出發(fā)，根據(jù)作業(yè)之間的依賴關(guān)系，利用工程網(wǎng)絡(luò)和Gantt圖可以制定出合理的進(jìn)度計(jì)劃，并且能夠科學(xué)地管理軟件開發(fā)工程的進(jìn)展情況。13.4 人員組織（自學(xué)）n軟件項(xiàng)目成功的關(guān)鍵是有高素質(zhì)的軟件開發(fā)人成功的關(guān)鍵是有高素質(zhì)的軟件開發(fā)人員員

37、。n大多數(shù)軟件的規(guī)模都很大，單個(gè)軟件開發(fā)人員無法在給定期限內(nèi)完成開發(fā)工作，因此，必須把多名軟件開發(fā)人員合理地組織起來合理地組織起來，使他們有效地分工協(xié)作共同完成開發(fā)工作。n為了成功地完成軟件開發(fā)工作，項(xiàng)目組成員必須以一種有意義且有效的方式彼此交互和通信有意義且有效的方式彼此交互和通信。13.4 人員組織n如何組織項(xiàng)目組是一個(gè)重要的管理問題，管理者應(yīng)合理組織項(xiàng)目組，使其有較高生產(chǎn)率，能使其有較高生產(chǎn)率，能夠按預(yù)定的進(jìn)度計(jì)劃完成所承擔(dān)的工作夠按預(yù)定的進(jìn)度計(jì)劃完成所承擔(dān)的工作。n項(xiàng)目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)項(xiàng)目組組織得越好，其生產(chǎn)率越高，而且產(chǎn)品質(zhì)量也越好品質(zhì)量也越好。n每個(gè)管理者的目標(biāo)都

38、是建立有凝聚力的項(xiàng)目組建立有凝聚力的項(xiàng)目組。一個(gè)有高度凝聚力的小組，由一批團(tuán)結(jié)得非常緊密的人組成，他們的整體力量大于個(gè)體力量的總和。一旦項(xiàng)目組具有了凝聚力，成功的可能性就大大增加了。13.4 人員組織n現(xiàn)有的軟件項(xiàng)目組的組織方式很多，通常，組織軟件開發(fā)人員的方法，取決于所承擔(dān)的項(xiàng)目取決于所承擔(dān)的項(xiàng)目的特點(diǎn)、以往的組織經(jīng)驗(yàn)以及管理者的看法和的特點(diǎn)、以往的組織經(jīng)驗(yàn)以及管理者的看法和喜好喜好。下面介紹3種典型的組織方式。n民主制程序員組n主程序員組n現(xiàn)代程序員組13.4.1 民主制程序員組n民主制程序員組的一個(gè)重要特點(diǎn)是小組成員完全平等，享有充分民主，通過協(xié)商做出技術(shù)決策。n小組成員之間的通信是平行

39、的，如果小組內(nèi)有n個(gè)成員，則可能的通信信道共有n(n-1)/2條。n程序設(shè)計(jì)小組的人數(shù)不能太多。n通信信道的維護(hù)難度增加；n測(cè)試和軟件接口的復(fù)雜性增加；大家都有發(fā)言權(quán)大家都有發(fā)言權(quán)13.4.1 民主制程序員組n程序設(shè)計(jì)小組的規(guī)模以28名成員為宜。n若項(xiàng)目規(guī)模很大,用一個(gè)小組不能在預(yù)定時(shí)間內(nèi)完成開發(fā)任務(wù),則應(yīng)該使用多個(gè)程序設(shè)計(jì)小組。n系統(tǒng)的總體設(shè)計(jì)應(yīng)該能夠保證由各個(gè)小組負(fù)責(zé)開發(fā)的各部分之間的接口是良好定義的,并且是盡可能簡(jiǎn)單的。n小組規(guī)模小,不僅可以減少通信問題,而且還有其他好處。例如,容易確定小組的質(zhì)量標(biāo)準(zhǔn),而且用民主方式確定的標(biāo)準(zhǔn)更容易被大家遵守;組員間關(guān)系密切,能夠互相學(xué)習(xí)等等。13.4.

40、1 民主制程序員組n民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個(gè)組長，但是他和組內(nèi)其他成員完成同樣的任務(wù)。n在這樣的小組中，由全體討論協(xié)商決定應(yīng)該完成的工作，并且根據(jù)每個(gè)人的能力和經(jīng)驗(yàn)分配適當(dāng)?shù)娜蝿?wù)。n民主制程序員組的主要優(yōu)點(diǎn)是，組員們對(duì)發(fā)現(xiàn)程序錯(cuò)誤持積極的態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯(cuò)誤，從而導(dǎo)致高質(zhì)量的代碼。13.4.1 民主制程序員組n民主制程序員組的另一個(gè)優(yōu)點(diǎn)是，組員們享有充分民主，小組有高度凝聚力，組內(nèi)學(xué)術(shù)空氣濃厚，有利于攻克技術(shù)難關(guān)。n因此，當(dāng)有難題需要解決時(shí)，也就是說，當(dāng)所要開發(fā)的軟件的技術(shù)難度較高時(shí)，采用民主制程序員組是適宜的。n如果組內(nèi)多數(shù)成員是經(jīng)驗(yàn)

41、豐富技術(shù)熟練的程序員,那么上述非正式的組織方式可能會(huì)非常成功。在這樣的小組內(nèi)組員享有充分民主,通過協(xié)商,在自愿的基礎(chǔ)上作出決定,因此能夠增強(qiáng)團(tuán)結(jié)、提高工作效率。13.4.1 民主制程序員組n如果組內(nèi)多數(shù)成員技術(shù)水平不高,或是缺乏經(jīng)驗(yàn)的新手,那么這種非正式的組織方式也有嚴(yán)重缺點(diǎn)： 由于沒有明確的權(quán)威指導(dǎo)開發(fā)工程的進(jìn)行,組員間將缺乏必要的協(xié)調(diào),最終可能導(dǎo)致工程失敗。n為了使少數(shù)經(jīng)驗(yàn)豐富、技術(shù)高超的程序員在軟件開發(fā)過程中能夠發(fā)揮更大作用，程序設(shè)計(jì)小組也可以采用下面的另外一種組織形式。13.4.2 主程序員組n美國IBM公司在20世紀(jì)70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下

42、述幾點(diǎn)考慮： (1) 軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗(yàn)多數(shù)比較缺乏經(jīng)驗(yàn)；(2) 程序設(shè)計(jì)過程中有許多事務(wù)性的工作有許多事務(wù)性的工作，例如，大量信息的存儲(chǔ)和更新；(3) 多渠道通信很費(fèi)時(shí)間，將降低程序員的生產(chǎn)率。13.4.2 主程序員組n主程序員組用經(jīng)驗(yàn)多、技術(shù)好、能力強(qiáng)的程序員作為主程序員，同時(shí)，利用人和計(jì)算機(jī)在事務(wù)性工作方面給主程序員提供充分支持，而且所有通信都通過一兩個(gè)人進(jìn)行。n這種組織方式類似于外科手術(shù)小組的組織： 主刀大夫?qū)κ中g(shù)全面負(fù)責(zé)，并且完成制訂手術(shù)方案、開刀等關(guān)鍵工作，同時(shí)又有麻醉師、護(hù)士長等技術(shù)熟練的專門人員協(xié)助和配合他的工作。此外，必要時(shí)手術(shù)組還要請(qǐng)其他領(lǐng)域的專家協(xié)助。13.4.

43、2 主程序員組n主程序員組的兩個(gè)重要特性： （1 1） 專業(yè)化。專業(yè)化。該組每名成員僅完成他們受過專業(yè)訓(xùn)練的那些工作。（2 2） 層次性。層次性。主刀大夫指揮每名組員工作，并對(duì)手術(shù)全面負(fù)責(zé)。n典型的主程序員組的組織形式如圖13.5所示。該組由主程序員、后備程序員、編程秘書以及13名程序員組成。在必要的時(shí)候，該組還有其他領(lǐng)域的專家協(xié)助。13.4.2 主程序員組管理者兼管理者兼構(gòu)架師構(gòu)架師主程序員主程序員的替補(bǔ)的替補(bǔ)主程序員主程序員的助手的助手代碼編寫代碼編寫者者13.4.2 主程序員組n主程序員組核心人員的分工如下： （1） 主程序員既是成功的管理人員又是經(jīng)驗(yàn)豐富、主程序員既是成功的管理人員又是

44、經(jīng)驗(yàn)豐富、技術(shù)好、能力強(qiáng)的高級(jí)程序員技術(shù)好、能力強(qiáng)的高級(jí)程序員，負(fù)責(zé)體系結(jié)構(gòu)設(shè)計(jì)和，負(fù)責(zé)體系結(jié)構(gòu)設(shè)計(jì)和關(guān)鍵部分的詳細(xì)設(shè)計(jì)，并且負(fù)責(zé)指導(dǎo)其他程序員完成關(guān)鍵部分的詳細(xì)設(shè)計(jì)，并且負(fù)責(zé)指導(dǎo)其他程序員完成詳細(xì)設(shè)計(jì)和編碼工作。詳細(xì)設(shè)計(jì)和編碼工作。程序員之間沒有通信渠道，所有接口問題都由主程序員處理。主程序員對(duì)每行代碼的質(zhì)量負(fù)責(zé)，因此，他還要對(duì)組內(nèi)其他成員的工作成果進(jìn)行復(fù)查。13.4.2 主程序員組（2） 后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗(yàn)后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗(yàn)，他他協(xié)助主程序員工作并且在必要時(shí)接替主程序員的工作協(xié)助主程序員工作并且在必要時(shí)接替主程序員的工作。平時(shí)，后備程序員的工作主要是設(shè)計(jì)

45、測(cè)試方案、分析測(cè)試結(jié)果及獨(dú)立于設(shè)計(jì)過程的其他工作。（3） 編程秘書負(fù)責(zé)完成與項(xiàng)目有關(guān)的全部事務(wù)性工編程秘書負(fù)責(zé)完成與項(xiàng)目有關(guān)的全部事務(wù)性工作作，例如，維護(hù)項(xiàng)目資料庫和項(xiàng)目文檔，編譯、鏈接、執(zhí)行源程序和測(cè)試用例。13.4.2 主程序員組n雖然圖13.5所示的主程序員組的組織方式說起來有不少優(yōu)點(diǎn)，但是，它在許多方面卻是不切實(shí)際的。n首先，主程序員應(yīng)該是高級(jí)程序員和優(yōu)秀管理者的結(jié)合體。在現(xiàn)實(shí)社會(huì)中這樣的人才并不多見在現(xiàn)實(shí)社會(huì)中這樣的人才并不多見。n其次，后備程序員更難找后備程序員更難找。n第三，編程秘書也很難找到。專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù)性工作，13.4.3 現(xiàn)代程序員組n民主制程序員

46、組的一個(gè)優(yōu)點(diǎn)是小組成員都對(duì)發(fā)小組成員都對(duì)發(fā)現(xiàn)程序錯(cuò)誤持積極、主動(dòng)的態(tài)度現(xiàn)程序錯(cuò)誤持積極、主動(dòng)的態(tài)度。但是，使用主程序員組的組織方式時(shí)，主程序員對(duì)每行代碼的質(zhì)量負(fù)責(zé)，因此，他必須參與所有代碼審查工作。n由于主程序員同時(shí)又是負(fù)責(zé)對(duì)小組成員進(jìn)行評(píng)價(jià)的管理員，他參與代碼審查工作就會(huì)把所發(fā)把所發(fā)現(xiàn)的程序錯(cuò)誤與小組成員的工作業(yè)績聯(lián)系起來現(xiàn)的程序錯(cuò)誤與小組成員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯(cuò)誤的心理造成小組成員出現(xiàn)不愿意發(fā)現(xiàn)錯(cuò)誤的心理。13.4.3 現(xiàn)代程序員組n可以取消主程序員的大部分行政管理工作。n于是，實(shí)際的“主程序員”應(yīng)該由兩個(gè)人共同擔(dān)任： u 一個(gè)技術(shù)負(fù)責(zé)人，負(fù)責(zé)小組的技術(shù)活動(dòng)

47、；u一個(gè)行政負(fù)責(zé)人，負(fù)責(zé)所有非技術(shù)性事務(wù)的管理決策。n如圖13.6所示。技術(shù)組長自然要參與全部代碼審查工作，因?yàn)樗獙?duì)代碼的各方面質(zhì)量負(fù)責(zé)；相反，行政組長不可以參與代碼審查工作，因?yàn)樗穆氊?zé)是對(duì)程序員的業(yè)績進(jìn)行評(píng)價(jià)。行政組長應(yīng)該在常規(guī)調(diào)度會(huì)議上了解每名組員的技術(shù)能力和工作業(yè)績。13.4.3 現(xiàn)代程序員組13.4.3 現(xiàn)代程序員組n在開始工作之前明確劃分明確劃分技術(shù)組長和行政組長的管理權(quán)限管理權(quán)限是很重要的。注意協(xié)調(diào)。注意協(xié)調(diào)。n例如，考慮年度休假問題，行政組長有權(quán)批準(zhǔn)某個(gè)程序員休年假的申請(qǐng)，因?yàn)檫@是一個(gè)非技術(shù)性問題，但是技術(shù)組長可能馬上否決了這個(gè)申請(qǐng)，因?yàn)橐呀?jīng)接近預(yù)定的項(xiàng)目結(jié)束日期，目前人手非

48、常緊張。n解決這類問題的辦法是求助于更高層的管理人員，對(duì)行政組長和技術(shù)組長都認(rèn)為是屬于自己職責(zé)范圍內(nèi)的事務(wù)，制定一個(gè)處理方案。13.4.3 現(xiàn)代程序員組n由于程序員組成員人數(shù)不宜過多，當(dāng)軟件項(xiàng)目規(guī)模較大時(shí)，應(yīng)該把程序員分成若干個(gè)小組，如圖13.7所示。n該圖描繪的是技術(shù)管理組織結(jié)構(gòu)，非技術(shù)管理組織結(jié)構(gòu)與此類似。n由圖可以看出，產(chǎn)品開發(fā)作為一個(gè)整體是在項(xiàng)目經(jīng)理的指導(dǎo)下進(jìn)行的，程序員向他們的組長匯報(bào)工作，而組長則向項(xiàng)目經(jīng)理匯報(bào)工作。當(dāng)產(chǎn)品規(guī)模更大時(shí)，可以適當(dāng)增加中間管理層次。13.4.3 現(xiàn)代程序員組13.4.3 現(xiàn)代程序員組n把民主制程序員組和主程序員組的優(yōu)點(diǎn)結(jié)合起來的另一種方法，是在合適的地方

49、采用分散做決定的方法分散做決定的方法，如圖13.8所示。這樣做有利于形成暢通的通信渠道，以便充分發(fā)揮每個(gè)程序員的積極性和主動(dòng)性，集思廣益攻克技術(shù)難關(guān)。n這種組織方式對(duì)于適合采用民主方法的那類問題（例如，研究性項(xiàng)目或遇到技術(shù)難題需要用集體智慧攻關(guān)）非常有效。n盡管這種組織方式適當(dāng)?shù)匕l(fā)揚(yáng)了民主，但是上下級(jí)之間的箭頭（即管理關(guān)系）仍然是向下的，也就是說，是在集中指導(dǎo)下發(fā)揚(yáng)民主集中指導(dǎo)下發(fā)揚(yáng)民主。顯然，如果程序員可以指揮項(xiàng)目經(jīng)理，則只會(huì)引起混亂。13.4.3 現(xiàn)代程序員組13.5 質(zhì)量保證 13.5.1 軟件質(zhì)量n軟件質(zhì)量就是軟件質(zhì)量就是“軟件與明確地和隱含地定義軟件與明確地和隱含地定義的需求相一致的

50、程度的需求相一致的程度”。n軟件質(zhì)量是軟件與明確地?cái)⑹龅墓δ芎托阅苘浖|(zhì)量是軟件與明確地?cái)⑹龅墓δ芎托阅苄枨?、文檔中明確描述的開發(fā)標(biāo)準(zhǔn)以及任何專需求、文檔中明確描述的開發(fā)標(biāo)準(zhǔn)以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。致的程度。n上述定義強(qiáng)調(diào)了下述的3個(gè)要點(diǎn)： 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ù)的）。如果軟件滿足明確描述的需求

51、，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。13.5.1 軟件質(zhì)量n可以把這些質(zhì)量因素分成3組，分別反映用戶在使用軟件產(chǎn)品時(shí)的3種不同傾向或觀點(diǎn)。n這3種傾向是： 產(chǎn)品運(yùn)行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。n圖13.9描繪了軟件質(zhì)量因素和上述3種傾向(或產(chǎn)品活動(dòng))之間的關(guān)系，表13.7列出了軟件質(zhì)量因素的簡(jiǎn)明定義。13.5.2 軟件質(zhì)量保證措施n軟件質(zhì)量保證（software quality assurance,SQA）的措施主要有： 基于非執(zhí)行的測(cè)試（也稱為復(fù)審或評(píng)審），基于執(zhí)行的測(cè)試（即以前講過的軟件測(cè)試）和程序正確性證明。13.5.2 軟件質(zhì)量保證措施n復(fù)審復(fù)審保證在編碼之前各階段產(chǎn)生的

52、文檔的質(zhì)量保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量；n基于執(zhí)行的測(cè)試基于執(zhí)行的測(cè)試需要在程序編寫出來之后進(jìn)行，需要在程序編寫出來之后進(jìn)行，它是保證軟件質(zhì)量的最后一道防線它是保證軟件質(zhì)量的最后一道防線；n程序正確性證明程序正確性證明使用數(shù)學(xué)方法嚴(yán)格驗(yàn)證程序是使用數(shù)學(xué)方法嚴(yán)格驗(yàn)證程序是否與對(duì)它的說明完全一致否與對(duì)它的說明完全一致。13.5.2 軟件質(zhì)量保證措施n參加軟件質(zhì)量保證工作的人員，可以劃分成下述兩類： n軟件工程師：通過采用先進(jìn)的技術(shù)方法和度量，進(jìn)行正式的技術(shù)復(fù)審以及完成計(jì)劃周密的軟件測(cè)試來保證軟件質(zhì)量。nSQA小組：輔助軟件工程師以獲得高質(zhì)量的軟件產(chǎn)品。其從事的軟件質(zhì)量保證活動(dòng)主要是：計(jì)劃，

53、監(jiān)督，記錄，分析和報(bào)告。SQA小組的作用是，通過確保軟件過程的質(zhì)量來保證軟件產(chǎn)品的質(zhì)量。13.5.2 軟件質(zhì)量保證措施1. 1. 技術(shù)復(fù)審的必要性技術(shù)復(fù)審的必要性n正式技術(shù)復(fù)審的顯著優(yōu)點(diǎn)是較早發(fā)現(xiàn)軟件錯(cuò)誤，從而可防止錯(cuò)誤被傳播到軟件過程的后續(xù)階段。n統(tǒng)計(jì)數(shù)字表明，在大型軟件產(chǎn)品中檢測(cè)出的錯(cuò)誤，60%70%屬于規(guī)格說明錯(cuò)誤或設(shè)計(jì)錯(cuò)誤，而正式技術(shù)復(fù)審在發(fā)現(xiàn)規(guī)格說明錯(cuò)誤和設(shè)計(jì)錯(cuò)誤方面的有效性高達(dá)75%。n正式技術(shù)復(fù)審是軟件質(zhì)量保證措施的一種包括走查（walkthrough)和審查（inspection）。走查的步驟比審查少，而且沒有審查正規(guī)。13.5.2 軟件質(zhì)量保證措施2. 2. 走查走查n走查組

54、由46名成員組成。以走查規(guī)格說明的小組為例，包括n一名負(fù)責(zé)起草規(guī)格說明的人n一名負(fù)責(zé)該規(guī)格說明的管理員n一位客戶代表n下階段開發(fā)組（在本例中是設(shè)計(jì)組）的一名代表nSQA小組的一名代表。SQA小組的代表應(yīng)該作為走查組的組長。n必須把被走查的材料預(yù)先分發(fā)給走查組每位成員。走查組成員應(yīng)該仔細(xì)研究材料并列出兩張表：一張表是他不理解的術(shù)語，另一張是他認(rèn)為不正確的術(shù)語。13.5.2 軟件質(zhì)量保證措施n走查組的任務(wù)僅僅是標(biāo)記出錯(cuò)誤而不是改正錯(cuò)誤，改正錯(cuò)誤的工作應(yīng)該由該文檔的編寫組完成。n走查的時(shí)間最長不要超過2小時(shí)，這段時(shí)間應(yīng)該用來發(fā)現(xiàn)和標(biāo)記錯(cuò)誤，而不是改正錯(cuò)誤。13.5.2 軟件質(zhì)量保證措施走查主要有下述

55、兩種方式： （1 1） 參與者驅(qū)動(dòng)法。參與者驅(qū)動(dòng)法。參與者按照事先準(zhǔn)備好的列表，提出他們不理解的術(shù)語和認(rèn)為不正確的術(shù)語。文檔編寫組的代表必須回答每個(gè)質(zhì)疑，要么承認(rèn)確實(shí)有錯(cuò)誤，要么對(duì)質(zhì)疑做出解釋。（2 2） 文檔驅(qū)動(dòng)法。文檔驅(qū)動(dòng)法。文檔編寫者向走查組成員仔細(xì)解釋文檔。走查組成員在此過程中不時(shí)針對(duì)事先準(zhǔn)備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。這種方法可能比第一種方法更有效，往往能檢測(cè)出更多錯(cuò)誤。經(jīng)驗(yàn)表明，使用文檔驅(qū)動(dòng)法時(shí)許多錯(cuò)誤是由文檔講解者自己發(fā)現(xiàn)的。13.5.2 軟件質(zhì)量保證措施3. 3. 審查審查n審查的范圍比走查廣泛得多，通常，審查過程包括下述5個(gè)基本步驟： （1 1） 綜述。綜述。由負(fù)

56、責(zé)編寫文檔的一名成員向?qū)彶榻M綜述該文檔。在綜述會(huì)結(jié)束時(shí)把文檔分發(fā)給每位與會(huì)者。（2 2） 準(zhǔn)備。準(zhǔn)備。評(píng)審員仔細(xì)閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯(cuò)誤的類型，并按發(fā)生頻率把錯(cuò)誤類型分級(jí)，以輔助審查工作。這些列表有助于評(píng)審員們把注意力集中到最常發(fā)生錯(cuò)誤的區(qū)域。13.5.2 軟件質(zhì)量保證措施（3 3） 審查。審查。評(píng)審組仔細(xì)走查整個(gè)文檔。和走查一樣，這一步的目的也是發(fā)現(xiàn)文檔中的錯(cuò)誤，而不是改正它們。通常每次審查會(huì)不超過90分鐘。審查組組長應(yīng)該在一天之內(nèi)寫出一份關(guān)于審查的報(bào)告。（4 4） 返工。返工。文檔的作者負(fù)責(zé)解決在審查報(bào)告中列出的所有錯(cuò)誤及問題。（5 5） 跟蹤。跟蹤。組長必須確保所提出的每個(gè)問

57、題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認(rèn)為是錯(cuò)誤的條目）。必須仔細(xì)檢查對(duì)文檔所做的每個(gè)修正，以確保沒有引入新的錯(cuò)誤。如果在審查過程中返工量超過5%，則應(yīng)該由審查組再對(duì)文檔全面地審查一遍。13.5.2 軟件質(zhì)量保證措施n通常，審查組由4人組成。組長既是審查組的管理人員又是技術(shù)負(fù)責(zé)人。審查組必須包括負(fù)責(zé)當(dāng)前階段開發(fā)工作的項(xiàng)目組代表和負(fù)責(zé)下一階段開發(fā)工作的項(xiàng)目組代表，此外，還應(yīng)該包括一名SQA小組的代表。n審查過程不僅步數(shù)比走查多，而且每個(gè)步驟都是正規(guī)的。審查的正規(guī)性體現(xiàn)在：仔細(xì)劃分錯(cuò)審查的正規(guī)性體現(xiàn)在：仔細(xì)劃分錯(cuò)誤類型，并把這些信息運(yùn)用在后續(xù)階段的文檔誤類型，并把這些信息運(yùn)用在后續(xù)階

58、段的文檔審查中以及未來產(chǎn)品的審查中審查中以及未來產(chǎn)品的審查中。13.5.2 軟件質(zhì)量保證措施n審查是檢測(cè)軟件錯(cuò)誤的一種好方法，利用審查可以在軟件過程的早期階段發(fā)現(xiàn)并改正錯(cuò)誤，也就是說，能在修正錯(cuò)誤的代價(jià)變得很昂貴之前就發(fā)現(xiàn)并改正錯(cuò)誤。n因此，審查是一種經(jīng)濟(jì)有效的錯(cuò)誤檢測(cè)方法。13.5.2 軟件質(zhì)量保證措施4. 4. 程序正確性證明（自學(xué)）程序正確性證明（自學(xué)）n測(cè)試是保證軟件可靠性的重要手段；但是，測(cè)試只能證明程序中有錯(cuò)誤，并不能證明程序中沒有錯(cuò)誤。n對(duì)于保證軟件可靠性來說，測(cè)試是一種不完善的技術(shù)，人們自然希望研究出完善的正確性證明技術(shù)。一旦研究出實(shí)用的正確性證明程序，軟件可靠性將更有保證，測(cè)

59、試工作量將大大減少。n程序正確性證明只證明程序功能是正確的，并不能證明程序的動(dòng)態(tài)特性是符合要求的，此外，正確性證明過程本身也可能發(fā)生錯(cuò)誤。13.5.2 軟件質(zhì)量保證措施n正確性證明的基本思想是證明程序能完成預(yù)定的功能。因此，應(yīng)該提供對(duì)程序功能的嚴(yán)格數(shù)學(xué)說明，然后根據(jù)程序代碼證明程序確實(shí)能實(shí)現(xiàn)它的功能說明。n在20世紀(jì)60年代初期，人們已經(jīng)開始研究程序正確性證明的技術(shù)，提出了許多不同的技術(shù)方法。雖然這些技術(shù)方法本身很復(fù)雜，但是它們的基本原理卻是相當(dāng)簡(jiǎn)單的。13.5.2 軟件質(zhì)量保證措施n如果在程序的若干個(gè)點(diǎn)上，設(shè)計(jì)者可以提出關(guān)于程序變量及它們的關(guān)系的斷言，那么在每一點(diǎn)上的斷言都應(yīng)該永遠(yuǎn)是真的。n

60、假設(shè)在程序的P1,P2,，Pn等點(diǎn)上的斷言分別是a(1),a(2)，a(n)，其中a(1)必須是關(guān)于程序輸入的斷言，a(n)必須是關(guān)于程序輸出的斷言。13.5.2 軟件質(zhì)量保證措施n為了證明在點(diǎn)Pi和Pi+1之間的程序語句是正確的，必須證明執(zhí)行這些語句之后將使斷言a(i)變成a(i+1)。n如果對(duì)程序內(nèi)所有相鄰點(diǎn)都能完成上述證明過程，則證明了輸入斷言加上程序可以導(dǎo)出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實(shí)是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。13.5.2 軟件質(zhì)量保證措施n人工證明程序正確性，對(duì)于評(píng)價(jià)小程序可能有些價(jià)值，但是在證明大型軟件的正確性時(shí)，不僅工作量太大