軟件項(xiàng)目管理第5章軟件項(xiàng)目成本估算 5.1軟件項(xiàng)目估算概述

5.1.1軟件項(xiàng)目估算的概念

估算是建立在客觀事實(shí)上對(duì)未來可能發(fā)生的事情的一種合理性預(yù)測(cè)。估算本身的不確定性決定了估算不可能是百分之百準(zhǔn)確無誤的，但是依據(jù)某種方法進(jìn)行合理估計(jì)顯然比主觀猜測(cè)要好得多。

軟件項(xiàng)目估算是指預(yù)測(cè)構(gòu)造軟件項(xiàng)目所需要的工作量以及任務(wù)經(jīng)歷過程的時(shí)間。主要包括規(guī)模估算、工作量估算、進(jìn)度估算和成本估算四個(gè)主要任務(wù)。規(guī)模估算是指根據(jù)清晰、有界限的用戶需求，估算項(xiàng)目所包含的軟件工程任務(wù)及其規(guī)模。主要估算軟件程序的規(guī)模，即最后交付的程序和文檔的規(guī)模，在此基礎(chǔ)上考慮軟件質(zhì)量控制、軟件測(cè)試和項(xiàng)目管理等非程序規(guī)模因素，將其增加一定比例作為軟件項(xiàng)目規(guī)模，從而為工作量估算提供依據(jù)。

工作量估算是指根據(jù)軟件規(guī)模估算結(jié)果，結(jié)合用戶提出的進(jìn)度要求和項(xiàng)目的其他因素估算軟件開發(fā)所需要的工作時(shí)間。通常以人月、人年、人天、人時(shí)等作為衡量單位。對(duì)軟件項(xiàng)目工作量估算時(shí)需要充分考慮程序的規(guī)模、復(fù)雜度、難度、項(xiàng)目團(tuán)隊(duì)的規(guī)模、素質(zhì)，以及項(xiàng)目管理水平等因素。

進(jìn)度估算是指根據(jù)軟件工作量估算結(jié)果以及用戶提出的進(jìn)度要求，估算實(shí)施一系列軟件工程任務(wù)的持續(xù)時(shí)間，即軟件項(xiàng)目歷時(shí)估計(jì)。進(jìn)度估算涉及人、財(cái)、物等項(xiàng)目資源的分配，形成項(xiàng)目進(jìn)度計(jì)劃，用來跟蹤和溝通項(xiàng)目進(jìn)展?fàn)顟B(tài)，也可跟蹤變更對(duì)項(xiàng)目的影響。

成本估算是根據(jù)軟件規(guī)模及其工作量估算結(jié)果，估算完成該項(xiàng)目要付出的經(jīng)濟(jì)代價(jià)。軟件項(xiàng)目的成本主要體現(xiàn)在人力資源成本上，但也不能忽視資源配置、軟件培訓(xùn)、人員變動(dòng)、進(jìn)度壓縮和進(jìn)度延期等因素產(chǎn)生的其他成本。

工作量估算結(jié)果和進(jìn)度估算結(jié)果對(duì)于組建項(xiàng)目團(tuán)隊(duì)具有重要作用。

圖5.1客戶的需要(除非你很清楚地知道客戶想要什么，否則你很難知道能否在期望的時(shí)間段內(nèi)建造客戶想要的產(chǎn)品)

5.1.2軟件項(xiàng)目估算的意義

軟件項(xiàng)目估算是有效的軟件項(xiàng)目管理必不可少的，沒有比較準(zhǔn)確的估算，軟件項(xiàng)目將不可避免地造成產(chǎn)品性能的損失、軟件成本大幅度增長(zhǎng)、項(xiàng)目的超支、軟件開發(fā)工作處于失控狀態(tài)和進(jìn)度拖期等問題。從上述的案例也可以發(fā)現(xiàn)這里列出的一些問題。

軟件項(xiàng)目估算是制定項(xiàng)目計(jì)劃的基礎(chǔ)和依據(jù)，目的就是為某個(gè)軟件項(xiàng)目的實(shí)施制定一個(gè)較準(zhǔn)確的經(jīng)費(fèi)預(yù)算和進(jìn)度估計(jì)，從而支撐整個(gè)項(xiàng)目在可控的狀態(tài)下按計(jì)劃執(zhí)行，并且能夠?qū)崿F(xiàn)預(yù)期目標(biāo)。除此之外，還能夠?yàn)楹罄m(xù)的軟件度量提供依據(jù)，以便發(fā)現(xiàn)項(xiàng)目實(shí)施中存在的問題，并總結(jié)項(xiàng)目管理和實(shí)施的經(jīng)驗(yàn)與教訓(xùn)，繼而提升軟件開發(fā)企業(yè)的軟件生產(chǎn)能力和軟件項(xiàng)目管理人員的管理水平。值得注意的是：由于軟件自身的抽象性、軟件項(xiàng)目的復(fù)雜性、以往經(jīng)驗(yàn)數(shù)據(jù)的可重復(fù)性、估算工具的缺乏以及人為主觀經(jīng)驗(yàn)的影響，將會(huì)導(dǎo)致軟件項(xiàng)目估算與實(shí)際情況有較大差異。在項(xiàng)目實(shí)施之初，估算有著非常重要的意義，但這一階段的估算有較大的誤差，隨著項(xiàng)目計(jì)劃的逐步落實(shí)，估算結(jié)果會(huì)越來越準(zhǔn)確，但是后期的估算將逐漸失去意義，如圖5.2所示。圖5.2軟件項(xiàng)目估算的意義和精度(估算的意義隨項(xiàng)目的進(jìn)展逐漸減弱，估算的精度則正好相反)因此，軟件項(xiàng)目估算具有以下幾個(gè)特點(diǎn)。

(1)估算是有誤差的。實(shí)踐證明，大多數(shù)項(xiàng)目超過估算25%到100%，但也有少數(shù)的估算準(zhǔn)確到10%以內(nèi)。

(2)經(jīng)驗(yàn)(歷史)數(shù)據(jù)非常重要，這種估算大多是利用以前的代價(jià)和經(jīng)驗(yàn)作為參考而做出的。

(3)估算可以借助估算工具和數(shù)學(xué)模型進(jìn)行，旨在減少人為誤差，但不要過分迷信數(shù)學(xué)模型。

(4)軟件開發(fā)是逐步細(xì)化的過程，估算也是隨項(xiàng)目的進(jìn)行逐步求精的過程，因此項(xiàng)目估算要考慮合適的時(shí)間節(jié)點(diǎn)。5.1.3軟件項(xiàng)目估算的時(shí)機(jī)

基于軟件項(xiàng)目估算的特點(diǎn)，可以將估算工作與軟件產(chǎn)品的生命周期結(jié)合起來，使其既有意義，又有較高的精度。

軟件產(chǎn)品的生命周期可以劃分為問題定義、可行性研究、需求分析、構(gòu)架設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼與測(cè)試和運(yùn)行與維護(hù)等八個(gè)階段。這些階段反映了軟件開發(fā)實(shí)質(zhì)是一個(gè)逐步細(xì)化的過程，在不同階段對(duì)項(xiàng)目進(jìn)行估算，存在著不同程度的誤差(如圖5.3所示)，這種誤差隨著項(xiàng)目的推進(jìn)具有收斂特性，并對(duì)項(xiàng)目實(shí)施能否成功有著重要的影響。圖5.3軟件項(xiàng)目估算的時(shí)機(jī)和收斂曲線(軟件項(xiàng)目估算的時(shí)間越早，誤差越大，意義也越大)圖5.3表明，軟件項(xiàng)目估算要把握6個(gè)不同的時(shí)機(jī)：

粗略估算期ET1：在問題定義階段，對(duì)軟件產(chǎn)品的認(rèn)識(shí)存在著諸多的不確定性，因此成本和進(jìn)度估算的偏差很大，分別達(dá)到±4倍和±1.6倍，此時(shí)的估算只能作為粗略估算，很難成為項(xiàng)目成本和進(jìn)度管理的依據(jù)。

初級(jí)精度估算期ET2：在可行性分析階段，通過研究問題確定是否存在可行的辦法，使得項(xiàng)目的不確定性降低了很多，成本和進(jìn)度估算的偏差分別降至±2倍和±1.25倍，啟動(dòng)或取消項(xiàng)目也能隨之定奪下來。一級(jí)精度估算期ET3：在需求分析階段，進(jìn)一步明確了系統(tǒng)的功能目標(biāo)，通過項(xiàng)目實(shí)施完成需求說明書中描述的功能及其規(guī)格，便會(huì)有比較明確的成本和進(jìn)度，此時(shí)的成本和進(jìn)度估算偏差分別降至±1.5倍和±1.15倍，開發(fā)方可再次權(quán)衡產(chǎn)品實(shí)現(xiàn)的可行性，進(jìn)而決定項(xiàng)目是否繼續(xù)執(zhí)行。

二級(jí)精度估算期ET4：在構(gòu)架設(shè)計(jì)和詳細(xì)設(shè)計(jì)階段，確定了系統(tǒng)實(shí)現(xiàn)的最佳方案及其詳細(xì)計(jì)劃、體系結(jié)構(gòu)、功能模塊及其算法和數(shù)據(jù)結(jié)構(gòu)，成本和進(jìn)度估算更多考慮的是如何將系統(tǒng)開發(fā)完成、后期各階段資源的分配以及相關(guān)的其他細(xì)節(jié)，不確定性因素更少，此時(shí)的成本和進(jìn)度估算具有較高的精度，其偏差分別降至±1.25倍和±1.1倍以下，開發(fā)方一般不會(huì)作出終止項(xiàng)目的決定，他們會(huì)將主要精力投入到更好的管理和實(shí)施項(xiàng)目上來。估算調(diào)整期ET5：在編碼調(diào)試階段，人、財(cái)、物等資源隨著系統(tǒng)實(shí)現(xiàn)工作的推進(jìn)，投入量更加清楚明了，為確保后期工作的順利實(shí)施，需要總結(jié)前面各階段的實(shí)際量，對(duì)成本和進(jìn)度估算進(jìn)行調(diào)整。

估算評(píng)價(jià)期ET6：產(chǎn)品完工、系統(tǒng)投入運(yùn)行之后，前面各階段存在的不確定性都已成為已知量，此時(shí)可以將各階段的估算值與實(shí)際量進(jìn)行比較評(píng)價(jià)，從中獲得項(xiàng)目估算的經(jīng)驗(yàn)教訓(xùn)，有助于提高開發(fā)方管理和實(shí)施軟件項(xiàng)目的能力和水平。

5.1.4軟件項(xiàng)目估算的方法

軟件項(xiàng)目估算根據(jù)不同任務(wù)采用不同的估算方法，如表5-1所示。表5-1軟件項(xiàng)目估算方法5.1.5軟件項(xiàng)目估算的步驟

軟件項(xiàng)目的范圍、時(shí)間和成本是互相制約的，導(dǎo)致規(guī)模估算、工作量估算、進(jìn)度估算和成本估算之間是密切相關(guān)的，因此軟件項(xiàng)目估算首先要確定項(xiàng)目范圍，其估算步驟如圖5.4所示。圖5.4軟件項(xiàng)目估算的步驟(軟件項(xiàng)目估算涉及規(guī)模、工作量、進(jìn)度、成本等方面，它們是密切相關(guān)的，軟件規(guī)模的估算是基礎(chǔ))圖5.4表明，軟件項(xiàng)目估算包括以下四個(gè)步驟。

1.確定軟件項(xiàng)目范圍

通過問題定義、可行性研究和需求分析，確定軟件的功能、性能、約束條件、接口和可靠性，并得到軟件用戶的認(rèn)可。

(1)功能包括：系統(tǒng)將做什么？系統(tǒng)將在何時(shí)做？有幾種操作方式？系統(tǒng)能在何時(shí)、怎樣被改變或增強(qiáng)？

(2)性能包括：對(duì)執(zhí)行速度、響應(yīng)時(shí)間等有無限制？

