Author: vpmiku

當談到 Visual Paradigm (“VP”) 時，我很肯定大多數讀者會立即將該主題與建模或建模語言聯繫起來，就像我一樣。而且我認為很難不這樣做。畢竟，VP 是一個屢獲殊榮的建模工具。 但是，儘管第一印像看起來非常清晰，但我認為當我們開始更深入地挖掘 Visual Paradigm 的一些更具體且可能較少提及的功能時，您可能會驚訝地發現您會發現什麼。其中之一是：信息管理。   什麼是“信息管理”？ 在我們開始之前，讓我們看看我們在這里處理的是什麼。簡而言之：處理可能來自不同來源的信息，並以目標受眾可以使用的方式進行處理。這聽起來很簡單，雖然可能有點抽象。現在，儘管我們可以爭辯說，建模過程本身也是一種信息管理形式，但這實際上不是我希望在這裡討論的方向。相反，我們將研究 Visual Paradigm 允許我們處理信息並在項目中使用它的幾種不同方式。 您會注意到許多功能在您使用的 Visual Paradigm 版本的基礎上變得更加廣泛。 Visual Paradigm 中的信息管理 最核心的是，它適用於所有版本，Visual Paradigm 為我們提供了文本分析圖。這是一種非常直接的方式，可以幫助我們啟動我們的項目；基本上，它允許我們獲取文本元素，例如關於某事的報告，手動提取我們想要可視化的信息片段，然後將它們作為模型元素或稍後使用的候選項目導入。 如前所述，我將忽略建模過程本身，但立即變得重要的是能夠將元數據添加到我們的大多數模型元素中。 在右側的屏幕截圖中，我打開了用例圖中使用的參與者模型元素的規範。項目管理選項卡允許我快速選擇預先確定的規範，然後可以幫助我在以後使用它。顯然也可以完全定制的規格。 當然，我們不僅限於使用預先確定的規格。“評論”和“標記值”選項卡都是提供有關元素本身的特定（自定義）信息的好地方。 報告 一旦我們收集了相當一部分信息並將其存儲為元數據，我們就可以使用它來提供自定義文檔來總結我們迄今為止收集的所有信息，Doc Composer和Project Publisher是一個很好的工具。 例如……使用項目管理選項卡，我可以在我的用例圖中優先考慮所有用例。然後，我為 Doc composer 設置了一個自定義模板，該模板檢查了我所有的用例圖並總結了那些具有高優先級的圖。然後，開發人員團隊可以使用該信息來獲得一些特定的項目方面，然後他們可以在他們的開發週期中給予更高的優先級。 這裡最好的部分是這個工作流程幾乎可以應用於項目中的幾乎每個模型元素。 但還有更多…… ITSM ITSM 或信息技術服務管理是幫助設計、計劃、交付、運營和控制 IT 服務的活動的集合，這些服務通常被公司用來為其客戶提供服務。它是一種更加抽象的信息處理形式，一般來說，它使用的管理方法比技術方法更多。這也是 Visual Paradigm 支持並幫助您管理的東西。 在 Visual Paradigm 的上下文中，主要區別在於，您的項目的重點將從通常以側面方式收集信息的情況（考慮存儲為元數據的信息）轉向信息的工作流。管理將成為您項目（或其當前階段）的主要目標。 引導過程 當然有一點問題。因為你從哪裡開始，如何開始？即使你決定自己分解……你可能需要開始收集信息，但任何具體的細節，也許是需要首先確定的具體目標或專業知識？ 嗯，這就是 Visual Paradigm 為我們提供 Guide-Through 過程功能的原因；一種完全符合當前製定的標準的方法，它將指導您完成整個過程。儘管 Visual Paradigm 將引導您朝著正確的方向前進，但您永遠不會被迫遵循該特定方法（儘管顯然強烈建議您這樣做）。 在這裡，我開始了幾個可用的 ITSM 程序之一：項目管理流程。整個生命週期由五個特定元素組成，本文的圖標也簡要顯示： 識別——檢查項目是否應該啟動。 啟動——指派一名經理，然後他可以定義項目的範圍。 計劃——制定計劃以確保項目按時完成。 執行和控制——開始工作吧！所有任務都在這裡解決。 收尾——記錄從項目中獲得的專業知識，並確保該文檔得到維護。 遵循五個不同的步驟，將允許您提供有關構成該特定項目的所有活動的信息，之後這些信息將匯集在一個 Word 文檔中，以形成您最終項目的基礎。 在這裡，我已經完成了第一步（識別），現在我準備自動生成四個文檔中的一個，它將提供識別和（重新）評估我的項目的特定部分所需的所有相關信息。 獨特的工作流程 此工作流程如此獨特的原因在於，您將完全專注於按特定順序提供所需信息，之後 Visual Paradigm 將收集所有部分以生成文檔。 您的項目將在每個單獨步驟之後保存並提交，這確保不會因僥倖事故而丟失任何數據（您基本上是在雲中維護備份）。 我個人認為非常有趣的另一個方面是，即使 ITSM 工作流程的行為與 Visual Paradigm 項目中的常規任務有些分離，整個事情仍然可以輕鬆共存。 例如：在我完成項目管理流程後，我可以導入我收集的所有信息，並將其導入我通常的 Visual Paradigm 建模工作流程中。因為所有生成的文檔都是項目本身的一部分，所以我總是可以在需要的地方添加參考。 即使該項目中存在 ITSM 工作流，我仍然可以處理項目的其他部分，例如建模或其他相關任務。我什至可以使用…continue reading →

在網上搜索，敏捷賢者認為用例和用戶故事是兩個不同的東西： Mike Cohn： 用戶故事不是用例 Alistair Cockburn： 用戶故事之於用例就像瞪羚之於涼亭 Extreme Programming.org： 用戶故事與用例的目的相同，但並不相同。 用例驅動方法是需求捕獲最熱門的技術之一，現在有些人認為它是一種過時的舊式技術，它與許多問題相關聯，導致您的團隊由於用例問題而不是“敏捷” ： 前期需求——試圖定義前期所有方面的細節將導致大量的精力和時間的浪費，因為很多工作都需要重做。 功能分解：用例的功能性質自然導致系統在具體和抽像用例方面的功能分解，這些用例通過擴展關聯並包括用例關聯。 如果你在網上搜索關鍵詞“用例 vs 用戶故事”，你會發現一長串關於用例方法的缺點、問題或陷阱的文章，而與用戶故事相關的好處甚至更長。 . 有趣的是，IT 行業的變化如此之快，對於人們從過去的“時尚”事物轉變為現在的“較新時尚”事物的人來說甚至更快。 有趣的是，有些人喜歡以二元模式感知事物，並通過象徵性地與它們相關聯來追逐時尚的東西，而不是真正地實踐它。有些人甚至不想讓其他人知道他們仍在使用用例，或者它們可能被認為是過時的和過時的。 現在有些人把用戶故事和用戶案例相關的等號： 敏捷 = 用戶故事或敏捷 = 用戶故事 + Scrum 用戶故事 = 恰到好處 & 及時 用戶故事=滿足用戶期望和滿意 用例 = 前期詳細需求捕獲 用例 = <<include>> + <<extends>> = 功能分解 用例是“用戶輸入”->“系統響應”唯一樣式 用例 = 舊式和過時 As a tool vendor, we are pretty neutral in methods, tools and techniques. Personally, I want to stress clear that I am a big fans of Agile development, user story and scrum process. Particularly, the underlining principles and best practices related to concepts such as:   Requirement discovery rather than requirement…continue reading →