Ø 问题：参数变更

HIS3主要有将近500个参数（最新统计498个，但是不清楚目前的参数库是否真实完整）,主要分为系统配置参数、业务开关参数和功能选项参数三大类，从使用级别上来说，分为应用级、系统级和公用级。这些参数是我们灵活配置业务流程的基础，从某种程度上来说，是按照产品化要求开发的HIS3能够支持客户化医院项目的关键。

在绿城的SP11升级过程中，参数方面给我们的工作造成了相当大的影响。主要有以下几类参数设置方面的问题：

1、  参数随意添加问题。

在北京协和和杭州绿城的并行开发过程中，开发人员对于参数的添加缺乏一个申请和审核机制，一般是开发人员把参数先使用了，然后才告诉北京的杨杰和我，没有人集中管理我们的参数。

2、  参数变更通知问题。

目前，在北京和杭州之间，对于参数的变更，是由杨杰和我每天各自交换本组的参数库变更记录（包括其他资源变更）。但是，这个方法不是很保险，存在开发人员漏发参数变更给各自负责人的情况，也存在杨杰和我在汇总本组的今日变更的时候，漏汇某些参数变更的情况。

3、  参数实际使用问题，主要是业务开关参数。

业务开关参数的设置状态，将直接控制程序按照完全不同的应用模式进行。目前的参数取值机制是，如果参数库找不到对应的参数，则按照界面层代码编写时指定的默认值进行处理，否则取该参数的参数值(GY_CanShu.CanShuZhi)。在此次升级过程中，由于存在交换参数遗漏、界面层脚本参数默认值设置不合理、数据库参数的参数值设置不合理这三种问题，导致绿城部分业务流程跑不起来，或进入了协和流程的情况发生，现在都已经解决。

经过和胡老师、马骏、陈智鸿的讨论，现在的解决方案是：

1、              所有的开发人员，禁止在未申请和审核的情况下，直接在脚本和参数库里添加参数，北京的需要先报给杨杰和马骏，杭州的直接报给马骏，必须经过认可，才能在脚本中使用。马骏将负责维护参数记录的完整性和审核参数添加的合理性。（马骏不在的时候怎么办？）

2、              由于目前来说，绿城是我们最典型的客户，应用的系统也是最完备的，所以，要求开发人员代码里用到参数时，必须按照保证绿城系统正确运行的要求设置界面层参数默认值和参数库参数值，保证在参数交换可能存在错误的情况下，系统也能正确运行。