基于系統動力學方法的軟件過程建模與仿真

摘要：軟件開發質量很大程度上取決于軟件過程。軟件過程涉及到眾多相互關聯和反饋的因素，特別是與人和組織行為有關的軟因素，但在離散型傳統建模方法中難以得到準確反映。文章介紹了基于系統動力學的連續型軟件過程建模與仿真方法，并以Brooks法則作為實例描述了該方法的基本要素和優勢。文章還對系統動力學方法應用于軟件過程不同領域的研究加以回顧，并給出了今后的幾個主要研究方向。

關鍵詞：軟件過程；系統動力學；建模；仿真

引言

如今軟件所扮演的角色越來越重要，而與此同時也伴隨著相關的許多問題：如費用超支、進度延期、質量低下等。這迫使人們對軟件開發的關注點從軟件設計開發的技術方面過渡到對技術和管理兩方面并重。軟件過程已經成為軟件工程學中一個研究熱點。研究表明軟件工程的兩大目標：減少費用和提高軟件質量，都在很大程度上取決于軟件過程的質量。

在現實開發中，軟件系統的復雜性通常有著各種形式，主要表現為：系統不確定性和隨機性、復雜的動態行為和反饋機制。過程的變更通常耗費巨大，而且后果對軟件開發組織的影響很大。因此，采用一些合適的方法和技術來輔助用戶尤為重要。軟件過程建模和仿真就是其中一種比較合適的方案。軟件建模有著多種方法，目前比較常用的是類似于工作流系統的針對軟件開發過程分階段進行的離散性建模方法。這種方法有其優點，但難以表達例如開發人員的經驗、項目進度帶來的壓力、連續加班的疲勞程度等一直變化著的因素，以及這些相互關聯的因素之間的因果關系和反饋回路對軟件開發結果的影響。例如，項目進度的落后會增加開發人員的壓力，激勵他們提高生產率，項目組可能會選擇加班以希望趕上進度。高壓力下的加班一般會提高單位時間內的產量，但同時也會增加人員的疲勞程度，這樣很有可能增加出錯率，最終導致質量保證工作和返工的增加，并且當疲勞程度到達一定時候將降低生產率，最終很有可能趕不上進度。軟件開發中這些經常被忽略的軟因素對項目的成敗有著重要影響，系統動力學作為一種連續性建模方法，能很好地解決這些問題。

1 軟件過程建模與仿真

軟件過程可以被定義為“針對構思、開發、部署和維護軟件產品的一系列相關的政策、組織結構、技術、程序和工件”。軟件開發過程是一個復雜的動態系統，有著巨大的結構復雜度和規模。這些復雜性促成了系統的一些違背直覺的行為，使得系統行為難以靠人的經驗來精確評價。這些系統有一些共同特性，比如有多個相互關聯的組件構成，表現出復雜的動態行為和反饋回路，組件間的非線性關系和軟數據操作。

軟件開發涉及到管理相關的(如：人力資源，預算，調度，計劃和控制等)和生產相關的(如：軟件設計、編碼、測試、驗證和確認等)眾多因素，比如：勞動力量，預算，項目完成成績，人員生產率，產生的錯誤數，檢測到的錯誤數，可供雇傭的勞動力數量等。這些變量相互影響，形成互動和反饋循環。軟件過程建模是經常采用的一種基本手段。模型是現實世界或者概念化的復雜系統的一種抽象，通過減少或者去除不影響相關行為的細節，它設用來展示實際系統的主要特性。結合過程模型，應用計算機仿真技術來進行軟件過程研究有著如下優勢：

(1)大多數復雜的、現實世界的系統都存在眾多關系復雜的元素，難以光靠一個不能運行的模型來表達并用以進行分析。而仿真是一種可行的研究方法。

(2)仿真允許研究者去估計實際系統在一些假設的操作環境下的性能。

(3)能夠通過仿真對多種候選方法進行對比，以決定哪種能更好地符合需求。

(4)在仿真中，研究人員能夠比真實試驗更好地控制實驗條件。

(5)仿真允許研究人員以較短的時間去研究一個現實中需要很長時間來完成的事情。

基于建模的目標不同，應該根據各種建模方法的特點來采用不同的建模技術進行軟件過程研究。有時候根據建模需求并不需要關注每一個實體的每一個屬性，而是要能夠簡單清晰地觀察某些因素對系統層次上的影響，輔助管理者在整體層面上對項目做出決策。例如，連續型仿真建模方法就適合于策略分析、初始估算、長期趨勢、高層(全局)視角觀測。系統動力學就是一種典型的連續型建模方法。

2 系統動力學方法及其應用實例

2．1系統動力學方法

