从软件工程学角度探讨动车追尾事件
　有很久没写技术文章了，恰巧昨晚温州发生了动车脱轨事故，所以打算单纯的从软件工程学角度探讨1下相关的事故原因。以下文字皆为本人在梦游状态中所写，不代表本人观点，谢绝跨省。

　　首先，根据官方公布的事故原因是因为前车遭遇雷击后，失去动力停车。尾车未采取应急措施，继续按照原定发车时间表前行，在高架桥中发生追尾，导致列车脱轨。

　　众所周知，动车的时速往往在200公里以上。鉴于此，当前车因紧急故障而停车时，尾车的驾驶人员绝对没有足够的时间采取任何应急措施。整体的应急响应机制，必须基于计算机系统及专用网络予以实施。即当调度中心通过专用网络收到车辆紧急停车信号或失去车辆信号后，基于一系列的规则判断后，向同一路线运行的后续车辆发送紧急停车信号。鉴于此，本次事故的原因，有很大一部分在于调度系统故障或反应时间过长。

　　鉴于，上午已经提及的动车本身时速的考量，由调度中心工作人员在获悉紧急状况后人工采取应急机制，反应时间过长，可行性极低。因此，必须采用高度自动化的计算机软件系统进行自动化响应。但是，很明显当出现信号盲区等一系列情况时，可能出现误报，而此时采取后续车辆紧急停车处理，往往是没有必要的。

　　由此可件，从需求分析而言，敏感度（即产生误报的概率）、反应速度、冗余能力是该应急响应系统首要性能指标。而于此同时，鉴于该应急响论文范文http://www.chuibin.com 应系统的特殊性。必须保证本身的项目质量，高密度的软件测试是不可避免的。由此可见，本次事故本身极有可能是首要性能指标不达标或软件测试密度不足所致。

　　因此，从软件工程角度而言，本次事故于欧洲阿里亚娜火箭爆炸或Therac-25事故如出一辙。完全是可以通过增大前期需求分析及后期软件测试的强度而可以避免的。

　　面向对象，这一概念在软件工程学界已经有了20余年的历史。在中国，基于版本控制和里程碑管理等软件工程学方法，进行系统开发也已经有了十多年的历史。可是即使在今天，大量的软件外包企业依旧将软件工程和软件质量管理视为走流程走过场。大量的外包企业，往往不注重于项目质量，以完成客户需求、客户同意验收，而非软件工程本身的性能达标为工作目的。在开发前期，亦往往只是通过客户所提需求进行开发，而不基于客观实际进行任何的需求分析，一味的追赶项目进度。

　　显而易见，这是上个世纪60年代软件危机在中国的在线，也是对中国软件外包产业的当头一棒。只是不知，这些平白无故而流逝的鲜血，究竟能唤醒多少躺在人民币上的企业的良知。