工程管理定义篇(1)

就是通过组织生产要素(人、材、机)，以最小的投入得到最好的效益，当然包括经济和社会及环境效益。施工管理是工程管理的一部分，它包括成本、技术、组织、质量、安全、环境等方面，这些环节形成了一个系统。

（来源：文章屋网 http://www.wzu.com）

工程管理定义篇(2)

关键词：XPDL；工作流；工作流引擎；项目管理

中图分类号：TP315 文献标识码：A 文章编号：1009-3044（2012）33-7936-03

随着我国经济建设的发展和人民生活水平的提高，房地产行业也获得了健康发展的契机，而房地产项目的成败主要取决于设计理念是否先进、施工质量是否达到预期目标等等，这些都直接关系到开发商的经济收益和社会效益。随着计算机应用日益普及，开发商普遍采用工程项目管理软件来帮助企业提高项目管理效率，企业业务规模的不断扩大，对并行项目的管理也变得越来越困难，同时由于当前很多的工程经过层层分包和转包，加上施工管理人员缺乏系统化、规范化流程控制管理理念，项目的管理比较混乱，设计方和建筑方沟通不彻底，项目协同设计能力较差，容易偏离初始设计目标，后期反馈导致项目修改负担重。同时各项目管理系统平台缺乏统一规划，各自形成“信息孤岛”无法进行数据的共享和交换，从而大大降低了企业项目管理的科学性与效率。

目前传统的工程项目管理系统一般是将现有业务的应用逻辑和业务流程固化到一起[1]，通过人工操作处理业务流程信息。房地产项目运作的环境错综复杂，地区经济发展水平、政府宏观、微观金融政策的调整、消费对象和消费意愿以及房地产市场的变化等，都可能直接影响到房地产项目的开发和销售。房地产项目的经营者迫切需要提高能够适应激烈的市场竞争，迅速对复杂、高风险的投资活动作出正确决策的能力。由于人工处理信息时效性差，使得房地产开发项目管理方无法做出及时准确的计划和控制。与此同时，当遇到外界环境发生改变，就不得不对已有的规划设计进行修改，甚至已经建成的建筑需要拆除重建，往往这种方式在时间上又是不被允许的，就会导致项目遭受巨大损失。

传统的工程项目管理系统实现信息流和业务流的流转一般通过菜单驱动方式，该方式只能机械地处理系统包含的数据和文档资料，难以应对市场快速变化做出相应设计上的修改和灵活管理业务逻辑变迁，无法实现开发商、建筑商、设计院之间的多方协同设计项目管理工作[2]。工程项目管理系统由于涉及到很多资源、进度、收入、设计、合同的变化，这些数据始终处于流动变化状态，业务流程也随之发生改变。比如增加一个审批流程，由于传统系统不能适应业务处理流程改动，除非修改系统源代码，这又需要大量时间和费用，还能导致整个项目管理的业务流程无法正常进行。因此这类系统在设计时就要考虑到如何实现业务流程的快速变更或重建，其中包括改变工作流程流向、增加新工作流程环节、减少老工作流程环节、合并工作流程环节等。传统的工程项目管理系统处理工作流程是通过开发人员人工编写固定操作流程，并由人工触发转入下一步骤，这显然难以适应现代工程项目管理需求灵活多变的现状。

1　相关技术

JaWE（Java　Workflow　Editor）是一种全新的图形化工作流过程定义编辑器，它严格遵循工作流管理联盟（Workflow　Management　Coalition，WfMC）的接口规范，输出一个标准的过程定义文本描述XPDL（XML　Process　Definition　Language）文件。工作流过程定义接口定义了一个公共接口模式，不同工作流产品的过程定义是可以通过XPDL标准来进行交互的。由JaWE定义的工作流过程模型，能够在不同的工作流软件产品上进行运行和通讯。基于元模型框架的XPDL过程定义接口规范定义了在一个过程定义中常用的实体以及它们之间的关系和实体属性。按照元模型定义，JaWE通过XPDL规范的公用接口模式能够实现多个模型间的转换和过程定义的内部描述。

2　支持协同设计的工作流项目管理系统模型

图1给出了用统一建模语言（Unified　Modeling　Language，UML）设计的体系结构模型，新模型采用工作流技术来解决目前项目管理信息系统的强耦合与弱柔性的问题。该系统结构包含5个层次，自上而下分别是表示层、访问控制层、模型层、数据访问层、数据库。表示层包含所有用户服务接口，直接为用户提供信息服务；访问控制层主要负责对用户身份进行核实，按照身份服务权限表赋予相应服务模块的访问权限；模型层封装系统所有的服务器组件、逻辑业务功能接口和XPDL流程定义文件，它结构复杂，任务繁重是整个系统协作运行的核心层；数据访问层为以上各层提供数据库访问服务接口；数据库主要存放各种相关应用数据，包括XPDL工作流模型定义文件、工程设计CAD文件、企业业务文档数据、系统访问控制数据及其他相关数据。

3　设计实现

该文设计的Web应用框架采取目前主流.NET开发技术设计，程序开发语言为Visual　C#　2010，开发环境为Visual　Studio　2010。工作流过程定义语言采用XPDL规范，它是工作流管理联盟提出的一种基于XML的工作流过程定义语言，它负责定义工作流参考模型中的过程定义交换接口。工作流过程设计组件使用JaWE　图形化设计工具，工程设计组件使用AutoCAD，它是目前世界各国工程设计人员的首选设计软件，简便易学、精确无误。数据库使用SQL　Server　2005，它是一个全面的数据库平台，使用集成的商业智能？（Business　Intelligence，BI）工具提供了企业级的数据管理，为关系型数据和结构化数据提供了更安全可靠的存储功能，可以构建和管理用于业务的高可用和高性能的数据应用程序。下面逐层进行阐述。

3.1　表示层

表示层为系统用户提供对项目管理系统的访问接口，由

Web窗体和代码隐藏文件组成。Web窗体可以提供多种多样的用户操作接口；信息格式检验脚本对输入信息格式是否合法进行验证，若用户输入格式不正确则提醒读者输入正确格式；访问控制根据用户组信息赋予当前用户相应的系统使用权限；而代码隐藏文件是.Net　Framework用来实现各种控件的事件响应处理程序。本架构同时支持B/S模式和C/S模式设计，用户可以通过IE浏览器或Windows　Form来获取系统提供的功能服务，为安全性考虑工作流设计员与系统管理员采用C/S模式设计。本系统涉及到四类角色，工程设计人员、项目管理人员、工作流设计人员、系统管理员。

