《軟件工程-理論、方法與實踐》課件第14章

第14章軟件計劃管理14.1軟件項目管理14.2成本估算14.3軟件配置管理14.4IBMRational軟件配置管理工具本章小結(jié)習題

14.1軟件項目管理

14.1.1軟件項目的特點

與其他項目相比，軟件項目有其特殊性，主要表現(xiàn)在：

(1)軟件產(chǎn)品的不可見性。軟件開發(fā)不同于其他產(chǎn)品的制造，其整個過程都是設(shè)計過程，其開發(fā)過程和產(chǎn)品既看不見又摸不著。因此，軟件項目具有特別的復雜性和抽象性。

(2)項目的高度不確定性。軟件的不可見性給項目的估算和計劃帶來了極大的不確定性，項目管理者也難以預(yù)見問題的出現(xiàn)，容易造成項目的預(yù)定計劃與實際情況存在較大的偏差。另外，計算機技術(shù)的飛速發(fā)展使得軟件項目的技術(shù)更新非?？?，過去積累的經(jīng)驗教訓難以在新的項目中發(fā)揮作用。

(3)軟件過程的多變化性。在軟件開發(fā)過程中，需求分析、體系結(jié)構(gòu)設(shè)計、詳細設(shè)計、軟件測試和交付等各個工作環(huán)節(jié)通常是一個典型的迭代和增量發(fā)展的動態(tài)變化過程。因此，軟件項目的開發(fā)過程具有復雜性、多樣性和不穩(wěn)定性的特點，特別是客戶需求的不確定性和多變性往往給軟件開發(fā)帶來極大的困難和風險。

(4)軟件人員的高流動性。在軟件開發(fā)過程中不需要使用大量的物質(zhì)資源，人力資源往往是關(guān)鍵性的因素。由于軟件產(chǎn)業(yè)發(fā)展迅速，人才需求旺盛，因此開發(fā)人員，尤其是項目的核心技術(shù)人才流動性高，這也給項目管理帶來了很大的風險。

總而言之，“復雜”和“變化”給軟件項目的管理帶來了相當大的難度，降低復雜性和控制變化成為軟件項目管理面臨的關(guān)鍵問題。軟件項目要想成功，需要大量的因素共同推動。調(diào)查研究表明，對信息系統(tǒng)項目成功起關(guān)鍵作用的最重要因素如下：

●清楚地界定目標及項目任務(wù)。

●高層管理者的支持。

●優(yōu)秀的項目經(jīng)理。

●有能力的項目團隊。

●充足的資源。

●客戶的參與協(xié)商。

●良好的溝通。

●對客戶的積極反應(yīng)。

●適當?shù)谋O(jiān)控和反饋。

●正確的技術(shù)。14.1.2軟件項目管理活動

1．項目啟動

在項目啟動階段，項目管理者需要與客戶一起定義系統(tǒng)的范圍，組建項目的開發(fā)團隊，并建立項目的基礎(chǔ)設(shè)施，具體活動內(nèi)容包括：確定項目范圍、組建項目團隊和建立項目

環(huán)境。

首先，要求項目管理者了解客戶的實際需求，從功能、性能和交付要求的角度定義軟件的范圍，研究系統(tǒng)的可行性和可能的解決方案，并與客戶在軟件范圍、驗收標準和交付日期等方面達成正式的協(xié)議。其次，項目管理者根據(jù)系統(tǒng)任務(wù)的要求組織開發(fā)團隊，并明確每一位成員的角色和職責。

另外，項目管理者應(yīng)與項目團隊一起，建立軟件開發(fā)所需的基礎(chǔ)設(shè)施，包括網(wǎng)絡(luò)環(huán)境、軟件系統(tǒng)、配置管理工具、文檔模板、會議程序和溝通系統(tǒng)等。

2．項目規(guī)劃

在項目規(guī)劃階段，項目管理者對于項目的資源、成本和進度進行合理估算，制定軟件開發(fā)計劃，主要包括確定項目活動、預(yù)算項目成本和制定進度計劃等活動。

項目管理者需要明確項目的各種活動、里程碑和可交付的文檔，確定各種活動之間的依賴關(guān)系和執(zhí)行順序，估計軟件開發(fā)所需要的資源；項目管理者還應(yīng)根據(jù)每項活動所需的資源進行成本估算，確定項目的成本預(yù)算；并估算完成每一項活動所需花費的時間，制定出合理的開發(fā)進度計劃，以確保項目在預(yù)定時間、預(yù)算資金與可利用資源的約束條件下完成。

3．項目實施

在項目實施階段，項目管理者執(zhí)行項目計劃，及時發(fā)現(xiàn)和糾正實際情況與計劃的偏差。具體活動內(nèi)容包括：監(jiān)控項目執(zhí)行、管理項目風險和控制項目變更。

項目管理者需要跟蹤項目的執(zhí)行情況，綜合評價整個項目的實際進展，及時發(fā)現(xiàn)和報告實際情況與計劃的偏差，并在必要的情況下采取糾正行動。項目管理者應(yīng)該識別可能造成項目進度推遲或預(yù)算超支的潛在問題，并采取有效的風險管理策略，以減少潛在問題發(fā)生的可能性和影響。

