架構:軟體成本估算

banq發表於2024-03-01

本文提出了一種新穎的軟體成本估算混合方法,該方法將軟體離散為更小的任務,並使用專家判斷和演算法技術。透過使用基於體積和複雜性的雙因素資格系統,我們提出了一種更具適應性和可擴充套件性的模型來估計軟體專案持續時間,特別強調大型遺留遷移專案。

介紹
軟體成本估算(SCE)是軟體工程領域內的一個系統化、定量的過程,涉及分析、預測和分配軟體系統的開發、維護和管理所需的財務、時間和資源投資。

這項重要工作使用不同的方法、模型和技術,為利益相關者提供對成功軟體專案執行的預期財務、時間和資源需求的專業評估。

它是專案規劃的重要組成部分,允許在軟體開發生命週期中進行資源的邏輯分配並支援風險評估和管理。

演算法方法
1、COCOMO
在軟體工程和成本估算領域,構造成本模型(通常稱為 COCOMO)是一個成熟且備受推崇的概念。COCOMO 由 Barry Boehm 博士開發,研究軟體屬性和開發成本之間的相互作用。

該模型在從基本到詳細的層次結構上執行,每個級別提供不同程度的粒度 [1]。該模型仔細使用程式碼行和其他專案細節等因素,將它們與經驗成本估算資料保持一致。

儘管如此,COCOMO 並不是過去停滯不前的遺蹟。多年來它一直在進步,COCOMO II 涵蓋了當代軟體開發實踐的複雜性,特別是在物件導向程式設計和敏捷方法等不斷髮展的正規化中 [2]。

然而,儘管 COCOMO 的實證和系統方法提供了可信度,但其使用程式碼行數作為主要指標卻招致了批評。對於功能屬性更為重要的專案尤其如此。

2、功能點分析 (FPA)
功能點分析 (FPA) 擺脫了程式碼指標的嚴格限制,成為從功能角度評估軟體的整體方法。

FPA 由 IBM 的 Allan Albrecht 在 20 世紀 70 年代末提出,旨在透過軟體的功能及其為使用者提供的價值來衡量軟體,而不是透過程式碼行數來衡量。

透過對不同的使用者功能(例如輸入、輸出、查詢和介面)進行分類和評估,FPA 將軟體複雜性簡化為可測量的功能點 [3]。

這種方法在功能輸出比底層程式碼更重要的專案中特別有效。FPA 採用以使用者為中心的方法,很好地滿足了客戶的需求,並提供了對開發人員和利益相關者都有吸引力的具體指標。

但值得注意的是,FPA 的有效性取決於對使用者需求的透徹理解,不確定性可能會導致估計的差異。

3、SLIM(軟體生命週期管理)
SLIM(軟體生命週期管理的縮寫)植根於機率建模哲學,是由 Lawrence Putnam 設計的多方面工具 [4]。

SLIM 的本質圍繞著一組非線性方程,當這些方程交織在一起時,可以追蹤軟體開發專案從開始到完成的軌跡。SLIM 結合歷史資料和專案具體情況,呈現了一個機率圖景,提供有關專案時間表、成本和潛在風險的見解。

SLIM 的獨特之處在於它能夠隨著專案的進展進行調整和重新配置。透過持續吸收專案反饋,SLIM 動態完善其估算,以確保它們始終立足於專案實際情況。

這種持續的重新校準既是 SLIM 最大的資產,也是它的主要障礙。雖然它提供了靈活的適應性,但它​​也需要詳細的資料記錄和跟蹤,這需要專案團隊採取嚴格的方法。

非演算法方法
1、專家的判斷
漫步在軟體評估方法的古老走廊中,我們不能忽視專家判斷的持久智慧[5]。專家判斷避免了其他技術的嚴格演算法和形式,而是借鑑了行業資深人士積累的經驗和直覺能力。

這些經驗豐富的從業者從眾多專案中積累了豐富的見解,具有評估新企業的範圍、複雜性和可能困難的天生能力。他們細緻入微的理解可以彌補更嚴格的資料驅動模型留下的差距。

專家判斷巧妙地捕捉了專案的無形微妙之處,以定量指標可能被忽視的方式封裝了軟體開發工藝。然而,與任何藝術形式一樣,專家判斷也會受到其實踐者的怪癖的影響。它很容易受到個人偏見和人類判斷固有的可變性的影響。

