基於 功能點 估算項目規模 FPA


Table of Contents

術語

功能點 FP function point

基本概念

應用邊界 application boundary

基本處理過程 elementary process

功能 function

要素類型 element type

估算方法

IFPUG估算 ,流程和規則

NESMA估算 ,流程和規則

工作量計算

ifpug方法

NESMA方法

工期計算

軟件開發價格計算

結論

   

   

國標、行業標准,基本上都是在遵從 NESMA方法進行實踐的

   

術語

功能點 FP function point

功能的度量單位,用於度量軟件規模; 不等同於 功能,或者用戶需求; 一般場景下所說的 功能點,是 指功能 【功能亮點、或者功能突出點】

A Function Point (FP) is a unit of measurement to express the amount of business functionality, an information system (as a product) provides to a user. FPs measure software size. They are widely accepted as an industry standard for functional sizing.

   

功能點估算,主流有2種方法,IFPUG 和 NESMA,2者在流程和規則上,大部分是相同的;主要差異是

  • NESMA具有 2個簡易化模式,可以用於快速估算
  • IFPUG 的處理過程比較復雜,沒有簡化模式
  • IFPUG和NESMA在 調整因數的計算方法,是不同的。一個是 14項基本特征的影響值TDI, 另外一個是 5 項調整因子
  • 對於非全新項目,NESMA可以在 FP計數時,就按 復用程度和修改類型進行估算 FP; 而 IFPUG 則需要 按 新增、轉換、變更 分別進行初估,分別計算調整因子

   

   

基本概念

  • 應用邊界
  • 基本處理過程
  • 功能點
  • 要素類型

   

   

應用邊界 application boundary

被度量軟件與用戶或者其他系統之間的界限

   

基本處理過程 elementary process

對用戶來說是一個有意義的、最小的活動單元,並且是自包含的活動

Elementary Process is the smallest unit of functional user requirement that −

  • Is meaningful to the user.
  • Constitutes a complete transaction.
  • Is self-contained and leaves the business of the application being counted in a consistent state.

   

功能 function

   

功能分為 2 大類, 5種類型

  • 數據功能
  • 事務功能

 

  • 數據 功能, 即 滿足內部或者外部數據需求的功能 , 存儲數據的功能
    • ILF 內部邏輯文件 【容納一組在本應用中由一個或者一組基本處理來維護的數據
    • EIF 外部接口文件【容納一組在本應用中由一個或者 一組基本處理引用到的數據 】

       

    "在這里,文件的概念並非是傳統意義的文件, 而是一組邏輯上相關聯的數據的集合。 "

   

  • 事務 功能, 即 處理數據的功能
    • EI 外部輸入
    • EO 外部輸出
    • EQ 外部查詢

   

識別事務功能時,要 按 基本處理 elementary process 的原則進行識別

   

   

要素類型 element type

   

對 數據功能,進一步按 對 要素類型進行識別計數 ,識別出 相關數據功能的復雜程度,以便基於復雜度 確定功能點數

  • DET data element type / 數據要素類型,為 唯一、用戶可識別、不重復的屬性,即字段 //Data Element Type (DET) is the data subgroup within an FTR. They are unique and user identifiable.
  • RET record element type / 記錄要素類型,為 用戶可識別的 DET 的子集【部分】, 例如, 主從類型的數據模式, 訂單,訂單行, 要識別為 2個 RET, 訂單自身是1個RET,訂單行 是1個RET //A Record Element Type (RET) is the largest user identifiable subgroup of elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them.

       

對於 事務功能,進一步對 要素類型進行識別計數,識別出 相關事務功能的復雜程度,以便基於復雜度確定 功能點數

  • DET data element type / 數據要素類型,為 唯一、用戶可識別、不重復的屬性,即字段
  • FTR file type referenced / 引用文件類型,被事務功能讀取或者維護的數據功能, 是被事務功能 讀取或者維護的 ILF,或者是被事務功能 讀取的 EIF, 例如, 訂單業務中,創建確認訂單並建立交貨單,要識別為2個FTR,訂單自身是1個FTR,還需要將 交貨單識別為1個FTR //File Type Referenced (FTR) is the largest user identifiable subgroup within the EI, EO, or EQ that is referenced to.

   

估算方法

IFPUG估算 ,流程和規則

  • 識別 EI
  • 識別 EI 的數據要素DET數量,引用文件類型RFT數量,確定復雜度,基於復雜度確定 功能點數
  • 依次 識別 EO、EQ
  • 識別 ILF和EIF
  • 分別識別 ILF、EIF 的數據要素DET數量,記錄要素RET數量,確定復雜度,基於復雜度確定功能點數
  • 所有的功能的功能點數加總得出 未調整的功能點數
  • 基於 14項基本特征的影響值TDI,計算調整因子 VAF=0.65 +TDI*0.01
  • 步驟6 確定的功能點數 乘以 調整因子,得出 調整后的功能點

   

NESMA估算 ,流程和規則

  • 識別 功能點,確定 復用程度和修改類型
  • 根據所處的估算時機,進行規模調整,得出未調整的 功能點
  • 基於調整因子進行調整,得出調整后的 功能點

   

