軟件項目管理課件

1、第13章 軟件項目管理 所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。 第1頁，共150頁。項目管理過程軟件項目管理的對象是軟件工程項目。它所涉及的范圍覆蓋了整個軟件工程過程。為使軟件項目開發(fā)獲得成功，關鍵問題是必須對軟件項目的工作范圍、可能風險、需要資源(人、硬件軟件)、要實現(xiàn)的任務、經(jīng)歷的里程碑、花費工作量(成本)、進度安排等做到心中有數(shù)。第2頁，共150頁。 估算軟件規(guī)模13.1工作量估算13.2進度計劃13.3人員組織13.4第3頁，共150頁。 軟件配置管理13.6能力成熟度模型13.7小 結13.8質量保證13.5第4頁，共150頁。

2、13.1 度量軟件規(guī)模 13.1.1 代碼行技術 代碼行技術是比較簡單的定量估算軟件規(guī)模的方法。這種方法根據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)，估計實現(xiàn)一個功能需要的源程序行數(shù)。第5頁，共150頁。由多名有經(jīng)驗的軟件工程師分別作出估計。每個人都估計程序的最小規(guī)模(a)、最大規(guī)模(b)和最可能的規(guī)模(m)，分別算出這三種規(guī)模的平均值a，b，和m之后，再用下式計算程序規(guī)模的估計值： 第6頁，共150頁。 13.1.2 功能點技術 功能點技術依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模。這種方法用功能點(FP)為單位，度量軟件的規(guī)模。 第7頁，共150頁。 1. 信息域特性 功能點技術定義

3、了信息域的5個特性，分別是輸入項數(shù)(Inp)、輸出項數(shù)(Out)、查詢數(shù)(Inq)，主文件數(shù)(Maf)和外部接口數(shù)(Inf)。第8頁，共150頁。 2. 估算功能點的步驟 用下述三個步驟，可以估算出一個軟件的功能點數(shù)(即軟件規(guī)模)。 第9頁，共150頁。 (1) 計算未調整的功能點數(shù)UFP 首先，把產(chǎn)品信息域的每個特性(即Inp、Out、Inq、Maf和Inf)都分類成簡單級、平均級或復雜級。第10頁，共150頁。 根據(jù)其等級，為每個特性都分配一個功能點數(shù)，例如，一個平均級的輸入項分配4個功能點，一個簡單級的輸入項是3個功能點，而一個復雜級的輸入項分配6個功能點。 第11頁，共150頁。 然后

4、，用下式計算未調整的功能點數(shù)UFPUFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系數(shù)，其值由相應特性的復雜級別決定，如表13.1所示。第12頁，共150頁。 (2) 計算技術復雜性因子TCF 這一步將度量14種技術因素對軟件規(guī)模的影響程度。這些因素包括高處理率、性能標準(例如，響應時間)、聯(lián)機更新等，在表13.2中列出了全部技術因素，并用Fi(1i14)代表這些因素。 第13頁，共150頁。第14頁，共150頁。 根據(jù)軟件特點，為每個因素分配一個從0(不存在或對軟件規(guī)模無影響)到5(有很大影響)的值。然后，用下式計算技術因素對軟件規(guī)模的綜合影

5、響程度DI：第15頁，共150頁。 技術復雜性因子TCF由下式計算：TCF=0.65+0.01DI 因為DI的值在070之間，所以TCF的值在0.651.35之間。第16頁，共150頁。 (3) 計算功能點數(shù)FP 功能點數(shù)FP由下式計算： FP=UFPTCF 功能點數(shù)與所用的編程語言無關，因此，功能點技術比代碼行技術更合理一些。第17頁，共150頁。13.2 工作量估算 計算機軟件估算模型使用由經(jīng)驗導出的公式來預測軟件開發(fā)的工作量，工作量是軟件規(guī)模(LOC或FP)的函數(shù)，工作量的單位通常是人月(pm)。 第18頁，共150頁。 支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結出來的

