游泳场项目总结

      十一终于完了,进入到新的项目.终于有时间来总结一下做的一个游泳场的项目了.从项目开始到现在,已经三个月了.中间有很多次想要将这个东西写下来,始终没机会.现在有时间,好好想一下,也算是对自己的一个总结.

      先说一下这个项目,是一个游泳场的收费系统,类似于公交车的卡系统.操作人员可以通过终端进行售票,然后用户凭票在游泳池门口验票进入;同时,也可以通过操作人员出售可以多次使用的IC卡,在游泳池门口通过刷卡器刷卡进入.这个系统的使用者分销售员和验卡票员,且游泳场分布在不同的地方.故需要作成一个联网的模式,以便进行数据同步.

      因此这个项目从一开始就分为两个部分,卡和票.

      票通过销售终端销售出去(用票打印机打印出来),在消费端由验票员验票进入.由于硬件条件限制,票打印机就是一般的打印机,没有任何防伪标记,且验票员由于水平原因也无法进行验证真伪,故设计为一个通过机器验票进入的方式,即通过扫描仪的方式.将条形码打印在票上,在消费时通过扫描条形码进行验证.

     卡则是通过销售终端根据用户的类型办理不同的卡(不同卡的消费方式不一样,如折扣,金额,次数,时间).之后,在消费终端,通过将卡放在读卡器上进行读卡,对消费数据进行处理之后放行用户.

      这个项目先是由一位同事在弄,后来由于出现了金额数据上的原因.导致客户对系统产生了不好的反应,因此由我来进行重新设计并编码.要求的时间为15天,而实际上用了30天.且说说前个同事在碰到的问题:

1.       前期需求不太规范.由于客户是个行政单位,在这个项目实施的过程之中,客户单位行政上发生了变化.导致负责这个项目的人员发生了变化,而导致需求临时变化.
2.       设计及经验上考虑不足.未考虑到此个项目在数据上的安全及完整.而在进行一些数据结构上的设计时,有些关键性的数据并没有出现在对象属性中,如消费和销售的时间.
3.       程序编码不严谨.在对一些时间的处理上,未考虑到实际系统中的运动环境与想象中的差异,而任意作出一些判断.在对销售和消费时间的处理上,取值的时间为客户端机器时间而不是服务器时间而导致当两者时间不一致时出现了销售和消费时间与真实时间不一致的问题.
4.       设计不充分,未考虑到扩展.在项目运动中,客户根据实际要求,提出一些需要限制的条件或者消费卡类.由于前期未考虑到这部分,而后面在要增加此功能时,对于前者只能在数据库中增加一个字段,而对于后者,只能通过修改程序代码来解决.这就导致程序代码判断字段越来越多,且越来越复杂.或者,一直不能让软件能够适应客户的变化需求.
5.       需求的更改欠考虑.在项目中,涉及到一个操作用户登陆问题.当天操作用户已打印财务数据时,就不能再登陆系统.这个需求在程序开发初期,就已经被内定为一个重要的限制.而在项目运行期间,用户的一句话让主开发同事轻易就修改了这个设定,而没有考虑到修改之后产生的后果,以致于后来在操作人员的金额数据上产生一个纠纷,并由于这个设定的修改和前面的时间问题,使得某操作人员在上交金额和实际统计金额有差异时,有相当的理由来为自己开脱.
6.       对用户数据不够重视.这个是最重要的问题.由于对整个系统的完整性未欠考虑,并没有考虑到用户数据的重要性.当出现一些数据上的不一致时,直接通过修改数据库数据以达到一致的效果.而修改的数据却是用户的金额类数据,且在修改时让客户在旁边观看,以致于到后来客户都明白做的行为代表什么并且指导同事修改哪些数据.这样的结果,直接导致用户金额数据的正确性受到质疑.以造成最后,用户对数据的正确性表示怀疑.这个是最重要的问题.

      当出现这些问题之后,公司要求整个项目重新设计并编码.由我来进行负责,所以这个项目从一开始就是一个救火性质的项目.

     在设计中,根据现有客户提出的问题,进行整体上的重新考虑,并重新开发了系统.在开发中,卡这部分进行了重新考虑.由于前个设计,卡这部分由一位delphi同事以控件的形式内嵌于界面上(这个项目是bs系统),而导致在需要改变卡一些定义数据时,需要对这个控件进行重新修改并重新在消费终端进行注册.为了修正这个问题,决定将卡部分逻辑代码放在服务端来完成(前个设计是由控件在客户端来完成),而控件只负责与硬件交互,取得IC卡信息和与读卡器交互发出声音.这样就涉及到控件与其他进行交互的问题,主要是控件与js之间的双向交互.控件向js发生命令,再由js根据命令及相应脚本信息向指定服务发生信息,将取回的数据根据结果来控制控件与硬件的交互(如发声音).在网上找了半天,找到一个类似的方法,但用到实际中就出问题(界面是一个框架性iframe界面),而导致控件无法与实际界面取得交互.后来决定用apple的方式来进行处理,在网上也得到了apple与js之间的详细交互,并实验成功.在修改了相应代码之后,终于使apple能够工作了.便发声部分还有些问题(主要是读卡是一个连续的死循环模式,而发声同样要调用读卡器,导致出现了占用锁方面的问题),后来钻研了许久,终于以一种讨巧的方式使得读卡与发声能够近似地独立工作,而不互相影响.

      一个月后,新系统正式上线.在成功将旧数据转到新系统中时,第二天就出现了新的问题.所有的读卡都出现了问题,原因就在于原读卡器提供的java动态库在读卡内码(一个惟一编码)时,出现了数据的溢出问题.原动态库RD800提供的java DLL中,读出的卡内码以int数值返回,而实际中的数据却是long型,而导致读出数据与真实数据不能对应,而不能正确读卡和刷卡.在通过与硬件厂商联系之后,终于拿到了新的dll库(其实就是java的本地库).更新之后成功运动了.

      第一天,客户根据前一个系统的使用习惯,对新系统提出了一些问题.不过都是些小小的界面及显示性问题.马上在公司修改之后,在第二天进行程序更新.这样来回几天,系统终于能够完整地运行了.后来,根据用户的要求,增加了一些新的功能,由于,在设计时已经考虑到了,故新系统中的数据结构完全能够支持客户的新需求,故增加的功能都能够很好地和系统兼容运行.

      整个系统,从我接手到最后客户提不出更多的需求结束,已是3个月了.中间,也实实在在地接触了客户,了解了一些客户的情况.也算是给一直从事程序开发的自己提供一些实际的用户经验.下面是我总结的一些:

1.       不要把客户的水平想得太高.最开始想到的客户至少会使用电脑,而在实际中由于许多客户都是临时请来的,有的完全不懂电脑,连鼠标都不会用.所以在一些设计上,要考虑到用户的水平,尽量减少客户的操作.如,在消费终端,用户只需要点击一个<验票验卡>就可以不再用鼠标而只用扫描仪和验卡器来完成验票和验卡的一天操作了.
2.       客户不会看系统中的任何提示信息.在验票中,要求验的条码长度为13位(EAN-13).在一些特殊情况下,扫描仪会扫描出非13位的条码,当界面出现alert形式的提示框(提示票条码长度不足)时,用户会直接认为这是通过,而不理会此问题.这样就导致了接下来的操作全部失效.最后,将这个警告信息以验票失败的形式放在界面上才解决这个问题.
3.       客户会把任何非程序问题归结为程序上的问题.在销售终端的售卡处,要用于照相机用于采集消费者头像.(这个硬件部分不由公司提供,公司只负责软件部分).当用户由于不规范操作,出现照相机使用不了或无法与电脑相连接时,第一想到的是程序出了问题,而不是操作上的问题.一旦出现问题,就打电话让解决.我们倒成了电脑维护员了.
4.       客户经常会根据自己的使用提出新的需求,而不考虑此需求是否恰当.如前面的第5条,这些修改都是由用户最先提出,后来又提出修改的.如果将客户的需求全部不加分析的接收之后,当发生某些问题时,客户永远不会承认是自己的问题,而永远会说是软件本身的问题.这样就使得当提出新的需求和修改时,我常常会先想想这个问题与设计中的一些约束是否违被.一旦出现冲突就马上提出,并且让用户写出明确的修改意见,并签字.(前个系统,都没有签字,只是由客户口头说)
5.       一定要严格控制需求的变化.一旦需求确定之后,就必须要将新的需求,往后推或者直接拒绝掉.不然,一个项目永远没有结束的时候,当然也永远没有验收的时候.

     现在这个项目已经全部完了,我也不想再趟这个混水了.差一点就陷在这个项目里了.现在作了这些总结,希望在以后的开发中也给自己提个醒,没出类似的错误.

      有兴趣的朋友,可以去看看这个系统.看看实际运行如何.地址:成都市猛追湾游泳场.