系統動力學方法由MIT的Forrester開發，是一種針對強調系統模型結構特性的復雜問題解決之道。系統動力學主要依賴兩種技術來構建模型：一是因果循環圖(causal loop diagram)，通過原因和結果關系來概念化系統，使得反饋回路得以顯現。二是流圖(now diagram)，采用流(flow)、流率(flow rate)、存量(stock)、水平(Ievel)、輔助變量(auxiliary)，常量(constant)和延遲(delay)等來表達系統。存量表示可以隨著時間累計或者消耗的元素；水平表示存量在某個給定時間點上的元素數量；流率描述存量的變化。系統動力學是采用連續的時間模擬方法，在模擬中，時間被劃分成預先設定好的時間間隔。模型變量在每個時間間隔的結束時計算，隨著時間調整它們的行為。例如，在軟件項目中，經驗被認為是影響生產率的一個重要因素，經驗水平值隨著項目進展不斷提高，同時，疲勞程度、進度壓力將影響到生產率，但可能會起反作用，系統動力學方法連續模擬這些變量的相互作用，進行生產率的動態估算。

2．2應用實例：Brooks法則

在軟件工程領域，有一個著名的Brooks法則，即在進度落后的項目中雇用新手加入以希望趕上進度，結果使得項目進度更加落后。下面我們將通過系統動力學模型和仿真來研究增加人手對生產率、總人月數和項目持續時間的影響。

建模首先要對問題域了解清楚，找出系統中的主要組成和因果結構關系。圖1是因果關系圖。一旦項目經理發現項目進度落后，積壓增加，就開始招聘新員工，增加員工數量。員工數量的增加帶來的直接影響是提高生產率以及通信和培訓的代價，而通信和培訓的代價的增加又會直接導致生產率的降低。生產率的提高會加大進度，減少項目積壓。通過圖1的因果關系圖的分析，我們會發現眾多元素形成一個反饋循環，增加員工對生產率的影響既有積極的也有消極的影響，因此難以直接通過定性分析來得出結論，結果如何還需要通過仿真的定量數據來說明。

圖2是采用系統動力學建模仿真工具PowerSim建立的Brooks法則的系統動力學模型。需求會逐步被開發成產品，所以隨著時間流逝，需求將減少而已經開發的軟件數量不斷增加。在本模型中，軟件生產效率由多個因素共同決定，其中包括標準生產效率、通信損耗和開發人員的數量。開發人員的總數=新人員數量+有經驗人員數量一負責培訓新人員的有經驗人員數量。通訊損耗為總人數的一個非線性函數，這里采用Abdel-Hamid模型中的數據(0.6*人數n的平方)。另外還假定一個有經驗人員可以培訓4個新員工，training overhead取值為25％。Assimilation delay表示—個新員工培訓為能勝任工作的有經驗人員的平均時間為20天。標準生產效率(Nominal productivity)為1，表示每把一個需求任務轉化為軟件產品需要1個標準化人天。在本模型中，新員工的生產效率為標準生產效率的0.8倍，而有經驗員工的生產效率為標準生產效率的1.2倍。

在我們的仿真運行中，設定初始條件為20個有經驗員工去開發5000個需求任務的項目，結果顯示為圖3、圖4中的reference曲線。總時間需要278天，總共耗費5500人天，生產效率為一條平行直線，值為18.24任務／天。

假設項目經理在開發過程中想加快項目進度，在100天的時候開始增加10名新的開發人員，仿真結果顯示為圖3、圖4中的current曲線。總時間反而需要299天，總共耗費7870人天，平均生產效率曲線在100天時有個顯著下降，然后再逐步上升，最后在為16.56任務／天時達到穩定。從結果對比中我們不難看出由于急劇增加的通訊損耗和培訓新員工而占用有經驗員工的正常開發時間，導致生產效率的下降。結果是項目進度并沒有提前，而開發費用卻急劇增加了。

圖3和圖4只是顯示了模型仿真運行的某一個場景，反映了在某些情況下Brooks法則的正確性。事實上我們還可以通過調整增加人員的數量和進入時間來預測其他場景下的項目開發結果，從而選擇相對較優的一個。比如，如果在100天的時候增加5個人，總時間能稍微較少一點，需要275天，但共耗費需要6295人天。

上面描述的Brooks法則模型只是一個經過簡化的模型，但還是能夠比較好地說明增加新開發人員對項目的影響。更符合實際軟件開發過程的模型還需要進一步細化。例如，新人員開發出來的產品其缺陷率往往比有經驗人員開發出來的要高，這樣將增加項目返工的工作量。當然還有如前面提到過的進度壓力、質量保證手段等其他因素的影響。

3 基于系統動力學的軟件過程相關模型

3．1 AbdeI-Hamid模型