6、，因此，沒有一個估算模型能夠適用于所有類型的軟件和開發(fā)環(huán)境。第19頁，共150頁。 13.2.1 靜態(tài)單變量模型 這類模型的總體結構形式如下： E=A+B(ev) C 第20頁，共150頁。大多數(shù)模型都有某種形式的調整成分，使得E能夠依據(jù)項目的其他特性(例如，問題的復雜程度、開發(fā)人員的經(jīng)驗、開發(fā)環(huán)境等)加以調整。下面給出幾個典型的靜態(tài)單變量模型。第21頁，共150頁。 1. 面向LOC的估算模型 (1) WalstonFelix模型 E=5.2(KLOC)0.91 (2) BaileyBasili模型 E=5.5+0.73(KLOC)1.16第22頁，共150頁。 (3) Boehm簡單模型

7、E=3.2(KLOC)1.05 (4) Doty模型(在KLOC9的情況下) E=5.288(KLOC)1.407第23頁，共150頁。 2.面向FP的估算模型(1) Albrecht & Gaffney模型E=-13.39+0.0545FP(2) Kemerer模型 E=60.627.72813-8FP3(3) Maston、Barnett和Mellichamp模型 E=585.7+5.12FP第24頁，共150頁。 13.2.2 動態(tài)多變量模型 動態(tài)多變量模型也稱為軟件方程式，它是根據(jù)從4000多個當代軟件項目中收集的生產(chǎn)率數(shù)據(jù)推導出來的。第25頁，共150頁。 這種模型把工作量看作是軟件

8、規(guī)模和開發(fā)時間這兩個變量的函數(shù)。動態(tài)多變量估算模型的形式如下： E=LOCB0.333/P3(1/t) 4第26頁，共150頁。 總體的過程成熟度及管理水平； 使用良好的軟件工程實踐的程度； 使用的程序設計語言的級別； 軟件環(huán)境的狀態(tài)； 軟件項目組的技術及經(jīng)驗； 應用系統(tǒng)的復雜程度。第27頁，共150頁。當開發(fā)實時嵌入式軟件時，典型值是P=2000；對于電信和系統(tǒng)軟件來說，P=13000；對于商業(yè)系統(tǒng)應用，P=28000。適用于當前項目的生產(chǎn)率參數(shù)，可以從歷史數(shù)據(jù)導出。 第28頁，共150頁。 從(13.2)式可以看出，開發(fā)同一個軟件(即LOC固定)的時候，如果把項目持續(xù)時間延長一些，則可降低

9、完成項目所需要的工作量。第29頁，共150頁。13.2.3 COCOMO2模型 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經(jīng)驗。第30頁，共150頁。 下面以后體系結構模型為例，介紹COCOMO2模型。該模型把軟件開發(fā)工作量表示成代碼行數(shù)（KLOC）的非線性函數(shù)：i=1第31頁，共150頁。 每個成本因素都根據(jù)它的重要程度和對工作量影響大小被賦予一定數(shù)值（稱為工作量系數(shù)）。第32頁，共150頁。（1） 新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續(xù)性（即人員穩(wěn)定程度）和多地點開發(fā)。這個變化表

10、明，這些因素對開發(fā)成本的影響日益增加。第33頁，共150頁。（2） 略去了原始模型中的2個成本因素（計算機切換時間和使用現(xiàn)代程序設計實踐）?，F(xiàn)在，開發(fā)人員普遍使用工作站開發(fā)軟件，批處理的切換時間已經(jīng)不再是問題。第34頁，共150頁。 而“現(xiàn)代程序設計實踐”已經(jīng)發(fā)展成內容更廣泛的“成熟的軟件工程實踐”的概念，并且在COCOMO2工作量方程的指數(shù)b中考慮了這個因素的影響。第35頁，共150頁。（3） 某些成本因素（分析員能力、平臺經(jīng)驗、語言和工具經(jīng)驗）對生產(chǎn)率的影響（即工作量系數(shù)最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。第36頁，共150頁。 COCOMO2采用了更加

