我们知道，对工程软件“旧方法”有很多解释和描述。经过多年的软件开发经验，软件行业已经学习并理解了许多经验教训，并制定或创建了许多原则。其中一些原则如下：
- 创造或创造品质–
必须对软件质量进行度量或量化，并建立机制以激励实现目标。 - 大型或高质量的软件都是可能的–
已经对提高和提高质量的几种技术进行了实际说明，其中包括使客户参与，制作原型，简化设计，进行检查以及雇用优秀人才。 - 尽早为客户提供最终产品–
在需求阶段，我们尝试学习和了解用户需求并不困难，确定和识别其真实和现实需求的最重要和最有效的方法就是将产品提供给用户并让他们使用它。 - 确定问题或问题，然后再写以及需求或要求–
当工程师通常面对他们认为的问题时，他们会急于提供解决方案。但是我们应该记住，在尝试解决任何问题之前，请确保探索所有替代方案，并且不要被明显的解决方案所蒙蔽。 - 评估所有设计备选方案–
当需求达成共识时，我们必须检查并理解各种体系结构和算法。通常，由于需求规范中使用了“架构”，因此通常通常不希望使用“架构”。 - 使用适当且正确的流程模型–
每个项目都必须选择适当的流程，该流程通常基于企业文化，承担风险的意愿，应用范围，需求的可变性以及对所有需求和需求的理解程度，通常对该项目最有意义。 - 在不同阶段使用不同的语言–
我们的行业通常会针对大型复杂问题提供简单的解决方案。由于他的存在，许多人宣称最佳开发方法只是在整个生命周期中都使用符号的一种方法。 - 最小化或减少智力距离–
软件的结构必须与实际结构足够接近，以最大程度地缩短智能距离。 - 在使用工具之前，先将技巧-
一个没有纪律的软件工程师使用工具会变得非常危险和有害。 - 在我们使其变得更快之前就把它弄好–
使正在运行的程序比仅使程序快速运行要快得多，这是非常容易和简单的。 - 检查代码–
评估或检查设计的详细信息和代码是识别测试以外的大多数错误的最佳方法。 - 好的管理比重要的技术更重要-
良好的管理只会激励他人也尽其所能，但是没有通用的“正确”管理风格。 - 成功的关键是“人” –
具有高超的技能，经验，才能和培训的人是成功的关键。 - 小心谨慎并以适当的方式进行操作–
仅仅因为每个人都在做某事并不意味着它对我们来说是正确的。它可能适合我们，也可能不适合。因此，我们必须非常仔细地检查或评估其对环境的适用性。 - 承担责任 –
当桥梁倒塌时，我们只问一个问题：“工程师做错了什么?”即使软件出现故障，我们也很少问这个问题。这是由于在任何工程学科中，都可以使用最佳和重要的方法来生成或开发糟糕的设计，而使用最佳且很大程度上过时的方法来开发优雅的设计。 - 了解客户的优先事项–
客户很可能仅在按时获得10％的性能时，才可以忍受90％的性能延迟交付。 - 他们看到的越多，他们需要的越多–
我们为用户提供的更多功能或性能，他们想要的更多功能或性能。他们的期望会不时增加。 - 计划扔掉一个–
最重要和关键的因素是产品是否是全新的。全新的应用程序，体系结构，接口或算法通常很少是第一次使用。 - 设计更新或更改–
我们应该更新或适应我们通常使用的变更架构，组件和规范技术。 - 没有文档，设计就不是设计–
我们有些工程师经常说“我已经完成并完成了设计，剩下的只是文档”。 - 使用工具时要切合实际–
该软件使用的工具使他们的客户和用户更加高效。 - 封装–
封装只是意味着隐藏信息，而且非常简单。这个概念只会使软件变得更简单，更易于测试并且非常易于维护。 - 避免花样–
一些程序员喜欢用一些技巧构造来创建和开发程序，这些技巧以正确的方式但以一种无法理解的方式执行函数。而是通过避免使用技巧代码向世界证明我们有多聪明。 - 不要测试自己的软件–
软件开发人员不应测试自己的软件。他们不应该是自己软件的主要测试者。
25.耦合与内聚
使用耦合和内聚力是衡量软件固有的可维护性和适应性的最佳方法。 - 除了卓越–
如果我们对员工抱有很高的期望，我们的员工将以更好的方式工作。