3.2　访问控制层

用户登录系统时，系统对用户名、密码进行验证，确定当前用户具备系统相关服务使用权限后，允许访问相应模块。由于本系统存储的数据信息具有极高的商业价值，为了保证系统及数据的安全性，需要严格管理系统的访问控制权限，可以采取基于角色对象身份的访问控制技术[3]。角色权限分组管理是对系统的全部资源建立独立的访问权限管理，根据系统使用人员情况设定所需要的角色分组类型，同时为其分配相应的权限。为方便系统管理员管理，预先按照用户职务对访问权限进行预分组，从而实现了用户与访问权限的逻辑分离。系统实施过程中再将具体用户分配到相关的角色分组，极大地方便了管理员进行权限管理。同时允许系统管理员对角色分组权限进行微调，实现灵活的访问控制。

3.3　模型层

模型层由XPDL流程定义文件、JaWE流程定义工具、工作流引擎和AutoCAD组件构成，为用户提供工作流流程定义和工作流业务实例的建立、管理、协调控制和协同设计功能等。下面逐一进行详细说明。

XPDL语言是工作流管理联盟提出的一种基于XML的工作流过程定义语言，它定义工作流参考模型中的过程交换接口。任何业务流程都能使用XPDL工作流模型设计，XPDL过程模型由一系列活动（Activity）以及这些活动在具体的执行过程中需要使用的资源和角色按照一定的约束关系组成。XPDL工作流过程定义就是将这一系列的活动、活动之间的关系按照业务需求定义，并对相应的活动安排活动的起止日期、活动相关角色、资源等，然后将XPDL工作流过程定义模型发送给工作流引擎，通过引擎触发任务项即在“合适的时间发送到合适的人员”。

系统引入工作流流程建模工具（JaWE）目的是为了便于定义工作流过程模型，直接生成XPDL过程定义文件。JaWE提供了制定工作流过程模型的图形化建模工具。每建立一个业务流程，需要的基本节点有起始节点、执行节点和结束节点，执行节点是为了执行任务或批量执行任务，系统将通过工作流引擎来执行前面生成的XPDL文件，并把新的节点模型号、节点类型、节点号、节点名称、处理者权限等信息写入数据库，新建流向时将模型号、当前节点号、前导节点号和后续节点号读入引擎，任务完成，工作流程结束或触发其他工作流程。JaWE作为一种柔性工作流技术可以通过图形化的设计界面进行工作流业务的设计，比如设置节点属性，修改流程结构、修改节点、修改路径、创建子流程等；能够修改流程结构和对相关属性进行设置[4]。工作流流程的设计是有着严格技术要求的，一般应由系统分析员级别的研发人员承担，这关系到系统能否正确运行的核心关键，用户在自行进行修改、添加时应严格按照系统使用说明书进行，并做好原流程的备份工作，方便必要时可以恢复。

工作流过程的定义分为两个维度，模型级和过程级。模型级：一个模型可能包含若干个工作流过程定义，这些过程共享相同的应用程序（Applications）、参与者（Participants）、相关数据（Relevant　Data）。模型就是一个容器，容纳多个独立的过程和他们的实体数据。过程不能单独创建，只有先创建一个模型，才能创建模型所有的过程以及相关的工作流应用程序、参与者、相关数据。在模型中定义工作流的过程定义、应用程序、参与者和相关数据实体是全局的，他们能够被模型中所有的过程定义所引用。过程是工作流业务过程实体的图形化表示，只要含有活动（Activity）和变迁（Transition），进行具体的业务过程定义时，首先要创建业务过程的所有参与者，控制相关的活动。接着定义业务过程的所有活动，一个过程必须有一个开始活动和结束活动。最后用变迁来连接这些活动，表示出活动之间的联系[5]。

工作流引擎的设计是为了解释XPDL过程定义，并调用相应的业务处理应用程序来帮助执行活动。工作流引擎被划分为执行器和监视器两个功能。执行器实现了绝大多数的复杂工作流流程的运行功能、工作流实体对象的实例化、工作流事务处理等方面。监视器主要判断是否有超时的过程实例或者节点实例存在，但监视器并不对发现的超时对象进行处理，而是采用消息通信的方式，通过引擎消息队列通知执行器来处理这些超时的对象[6]。工作流实例运行时，引擎要使用工作流引擎管理器提供的服务来创建和管理工作流实例的运行，相关服务可以通过函数接口向引擎提供，具体设计方法篇幅较多，可以参考我的论文《基于业务流程可视化的工作流引擎设计》。

3.4　数据访问层与数据库

数据访问层可以封装几种常用的数据库访问方法，如事务提交、事务开始、事务回滚、建立连接、断开连接等，供上层复用或调用。访问层独立设计的优点就是可以针对用户特点选用不同数据库的访问程序和SQL程序，实现对多种数据库的支持，扩展该框架的适用范围。

数据库存储系统涉及到的工程设计数据库、项目数据库（包含工作流数据模型库）、文档数据库和角色权限数据库，它是表示层与模型层逻辑运算的数据来源。在该系统中涉及到的数据是与具体业务有关的数据，它只对数据访问层开放，对于其他各层它是透明的，不可直接访问的，这样做的好处就是统一管理，提高安全性。

4　结束语

该文通过对传统的工程项目管理系统进行研究，发现它们普遍存在将现有业务的应用逻辑和业务流程固化，通过人工操作处理业务流程信息，已经无法满足目前房地产开发企业需求。该文将工作流、协同设计技术引入，重新设计出灵活的工作流项目管理系统，采用JaWE组件规范设计XPDL工作流模型文档，设计实现工作流引擎对其进行解释执行，改进了传统工程项目管理系统的设

计模式，消除了由于业务流程迁移而对信息系统产生的不利影响，可以实现快速改变业务流程而无需改变系统主程序。数据访问层采用策略模式可以支持目前常用大部分数据库，基本实现了协同设计的工作流管理信息系统。

参考文献：

[1]　林闯，田立勤.工作流系统模型的性能等价分析[J].软件学报，2002，13（8）：1472-1480.

[2]　张益林.工作流技术的研究及在工程项目管理中的设计与实现[D].长沙：湖南大学，2005.

[3]　Sandhu　R，Coyne　E，Feinstein　H.Role-based　access　control　models[J].IEEE　Computer，1996，29（2）：38-47.

[4]　杨磊，戴金海，陈琪锋.柔性工作流的可视化方法研究[J].计算机仿真，2008，25（7）：223-227.