2、類比估計(或歷史資料)
歷史資料估計,也稱為類比估計,是一種透過回顧過去的專案來為未來專案提供估計的技術。這類似於凝視後視鏡來導航前方的道路。

這種方法涉及推斷以前類似專案的經驗和結果,並將其與當前專案進行比較。透過這樣做,它提供了一個經過現實世界結果調整的紮根視角,為估計提供資訊。

它的有效性取決於其經驗基礎,過去的事件常常為未來的事業提供可靠的預測。然而,現有歷史資料的質量和相關性是關鍵因素。

不匹配的比較或過時的資料可能會導致專案誤入歧途,這凸顯了仔細資料管理和謹慎實施的重要性[6]。

3、德爾菲法
該方法的名字來源於古老的德爾菲神諭,它協調了專家們的和諧融合。德爾菲技術是一種旨在透過收集專家組的匿名見解和預測來達成共識的方法[7]。

這種方法有利於集體智慧的研討會,而不是依賴單一的觀點。透過迭代輪次的反饋,根據集體輸入對估計進行細化和重新校準。

德爾菲法是一個結構化但動態的過程,可以過濾掉異常值並趨向於更加平衡的集體判斷。它本質上是迭代的,並強調匿名性,以減少群體思維和有影響力的偏見的潛在陷阱。

這提供了一個讓每個專家的聲音都能得到應有共鳴的環境。然而,德爾菲法需要細緻的引導和耐心,因為它需要經過多輪審議才能達成共識。

基於人工智慧的方法
1、SCE 中的機器學習
在快速發展的軟體成本估算領域,機器學習 (ML) 成為變革的強大預兆 [8]。機器學習擺脫了傳統方法的確定性限制,深入研究機率領域,利用大量歷史資料來挖掘隱藏的模式和相關性。

透過對不同專案資料集進行訓練,機器學習演算法提高了預測能力,適應了經常被嚴格的基於規則的系統忽視的細微差別。這種適應性使機器學習成為動態軟體生態系統中特別有效的工具,其中專案範圍和挑戰不斷變化。

然而,機器學習在 SCE 中的有效性取決於訓練資料的質量和全面性。稀疏或有偏差的資料集可能會導致演算法誤入歧途,這凸顯了穩健資料管理和驗證的重要性。

2、神經網路
神經網路 (NN) 深入研究計算建模的複雜神經通路,證明了人工智慧的仿生願望。神經網路的結構模仿人腦的神經元複雜性,部署節點和連線的分層架構來處理和解釋資訊。

在軟體成本估算領域,神經網路從歷史資料中編織出複雜的模式,捕獲傳統模型通常難以捉摸的非線性關係[9]、[10]。它們的深度學習能力,尤其是隨著多層架構的出現,為 SCE 的複雜資料集帶來了巨大的希望。

然而,賦予神經網路力量的深度有時也會使它們籠罩在不透明之中。它們的“黑匣子”性質,加上容易過度擬合,需要進行細緻的培訓和驗證,以確保可靠的估計。此外,最近“Grokking”的發現表明該領域可能會產生令人著迷的新發現。

3、遺傳演算法
遺傳演算法 (GA) 從生命的本質中汲取靈感,將進化原理轉移到計算畫布上。遺傳演算法將軟體成本估算視為最佳化難題,透過模仿自然選擇、交叉和突變的過程尋找最合適的解決方案。

透過啟動不同群體的估計策略並透過進化週期迭代地完善它們,遺傳演算法收斂到更最佳化的估計模型。它們固有的適應性和探索性使它們非常適合充滿區域性最優的 SCE 景觀。

然而,遺傳演算法的隨機本質意味著它們的結果雖然通常是穩健的,但可能並不總是保證執行之間的絕對一致性。其進化引數的校準對於在探索和開發之間取得平衡仍然至關重要。

敏捷估算技術
敏捷方法最初是為了解決傳統軟體開發流程的挑戰而制定的,它引入了專案管理和產品交付方式的正規化轉變。

這種方法的一個組成部分是開發的迭代性質以及對跨職能團隊之間協作的強調。這種協作方法擴充套件到敏捷中的估計過程。

敏捷估算技術不是試圖從一開始就預見專案的全部複雜性,而是旨在隨著團隊收集更多資訊而不斷髮展和適應。

1、故事點
許多敏捷團隊不是用幾小時或幾天來估計任務,而是使用故事點來估計使用者故事所需的相對工作量。故事點考慮任務的複雜性、風險和工作量。

