供水调度信息管理系统的开发

　摘要 为了提高供水调度内部管理效率，将调度业务与信息化技术逐步结合，我们开发了供水调度信息管理系统。该系统不仅为目前的供水调度业务提供了信息化的高效手段，使得系统的开发使用与调度业务的流程标准化、加快调度过程互相形成了良好的互动，而目前所积累的原始数据，为将来进一步管理分析提供了依据。

　　本文以开发管理管网施工票单的功能为例，阐述了系统的开发思路、开发过程以及在实践过程中所遇到的一些问题。

　　关键字  供水, 调度, 信息化, 管理系统, 管网施工

一、背景

　　随着广州供水事业的发展，供水调度业务不断增长。在管网监控数据以外，还存在了大量如各种工作票单、报表文件和其它辅助信息需要管理和统计分析，同时管理流程也日益标准化。调度过程中的各种数据特别是管网、泵站的施工票单日益积累，给人工管理数据带来了相当的压力。建立合适的信息化系统来处理这些数据，可以实现动态管理和业务跟踪，达到提高效率改进流程的目的。我们为此开发了供水调度信息管理系统。

　　在供水调度管理信息系统中，我们以管网施工票单的动态管理，分计划、开工、完工三个主要阶段来跟踪管网施工，并积累下相关的原始数据，为将来进一步管理分析提供依据。系统具有开发快速、经济实用、变更灵活的特点，可以很好地在开发过程中与业务流程的改进互相促进，形成互动的良好局面。

二、构想

　（一）原有的业务流程

　　原有的业务流程基本是：供水管理所、水厂发送供水施工工作票单到调度大厅。调度大厅按照质量管理要求，在接到工作票后将工作票单编号，并将其中数据通过人工抄写，输入统计表格。统计时以人工点数的方式进行。如统计一个月有多少票单时，对施工日期在本月范围内的工程进行点数，或对管网、厂站的施工分别进行统计；又如统计一个月中施工小时数，以得出可能对水量的影响，需要逐张票单核对统计。开工完工则在接报后翻阅相应票单手工填写内容。

由于票单数量比较多时，人工统计效率比较低，按条件统计时，限制条件越多，工作就越复杂，甚至以人力不堪重负。

　（二）使用管理信息系统

　　使用管理信息系统，将数据录入数据库，由计算机完成统计的过程，不仅大大提高统计效率，而且能够有效减少人为错误，并且可以在计划、开工、完工三个阶段分别跟进、统计，实现如下的这样一种流程：

　

