估算軟件規(guī)模

1、,第113章皴牌頻撕管理； * 估算軟件規(guī)模工作量估算進度計劃人員組織質(zhì)量保證軟件配置管理能力成熟度模型在經(jīng)歷了若干個大型軟件工程項目的失敗之后，人們才逐漸認(rèn)識 到軟件項目管理的重要性和特殊性。事實上，這些項目的失敗并不是 由于從事軟件開發(fā)工作的軟件工程師無能，正相反，他們之中的絕大 多數(shù)是當(dāng)時杰出的技術(shù)專家。這些工程項目的失敗主要是因為管理不 善。所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置 和使用各種資源，以達到既定目標(biāo)的過程。軟件項目管理先于任何技術(shù)活動之前開始，并且貫穿于軟件的整 個生命周期之中。軟件項目管理過程從一組項目計劃活動開始，而制 定計劃的基礎(chǔ)是工作量估算和完成期

2、限估算。為了估算項目的工作量 和完成期限，首先需要估算軟件的規(guī)模。估算軟件規(guī)模代碼行技術(shù)代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的方法。這種方法依 據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)，估計實現(xiàn)一個功能所需要的 源程序行數(shù)。當(dāng)有以往開發(fā)類似產(chǎn)品的歷史數(shù)據(jù)可供參考時，用這種 方法估計出的數(shù)值還是比較準(zhǔn)確的。把實現(xiàn)每個功能所需要的源程序 行數(shù)累加起來，就可得到實現(xiàn)整個軟件所需要的源程序行數(shù)。代碼行技術(shù)的主要優(yōu)點是，代碼是所有軟件開發(fā)項目都有的“產(chǎn) 品”，而且很容易計算代碼行數(shù)。代碼行技術(shù)的缺點是：源程序僅是 軟件配置的一個成分，用它的規(guī)模代表整個軟件的規(guī)模似乎不太合理;用不同語言實現(xiàn)同一個軟件所需要的

3、代碼行數(shù)并不相同；這種方法不 適用于非過程語言。為了克服代碼行技術(shù)的缺點，人們又提出了功能 點技術(shù)。功能點技術(shù)功能點技術(shù)依據(jù)對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果，估 算軟件規(guī)模。這種方法用功能點（FP）為單位度量軟件規(guī)模。1.信息域特性 a a 功能點技術(shù)定義了信息域的5個特性，分別是輸入項數(shù)（1叩）、輸出 項數(shù)（0比）、查詢數(shù)（：叫）、主文件數(shù)阿）和外部接口數(shù)（：叫。下面講述 這5個特性的含義。2.估算功能點的步驟舉例：用3個步驟，可估算出一個軟件的功能點數(shù)（即軟件規(guī)模）。（1）計算未調(diào)整的功能點數(shù)UFP計算技術(shù)復(fù)雜性因子丁6尸（3）計算功能點數(shù)尸口工作量估算軟件估算模型使用由經(jīng)驗導(dǎo)出的公

4、式來預(yù)測軟件開發(fā)工作量，工 作量是軟件規(guī)模（KLOC或FP）的函數(shù)，工作量的單位通常是人月（pm）。 支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結(jié) 出來的，因此，沒有一個估算模型可以適用于所有類型的軟件和開發(fā) 環(huán)境。注：簡要介紹：靜態(tài)單變量模型、動態(tài)多變量模型、COCOMO2 模型進度計劃不論從事哪種技術(shù)性項目，實際情況都是，在實現(xiàn)一個大目標(biāo)之 前往往必須完成數(shù)以百計的小任務(wù)（也稱為作業(yè)）。這些任務(wù)中有一 些是處于“關(guān)鍵路徑”（回顧之前相關(guān)知識）之外的，其完成時間如 果沒有嚴(yán)重拖后，就不會影響整個項目的完成時間；其他任務(wù)則處于 關(guān)鍵路徑之中，如果這些“關(guān)鍵任務(wù)”的進度拖后，則整

