软件工程中的系统文献映射研究实例-软件开发中假设条件管理的收益和挑战是哪些？（第八部分）

本文链接：https://blog.csdn.net/ytomc/article/details/90573672

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

这篇博客主要介绍第七个研究问题的结果，即软件开发中假设条件管理的收益和挑战是哪些。

1. 软件开发活动的收益

下表依据SWEBOK [1]将假设条件管理对软件开发活动的收益分类为：需求工程、软件设计、软件构造、软件测试、软件维护和演化。

软件开发活动	收益
需求工程	（1）通过追溯假设条件到其来源可明确用户的隐式知识。（2）通过形式化地建模假设条件、需求和系统的行为可明确假设条件的意义并帮助需求分析、描述和验证。（3）帮助分析需求文档的质量和完整性。（4）帮助理解需求工程师的想法。（5）减少需求工程花费的时间。（6）帮助需求工程中一致性的管理。（7）缩小问题空间。（8）帮助探测需求的偏差以及需求之间的关系。（9）帮助识别需求。（10）明确需求的问题。（11）帮助构建原型。
软件设计	（1）基于服务的假设条件可支持服务的合成。（2）通过关联和推理需求、假设条件、约束、设计决策以帮助理解体系结构设计。（3）帮助方面的设计和复用。（4）帮助识别体系结构的交互点。（5）提高体系结构活动的效力。（6）降低从需求工程过渡到体系结构设计的难度。（7）减少操作模型的成本。（8）支持体系结构知识管理。（9）支持在软件设计中基于不完全信息的推理。（10）提高模型和体系结构的质量。
软件构造	（1）通过设计的假设条件以支持对需求属性的检查。（2）提高代码的质量。（3）帮助理解、评价、构造代码。（4）通过使用线程的假设条件以保证信息流的安全性。
软件测试	（1）通过在构件测试中使用assume-guarantee属性以减少测试时间。（2）帮助识别和修复漏洞。
软件维护和演化	（1）通过使用生成的假设条件帮助在构件的演化中有效地重复检测基于构件的系统。（2）促进关于系统演化的讨论。（3）促进知识的转移以支持软件的维护和演化。（4）使软件演化更可靠。（5）降低软件维护的难度。（6）帮助演化的版本发布计划。（7）通过明确假设条件以帮助探测、减少和修复系统错误、终端产品缺陷、脆弱性等。（8）提供应用程序和系统中不匹配的警告。（9）减少系统错误的风险。

2. 其他收益

下表列出未明确关联软件开发活动的假设条件管理的其他收益。

收益类型	收益描述
系统验证	（1）通过提供基于assume-guarantee reasoning的自动化验证技术以促进软件系统的验证，包括模块验证、构件验证、程序验证。（2）提高代码级别以及系统级别的模型检测的效率。
成本	（1）通过使用assume-guarantee技术以降低在基于构件的系统中的模块验证的计算成本。（2）帮助分析改变系统的成本。（3）降低金钱投入。（4）避免会导致高成本的错误。
可追溯性	（1）通过追溯假设条件与其他类型的软件制品以提高可追溯性。（2）帮助假设条件、设计和实现追溯。
软件开发	（1）通过将假设条件表达为语法的约束以促进API开发。例如自动化地检测对某API的使用是否正确。（2）通过使用基于模型的assume-guarantee原理以促进嵌入式软件开发（如建模和分析）。（3）通过使用assume-guarantee原理以促进多线程程序开发（如对线程行为建模）。（4）促进敏捷开发（5）为软件的开发过程提供指南。（6）帮助设计新的软件开发过程。（7）提高软件开发以及对软件使用的可靠性。（8）在迭代的开发中使连续的开发迭代之间过渡更平滑。（9）降低软件开发需要投入的时间和精力。
不一致性管理	（1）通过使用派生类比以检测需求和设计决策间的不匹配。（2）降低由于假设条件不兼容导致的风险。
涉众	（1）通过使用结构和目标模型追溯假设条件和需求以帮助用户和设计师获得对软件的清晰、一致的理解。（2）促进软件开发团队对程序设计和在软件体系结构、测试计划、分类过程如何明确假设条件的深入思考。（3）帮助涉众设定更实际的期望。（4）帮助涉众理解建模活动和系统。（5）为涉众提供结构化的思考和辩论方法。（6）通过在虚拟环境中集成和实现带有假设条件的软件模型以帮助涉众在开发的早期阶段获得必要的知识。
软件质量	（1）通过明确不同类型的构件假设条件或基于不变性的假设条件制定关于系统不变性的设计决策以提高软件质量。（2）提高系统的安全性和可靠性。（3）使网络服务更灵活和智能。
其他	（1）帮助识别关于需求控制的更有效的运行时方案。（2）帮助满足安全性需求。（3）在假设条件描述中使用非决定论可以通过仅分析独立的配置属性而不需要列举配置设置的组合从而达到促进系统配置的目的。（4）通过生成最弱的环境假设条件以支持运行时监视和构件检索。（5）通过在算法扩展中使用环境的假设条件以更好地描述系统（如系统的行为）。（6）通过在构件测试中使用assume-guarantee属性以单独检查每个构件从而使重现有问题的构件行为更加容易。（7）减少项目的风险。例如通过半自动化过程管理无效的假设条件的风险。（8）帮助连接一个系统及其操作环境。（9）减少执行过程中的不期望或有问题的行为，提高系统运行时的可靠性，促进执行过程中的一致性管理。

3. 挑战

下表将假设条件管理的挑战分为两大类：假设条件和假设条件管理。

挑战类型	挑战子类型	描述
假设条件	区分假设条件和其他类型的制品	区分假设条件和其他类型的制品（如需求）具有一定难度。
	假设条件的分类	难以对软件开发中的假设条件进行分类。
	软件错误和无效的假设条件	难以分析软件错误和无效的假设条件间的因果关系。
	理想和现实世界的差距	理想世界中的假设条件可能在现实世界中并不存在。
假设条件管理	假设条件管理活动	因多种原因，如需要付出的努力、不完整的信息、缺少方法、工具或指南，假设条件管理活动难以执行。
	假设条件爆炸	难以管理数量庞大的假设条件或者在assume-guarantee reasoning中具有多种状态的假设条件。
	假设条件的明确	涉众在工作中难以意识到他们制定的假设条件。
	经验和知识	涉众缺乏在软件开发中管理假设条件所需的经验和知识，例如对假设条件属性和概念的不熟悉。
	集成至软件开发	难以将假设条件管理集成至软件开发活动或者整个软件开发过程。
	收益不明	软件开发中管理假设条件的收益不明确。
	短期收益	管理假设条件无法带来短期收益。