任何項目都不可避免地要發(fā)生變更，項目管理者應(yīng)該建立有效的變更控制系統(tǒng)，包括變更控制委員會、軟件配置管理和項目溝通體系，以便對項目變更進行控制和管理。

4．項目收尾

在項目收尾階段，項目團隊完成項目的交付，并進行項目總結(jié)，主要活動包括：客戶驗收項目、安裝培訓軟件、總結(jié)項目經(jīng)驗。

根據(jù)項目協(xié)議中規(guī)定的驗收標準，客戶對所交付的軟件產(chǎn)品進行評價，最終正式接受產(chǎn)品；項目團隊在目標環(huán)境中安裝軟件系統(tǒng)，培訓用戶使用系統(tǒng)，并移交文檔；項目團隊分析和總結(jié)項目的經(jīng)驗教訓，避免在以后的軟件項目中犯同樣的錯誤，不斷提高軟件開發(fā)管理水平。綜上所述，軟件項目管理不僅涉及軟件開發(fā)過程的各個方面，而且包括開發(fā)前期的立項階段和軟件運行以及項目評價階段的工作，強調(diào)了軟件項目的生命周期全過程和全方位的管理，強調(diào)軟件開發(fā)隊伍與軟件用戶之間的溝通。軟件項目管理的主要職能包括：

(1)制定計劃。規(guī)定待完成的任務(wù)、要求、資源、人力和進度等。

(2)建立組織。為實施計劃、保證完成任務(wù)，需要建立分工明確的責任制機構(gòu)。

(3)配備人員。任用各種層次的技術(shù)人員和管理人員。

(4)指導。鼓勵和動員軟件人員完成所分配的工作。

(5)檢驗。對照計劃或標準，監(jiān)督、控制和檢查實施情況。14.1.3軟件計劃和進度安排

在軟件開發(fā)過程中，軟件項目計劃處于十分重要的地位，涉及實施項目的各個環(huán)節(jié)，是有條不紊地開展軟件項目活動的基礎(chǔ)，是跟蹤、監(jiān)督、評審計劃執(zhí)行情況的依據(jù)。沒有完善的工作計劃常常會導致事倍功半，或者使項目在質(zhì)量、進度和成本上達不到要求，甚至使軟件項目失敗。因此，制定周密、簡潔和精確的軟件項目計劃是成功開發(fā)軟件產(chǎn)品的關(guān)鍵。軟件項目計劃的目標是提供一個能使項目管理人員對資源、成本和進度做出合理估算的框架。這些估算應(yīng)當在軟件項目開始的一個時間段內(nèi)做出，并隨著項目的進展定期更新。具體地講，軟件項目計劃的主要內(nèi)容包括確定軟件范圍，確定需要進行哪些活動，明確每項活動的職責，明確這些活動的完成順序，估算資源、成本和進度，制定項目計劃，編排進度等。

1．確定軟件范圍

確定軟件范圍是軟件項目計劃的首要任務(wù)，是制定軟件開發(fā)計劃的根據(jù)，是整個軟件生命周期中估算、計劃、執(zhí)行和跟蹤軟件項目活動的基礎(chǔ)。因此，應(yīng)該從管理角度和技術(shù)角度出發(fā)，對軟件工程中分配給軟件的功能和性能進行評價，確定明確的可理解的項目范圍。具體地講，軟件范圍包括功能、性能、限制、接口和可靠性。

軟件范圍的確立首先需要說明項目的目標與要求，給出該軟件的主要功能描述(只涉及高層和較高層的系統(tǒng)功能)，指明總的性能特征及其約束條件。在估算項目之前，應(yīng)對軟件的功能進行評價，并對其進行適當?shù)募毣员闾峁└敿毜募毠?jié)。由于成本和進度的估算都與功能有關(guān)，因此常常采用功能分解。軟件性能的考慮包括處理和響應(yīng)時間的需求。約束條件則標識外部硬件、可用存儲器或其他現(xiàn)行系統(tǒng)的限制，如主存、數(shù)據(jù)庫、通信速率和負荷限制等。功能、性能和約束必須在一起進行評價。因為，當性能不同時，為實現(xiàn)同樣的功能，開發(fā)工作量可能相差一個數(shù)量級。其次，給出系統(tǒng)接口描述與該軟件有關(guān)的其他系統(tǒng)之間的關(guān)系。對于每個接口都要考慮其性質(zhì)和復雜性，以便確定對開發(fā)資源、成本和進度的影響。接口可以細分為：運行軟件的硬件(如處理機和外設(shè))以及由該軟件控制的各種間接設(shè)備；必須與該軟件連接的現(xiàn)有軟件(如操作系統(tǒng)、數(shù)據(jù)庫、公用應(yīng)用軟件等)；通過終端或輸入/輸出設(shè)備使用該軟件的操作人員。

同時，軟件范圍還必須描述軟件質(zhì)量的某些因素，如可靠性、實時性、安全性等方面的要求。

2．估算項目

軟件項目計劃的第二個任務(wù)就是估算該軟件項目的規(guī)模及完成該軟件項目所需的資源、成本和進度。

項目規(guī)模的度量可以是軟件的功能點、特征點、代碼行的數(shù)目。規(guī)模估計涉及的產(chǎn)品和活動有：運行軟件和支持軟件，可交付的和不可交付的產(chǎn)品，軟件和非軟件工作產(chǎn)品(如文檔)、驗證和確認工作產(chǎn)品的活動。為便于估計項目規(guī)模，需要將軟件工作產(chǎn)品分解到滿足估計對象所需要的粒度。為了使開發(fā)項目能夠在規(guī)定的時間內(nèi)完成，而且不超過預(yù)算，工作量與成本的估算和管理控制是關(guān)鍵。但由于影響軟件工作量和成本的因素眾多，因此對項目的工作量、人員配置和成本的估算，有一定難度，其方法目前還不太成熟。如果可能，應(yīng)利用類似項目的經(jīng)驗，導出各種活動的時間段，做出工作量、人員配置和成本估算在軟件生命周期上的分布。

項目所需資源包括人力資源、硬件資源和軟件資源。對每種資源都應(yīng)說明資源的描述、資源的有效性、資源的開始時間和持續(xù)時間。后兩個特性又統(tǒng)稱為時間窗口。軟件項目是智力密集、勞動密集型項目，受人力資源影響最大。項目成員的結(jié)構(gòu)、責任心、能力和穩(wěn)定性對項目質(zhì)量以及是否成功有著決定性的影響。因此，在項目計劃中，必須認真考慮人員的技術(shù)水平、專業(yè)、人數(shù)以及在開發(fā)過程各階段中對各種人員的需要。對于具有一定規(guī)模的項目，在軟件開發(fā)的前期和后期，即軟件計劃與需求分析階段和軟件檢驗、評價與驗收階段，管理人員和高級技術(shù)人員需要投入大量精力，而初級技術(shù)人員參與較少。在詳細設(shè)計、編碼和單元測試階段，大量的工作由初級技術(shù)人員完成，高級人員主要進行技術(shù)把關(guān)。在軟件開發(fā)中，硬件也是一種軟件開發(fā)工具。硬件資源包括宿主機(指軟件開發(fā)階段所使用的計算機和外圍設(shè)備)、目標機(指運行所開發(fā)軟件的計算機和外圍設(shè)備)、其他硬件設(shè)備(指專用軟件開發(fā)時所需要的特殊硬件資源)。

在軟件開發(fā)過程中，需要使用許多軟件工具來幫助軟件開發(fā)，這些軟件工具就是軟件資源。主要的軟件工具有業(yè)務(wù)數(shù)據(jù)工具、項目管理工具、支持工具、分析和設(shè)計工具、編程工具、組裝和測試工具、原型化和模擬工具、維護工具、框架工具等。為了提高軟件生產(chǎn)率和軟件質(zhì)量，應(yīng)該建立可復用的軟件標準件/部件庫。當需要時，根據(jù)具體情況，對軟件部件稍做加工、修改，就可以構(gòu)成所需的軟件。但有時在修改時可能出現(xiàn)新的問題，所以此時應(yīng)特別小心。

3．編制項目進度表

項目進度表與軟件產(chǎn)品的規(guī)模估計、軟件工作量和成本估算有關(guān)。在編制軟件進度表時，若有可能，要利用類似項目的經(jīng)驗。應(yīng)注意的是：軟件進度表受規(guī)定的里程碑日期、關(guān)鍵的相關(guān)日期及其他限制，軟件進度表中的活動要有合適的時間間隔，里程碑要以適當?shù)臅r間長度分開。為了讓項目組成員各負其責，應(yīng)明確規(guī)定他們在項目組分擔的責任。一種有效的方法就是繪制技術(shù)編制表及責任表，在項目開始時就要恰當?shù)卮钆浜萌藛T、技術(shù)及工作任務(wù)。隨著項目的進展，有可能要把已分的工作再細分或進行新的調(diào)整，為此，項目經(jīng)理需要了解項目組的每個成員，清楚他們的特長、經(jīng)驗以及掌握的技術(shù)情況。首先，按照每個成員對專業(yè)領(lǐng)域的熟悉程度打分，形成專業(yè)領(lǐng)域技術(shù)編制表，如表14.1所示。具體方法是，假設(shè)將專業(yè)領(lǐng)域分為五種：系統(tǒng)分析員、系統(tǒng)設(shè)計員、程序員、測試員、硬件工程師，并將最高分定為5分。然后根據(jù)每個成員對上述專業(yè)領(lǐng)域的熟悉程度打分，熟悉程度越高，得分越高。這樣就可以對項目組成員及技術(shù)狀況一目了然，并據(jù)此分配工作。項目經(jīng)理根據(jù)上述技術(shù)編制表，結(jié)合項目實際需求可以制定責任表，在責任表中確定項目的主要負責人和輔助負責人。每項任務(wù)只需要一個人負主要責任，但可以安排幾個項目組成員輔助他。

對于具有一定規(guī)模的軟件項目，通常參加的不止一人，這樣開發(fā)工作就會出現(xiàn)并行情形。圖14.1給出了一個典型的由多人參加的軟件項目的任務(wù)圖。圖14.1軟件項目的并行性在軟件項目的各種活動中，首先是進行項目的需求分析和評審，此項工作是以后工作的基礎(chǔ)。只要軟件的需求分析通過評審，系統(tǒng)概要設(shè)計和測試計劃制定工作就可以并行進行。如果系統(tǒng)模塊結(jié)構(gòu)已經(jīng)建立，則對各個模塊的詳細設(shè)計、編碼、單元測試等工作就可以并行進行。等到每一個模塊都已經(jīng)測試完成，就可以組裝、測試，最后確認測試，以便軟件交付。從圖14.1所示可以看出，在軟件開發(fā)過程中設(shè)置了許多里程碑。里程碑為管理人員提供了指示項目進度的可靠依據(jù)。當一個軟件工程任務(wù)成功地通過了評審并產(chǎn)生了文檔，就完成了一個里程碑。