工程管理定义篇(3)

图1 micro-workflow前台定义元模型

(1)简单过程（simple procedure）——这些过程表示树（指定义树，非元模型）中的叶子节点，它既可以是一个代表软件服务的过程，也可以是一个代表用户必须完成的工作过程。 (2)复合过程（composite procedure）——复合过程用于表示对控制流（序列、条件等）的管理结构，是树中的非叶子节点。 2.2 后台定义 采用基础数据结构中的有向图来进行后台定义，其中节点代表活动步骤，节点之间的连接代表流（数据流或控制流）。控制流建立了节点的执行顺序，数据流定义了从一个活动传递到另一个活动的数据，任何图都有一个开始节点和终止节点。 2.3 前台定义到后台定义的翻译 要完成从前台到后台的翻译，前台定义模型与后台定义模型之间必须有一个完备的映射。前台定义模型提供编译规则从而生成后台定义，micro-workflow中的编译是按照自顶向下的方式完成的，它从前台定义的根部开始，递归进行，每个复合过程编译它的子节点作为其相应后台定义图中的表示。每个简单过程编译成图中的一个节点，而复合过程中的信息则成节点之间的连接，生成的结果图就是工作流引擎可任意处理的后台定义，定义编译算法时要考虑所有存在的规则，如控制流、数据流以及发送给各个节点的消息类型等。图2大体描述了一个前台到后台的映射。

图2 micro-workflow的前台/后台定义

3 工作原型修改 一个灵活的工作流管理系统应该具备wft的修改功能，即便是已经有实例运行在wft上，它也可以被修改，下面将解决这个问题。首先介绍wft版本化的概念并给出图1的扩展，然后介绍修改操作（modification operation）的概念。

3.1 wft版本化 wft版本化的主要思想是创建wft的新版本而不是直接修改原有的wft。wft的行为信息保留在它的各个版本中，图3是图1元模型的扩展，提供了wft版本化支持。 一个wft由一个或多个版本组成，并且某一版本只唯一隶属于一个wft，也就说一个版本可以有多个子孙，但只能有一个父亲，每个版本都有一个版本号作为唯一标识。当一个新的wft加入到工作流模型中时，便建立了此wft的根版本。如果要施加任何修改操作，则先创建此版本的一个子孙版本，然后在新版本上进行修改操作。一个版本可处于三种状态中：临时状态、状态及过时状态。一个版本一旦创建便置于临时状态中，处于临时状态的版本可以进行修改或移除，但不能进行实例化也不能产生子孙版本；一旦修改操作完成则变为状态，处于此状态的版本不能修改或移除，但可产生新版本；最后，当状态的版本变失效时，它的状态被置为过时。

图3 支持版本化的工作流定义元模型 3.2 修改操作 为了处理工作流模型，必须有一套定义良好的操作。所谓“定义良好”是指达到两个基本条件：完备性和正确性。完备性是指可以创建或移除wft模型上的所有元素，正确性是指当完成一系列修改操作后可以保持wft模型及实例的正确性。为了达到这两个条件，必须设置某些操作的先决条件，如果先决条件不满足，那么操作就不能执行。修改操作有两类： (1)class 1——创建和移除wft以及控制版本的操作。这一类操作完全独立于前台定义语言。 (2)class 2——修改wft版本内容的操作，这些操作依赖于前台定义语言。因此当前台定义语言改变时，这些操作必须重新实现。 4 工作流实例迁移 wfi的迁移是一个wfi绑定到一个新版本wft的过程。当一个工作流实例w从版本wt[x]迁移到wt[y]时，它便依据wt[y]开始执行。必须保证迁移操作不会产生无效的wfi，只有当w迁移到wt[y]后仍然保持有效状态，才允许进行迁移操作。 4.1 迁移条件 要判断工作流实例w在t时刻是否可以迁移到wt[y]，一个简单的方法是分析以往w在t时刻所包含的事件，看其是否与wt[y]兼容，也就是说必须检验t时刻的每一个事件，看迁移到wt[y]后是否会导致无效的wfi。很明显这种方法的效率不高，可以采用产生新版本wfi的修改操作（class 2，参见3.2）。为了决定是否可以迁移，必须考虑每个修改操作的先决条件，修改操作op的先决条件保证wt[y]在经过继承自wt[x]的修改操作op后，实例w的正确性。因此如果w在时刻t可以满足所有修改操作的先决条件，则w可以在时刻t从wt[x]迁移到 wt[y]，于是迁移条件便可由修改操作导出。需要注意的是，修改操作只与前台定义相关，而迁移条件必须依据后台定义设置，这意味着实现一个修改操作必须了解后台定义模型以便生成正确的迁移条件。 迁移算法在检查迁移条件后执行实例迁移，只要有一个迁移条件不满足，演进策略就将被激活（参见4.2）。迁移算法工作在后台定义的层次上，不需要任何前台定义的知识。 由于修改操作直接依赖于前台定义语言并且要生成不同的迁移条件，因此采用不同的前台语言必然导致修改操作重新实现，而迁移条件按后台定义设置，迁移算法可独立于前台定义语言得到重用。 4.2 演进策略 如上所述，工作流实例迁移依赖于对一组迁移条件的评估，对不满足迁移条件的实例，可采用以下三种方式： (1)abort——放弃此工作流实例的执行。 (2)complete——依据老的wft定义完成此实例的执行。 (3)rollback——回滚实例直到可以进行迁移操作的执行点。 前两种动作很简单，但都有缺点。abort将浪费大量已完成的工作，而complete要求实例运行在一个已过时的wft上，一般是不能接受的，rollback策略则克服了前两种方法带来的问题。rollback动作由单步的undo操作组成，先分析实例的执行历史，然后针对每个活动执行undo操作，通过不断的undo操作来更新执行历史，直到所有的迁移条件都满足。 和迁移算法一样，rollback算法也工作在后台定义上，因此它可以独立于前台定义语言而获得重用。 5 演进组件体系结构 依照上述原理，本文设计了一个工作流演进组件，此组件对工作流管理系统提供三个支持：wft版本化管理、实例迁移管理、定义语言无关支持，以此来实现支持多语言的工作流动态演进策略。图4是该组件的体系结构图，其在逻辑上可分为三个模块：版本管理器、迁移管理器、内容管理器，如此划分可提供良好的复用性。版本管理器对wft版本进行管理，要提供3.2中所描述的第一类操作。迁移管理器提供迁移算法、演进策略并且对迁移条件进行检测。这两个模块都工作在后台定义上，可以得到完全复用。通过前面讨论可知，要支持不同的工作流定义语言，与前台定义语言相关的修改操作是不可复用的，内容管理器正是来完成这一工作，它能提供3.2中所描述的第二类操作，将不同定义语言带来的影响限制在一个模块内。