(3)約束條件包括：系統(tǒng)可占用多少物理空間，有幾種類型的用戶，每種類型用戶的技術(shù)水平怎樣。(4)接口包括：轉(zhuǎn)入(導(dǎo)入)來自一個(gè)或多個(gè)別的系統(tǒng)？轉(zhuǎn)出(導(dǎo)出)至一個(gè)或多個(gè)別的系統(tǒng)？有用于格式化數(shù)據(jù)的規(guī)定的方式嗎？

(5)可靠性包括：系統(tǒng)必須檢測(cè)并隔離故障，失敗間隔的平均時(shí)間規(guī)定為多少，對(duì)一次失敗后重啟系統(tǒng)的最大時(shí)間。

2.確定項(xiàng)目的資源需求

如何配置人力資源和環(huán)境資源對(duì)軟件項(xiàng)目的進(jìn)度和成本估算有著非常重要的影響。

項(xiàng)目團(tuán)隊(duì)的規(guī)模和素質(zhì)關(guān)系到開發(fā)方能否以最高的效率和最小的成本完成既定任務(wù)和目標(biāo)，不同水平和責(zé)任心的項(xiàng)目組成員完成同一任務(wù)所需的時(shí)間和質(zhì)量有著明顯的差異，所以確定項(xiàng)目可用的人力資源時(shí)，需要考慮軟件系統(tǒng)的復(fù)雜性、技術(shù)的難易度、用戶對(duì)進(jìn)度的要求和項(xiàng)目經(jīng)費(fèi)的支撐能力等因素。軟件項(xiàng)目的實(shí)施離不開軟硬件的支撐，例如操作系統(tǒng)、計(jì)算機(jī)/服務(wù)器、數(shù)據(jù)庫系統(tǒng)和開發(fā)工具等，也需要舒適的辦公環(huán)境和人性化的管理制度，因此合理規(guī)劃軟件開發(fā)所需的環(huán)境資源，有利于保障項(xiàng)目在有限經(jīng)費(fèi)的支撐下高效推進(jìn)。

3.估算規(guī)模和工作量

采用WBS，確定和說明項(xiàng)目包含的工作(任務(wù))，然后借助軟件生產(chǎn)率將其轉(zhuǎn)化為工作量，為下一步估算進(jìn)度和成本提供依據(jù)。

軟件生產(chǎn)率是指軟件規(guī)模與軟件工作量的比值。一般用代碼行/人月、功能點(diǎn)/人月來表示。

4.估算進(jìn)度和成本

以工作量估算結(jié)果為主要輸入，綜合考慮軟件用戶的要求和開發(fā)方的軟件生產(chǎn)能力等其他因素，估算項(xiàng)目的進(jìn)度和成本。完成某一工作量的時(shí)間越短，成本將越是大幅度增加，所以進(jìn)度和成本估算要密切結(jié)合起來進(jìn)行，充分考慮二者之間相互制約、相互影響的一些關(guān)鍵因素。 5.2軟件項(xiàng)目規(guī)模估算

5.2.1軟件生產(chǎn)率

軟件生產(chǎn)率是指人均每月能生產(chǎn)的有效源代碼行數(shù)。

軟件生產(chǎn)率的計(jì)算通常比較困難，不僅要考慮編碼階段，還應(yīng)該包括軟件生存期的各個(gè)階段，同時(shí)要考慮人、問題、過程和環(huán)境等因素的影響。

1.人的因素影響

開發(fā)機(jī)構(gòu)的規(guī)模和經(jīng)驗(yàn)關(guān)乎軟件項(xiàng)目以何種組織形式開展工作，以及組織內(nèi)成員之間交流溝通的方式和路徑數(shù)量。而且通信路徑的多少對(duì)軟件生產(chǎn)率的影響不容忽視。假設(shè)機(jī)構(gòu)內(nèi)缺乏經(jīng)驗(yàn)多、技術(shù)好、能力強(qiáng)的主程序員，項(xiàng)目的組織形式恐怕要采用民主制小組的形式，當(dāng)開發(fā)小組有n個(gè)人時(shí)，總的通信路徑需要n×(n－1)/2條，且聯(lián)接每個(gè)人的通信路徑都是n－1條。

假設(shè)一個(gè)程序員正常情況下獨(dú)立開發(fā)軟件的生產(chǎn)率為L(zhǎng)代碼行/人月，當(dāng)n個(gè)人組成一個(gè)小組共同開發(fā)且耗費(fèi)在每條通信路徑上的工作量相當(dāng)于每人月編寫LC行源代碼時(shí)，組內(nèi)每個(gè)成員的軟件生產(chǎn)率就會(huì)降低為：

L－[n×(n－1)/2]×LC假定L為500行/人月、LC為25行/人月，在以下幾種情況下，觀察軟件生產(chǎn)率的變化幅度：

若一個(gè)人單獨(dú)開發(fā)(即n=1)，則每個(gè)成員的軟件生產(chǎn)率為500行/人月；

若二個(gè)人共同開發(fā)(即n=2)，則每個(gè)成員的軟件生產(chǎn)率降為475行/人月；

若三個(gè)人共同開發(fā)(即n=3)，則每個(gè)成員的軟件生產(chǎn)率降為425行/人月；

若四個(gè)人共同開發(fā)(即n=4)，則每個(gè)成員的軟件生產(chǎn)率降為350行/人月；

若五個(gè)人共同開發(fā)(即n=5)，則每個(gè)成員的軟件生產(chǎn)率降為250行/人月；由此可見，采用民主制小組的組織形式開發(fā)軟件，由一個(gè)人單獨(dú)開發(fā)的生產(chǎn)率最高；通過多人共同開發(fā)必然降低每個(gè)人的軟件生產(chǎn)率，而且人數(shù)越多、總的通信路徑越多，個(gè)體的軟件生產(chǎn)率就會(huì)越低。所以擁有豐富開發(fā)經(jīng)驗(yàn)的、成熟的開發(fā)機(jī)構(gòu)必然有較高的生產(chǎn)率。

歷史經(jīng)驗(yàn)證明，開發(fā)機(jī)構(gòu)中最優(yōu)秀的開發(fā)人員和新入職的人員相比，其生產(chǎn)率比值接近10∶1；最優(yōu)秀的開發(fā)人員和平均水平的人員相比，比例接近2.5∶1；可見，要提高開發(fā)機(jī)構(gòu)的軟件生產(chǎn)率，聘用和培養(yǎng)優(yōu)秀人才是一個(gè)永恒的主題。

2.問題因素影響

軟件系統(tǒng)試圖解決的問題常常涉及不可避免的復(fù)雜性，其功能需求已經(jīng)很難理解，再加上一些隱含的非功能需求，使得用戶很難用開發(fā)者能夠理解的形式對(duì)自己的需求給出準(zhǔn)確的描述，具備不同領(lǐng)域知識(shí)背景的用戶和開發(fā)者之間關(guān)于問題的溝通變得很困難。

另外，隨著軟件開發(fā)過程的推進(jìn)，用戶和開發(fā)者對(duì)問題的理解比項(xiàng)目初期更加清晰、準(zhǔn)確，但系統(tǒng)演化本身改變了問題的規(guī)則，導(dǎo)致需求變更頻繁發(fā)生，相當(dāng)一部分資源被迫用在了應(yīng)對(duì)需求變化和修復(fù)以前的錯(cuò)誤上。

3.過程因素影響

使用結(jié)構(gòu)化方法和面向?qū)ο?OO)方法進(jìn)行軟件分析和設(shè)計(jì)時(shí)，選擇不同的程序設(shè)計(jì)語言以及評(píng)審的過程會(huì)對(duì)軟件開發(fā)的效率有較大的差異。通常面向?qū)ο蠓椒ㄩ_發(fā)軟件的生產(chǎn)率明顯高于結(jié)構(gòu)化方法。

面向?qū)ο蟮姆治雠c設(shè)計(jì)方法有利于開發(fā)人員和用戶之間的交流，有助于使有關(guān)開發(fā)人員與用戶從一開始就考慮程序的易理解性、易維護(hù)性及軟件質(zhì)量等因素，便于快速開發(fā)大型軟件系統(tǒng)，也便于開發(fā)小組人員之間的合作，避免重復(fù)工作。

4.環(huán)境因素影響

軟件開發(fā)工具是軟件開發(fā)過程中必不可少的部分，是用于輔助軟件生命周期過程的基于計(jì)算機(jī)系統(tǒng)的工具，用來支持特定的軟件工程方法，協(xié)助開發(fā)人員開展需求、分析、設(shè)計(jì)、測(cè)試、維護(hù)、模擬、移植或管理等工作。

軟件開發(fā)工具對(duì)設(shè)計(jì)模式、對(duì)象結(jié)構(gòu)以及管理的支撐情況不同，在減少人工負(fù)擔(dān)、提高軟件生產(chǎn)率和軟件質(zhì)量方面的能力就會(huì)存在較大差異。

一個(gè)軟件開發(fā)機(jī)構(gòu)根據(jù)歷史數(shù)據(jù)獲取近期的軟件生產(chǎn)率，才能弄清自己的軟件開發(fā)能力，繼而對(duì)新項(xiàng)目做出盡可能客觀、合理的估算。建議按照以下步驟獲取軟件生產(chǎn)率的估算值：

從規(guī)模、程序設(shè)計(jì)語言、應(yīng)用領(lǐng)域、開發(fā)經(jīng)驗(yàn)等方面對(duì)比分析新項(xiàng)目和已完成的項(xiàng)目，選擇與新項(xiàng)目相似度較高的最近完成的一些項(xiàng)目；

提取選中項(xiàng)目的規(guī)模數(shù)據(jù)和人員數(shù)據(jù)；

針對(duì)每個(gè)選中項(xiàng)目分別計(jì)算其軟件生產(chǎn)率；

計(jì)算所有選中項(xiàng)目的平均生產(chǎn)率，并作為新項(xiàng)目軟件生產(chǎn)率的估算值。5.2.2LOC估算法

LOC(LinesofCode，代碼行)估算法是一種衡量軟件項(xiàng)目規(guī)模的最常用方法。

LOC是指所有的可執(zhí)行的源代碼行數(shù)，包括可交付的工作控制語言語句、數(shù)據(jù)定義、數(shù)據(jù)類型聲明、等價(jià)聲明和輸入/輸出格式聲明等。

LOC是從程序員的角度、通過測(cè)量軟件產(chǎn)品源代碼的行數(shù)來估算軟件規(guī)模的方法，因此在早期的系統(tǒng)開發(fā)中較為廣泛使用。如果把代碼行分為兩類，即NCLOC(Non-CommentedSourceLinesOfCode，無注釋的源代碼行)和CLOC(CommentedSourceLinesOfCode，注釋的源代碼行)，那么源代碼行數(shù)如下：

(5-1)

式中：LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；

LNCLOC表示無注釋的源代碼行數(shù)，單位：千行源代碼(KLOC)；

LCLOC表示注釋的源代碼行數(shù)，單位：千行源代碼(KLOC)。通常用KLOC(thousandsLinesOfCode，千行源代碼)作為代碼行估算結(jié)果的單位，也有用SLOC(SingleofLinesOfCode，行源代碼)表示的。

用代碼行數(shù)不僅能度量軟件的規(guī)模，而且可以度量軟件開發(fā)的工作量。

如果開發(fā)團(tuán)隊(duì)根據(jù)相關(guān)歷史項(xiàng)目的經(jīng)驗(yàn)數(shù)據(jù)獲知該組織的軟件生產(chǎn)率，就可以在估算出軟件規(guī)模之后，進(jìn)一步估算軟件開發(fā)的工作量，其計(jì)算公式如下：

(5-2)

式中：E表示軟件開發(fā)工作量，單位：人月(PM)；

LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；

