第 11 章 MIS 系统开发的原型法

1. 第11章 MIS系统开发的原型法

2. 11.1 原型法概述 • 1.1.1 导致原型法产生的结构化生命周期法的 不足之处 • 1.前提不符合实际：结构化生命周期法要求用户在未见到实际运行的系统之前就能够靠规格说明书来清楚的一劳永逸的表达对要开发的系统的需求，这往往不；人的认识规律。 • 2. 开发周期长且难使用环境变化：结构化生命周期法使用工具效率低，要形成许多冗长的文档，导致开发周期长且难使用环境变化。 • 3. 很难调动用户参与系统开发的积极性：”务虚“阶段长，用户长期看不到实际运行的系统，阻碍了用户参与。

3. 4. 各阶段之间不允许有反复：各阶段使用完全不同的模型，阶段之间反复困难，只适于瀑布式前进。 • 11.1.2原型法的一般工作过程 • 1.原型法的概念：在对用户需求作简要分析后，就快速地建立系统的原型，使用户能通过实际试用原型系统来认识优势与不足，多次反复地参与原型改进，直到得到满意的系统。 • 2.原型法的一般工作过程（如下页所示）

4. 用户提出要求 • 识别归纳问题 • 开发系统原型 • 分析评价 • 不可行处理 • 不满意处理 • 修改 • 试运行 图11.1 原型法的工作过程

5. 3. 原型法的软件支持环境 • 一个方便灵活的关系数据库系统（RDBS）提供设计上和存取上的方便，允许直接进行数据的模型化和简化程序开发。 • 一个与RDBS相对应的方便灵活的数据字典，它具有存储所有实体的功能，用于存储所有系统实体的定义和控制信息。 • 一套与RDBS相对应的快速查询系统，能支持任意非过程化的（即交互定义方式）组合条件查询，且能将查询结果保留，并和字典溶为一体。 • 一套高级的软件工具（如4GL或信息系统开发生成环境等等）用以支持结构化或面向对象程序，并且允许采用交互的方式迅速地进行书写和维护，产生任意程序语言的模块。

6. 一个非过程化的报告或屏幕生成器，允许设计人员详细定义报告或屏幕输出样本。一个非过程化的报告或屏幕生成器，允许设计人员详细定义报告或屏幕输出样本。 • 原型人员工作台：提供原型开发人员使用，具有交互功能，使用方便，并能产生反馈信息的工作站。 • 基于上述这些软件支持工具，“原型”可以快速生成，可以快速地测试，即可以测试新的构思、新的设想的好坏优劣。对于想法、概念、观点和要求的正确性，都可以在原型实验室中加以验证。这就是原型技术目前越来越广泛存在于各种形式的开发活动中的主要原因。

7. 11.1.3 原型法的特点与适用范围 1．原型法的特点 原型法更多地遵循了人们认识事物的规律，因而更容易为人们所普遍接受。 人们认识任何事物都不可能一次就完全了解并把工作做得尽善尽美。 认识和学习的过程都是循序渐进的。 人们对于事物的描述往往都是受环境的启发而不断完善的。 人们批评指责一个已有的事物，要比空洞地描述自己的设想容易得多，改进一些事物要比创造一些事物容易得多

8. 原型法将模拟的手段引入系统分析的初期阶段，沟通了人们的思想，缩短了用户和系统分析人员之间的距离，解决了结构化方法中最难于解决的一环。原型法将模拟的手段引入系统分析的初期阶段，沟通了人们的思想，缩短了用户和系统分析人员之间的距离，解决了结构化方法中最难于解决的一环。 • 所有问题的讨论都是围绕某一个确定原型而进行的，彼此之间不存在误解和答非所问的可能性，为准确认识问题创造了条件。 • 有了原型后才能启发人们对原来想不起来或不易准确描述的问题有一个比较确切的描述。 • 能够及早地暴露出系统实现后存在的一些问题，促使人们在系统实现之前就加以解决。 • 充分利用了最新的软件工具，摆脱了老一套工作方法，使系统开发的时间、费用大大减少，效率等方面都大大地提高。 • 原型法可以提供很好的项目说明和示范，简化了项目管理。 • 原型法可以接受需求的不确定性和风险。