在進行計數實踐的時候,按照估算的時機,或者文檔的完備性,可以分為 3 種估算方法

   

  • 1, Indicative方法, 預估功能點【用於項目早期】,

    只 用識別出 數據功能,即 ILF 和 EIF 的數量

    然后 按 公式 35*ILF + 15* EIF 計算出 未調整的功能點數

       

    Indicative方法基於如下假設:

       

    平均情況下,每個ILF對應3個EI(對應添加、修改、刪除這三個操作)、2個EO(對應兩種統計報表操作)和1個EQ(對應查詢操作);

    平均情況下,每個EIF對應1個EO和1個EQ;

    公式中的35和15這兩個權重,則是全部ILF、EIF的復雜度默認為"低",EI、EO、EQ的復雜度默認為"中",再考慮系統整體的功能性得出的。???

       

  • 2, Estimated方法, 估算功能點【用於項目中期】 ,

    識別出 數據功能,以及 事務功能, 即 ILF 和 EIF 的數量 以及 EI、EO、EQ的數量

    然后 按公式 10*ILF + 7* EIF + 4*EI + 5*EO + 4*EQ 計算出 未調整的功能點數

       

  • 3,詳細功能點【用於項目后期】

    識別5類功能的功能個數

    識別各功能的功能要素,基於功能要素的數量,使用《功能要素復雜度計算表》確定各個功能的復雜程度,根據《功能點數與復雜度之間的對應關系》 查出相應功能的 功能點數

    匯總所有的功能點數為 未調整的功能點數

   

Indicative方法 和 Estimated方法,均是 是 詳細功能點估算方法 的簡化。

Estimated方法 就是 按中等復雜度進行估算

   

使用NESMA估算未調整的功能點數時,可以基於 復用程度、修改類型進行對各功能的 功能點數進行調整, 調整系數 為 復用程度系數* 修改類型系數

復用程度

系數

1/3

2/3

1

   

修改類型

系數

新增

1

修改

0.8

刪除

0.2

   

   

   

功能要素復雜度計算表

   

功能點數與復雜度之間的對應關系

功能點數

功能

  

  

  

  

復雜度

ILF

EIF

EI

EO

EQ

7

5

3

4

3

10

7

4

5

4

15

10

6

7

6

   

   

工作量計算

計算公式: 工作量 = 功能點 * 基准生產率

   

ifpug方法

按 功能點計算出 工作量后,再 根據下面的14項系統基本特征 評分得出調整系數,然后進行調整

   

14項系統基本特征

  • 數據通訊
  • 分布式數據處理
  • 性能
  • 大業務量配置
  • 事務處理率
  • 在線數據輸入
  • 最終用戶效率(用戶界面友好程度)
  • 在線更新
  • 復雜處理(算法)
  • 可復用性
  • 易安裝性
  • 易操作性
  • 多場地(多點運行)
  • 支持變更(客戶化程度)

   

上面14項目每個項目的分值 從0 到 5分

計算公式是: 14項目 加總后 * 0.01 + 0.65

   

NESMA方法

   

在估算功能點后,根據計數時機,按調整系數進行調整,從而確定 未調整的功能點

計數時機

系數

早期

1.39

中期

1.22

完成

1.0

   

按 功能點計算出 工作量后,再 根據下面5項調整因素計算得出的調整系數,然后進行調整

計算 公式是: 5 項得分 相乘

   

因素

得分范圍

應用類型

1.0~2.0

質量特性

0.9~1.1

完整性級別

1.0~1.3

開發語言

0.6~1.5

開發團隊背景

0.8~1.2

【 質量特性有4個維度,總體上應該是 8 個調整因素】

   

應用類型

應用類型

描述

調整因子

業務處理

辦公自動化系統、日常管理及業務處理用軟件等

1.0

應用集成

企業服務總線、應用集成等

1.2

科技

科學計算、仿真、基於復雜算法的統計分析等

1.2

多媒體

多媒體數據處理;地理信息系統;教育和娛樂應用等

1.3

智能信息

自然語言處理、人工智能、專家系統等

1.7

系統

操作系統、數據庫系統、集成開發環境、自動化開發/設計工具等

1.7

通信控制

通信協議、仿真、交換機軟件、全球定位系統等

1.9

流程控制

生產管理、儀器控制、機器人控制、實時控制、嵌入式軟件等

2.0

   

質量特性

調整因子

判斷標准

調整因子

分布式處理

沒有明示對分布式處理的需求事項

-1

  

通過網絡進行客戶端/服務器及網絡基礎應用分布處理和傳輸

0

  

通過特別的設計保證在多個服務器及處理器上同時相互執行應用中的處理功能

1

性能

沒有明示對性能的特別需求事項或僅需提供基本性能

-1

  

應答時間或處理率對高峰時間或所有業務時間來說都很重要,存在對連動系統結束處理時間的限制

0

  

為滿足性能需求事項,要求設計階段開始進行性能分析,或在設計、開發階段使用分析工具