PS表示軟件生產(chǎn)率，單位：千行源代碼/人月(KLOC/PM)。開發(fā)團(tuán)隊(duì)可以根據(jù)對(duì)歷史項(xiàng)目的審計(jì)來核算開發(fā)團(tuán)隊(duì)的軟件生產(chǎn)率、單行代碼的平均成本和千行代碼出錯(cuò)率等。人月均代碼行數(shù)和每行代碼的平均成本可以體現(xiàn)一個(gè)軟件開發(fā)團(tuán)隊(duì)的生產(chǎn)能力。

由公式5-2可得軟件生產(chǎn)率估算公式如下：

(5-3)

式中：PS表示軟件生產(chǎn)率，單位：千行源代碼/人月(KLOC/PM)；

LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；

E表示軟件開發(fā)工作量，單位：人月(PM)。單行代碼的平均成本(行均成本)估算公式如下：

(5-4)

式中：CL表示單行代碼的平均成本，單位：元/行源代碼(元/SLOC)或(美元/SLOC)；

CT表示軟件的總成本，單位：元或美元；

LC表示軟件代碼行數(shù)，單位：行源代碼(SLOC)。

軟件總成本可用如下公式估算：

(5-5)

式中：CT表示軟件的總成本，單位：元或美元；

CPM表示每人月的成本，單位：元或美元；

E表示軟件開發(fā)工作量，單位：人月(PM)。千行源代碼的文檔頁數(shù)(文檔代碼比)計(jì)算公式如下：

(5-6)

式中：DKL表示千行源代碼的文檔頁數(shù)，單位：頁/千行源代碼(頁/KLOC)；

ND表示軟件文檔的規(guī)模，單位：頁；

LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)。千行源代碼的平均錯(cuò)誤數(shù)(軟件程序的錯(cuò)誤率)計(jì)算公式如下：

(5-7)

式中：QKL表示千行源代碼的平均錯(cuò)誤數(shù)，單位：個(gè)/千行源代碼(個(gè)/KLOC)；

NE表示軟件中出現(xiàn)的錯(cuò)誤數(shù)量，單位：個(gè)；

LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)。

根據(jù)公式(5-1)～公式(5-7)，得到基于LOC估算的相關(guān)指標(biāo)，表5-2是sp001、sp002、sp003三個(gè)項(xiàng)目的運(yùn)行結(jié)果。表5-2LOC估算的各種指標(biāo)由表5-2可以看出，軟件開發(fā)工作量、總成本和文檔規(guī)模通常與代碼行數(shù)成正比，但行均成本、文檔代碼比和錯(cuò)誤率不一定遵循這個(gè)規(guī)律，尤其是文檔代碼比和錯(cuò)誤率表現(xiàn)最為明顯。Sp002的文檔代碼比和錯(cuò)誤率都比sp003的小正好說明了這一點(diǎn)。

由此可見：LOC估算法的缺點(diǎn)在于代碼行數(shù)的含糊不清，不能正確反映一項(xiàng)工作的難易程度以及代碼的效率，難以正確反映軟件的最終質(zhì)量；另外在開發(fā)初期估算代碼行比較困難，適用于過程式程序設(shè)計(jì)語言。

但是，LOC估算法具有計(jì)算方便、估算軟件的規(guī)模相對(duì)簡(jiǎn)單、容易監(jiān)控和能反映程序員的思維能力等優(yōu)點(diǎn)，因此業(yè)界一直廣泛使用。5.2.3FP估算法

FP(FunctionPoints，功能點(diǎn))估算法是一種相對(duì)抽象的方法，是一種人為設(shè)計(jì)的估算方式。FP估算法從系統(tǒng)的復(fù)雜性和系統(tǒng)的特性來估算系統(tǒng)的規(guī)模，關(guān)注程序的“功能性”和“實(shí)用性”，并從用戶的角度來估算軟件規(guī)模，與開發(fā)語言無關(guān)，是對(duì)軟件和軟件開發(fā)過程的間接估算。

FP最初是由IBM的工程師艾倫·艾爾布策(AllanAlbrech)于20世紀(jì)70年代提出的，隨后被國際功能點(diǎn)用戶組(TheInternationalFunctionPointUsers'Group)提出的IFPUG方法繼承，是目前國際上常見的軟件規(guī)模估算方法。

功能點(diǎn)估算法的核心是利用軟件信息域中的一些計(jì)數(shù)估算和軟件復(fù)雜性估計(jì)的經(jīng)驗(yàn)關(guān)系式而導(dǎo)出功能點(diǎn)FP。使用FP方法估算軟件的功能點(diǎn)數(shù)一般要經(jīng)過以下步驟：

(1)識(shí)別功能點(diǎn)的類型；

(2)識(shí)別待估算應(yīng)用程序的邊界和范圍；

(3)計(jì)算數(shù)據(jù)類型功能點(diǎn)所提供的未調(diào)整的功能點(diǎn)數(shù)；

(4)計(jì)算人機(jī)交互功能所提供的未調(diào)整的功能點(diǎn)數(shù)；

(5)確定調(diào)整因子；

(6)計(jì)算調(diào)整后的功能點(diǎn)數(shù)。

1.功能點(diǎn)估算法的基本要素

FP將軟件的功能分為5個(gè)基本要素，其含義及特征如表5-3所示。表5-3FP的5個(gè)基本要素1)?EI的計(jì)算規(guī)則

①從應(yīng)用邊界之外收到數(shù)據(jù)。

②如果進(jìn)入系統(tǒng)邊界內(nèi)的數(shù)據(jù)不是一個(gè)改變系統(tǒng)行為的控制信息，那么至少一個(gè)ILF應(yīng)該被改變。

③對(duì)于已識(shí)別的處理過程，至少滿足下面三個(gè)條件之一:

該基本處理過程(ElementaryProcess)的邏輯與本應(yīng)用系統(tǒng)中其它基本處理過程的邏輯不同。該基本處理過程應(yīng)該具有唯一性。例如不能存在兩個(gè)完全一模一樣的存盤操作。

在應(yīng)用程序邊界內(nèi)，該基本處理過程所使用的這組數(shù)據(jù)應(yīng)該與其他基本處理過程所使用的數(shù)據(jù)不同。

在應(yīng)用程序邊界內(nèi)，基本處理過程所引用的ILF或EIF是不同于其它基本處理過程所引用的ILF或EIF的。2)?EO和EQ通用計(jì)算規(guī)則

必須全部滿足以下內(nèi)容才能被視為一個(gè)EO或EQ：

①從外部發(fā)送數(shù)據(jù)或控制信息到應(yīng)用程序邊界內(nèi)。

②為了識(shí)別這個(gè)過程，以下三點(diǎn)必須滿足一個(gè)：

該基本處理過程邏輯上必須是唯一的，該唯一性是指其在應(yīng)用程序中與其他EO或EQ的邏輯性上保持唯一。

該基本處理過程所使用的數(shù)據(jù)應(yīng)該是唯一的，該唯一性是指其在應(yīng)用程序中與其他EO或EQ所使用的數(shù)據(jù)不同。

該基本處理過程所引用的ILF或EIF文件應(yīng)該是唯一的，該唯一性是指其在應(yīng)用程序中與其他EO或EQ所引用的ILF或EIF文件不同。3)?EO補(bǔ)充的計(jì)算規(guī)則

除了要滿足上面的通用規(guī)則外，還要滿足下面其中一條：

在基本操作過程中至少包含一個(gè)數(shù)學(xué)公式或計(jì)算方法；

在基本操作過程中要產(chǎn)生派生數(shù)據(jù)；

在基本操作過程中至少要維護(hù)一個(gè)ILF；

在基本操作過程中要改變系統(tǒng)的行為。

4)?EQ補(bǔ)充的計(jì)算規(guī)則

除了要滿足上面的通用規(guī)則外，還要滿足下面其中一條：

基本操作過程從ILF或EIF中獲取數(shù)據(jù)；

基本操作過程不能包含數(shù)學(xué)公式或計(jì)算方法；

基本操作過程不能生成派生數(shù)據(jù)；

基本操作過程不能維護(hù)任何一個(gè)ILF；

基本操作過程不能改變系統(tǒng)的行為。5)?EIF遵循的規(guī)則

①從用戶角度出發(fā)識(shí)別的一組邏輯數(shù)據(jù)；

②這組數(shù)據(jù)是在應(yīng)用程序外部，并被應(yīng)用程序引用的；

③計(jì)算功能點(diǎn)的這個(gè)應(yīng)用程序并不維護(hù)該EIF；

④這組數(shù)據(jù)是作為另一個(gè)應(yīng)用程序中的ILF被維護(hù)的。

6)?EI、EO和EQ的區(qū)別和聯(lián)系

EO和EQ有著相同的主要目的，即是通過基本操作過程展現(xiàn)數(shù)據(jù)給用戶看。表示人機(jī)交互事務(wù)類型的三類功能點(diǎn)EI、EO和EQ的主要目的對(duì)比如表5-4所示，它們的主要行為對(duì)比如表5-5所示。表5-4EI、EO和EQ的主要目的對(duì)比表5-5EI、EO和EQ的主要行為對(duì)比

2.功能點(diǎn)估算法的計(jì)算方法

項(xiàng)目的功能點(diǎn)數(shù)是幾個(gè)測(cè)量參數(shù)(用戶輸入數(shù)、用戶輸出數(shù)、用戶查詢數(shù)、文件數(shù)和外部接口數(shù))的功能點(diǎn)之和。

用戶輸入數(shù)：計(jì)算每個(gè)用戶輸入，它們向軟件提供面向應(yīng)用的數(shù)據(jù)。輸入應(yīng)該與查詢區(qū)分開來分別計(jì)算。

用戶輸出數(shù)：計(jì)算每個(gè)用戶輸出，它們向軟件提供面向應(yīng)用的信息。這里輸出是指報(bào)表、屏幕和出錯(cuò)信息等，一個(gè)報(bào)表中的單個(gè)數(shù)據(jù)項(xiàng)不單獨(dú)計(jì)算。

用戶查詢數(shù)：一個(gè)查詢被定義為一次聯(lián)機(jī)輸入，它導(dǎo)致軟件以聯(lián)機(jī)輸出的方式產(chǎn)生實(shí)時(shí)的響應(yīng)。每個(gè)不同的查詢都要計(jì)算。內(nèi)部邏輯文件數(shù)：計(jì)算每個(gè)邏輯的主文件(如數(shù)據(jù)的一個(gè)邏輯組合，可能是某個(gè)大型數(shù)據(jù)庫的一部分或是一個(gè)獨(dú)立的文件)。

外部接口數(shù)：計(jì)算所有機(jī)器可讀的接口(如磁帶或磁盤上的數(shù)據(jù)文件)，利用這些接口可以將信息從一個(gè)系統(tǒng)傳送到另一個(gè)系統(tǒng)。

歸納起來，F(xiàn)P方法的計(jì)算公式如下：

(5-8)

式中：UFC表示未調(diào)整的功能點(diǎn)數(shù)(UnadjustedFunctionPointCount)；

TCF表示技術(shù)復(fù)雜度因子(TechnicalComplexityFactor)。1)?UFC的計(jì)算

估算每類功能項(xiàng)的數(shù)量FPij之后，根據(jù)待開發(fā)軟件的特點(diǎn)評(píng)估各類功能的復(fù)雜性，通常分為簡(jiǎn)單、一般和復(fù)雜三個(gè)等級(jí)，并且用復(fù)雜度權(quán)重Wij來量化(如表5-6所示)，將二者相乘，最后把每類功能項(xiàng)的加權(quán)結(jié)果逐一累加起來，便可得到項(xiàng)目未調(diào)整的功能點(diǎn)數(shù)，UFC的估算公式如下：(5-9)表5-6功能點(diǎn)的復(fù)雜度權(quán)重需要說明的是，表5-6給出的功能點(diǎn)復(fù)雜度權(quán)重是通過使用者自行擬定一些準(zhǔn)則來確定的一個(gè)系數(shù)，帶有一定的主觀性。