軟件項目并行性對進度提出了要求，要求進度計劃必須決定任務(wù)之間的從屬關(guān)系，確定各任務(wù)的先后次序和銜接，確定各任務(wù)完成的持續(xù)時間，確定構(gòu)成關(guān)鍵路徑的任務(wù)。制定項目進度計劃的第一步就是估計每項活動從開始到完成所需的時間，即估計工期。工期估計和預(yù)算分攤估計可以采用兩種辦法：一是自上而下法，即在項目建設(shè)總時間和總成本之內(nèi)按照每一工作階段的相關(guān)工作范圍來考察，按項目總時間或總成本的一定比例分攤到各個工作階段中；二是自下而上法，由每一工作階段的具體負責人進行工期和預(yù)算估計，然后再進行平衡和調(diào)整。經(jīng)驗表明，行之有效的方法是由某項工作的具體負責人進行估計，因為這樣做既可以得到該負責人的承諾，產(chǎn)生有效的參與激勵，又可以減少由項目經(jīng)理獨自估計所有活動的工期所產(chǎn)生的偏差。在此估計的基礎(chǔ)上，項目經(jīng)理完成各工期的累計和分攤預(yù)算的累計，并與項目總建設(shè)時間和總成本進行比較，根據(jù)一定的規(guī)則進行調(diào)整。在進度安排中，為了清楚地表達各項任務(wù)之間進度的相互依賴關(guān)系，通常采用圖示方法。常用的圖示方法有甘特圖和網(wǎng)絡(luò)圖。在這些圖示方法中，必須明確標明以下信息：

(1)各個任務(wù)計劃的開始時間、完成時間。

(2)各個任務(wù)完成的標志。

(3)各個任務(wù)與參與工作的人數(shù)，各個任務(wù)與工作量之間的銜接情況。

(4)完成各個任務(wù)所需的物理資源和數(shù)據(jù)資源。甘特圖又稱為條形圖，如圖14.2所示。用水平線段表示任務(wù)的工作階段，線段的起點和終點分別對應(yīng)著任務(wù)的開始時間和完成時間，線段的長度表示完成任務(wù)所需的時間。甘特圖的優(yōu)點是標明了各任務(wù)的計劃進度與當前進度，能動態(tài)地反映軟件開發(fā)進展情況，缺點是難以反映多個任務(wù)之間存在的復雜的邏輯關(guān)系。圖14.2甘特圖網(wǎng)絡(luò)計劃是一種在項目的計劃、進度安排和控制工作中很有用的技術(shù)，它由許多相互關(guān)聯(lián)的活動組成。兩種網(wǎng)絡(luò)計劃方法：計劃審評技術(shù)和關(guān)鍵路徑法，都是應(yīng)用網(wǎng)絡(luò)圖來表明活動的順序流程以及它們之間的相互關(guān)系。通常用兩張圖來定義網(wǎng)絡(luò)圖，一張圖繪出某一特定軟件項目的所有任務(wù)即任務(wù)分解結(jié)構(gòu)，另一張圖給出應(yīng)該按照什么次序來完成這些任務(wù)，給出各個任務(wù)之間的銜接關(guān)系。

如圖14.3為舊木板房刷漆的工程網(wǎng)絡(luò)圖。圖中1～11為刷漆工程中分解得到的不同任務(wù)。圖14.3舊木板房刷漆的工程網(wǎng)絡(luò)圖

14.2成本估算

14.2.1軟件規(guī)模估算

軟件規(guī)模估算(SoftwareSizeEstimation)是在軟件工作產(chǎn)品沒有完成之前對軟件工程產(chǎn)品的估算。軟件規(guī)模是軟件項目可量化的結(jié)果，可以直接采用代碼行LOC(LineofCode)來表示，也可以間接采用功能點FP(FunctionPoints)或?qū)ο簏cOP(ObjectPoints)來測算。

代碼行LOC是指系統(tǒng)交付的源代碼行數(shù)。對于現(xiàn)代軟件系統(tǒng)，顯然直接估算代碼行不太容易，而功能點FP和對象點OP則是基于交付系統(tǒng)相關(guān)功能度的測算，相對容易提取。功能點FP可以根據(jù)外部的輸入輸出、用戶界面、與外部系統(tǒng)的接口、系統(tǒng)使用的文件數(shù)來確立。

對象點OP和功能點類似，主要用于數(shù)據(jù)庫語言、腳本語言構(gòu)成的系統(tǒng)。OP可以是用戶界面的個數(shù)、報表個數(shù)、構(gòu)造應(yīng)用程序的所需要的組件個數(shù)。而每個對象點也可以依據(jù)其復雜度歸為三個級別：簡單的、中等的和復雜的。表14.2列出了各類對象點的加權(quán)因子。其中，組件是指由如Java、C++?這類第三代語言實現(xiàn)的系統(tǒng)模塊。對象點的估算應(yīng)是系統(tǒng)中的對象點乘以對應(yīng)加權(quán)因子的總和。

