Table of Contents
FPA估算的 項目規模，是指軟件開發的項目規模，包含了需求分析、設計、編碼、測試 等活動，但不包含項目管理，軟件維護等支持性且因項目要求的不同而差異加大的活動。
用戶需求分為 功能性用戶需求和非功能性用戶需求，IFPUG 和 NESMA 用來估算 功能性用戶需求的規模； 而SNAP 用來估算 非功能性用戶需求的規模
國內的行業標准，有使用 IFPUG 方法的，也有是 NESMA 方法的； 需要注意二者的差異和聯系
估算軟件開發成本的總體思路是：
1，先估算出規模，估算法方法可以選用其中一個
A，NESMA快速估算， 項目早期，需求不明朗，文檔不全
B， NESMA估算，項目中期，需求清晰，文檔較全
C， NESMA詳細估算，項目完全，需求完成，文檔完備
D， IFPUG 估算
2，然后使用方程 工作量 = 規模/ 生產率， 計算得出工作量
3，基於工作量計算開發成本
術語
功能點 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.
國標/行業標准所描述的功能點估算規范，既有IFPUG ，也有 NESMA，2者在流程和規則上，大部分是相同的；主要差異是
- NESMA具有 2個簡易化模式，可以用於快速估算
- IFPUG 的處理過程比較復雜，沒有簡化模式
- IFPUG和NESMA在 調整因數的計算方法，是不同的。一個是 14項基本特征的影響值TDI， 另外一個是 5 項調整因子
- 對於非全新項目，NESMA可以在 FP計數時，就按 復用程度和修改類型進行估算 FP； 而 IFPUG 則需要 按 新增、轉換、變更 分別進行初估，分別計算調整因子
基本概念
- 應用邊界
- 基本處理過程
- 功能點
- 元素類型
應用邊界 application boundary
被度量軟件與用戶或者其他系統之間的界限
控制信息 Control Information
Control Information is data that influences an elementary process by specifying what, when or how data is to be processed.
基本處理過程 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. 自包含，並且使應用程序的業務處於一致狀態
Processing Logic
Processing logic is defined as any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function.
功能 function
功能分為 2 大類， 5種類型
- 數據功能
- 交易功能
-
數據 功能， 即 滿足內部或者外部數據需求的功能 ， 存儲數據的功能
- ILF 內部邏輯文件 【容納一組在本應用中由一個或者一組基本處理來維護的數據 】
- EIF 外部接口文件【容納一組在本應用中由一個或者 一組基本處理引用到的數據 】
"在這里，文件的概念並非是傳統意義的文件， 而是一組邏輯上相關聯的數據的集合。 "
-
交易 功能， 即 處理數據的功能
- EI 外部輸入
- EO 外部輸出
- EQ 外部查詢
識別交易功能時，要 按 基本處理 elementary process 的原則進行識別
元素類型 element type
用來估計功能的復雜度，從而為功能估算出合適的FP數
-
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.
- 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估算流程概覽 【ISO規范】
- 收集可用的文檔
- 確定計數類型【開發？、增強？、應用系統？】
- 確定計數范圍，邊界，以及用戶的功能性需求
-
度量數據功能
- 識別數據功能
- 識別 ILF和EIF
- 分別識別 ILF、EIF 的數據元素DET數量，記錄元素RET數量，使用《功能元素復雜度計算表》確定復雜度，基於復雜度確定功能點數
-
度量交易功能
- 識別每一個基本處理
- 確定唯一的基本處理
- 將交易功能分類為 EI、EO、EQ
- 識別 EI、EO、EQ的數據元素DET數量，引用文件類型RFT數量，使用《功能元素復雜度計算表》確定復雜度，基於復雜度確定 功能點數
- 度量轉換功能
- 度量增強功能
-
計算功能規模
-
開發類型公式： DFP = ADD + CFP // ADD 開發項目要交付給用戶的功能規模， CFP = conversion function point 轉換功能的規模
【 在開發完成后的應用系統的生命周期內，應用系統的 規模 計算為 AFP = ADD 】
-
增強類型公式： EFP = ADD + CHGA + CFP + DEL // CHGA 變更后的功能規模， DEL =deleted function point 刪除的功能的規模
【 在項目增強后，應用系統的 規模 計算為： AFPA = （AFPB +ADD + CHGA） - （CHGB +DEL） // CHGA 變更后的功能規模， CHGB 變更前的功能規模， AFPA 增強項目后的功能規模，AFPB 增強項目前的功能規模 】
-
- 將功能點計數記錄在案
- 報告功能點計數結果， 至此 IFPUG 流程結束
- 【依據SNAP】進行非功能性需求 的規模調整
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 Estimated方法 估算未調整的功能點數時，可以基於 復用程度、修改類型進行對各功能的 功能點數進行調整, 調整系數 為 復用程度系數* 修改類型系數
復用程度 |
系數 |
高 |
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 |
估算流程概覽【國內行業規范-NESMA】
-
規模估算
- 收集可得文檔
- 確定計數范圍和邊界識別功能用戶需求
- 度量數據功能
- 度量事務功能
- 計算功能規模
-
功能規模調整
依據行業數據，確定CF【規模變更調整因子】，使用公式 S = UFP * CF
-
工作量計算
AE = （PDR *S）*SWF * RDF
其中：PDR 為生產率，取行業數據， SWF軟件因素調整因子【完整性級別調整因子* 應用類型調整因子 *質量及特性調整因子】，RDF 開發因素調整因子【開發語言，開發團隊背景】
-
工期計算
D = 1.227 *（ AE/176）^0.404
在規模估算時， 根據 項目階段，使用不同的NESMA方法
- 項目匡算， 使用預估功能點，計算公式為 UFP = 35 * ILF + 15* EIF
-
項目概算，使用估算功能點，計算公式為 UFP = 10* ILF + 7 * EIF + 4 *EI + 5*EO + 4*EQ
在估算功能點時，要考慮復用程度，按 低/中/高 分類，各自取值為 1 、 2/3 、 1/3 各預設功能點值
-
項目階段，使用詳細功能點，計算公式為 UFP = ∑ ILF + ∑ EIF + ∑EI + ∑EO + ∑EQ
詳細功能點估算時，要計算 數據功能和交易功能的復雜度，基於復雜度計算 功能點，即得出各項功能的 功能點數
估算流程概覽【國內行業規范-IFPUG】
- 確定估算的類型
- 開發項目、升級項目、應用系統
- 識別分析范圍和應用邊界
- 識別分析范圍和應用邊界中的定義
- 定義應用邊界
-
計數數據功能
- 識別數據功能
- 識別ILF，EIF
- 確定復雜度，基於復雜度確定功能點
-
計數交易功能
- 識別基本處理
- 識別EI、EO、EQ
- 確定復雜度，基於復雜度確定功能點
-
確定調整系統
- 調整系數 VAF 基於 14個通用系統特性計算得出， 每個特性取值范圍0～5
- 14 個值相加，然后加上 0.65
-
計算調整功能點
-
開發項目： DFP = （UFP + CFP ） * VAF //
UFP 為應用在安裝以后向用戶提的 未經調整的功能點，
CFP 為額外的轉換功能的未經調解的功能點
-
升級項目： EFP = (ADD+CHGA+CFP)* VAFA +DEL*VAFB //
ADD = 升級項目中增加的未經調整的功能點
CHGA = 升級項目中改變的功能在改變后所具有的未經調整的功能點 CFP = 額外的轉換功能的未經調整的功能點
VAFA = 升級后的應用的調整系數
DEL = 被刪除的功能的未經調整的功能點
VAFB = 升級前的應用的調整系數
-
應用系統：
基線 AFP = ADD * VAF //
ADD = 安裝的功能的
UFPC VAF = 調整系數
應用升級后 AFP = [(UFPB+ADD+CHGA) – (CHGB+DEL)]*VAFA //
UFPB = 應用升級前的未經調整功能點
ADD = 新增功能的 UFPC
CHGA = 升級后的修改功能的 UFPC
CHGB = 升級前的修改功能的 UFPC
VAFA = 升級后的調整系數 【注意該公式中不包含轉換功能， 因為轉換功能與應用直接提供的功能無關 】
-
調整因素
國內ifpug標准
按 功能點計算出 工作量后，再 根據下面的14項系統基本特征 評分得出調整系數，然后進行調整
14項系統基本特征
- 數據通訊
- 分布式數據處理
- 性能
- 大業務量配置
- 交易處理率
- 在線數據輸入
- 最終用戶效率（用戶界面友好程度）
- 在線更新
- 復雜處理（算法）
- 可復用性
- 易安裝性
- 易操作性
- 多場地（多點運行）
- 支持變更（客戶化程度）
上面14項目每個項目的分值 從0 到 5分
計算公式是： ∑14項因子*0.01 + 0.65， 即14項目 加總后 * 0.01 + 0.65
國內NESMA方法
在估算功能點后，根據計數時機，按規模調整系數進行規模調整，從而確定 未調整的功能點
計數時機 |
系數 |
早期 |
1.39 |
中期 |
1.22 |
完成 |
1.0 |
估算出未調整的 功能點后，再 根據軟件因素，和開發因素，一共5項調整因素計算得出的調整系數，然后進行調整
計算公式是： ∏ 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，采用敏捷管理項目，比傳統的瀑布模式更有效率
本文是學習筆記，難免有理解的錯誤，歡迎指正