就软件设计而言，“不一致”和“不完整”的真正含义是什么？
例如- 创建规范
在创建规范时，与其他不太正式的方法（如面向对象设计）相比，软件工程的形式化方法的使用被认为更少“不一致”和“不完整”。
【问题讨论】：
问题标题表示软件工程。但正文指定了软件设计。这两个术语不是等价的。
关于不一致和不完整，这些适用于许多领域。仅举几例：
不完整：
不一致
【讨论】：
不一致性和不完整性都是形式逻辑中的术语，用于描述逻辑系统。
完整的定义取决于确切的上下文，但inconsistency 通常表示“对于某些 X，您可以证明 X 和 !X”，而 incompleteness 表示类似“对于某些 X，您可以” t 证明 X 而你不能证明 !X"。
因此，对于规范，我将“不一致”理解为“无法实施，因为它在某种程度上是自相矛盾的”，“不完整”表示“未指定 - 对于某些输入，输出没有明确定义”。
【讨论】：
在数据库系统中，一致事务是在执行期间不违反任何完整性约束的事务。如果事务使数据库处于非法状态，则将其中止并报告错误。
在算法中，完整性的概念是指算法找到解决方案（如果存在）的能力，如果不存在，则报告没有解决方案是可能的。
在计算复杂性理论中，如果 P 在 C 中，则在给定类型的归约下，对于复杂性类别 C，问题 P 是完整的，并且 C 中的每个问题都使用该归约归约为 P。例如，NP-complete 类中的每个问题对于 NP 类都是完全的，在多项式时间、多对一约简下。
在软件测试中，完整性的目标是调用图（软件项之间）和控制图（每个软件项内部）的功能验证。 完备性的概念见于知识库理论。
您可以继续使用这样的定义...也许可以让问题变得不那么模糊？
如果我有一个糟糕的一天，我会链接到“Goedels 不完备定理”，因为它肯定会成为主题；）
【讨论】：
在正式系统的上下文中，一致性和完整性（以及它们各自的否定）的一个含义如下。粗略地说，一个系统是一致的，当且仅当不可能从中得出矛盾。如果可以生成有关底层模型的所有真相，则系统是完整的。理想的情况是提出一组合理的公理，能够“捕获”所有且仅能“捕获”某个给定领域的真相。
【讨论】：
它们可能意味着很多东西，我将在这里举一些例子：
不一致：
不完整：
名单还在继续……
【讨论】：
根据上下文，Formal Methods 可能指的是用于证明程序正确性的数学技术。在这种情况下，使用数学证明将确保规范不会不一致（没有逻辑矛盾）或incomplete（规范有效性的正式证明）。
【讨论】：
在您提供的示例的上下文中，它们只是意味着强制实施一个正式的流程——一个具有端到端记录方法、方法、一组可交付成果、定义的角色和职责的流程，将产生一个比针对同一问题的临时方法更好的产品。换句话说，描述完整软件工程过程的正式系统在项目的整个生命周期中始终如一地使用和应用，将比不提供此支持框架的系统产生更好的结果。
这就像盖房子一样。是的，你可以用完并开始一起钉板，你也许可以建造一些你可以居住的东西，但如果你改为学习建筑、建筑材料和技术、定义工作流程等，你最终会得到更好的房子。不过，比这更好的是，您将能够再次建造同样的房子或类似的房子，而且成功的可能性要高得多。
【讨论】：