工程管理定义篇(4)

第一种含义：工程造价是指建设一项工程所需要的全部投资费用。包括建筑工程费、安装工程费、设备费以及其他的相关费用，这实质上是指建设项目的建设成本，也就是对建设项目的资金投入。这一含义是从投资者―业主的角度定义的。

第二种含义：工程造价是指发包工程的承包价格。发包的内容有建筑、有安装，也有的是包括建筑安装在内的“交钥匙”工程，但主要是指施工的承包价格。这一含义是以社会主义商品经济和市场经济为前提的。

对施工企业，实施并加强对工程造价全过程的管理正是为适应建筑市场这种多层次、多元化的发展趋势，满足不同投资者不同投资目的对工程造价所提出的不同要求。因此，工程造价与建筑施工企业密切相关。本文重点就建筑施工企业加强工程造价管理，即加强对发包工程承包价格的管理谈几点认识：

一．施工承包价格的宏观调控和监管机制

施工承包价格指施工企业接受委托承担工程建筑、安装等任务以货币表现的交换值。

施工承包价格是建设项目所需全部费用的重要组成部分，它直接影响建设工程造价的高低，同时与施工企业的利益紧密相关。因此，它是基本建设领域中的一项重大课题。

在计划经济的体制下，施工承包价格是通过编制施工图预算或概算来确定的。无论前者还是后者，它们是以国家及各省规定的建筑工程预算定额、费率、指标等依据编制的。这是在计划经济条件下对施工承包价格的调控和监管，因而它反映了国家的标准定价、实质上实行着国家定价制。

在社会主义市场经济体制下，施工承包价格一般是通过招投标工作来实现的，施工承包合同价格等于中标价格加变更增减及合同规定允许调整的费用。在招投标阶段，建设单位根据国家、当地政府规定的现行定额、费率、单价、工程量计算规则及施工图纸编制标底，这是对施工承包价的宏观控制。这与计划经济有着很大不同的是：参加竞争投标的各施工单位，他们的报价除按照招标文件和国际及有关定额规定编制外，还必须建立在企业自我测算的基础上，并适合于本企业的定额，按照可以争取达到的先进合理水平来确定，兼备可行性和先进性，以确保在投标中获得有竞争力的价格优势。投标单位的报价需要由建设单位组织各有关专家组成评标小组来进行工程评标。与技术措施、施工方案、进度安排、质量保证、社会业绩等因素结合起来，判别其可靠性、合理性。为此，有关方面已出台评标规则（包括工程报价与标底的允许偏离幅度），以指导和调控定标工作，合理决定施工承包价格。这就是在社会主义市场经济条件下对施工承包价格的宏观调控及监管。

二．对加强工程造价管理的几点认识

在工程中标以后，建筑施工企业在施工全过程中加强对工程造价的管理是提高企业经济效益的关键。根据多年的实践探索，对加强工程造价管理有以下的认识。

1．签订公平合理的合同是做好工程造价管理的基础

在工程中标以后，施工单位将与建设单位签订工程施工合同，合同签订时双方应处于平等地位，合同本身也应具有公平性。合同一经签订便成为日后双方行为的准则，单方不得擅自变更或解除合同。同时我们也应意识到合同的严肃性，从工程造价角度看合同中的每一句话都有可能成为日后双方争论的焦点，因此在中标之后的签约阶段，承包商应据理力争签订公平合理的合同，为工程造价管理打好基础。

合同条款中语言应周密、详实，不能给予模棱两可的解释，任何模棱两可这方面的文字，都可能给承包商造成不应有的损失。

合同条款中应明确双方权利、义务和责任。我们知道，承包商一般至少具有以下权利：⑴享有工程预付款的权利；⑵按期收回工程款及逾期利息的权利；⑶遇有不可抗力或不可预见事件时索赔的权利；⑷业主违约时停止履行合同的权利。承包商在限制业主提出过分要求的同时，应依据国家及当地政府规定的管理办法，结合实际情况争取更多的权利。

2．工程施工期间的全方位管理是加强工程造价管理的重要环节

工程在施工过程中，承包商应“以合同为依据，以事实为基础”，充分发挥主观能动性，做好全方位的造价管理工作。

（1） 做好工程量的计量与计价

工程量的统计，是造价管理中一项最基本的工作，在造价管理中地位举足轻重。统计人员应熟悉施工现场的情况和概（预）算方面的知识，不错算漏算工程量，与预算人员密切配合，善于发现可以进行索赔的因素，如实做好统计保量工作。

（2）做好工程实施中的索赔工作

造价管理人员应熟悉合同规定，善于发现可以进行索赔的因素，维护自己的合法权益。最常见的索赔有：延误工期索赔，变更索赔，不可抗力索赔等。同时要注意索赔的程序及索赔有关资料的整理，以作为日后索赔工作的依据。

（3）建立良好的造价管理系统

造价管理部门在承包商内部应处于造价管理的核心地位，其他各部门应与其密切配合，材料采购清单及发票复印件、工程变更、技术交底、施工方案、生产计划安排等资料及时递交造价管理部门。然后由该部门人员在此基础上进行分析比较，定期进行核算，当发现预算用量与实际用量有较大出入时，应分析是预算原因还是施工管理的原因，并相应采取不同措施。

3．技术方案与经济管理的结合是加强工程造价管理的一项重要工作

技术与经济的关系，技术是手段，经济是目的，通过科学的技术手段达到良好经济效益的目的。两者相辅相成，忽视任何一个方面，都会有不良后果。如果为了保证质量，不惜代价地提高建筑标准，使工程费用超出了工程合同造价。反之，如果我们制定的施工组织设计和施工方案，在考虑保证工期和工程质量的同时，严格控制工程成本，厉行节约，提高企业经济效益，使工程的工期和质量得到可靠的保证。因此，技术方案与经济管理的结合，对加强工程造价管理，提高企业经济效益，将起着重要作用。

工程管理定义篇(5)

1.概述

Primavera 6.1

