軟件工程導(dǎo)論之軟件項(xiàng)目管理第五張海藩編著PPT課件

1、 所謂管理就是通過(guò)計(jì)劃、組織和控制等一系列活動(dòng)，合理地配置和使用各種資源，以達(dá)到既定目標(biāo)的過(guò)程。第1頁(yè)/共96頁(yè) 軟件項(xiàng)目管理先于任何技術(shù)活動(dòng)之前開(kāi)始，并且貫穿于軟件的整個(gè)生命周期之中。 軟件項(xiàng)目管理過(guò)程從一組項(xiàng)目計(jì)劃活動(dòng)開(kāi)始，而制定計(jì)劃的基礎(chǔ)是工作量估算和完成期限估算。 為了估算項(xiàng)目的工作量和完成期限，首先需要估算軟件的規(guī)模。第2頁(yè)/共96頁(yè)13.1 估算軟件規(guī)模13.1.1 代碼行技術(shù) 代碼行技術(shù)是比較簡(jiǎn)單的定量估算軟件規(guī)模的方法。 依據(jù)以往開(kāi)發(fā)類似產(chǎn)品的經(jīng)驗(yàn)和歷史數(shù)據(jù)，估計(jì)實(shí)現(xiàn)一個(gè)功能所需要的源程序行數(shù)。 當(dāng)有以往開(kāi)發(fā)類似產(chǎn)品的歷史數(shù)據(jù)可供參考時(shí)，估計(jì)出的數(shù)值還是比較準(zhǔn)確的。把實(shí)現(xiàn)每個(gè)功

2、能所需要的源程序行數(shù)累加起來(lái)，就可得到實(shí)現(xiàn)整個(gè)軟件所需要的源程序行數(shù)。 第3頁(yè)/共96頁(yè)估算方法： 由多名有經(jīng)驗(yàn)的軟件工程師分別做出估計(jì)。 每個(gè)人都估計(jì)程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m)， 分別算出這3種規(guī)模的平均值、和之后，再用下式計(jì)算程序規(guī)模的估計(jì)值：?jiǎn)挝唬?LOC或KLOC。 64bmaL第4頁(yè)/共96頁(yè)代碼行技術(shù)的優(yōu)點(diǎn)： 代碼是所有軟件開(kāi)發(fā)項(xiàng)目都有的“產(chǎn)品”，而且很容易計(jì)算代碼行數(shù)； 有大量參考文獻(xiàn)和數(shù)據(jù) 。代碼行技術(shù)的缺點(diǎn)： 源程序僅是軟件配置的一個(gè)成分，由源程序度量軟件規(guī)模不太合理； 用不同語(yǔ)言實(shí)現(xiàn)同一個(gè)軟件所需要的代碼行數(shù)并不相同； 不適用于非過(guò)程性語(yǔ)言。第

3、5頁(yè)/共96頁(yè)13.1.2 功能點(diǎn)技術(shù) 功能點(diǎn)技術(shù)依據(jù)對(duì)軟件信息域特性和軟件復(fù)雜性的評(píng)估結(jié)果，估算軟件規(guī)模。 這種方法用功能點(diǎn)(FP)為單位度量軟件規(guī)模。 第6頁(yè)/共96頁(yè)1. 信息域特性功能點(diǎn)技術(shù)定義了信息域的5個(gè)特性： 輸入項(xiàng)數(shù)(Inp)：用戶向軟件輸入的項(xiàng)數(shù)，這些輸入給軟件提供面向應(yīng)用的數(shù)據(jù)。 輸出項(xiàng)數(shù)(Out)：軟件向用戶輸出的項(xiàng)數(shù)，它們向用戶提供面向應(yīng)用的信息， 查詢數(shù)(Inq)：查詢即是一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出方式產(chǎn)生某種即時(shí)響應(yīng)。 主文件數(shù)(Maf)：邏輯主文件的數(shù)目。 外部接口數(shù)(Inf)：機(jī)器可讀的全部接口的數(shù)量，用這些接口把信息傳送給另一個(gè)系統(tǒng)。 第7頁(yè)/共96頁(yè)

4、 每個(gè)特征根據(jù)其復(fù)雜程度分配一個(gè)功能點(diǎn)數(shù)，即信息域特征系數(shù)a1，a2，a3，a4，a5，見(jiàn)表13.1。表 13. 1 信息域特性系數(shù)值 復(fù)雜級(jí)別特性系數(shù)簡(jiǎn)單平均復(fù)雜輸入系數(shù) a1346輸出系數(shù) a2457查詢系數(shù) a3346文件系數(shù) a471015接口系數(shù) a55710第8頁(yè)/共96頁(yè)2. 估算功能點(diǎn)的步驟(1) 計(jì)算未調(diào)整的功能點(diǎn)數(shù)UFP 首先，把產(chǎn)品信息域的每個(gè)特性都分類為簡(jiǎn)單級(jí)、平均級(jí)或復(fù)雜級(jí)，并根據(jù)其等級(jí)為每個(gè)特性分配一個(gè)功能點(diǎn)數(shù)。 然后，用下式計(jì)算未調(diào)整的功能點(diǎn)數(shù)UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，ai(1i5)是信息域特性系數(shù)，其值由

5、相應(yīng)特性的復(fù)雜級(jí)別決定，如表13.1所示。 第9頁(yè)/共96頁(yè)(2) 計(jì)算技術(shù)復(fù)雜性因子TCF 這一步驟度量14種技術(shù)因素對(duì)軟件規(guī)模的影響程度。在表13.2中列出了全部技術(shù)因素，并用Fi(1i14)代表這些因素。 根據(jù)軟件的特點(diǎn)，為每個(gè)因素分配一個(gè)從0（不存在或?qū)浖?guī)模無(wú)影響）到5（有很大影響）的值。第10頁(yè)/共96頁(yè)表 13 . 2 技術(shù)因素序號(hào)Fi技術(shù)因素1 F1 數(shù)據(jù)通信2 F2 分布式數(shù)據(jù)處理3 F3 性能標(biāo)準(zhǔn)4 F4 高負(fù)荷的硬件5 F5 高處理率6 F6 聯(lián)機(jī)數(shù)據(jù)輸入7 F7 終端用戶效率8 F8 聯(lián)機(jī)更新9 F9 復(fù)雜的計(jì)算10 F10 可重用性11 F11 安裝方便12 F12

