项目计划管理模块设计

第四章 系统设计

　　软件设计主要解决待开发软件“怎么做”的问题。在对审计项目管理应用系统进行了深入的需求分析后，对系统进行详细设计。

　　4.1 系统设计原则。

　　审计项目管理应用系统的设计，需要遵循以下基本原则：

　　1.实用性与可行性。

　　系统各项应用功能应紧密结合审计工作实际，具有实用、成熟、稳定、安全的特点，便于审计人员操作，便于系统管理。

　　2.可靠性与安全性

       系统应能保证数据的安全性、准确性和一致性，能从系统结构、技术措施、系统管理等方面提供多种检查和处理手段，如针对特定的网络环境，采取系统安全机制、数据存取的权限控制等措施，确保系统运行的可靠性和稳定性，达到最大的平均无故障时间[36]。

　　3.先进性与扩展性。

　　系统设计应具有超前性，注重合理性、可行性、正确性，且具有发展潜力，突出先进性与成熟性并重，能面向未来应用发展。系统的软硬件环境应具有良好的平滑可扩充性。在现有模式下，能促使通用软件构件和行业业务构件松散耦合，实现“构件库”的模块化、标准化和灵活性，增强系统的可复制性和二次开发的现实可能性。

　　4.开放性与标准化。

　　系统应遵循业界主流规范或标准，采用先进、成熟的软硬件支撑平台，减少网络的硬件环境、通信环境、软件环境、操作平台之间的相互依赖性[37]，可灵活地与其他系统集成。

　　5.高性价比与可管理性。

　　一是系统应以合理的投入、采用最新技术推进建设，提高技术普及率和资源综合利用。二是系统能够提供完善快速的开发工具，提供多种方案与其他系统整合，拥有安全、稳定、高效的支撑环境。三是系统要有良好的可管理性和可维护性，包括对系统自身的管理和维护，以便于系统的日常运行维护和管理。

　　4.2 系统功能模块及其数据库结构设计。

　　根据之前的需求分析，审计项目管理应用系统主要包括系统管理、项目计划管理、项目公文管理、项目信息查看四大模块，总体功能框架如图 4.1 所示。

　

　　4.2.1 系统管理模块设计。

　　1. 部门管理。

　　由系统管理员统一维护系统使用单位的部门信息、部门所属人员信息，对人员调入或调出部门进行管理。

　　（1）数据完整性设计。

　　(a)对部门信息进行管理，部门编号、部门名称不能为空，部门编号不能重复，部门类型分为机关领导、行政管理和业务处室三种类型。

　　(b)对部门所属人员进行管理，在所选择的部门下编辑部门人员信息，人员编号、人员姓名不能为空。

　　(c)对人员调入或调出部门进行管理，在所选择部门中，通过在人员列表中进行人员选择，将所选中人员调入或调出所选择的部门。

　　（2）对应的数据库逻辑结构设计。

　　对应的数据库逻辑结构即二维表，为本功能设计的二维表有：系统部门信息表 INTERFACE_DEPT、系统人员信息表 INTERFACE_UNITUSER、人员部门设置表 INTERFACE_DEPTUSERS，各表的结构如下表 4.1 至表 4.3 所示。

　　2. 职务维护。

　　按照单位内部的行政关系，维护系统人员的职务，对系统内职务信息进行管理。行政职务主要包括：局长、副局长、纪检组长、总审计师、副调研员、处长、副处长、主任科员、副主任科员、科员、办事员、工勤员、临时工等。

　　（1）数据完整性设计。

　　职务编码和职务名称不能为空。

　　（2）对应的数据库逻辑结构设计。

　　为本功能设计一张二维表：职务信息表 HC_DM_POST，其结构如下表 4.4所示。

　

　　3.角色人员管理。

　　按角色来划分系统功能，即不同角色人员具有不同的菜单功能。根据业务管理要求进行角色人员的设置，并可根据人员职责、管理要求的变化实时调整。

　　（1）数据完整性设计。

　　(a)对角色信息进行管理，角色代码、角色名称不能为空，角色代码不能重复。

　　(b)选中某个角色，在人员列表中选择人员，通过调入或调出功能，给选中的角色选择角色人员。

　　（2）对应的数据库逻辑结构设计。

　　为本功能设计的二维表有：系统角色表 HC_DM_POST、角色人员表INTERFACE_ROLEUSERS、角色授权表 INTERFACE_ROLERIGHT、用户授权表 INTERFACE_MENU_USER，各自的结构如下表 4.5 至表 4.8 所示。

　

　　4. 功能管理。

　　系统管理员对系统功能进行维护，功能管理分为功能组管理和功能模块管理。每个功能模块对应功能类型。在角色授权时，系统管理员根据对应的类型进行授权。

　　（1）数据完整性设计。

　　(a)对功能模块进行管理，模块代码和模块名称均不能为空，模块代码不能重复。

