美文网首页
大话软件工程:需求分析与软件设计(十一)

大话软件工程:需求分析与软件设计(十一)

作者: 谢阿乞 | 来源:发表于2021-12-11 16:05 被阅读0次

    第11章 数据的概要设计

            数据的概要设计,是概要设计阶段的第三层,它是对数据层的内容进行整体规划、定义,为后续功能、数据的相关设计规定范围、分类、标准。

    11.1 基本概念

    11.1.1 定义与作用

            1.定义

            数据的概要设计,是基于需求分析成果——既存表单、架构的概要设计成果——架构概要规格书、功能的概要设计成果——功能概要规格书等资料,对未来系统进行数据层面的整体规划和领域规划,同时制定相应的数据标准,最终形成数据概要规格书。架构层采用了业务架构图,因为架构图表达的是客户的业务逻辑关系,所以其内容是直观且容易理解的;功能层采用了原型表述,由于原型是可视和可操作的,所以也是易于理解的。与前两者相比较,数据层的表达就相对抽象、不直观,由于它既不能和业务场景直接相关既也无法用具象的原型来表达,所以数据只能从“数据”上去理解。数据是从架构拆分出功能,然后再从功能原型的“控件定义”的过程中产生出来的,数据的应用还需要利用架构和功能才能体现出来。

            2.作用

            从软件工程上数据的全过程看,数据的概要设计是基于需求工程的既存表单、概要设计的架构规划、功能规划结果进行的第一次数据设计,这个环节的作用就是根据设计理念、输入/输出的需求,以及未来企业发展对数据利用的要求,做出系统整体的数据规划,按照业务领域的数据规划,以及数据的标准和规范,为后面的详细设计奠定基础。

            数据的整体规划就如同功能的规划一样,这两者的异同如下。

            (1)功能规划:规划需要哪些产生数据的功能、数据产生的方式等。

            (2)数据规划:规划需要哪些数据、数据的用途、数据的形式、标准等。

            功能规划的目的是为数据服务的,因此两者的关系为:数据是目的,功能是工具。对功能不论如何进行周全的规划它的生命周期都是有限的,因为功能会随着外界需求的变化而变化(来自于用户功能需求的变化或是因为硬件技术的进步等),但是对数据则不同,企业希望数据的生命周期尽可能长,希望规划的结果可以让数据尽可能地不受外界因素(如功能、技术)的影响,或将影响控制到最小。数据是企业最重要的信息资产,数据的概要设计核心作用就是要为企业数据资产做出长久的规划和建立标准。

    11.1.2 内容与能力

            数据的概要设计主要内容分为两个部分:数据规划与数据标准。

     1.作业内容

            1)数据规划

            (1)按照系统划分——数据的整体规划。从系统的整体出发对系统所含的全部数据进行规划,包括:过程数据、基础数据、管理规则(数据)、外部数据、企业知识数据等。

            (2)按照业务划分——数据的领域规划。对系统数据进行整体划分后,再对整体划分中的每个业务领域的数据进行规划,例如:销售领域、生产领域、物流领域、财务领域等。

            2)数据标准

            建立系统的数据标准,包括主数据的标准、业务数据的标准(业务编号)。

            (1)主数据标准:建立统一的主数据标准,让系统中的数据实现共享、共用。

            (2)业务编号标准:建立规范化的业务编号体系,这也是建立统一主数据标准的一环。

    11.1.3 思路与理解

            1.数据设计的背景

            数据的来源都是由原始凭证、业务处理的记录等按照生产过程逐步地收集的,而不是按照决策者、管理者以及各类数据分析的格式记录的。企业不希望获得的数据随着业务流程、功能界面的变化而变化,如果要保持数据不受外界的影响,就需要在系统的设计之初就对建立数据体系给出约束条件,这样就可以避免在以后的使用过程中出现由于数据不规范而造成的信息孤岛现象。随着企业信息化的推进,数据采集系统在不断地改进、增加,而数据应用部分则希望不受变动的影响,保持长期稳定地使用数据。

            1)信息孤岛

            由于系统在构建的初期对数据层缺乏长远的、缜密的规划,没有预先进行数据的标准化工作,造成很多的企业在不间断地推进信息化建设后,发生了复数正在运行中的系统之间无法共享数据,也就是常说的“信息孤岛”问题,出现了有数据也无法利用的现象。改造它不仅是成本和时间的问题,而且是非常复杂的问题,因为互不相容的数据之间不但有数据格式问题,还有业务逻辑、管理规则甚至技术的问题存在,信息孤岛的现象一旦形成就难以从根本上得到解决,因为数据是由系统产生的,而系统标准的统一则是非常复杂且费力的工作,往往不如新建系统来的更快捷一些。但现实中又不可能简单地通过推倒旧系统重建新系统的方式来解决信息孤岛的问题,所以,在新建系统前充分地进行数据的规划、数据标准的建立是非常重要的且必不可少的设计工作。

            2)共享与复用

            未来企业的数据不但有一次使用(凭证、统计),还会有更多的二次、三次使用,本部门内部用、跨部门用甚至跨企业使用,因此数据的共享场景、复用场景要预先思考、规划,以向后续各类设计提出要求。对数据的第一次应用往往都是企业的日常业务处理工作,如各类月统计数据、报表等。

            而数据的第二次、第三次的应用才是可以为企业带来更多附加价值的应用。例如,各个不同的部门、系统之间对数据的共享与复用等。

            (1)数据的共享:数据只需要输入一次,就可以供给不同的部门、不同的系统使用,这样从整体上就提升了系统操作的效率,例如,财务系统可以使用生产系统输入的原始凭证数据,实现业务财务一体化作业,不但提升了作业效率,而且能够减少输入错误。

            (2)数据的复用:对已经积累的历史数据进行抽提、深度的加工后,可以作为下一轮业务处理的参考数据,例如,历史的材料采购价格,可以作为下一次采购的参考价格等,这样做不但可以控制成本,还可以减少未知的风险。

            2.数据的规划与标准

            数据是企业的数据资产,数据的有效积累会为客户解决旧问题并带来新的商机,在设计的三个层中,数据的生命周期是比架构和功能都要长的,因此在系统规划设计时,特别要对数据的规划给予重点的关注,数据的规划一定要在软件的设计和开发前进行。

            1)数据的规划

            作为企业的数据资产,首先要确定需要哪些数据、数据的分类、每个分类的用途、边界等,这个规划不但要考虑目前的用途,还需要考虑到未来可能的扩展。

            2)数据的标准

            建立统一的数据标准,如主数据、基础数据的编号规范等。如果完成系统内的数据标准不相同,在后期需要统一数据标准时就会发现,软件一点儿都不“软”,如同硬件一样难以修改,而且需要投入大量人力和时间,最终还不一定能够永久性地解决信息孤岛问题。

            3.由谁来规划数据和建立数据标准

            在软件企业中,有不少人认为数据层面的设计是技术设计师或是开发工程师的工作,其实不然,包括数据层面的工作在内,所有的设计层面的工作都应该从业务设计做起,因为不论什么设计成果都是为客户服务的,而最为接近客户也容易为客户所理解的是业务设计。业务层面与技术层面对数据的设计方法是不同的,技术层面的数据设计不能代替业务层面的数据设计,相反,没有很好的业务层面的数据设计做支持,技术层面的数据设计成果是不完善的,数据难以做到共享、复用。与技术层面的数据设计不同,业务层面重点做的不是数据“库”的设计,而是业务数据的逻辑设计,由于业务和技术的视角不同,数据关系图的表达内容和方式也不同。区别的关键点还是在于业务逻辑的有无。

            (1)业务视角的数据关系图:有业务流程,带有清晰的业务逻辑关系。

            (2)技术视角的数据关系图:用“键”的形式替代了业务逻辑的表达形式。

            只有从业务设计的视角,充分地理解业务数据的内容、用途、业务数据之间的逻辑关系,以及未来可能的变动规律等,才能支持技术的数据设计,可以保证不论业务如何变化数据的结构都能保持稳定。消除企业信息孤岛现象,首先是业务设计师要解决的问题,因为这个问题的本质不是数据库问题,也不是技术开发工程师单独能够解决的问题。

    11.2 数据分类

    11.2.1 数据的划分方法

    对于计算系统来说,数据就是记录、计算、展示的结果。数据的表达形式有很多种,常用的有数字、文字、图像、附件等形式。由于本书的重点是企业管理信息化,其主要的数据形式是数字和文字,图形、音像等大都是以附件的形式存入的,以下如果对数据类型没有特殊说明,则数据仅指数字型和文字型的数据。

            1.数据类型分类

            按照数据的类型,可以将全部业务数据分为两大部分:数字型数据、文字型数据。        

            1)数字型数据

            数字型数据,指的是直接可以进行运算的数据。这类数据因为是用“数值”来表现的,所以它是管理信息系统中数量最大、处理方法最为成熟的,如成本、资金、物资等。

            2)文字型数据

            文字型数据,指的是不能直接用来进行运算的数据。这类数据的内容大多用文字“叙述”,所以不适合利用管理信息系统进行直接的处理,如安全、质量、风险、满意度等数据,它们大都是文字输入、上传文档或是以扫描资料的形式存在的。

            计算机难以对不规范的文字型数据进行定性、定量的判断,如果计算机处理的对象不是数字型,就不能够真正地发挥出“计算”机的能力,特别是对企业管理信息系统来说。缺乏定性、定量的判断也就影响了处理结果的正确性、合理性和科学性。因此,如果要想有效地利用文字型部分的数据资源,就要对它们进行量化的处理,也就是将文字型的数据转换为数字型的数据。

            ①可数字化部分:通过设计、建模等方式建立转换关系,将文字型中的可数字化的部分转换为数字型数据,然后就可以采用运算的方法进行处理(判断:大小、多少、高低等)。

            ②不可数字化部分:不能转换为数字型的数据,只能采用文档保存、判断“有无”等简单的处理形式。

            在企业管理中,决策者、高层管理者非常关心的数据有很多都是文字型的数据,例如,企业经营过程中的风险、企业内控管理、紧急事故的应急方法、产品质量、生产安全等。如果能够将文字型数据转换为数据型数据,就可以为企业带来非常大的信息化价值。

            2.数据、数字与信息在数据层面进行设计时,要搞清楚几个与数据相关的概念,如数据与数字、数据与数值、数据与信息,以及数据与架构、功能之间的异同。

            1)数据与数字

            ● 数字,是10、100、300等。

            ● 数据包含数字,数据的形式可以是数字、文字、图形等。

            2)数据与信息

            ● 数据,是通过从功能界面录入而采集到的、客观存在的原始数值。

            ● 信息,是对采集到的原始数据进行加工后获取的具有特殊含义的数据。

    11.2.2 数据与业务功能的对应

            在企业管理信息系统中产生的业务数据,按照业务领域可以划分为:销售数据、财务数据、生产数据、物流数据等。这些数据从业务属性上看它们代表的是完全不同的意义,但是从管理信息系统的设计方法上看,它们是有共性的,找到共性就易于从设计的视角理解数据了(如同企业构成的分类、业务功能的分类一样)。为了方便系统的架构和设计,需要将这些数据带有的业务属性去掉,按照设计用途进行分类如下。

            1.数据用途分类

            (1)过程数据:系统在运行过程中采集到的第一手数据。

            (2)基础数据:在系统中被反复使用到的数据,在企业中必须被标准化固化下来的数据。

            (3)管理数据:对系统中运行的业务数据进行管理而设定的相关标准、规则。

            (4)其他数据:来源于企业内部其他系统或外部系统产生的数据等。

            (5)加工数据:对收集到的原始数据进行加工后(ETCL)而获得的数据,供查阅、分析用。

            这些数据中对系统的规划、架构、设计、标准的建立等起着最为重要影响的是过程数据和基础数据。

            2.分类的区别:过程数据与基础数据基础数据和过程数据的性质不同、产生方式不同、管理方式不同、使用方式也不同。

            1)数据来源

            (1)过程数据:来源于业务功能的“活动”,“过程”指的是业务处理的过程。

            (2)基础数据:来源于业务功能的“字典”,“基础”指的是企业运营的基础。

            2)数据区别

            (1)过程数据:记录的是生产过程中的行为数据,如销售、采购、支出/收入等。

            (2)基础数据:记录的是企业管理要标准化的数据,如客商、材料、产品、组织等。

            3)数据变化

            (1)过程数据:输入确定无误后,必须保持数据输入时的原始状态,不许变更(变更违法)。

            (2)基础数据:不同时间段输入的数据不同,数据必须定期维护、调整。

            4)数据使用

            (1)过程数据:除去第一次应用以外,还可对过程数据进行加工,进行二次、三次应用。

            (2)基础数据:辅助数据的输入,作为查询、抽提的分类属性等,基础数据不作为加工对象。

            5)数据转换

            (1)过程数据:在输入时基础数据被选择并记录到活动的数据表上,就变成了过程数据。

            (2)基础数据:过程数据中有参考价值的数据,被抽提出来经过加工后就成为基础数据。

    11.2.3 数据与软件工程的对应

            数据设计,就是按照设计的要求记录企业活动的行为,让数据经过不同的加工处理,从原始“数据”变为可以为客户提供有各类使用价值的“信息”。数据设计的过程包括三个阶段,即:数据的概要设计、数据的详细设计、数据的应用设计。

            它们各自的作用如下。

            (1)数据的概要设计:对数据进行全面规划,包括:区域划分、主数据、数据标准等。

            (2)数据的详细设计:对数据的关联方式、数据表关系、算式等逻辑进行细节的设计。

            (3)数据的应用设计:对概要和详细设计的成果,给出在系统实现时的方法(机制)。

            设计工程的每个阶段都被分成三个设计层(即工作分解:架构层、功能层和数据层),这三个设计层与数据的关系如下。

            (1)架构层:架构图是由功能要素构成的,因为架构图上的功能是以黑盒状态呈现的,所以在架构设计阶段,由于粒度的原因既看不到数据层,也不关注数据层面的内容。架构层虽然与数据层没有直接关系,但是架构层为数据层的设计提供了业务逻辑。

            (2)功能层:数据是由功能产生的(活动、字典),但在功能设计层面的重点是如何实现业务、管控等内容,此时关注的是功能内部的数据个体,而非某个领域的数据整体。

            (3)数据层:在数据层,数据来源于什么样的架构和功能并不重要,此时是以数据为中心进行体系化的数据规划,设计重点是数据的形式、构成、标准等。

            可以看出,每个设计层的关注重点不同,对数据的设计只能在数据层进行,而且也只能在对应的架构设计和功能设计完成后,才能进行数据的设计,这是因为架构产生了功能、功能产生了数据,数据设计只能排在第三位。但同时,数据也不是由功能自然地、随意地产生出来的,而是预先规划、设计出来的。数据的规划、标准反过来也会影响到功能的设计。

            1.数据的概要设计

            数据的概要设计:在数据层面上对系统的数据进行全面规划,对各个领域的数据进行专业规划,建立系统的主数据,以及数据的标准。数据的概要设计决定了数据的生命周期。

            (1)数据的整体规划:对所有的数据进行全面的梳理、规划、划分系统、领域等。

            (2)数据的领域规划:对整体规划的成果进行细分,逐一对各业务领域的数据进行规划。

            (3)主数据的规划:确定未来的主数据对象、标准等。

            (4)业务编号的标准制定:确定各个数据表的识别编号的制定标准。

            2.需求变化对架构层、功能层和数据层的影响

            在企业的经营模式、业务处理流程、管理方式等发生变化时:

            (1)业务架构:随着企业上述变化而不停地进行调整、优化。

            (2)业务功能:除去会随着业务和管理的变化而变化以外,还会随着IT技术、硬件的进步等发生变化、改进,例如,从PC处理方式到移动处理方式。

            (3)业务数据:不论架构和功能如何变化,我们都不希望数据的结构和标准也随着变化,因为不论架构和功能如何变化,只要数据的结构和标准不变,业务数据就可以继承、使用。承载企业信息资产的是数据,而不是架构和功能。

            还要理解一个重要的概念:数据能否共享、系统的生命周期长短等都与数据层面的设计水平紧密相关,数据层设计得不好,不但未来会带来严重的信息孤岛问题,而且还会造成系统的应变能力差,更难以实现行业流行的碎片化设计、物联网应用设计等,因此,数据设计的优劣,影响的不仅是数据,而是整个系统未来的应用、生命周期。

            3.各设计阶段的数据设计内容

            1)数据的概要设计——数据的标准确定数据的标准:主数据、业务编号等,它们是系统间数据共享、复用的必要前提。

            2)数据的详细设计——数据的逻辑确定数据表之间、数据之间以及复杂算式的逻辑关系,这些关系是进行数据分析、数据架构,以及对业务功能进行详细设计(业务4件套)的基础。

            3)数据的应用设计——数据的机制设计各种机制,以使得前面对数据设计的成果可以在系统中有效地得到落实,特别是对数据的共享、复用,以及将文字型数据向数字型设计转换机制的设计。

    11.3 数据规划

    11.3.1 数据规划的概念

            积累企业数据,是客户构建管理信息系统的目的之一,从对数据的顶层规划开始需要经过几个步骤才能最终获得各个层次的数据,根据开发的项目规模,以及对信息系统未来使用的要求,对数据的规划大致可以分为3种粒度,从最粗粒度的数据整体规划到最细粒度的数据定义,在实际的设计中这三种粒度的规划是否全部要做,需要根据实际项目的规模、复杂度、后期变化的频繁情况等由业务设计师来决定。

            1.系统粒度

            系统粒度的规划目的是为了给出整个系统需要哪些数据,规划范围要覆盖整个系统的数据,要确定全部数据的边界,以及各个子系统的数据边界。子系统的数据包括:主营业务数据、辅营业务数据、系统维护数据等,可以看出这些子系统所包含的数据之间是不重叠的。

            2.领域粒度

            以各个业务领域为对象进行规划,如销售领域、财务领域、成本领域等,按照业务领域进行规划时数据来源可能会发生跨系统的现象,例如基础数据中的“客商数据”,就会发生被多个业务领域所引用,在设计时就要特别注意,不要让相同的客商数据多次输入到系统中,避免因重复输入而带来的混乱。通过建立主数据的体系,可以保持数据来源的唯一性。

            3.数据表粒度

            数据表是建立在数据规划的基础之上的,它属于数据的详细设计内容,数据表是数据集合体的最小单位,再小就是单个的数据了。到此就完成了数据层要素“粒度”的全部定义和说明。下面就要对数据进行具体的规划设计了。

    11.3.2 规划1——按系统整体

            完成了架构、功能的概要设计(规划)后,就需要在数据层面对数据也进行同样的规划,这个规划是从企业数据资产的视角进行的。这些数据是支持企业的经营、销售、生产、节约成本、增加利益等不可或缺的重要分析依据,规划包括企业需要哪些领域的数据、这些领域的数据构成是什么等。数据的规划可以从两个层面进行:整体规划、领域规划。对企业信息系统的数据进行整体的规划,采用框架图的形式给出企业需要数据的范围、分类,可以从几个维度来规划数据,图内的数据划分的区域名称、数据名称等仅作参考,因不同的企业会有不同的划分方式和冠名方法。

            框架图中包括:①过程数据,②基础数据,③管理数据,④其他数据及⑤加工数据共5个部分。这5个部分的数据通常需要分成不同的周期进行规划和建设,因此,如果本次信息系统是建设的第一期,那么规划的内容不但要包括本次的数据,还需要包括未来二期、三期将要产生的新数据,这一点非常重要,这是避免未来产生信息孤岛的重要设计环节,同时也是实现在不同期间构建的系统之间可以实现数据共享的主要措施。

            这个数据规划框架图是一个业务视角的、逻辑层面的数据规划图,它不是技术设计视角的数据规划图,因为无论是哪个层的设计工作,原则上都必须要从业务视角开始规划和设计。

            数据规划用的框架图与功能规划用的框架图看似相近,但是仔细观察会发现它们的内容构成是不一样的。

            (1)功能规划框架图中的要素是“功能”。

            (2)数据规划框架图中的要素是“数据”。数据的规划,首先从企业数据的整体规划开始,通过这个规划可以给出数据的全貌、领域的划分。框架图中给出了区域划分的参考方式,各个区域的含义如下。

            1.过程数据(图中①部分)

            过程数据,顾名思义,就是在系统运行过程中产生的原始数据,这些数据都是直接输入的数据,它们尚未经过数据的加工。

            2.基础数据(图中②部分)基础数据从内容上可以划分为两大类,即:公共字典、企业知识库。

            3.管理数据(图中③部分)管理数据也可以分为两大类:业务的管理数据、系统的管理数据。

            4.其他数据(图中④部分)其他内部、外部系统产生的数据。还有不是企业管理系统中产生的数据,它们可能来自于其他类型的软件、或是来自于外部的系统数据等,如图形数据、音像数据等。

            5.加工数据(图中⑤部分)对过程数据进行的加工,形成了原始数据中不存在的数据,如赢亏、产值、利润等。

    11.3.3 规划2——按业务领域

            前面对全部数据进行了5个层面的规划,这个规划虽然看到了数据的全貌,但是它们是基于“数据不能重复”的原则进行的。例如在数据的框架图中,基础数据和过程数据是属于不同的区域,因此从整体规划上看不出这两个区内的数据是如何关联的。下面就要以每个业务领域为对象进行数据的规划,这样就可以看出以业务领域为单元的数据关联关系。

            1.领域数据规划的概念

            领域数据与整体数据划分不同,领域是以业务系统划分的,它是将与业务领域相关的所有数据放在一起,例如材料采购数据,则将采购合同、采购计划、材料/设备编码、供应商信息等汇总在一起,观察它们之间的逻辑关系。一个数据领域大小的划分可以根据需要来决定,粒度可以是框架图中的一个模块,也可以将数个有关联关系的模块整合在一起,这样可以从更大的视角去理解数据之间的关系。在哪个层面、哪种粒度上进行数据的展开,取决于设计师想要为后续的设计提供什么信息、确定什么样的数据范围,以及树立什么样的数据标准等。

            业务设计师不急于去关注这些数据表内有哪些具体的数据,他只是从业务的视角确定需要哪些种类的数据、数据表的名称、不同种类数据表之间是什么关系就可以了。另外,业务设计师也不关注数据表与实际的数据库之间的关系,针对数据库的设计工作交由后续的技术设计师来完成,因为它属于技术设计的范畴。

            2.领域数据规划的步骤

            领域数据规划的依据来源于业务架构图的业务逻辑关系、功能规划的数据关系等,同时,数据规划要与功能规划有相互的匹配检查,以确定它们之间的数据表关系没有问题。

            1)领域数据来源的确定

            收集相关的数据来源,这里主要利用功能的概要设计成果——功能规划视图等,构成数据规划的核心数据来源可以分为两类,即:基础数据、过程数据。它们是通过业务功能中的“字典”和“活动”分别获取的,其中,字典是独立的,活动可以参考业务架构的关系。

            2)数据体系的建立

            利用业务架构图作载体,对收集到的数据源(数据表)进行关联,关联时要注意,此时并不关注用数据表中的哪个“键”进行关联,只要标识出哪些数据表之间有关联关系就可以了。

    11.4 数据标准

    11.4.1 业务编号的标准

            1.业务编号的原则

            业务编号,是为保证每个数据表在系统中都是唯一的而建立的识别编号。因为这个编号的构成中带有业务含义,因此称之为业务编号。它是后续建立数据逻辑关系的基础。确立业务编号的编制原则是数据规划中的重要工作,有了这个业务编号就可以将系统中的全部数据关联起来,相互应用、管理。可以说,业务编号是数据设计的基础。

            2.编号工作的分担

            对企业的基础数据进行收集、甄别、梳理以保证它们的功能符合信息系统的要求是客户要在系统上线前做的重要准备工作之一。而制定业务编号的标准又是梳理基础数据之前要做的事。通常企业都有自己的基础数据和业务编号,但是由于这些编号制定时可能还是手工作业的,因此业务编号的标准方法可能不符合信息系统的要求。因此,需要业务设计师与企业的相关部门一起,参考企业原有的编号,对预计要导入到信息系统的全部基础数据逐一地进行业务编号的设计,确保系统的正确运行,以及未来的主数据选取、数据共享与复用等。

            (1)确定哪些数据需要导入到新的信息系统中(参考字典功能设计)。

            (2)分析这些基础数据需要的业务编号长度、构成方式。

            (3)制定对所有基础数据的业务编号标准。

    11.4.2 业务数据的标准

            按照业务数据的分类建立标准,业务数据包括:基础数据、过程数据、管理数据、加工数据等,这里重点对过程数据和基础数据的标准建立进行说明。

            1.过程数据

    过程数据的内容非常多,原始输入的数据除去基础数据外,全部都属于过程数据。过程数据反映了生产过程中的情况。过程数据的标准是在功能的定义中确定的。

            2.基础数据

            建立基础数据标准的关键就在于对数据的分类,因为基础数据不仅是需要输入的数据,而且还是建立企业管理标准化最为重要的手段之一,所以,基础数据的分类、定义清晰,就相当于其对应的企业工作是定义清晰的。

    11.4.3 主数据的选定与标准

            1.主数据的概念

            主数据,是指可以在计算机系统之间共享、共用的数据,如客商编号、产品型号、组织机构等。一个企业管理信息化体系由最初的一个系统逐渐地增加到复数的系统,例如,自动办公系统(OA)、人力资源系统(HR)、企业资源计划(ERP)、项目管理系统(PM)、生产信息化管理系统(MES)等,由于系统不是一次建成的,常常还可能是由复数的软件商开发的,如果预先不做主数据设计,就会发生各类数据名称的不一致、编码不统一的问题,当需要将系统的数据整合在一起应用时,就会发现系统间的数据不能共用、共享,也就是出现通常所说的信息孤岛现象。主数据的工作不仅是技术设计师的工作,同时也是业务设计师的工作,因为哪些数据需要共享、共用,它们首先是属于业务问题,所以应该先由业务设计师考虑,否则按照软件工程推进的顺序,到了技术设计阶段再考虑就迟了,将会造成很多的内容要返回到概要设计去重新考虑。当然,主数据的设计还需要有专业的知识和技术,这里只谈业务人员可以做到的工作,而且这个工作做好了对后续技术设计师做构建主数据体系具有很好的辅助作用。

            统一的主数据标准,不但可以让正在设计开发中系统内的所有数据实现共享、共用,而且还可以让未来开发的系统也能够顺利地融入到既有的系统中来,彻底避免系统上线后发生信息孤岛的现象,让企业的数据资产得以永久地使用。

            2.主数据的存在确认

            观察领域数据规划就可以看到,很多领域之间存在着某些数据是可以共享的,三个不同的业务领域中都用到了“材料编号”这类数据,在定义了主数据和相应的标准后,这三个业务领域中的任意一处首先建立了“材料编号”的数据之后,那么后续的其余两个业务领域的数据只要符合相同的标准,就可以共享材料编号这个基础数据了。

            3.主数据的设计

            主数据体系的建立通常有4个方面的工作,即:采集/集成、共享、数据质量、数据治理。作为业务设计师的工作重点就是将主数据识别出来,建立主数据的一览,然后交由技术设计师按照主数据的标准来完成后续的工作。大多数的主数据都是来自于基础数据。

            主数据一览的构成内容如下。

            (1)行:是不同系统、功能的名称。

            (2)列:是主数据的名称。

            (3)○:表明主数据被哪个功能所应用。

            4.主数据与数据标准的不同

            主数据指的是某个数据在不同系统之间可以共用,数据标准指的是数据的表达格式,包括:单个的“数、值”,或是一个数据“表”。数据标准的覆盖范围包括系统中所有的数据(也包括主数据)。

    小结

            数据的设计非常重要,传统上从事非技术方面工作的工程师是比较少关注数据设计的,当企业信息化进行了一段时间后,系统的功能数量和数据的数量都会增加,就会带来各式各样的问题,其中,功能层面上的问题相对易于解决,而数据层面的问题就很难解决了,这也就是为什么一旦出现了信息孤岛问题解决的成本就非常高,以至于很多企业就放弃了。为了避免在信息系统生命周期内发生这样的问题,就必须在信息系统的设计初期考虑对策。核心价值在于让业务设计师可以掌握一定的数据规划设计知识,感受到数据层的存在、数据层架构层和功能层的关系,以及数据的设计对于信息系统生命周期的意义和价值。

            (1)数据的分类,是从非业务视角对数据的共性抽提,这个分类使得对数据的设计方法具有普遍性和通用性,同时这个数据分类也是业务功能分类的依据。

            (2)数据的规划,是从数据的视角来理解信息系统(通常都是从架构、功能来理解的),完整、长久的信息系统设计,不仅要有架构和功能的设计,还必须有数据层的设计。

            (3)数据的标准,它不仅是系统之间数据可否共享和复用的基础,而且数据标准也是决定信息系统生命周期长短的主要因素之一。

            在架构的概要设计完成后,架构层的内容是一定要随着企业的变化而变化的,也就是说对架构层来说“变”是“不变的真理”;在功能的概要设计完成后,同样要通过各种设计方法尽量减少功能的变化,或是不得已发生变化时尽可能地不去影响其他不需要变化的功能;而到了数据的概要设计时,不但希望数据层不受其他变化的影响,而且希望数据尽可能做到一直都不变,如此数据的生命周期才会长久。

            理解信息系统生命周期的长短取决于数据的生命周期,而数据生命周期的长短取决于业务设计中的数据规划设计,这其中的关键角色之一就是业务设计师。

            数据设计,是业务设计师的基础工作

            业务设计师实际上参与了大量的数据设计,他们只是没有直接参与最后的数据“库”设计。严格地说,这个数据“库”的设计是以业务设计师的成果为基础由技术人员(设计、开发)做的。软件的实现(包括数据库)当然是由开发工程师做的,但是这些问题的研究都需要从业务人员开始,解决方案也必须有业务人员参与,信息孤岛的问题,它首先不是技术问题而是业务问题(如果是技术问题的话,开发工程师早就解决了,也就不存在信息孤岛现象了)。大家强烈地意识到,在多系统、多业务板块由不同组同时设计开发时,如果类似于数据的复用、共享、主数据、数据标准等需求在业务设计阶段没有解决,等到了数据库设计阶段再考虑,就有可能带来前期设计的返工,造成一连串的问题。

    相关文章

      网友评论

          本文标题:大话软件工程:需求分析与软件设计(十一)

          本文链接:https://www.haomeiwen.com/subject/iwgaxrtx.html