由美国Primavera 公司开发Prim avera Pro ject P lanner(简称p3)是目前项目管理软件中佼佼者, 其最新版本为Primavera 6.1 forW indow s V ista。Primavera 6..1首先是基于广义网络计划技术的理论编制的项目管理软件, 也是目前唯一能够在C / S结构和B /S 结构下都能运行的软件( Brow ser/ Server) 。

2. Primavera 6.1在项目管理中的应用

2.1Prim avera 6.1的管理理念

P6系统涉及项目范围管理、项目时间管理、项目费用管理、集成管理、风险管理等 的项目管理知识领域，它通过在作业项加载资源和费用信息形成广义网络，增强了其功能。该系统的功能设计完全符合项目管理协会的项目管理理念，用户使用这些功能，在工程项目管理的实际工作 中发挥了重要作用，很多用户也在原有功能的基础上，通过灵活使用，使该系统在项目管理方面提供了更多有意义的帮助信息。

2.2P6.1进行项目管理前的准备工作

由于工程项目管理系统可分解为进度管理子系统、成本管理子系统、质量管理子系统和合同管理子系统等, Primavera 6.1 在进行项目管理前需要完成以下几方面的工作:

( 1)项目的定义: 对项目的总体和各个细节进行定义, 通常包括: 项目总体的定义, 包括项目名称、代码、地点、企业名称、开始时间、限定结束时间、备注等; 日历的定义, 项目的各种工期、成本、资源等计划和控制都按日历进行的, 可以小时、日、周、月作为计划单位;

( 2)工程活动及其持续时间的定义, 工程活动数量不应有限制, 否则对于大型项目将造成不便;

( 3)成本的定义, 对项目可以定义任意个成本项目, 计划成本可以通过按工程活动或工作包的成本总额, 成本额/单位时间, 成本额/单位时间/成本项目等输入。

3.以下就是关键的技术准备

3.1项目前期准备

( 1)项目定义: 根据实际情况录入各种信息, 包括的项目名称、货币类型、代码、企业名称、项目开始、结束日期等。

( 2)资源定义: 项目运作初期, 各资源种类、用量是根据以往经验估计的, 如果具体人力资源不祥, 只能安排岗位的设置。

3.2设计管理

( 1)根据费用分解所估算的权重和图纸数量完成对各区域、各子项的情况分析, 并在作业窗口把信息录入相应作业中。

( 2)随设计进度的推进, 不断更新在P3E /C 中图纸完成情况百分比(工期百分比, 实际百分比, 数量百分比)。

3.3采购及运输管理

根据设计组提出的采购数据页、综合材料表及施工图纸等信息, 手动连接逻辑关系到采购工作的分包商谈判, 分包商考察、设备监造等作业, 进度计算后会自动生成作业计划开始时间, 在根据经验和历史数据手动输入工期, 由于可能用到资源情况的不确定性, 对于资源的设置在此暂不录入, 只考虑费用。运输管理要与采购管理紧密结合, 将设备的出场时间与运输的开始时间设定逻辑关系。

3.4施工管理

( 1)进度控制: 在项目进度管理中, 首先通过一级网络计划, 确定工程建设进度的最终目标。按照一级网络计划确定的目标, 进一步将整个工程进度分解为四个阶段目标, 以保证一级网络计划进度目标的实现。进一步将四个阶段的目标任务, 继续分解到每月、每周, 并将周计划分解到日计划管理体系。

( 2)各类施工文件的保存与调用: 这其中涉及到各种报告、事故单、变更等等, P3E /C 还可以实现网络上的, 令进度工程师实现远程管理操作。

3.5 查阅

( 1)视图保存: 此功能满足了不同审阅者的不同检查要求, 使得他们关心的信息第一时间呈现眼前, 提高数据的分析效率。

( 2)过滤器: 灵活方便, 满足自定义, 是项目管理者审阅的得力助手。

( 3)分组排序: 此功能使用前提是设置有分类码, 否则达不到快速简便查阅的效果。但是提供了一种查阅方式, 为使用者提供了方便。

( 4)跟踪: 随鼠标点击出现横道图, 直方图等详情, 非常便于具体作业或WBS情况查询。

4.结 论

项目资源管理是项 目管理的重点内容，因为重大资源一般是制约工期的关键因素。P6系统通过 在时间计划上加载资源的方式，实现资源计划网络化，并进行多项目的资源平衡与分析，为资源计划提供了有效的帮助信息。综上所述，P6系统在工程项目管理中的科学应用，将为项 目实施合理配置资源、有效控制费用 提供有效的分析，对优化资源计划、降低项目成本奠定了良好的基础。

参考文献：

[1]何丰．从Primavera (P3e／c)学 项 目管理[M]．中国建筑工业出版社，2007年 l1月．

工程管理定义篇(6)

随着知识经济的极大发展，企业的经营管理在发生着深刻的变化，企业中“人”的地位不断提高，企业开始要求员工更广泛、更积极地投入企业运作，并通过员工不断的学习和自身能力素质的提高，来达到企业繁荣和发展的目标。这种知识经济所倡导的管理模式，也可以称之为“人本主义”的管理模式，这种模式正在为越来越多国家的企业所采纳。

但是同样的模式在互不相同的国家当中实施，是否都能发挥其作用，从而实现企业的经营目标呢？据国际调查显示，国际间经济合作的失败，只有30％是由于技术、财务或战略方面的原因造成的．与之相对，倒有70％的失败在于人员之间的跨文化沟通。正如荷兰学者霍夫斯坦特所指出的，在过去的研究中，理论家和企业家都忽视了文化与管理的关系，这是管理学发展的一大弱点。而事实上，管理不是处理具体的东西，而是处理对于“人”有意义的信号，这种信号是在家庭、学校、社会等特有的文化背景下形成的，因而文化必然渗透于管理和组织的全过程。（Hofstede，1980）

一、企业当中的人本主义管理模式

知识经济之下为各国企业所大力倡导的人本主义管理，我们这里将其内容概括如下：

1、员工借助于工作小组，任务团队或质量圈等活动，广泛地融入和参与管理。

2、通过工作流程设计，使员工的工作更富有灵活性，并体现出责任感。

3、为员工提供更大的职业稳定性。

4、为员工在工作当中提供学习的机会，使他们不断进步。

5、员工培训的着眼点不仅仅是掌握某种技能，更强调员工的自我发展和完善。

6、构建员工和管理者之间和谐的关系。

7、构建基于员工工作业绩的奖励制度。

就我们所知，上述人本主义管理模式正在各国企业中广泛被采纳和实施。但是由于民族文化差异性的存在，这些政策的实施效果在各国又是各不相同的。