軟件成本被認為是軟件規(guī)模S的函數(shù)，而S通常采用源代碼行作為計算參數(shù)，因此，通常需要根據(jù)歷史的經(jīng)驗將FP/OP轉(zhuǎn)換為代碼行。對于不同的程序設(shè)計語言，實現(xiàn)每個FP所需要的平均代碼行數(shù)AVC會有區(qū)別。如對于匯編語言，每個FP可能需要200～300行代碼行；而對于數(shù)據(jù)庫語言，每個FP只需要2～40行代碼行。因此，軟件規(guī)模S可以用以下公式計算：

S?=?AVC?×?FP14.2.2軟件成本估算方法

對于一個大型的軟件項目，由于項目的復雜性，開發(fā)成本的估算不是一件簡單的事情，要進行一系列的估算處理，主要是靠分解和類推的手段進行?；竟浪惴椒ǚ譃槿缦氯悾?/p>

(1)自頂向下估算。這種方法是從項目的整體出發(fā)，進行類推。即估計人員根據(jù)已完成項目所耗費的總成本(或總工作量)，推算將要開發(fā)的軟件的總成本(或總工作量)，然后按比例將它分配到各開發(fā)任務(wù)中，再檢驗它是否能滿足要求。這種方法的優(yōu)點是估算量小，速度快；缺點是對項目中的特殊困難估計不足，估算出來的成本盲目性大，有時會遺漏被開發(fā)軟件的某些部分。

(2)自底向上的估算。這種方法是把待開發(fā)的軟件細分，直到每一個子任務(wù)都已經(jīng)明確所需要的開發(fā)工作量，然后把它們加起來，得到軟件開發(fā)的總工作量。這是一種常見的估算方法。它的優(yōu)點是估算各個部分的準確性高；缺點是不僅缺少各項任務(wù)之間相互聯(lián)系所需要的工作量，還缺少許多與軟件開發(fā)有關(guān)的系統(tǒng)級工作量(配置管理、質(zhì)量管理、項目管理)。所以往往估計值偏低，必須用其他方法進行校驗和校正。

(3)差別估算。這種方法綜合了上述兩種方法的優(yōu)點，是把待定的軟件項目與已完成的軟件項目進行比較，不同的部分則采用相應(yīng)的方法進行估算。這種方法的優(yōu)點是可以提高估算的準確程度，缺點是不容易明確“類似”的界限。14.2.3專家判定技術(shù)

目前，軟件成本估算一般包括專家判定、類比估算和經(jīng)驗?zāi)Ｐ偷热N技術(shù)。這些技術(shù)可以在自頂向下的方法中使用，也可以在自底向上的方法中使用。

Deiphi技術(shù)的步驟是：

(1)組織者發(fā)給每位專家所有軟件系統(tǒng)的規(guī)格說明書和一張記錄估算值的表格，請他們進行估算。

(2)專家詳細研究軟件規(guī)格說明書的內(nèi)容。然后組織者召集小組會議，在會上，專家們與組織者一起對估算問題進行討論。

(3)各位專家對該軟件提出三個規(guī)模的估算值，即：

ai——該軟件可能的最小規(guī)模(最少源代碼行數(shù))；

mi——該軟件最可能的規(guī)模(最可能的源代碼行數(shù))；

bi——該軟件可能的最大規(guī)模(最多源代碼行數(shù))。

無記名地填寫表格，并說明做此估算的理由。

(4)組織者對各位專家在表中填寫的估算值進行綜合和分類。首先，計算各位專家(序號為i，i=1，2，…，n)的估算期望值Ei和估算值的期望中值E：

(n為專家數(shù))

然后，對專家的估算結(jié)果進行分類摘要。

(5)組織者召集會議，請專家們對其估算值有很大變動之處進行討論。專家對此估算另做一次估算。

(6)在綜合專家估算結(jié)果的基礎(chǔ)上，組織專家再次無記名地填寫表格。

從(4)～(6)適當重復幾次類比，根據(jù)過去完成項目的規(guī)模和成本等信息，推算出該軟件每行源代碼所需成本。然后再乘以該軟件源代碼行數(shù)的估計值，得到該軟件的成本估算值。14.2.4COCOMO模型

成本估算是用數(shù)學模型來估算軟件成本。現(xiàn)有的模型是根據(jù)長期的項目經(jīng)驗而總結(jié)出的經(jīng)驗公式。

構(gòu)造性成本模型COCOMO(ConstructiveCostModel)最初出現(xiàn)的是COCOMO81版，是產(chǎn)業(yè)界最廣泛應(yīng)用的軟件成本估算模型之一，Boehm在他的經(jīng)典著作“軟件工程經(jīng)濟學”中對COCOMO81模型進行了詳盡的描述。

1．COCOMO81

Boehm定義了“基本的”、“中間的”和“詳細的”三種形式的COCOMO模型，其兩個核心公式為：

工作量(人月PM)： ED?=?rSc

開發(fā)時間(月)： TD?=?a(ED)b

其中，S為千行源代碼數(shù)KLOC，經(jīng)驗常數(shù)r，c，a和b取決于項目的總體類型。在COCOMO81中，項目的類型被分為結(jié)構(gòu)型、半獨立型和嵌入型，三種類型的項目特點如表14.3所示。表14.4列出了根據(jù)項目類型確立的基本COCOMO公式。但顯然，軟件系統(tǒng)的三種簡單分類并不能準確地估算工作量成本，因此，中間的COCOMO估算公式通過引入與17個成本因素有關(guān)的作用系數(shù)Mi將模型進一步細化。Mi用來修正公式中的系數(shù)r。

17個成本因素Mi列于表14.5中，表中也給出了Mi的取值范圍，取值為1.00表示為該項要求正常時的修正系數(shù)?？紤]成本因素的中間的COCOMO公式對基本公式進行了修正，修正后的公式為

ED?=?rScM

其中

表14.6列出了正常未經(jīng)修正的中間COCOMO模型公式。實際應(yīng)用時應(yīng)根據(jù)項目的特性，對照表14.5來修正系數(shù)，參見表14.7給出的示例。詳細的COCOMO模型應(yīng)用自底向上的方式，首先把系統(tǒng)分為系統(tǒng)、子系統(tǒng)和模塊多個層次，然后先在模塊層應(yīng)用估算方法得到它們的工作量，再估計子系統(tǒng)，最后算出系統(tǒng)層。詳細的COCOMO對于生存期的各個階段使用不同的工作量系數(shù)。

2．COCOMOⅡ

COCOMO81目前已演化為更為全面的COCOMOⅡ版，COCOMOⅡ模型也包含幾個層次的模型：早期設(shè)計階段模型、復用模型以及體系結(jié)構(gòu)后階段模型。

早期設(shè)計階段模型適用于需求已建立、系統(tǒng)設(shè)計已處于初始階段，目標是對軟件系統(tǒng)的工作量做近似估計。其估算公式為

ED?=?2.94ScM

這里，M是表14.5所列成本因素的簡化集。

M?=?PERS?×?RCPX?×?RUSE?×?PDIF

×?PREX?×?FCIL?×?SCED

其中，PERS為個人能力；RCPX為可靠性和復雜性；RUSE代表復用性要求；PDIF為使用的平臺特性；PREX為個人經(jīng)驗；FCIL是項目支持設(shè)施；SCED是對進度的要求。復用模型用于估算集成可復用組件的工作量。由于目前軟件系統(tǒng)大量采用可復用的組件來構(gòu)造新的系統(tǒng)，其工作量計算也應(yīng)體現(xiàn)面向復用的軟件過程活動。復用模型采用對象點作為軟件規(guī)模估算單位，工作量計算公式如下：

其中，PROD?=?對象點數(shù)/人月，即軟件生產(chǎn)效率。體系結(jié)構(gòu)后階段模型用于軟件體系結(jié)構(gòu)已建立，子系統(tǒng)已分解，是最詳細的模型。其工作量計算模型與早期設(shè)計階段模型相同，但此時軟件規(guī)模的估算應(yīng)該更精確，公式中的M則考慮表17.5中17個因素，而指數(shù)因子C則基于5個因素的值：已有項目經(jīng)驗、開發(fā)過程的靈活性、是否需要風險分析、團隊合作狀況和軟件過程成熟度。因素值分為6級，從5到0對應(yīng)非常低到極高。設(shè)Fi表示第i個因素，則表14.7給出一個例子，說明這些成本因素形成是如何影響工作量估算的，其中指數(shù)所取的值為1.17；假設(shè)指標RELY、CPLX、STOR、TOOL和SCED是項目中的主要成本形成因素，因子取值參見表14.5，所有其他因素取正常值1。

在這個例子中，對關(guān)鍵性的成本形成因素分別賦予了最大和最小值來說明它們對工作量估算帶來的影響。從表中可以看出，對成本形成因素取較高值時的工作量估算是初始估算的一倍多，而對這些成本形成因素取低值時的工作量估算會降低到初始估算的大約1/3，這樣就突出表示了不同類型項目之間的巨大差異，以及在將一個領(lǐng)域的經(jīng)驗移植到另一個領(lǐng)域時的巨大困難。

COCOMO模型的計算公式是由模型設(shè)計者提出來的，反映了設(shè)計者們的經(jīng)驗和所掌握的數(shù)據(jù)，但是，它在實際使用時未免過于復雜。公式中用到的屬性太多，而且對這些值的估算帶有太多的不確定性。原則上講，模型的每個用戶應(yīng)該依照自己的歷史項目數(shù)據(jù)來校準該模型，因為這將反映出局部環(huán)境對模型的影響，然而實際過程中，很少有機構(gòu)對過去的項目數(shù)據(jù)進行長期細心的收集以支持對COCOMO模型的校準。因此，在COCOMO的實際使用中，模型參數(shù)的取值一般都用一些公開發(fā)表的取值。14.2.5面向?qū)ο箜椖康墓浪?/p>

Lorenz和Kidd給出了面向?qū)ο箜椖康墓浪憬ㄗh：

(1)可以使用工作量分解、FP分析和適用傳統(tǒng)應(yīng)用的方法進行估算。

(2)使用面向?qū)ο蟮姆治瞿Ｐ徒⒂美⒋_定用例數(shù)。

(3)對每個用例由分析模型確立系統(tǒng)核心類的數(shù)量。

