pega的好处

让软件写软件
强化业务逻辑
在对组织有意义的地方运行应用程序
使用Pega的应用程序产品启动您的转换

团队成员：

1案例设计者（业务架构师和系统架构师）：和课题专家还有利益相关者开发系统
业务架构师：定义一个业务规则，服务等级协议和进程。是去理解用户需求和定义用户案例和特征的关键
系统架构师：应用开发者进行面向对象的设计和应用的实现
2课题专家设计一个业务逻辑
3利益相关者帮助去复查，重定义和提供解决方法

直接在应用中捕捉对象

Direct capture of objective(DCO)商业和it利益相关者使用一个分享虚拟模型去直接在应用中捕捉商业需求,帮助双方在商业目的中互相交流完成需求理解。

安装pega平台应用

最佳实践和护栏

最佳实践目的：都会至少有一个目标。如果组织遵循最佳实践，它可以通过最小化问题或并发问题去预测一个预期结果。

建立最佳实践的方法：

可以使用多种标准去帮助选择最佳实践，它将为应用程序开发提供可测量和可预见的交付。
最佳实践是否符合组织目标
最佳实践是否匹配组织架构
在使用时是否添加了必要资源
最佳实践的成本效益

pega已经定义最佳实践是去交付pega项目的关键。

利用ldco去提高产品质量：

DCO能使项目团队直接将业务需求输入到pega。DCO帮助去剔除转化错误，节省团队时间，提高效率，促进围绕可见工作模型的业务和IT资源的直接参与，并使项目参与者能够最佳地审查工作进度。

pega建议所有工程都利用dco作为一个交付过程的核心。

使用标准的pega性能

pega7有许多特征和性能被构建进产品中，使用pega性能，这已经被测试且证明是可靠的。例如，假设案例生命周期的一部分需要增加审查级别。使用Pega 7中提供的审批流程，而不是构建自定义的审查流程。您可以在构建自定义流程所需的时间的一小部分内设计案例的生命周期来支持您的需求。

构建时进行迭代和测试

在你的组织中会最多的使用敏捷和迭代交付模型。首先，会分离大的应用程序使它变得更小，更好的管理整合。例如，不是构建完整的应用程序然后一次测试全部完成的应用程序，而是增量地构建和测试各个流程。然后能够提供这些功能的相关演示给提供反馈的相关方。在项目比较早的时候进行测试可以去驱动更高等级的产品质量。

在所有等级中交流项目进程

定期交流可以帮助团队按时关注正确的问题

遵循pega护栏

pega护栏能帮助你去确保使用最佳实践来安装配置pega应用。pega护栏能使开发团队去追踪配置pega最佳实践，使其更容易维护和升级。
护栏是关于包含危险条件或可能导致不良结果的情况的最佳做法和指导。护栏确保您和您的团队正确使用Pega平台，并帮助您避免麻烦的情况。

设置一个生命周期循环

生命周期设计时一个技术模型常常被用于去描述商业应用如何工作。是每个工程的基础。商业应用会自动化工作以至于能达到特定的商业结果。例如，开一个账户，提出事故索赔，或在线订购商品。

一个可见的工作业务

为了帮助业务用户有效地实现业务成果，业务用户需要一种协同工作的方式。业务应用程序应该以业务用户自然地思考和描述其工作的相同方式运行。在Pega应用程序中，您使用case类型为可重复的业务事务建模。案例类型是业务事务的抽象模型，而案例是事务的特定实例。您可以将案例类型视为用于创建和处理案例的模板。当一个新的事务开始时，将根据案例类型定义创建一个新的案例。
用于以业务术语描述业务应用程序的建模技术在工作中被叫做生命周期循环设计。

阶段

阶段是在你的组织工作中的第一等级。它包含工作流，进程。用户在将案例转移到案例生命周期的下一个阶段之前会遵循以下步骤。
在案例生命周期中，导致预期结果的阶段被叫做primary stages。初始阶段的·顺序会被经常被叫做happy path.以新建住宅为例。如果你被要求把建造一所房子的任务组织成建造的关键阶段，你可能会把任务组织成三个阶段。任何建筑的地基都是第一阶段。然后房子本身——框架——就建造好了。最后，添加了屋顶。每个阶段代表了住宅建设案例生命周期的一个不同阶段。在住宅建设的例子中，基础、框架和屋顶是导致房屋完成的主要阶段，这也是商业成果。

交替的阶段

案件通常按顺序从一个初级阶段发展到下一个初级阶段。在某些情况下，工作并不总是按照计划进行。当这种情况发生时，用另一个阶段来描述解决问题所需的行动。Alternate stages用于组织不属于“正常事件过程”，但在某些情况下必须可用的流程步骤。例如，在建模在线订购应用程序的生命周期时，必须考虑订单可以在发货之前取消。如果订单被取消，则必须完成许多任务才能认为该订单已被取消。第一个任务是处理取消订单，然后必须退款，最后必须通知客户订单已被取消。使用备用阶段来组织用于从主路径管理异常的流程步骤。

定义阶段的指导方针

要定义阶段，请考虑以下指导原则。
**组织阶段：**阶段通常表示案例从一个权限转移到另一个权限，或者从组织的一个部分转移到另一个权限。阶段也可能代表案件状况的重大变化。
命名阶段：使用对业务用户最有意义和最相关的名称。使用名词或名词短语来描述这个舞台的背景。尽量把名字限制在两个字以内。
阶段的数量：考虑将任何给定情况下的初级阶段数限制为7个，交替阶段数限制为5个。如果您发现自己需要10个以上的初级阶段或5个以上的交替阶段，可以考虑将两个或两个以上阶段结合使用，或者使用单独的case类型。
在案例中阶段常常被作为组织工作的第一级

阶段过渡

阶段转换允许您进一步细化阶段的运行时顺序。
对于初级阶段，当一个阶段中的所有步骤都完成时，默认选项是自动转换到下一个初级阶段。若要在完成当前阶段之前允许转换到其他阶段，可以向阶段添加受控转换。受控转换可以配置为任何主要或备用阶段，并且可以作为步骤中的操作或流程中的特定步骤发生。
您可以配置一个步骤，以允许用户选择案例转换到的阶段。这种类型的配置对于需要确定是/否的步骤最有用。例如，案例工作人员必须审查请求，并且可以批准或拒绝请求。如果请求被批准，正常处理将继续，案例将推进到主路径中的下一个步骤或阶段。如果请求被拒绝，案例将推进到预定义的阶段，该阶段可能在主路径中，也可能不在主路径中。

您可以使用Change Stage流程步骤自动将案例流转换到指定的阶段。
这种类型的配置对于自动转换到交替阶段和从交替阶段转换非常有用。例如，一个被拒绝的请求被发送回发起者以进行更新。更新请求的流程步骤组织在一个备用阶段。当遇到Change Stage步骤时，案例流自动转换到Change Stage步骤中定义的阶段

控制阶段过渡

若要允许转换到交替阶段，或在某个阶段完成之前，可以向某个阶段添加受控转换。受控转换可以使用Change Stage smart shape作为流程步骤添加，也可以作为流程步骤中的可选用户操作添加。
使用批准/拒绝步骤来控制案例转换到的阶段。