知识经济所倡导的人本主义管理，其政策的出发点和目标都在于“人”，即如何使企业中的人充分发挥其才能。而人又是生在文化中，长在文化中的，作为企业的管理者，由于文化的差异性，他们首先在管理理念上便存在着不同，这种理念被带入管理行为当中，反过来又对最初的理念起着强化作用。作为企业当中的员工，内心深处都有民族文化的烙印，这会使他们形成在工作中应该怎样被对待的模式，以及对不同的管理措施做出什么样的反映。因而人本主义管理在诸多管理形式中对文化的差异性表现得最为敏感。

因而很多专家都告诫那些跨文化管理者，在本国被认为是非常有效的人本主义政策，比如在美国，到了其他国家则未必是起作用的，比如到了日本和欧洲。因此他们认为挑选一种适合的人本主义政策是非常必要的，必须要使之适合于本民族和本国企业的文化氛围。

二、文化的差异性及其指标

文化一词定义很多，霍夫斯坦特从管理心理学的角度所下之定义是被管理学界广为接受的一种，他认为文化是一组织成员或者一种区划下的人群在精神气质方面的集体性特征，这种特征使之与其他组织或人群区别开来。因而在这一群体之中总会存在某些行为习惯、思考方式和看事物的角度是为这一共同体的成员所特有的，人们通过成为一个组织的成员而学会这个组织的文化，人们往往在有意或者无意之中坚持着自己所在共同体的价值与信念，但又往往意识不到自己所在共同体的价值与信念对自己的刻骨铭心的影响，通常是在与来自其他文化的人们打交道时才真正感知自己所在的文化。

基于上述定义，霍夫斯坦特针对跨国公司的雇员，进行了遍及四十个国家，长达七年，资料总数包括116000张问卷的大规模调查，然后提出了四项描述民族文化差异的指标，即民族文化四维度，其内容包括：

1、权力距离（powerdistance）。即在一个组织当中，权力的集中程度和领导的独裁程度，以及一个社会在多大的程度上可以接受组织当中这种权力分配的不平等，在企业当中可以理解为员工和管理者之间的社会距离。一种文化究竟是大的权力距离还是小的权力距离，必然会从该社会内权力大小不等的成员的价值观中反映出来，如果领导上的集权和专断是深植在员工的头脑中的，成为一种理所当然的现象，那么权力分配的不公平是不会影响到组织的稳定的。

2、不确定性避免（uncertaintyavoidanceindex）。在任何一个社会中，人们对于不确定的、含糊的、前途未卜的情境，都会感到面对的是一种威胁，从而总是试图加以防止。防止的方法很多，例如提供更大的职业稳定性，订立更多的正规条令，不允许出现越轨的思想和行为等等。不同文化，防止不确定性的迫切程度是不一样的。相对而言，在不确定性避免程度低的社会当中，人们普遍有一种安全感，倾向于放松的生活态度和鼓励冒险的倾向。而在不确定性避免程度高的社会当中，人们则普遍有一种高度的紧迫感和进取心，因而易形成一种努力工作的内心冲动。

3、个人主义与集体主义（individualismversuscollectivism）。“个人主义”是指一种结合松散的社会组织结构，其中每个人重视自身的价值与需要，依靠个人的努力来为自己谋取利益。“集体主义”则指一种结合紧密的社会组织，其中所有的人往往以“在群体之内”和“在群体之外”来区分，他们期望得到“群体之内”的人员的照顾，但同时也以对该群体保持绝对的忠诚作为回报。

4、男性度与女性度（masculinityversusfemininity）。即社会上居于统治地位的价值标准，对于男性社会而言，居于统治地位的是男性气概，如自信武断，进取好胜，对于金钱的索取，执着而担然，而女性社会则完全与之相反。

通过对上述文化四维度调查数据的分析，霍夫斯坦特证实了不同民族的文化之间确实存在着很大的差异性，而且这种差异性是根植在人们的头脑中的，很难轻易被改变。

三、人本主义政策的文化模型。

文化会从内部和外部两个方面影响员工对于职业的看法。首先，在内心深处，每个员工都有自身的文化背景，这会使他们形成一种思维定势，从而影响他们在工作中希望被上司怎样对待，以及对于不同的人本主义政策采取怎样的态度。这必定会影响到管理者对政策的选择和执行。其次，在外部，文化会影响组织价值观念的选择和组织规范的构架，进而影响人本主义管理政策的选择。而所有这些政策选择反过来又会强化组织原有的文化。

下面我们结合上述通行的人本主义管理模式和霍夫斯坦特的民族文化四维度理论，来构建不同文化之下企业人本主义管理政策选择的模型：

1、依据文化四维度理论，较大的权力距离，在企业当中表现为等级顺序比较严格，不同等级之间存在着事实上的不平等。所以我们认为大的权力距离容易造成拥有权力者与没有权力者之间潜在的矛盾和冲突，所以也就不利于创造员工与管理者之间的和谐关系（人本政策6）。此外，大的权力距离还会造成下属对上级有一种强烈的依附需要，下属对上级惟命是从。因此我们认为大的权力距离使组织缺乏活力，不利于激励员工在工作当中学习和不断进步（人本政策4）。

例如，美国是权力距离相对较小的国家，美国员工倾向于不接受管理特权的观念，下级通常认为上级是“和我一样的人”。所以在美国，员工与管理者之间更平等，关系也更融洽，员工也更善于学习、进步和超越自我，实现个人价值。中国相对而言，是权力距离较大的国家，在这里地位象征非常重要，上级所拥有的特权被认为是理所应当的，这种特权大大地有助于上级对下属权力的实施。这些特点显然不利于员工与管理者之间和谐关系的创造和员工在企业中不断的学习和进步。因而要在中国的企业当中采纳“构建员工与管理者之间和谐的关系”以及“为员工在工作当中提供学习的机会，使他们不断进步”这两项人本主义政策，管理者有必要在实践当中有意识地减小企业内部权力之间的距离，才会更好地实现管理目标。

2、依据文化四维度理论，不确定性避免程度高的社会，人们通常认为离经叛道的人和思想是危险的，因此强烈要求一致性，相比较带有冒险意味的个人决策，他们更喜欢群体做出决策。所以我们认为不确定性避免程度高的社会更容易动员员工参与到管理当中（人本政策1），也更愿意提供更大的职业稳定性（人本政策3）。

