项目小结

   首先描述项目大致时间:
   项目类型:C#  B/S  三层架构 复杂数据源
   项目需求:2005年6月中旬确定
   项目编码:2005年10月8日启动编码
   原定上线:2006年3月1日
   项目上线:2006年7月1日(推迟了4个月)
   总计:40人月  

   <一> 需求。项目中重要的一部分DLYW，业务虽比较复杂，但开发人员及客户，有前期业务系统版本参考，在需求理解上无偏差，因此，这部分业务非常顺利。项目中重要的报表部分，没有引起重视，在需求还没有清晰之前就开始编码，并且低估了报表数据源的复杂度,最严重的是开发人员并未完全吃透需求。如：SSKD的逻辑、KHDHY逻辑上线后仍然引发争论,开发工作到了最后交付阶段才发现问题，寻找原因。这些问题归根于两点(事实也算一个问题)：(1) 开发时理解的需求和实际的需求不一致，没有调查用户最终数据结构，凭自己的想法去构造测试数据；(2) 在需求文档形成时，用户只是模糊的概念，只有在界面出来后最终用户才能知道双方需求理解上的误差。庆幸的是,报表的结构设计,使得修改比较方便,才不至于造成特别混乱的局面.

   <二> 人员管理与分配。业务复杂,新招聘的员工直到项目上线都没有理解透需求。项目经理身兼数职,管理不合理，工作任务与重心集中在少数人身上。
  
   <三> 测试方面，在COMPANY开发测试时,没有用实例测试，AS/400的数据源特别复杂，因此早期自己构造测试数据根本不能发现问题；很多数据都需要进行特殊处理,而工程部的用户自己知道问题,也是有心无力,最终用户又不管,只想得到自己预期结果。而且,用户的数据需要大数据量来进行测试；测试人员即使交叉测试，仍没有达到测试力度，因测试人员对目标结果无法理解。
  
   <四> 技术方面，缺乏海量数据操作经验，造成早期报表测试效率太低，不得不专程花两个星期时间去重整存储过程。关于性能提高

   <五> 版本管理，到了测试上线结算，用户抱怨改好一个功能，影响了其他功能。还未测试好就上线了。这是两个问题，都是版本没有管理好造成的。好的版本管理，在修改问题的时候会首先考虑有没有影响其它功能。
 
  当然，也不能忽视项目的优点：
  <一> 主业务DLYW流畅.(1)界面设计流畅.操作用户不是计算机专业人员,因此,界面采用流水式设计.给每个用户一个流水号,象生产流水线一样操作.每个操作界面连接紧密. (2) 无刷新.对客户使用凭率比较高的页面,采用无刷新机制,只传递数据交互部分,减少了数据交互,减轻系统符合.(3) 快捷键.任何按钮,添加快捷键及提示功能,使得B/S结构的程序和C/S的界面一样好用.
  <二> 报表的架构设计比较合理.将表示层和业务逻辑分开.实现层采用用抽象工厂来生产报表,为每种报表配置一个模型.表示层只需要配置xml与报表模板.业务逻辑也将所有的报表实现部分通过存储过程产生到临时表.如果不是这种机制,项目将更难处理复杂的业务需求变化,以及用户现有环境中各种特殊化的数据.
  <三> 系统压力的分配合理.为减少数据库服务器端的压力,将数据使用频率高的通用型数据放在服务器端内存中,不用事无巨细,访问数据库;胖客户,将复杂计算逻辑在客户端进行,服务器只做简单存储及分配;单独配置报表服务器,将报表全部借助此机器产生,然后在前台只需要提供用户产生的报表文件,以减少用户等待的时间;
  <四> 事务机制.所有的数据增删改,都一次性操作,传递到存储过程.存储过程一旦任何问题或者异常,回滚事务.这点对于数据密集型程序是特别好的.

  提出一些解决的方法,对于项目管理方面：
  1.一定不能低估需求，要有专门的文档来管理需求，以及需求的变更，需求的理解，作为以后审评的依据。
  2.所有的开发人员、测试人员都必须能掌握完整的需求，作为统一的整体理解。别想着报表的用户只需要知道他那部分逻辑就OK。
  3.需要专门人员配置管理。代码可乱, 版本不可乱!
  4.不能随心所欲评估工作量。推迟的4个月都是在整报表,初期我只定了两个月。
 
  最后想说一句,为银行或者证券作系统,千万不要低估数据源及报表,我用了200个存储过程(包含function和trigger)。