Abdel-Hamid模型是把系統動力學運用到軟件工程領域的第一個系統比較完備的模型，它的目標是研究項目管理政策和活動在軟件開發中的作用。Abdel-Hamid模型被劃分為4個主要子系統，包括人力資源管理、軟件生產、項目計劃和控制。人力資源子系統針對軟件開發人員，其管理內容包括人員雇傭、解雇、人員流動以及培訓。軟件生產子系統為不同的開發活動分配可用的開發人員，比如培訓、設計、編碼、測試、返工和質量保證。該子系統還處理團隊動機、開發人員疲勞程度、生產率消耗因素，比如通信和返工等。軟件控制子系統測量軟件生產活動，描述針對這些測量的管理措施。該子系統控制加班時間，進度壓力和資金耗費等。軟件計劃子系統提供軟件項目的初始化參數值，比如項目規模、初始團隊規模、預期結束時間等。該子系統同樣控制著高層管理人員對雇傭新員工的意愿等。

通過對模型仿真運行結果的研究，Abdel-Hamid等人在項目花費、進度估算、質量保證的經濟性質，和項目人員管理等方面得出了很多有趣的結論，例如：

(1)在軟件項目估算中更精確的估算，結果不一定會更好，因為不論原始估算進度如何，進度總是趨向于超過預計的。

(2)采用類比的方法來進行軟件估算通常使得進度比本來所需要的要長。

(3)堅持過緊的進度會因勞動力的原因而增加費用。

3．2軟件過程領域中的其他應用模型

基于系統動力學的建模和仿真已經被成功應用到很多領域，但在軟件工程領域還沒有得到廣泛應用。其主要原因為相對物理系統來說，人和組織行為更難以精確建模，本節將從不同的應用方向介紹相關研究。

項目管理項目估算是軟件開發管理的一個必須的環節，而且估算對項目的開展有著重要影響。基于系統動力學的項目管理由于考慮到了過程的動態性，通常能夠比一般基于統計歷史數據的估算模型要更精確合理。Dynamic COCOMO就是在COCOMO模型的基礎上提出的結合系統動力學的估算模型。在項目進度控制方面，結合系統動力學的模型能夠更好地考慮到任務之間的相關性、有限的資源和可能的返工循環帶來的延遲，因此比傳統的項目管理方法更能反映現狀。

教育培訓由于組織系統中的各種因素之間存在復雜的關聯，經常會遇到一些違背直覺的現象。遇到問題如果只是簡單地采取一些應對手段通常并不能取得預期效果，Brooks法則就是一個很好的例子。一般的教育方法很難說清問題本質原因，而利用仿真模型則可以進行有效的闡明。基于系統動力學仿真模型的教育培訓還能使相關人員參與到仿真的軟件開發活動中，去分析深層次原因。通過更改和設置不同參數，如雇傭率等來研究不同方法的結果，增強決策支持的能力。另外借助模型還能實現分布式培訓，增強凝聚力和培訓效果，節約費用。

風險管理項目通常會因為需求變更、人員變動、資金削減等原因而顯得很脆弱。基于系統動力學的仿真有助于在項目早期識別風險，通過定量的預測決策變化帶來的后果，能夠幫助設計出更客觀、低風險的策略。

過程改進在傳統方法中，改變或者新增一個過程主要由操作經驗決定。這種方式通常費用很高而且風險很大。建模仿真可以在一定程度上預見一個過程的運行狀態。這種洞察力能夠幫助過程設計者評估候選方案。這種基于數據的客觀方法通常比主觀評價方法更具有說服力。

開發方法系統動力學仿真建模還被運用到輔助驗證新的開發方法論的有效性中。比如為極限編程Xp的開發過程建模，被用來研究采用Xp方法時需求變更帶來的費用變化。

4 結束語

軟件開發是一個復雜的過程，采用系統動力學方法來對軟件過程進行建模能很好地描述各個組成要素問的動態關聯，尤其是對傳統建模方法難以精確描述的軟性因素，它以一種連續的方式從定性和定量兩個方面對軟件過程進行建模和仿真。因此系統動力學對軟件過程的多個領域都能提供有效的策略支持。但該方法還不夠成熟，在以下各方面還需要做進一步的研究。 工業數據分析與模型驗證。建模和仿真的有效性主要取決于模型的有效性。組織模型需要處理人和其他難以量化的問題；不僅收集數據困難，而且這些數據的重現性也難以得到保證；模型只是現實世界的一種簡化，因此它不可能完全和實際情況相一致。對已有工業數據進行分析，來驗證模型是一個值得關注的課題。

多建模方法結合。當今研究的一個主要方向是如何結合離散型過程模型，比如側重工件生產流程的基于工作流的過程建模。采用連續性建模方法為動態環境和行為建模，使用離散模型來為過程步驟、任務和資源建模。 模型的可用性和重用性。另外一個問題是如何制定容易裁減和重用的模型。顯然如果模型過于簡單，將難以反映所關注問題，但過于龐大和復雜則難以應用和開發。單純的減小模型規模不是長久之計。