例如，日本是不确定性避免程度较高的社会，因而在日本，“全面质量管理”这一员工广泛参与的管理形式取得了极大的成功，“终身雇佣制”也得到了很好的推行。与此相反，美国是不确定性避免程度低的社会，同样的人本主义政策在美国企业中则不一定行得通，比如在日本推行良好的“全面质量管理”，在美国却几乎取不得成效。中国与日本相似，也属于不确定性避免程度较高的社会，因而在中国推行员工参与管理和增加职业稳定性的人本主义政策，应该是适合的并且是有效的。

3、不确定性避免程度低的社会，人们较容易的接受生活中固有的不确定性，能够接受更多的异见，上级对下属的授权被执行的更为彻底，员工倾向于自主管理和独立的工作。而在不确定性避免程度高的社会，上级倾向于对下属进行严格的控制和清晰的指示。所以我们认为不确定性避免程度低的社会更适合于构建灵活的工作制度（人本政策2）。此外，在不确定性避免程度低的社会当中，基于员工工作绩效而开展的职业竞争被认为是公平的和合理的（人本政策7），而在不确定性避免程度高的社会，员工会强烈地排斥这种竞争。

例如，美国是不确定性避免程度低的社会，因而灵活的工时制度、弹性工作制等都是发源自美国，员工之间的个人竞争也是美国企业取胜的法宝。中国是不确定性避免程度较高的社会，同样的人本主义政策则未必能激发起员工的工作热情。

4、个人主义与集体主义之间的关系代表一个社会对个人权力的看法。在崇尚集体主义的社会当中，员工对于组织怀有忠诚感和效忠心理，工作中倾向于群体的努力和集体的回报。而崇尚个人主义的社会则相反，倾向于个人的至高无上的权力。所以我们认为崇尚个人主义的社会更适合于采纳基于员工表现的奖励制度（人本政策7）。

美国是崇尚个人主义的社会，强调个性自由及个人的成就，因而开展员工之间个人竞争，并对个人表现进行奖励是有效的人本主义激励政策。中国则相反，这种激励手段未必会取得同样的成效，这也与我们的上述论点达到了不谋而合。

5、在崇尚集体主义的社会当中，认为归属于组织，取得成员身份是一种美德。所以我们认为崇尚集体主义的社会更易于创造员工和管理者之间融洽的关系（人本政策6）。

中国和日本都是崇尚集体主义的社会，员工对组织有一种感情依赖，应该容易构建员工和管理者之间和谐的关系。但是就我们上述模型1的论述，中国和日本又属于权力距离相对较大的国家，有权者与无权者之间存在着潜在的冲突，这又不利于形成员工与管理者之间融洽的关系。由于这两种指标逆向性的存在，我们该如何来判断中日两国文化是否适合于采纳“构建员工与管理者之间和谐的关系”这一人本主义政策呢？这里就要取决于管理者的操作技巧，即如何扬长避短，来实现管理目标。在这一点上，日本企业的做法值得借鉴。日本社会等级制度森严，但同时又崇尚国家、集体至上，其企业就很好地利用了这两个特点，他们在企业当中大力倡导集体主义，使之在员工和管理者的价值观当中居于主导地位，对于依然存在的等级观念，他们把其消极影响降到了最小，即采取把权力和等级在员工之间进行平等分配的方式，实行根据员工的资历缓慢进行升级的“年功序列制”。这样，大的权力距离所形成的负面影响被包容于集体主义精神所带来的正面影响之中，没有影响到员工与管理者之间和谐关系的构建，这也是日本企业成功的原因之一。中国企业由于与日本企业有着相似的东方文化背景，因而也面临着相似的人本主义政策问题，这就需要管理者因地制宜、相机抉择，来实现以人为本的管理目标。

6、在男性度较高的社会当中，人们倾向于强烈地追求成就感，认为个人决策的质量高于群体决策，决策者之间通常不愿采取合作的态度。所以我们认为男性度较高的社会不利于员工积极地参与管理（人本政策1）。

工程管理定义篇(7)

关键字： 工作流； 动态工作流； 修改策略； 状态迁移策略

中图分类号： TN964?34 文献标识码： A 文章编号： 1004?373X（2014）06?0062?03

工作流的概念最早出现在生产组织和办公自动化等领域，这是由于这些领域日常的工作流程都是具有固定的流程，为了提高工作效率提出了工作流的概念，它是将工作分解成分工明确的任务或角色，不同角色之间按照一定的规则和顺序来执行这些任务[1]，这样就能够达到提高工作效率、提高企业管理水平和企业竞争力的目的。早期的工作流管理系统是在软件设计阶段完成过程定义的设计，系统执行期间用户只需按照步骤完成操作，然而，一旦工作流系统启动后，工作流的执行过程就不会发生改变，只能根据事先定义的流程进行，需要改变工作流程时就必须重新进行软件设计，造成资源浪费。随着科学技术和市场经济的不断发展，多数企业处于一个快速连续变化的环境中，他们的业务过程也在持续不断的变化，企业希望他们的信息系统能够快速地应对这种动态性变化，但是传统工作流系统一旦启用后不能再发生任何改变，仅仅依靠前期的一次静态定义已经不能满足现代企业的需求。动态工作流的概念就是为了解决这一问题而提出的。

1 动态工作流概述

一个并开始执行的工作流系统包含特定的工作流程，流程对应现实的工作过程。然而，这个现实过程会因为实际情况发生改变，这时就需要对计算机中的工作流程进行改变。这种能够根据实际情况改变工作流程的计算机系统就称之为动态工作流系统[2?4]。动态工作流主要体现的是动态修改，同时，修改发生时需要有一定的修改策略，下面是对修改的不同类型以及修改策略的分析。

1.1 动态修改分类

工作流在运行期间可能发生多种方面的动态修改，本文主要从过程的动态修改方面研究，常见的动态修改有以下3种形式[5?6]：

（1） 任务的增加或删除（如A、B两个连续的任务之间增加新的任务C）；

（2） 任务被其他一些任务替换（如原有的任务A换为任务B）；

（3） 任务的执行顺序改变（如两个任务的执行顺序颠倒、串行的任务变为并行）。

1.2 修改策略分析

当过程定义变更发生时，它有可能影响运行中的案例，工作流引擎需要对这一变化进行快速响应，工作流要完成从旧的过程定义到新的过程定义的修改策略，常见的修改策略有[7?9]：

（1） 重启：丢弃运行中的工作流实例，按照新过程定义重新启动一个工作流实例；但是这种策略由于要丢掉正在运行的实例，会造成大量资源浪费，这需要付出很大代价。

