全部科目 > 信息系统项目管理师 >
2009年上半年 上午试卷 综合知识
第 46 题
知识点 过程模型   开发过程   可控性   螺旋模型   瀑布模型   软件过程   系统解决方案  
关键词 风险   开发方法   开发过程   螺旋模型   瀑布模型   软件过程   原型   开发   瀑布  
章/节 信息系统项目的生命周期  
 
 
螺旋模型是一种演进式的软件过程模型,结合了原型开发方法的系统性和瀑布模型可控性特点。它有两个显著特点, 一是采用(46) 的方式逐步加深系统定义和实现的深度,降低风险;二是确定一系列(47),确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案
 
  A.  逐步交付
 
  B.  顺序
 
  C.  循环
 
  D.  增量
 
 




 
 
相关试题     螺旋模型 

  第2题    2011年上半年  
螺旋模型的开发过程具有周期性重复的螺旋线状,每个开发周期由4个象限组成,分别标志着开发周期的4个阶段。螺旋模型之所以特别适用于庞大而复杂的、高风险的系统开发,是因为它强调其中的(2)阶..

  第47题    2009年上半年  
螺旋模型是一种演进式的软件过程模型,结合了原型开发方法的系统性和瀑布模型可控性特点。它有两个显著特点, 一是采用(46) 的方式逐步加深系统定义和实现的深度,降低风险;二是确定一系列(..

 
知识点讲解
· 过程模型
· 开发过程
· 可控性
· 螺旋模型
· 瀑布模型
· 软件过程
· 系统解决方案
 
        过程模型
        产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型,它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。
               瀑布模型(Waterfall Model)
               瀑布模型是将系统生存周期各个活动规定为依线性顺序连接的若干阶段的模型,也称为线性模型。它包括需求分析、设计、实现、测试、运行和维护。它规定了由前至后、相互衔接的固定次序,如同瀑布流水,逐级下落,如下图所示。
               
               瀑布模型
               瀑布模型为系统的开发和维护提供了一种有效的管理模式,根据这一模式制定开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,所以它是以文档作为驱动、适合于系统需求很明确的软件项目的模型。
               瀑布模型假设一个待开发的系统需求是完整的、简明的、一致的,而且可以先于设计和实现产生。瀑布模型的优点是,容易理解,管理成本低;强调开发的阶段性早期计划及需求调查和产品测试。不足之处是,客户必须能够完整、正确和清晰地表达他们的需要;在开始的两个或三个阶段中,很难评估真正的进度状态;当接近项目结束时,出现了大量的集成和测试工作;直到项目结束之前,都不能演示系统的能力。在瀑布模型中,需求或设计中的错误往往只有到了项目后期才能够被发现,对于项目风险的控制能力较弱,从而导致项目常常延期完成,开发费用超出预算。
               瀑布模型的一个变体是V模型,如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着团队工作沿着V模型左侧步骤向下推进,基本问题需求逐步细化,形成问题及解决方案的技术描述。一旦编码结束,团队沿着V模型右侧的步骤向上推进工作,其实际上是执行了一系列测试(质量保证活动),这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。
               
               V模型
               增量模型(Incremental Model)
               增量模型融合了瀑布模型的基本成分和原型实现的迭代特征,它假设可以将需求分段为一系列增量产品,每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”,如下图所示。当使用增量模型时,第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
               
               增量模型
               增量模型作为瀑布模型的一个变体,具有瀑布模型的所有优点。此外,它还有以下优点:第一个可交付版本所需要的成本和时间很少;开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本,因此可以减少用户需求的变更;运行增量投资,即在项目开始时,可以仅对一个或两个增量投资。
               增量模型有以下不足之处:如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,重新发布;管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
               原型模型(Prototype Model)
               并非所有的需求都能够预先定义,大量的实践表明,在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求,开发者对要解决的应用问题模糊不清,以至于形成的需求规格说明常常是不完整的、不准确的,有时甚至是有歧义的。此外,在整个开发过程中,用户可能会产生新的要求,导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化,于是出现了快速原型(rapid prototype)这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况,是一种演化模型(Evolutionary Model)。当系统规模不是很大也不太复杂时,采用该方法比较好。
               原型是预期系统的一个可执行版本,反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束,其目的是能快速、低成本地构建原型。当然,能够采用原型方法是因为开发工具的快速发展,使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样,对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求,开发初始原型,然后征求用户对初始原型的改进意见,并根据意见修改原型。原型模型如下图所示。
               
               原型模型
               原型模型开始于沟通,其目的是定义软件的总体目标,标识需求,然后快速制定原型开发的计划,确定原型的目标和范围,采用快速射击的方式对其进行建模,并构建原型。被开发的原型应交付给客户使用,并收集客户的反馈意见,这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进,或者需要扩展其范围的时候,进入下一轮原型的迭代开发。
               根据使用原型的目的不同,原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求,确定所希望的特性,并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性,是在大规模开发和实现前,用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分,通过对原型的多次改进,逐步将原型演化成最终的目标系统。
               螺旋模型(Spiral Model)
               对于复杂的大型系统,开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。螺旋模型是一种演化模型。
               螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,如下图所示。在每个螺旋周期分为如下4个工作步骤。
               
               螺旋模型
               (1)制订计划。确定系统的目标,选定实施方案,明确项目开发的限制条件。
               (2)风险分析。分析所选的方案,识别风险,消除风险。
               (3)实施工程。实施系统开发,验证阶段性产品。
               (4)用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
               螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
               与瀑布模型相比,螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高产品的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了系统开发的风险。在使用螺旋模型进行系统开发时,需要开发人员具有相当丰富的风险评估经验和专门知识。另外,过多的迭代次数会增加开发成本,延迟提交时间。
               喷泉模型(water fountain model)
               喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性,如下图所示。迭代意味着模型中的开发活动常常需要重复多次,在迭代过程中不断地完善系统。无间隙是指在开发活动(如分析、设计、编码)之间不存在明显的边界,也就是说,它不像瀑布模型那样,需求分析活动结束后才开始设计活动,设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。
               
               喷泉模型
               喷泉模型的各个阶段没有明显的界限,开发人员可以同步进行。其优点是可以提高项目开发效率,节省开发时间。由于喷泉模型在各个开发阶段是重叠的,在开发过程中需要大量的开发人员,不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大。
               形式化方法模型(Formal Methods Model)
               形式化方法是用于将复杂系统建模为数据实体的技术,是建立在严格数学基础上的一种开发方法,其主要活动是生成计算机软件形式化的数学规格说明。
               形式化方法用严格的数学语言和语义描述功能规约和设计规约,通过数学的分析和推导,易于发现需求的歧义性、不完整性和不一致性,易于对分析模型、设计模型和程序进行验证。通过数学的演算,使得从形式化功能规约到形式化设计规约,以及从形式化设计规约到程序代码的转换成为可能。
               统一过程(UP)模型
               统一过程的特色是“用例和风险驱动,以架构为中心,迭代的增量开发过程”。迭代的意思是将整个产品开发项目划分为许多个小的“袖珍项目”,每个“袖珍项目”都包含正常项目的所有元素:计划、分析和设计、构造、集成和测试,以及内部和外部发布。
               统一过程定义了5个阶段及其制品。
               (1)起始阶段(inception phase)。起始阶段专注于项目的初创活动,产生的主要工作产品有构想文档(vision document)、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划(阶段及迭代)、业务模型以及一个或多个原型(需要时)。本阶段的里程碑是生命周期目标。
               (2)精化阶段(elaboration phase)。精化阶段在理解了最初的领域范围之后进行需求分析和架构演进,产生的主要工作产品有用例模型、补充需求(包括非功能需求)、分析模型、体系结构描述、可执行的体系结构原型、初步的设计模型、修订的风险列表、项目计划(包括迭代计划、调整的工作流、里程碑和技术工作产品)以及初始用户手册。本阶段的里程碑是生命周期架构。
               (3)构建阶段(construction phase)。构建阶段关注系统的构建,产生实现模型,产生的主要工作产品有设计模型、系统构件、集成的增量、测试计划及步骤、测试用例以及支持文档(用户手册、安装手册和对于并发增量的描述)。初始运作功能。
               (4)移交阶段(transition phase)。移交阶段关注于系统提交方面的工作,产生系统增量,产生的主要工作产品有提交的系统增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。
               (5)生产阶段(production phase)。生产阶段对持续使用的软件进行监控,提供运行环境(基础设施)的支持,提交并评估缺陷报告和变更请求。
               在每个迭代中,有5个核心工作流:捕获系统应该做什么的需求工作流,精化和结构化需求的分析工作流,用系统构架实现需求的设计工作流,构造系统的实现工作流,验证实现是否如期望那样工作的测试工作流。
               统一过程的典型代表是RUP(Rational Unified Process),主要针对前4个技术阶段。RUP是UP的商业扩展,完全兼容UP,但比UP更完整、更详细。
               敏捷方法(Agile Development)
               敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在产品开发过程中加入灵活性,敏捷方法使用户能够在开发周期的后期增加或改变需求。
               敏捷过程的典型方法有很多,每一种方法基于一套原则,这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。
               (1)极限编程(XP)。XP是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成,彼此相互依赖、关联,并通过行为贯穿于整个生存周期。
               .4大价值观:沟通、简单性、反馈和勇气。
               .5个原则:快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
               .12个最佳实践:计划游戏(快速制订计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、简单设计(只处理当前的需求,使设计保持简单)、测试先行(先写测试代码,然后再编写程序)、重构(重新审视需求和设计,重新明确地描述它们以符合新的和现有的需求)、结队编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作40个小时、现场客户和编码标准。
               (2)水晶法(Crystal)。水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。
               (3)并列争球法(Scrum)。并列争球法使用迭代的方法,其中,把每30天一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行,就像橄榄球中的“并列争球”。。
               (4)自适应软件开发(ASD)。ASD有6个基本的原则:有一个使命作为指导;特征被视为客户价值的关键点;过程中的等待是很重要的,因此“重做”与“做”同样关键;变化不被视为改正,而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
 
        开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
 
        可控性
        可控性是指网络信息系统责任主体对其具有管理、支配能力的属性,能够根据授权规则对系统进行有效掌握和控制,使得管理者有效地控制系统的行为和信息的使用,符合系统运行目标。
 
        螺旋模型
        螺旋模型将瀑布模型和变换模型相结合,综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制定计划、风险分析、实施工程及客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。螺旋模型的核心思想是循环,在每个循环的出口设置里程碑。
 
        瀑布模型
        瀑布模型也称为生命周期法,是结构化方法中最常用的开发模型,它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。采用瀑布模型的软件过程如下图所示。
        
        软件生存周期的瀑布模型
        (1)软件计划(问题的定义及规划):主要确定软件的开发目标及其可行性。
        (2)需求分析:在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。
        (3)软件设计:主要是指根据需求分析的结果,对整个软件系统进行设计,如系统框架设计和数据库设计等。软件设计一般分为总体设计(概要设计)和详细设计。
        (4)程序编码:将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范,以保证程序的可读性和易维护性,提高程序的运行效率。
        (5)软件测试:在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。
        (6)软件维护:软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件可能会不能继续适应用户的要求,这时如果要延续软件的使用寿命,就必须对软件进行维护。
        瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”,即每个活动只做一次,最后得到软件产品,也称做“线性顺序模型”或者“传统生命周期”,其过程是从上一项活动接收该项活动的工作对象并作为输入,利用这一输入实施该项活动应完成的内容,给出该项活动的工作成果,然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。
        瀑布模型有利于大型软件开发过程中人员的组织与管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下的,而是呈线性图式,因此,瀑布模型存在严重的缺陷。
        (1)由于开发模型呈线性,所以当开发成果尚未经过测试时,用户无法看到软件的效果。这样,软件与用户见面的时间间隔较长,也增加了一定的风险。
        (2)在软件开发前期未发现的错误传到后面的开发活动中时,可能会扩散,进而可能会导致整个软件项目开发失败。
        (3)在软件需求分析阶段,完全确定用户的所有需求是比较困难的,甚至可以说是不太可能的。
        :瀑布模型适用于需求明确或很少变更的项目。
 
        软件过程
        在开发产品或构建系统时,遵循一系列可预测的步骤(即路线图)是非常重要的,它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为"软件过程"。过程是活动的集合,活动是任务的集合。软件过程有3层含义:一个是个体含义,即指软件产品或系统在生存周期中的某一类活动的集合,如软件开发过程、软件管理过程等;二是整体含义,即指软件产品或系统在所有上述含义下的软件过程的总体;三是工程含义,即指解决软件过程的工程,应用软件的原则、方法来构造软件过程模型,并结合软件产品的具体要求进行实例化,以及在用户环境下的运作,以此进一步提高软件的生产率,降低成本。
               能力成熟度模型(CMM)
               CMM将软件组织的过程能力分成五个成熟度级别:初始级、可重复级、已定义级、已管理级和优化级。由低到高,软件开发生产精度越来越高,每单位工程的生产周期越来越短。
               (1)初始级。软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。
               (2)可重复级。建立了基本的项目管理过程来跟踪费用、进度和功能特性;制定了必要的过程纪律,能重复早先类似应用项目取得的成功。
               (3)定义级。已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
               (4)管理级。收集对软件过程和产品质量的详细度量,对软件过程和产品都有定量的理解和控制。
               (5)优化级。过程的量化反馈和先进的新思想、新技术促使过程不断改进。
               能力成熟度模型集成(CMMI)
               CMM的成功导致了适用不同学科领域的模型的衍生,如系统工程的能力成熟度模型,适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科,因此有必要将各种过程改进的工作集成起来。1998年,由美国产业界、政府和卡内基.梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进,是支持多个工程学科和领域的、系统的、一致的过程改进框架,能适应现代工程的特点和需要,能提高过程的质量和工作效率。
               CMMI提供了两种表示方法:阶段式模型和连续式模型。
               1)阶段式模型
               阶段式模型的结构类似于CMM,它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版中有5个成熟度等级。
               初始的:过程不可预测且缺乏控制。
               已管理的:过程为项目服务。
               已定义的:过程为组织服务。
               定量管理的:过程已度量和控制。
               优化的:集中于过程改进。
               2)连续式模型
               连续式模型关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级(Capability Level,CL)。CMMI中包括6个过程域能力等级,等级号为0-5。能力等级包括共性目标及相关的共性实践,这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时,就说该组织达到了那个过程域的能力等级。
               能力等级可以独立地应用于任何单独的过程域,任何一个能力等级都必须满足比它等级低的能力等级的所有准则。对各能力等级的含义简述如下。
               CLo(未完成的):过程域未执行或未得到CLi中定义的所有目标。
               CLi(已执行的):其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标。
               CL2(已管理的):其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程,项目遵循已文档化的计划和过程描述,所有正在工作的人都有权使用足够的资源,所有工作任务和工作产品都被监控、控制和评审。
               CL3(已定义级的):其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的,还必须收集过程资产和过程的度量,并用于将来对过程的改进。
               CL4(定量管理的):其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域,建立和使用关于质量和过程执行的定量目标作为管理准则。
               CLs(优化的):使用量化(统计学)手段改变和优化过程域,以满足客户要求的改变和持续改进计划中的过程域的功效。
 
        系统解决方案
        本小节介绍实现该智能工厂车间的底层解决方案,主要包括网络构建、数据采集架构、PLC数据采集平台等内容。
               网络拓扑图
               下图是本智能工厂的网络拓扑结构,通过一个交换机连接了各车间的数字设备、服务器、各种电子看板。
               
               网络拓扑图
               数据采集应用架构示意图
               各车间局域网连接了各类需要数据采集的设备,局域网向上连接到整个工厂的主干网,服务器连接在主干网。整个应用架构如下图所示。
               
               数据采集架构
               PLC设备数据采集平台
               生产线现场加工设备为西门子等国际通用的PLC,采用DAServer的方式与现场PLC进行通信交互,将现场加设备中的工艺参数,报警信息、产量等设备信息采集到系统历史数据库中,与当前的生产工单、加工工序、加工产品、加工时间相对应,通过报表的形式展示。
               原料、工装夹具扫描确认无误后,在工位终端(触摸屏)点击开始加工,现场工控机实时获取加工过程中的工艺实时数据,上传到系统服务器中,并显示在工位终端,供加工工人查看,业务流程如下图所示。
               
               数据采集处理流程
               系统方案结构图
               系统整体方案如下图所示。系统模块较多,重点介绍其中的计划排产模块。
               
               生产管理系统整体方案
               生产计划排产模块主要包含了五个功能,具体如下。
                      ERP集成
                      由于企业存在多个管理系统,包括ERP和PDM等。MES中的部分功能是和ERP中的一些功能重合的,为了避免员工重复的工作,MES系统需要和ERP系统做系统集成。在生产计划方面MES系统需要读取ERP系统的生产主计划及交期信息,MES系统再根据从ERP中得到的主计划进行详细任务分解。下图为ERP集成示意图。
                      
                      ERP集成
                      生产任务分解
                      该模块主要功能为把从ERP读取的主计划进行进一步任务分解,根据产品的工艺路线或工艺标准,把任务分解到车间或产线。
                      生产任务派工
                      该模块主要功能为,车间一线管理人员可根据MES系统下达到车间或产线的任务进行进一步详细分解,可具体到人、数量、工位、设备、时间等。
                      返修任务派工
                      该模块主要用来对生产过程中或检验后不合格且需要返修的产品重新进行任务派工,可派工到原生产人员处也可指定其他人员。
                      生产任务管理
                      可对生产任务进行管理,如暂停任务,重启任务,关闭任务等,任务处于不同的状态时,会对生产过程产生不同影响。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有