6、 操作方便13 F13 可移植性14 F14 可維護(hù)性第11頁(yè)/共96頁(yè) 然后，用下式計(jì)算技術(shù)因素對(duì)軟件規(guī)模的綜合影響程度DI： 技術(shù)復(fù)雜性因子TCF由下式計(jì)算： TCF = 0.65 + 0.01 DI 因?yàn)镈I的值在070之間，所以TCF的值在0.651.35之間。141DIiiF第12頁(yè)/共96頁(yè)(3) 計(jì)算功能點(diǎn)數(shù)FPFP = UFP TCF 功能點(diǎn)技術(shù)優(yōu)點(diǎn)：與所用的編程語(yǔ)言無(wú)關(guān)，比代碼行技術(shù)更合理。 功能點(diǎn)技術(shù)缺點(diǎn)：在判斷信息域特性復(fù)雜級(jí)別和技術(shù)因素的影響程度時(shí)主觀因素較大，對(duì)經(jīng)驗(yàn)依賴性較強(qiáng)。 第13頁(yè)/共96頁(yè)13.2 工作量估算 軟件估算模型使用由經(jīng)驗(yàn)導(dǎo)出的公式來(lái)預(yù)測(cè)軟件開(kāi)發(fā)工作

7、量，工作量是軟件規(guī)模(KLOC或FP)的函數(shù)，工作量的單位通常是人月(pm)。 支持大多數(shù)估算模型的經(jīng)驗(yàn)數(shù)據(jù)，都是從有限個(gè)項(xiàng)目的樣本集中總結(jié)出來(lái)的，因此，沒(méi)有一個(gè)估算模型可以適用于所有類型的軟件和開(kāi)發(fā)環(huán)境。 第14頁(yè)/共96頁(yè)13.2.1 靜態(tài)單變量模型 總體結(jié)構(gòu)形式如下： E = A + B (ev) C 其中，A、B和C是由經(jīng)驗(yàn)數(shù)據(jù)導(dǎo)出的常數(shù)， E是以人月為單位的工作量， ev是估算變量（KLOC或FP）。第15頁(yè)/共96頁(yè)1. 面向KLOC的估算模型 (1) Walston_Felix模型 E=5.2(KLOC)0.91 (2) Bailey_Basili模型 E=5.5+0.73(KL

8、OC)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 第16頁(yè)/共96頁(yè)13.2.2 動(dòng)態(tài)多變量模型 動(dòng)態(tài)多變量模型也稱為軟件方程式，該模型把工作量看作是軟件規(guī)模和開(kāi)發(fā)時(shí)間這兩個(gè)變量的函數(shù)。 動(dòng)態(tài)多變量估算模型的形式如下： E=(LOCB0.333/P)3(1/t)4 其中， E

9、是以人月或人年為單位的工作量； t 是以月或年為單位的項(xiàng)目持續(xù)時(shí)間； B 是特殊技術(shù)因子，它隨著對(duì)測(cè)試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加，對(duì)于較小的程序（KLOC=515），B=0.16,對(duì)于超過(guò)70 KLOC的程序，B=0.39； 第17頁(yè)/共96頁(yè) P是生產(chǎn)率參數(shù)，它反映了下述因素對(duì)工作量的影響： 總體過(guò)程成熟度及管理水平； 使用良好的軟件工程實(shí)踐的程度； 使用的程序設(shè)計(jì)語(yǔ)言的級(jí)別； 軟件環(huán)境的狀態(tài)； 軟件項(xiàng)目組的技術(shù)及經(jīng)驗(yàn)； 應(yīng)用系統(tǒng)的復(fù)雜程度。 開(kāi)發(fā)實(shí)時(shí)嵌入式軟件時(shí)，P的典型值為2000；開(kāi)發(fā)電信系統(tǒng)和系統(tǒng)軟件時(shí)，P=10000；對(duì)于商業(yè)應(yīng)用系統(tǒng)來(lái)說(shuō)，P=28000?？梢?/p>

10、從歷史數(shù)據(jù)導(dǎo)出適用于當(dāng)前項(xiàng)目的生產(chǎn)率參數(shù)值。 第18頁(yè)/共96頁(yè)13.2.3 COCOMO2模型 COCOMO是構(gòu)造性成本模型（constructive cost model)的英文縮寫(xiě)。 1981年Boehm在軟件工程經(jīng)濟(jì)學(xué)中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來(lái)在成本估計(jì)方面所積累的經(jīng)驗(yàn)。 第19頁(yè)/共96頁(yè) COCOMO2給出了3個(gè)層次的軟件開(kāi)發(fā)工作量估算模型，這3個(gè)層次的模型在估算工作量時(shí)，對(duì)軟件細(xì)節(jié)考慮的詳盡程度逐級(jí)增加。 3個(gè)層次的估算模型分別是： 應(yīng)用系統(tǒng)組成模型。這個(gè)模型主要用于估算構(gòu)建

11、原型的工作量，模型名字暗示在構(gòu)建原型時(shí)大量使用已有的構(gòu)件。 早期設(shè)計(jì)模型。這個(gè)模型適用于體系結(jié)構(gòu)設(shè)計(jì)階段。 后體系結(jié)構(gòu)模型。這個(gè)模型適用于完成體系結(jié)構(gòu)設(shè)計(jì)之后的軟件開(kāi)發(fā)階段。 第20頁(yè)/共96頁(yè) 該模型把軟件開(kāi)發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)： 其中， E是開(kāi)發(fā)工作量（以人月為單位）， a是模型系數(shù)， KLOC是估計(jì)的源代碼行數(shù)， b是模型指數(shù)， fi (i=117)是成本因素。 171iibfEKLOCa第21頁(yè)/共96頁(yè) 每個(gè)成本因素都根據(jù)它的重要程度和對(duì)工作量影響大小被賦予一定數(shù)值（稱為工作量系數(shù)）。表13.3列出了COCOMO2模型使用的成本因素及與之相聯(lián)系的工作量系數(shù)。

12、 與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化。 新增加了4個(gè)成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點(diǎn)開(kāi)發(fā)。 略去了原始模型中的2個(gè)成本因素（計(jì)算機(jī)切換時(shí)間和使用現(xiàn)代程序設(shè)計(jì)實(shí)踐）。 某些成本因素（分析員能力、平臺(tái)經(jīng)驗(yàn)、語(yǔ)言和工具經(jīng)驗(yàn)）對(duì)生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。 第22頁(yè)/共96頁(yè) 為了確定工作量方程中模型指數(shù)b的值，COCOMO2采用了更加精細(xì)得多的b分級(jí)模型，這個(gè)模型使用5個(gè)分級(jí)因素Wi(1i5),其中每個(gè)因素都劃分成從甚低（Wi=5)到特高（

13、Wi=0)的6個(gè)級(jí)別，然后用下式計(jì)算b的數(shù)值： 因此，b的取值范圍為1.011.26。顯然，這種分級(jí)模式比原始COCOMO模型的分級(jí)模式更精細(xì)、更靈活。 5101. 001. 1iiWb第23頁(yè)/共96頁(yè)COCOMO2使用的5個(gè)分級(jí)因素如下所述： 項(xiàng)目先例性。這個(gè)分級(jí)因素指出，對(duì)于開(kāi)發(fā)組織來(lái)說(shuō)該項(xiàng)目的新奇程度。 開(kāi)發(fā)靈活性。這個(gè)分級(jí)因素反映出，為了實(shí)現(xiàn)預(yù)先確定的外部接口需求及為了及早開(kāi)發(fā)出產(chǎn)品而需要增加的工作量。 風(fēng)險(xiǎn)排除度。這個(gè)分級(jí)因素反映了重大風(fēng)險(xiǎn)已被消除的比例。 項(xiàng)目組凝聚力。這個(gè)分級(jí)因素表明了開(kāi)發(fā)人員相互協(xié)作時(shí)可能存在的困難。 過(guò)程成熟度。這個(gè)分級(jí)因素反映了按照能力成熟度模型度量出的項(xiàng)

14、目組織的過(guò)程成熟度。 第24頁(yè)/共96頁(yè)13.3 進(jìn)度計(jì)劃 軟件項(xiàng)目的進(jìn)度安排通過(guò)把工作量分配給特定的軟件工程任務(wù)并規(guī)定完成各項(xiàng)任務(wù)的起止日期，從而將估算出的項(xiàng)目工作量分布于計(jì)劃好的項(xiàng)目持續(xù)期內(nèi)。 進(jìn)度計(jì)劃將隨著時(shí)間的流逝而不斷演化。第25頁(yè)/共96頁(yè)13.3.1 估算開(kāi)發(fā)時(shí)間 各種模型估算開(kāi)發(fā)時(shí)間的方程很相似，例如： Walston_Felix模型 T=2.5E0.35 原始的COCOMO模型 T=2.5E0.38 COCOMO2模型 T=3.0E0.33+0.2(b-1.01) Putnam模型 T=2.4E1/3 其中，E是開(kāi)發(fā)工作量（以人月為單位），T是開(kāi)發(fā)時(shí)間（以月為單位）。 第26

15、頁(yè)/共96頁(yè) 經(jīng)驗(yàn)告訴我們，隨著開(kāi)發(fā)小組規(guī)模擴(kuò)大，個(gè)人生產(chǎn)率將下降，以致開(kāi)發(fā)時(shí)間與從事開(kāi)發(fā)工作的人數(shù)并不成反比關(guān)系。出現(xiàn)這種現(xiàn)象主要有下述兩個(gè)原因： 當(dāng)小組變得更大時(shí)，每個(gè)人需要用更多時(shí)間與組內(nèi)其他成員討論問(wèn)題、協(xié)調(diào)工作，因此增加了通信開(kāi)銷(xiāo)。 如果在開(kāi)發(fā)過(guò)程中增加小組人員，則最初一段時(shí)間內(nèi)項(xiàng)目組總生產(chǎn)率不僅不會(huì)提高反而會(huì)下降。 Brooks規(guī)律：向一個(gè)已經(jīng)延期的項(xiàng)目增加人力，只會(huì)使得它更加延期。 存在一個(gè)最佳的項(xiàng)目組規(guī)模Popt，這個(gè)規(guī)模的項(xiàng)目組其總生產(chǎn)率最高。項(xiàng)目組的最佳規(guī)模是5.5人，即Popt=5.5。第27頁(yè)/共96頁(yè)13.3.2 Gantt圖 Gantt(甘特)圖是歷史悠久、應(yīng)用廣泛

16、的制定進(jìn)度計(jì)劃的工具。 例子：舊木板房刷漆工程(15名工人，工具各5把) 表13.5 各道工序估計(jì)需用的時(shí)間(小時(shí))工序墻壁刮舊漆刷新漆清理1或32312或4462第28頁(yè)/共96頁(yè)第29頁(yè)/共96頁(yè)Gantt圖的主要優(yōu)點(diǎn)： Gantt圖能很形象地描繪任務(wù)分解情況，以及每個(gè)子任務(wù)(作業(yè))的開(kāi)始和結(jié)束時(shí)間。 具有直觀簡(jiǎn)明和容易掌握、容易繪制的優(yōu)點(diǎn)。Gantt圖的3個(gè)主要缺點(diǎn)： 不能顯式地描繪各項(xiàng)作業(yè)彼此間的依賴關(guān)系； 進(jìn)度計(jì)劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻和主控的對(duì)象； 計(jì)劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費(fèi)。 第30頁(yè)/共96頁(yè)13.3.3 工程網(wǎng)絡(luò) 工程網(wǎng)絡(luò)是

17、制定進(jìn)度計(jì)劃時(shí)另一種常用的圖形工具，它同樣能描繪任務(wù)分解情況以及每項(xiàng)作業(yè)的開(kāi)始時(shí)間和結(jié)束時(shí)間。 它能顯式地描繪各個(gè)作業(yè)彼此間的依賴關(guān)系。 工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計(jì)的強(qiáng)有力的工具。第31頁(yè)/共96頁(yè)符號(hào)： ：表示作業(yè)，持續(xù)一定時(shí)間。 ：表示事件，作業(yè)的開(kāi)始或結(jié)束時(shí)刻。 ：虛擬作業(yè)，事實(shí)上并不存在的作業(yè)，表示依賴關(guān)系。 第32頁(yè)/共96頁(yè)舊木板房刷漆工程的工程網(wǎng)絡(luò)第33頁(yè)/共96頁(yè)13.3.4 估算工程進(jìn)度工程網(wǎng)絡(luò)必要的信息： 每個(gè)作業(yè)估計(jì)需要使用的時(shí)間：箭頭長(zhǎng)度和它代表的作業(yè)持續(xù)時(shí)間沒(méi)有關(guān)系，箭頭僅表示依賴關(guān)系，它上方的數(shù)字才表示作業(yè)的持續(xù)時(shí)間。 最早時(shí)刻EET：該事件可以發(fā)生的最早時(shí)間。

18、最遲時(shí)刻LET：在不影響竣工時(shí)間的前提下，該事件最晚可以發(fā)生的時(shí)刻。 機(jī)動(dòng)時(shí)間：實(shí)際開(kāi)始時(shí)間可以比預(yù)定時(shí)間晚一些，或者實(shí)際持續(xù)時(shí)間可以比預(yù)定的持續(xù)時(shí)間長(zhǎng)一些，而并不影響工程的結(jié)束時(shí)間。 第34頁(yè)/共96頁(yè)第35頁(yè)/共96頁(yè)最早時(shí)刻的計(jì)算： 事件的最早時(shí)刻是該事件可以發(fā)生的最早時(shí)間。 通常工程網(wǎng)絡(luò)中第一個(gè)事件的最早時(shí)刻定義為零，其他事件的最早時(shí)刻在工程網(wǎng)絡(luò)上從左至右按事件發(fā)生順序計(jì)算。 計(jì)算最早時(shí)刻EET使用下述3條簡(jiǎn)單規(guī)則： 考慮進(jìn)入該事件的所有作業(yè)； 對(duì)于每個(gè)作業(yè)都計(jì)算它的持續(xù)時(shí)間與起始事件的EET之和； 選取上述和數(shù)中的最大值作為該事件的最早時(shí)刻EET。 第36頁(yè)/共96頁(yè)最遲時(shí)刻的計(jì)算：

19、 事件的最遲時(shí)刻是在不影響工程竣工時(shí)間的前提下，該事件最晚可以發(fā)生的時(shí)刻。 按慣例，最后一個(gè)事件(工程結(jié)束)的最遲時(shí)刻就是它的最早時(shí)刻。其他事件的最遲時(shí)刻在工程網(wǎng)絡(luò)上從右至左按逆作業(yè)流的方向計(jì)算。 計(jì)算最遲時(shí)刻LET使用下述3條規(guī)則： 考慮離開(kāi)該事件的所有作業(yè)； 從每個(gè)作業(yè)的結(jié)束事件的最遲時(shí)刻中減去該作業(yè)的持續(xù)時(shí)間； 選取上述差數(shù)中的最小值作為該事件的最遲時(shí)刻LET。 第37頁(yè)/共96頁(yè)第38頁(yè)/共96頁(yè)13.3.5 機(jī)動(dòng)時(shí)間 某些作業(yè)有一定程度的機(jī)動(dòng)余地實(shí)際開(kāi)始時(shí)間可以比預(yù)定時(shí)間晚一些，或者實(shí)際持續(xù)時(shí)間可以比預(yù)定的持續(xù)時(shí)間長(zhǎng)一些，而并不影響工程的結(jié)束時(shí)間。 機(jī)動(dòng)時(shí)間=(LET)結(jié)束(EET)

20、開(kāi)始持續(xù)時(shí)間 =右下角左上角持續(xù)時(shí)間 在制定進(jìn)度計(jì)劃時(shí)仔細(xì)考慮和利用工程網(wǎng)絡(luò)中的機(jī)動(dòng)時(shí)間，往往能夠安排出既節(jié)省資源又不影響最終竣工時(shí)間的進(jìn)度表。 第39頁(yè)/共96頁(yè)第40頁(yè)/共96頁(yè)第41頁(yè)/共96頁(yè)13.3.6 關(guān)鍵路徑 最早時(shí)刻和最遲時(shí)刻相同的事件(機(jī)動(dòng)時(shí)間為0的作業(yè))定義了關(guān)鍵路徑，在圖中關(guān)鍵路徑用粗線箭頭表示。 關(guān)鍵路徑上的事件(關(guān)鍵事件)必須準(zhǔn)時(shí)發(fā)生，組成關(guān)鍵路徑的作業(yè)(關(guān)鍵作業(yè))的實(shí)際持續(xù)時(shí)間不能超過(guò)估計(jì)的持續(xù)時(shí)間，否則工程就不能準(zhǔn)時(shí)結(jié)束。第42頁(yè)/共96頁(yè)第43頁(yè)/共96頁(yè) 例題：假設(shè)一項(xiàng)工程分解成9個(gè)子任務(wù)，根據(jù)下表給出的信息，畫(huà)出工程網(wǎng)絡(luò)圖，計(jì)算每個(gè)事件的最早時(shí)刻和最遲時(shí)刻，