假設(shè)估算人員對(duì)項(xiàng)目X進(jìn)行分析研究之后識(shí)別的功能數(shù)如表5-7所示。表5-7X項(xiàng)目中識(shí)別的功能數(shù)那么X項(xiàng)目的未調(diào)整功能點(diǎn)數(shù)可用公式5-9計(jì)算如下：

UFC=(5×3)+(2×4)+(2×6)+(6×4)+(6×5)+(0×7)

+(0×3)+(2×4)+(4×6)+(4×7)+(2×10)+(2×15)

+(8×5)+(0×7)+(2×10)

?=257個(gè)

如果不考慮功能項(xiàng)的復(fù)雜度，那么表5-7中識(shí)別的功能數(shù)是45(即5+2+2+6+6+0+0+2+4+4+2+2+8+0+2)個(gè)，與考慮了復(fù)雜度后估算出來的257個(gè)相比，存在很大的差距。過于簡(jiǎn)單的方法使得估算可能很容易，但是給項(xiàng)目實(shí)施埋下的隱患將不可低估，例如由此導(dǎo)致的進(jìn)度估算遠(yuǎn)遠(yuǎn)不夠、人力資源調(diào)配不合理、項(xiàng)目經(jīng)費(fèi)根本難以支撐到成功的那一刻，最壞的情況是項(xiàng)目最終以失敗而告終。所以依據(jù)功能點(diǎn)估算時(shí)，不僅要識(shí)別各類功能項(xiàng)的數(shù)量，更要對(duì)各功能項(xiàng)的復(fù)雜度做出盡可能正確的判斷。

·EIF和ILF的復(fù)雜度判斷

EIF和ILF的復(fù)雜性取決于記錄單元類型(RecordElementType，RET)和數(shù)據(jù)單元類型(DataElementType，DET)的數(shù)量。

RET是指一個(gè)EIF/ILF中用戶可以識(shí)別的DET的集合。如果把DET簡(jiǎn)單理解為字段的話，那RET就可以簡(jiǎn)單理解為數(shù)據(jù)庫中的表。RET在ILF/EIF中分為兩種類型：可選的(Optional)和必選的(Mandatory)。DET是一個(gè)以用戶角度識(shí)別的、非重復(fù)的、有業(yè)務(wù)邏輯意義的字段。

RET計(jì)算的規(guī)則：

①在一個(gè)ILF/EIF中每個(gè)可選或必選的集合都被計(jì)算為一個(gè)RET；

②如果一個(gè)ILF/EIF沒有子集，則ILF/EIF被計(jì)算為一個(gè)RET。DET計(jì)算的規(guī)則：

①通過一個(gè)基本處理過程的執(zhí)行，對(duì)ILF進(jìn)行維護(hù)或從ILF/EIF中返回一個(gè)特定的、用戶可識(shí)別的、非重復(fù)的字段，那么每個(gè)這樣的字段算一個(gè)DET；

②當(dāng)兩個(gè)應(yīng)用程序維護(hù)和/或引用相同的ILF/EIF，但是每個(gè)應(yīng)用程序分別維護(hù)/引用它們相應(yīng)的DET時(shí)，這些DET在這兩個(gè)應(yīng)用程序的維護(hù)或引用中將單獨(dú)計(jì)算。

ILF/EIF復(fù)雜度的判定矩陣如表5-8所示。表5-8ILF/EIF復(fù)雜度的判定矩陣·EI、EO和EQ的復(fù)雜度判斷

EI、EO、EQ的復(fù)雜性取決于文件引用類型(FileTypeReferenced，F(xiàn)TR)和DET的數(shù)量。

FTR是被一個(gè)事務(wù)操作讀取或維護(hù)的一個(gè)ILF，或是被一個(gè)事務(wù)操作讀取的一個(gè)EIF。

EI中識(shí)別FTR的規(guī)則：

①每個(gè)ILF應(yīng)該算做一個(gè)FTR；

②通過EI讀取操作的每個(gè)ILF或EIF都應(yīng)該被計(jì)算為一個(gè)FTR；

③既被EI維護(hù)又被讀取的ILF僅計(jì)算一個(gè)FTR。EI中識(shí)別DET的規(guī)則：

①在EI的過程中，以用戶角度識(shí)別的、通過應(yīng)用系統(tǒng)邊界輸入系統(tǒng)內(nèi)部非重復(fù)的字段，那么該字段應(yīng)算一個(gè)DET；

②如果在EI過程中，只要沒有通過系統(tǒng)邊界輸入，就算它存在于系統(tǒng)內(nèi)的一個(gè)ILF中，也不能算為一個(gè)DET；

③在應(yīng)用程序的EI操作時(shí)，系統(tǒng)提示的錯(cuò)誤信息或完成操作的信息，應(yīng)該被分別計(jì)算為一個(gè)DET。

④在EI操作中如果遇到主外鍵的字段，應(yīng)該算作一個(gè)DET。

EI復(fù)雜度的判定矩陣如表5-9所示。表5-9EI復(fù)雜度的判定矩陣EO和EQ計(jì)算FTR的通用規(guī)則：

每個(gè)在EO/EQ處理過程中讀取的ILF和EIF算一個(gè)FTR。

EO額外的FTR計(jì)算規(guī)則：

①在EO處理過程中每個(gè)被維護(hù)的ILF算一個(gè)FTR；

②在EO處理過程中即被讀取又被維護(hù)的ILF算一個(gè)FTR。

EO和EQ計(jì)算DET的通用規(guī)則：

①用戶可識(shí)別的非重復(fù)的字段，進(jìn)入應(yīng)用邊界并且指明處理什么，何時(shí)處理或處理方式，并且由EO/EQ返回或產(chǎn)生，那么這樣的每個(gè)字段算一個(gè)DET；

②在應(yīng)用邊界內(nèi)以用戶角度識(shí)別的非重復(fù)字段算一個(gè)DET；③在EO或者EQ操作中如果對(duì)系統(tǒng)進(jìn)行輸入或讀取操作時(shí)，相同的字段只計(jì)算一個(gè)DET；

④在應(yīng)用程序的EO或EQ操作時(shí)，系統(tǒng)提示的錯(cuò)誤信息或完成操作的信息，應(yīng)該被計(jì)算為DET；

⑤在EO或EQ操作中如果遇到主外鍵的字段，應(yīng)該算作一個(gè)DET；

⑥如果在EO或EQ過程中，只要沒有通過系統(tǒng)邊界輸入，就算它存在于系統(tǒng)內(nèi)的一個(gè)ILF中，也不能算為一個(gè)DET；

⑦頁面的標(biāo)題等類似的信息不計(jì)算DET；

⑧系統(tǒng)字段生成的記號(hào)不能被算作一個(gè)DET。

EO、EQ復(fù)雜度的判定矩陣如表5-10所示。表5-10EO、EQ復(fù)雜度的判定矩陣采用FP方法估算軟件規(guī)模時(shí)，除了識(shí)別功能點(diǎn)數(shù)量和判定其復(fù)雜性，還需要根據(jù)項(xiàng)目具體情況，分析其運(yùn)行環(huán)境，關(guān)注系統(tǒng)特性及其影響程度，進(jìn)一步通過技術(shù)復(fù)雜度因子TCF對(duì)估算出來的UCF進(jìn)行調(diào)整。

2)用TCF調(diào)整UFC

技術(shù)復(fù)雜度包括性能復(fù)雜度、配置項(xiàng)目復(fù)雜度、數(shù)據(jù)通信復(fù)雜度、分布式處理復(fù)雜度和在線升級(jí)復(fù)雜度等因素，具體表現(xiàn)為14個(gè)系統(tǒng)常規(guī)特性，并將它們對(duì)系統(tǒng)的影響程度分為5個(gè)等級(jí)：0表示沒有影響，1表示偶然影響，2表示適度影響，3表示一般影響，4表示重要影響，5表示強(qiáng)烈影響。技術(shù)復(fù)雜度因子的組成如表5-11所示。表5-11技術(shù)復(fù)雜度因子的組成F1～F14是復(fù)雜性校正值，它們應(yīng)通過逐一回答相應(yīng)的提問來確定。

F1數(shù)據(jù)通信指的是應(yīng)用程序直接與處理器通信的程度，通常都是通過某種通信手段來實(shí)現(xiàn)在一個(gè)應(yīng)用中所使用的數(shù)據(jù)或控制信息的。連接到本地控制器上的終端被認(rèn)為是使用通信設(shè)施，而協(xié)議指的是兩個(gè)系統(tǒng)或兩個(gè)設(shè)備之間進(jìn)行通信時(shí)所使用的一種約定。所有的數(shù)據(jù)通信鏈接都需要某種協(xié)議。數(shù)據(jù)通信因子取值參考如表5-12所示。表5-12問題：系統(tǒng)是否需要數(shù)據(jù)通信？F2分布式數(shù)據(jù)處理是應(yīng)用在內(nèi)部組件之間傳遞信息的程度。這個(gè)特性是在應(yīng)用邊界內(nèi)體現(xiàn)的。分布式數(shù)據(jù)處理因子取值如表5-13所示。表5-13問題：系統(tǒng)是否需要分布式處理功能？F3性能指的是吞吐量、處理時(shí)間等指標(biāo)對(duì)開發(fā)的影響。用戶所提出的性能要求將直接影響到系統(tǒng)的設(shè)計(jì)、實(shí)施、安裝和支持。性能因子取值如表5-14所示。表5-14問題：系統(tǒng)性能是否很關(guān)鍵？F4大業(yè)務(wù)量配置指的是計(jì)算機(jī)的資源對(duì)應(yīng)用開發(fā)的影響程度。大業(yè)務(wù)量的運(yùn)行配置對(duì)設(shè)計(jì)有特殊要求，是必須考慮的一個(gè)系統(tǒng)特性。大業(yè)務(wù)量配置因子取值如表5-15所示。表5-15問題：系統(tǒng)是否需要高強(qiáng)度配置？F5聯(lián)機(jī)數(shù)據(jù)輸入是指數(shù)據(jù)通過交互方式輸入系統(tǒng)的程度。系統(tǒng)中包括聯(lián)機(jī)數(shù)據(jù)輸入和控制信息功能。聯(lián)機(jī)數(shù)據(jù)輸入因子取值如表5-16所示。表5-16問題：數(shù)據(jù)通過交互方式輸入系統(tǒng)的程度如何？F6易操作性指的是應(yīng)用對(duì)運(yùn)行的影響程度，如對(duì)有效啟動(dòng)、備份和恢復(fù)規(guī)程的影響。易操作性是應(yīng)用提供的一種特性，最小化了手工操作的要求。易操作性因子取值如表5-17所示。表5-17問題：系統(tǒng)是否在一個(gè)已有的、很實(shí)用的操作環(huán)境中運(yùn)行？F7在線升級(jí)是指內(nèi)部邏輯文件ILF被在線更新的程度。應(yīng)用系統(tǒng)提供在線更新內(nèi)部邏輯文件的功能。在線升級(jí)因子取值如表5-18所示。表5-18問題：是否需要聯(lián)機(jī)更新主文件？F8復(fù)雜處理描述了邏輯處理對(duì)應(yīng)用開發(fā)的影響程度，包含以下要素：

敏感控制(例如特殊的審核過程)和/或程序特定的安全處理；

大量的邏輯處理；

大量的數(shù)學(xué)處理；

因?yàn)槔馓幚碓斐尚枰匦绿幚淼那闆r(例如，由TP中斷、數(shù)據(jù)值缺少和驗(yàn)證失敗導(dǎo)致的ATM事務(wù))；

多種可能的輸入/輸出造成的復(fù)雜處理。

復(fù)雜處理因子取值如表5-19所示。表5-19問題：內(nèi)部處理是否復(fù)雜？F9事務(wù)處理率是業(yè)務(wù)交易處理速度的要求對(duì)系統(tǒng)的設(shè)計(jì)、實(shí)施、安裝和支持等的影響。事務(wù)處理率因子取值如表5-20所示。表5-20問題：對(duì)事務(wù)處理效率有何要求？F10界面復(fù)雜性是指對(duì)應(yīng)用的人文因素以及使用的便捷方面的考慮程度。針對(duì)最終用戶效率的功能設(shè)計(jì)，主要包括以下因素：