（2） 继续执行：正在运行的实例不做任何处理，继续执行原有的流程，新启动的实例执行新版本的实例；这种策略对于实际发生的变化不能快速响应，缺少灵活性，也就缺少了动态修改的意义。

（3） 迁移：将正在运行的工作流实例按照某种规则转换到新的过程定义中继续执行；这种策略能够快速应对实际发生的变化，使用这种策略最能体现动态性，也是本文研究动态工作流修改策略的重点。

2 系统设计

工作流系统是通过人与计算机协同工作的管理系统，它辅助人来完成具有特定流程的工作，因此，本设计的工作流系统首要职责是它能够帮助用户定义的工作流程；还包含工作流过程定义的制定；指定过程定义的实施，用户能够使用制定后的工作流程；以及废弃的工作流过程定义的删除与备份。其次，它具有动态性，现实的工作过程发生改变，管理员用户可以通过管理员界面修改系统正在运行的工作流模型，提交修改后的工作流，工作流系统将这个新工作流模型动态实施新的工作流实例以及正在运行中的实例中。

2.1 系统结构

为了实现工作流系统的动态性，参考了工作流管理联盟提供的参考模型，以.NET框架为基础，采用3层体系结构设计而成，系统结构如图1所示。

2.2 表示层

表示层是用户界面，分为2种：普通用户界面和管理用户界面。普通用户界面是工作流程的显示界面，主要面向的是普通用户，普通用户使用这个界面完成正常的工作流程；管理用户界面是工作流系统的实例和过程定义的管理界面，是面向管理员用户的，管理员通过这个界面来定制、实施、修改、删除工作流过程定义，还能管理正在实施的工作流实例及查询已经完成的工作流实例。

2.3 业务逻辑层

该层主要包括工作流执行服务以及基础业务2个部分。工作流执行服务部分完成工作流管理的功能；基础业务部分完成辅助功能，下面是这两层的具体设计。

（1） 工作流执行服务。工作流执行服务是用户与工作流引擎之间的桥梁，它实现了用户界面与工作流引擎的分离，它负责管理工作流实例和响应用户服务请求，是整个工作流管理系统的心脏，其主要功能如下：

① 与外部资源交互完成各项活动，为用户提供应用接口，接收用户的服务请求并做出响应；

② 实例化工作流引擎，根据用户的工作流服务申请查找工作流表，得到工作流关联的类名，使用C#反射机制创建对象；

③ 管理运行中的工作流实例，包括异常结束的工作流实例处理，结束后的工作流实例的资源释放等。

（2） 基础服务。基础服务部分不是工作流管理系统的一部分，它是与实际工作的执行相关联的，包含实际工作中的应用、配置文件与数据库等，他们由工作流引擎调用完成工作流过程定义的所有任务。

2.4 数据访问层

数据访问层主要为系统提供与数据库之间的链接和操作功能。

3 关键技术

3.1 数据库设计

工作流系统的过程定义数据是在数据库中存储，数据库主要包括工作流表、状态表、状态转换表、用户组表、用户表、工作流历史表、状态历史表等几个表，表间关系如图2所示。

3.2 工作流引擎设计

工作流引擎是工作流系统的核心，工作流程的执行部分，它在正确的时间把正确的信息传递给正确的资源来执行，提供完成案例所需的后勤支持功能。有以下几个子模块组成：

① 解析工作流：从数据库中读出引擎需要的状态，状态转换，操作权用户等信息。

② 流程控制：控制工作流在正确的时间执行正确的操作，实现工作流整个流程与过程定义一致性执行，其主要包括工作流节点控制、转移控制以及状态控制。工作流实例在整个生命周期中会根据不同的资源情况，数据情况等工作在不同的状态中，这些状态控制工作流的执行，这些状态有：初始状态、运行状态、挂起状态、终止状态、完成状态[10]。

③ 信息记录：记录工作流运行历史，并将其写入工作流历史表和状态历史表。

④ 任务调度：基于反射机制实现，动态调用基础业务中的方法完成流程任务。

用户申请工作流的执行过程如图3所示。

3.3 工作流修改服务设计

工作流修改服务是工作流系统完成动态修改的核心部分，响应管理用户在工作流动态修改界面发来的工作流修改请求，将新的工作流过程定义数据加入到数据库中，同时在管理用户的协同工作下完成迁移规则的设定，得到迁移规则，其中旧工作流的每一个状态都有一个与之对应的新工作流中的状态，可以一个对多个，但是不能多对一或多对多，规则以XML格式描述，描述如下：

调用工作流引擎中的流程控制挂起工作流实例，查看当前工作流运行所处的状态，根据迁移规则得到迁移状态ID（新过程定义对应的状态），调用解析模块从数据库中加载迁移状态信息，流程控制将工作流设置为运行，之后沿用新的过程定义完成工作流实例。动态修改发生时系统执行过程如图4所示。

4 结 语

本文研究的动态工作流是以状态以及状态转换为基础，通过管理员用户与计算机协同完成迁移规则制定，使旧过程定义的状态与新过程定义中的状态一一对应，能够快速准确地完成工作流实例从旧工作流到新工作流的转换，极大地提高了工作流系统的动态性。

参考文献

[1] WFMC. Workflow management coalition terminology and glossary （WfMC?TC?1011） [EB/OL]. [1999?01?01]. http：///Workflow?Management?Coalition?Terminol.

[2] ELLIS C， KEDDARA K， ROZENBERG G. Dynamic change within workflow systems [C]// Proceedings of the Conference on Organizational Computing System. New York， NY， USA： ACM Press， 1995： 10?21.

[3] KRADOLFERM G A. Dynamic workflow schema evolution based on workflow type versioning and workflow migration [C]// Proceedings of the 4th IFCIS International Conference on Cooperative Information Systems. Edinburgh， Scotland： IEEE Computer Society， 1999： 104?111.

[4] 周明天，王敏毅，姚绍文.一种基于扩展任务模型结构的工作流实例迁移方法[J].软件学报，2003，14（4）：757?763.

[5] 万欣，刘强.工作流平台中动态流程模型的研究[J].计算机应用研究，2006，23（9）：69?71.

[6] 王建民，闻立杰.工作流管理：模型、方法和系统[M].北京：清华大学出版社，2004.

[7] 管昌生，蔡瑾.基于角色的动态工作流技术的研究[J].计算机与数字工程，2009，37（1）：77?80.

[8] 黄贤明，胡志刚.动态工作流研究[J].计算机与现代化，2009（8）：174?177.