5、個項目的完 成日期就會拖后，管理人員應(yīng)該高度關(guān)注關(guān)鍵任務(wù)的進展情況。一個有效的軟件過程應(yīng)該定義一個適用于當(dāng)前項目的任務(wù)集合。 一個任務(wù)集合包括一組軟件工程工作任務(wù)、里程碑和可交付的產(chǎn)品。為一個項目所定義的任務(wù)集合，必須包括為獲得高質(zhì)量的軟件產(chǎn)品而 應(yīng)該完成的所有任務(wù)，但是同時又不能讓項目組承擔(dān)不必要的工作。項目管理者的目標(biāo)是定義全部項目任務(wù)，識別出關(guān)鍵任務(wù)，跟蹤 關(guān)鍵任務(wù)的進展?fàn)顩r，以保證能及時發(fā)現(xiàn)拖延進度的情況。為達到上 述目標(biāo)，管理者必須制定一個足夠詳細(xì)的進度表，以便監(jiān)督項目進度 并控制整個項目。估算開發(fā)時間估算出完成給定項目所需的總工作量之后，接下來需要回答的問 題就是： 用多長時間才能

6、完成該項目的開發(fā)工作？對于一個估計工 作量為20人月的項目，可能想出下列幾種進度表：1個人用20個月完成該項目；4個人用5個月完成該項目；20個人用1個月完成該項目。a g j a j a a但是，這些進度表并不現(xiàn)實，實際上軟件開發(fā)時間與從事開發(fā)工 作的人數(shù)之間并不是簡單的反比關(guān)系。通常，成本估算模型也同時提供了估算開發(fā)時間T的方程。重點：研究項目組規(guī)模與項目組總生產(chǎn)率的關(guān)系。舉例：說明項目組規(guī)模與生產(chǎn)率的關(guān)系。Gan”圖首先通過一個非常簡單的例子引出這種工具。例：假設(shè)有一座陳舊的矩形木板房需要重新油漆。這項工作必須 分3步完成：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的 油漆。假設(shè)一共

7、分配了15名工人去完成這項工作，然而工具卻很有限： 只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油 漆用的小刮刀。怎樣安排才能使工作進行得更有效呢？一種做法是首先刮掉四面墻壁上的舊漆，然后給每面墻壁都刷上 新漆，最后清除濺在每個窗戶上的油漆。顯然這是效率最低的做法， 因為總共有15名工人，然而每種工具卻只有5件，這樣安排工作在任何 時候都有10名工人閑著沒活干。這時：同學(xué)們可能已經(jīng)想到，應(yīng)該采用“流水作業(yè)法”，也就是 說，首先由5名工人用刮板刮掉第1面墻上的舊漆（這時其余10名工人休 息），當(dāng)?shù)?面墻刮凈后，另夕卜5名工人立即用刷子給這面墻刷新漆（與此同時拿刮板的5名工人轉(zhuǎn)去

8、刮第2面墻上的舊漆)，一旦刮舊漆的工人轉(zhuǎn) 到第3面墻而且刷新漆的工人轉(zhuǎn)到第2面墻以后，余下的5名工人立即拿 起刮刀去清除濺在第1面墻窗戶上的油漆，。這樣安排每個工人都 有活干，因此能夠在較短的時間內(nèi)完成任務(wù)。假設(shè)木板房的第2、4兩面墻的長度比第1、3兩面墻的長度長一倍， 此外，不同工作需要用的時間長短也不同，刷新漆最費時間，其次是 刮舊漆，清理(即清除濺在窗戶上的油漆)需要的時間最少?？梢允褂?。壯圖描繪上述流水作業(yè)過程：在時間為零時開始刮 第1面墻上的舊漆，兩小時后刮舊漆的工人轉(zhuǎn)去刮第2面墻，同時另5 名工人開始給第1面墻刷新漆，每當(dāng)給一面墻刷完新漆之后，第3組的5 名工人立即清除濺在這面墻

9、窗戶上的漆。工程網(wǎng)絡(luò)Gantt圖能很形象地描繪任務(wù)分解情況，以及每個子任務(wù)(作業(yè))的 開始時間和結(jié)束時間，因此是進度計劃和進度管理的有力工具。它具 有直觀簡明和容易掌握、容易繪制的優(yōu)點，但是6。壯圖也有3個主要 缺點：(1)不能顯式地描繪各項作業(yè)彼此間的依賴關(guān)系；(2)進度計劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻 和主控的對象；(3)計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的 浪費。估算工程進度舉例：在前面例子的基礎(chǔ)之上，利用工程網(wǎng)絡(luò)估算工程進度。補充：計算最遲時刻LET使用下述3條規(guī)則：(1)考慮離開該事件的所有作業(yè)；(2)從每個作業(yè)的結(jié)束事件的最遲時刻中減去該作業(yè)的持續(xù)時

