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