(4)對系統(tǒng)的用戶界面進行歸類，確定用戶界面支持類的加權(quán)因子，并計算用戶界面支持類數(shù)。參考因子為：

●非圖形用戶界面：2.0。

●基于文本的用戶界面：2.25。

●圖形用戶界面：2.5。

●復雜的圖形用戶界面：3.0。

(5)確立工作單元數(shù)(人日)。Lorenz和Kidd建議每個類的平均工作單元數(shù)為15～20人日。

14.3軟件配置管理

14.3.1基線和配置項

1．基線(Baseline)

軟件變更是軟件開發(fā)中不可回避的事情。客戶希望修改需求，開發(fā)者希望修改技術(shù)方法，管理者希望修改項目方法，這三個希望都可能引起軟件變更。這是因為隨著時間的流逝和開發(fā)過程的推進，系統(tǒng)相關(guān)人員可能會了解和掌握更多的信息，如客戶真正需要什么？什么方法最好？項目如何實施代價更小等，這些開發(fā)過程中獲取的知識促使軟件不得不發(fā)生變更，而軟件開發(fā)者也只能認可這類變更?；€是軟件配置管理的概念，它幫助我們在不嚴重阻礙合理變化的情況下來控制變化。IEEE(IEEEStd．610.12-1990)定義基線如下：

基線是已經(jīng)通過正式復審和批準的規(guī)格說明或中間產(chǎn)品，它因此可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變化控制過程才能改變。簡單地說，基線是指軟件配置項通過正式復審而進入正式受控的一種狀態(tài)。以軟件需求規(guī)格說明為例，開發(fā)人員可以在需求開發(fā)階段隨時根據(jù)用戶的要求修改該文檔。一旦該文檔通過正式評審形成基線之后，需求變更就必須受到嚴格的控制，原則上是不允許輕易變更的，必須按照規(guī)定的變更控制程序進行申請、評估、修改和驗證。

基線標志著軟件開發(fā)過程的各個里程碑，通常的軟件基線如圖14.4所示，它將軟件開發(fā)各個階段的工作劃分得更加明確，有利于階段成果的檢查和確認。圖14.4軟件基線(里程碑)

2．軟件配置項(SoftwareConfigurationItem，SCI)

軟件配置項定義為部分軟件開發(fā)過程中創(chuàng)建的信息，一個SCI可以是某個大的規(guī)約中的某個單獨段落，或在某個大的測試用例集中的某種測試用例；一個SCI也可以是一個文檔、一個全套的測試用例或一個已命名的程序組件。

軟件配置項是配置控制下的一組相關(guān)程序、文檔或數(shù)據(jù)的集合，包括：

●與合同、過程、計劃和產(chǎn)品有關(guān)的文檔和數(shù)據(jù)。

●源代碼、目標代碼和可執(zhí)行代碼。

●相關(guān)產(chǎn)品，包括軟件工具、庫內(nèi)可復用軟件、外購軟件及用戶提供的軟件。隨著軟件開發(fā)過程的進展，軟件配置項的數(shù)量將會迅速增加，其內(nèi)容也會隨時發(fā)生變化。因此，軟件人員必須盡力保證所有軟件配置項的正確性和一致性。

以下的SCI成為配置管理的目標并成為一組基線：

●系統(tǒng)規(guī)格說明。

●軟件項目計劃。

●軟件需求規(guī)格說明。包括圖形分析模型、處理規(guī)格說明、原型和形式規(guī)格說明等。

●初步的用戶手冊。

●設(shè)計規(guī)格說明。包括數(shù)據(jù)設(shè)計描述、體系結(jié)構(gòu)設(shè)計規(guī)格說明、模塊設(shè)計描述、界面設(shè)計描述、對象描述等?！裨创a清單。

●測試規(guī)格說明。包括測試計劃和過程、測試用例和結(jié)果記錄等。

●操作和安全手冊。

●可執(zhí)行程序。包括模塊的可執(zhí)行代碼、鏈接的模塊等。

●數(shù)據(jù)庫描述。

●聯(lián)機用戶手冊。

●維護文檔。包括軟件問題報告、維護請求、軟件變化指令等。

●軟件工程的標準和規(guī)程。除了上面列出的SCI，很多軟件工程組織也將軟件工具列入配置之中，即特定版本的編輯器、編譯器和其他CASE工具被“固定”作為軟件配置的一部分。因為這些工具被用于生成文檔、源代碼和數(shù)據(jù)，所以當對軟件配置進行改變時，必須要用到它們。雖然問題并不多見，但有可能某些工具的新版(如編輯)會產(chǎn)生和原版本不同的結(jié)果。為此，工具就像它們輔助產(chǎn)生的軟件一樣，可以被基線化，并作為綜合的配置管理過程的一部分。在實現(xiàn)SCM時，應(yīng)把SCI組織成配置對象，在項目數(shù)據(jù)庫中用一個唯一的名字組織它們。一個配置對象有一個名字和一組屬性，并通過某些關(guān)系“連接”到其他對象，如圖14.5所示。

