計算調整因子
功能點的調整係數是經過通用系統特性及其影響程度來評定的,對每一個常規系統特性的評估由其影響程度(DI)而定,分爲0-5級:
0 毫無影響
1 偶然影響
2 適度影響
3 通常影響
4 重要影響
5 強烈影響html
而後依次對如下14個系統常規特性進行打分,並帶入如下計算公式算出功能點的調整因子。
Value Adjustment Factor=( sum of (DI) * 0.01 ) + 0.65前端
1. 數據通信算法
數據通信指的是應用程序直接與處理器通信的程度。一般咱們都是經過某種通信手段來實如今一個應用中所使用的數據或者控制信息的。鏈接到本地控制器上的終端被認爲是使用通信設施,而協議指的是兩個系統或者兩個設備之間進行通信時所使用的一種約定。全部的數據通信連接都須要某種協議。
數據庫
0安全 |
應用程序是單純的批處理或者PC stand-alone數據結構 |
1分佈式 |
應用程序是一種批處理過程,可是包含遠程數據的錄入或遠程打印工具 |
2post |
應用程序是一種批處理過程,可是包含遠程數據的錄入和遠程打印性能 |
3 |
應用程序包括在線數據收集或者包括批處理或查詢系統的遠程處理的前端應用 |
4 |
應用程序不單只是前端應用,可是僅支持一種遠程處理通信協議 |
5 |
應用程序不單只是前端應用,還支持多於一種的遠程處理通信協議 |
2. 分佈式數據處理
分佈式數據處理是應用在內部組件之間傳遞信息的程度。這個特性是在應用邊界內體現的。
0 |
應用程序不支持組件之間的數據傳輸和處理功能 |
1 |
應用程序爲用戶可能進行的處理準備數據(例如使用電子表格或者數據庫等) |
2 |
應用程序所準備的數據是爲了在系統另一個組件上傳輸和處理。並不是爲終端用戶所處理。 |
3 |
分佈式處理和數據傳輸是在線的,而且是單向的 |
4 |
分佈式處理和數據傳輸是在線的,而且是雙向的 |
5 |
由系統中最恰當的組件動態地執行處理功能 |
3. 性能
性能是吞吐量、處理時間等指標對開發的影響。用戶所提出的性能要求將直接影響到系統的設計,實施,安裝和支持。
0 |
用戶沒有提出性能方面的要求 |
1 |
用戶提出了性能和設計方面的要求,但不須要採起特定措施 |
2 |
響應時間和吞吐量在系統峯值時是關鍵的,可是不須要採起相應的CPU 使用方面的特殊設計。處理的最後期限是在下一個工做日。 |
3 |
在任什麼時候候響應時間和吞吐量都是關鍵的,可是不須要採起相應的CPU 使用方面的特殊設計。處理的完成期限比較嚴格 |
4 |
除了上面一項的要求外,因爲對需求的要求比較嚴格,在設計階段就要進行性能分析 |
5 |
除了上面一項的要求以外,在設計和實施階段須要使用性能分析工 具來判斷性能要求的完成狀況 |
4. 大業務量配置
大業務量配置指的是計算機的資源對應用開發的影響程度。大業務量的運行配置對設計有特殊要求,是必須考慮的一個系統特性。
0 |
沒有提出明確的運行方面的限制 |
1 |
有運行方面的限制,可是不須要採起特別的措施以知足運行限制 |
2 |
提出了一些安全和時間方面的限制 |
3 |
應用程序的某些部分對處理器有特定的要求。 |
4 |
提出的運行限制對應用的中央處理器或者專用處理器有特殊的要求 |
5 |
除上面一項以外,還對應用的分佈式組件提出了限制 |
5. 事務處理率
事務處理率是業務交易處理速度的要求對系統的設計,實施,安裝和支持等的影響。
0 |
預計不會出現週期性的高峯事務處理期 |
1 |
預計會有周期性的高峯事務處理期(例如:每個月、每季、每一年) |
2 |
預計每週都會出現高峯事務處理期 |
3 |
預計天天都會出現高峯事務處理期 |
4 |
用戶在應用程序需求或者服務級別協議中對事務率要求很高,所以必須在設計階段進行性能分析。 |
5 |
用戶在應用程序需求或者服務級別協議中對事務率要求很高,所以必須進行性能分析並在設計、開發和安裝階段中使用到性能分析工具。 |
6. 在線數據輸入
在線數據輸入是指數據經過交互的方式輸入系統程度。系統中包括在線數據輸入和控制信息功能。
0 |
全部事務都是批處理的。 |
1 |
1%~7%的事務是以交互式的方式進行數據錄入 |
2 |
8%~15%的事務是以交互式的方式進行數據錄入 |
3 |
16%~23%的事務是以交互式的方式進行數據錄入 |
4 |
24%~30%的事務是以交互式的方式進行數據錄入 |
5 |
30%以上的事務是以交互式的方式進行數據錄入 |
7. 最終用戶效率
最終用戶效率是指對應用的人文因素以及使用的便捷方面的考慮程度。
以下功能設計是針對最終用戶效率的:
頁面導航Ø
菜單Ø
在線幫助或文檔Ø
光標自動跳轉Ø
能夠滾動Ø
在線遠程打印Ø
預約義的功能鍵Ø
在線作批量提交任務Ø
光標能夠選取界面上的數據Ø
用戶使用大量反白顯示、重點顯示、下劃線或其餘的標識Ø
在線copy用戶文檔Ø
鼠標拖動功能Ø
彈出窗體Ø
使用最少的界面完成某種商業功能Ø
雙語言支持(若是選擇了這個就算4項)Ø
多語言支持(若是選擇了這個就算6項)Ø
0 |
以上的一個都不包括 |
1 |
包括以上的1~3個 |
2 |
包括以上的4~5個 |
3 |
包括以上的6個或以上,可是沒有用戶對於效率的要求 |
4 |
包括以上的6個或以上,對用戶使用效率有較高要求,於是必須考慮用戶方面的設計(例如,最少擊鍵次數、儘量提供默認值、模版的使用) |
5 |
包括以上的6個或以上,用戶對效率的要求使得開發人員必須使用特定的工具和流程以斷定用戶對效率的要求已經被達成 |
8. 在線更新
在線更新是指內部邏輯文件ILF 被在線更新的程度。應用系統提供在線更新內部邏輯文件的功能。
0 |
沒有在線更新 |
1 |
包含1~3 個控制文件的在線更新。更新的流量低,恢復容易 |
2 |
包含對4 個以上控制文件的在線更新。更新的流量低,恢復容易 |
3 |
包含對主要ILF 的更新 |
4 |
除了3 以外,在設計和實施中要考慮對數據丟失的防範。 |
5 |
除了4 以外,大量的數據恢復工做要考慮成本因素,同時包含了高度自動化的恢復流程。 |
9. 複雜處理
複雜處理描述了邏輯處理對應用開發的影響程度。 它包含如下要素:
敏感控制(例如特殊的審覈過程)和/或程序特定的安全處理Ø
大量的邏輯處理Ø
大量的數學處理Ø
由於例外處理形成的須要從新處理的狀況(例如,由TP中斷、數據值缺乏和驗證失敗致使的ATM事務)Ø
多種可能的輸入/輸出形成的複雜處理
0 |
上面一個都不知足 |
1 |
只知足一個 |
2 |
只知足兩個 |
3 |
知足三個 |
4 |
知足四個 |
5 |
都滿 |
10. 可複用性
應用系統中的應用和代碼通過特殊設計、開發和支持,能夠在其餘應用系統中複用。
0 |
沒有可複用的代碼 |
1 |
代碼在應用以內複用 |
2 |
應用中被其餘用戶複用的部分不足10% |
3 |
應用中被不止一個用戶使用的部分超過10% |
4 |
應用聽從一種易於複用的方式被打包和文檔化。用戶在源代碼級客戶化該應用 |
5 |
應用按照一種易於複用的方式被打包和文檔化。用戶使用用戶參數來對該應用進行客戶化 |
11. 易安裝性
易安裝性指應用系統的轉換和安裝容易度對開發的影響程度。
系統測試階段提供了轉換和安裝計劃和/或轉換工具。
0 |
用戶對安裝沒有特定的要求 |
1 |
用戶對安裝沒有特定的要求,但有特定的安裝環境要求 |
2 |
用戶提出了安裝和轉化的要求,轉化/安裝指南被通過測試提供給用戶。可是轉化的影響對該應用不重要 |
3 |
用戶提出了安裝和轉化的要求,轉化/安裝指南被通過測試提供給用戶。轉化的影響對該應用來講是重要的 |
4 |
除了2 的要求以外,須要提供通過測試的自動化的安裝和轉化工具。 |
5 |
除了3 的要求以外,須要提供通過測試的自動化的安裝和轉化工具。 |
12. 易操做性
易操做性指的是應用對運行的影響程度,若有效啓動、備份和恢復規程的影響。
易操做性是應用提供的一種特性,它最小化了手工操做的要求。
0 |
用戶沒有指定除正常備份程序外的其它特定操做 |
1 |
提供高效的啓動、備份和恢復進程,但須要人手操做 |
2 |
提供高效的啓動、備份和恢復進程,不須要人手操做(看成兩項計算) |
3 |
應用程序對磁帶的需求最小化 |
4 |
應用程序對硬拷貝處理的需求最小化 |
5 |
程序設計成無人操做模式。無人操做模式的意思是除了啓動和關閉以外,不須要對系統進行操做。程序的其中一個功能就是錯誤自動恢復。 |
13. 多場地
多場地指應用系統經特殊設計、開發能夠在多個組織、多個地點應用的程度。
0 |
用戶需求不含多場地和組織的要求 |
1 |
考慮了多場地的要求,可是設計要求應用在不一樣的場地使用相同的軟硬件環境 |
2 |
考慮了多場地的要求,可是設計要求應用在不一樣的場地使用相似的軟硬件環境 |
3 |
考慮了多場地的要求,同時設計支持應用在不一樣的場地使用不一樣的軟硬件環境 |
4 |
在1 或者2 的要求之上,提供了通過測試的多場地的文檔和支持計劃 |
5 |
在3 的要求之上,提供了通過測試的多場地的文檔和支持計劃 |
14. 支持變動
支持變動指的是應用在設計上考慮支持處理邏輯和數據結構變化的程度。
能夠具備以下的特性:
提供能夠處理簡單要求的彈性查詢和報告功能,如對一個ILF進行與(或)邏輯Ø
提供能夠處理通常複雜度要求的彈性查詢和報告功能,如對多於一個的ILF進行的與(或)邏輯(看成兩項計算)Ø
提供能夠處理複雜要求的彈性查詢和報告功能,如對一個或多個ILF進行的與(或)邏輯的組合(看成三項計算)Ø
業務控制數據被保存到用戶經過在線交互進程維護的表中,但變動只會在第二個工做日生效Ø
業務控制數據被保存到用戶經過在線交互進程維護的表中,且變動即時生效Ø
0 |
一個都不知足 |
1 |
合計知足一個 |
2 |
合計知足二個 |
3 |
合計知足三個 |
4 |
合計知足四個 |
5 |
合計知足五個 |
計算調整後的功能點個數
國際的IFPUG組織將軟件項目分爲三類,功能點估算法適用於任何一類項目,其計算公式中的術語請詳見表1。
功能點的原始計算公式:FP Countl =UFP * VAF
新開發項目l
有時新開發的軟件項目也須要與其餘現存的軟件系統進行整合,例如:一個企業新開發的MIS內部管理系統常常會與財務系統進行整合。這個時候除了考慮自己項目的功能點個數外,還要考慮系統整合或數據遷移部分的工做量,所以其功能點計算公式以下:
FP Count =(UFP+CFP)* VAF
二次開發的項目l
有時新開發的軟件項目是在原有基礎上進行二次開發的,只是爲了增長一些新的功能,所以其功能點計算公式以下:
FP Count = ADD * VAF
功能加強的項目l
對於功能加強的項目功能點估算比較複雜,在功能點加強前你們須要計算有哪些是新增長的功能,有哪些是被修改的功能,還有哪些是屬於數據遷移或系統整合的功能。而後計算新系統技術複雜度的調整因子「VAFA」,並在此基礎上計算系統功能點的數量。固然此類項目也會去掉一些原有功能,那麼在原有系統的技術複雜度基礎上從新計算功能點的調整因子「VAFB」,再計算所去掉功能貢獻的功能點數量,所以其功能點計算公式以下:
FP Count = [(ADD+CHGA+CFP)* VAFA]+(DEL * VAFB)
表1 功能點技術公式術語
術語
|
英文
|
中文含義
|
ADD |
Added functionality |
被添加的功能點個數 |
CFP |
Conversion functionality |
被轉換的功能點個數 |
CHGA |
UFP of changed functionality after enhancement |
功能加強後所改動的功能所貢獻的未調整的功能點個數 |
DEL |
Deleted functionality |
被刪除的功能點個數 |
UFP |
Unadjusted functional point count |
未調整的功能點個數 |
VAF |
Value adjustment factor VAF=(sum of(DI)* 0.01)+ 0.65 |
功能點的調整因子的計算公式 VAF=(sum of(DI)* 0.01)+ 0.65 |
VAFA |
Value adjustment factor after enhancement |
功能加強後的功能點調整因子 |
VAFB |
Value adjustment factor before enhancement |
功能加強前的功能點調整因子 |