软件工程中的信任

似乎每一代人都需要重新学习前几代人的教训。制造业也是如此，老工程师即将退休，必须将知识传授给年轻工程师。

不幸的是，对于制造软件来说，实际上很少有可以传递的经验教训。健壮的制造软件开发所需的许多知识对于老工程师来说是不知道的。软件开发的语言、工具和方法在其职业生涯中一直在不断发展和变化。

制造软件课程必须来自制造学科之外，并且应该来自软件工程学科。许多软件工程的经验教训都是通过开发具有数十年生命周期的大型系统获得的。这是制造业中常见的情况，即使它在现代非制造业和非规范软件系统中变得越来越罕见。许多现代系统的设计寿命都很短——更换前最多5年——并且假定原来的程序员可以进行维护。幸运的是，制造软件的开发人员可以从传统的软件工程规则中学习。

制造软件的残酷事实之一是，它不是由软件工程师或计算机科学专业的学生开发的。我们不会定期要求电气工程师设计机械系统，或者要求化学工程师设计电气系统，但我们经常要求机械、电气和化学工程师设计和开发软件系统。如果您处于这种情况，您应该信任软件工程方法。

“T”代表试用和原型。工程学科使用物理或数学模型来理解系统的基本概念和关系。原型在软件中扮演着同样的角色。根据您的开发方法，原型可以被丢弃，作为试用或增量设计元素。然而，它们应该是所有项目的共同起点。

仅仅因为某人对一个软件项目有一个好的概念并不意味着这个项目是可行的。试验证实，这一概念在技术上是可行的。通过类比，在汽车工程中，仅仅因为某人想象一辆汽车每加仑行驶300英里并不意味着它是可行的。原型证明或否定可行性。

“R”代表需求。一旦您知道项目在技术上是可行的，您就可以编写用户、功能和设计需求。这些要求记录了必须做什么以及最终系统必须如何在您的制造环境中运行。

“U”表示用例。虽然需求文档很重要，但它们并没有记录最终用户如何使用软件。用例定义正常的操作方法，以及预期的错误条件和响应。设计用例是为了帮助最终用户理解将提供什么。

“S”代表源代码、标准和构建脚本。只有在您理解了需求和用例之后，才应该开发源代码。如果您遵循敏捷项目方法，则可以将其分成小块进行开发;如果您遵循迭代或瀑布方法，则可以将其分成大块进行开发。注释、配置管理和版权标准必须应用于所有生成的代码和文档。构建脚本允许每天或每周在新系统上自动重新创建项目软件，从而消除手动错误和配置问题。

“T”代表测试用例和测试脚本。这些是用于验证软件在正常和错误条件下按规定运行的详细定义。在成功运行测试用例之前，软件还没有为部署做好准备。这些是正确的最后证明。

相信从软件工程中学到的经验教训，并将它们应用到您的项目中。

www.globalelove.com

作者信息

丹尼斯·布兰德是北卡罗来纳州卡里市BR&L咨询公司的总裁，dbrandl@brlconsulting.com．

您是否具有本内容中提到的主题的经验和专业知识?您应该考虑为我们的CFE媒体编辑团队做出贡献，并获得您和您的公司应得的认可。点击在这里开始这个过程。