翻开第一篇聊假设条件的博客，发现已经快2年了。那篇主要涉及了点架构方面假设条件的东西，不是很全，今天开一篇聊一下软件开发中的假设条件。如果把假设条件限定在架构方面，稍显冷门。但如果将其扩展到整个软件开发中，这里面已有的工作非常多。这篇博客首先关联软件开发中的不确定性和假设条件，其次给出软件开发中假设条件的定义，最后举几个由未妥善管理假设条件引起问题的例子。
在软件开发中，存在很多不确定性，但为了实现项目目标（如在计划内完成项目），涉众往往需要应对这些不确定的事物（如假设条件制定）。例如系统中需要采用一种新技术，而该技术的发布日期存在不确定性。那么涉众可能会假设一个可能的发布日期。软件开发中有许多针对不确定性的研究。以下给出四个例子。Ziv等人提到软件开发中有多种不同的不确定性，如需求分析中的不确定性、系统需求过渡到设计乃至代码中的不确定性、软件再工程中的不确定性、软件复用中的不确定性、测试中的不确定性[1]。例如Ziv等引用Humphrey书中的内容[2]以解释为什么需求分析中含有不确定性：即对于一个新的软件系统，在用户使用前需求都不会完全的清晰。Liu等人[3]关注需求不确定性，并讨论了需求不确定性、涉众间的冲突、软件项目效率间的关系。例如Liu等人认为需求不确定性导致不稳定的需求，而这种需求可以进一步导致涉众间的冲突。Whittle等人[4]提出了一种语言（RELAX）以解决自适应系统中的需求不确定性。Whittle等人认为不确定性来源于两个方面：（1）环境不确定性（即环境可能发生变化）以及（2）行为不确定性（即需求可能变化）。Cheng等人[5]同样提到环境不确定性是研究和采用动态自适应的关键因素，即根据系统环境的变化，持续地改变系统的行为。他们说道：“在开发周期内，不可能预知所有未来可能遇到的系统环境条件集合。”
本人认为不确定性和假设条件应作为两种不同但相关的概念：应对不确定性存在多种方式，其中一种方式就是制定显式的或者隐式的假设条件。例如上述的例子中，涉众也可通过选择采用其他技术的方式以应对该不确定性。
在英文字典中，假设条件的定义为：“a thing that is accepted as true or as certain to happen, without proof”[6]或者“a fact or statement taken for granted”[7]。本人定义软件开发中的假设条件为：在没有足够证据支持的情况下，被接受或认可为真的软件开发知识。根据Alavi和Leidner[8]的文章以及Aurum等人[9]书中的描述，软件开发知识代表在软件开发中与事实、过程、概念、解释、想法、观察、判断相关的个性化信息。以上对假设条件的定义强调在软件开发中，假设条件具备不确定性的特征：涉众相信但不确定特定的软件开发知识的重要性、影响、适当性、适应性、正确性等。例如某项目经理假设其项目开发团队中的软件工程师具备足够的技能和能力来完成该项目。在这条描述中，该项目经理并非完全确定这些软件工程师是否具备足够的技能和能力。又如某软件开发人员假设修改构件A不会影响系统中的其他构件。在此描述中，该开发人员不确定修改构件A所造成的影响。在软件开发中假设条件是一个较为宽泛的主题：不同类型的假设条件被广泛地讨论（如需求假设条件[11]、软件架构假设条件[12]、软件构造假设条件[13]）。不同的涉众（例如设计师、需求工程师、开发人员和测试人员）频繁地在工作中制定假设条件[13]。
因为未得到妥善管理的假设条件可能在软件开发中导致多种问题，许多研究者指出软件开发中假设条件及其管理的重要性[7]。以下提供五个相关例子。首先，Corbató[14]在图灵奖获奖演讲中指出：项目早期往往会制定一些假设条件。在后期，例如增加新功能时，若不注意这些假设条件则可能导致设计漏洞。其次，Garlan等人[15]指出：软件架构中不兼容的假设条件可能导致架构的不匹配（如构件或者连接器之间的不匹配）。软件架构的不匹配可能会导致进一步的问题，如设计的违反和低质量的架构。再次，因为假设条件概念的主观性，涉众可能对已经存在的假设条件产生误解[16]。对假设条件的误解可能进一步造成对其他相关软件制品的误解。例如因为对设计决策背后假设条件的忽视，涉众可能误解这些设计决策的真正含义。第四，Steingruebl和Peterson[17]提出未归档的软件开发中的假设条件可能导致软件的故障。例如假设系统将在单机模式下运行，则不必考虑外部安全性（如跨站脚本攻击和系统权限设计）。 但若该假设条件未被归档，当系统运行环境发生改变时（如系统将被部署到网络上），则可能导致安全问题。最后，Bazaz等人[18]定义系统脆弱性为“a state of the system from which it is possible to transition to an incorrect system state”，并指出对系统资源假设条件的违反可能导致系统变得脆弱（如内存或者I/O系统出现漏洞）。
[1] H. Ziv, D. Richardson, and R. Klösch. The Uncertainty Principle in Software Engineering. Technical Report, 1997.
[2] W.S. Humphrey. A Discipline for Software Engineering. SEI Series in Software Engineering, Addison-Wesley, 1995.
[3] J.Y.C. Liu, H.G. Chen, C.C. Chen, and T.S. Sheu. Relationships among interpersonal conflict, requirements uncertainty, and software project performance. International Journal of Project Management, 29(5): 547–556, 2011.
[4] J. Whittle, P. Sawyer, N. Bencomo, B.H.C. Cheng, and J.M. Bruel. RELAX: A language to address uncertainty in self-adaptive systems requirement. Requirements Engineering, 15(2): 177-196, 2010.
[5] B.H.C Cheng, P. Sawyer, N. Bencomo, and J. Whittle. A goal-based modeling approach to develop requirements of an adaptive system with environmental uncertainty. In: Proceedings of the 12th International Conference on Model Driven Engineering Languages and Systems (MODELS), Denver, CO, USA, pp. 468-483, 2009.
[6] Oxford Dictionaries. http://www.oxforddictionaries.com/definition/english/assumption
[7] Merriam-Webster. http://www.merriam-webster.com/dictionary/assumption
[8] M. Alavi and D.E. Leidner. Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly, 25(1): 107-136, 2001.
[9] A. Aurum, R. Jeffery, C. Wohlin, and M. Handzic. Managing Software Engineering Knowledge, Springer-Verlag, New York, 2003.
[10] P. Kroll and P. Kruchten. The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP. Addison-Wesley Professional, 2003.
[11] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh. Using trust assumptions with security requirements. Requirements Engineering, 11(2): 138-151, 2006.
[12] M.M. Lehman and J.F. Ramil. Rules and tools for software evolution planning and management. Annals of Software Engineering, 11(1): 15-44, 2001.
[13] G.A. Lewis, T. Mahatham, and L. Wrage. Assumptions Management in Software Development. Technical Report, CMU/SEI-2004-TN-021, 2004.
[14] F.J. Corbató. On building systems that will fail. ACM Turing Award lectures, Year Awarded 1990, Communications of the ACM, 34(9): 72-81, 1991.
[15] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is still so hard. IEEE Software, 26(4): 66-69, 2009.
[16] R. Roeller, P. Lago, and H. van Vliet. Recovering architectural assumptions. Journal of Systems and Software, 79(4): 552-573, 2006.
[17] A. Steingruebl and G. Peterson. Software assumptions lead to preventable errors. IEEE Security & Privacy, 7(4): 84-87, 2009.
[18] A. Bazaz, J.D. Arthur, and J.G. Tront. Modeling security vulnerabilities: A constraints and assumptions perspective. In: Proceedings of the 2nd IEEE International Symposium on Dependable, Autonomic and Secure Computing (DASC), Indianapolis, IN, USA, pp. 95-102, 2006.