2009年7月14日
似乎每一代人都需要重新学习前几代人的教训。这同样适用于制造业，老工程师退休了，必须把知识传授给年轻的工程师。不幸的是，对于软件制造业来说，实际上可以传授的经验很少。许多健壮的制造软件开发所需的知识对老工程师来说是不了解的。在他们的职业生涯中，软件开发的语言、工具和方法一直在不断地发展和变化。制造软件课程必须来自制造学科之外，而且应该来自软件工程学科。许多软件工程的经验教训都是通过开发生命周期长达数十年的大型系统获得的。这种情况在制造业中很常见，即使在现代非制造业和不受管制的软件系统中也越来越少见。许多现代系统的设计寿命都很短——在更换之前最多5年——并且假定原始程序员可以进行维护。幸运的是，制造软件的开发人员可以从传统的软件工程规则中学习。关于制造软件的一个残酷事实是，它不是由软件工程师或计算机科学专业的学生开发的。我们不会经常要求电气工程师设计机械系统，或化学工程师设计电气系统，但我们经常要求机械、电气和化学工程师设计和开发软件系统。如果您处于这种情况，那么您应该相信软件工程方法。“T”代表试演和原型。工程学科使用物理或数学模型来理解一个系统的基本概念和关系。原型在软件中扮演同样的角色。根据您的开发方法，原型可以抛弃尝试或增量设计元素。但是，它们应该是所有项目的共同起点。仅仅因为某人对软件项目有一个好的概念并不意味着这个项目是可行的。试验证实这个概念在技术上是可行的。打个比方，在汽车工程中，仅仅因为有人设想一辆汽车每加仑行驶300英里，并不意味着它是可行的。原型证明或否定了可行性。“R”代表需求。一旦您知道项目在技术上是可行的，您就可以编写用户、功能和设计需求。这些需求说明了必须做什么，以及最终系统必须如何在您的生产环境中运行。“U”代表用例。虽然需求文档很重要，但它们并没有说明最终用户将如何使用软件。用例定义了正常的操作方法，以及预期的错误条件和响应。这些用例旨在帮助最终用户理解将提供什么。“S”代表源代码、标准和构建脚本。只有在您理解了需求和用例之后，才应该开发源代码。如果您遵循敏捷项目方法，它可以在小块中开发，如果您遵循迭代或瀑布方法，则可以在大块中开发。注释、配置管理和版权标准必须应用于所有生成的代码和文档。构建脚本允许在一个新的系统上每天或每周自动地重新创建项目软件，消除手工错误和配置问题。“T”代表测试用例和测试脚本。这些是用来验证软件在正常和错误条件下是否按规定运行的详细定义。在成功运行测试用例之前，软件还没有准备好进行部署。这些都是最后的正确性证明。相信从软件工程中学到的教训，并将它们应用到您的项目中。
打印这一页|电子邮件这一页
这不是付费墙。这是一个Freewall。我们不想妨碍你来这里的目的，所以这只需要几秒钟。
现在注册