所在位置:首頁 -- 項目管理 -- 正文

軟件項目的規模、工作量和成本是如何進行估算的


發布時間:2017-4-1  來源:admin

 1. 基于代碼行和功能點的估算

軟件項目的規模是影響軟件項目成本和工作量的主要因素。在基于代碼行(loc,line of code)和功能點(function point)的估算方法中,利用代碼行和功能點來表示軟件系統的規模,并通過對軟件項目規模的估算進而來估算軟件項目的成本和工作量。

顯然,一個軟件項目的代碼行數目越多,它的規模也就越大。軟件代碼行的數目易于度量,許多軟件開發組織和項目組都保留有以往軟件項目代碼行數目的記錄,這有助于在以往類似軟件項目代碼行記錄的基礎上對當前軟件項目的規模進行估算。

用代碼行的數目來表示軟件項目的規模簡單易行,自然、直觀且易于度量。但是其缺點也非常明顯。在軟件開發初期很難估算出最終軟件系統的代碼行數;軟件項目代碼行的數目通常依賴于程序設計語言的功能和表達能力;采用代碼行的估算方法會對那些設計精巧的軟件項目產生不利的影響;該方法只適合于過程式程序設計語言,不適合于非過程式程序設計語言(如函數式或者邏輯語言)。

針對上述問題,人們提出用軟件系統的功能數目來表示軟件系統的規模。1979年ibm的albrecht提出了計算功能點的方法。該方法需要對軟件系統的二個方面進行評估,即評估軟件系統所需的內部基本功能和外部基本功能,然后根據技術復雜度因子對這二個方面的評估結果進行加權量化,產生軟件系統功能點數目的具體計算值。具體的,以下是軟件系統功能點的計算公式。

fp = ct× (0.65 + 0.01×sfi) (i=1..14)

其中,ct是5個信息量的“加權和”,fi是14個因素的“復雜性調節值”(i =1..14),0.65和0.01是經驗常數。

ct的計算方法如表 3所示,ct =(簡單用戶輸入數×3 +一般用戶輸入數×4+復雜用戶輸入數×6)+(簡單用戶輸出數×4+一般用戶輸出數×5+復雜用戶輸出數×7)+(簡單用戶查詢數×3+一般用戶查詢數×4+復雜用戶查詢數×6)+(簡單文件數×7+一般文件數×10+復雜文件數×15)+(簡單外部界面數×5+一般外部界面數×7+復雜外部界面數×10)。其中,用戶輸入數是指由用戶提供的、用來輸入的應用數據項的數目;用戶輸出數是指軟件系統為用戶提供的、向用戶輸出的應用數據項的數目;用戶查詢數是指要求回答的交互式輸入的項;文件數是指系統中主文件的數目;外部界面數是指機器可讀的文件數目(如磁盤或者磁帶中的數據文件)。

例如,假設項目組要開發一個軟件項目a。根據用戶的需求描述,該軟件項目的ct取值如表 5所示。進一步的,假設該軟件項目的14個復雜性調節值全部取平均程度。那么根據表 5可知,該軟件項目的ct=341,14個復雜性調節因素的累加值sfi=42,因而根據公式fp = ct× (0.65 + 0.01×sfi) (i=1..14)可知,該軟件項目的功能點fp=341× (0.65 + 0.01×42) = 364.87,即該項目的功能點數目大致為364。

用功能點來表示軟件項目規模的好處是:軟件系統的功能與實現該軟件系統的語言和技術無關,而且在軟件開發的早期階段(如需求分析)就可通過對用戶需求的理解獲得軟件系統的功能點數目,因而該方法可以較好地克服基于代碼行軟件項目規模表示方法的不足。其不足主要體現在:該方法沒有直接涉及算法的復雜度,不適合算法比較復雜的軟件系統;功能點計算主要靠經驗公式,主觀因素比較多;此外計算功能點所需的數據不好采集。

大量的實踐表明:針對特定的程序設計語言,軟件系統的功能點和代碼行二者之間存在某種對應關系(如表 6所示)。根據該表的數據,一個功能點如果用匯編語言來實現大約需要320行代碼,如果用c語言來實現大約需要150行代碼,如果用smalltalk語言來實現大約需要21行代碼。從另一個角度上看,該表反映了不同程序設計語言的描述能力是不一樣的。

假設用l表示軟件系統的規模(或者用loc表示,或者用fp來表示)。針對一個具體的軟件項目,可以采用自頂向下或者自底向上等多種方式來估算出軟件項目規模的樂觀值a、悲觀值b和一般值m,然后根據以下公式估算出軟件項目規模的期望值e:

e = (a + 4′m + b)/6

根據軟件項目規模的期望值e以及下列公式,就可以估算出軟件項目的成本和工作量。

生產率

pm = l / e

其中,l表示軟件項目的規模(單位:loc或者fp),e表示軟件工作量(單位:人月),pm表示單個人月能夠生產的功能點或者代碼行數。

平均成本

ckl = s / l