透過關注相對努力而不是絕對時間,團隊可以避免由於不可預見的挑戰或依賴而導致低估或高估的陷阱。經過幾次迭代,團隊形成了一種對其“速度”的感覺——他們在一次迭代中完成的故事點的平均數量——這有助於預測[13]。

2、規劃撲克
最流行的敏捷估算技術之一是規劃撲克。團隊成員(通常包括開發人員、測試人員和產品所有者)協作估計特定任務或使用者故事所需的工作量。

使用一組具有預定義值(通常是斐波那契數列)的卡片,每個成員選擇一張代表他們的估計的卡片。同時亮出他們的牌後,討論估計的差異,從而達成共識。

Planning Poker 的美妙之處在於它能夠結合個人專家的意見並得出反映整個團隊集體智慧的估計。該過程還揭示了潛在的挑戰或不確定性,從而做出更明智的決策。

3、持續重新評估
敏捷估算的一個標誌是它的迭代性質。當團隊進行衝刺或迭代時,他們會根據新的知識和之前週期中花費的實際工作不斷重新評估和調整他們的估計。隨著專案的進展,這種迭代反饋迴圈可以實現更準確的預測。

混合模型方法
我們的目標是提出一種結合了專家判斷和演算法方法的新穎模型。在考慮專家方法時,值得注意的是,它可能涉及主觀評估,可能會表現出不同專家之間的不一致。

此外,它對專家經驗和可用性的依賴有可能由於認知啟發法和過度依賴最近的經驗而引入偏差。

另一方面,演算法方法可能需要大量的專業知識才能正確應用,並且可能關注某些可能不相關的引數,例如程式碼行數。

因此,這裡的目的是提出一個獨立於程式語言並考慮專案、硬體和人員屬性等多種因素的模型。

任務離散化
在不斷髮展的軟體工程領域,任務離散化實踐已成為中流砥柱。這種方法強調將較大的軟體目標分解為可管理的小型單元的重要性。

透過承認軟體元件固有的謹慎性(從螢幕和 API 到 SQL 指令碼),有條理的分解成為一種實際需求 [17]。這種方法允許您在由一致元素組成的一致模組中定義軟體。擁有同質的估算元素至關重要,這樣估算團隊就能輕鬆瞭解他們正在估算的內容,並避免適應這些元素。這些元素在本文中將被稱為“任務”。

此外,在個人層面上處理任務可以提高準確性,而它提供的細節可以提高靈活性,從而可以進行迭代調整以適應專案不斷變化的需求。

這種方法保證了每個元件的獨特特徵得到適當和獨立的考慮。這種離散化方法有幾個優點。在個人層面上處理任務可以提高準確性,而它帶來的粒度可以提高靈活性,從而實現迭代調整,以滿足專案的流動需求。

相反,對每項任務複雜性的詳細理解可以謹慎地分配資源並調整技能到最需要的地方。然而,這種詳細程度並非沒有缺點。

儘管提供了準確性,但將任務解構為其組成部分可能會導致管理挑戰,特別是在大型專案中。忽略某些任務的可能性(儘管很小)卻始終存在。此外,過於詳細的方法有時會掩蓋更廣泛的專案目標,導致決策延遲,這通常被稱為“分析癱瘓”。

雙因素資格體系和努力計算任務離散化
隨著任務的描述表現出同質屬性,必須確定分配適當工作量的通用決定因素。

經過仔細審查,我們發現了兩個關鍵因素:複雜性和體積[1],[18]。

複雜性是衡量任務執行所需技術敏銳度的指標。例如,在使用者介面內,動態表的合併可以保證將任務分類為由於其複雜的要求而具有高複雜性。

體積法描述了所涉及的工作量或數量。為了說明這一點,在使用者介面的上下文中,廣泛的四十欄位表單的存在可能表明由於其元件的龐大規模而具有大量體積的任務。

複雜性和體積 都在[1 − 5] 區間內,並且必須是整數。現在我們定義 Effort ( E),其計算如下:

E=C*V

我們在此計算中使用乘法,以便在高複雜性和高體積之間建立聯絡。這使我們能夠在兩個評估標準同時增加時考慮潛在風險,同時保持係數較低的任務的準確性。

算盤系統
現在已經獲得了工作量,可以為每個工作量值確定相應的天數。此階段至關重要,需要了解目標架構和技術的專家進行干預。
然而,該模型允許這一關鍵資源在建立這些值時僅干預一次。