·頁面導(dǎo)航；

·菜單；

·在線幫助或文檔；

·光標(biāo)自動(dòng)跳轉(zhuǎn)；

·可以滾動(dòng)；

·在線遠(yuǎn)程打?。?/p>

·預(yù)定義的功能鍵；

·在線做批量提交任務(wù)；

·光標(biāo)可以選取界面上的數(shù)據(jù)；·用戶使用大量反白顯示、重點(diǎn)顯示、下劃線或其他的標(biāo)識(shí)；

·在線copy用戶文檔；

·鼠標(biāo)拖動(dòng)功能；

·彈出窗體；

·使用最少的界面完成某種商業(yè)功能；

·雙語言支持(如果選擇了這個(gè)就算4項(xiàng))；

·多語言支持(如果選擇了這個(gè)就算6項(xiàng))。

界面復(fù)雜性因子取值如表5-21所示。表5-21問題：針對(duì)最終用戶效率的功能設(shè)計(jì)主要包括哪些因素？F11重用性指的是應(yīng)用系統(tǒng)中的應(yīng)用和代碼經(jīng)過特殊設(shè)計(jì)、開發(fā)和支持，可以在其他應(yīng)用系統(tǒng)中復(fù)用。重用性因子取值如表5-22所示。表5-22問題：代碼是否需要設(shè)計(jì)成可復(fù)用的？F12易安裝性指應(yīng)用系統(tǒng)的轉(zhuǎn)換和安裝容易度對(duì)開發(fā)的影響程度。系統(tǒng)測(cè)試階段提供了轉(zhuǎn)換和安裝計(jì)劃和/或轉(zhuǎn)換工具。易安裝性因子取值如表5-23所示。表5-23問題：設(shè)計(jì)中是否需要包括轉(zhuǎn)換及安裝？F13多重站點(diǎn)指應(yīng)用系統(tǒng)經(jīng)特殊設(shè)計(jì)、開發(fā)可以在多個(gè)組織、多個(gè)地點(diǎn)應(yīng)用的程度。多重站點(diǎn)因子取值如表5-24所示。表5-24問題：系統(tǒng)的設(shè)計(jì)是否支持不同組織的多次安裝？F14支持變更指的是應(yīng)用在設(shè)計(jì)上考慮支持處理邏輯和數(shù)據(jù)結(jié)構(gòu)變化的程度。可以具有如下的特性：

·提供可以處理簡(jiǎn)單要求的彈性查詢和報(bào)告功能，如對(duì)一個(gè)ILF進(jìn)行與(或)邏輯；

·提供可以處理一般復(fù)雜度要求的彈性查詢和報(bào)告功能，如對(duì)多于一個(gè)的ILF進(jìn)行的與(或)邏輯(當(dāng)作兩項(xiàng)計(jì)算)；

·提供可以處理復(fù)雜要求的彈性查詢和報(bào)告功能，如對(duì)一個(gè)或多個(gè)ILF進(jìn)行的與(或)邏輯的組合(當(dāng)作三項(xiàng)計(jì)算)；

·業(yè)務(wù)控制數(shù)據(jù)被保存到用戶通過在線交互進(jìn)程維護(hù)的表中，但變更只會(huì)在第二個(gè)工作日生效；

·業(yè)務(wù)控制數(shù)據(jù)被保存到用戶通過在線交互進(jìn)程維護(hù)的表中，且變更即時(shí)生效。支持變更因子取值如表5-25所示。表5-25問題：對(duì)變更的支持情況如何？通過分析判定獲得上述技術(shù)復(fù)雜度因子的值后，可以用公式(5-10)估算TCF的值。

(5-10)

由公式(5-10)可以看出，TCF的取值范圍是0.65～1.35。

案例：FP估算實(shí)例

W公司為X學(xué)校開發(fā)一個(gè)教職工管理系統(tǒng)，主要功能涉及職工信息、部門信息和工資信息的管理，要求系統(tǒng)能夠?qū)β毠ば畔?、部門信息進(jìn)行增加、刪除、修改和查詢，以及職工工資統(tǒng)計(jì)等操作。

假設(shè)系統(tǒng)涉及的信息如表5-26所示。表5-26X學(xué)校教職工管理系統(tǒng)中的基本信息由上述信息，可以識(shí)別ILF和EIF的功能點(diǎn)數(shù)，如表5-27所示。表5-27X學(xué)校教職工管理系統(tǒng)中ILF和EIF的功能點(diǎn)數(shù)EI功能點(diǎn)數(shù)如表5-28所示。表5-28X學(xué)校教職工管理系統(tǒng)中EI的功能點(diǎn)數(shù)EQ功能點(diǎn)數(shù)如表5-29所示。表5-29X學(xué)校教職工管理系統(tǒng)中EQ的功能點(diǎn)數(shù)EO功能點(diǎn)數(shù)如表5-30所示。

整個(gè)系統(tǒng)的未調(diào)整功能點(diǎn)數(shù)為UFC=19+25+9+4=57個(gè)。

系統(tǒng)技術(shù)復(fù)雜度因子影響如表5-31所示。表5-30X學(xué)校教職工管理系統(tǒng)中EO的功能點(diǎn)數(shù)表5-31X學(xué)校教職工管理系統(tǒng)的技術(shù)復(fù)雜度因子系統(tǒng)的技術(shù)復(fù)雜度調(diào)整因子為TCF=0.65+0.01×(3+2+5+3+1+3+1)=0.83。

調(diào)整后系統(tǒng)的功能點(diǎn)為FP=UFC×TCF=57×0.83=47.31個(gè)。

在估算管理系統(tǒng)的功能點(diǎn)時(shí)應(yīng)該多以用戶的紙質(zhì)表單為依據(jù)，每個(gè)表單就是一個(gè)ILF或EIF，表單上顯示的字段都是DET，一個(gè)表單上的“核心”內(nèi)容不管是由幾個(gè)數(shù)據(jù)表來分別存放數(shù)據(jù)的，每個(gè)表都是一個(gè)RET。簡(jiǎn)單來講，ILF和EIF可以被看作數(shù)據(jù)庫中的數(shù)據(jù)表，但是主、從表將被視為一個(gè)ILF或EIF。那么ILF和EIF的復(fù)雜度就是由數(shù)據(jù)表中的字段DET和一個(gè)ILF或EIF自身所包含的主、從表個(gè)數(shù)RET來決定。在計(jì)算DET時(shí)主、外鍵只能算作一個(gè)。

EI就是對(duì)應(yīng)用戶增加、修改和刪除的操作，EO和EQ都是用于用戶查詢的操作。EO和EQ的區(qū)別是EO查詢時(shí)使用了數(shù)學(xué)公式或計(jì)算方法。EI、EQ和EO的復(fù)雜度是由FTR和DET決定的。FTR的個(gè)數(shù)由ILF和EIF的個(gè)數(shù)決定，可以由主表中主、外鍵的個(gè)數(shù)來計(jì)算。在計(jì)算EI的DET時(shí)，只有用戶在界面上直接輸入的信息才算作DET，通過頁面自動(dòng)計(jì)算或轉(zhuǎn)換的數(shù)據(jù)不能算作EI的DET。在EO和EQ計(jì)算DET時(shí)，報(bào)表的標(biāo)題、頁碼等信息不能被計(jì)算為一個(gè)DET。

3.?FP估算法的特點(diǎn)

①?FP估算法與程序設(shè)計(jì)語言無關(guān)，常用在項(xiàng)目開始或項(xiàng)目需求基本明確時(shí)使用，估算結(jié)果比較準(zhǔn)確，假如這時(shí)使用LOC行估算法，則誤差比較大；

②使用FP估算法無需懂得軟件使用何種開發(fā)技術(shù)，LOC估算法與軟件開發(fā)技術(shù)密切相關(guān)；

③?FP估算法從用戶角度進(jìn)行估算，LOC估算法從程序員角度進(jìn)行估算；

④?FP估算法涉及到的主觀因素較多，有些數(shù)據(jù)不易采集，功能點(diǎn)FP值沒有直觀的物理意義；

⑤通過一些行業(yè)標(biāo)準(zhǔn)或企業(yè)自身度量的分析，F(xiàn)P估算法可以轉(zhuǎn)換為L(zhǎng)OC代碼行。功能點(diǎn)和源代碼行從兩個(gè)不同的角度來度量軟件規(guī)模，它們之間存在著較強(qiáng)的相關(guān)性。對(duì)于具體的軟件開發(fā)部門，可根據(jù)該部門歷史數(shù)據(jù)經(jīng)過統(tǒng)計(jì)處理獲得功能點(diǎn)數(shù)和源代碼行之間的關(guān)系。LOC和FP之間的換算與編程語言密切相關(guān)，表5-32給出了不同編程語言環(huán)境下每個(gè)功能點(diǎn)對(duì)應(yīng)的源代碼行數(shù)的參考值。表5-32不同編程語言下FP與LOC之間的換算關(guān)系在項(xiàng)目剛開始的時(shí)候進(jìn)行功能點(diǎn)估算可以對(duì)項(xiàng)目的范圍進(jìn)行預(yù)測(cè)，在項(xiàng)目開發(fā)的過程中由于需求的變更和細(xì)化可能會(huì)導(dǎo)致項(xiàng)目范圍的蔓延，計(jì)算出來的結(jié)果會(huì)與當(dāng)初估計(jì)的不同，因此在項(xiàng)目結(jié)束時(shí)還需要對(duì)項(xiàng)目的范圍情況進(jìn)行估算，這個(gè)時(shí)候估算的結(jié)果才能最準(zhǔn)確反映項(xiàng)目的規(guī)模。

在軟件項(xiàng)目管理中項(xiàng)目計(jì)劃制定的優(yōu)劣直接關(guān)系到項(xiàng)目的成敗，項(xiàng)目計(jì)劃中對(duì)項(xiàng)目范圍的估算又尤為重要，如果項(xiàng)目負(fù)責(zé)人對(duì)項(xiàng)目的規(guī)模沒有一個(gè)比較客觀的認(rèn)識(shí)，沒有對(duì)工作量、所需資源和完工時(shí)間等因素進(jìn)行估算，那么項(xiàng)目計(jì)劃也就沒有存在的意義。 5.3軟件項(xiàng)目成本估算方法

軟件開發(fā)成本估算主要指軟件開發(fā)過程中所花費(fèi)的工作量及相應(yīng)的代價(jià)。不同于傳統(tǒng)的工業(yè)產(chǎn)品，軟件的成本不包括原材料和能源的消耗，主要是人勞動(dòng)的消耗。另外軟件也沒有一個(gè)明顯的制造過程，其開發(fā)成本是以一次性開發(fā)過程所花費(fèi)的代價(jià)來計(jì)算的。因此估算人員應(yīng)該以整個(gè)開發(fā)過程(包括軟件計(jì)劃、需求、分析、設(shè)計(jì)、編碼、單元測(cè)試、集成測(cè)試和確認(rèn)測(cè)試)所花費(fèi)的代價(jià)作為依據(jù)來估算軟件開發(fā)成本。

