1.为什么部标平台的开发周期长?
1)首先对于交通部部标标准文档的阅读、理解和消化需要很长时间,你面对的是冷冰冰的交通部信息中心颁发的jt/t 796、808、809协议文档,面对文字的歧义,这个消化、曲解、走弯路的时间成本,伴随在整个软件开发周期当中,一直到你进京赶考,进行部标检测,最终过检。所以这个时间是无法估计的,理解完毕,将理解的文档转化成开发团队必须要完成的功能用例,中间的误差极大,这也是很多开发者容易自信、乐观冒进的原因。
你必须需要阅读和理解的协议文档有四份: 796文档、808协议文档、809协议文档、GB19056文档。参见-》交通部道路运输车辆卫星定位系统部标JTT808、809、796标准大全
2)对于标准的严酷性准备不足,正常自己公司开发一个系统,功能标准是自己的写的,差不多,八九不离十就行了。很多开发者用这种习惯开发部标平台,很多功能看似都是八九不离十,结果到最后,结局就是通不过。在检测中心,检测人员进行检测主要是依靠检测工具和检测用例文档,特别是测试用例文档,比自己公司测试部门写的黑盒测试用例都写的细致和充分,可惜你看不到这个文档,开发人员就像一个瞎子不断的拿着自己脑袋硬碰才找到门在那里。
3)联调难度大
考不容易开发出来一个东西,需要测试,从客户端到服务器再到gps终端这样一个双向联调测试,服务器有服务器的问题,客户端有客户端的问题,网络通讯有网络通讯的问题,合在在一起联调,就像一群坏孩子集中在一个班里,乱成一锅粥了。由于互相影响,耽误的时间都是叠加在一起的,而不是并行开发所能解决的了得。
4)前面问题,是部标平台开发不同于常规的信息化软件开发之处,这些不同之处加大或者恶化了计划失真的问题,就是无知者无畏,容易乐观、轻视、冒进、准备不足,反而更容易拖延整个开发交付的周期。我增经见过一个最激进的部标监控平台的开发计划,整个平台计划50多天完成,设计一周时间,部标808gps服务器一个月完成,web客户端20多天就要完成,809运管平台接入10多天就完成,留给测试的时间就5天。当时我就震惊了。估计是领导根据市场情况强加的,这简直是要人命的。项目经理很据领导或自己的意志写项目计划,反正计划归计划,让写几天就写几天吧,到时间完不成,就继续延期呗,难不成还开除不成?
2.如何快速开发部标监控平台?
坦白的说,就是购买我的源码,进而获得我的技术支持和经验,少走弯路。有两个路径可以走:
1)结合自己团队的情况,购买我的部标808GPS服务器、部标809GPS服务器源码,大幅缩短自己在协议理解、开发、性能调试上的时间,在此基础上集中精力开发网页客户端或者CS客户端。极大减轻的进度压力,毕竟没有谁愿意顶着压力做事,从从容容得做事,是一件很幸福的事情,对于公司来讲,也会节省掉几个月的开发费用支出。当然转变思维也不是件容易的事,虽然花的是公司的钱,省得也是公司的钱。参见我的博客文章:如何提高生产力(一) -养成交换的习惯
2)购买完整部标平台的源码(包含部标808服务器、809服务器、网页客户端和安卓客户端)
公司或团队购买后,直接过检或者在此基础上,集中精力开发有行业竞争力的差异化客户需求功能,开发周期从以前的一年多的时间缩短为一个月的时间,一年多的开发费用是多少,会数学应该能算出来,划不划算,更应该能算清楚。
3.开发文章索引
1)C#版的808GPS服务器开发-》基于部标JT/T 808协议及数据格式的GPS服务器
2)Java版的808GPS服务器开发-》基于Java Mina框架的部标808服务器设计和开发
3)C#版的809GPS服务器开发-》基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器
4)Java版的809GPS服务器开发-》基于Java Mina 通信框架的JT/T809转发服务器设计
5)Asp.NET版的部标平台开发-》基于Asp.NET MVC构建GPS部标平台
6)Java版的部标平台开发-》基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台
7)基于C# winform桌面客户端的部标平台开发-》GPS监控客户端设计
8)地图纠偏加篇算法-》地图服务算法库
9)手机客户端-》Android手机客户端和手机查车设计
10)部标检测-》交通部部标监控平台检测