仔细分析“7·23”甬温线特别重大铁路交通事故的过程，会给我们带来很多启示：
    1，要有风险意识

    “7·23”甬温线事故之所以引起如此大的关注，除了态度问题以外，还有一个大的背景，就是在这之前京沪高铁已经出过多次事故（很遗憾，事故原因和这次特大事故技术原因几乎一致，都是通信信号的问题），但这并没有引起人们重视，还是一味地说我们的高铁没问题，比日本好比美国好，这就是没有风险意识的典型表现，没有感受到危险正在迫近，最后酿成大祸。这给了我们很重要的启示，我们在系统架构设计中，一定要把用风险来驱动设计的理念放到重要的位置，要关注风险对设计的影响，要善于识别风险和化解风险，这也是一个成熟的高级设计人员的特征。在需求分析的时候，不能只关注对所要求功能的正确表述，要把更多的精力放在异常情况的表述上，例如当发生什么情况时会引发什么情况，该如何解决？这样的需求才可能给设计提供更多的支持。软件企业一定要有一批受过良好训练的需求分析人员，而不能把需求分析仅仅作为附带的工作。在这次事故中通信信号有个很大的问题，就是一旦发生异常（雷击造成保险丝熔断），会发出错误信号（红灯变绿灯），显然在当初设计通信信号系统进行需求分析的时候，并没有设想到这个情况，需求分析中也没有提出这个要求（在发生故障的时候不能发出错误信号），由于系统测试是依据需求进行的，因此系统测试的时候也就不会对此进行测试，这就形成了隐性Bug，结果酿成重大事故。
    2，产品设计要坚持质量第一

    “7·23”甬温线事故给我们最大的启示，就是我们软件企业是该关注一下产品质量了。事实上坚持产品质量已经提了很多年，但一直没有引起众多软件企业的重视。产品质量并不能靠在交付阶段不断加班、修修补补、赖赖巴巴的满足要求来达到的，更不是靠事后补一些文档来应付检查，而是要依靠整个开发过程中的质量控制，通过实施全面的质量管理来达到，这就需要投入相当多的人力、物力和财力。换句话说，加强产品质量并不会降低成本，相反开发成本会有一定程度的提高，但从长远来看这会获得更大的利益。软件的质量还取决于设计人员思维的缜密，这需要有很好的前期需求，要考虑到各种例外和异常情况，每一种例外都需要作为一个场景进行测试，需要有很高的测试覆盖率。抓质量更要关注细节，粗粗拉拉的产品永远不是高质量的产品，质量很大程度上都是通过细节来体现的。要通过多次重构反复优化程序结构，要仔细思考什么样的程序结构才是优秀的，以此对程序进行不断优化和精化。这些都可能很麻烦，会延长软件交付时间，但没办法，我们必须跨过这个坎。
    3，要用系统的观点看问题

    “7·23”甬温线事故我们还可以看到一个问题，那就是从单点来看也可能谁都没错，但从系统上看错了。我们的高等教育在这方面非常薄弱，人们只关注自己专业范畴的事，而一谈从系统的角度看问题就感觉虚，这就造成了人才上的缺陷。一个高级设计人员必须学会从系统的角度看问题，要关注谁推动谁，谁拉动谁，谁影响谁，这就是系统设计的根本。我经常感叹，一些很聪明很有能力的人，到了实际工作岗位努力工作，慢慢沉溺于琐碎的工作中，思维慢慢得失去了线路，变成了一个个的碎片，他很忙，也很努力，但漫漫的就失去价值了，因为高级人员的价值就在于能看到系统，能尽早感知风险，能确定正确的目标。
    产品质量控制是一个系统，单点质量没什么意义，必须整体上每个控制点的质量都要好，这就需要付出巨大的努力。要注意到从系统的角度看质量是一个乘法，总体质量是每个单点质量乘在一起的，只要有一个点质量是是0，总的质量就是0。“7·23”甬温线事故中我们看到，车头质量很好跑得很快，铁轨质量很好能够承载，但并不等于总体质量就很好，一个小小的bug引起了对整个体系质量的否定，关于质量的这个原理我们都要铭记于心。因此，在我们的课程中会强调“高质量软件项目管理”、“需求分析中的质量属性定义”、“质量属性影响下的架构设计”、“用质量目标驱动软件过程改进”、“质量控制与质量保证”、“变更环境下的软件配置管理”等等这些和质量紧密相关的问题。随着社会运转的速度越来越快，人们对于自动化系统的依赖也越来越大，这就对软件质量提出了更苛刻的要求，我们必须改变我们的习惯和某些文化，为产品质量投入更多的成本和关注。
    “7·23”甬温线特别重大铁路交通事故死了很多人，但如果我们各行各业都能从中吸取教训，能够形成一个正确的观念，以后把事情做得更好，这才是更好的告慰亡灵。相反仅仅是作为茶余饭后的谈资，我想这是对死者最大的不尊重。