21、找出關(guān)鍵路徑。 子任務(wù)標(biāo)識(shí)子任務(wù)標(biāo)識(shí)完成任務(wù)時(shí)間完成任務(wù)時(shí)間依賴關(guān)系依賴關(guān)系a8b10c8a, bd9ae5bf3c, dg2dh4f, gi3e, f第44頁(yè)/共96頁(yè)第45頁(yè)/共96頁(yè)第46頁(yè)/共96頁(yè)第47頁(yè)/共96頁(yè)第48頁(yè)/共96頁(yè)第49頁(yè)/共96頁(yè)第50頁(yè)/共96頁(yè)第51頁(yè)/共96頁(yè)第52頁(yè)/共96頁(yè)第53頁(yè)/共96頁(yè)第54頁(yè)/共96頁(yè)第55頁(yè)/共96頁(yè)第56頁(yè)/共96頁(yè)第57頁(yè)/共96頁(yè)13.4 人員組織 為了成功地完成軟件開(kāi)發(fā)工作，項(xiàng)目組成員必須以一種有意義且有效的方式交互和通信。 管理者應(yīng)該合理地組織項(xiàng)目組，使項(xiàng)目組有較高生產(chǎn)率，能夠按預(yù)定的進(jìn)度計(jì)劃完成所承擔(dān)的工作。 除了追

22、求更好的組織方式之外，每個(gè)管理者的目標(biāo)都是建立有凝聚力的項(xiàng)目組。 一個(gè)有高度凝聚力的小組由一批團(tuán)結(jié)得非常緊密的人組成，他們的整體力量大于個(gè)體力量的總和。第58頁(yè)/共96頁(yè)13.4.1 民主制程序員組 民主制程序員組的一個(gè)重要特點(diǎn)是，小組成員完全平等，享有充分民主，通過(guò)協(xié)商做出技術(shù)決策。因此，小組成員之間的通信是平行的，如果小組內(nèi)有n個(gè)成員，則可能的通信信道共有n(n-1)/2條。 程序設(shè)計(jì)小組的人數(shù)不能太多，否則組員間彼此通信的時(shí)間將多于程序設(shè)計(jì)時(shí)間。 民主制程序員組通常采用非正式的組織方式，也就是說(shuō)，雖然名義上有一個(gè)組長(zhǎng)，但是他和組內(nèi)其他成員完成同樣的任務(wù)。第59頁(yè)/共96頁(yè)民主制程序員組的

23、優(yōu)點(diǎn)： 組員們對(duì)發(fā)現(xiàn)錯(cuò)誤抱著積極的態(tài)度，有助于更快地發(fā)現(xiàn)錯(cuò)誤，導(dǎo)致高質(zhì)量的代碼； 小組成員享有充分民主，有高度凝聚力，學(xué)術(shù)空氣濃厚，利于攻克技術(shù)難關(guān)； 若組內(nèi)多數(shù)成員經(jīng)驗(yàn)豐富，那么本組織方式會(huì)非常成功。民主制程序員組的缺點(diǎn)： 如果組內(nèi)多數(shù)成員技術(shù)水平不高，或是缺乏經(jīng)驗(yàn)的新手，由于沒(méi)有明確的權(quán)威指導(dǎo)開(kāi)發(fā)工程的進(jìn)行，組員間將缺乏必要的協(xié)調(diào)，最終可能導(dǎo)致工程失敗。 第60頁(yè)/共96頁(yè)13.4.2 主程序員組采用這種組織方式的原因： 軟件開(kāi)發(fā)人員多數(shù)比較缺乏經(jīng)驗(yàn)； 程序設(shè)計(jì)過(guò)程中有許多事務(wù)性的工作，例如，大量信息的存儲(chǔ)和更新； 多渠道通信很費(fèi)時(shí)間，將降低程序員的生產(chǎn)率。第61頁(yè)/共96頁(yè)主程序員組的兩

24、個(gè)重要特性： 專業(yè)化。該組每名成員僅完成他們受過(guò)專業(yè)訓(xùn)練的那些工作。 層次性。主程序員指揮成員工作并全面負(fù)責(zé)。 典型的主程序員組由主程序員、后備程序員、編程秘書(shū)以及13名程序員組成。 第62頁(yè)/共96頁(yè)主程序員組核心人員的分工： 主程序員既是成功的管理人員又是經(jīng)驗(yàn)豐富、技術(shù)好、能力強(qiáng)的高級(jí)程序員，負(fù)責(zé)體系結(jié)構(gòu)設(shè)計(jì)和關(guān)鍵部分的詳細(xì)設(shè)計(jì)，并且負(fù)責(zé)指導(dǎo)其他程序員完成詳細(xì)設(shè)計(jì)和編碼工作。 后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗(yàn)，他協(xié)助主程序員工作并且在必要時(shí)（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。 編程秘書(shū)負(fù)責(zé)完成與項(xiàng)目有關(guān)的全部事務(wù)性工作，例如，維護(hù)項(xiàng)目資料庫(kù)和項(xiàng)目文檔，編譯、鏈接、