9. 2．原型法的适用范围 • 作为一种具体的开发方法，它有一定的适用范围和局限性。主要表现在： • 对于一个大型的系统，如果我们不经过系统分析来进行整体性划分，想要直接用屏幕来一个一个地模拟是很困难的。 • 对于大量运算的、逻辑性较强的问题，原型法很难构造出模型来供人评价。 • 对于基础管理不善、信息处理过程混乱的问题，使用有一定的困难。 • 对于一个批处理系统，其大部分是内容处理过程，这时用原型方法有一定的困难。

10. 原型方法是在信息系统研制过程中的一种简单的模拟方法，与人们不经分析直接编程时代以及结构化系统开发时代相比，它是人类认识信息系统开发规律道路上的“否定之否定”。它站在前者的基础之上，借助于新一代的软件工具，螺旋式地上升到了一个新的更高的起点；它“扬弃”了结构化系统开发方法的某些繁琐细节，继承了其合理的内核，是对结构化开发方法的发展和补充。这种相互补充、相互促进的系统开发方式将会是今后若干年信息系统或软件工程中所使用的主要方法。原型方法是在信息系统研制过程中的一种简单的模拟方法，与人们不经分析直接编程时代以及结构化系统开发时代相比，它是人类认识信息系统开发规律道路上的“否定之否定”。它站在前者的基础之上，借助于新一代的软件工具，螺旋式地上升到了一个新的更高的起点；它“扬弃”了结构化系统开发方法的某些繁琐细节，继承了其合理的内核，是对结构化开发方法的发展和补充。这种相互补充、相互促进的系统开发方式将会是今后若干年信息系统或软件工程中所使用的主要方法。

11. 11.2 增长原型法 • 11.2.1 抛弃原型法 • 建立这种原型系统的目的，是评价目标系统的某个（或某些）特性，以便更准确地确定需求，或者更严格地验证设计方案。使用完之后就把这种原型系统抛弃掉，然后再重新建立正式的目标系统。这种途径本质上仍属于传统的瀑布模型（Waterfall Model），建立原型只不过是一种辅助性的步骤。 • 11.2.2 演化原型法 • 经过初步调研和分析获知用户的基本需求之后，就利用适当的软件工具（如4GL）快速地实现一个原型系统，作为沟通各方的基础和用户实践的场所，开发人员根据用户试用后的意见，对原型进行修改和扩充，然后再次交给用户试用，并根据试用后提出的意见，再次对原型进行修改和扩充，这样，经过多次迭代直到用户满意为止。

12. 11.2.3 增长原型法 • 把系统划分为若干个子系统。选择其中一个作为首期工程，用演化原型法开发这个子系统；再选择另一个与之相关的子系统作为二期工程，在首期过程开发的子系统的基础上，用演化原型法增加二期工程的子系统需要的信息与功能，并把它们集成为一个整体；这样一期期地推进，直到完成整个系统的开发。 • 可见，增长原型法先要把系统开发划分为若干期工程，每期工程从首轮开始，有要有若干轮的演进。每期内采用的是螺旋模型，一期期向前推进则形成渐增模型。

13. 螺旋模型的原型开发方法如图11.2所示。 图11.2 螺旋模型的原型开发过程

14. 按照螺旋模型，整个系统（软件）开发项目始于螺旋中心，然后绕着中心做360°的旋转，每旋转一周便得到一个原型版本，对整个系统而言则是开发过程中的一个步骤。这种不断的旋转可以大量节省开发和维护的时间和费用，因为下一个版本总是在上一个版本的基础上加上改进和维护的结果。这种通过不断地螺旋式旋转、反馈、修改与完善来完成最终版本的途径，正是4GL与螺旋式应用开发系统的目标。按照螺旋模型，整个系统（软件）开发项目始于螺旋中心，然后绕着中心做360°的旋转，每旋转一周便得到一个原型版本，对整个系统而言则是开发过程中的一个步骤。这种不断的旋转可以大量节省开发和维护的时间和费用，因为下一个版本总是在上一个版本的基础上加上改进和维护的结果。这种通过不断地螺旋式旋转、反馈、修改与完善来完成最终版本的途径，正是4GL与螺旋式应用开发系统的目标。

15. 使用渐增模型开发系统的过程如下： • ● 完成一部分分析工作； • ● 完成一部分设计工作； • ● 完成一部分程序设计工作； • ● 建造系统原型并评价； • ● 对另一部分重复上述过程。

16. 11.3 快速原型法的开发工具 • 建立原型的计算机辅助软件工程（CASE）工具除了RDBS外主要有： • ● 屏幕绘图程序（屏幕生成器） • ● 报告生成程序（报表生成器） • ● 菜单建立程序（菜单生成器） • ● 第四代程序生成语言（4GL） • ● 可执行的规格说明语言

17. 4GL可以用来开发更为完整的系统模型，在这种情况下，原型包括了系统的主要功能，但不检查例外情况或无效的输入数据，也不考虑执行的性能，其目的是通过使用相对完整的原型，让用户具有使用该系统的经验。4GL可以用来开发更为完整的系统模型，在这种情况下，原型包括了系统的主要功能，但不检查例外情况或无效的输入数据，也不考虑执行的性能，其目的是通过使用相对完整的原型，让用户具有使用该系统的经验。 • 可执行的规格说明语言是最复杂的原型建立工具，它把系统开发变成一个迭代过程，在这个过程中，系统得到描述，执行该规格说明能够判断系统是否完整与正确。然后，根据使用这个原型的经验对规格说明重新定义后再重新执行。迭代过程就这样继续下去，直到系统满足了所有的用户需求。 • 现在的应用中，尤其是在C/S模式MIS的开发与研制中，一般是先快速地建立一个图形用户接口（GUI），作为系统的初始原型，通过用户的不断反馈、反复与累增、逐步地建立起符合用户需求的新MIS。

18. 11.3.1 可视化 • 科学计算可视化（Visualization in Scientific Computing）是运用计算机图形学和图象处理技术，将科学计算过程中产生的数据及计算结果转换为图形或图象在屏幕上显示出来。它不仅包括科学计算数据可视化，而且包括工程计算数据的可视化；同时也包括测量数据的可视化. • 程序设计可视化（Visual Programming）是指用图表、随手画的素描、图标或图象等可视表达式来编制程序。运用这类可视表达式时所用的技术手段有以下三项： • “点击”：例如，Windows中点File菜单，File的下拉菜单项。

19. “剪贴” （Cut and Paste）或“抄贴” （Copy and Paste）： “剪贴”，例如，Windows中剪一个图标，再把这个图标粘贴于另一处； “抄贴”，就是抄录板（Clipboard）的操作。 • “拖放”（Drag and Drop）：例如，Windows中把一幅图从屏幕的一边拖到另一边。 • 一个程序设计语言的语法若用到这种可视表达方式，这个语言就叫可视程序设计语言（Visual Programming Language，VPL）。一个可视程序设计环境（Visual Programming Environment，VPE）提供可视的方法来使用一种语言，不管这个语言是可视的，还是文字的。

20. 不少可视技术已被吸收到一些支持文字程序语言的VPE之中，而且跟着也用于不少可视技术已被吸收到一些支持文字程序语言的VPE之中，而且跟着也用于 • GUI程序设计； • 图象描述关系和数据结构行为； • 可视地把文字编程而得到的各部分，组建成新的程序。 • Microsoft的Windows就是GUI程序设计的最有名和最有用的例子。

21. 11.3.2 速成化 • 速成应用开发（Rapid Application Development，RAD），简称为速成化，是从联合应用程序设计（Joint Application Design，JAD）演变而来的： • 做到JAD原来要求的把用户需求快速明确提出来 • CASE工具 • 原型技术 • 一支能突击完成任务的队伍 • 有一套能快速实现用户要求的形式化软件研制方法，包括可视程序设计方法和技术。 • RAD的实际做法是：在初步掌握用户要求后，立即实现（建库与编程，目前的做法是可视建库与编程）。在此过程中，反复分析与设计是通过与用户共同参与来完成的。

22. 目前推行的RAD实际上有两方面内容： • 联合应用程序设计（JAD）， • 速成迭代原型法（Rapid Iterative Prototyping，RIP）。 • 这两方面结合使用，表示RAD是面向用户的。JAD讨论和RIP结合使用的目的，是使用户在整个研制周期中成为积极的参与者，从而保证系统符合所有要求。JAD的反复讨论缩短需求分析与设计的进行过程，而RIP会加速编程过程。这同时表示具有JAD和RIP两方面的RAD实际上包含分析、设计与实现（编程）三阶段，不过在RAD下整个的开发周期缩短了。 • RAD往往是可视的，它最拿手的一招是一套可视程序设计工具，能快速建成合格的图象用户接口（GUI）。从RAD发展到现有阶段来看，需要弄清它做得好或甚至很好的是哪些，哪些做得不好或者不能做。

23. 11.3.3 组件化(Components ) • 组件软件基本思路是，系统的开发可以用现成的预制软件组件来组装。象硬件系统可用集成电路等元器件来“即插即用”（Plug and Play）组装一样，最后软件系统也能象硬件一样，用所需的一套软件组件“即插即用”组合起来。 • 复合文书是其特例，即以一个空文书为容器，把不同来源的组件组装在其中。 • 组件软件可以做到少编程序，而且能快速地把待制的应用搞出来。组件软件的好处可概括为：可重用、能交互操作、易于使用、有灵活性、可加工改造以及有规模的伸缩性。

24. 现行的组件可分为五种类型： • GUI组件（GUI Components）：它扩充研制工具，建立GUI的能力。 • 逻辑组件（Logic Components）：它提供非可视的计算能力、图象编辑等。 • 垂直组件（Vertical Components）：它对某一具体产业提供数据和逻辑，类似于小型应用。 • 容器组件（Container Components）：它提供一骨架，把各类定制的控件装填进去。 • 中间组件（Middleware Components）：它便于与网络、交易监督程序或DB的交互操作。 • 组件可在下列三种环境中使用: • 某一具体应用研制环境 • 一种应用的平台 • 一种对象标准

25. 目前的使用情况是应用开发环境占领先地位，大多数组件是属于Visual Basic/ActiveX之列。 • 组件软件（Compound Software）与复合文书（Compound Documents）：所谓文书中心，即编程以文书为中心，而不象以应用（例如，库存管理）为中心的程序设计。以文书为中心时，用户不是启动一个应用，然后打开文件，而是直接打开文书。实际上一个组件是一个预制的小型应用程序，组件软件与复合文书把不同的预制的小型应用程序集成在一起。因此说它是文书中心的，不是应用中心的。 • 组件软件与复合文书同时也是可视的，往往也是速成的。就目前组件工艺而言，组件的来源有三： • 装配组件的研制工具都能提供组件框架。 • 专门制造组件框架的软件厂商。 • 用户自制组件。

26. 11.4 原型法系统开发实例 • 本节以数据库（DB）设计为中心，使用Visual FoxPro（VFP）6.0，对某商业企业以其仓库的进、销、存信息系统为第一期工程，讨论用原型法开发首轮原型的具体过程。 • 这里把系统分析与设计做得比较规范，叙述也是直线推进，是为使学生把握全貌。原型法的各轮开发都是只要做概略分析与设计就动手实现，并且是不断反复而非直线推进的。

27. 11.4.1 系统首轮概要分析 • 概述：仓库进、销、存（进货、销售、存储）管理是商业企业经营管理中的核心环节，也是一个企业能否取得效益的关键。建立仓库进、销、存信息系统的目的是使企业能做到合理进货、及时销售、库存量最小、周转灵活、没有积压，使企业取得最好的经济效益。 • 一. 需求初步分析 • 1. 组织结构概况 • 通过调查研究，得出该商业企业的组织机构图如图11.3所示，图中只简单地给出与仓库进、销、存业务相关部分的结构层次图。供应部负责进货业务；销售部负责销售业务；仓储部下有三个仓库，负责存储各类商品。

28. 总经理办公室 人 事 部 销售部 仓储部 财会部 供应部 仓库 1 仓库 2 仓库3 图11.3 某商业企业仓库的进、销、存组织机构图

29. 2. 业务流程概况 • 业务流程分析简述如下： • J. 进货管理 • 接受供应部门交来的进货单，审查，有错退回，无错则与已到货物核对，单物不符则退回，相符则把货物入库，在库存台帐各相关帐页中登入进货栏并修改库存栏。 • P. 盘存管理 • 接受仓储部门交来的盘存通知，审查，有错退回，无错则依库存台帐盘点货物，填写盘存明细表，按处理意见，登记库存台帐相应货物页，对使现存量少于最小存量者，登记进货要求单，交供应部门。

30. T. 提货管理 • 接受销售部门交来的订货单，审查，有错退回，无错则与库存台帐核对，缺货项填缺货单交销售部门，并登记进货要求单交供应部门；有货项则填入提货单，交经办人提货，并登记库存台帐相应货物页的提货栏，修改其库存栏；当现存量少于最小存量时，登记进货要求单交供应部门。 • 从系统业务流程分析可得到系统的业务流程图如图11.4所示。（见Word文档）

31. 3. 信息需求调查与分析 • 从业务流程图中找出相关单证、票据、帐簿、报表、文档等原始资料，从中抽出反映信息需求的相关事项。下面以本系统中最有代表性的库存台帐为例（图11.5）。 • 为节省篇幅，其它单证帐表，如进货单、提货单、盘存明细表、仓库月报表等就不一一列举。 • 从原始资料中抽出各栏目名称等系统要保存使用的相关事项，去掉组合项、导出项、泛指项得到基本项（不能在系统内生成、来自外部的项），就是要组织数据库基表中的信息。列举如下： • 货号，货名，型号，规格，计量单位；部门号，部门名，部门类型，位置，电话； • 员工号，姓名，性别，生日，职务，住址，电话；客户号，客户名，地址，信誉度，联系人，邮编，电话；

32. 供应商号，户名，信誉度，联系人，邮编，电话；货物所存库号，库存价，期初存量，现存量，最低存量，最高存量，采购批量；供应商号，户名，信誉度，联系人，邮编，电话；货物所存库号，库存价，期初存量，现存量，最低存量，最高存量，采购批量； • 员工所属部门号，聘用日期；部门主管工号，任职日期； • 提货单号，日期，时间，经手员工号，提货客户号，所提货号，售价，提货数量； • 进货单号，日期，时间，经手员工号，进供供应商号，所进货号，进价，供应数量； • 盘存单号，日期，盘存库号，清点员，对帐员，审查员，所盘货号，实存量，处理意见。

33. 库存台帐 • 封面 • 库号 库名 位置 电话号 主管姓名 管理人员登记表 记帐期间： 年 月 日至 年 月 日

34. 帐页 • 摘要常为：“XXX客户用XXX号提单提货”等 • 图11.5 库存台帐格式示意图

35. 仓库进销存MIS 提货 进货 盘存 图11.6 进销存信息系统现状功能层次简图 • 4. 处理功能现状调查分析 • 在以数据库为中心的原型法中，按业务流程图划分功能，通常只要展开一两层就可以了。本例划分为进货、提货、盘存3个子系统，功能层次图如图11.6。

36. 二、 数据库初始概念设计 • 由系统的基本数据项，按照由基本项构思E-R图的四条原则，并根据系统的基本功能要求，导出三个初始局部E-R子图，并改进，然后综合成系统全局E-R草图，再经过优化，消除重复的实体与重复的联系；引进所需的联系体，把多元联系转换为多个二元联系，最终得到系统的全局E-R图。 • 1. 初始局部E-R图的构思 • 规定一个库管员只在一个仓库工作，一个仓库可以有多个库管员；一种货物只能存放在一个仓库，一个仓库可以存放多种货物；每次盘存只有一个清点员、一个记帐员、一个审核员。由基本数据项，得到提货、进货、盘存三个子E-R图如下图11.7（实体的属性未列出）：

37. *工号 员 工 父子类 父子类 销售员 库管员 N K 日期 *客户号 时间 M 提货 客 户 售价 数量 *货号 L 货 物 提货子ERD

38. *工号 员 工 父子类 父子类 采购员 库管员 N K 日期 *商号 时间 M 进货 供应商 进价 数量 *货号 L 货 物 进货子ERD

39. *工号 员 工 父子类 父子类 父子类 父子类 库管员 清点员 对帐员 审查员 N K M J 日期 管理 实存 盘存 盈亏量 处理意见 1 M *货号 L 仓 库 货 物 1 M *库号 存放 现存量 盘存子ERD 现存价

40. 2. 初始局部E-R图的改进 • 从图11.7按从ERD导出一般关系的四条原则，多对多提货联系得到提货关系框架（图11.8）。 • 提货关系 从提货关系中可以发现两个问题，一是复合主码太复杂，不便于查询；二是非码属性售价、数量函数依赖于(日期,时间,客户号,货号)，对主码是部分函数依赖，因此，提货关系模式不是3NF。当客户一次提取多种货物时，日期、时间、客户号、销售员工号、库管员工号必定多次重复。

41. 究其原因是：当考虑多次提货时，客户、经手员工、货物之间是多对多联系；但是当考虑客户的一次提货（提取多种货物时）与经手员工、客户之间是对一的联系，而与货物依然是对多联系。究其原因是：当考虑多次提货时，客户、经手员工、货物之间是多对多联系；但是当考虑客户的一次提货（提取多种货物时）与经手员工、客户之间是对一的联系，而与货物依然是对多联系。 • 解决的方法是在提货E-R子图中引进联系虚体（简称联系体）提货单。它描述的是提货联系，本质上不是实体，只是为了化简提货这个复杂的多元联系而引进的一个中间替身。借用了业务人员熟习的名字－－提货单，但与日常业务中的提货单在组成结构与内容上都相差甚远。从而把提货转化为员工与提货单之间的经手联系（一对多）、客户与提货单之间的购买联系（一对多）、提货单与货物之间的所提联系（多对多）等三个二元联系。 • 引进联系体后的提货E-R子图如图11.9。

42. *工号 员 工 父子类 父子类 销售员 库管员 1 1 出售 经手 *提货单号 购买 M K *客户号 日期 客 户 提货单 N 1 时间 M 摘要 售价 所提 数量 *货号 L 货 物 提货子ERD

43. 提货单关系 (出售联系) (购买联系) (经手联系) • 引进类型体后，提货联系在引进联系体提货单后，导出提货单关系、所提货关系如下： *时间是为把同日同客户同经手人的提货区分开，引进提单号后就可省去 所提货关系

44. 对进货联系作同样的处理，可以得到完全类似的改进后的进货ERD。盘存联系也可以作类似的考虑，不过得到的改进后的盘存ERD要复杂一些，请同学们参考教材上的图11.11，按这里所作的修改，画出改进后的盘存ERD。对进货联系作同样的处理，可以得到完全类似的改进后的进货ERD。盘存联系也可以作类似的考虑，不过得到的改进后的盘存ERD要复杂一些，请同学们参考教材上的图11.11，按这里所作的修改，画出改进后的盘存ERD。 • 3. 综合成全局E-R图 • 把各子业务的ERD，以共有实体为铰链，集成起来，就得到全局ERD初稿；再消除冗余的联系、实体与属性，归并相关实体成父类实体，就可以对其改进。员工实体与人事管理共享，在人事管理中员工与部门联系，而仓库是仓储部属下的子部门，所以在全局E-R图中应引入部门实体。供应商与作为购买商的客户是属性相同的实体，可以看成是客户实体的两个子类。请参考教材图11.12的全局E-R图，按这里所作的修改，画出其全局ERD基本结构。

45. 对全局ERD中的多对多的多元联系引进联系体，参考改进后的各子ERD，可以得到改进后的全局ERD。对本案例，请同学们对照教材上的图11.13，按这里所作的修改，画出改进后的全局ERD基本结构。对全局ERD中的多对多的多元联系引进联系体，参考改进后的各子ERD，可以得到改进后的全局ERD。对本案例，请同学们对照教材上的图11.13，按这里所作的修改，画出改进后的全局ERD基本结构。 • 三、 数据存储组织的初步考虑 • 依据四条原则从全局ERD导出一般关系框架，作为数据存储组织的初步考虑，可以检验ERD的构思是否规范，可为以数据库为中心进行业务流程再造提供依据。本例从引进联系体的ER图（图11.13）导出系统的10个一般关系模型（二维表）如图11.14。这些关系模式都是3NF或BCNF，可见该ERD的规范化程度是满足基本结构要求的。请同学们按这里所作的修改，对这些关系框架作补充改进。

46. 四、 以数据库为中心的进销存业务流程再造 • 假设用原型法开发仓库进销存业务系统为起点系统，其它相关业务都还是手工作业，它们与本系统的信息交换还是用纸介质。为相关业务计算机化并联网后系统集成需要，本系统所有接收送出的票据帐表都存入临时文件；当然，系统渐进集成时要从更大范围考虑数据库重构和业务流程再造。 • 作为以数据库设计为中心的原型法起点的业务系统开发中的业务流程再造，很难完全着眼于企业经营链的全局，只能尽可能考虑全局，重点放在本系统业务的降低成本和提高收益上。本案例主要考虑三个方面：一是以数据库为中心，尽可能用计算机处理业务，集成业务流程，减少业务环节，提高效率与质量；二是及时向相关部门公布进销存明细和统计分析结果，以便及时进货，适时销售，合理库存，提高效益；三是建立并及时改进市场模型和库存模型，提高其运行频率，有效控制进货和库存，提高资金运用效率，创造经济效益。

47. 为了尽快研制出实用原型，首轮主要考虑第一方面，适当兼顾第二方面。人工流程有些环节是隐含模糊的，计算机处理流程则不能这样。下面是再造的进货管理、提货管理、盘存管理、统计分析等业务流程。为了尽快研制出实用原型，首轮主要考虑第一方面，适当兼顾第二方面。人工流程有些环节是隐含模糊的，计算机处理流程则不能这样。下面是再造的进货管理、提货管理、盘存管理、统计分析等业务流程。 • J. 进货管理 • 接受供应部门提供的进货单，人工审查，有错退回。无错则加上实到货量栏，输入进货临时文件，按进单户名查客户关系，找到则把客户号填入进货临时文件，否则人机结合在临时文件中确定客户号，把新客户信息登录到客户关系。从进货临时文件打印出相应的进货单，核对所到货，货单不符合记录实到货量，打印有错进货表，交供应部门；相符的则入库并登记到进货单关系及所进货关系，若是新货则登记货物信息到货物关系，否则只修改货物关系中的现存量和库存价。

48. P. 盘存管理 • 仓储部门按计划编制盘存通知，人工审查，有错修改，无错则输入盘存临时文件。从货物关系按盘存通知中库号查找相应的货物记录，加上清点工号、对帐工号、审查工号、实存量、盘盈量、处理意见等空白字段，组成盘存明细记录到盘存临时文件中，打印出盘存单及其盘存明细表，据此盘点库存，记录上述空白字段的值，输入到盘存临时文件中并打印盘存结果。依据盘存临时文件登记盘存单关系及所盘货物关系；按实存量和处理意见修改货物关系中的现存量。若修改后的现存量低于最小存量，则调用“进货要求生成”，生成进货要求记录，存入进货要求临时文件，定期打印进货要求单交供应部门。

49. T. 提货管理 • 接受销售部门订货单，人工审查，有错退回，无错则输入订货临时文件。按订单户名查客户关系，找到则把客户号填入进货临时文件，否则人机结合在临时文件中确定客户号，把新客户信息登录到客户关系。与货物关系核对，若是新货，则把现存量为0的新货记录登记到货物关系；把（订货数量—货物关系中的现存量）登记到订货临时文件中的缺货量字段中。缺货量>0的为缺货项，登记到缺货临时文件，打印出缺货单交销售部门，并调用进货要求生成，登记进货要求记录到进货要求临时文件。有货的订货项目则登记到提货单关系及所提货物关系，打印出提货单，交仓管员发货，并登记经手工号，输入提货单关系。按（现存量=现存量—提货数量）修改货物关系的现存量，若改后现存量低于最小存量则调用进货要求生成，生成进货要求记录，存入进货要求临时文件。定期打印进货要求单交供应部门。

50. F. 统计分析 • 可以通过统计分析编制多种图表，支持相关决策。这里仅考虑进销存明细帐、月报表，盘存明细表，进货统计表，提货统计表，库存金额降序排列的前20%种(即A类)货物的库存金额与提货金额对比直方图等。 • 在课件Word文档中给出给出新的业务流程图，请同学们注意对输入的校验等方面与人工流程的重要差别。 • 五、系统首轮实现的功能分析 • 系统首期除了要实现进货管理、盘存管理、提货管理、统计分析等基本业务，还要实现系统初始化、查询等常规功能。对系统本身的管理维护功能是常规的，原型法首期往往也不急于实现，这里不讨论。本例系统首期功能层次图如图11.16。