軟件項(xiàng)目成本估算有兩種基本的方法：自頂向下和自底向上。自頂向下估算法是估算人員從項(xiàng)目的整體出發(fā)，根據(jù)以前已完成項(xiàng)目所消耗的總成本(或總工作量)推算將要開發(fā)的軟件的總成本(或總工作量)，然后按比例將它分配到各開發(fā)任務(wù)單元中去，再來檢驗(yàn)它是否能滿足要求。自頂向下估算法的優(yōu)點(diǎn)在于：對(duì)系統(tǒng)級(jí)的重視，估算工作量小，速度快。自頂向下估算法的缺點(diǎn)是：對(duì)項(xiàng)目中的特殊困難估計(jì)不足，估算出來的成本盲目性大，有時(shí)會(huì)遺漏待開發(fā)軟件的某些部分。自底向上估算法是估算人員把待開發(fā)的軟件細(xì)分，直到每個(gè)子任務(wù)都已經(jīng)明確所需要的開發(fā)工作量和開發(fā)時(shí)間，然后把它們加起來，得到軟件開發(fā)的總工作量。自底向上估算法的優(yōu)點(diǎn)是估算各個(gè)部分的準(zhǔn)確性高。這是由于細(xì)分之后的每一部分一般是由相應(yīng)的負(fù)責(zé)人在充分理解其規(guī)模的基礎(chǔ)上估算出來的。自底向上估算法的缺點(diǎn)是缺少各項(xiàng)子任務(wù)之間相互聯(lián)系所需要的工作量，還缺少許多與軟件開發(fā)有關(guān)的系統(tǒng)級(jí)工作量，往往造成項(xiàng)目估算花費(fèi)精力多，而估算總值不足的結(jié)果。

任務(wù)單元法是一種常見的引用自底向上思想的估算方法。

軟件項(xiàng)目成本估算的具體方法有多種，常用的主要有類推估算法、專家判定估算法和參數(shù)模型估算法。5.3.1類推估算法

類推估算法是比較科學(xué)的一種傳統(tǒng)估算方法，適合評(píng)估一些與歷史項(xiàng)目在應(yīng)用領(lǐng)域、環(huán)境和復(fù)雜度方面相似的項(xiàng)目，通過新項(xiàng)目與歷史項(xiàng)目的比較得到規(guī)模估計(jì)。類推估算法估計(jì)結(jié)果的精確度取決于歷史項(xiàng)目數(shù)據(jù)的完整性和準(zhǔn)確度，因此用好類推估算法的前提條件之一是開發(fā)機(jī)構(gòu)需要建立較好的項(xiàng)目后評(píng)價(jià)與分析機(jī)制，對(duì)歷史項(xiàng)目的數(shù)據(jù)分析必須是可信賴的。這種方法的基本步驟是：

(1)整理出項(xiàng)目功能列表和實(shí)現(xiàn)每個(gè)功能的代碼行；

(2)標(biāo)識(shí)出每個(gè)功能列表與歷史項(xiàng)目的相同點(diǎn)和不同點(diǎn)，特別要注意歷史項(xiàng)目做得不夠的地方；

(3)通過步驟(1)和(2)得出各個(gè)功能的估計(jì)值；

(4)產(chǎn)生規(guī)模估計(jì)。類推估算法引用自頂向下思想時(shí)，是將估算項(xiàng)目的總體參數(shù)與類似項(xiàng)目進(jìn)行直接相比得到結(jié)果；引用自底向上思想時(shí)，類推是在兩個(gè)具有相似條件的工作單元之間進(jìn)行的。

5.3.2專家判定估算法

專家判定估算法是依靠一位或多位專家對(duì)項(xiàng)目做出估計(jì)，其精確性主要取決于兩點(diǎn)，即專家對(duì)估算項(xiàng)目定性參數(shù)的了解和專家的經(jīng)驗(yàn)。所以專家要求具有專門的知識(shí)和豐富的經(jīng)驗(yàn)，估算是一種近似的猜測(cè)。因?yàn)閱为?dú)一位專家可能會(huì)產(chǎn)生某種偏見，所以最好由多位專家進(jìn)行估算取得多個(gè)估算值，然后采用某種方法把這些估算值合成一個(gè)最終的估算值。一種方法是簡(jiǎn)單地求各估算值的中值或平均值，優(yōu)點(diǎn)是簡(jiǎn)便，缺點(diǎn)是可能會(huì)由于受一兩個(gè)極端估算值的影響而產(chǎn)生嚴(yán)重的偏差；另一種方法是召開小組會(huì)議，使各位專家統(tǒng)一于或至少同意某一個(gè)估算值，優(yōu)點(diǎn)是可以擯棄蒙昧無知的估算值，缺點(diǎn)是一些專家成員可能會(huì)受權(quán)威或政治因素的影響。Delphi法是常用的專家判定評(píng)估方法，在沒有歷史數(shù)據(jù)的情況下，這種方式適用于評(píng)定過去與將來、新技術(shù)與特定程序之間的差別。這種方法可以減輕由于專家具備的知識(shí)、經(jīng)驗(yàn)及其對(duì)項(xiàng)目的理解程度不同所帶來的估算偏差，盡管如此，這種方法在評(píng)定一個(gè)新軟件實(shí)際成本時(shí)不經(jīng)常使用，但是這種方式對(duì)決定其它模型的輸入特別有用。Delphi法鼓勵(lì)參與者就問題相互討論。采用這種方法，要求具有多種軟件相關(guān)經(jīng)驗(yàn)的人參與，互相說服對(duì)方。Delphi法的步驟是：

(1)協(xié)調(diào)人向各專家提供項(xiàng)目規(guī)格和估計(jì)表格；

(2)協(xié)調(diào)人召集小組會(huì)，各專家討論與規(guī)模相關(guān)的因素；

(3)各專家匿名填寫迭代表格；

(4)協(xié)調(diào)人整理出一個(gè)估計(jì)總結(jié)，以迭代表的形式返回專家；

(5)協(xié)調(diào)人召集小組會(huì)，討論較大的估計(jì)差異；

(6)專家復(fù)查估計(jì)總結(jié)，并在迭代表上提交另一個(gè)匿名估計(jì)；(7)重復(fù)步驟(4)～(6)，直到達(dá)到最低和最高估計(jì)的一致。

Delphi法不會(huì)產(chǎn)生一些專家成員受權(quán)威或政治因素影響的現(xiàn)象，因?yàn)楣浪銓＜沂欠稚⒌?，他們互不見面地開展估算工作，對(duì)應(yīng)于每個(gè)專家的單個(gè)估算值不會(huì)受到其他人員的影響。

5.3.3參數(shù)模型估算法

參數(shù)模型估算法是一種使用項(xiàng)目特性參數(shù)建立數(shù)學(xué)模型來估算成本的方法，是一種統(tǒng)計(jì)技術(shù)，如回歸分析和學(xué)習(xí)曲線。采用這種方法很難完全依靠理論導(dǎo)出估算模型，一般要參考?xì)v史信息，借助經(jīng)驗(yàn)公式得出估算模型，而且重要參數(shù)必須量化處理，根據(jù)實(shí)際情況對(duì)參數(shù)模型按適當(dāng)比例調(diào)整。每個(gè)任務(wù)必須至少有一個(gè)統(tǒng)一的規(guī)模單位。參數(shù)模型估算法與類推估算法、專家判定估算法相比，運(yùn)用數(shù)學(xué)模型旨在盡力避免主觀因素的影響，相對(duì)而言比較客觀，估算過程比較簡(jiǎn)單，估算結(jié)果比較準(zhǔn)確。數(shù)學(xué)模型可以簡(jiǎn)單也可以復(fù)雜，有的是簡(jiǎn)單的線性關(guān)系模型，有的模型卻比較復(fù)雜。

模型中用一個(gè)唯一的變量(如程序規(guī)模)作為初始元素來計(jì)算所有其他變量(如成本和時(shí)間)，且所用計(jì)算公式的形式對(duì)于所有變量都是相同的，把這種模型稱為靜態(tài)模型。

模型中沒有類似靜態(tài)模型中的惟一基礎(chǔ)變量，所有變量都是相互依存的，把這種模型稱為動(dòng)態(tài)模型。目前運(yùn)用的靜態(tài)單變量成本估算模型，從其主要的輸入?yún)?shù)來看，可以歸為面向代碼行驅(qū)動(dòng)的成本模型和面向功能點(diǎn)的成本模型兩大類，如表5-33所示。

從表5-33給出的模型估算公式可以看出，對(duì)于具有相同代碼行數(shù)或功能點(diǎn)數(shù)的項(xiàng)目，選用不同模型估算出來的結(jié)果并不相同。究其原因，主要是這些模型只是根據(jù)若干應(yīng)用領(lǐng)域內(nèi)有限個(gè)項(xiàng)目的經(jīng)驗(yàn)數(shù)據(jù)推導(dǎo)出來的，適用范圍有限，因此目前還沒有一種估算模型能夠適用于所有的軟件類型和開發(fā)環(huán)境，如果模型選擇不當(dāng)或數(shù)據(jù)不準(zhǔn)，也會(huì)導(dǎo)致明顯的偏差，從這些模型中得到的結(jié)果必須慎重使用。當(dāng)然應(yīng)該根據(jù)新項(xiàng)目的特點(diǎn)選擇適用的估算模型，并且根據(jù)實(shí)際情況適當(dāng)?shù)卣{(diào)整估算模型。表5-33常見的靜態(tài)單變量估算模型除了表5-33列出的幾種模型之外，還有Farr-Zagorski模型、Price-S模型、Putnam模型、COCOMO模型等。

COCOMO模型是一種典型的成本模型，用來提供工作量或規(guī)模的直接估計(jì)，其常常有一個(gè)主要的成本因素(例如規(guī)模)，還有很多的次要調(diào)節(jié)因素或成本驅(qū)動(dòng)因素。典型的成本模型是將歷史項(xiàng)目數(shù)據(jù)進(jìn)行回歸分析得出的基于回歸分析的模型。

Putnam模型是一種約束模型，顯示出兩個(gè)或多個(gè)工作量參數(shù)、持續(xù)時(shí)間參數(shù)或人員參數(shù)之間時(shí)間變化的關(guān)系。 5.4軟件項(xiàng)目成本估算模型

5.4.1COCOMO模型

COCOMO(ConstructiveCostModel，結(jié)構(gòu)化成本模型)是由巴里·勃姆(BarryBoehm)提出、TRW公司開發(fā)的一種結(jié)構(gòu)化成本估算模型。巴里·勃姆于1981年在該公司擔(dān)任軟件研究與技術(shù)總監(jiān)，在對(duì)TRW飛機(jī)制造公司的63個(gè)項(xiàng)目的研究基礎(chǔ)上，使得這項(xiàng)研究中的項(xiàng)目所包含的代碼量從2000行到10000行，包含的編程語言從匯編語言到PL/I。這些項(xiàng)目采用瀑布模型進(jìn)行軟件開發(fā)，這是1981年時(shí)主流的軟件開發(fā)模式。COCOMO模型使用一種基本的回歸分析公式，使用從項(xiàng)目歷史和現(xiàn)狀中得出的某些特征作為參數(shù)來進(jìn)行計(jì)算。COCOMO模型是一個(gè)采用自底向上的方法進(jìn)行估算的典范，是一種精確、易于使用的成本估算方法。

COCOMO模型可以分為三個(gè)層次：基本COCOMO模型、中級(jí)COCOMO模型和高級(jí)COCOMO模型，分別用于軟件開發(fā)的三個(gè)不同階段。

基本COCOMO模型是一個(gè)靜態(tài)單變量模型，用一個(gè)已估算出來的代碼行數(shù)(LOC)作為自變量的經(jīng)驗(yàn)函數(shù)計(jì)算軟件開發(fā)工作量；中級(jí)COCOMO模型在基本COCOMO模型的基礎(chǔ)上，再用涉及產(chǎn)品、硬件、人員、項(xiàng)目等方面的因素調(diào)整工作量的估算；

高級(jí)COCOMO模型包括中級(jí)COCOMO模型的所有特性，但更進(jìn)一步考慮了軟件工程中每一步驟(如分析、設(shè)計(jì))的影響。

1.基本COCOMO模型

基本COCOMO模型是一種靜態(tài)單變量模型，用源代碼行數(shù)(KLOC)為自變量的(經(jīng)驗(yàn))函數(shù)來計(jì)算軟件開發(fā)工作量(及成本)。其工作量計(jì)算公式如下：

(5-11)式中：LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；a，b是與軟件開發(fā)模式有關(guān)的兩個(gè)經(jīng)驗(yàn)常數(shù)。

開發(fā)時(shí)間計(jì)算公式如下：

(5-12)

式中：E表示軟件開發(fā)工作量，單位：人月(PM)；c，d是與軟件開發(fā)模式有關(guān)的兩個(gè)經(jīng)驗(yàn)常數(shù)。

COCOMO模型中，考慮開發(fā)環(huán)境，定義了三種軟件開發(fā)模式，它們分別是組織型(Organic)、嵌入型(Embedded)和半獨(dú)立型(Semidetached)?！そM織型(Organic)：相對(duì)較小、較簡(jiǎn)單的軟件項(xiàng)目。開發(fā)人員對(duì)軟件產(chǎn)品開發(fā)目標(biāo)理解比較充分，與軟件系統(tǒng)相關(guān)的工作經(jīng)驗(yàn)豐富，對(duì)軟件的使用環(huán)境很熟悉，受硬件的約束較小，程序的規(guī)模不是很大，一般小于5萬行。如多數(shù)應(yīng)用軟件和較早的OS、Compiler。

·嵌入型(Embedded)：要求在緊密聯(lián)系硬件、軟件和操作的限制條件下運(yùn)行，通常與某種復(fù)雜的硬件設(shè)備緊密聯(lián)系。對(duì)接口、數(shù)據(jù)結(jié)構(gòu)和算法的要求較高，軟件規(guī)模任意。如大型復(fù)雜的事務(wù)處理系統(tǒng)、大型/超大型操作系統(tǒng)、航天用控制系統(tǒng)和大型指揮系統(tǒng)等?！ぐ氇?dú)立型(Semidetached)：介于上述兩種軟件之間。規(guī)模和復(fù)雜度都屬于中等或更高，最大可達(dá)30萬行，如固定需求的事務(wù)處理系統(tǒng)。

