ITSM:ビジュアルパラダイムによる情報管理

ITSM:ビジュアルパラダイムによる情報管理

ビジュアルパラダイム(「VP」)について話すとき、ほとんどの読者は、私と同じように、トピックをモデリングまたはモデリング言語にすぐに関連付けると確信しています。そして、そうしないのは難しいと思います。VPは、結局のところ、受賞歴のあるモデリングツールです。 しかし、第一印象は非常に明確に見えるかもしれませんが、ビジュアルパラダイムのより具体的であまり言及されていない機能のいくつかをもう少し深く掘り下げ始めると、何が見つかるかを知って驚くかもしれません。その1つは、情報管理です。   「情報管理」とは? 始める前に、ここで何を扱っているかを見てみましょう。簡単に言えば、おそらくさまざまなソースからの情報を処理し、ターゲットオーディエンスが意図したとおりに使用できるようにすることです。少し抽象的なかもしれませんが、それは十分に単純に聞こえます。さて、モデリングのプロセス自体も情報管理の一形態であると主張することはできますが、実際にはここで取り上げたい方向ではありません。代わりに、ビジュアルパラダイムによって情報を処理し、プロジェクト内で使用できるようにするいくつかの異なる方法を見ていきます。 使用しているビジュアルパラダイムエディションに基づいて、多くの機能がより広範囲になっていることに気付くでしょう。 ビジュアルパラダイムにおける情報管理 それは非常にコアであり、すべてのエディションに適用されます。ビジュアルパラダイムはテキスト分析図を提供します。これは非常に簡単な方法であり、プロジェクトを開始するのに役立ちます。基本的には、レポートなどのテキスト要素を取得し、視覚化する情報スニペットを手動で抽出して、モデル要素または後で使用する候補アイテムとしてインポートできます。 前に述べたように、モデリングプロセス自体は無視しますが、すぐに重要になるのは、ほとんどのモデル要素にメタデータを追加する機能です。 右のスクリーンショットでは、ユースケース図で使用されているアクターモデル要素の仕様を開いています。[プロジェクト管理]タブを使用すると、事前に決定された仕様をすばやく選択でき、後でこれを使用するのに役立ちます。明らかに完全にカスタマイズできる仕様。 もちろん、あらかじめ決められた仕様だけに限定するものではありません。[コメント]タブと[タグ付き値]タブはどちらも、要素自体に関する特定の(カスタム)情報を提供するのに最適な場所です。 報告 かなりの量の情報を収集してメタデータとして保存したら、それを使用して、これまでに収集したすべての情報を要約するカスタムドキュメントを提供できます。これは、DocComposerとProjectPublisherがそのための優れたツールです。 たとえば… [プロジェクト管理]タブを使用して、ユースケース図内のすべてのユースケースに優先順位を付けることができます。次に、Doc Composerのカスタムテンプレートを設定します。このテンプレートは、すべてのユースケース図をチェックし、優先度が高いものと高いものを要約します。次に、その情報を開発者チームが使用して、特定のプロジェクトの側面を持ち、開発サイクル内でより高い優先順位を与えることができます。 そして、ここでの最良の部分は、このワークフローがプロジェクト内のほぼすべてのモデル要素にほぼ適用できることです。 しかし、もっとあります… ITSM ITSM(Information Technology Service Management)は、ITサービス(通常、企業が顧客に提供するために使用するサービス)の設計、計画、提供、運用、および制御を支援するアクティビティの集まりです。これは、はるかに抽象的な形式の情報処理であり、一般的に言えば、技術的なアプローチよりも多くの管理を使用します。また、ビジュアルパラダイムがサポートし、管理に役立つものでもあります。 ビジュアルパラダイムのコンテキスト内での主な違いは、プロジェクトの焦点が、情報が横向きに収集されることが多い状況(メタデータとして保存された情報について考える)から、情報が収集されるワークフローにシフトすることです。管理は、プロジェクト(または現在のフェーズ)の主要な目標になります。 ガイド-プロセスを介して もちろん、少し問題があります。どこから始めて、どのように始めますか?そして、自分で物事を分解することにしたとしても…情報の収集を開始する必要があるかもしれませんが、特定の詳細、おそらく最初に特定する必要のある特定の目標や専門知識はありますか? これが、ビジュアルパラダイムがガイドスループロセス機能を提供する理由です。現在設定されている標準に完全に準拠し、プロセス全体をガイドする方法論。ビジュアルパラダイムは正しい方向にあなたを導きますが、あなたはその特定のアプローチに従うことを強制されることは決してありません(それは明らかにそうすることを強くお勧めしますが)。 ここで、いくつかの利用可能なITSM手順の1つであるプロジェクト管理プロセスを開始しました。ライフサイクル全体は、この記事のアイコンにも簡単に示されている5つの特定の要素で構成されています。 識別–プロジェクトを開始する必要があるかどうかを確認します。 開始–プロジェクトの範囲を定義できるマネージャーを割り当てます。 計画–プロジェクトが予定どおりに完了するように計画を立てます。 実行と制御–仕事に取り掛かりましょう!ここではすべてのタスクに取り組んでいます。 見切り–プロジェクトから得た専門知識を文書化し、この文書が維持されるようにします。 5つの異なるステップに従うと、その特定のアイテムを構成するすべてのアクティビティに関する情報を提供できるようになります。その後、この情報はWordドキュメントにまとめられ、最終的なプロジェクトの基礎を形成します。 これで最初のステップ(識別)が完了し、プロジェクトの特定のセクションを識別して(再)評価するために必要なすべての関連情報を提供する4つのドキュメントの1つを自動的に生成する準備が整いました。 独自のワークフロー このワークフローを非常にユニークなものにしているのは、必要な情報を特定の順序で提供することに完全に集中できることです。その後、VisualParadigmがすべてのパーツを収集してドキュメントを生成します。 プロジェクトは、個々のステップごとに保存およびコミットされます。これにより、まぐれ事故によってデータが失われることはありません(基本的にクラウドでバックアップを維持しています)。 私が個人的に非常に興味深いと思ったもう1つの側面は、ITSMワークフローがビジュアルパラダイムプロジェクト内の通常のタスクからいくらか分離して動作していても、すべてが簡単に共存できるという事実です。 たとえば、プロジェクト管理プロセスを完了した後、収集したすべての情報をインポートして、通常のビジュアルパラダイムモデリングワークフローにインポートできます。また、生成されたすべてのドキュメントはプロジェクト自体の一部であるため、必要な場所にいつでも参照を追加できます。 このプロジェクト内にITSMワークフローが存在する場合でも、モデリングやその他の関連タスクなど、プロジェクトの他の部分でも作業できます。doc composorを使用して、図やその他のオプションのメタデータに基づいてドキュメントを生成することもできます。 そして、これでこの部分は終わりです… これはシリーズの最初の部分であり、ビジュアルパラダイムによって提供されるいくつかのITSMベースの機能について詳しく説明します。この部分では、コンテキストは情報とプロジェクト管理に向けられていました。後の部分では、ビジュアルパラダイムにすぐには関連付けられない可能性のある他の特定の側面を調査します。continue reading →
ユーザーストーリーはユースケースと互換性がありますか?