演算法的使用
為了建立這些值,我們建議使用一種演算法來提高準確性並防止錯誤。它可用於使用三個不同的模型和兩個起始標準來模擬資料集:

  • 最大天數(與 25 的努力相關)
  • 值之間的間隙填充

我們利用三種不同的模型,使專家和評估團隊能夠從不同的曲線輪廓中進行選擇,這些曲線輪廓可能會產生不同的特性,例如精度、風險評估和填充尺寸,以理想地適應要求。假設了三種不同的數學模型來解釋這種關係:線性、二次和指數。每個模型都假設了一種獨特的“努力到天”的轉變行為:
  • 線性模型假設工作量與天數之間成正比。
  • 二次模型 設想了加速的增長率,引用了多項式數學。
  • 指數模型 預測指數激增,意味著更高的努力值急劇升級。

可以調整這些模型以更準確地滿足估計要求。最後我們得到如下程式碼:

import numpy as np
import matplotlib.pyplot as plt
import pandas as pd # Importing pandas for tabular display
# Fixed effort values
efforts = np.array([1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20, 25])
# Parameters
Max_days = 25
Step_Days = 0.25
def linear_model(effort, max_effort, max_days, step_days):
 slope = (max_days - step_days) / max_effort
 return slope * effort + step_days - slope
def quadratic_model(effort, max_effort, max_days, step_days):
 scale = (max_days - step_days) / (max_effort + 0.05 * max_effort**2)
 return scale * (effort + 0.05 * effort**2)
def exponential_model(effort, max_effort, max_days, step_days):
 adjusted_max_days = max_days - step_days + 1
 base = np.exp(np.log(adjusted_max_days) / max_effort)
 return step_days + base ** effort - 1
def logarithmic_model(effort, max_effort, max_days, step_days):
 scale = (max_days - step_days) / np.log(max_effort + 1)
 return scale * np.log(effort + 1)
# Rounding to nearest step
def round_to_step(value, step):
 return round(value / step) * step
linear_days = np.array([round_to_step(linear_model(e, efforts[-1], Max_days, Step_Days), Step_Days) for e in efforts])
quadratic_days = np.array([round_to_step(quadratic_model(e, efforts[-1], Max_days, Step_Days), Step_Days) for e in efforts])
exponential_days = np.array([round_to_step(exponential_model(e, efforts[-1], Max_days, Step_Days), Step_Days) for e in efforts])
logarithmic_days = np.array([round_to_step(logarithmic_model(e, efforts[-1], Max_days, Step_Days), Step_Days) for e in efforts])
# Plot
plt.figure(figsize=(10,6))
plt.plot(efforts, linear_days, label=<font>"Linear Model", marker='o')
plt.plot(efforts, quadratic_days, label=
"Quadratic Model", marker='x')
plt.plot(efforts, exponential_days, label=
"Exponential Model", marker='.')
plt.plot(efforts, logarithmic_days, label=
"Logarithmic Model", marker='+')
plt.xlabel(
"Effort")
plt.ylabel(
"Days")
plt.title(
"Effort to Days Estimation Models")
plt.legend()
plt.grid(True)
plt.show()
# Displaying data in table format
df = pd.DataFrame({
 'Effort': efforts,
 'Linear Model (Days)': linear_days,
 'Quadratic Model (Days)': quadratic_days,
 'Exponential Model (Days)': exponential_days,
 'Logarithmic Model (Days)': logarithmic_days
})
display(df)


大型遺留遷移專案中的具體用例
現在已經描述了該模型,接下來將在遷移專案的背景下提出具體的應用程式。人們相信,該模型非常適合此類專案,在此類專案中,團隊面臨著似乎不適合現有標準模型的情況,如第一部分中所述。

SCE 在遺產遷移中的重要性
通常,遷移專案會受到成本的影響。遷移需求通常是由以下因素引起的:

  • 更頻繁的迴歸和副作用
  • 難以為過時技術 找到新資源
  • 專業知識集中
  • 整合新功能的複雜性
  • 效能問題

上面列出的所有潛在原因都會增加成本和/或風險。可能有必要考慮有問題的技術構建模組的遷移。實施主要取決於所產生的成本,需要準確的估計。

然而,重要的是要認識到,在組織的遷移過程中,技術的變化必須伴隨著人員和組織的調整。

通常,在定義目標架構和技術後,組織可能缺乏這些領域的必要專家。這可能會使“專家判斷”方法變得複雜。演算法方法似乎也不合適,因為它們需要知識和掌握,但也不一定考慮遷移在重繪要遷移的元件方面可能需要的所有微妙之處。

