Cognos 部署經過驗證的實踐

by 約翰·博耶2022 年 10 月 26 日Cognos 分析, MotioCI0評論

如何充分利用 MotioCI 支持經過驗證的實踐

MotioCI 具有用於 Cognos Analytics 報告創作的集成插件。您鎖定您正在處理的報告。然後，當您完成編輯會話時，您將其簽入並添加評論以記錄您所做的事情。您可以在註釋中包含對外部缺陷跟踪或更改請求系統中的故障單的引用。

您可以找到有關如何設置之間的連接的其他詳細信息 MotioCI 和您的第三方票務系統 MotioCI 使用下的管理員指南 MotioCI 與第三方票務系統。一個關鍵字（修復，關閉) 與票號將關閉票。或者，使用類似的關鍵字引用加上票號會將簽到評論寫入票務系統並保持票證打開。

使用票務系統（如 Atlassian® JIRA、Microsoft Windows™ Trac 或許多其他系統）通過跟踪特定任務、問題及其解決方案來幫助項目管理。票據提供了作者或報告開發人員與最終用戶、測試團隊和其他利益相關者之間的溝通方式。票務系統還提供了一種跟踪缺陷並確保在將報告推廣到生產之前解決它們的方法。

報告開發的典型工作流程

需要明確的是，整合 MotioCI 使用票務系統並不是您的團隊與票務系統交互的唯一方式。通常，如隨附的工作流程圖所示，在 Cognos Analytics 環境中的報表開發過程與 MotioCI 可能是這樣的：

積壓. 將創建一個新票證。業務分析師記錄新報告的業務需求，並通過創建工單將其直接輸入工單系統。他把票放在積壓一直。
產業發展 . 積壓工單可以通過多種不同方式確定優先級，但最終工單將分配給報告開發人員並標有她的姓名。票的狀態可能會更改為 in_dev. 她將創建一個新報告。當她在 Cognos Analytics 中開發報告時，她將簽入她的更改並在簽入註釋中引用該票證，例如“已創建新報告；初始版本；添加提示頁面和支持查詢， 參考文獻#592”。 或者，“添加了事實查詢和交叉表；過濾器和格式， 參考文獻#592。” （在 MotioCI，主題標籤編號成為直接指向工單的超鏈接。）她可以在幾天內多次查看報告、進行更改並使用工單參考將其重新簽入。
開發完成。 報告開發人員完成報告並對其進行基準測試後，她在工單系統的工單中註明它已準備好由 QA 測試並從 in_Dev 至 準備好進行質量檢查. 這個狀態是一個標誌 MotioCI 管理員或負責推廣 Cognos 報告的角色，報告已準備好遷移到 QA 環境進行測試。
專業版motion 到 QA。 管理員將報告和狀態更改為 在_QA。 此狀態讓 QA 團隊知道報告已準備好進行測試。
測試。 QA 團隊根據業務需求測試報告。報告要么通過測試，要么失敗。如果報告未通過 QA 測試，則工單將標記為 在開發 狀態，返回給報告開發者進行修復。
測試成功。 如果報告通過，則 QA 團隊通過標記它來告訴管理員它已準備好升級到生產 準備好生產 一直。
專業版motion 到生產. 一旦報告準備好生產，就可以獲得最終批准並按計劃發布，可能與其他已完成的報告捆綁在一起。管理員將報告提升到 Cognos 生產環境。他把票放進去完成表示開發和測試已完成並已投入生產的狀態。這將關閉票證。

報告開發過程的管理

此工單管理流程意味著並且經過驗證的實踐表明：

每個新報告都應該有一張帶有設計報告的業務需求的票。
每個缺陷都應該有一張票來記錄報告中的任何錯誤或問題。
每次編輯報告時， MotioCI 簽到註釋應包括已處理的票號。
從 Dev 提升到 QA 的每個報告都應該有一個關聯的票證，管理員可以確認開發已經完成並且可以轉移到 QA 環境。
從 QA 升級到生產的每個報告都應該有一張歷史記錄表明開發完成、已通過 QA、已獲得所有必需的管理批准並已升級。
生產環境中的每個報告都應該有一個 digital 從概念到測試到修復到解決再到批准和專業的書面記錄motion.

最後一點是審核員最喜歡驗證的。她可能會問：“您能告訴我您如何確認生產環境中的所有報告都符合您記錄的票務和批准流程嗎？” 回應審計員的一種方法可能是提供一份所有已遷移報告的列表，並讓她仔細檢查票證以查找不符合您的流程的報告。

或者，更理想的是，您可以提供一份報告列表 任何監管機構都不批准 遵守您定義的開發和票務流程。這就是這份報告有用的地方：“無票推廣的報告”。這是一份報告列表的例外報告 任何監管機構都不批准 堅持將每個報告更改與工單相關聯的最佳實踐. 這是您希望為空的少數報告之一。如果所有已提升的報告都有與之關聯的票證，它將沒有記錄。換句話說，只有在生產環境中並且被提升的報告沒有在評論中引用票號時，該報告才會出現在列表中。

有好處的過程

這個過程有什麼好處，或者你為什麼要在你的組織中這樣做？

改進的團隊協作：票務系統實際上可以將可能無法正常交流的角色聚集在一起。例如，報告作者和最終用戶，或項目經理和 QA 團隊。票證跟踪提供了一個公共場所來交流共享資源，即正在開發的報告。
降低成本：
- 與逃逸到生產中的缺陷相比，儘早發現並修復缺陷的成本要低得多。
- 提高效率 - 報告作者總是從一個明確定義的工作說明中工作。
- 通過手動流程自動化縮短時間
改進的文檔：此過程成為缺陷及其解決方式的自我記錄知識庫。
改進的預測和分析：您現在可以跟踪關鍵績效指標並將其與服務水平協議進行比較。大多數票務系統都提供這些類型的分析。
改進的內部支持：您的支持團隊、其他報告開發人員（甚至是您未來的自己！）可以查看過去是如何解決類似缺陷的。這種共享的知識庫可以導致缺陷的快速解決。
提高最終用戶滿意度：通過票務系統直接訪問開發人員，用戶可以期望快速解決缺陷，並通過系統監控請求報告的進度。