上述三種軟件開發(fā)模式的特性比較如表5-34所示。表5-34COCOMO模型的三種開發(fā)模式比較基本COCOMO模型中與三種開發(fā)模式相關(guān)的常數(shù)取值如表5-35所示。表5-35基本COCOMO模型中a、b、c、d的取值用基本COCOMO模型估算軟件項(xiàng)目的工作量和開發(fā)時(shí)間，必須首先確定項(xiàng)目的開發(fā)模式，以便獲得與之對(duì)應(yīng)的a、b、c、d值。b和d的引入使得估算工作量和開發(fā)時(shí)間成指數(shù)增加，因?yàn)轫?xiàng)目越大，協(xié)調(diào)和安排需要投入越多的時(shí)間和工作量。

基本COCOMO模型適用于系統(tǒng)開發(fā)初期對(duì)軟件開發(fā)重要的方面進(jìn)行快速和粗略的成本估計(jì)，但因其缺少不同的項(xiàng)目屬性因素，所以準(zhǔn)確性有一定的局限性。因?yàn)樵撃Ｐ椭豢紤]了軟件開發(fā)模式和程序規(guī)模，并未考慮軟件開發(fā)方法、開發(fā)工具和項(xiàng)目管理等因素，只要不同項(xiàng)目的開發(fā)模式和程序規(guī)模相同，估算出來的工作量和開發(fā)時(shí)間就會(huì)相等，這顯然是不準(zhǔn)確的，需要慎重對(duì)待使用該模型估算的結(jié)果。

2.中級(jí)COCOMO模型

在用LOC為自變量的函數(shù)計(jì)算軟件開發(fā)工作量(此時(shí)稱為名義工作量)的基礎(chǔ)上，再用涉及產(chǎn)品、硬件、人員和項(xiàng)目等方面15種影響軟件工作量的因素，通過決定下乘法因子，修正COCOMO工作量公式和進(jìn)度公式，可以更合理地估算軟件(各階段)的工作量和進(jìn)度。其工作量計(jì)算公式如下：

(5-13)

式中：LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；EAF表示工作量調(diào)整因子(EffortAdjustmentFactor)；a、b是與軟件開發(fā)模式有關(guān)的兩個(gè)經(jīng)驗(yàn)常數(shù)。中級(jí)COCOMO模型中與三種開發(fā)模式相關(guān)的常數(shù)取值如表5-36所示。表5-36中級(jí)COCOMO模型中a、b的取值

調(diào)整前的工作量 稱為名義工作量，是按照基礎(chǔ)模型計(jì)算的。

工作量調(diào)整因子EAF的計(jì)算公式為：

(5-14)

式中：Di表示成本驅(qū)動(dòng)量，n表示成本驅(qū)動(dòng)因子的個(gè)數(shù)。在中級(jí)COCOMO模型估算中，獲取成本驅(qū)動(dòng)量Di成為重要工作之一。

中級(jí)COCOMO模型將成本驅(qū)動(dòng)因子分為四類，分別是產(chǎn)品、計(jì)算機(jī)、人員及項(xiàng)目屬性。每類又有一些具體的屬性，總共形成了15個(gè)成本驅(qū)動(dòng)因子。每個(gè)成本驅(qū)動(dòng)因子按照重要程度或大小分為“很低”、“低”、“一般”、“高”、“很高”、“非常高”6個(gè)等級(jí)，通過逐項(xiàng)評(píng)價(jià)可以從表5-37中獲得每個(gè)成本驅(qū)動(dòng)因子的值。表5-37中級(jí)COCOMO模型中的成本驅(qū)動(dòng)量在這15個(gè)成本驅(qū)動(dòng)因子中，影響最大的是人員屬性。因?yàn)椴煌降娜藛T，其工作效率差異很大，例如當(dāng)分析員的能力“低”時(shí)，該因子的值為1.19，工作量將會(huì)增加19%；而達(dá)到平均水平以上(“高”)時(shí)，該因子的值為0.86，工作量將會(huì)降低14%。由此可見，不同的人員完成同一個(gè)軟件項(xiàng)目，需要付出的代價(jià)可能會(huì)有很大差別。

中級(jí)COCOMO模型中估算開發(fā)時(shí)間的公式與基本COCOMO模型的相同。

中級(jí)COCOMO模型也可以進(jìn)行部件級(jí)估算。估算過程中，首先將軟件劃分成若干軟件部件，再針對(duì)每個(gè)部件，運(yùn)用上述估算方法進(jìn)行估算，然后把各部件的估算值累加起來，便可得到整個(gè)軟件的估算值。

3.高級(jí)COCOMO模型

高級(jí)COCOMO模型包括中級(jí)COCOMO模型的所有特性，其名義工作量公式和進(jìn)度公式與中級(jí)COCOMO模型相同，但用上述各種影響因素調(diào)整工作量估算時(shí)，還要考慮對(duì)軟件工程過程中每一步驟(包括分析和設(shè)計(jì)等)的影響，于是引入了三層產(chǎn)品分級(jí)結(jié)構(gòu)和階段敏感工作量因素，而且工作量因素分級(jí)表被分層、分階段給出。

針對(duì)軟件系統(tǒng)的抽象性和復(fù)雜性，把成本驅(qū)動(dòng)量放在模塊、子系統(tǒng)和系統(tǒng)三個(gè)層次上予以考慮。隨底層各模塊的不同而變化的因素放在模塊級(jí)處理；不經(jīng)常變化的因素放在子系統(tǒng)級(jí)處理；系統(tǒng)級(jí)處理與軟件項(xiàng)目總體規(guī)模等相關(guān)的問題?？紤]軟件開發(fā)各階段受成本驅(qū)動(dòng)因素影響的大小不同，如某些階段(例如設(shè)計(jì)、編碼和調(diào)試等)比其他階段受到某種因素的影響可能更大，因此根據(jù)階段敏感工作量因素按需求計(jì)劃和產(chǎn)品設(shè)計(jì)(RPD)、詳細(xì)設(shè)計(jì)(DD)、編碼和單元測(cè)試(CUT)、集成測(cè)試(IT)四個(gè)不同階段的不同，為成本驅(qū)動(dòng)變量賦予了不同的值。針對(duì)每一個(gè)影響因素，按模塊級(jí)、子系統(tǒng)級(jí)和系統(tǒng)級(jí)有相應(yīng)的工作量因素分級(jí)表(如表5-38、表5-39、表5-40所示)，供不同層次的估算使用。使用這些表格，可以比中級(jí)COCOMO模型更方便、更準(zhǔn)確地估算軟件開發(fā)工作量。表5-38高級(jí)COCOMO模型中的模塊級(jí)驅(qū)動(dòng)因素表5-39高級(jí)COCOMO模型中的子系統(tǒng)級(jí)驅(qū)動(dòng)因素表5-40高級(jí)COCOMO模型中的工作量在四個(gè)階段的分布情況5.4.2COCOMOⅡ模型

20世紀(jì)90年代后期，軟件項(xiàng)目管理和開發(fā)技術(shù)與工具發(fā)生了很大變化，未來軟件市場(chǎng)被劃分為基礎(chǔ)軟件、系統(tǒng)集成、程序自動(dòng)化生成、應(yīng)用集成和最終用戶編程五個(gè)部分，早期COCOMO模型已不再適應(yīng)新的軟件成本估算和過程管理的需要。1994年，Boehm重新研究和調(diào)整原有COCOMO模型,發(fā)表了COCOMOⅡ模型。該模型是對(duì)經(jīng)典COCOMO模型的徹底更新，反映了現(xiàn)代軟件過程與構(gòu)造方法。后來，Boehm又通過對(duì)大量軟件開發(fā)項(xiàng)目進(jìn)行測(cè)算，推出了COCOMOⅡ2000。COCOMOⅡ通過應(yīng)用組合模型、早期開發(fā)模型和結(jié)構(gòu)化后期模型支持上述的五種軟件項(xiàng)目，這三個(gè)計(jì)算模型是按照軟件生命周期劃分的。

·應(yīng)用組合模型：通過原型來解決人機(jī)交互、系統(tǒng)接口和技術(shù)成熟度等具有潛在高風(fēng)險(xiǎn)的問題，通過計(jì)算屏幕、報(bào)表和第三代語言模塊的對(duì)象點(diǎn)數(shù)來評(píng)估軟件成本。適用于使用現(xiàn)代GUI工具開發(fā)的項(xiàng)目。

·早期開發(fā)模型：適用于在軟件架構(gòu)確定之前對(duì)軟件進(jìn)行粗略成本和事件的估算，包含了一系列新的基于功能點(diǎn)或代碼行成本和進(jìn)度的估算方法?！そY(jié)構(gòu)化后期模型：在項(xiàng)目確定開發(fā)之后，對(duì)軟件功能結(jié)構(gòu)己經(jīng)有了一個(gè)基本了解的基礎(chǔ)上，通過源代碼行數(shù)或功能點(diǎn)數(shù)來計(jì)算軟件工作量和進(jìn)度，使用5個(gè)規(guī)模度量因子和17個(gè)成本驅(qū)動(dòng)因子調(diào)整計(jì)算公式。其是COCOMOⅡ中最詳細(xì)的模型，適用于在整體軟件架構(gòu)已確定之后。

1.?COCOMOⅡ中處理軟件復(fù)用的模型

COCOMOⅡ采用非線性估算模型處理軟件復(fù)用，把復(fù)用代碼和改變代碼的有效規(guī)模調(diào)整為等價(jià)的新代碼行。計(jì)算重用模塊規(guī)模的公式如下：(5-15)AAM表示改變調(diào)整修改量(5-16)(5-17)(5-18)，(AAF≤50)，(AAF>50)評(píng)估和選擇參數(shù)AA的等級(jí)量如表5-41所示。表5-41評(píng)估和選擇參數(shù)AA的取值參考軟件理解參數(shù)SU的等級(jí)量如表5-42所示。表5-42軟件理解參數(shù)SU的取值參考程序員不熟悉程度UNFM的等級(jí)量如表5-43所示。表5-43程序員不熟悉程度UNFM的取值參考

