一个OA系统升级实施方案
背景：
一、旧系统简介：
二、新系统简介：
三、系统架构设计：
四、数据访问模式：
五、系统升级方案：
方案一：同时运行方案
方案提出背景：
方案实施步骤：
方案评价：
方案二：渐进式运行方案
方案提出背景：
方案实施步骤：
方案评价：
方案三：“试运行”方案
方案提出背景：
方案实施步骤：
方案评价：
方案四：“择机上线”方案
方案提出背景：
方案实施步骤：
方案评价：
方案五：“改良式”方案
方案提出背景：
方案实施步骤：
方案评价：
方案对比分析
附录：一号方案实施过程总结
问题关键点分析：
问题根源：
解决方案：
总结：
背景：
XX市房地产勘查测绘所（以下简称“房产所”或者“客户”）新业务办公系统（以下简称“FCOA”或“新系统”）经过一年多的开发和测试，现在到了需要准备新系统上线的时候，以取代原有的办公系统（以下简称旧系统），但是，新系统在2007-7-4日和5日上线的时候，遇到了一系列问题，最后不得不停止新系统，仍然切换到旧系统运行。面对这些问题，如何看待现有开发的新系统，以及如果认为新系统可行，如何制订切实可行的上线实施方案，为本文讨论的主要问题。
一、旧系统简介：
Gis-ver2005 是现在运行在房产所的一套业务办公系统，处理市各大房屋测绘公司/单位提交的房屋测绘档案和数据，这些数据称为“汇交数据”，房产所负责这些材料的审查和备案。房产所是一个重要的行政审批单位，其管理里的数据具有严格的经济和社会意义，业务不允许中断和出错。
Gis-ver2005对数据的业务处理流程举例：
预售登记测绘：包括 “售初始登记”，“预售变更登记”，由大厅业务人员负责材料的登记；
预售业务审件：由测绘管理科科员进行材料的初步审查；
决定：有房产所领导对初步审查的材料进行决定，是否正确；
成果导入：对正确的材料，将数据导入到系统数据库中；
单据输出；给客户打印回执单和通知单等
建委成果导出：将数据库中的数据导出然后上传给建委；
归档：对最有正确的业务进行归档操作。
对于实测业务（产权登记测绘），流程跟预测业务处理流程类似，也分为初始登记和变更登记，只是数据和单据的格式内容有所不同。
另外还有成果数据变更，实预测对应等业务，业务流程比较简单此处不做详细说明。
整个旧系统从功能上说基本满足现有业务运行状况，但是中间也伴随着大量的维护工作。从整体界面风格上来看比较简单，显得不够专业。
二、新系统简介：
新系统除了满足上面所说的各种业务功能外，还加入了以下一些功能：
公共信息管理：如公告通知，政策法规，行业动态等公共类信息，这些分类和内容都是可管理的，可自行设置和调整；
个人办公：集成了原有gis-ver2.5中该部分内容；增加了通讯录和网络磁盘模块。
另外，业务管理，大厅接待等模块集成了原gis-ver2.5中对应的功能。
从系统功能架构方面来说，新系统加入了以下两个大的功能：
工作流：所有业务的流转均由工作流控制，包括业务的受理，转交，回退，完成等。在界面表现上，只有当前操作员接收到了上一步流转下来的业务，才可进行当前操作，最后转交给下一步。业务的流转方向由工作流类型事先定义好了。业务流转给谁由权限系统或者工作流本身控制。
权限控制：新系统的所有模块都由权限子系统控制，包括业务信息和非业务信息，跟工作流的关联也比较紧密。权限系统可以方便的定义操作员，权限，角色等信息，每个程序模块根据事先设定好的权值代码来判断当前操作员是否具有该操作权限。该权限子系统实现了细粒度的权限控制（按钮级别）。
另外从流程上来说，新系统在业务受理阶段即进行了数据导入，取消了旧系统的“成果导入”步骤。
从界面风格方面来说，新系统重新进行了设计，显得跟专业，更易于操作。
三、系统架构设计：
旧系统：
采用了比较简单的单层架构/双层架构，很多业务逻辑在后台页面代码中处理；有少量代码，比如数据访问代码，放到了单独的程序代码中处理。
新系统：
采用了多层架构方式，将部分业务代码抽取到了单独的业务层中处理，但是做的很不彻底，有大部分业务代码仍然沿袭了旧系统的模式。另外将数据访问层单独抽取了出来，但这部分组件主要是为工作流和权限子系统服务的。
四、数据访问模式：
新旧系统采用了不同的数据访问模式，旧系统大量采用了Oracle数据库的特性，对表的主键列的值采用Oracle的“序列”方式，每次插入一条数据的时候改序列值加一；新系统为了屏蔽底层数据库的具体类型，采用了抽象数据访问方式，在运行时指定数据库类型，尽量采用跟具体数据库无关的查询方式，因此对表主键的处理方式采用单独建立一个“种子”表，由程序决定对主键值加一。
理论上这两种数据访问模式都不会有问题，但是当新旧系统过渡的时候，这成了一个严重的问题（后面会分析到）。
五、系统升级方案：
新旧系统虽然处理的业务类型没有发生改变，但是两者的功能无论从使用者方面还是设计者方面均发生了重大变化，主要表现为“工作流”是旧系统根本没有东西，而且“权限”管理也采用了全新的方式。
根据新旧系统的上述差异，为了确保系统顺利“交割”，需要制定几套升级方案：
方案一：同时运行方案
新旧系统程序同时运行，共同使用一个数据库
方案提出背景：
房产所的业务从受理到最后归档，一般都在5个工作日内，但有的也可能5个工作日以上，而且在正常工作日内，是不能停止接收新件的。因为新系统使用的数据库是在旧系统的数据库基础上作了一些扩展，但是并没有删除过任何老系统表的字段，所以从表结构上来说是向后兼容的。为了让旧系统中没有处理完的业务继续处理，可以把当前正在使用的业务数据完全复制到新系统的数据库中，这样理论上旧系统的程序就可以使用新系统的数据库了。
在业务上，该方案的主要背景在于三点：
延续旧系统中没有处理完的业务；
在旧系统中如果业务还没有做完，需要变更业务数据；
新系统可以使用旧系统没有处理完的数据。
方便查询旧系统中正在处理的业务。
方案实施步骤：
旧系统使用的老数据库（以下简称 GIS库）在新系统上线日停止使用，作为备份封存；
复制GIS 库的数据到新系统的数据库中（以下简称FCOA库）；
修改旧系统程序所使用的数据库为FCOA库，使新旧系统使用同一个库；
部署FCOA程序，使用FCOA库；
新旧系统同时运行，旧系统中没有完成的业务继续在旧系统中处理，直到最后归档为止；新接收的业务从收件开始，完全在新系统中处理。
方案评价：
优点：
该方案可以使新旧系统的业务顺利交接，对各种业务的处理不会造成影响，且不需要手工维护数据的一致性。
缺点：
新旧系统同时使用一个数据库风险比较大，有可能发生两个系统的数据互相干扰的情况。而且，不能保证业务人员不熟悉新系统操作的情况下出现业务无法办理的情况。
方案二：渐进式运行方案
新旧系统渐进式运行，分别各自使用自己的数据库
方案提出背景：
该方案主要是基于确保数据的安全性，从物理上隔绝两个系统对数据的相互干扰。而且，也不希望在旧系统中做过的业务重新在新系统中再做一次。
方案实施步骤：
旧系统使用的GIS库 新系统上线日继续使用，但做一个备份保存；
复制GIS 库的数据到新系统的数据库中（以下简称FCOA库）；
部署FCOA程序，使用FCOA库；
旧系统没有做完的业务继续在旧系统中处理，直到归档为止；
新接的业务完全在新系统中运行；
旧系统中原来没有做完的业务做完以后，采用程序/手工方式将数据导入到FCOA中；
旧系统中没有做完的业务全部做完以后，封存GIS库并作备份。
完成过渡，以后的业务全部在新系统中做。
方案评价：
优点：
可以确保老数据的安全性和准确性；
缺点：
首先，如果在旧系统的业务还没有做完的情况下，业务发生变更，这时候只有等到该业务在旧系统中做完以后，继续在旧系统中做变更业务；同时，在业务需要查询的时候，不能方便的确定要查询的数据再哪个库中；
然后，在旧系统中后来做完的业务需要用程序/手工导入到FCOA库中，这一过程可能比较复杂而且易于出错，需要再制定一个比较好的处理方案；
最后，同样不能保证业务人员不熟悉新系统操作的情况下出现业务无法办理的情况。
方案三：“试运行”方案
新旧系统同时运行，但新系统在最后上线前始终处于“试运行”阶段。两个系统分别各自使用自己的数据库
方案提出背景：
该方案主要基于确保新旧系统的数据的稳定安全，克服因新系统在操作方式上的重大改变引起的可能的操作问题。同时，在新系统的试运行中，也能及早的发现问题而不至于业务的中断处理。
方案实施步骤：
复制GIS 库的数据到新系统的数据库中（以下简称FCOA库）；
部署FCOA程序，使用FCOA库；
旧系统程序正常使用，在过渡期继续办理业务；
新系统在“过渡期”内，每天/隔天随机抽取旧系统中办理过的业务，到新系统中重新办理，作为测试对照；
在新系统试运行一段时间以后，根据新系统对业务处理的稳定性/正确性，何业务人员对新系统操作的熟练程度，决定何时结束“过渡期”；
过渡期结束，再采用方案一或者方案二，处理旧系统中没有做完的业务。
方案评价：
优点：
采用试运行方案，可以在试运行中及早发现新系统中的问题，保证原有业务的正常运行；同时，系统经过一段时间的试运行，业务人员也能够熟悉新系统，避免因为操作问题引起数据的丢失或错误。
缺点：
在试运行期间，业务人员可能会提出更多的改进需求，修改和实现需求的时间可能会影响上线的时间；在过渡期结束以后，同样不可避免的会遇到方案一和方案二中的问题。
方案四：“择机上线”方案
选择一个业务相对较少的日期（根据房产所办理业务的经验推测一个合适的日期），在周末前只剩下少量未办理完的业务，最后还是未办理完的业务利用周末加班办理完成，然后在下周一新系统正式上线。
方案提出背景：
新旧系统业务的延续是本方案提出的最主要动机，上述三套方案都不可避免的会遇到这个问题，但解决起来都不是很容易。采用“择机上线”的方案，选择一个业务量相对较少的日期作为新系统升级上线的日期可以避免前面的问题。这样后续的业务全部在新系统中办理，不会出现业务是否连贯的问题。
方案实施步骤：
根据以往办理业务的经验，统计出一个比较合适的时间，选择那天上线，或者根据当前所在周的星期五看没有办理完成的业务数量，决定下个周一新系统是否上线。
如果决定在下个周一新系统上线，旧系统使用的老数据库（以下简称 GIS库）在新系统上线日停止使用，作为备份封存；
复制GIS 库的数据到新系统的数据库中（以下简称FCOA库）；
部署FCOA程序，使用FCOA库；
在周一，业务人员完全使用新系统办理各种业务。
方案评价：
优点：
由于业务事先已经全部在旧系统中办理完成，避免了上述方案业务难以延续的缺点；
缺点：
需要预计和选择业务比较少的日期，这个合适的日期可能比较难以选择；
因为需要加班做完旧系统中没有做完的业务，需要房产所领导的全力支持和房产所所有员工的理解和支持；
新系统上线以后，同样有业务人员不熟悉新系统操作的情况，但可以采取上面的“试运行”方案来做好培训。
方案五：“改良式”方案
对现有的旧系统程序进行“改良”，比如首先修改旧系统的界面风格，然后再逐步优化和完善代码，增加新的功能。
方案提出背景：
由于新系统使用工作流驱动业务，产生了业务无法正常延续的问题，而上述四套方案都难以实现，那么只有对现有的旧系统进行逐步“改良”的方案了。
方案实施步骤：
继续使用旧系统办理日常业务；
逐步修改界面风格，改善操作体验；
优化代码结构和效率，逐步增加新功能。
方案评价：
优点：
本方案不涉及新旧系统升级的问题，是对原有系统的逐步“改良”过程，所以不会造成业务的延续问题。
缺点：
由于旧系统的界面没有完全按照CSS风格理念来设计，所以要完全改变系统风格工作量还是比较大；
由于原来采用的是单层/双层架构，所以代码的逐步分离和优化也是不小的工作，相当于重新设计一个系统；
在改良过程中，由于有“FCOA”的体验，客户也可能要求加入一些FCOA的操作方式，从而影响到原有系统的设计；
改良过程也有可能花费不少的时间；
放弃现有的FCOA，从开发时间和成本上来说也是一个不小的损失。
方案对比分析
下面对五套方案的各项指标进行分析，最后总结出方案的可行性和综合评价指数。
| 方案 |
方案一 同时运行方案 |
方案二 渐进式方案 |
方案三 试运行方案 |
方案四 择机上线方案 |
方案五 改良式方案 |
| 问题 |
|||||
| 业务延续性 |
无 |
有 |
有 |
无 |
|
| 数据库 |
一个 |
两个 |
两个 |
一个 |
一个 |
| 数据一致性维护 |
不需要 |
需要 |
需要 |
不需要 |
不需要 |
| 数据安全性 |
低 |
高 |
高 |
中 |
|
| 新旧系统使用过渡期 |
无 |
短 |
长 |
无 |
|
| 新旧系统切换时间 |
短 |
长 |
很长 |
较长 |
|
| 需要客户支持程度 |
低 |
高 |
中 |
高 |
高 |
| 客户需要培训力度 |
大 |
中 |
小 |
大 |
|
| 旧系统同时运行 |
不需要 |
需要 |
需要 |
不需要 |
|
| 新系统部署难度 |
低 |
中 |
高 |
中 |
|
| 新系统上线风险系数 |
高 |
中 |
低 |
中 |
中 |
| 升级失败处置程度 |
复杂 |
较容易 |
容易 |
较复杂 |
较复杂 |
| 上线前内部测试时间 |
长 |
中 |
短 |
长 |
|
| 方案问题可预测性 |
可 |
未知 |
可 |
未知 |
|
| 方案实施经验 |
有 |
无 |
无 |
无 |
|
| 是否包含其他方案 |
否 |
否 |
是 |
否 |
否 |
| 方案可行性 |
★★★ |
★★★ |
★★★★★ |
★★ |
★ |
| 综合评价 |
★★★★ |
★★★ |
★★★ |
★★★★ |
★ |
从上面几套方案的对比分析，方案三具有最高的可行性；方案一和方案四都有较高的综合评价指数，因为方案一已经具有实际的实施经验，这是其他方案都不具备的优势，方案四具有较大的操作空间，如果能够得到客户方的全力支持是一个不错的选择。方案五可能难以得到客户的支持，故可行性比较低。
附录：一号方案实施过程总结
2007年7月4日（周三）和5日，主要考虑到避免业务前后延续的问题，我们实施了一号方案，新旧系统同时运行，旧系统继续处理原来没有做完的业务，而新的业务则完全在新系统中运行。开始运行后，主要发生了以下几个问题和情况：
1老系统中实测/预测数据导入不进去，经检查，发现是新建立的旧系统跟新系统使用的同一个数据库没有建立Oracle的序列。把原来GIS库的序列导入到新库（FCOA库）中解决；
2新系统中看不到刚做的一个预测业务。经过检查发现业务表等有记录，但是工作流表没有相关数据，怀疑可能是用户不熟悉新系统，在收件过程完成的时候，没有单击系统的“完成”按钮。但是客户说这个功能已经培训过，不可能犯这样的错误；
3旧系统的建委数据包上穿不上去，经过检查，发现新旧系统的两笔业务使用了同一个楼栋序号。将旧系统的这笔业务回退到成果导入，然后重新导出建委包解决；
4在旧系统发现数笔业务根实际的材料不一致，初步判断是上午数据库没有建立序列有关。这些发现的问题通过手工逐个解决。
5在排除问题的过程中，发现旧系统中成果导入程序里面一处致命的数据写入方式，有可能严重干扰新系统的运行。
6在系统上线的第二日决定停止新系统的运行，新业务仍然有旧系统程序做，但是仍然发生了很多问题。
7在第二日晚上，决定全面停止新系统和旧系统的运行，将旧系统的数据恢复到两天前正常的数据库中去。
8在过后的两天时间里面，我们和客户一起恢复数据，客户在旧系统中重新录入了4日和5日新做的业务。
问题关键点分析：
问题根源：
经过反复查找错误原因，最后发现旧系统写入数据获取主键字段值的时候采用了Oracle序列对象的特性；而新系统写入数据采取的是单独一个表存放主键种子的方式。有些重要的主键字段，新系统没有使用足够大的主键种子数，导致获取的值和旧系统的序列对象值相冲突。
另外，在旧系统的导入程序中，存在下面一个致命的数据写入方式：
//导入楼盘表
Ssql="insert into Tb_houses(houseID,archID,houseNo,CellLinkSymbol,survey_SDate,survey_EDate,";
Ssql+="FinYear,struct,remarks,type,plan_BArea,plan_SArea,outWallApportType,SUBMITCOMPANY) values(seq_houses_id.nextval,";
。。。 。。。（此略）
//采用seq_houses_id.nextval获取下一个楼盘序号
。。。 。。。（此略）
//取得新导入数据的maxID
Ssql = "select max(houseID) as maxHOUSEID from Tb_houses";
DataSet dsmax = db.TransactionQuery(Ssql);
string maxHouseid = dsmax.Tables[0].Rows[0]["maxHOUSEID"].ToString();
。。。 。。。（此略）
上面的代码存在以下一些隐患：
如果几个用户同时导入数据，houseID 将有可能产生并发冲突，如果houseID启用了约束，那么写入将失败；如果没有启用约束，那么将有可能出现相同的houseID。（事实证明，没有启用约束）。
如果新系统也导入了一笔业务（注：新系统在收件的时候就已经将业务数据全部导入了），假设新系统对houseID 启用了一个大得多的新种子数，那么将发生上面的maxHouseid 根本不是前面刚刚写入的那个seq_houses_id.nextval 值。这样，该笔业务项目下的几个楼栋都将有可能使用同一个HouseID 。最糟糕的是Tb_houses 表的主键houseID 没有启用唯一性约束，最终导致很多业务数据导入出错但没有及时发现问题。
解决方案：
在插入数据之前，先执行select max(houseID) as maxHOUSEID from Tb_houses 命令，获取当前表中最大的一个houseid值即可。同时，新系统该表的主键种子数预估一个远大于当前max(houseID) 的数即不会导致冲突。
总结：
所以，一个良好的系统，设计是关键。如果在设计的时候就考虑到了上面的问题，那么此次升级中遇到的该类问题根本就不应该发生。
（全文完）