25、執(zhí)行源程序和測(cè)試用例。 第63頁(yè)/共96頁(yè)主程序員組的組織方式不切實(shí)際： 首先，主程序員應(yīng)該是高級(jí)程序員和優(yōu)秀管理者的結(jié)合體。通常，既缺乏成功的管理者也缺乏技術(shù)熟練的程序員。 其次，后備程序員更難找。 第三，編程秘書(shū)也很難找到。第64頁(yè)/共96頁(yè)13.4.3 現(xiàn)代程序員組實(shí)際的“主程序員”應(yīng)該由兩個(gè)人共同擔(dān)任： 一個(gè)技術(shù)負(fù)責(zé)人，負(fù)責(zé)小組的技術(shù)活動(dòng)，參與全部代碼審查工作，因?yàn)樗獙?duì)代碼的各方面質(zhì)量負(fù)責(zé)； 一個(gè)行政負(fù)責(zé)人，負(fù)責(zé)所有非技術(shù)性事務(wù)的管理決策，不可以參與代碼審查工作，因?yàn)樗穆氊?zé)是對(duì)程序員的業(yè)績(jī)進(jìn)行評(píng)價(jià)。行政組長(zhǎng)應(yīng)該在常規(guī)調(diào)度會(huì)議上了解每名組員的技術(shù)能力和工作業(yè)績(jī)。 第65頁(yè)/共96頁(yè)第

26、66頁(yè)/共96頁(yè) 由于程序員組成員人數(shù)不宜過(guò)多，當(dāng)軟件項(xiàng)目規(guī)模較大時(shí)，應(yīng)該把程序員分成若干個(gè)小組。該圖描繪的是技術(shù)管理組織結(jié)構(gòu)，非技術(shù)管理組織結(jié)構(gòu)與此類似。第67頁(yè)/共96頁(yè) 把民主制程序員組和主程序員組的優(yōu)點(diǎn)結(jié)合起來(lái)的另一種方法，是在合適的地方采用分散做決定的方法。有利于形成暢通的通信渠道，以便充分發(fā)揮每個(gè)程序員的積極性和主動(dòng)性，集思廣益攻克技術(shù)難關(guān)。 第68頁(yè)/共96頁(yè)13.5 質(zhì)量保證13.5.1 軟件質(zhì)量 概括地說(shuō)，軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。 軟件質(zhì)量是軟件與明確地?cái)⑹龅墓δ芎托阅苄枨?、文檔中明確描述的開(kāi)發(fā)標(biāo)準(zhǔn)以及任何專業(yè)開(kāi)發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含

27、特征相一致的程度。 第69頁(yè)/共96頁(yè)定義強(qiáng)調(diào)了下述的3個(gè)要點(diǎn)： 軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)量不高。 指定的開(kāi)發(fā)標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開(kāi)發(fā)的準(zhǔn)則，如果沒(méi)有遵守這些準(zhǔn)則，幾乎肯定會(huì)導(dǎo)致軟件質(zhì)量不高。 通常，有一組沒(méi)有顯式描述的隱含需求。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是值得懷疑的。第70頁(yè)/共96頁(yè) 影響軟件質(zhì)量的主要因素，是從管理角度對(duì)軟件質(zhì)量的度量。可以把這些質(zhì)量因素分成3組，分別反映用戶在使用軟件產(chǎn)品時(shí)的3種不同傾向或觀點(diǎn)。這3種傾向是：產(chǎn)品運(yùn)行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。 第71頁(yè)/共96頁(yè)13.5.2 軟件質(zhì)量保證措施軟件質(zhì)量保證（s

28、oftware quality assurance,SQA）的措施主要有： 基于非執(zhí)行的測(cè)試（復(fù)審或評(píng)審），主要用來(lái)保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量； 基于執(zhí)行的測(cè)試（軟件測(cè)試），需要在程序編寫(xiě)出來(lái)之后進(jìn)行，它是保證軟件質(zhì)量的最后一道防線； 程序正確性證明，使用數(shù)學(xué)方法嚴(yán)格驗(yàn)證程序是否與對(duì)它的說(shuō)明完全一致。 第72頁(yè)/共96頁(yè)1. 技術(shù)復(fù)審的必要性 正式技術(shù)復(fù)審的顯著優(yōu)點(diǎn)是，能夠較早發(fā)現(xiàn)軟件錯(cuò)誤，從而可防止錯(cuò)誤被傳播到軟件過(guò)程的后續(xù)階段。 統(tǒng)計(jì)數(shù)字表明，在大型軟件產(chǎn)品中檢測(cè)出的錯(cuò)誤，60%70%屬于規(guī)格說(shuō)明錯(cuò)誤或設(shè)計(jì)錯(cuò)誤，而正式技術(shù)復(fù)審在發(fā)現(xiàn)規(guī)格說(shuō)明錯(cuò)誤和設(shè)計(jì)錯(cuò)誤方面的有效性高達(dá)75%。由

29、于能夠檢測(cè)出并排除掉絕大部分這類錯(cuò)誤，復(fù)審可大大降低后續(xù)開(kāi)發(fā)和維護(hù)階段的成本。 正式技術(shù)復(fù)審是軟件質(zhì)量保證措施的一種，包括走查（walkthrough)和審查（inspection）等具體方法。走查的步驟比審查少，而且沒(méi)有審查正規(guī)。 第73頁(yè)/共96頁(yè)2. 走查 走查組由46名成員組成。走查組組長(zhǎng)引導(dǎo)該組成員走查文檔，力求發(fā)現(xiàn)盡可能多的錯(cuò)誤。 走查組的任務(wù)僅僅是標(biāo)記出錯(cuò)誤而不是改正錯(cuò)誤，改正錯(cuò)誤的工作應(yīng)該由該文檔的編寫(xiě)組完成。 走查的時(shí)間最長(zhǎng)不要超過(guò)2小時(shí)，這段時(shí)間應(yīng)該用來(lái)發(fā)現(xiàn)和標(biāo)記錯(cuò)誤，而不是改正錯(cuò)誤。 走查主要有下述兩種方式： 參與者驅(qū)動(dòng)法 文檔驅(qū)動(dòng)法第74頁(yè)/共96頁(yè)3. 審查 綜述。由

