第 5 章 IRP 技术 | 您所在的位置:网站首页 › 信息系统的模型分为 › 第 5 章 IRP 技术 |
# 第 5 章 IRP 技术— 系统建模 企业信息资源规划的主要成果就是建立起全企业集成化的信息系统模型— 功能模型、数据模型和系统体系结构模型。需求分析是系统建模的准备,系统建模是需求分析的继续和“定型”。 # 5.1 引言:系统建模在 IRP 中的地位认真研究、准确定义信息系统的目标,-般要涉及这样几个方面: 企业管理目标是什么; 信息系统如何支持企业管理目标; 信息 系统的用户类型划分及如何为他们服务; 信息系统的特征,等。 example: 与需求分析紧密相联的系统建模工作,主要包括信息系统的三种模型的建立: (1)系统功能建模要确定所规划的系统应该具有哪些功能,即全局地、自顶向下地看,系统应该做什么,能做什么,这就是功能建模的目的。 功能建模的主要工作是: 了解企业领导关于管理体制和管理机制方面的意见,掌握已有的有关管理模式的研究成果; 在业务领导参与复查职能域和业务过程定义、与规划分析人员取得共识所形成的规范化功能需求文档的基础上,由规划分析人员进行计算机处理的可行性研究,提出可自动化处理与人机交互完成的模块; 选取已经开发和使用的应用系统中的有用程序模块; 如有可能,借鉴同类系统的有关模块。 将这几方面工作综合起来,以各功能模块的识别和定义为主要工作,提出规划系统的功能模型初稿一系统由 哪些子系统、功能模块、程序模块所构成。 (2)系统数据建模是确定规划的系统应该有哪些业务主题数据库,即各功能模块的运作是在什么数据的支持下进行的,这些数据组织到基本表的层次应具有什么样的结构。这就是数据建模的目的。 数据建模的主要工作是: 在业务领导参与复查用户视图和数据流分析资料、与规划分析人员取得共识的基础上,业务领导根据管理经验规划分析人员根据用户视图分组,提出概念的主题数据库(数据库名称及内容列表),经过讨论和全局协调,再由规划分析人员将每一概念数据库规范化到 3-NF 的一组基本表; 在全域数据实体对象的识别和分类的基础上,进行 E-R 分析;选取已经开发和使用的应用系统中有用的基本表结构; 如有可能,借鉴同类系统的有关基本表结构。将这几方面工作综合起来,以主题数据库和其基本表的识别、定义为主要工作,提出规划系统的数据模型初稿一系统有哪些主题数据库、每个主题数据库有哪些基本表,以及它们之间的联系。 (3)系统体系结构建模识别定义每一主题数据库/ 基本表被功能模块存取的关系,从而形成各系统和全域的 C-U 矩阵,这是科学地制定总体网络计算机配置方案、数据分布策略和项目进度计的根据,同时,也是系统共享数据库的创建、维护和使用等责任的规定依据。 系统建模是由各职能域规划小组和核心小组联合进行的深入分析研究工作过程,需要有统的、科学的方法和规范,还要注意加强指导、控制与协调。规划核心小组要充分发挥作用,注意好以下经过实践证明是十分有效的“三控制”和“三协调"工作。 三控制: (1)控制规模。系统的目标和边界应该是有限的,界定后不要在建模过程中不适当地膨胀。 (2)控制细化程度。不论功能模型还是数据模型要做到概念层和部分逻辑层,分解与细化要适当,不能与系统的逻辑设计相混淆,处理好分解与集结、粗与细的关系。 (3)控制一致性。认真执行统一的规范和标准,凡不符合规范和标准的要及时纠正;规范和标准有问题要认真研究、统一解决。 三协调: (1)协调部门与整体的信息利益,克服信息私有和自采自用的倾向,追求信息共享和全局信息资源优化管理。 (2)协调业务管理人员与信息技术人员的关系,注意调动和保护两类人员的积极性,引导和鼓励相互学习、相互尊重、加强讨论、扬长避短。 (3)协调个人与集体、小组与大组之间的关系,既要提倡发挥每个规划分析人员、每个小组的知识经验和创造精神,又要强调群体意识和发挥集体智慧,把建模过程作为共同学习和提高的过程。 # 5.3 系统功能建模系统功能建模就是要解决“系统做什么”的问题。经过功能需求分析所得出的业务模 型,在很大程度上是当前业务流程的反映。 # 5.3.1 功能模型的概念和表示法系统的功能模型(Function Model)是对规划系统功能结构的概括性表示,采用“子系统 一功能模块 一程序模块”的层次结构来描述。 由业务模型研制出功能模型的主要分析工作是对业务过程和业务活动作计算机化的可 行性分析。业务模型是对现行系统功能的概括性认识,功能模型是对新系统功能的概括性 认识,两者大体存在如下的对应关系: 注意 : 这决不是一种简单的对应关系。因为,除了规划人员在调研阶段和建模阶段的认识有 所不同而导致两个模型的关健成分、相互关系和内部逻辑顺序有所不同之外,更重要的是 功能模型的研制要进行更为深入的分析研究工作,其中包括运用计算机与信息系统的若干 专业知识 对业务过程和活动进行计算机化可行性分析,是指识别和区分: 哪些业务过程、业务活动可以由计算机自动进行(A 类); 哪些可以人一机交互进行(I 类); 哪些仍然需要由人工完成(M 类)。 这样一来,功能模型的建立就需要改造那些人工活动部分,并对某些过程或活动进行必要的分解与综合,包括重新设计。 # 5.3.3 功能建模过程 # 1.定义子系统子系统的目标是什么,即需要对系统总体目标进行分解,作更具体的界定; 说明子系统的边界,即覆盖哪个职能域或跨职能域,为哪个管理层次或跨管理层服务 ; 确定信息加工处理深度或信息系统类型— 事务处理 (TPS)、管理信息系统(MIS )、联机实时处理分析(OLTP/OLAP)、决策支持系统(DSS)、主管信息系统(EIS )、战略信息系统(SIS)等; 列出子系统的主要功能,注意运用“关键成功因素”和“价值流”分析思想,在业务过程计算机化可行性分析的基础上加以识别。 # 2.定义功能模块和程序模块总结 将业务过程和业务互动转换成系统中可操作性的系统模块功能名称。 怎样由功能模块体现子系统的目标?即对子系统的目标进行分解,落实到具体的功能模块上; 说明功能模块的边界,即它属于哪个职能域或跨职能域,为哪个管理层次或跨管理层服务 ; 信息加工处理深度或模块类型— 属于事务处理、信息形成模块,还是属于实时处理分析(OLTP/OLAP)或更为高层的(DSS/EIS/SIS)模块; 突出关键性功能模块(或反映主业的功能模块),这要借助“关键成功因素”和“价值流”分析来识别; 通过分解与集结的权衡 ,确定功能模块一程序模块的层次关系,分解要注意控制细化程度,集结要注意控制综合程度; 分析选取已经开发和使用的有用模块,如果可能,分析选取类似系统的有用模块 ; 每一功能模块需要用短文加以描述,而程序模块则不必描述。 例子 137 页 在核心小组研究的基础上,召开全体规划组讨论会 ,交叉讨论提出修订稿。交叉讨论 的要点是 : 跨管理层次、跨业务部门的子系统和功能模块有无问题; 关键功能模块的认定(在相应的子系统说明中描述); 共用或类似程序模块的认定(在相应的功能模块说明中描述); 去除冗余模块。经过交叉讨论和修订,应及时提交给中高层业务负责人进行复查认定。复查要点是: 子系统划分定义的准确性; 关键功能模块识别定义的准确性; 跨管理层次、跨业务部门的子系统和功能模块对建立信息管理制度的影响和对策; 对意见不易统一的部分提出原型研究的要求。 # 5.3.4 功能建模的资源与功能模型的运用(1)认真做好需求分析资料的复查工作,与功能建模直接相关的包括业务分析结果 (即业务模型,重点是职能域和业务过程的定义)的复查和数据流程图(一、二级数据流程 图相匹配,并与业务模型相一致)的复查。复查工作决不能仅限于在系统分析员和业务代 表中进行,一定要使业务部门负责人参与复查工作,形成共识。 (2)经过复查确认的业务过程和业务活动,再经过计算机化可行性分析,将有相当多 的部分被选人系统功能模型(见图 5.3 中间部分及其左向箭头)。 (3)企业已有应用系统行之有效的功能模块或程序模块应予以继承,还有其他应用软 件的有用模块也应该吸收,这些模块也被加进系统功能模型(见图 5.3 右边部分及其左向 箭头)。 需要着重说明的是,功能建模拟定的子系统是“逻辑子系统”(面向规划、设计人员), 而不是“物理子系统”(面向最终用户) 只要企业的生产经营方向不变,企业基本的职能域是相对不变的, 基于职能域的业务过程和数据分析可以定义相对稳定的功能模块和程序模块,这样建立起 系统的功能模型是能对机构管理变化有一定的适应性的。 # 5.4 系统数据建模系统数据建模就是要解决系统的“信息组织”问题。这是信息资源规划的核心部分,是数据环境重建的根本保障。
第 141 页 表(Table)是数据分析工作中经常用到的概念,它是一组有联系的数据的抽象。数据 分析工作经常需要列出一个表所含的数据元素或数据项,而不具体考察每一行的数据项 的值。 # 3.基本表基本表(Base Table)是由企业管理工作所需要的基础数据所组成的表,而其他数据则 是在这些数据的基础之上衍生出来的,它们组成的表是非基本表。基本表可以代表一个实 体,也可以代表一个关系,基本表中的数据项就是实体或关系的属性。基本表应该具有一 些基本特性 : 原子性,即表中的数据项是数据元素; 演绎性,即可由表中的数据生成系统全部的输出数据; 稳定性,即表的结构不变,表中的数据一处一次输人,多处多次使用,长期保存 ; 规范性,即表中的数据关系满足三范式(3-NF) ; 客观性,即表中的数据是客观存在的数据,是管理工作需要的数据,不是主观臆造的数据。 # 4. E- R 图数据模型(Data Model)是对用户信息需求的科学反映,是规划系统的信息组织框架结构。 数据模型分为: 全域数据模型— 全企业(整个集成系统)的所有主题数据库及其基本表; 子系统数据模型— 某个子系统所涉及的主题数据库及其基本表。 # 2.概念数据模型概念数据库(Conceptual Database)是最终用户对数据存储的看法,反映了用户的综合 性信息需求。 概念数据库一般用数据库名称及其内容(简单数据项或复合数据项)的列表来表达。 采用“离散集表达法”,每个概念的主题数据库有如下的表达形式: 数据库名称(数据内容列表……) 注意 : 不要以为上面列出的五个概念的主题数据库(它们构成了工程管理系统的概念数据模 型),是简单的事情。事实上,如何使规划组成员与业务领导达成共识,对工程管理的业 务主题能有如此高度的抽象认识,是一种相当复杂的认识过程。我们是经过多次讨论(甚 至是激烈的争论),几经修改,才有如此“简单”的表述。 # 3.逻辑数据模型 # 5.4.3 数据建模方法 # 1.数据建模的基础资料我们是在规范化需求分析的基础上进行数据建模的,这时我们已有的调研资料是: 各个职能域的用户视图及其组成 各个职能域的数据流程图(1 一 DFD, 2-DFD) 各个职能域的输入数据流、输出数据流和数据存储分析报告 全域的数据元素集 全域的数据元素 一用户视图分布分析报告,等我们是在计算机内建立了这些资料的规划元库(PR),它不仅比一般的数据字典有更 丰富的内容,而且可方便地检索使用和自动化处理,可以有效地用于数据建模(详见第 6 章) # 2.数据建模的基本工作和步骤数据建模的基本工作是: 识别定义业务主题,按主题将用户视图分组定义为实体大组,提出概念数据模型 按业务需要进一步分析实体的属性,规范化数据结构产生基本表,提出逻辑数据模型 数据元素规范化,进一步审核基本表的组成为了实现系统开发的高质量、高速度和高效益的目标,我们提出了企业组织信息资源 规划工作的几项要则 : (1)组成业务代表和系统分析员相结合的联合规划组,强调两类人员密切合作,互相 学习,通过调查和讨论进行需求分析。 (2)综合利用信息工程的理论和实践经验,采用业务代表与系统分析员都能掌握的科 学、简单和实用的分析、建模方法和文档规范。 (3)对已有的调研资料进行去伪存真、删繁就简的分析,提取合理部分重新规范表 述,根据实际情况做补充调查。 (4)借鉴原有系统、国内外较成功的经验资料,结合实际吸收有关部分,用于需求分 析与系统建模。 (5)采取实用的 I- CASE 工具,以规划元库(PR)为中心机理,形成规范化的机内文 档,系统地支持需求分析、系统建模和应用设计,使规划工作顺利与后续开发相衔接。 只有建立起全企业的信息资源 管理基础标准、总体功能模型和数据模型,才能处理好现有应用系统整合 、先进软件引进 和新系统开发之间的关系。 |
今日新闻 |
推荐新闻 |
专题文章 |
CopyRight 2018-2019 实验室设备网 版权所有 |