11、精細得多的b分級模型，這個模型使用5個分級因素Wi(1i5），其中每個因素都劃分成從甚低（Wi=5）到特高（Wi=0)的6個級別，然后用下式計算b的數(shù)值：b=1.01+0.01Wi第37頁，共150頁。 COCOMO2使用的5個分級因素如下所述：（1） 項目先例性。（2） 開發(fā)靈活性。（3） 風險排除度。（4） 項目組凝聚力。（5） 過程成熟度。第38頁，共150頁。13.3 進度計劃 項目管理者的目標是定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發(fā)現(xiàn)拖延進度的情況。 第39頁，共150頁。 軟件計劃最詳盡地描述了軟件過程，它包括采用的生命周期模型、開發(fā)組織的組織結構

12、、責任分配、管理目標和優(yōu)先級、所用的技術和CASE工具，以及詳細的進度、預算和資源分配。整個計劃的基礎是工作量估算和完成期限估算。第40頁，共150頁。 軟件項目的進度安排是一項活動，它通過把工作量分配給特定的軟件工程任務，并規(guī)定完成各項任務的起、止日期，從而將估算的工作量分布于計劃好的項目持續(xù)期內。第41頁，共150頁。13.3.1 估算開發(fā)時間設一個人單獨開發(fā)軟件，生產(chǎn)率是5000行人年。若 4 個人組成一個小組共同開發(fā)這個軟件，則需要 6條通信路徑。若在每條通信路徑上耗費的工作量是 250 行人年。則小組中每個人的軟件生產(chǎn)率降低為 500062504 = 5000375 = 4625 行

13、人年。第42頁，共150頁。從上述分析可知，一個軟件任務由一個人單獨開發(fā)，生產(chǎn)率最高；而對于一個稍大型的軟件項目，一個人單獨開發(fā)，時間太長。因此軟件開發(fā)小組是必要的。但是，開發(fā)小組不宜太大，成員之間避免太多的通信路徑。在開發(fā)進程中，切忌中途加人，避免太多的生產(chǎn)率損失。第43頁，共150頁。 13.3.2 Gantt圖 Gantt圖(甘特圖)是歷史悠久、應用廣泛的進度計劃工具，下面通過一個非常簡單的例子介紹這種工具。第44頁，共150頁。圖13.1 舊木板房刷漆工程的Gantt圖 第45頁，共150頁。 為了醒目地表示里程碑，可以在Gantt圖中加上菱形標記，一個菱形代表一個里程碑，如圖13.2

14、所示。第46頁，共150頁。圖13.2 標有里程碑的Gantt圖第47頁，共150頁。 13.3.3 工程網(wǎng)絡 上一小節(jié)介紹的Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業(yè))的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是Gantt圖也有三個主要缺點： 第48頁，共150頁。 不能顯式地描繪各項作業(yè)彼此間的依賴關系； 進度計劃的關鍵部分不明確，難于判定哪些部分應當是主攻和主控的對象； 計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。第49頁，共150頁。 當把一個工程項目分解成許多子任務，并且它們彼此間的依賴關系又

15、比較復雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難于做出既節(jié)省資源又保證進度的計劃，而且還容易發(fā)生差錯。 第50頁，共150頁。 工程網(wǎng)絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業(yè)的開始時間和結束時間，此外，它還顯式地描繪各個作業(yè)彼此間的依賴關系。第51頁，共150頁。 因此，工程網(wǎng)絡是系統(tǒng)分析和系統(tǒng)設計的強有力的工具。第52頁，共150頁。圖13.3 舊木板房刷漆工程的工程網(wǎng)絡圖中：12刮第1面墻上的舊漆；23刮第2面墻上的舊漆；24給第1面墻刷新漆；35刮第3面墻上舊漆；46給第2面墻刷新漆；47清理第1面墻窗戶；58刮第4面墻上舊漆；68給第

