集团企业管理信息系统(完整版）.doc

集团企业管理信息系统集团企业管理信息系统】我于 199 8年8月至 201 X年7 月参加了某个大型集团的企业信息系统的开发工作,该大型集团的业务主要涉及到 it 类产品的进销存。本人在项目中负责系统分析的工作, 该集团企业原先已委托某个电脑公司开发过一套 it 类产品管理系统,但是该老系统存在两个主要的问题: 系统运行速度非常慢,如商品销售开单时,从确定开单到开单完成有时需要 1~2 分钟左右的响应时间,让客户无法忍受。系统数据不准确, 经常出现实物库存与电脑库存严重不相匹配的情况, 使销售数据的统计产生一些混乱, 有关财务的数据因此无法有效使用, 只能采用人工录入方式补充进行。在这种情况下, 该集团的总经理决定参考原有系统重新开发一个系统, 以便解决原系统所存在的上述两个难以克服的难题。注; 原系统采用 pb 开发,数据库采用 sbase ,服务器采用 indos201Xserver ,客户端采用 indos 98 ,程序架构采用的是传统的 s 结构。鉴于该集团业务操作复杂, 流程多, 涉及人员多等特点, 以及项目完成时间短, 经费有限, 人员有限等限制约束条件, 再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题, 我们决定要对原系统的需求做一个比较彻底的和切实可行的分析, 由于原有系统已经开发了近两年, 并且客户也有了一定的使用经验, 业务基本流程本身也并没有太大的变化,因此,我们把需求分析的过程分为三步: 分析原有系统的结构,主要是数据库结构和程序结构,在获得第步结果的基础上写出基本需求, 交由客户评审补充, 在第步的基础上开发原型,利用此原型与客户交流,从而获得最终可用的需求结果。下面按上述三步分别加以论述。第一步是实施逆向工程,获取原有系统的基本需求。由于原有系统在功能上大体上能基本满足客户的需求, 并且在两年多的开发中也积累了不少经验,因此,从中可以获得一些有益的参考, 也可以避免多走弯路。在这一阶段,我们采用的主要工具是 pb 自带的 poer designer 和 pb douments; 前者主要用来分析数据库结构, 后者主要用来分析程序结构, 便于开发人员与高级用户理解程序。采用这两个工具的原因是: 原系统过于庞大,模块多,数据库模式多,表格量很大,仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成, 而且原有系统未能提供一套正确完整有效的设计文档, 于是我们只能依靠工具辅助来进行。在使用 poer designer 分析数据库, 并且用 pb douments 分析原程序中的 pbl 以后, 我们对原系统的结构有了一个初步的了解, 再结合对原系统的使用, 基本明确了功能与流程的需求, 并在此基础上用人工录入方式, 产生了初步需求的自然语言文档。这里指出,使用 poer designer 的一个不足之处是: 如果一个表中的字段过多,而且又同时依赖多个表时,输出的表格相关图形很复杂,有很多交叉,且难于调整,不方便阅读及打印。第二步是在第一步的基础上进行的, 即写出系统基本需求, 交由客户评审和补充。通过第一步的逆向工程,我们获得了系统的基本需求。为了充分记录需求的变化及需求之间的依赖关系,我们决定选用 rational 公司的 requisite pro 作为我们的需求管理工具, rationa l 公司有一整套用于需求管理的工具, 功能非常强大, 包括 requisite pro 、 lear quest 等等,这些需求分析工具可以对需求进行全面的管理,包括记录需求的变化情况,需求之间的依赖关系等等。但是,我们考虑到 rational 的一套工具全面实施会非常昂贵与复杂,需要非常强的项目管理能力才能全面实施, 因此, 我们只采用了其中最简单的一部分功能,那就是记录需求变更,记录需求之间的依赖关系,其他跟 rup 有关的功能都给略去了。之所以这样做, 主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说, 我们根据自己的理解并写出基本需求后,交由客户做评审井做适当补充,我们将经过补充整理后的需求作为正式需求记录入 requisite pro 所维护的数据库中, 并对各个需求进行分类, 设定优先级等, 这些工作完成后,就可以从数据库中直观地了解客户到现在为止提出了哪些需求, 哪些需求是必须优先考虑的, 哪些是难度较大的等等。在这个过程中,我们遇到了一些问题,譬如: 用户对我们用自然语言书写的需求文档有许多地方不理解,往往在花了较长时间阅读之后, 仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系; 另外是由于首次采用 requisite pro 进行需求管理, 在类型划分, 属性值的确定上, 部分开发人员没有经验, 造成了不少反复,对于前者,我们的方