10、間；(3)選取上述差數(shù)中的最小值作為該事件的最遲時刻LET。關(guān)鍵路徑強調(diào)：關(guān)鍵路徑上的事件(關(guān)鍵事件)必須準(zhǔn)時發(fā)生，組成關(guān)鍵路 徑的作業(yè)(關(guān)鍵作業(yè))的實際持續(xù)時間不能超過估計的持續(xù)時間，否則工程就不能準(zhǔn)時結(jié)束。工程項目的管理人員應(yīng)該密切注視關(guān)鍵作業(yè)的進展情況，如果關(guān) 鍵事件出現(xiàn)的時間比預(yù)計的時間晚，則會使最終完成項目的時間拖后； 如果希望縮短工期，只有往關(guān)鍵作業(yè)中增加資源才會有效果。機動時間不在關(guān)鍵路徑上的作業(yè)有一定程度的機動余地實際開始時間 可以比預(yù)定時間晚一些，或者實際持續(xù)時間可以比預(yù)定的持續(xù)時間長 二 二 二 一些，而并不影響工程的結(jié)束時間。一個作業(yè)可以有的全部機動時間 等于它的結(jié)束事件

11、的最遲時刻減去它的開始事件的最早時刻，再減去 這個作業(yè)的持續(xù)時間：機動時間=(LET)結(jié)束-(EET)開始-持續(xù)時間人員組織軟件項目成功的關(guān)鍵是有高素質(zhì)的軟件開發(fā)人員。然而大多數(shù)軟 件的規(guī)模都很大，單個軟件開發(fā)人員無法在給定期限內(nèi)完成開發(fā)工作， 因此，必須把多名軟件開發(fā)人員合理地組織起來，使他們有效地分工 協(xié)作共同完成開發(fā)工作。 I 11 - 1 1 I R -r 刃- I I B -為了成功地完成軟件開發(fā)工作，項目組成員必須以一種有意義且 有效的方式彼此交互和通信。如何組織項目組是一個重要的管理問題， 管理者應(yīng)該合理地組織項目組，使項目組有較高生產(chǎn)率，能夠按預(yù)定 的進度計劃完成所承擔(dān)的工作。

12、經(jīng)驗表明，項目組組織得越好，其生 產(chǎn)率越高，而且產(chǎn)品質(zhì)量也越好?，F(xiàn)有的軟件項目組的組織方式很多，通常，組織軟件開發(fā)人員的 方法，取決于所承擔(dān)的項目的特點、以往的組織經(jīng)驗以及管理者的看 法和喜好。下面介紹3種典型的組織方式：民主制程序員組、主程序員組、現(xiàn) 代程序員組。比較以上三種組織方式的特點。質(zhì)量保證軟件質(zhì)量概軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程 度”。更具體地說，軟件質(zhì)量是軟件與明確地敘述的功能和性能需求、 文檔中明確描述的開發(fā)標(biāo)準(zhǔn)以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有 的隱含特征相一致的程度。注：上述定義強調(diào)了下述的3個要點：軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)

13、量不高。（2）指定的開發(fā)標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則，如果沒有遵守這些準(zhǔn)則，幾乎肯定會導(dǎo)致軟件質(zhì)量不高。通常，有一組沒有顯式描述的隱含需求（例如，軟件應(yīng)該 是容易維護的）。如果軟件滿足明確描述的需求，但卻不滿足隱含的 需求，那么軟件的質(zhì)量仍然是值得懷疑的。13.5.2軟件質(zhì)量保證措施軟件質(zhì)量保證（software quality assurance,SQA）的措施主要有： 基 于非執(zhí)行的測試（也稱為復(fù)審或評審），基于執(zhí)行的測試（即以前講過的軟件測試）和程序正確性證明。復(fù)審主要用來保證在編碼之前各 階段產(chǎn)生的文檔的質(zhì)量；基于執(zhí)行的測試需要在程序編寫出來之后進B a 工行，它是保證軟件質(zhì)量的最