16、3面墻刷新漆；79清理第2面墻窗戶；813給第4面墻刷新漆；913清理第3面墻窗戶；1311清理第4面墻窗戶；虛擬作業(yè)：34；56；67；89。第53頁，共150頁。 在工程網(wǎng)絡中的一個事件，如果既有箭頭進入又有箭頭離開，則它既是某些作業(yè)的結束又是另一些作業(yè)的開始。第54頁，共150頁。 例如，圖13.3中事件2既是作業(yè)12(刮第1面墻上的舊漆)的結束，又是作業(yè)23(刮第2面墻上舊漆)和作業(yè)24(給第1面墻刷新漆)的開始。第55頁，共150頁。 也就是說，只有第1面墻上的舊漆刮完之后，才能開始刮第2面墻上舊漆和給第1面墻刷新漆這兩個作業(yè)。因此，工程網(wǎng)絡顯式地表示了作業(yè)之間的依賴關系。第56頁，

17、共150頁。 在圖13.3中還有一些虛線箭頭，它們表示虛擬作業(yè)，也就是事實上并不存在的作業(yè)。引入虛擬作業(yè)是為了顯式地表示作業(yè)之間的依賴關系。例如，事件4既是給第1面墻刷新漆結束，又是給第2面墻刷新漆開始(作業(yè)46)。第57頁，共150頁。 但是，在開始給第2面墻刷新漆之前，不僅必須已經(jīng)給第1面墻刷完了新漆，而且第2面墻上的舊漆也必須已經(jīng)刮凈(事件3)。第58頁，共150頁。 也就是說，在事件3和事件4之間有依賴關系，或者說在作業(yè)23(刮第2面墻上舊漆)和作業(yè)46(給第2面墻刷新漆)之間有依賴關系，虛擬作業(yè)34明確地表示了這種依賴關系。注意，虛擬作業(yè)既不消耗資源也不需要時間。第59頁，共150頁

18、。 13.3.4 估算工程進度 畫出類似圖13.3那樣的工程網(wǎng)絡之后，系統(tǒng)分析員就可以借助它的幫助估算工程進度了。為此需要在工程網(wǎng)絡上增加一些必要的信息。 第60頁，共150頁。 首先，把每個作業(yè)估計需要使用的時間寫在表示該項作業(yè)的箭頭上方。注意，箭頭長度和它代表的作業(yè)持續(xù)時間沒有關系，箭頭僅表示依賴關系，它上方的數(shù)字才表示作業(yè)的持續(xù)時間。 第61頁，共150頁。 其次，為每個事件計算下述兩個統(tǒng)計數(shù)字：最早時刻EET和最遲時刻LET。這兩個數(shù)字將分別寫在表示事件的圓圈的右上角和右下角，如圖13.4左下角的符號所示。第62頁，共150頁。圖13.4 舊木板房刷漆工程的完整的工程網(wǎng)絡(粗線箭頭是關

19、鍵路徑)第63頁，共150頁。 事件的最早時刻是該事件可以發(fā)生的最早時間。通常工程網(wǎng)絡中第一個事件的最早時刻定義為零，其他事件的最早時刻在工程網(wǎng)絡上從左至右按事件發(fā)生順序計算。第64頁，共150頁。 計算最早時刻EET使用下述三條簡單規(guī)則： 考慮進入該事件的所有作業(yè)； 對于每個作業(yè)都計算它的持續(xù)時間與起始事件的EET之和； 選取上述和數(shù)中的最大值作為該事件的最早時刻EET。第65頁，共150頁。 事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。按慣例，最后一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網(wǎng)絡上從右至左按逆作業(yè)流的方向計算。第66頁

