工欲善其事，必先利其器---iESE200改进

iES-E200电能量综合应用环境于2003年研发完成，该系统当时在同类系统中处于先进行列，能够满足用户的大部分需求，在推向市场后，取得了巨大的成功，目前已经有三十多套运行在全国各个地市。
但是随着产品的实施，很多问题也开始暴露出来：
1) 系统没有持续开发，不能满足客户新需求。随着该领域的发展，以及该系统的推广，新的需求不断涌现，另外向多样化发展，而近几年iES-E200主要以工程开发为主，没有系统性的进行规划和增强研发，一方面导致产生较多的型号版本，带来维护不便和稳定性不够的问题，另一方面系统已不能完全满足用户的需求，特别是新的需求。
2) 版本问题。版本问题始终是困扰iESE200工程人员的一个大问题，虽然有微软的VSS配置库，但配置库只能在公司内部使用。如果纯粹用于研发，VSS完全能够满足需要。而对于iESE200的工程实施，则免为其难。iESE200工程人员遍布全国各地，无法进行版本的各种控制，因为工程任务重，也不可能增派专门的管理人员进行版本的管理。久而久之，工程人员的版本比配置库的版本还要新，导致了对配置库的不信任。每个工程人员都只信任自己手头的版本，使得工程人员总成使用一个版本，而施工人员与总成人员一般不是一个人，施工时就从自己的机器上复制一个版本。工程人员到了现场，一般先编译自己的版本，有时候编译就需要两三天的时间，有时候根本就无法编译。编译通过之后，也不一定能够正常运行，需要对程序进行各种各样的调试，费时费力，效率低下，用户也感到不可理解。
3) 工程人员各自为战。因为没有统一的配置管理，工程人员非常的辛苦，通常为了解决一个BUG或者增加一个功能而通宵奋战，而这个BUG或者功能有可能是其它工程已经解决了的，这使得工程施工时间无限期的延长。而且，修改的BUG或者增加的功能只用于该工程版本，而其它的工程遇到同类的问题，因为不知道同事已经解决这个问题，可能会从头再来，重复开发，造成人力的浪费。
4) 新员工需要较长时间的培训，短时间内不能出差。因为版本混乱，现场需求没有统一的管理，人员生产效率低，即使新员工即使非常努力，因为以上各种问题对工程人员要求非常高，短时间内也无法单独出差。长期在外出差的iESE200工程组人员李雪生曾经深有感触的说：“工程人员要会整合版本，调试所有的程序，要会进行各种需求的开发，水平需要比开发人员的水平还要高”。这是一种不正常的状态。
可以说，iESE200工程实施已经到了非常危机的地步，大家每天都在为基本的版本搭建、系统能够运行而奋战，而真正需要我们奋战的：客户的需求，我们却始终没有精力去完成！而且系统的稳定性一直得不到很好的解决，这仿佛永远成了iESE200成员心头的痛！
iESE200过程改进，势在必行！
第一步，重中之重，整合版本，建立型号，形成iESE200的基线。 因为iESE200为工程组，有很多的工程需要实施，还有很多的遗留工程问题需要解决，考虑到iESE200在相当长的时间内还要支持事业部的发展。在崔仁涛老师、杜晓兵老师、徐军老师等领导的大力支持下，决定对iESE200进行增强开发，整合所有版本的功能，整合各种工程需求，满足客户的需要，使iESE200系统继续处于先进行列，保持产品的竞争力。为了有效的进行开发，根据型号组目前的工作特点（开发可能会因为工程及其它事务而中断），采取迭代开发的方法，把开发分成一个个单独的功能，每个功能尽量不影响其他的功能，每个功能的开发尽量在两到三个周完成，并进行充足的测试。整个开发过程是一个长期的、有计划的行为，在保证总体计划正常执行的前提下，对过程中遇到的问题调整，及时规避各类风险。
工欲善其事，必先利其器！为了有效的配合iESE200基线的建立，必须采用配置库，以便进行员工的协同开发。我们选择了大家都比较熟悉的VSS配置库，并以德州的版本为集成，建立了初步基线版本，确定了管理方法：
1) 系统总成时一定从基线库中出，并由配置库管理员签字认可。
2) 工程人员在出差之前一定要出相同的版本，并把版本测试一遍。
3) 工程人员现场小的需求可以进行改动，但是一定要形成纪录，发给技术主管；大的开发或者需求由技术主管组织研讨并处理与开发，由现场人员负责实施。
4) 工程人员返回时，将所有改动发给技术主管，由技术主管进行管理，并确定是否形成新的基线。
5) 进行版本的维护，建立测试软件平台。
6) 开发一定要从库中检出，再进行更改。
配置库在iESE200基线建立的过程中发挥了巨大的作用，使得iESE200基线的建立在2007年10月中旬按期完成，初步具备了现场实施条件。但是在VSS的使用中，也发现了一些问题：
1) 非原子递交
使用VSS库经常相互覆盖的问题，例如一个同事把程序检入到库里，结果被一个没有遵守检入规则的同事给覆盖了；或者好不容易编写的程序，一个错误检出，完全被覆盖了，只能重新再写一遍。
2) 可靠性差，速度慢
VSS支持的连接数非常少（Windows有关系），速度也慢。当5~6个人同时操作时，就象死机一样，大大影响了工作效率，更甚者，超过一定的连接数目，就无法再进行连接。开发那端时间，大家说的最多的就是“谁不使用配置库了，请断开，让我用用.....”。这严重的影响了工作效率。
3) 安全性
VSS所在的文件夹设置为任何人都可以控制，可能会造成误删除，或者现场使用时，被竞争对手拷走，暴力破解。
4) 不支持远程访问
如果说以上三个问题都是小问题的话，那么不支持，不能提供远程访问则是VSS最大的弱点！iESE200是工组，开发也是为了工程的顺利实施。而工程最大的问题就是现场的版本控制，现场不能用配置库，使得一旦有什么问题或者解决了什么，只能通过发送邮件进行通知，而这些邮件需要专门有人处理，并将修改的程序或者增加的功能检入配置库，并发送邮件通知其它工程人员。而这高昂的管理成本是人员紧张的iESE200工程组所不能忍受的。更严重的是，没有配置库的管理，导致一个工程现场出现多个版本（一台机器一个！），这为系统的维护带来了极大的隐患。必须有更好的配置库实现所有工程的同一管理。
 当iESE200工程组为配置库的问题苦恼时，质量管理中心的霍巍、电网事业部万林推荐了SVN配置库，并提供了大力支持，根据我们的要求进行了配置库的安装与设置，并调通了内外网访问。配置库虽然建立起来了，但是能否真正的应用，还是一个疑问。对VSS虽然不满意，但毕竟用熟悉了，现在换用另一个产品，能不能习惯，万一用的不好，如何化解这个风险? 通过工程组的讨论，决定先不移植基线库，而是把周报管理文档先移植到SVN配置库上，让大家进行使用，等到使用熟悉以后，在使用该基线施工以前，再把基线库移植到SVN，以便最大的降低风险。
