資料結構
網路
關係資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理
化學
生物
數學
英語
經濟學
心理學
社會學
服裝設計
法律軟體工程中的成本估算模型
軟體成本估算方法是一種軟體專業人員用來估算專案成本的間接度量。它們被用於各種用途。它包含以下專案 -
預算 - 最需要的功能是整體估算的準確性。因此，首先要關注的是估算軟體產品的預算。
權衡和風險分析 - 能夠揭示軟體專案選擇（範圍、人員配備、工具、重用等）的成本和進度敏感性是一個重要的附加功能。
控制和規劃專案 - 另一個選項是按元件、階段和活動細分成本和進度。軟體增強的投資分析 工具、重用和流程成熟度都對軟體開發過程有益。
成本估算模型
軟體開發效率將緩解軟體生產當前面臨的挑戰，這些挑戰導致了成本超支甚至專案取消。軟體工程成本模型，與任何其他學科一樣，也面臨著一些挑戰。軟體開發的快速發展使得開發能夠在所有學科中為軟體開發提供高準確度的引數模型變得非常具有挑戰性。軟體開發成本正在以驚人的速度增長，從業者不斷抱怨他們無法有效預測所涉及的成本。軟體模型有助於描述開發生命週期並預測構建軟體產品的成本。在過去的二十年中，由於學術界開創性的工作，出現了許多軟體估算模型。由於大多數模型都是專有的，因此無法在模型結構方面進行比較和對比。這些模型的功能形狀是由理論或實驗決定的。以下是其中一些 -
COCOMO 81
(a) COCOMO 基礎
COCOMO 代表構造性成本模型。Barry Boehm 的著作《軟體工程經濟學》最初於 1981 年出版。由於模型易於透明，它提供了專案費用的量級。它專為小型專案設計，因為它具有有限數量的成本驅動因素。當團隊規模較小時，即當員工人數較少時，它很有用。
它對於快速、早期、粗略地估算軟體成本很有用，但由於缺乏因素來解釋硬體約束、人員質量和經驗、現代工具和技術的應用以及其他已知對軟體成本有重大影響的專案屬性的差異，因此其準確性有限。
工作量 = a* (KDSI)b 工作量 = a* (KDSI)
常數 a 和 b 根據專案型別具有不同的值。KLOC 是專案預計交付的程式碼行數。
COCOMO 中有三種模式 -
有機模式 - 一個小型、基本的軟體專案，涉及一小群具有先前應用知識的人員。工作量 E 和開發時間 D 如下 -
E = 2.4*(KLOC)^1.05
D=2.5*(E)^0.38
半獨立模式 - 一箇中等規模的軟體專案，其中具有不同專業知識水平的團隊協作。
E= 3.0*(KLOC)^1.12D=2.5*(E)^0.35
嵌入式模式 - 一個必須在嚴格的硬體、軟體和操作限制下構建的軟體專案。
E= 3.6*(KLOC)^1.20
D= 2.5*(E)^0.32
(b) COCOMO 中級
它將軟體開發工作量評估為程式規模和一組成本驅動因素的函式，其中包括對產品、硬體、員工和專案特徵的主觀評估。
它適用於中等規模的任務。成本驅動因素包括從基本到高階的 COCOMO。成本因素會影響產品可靠性、資料庫大小、執行和儲存。團隊規模適中。COCOMO 中級模型如下 -
工作量 = a*(KLOC)b*EAF
這裡，工作量以人月為單位測量，KLOC 是專案預計交付的程式碼行數。
(c) COCOMO 高階
它專為大型專案而設計。成本驅動因素由需求、分析、設計、測試和維護確定。團隊規模相當大。高階 COCOMO 模型包含中級版本的所有特性，以及對成本驅動因素對軟體工程過程每個階段（分析、設計等）的影響的評估。
COCOMO-II
COCOMO II 是一個始於 1994 年在南加州大學進行的研究專案。它非常重視非順序和快速開發過程模型、再工程、重用驅動的 методология、面向物件的方法等等。它是三種模型的組合結果：應用組合、早期設計和後期架構。
在使用整合計算機輔助軟體工程技術進行快速應用開發的專案中，應用組合模型用於估算工作量和進度。它基於物件點的概念（物件點是對應用程式中開發的螢幕、報表和 3GL 語言模組的計數）。
早期設計模型涉及檢視備選系統設計和操作方法。
後期架構模型顧名思義，在完成頂層設計並獲得有關專案的詳細資訊以及軟體架構已明確定義且眾所周知時使用。它是早期設計模型的全面擴充套件，考慮了整個開發生命週期。這是一個從精益到中級的 COCOMO 模型，定義如下 -
工作量 = 2.9(KLOC)^1.10
PUTNAM 模型 (SLIM)
軟體生命週期模型 (SLIM) 基於 Putnam 對專案人員級別與時間的關係的瑞利分佈的研究。它結合了大多數常見的規模估算方法，例如概算技術、源指令、功能指標等。它計算專案的工時、時間線和缺陷率。收集和分析先前完成的專案的資料，然後對模型進行標準化。如果資料不可用，可以完成一系列問題以從資料庫中獲取 MBI 和 PF 值。P 代表生產力，定義為軟體產品規模 S 與開發工作量 E 的比率，如下 -
S/E = P
ESTIMACS
管理和計算機服務將這項專有技術商業化，它用於關鍵飛行軟體（MACS）。在業務方面，ESTIMACS 強調審查的迫切工作。Rubin 確定了六個關鍵估算比例和一張描述它們之間相互作用的地圖，從他所謂的“總體業務條款”到它們對開發人員長期預測的投資組合組合的影響。重要的估算維度如下：工作量小時數、工作量小時數、工作量小時數、工作量小時數、工作量小時數、工作量小時數
員工的數量和分佈，
價格，
對硬體資源的需求，
風險，
對投資組合的影響。
SEER-SEM
加利福尼亞州埃爾塞貢多的 Galorath, Inc. 銷售一種名為 SEER-SEM 的產品，它代表系統評估和資源估算。該模型已上市 15 年，基於原始的 Jensen 模型 [Jensen1983]。該模型具有廣泛的應用。它涵蓋了整個專案生命週期，從規範的早期階段到設計、開發、交付和維護。它使對模型輸入引數的靈敏度和權衡分析更容易。它將專案方面分解為工作分解結構，以便更好地規劃和管理，並顯示專案成本驅動因素。在甘特圖上，該概念允許對專案方面進行互動式排程。估算基於先前專案的龐大資料庫。
成本估算技術
A. 演算法方法
軟體成本估算使用演算法技術計算，該技術使用公式。該公式源自透過合併而形成的成本因素模型。此外，還使用統計方法來構建模型。演算法技術旨在提供一組可用於估算軟體的數學方程。這些數學計算基於研究和歷史資料，並考慮諸如原始碼行數 (SLOC) 的數量、要執行的函式的數量以及其他成本驅動因素（如語言、設計方法、人才水平、風險評估等）。許多模型，例如 COCOMO 模型、Putnam 模型和基於功能點的模型，都是使用經過廣泛研究的演算法方法構建的。
功能點分析
另一種根據軟體系統提供給使用者的服務來評估軟體系統規模和複雜性的方法是功能點分析。例如，ESTIMACS 和 SPQR/20 是兩種使用功能點方法的專有成本估算方法。Albrecht [8] 是第一個建立此度量標準的人，該度量標準基於程式的效用。總功能點數由計算的不同（格式或處理邏輯）型別數量決定。
計算功能點包括兩個步驟
使用者函式列表的編譯 − 原始函式數量是使用五個基本軟體元件的線性組合計算得出的：外部輸入、外部輸出、外部查詢、邏輯內部檔案和外部介面，所有這些都分為三個複雜度等級：簡單、中等和困難。函式數量的總數是這些數字的總和，並根據難度級別加權 (FC)。
考慮環境處理難度 − 最終的功能點是透過將 FC 乘以一個調整因子計算得出的，該調整因子是透過考慮 14 個不同的處理複雜度因素得到的。
B. 非演算法技術
軟體成本估算不是使用非演算法方式中的公式計算的。
自頂向下估算方法
宏觀模型是自頂向下估算的另一個名稱。使用自頂向下估算方法，從軟體專案的全域性屬性獲得專案的總體成本估算，然後將專案劃分為幾個低階機制或元件。Putnam 模型是最流行的採用此策略的技術。當只有全域性屬性已知時，此技術更適合於早期成本估算。由於在軟體開發的早期階段沒有可訪問的精確資訊，因此它非常有價值。
自底向上估算方法
使用自底向上估算方法計算每個軟體元件的成本，然後將結果合併以得出整個專案的估計成本。其目標是利用收集到的關於小型軟體元件及其互動的資訊來構建系統估算。COCOMO 的詳細模型是最流行的採用此方法的技術。
基於類比的估算
基於類比的估算就是將計劃中的專案與已經完成的類似專案進行比較，並且該專案的開發資訊是可用的。為了估算計劃中的專案，將已完成專案的實際資料進行外推。此策略可用於系統級和元件級。以下是使用此方法估算的步驟
瞭解擬議專案的特性。
根據其特性，從歷史資料庫中選擇最類似的已完成專案。
透過類比，使用最類似的已完成專案的成本計算擬議專案的成本。
11K+ 瀏覽量