20、，共150頁。 計算最遲時刻LET使用下述三條規(guī)則： 考慮離開該事件的所有作業(yè)； 從每個作業(yè)的結束事件的最遲時刻中減去該作業(yè)的持續(xù)時間； 選取上述差數(shù)中的最小值做為該事件的最遲時刻LET。第67頁，共150頁。 13.3.5 關鍵路徑 圖13.4中有幾個事件的最早時刻和最遲時刻相同，這些事件定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。第68頁，共150頁。 關鍵路徑上的事件(關鍵事件)必須準時發(fā)生，組成關鍵路徑的作業(yè)(關鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準時結束。第69頁，共150頁。 13.3.6 機動時間 不在關鍵路徑上的作業(yè)有一定程度的機動余地實際開始時間可以

21、比預定時間晚一些，或者實際持續(xù)時間可以比預計的持續(xù)時間長一些，而并不影響工程的結束時間。第70頁，共150頁。 一個作業(yè)可以有的全部機動時間等于它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業(yè)的持續(xù)時間：機動時間=(LET)結束-(EET)開始-持續(xù)時間 第71頁，共150頁。 對于前述油漆舊木板房的例子，計算得到的非關鍵作業(yè)的機動時間列在表13.6中。第72頁，共150頁。第73頁，共150頁。 在工程網(wǎng)絡中每個作業(yè)的機動時間寫在代表該項作業(yè)的箭頭下面的括弧里(參看圖13.4)。 在制定進度計劃時仔細考慮和利用工程網(wǎng)絡中的機動時間，往往能夠安排出既節(jié)省資源又不影響最終竣工時間

22、的進度表。第74頁，共150頁。圖13.5 舊木板房刷漆工程改進的Gantt圖之一第75頁，共150頁。13.4 人員組織 13.4.1 民主制程序員組 有兩種極端方法可用來組織程序員組，這兩種組織方法分別稱為民主制程序員組和主程序員組。構成民主制程序員組的基本概念是“無私編程”。第76頁，共150頁。 必須改變評價程序員價值的標準，每名程序員都應該鼓勵該組其他成員找出自己編寫的代碼中的錯誤。不要認為存在錯誤是壞事，而應該認為是正常的事情，應該把找出模塊中的一個錯誤看作是取得了一個勝利。第77頁，共150頁。 任何人都不能嘲笑程序員所犯的編碼錯誤。程序員組作為一個整體，將培養(yǎng)一種平等的團隊精神

23、，堅信“每個模塊都是屬于整個程序員組的，而不是屬于某個人的”。一組無私的程序員將構成一個民主制程序員組。第78頁，共150頁。 民主制程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協(xié)商做出技術決策。因此，小組成員間的通信是平行的，如果一個小組有n個成員，則可能的通信信道有n(n-1)/2條。 第79頁，共150頁。 一般說來，程序設計小組的規(guī)模應該比較小，以28名成員為宜。如果項目規(guī)模很大，用一個小組不能在預定時間內完成開發(fā)任務，則應該使用多個程序設計小組，每個小組承擔工程項目的一部分任務，在一定程度上獨立自主地完成各自的任務。第80頁，共150頁。 系統(tǒng)的總體設計應該能夠保證

24、由各個小組負責開發(fā)的各部分之間的接口是良好定義的，并且是盡可能簡單的。第81頁，共150頁。 小組規(guī)模小，不僅可以減少通信問題，而且還有其他好處。例如，容易確定小組的質量標準，而且用民主方式確定的標準更容易被大家遵守；組員間關系密切，能夠互相學習等。 第82頁，共150頁。 民主制程序員組通常采用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。在這樣的小組中，由全體討論決定應該完成的工作，并且根據(jù)每個人的能力和經(jīng)驗分配適當?shù)娜蝿铡?第83頁，共150頁。 為了使少數(shù)經(jīng)驗豐富、技術高超的程序員在軟件開發(fā)過程中能夠發(fā)揮更大作用，程序設計小組也可以采用下一小節(jié)中

25、介紹的另外一種組織形式。第84頁，共150頁。13.4.2 主程序員組 美國IBM公司在20世紀70年代初期開始采用主程序員組的組織方式。采用這種組織方式主要出于下述幾點考慮： 第85頁，共150頁。 軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗； 程序設計過程中有許多事務性的工作，例如，大量信息的存儲和更新； 多渠道通信很費時間，將降低程序員的生產(chǎn)率。第86頁，共150頁。Baker描述的一個典型的主程序員組如圖13.5所示。第87頁，共150頁。13.4.3 現(xiàn)代程序員組 實際的“主程序員”應該由兩個人來擔任：一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術的管理決策。這樣的組織結構如圖

26、13.6所示。第88頁，共150頁。圖13.6 現(xiàn)代程序員組第89頁，共150頁。 由于程序員組的成員人數(shù)不宜過多，當軟件項目規(guī)模較大時，應該把程序員分成若干個小組，采用圖13.7所示的組織結構。第90頁，共150頁。圖13.7 大型項目的技術管理組織結構第91頁，共150頁。 把民主制程序員組和主程序員組的優(yōu)點結合起來的另一種方法，是在合適的地方采用分散做決定的方法，如圖13.8所示。第92頁，共150頁。圖13.8 包含分散決策的組織方式第93頁，共150頁。13.5 質量保證 質量是產(chǎn)品的生命，不論生產(chǎn)什么產(chǎn)品，質量都是極端重要的。軟件產(chǎn)品開發(fā)周期長，耗費巨大的人力和物力，更必須特別注意

27、保證質量。 第94頁，共150頁。 13.5.1 軟件質量 概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。第95頁，共150頁。 更具體地說，軟件質量是軟件符合明確地敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度。上述定義強調了下述的三個要點。第96頁，共150頁。 軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。 指定的標準定義了一組指導軟件開發(fā)的準則，如果沒有遵守這些準則，幾乎肯定會導致質量不高。第97頁，共150頁。 通常，有一組沒有顯式描述的隱含需求(例如，期望軟件是容易維護的)。如果軟件滿足明確描述的需求

28、，但卻不滿足隱含的需求，那么軟件的質量仍然是值得懷疑的。第98頁，共150頁。 下面介紹影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量?？梢园堰@些質量因素劃分成三組，它們分別反映用戶在使用軟件產(chǎn)品時的三種不同傾向或觀點。第99頁，共150頁。 這三種傾向是：產(chǎn)品運行，產(chǎn)品修改和產(chǎn)品轉移。圖13.9描繪了軟件質量因素和上述三種傾向(或稱為產(chǎn)品活動)之間的關系，表13.7給出了軟件質量因素的簡明定義。第100頁，共150頁。圖13.9 軟件質量因素與產(chǎn)品活動的關系第101頁，共150頁。第102頁，共150頁。第103頁，共150頁。 13.5.2 軟件質量保證措施 軟件質量保證(S

29、oftware Quality Assurance，通常縮寫為SQA)的措施主要有，基于非執(zhí)行的測試(也稱為復審)、基于執(zhí)行的測試(以前講述的軟件測試)。 第104頁，共150頁。 1. 技術復審的必要性 正式技術復審的明顯優(yōu)點是，能夠較早地發(fā)現(xiàn)錯誤，防止錯誤被傳播到軟件過程的后續(xù)階段。第105頁，共150頁。 正式技術復審實際上是一類復審方法，包括走查(Walkthrough)和審查(Inspection)等具體方法。走查的步驟比審查少，而且沒有審查那樣正規(guī)。第106頁，共150頁。 2. 走查 (1) 參與者驅動法 參與者按照事先準備好的列表，提出他們不理解的術語和認為不正確的術語。文檔編

30、寫組的代表必須對每個質疑做出回答，要么承認確實有錯誤，要么對質疑做出解釋。 第107頁，共150頁。 (2) 文檔驅動法 文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質疑。第108頁，共150頁。 3. 審查 審查的范圍要比走查廣泛得多，它的步驟也比較多。一般來說，審查有5個基本步驟。 第109頁，共150頁。 綜述：由負責編寫文檔的一名成員向審查組成員綜述該文檔。在綜述會議結束時把文檔分發(fā)給每位與會者。 第110頁，共150頁。 準備：評審員仔細閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作

31、的進行。這些列表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。第111頁，共150頁。 審查：評審組仔細走查整個文檔。和走查一樣，這一步的目的也是找出文檔中的錯誤，而不是改正它們。審查組組長必須在一天之內寫出一份關于審查的報告。通常每次審查會不超過90分鐘。 第112頁，共150頁。 返工：文檔的作者負責解決在書面報告中列出的所有錯誤及問題。 第113頁，共150頁。 跟蹤：組長必須確保所提出的每個問題都得到了圓滿的解決(要么修正了文檔，要么澄清了被誤認為是錯誤的條目)。第114頁，共150頁。 必須檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審查過程中返工量超過5%，則應該召集

32、審查組再對文檔全面地審查一遍。第115頁，共150頁。 4. 程序正確性證明 正確性證明的基本思想是證明程序能完成預定的功能。因此，應該提供對程序功能的嚴格數(shù)學說明，然后根據(jù)程序代碼證明程序確實能實現(xiàn)它的功能說明。第116頁，共150頁。 如果在程序的若干個點上，設計者可以提出關于程序變量及它們的關系的斷言，那么在每一點上的斷言都應該永遠是真的。第117頁，共150頁。 如果輸入斷言和輸出斷言是正確的，而且程序確實是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。第118頁，共150頁。13.6 軟件配置管理 在開發(fā)計算機軟件的過程中，變化(或稱為變動)是不可避免的。如果不能適當?shù)?/p>

33、控制和管理變化，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。 第119頁，共150頁。 軟件配置管理是在計算機軟件整個生命期內管理變化的一組活動。具體地說，這組活動用來：標識變化；控制變化；確保適當?shù)貙崿F(xiàn)了變化；向需要知道這方面信息的人報告變化。第120頁，共150頁。 軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后才發(fā)生的，而軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件退役后才終止的一組跟蹤和控制活動。 第121頁，共150頁。 軟件配置管理的目標是，使變化更容易被適應，并且在必須變化時減少所需花費的工作量。第122頁，共150頁。 13.6.1 軟件配置 1. 軟件配置項 軟件

34、過程的輸出信息可以分為三類：計算機程序(源代碼和可執(zhí)行程序)；描述計算機程序的文檔(供技術人員或用戶使用)；數(shù)據(jù)(程序內包含的或在程序外的)。第123頁，共150頁。 上述這些項組成了在軟件過程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。 可以把軟件配置管理看作是應用于整個軟件過程的軟件質量保證活動，是專門用于管理變化的軟件質量保證活動。第124頁，共150頁。 2. 基線 基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為： 第125頁，共150頁。 已經(jīng)通過了正式復審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎，

35、并且只有通過正式的變化控制過程才能改變它。 第126頁，共150頁。 簡而言之，基線就是通過了正式復審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必須應用特定的、正式的過程(稱為規(guī)程)來評估、實現(xiàn)和驗證每個變化。第127頁，共150頁。 13.6.2 軟件配置管理過程 軟件配置管理是軟件質量保證的重要一環(huán)，它的主要任務是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。 第128頁，共150頁。具體來說，軟件配置管理主要有五項任務：標識、版本控制、變化控制、配置審計、報告

36、第129頁，共150頁。 1. 標識軟件配置中的對象 為了控制和管理軟件配置項，必須單獨命名每個配置項，然后用面向對象方法組織它們?？梢詷俗R出兩類對象：基本對象和聚集對象(可以把聚集對象作為代表軟件配置完整版本的一種機制)。 第130頁，共150頁。 每個對象都有一組能惟一地標識它的特征：名字、描述、資源表和“實現(xiàn)”。其中，對象名是無二義性地標識該對象的一個字符串。第131頁，共150頁。 2. 版本控制 版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。第132頁，共150頁。 實現(xiàn)這個目標的方法是，把屬性和軟件的每個版本關聯(lián)起來，然后通過描述一組所期望的屬性來指定和構造所需要的配置。第133頁，共150頁。 3. 變化控制 對于大型軟件開發(fā)項目來說，無控制的變化將迅速導致混亂。變化控制把人的規(guī)程和自動工具結合起來，以提供一個控制變化的機制。變化控制過程如圖12.4所示。第134頁，共150頁。圖 訪問和同步控制第135頁，共150頁。 4. 配置審計 為確保適當?shù)貙崿F(xiàn)了所