BPMN：截止時間定時器是否需要自己的流水線？

Question

我使用BPMN捕獲我公司的正式軟件發佈流程。我們每個季度都會發布我們軟件的主要版本，並且在發佈日前的X天有一些門，例如「在T爲發佈日的情況下，在T負37天后的季度版本中不再增加範圍」。

編輯：網關以「爲此版本註冊項目」開始，按照「發佈設計文檔」和「發佈測試計劃」等關鍵文檔的截止日期進行操作，並指明完成實施，QA測試等的下載死亡日期。例如，如果QA測試在發佈日期前18天未完成，則該項目將從該季度的發佈中撤出。我想在這個流程文檔中捕獲它。

正確的方式記錄這些（據我所知）是使用像這樣的中斷定時器：

我的問題是，如果在所有情況下，計時器痕跡到同一位置爲基礎的活動，可能我省略冗餘流量/跟蹤線？在我看來，它會讓我的圖表雜亂無章，讓所有這些活動都跟蹤兩條線，每條線都與過程中的下一個點相同。

一些其他方面：使用BPMN仍然是不尋常的，在我的公司，我非常想創建「正確的」圖作爲建立的參考圖的集合，向其他人顯示的一部分。所以如果正式的正確方法是從活動和事件中追蹤，那麼我想這樣做。我希望有一個支持單一跟蹤的公認的約定。

編輯：我們的過程是，PM可以根據需要添加儘可能多的項目，直到截止日期，之後他們將不得不將項目放入後續版本。然而，在整個項目中，還有一大堆定時門，比如「QA測試完成和測試報告」，我們也必須要滿足。這個過程有六個或七個。

我在想，如果我能做到這一點，像這樣，發送定時到終點，以說明你有計時器到期之前完成活動或退出的過程：

，關於第一個答案得出另一種方法：

我喜歡這個從清晰度站立點最多。根據Silver的「BPMN規則」所述，「除了結束事件和拋出鏈接事件之外的所有流程節點都必​​須有一個流出的序列流......」，因爲該定時器被保證觸發。

Answer 1

考慮您的使用情況下，計時器事件可能不是一個很好的解決方案。 您的過程意味着項目已註冊一次（全部在一起），而您的文字說明建議項目可以多次添加一次發佈，因爲它們符合所需的截止日期。

因此，實際上，你有兩個過程：發佈

1. 註冊項目
2. 發佈軟件

發佈註冊項目常常由一個團隊領導或項目執行的過程經理，我想。

發佈軟件是發佈管理團隊（例如）執行的過程。

註冊項目發佈進程包含一些決定邏輯，用於決定項目註冊的發佈版本。該信息保存在版本軟件過程中要訪問的文檔/數據存儲中。

下面，你看到的過程（包括同一圖中）的草圖：

注意，決策邏輯是隱藏在一個業務規則任務。 當然，決策邏輯需要確定項目是否仍然可以添加到當前版本。這可以在獨家網關的幫助下完成。 但是，您可能需要考慮Decision Model and Notation，它補充了BPMN以更好地表示決策邏輯。