1

可靠性

沒有明示對可靠性的特別需求事項或僅需提供基本的可靠性

-1

  

發生故障時帶來較多不便或經濟損失

0

  

發生故障時造成重大經濟損失或有生命危害

1

多重站點

在相同的硬件或軟件環境下運行

-1

  

在設計階段需要考慮不同站點的相似硬件或軟件環境下運行需求

0

  

在設計階段需要考慮不同站點的不同硬件或軟件環境下運行需求

1

質量因子 計算公式

質量系數 = 1 + 0.025* 以上調整因子之和

   

完整性級別

完整性級別

調整因子

沒有明確的完整性級別或等級為C/D

1.0

完整性級別為A/B同時為達成完整性級別要求采取了特殊的設計及實現方式

1.1

完整性級別為A同時為達成完整性級別要求在軟件開發全生命周期均采取了特定、明確的措施

1.3

   

開發語言

開發語言

調整因子

C及其他同級別語言/平台

1.5

JAVA、C++、C#及其他同級別語言/平台

1.0

PowerBuilder、ASP及其他同級別語言/平台

0.6

   

開發團隊背景

開發團隊背景

調整因子

為本行業開發過類似的軟件

0.8

為其他行業開發過類似的軟件,或為本行業開發過不同但相關的軟件

1.0

沒有同類軟件及本行業相關軟件開發背景

1.2

   

   

例如, 使用NESMA 估算功能點法,估算出 功能點為 345.87 , 經規模調整后為 480.75 , 基准生產率為7.10 人時/功能點 , 那么 工作量 = 480.75 功能點 * 7.10 人時/ 功能點 =3,413.325 人時 【480.75*7.10=3,413.325 人時 】 = 3,413.325/8 = 426.6656 人天

   

【規模調整因子是 根據估算時機確定的,上例是 以早期 1.39 取值的】

   

例如, 調整因子 得分如下

應用類型

1.00

質量特性

1.08

完整性級別

1.30

開發語言

0.60

開發團隊背景

1.00

   

調整系數 為 1*1.08 * 1.3 *.6 * 1 = 0.8424

   

所以調整后的 工作量 = 426.6656 人天 * 0.8424 = 359.4231 人天

   

【基准生產率可以查行業數據,一般取中位數】

   

工期計算

   

工期 = 1.277 * ( 工作量 /176 ) ^ 0.404

【 此公式 中工作量的單位是 人時, 工期的單位是 月】

   

例如, 工作量為 359.4231 人天 , 轉換為 人時 為 3,413.325 人時, 計算得出 工期 為 1.227*( 3,413.325/176)^0.404=4.065 即 工期為 4.065 月

   

進一步 估算團隊規模: 359.4231 人天 = 359.4231/22= 16.3374 人月, 16.3374 人月 / 4.065 月 = 【 16.3374/4.065 】 4.019 人

   

   

軟件開發價格計算

   

軟件開發價格 = 開發工作量 * 開發費用/ 人月

其中:

開發工作量 = 估算工作量 * 風險系數 * 復用系數

開發費用/人月 = 【工資 + 國家規定的福利 + 獎金以及獎勵 + 辦公成本 + 人力資源成本 + 設備/基礎設施 + 稅金和利潤 】 * 管理系數 * 優質系數

國家規定的福利 = 工資 * 0.476

獎金以及獎勵 = 工資 * 1/5

辦公成本 = 工資 * 1/3

人力資源成本 = 工資 * 1/5

設備/基礎設施 = 工資 * 0.15

稅金和利潤 = 工資 * 1/3

   

管理系數 取值於 1~ 1.2

優質系數 按 ISO9000 質量 或者 CMMI 認證確定,分別取值 1.05, 1.1,1.2,1.3

   

一般 綜合下來, 按 平均月薪 * 3.23 作為開發費用/人月

   

人月開發費用,也可以采取 行業基准數據, 例如 2019年軟件開發行業基准人月單價 2.8767 萬元 /人月, 不包含 直 接非人力成本

   

繼續 上例 359.4231 人天 換算為 人月, 為 359.4231/21.75=16.5252 人月,軟件開發價格為 47.538 萬 【 16.5252 * 2.8767=47.538 】

   

如果采用 月平均工資 * 3.23, 例如 月平均工資為 1.5W , 則軟件開發價格為 80.0646 萬 【 16.5252*1.5 *3.23 = 80.0646 】

   

   

注意, FPA 方法是按 瀑布模式 運作項目的,如果是采用敏捷模式,工作量上應該要少很多。。。

   

   

   

   

   

對於系統集成項目

   

   

   

結論

前面部分所述的是軟件開發部分, 軟件開發之后,還需要進行 實施、運維支持,也存在相應的費用。

   

基於 Odoo 開發應用系統,存在3個優勢

1,Odoo自身原本擁有大量的 應用

2,Odoo框架的 復用程度高

3,采用敏捷管理項目,比傳統的瀑布模式更有效率

   

   

本文是學習筆記,難免有理解的錯誤,歡迎指正

   


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM