ERP阶段实施之概要设计阶段的分析（下）（by AMT 曹伟）

摘要：项目可行性分析是针对实施的可行性进行分析的，而并非给出系统在业务领域模型，其在系统解决方案上给出的是客户需求的原始模型。

ERP阶段实施之概要设计阶段的分析（下）

－－如何编写中小企业ERP项目概要设计说明书

by AMT 曹伟

2.4系统功能的介绍

2.4.1系统的功能模块的分类

从使用者的单位来分有三类：客户服务部的功能模块、仓库的功能模块和客户的功能模块。

从业务来分有八类：订单功能模块（其他七类略）。

从业务角度来设计，分为六个主题领域，以下描述了各个主题领域和功能模块间的对应关系

在区分主题领域时，主要的立足点在用例上，根据前面给的用例模型，和分析模型给出业务流程相关的数据流图(参照下面系统设计实现)，

2.4.2功能模块的详细介绍

根据各业务模快进行说明，首先详细介绍各业务的业务规则、业务过程，然后根据业务的业务规则和业务过程描述系统的实现模块。

举例说明：订单功能模块

业务描述：客户需要从客户服务部采购备件。

功能描述：订单负责人员根据客户的提交的已确定的订单，在系统进行数据录入，打印出一份含单价和金额的订单单交于客户，同时在系统中形成应收款（收取的客户的销售金额）。订单负责人申请发货，若发货完毕，仓库人员在系统上录入发货的情况。

2.4.3设计要求

针对以上分析的系统，根据业务的具体情况、操作人员、系统的网络拓扑结构等等先决的条件，设计系统相关的容量、响应速度、处理能力以及需要硬件支持。

ERP软件供应商一般不提供硬件设备，但对于承揽了客户的服务类型的系统，就需要为客户提供一个相应的硬件指标，这个硬件指标是给客户一个标准，客户需要按照这个标准进行硬件设备的采购。当然这些设备的给出需要进行技术上的论证，不是随便照几台计算机或服务器就可以作为硬件设备的，另外，对于相应的操作系统、支撑软件等都需要ERP提供商提供详细的资料，以方便用户采购(原在系统解决方案中提出的硬件及相关的支撑软件可能会有相应的变更)。

以下就各种条款进行简单的说明，读者需要根据相应的系统进行分析、论证，以给出符合系统的准确资料。

2.4.3.1设备

该硬件设备由使用单位提供，该处罗列的型号和设置仅供性能上的参考。

PC 机（客户端PC）：

处理器：Inter PII266（及以上）

内存 容量：64M

硬盘 容量：2G

操作 系统：Windows98/IE5.0（及以上）

IBM X系列服务器（Database Server/ Web Server）:

服务器型号：X342(8669-2RX)

处理器：Inter PIII 1.13G *2

内存 容量：256M*4

硬盘 容量：IBM 18.2G*3

其他 外设：Raid Card/40XCD/ 10/100M网卡

在描述上提供了服务器和PC机不同的性能描述，在编写概要设计文档时，需要将各种服务器描述并还要描述该服务器在性能上为什么适合作该项服务的服务器。在这里我把Database Server/ Web Server放在一起叙述，在做具体的项目时还需要把服务器的性能分析一下，有针对性提供适合该系统运行的硬件。

2.4.3.2运行环境

以下给出系统运行的软件支撑环境：

服务器：

Microsoft Windows 2000 Advance Server

Microsoft SQL Server 2000 Enterprise

客户机：

Microsoft Windows 98/IE5.0(或以上版本)（兼容）Windows me/ Windows 2000 Professional/Windows XP

2.4.3.3客户端要求

客户端是指直接在线操作的客户端，因系统采用Web Service架构，故需要说明客户采用的操作模式。

其网络环境需要客户端的机器在操作期间实时地连接在Internet上，采用IE5.0及以上版本的浏览器，尽量避免使用IE5.5版本的浏览器，因IE5.5浏览器对于某些层（即CSS）不作支持。

2.4.3.4接口协议

采用简单的文本接口为例，进行接口协议的声明描述：

①输入参数：由CALL CENTER人员提供EXECL文件，该文件含有以下内容：

客户所属地区，咨询数量，投诉数量，热线记录服务数量，热线记录质量。

②现举例如下：“南京，1，0，12，56”

③文件的来源：由客户服务部的Call Center负责人员按一周为周期将EXECL 数据文件提供给客户服务部的数据人员。文件名称由用户自己确定，只要名称符合Windows系统的文件命名规范，对于具体在此不作规定。

④操作方法：系统将该文件作为参数，导入数据库中。

2.4.3.5安全性的考虑

若系统运行在公司内部网，WEB服务是依赖使用客户的网络环境；若客户没有内部网，系统也不提供软/硬件防火墙，向用户建议采用硬件防火墙。此外，系统据microsoft公司的SERVER服务操作系统提供相应的安全机制以及客户内网的安全机制，在服务上采用windows 2000 server提供的AD安全机制。

同时，系统在实时操作时，采用定时限机制，保证操作的时段性，也有效避免业务的不当。

2.4.3.6业务连续性与数据完备性

各个业务在实际的操作中，各个环节节节相融，保证业务操作过程中准确、及时、完整录入业务数据，保证下一个操作环节的正常进行，保证业务的过程有完整的数据以备查。在业务进行中也需要各个环节相关联的数据，在系统投入运行前应该把日常使用的不常变更的数据初始化入数据库，保证业务操作的正常进行。

2.4.3.7数据备份机制

采用SQLSERVER 2000数据库系统自身的备份机制，定时间向指定设备（比如MO光驱）备份数据。该硬件实施由使用者提供，若没有数据存取设备，该备份需要一个非本机的存储空间用来存放备份数据。

3．设计目标的实现

概要设计的设计目标是初步地定义软件各功能模块的功能、系统的接口、数据属性以及数据间的关系，初步地划分程序基本结构，初步地说明各功能模块名称、功能和实现，以便于详细设计(下一节我们将介绍详细设计)。

3.1设计目标的分类

3.1.1接口模块的设计目标：

接口模块需求分析的结果是读取系统产生的数据文件，以文本方式和EXECL的形式提供，接口设计的目标是把数据文件读入切实的数据库中、同时提供接口函数把数据库中的数据导出成EXECL格式的文件。对接口函数进行详细分析，得出完整的实现方式和实现过程，提供接口实现方法的属性的描述、操作。

3.1.2功能模块的设计目标：

详细设计各个模块的数据来源、操作方式、数据交互方式、各类型的数据录入数据库中、以及各个字段在操作过程中的关联性。

详细定义各个功能的实现时各个条件、业务过程的操作规范、操作内容、操作方式方法等。

3.1.3数据维护模块的设计目标：

详细设计维护模块的操作方式、数据以及数据间的关联性。详细定义该维护模块的各个操作的实现、数据来源等。

3.3系统程序框架

在系统的实现上，在前面我已有较为详细的说明，主要针对于全国各地的条件进行分析，结果是我们必须提供两类系统供不同条件或环境的客户使用，故产生了接口型子系统。

主系统和子系统之间的交互采用文件包的形式，子系统将系统中生成的文件包以一定的方式给客户服务部的数据负责人员，数据负责人员通过接口导入到主系统中。

其实现的形式（参见图5）：

图5：系统的程序实现

在主系统中我们将分各个模块进行阐述，每个模块对应于一个具体的流程，为此我们再次讨论一下业务的流程，以及与业务相关联的程序设计。而对于程序实现的包或子系统，将在详细分析中继续讨论。

3.3业务流程的再讨论

[一段说明：此时给出业务流程，略显迟疑，关于业务流程的描述是在系统的解决方案中给出的，但在系统方案的分析上，我们给出的是服装行业的具体例子，而在例子中也没有给出具体流程情况，因为服装行业的订单业务和其他行业的订单业务基本上是相同的。]

功能模块的来源是客户业务流程系统体现，以上提出的具体目标是根据系统整体框架上的要求给出的，为了继续落实各个功能模块的实际操作和应用，我们再对业务流程进行讨论。

在用例模型中提及的订单业务，其具体的业务流程见下：

图6：订单的业务流程图

通过客户描述的业务流程，我们给出系统的数据流图，根据数据流可分析得出系统的数据库结构，其间的字段、以及其他更为详细的信息，需要对数据流逐步精化而得到，如何精化以及精化到一个什么样的地步，将在下节详细设计中阐述。

图7：订单业务的数据流图

由订单的业务流程（客户和系统分析人员都很熟悉的）到业务的数据流图，是一次描述上的整理，若采用RUP过程并建模的话，其分析模型将从类图的角度逐步说明系统的实现。

以上的这个过程—从业务需求到数据实现的分析是我们走完分析的第一步—概要设计，概要设计是概要地分析系统的实现，提供系统实现的初步，在以后的分析中将以此为蓝本，逐步细化、精化，从而达到完全解剖系统，在系统的实现上游刃有余，便于操作、控制。

4．总结

以RUP的观点：从客户的需求出发，分析得出系统的用例模型，以用例模型为驱动，分析得出系统的分析模型，在系统的架构上体现了系统“本性”，以系统的模型入口，各级细化、逐层精化，辅助以说明性文字。在项目的实施有效的开发、跟踪和控制。

以国内常规开发过程的观点：从客户的需求出发，进行需求分析，给出需求分析报告(关于软件需求说明书的编制参见GB8567-88附录C)，根据编制出的系统需求分析报告，系统设计人员进行概要设计，满足了交流上、项目跟踪和控制上的需要，但在有效性或效率上存在不足。

比较以上的两个开发过程，较为清楚认识到国内目前的较为成熟软件开发过程是基于描述性文档或制品(Artifact)，而RUP的观点是基于各级分析模型，侧重点在于文字形式和图形形式的区别，当然，RUP将两者结合起来，更详细、更分工化的进行系统开发。

在此系列的技术实现和实施的文档中，我将RUP和国内的开发过程进行结合分析，主要是想借此ERP阶段实施文章的机会和大家交流软件项目开发的“新”(心)得。无论是文档形式还是模型的形式，主要是实施项目上有保证满足项目在过程控制上的需要，若为小的项目，就比如该文章的例子，我个人认为，采用文档化的形式已经满足了项目的需要。没有必要循规蹈矩地模仿RUP 的过程。

全文完

浏览：ERP阶段实施之概要设计阶段的分析（上）

本文由作者向AMT提供
作者联系方式：errorcao@hotmail.com

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友