以下文章來源于信息化與數字化 ,作者陳曉明
來源:信息化與數字化
導讀: 本文我們就來看看常用的估算方法都有哪些,業界又是怎么來做的呢。
(相關資料圖)
一.工作量評估概述
長期以來,如何度量軟件研發成本一直是軟件業界的難題,科學、統一的軟件研發成本度量標準既是有效進行軟件項目管理的重要依據,也是當前軟件產業發展的迫切需要。很多軟件行業從業人員感嘆道,這么高科技的行業,在成本預算的確定性、開發速度和組織效能上,甚至還遠遠不如看起來很傳統的建筑制造行業。一座摩天大樓可能在半年內就可以建好,而一個大型軟件開發時間可能要好幾年,并且隨著時間的變長項目失敗率會越高。
缺乏成本度量依據及成本控制,可能在項目生命周期的各個階段造成影響,如:在預算階段,會造成預算浪費或預算不足;招投標階段,可能出現惡意競標或低價中標;在項目實施階段,引發項目變更或成本超支。
但在實際情況中,軟件工作量評估也面臨著各種各樣的問題,如:項目范圍不確定、沒有可以參考的歷史項目、項目個性化多、評估結果不斷被質疑等等。那么如何在現狀基礎之上,做好軟件規模評估這件事呢?國際著名軟件工程專家-Caper Jones曾說過:良好的估算方法和可靠的歷史數據提供了最好的希望,現實將戰勝不可能的要求。
下面,我們就來看看常用的估算方法都有哪些,業界又是怎么來做的呢。
二.常用評估方法
目前,常用的評估方法包括如下幾大類:專家法、類推/類比法、方程法,其中,專家法常用的是WBS拆分法、Delphi法;類推/類比法會基于類似的歷史項目或一組基準數據做估算;方程法要基于基準數據建模,并會與行業、企業數據相結合對模型不斷調優,同時從功能視角、技術視角將方法劃分為兩大類。
1. 專家法-WBS拆分法
含義:即項目結構拆分估算法,將項目或產品分解為具體的工作,然后分別對各個工作進行時間估算,最終求和得出項目或產品的總工作量。
適用場景:適用于實施階段,有詳細的需求說明書作為依據的項目。
如:(1)項目實施階段排期、分工;(2)存量項目二期/三期的售前評估。
2. 專家法-Delphi法
含義:由多種相關經驗的人共同參與,各人進行估算,然后匯總討論,最終得出一個綜合后的結果;
適用場景:適用于輸入的材料不足,需求模糊的模塊或項目。
如:(1)售前階段,一句話需求;(2)新產品類型項目。
3. 類推/類比法
含義:指將本項目的部分屬性與高度類似的歷史項目或一組基準數據進行比對,進而獲得待估算項目工作量、工期或成本估算值的方法。
適用場景:與本項目有類似屬性,如:規模、業務領域、應用場景、復雜度、開發團隊經驗等。
如:與資金方對接、外部系統對接等。
4. 方程法
含義:基于基準數據建模,結合行業數據、企業數據對模型不斷迭代優化,最終計算出項目工作量、成本。
適用場景:輸入的材料較完整,有詳細的需求描述、用例描述等。
如項目實施階段,有需求說明書、設計文檔作為輸入材料。
在方程法中,按照功能視角、技術視角進一步劃分為兩個類別,其中功能視角包括,功能點評估方法(Function Point Analysis,下文簡稱FPA)、對象點、用例點、故事點等;技術視角包括,代碼行、數據庫表、函數數量等。在上述方法中,應用最廣泛的為功能點FPA。
該方法由Allan J. Albrecht于1970s在IBM提出,主要應用在金融科技領域。在1980s、1990s逐步形成國際標準,廣泛應用于金融、電信、政府等領域,并在日本、韓國、荷蘭等國使用該方法作為政府軟件采購的依據。2000s,國內引入功能點方法,迅速在金融、能源、電信等各領域推廣,尤其國內銀行業,已普遍采用該方法度量軟件規模,如中國銀行、中國農業銀行、交通銀行、國開行、招商銀行、平安銀行、郵儲銀行、南京銀行、天津銀行等。
中國電子技術標準化研究院、北京軟件造價評估技術創新聯盟和北京軟件和信息服務交易所聯合發布的《中國軟件行業基準數據》文檔里也有關于不同行業和地區的軟件行業的一些基準數據,有興趣的同學可以參考下。
中國軟件行業基準數據
5. 小結
我們再回顧一下軟件評估的常用方法:WBS拆分法、Delphi專家法、類推/類比法、功能點FPA,在這么多方法中,前幾個都屬于通用類方法,可以應用在各行各業,如:建筑業的造價評估、石油勘探鉆井預測等。但只有FPA是專門針對軟件造價評估的方法,且考慮其在金融科技領域已經得到廣泛應用,所以下面我們具體看一看什么是FPA方法。
三.功能點評估方法FPA
含義:從用戶視角出發,對軟件的規模從邏輯設計的角度進行度量的標準方法。該方法將系統分為數據功能和事物功能兩大類,分別根據具體的規則來計算功能點,最后結合系統的特征因子來調整功能點數,從而得到最終的系統規模。
適用場景:輸入的材料較完整,有詳細的需求描述。
可能有點抽象,下面我們一點點展開:
1. 什么是功能點
(1)度量單位
功能點是度量軟件規模的一種單位,例如生活中我們采用平方米度量房子的面積,用斤或千克來度量體重一樣。
(2)用戶視角
在評估過程中,它是從用戶視角出發,強調用戶能感知的業務價值。比如我們在信貸系統、供應鏈系統中常見的“客戶管理”模塊,系統操作用戶是能切切實實感知到客戶信息存在的,用戶點擊【新增】【查詢】按鈕,是能感知到信息流變化的。
(3)核心思想
核心思想:一是系統維護的信息;二是系統處理的復雜度。
(4)國際標準
目前已形成5個國際標準,其中在國內應用最廣泛的是IFPUG和NESMA:
l IFPUG 國際功能點用戶組
lCOSMIC 通用軟件度量國際聯盟
l Mk II 英國軟件度量協會
l NESMA 荷蘭軟件度量協會
lFiSMA 芬蘭軟件度量協會
2. FPA概述
下圖很好的詮釋了FPA的核心思想,中間藍色框表示我們待評估的系統,其自身維護了很多的業務數據,稱之為內部邏輯文件(ILF)。與外部的交互包括兩種場景,一是用戶,二是外圍系統。在與外部交互過程中,進一步細分為兩個層面,一是外部去觸發、輸入信息,本系統做出相應的響應,即對應評估結果的基本過程(EI、EO、EQ);二是本系統與其他系統對接時,需要調用外圍系統信息,這些信息本身是外部系統的內部邏輯文件,對應本系統稱之為外部接口文件(EIF)。以上就構成了FPA評估的所有基礎組件,從中我們也可以看出,FPA是從用戶視角出發去評估,即系統能向外提供(或輸出)的功能價值。這也間接的說明了,該方法論不適用于非功能性需求、AI等新興技術開發為主的規模度量。
3. FPA計數過程
在FPA評估過程中,其實就是對輸入文檔(需求、設計文檔等)進行如下5種基礎功能組件的分解計數,確定復雜度,再確定權重值。
第一步:計數
(1)邏輯文件
① ILF(內部邏輯文件):在本系統維護的業務數據、業務規則。
可以通俗的理解為,系統后臺維護的數據表,但并不是全部數據表。因為本方法的設計理念是從用戶視角出發,因此維護的這些數據是要能被用戶感知到的實體表,如客戶信息表、賬戶信息表、借據表等,而處理過程中所設計的中間表、配置表等不納入ILF計數范圍。
② EIF(外部接口文件):本系統引用,在其他系統維護的數據。
我們與外部系統對接,會引用外部的信息,這些文件本身是外部系統的ILF,對于本系統而言,計入EIF。
(2)基本過程
由一個觸發事件引起,系統進入穩定狀態作為一個標志。因此,在識別基本過程時,一定要找到觸發事件,比如用戶點擊的一個按鈕或日終的定時任務等,但最終系統都要進入一個穩定的狀態,這樣才算一個完整的基本過程。分為如下3類:
① EI(外部輸入):由外部輸入,并對內部邏輯文件進行維護或改變系統行為的事務。
舉例:點擊【新增】【修改】按鈕,新增或修改一個客戶信息,均算作EI。
② EO(外部輸出):對數據加工后呈現或輸出的事務。
舉例:按月計提臺賬查詢或導出,該臺賬在生成過程中,并不是簡單的將后臺數據表直接輸出(select *from...),而是需要進行邏輯計算、數據加工,這種情況算作EO。
③ EQ(外部查詢):對已有數據直接呈現或輸出的事務。
舉例:客戶信息查詢功能,直接把數據庫中存的數據原封不動的展示出來,沒有做任何的加工處理,算作EQ。
說明:在實際規模估算過程中,某一個事務算作EO/EQ/EI并不是特別關鍵,因為他們的權重區別并不是很大。重要的是要數全了,不要漏~~~
第二步:確定重用程度、修改類型
識別出邏輯文件或基本過程后,需要確定每一項的重用程度、修改類型:判斷本事務與原有系統功能的重用程度(高、中、低);然后再確定其修改類型(新增、修改、刪除)。
下圖為評估示例:
4. 工作量計算過程
FPA計數完成后,我們最終是要獲得待評估系統/項目的工作量,整體計算過程如下:
功能組件權重映射表:
計算過程如下表所示:
5. 方法特點與推廣
我們總結一下FPA方法的特點:
(1)客觀性:對比專家法、類推法,相對能減少主觀偏差。
(2)輸入文件:輸入的材料較完整,有詳細的需求描述、用例描述等。
(3)適用場景:有清晰、明確輸入的功能性需求,如實施階段或存量項目二期,不太適合新項目售前階段的一句話需求;不適用于非功能性需求及新興技術開發為主的成本評估;也不太適合那種交互單一但是難度高的場景,例如復雜的算法,風控模型,安全防控,高標準的基礎架構層等。
(4)學習成本:雖已對功能點分析法進行精簡,但仍有較大的學習、培訓成本。
(5)溝通成本:原始需求功能與工作量沒有直觀對應,對未接觸過該方法論的同學理解難度大,溝通成本高。
(6)評估投入成本:拆解過程需要考慮細致的設計實現方式,需要花費的時間、精力較多。
四.總結
最后,我們對常用的評估方法進行對比,大家會發現沒有萬能的評估方法,每一種方法都有其適用的場景,并均有所限。在條件允許的情況下,我們可以進行交叉驗證。
隨著軟件工程領域的數字化不斷深入,工作量評估的精度也在穩步提升。舉例來說,設計工程師現在可以利用Figma等工具,與客戶緊密合作,共同塑造交互性極強的設計。而在編碼環節,團隊成員通過使用Vscode等在線代碼編輯器共享工作空間,彼此協同以提升編碼效率。此外,通過自動化測試以及眾多的RPA(Robotic Process Automation)工具,我們能夠及時發現產品的Bug,而且還能記錄下每個功能點的完成時間和效率,從而積累大量寶貴的數據,為工作量評估提供強有力的參考。
進入GPT大模型的時代,AI的作用更是不可或缺。開發團隊現在可以借助AI生成代碼,甚至是完整的軟件和產品。AI模型的崛起無疑將重塑行業標準。想象一下,當用戶能夠清晰地描述他們的奇思妙想和設計構想時,AI成本估算模型能夠在短時間內提供一個大致的成本評估。而后,這些信息可以交由高度專業化的AI交付模型來執行開發工作,或者,根據成本評估,在市場上尋找最符合要求的開發團隊來實現這些構想。數字化工具和AI的結合正在為軟件工程注入新的活力,使工作量評估更加精準,開發過程更加流暢,而產品的創新和質量也得以提升。
參考資料
[1]張旸旸,王海青,蔡立志,等.軟件成本度量標準實施指南[M].北京:清華大學出版社,2017.
[2]王海青等,軟件研發成本度量規范釋義[M].北京:機械工業出版社,2014.
關鍵詞: