项目经验-钱彦云

项目一：电信业务档案管理系统
项目简介（功能与用途）：
电信在与客户的业务交互过程中，产生了大量的纸质媒介信息，如合同，协议，装(移、拆)机工单等。而随着电信业务的不断发展，这些纸质媒介信息的数量还在日益增多。日积月累，数量已经非常庞大，其查询、保存、流通十分困难。本系统以此为出发点，将纸质媒介信息通过高速扫描仪进行数字化处理后，再根据用户需求进一步加工，从根本上解决纸质媒介信息难以查阅、保存和流通的问题。
本系统的功能就是将电信每天受理产生的纸质量合同通过扫描、压缩、加密后存储在文件服务器上，同时以日接口方式获得电信业务支撑系统的客户、用户信息及其修改信息。实现电子化档案管理，相关人员可以在网页中随时按照条件组合查询业务档案信息。如下图。

系统的开发和部署环境：
软件环境： web容器是IIS6.0；数据库选型号oracle10g；操作系统选择win2003
硬件环境： IBM X366
开发工具： vs2005
项目难点与解决方案：
难点1：
数据库中的用户信息客户虽然有500万条以上，但是通过分区和分区索引的使用技巧，性能还是比较好。但是文件服务器的负荷非常高。以每天发生2000到3000笔业务估计，每天会产生20000张纸质信息，每张纸质信息的数据最大存储量约32k，这样，每天会产生640M的图片信息，5年时间就有1T的数据在文件服务器上。有很高的性能需求。
解决方案1：在不影响清晰度的情况下尽量压缩，运用DIBB等各种图像无损压缩算法，在保持原样的基础上，对数字化文档进行压缩后存储
解决方案2：清晰化处理，仅对纸质文档的文字信息进行原始留样，运用锐化，去污等多种图像滤镜算法，对数字化后的文档进行清晰化处理。可以更好的减少图片占有空间
解决方案3:合理组织目录名、文件名，以组织机构 ＋ 日期组织目录名，以业务工单号 ＋ 序号组织文件名。将全路径存储在数据库中，在文件服务器的查询使用全路径，直接定位文件。
难点2：
扫描和刻录要求在浏览器中完成，需要突破IE安全限制
解决方案：自己写了ACTIVX控件完成此功能
项目成功与失败的经验归纳：
本项目属于成功的项目经历，主要有以下体会：
仿照PetShop框架，我们设计了自己的一个简单web框架，数据访问层和业务逻辑层使用了Factory模式解偶。对这个项目和将来的项目都是很好的积累。先做框架，在快速原型的方法在这种数据密集型的应用中很有价值。
加密算法使用.NET框架自带的类库完成，又一次证明了不要自己造轮子的意义。


你在项目中岗位与贡献：
项目的需求分析，项目的主要设计人员。接口数据的来源来自省公司的数据仓库，接口部分所有的设计和实现。同时在本项目中承担质量控制员的角色。


项目二：电信业务支撑系统二期改造－欠费管理模块
项目简介（功能与用途）：
本系统的主要功能有
1. 在电信业务支撑系统中建立并完善欠费管理功能，向管理催缴的业务部门提供催缴数据，催缴是通过10000号语音系统完成的，本系统通过接口形式将需要播放缴费通知音的客户数据提供给10000号，有10000号平台完成相应呼出，达到缴费通知的目的。对于存在担保电话的设备、连带担保电话一并催交。
2. 对于经催费后仍未交费的用户，系统能自动停机，停机的数据采集应支持按欠费金额大小，按区局，按地理区域，按局码组合数据，同时应剔除重要用户，用户交清欠费后，系统能自动生成复机数据，并确保复机数据传给程控机房，程控机房处理完毕后应及时回送处理信息，在一定时限内若没有处理成功，系统能自动重传数据。欠费停机，缴费开机是本系统最主要功能。
3. 系统会自动生成停机、复机、拆机处理详细日志，对欠费催缴、缴费、停话、复机、拆机、复装等处理全过程就可以提供统计、查询、打印。
4. 提供人工派单接口，可以人工强行停、复机
5. 对调帐业务的支持
6. 对预付费设备停、复机工单的支持，预付费设备的停复机逻辑由朗讯另外负责，不在本系统内。
7. 高额、限额业务支持
8. 对欠费用户的信息处理，一方面将欠费信息提供给营业系统（限制该用户办理业务）；另一方面将欠费信息提 供给网管系统（限制该用户使用现有的业务功能）。
9. 对无法收回的坏帐进行分类归整，将其费用转入坏帐处理系统中，并纳入黑名单管理。
系统简单流程描述：对后付费设备，在每月交费周期过后，电信计费系统会将没有交费的数据生成欠费。本系统采用月接口以ftp方式接受计费全量账单。用户销帐后，销帐信息使用unix的SOCKET包发过来，解析后调用存储过程更新用户账单，对已经停机的设备会做开机处理。预付费这里只是提供了工单接口。
系统的开发和部署环境：
软件环境： ORACLE RAC
硬件环境： IBM AIX
开发工具： C/PRO*C
项目难点与解决方法：
难点1:
数据量大，全省的电信账目，用户信息和客户信信息量都非常大，最大的表有上千万条记录，但是缴费开机对性能的要求非常高，否则就有可能被投诉。
解决方案：
对大表按照地区分区，创建充分索引，并且索引都创建为分区索引。这样销账开机时对表中数据的查询可以迅速返回。但是这里同时又引入了新的风险，数据不断更新后oracle的统计值可能会不准备，不能采用正确的执行计划。曾经发生过突然销账非常缓慢的情况，应该写代码定时分析表，避免此类错误。索引增加会增加insert和update操作的开销，这里需要注意这两方面的平衡。
难点2:
系统的稳定性要求很高，任何故障都有可能被投诉
调度逻辑采用标准C编写，部署在AIX上，后台数据库IBM小型机上，并且是ORACLE RAC，为了保证不发生存储过程失效，写了个proc程序定时监测存储过程状态，保证7*24的运行。数据库定时热备份。备份的方案很复杂，由IBM来做。

