管理性软件项目的数据初始化1

1.前言
管理性软件，即对大量的数据进行管理的软件，常见的有应用于各企事业单位的MIS系统、ERP系统等等。管理性软件项目，即对管理性软件进行开发、实施的项目。从项目的生命周期角度考虑，项目经过前期的需求调研、分析、设计、开发完成之后，并不是直接提交给用户就完成了。在上述的阶段完成之后，进入实施阶段，实施阶段的一个重要工作，就是进行数据的初始化工作。
数据对于一个管理性的软件是至关重要的组成部分，软件系统只是一个外在的表现形式，而数据是软件系统的本质组成部分。没有数据的软件，就像无水之源，无根之木，从软件应用的角度讲，是没有意义的。软件系统开发完成之后，只有经过数据的初始化，将数据加载进系统，软件系统才能正式的运行，才算完成了整个系统的交付。正如业界通用的对数据重要性的描述：三分软件，七分管理，十二分数据。
软件项目是需要甲乙双方配合才能完成的，在项目生命周期的不同阶段，甲乙双方的工作职责也不尽相同。需求调研阶段，甲方负责提供需求和进行需求的确认，乙方负责需求分析；开发阶段，主要的开发工作由乙方完成，甲方进行进度的监控和业务知识支持。实施阶段的数据初始化期间，也是甲乙双方需要配合才能完成的工作，这期间的工作，应该是甲方负责协调、确定初始化数据，乙方提供指导和技术支持。
管理性软件的数据，分为三种不同的类型，分别为字典数据、权限数据和业务数据。这三种类型的数据，在软件项目实施的阶段，都是需要初始化的数据内容。下面就分别针对这三种类型，结合项目双方的工作任务，对数据初始化的问题进行分析。
2.字典数据初始化
软件系统中的字典数据，是指对一个字段定义几个选择性数据值的形式的数据，其在软件系统中的表现形式通常为选择框或下拉列表。例如在人力资源管理系统中，人员的性别、职称、状态等，都是字典数据，他们的数据内容都是从几个备选项中选择得到的。字典数据又分为两种类型：固定字典和活动字典。
数据分类
对其他功能的影响
定义阶段
初始化原则
固定字典
有
需求定义
不建议调整
活动字典
无
需求初步定义，实施完善
可以完善
（1）数据分类
固定字典，是对软件系统的相关内容会产生影响的字典数据。简单讲就是字典中的几个备选项，不能随意设定，它的改变会影响其他的功能的实现。人力资源管理系统中的人员的状态就是一个明显的例子，最简单的人员的状态可以分为“在职”和“离职”两种，在计算人员工资的功能时，就不能计算状态为“离职”的人员的工资。所以说，人员状态的内容的设置会影响其他功能，是不能随意设定的。
活动字典，是对软件系统的相关内容不会产生影响的字典数据。字典中的几个备选项可以自由设定，只是一个选择性内容，不是关键性因素。例如人力资源管理系统中的职称，其内容是自由设定的，没有依据该内容进行处理的功能。
（2）初始化工作解析
固定字典数据通常是在需求定义或开发阶段进行提出和确认的，是不能在实施阶段的数据初始化过程中重新进行定义的，否则就会影响其他的功能。系统的开发完成之后，应该经过一个用户测试的过程。用户测试的过程，同时也是对固定字典确认的一个过程。如果对固定字典的确认没有通过，需要进行调整，这实际上是一个需求变更。在数据初始化期间，如果还要对固定字典的内容进行调整，这种需求变更的工作量就非常大了。从项目开发实施的经验来看，不建议在项目的实施阶段进行固定字典的调整。
活动字典的数据一般在需求定义阶段有初步的设置，在数据初始化时可以进行调整。活动字典的数据完善，主要由项目的甲方来完成，主要原因在于活动字典牵涉到业务的内容比较多，而甲方是对业务了解最清楚的，乙方只能起到指导和支持的作用。
3.权限数据初始化
管理性软件，由于受工作职责划分、数据控制要求等因素的影响，在数据初始化时必然会有权限数据初始化的工作。
权限数据一般包括三部分：组织机构的设置、角色的设置和用户的设置。
数据分类
严密性要求
与原系统一致性要求
初始化原则
组织机构
系统越庞大越高
高
甲方指定专人进行，乙方进行系统操作指导
角色
系统越庞大越高
低
用户
高
高
（1）数据分类
组织机构的设置，即应用本软件系统的企事业单位的组织机构，一般包括公司、部门及其他机构。设置组织机构的目的，一般有两种，一是设置人员的需要。一个软件系统中，可能用户众多，如果在系统中直接罗列用户，可能很难直观的看出用户的属性，对用户查询的方便性也较差；二是对业务数据权限的要求，软件系统中的业务数据，并不是每一个用户都应该看到所有的数据，一般来讲一个部门的人员只能看到本部门的数据，否则就会造成数据的保密性紊乱，对数据的维护也会造成不必要的麻烦。
角色的设置，主要是为了用户权限的设置的方便性。设置用户的权限，一般有两种做法，一是直接为用户设置功能点的权限，每次添加一个新的用户时，直接设置他的功能点，这种做法适合于功能点比较少、用户比较少的软件系统。二是给用户进行功能点分组，对于功能点庞大，用户比较多的系统，采用前一种做法就比较麻烦了。通常的做法是给功能点分组，一个组为一个角色，设置角色的功能点。在添加用户时，直接设置其为某个角色就可以了，这样，对系统维护的方便性就大大增强了。
用户的设置，这里讲的用户，也就是软件系统的登录用户，一般是为了软件系统的安全性要求。在设置用户时，设定其组织机构和角色，就完成了用户权限的设置。
（2）初始化工作解析
权限数据的初始化，一般在实施的初期阶段进行。针对具体的情况，其做法也不同。针对一个新的软件系统，如果该业务没有原系统的支持，其组织机构、角色和用户都是新添加进系统中的，一般按照应用单位现有的情况进行设定，例如用户的编号按照员工卡号设定。
如果该业务原来有软件系统支持，现在要切换成新的软件系统，则有保持业务连续性的要求。例如，原有系统中的业务数据内有组织机构的编码、操作人等信息，则在新的软件系统中，需要保持原有的组织机构的编码和操作人的一致性。一致性的要求有两种做法，一是新系统同原系统一致，采用同样的编码；另一种是如果不采用一致的编码，在将原有的系统业务数据移植到新的系统时，不要将原操作人编码直接移植到新的系统中，要转化成新的用户编码，否则在将来的查询中就会造成不必要的麻烦，一般有这种要求的是组织机构和用户数据，对角色一般都是重新定义。如果原系统的数据舍弃，不移植到新的系统中，则不存在此问题。
从项目的开发实施经验来看，权限数据的初始化的难度不大。一般的管理性软件系统也都提供了权限数据维护的功能，单独作一个批量处理的功能意义不大。一般的做法是甲方提供组织机构、角色和用户的明细表格，罗列组织机构的编码和名称、用户的编码和姓名。如果有原来的软件系统，还需要提供组织机构的编码与原系统的编码及用户编码与原用户编码的对照，作为后续的业务数据移植的用户编码调整的依据。乙方只要提供系统使用指导的功能即可。组织机构、角色和用户的维护，应该是甲方指定专人进行，如果多人进行维护，很容易出现前后不一致及用户权限定义错误的现象。
4.业务数据初始化
业务数据是一个管理性软件系统的核心，是软件系统管理的必须的业务内容，同时业务数据又是系统中变化频率最高的部分。业务数据又分为三类：基础数据、历史数据、现行数据。
数据分类
数据初始化要求
处理方式
初始化原则
基础数据
高
移植或录入
双方协商移植的内容和手段，甲方执行，乙方提供技术支持
历史数据
低
记录总帐，不需要移植或录入
现行数据
高
移植或录入
（1）数据分类
基础数据，顾名思义，就是业务数据中最基础的部分。例如一个收费管理系统中的档案部分，档案提供了收费的对象、收费的标准等各项基本信息。这部分数据是整个业务系统构建的基础，是不能缺少的，在系统的数据初始化时必须准确加入到系统中来。
历史数据，是指以前发生过，以后只作为查询使用，不再进行调整的数据。例如收费管理系统中的已收费用信息，都是历史数据。
现行数据是指软件系统中正在或将要处理的数据，在新的系统中还要进行调整。例如收费管理系统中的欠费数据，以后还需要进行收费处理，是现行数据。
（2）初始化思路
基础数据的初始化，根据不同的实际情况，也有不同的做法。如果原来没有业务系统支持，可以采用分步录入或批量录入的方式。可以单独作一个录入的程序，支持基础数据的录入。分步录入是数据在一个持续时间比较长的阶段，分批次、分步骤的录入系统。批量录入则是在一个持续时间比较短的时间内，组织大量的录入人员，突击进行录入，这种做法在纸面的基础数据比较庞大的情况下适用，能够将以前的手工的业务处理方式在很短的时间内整体转换到计算机系统处理。
如果原来有软件系统支持，基础数据在条件允许的情况下可以进行批量的移植。这里的条件允许包括原有系统的数据结构清楚、逻辑关系准确、技术手段能够支持等内容。如果不具备这几个必备条件，则也无法从原有系统直接将基础数据移植到新的软件系统中，需要采用手工录入手段进行。
历史数据在以后的软件系统中，只作为查询使用，如果完全从原有系统移植到新的系统中，其意义不大，一般只保留总量即可。例如一个收费管理系统，如果系统上线是在年初，则只保留上年结转的总量，对于以往的历史数据不需要保留。如果系统上线是在年中，则保留上年结转的总量和当年的历史数据，以往年度的历史数据不需要保留。
历史数据可以保存在某个特定的地方，需要查询的时候单独进行查询，不移植到新的系统中，这样的做法对于保持新系统的数据的准确性和清晰性是大有裨益的。
现行数据，由于以后的处理要求，需要移植到新的系统中。移植的办法可以根据不同的情况采用移植和录入两种。如果具备原有系统的数据结构清楚、逻辑关系准确、技术手段能够支持等条件，可以采用移植的手段。没有具备以上的条件，则采用手工录入的方式。
（3）初始化工作解析
软件系统的上线，一般的做法是分步进行，让一部分人先用起来。由点到线，由线到面，逐步推进。比如一个集团性的企业，很难做到全部子（分）公司一起使用软件系统，通常的做法是先选择几家子（分）公司，将这些公司的数据先行移植到新的系统中，让系统用起来。然后带动其他的子（分）公司，逐步的将数据移植到新的系统中，进而达到全部应用的目的。这个试点的选择，以及逐步推进的步骤、措施，移植数据的内容、手段等工作，可以由甲乙双方协商确定，甲方负主要责任，乙方可以提供意见和建议，但是执行肯定是甲方的事，让乙方的人员去给甲方的人员下命令肯定是不现实的。如果甲方一直不能确认移植数据的范围，在这个问题上反复的考虑，拖延下去，对项目进度的影响甲方是逃脱不了责任的。
把原来系统的数据完整的移植到新的系统中，这是很多甲方人员的想法，但是这种想法肯定是不现实的。既然新开发了一个系统而不是坚持使用原来的系统，那么新的系统相比原系统而言，在业务管理流程、系统设计思路等等方面肯定有很大的调整。没有一个新开发的系统是按原系统的设计思路、业务管理流程原原本本的照搬过来的，那样新开发一个系统意义也就很渺小了。在不影响业务应用的前提下，对原系统的历史数据进行一些舍弃，是很正常的做法。现实情况是这恰恰是很多甲方人员坚持的地方，当乙方人员提出舍弃某些历史数据的时候，甲方的人员在固执的坚持，而不考虑完整保留的意义和其他可行的做法。此时有效的做法是双发协商确定一个有效的数据移植的内容和手段，并制定工作计划，甲方按计划去执行，乙方提供技术支持的手段。在历史数据的完整性上反复的考虑、坚持是没有意义的，相反的会影响项目实施的进度。
现行数据的认定，即确认哪部分数据是需要移植的数据，是一个非常重要的工作内容，也是一个工作的难点。数据的认定包含两方面的内容，一方面是数据范围的认定，也就是在一个大的应用单位里边移植的数据所属的部门或机构；另一方面是认定该部分数据是现行数据而不是历史数据。这两方面的工作需要项目的甲乙双方协商确定，而执行通常是甲方的工作职责，乙方通常提供指导和技术支持。
管理性软件项目的数据初始化的工作难点，在于要将原系统的数据移植到新的软件系统中。有时还会存在原来的系统是多套的情况，这种情况通常会发生在大的集团性企事业单位中，各个系统的使用方法以及数据库结构等都不相同，这时尤其要分步进行操作，不能一哄而上，否则会造成比较大的混乱。分步的设定，通常是甲方的工作，乙方一般不能直接下硬性的命令。
5.结束语
以上的几种数据的处理，如果是从原软件系统移植到新的软件系统，都需要记录移植的数据统计信息作为以后备查使用，主要包括移植的条数、总量等信息。针对不同的业务系统，应依据实际的业务要求定义相应的业务统计指标，例如针对一个收费管理系统，其指标可以为总条数、总户数、实收总金额、欠费总金额等等。移植数据的统计信息，一般采用表格的形式记录，并且需要项目的甲乙双方签字，作为数据移植情况的备案。
参考文献
1、中国软件网  怎样做好管理软件的项目实施和产品研发 2007-6-7；
2、李明国  关于软件实施项目管理的探讨 2003-4-9。