軟體工程中的系統文獻映射研究執行個體-對九個研究問題相關結果的分析（第十一部分）

之前的部落格較長的描述了軟體工程中的系統文獻映射研究方法。這裡接着給出一個我曾經做過的工作作為例子，以更直覺地展示這種研究類型。該研究的背景資訊這裡不再贅述。                  

這篇部落客要介紹基于前面九個研究問題的結果，我們可以得到什麼更深層次的結論。

入選文獻來自于九十四個不同來源。這表明假設條件及其管理在軟體工程中廣度較大。但是入選文獻最多的兩個刊物也僅有六篇和五篇文獻，且并沒有軟體開發中假設條件及其管理的專用發表刊物。

1. 假設條件的定義

134篇入選文獻中僅有21篇文獻（15.7%）明确定義假設條件的概念。一個潛在的原因為：假設條件的術語在軟體開發中被普遍和經常使用，是以假設條件的術語及概念可能被視為常識[1][2]。如下表所示，比較識别的十二類定義，大部分定義并未解釋假設條件這個詞本身，而是直接使用假設條件作為構成定義的要素。此類定義聚焦于假設條件的關注點。例如在文獻[3]中，作者将環境的假設條件的範圍限制為現實世界的規則以及其他系統的行為。12類定義中的4類定義(33.3%)顯式地提到假設條件的本質在于不确定性。

核心概念	數量（%）
關于特定環境的假設條件	5 (41.7%)
不确定性	4 (33.3%)
可信的選擇、陳述、意見	1 (8.3%)
隐式的設計決策及其原理	1 (8.3%)
不可變性	1 (8.3%)

2. 假設條件的類型及相關的軟體制品

軟體開發中的大部分假設條件在需求工程和軟體設計中被制定或與需求工程和軟體設計的制品關聯。關于此現象有兩個潛在原因：（a）由于在項目早期缺乏足夠的資訊、知識、經驗，假設條件主要集中于這些早期階段（如需求工程階段）。（b）不同階段使用的術語可能不同。例如開發人員在項目後期談到假設條件時可能使用不同的術語。

雖然一種類型的制品可能與一個或多個軟體的開發活動關聯，但此系統文獻映射研究僅考慮與制品關聯的主要活動（即該産生和管理該制品的活動，如需求和需求工程）。是以，軟體維護和演化中無制品與假設條件關聯，且僅有少量文獻處于軟體維護和演化的分類下。此外，本研究發現軟體開發中的假設條件與特定類型的軟體制品關聯，且其關系類型可能較為複雜（如其關系可能為零種、一種、或多種；單向關聯或雙向關聯）。

3. 假設條件管理活動、方法、工具

此系統文獻映射研究識别出十二類假設條件管理活動，但大部分文獻聚焦于假設條件制定（134篇文獻中的108篇；80.6%）、描述（134篇文獻中的89篇；66.4%）、評價（134篇文獻中的83篇；61.9%）。其次是假設條件維護（134篇文獻的30篇；22.4%）。其他假設條件管理活動僅被低于15.0%的入選文獻提到。一個原因可能為：假設條件制定、描述、評價、維護是假設條件管理的主要活動。如果需要管理假設條件，這些主要活動最可能被采用。相反地，其他活動為次要活動（即不一定被采用）。下表提供相應的原理。

活動	原理
制定	假設條件制定是假設條件管理的第一步。若未制定假設條件，則沒有假設條件會存在。
描述	盡管作為一類重要的軟體開發知識，但項目中的假設條件常常不被歸檔，這也是軟體開發中的一個重要挑戰，且導緻多種問題。是以，軟體開發中對假設條件的顯式歸檔具有關鍵的意義。
評價	假設條件可能從一開始即為無效。但是此類假設條件很可能在制定時不會被識别出來。此外，假設條件具有動态的特征，即可能随時間而演化。最後假設條件依賴環境，即不同環境下假設條件可能産生變化。鑒于無效的假設條件對項目有害，假設條件評價是識别無效假設條件的必要手段。
維護	鑒于假設條件随時間演化和依賴環境的特征，可能導緻項目中含有多個無效的假設條件，并進一步導緻多類問題，如體系結構的不比對。是以，假設條件維護在假設條件管理中具有一定的重要性。例如當項目環境改變時，某假設條件可能需要被維護以适應新的環境。

