【文章內(nèi)容簡介】 量，當把FP當做估算變量時所需要的分解程度不很詳細。應注意，LOC是直接估算的，而FP是通過估計輸入、輸出、數(shù)據(jù)文件、查詢和外部接口的數(shù)目。 計劃人員可對每一個分解的功能提出一個有代表性的估算值范圍。利用歷史數(shù)據(jù)或憑實際經(jīng)驗，對每個功能分別按最佳的、可能的、悲觀的三種情況給出LOC或FP估計值。記作a、m、b。當這些值的范圍被確定之后，也就隱含地指明了估計值的不確定程度。接著計算LOC或FP的期望值E。 E ＝ （a＋4m＋b）／6 （加權平均） 確定了估算變量的期望值，就可以用作LOC或FP的生產(chǎn)率數(shù)據(jù)。 作為LOC和FP估算技術的一個實例，考察一個為計算機輔助設計（CAD）應用而開發(fā)的軟件包。在這個實例中，使用LOC做為估算變量。 根據(jù)對軟件范圍的敘述，對軟件功能進行分解，識別出主要的幾個功能：用戶界面和控制功，二維幾何分析，三維幾何分析，數(shù)據(jù)庫管理，計算機圖形顯示功能，外設控制以及設計分析模塊。通過下述的分解技術。 估算表功 能a最佳值m可能值b悲觀值E期望值每行成本(元∕行)生產(chǎn)率(行∕PM)成本(元)工作量(PM)用戶接口控制180024002650234014315 32760 二維幾何造型410052007400538020220107600 三維幾何造型460069008600680020220136000 數(shù)據(jù)庫管理295034003600335018240 60300 終端圖形顯示405049006200495022200108900 外部設備控制200021002450214028140 59920 設計分析660085009800840018300151200 總計33360656680 表中給出了LOC的估算范圍。計算出的各功能的期望值放入表中的第4列。然后對該列垂直求和，得到該CAD系統(tǒng)的LOC估算值33360。從歷史數(shù)據(jù)求出生產(chǎn)率度量和每行成本，即行／PM和元／行。在表中的成本和工作量這兩列的值分別用LOC的期望值E與元／行相乘，及用LOC 的期望值E與行／PM相除得到。因此可得，該項目總成本的估算值為657,000元，總工作量的估算值為145人月(PM）。② 工作量估算每一項目任務的解決都需要花費若干人日、人月或人年。每一個工作量單位都對應于一定的貨幣成本，從而可以由此做出成本估算。類似于LOC或FP技術，工作量估算開始于從軟件項目范圍抽出軟件功能。接著給出為實現(xiàn)每一軟件功能所必須執(zhí)行的一系列軟件工程任務，包括需求分析、設計、編碼和測試。計劃人員針對每一軟件功能，估算完成各個軟件工程任務所需要的工作量(如人月)。同時，把勞動費用率(即單位工作量成本)加到每個軟件工程任務上。最后，計算每一個功能及軟件工程任務的工作量和成本。如果工作量估算不依賴LOC或FP估算，那么，就可得到兩組能進行比較和調(diào)和的成本與工作量估算。如果這兩組估算值合理地一致，則估算值是可靠的。如果估算的結果不一致，就有必要做進一步的檢查與分析。 工作量矩陣以上面所介紹的CAD軟件為例，列出它的一個完全的工作量估算表()。表中對每一個軟件功能提供了用人月(PM)表示的每一項軟件工程任務的工作量估算值。橫向和縱向的總計給出所需要的工作量。 工作量估算表需求分析總 計測 試編 碼設 計 任務功能用戶接口控制 二維幾何造型 三維幾何造型 數(shù)據(jù)庫管理 圖形顯示功能 總工作量估算外設控制功能 總成本 估算設計分析功能 總計 費用率(元) 5200 4800 4250 4500成本(元) 75400 292800 112625 227250 708075除特別指出外，工作量都按人月(PM)估算。與每個軟件工程任務相關的勞動費用率記入表中費用率(元)這一行，這些數(shù)據(jù)反映了“負擔”的勞動成本，即包括公司開銷在內(nèi)的勞動成本。如果工作量估算法與LOC估算法所得結果之間的一致性很差，就必須重新確定估算所使用的信息。如果要追尋產(chǎn)生差距的原因，不外乎以下兩個原因之一：167。 計劃人員沒有充分了解或誤解了項目的范圍；167。 用于LOC估算的生產(chǎn)率數(shù)據(jù)不適合于本項目，過時了(即使用這些數(shù)據(jù)不能正確反映軟件開發(fā)機構的情況)，或者是誤用了。計劃人員必須確定產(chǎn)生差距的原因再來協(xié)調(diào)估算結果。 軟件開發(fā)成本估算 軟件開發(fā)成本主要是指軟件開發(fā)過程中所花費的工作量及相應的代價。它不同于其它物理產(chǎn)品的成本，它不包括原材料和能源的消耗，主要是人的勞動的消耗。人的勞動消耗所需代價就是軟件產(chǎn)品的開發(fā)成本。另一方面，軟件產(chǎn)品開發(fā)成本的計算方法不同于其它物理產(chǎn)品成本的計算。軟件產(chǎn)品不存在重復制造過程，它的開發(fā)成本是以一次性開發(fā)過程所花費的代價來計算的。因此軟件開發(fā)成本的估算，應是從軟件計劃、需求分析、設計、編碼、單元測試、組裝測試到確認測試，整個軟件開發(fā)全過程所花費的代價作為依據(jù)的。 (1) 軟件開發(fā)成本估算方法 對于一個大型的軟件項目，要進行一系列的估算處理。主要靠分解和類推的手段進行?；竟浪惴椒ǚ譃槿悺?① 自頂向下的估算方法： 這種方法的主要思想是從項目的整體出發(fā)，進行類推。即估算人員根據(jù)以前已完成項目所消耗的總成本(或總工作量)，來推算將要開發(fā)的軟件的總成本(或總工作量)，然后按比例將它分配到各開發(fā)任務單元中去。 這種方法的優(yōu)點是估算工作量小，速度快。缺點是對項目中的特殊困難估計不足，估算出來的成本盲目性大，有時會遺漏被開發(fā)軟件的某些部分。② 自底向上的估計法：這種方法的主要思想是把待開發(fā)的軟件細分，直到每一個子任務都已經(jīng)明確所需要的開發(fā)工作量，然后把它們加起來，得到軟件開發(fā)的總工作量。這是一種常見的估算方法。它的優(yōu)點是估算各個部分的準確性高。缺點是缺少各項子任務之間相互聯(lián)系所需要的工作量，還缺少許多與軟件開發(fā)有關的系統(tǒng)級工作量（配置管理、質(zhì)量管理、項目管理）。所以往往估算值偏低，必須用其它方法進行檢驗和校正。③ 差別估計法：這種方法綜合了上述兩種方法的優(yōu)點，其主要思想是把待開發(fā)的軟件項目與過去已完成的軟件項目進行類比，從其開發(fā)的各個子任務中區(qū)分出類似的部分和不同的部分。類似的部分按實際量進行計算，不同的部分則采用相應的方法進行估算。這種的方法的優(yōu)點是可以提高估算的準確程度，缺點是不容易明確“類似”的界限。(2) 專家判定技術專家判定技術就是由多位專家進行成本估算。由于單獨一位專家可能會有種種偏見，譬如有樂觀的、悲觀的、要求在競爭中取勝的、讓大家都高興的種種愿望及政治因素等。因此，最好由多位專家進行估算，取得多個估算值。Rand公司提出Deiphi技術，作為統(tǒng)一專家意見的方法。用Deiphi技術可得到極為準確的估算值。Deiphi技術的步驟是：① 組織者發(fā)給每位專家一份軟件系統(tǒng)的規(guī)格說明書（略去名稱和單位） 和一張記錄估算值的表格，請他們進行估算。② 專家詳細研究軟件規(guī)格說明書的內(nèi)容，對該軟件提出三個規(guī)模的估算值，即： ai ── 該軟件可能的最小規(guī)模（最少源代碼行數(shù)）； mi ── 該軟件最可能的規(guī)模（最可能的源代碼行數(shù)）； bi ── 該軟件可能的最大規(guī)模（最多源代碼行數(shù)）。無記名地填寫表格，并說明做此估算的理由。在填表的過程中，專家互相不進行討論但可以向組織者提問。③ 組織者對專家們填在表格中的答復進行整理，做以下事情： a) 計算各位專家（序號為i，i＝1,2,…,n，共n位專家）的估算期望值Ei：，并綜合各位專家估算值的期望中值E： b) 對專家的估算結果進行分類摘要。 ④ 在綜合專家估算結果的基礎上，組織專家再次無記名地填寫表格。 然后比較兩次估算的結果。若差異很大，則要通過查詢找出差異的原因。 ⑤ 上述過程可重復多次。最終可獲得一個得到多數(shù)專家共識的軟件規(guī)模（源代碼行數(shù)）。在此過程中不得進行小組討論。 最后，通過與歷史資料進行類比，根據(jù)過去完成軟件項目的規(guī)模和成本等信息，推算出該軟件每行源代碼所需要的成本。然后再乘以該軟件源代碼行數(shù)的估算值，就可得到該軟件的成本估算值。 此方法的缺點是人們無法利用其他參加者的估算值來調(diào)整自己的估算值。寬帶Deiphi技術克服了這個缺點。在專家正式將估算值填入表格之前，由組織者召集小組會議，專家們與組織者一起對估算問題進行討論，然后專家們再無記名填表。組織者對各位專家在表中填寫的估算值進行綜合和分類后，再召集會議，請專家們對其估算值有很大變動之處進行討論，請專家們重新無記名填表。這樣適當重復幾次，得到比較準確的估計值。 由于增加了協(xié)商的機會，集思廣益，使得估算值更趨于合理。 (3) 軟件開發(fā)成本估算的早期經(jīng)驗模型 軟件開發(fā)成本估算是依據(jù)開發(fā)成本估算模型進行估算的。開發(fā)成本估算模型通常采用經(jīng)驗公式來預測軟件項目計劃所需要的成本、工作量和進度數(shù)據(jù)。還沒有一種估算模型能夠適用于所有的軟件類型和開發(fā)環(huán)境，從這些模型中得到的結果必須慎重使用。 ① IBM模型 1977年，IBM的Walston和Felix提出了如下的估算公式： E ＝ ， L是源代碼行數(shù)(以KLOC計)，E是工作量(以PM計) D ＝ ＝ ， D是項目持續(xù)時間(以月計) S ＝ ， S是人員需要量(以人計) DOC ＝ 49。 DOC是文檔數(shù)量(以頁計)在此模型中，一般指一條機器指令為一行源代碼。一個軟件的源代碼行數(shù)不包括程序注釋、作業(yè)命令、調(diào)試程序在內(nèi)。對于非機器指令編寫的源程序，例如匯編語言或高級語言程序，應轉(zhuǎn)換成機器指令源代碼行數(shù)來考慮。IBM模型是一個靜態(tài)單變量模型，但不是一個通用的公式。 在應用中有時要根據(jù)具體實際情況，對公式中的參數(shù)進行修改。這種修改必須擁有足夠的歷史數(shù)據(jù)，在明確局部的環(huán)境之后才能做出。② Putnam模型這是1978年Putnam提出的模型，是一種動態(tài)多變量模型。它是假定在軟件開發(fā)的整個生存期中工作量有特定的分布。這種模型是依據(jù)在一些大型項目(總工作量達到或超過30個人年)中收集到的工作量分布情況而推導出來的，但也可以應用在一些較小的軟件項目中。Putnam模型可以導出一個“軟件方程”，把已交付的源代碼(源語句)行數(shù)與工作量和開發(fā)時間聯(lián)系起來。其中，td是開發(fā)持續(xù)時間(以年計)，K是軟件開發(fā)與維護在內(nèi)的整個生存期所花費的工作量(以人年計)，L是源代碼行數(shù)(以LOC計)，Ck是技術狀態(tài)常數(shù)，它反映出“妨礙程序員進展的限制”，并因開發(fā)環(huán)境而異。 技術狀態(tài)常數(shù)Ck的取值 Ck的典型值 開發(fā)環(huán)境 開 發(fā) 環(huán) 境 舉 例 2000 差 沒有系統(tǒng)的開發(fā)方法，缺乏文檔和復審，批處理方式。 8000 好 有合適的系統(tǒng)開發(fā)方法，有充分的文檔和復審，交互執(zhí)行方式。 11000 優(yōu) 有自動開發(fā)工具和技術。 (4) COCOMO模型（COnstructive COst MOdel）這是由TRW公司開發(fā)。Boehm提出的結構型成本估算模型。是一種精確、易于使用的成本估算方法。在該模型中使用的基本量有以下幾個：DSI（源指令條數(shù)）定義為代碼或卡片形式的源程序行數(shù)。若一行有兩個語句，則算做一條指令。它包括作業(yè)控制語句和格式語句，但不包括注釋語句。KDSI＝1000DSI。MM（度量單位為人月）表示開發(fā)工作量。TDEV（度量單位為月）表示開發(fā)進度。它由工作量決定。① 軟件開發(fā)項目的分類在COCOMO模型中，考慮開發(fā)環(huán)境，軟件開發(fā)項目的總體類型可分為三種：組織型(Organic)、嵌入型(Embadded)和介于上述兩種軟件之間的半獨立型(Semidetached)。② COCOMO模型的分類COCOMO模型按其詳細程度分成三級：即基本COCOMO模型、中間COCOMO模型、詳細COCOMO模型?；綜OCOMO模型是一個靜態(tài)單變量模型，它用一個以已估算出來的源代碼行數(shù)(LOC)為自變量的(經(jīng)驗)函數(shù)來計算軟件開發(fā)工作量。中間COCOMO模型則在用LOC為自變量的函數(shù)計算軟件開發(fā)工作量(此時稱為名義工作量)的基礎上，再用涉及產(chǎn)品、硬件、人員、項目等方面屬性的影響因素來調(diào)整工作量的估算。詳細COCOMO模型包括中間COCOMO模型的所有特性，但用上述各種影響因素調(diào)整工作量估算時，還要考慮對軟件工程過程中每一步驟(分析、設計等)的影響。③ 基本COCOMO模型。 基本COCOMO模型的工作量和進度公式總體類型工 作 量進 度組 織 型 MM ＝ (KDSI)TDEV＝ (MM)半獨立型 MM ＝ (KDSI)TDEV＝ (MM)嵌 入 型 MM ＝ (KDSI)TDEV＝ (MM)利用上面公式，可求得軟件項目，或分階段求得各軟件任務的開發(fā)工作量和開發(fā)進度。④ 中間COCOMO模型進一步考慮以下15種影響軟件工作量的因素，通過定下乘法因子，修正CO