项目成功与失败的经验归纳：
成功经验1：
数据密集型程序设计阶段要充分重视数据流程图，这点和应用密集型程序有所区别。建模上要有侧重点。一定要先有E-R图，再向数据库详细设计走，这样很容易的迭带开发，数据库设计也更容易被理解。
成功经验2:
接口非常多的项目，例如本项目，要搞好接口谈判并且明确定义接口，写出清晰的接口文档。尽量早的开发出接口并测试


你在项目中岗位与贡献：
主要设计人员，所有的C/PRO*C代码的编写，和计费接口所有ORACLE数据库包编写。系统性能的主要优化人员。


项目三：电信网上营业厅
项目简介（功能与用途）：
网上营业厅是电信推出的，通过网络办理电信业务的新运营模式，以网上营业厅的形式为客户提供服务，客户、代理商或合作伙伴等用户都可以完成的电信的全业务受理。
主要包括三部分功能：
 面向客户的功能
 面向后台用户的功能
 面向系统管理员的功能

软件环境： EJB容器：weblogic；语言：java；数据库调用逻辑和连接：tuxedo
硬件环境： IBM AIX
开发工具： JAVA
项目难点与解决方法：
难点1:
负载均衡，由于是全省电信的应用，用户的数据分布在全省14个地州，web服务器采用省集中方式部署，业务受理时要自动选择负载最小，并且是存放用户信息的数据库服务器。由于系统的稳定要求很高，当因网络等原因数据库链路中断后，要有完整的事务处理机制。
解决方案：
采用BEA TUXEDO中间件，由中间件自动转发数据请求做到负载均衡。Weblogic上只是实现了应用界面层。数据的操作逻辑全部在TUXEDO上实现。本系统充分利用了以前的程序，用java把delphi的界面逻辑重新翻写。大大减少了代码量。

项目成功与失败的经验归纳：
1. 复用以前的代码和数据库
2. 使用了中间件实现后台很重要的管理和企业级别特性，降低了开发复杂度
3. 使用了Spring框架

你在项目中岗位与贡献：
受理缴费部分代码


项目四： 铁路客运审核系统
项目简介（功能与用途）：
当时是铁道部的一个项目，功能主要有
1. 审核是否有票价错误的票根
2. 审核各类客运票据，并产生铁道部统一规定的财务报表
3. 生成其他统计报表

项目难点与解决方法：
全国各地的票价制定规则是有区别的，而且票据也五花八门各不相同，报表的需求差别非常大。
解决方案：
1. 制作了自定制报表，有点类似于OLAP报表工具的自定制功能
2. 各功能点安装时定制


项目成功与失败的经验归纳：
这个系统做完都过去好几年了，之所以这里提到因为这是个很惨痛的失败项目。项目首先性能太低，不论是票据的录入速度，电子票的导入，报表的生成，时间都无法让人忍受，导入1次电子票要等2个甚至3个小时，汇总统计报表也是这样。
根源在数据库设计上，虽然花很大功夫优化了数据库环境，但是收效不能令人满意。查询中到处用到多表关联，并且这些表都很大。票据审核的算法有问题，影响了导入性能。
其次开发的时间太长，开发完毕后大量新的需求出现。数据密集型的应用最好在三个月内完成。

你在项目中岗位与贡献：
数据库优化工作