2.?COCOMOⅡ中估算開發(fā)工作量的模型

COCOMOⅡ以代碼行作為軟件規(guī)模計(jì)算工作量的公式如下：

式中：E表示軟件開發(fā)工作量，單位：人月(PM)；A是一個(gè)可校準(zhǔn)常數(shù)，COCOMOII2000中A?=?2.94；LC表示軟件代碼行數(shù)，單位：千行源代碼(KLOC)；B是一個(gè)依賴于5個(gè)規(guī)模經(jīng)濟(jì)性比例因子的指數(shù)；EAF是一個(gè)依賴于成本驅(qū)動(dòng)因素的工作量調(diào)整因子；EAUTO表示自動(dòng)轉(zhuǎn)換代碼的工作量，單位：人月(PM)。公式(5-19)中指數(shù)B的計(jì)算公式如下：(5-19)

式中：C是一個(gè)可校準(zhǔn)常數(shù)，COCOMOⅡ2000中C=0.91；SFi代表規(guī)模經(jīng)濟(jì)性比例因子，其值如表5-44所示。(5-20)表5-44COCOMOⅡ模型中的規(guī)模度量因子取值在COCOMOⅡ中，用工作量估算公式中的指數(shù)B體現(xiàn)了不同規(guī)模的軟件項(xiàng)目所具有的相對(duì)規(guī)模經(jīng)濟(jì)性和不經(jīng)濟(jì)性的最終影響合力。

·若B?<?1.0，則表明項(xiàng)目架構(gòu)、開發(fā)環(huán)境、團(tuán)隊(duì)都足夠健壯和穩(wěn)定，項(xiàng)目總體能夠體現(xiàn)出規(guī)模經(jīng)濟(jì)性。當(dāng)項(xiàng)目的規(guī)模加倍時(shí)，工作量不會(huì)翻倍。項(xiàng)目的生產(chǎn)率也隨著產(chǎn)品規(guī)模的增加而提高?！と鬊?=?1.0，則表明項(xiàng)目的規(guī)模經(jīng)濟(jì)性和不經(jīng)濟(jì)性是平衡的，這個(gè)時(shí)候就等同于通過規(guī)模/生產(chǎn)率來確定項(xiàng)目工作量的情況。這種線性模型通常用于小項(xiàng)目的成本估算。根據(jù)實(shí)踐經(jīng)驗(yàn)，項(xiàng)目工作量并不是完全由簡(jiǎn)單的個(gè)體生產(chǎn)率來確定的，它還涉及到開發(fā)靈活性、架構(gòu)風(fēng)險(xiǎn)、團(tuán)隊(duì)和過程成熟度等很多的影響因素。因此需要用表5-39中的規(guī)模經(jīng)濟(jì)性比例因子對(duì)B進(jìn)行適當(dāng)調(diào)整。

·若B?>?1.0，則項(xiàng)目就表現(xiàn)出總體的規(guī)模不經(jīng)濟(jì)性。當(dāng)規(guī)模增加的時(shí)候可能會(huì)導(dǎo)致工作量的成倍增加。這通常是由于人員交流開銷的增大和大型系統(tǒng)集成開銷的增長(zhǎng)。早期設(shè)計(jì)模型和結(jié)構(gòu)后期模型中，A、B、C、SF1～SF5都是相同的。

EAF是一個(gè)工作量調(diào)整因子，可用公式(5-14)計(jì)算，關(guān)鍵在于確定成本驅(qū)動(dòng)量。

在早期設(shè)計(jì)模型中，成本驅(qū)動(dòng)因子有7個(gè)，其值如表5-45所示。表5-45COCOMOⅡ早期設(shè)計(jì)模型的成本驅(qū)動(dòng)量在結(jié)構(gòu)后期模型中，成本驅(qū)動(dòng)因子有17個(gè)，其值如表5-46所示。表5-46COCOMOⅡ結(jié)構(gòu)后期模型的成本驅(qū)動(dòng)量EAUTO表示自動(dòng)轉(zhuǎn)換代碼的工作量，計(jì)算公式如下：

式中：EAUTO表示自動(dòng)轉(zhuǎn)換代碼的工作量，單位：人月(PM)；

LMC表示改編的代碼行數(shù)，單位：千行源代碼(KLOC)；

AT表示重構(gòu)時(shí)自動(dòng)轉(zhuǎn)換代碼的百分比；

PAT表示自動(dòng)轉(zhuǎn)換生產(chǎn)率。(5-21)

3.?COCOMOⅡ中多模塊的工作量估算

(1)對(duì)所有組件的規(guī)模Si求和，得到軟件的總規(guī)模SA：

(2)應(yīng)用項(xiàng)目級(jí)驅(qū)動(dòng)因子B公式(5-20)和SCED，計(jì)算基本總工作量EB：

(3)考慮每個(gè)組件對(duì)總規(guī)模的貢獻(xiàn)，將EB按比例分配給每個(gè)組件，由此計(jì)算EBi：(5-22)(5-23)(5-24)(4)應(yīng)用除了SCED之外的16個(gè)成本驅(qū)動(dòng)量調(diào)整每個(gè)組件的工作量：

式中：EAFUSCED表示用表5-46中的16個(gè)驅(qū)動(dòng)量(除去SCED)相乘所得的工作量調(diào)整因子：

(5)對(duì)每個(gè)組件的工作量求和，得到整個(gè)項(xiàng)目的總工作量EA：(5-27)(5-26)(5-25)COCOMOⅡ不僅可以估算開發(fā)工作量，而且可以估算項(xiàng)目的進(jìn)度，限于篇幅，這里不再詳細(xì)介紹。

一系列成功案例顯示，使用COCOMOⅡ估算模型所得到的估算結(jié)果與實(shí)際工作量很接近，相對(duì)誤差平均值都在可接受的范圍內(nèi)。而用未改進(jìn)的估算模型計(jì)算出的結(jié)果與實(shí)際工作量的誤差大于20%。5.4.3Putnam模型

Putnam在研究來自美國計(jì)算機(jī)系統(tǒng)指揮部的200多個(gè)大型項(xiàng)目(項(xiàng)目的工作量在30～1000人年之間)中收集到的工作量分布數(shù)據(jù)之后，發(fā)現(xiàn)工作量在項(xiàng)目實(shí)施各階段的前期緩慢上升，在后期急劇下降，類似于Rayleigh曲線的特性。于是，假定在軟件開發(fā)的整個(gè)生存期中工作量有特定的分布，于1978年提出了Putnam模型，這是一種動(dòng)態(tài)多變量模型，是一種引用了自頂向下思想的宏觀估算模型，也稱為軟件生命周期模型(SoftwareLifecycleModel,SLIM)。

該模型以大型軟件項(xiàng)目的實(shí)測(cè)數(shù)據(jù)為基礎(chǔ)，大型軟件項(xiàng)目的開發(fā)工作量分布可以用Rayleigh-Norden曲線表示(如圖5.5所示)，但也可以應(yīng)用在一些較小的軟件項(xiàng)目中。圖5.5軟件項(xiàng)目生命周期各階段的Rayleigh-Norden曲線(不同生命周期階段工作量分布情況不同。虛線左方大約相當(dāng)于軟件開發(fā)期，虛線右方相當(dāng)于運(yùn)行和維護(hù)期。曲線下方的曲面面積，就是整個(gè)軟件生存期所需要的工作量。對(duì)于大型軟件來說虛線左右兩側(cè)的面積比大約為4∶6，即開發(fā)所需的工作量約占軟件生存期總工作量的40%，而維護(hù)工作量占60%左右)圖5.5所示的曲線把已交付的源代碼行數(shù)與工作量和開發(fā)時(shí)間聯(lián)系起來。在軟件項(xiàng)目的不同生命周期階段分別使用不同的曲線，其所反映的各個(gè)階段的工作量非常直觀，但是不能反映人員、計(jì)算機(jī)資源和項(xiàng)目的屬性。

用Rayleigh-Norden曲線可以導(dǎo)出Putnam模型的軟件方程：

式中：LC表示軟件的源代碼行數(shù),單位：行源代碼(SLOC)；

Ck是技術(shù)因子；

E表示軟件開發(fā)工作量，單位：人年(PY)；

T表示軟件開發(fā)持續(xù)的時(shí)間，單位：年(Y)。(5-28)技術(shù)因子Ck是由多個(gè)組成部分形成的復(fù)合成本驅(qū)動(dòng)因子，其取值因開發(fā)環(huán)境而異，如表5-47所示。表5-47Putnam模型中技術(shù)因子的Ck的取值將公式(5-28)加以變換，可以得到估算工作量的公式如下：

還可以得到估算開發(fā)時(shí)間的公式如下：

Putnam模型的人力增加方程定義如下：(5-29)(5-30)(5-31)D是一個(gè)表示人員配備加速度的常數(shù)，其值如表5-48所示。

將公式5-30和公式5-31聯(lián)立，可以得到工作量計(jì)算方程如下：表5-48Putnam模型中人員配備加速度常數(shù)D的取值(5-32)5.4.4成本模型的評(píng)價(jià)準(zhǔn)則

從前面所述的估算模型不難看出，無論是模型結(jié)構(gòu)、復(fù)雜度還是軟件項(xiàng)目規(guī)模都是靠開發(fā)者的經(jīng)驗(yàn)估計(jì)出來的，這些參數(shù)在開發(fā)的早期很難預(yù)測(cè)。大多數(shù)模型在當(dāng)初導(dǎo)出它們的適用項(xiàng)目估算中發(fā)揮了很好的作用，但應(yīng)用于普通情況時(shí)表現(xiàn)很差。軟件需求是復(fù)雜而有差異的。雖然許多模型包含解決差異的調(diào)整因素，評(píng)估人員可依靠調(diào)整因素去解決當(dāng)前問題的任何變動(dòng)，但是這種方法常常是不合適的。實(shí)際上，許多因素會(huì)相互影響，有時(shí)會(huì)導(dǎo)致過度忽略了某個(gè)因素的重要性。同時(shí)這些方法也非常具有主觀性，常常帶有開發(fā)者的個(gè)人傾向。另外調(diào)整因素的計(jì)算過程也過于復(fù)雜，不是一個(gè)容易確定的值。一般模型要求對(duì)軟件規(guī)模進(jìn)行估算，但項(xiàng)目初期很難預(yù)測(cè)。對(duì)規(guī)模的估計(jì)結(jié)果也很主觀，并要求模型的規(guī)模度量和用于實(shí)際中的規(guī)模度量相同，否則不能給出準(zhǔn)確的結(jié)果。

由于各種成本估算方法的適用范圍不同，經(jīng)常導(dǎo)致同一個(gè)軟件項(xiàng)目采用不同的方法而得出不同的結(jié)果。給定一個(gè)具體的項(xiàng)目，如何選擇最適合的成本估算方法是實(shí)施軟件成本管理必須解決的關(guān)鍵問題。Boehm提出了10條評(píng)價(jià)成本模型的準(zhǔn)則，包括定義、正確性、客觀性、構(gòu)造性、細(xì)節(jié)、穩(wěn)定性、范圍、易用性、可預(yù)期性、節(jié)約性。

(1)定義：模型是否清楚定義了估算的成本和排除的成本；

(2)正確性：估算是否接近于項(xiàng)目的實(shí)際成本；

(3)客觀性：模型是否避免將大部分軟件成本的變化歸納為校準(zhǔn)很差的主觀因素，如復(fù)雜性；是否很難調(diào)整模型來獲得想要的結(jié)果；

(4)構(gòu)造性：用戶是否了解為什么模型能進(jìn)行估計(jì)，是否有助于用戶理解即將著手的軟件項(xiàng)目；(5)細(xì)節(jié)：模型能否方便地對(duì)一個(gè)有很多子系統(tǒng)和單元組成的軟件系統(tǒng)進(jìn)行估算，是否能準(zhǔn)確地分出階段并相應(yīng)的將活動(dòng)分階段；

(6