软件工程中的系统文献映射研究实例-对九个研究问题相关结果的分析（第十一部分）

之前的博客详细描述了软件工程中的系统文献映射研究方法。这里接着给出一个我曾经做过的工作作为例子，以更直观地展示这种研究类型。该研究的背景信息这里不再赘述。                  

这篇博客主要介绍基于前面九个研究问题的结果，我们可以得到什么更深层次的结论。

入选文献来自于九十四个不同来源。这表明假设条件及其管理在软件工程中广度较大。但是入选文献最多的两个刊物也仅有六篇和五篇文献，且并没有软件开发中假设条件及其管理的专用发表刊物。

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.