这样就实现了以下这些动态跟踪施工过程的机制： 　1. 核对内容 　　由于输入和统计可能会由于输入错误造成差错，如果要得到比较准确的数据，应当在对输入的数据进行核对之后才写入确认统计表进行统计。人工进行的核对可能在修改时造成涂改痕迹，或重新抄写一遍，而由计算机进行自动转存，可以使输入的内容得以在核对后转入统计表，并在需要的时候无涂改地打印出来。 　2. 自动通知相关人员 　　接报供水施工工程票单后，往往要通知部门的其他人员，如调度室主任、组长、调度分析员、管理员等等。有必要在收到施工工作票单之后自动及时通知相关人员，并留下通知记录以备查阅。 　3. 分阶段录入/查询 　　工程从计划施工、实际开工、完工不同时段实施，通过计算机对此进行动态的跟踪，不仅可以分不同时段进行输入，而且可以对不同时段分别自动发送通知给各级人员，还可以针对已经完工或未完工的工程以及现在正在进行施工的工程分别进行统计查询。 分阶段进行供水施工工程跟踪统计，更为符合施工的自然流程，使得施工影响能够及时反映到调度计划分析，减小损失，保障供水。 　（三）两个重要条件 　　　1. 用户的支持 　　推行系统应得到用户大多数人的支持，特别是领导层的支持。因为系统的推行将改变工作人员日常的工作习惯，而这些习惯往往会成为阻力。比如因为不习惯打字而不使用或极少使用系统而使用旧的记录方式。在面对一些比较紧急的事件时，即使是支持推行新系统的人员，也会将旧的操作方式作为第一选择，因为感觉上这样往往比使用新系统风险更低。如果能够制定相应的规则，如要求使用新系统产生的数据才予以确认，那么将有利于系统的推行。 　　　2. 制度的支持 　　在构建系统之前，现有的制度应当已经形成比较明晰的规则章程，这样可以降低开发的风险，使系统开发初期能够相对稳定地针对业务进行设计，不仅有利于设计一个合理的系统结构，而且能够使系统得以尽早开始积累原始数据。 三、特性 　　　1. 以需求驱动开发 　　以需求驱动系统的设计，是比较人性化的做法，也是目前软件开发的趋势。因为在系统设计时，往往工作人员对于信息化技术的认识不足，又或是基于过往流程的经验，没有较深入细致的考虑，因此系统需求是会随着项目的开展而不断改变。要将这些改变及时反映到软件设计上，就要在设计时从需求变化出发，考虑预留的空间，可以随着需求变动而进行迭代式开发或增量设计。 在制定需求时，应与工作人员一同制定需求，而不是以开发者一方的角度推进设计，那往往会造成脱离实际。 　　　2. 数据共享 　　在数据库中的数据，应能共享给多个用户，用户按权限登录并能获取相应的数据权限。按照规范化的处理程序对数据进行管理和决策。局部输入的数据要能够在全局都能进行查阅并按权限进行操作。对于查阅出来的数据应能提取出来，能转换为其他形式的文件。 　　　3. 便捷易用 　　由于供水专业与计算机专业的不同，大多数的供水调度人员并不一定对计算机操作非常熟悉，因此便捷、易用，具有实际用途的操作界面是推广系统使用的一种必要手段。在设计过程中应尽量避免大量的人工输入和数据格式限定。对于常输入的项（如厂、站名称、人名、监测点名称、地名等），可以采用读取设置的方式，鼠标点击就能完成输入。对于有规律生成的输入项（如表单的编号号码等），可以由系统自动生成，又要能够给用户对自动生成的内容进行修改。 　　　4. 实用性 　　在设计系统时，我们充分考虑了系统的实用性。在设计时就将目标定为一个可以为调度人员提供较丰富各类相关信息的系统。因此将各种天气参数、会议通知、工作照会、公布板、传阅文件发布、站内消息/信箱等功能都集成在内。工作人员随时可以在系统首页浏览到调度室内各种发生的事务，不仅有利于提高工作效率，而且也提高了系统的使用率。对于工作人员养成使用信息化手段的习惯来提高工作效率具有良好的作用。 四、设计 　（一）总体结构 　　系统结构可以有很多种，这里我们采用MS SQL Server2000和使用ASP 2.0设计的B/S系统结构，服务端通过TCP/IP访问数据库，并开启WEB服务，用户使用IE浏览器进行操作。与C/S结构（即使是瘦客户端）相比，B/S结构的系统更新更方便。这样的设计主要是考虑避免在开发过程中需要频繁更新客户端。这对于开发修改快速的原型系统来说是非常有利的。用户客户端本地的设置，使用cookie对非敏感的信息进行记录，敏感信息则使用SSL技术（尽量减少敏感信息的记录）传递。 　　　系统总体结构图如下： 　　　 （二）数据库结构 　　出于简单化系统设计来考虑，这里我们没有使用数据库关系。在将来的应用中还可以进一步建立相应的数据关系，以使流程更为简捷。 　　　1. 不进行记录的内容 数据库结构的设计应以简洁明确为主，对于可以计算出来的数据应不记录在内。这样不但可以在访问数据库过程中节省资源，而且对于维持数据一致是有好处的。比如施工超时时间=实际完工时间-计划完工时间，由于实际完工时间和计划完工时间已经记录进数据库，因此施工超时的时间就不需要进行记录，而是在用户界面显示时动态显示出来。 　　　2. 施工票单存储数据库 　　施工票单的数据库包含如下的内容： 　　a.主键/索引，即标识该工作票单的唯一号码，由数据库自动增量生成。其作用主要是查询时方便，因此可以不在用户界面显示出来； 　　b.记录人信息，记录该条信息的用户，该用户应该是在用户信息数据库中的用户，其作用主要是在将来对记录进行修改、删除时可以判断权限，此外也可以跟踪进行记录操作的人； 　　c.票单编号，该编号是物理票单的唯一标识，但不排除有时候需要记录改期、延期等工程时，使用同一张票单，因此票单编号应允许重复，判别数据库不同记录，还是要使用主键/索引； 　　d.施工计划信息，记录计划施工的基本信息如工程内容、地点、所属区域等还包括有计划施工时间以计算实际超时施工等信息； 　　e.施工开工信息，包括实际开工时间，开工核实人； 　　f.施工完工信息，包括完工时间和完工核实人； 　　g.确认机制的信息，包括计划施工、实际开工、实际完工三个阶段的确认人、三个阶段分别已发出通知的人员名单，在每一票单的记录信息中包含这些信息以备查； 　　h.改期、延期等其它信息。 　　　3. 确认信息队列数据库 　　确认信息队列的数据项应包含票单存储数据库中除施工开工信息、施工完工时间、确认机制信息和改期信息以外的所有信息。在确认后，将队列内的内容直接转入到票单存储数据库，并将确认队列内的此条信息删除。 　　　4. 删除/修改信息数据库 　　删除/修改记录，应以数据形式将操作记录下来备查，当然也可以使用log文本的方式进行记录，但进行搜索不如数据库记录的信息方便。 　　　5. 其他数据库 　　除工作票单需要使用的数据库外，还包括有记录用户基础信息的数据库、按时间对添加票单进行记录的消息数据库、通知相应用户施工信息的数据库以及其他的数据库。 五、存在问题 　　在实践的过程中，我们也遇到了一些棘手的问题，包括有： 　　　1. 数据有效的问题 系统应该在基本功能完成，并能实际投入运行后才使用。因为一旦开始投入运行使用，工作人员输入的数据就会被当作历史数据存留确认，如果系统不完整，使得工作人员过往输入的数据无效甚至丢失，不仅打击了使用系统的积极性，而且也让项目的继续开展极为不利。因此在输入的数据中应尽量完整，包含了考虑到的各方面数据，此外系统功能也基本完整，对数据能及时查改、提取和统计。在系统开始投入使用之后，输入的数据应该都能兼容到将来的修改中。 　　　2. 文件上传问题 在B/S模式下上传文件时，要对上传目录的权限进行设置，特别是不使用Windows身份登录网站的情况下，往往在安全方面造成隐患。我们的解决办法是首先使网站不直接在internet运行，而是仅在局域网内运行，由于我们开通了VPN的功能，因此要通过外部访问，只要首先拨VPN链接就可以进行访问，实际使用过程中，这样的一种访问速度并不是很慢；其次是对于windows权限我们设置了仅对固定上传文件的目录有上传权限，而禁止操作其他目录。对登录网站的用户信息进行加密，建议所有用户设置安全密码。 　　　3. 自动验证问题 　　微软的.net技术有自动验证网页发送内容的功能，但是有时我们要发布一些带有html标记的信息时（如传输<img>标记以实现显示图片），就无法通过自动验证，因此我们的做法是关闭这些自动验证，使用人工的方法来确保验证输入，并把验证的功能写成类模块的函数以复用。但是这种做法仅在某些需要的页面实施，如留言、发布布告、通知等功能，在其他的页面则仍使用自动验证功能。 　　　4. 记录本地设置信息问题 　　有些不是很敏感的客户端本地设置信息需要记录起来。如在数据显示表格中隐藏某些不需要的项目、网页的一些个性化设置等。开始时我们使用访问注册表的方式对本地设置信息进行记录，但是通过服务端来操作客户端注册表不仅对使用系统的客户端造成安全上的问题，而且也要装有防火墙、防网页修改注册表软件的客户端开通权限。而使用服务端的注册表，则无法使客户端各自使用自己的设置。因此我们改用了cookie对这些设置信息，则解决了这些问题。 　　　5. 输出Excel表格问题 　　由于Excel对表格形式文件的处理具有强大的功能，因此在B/S方式下，输出Excel表格进行打印是常用的做法。对于一般的数据表格的输出，只要利用JavaScript运行在客户端就可以实现，而对于不甚规则的表格（如需要还原原来施工票单的电子表格形式），则产生了一些问题。 　　我们的想法是按照原表格的格式做成Excel模版，然后在响应用户要求时，将数据读取填入模版。目前浏览器生成Excel并没有很好的支持，在客户端操作Excel需要对权限进行设置，而微软公司也不建议使用管理员的权限从网站登录服务器这种不安全的做法来操作Excel对象。因此我们采用在服务端将数据填充模版，然后用下载文件的方式让客户端进行访问。