function point estimation 功能點估算是一種用來估算專案大小的技術。
功能點是對軟體功能和規模的間接定量測量，它基於客觀的外部應用介面和主觀的內部應用複雜度以及總體的效能特徵。
功能點法和專家法估算最大的不同點在於對估算規模的細化的定量分析上面．我們在用專家法估算的時候往往會直接去估算工作量，或在規模的估算中摻 雜了生產率的資料，導致估算資料出現問題．專家法估算雖然有時候也很準確，但不能提公升為組織級可以參考和借鑑的同樣規則．其實專家法的估算要做準確也是遵 循了功能點法估算的思路，在考慮乙個軟體功能究竟涉及到哪些操作，涉及到多少資料檔案的存在，每個操作需要訪問哪些資料檔案等相關問題．只是這些想法停留 在專家頭腦裡面而沒有量化出來．
我們的**，分析和決策能力要提公升，就必須對我們的經驗進行模型化和定量分析．功能點法正好就起到了這個作用．其實功能點發也有不完善的地方，這可以根據我們專案實際的使用情況去不斷的改進．
功能點發進行估算的時候具體過程是：
1.對估算功能單元的型別進行識別
2.計算每種型別的複雜度．
3.計算總體的調整前的功能點數
4.根據調整因子對功能點數進行調整
功能點估算中有5種資訊域需要進行描述：其中事務類的有ei,eo和eq，資料儲存類有ilf和eif.
外部輸入(ei):通過介面等的輸入，插入更新等操作都是典型外部輸入
外部輸出(eo):僅僅輸出，入匯出，報表，列印等輸出
外部查詢(eq):先要輸入資料，在根據輸入資料計算輸出，如查詢
內部邏輯檔案(ilf):可以理解為業務物件，可能對應多個資料表
外部介面檔案(eif):其它應用提供的介面資料
a.對事務類功能點的估算：
對事務類的功能點估算需要確定det和ftr兩個指標：
det:可以理解為介面的錄入具體資料項，按鈕也要作為資料項
ftr:事務功能需要操作的資料檔案的數目
對ei的複雜度的計算：
對eo和eq複雜度的計算：
b.對資料儲存類功能點的估算
對資料儲存類功能點的估算需要確定det和ret兩個指標
det:具體資料儲存檔案的資料項的數目
ret:資料檔案是復合檔案時候關聯或引用的個數．如訂單資料檔案由於存在訂單頭和明細關聯引用,ret應該算2.
對ilf和eif複雜度的計算：
資訊域資料估算完成後可以開始考慮調整因子：
調整因子是一種補償機制，即通過五個資訊域和複雜度都還沒有辦法考慮到的因素就應該做為調整因子．如同樣乙個軟體系統一種是系統要支援分布式和自動更新，而另一種是不考慮這種需求，如果不考慮調整因子這兩者的規模是一樣的，但很明細第一種情況複雜度和規模都會更大些．
有了調整因子後最終可以得到調整後的功能點數:
afp(調整後功能點)= ufp (未調整功能點數目)* af (影響因子)
軟體專案中的風險管理
http www.csai.cn 2005年07月27日 1.引言 軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理...
軟體專案中的基礎測試
軟體專案中的基礎測試 單元測試 ut 什麼是單元測試 單元測試 又稱為模組測試 是針對程式模組 軟體設計的最小單位 來進行正確性檢驗的測試工作。序單元是應用的最小可測試部件。在過程化程式設計中，乙個單元就是單個程式 函式 過程等。單元測試流程 在傳統軟體開發過程中，單元測試是在編寫完模組 後開始進行...
軟體專案中存在的問題
在學習 軟體工程 前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了 軟體工程 之後，覺得自己的思路開闊了...