14、后一道防線；程序正確性證明使用數(shù)學(xué)方 法嚴(yán)格驗證程序是否與對它的說明完全一致。重點：審查審查過程包括下述5個基本步驟：（1）綜述。由負(fù)責(zé)編寫文檔的一名成員向?qū)彶榻M綜述該文檔。 在綜述會結(jié)束時把文檔分發(fā)給每位與會者。（2）準(zhǔn)備。評審員仔細(xì)閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯 誤的類型，并按發(fā)生頻率把錯誤類型分級，以輔助審查工作。這些列 表有助于評審員們把注意力集中到最常發(fā)生錯誤的區(qū)域。（3）審查。評審組仔細(xì)走查整個文檔。和走查一樣，這一步的 目的也是發(fā)現(xiàn)文檔中的錯誤，而不是改正它們。通常每次審查會不超 過90分鐘。審查組組長應(yīng)該在一天之內(nèi)寫出一份關(guān)于審查的報告。（4）返工。文檔的作者負(fù)責(zé)解決在審查

15、報告中列出的所有錯誤 及問題。（5） 跟蹤。組長必須確保所提出的每個問題都得到了圓滿的解 決（要么修正了文檔，要么澄清了被誤認(rèn)為是錯誤的條目）。必須仔 細(xì)檢查對文檔所做的每個修正，以確保沒有引入新的錯誤。如果在審 查過程中返工量超過5%，則應(yīng)該由審查組再對文檔全面地審查一遍。審查組由4人組成。組長既是審查組的管理人員又是技術(shù)負(fù)責(zé)人。審查組必須包括負(fù)責(zé)當(dāng)前階段開發(fā)工作的項目組代表和負(fù)責(zé)下一階段 開發(fā)工作的項目組代表，此外，還應(yīng)該包括一名SQA小組的代表。審查是檢測軟件錯誤的一種好方法，利用審查可以在軟件過程的 早期階段發(fā)現(xiàn)并改正錯誤，也就是說，能在修正錯誤的代價變得很昂 貴之前就發(fā)現(xiàn)并改正錯誤。

16、因此，審查是一種經(jīng)濟有效的錯誤檢測方 法。4.程序正確性證明測試可以暴露程序中的錯誤，因此是保證軟件可靠性的重要手段; 但是，測試只能證明程序中有錯誤，并不能證明程序中沒有錯誤。因 此，對于保證軟件可靠性來說，測試是一種不完善的技術(shù)，人們自然 希望研究出完善的正確性證明技術(shù)。正確性證明的基本思想是證明程序能完成預(yù)定的功能。因此，應(yīng) 該提供對程序功能的嚴(yán)格數(shù)學(xué)說明，然后根據(jù)程序代碼證明程序確實 能實現(xiàn)它的功能說明。介紹證明的基本思想：如果在程序的若干個點上，設(shè)計者可以提 出關(guān)于程序變量及它們的關(guān)系的斷言，那么在每一點上的斷言都應(yīng)該 永遠是真的。假設(shè)在程序的P1,P2,，Pn等點上的斷言分別是 a

17、(1),a(2)，(。)，其中必須是關(guān)于程序輸入的斷言，a(n)必須是 關(guān)于程序輸出的斷言。為了證明在點Pi和Pi+1之間的程序語句是正確 的，必須證明執(zhí)行這些語句之后將使斷言&(。變成(1+1)。如果對程序 內(nèi)所有相鄰點都能完成上述證明過程，則證明了輸入斷言加上程序可 以導(dǎo)出輸出斷言。如果輸入斷言和輸出斷言是正確的，而且程序確實 是可以終止的(不包含死循環(huán))，則上述過程就證明了程序的正確性。補充：目前已經(jīng)研究出證明PASCAL和LISP程序正確性的程序系 統(tǒng)，正在對這些系統(tǒng)進行評價和改進?，F(xiàn)在這些系統(tǒng)還只能對較小的 程序進行評價，毫無疑問還需要做許多工作，這樣的系統(tǒng)才能實際用 于大型程序的正

18、確性證明。軟件配置管理軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動。具 體地說，這組活動用來： 標(biāo)識變化；控制變化；確保適當(dāng) 地實現(xiàn)了變化；向需要知道這類信息的人報告變化。軟件配置管理不同于軟件維護。維護是在軟件交付給用戶使用后 才發(fā)生的，而配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到 軟件退役后才終止的一組跟蹤和控制活動。軟件配置管理的目標(biāo)是，使變化更正確且更容易被適應(yīng)，在必須 變化時減少所需花費的工作量。軟件配置.軟件配置項軟件過程的輸出信息可以分為3類：計算機程序（源代碼和可 執(zhí)行程序）；描述計算機程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。上述這

19、些項組成了在軟件過 程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟 件配置項。.基線a g j a j a a基線是一個軟件配置管理概念，它有助于我們在不嚴(yán)重妨礙合理 變化的前提下來控制變化。IEEE把基線定義為：已經(jīng)通過了正式復(fù) 審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有 通過正式的變化控制過程才能改變它。簡而言之，基線就是通過了正式復(fù)審的軟件配置項。軟件配置管理過程軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它的主要任務(wù)是控制 變化，同時也負(fù)責(zé)各個軟件配置項和軟件各種版本的標(biāo)識、軟件配置 審計以及對軟件配置發(fā)生的任何變化的報告。具體來說，軟件配置管理主要有5項任務(wù)

20、：標(biāo)識、版本控制、變化控制、配置審計和報告。能力成熟度模型（重點）能力成熟度模型（capability maturity model，CMM），是用于評價軟 件機構(gòu)的軟件過程能力成熟度的模型。最初，建立此模型的目的主要 是，為大型軟件項目的招投標(biāo)活動提供一種全面而客觀的評審依據(jù)， 發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu)內(nèi)部的過程改進活 動中。能力成熟度模型的基本思想是，由于問題是由我們管理軟件過程 的方法不當(dāng)引起的，所以新軟件技術(shù)的運用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個有規(guī)律的、 成熟的軟件過程。改進后的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更 多的軟

21、件項目免受時間和費用超支之苦。CMM把軟件過程從無序到有序的進化過程分成5個階段，并把這 些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個 有序的尺度，用以測量軟件機構(gòu)的軟件過程成熟度和評價其軟件過程 能力，這些等級還能幫助軟件機構(gòu)把應(yīng)做的改進工作排出優(yōu)先次序。注：成熟度從“1級”到“5級”，反映出一個軟件機構(gòu)為了達到 從一個無序的、混亂的軟件過程進化到一種有序的、有紀(jì)律的且成熟 的軟件過程的目的，必須經(jīng)歷的過程改進活動的途徑。每一個成熟度 級別都是該軟件機構(gòu)沿著改進其過程的途徑前進途中的一個臺階，后 一個成熟度級別是前一個級別的軟件過程的進化目標(biāo)。CMM的每個成熟度級別中都包含

22、一組過程改進的目標(biāo)，滿足這些 目標(biāo)后一個機構(gòu)的軟件過程就從當(dāng)前級別進化到下一個成熟 度級別。下面介紹這5個級別的特點。.初始級軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過 程是經(jīng)過定義的（即沒有一個定型的過程模型），項目能否成功完全 取決于開發(fā)人員的個人能力。.可重復(fù)級軟件機構(gòu)建立了基本的項目管理過程（過程模型）,可跟蹤成本、進 度、功能和質(zhì)量。已經(jīng)建立起必要的過程規(guī)范，對新項目的策劃和管 理過程是基于以前類似項目的實踐經(jīng)驗，使得有類似應(yīng)用經(jīng)驗的軟件 項目能夠再次取得成功。.已定義級軟件機構(gòu)已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已 經(jīng)文檔化和標(biāo)準(zhǔn)化。所有項目組都使用文檔化的、經(jīng)過批準(zhǔn)的過程來 開發(fā)和維護軟件。這一級包含了第2級的全部特征。在第3級成熟度的 軟件機構(gòu)中，有一個固定的過程小組從事軟件過程工程活動。當(dāng)需要 時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例，并投入過程運作而開展有效的軟 件項目工程實踐。.已管理級軟件機構(gòu)對軟件過程（過程模型和過程實例）和軟件產(chǎn)品都建立 了定量的質(zhì)量目標(biāo)，所有項目的重要的過程活動都是