假設條件管理方法和假設條件管理活動類似，即最受關注方法的類型為假設條件制定、描述、評價、維護。相反地，僅有少數文獻提出假設條件追溯、監視、恢複的方法，且沒有文獻提出假設條件交流、複用、了解、檢索、組織的方法。如以上提到的原因，可能這些活動并非軟體開發中假設條件管理的主要活動。

大部分文獻提出的工具（34種工具中的19種；55.9%）用于支援assume-guarantee reasoning。一個原因為：許多入選文獻提出的方法與assume-guarantee reasoning有關。此外，在其他工具中（34種工具中的15種；44.1%），大部分工具支援假設條件描述（15種工具中的12種；80.0%）。此結果的原因為：隻有明确描述假設條件，涉衆才能管理它們。

最後，入選文獻提出的方法和工具都具有相應的使用環境。例如assume-guarantee reasoning是一個強大的系統驗證方法，且支援假設條件制定、描述、評價。但是在軟體開發的其他環境中（如需求分析、設計決策制定），assume-guarantee reasoning并不适用。使用環境是在項目中選擇适用方法和工具的重要因素。

4. 涉衆

所有識别的涉衆類型均會在其工作中制定假設條件，其次是評價和描述假設條件。需求工程、軟體設計、軟體構造中的涉衆在管理假設條件中負主要責任。相反地，沒有入選文獻提及誰與假設條件的複用、檢索、組織關聯。

5. 收益和挑戰

此系統文獻映射研究中收集的收益都有不同的先決條件（如需要使用特定的假設條件管理方法、活動、工具，或者可能導緻特定的挑戰）。例如假設條件描述可使其明确，并降低由隐式假設條件帶來問題的風險。但是假設條件描述可能導緻以下挑戰：即如何描述才可最大化收益而最小化成本。涉衆可能需要投入一定的時間和精力去描述假設條件，而很多相應的輸出在項目中可能并無重大意義。是以，涉衆需要平衡管理假設條件的收益及其帶來的問題。此外，識别的假設條件管理的主要挑戰為：假設條件管理活動難以執行。主要原因是這些活動需要特定的成本，且執行過程中可能遇到資訊不完全、缺乏方法、工具和指南的支援等問題。

6. 未被妥善管理的假設條件

未被妥善管理的假設條件中，以無效的或者隐式的假設條件危害最大。一個原因為：假設條件存在于軟體開發的不同階段，且與多種軟體制品和涉衆關聯。若假設條件無效或隐式，則可能對項目的特定方面産生消極影響。此結果也可作為明确假設條件和減少無效條件的動機。

7. 經驗

與方法和工具類似，此系統文獻映射研究收集的經驗依賴特定的使用環境。若在不同的環境中不加驗證或修改而直接使用這些經驗，則可能在管理假設條件中遇到嚴重的問題。例如在文獻[4]中，作者發現在系統運作過程中，關于運作環境的假設條件可能變為無效。此假設條件的類型為系統運作環境。然而，其他類型的假設條件，如構件假設條件，則不一定會在系統運作過程中變為無效。

參考文獻

[1] G.A. Lewis, T. Mahatham, and L. Wrage. Assumptions Management in Software Development. Technical Report, CMU/SEI-2004-TN-021, 2004.

[2] M.A.A. Mamun and J. Hansson. Review and challenges of assumptions in software development. In: Proceedings of the 2nd Analytic Virtual Integration of Cyber-Physical Systems Workshop (AVICPS), Vienna, Austria, Article No. 7, 2011.

[3] S. Maoz and Y. Sa’ar. Assume-guarantee scenarios: semantics and synthesis. In: Proceedings of the 15th International Conference on Model Driven Engineering Languages and Systems (MODELS), Innsbruck, Austria, pp. 335-351, 2012.

[4] A. Nhlabatsi, Y. Yu, A. Zisman, T. Tun, N. Khan, and A. Bandara. Managing security control assumptions using causal traceability. In: Proceedings of the 8th International Symposium on Software and Systems Traceability (SST), Florence, Italy, pp. 43-49, 2015.