　　(b)对功能信息进行管理，所属模块、功能代码、功能名称、链接地址均不可为空，功能代码不能重复。

　　（2）对应的数据库逻辑结构设计。

　　为本功能设计的二维表有：系统功能类别表 INTERFACE_MAINMENU、系统功能表 INTERFACE_MENU，各自的结构如下表 4.9 至表 4.10 所示。

　　

　　5. 项目基本资料维护。

　　维护项目基本资料类型，选择某种类型，通过新增或删除功能，编辑项目基本资料。对项目中频繁使用的选项内容进行维护，主要包括对项目来源、项目类型、项目类别、专业类别等基本资料进行设置，以方便在审计项目计划录入、项目管理时等进行选择。

　　为本功能设计的二维表是项目基本资料表 SJ_DM_XMJBZL，其结构如下表4.11 所示。

　

　　4.2.2 项目计划管理模块设计。

　　1.计划录入。

　　由项目计划管理部门法规处根据年度审计项目计划，录入项目信息。通过新增功能，进行项目信息的编辑，计划编码系统自动生成，项目计划主要内容包括：立项年度、计划性质、项目号、项目来源、计划年度、责任处室、项目名称、类型、重要审计项目 （是/否）、保密期（默认 2 个月）、审核人员等内容。在项目列表中选中项目后点击发送分解将项目计划发送到计划分解步骤。为 本 功 能 设 计 两 张 二 维 表 ： 项 目 计 划 表 SJ_ITEM 、 项 目 成 员 表SJ_ITEM_PERSON，各表的结构分别如下表 4.12 和表 4.13 所示。

　　2.计划分解。

　　根据法规处发送的项目计划基本信息，相关业务处室完善相关信息，尤其是人员分工和时间安排信息，并重新发送法规处审核确认。

　　(1) 具体操作设计。

　　(a)根据查询条件显示已发送至业务处室分解的项目计划，点击分解按钮进行项目分解信息录入。

　　(b)相关责任处室在法规处已录入内容的基础上，完善以下信息：审计组组长、副组长、主审、审计人员（可以多人）、审计开始日期、审计结束日期、审计范围起始日期、审计范围终止日期、审计目标、审计重点、组织形式等。填写完成后重新发送法规处审核。

　　（2）对应的数据库逻辑结构设计。

　　本功能使用以上的项目计划表 SJ_ITEM 和项目成员表 SJ_ITEM_PERSON。

　　3.计划审核。

　　法规处对责任处室填写的审计信息进行确认审核，审核完毕后项目组成员即可以起草各类审计文书，查看该项目的所有相关资料和信息。

　　(1) 具体操作设计。

　　(a)根据查询条件显示已经分解完成的项目计划，点击所选项目可以审核项目信息及项目分解信息。计划审核员也可以在查询结果列表中勾选项目，批量审核通过。

　　(b)显示项目计划详细信息和审计组人员列表，供审核人员审核。点击审核通过即项目计划通过审核，若审核不通过，点击退回则将项目计划退回到计划分解步骤。

　　（2）对应的数据库逻辑结构设计。

　　本功能使用以上的项目计划表 SJ_ITEM 和项目成员表 SJ_ITEM_PERSON。

　　4.项目实施。

　　根据项目的实际实施情况，更新项目实施状态，实施状态包括未实施、审计中、待结案、已结案、调减 5 种状态。审计项目的实施状态，以审计业务文书的流转情况为依据进行实时更新。具体设置如表 4.14 所示。

　

　　审计过程中，也可以根据查询条件显示已经审核通过的审计项目列表，可以直接为审计项目选择项目状态，变更项目状态。如未结案，可变更项目实施状态；如已结案，则不可再变更项目实施状态。本功能使用以上的项目计划表SJ_ITEM和项目成员表SJ_ITEM_PERSON。5.项目变更通过该模块可新增审计项目或变更本人参与的审计项目信息，对于变更的信息进行日志记录。

　　（1）具体操作设计。

　　(a)根据查询条件显示已经审核通过的用户参与的审计项目计划，点击变更按钮进入项目信息变更页面。

　　(b)编辑项目变更信息，点击审计组人员可以变更人员信息。审计组人员页面中，显示机构部门列表和部门所属人员列表，同时显示该项目已有的审计组人员，可以删除。项目变更后需重新发送法规处审核确认，同时记录项目变更记录。

　　（2）对应的数据库逻辑结构设计。

　　为本功能设计的二维表是：项目变更表SJ_ITEM_CHANGE，其结构如表4.15所示。

　　6.项目滚动。

　　对于还在审计中的项目可滚入下一年度继续执行实施。主要针对工程审计项目，由于审计时间跨度较长，需要滚动实施。年度结束后，根据查询条件显示已经审核通过的审计项目列表，将审计状态为未实施、审计中和待结案的审计项目，根据实施情况滚入下一年度继续实施。本功能使用以上的项目计划表 SJ_ITEM 和项目成员表 SJ_ITEM_PERSON。