此外,初始程式碼行數並不始終是可靠的標準。最後,基於人工智慧的方法似乎仍處於形成階段,對於這些組織來說實施和掌握可能具有挑戰性。

這就是為什麼我們的模型看起來很合適,因為它使現有團隊能夠量化工作量,然後向目標技術專家尋求建議來建立估計,從而獲得準確的數字。值得注意的是,這種估計僅涵蓋開發本身,而忽略了規範階段和相關的基礎設施成本。

混合模型的應用
我們將概述實施我們的估計模型的整個過程。該過程包括三個階段:初始化、估計和最終化。

1、初始化
在此階段,必須首先解構要評估的技術構建塊。它需要被分解為一組統一的任務。 
例如,具有呼叫 AS400 資料庫的 GWT 前端的應用程式可以分為兩個主要集:

  • 前端: 任務由螢幕表示。
  • 後端:任務由 API 表示。

然後我們可以組建估算團隊。它不需要是目標技術的技術專家,但應該由現有專案的資源組成,最好是技術/功能對,他們可以評估每個任務與兩個願景的互補性。

該團隊將能夠開始列出離散化過程中確定的主要元件的任務。

2、預估
現在,我們有一個團隊準備將複雜性和體積值分配給要識別的任務集。在進行關聯工作的同時,我們可以開始設定與工作相關的天數。
這項工作可能需要目標技術方面的專家以及估算團隊的成員來量化一些基準值,在此基礎上專家可以進行批判性的審視並將結果擴充套件到整個圖表。
在這個階段結束時,我們有一個天/努力對應算盤和一個具有相關努力值的任務列表。

3、最終確定
最後一步是使用算盤計算工作量和天數之間的換算,以獲得總天數。獲得工作量值列表後,可以使用以下標準進行風險分析:

  • 努力機率密度曲線的標準差
  • 分析元件的某些“區域”是否集中高努力值
  • 工作量值大於 16 的任務數量

根據這些標準,可以在限制區域採取具體措施。

結論
總之,我們的模型提供了一種實用且靈活的方法來估計大型遺留遷移專案所涉及的成本。

透過將專家判斷的要素與結構化演算法分析相結合,該模型解決了遷移過時或複雜系統所帶來的獨特挑戰。

它認識到準確衡量工作量和成本的重要性,不僅考慮技術方面,還考慮所需的人力和組織轉變。

三個階段的過程——初始化、估計和最終確定——確保了全面的評估,從將專案分解為可管理的任務到進行詳細的風險分析。這種混合模型對於面臨艱鉅的遷移任務的團隊特別有益,它提供了做出明智決策並有效為過渡做好準備的途徑。

透過這種方法,組織可以應對錯綜複雜的遷移,確保更順利地過渡到現代、更高效的系統。

根據所提出的討論和發現,很明顯遺留遷移專案提出了一系列獨特的挑戰,僅靠傳統的軟體成本估算方法無法解決這些挑戰。

所提出的混合模型可以作為更具啟發性的專家判斷方法和更結構化的演算法分析之間的橋樑,提供平衡和自適應的解決方案。該模型的主要優勢在於其適應性以及利用目標技術方面的機構知識和特定專業知識的能力。

此外,該模型能夠將問題解構為一組統一的任務,並以適當的粒度進行估計,確保了其在各種應用場景中的相關性。雖然混合模型的當前實施顯示出潛力,但未來的研究和改進可以進一步推動其實用性:

  • 實證驗證:與所有模型一樣,對各種遷移專案進行實證驗證至關重要。這不僅可以驗證其有效性,還可以提高其準確性。
  • (我們已經在努力了。)
  • 與人工智慧整合: 儘管基於人工智慧的軟體成本估算方法仍處於萌芽階段,但其潛力不容忽視。混合模型的未來迭代可以整合機器學習以增強預測,特別是當可以使用過去專案的大型資料集時。
  • 改進的風險分析:擬議的風險分析標準提供了堅實的起點。然而,更復雜的風險模型(考慮了移民專案固有的不可預見的複雜性和不確定性)可以整合到模​​型中。
  • 工具和自動化:開發可以半自動化所描述的過程的工具將使模型更容易被組織訪問和採用。

總之,混合模型在軟體成本估算領域取得了顯著的進步,特別是對於遺留遷移專案。然而,與所有模型一樣,它是一個不斷髮展的實體,持續改進只會增強其適用性和有效性。

相關文章