30、負(fù)責(zé)編寫(xiě)文檔的一名成員向?qū)彶榻M綜述該文檔。 準(zhǔn)備。評(píng)審員仔細(xì)閱讀文檔。 審查。評(píng)審組仔細(xì)走查整個(gè)文檔。 返工。文檔的作者負(fù)責(zé)解決在審查報(bào)告中列出的所有錯(cuò)誤及問(wèn)題。 跟蹤。組長(zhǎng)必須確保所提出的每個(gè)問(wèn)題都得到了圓滿的解決。 通常，審查組由4人組成。組長(zhǎng)既是審查組的管理人員又是技術(shù)負(fù)責(zé)人。審查過(guò)程不僅步數(shù)比走查多，而且每個(gè)步驟都是正規(guī)的。第75頁(yè)/共96頁(yè)4. 程序正確性證明 在20世紀(jì)60年代初期，人們已經(jīng)開(kāi)始研究程序正確性證明的技術(shù)，提出了許多不同的技術(shù)方法。 人工證明程序正確性，對(duì)于評(píng)價(jià)小程序可能有些價(jià)值，但是在證明大型軟件的正確性時(shí)，不僅工作量太大，更主要的是在證明的過(guò)程中很容易包含錯(cuò)誤，因

31、此是不實(shí)用的。為了實(shí)用的目的，必須研究能證明程序正確性的自動(dòng)系統(tǒng)。 目前已經(jīng)研究出證明PASCAL和LISP程序正確性的程序系統(tǒng)，正在對(duì)這些系統(tǒng)進(jìn)行評(píng)價(jià)和改進(jìn)。現(xiàn)在這些系統(tǒng)還只能對(duì)較小的程序進(jìn)行評(píng)價(jià)。 第76頁(yè)/共96頁(yè)13.6 軟件配置管理 軟件配置管理是在軟件的整個(gè)生命期內(nèi)管理變化的一組活動(dòng)。 具體地說(shuō)，這組活動(dòng)用來(lái)：標(biāo)識(shí)變化；控制變化；確保適當(dāng)?shù)貙?shí)現(xiàn)了變化；向需要知道這類信息的人報(bào)告變化。 軟件配置管理的目標(biāo)是，使變化更正確且更容易被適應(yīng)，在必須變化時(shí)減少所需花費(fèi)的工作量。 第77頁(yè)/共96頁(yè)13.6.1 軟件配置1. 軟件配置項(xiàng) 軟件過(guò)程的輸出信息可以分為3類： 計(jì)算機(jī)程序（源代碼和可

32、執(zhí)行程序）； 描述計(jì)算機(jī)程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。 上述這些項(xiàng)組成了在軟件過(guò)程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項(xiàng)就是軟件配置項(xiàng)。第78頁(yè)/共96頁(yè)2. 基線 基線是一個(gè)軟件配置管理概念，有助于我們?cè)诓粐?yán)重妨礙合理變化的前提下控制變化。 IEEE把基線定義為：已經(jīng)通過(guò)了正式復(fù)審的規(guī)格說(shuō)明或中間產(chǎn)品，它可以作為進(jìn)一步開(kāi)發(fā)的基礎(chǔ)，并且只有通過(guò)正式的變化控制過(guò)程才能改變它。 簡(jiǎn)而言之，基線就是通過(guò)了正式復(fù)審的軟件配置項(xiàng)。第79頁(yè)/共96頁(yè)13.6.2 軟件配置管理過(guò)程 具體來(lái)說(shuō)，軟件配置管理主要有5項(xiàng)任務(wù)：標(biāo)識(shí)、版本控制、變化控制、配置審

33、計(jì)和報(bào)告。1. 標(biāo)識(shí)軟件配置中的對(duì)象 為了控制和管理軟件配置項(xiàng)，必須單獨(dú)命名每個(gè)配置項(xiàng)，然后用面向?qū)ο蠓椒ńM織它們?？梢詷?biāo)識(shí)出兩類對(duì)象： 基本對(duì)象，是軟件工程師在分析、設(shè)計(jì)、編碼或測(cè)試過(guò)程中創(chuàng)建出來(lái)的“文本單元”。 聚集對(duì)象，是基本對(duì)象和其他聚集對(duì)象的集合。第80頁(yè)/共96頁(yè)2. 版本控制 版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過(guò)程中所創(chuàng)建的配置對(duì)象的不同版本。 借助于版本控制技術(shù)，用戶能夠通過(guò)選擇適當(dāng)?shù)陌姹緛?lái)指定軟件系統(tǒng)的配置。3. 變化控制 典型的變化控制過(guò)程如下： 首先評(píng)估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作用、對(duì)其他配置對(duì)象和系統(tǒng)功能的整體影響以及估算出的修改成本。 為每個(gè)被批

34、準(zhǔn)的變化都生成一個(gè)“工程變化命令” 。把要修改的對(duì)象從項(xiàng)目數(shù)據(jù)庫(kù)中“提取”出來(lái)，進(jìn)行修改并應(yīng)用適當(dāng)?shù)腟QA活動(dòng)。 最后，把修改后的對(duì)象“提交”進(jìn)數(shù)據(jù)庫(kù)，并用適當(dāng)?shù)陌姹究刂茩C(jī)制創(chuàng)建該軟件的下一個(gè)版本。第81頁(yè)/共96頁(yè)4. 配置審計(jì) 通常從下述兩方面采取措施： 正式的技術(shù)復(fù)審，關(guān)注被修改后的配置對(duì)象的技術(shù)正確性。 軟件配置審計(jì)，通過(guò)評(píng)估配置對(duì)象那些通常不在復(fù)審過(guò)程中考慮的特征，是對(duì)正式技術(shù)復(fù)審的補(bǔ)充。5. 狀態(tài)報(bào)告 書(shū)寫(xiě)配置狀態(tài)報(bào)告回答下述問(wèn)題： 發(fā)生了什么事？ 誰(shuí)做的這件事？ 這件事是什么時(shí)候發(fā)生的？ 它將影響哪些其他事物？第82頁(yè)/共96頁(yè)13.7 能力成熟度模型 美國(guó)卡內(nèi)基梅隆大學(xué)軟件工程