ユーザーストーリーはユースケースと互換性がありますか?

アジャイルセージはウェブをグーグルで検索し、ユースケースとユーザーストーリーは2つの異なるものであると考えています。 Mike Cohn: ユーザーストーリーはユースケースではありません Alistair Cockburn: ガゼルが望楼にあるように、ユーザーストーリーはユースケースにあります Extreme Programming.org: ユーザーストーリーはユースケースと同じ目的を果たしますが、同じではありません。 ユースケース主導のアプローチは、要件をキャプチャするための最もホットな手法の1つであり、ユースケースの問題のためにチームが「アジャイル」ではなくなる多くの問題に関連する一種の時代遅れの古いスタイルの手法であると考える人もいます。 : 前払いの要件–前払いのすべての側面の詳細を定義しようとすると、多くの作業をやり直す必要があるため、多くの無駄な労力と時間が発生します。 機能的分解:ユースケースの機能的性質は、拡張によって関連付けられ、ユースケースの関連付けを含む具体的および抽象的なユースケースの観点から、システムの機能的分解に自然につながります。 「ユースケースとユーザーストーリー」というキーワードでWebを検索すると、ユースケースアプローチの欠点、問題、または落とし穴について示唆する記事の長いリストが見つかりますが、ユーザーストーリーに関連する利点のリストはさらに長くなります。 。興味深いことに、IT業界では物事が急速に変化し、以前は「トレンディ」だったものから現在の「新しいトレンディ」なものに切り替わる人々にとってはさらに速くなります。 興味深いことに、実際に本物の練習をするのではなく、物事をバイナリパターンで認識し、それらを象徴的に関連付けることで流行のものを追いかけることを好む人もいます。一部の人々は、他の人々にまだユースケースを使用していることを知らせたくない、または彼らは時代遅れで古いスタイルであると見なされるかもしれません。 現在、一部の人々は、ユーザーストーリーとユーザーケースに関連する等号を付けています。 アジャイル=ユーザーストーリーまたはアジャイル=ユーザーストーリー+スクラム ユーザーストーリー=ちょうど十分でちょうどいい時間 ユーザーストーリー=ユーザーの期待に応え、満足のいくもの ユースケース=事前の詳細な要件のキャプチャ ユースケース= << include >> + << extends >> =関数分解 ユースケースは「ユーザー入力」->「システム応答」のみのスタイルです ユースケース=古いスタイルと時代遅れ ツールベンダーとして、私たちは方法、ツール、テクニックにかなり中立です。個人的には、私はアジャイル開発、ユーザーストーリー、スクラムプロセスの大ファンであることを明確に強調したいと思います。特に、次のような概念に関連する下線を引く原則とベストプラクティス。   要件の配信ではなく、要件の発見 上記の原則の下で、アジャイル開発プロセスで2つの重要な特性が得られます ジャストインタイム 十分です (私は、1992年から1995年の私の博士課程の研究分野に密接に関連している私自身の意見で上記の原則に関連するより多くの投稿を書きます-メタモデルとスキーマ変換) それでは、「ユースケースとユーザーストーリー」のトピックに戻りましょう。ヘビーウェイトのアジャイルセージはすでにその票を投じていますが、私は彼らの「類似している、あるいは同じでさえあると主張することによって彼らの投票を覆そうとして頑固ですか? ユーザーストーリーがユーザーケースと「非常に異なる」かどうかを示す例を示しましょう。 例 優れたユーザーストーリーは、単なる発言以上のものです。標準のユーザーストーリーは、一般に3つのCと呼ばれる3つの部分で構成されます。 各ユーザーストーリーの最初の「C」は、次の標準化された形式に従う必要があります。 [役割]として、[何かをしたい]ので、[メリット] これは、カードに入れるユーザーストーリーの最小限のコンテンツです。 会話は、エンドユーザー、プロジェクトオーナー、および開発チーム間のディスカッションを表すユーザーストーリーの2番目の「C」の内容です。これらの変換では、口頭での話し合い、または電子メール、ワイヤーフレーム、その他のプロジェクト関連コンテンツなど、他の多くの有用な情報が記録されます。 ユーザーストーリーの最後の「C」は、ユーザーストーリーが修正されて正常に配信されたことを確認するために使用される受け入れ基準である確認です。 ユーザーストーリーの確認部分を作成する方法についてもう少し詳しく説明します。ここでは、Gherkinと呼ばれる最もよく知られているテンプレートを使用します。これは、Given-When-Then式を採用して、ユーザーストーリーの受け入れテストの作成をガイドします。 (与えられた..そして)いくつかの文脈 (いつ..そして)何らかのアクションが実行されます (次に..および)いくつかのアクションを実行します CucumberやJbehaveテストフレームワークなどのツールは、自動テストを実行するためのGiven / When / Thenテンプレートの使用を推奨しますが、使用するツールに関係なく、純粋にヒューリスティックとして使用することもできます。 「登録コース」のユーザーストーリーのすべての情報を収集し、3C形式で入力してみましょう。 「登録コース」のユーザーストーリーを表すために、一般的に使用される3C形式を採用しました。同様に、ユースケースの説明で作成された同じ「登録コース」のユースケースを説明するために、最も広く使用されている形式を採用しました。ユースケースの説明に記載したステップ番号に関連付けられているユーザーストーリーの確認セクション(最後のC)のステップに番号を付けました。これらは、シナリオの同じ「9ステップ」であり、それぞれのアプローチに異なる順序で配置されます。私は、モデル表現の両方が、対応する賢人と信者にとって受け入れられると信じています。次に、もう一度質問します。ユーザーストーリーはユーザーケースと非常に似ていますが、それらは異なっているのでしょうか、それともステップの順序がユースケースアプローチに対するあらゆる種類の批判を引き起こしているのでしょうか。 異なる意味と意味的に同等ですか? モデリングドメインに同様のケースがあるかどうかを調べて、ここでの状況と比較してみましょう。または、「ユーザーストーリーとユースケース」に投票するのに役立つかもしれませんが、群衆を盲目的にフォローしたり、何を繰り返したりしないでください。賢人はオウムの話のように言った。 例:意味的に同等 UMLでは、シーケンス図を使用してユースケースシナリオを説明できますが、通常、同じ目的でコラボレーション図を使用することはありません。両方の図を通してさえ、意味的に同等です。つまり、シーケンス図とコラボレーション図の両方で、シナリオに参加している同じ数のオブジェクトがあり、シナリオのタスクを実行するために同じ数のオブジェクトが同じセットのオブジェクトを通過します。ただし、前者は時間重視、後者は空間重視です。シーケンス図はシナリオモデリングで使用する場合により直感的ですが、コラボレーション図はオブジェクト間の構造関係のモデリングに適しています。つまり、参加しているオブジェクトのシナリオをMVCフレームワーク(モデル/ビューおよびコントロールレイヤー)に構造的に表現したいとします。 個人的には、ユーザーストーリーを使用してもチームがアジャイルになるとは思いません。また、ユースケースによってチームが「前向き」になるとは思いません。最も重要なのは、どのような考え方とベストプラクティスを背後に置いて、これらのツールをどのように適用して使用するかです。私が実際にアジャイルで行動するとき、私が「古いスタイル」または時代遅れであると人々が考えることについてあまり心配していません。 構造化分析と設計の時代を思い出します。おそらく、ADAの抽象データ型を使用して、198xのOOPのサポートがなくても、オブジェクト指向の分析と設計の原則を適用できますか?残念ながら、抽象データ型の概念にまったく出くわさないかもしれません。おー!私の神私は誤って開示します–私は年をとっていますか?または、私は前向きに考える必要があります–経験豊富ですか? どう思いますか?これに対するあなたの投票は何ですか?私が間違っている場合は、私に知らせてください。continue reading →