我正在使用BPMN捕捉我公司的正式软件发布流程。我们每季度发布一次软件的主要版本,并且在发布日的前X天有许多门,例如“在T减37天后,季度发布的范围不再增加”,其中T是发布日。
编辑:网关从“为此版本注册项目”开始,通过“发布设计文档”和“发布测试计划”等关键文档的截止日期,并指出完成实施、QA测试等的截止日期。例如,如果QA测试在发布日期前18天没有完成,则项目将从该季度的发布中提取。我想在这个过程中留档捕获它。
我的问题是,如果在所有情况下,计时器跟踪到与基本活动相同的位置,我可以省略冗余的流/跟踪线吗?在我看来,让所有这些活动跟踪两条线到流程中的下一个点会使我的图表变得混乱。
一些额外的背景:在我的公司,使用BPMN仍然不寻常,我非常想创建“正确”的图表,作为建立参考图集合的一部分,以向其他人展示。所以如果正式正确的方法是从活动和事件中跟踪,那么我想这样做。我希望有一个公认的约定支持单个跟踪。
编辑:我们的流程是PM可以在截止日期前将任意数量的项目添加到版本中,之后他们必须将项目放入后续版本中。然而,在整个项目中,我们也必须满足一堆时间门,例如“QA测试完成和测试报告交付”。这个过程有六七个。
我想知道我是否可以这样做,将计时器发送到终端,以说明您必须在计时器到期或退出进程之前完成活动:
另一种借鉴第一个答案的方法:
从清晰的角度来看,我最喜欢这个。根据Silver的“BPMN规则”,“除了结束事件和抛出链接事件之外的所有流节点都必须有一个传出序列流……”这个表示确实如此,因为定时器保证会触发。
考虑到您的用例,计时器事件可能不是一个好的解决方案。您的流程意味着项目注册一次(所有项目都在一起),而您的文本描述表明,如果项目满足要求的截止日期,则可以为一个版本添加多次项目。
所以实际上,你有两个过程:
我想,注册项目以供发布是团队负责人或项目经理经常执行的过程。
发布软件是由发布管理团队(例如)执行的过程。
发布过程的注册项目包含一些决定项目注册哪个版本的决策逻辑。此信息保存在文档/数据存储中,以便在发布软件过程中访问。
下面,您可以看到流程的草图(都在同一图中):
请注意,决策逻辑隐藏在业务规则任务中。当然,决策逻辑需要确定项目是否仍然可以添加到当前版本中。这可以在独占网关的帮助下完成。但是,您可能需要为此考虑决策模型和表示法,它补充了BPMN以更好地表示决策逻辑。