圖14.5中分別對配置對象“設(shè)計規(guī)格說明”、“數(shù)據(jù)模塊”、“模塊N”、“源代碼”和“測試規(guī)格說明”進行了定義，每個對象與其他對象的聯(lián)系用箭頭表示。這些箭頭指名了一種構(gòu)造關(guān)系，即“數(shù)據(jù)模塊”和“模塊N”是“設(shè)計規(guī)格說明”的一部分。雙向箭頭則表明一種相互關(guān)系。如果對“源代碼”對象作了一個變更，軟件工程師就可以根據(jù)這種相互關(guān)系確定哪些對象可能受到影響。圖14.5配置對象14.3.2軟件配置活動

軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，在軟件開發(fā)過程中，其主要任務(wù)是控制軟件的修改，涉及標識軟件配置中各種對象、管理軟件的各種版本、建立系統(tǒng)、控制對軟件的變更和審計配置等活動。

1．標識配置對象

為了控制和管理，所有SCI都應(yīng)按面向?qū)ο蟮姆绞矫⒔M織起來。此時，對象分為基本對象和組合對象?；緦ο笾冈诜治?、設(shè)計、編碼或測試階段由開發(fā)人員創(chuàng)建的某個“文本單元”(UnitofText)，例如，需求說明書中某一節(jié)，某個模塊的源代碼，或按等價分類法制定的一套測試用例；復合對象指由若干基本對象和復合對象組合而成的對象，例如，圖14.5的“設(shè)計規(guī)格說明”即為復合對象，它由“數(shù)據(jù)模塊”和“模塊N”等基本對象組合而成。每個配置對象都擁有名字、描述、資源列表和實際存在體四個部分。對象名一般為字符串；對象描述包括若干數(shù)據(jù)項，它們指明對象的類型(例如文檔、程序或數(shù)據(jù))、所屬工程項目的標志及變動和版本的有關(guān)信息；資源列表給出該對象要求、引用、處理和提供的所有實體，如數(shù)據(jù)類型、特殊函數(shù)等，有時變量也被看做資源；只有基本對象才有實際存在體，它是指向該對象“文本單元”的一個指針，復合對象此項取null值。

除了標識配置外，還必須指明對象之間的關(guān)系。一個對象可標識為另一復合對象的一部分，即此兩對象之間存在一個part-of關(guān)系。若干part-of關(guān)系可定義出對象之間的分層結(jié)構(gòu)。例如：

“E-R圖”(part-of)“數(shù)據(jù)模型”；“E-R圖”為數(shù)據(jù)模型的一部分。

“數(shù)據(jù)模型”(part-of)“設(shè)計規(guī)格說明書”；“數(shù)據(jù)模型”是設(shè)計規(guī)格說明書的一部分。

由此描述出三個對象組成樹狀的層次結(jié)構(gòu)。

因一個配置對象可能與其他多個對象有關(guān)系，所以SCI的分層結(jié)構(gòu)不一定是簡單的樹狀結(jié)構(gòu)，也有可能是網(wǎng)狀結(jié)構(gòu)。此外，在標識對象時還應(yīng)考慮對象隨著開發(fā)過程的深入不斷演化的因素。為此，可為每個對象創(chuàng)建如圖14.6所示的一個進化圖，它概述某對象演化的歷史，圖中每個節(jié)點都是SCI的一個版本。至于開發(fā)人員如何尋找與具體的SCI版本相協(xié)調(diào)的所有相關(guān)的SCI版本，市場部門又怎樣得知哪些顧客有哪些版本，以及怎樣通過選擇合適的SCI版本配置出一個特定的軟件系統(tǒng)等問題，都需要通過有效的標識和版本機制解決。圖14.6進化圖

2．版本控制

理想情況下，每個配置項只需保存一個版本。實際上因為軟件的變更和滿足不同用戶的需求，往往一個項目保存多個版本，并且隨著系統(tǒng)開發(fā)的展開，版本數(shù)目明顯增多。配置管理的版本控制主要解決下列問題：

(1)根據(jù)不同用戶的需要配置不同的系統(tǒng)。

(2)保存系統(tǒng)老版本，為以后系統(tǒng)追蹤時使用。

(3)建立一個系統(tǒng)新版本，使它保留某些決策而舍棄另一些決策。

(4)支持兩位以上工程師同時為一個項目工作。

(5)高效存儲項目的多個版本。

3．變更控制

一個大型軟件開發(fā)過程中，無控制的變更會迅速導致混亂。所謂變更控制，即建立一套機制，有意識地控制軟件的變更，其過程如圖14.7所示。圖14.7變更控制過程

4．配置審計

軟件配置審計作為一種補救措施，主要考慮下列在正式技術(shù)復審中未被考慮的因素：

(1)控制變更指令(ECO)指出的修改是否都已完成？是否另加了哪些修改？

(2)是否做過正式技術(shù)復審?

(3)是否嚴格遵守軟件工程標準？

(4)修改過的SCI是否做了特別標記？修改的日期和執(zhí)行修改的人員是否已經(jīng)注冊？該SCI的屬性是否能夠反映本次修改的結(jié)果？

(5)是否完成與本次修改有關(guān)的注釋、記錄和報告等事宜？

(6)所有相關(guān)的SCI是否已一并修改？

5．配置狀況報告

配置狀況報告(ConfigurationStatusReporting，CSR)作為軟件配置管理的一項任務(wù)，主要概述發(fā)生了什么事情，誰做的，何時發(fā)生的以及有什么影響。

CSR的產(chǎn)生與圖14.7所述過程緊密相關(guān)，當某個SCI被賦予新標記或更新標記時、或