35、研究所在美國(guó)國(guó)防部資助下于20世紀(jì)80年代末建立的能力成熟度模型（capability maturity model，CMM)，是用于評(píng)價(jià)軟件機(jī)構(gòu)的軟件過(guò)程能力成熟度的模型。 CMM的定義：CMM是對(duì)于軟件組織在定義、實(shí)施、度量、控制和改善其軟件過(guò)程的實(shí)踐中各個(gè)發(fā)展階段的描述。第83頁(yè)/共96頁(yè)多種基于CMM的模型，構(gòu)成了一個(gè)CMM族： SW-CMM ：針對(duì)軟件過(guò)程的成熟度模型 。 P-CMM：人員能力成熟度模型。 SA-CMM：軟件獲取成熟度模型。 IPD-CMM：集成系統(tǒng)產(chǎn)品開(kāi)發(fā)能力成熟度模型。 SE-CMM：系統(tǒng)工程能力成熟度模型。 SSE-CMM：系統(tǒng)安全工程能力成熟度模型。 第84頁(yè)

36、/共96頁(yè) 能力成熟度模型的基本思想是，由于問(wèn)題是由我們管理軟件過(guò)程的方法不當(dāng)引起的，所以新軟件技術(shù)的運(yùn)用并不會(huì)自動(dòng)提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開(kāi)發(fā)機(jī)構(gòu)建立一個(gè)有規(guī)律的、成熟的軟件過(guò)程。 對(duì)軟件過(guò)程的改進(jìn)，是在完成一個(gè)又一個(gè)小的改進(jìn)步驟基礎(chǔ)上不斷進(jìn)行的漸進(jìn)過(guò)程，而不是一蹴而就的徹底革命。CMM把軟件過(guò)程從無(wú)序到有序的進(jìn)化過(guò)程分成5個(gè)階段，并把這些階段排序，形成5個(gè)逐層提高的等級(jí)。 第85頁(yè)/共96頁(yè)CMM包括以下組成部分： 成熟度等級(jí)(Maturity Levels) ； 過(guò)程能力(Process Capability)； 關(guān)鍵過(guò)程域(Key Process Areas,

37、KPA)； 目標(biāo)(Goals)； 公共特性(Common Features)； 關(guān)鍵實(shí)踐(Key Practices)。 第86頁(yè)/共96頁(yè)第87頁(yè)/共96頁(yè)CMM的用途： 軟件過(guò)程評(píng)估，借助CMM分析軟件組織當(dāng)前軟件過(guò)程的狀態(tài)，明確其強(qiáng)項(xiàng)和弱項(xiàng) 軟件過(guò)程改進(jìn)，軟件開(kāi)發(fā)組織用它來(lái)改進(jìn)開(kāi)發(fā)和維護(hù)軟件的過(guò)程，根據(jù)評(píng)估結(jié)果，從低級(jí)逐極向更高級(jí)發(fā)展，制定軟件過(guò)程改進(jìn)的策略。 軟件能力評(píng)價(jià)，政府或商業(yè)企業(yè)用它來(lái)評(píng)價(jià)與一個(gè)特定的軟件公司簽訂軟件項(xiàng)目合同的風(fēng)險(xiǎn)。 第88頁(yè)/共96頁(yè)1. 初始級(jí) 軟件過(guò)程的特征是無(wú)序的，有時(shí)甚至是混亂的。幾乎沒(méi)有什么過(guò)程是經(jīng)過(guò)定義的（即沒(méi)有一個(gè)定型的過(guò)程模型），項(xiàng)目能否成功完

38、全取決于開(kāi)發(fā)人員的個(gè)人能力。 處于這個(gè)最低成熟度等級(jí)的軟件機(jī)構(gòu)，基本上沒(méi)有健全的軟件工程管理制度，其軟件過(guò)程完全取決于項(xiàng)目組的人員配備，所以具有不可預(yù)測(cè)性，人員變了過(guò)程也隨之改變。第89頁(yè)/共96頁(yè)2. 可重復(fù)級(jí) 軟件機(jī)構(gòu)建立了基本的項(xiàng)目管理過(guò)程(過(guò)程模型)，可跟蹤成本、進(jìn)度、功能和質(zhì)量。已經(jīng)建立起必要的過(guò)程規(guī)范，對(duì)新項(xiàng)目的策劃和管理過(guò)程是基于以前類似項(xiàng)目的實(shí)踐經(jīng)驗(yàn)，使得有類似應(yīng)用經(jīng)驗(yàn)的軟件項(xiàng)目能夠再次取得成功。 處于2級(jí)成熟度的軟件機(jī)構(gòu)的過(guò)程能力可以概括為，軟件項(xiàng)目的策劃和跟蹤是穩(wěn)定的，已經(jīng)為一個(gè)有紀(jì)律的管理過(guò)程提供了可重復(fù)以前成功實(shí)踐的項(xiàng)目環(huán)境。軟件項(xiàng)目工程活動(dòng)處于項(xiàng)目管理體系的有效控制之下，執(zhí)行著基于以前項(xiàng)目的準(zhǔn)則且合乎現(xiàn)實(shí)的計(jì)劃。 第90頁(yè)/共96頁(yè)3. 已定義級(jí) 軟件機(jī)構(gòu)已經(jīng)定義了完整的軟件過(guò)程（過(guò)程模型），軟件過(guò)程已經(jīng)文檔化和標(biāo)