其中,s為軟件項目總開銷,l表示軟件項目的規模(單位:loc或者fp), ckl表示每行代碼或者每個功能點的平均成本。

對于一個特定的軟件開發組織或者項目組而言,其軟件生產率和平均成本在不同的軟件項目實施中可能是比較穩定的。如果有以往軟件項目的歷史信息,可以很容易地獲得關于軟件開發組織或者項目組的pm和ckl值。因此,一旦估算出了軟件項目的規模,獲得了軟件開發組織或者項目組的pm和ckl的值,就可根據公式ckl = s / l計算出軟件項目的成本s = ckl′ l,也可根據公式pm = l / e計算出軟件項目的工作量e= l / pm。

例如,假設項目組要開發一個軟件項目a,經過估算該項目的規模是364個功能點。進一步的,根據以往的歷史數據,該項目組軟件開發的生產率是8fp/人月,每個功能點的平均成本為12000元人民幣,那么該軟件項目的開發成本s = 6800元人民幣′ 364 = 247,5200元人民幣,工作量為e= 364/ 8 = 45.5人月。

基于經驗模型的估算

基于經驗模型的估算根據以往軟件項目實施的經驗數據(如成本、工作量和進度等)建立相應的估算模型,并以此為基礎對軟件項目開發的有關屬性進行估算。構造性成本模型cocomo(constructive cost model)是目前應用最為廣泛的經驗模型之一。

在二十世紀七十年代后期,boehm對多達63個軟件項目的經驗數據進行了分析和研究,在此基礎上于1981年提出了cocomo模型用于對軟件項目的規模、成本、進度等方面進行估算。boehm把cocomo模型分為基本、中間和詳細三個層次,分別支持軟件開發的三個不同階段。基本cocomo模型用于估算整個軟件系統開發所需的工作量和開發時間,適合于軟件系統開發的初期。中間層次的cocomo模型用于估算各個子系統的工作量和開發時間,適合在獲得各個子系統信息之后對軟件項目的估算。詳細層次的cocomo模型用于估算獨立的軟構件,適合在獲得各個軟構件信息之后對軟件項目的估算。由于篇幅限制,本書僅介紹基本cocomo模型,其模型形式描述如下。

e = a * (kloc)b 。其中e是軟件系統的工作量(單位:人月) ,a和b是經驗常數,其取值見表 7,kloc是軟件系統的規模(單位:千行代碼)。該公式描述了軟件系統的規模與工作量之間的關系。

d = c * ed。其中d是開發時間(單位:月),c和d是經驗常數,其取值見表 7。該公式描述了軟件系統的開發時間與工作量之間的關系。

cocomo模型是一個綜合經驗模型,它考慮了諸多因素,因而是一個比較全面的估算模型。cocomo模型有許多參數,其取值來至于經驗值。該估算模型比較實用、易于操作,在歐盟國家應用較為廣泛。

例如,針對上面所述的軟件項目a,如果已估算出該項目的軟件規模是33.3kloc,而且該項目屬于半獨立型,即cocomo模型中的參數a、b、c、d的取值分別是3.0、1.12、2.5、0.35,那么根據模型公式e =a * (kloc)b可以估算出該項目的工作量是3.0*(33.3)1.12,即152人月;然后根據公式d = c * ed可以估算出該項目的開發時間是2.5*(152)0.35,即14.5月。

2. 其它估算方法

其它估算方法包括:專家估算、類比估算等等。

專家估算方法是由一組專家來對軟件項目所需的成本、工作量和進度等進行估算。一般地,這些專家具有應用領域或者開發環境方面的知識、參與了以往類似軟件項目的開發。為了避免專家估算的片面性,專家估算方法一般要求每位專家給出估算的最小值a、可能值m和最大值b,然后計算出每位專家估算的平均值esti =(a+4m+b)/6,最后根據各位專家的估算情況計算出最終的估算值est=(est1+est2+est3+……+estn)/n。如果軟件開發組織或者項目組擁有一批經驗豐富的專家,可以考慮采用該方法。專家估算方法具有人為因素多、主觀因素大的特點,一般應用于軟件開發的初期階段,此時軟件項目組往往難以獲得估算軟件項目所需的各種數據和信息。

類比估算方法是指估算人員根據以往類似軟件項目實施所積累下來的數據,通過分析待開發軟件項目和以往軟件項目二者之間的相似性,估算出軟件項目的開發工作量、成本和進度等。使用該方法的前提是:待估算的軟件項目和以往的軟件項目必須具有一定的相似性(如它們均屬于同樣的應用領域),并且擁有以往類似軟件項目的開發數據(如工作量、周期、參與的人數、規模和成本等)。

軟件估算發生在事前,因而估算的結果與實際的結果有所偏差是不可避免的。但是,如果估算的偏差過大,那么估算的結果將會對軟件項目的實施和管理產生消極的影響,甚至可能導致軟件項目的失敗。因此,在對軟件項目的規模、成本和工作量等進行估算的過程中,要避免低劣的估算,盡可能地獲得合理和準確的估算數據。

中国北京单场足球彩票