通过一段时间的使用，iESE200工程组基本熟悉了SVN配置库，并一致认为，SVN远远优越于VSS，建议使用SVN配置库。将基线库移植到SVN上的条件已经成熟，于是，在2007年10月中旬，基线库被移植到了SVN配置库上，SVN配置库开始在iESE200工程组进行全面的使用。配合SVN的使用，制定了以下管理规范：
1) 系统总成时一定从基线库中出，进行系统安装。
2) 工程人员现场施工时，从基线库进行现场更新。
3) 工程人员现场小的需求可以进行改动，但是一定要形成纪录，发给技术主管，技术主管同意之后，有工程人员现场检入基线库。
4) 工程人员现场大的开发或者需求由技术主管组织研讨并处理与开发，由现场人员负责实施，并检入配置库。
5) 工程人员现场特殊要求检入各地工程特殊配置库。
6) 工程中发现的错误，更新到配置库之后，由技术主管及时通知其它工程，由工程人员检出，进行使用。
使用SVN后，iESE200工程组真正的实现了版本的同一，也结束了原来那种单打独斗，各自为战的状态，使得iESE200人员体会到了团队作战的快乐（一个工程中修改的错误、添加的功能，其它的工程可以立刻应用）。截止到目前，现场运行的系统（山东齐河电力公司、云南楚雄供电公司、江西萍乡供电公司、安徽广德广德供电公司、湖北黄石供电公司、安徽凤台供电公司）使用了同一个版本，这使得系统的稳定性和可维护性大大增加。配置库成了我们IESE200的中转站，如果说了模块以数据库为中心，而iESE200的管理则以配置库为中心。
 艰难困苦，玉汝于成。iESE200还有很多事情要做，例如缺陷的跟踪，工程开发的单元测试、客户需求的管理等等。但我们有理由相信，只要进行持续的改进，iESE200定能继续发挥它的热量，为事业部，为积成电子贡献力量。