我想分享这个，这是我在系统安全邮件列表中找到的:https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
马丁·托马斯(Martyn Thomas)在实现计算机系统方面拥有丰富的经验，是Praxis公司的创始人，该公司现在是Altran集团的一部分，成为“国际公认的使用严格软件工程的领导者，包括数学形式方法”。他在一个关于软件的帖子中写道:
我想起了Dijkstra在1973年的一次演讲。一位听众问道:“你的方法对现实世界的问题有效吗?”Dijkstra停顿了一下，然后平静地说:“现实世界的问题。啊，是的，当你没有应用所有已知的解决方案时，那些仍然存在的问题。” 多年来，我听过许多未能使用专业工程方法的借口。 "如果我们培训程序员，他们就会去找一份薪水更高的工作" "我们不能雇佣愿意使用那种编程语言的程序员" “大学不教(数学、项目管理、质量控制、计划、团队合作... ...)” “为了兼容性，客户坚持要求我们使用这个(有bug的)中间件” “现代软件不是写出来的——它是由大量(有bug的)COTS组装而成的。” “如果我们试图将其纳入标准，行业将会反对。” "如果我们要这些证据，企业会收我们一大笔钱" 还有很多很多。 大多数软件开发人员似乎都忽略了这个问题。每周，我都听到有人用动词“test”来表示“确信……适合目的”;这揭示了一个危险的、隐含的假设，即“测试-修复”是开发软件的唯一可行方法。大多数软件仍然是用没有良好数据结构和强类型检查的语言编写的。大多数软件需求(甚至是接口规范)都是用英语(或其他自然语言)编写的——可能带有一些缺乏严格语义的图。大多数项目都有严重不足的变更控制。我很少看到有价值的风险记录(除了证明项目经理没有管理项目)。 是否存在另一种行业:(a)使用不合格的人员构建复杂、新颖和关键的系统，(b)几乎只使用有重大已知缺陷的工具，(c)使用来历不明、无法证明适合用途的组件构建系统，(d)尽管如此，仍声称自己是专业工程师? 显然，我们这个职业目前的状态是不可持续的。让我们停止找借口，寻找方法来加速我们知道需要的改变。在我看来，Martyn对整个软件领域提出了一个非常准确的观点。即使在安全关键领域，对这些问题的关注仍然太少。我们如何着手解决这个问题?还是说现在把魔鬼放回瓶子里太晚了?
在应用了所有严格的方法之后，剩下的是一个复杂的系统，由于对资源的竞争，这个系统有时会试图打败自己。工人的职能在管理职能期间暂停，管理职能依赖于同样的解释和执行能力。对输入进行时间到空间的转换，对输出进行有用的空间到时间的转换。大多数软件附带的免责声明道出了事实:买家当心。
有一种补救办法，一种可以替代tm的方法，它在时域内，而不是被降级到空间域。
详情请参阅c.moeller@ieee.org