メソッドエンジニアリング

「情報システムの分野における方法論工学は、既存の方法論から新しい方法論を構築する学問である」 ^{[2] 。それは「}情報システム開発のための方法論、技術、支援ツールの設計、構築、評価」に重点を置いている。^[3]

さらに、メソッドエンジニアリングは「特定の組織状況に合わせてメソッドを作成する適応フレームワークを作成することで、システム開発メソッドの有用性を向上させることを目指しています」。 ^[4]

メタプロセスモデリングプロセスは、コンピュータ支援メソッドエンジニアリング（CAME）ツールやMetaCASEツール（メタレベルコンピュータ支援ソフトウェアエンジニアリングツール）と呼ばれるソフトウェアツールではサポートされないことがよくあります。多くの場合、インスタンス化技術は「コンピュータ支援メソッドエンジニアリング環境のリポジトリを構築するために利用されています」。^[5]メタプロセスモデリングには多くのツールがあります。^{[6] [7] [8] [9] [10]}

文献では、メソッドの適応の概念を指すさまざまな用語が使用されており、「メソッドの調整」、「メソッドの断片の適応」、「状況に応じたメソッドのエンジニアリング」などがあります。メソッドの調整は次のように定義されています。

人間のエージェントが、コンテキスト、意図、方法の断片間の応答的な変化や動的な相互作用を通じて、特定のプロジェクト状況に対するシステム開発アプローチを決定するプロセスまたは能力。^[11]

潜在的には、ほとんどすべてのアジャイル手法は、手法の調整に適しています。DSDM手法もこの目的で使用されており、CMM のコンテキストでうまく調整されています。[ 12 ^]状況適合性は、アジャイル手法と従来のソフトウェア開発手法との違いとして考えることができます。後者は比較的はるかに厳格で規範的です。実用的な意味合いは、アジャイル手法により、プロジェクト チームが個々のプロジェクトのニーズに応じて作業プラクティスを調整できることです。プラクティスとは、手法フレームワークの一部である具体的な活動と成果物です。より極端なレベルでは、いくつかの原則で構成される手法の背後にある哲学を調整できます。^[11]

状況的方法論工学とは、開発プロジェクトの特定の状況に合わせて調整された方法論を構築することである。^[13]これは、

1. 再利用可能なメソッドコンポーネントのリポジトリから適切なメソッドコンポーネントを選択する。
2. これらの方法の構成要素を適切に調整し、
3. これらのカスタマイズされた方法のコンポーネントを統合して、新しい状況固有の方法を形成します。

これにより、あらゆる開発状況に適した開発手法の作成が可能になります。各システム開発は、その場で開発手法を構築する手法定義フェーズから始まります。^[4]

モバイルビジネス開発の場合、ビジネスモデル設計プロセスとICT開発の特定の部分に利用可能なメソッドがあります。状況メソッドエンジニアリングを使用すると、これらのメソッドをモバイルICTサービスの特性を取り入れた1つの統一されたメソッドに組み合わせることができます。

IDEFモデリング言語の開発者であるRichard J. Mayer ら (1995) は、一般的なメソッド エンジニアリングの実践と他の分析および設計メソッドの開発経験の研究から、メソッド エンジニアリングへの初期のアプローチを開発しました。次の図は、このアプローチのプロセス指向のビューを示しています。この図では、IDEF3プロセス記述キャプチャ メソッドを使用してこのプロセスを説明しています。動詞句のボックスはアクティビティを表し、矢印は優先順位関係を表し、可能なパス間の「排他的論理和」条件は「X」というラベルの付いたジャンクション ボックスで表されます。^[1]

このアプローチによれば、方法論工学には3つの基本的な戦略がある。^[1]

• 再利用: 方法論エンジニアリングの基本的な戦略の 1 つは再利用です。可能な限り、既存の方法を採用します。
• テーラーメイド: わずかな変更で特定されたニーズを満たすことができる方法を見つけます。変更によって方法の基本概念や設計目標に根本的な変更が必要ない場合、このオプションは魅力的です。
• 新規開発: これらのオプションのいずれも実行不可能な場合にのみ、メソッド設計者は新しいメソッドの開発を検討する必要があります。

この基本戦略は、コンセプト開発と同様のプロセスで開発することができます。

知識工学アプローチは、方法の強化と新しい方法の開発のための主要なメカニズムです。言い換えれば、ごくわずかな例外を除いて、方法の開発には、特定のタスクに対する既存の実践を分離、文書化、パッケージ化して、実践者の間で確実な成功を促進する形式にすることが含まれます。専門家の調整は、まず基本的な直感と方法の概念の形で特徴付けられます。これらは、専門家が使用するテクニック、図、表現の分析を通じて最初に特定されることがよくあります。これらの発見は、初心者の実践者が同じ調整とスキルを習得するのを支援するために活用できる既存の方法の検索に役立ちます。^[1]

新しい方法の開発は、方法の範囲を確立し、方法の概念と直感の特徴を洗練し、タスクの達成と初心者の実践者への基本的な見習いサポートの両方を提供する手順を設計し、表現言語を開発することによって達成されます。次に、スタンドアロンモードでの使用と他の方法との併用に関するガイドラインを概説した方法の適用技術が開発されます。その後、方法の各要素は、実験室とフィールドの両方でのテストを通じて反復的に改良されます。^[1]

メソッド言語の設計プロセスは、本質的に非常に反復的で実験的です。既存の実践から一連のヒューリスティックとテクニックを特定、統合、改良できる手順開発とは異なり、言語設計者は、十分に開発されたグラフィカル表示やテキスト情報キャプチャメカニズムに遭遇することはほとんどありません。再利用可能な可能性のある言語構造が見つかった場合、それらは定義が不十分であったり、メソッドのニーズに部分的にしか適合しなかったりすることがよくあります。^[1]

方法言語の設計において重要な要素は、方法の目的と範囲を明確に定めることです。方法の目的は、方法が対処しなければならないニーズを定めます。これは、サポート言語に必要な表現力を決定するために使用されます。方法の範囲は、適切な言語設計戦略を設計する前にも確立しなければならないカバレッジの範囲と深さを定めます。範囲の決定には、方法の適用を通じてサポートされる認知活動を決定することも含まれます。たとえば、言語設計は、方法の適用の最終結果を表示するだけに限定できます (制約のロジックと構造を捉えるグラフィカルおよびテキスト言語機能を IDEF9 に提供するなど)。あるいは、情報の収集と分析を容易にするプロセス内言語サポートが必要になる場合があります。そのような状況では、方法の実践者が情報を整理、分類、および表現し、後で表示用に追加の表現構造に統合できるように、特定の言語構成を設計できます。^[1]

この基礎を基に、言語設計者は言語で何を表現する必要があるか、どのように表現すべきかを決定するプロセスを開始します。言語設計は、対象となる情報の全範囲を表現できるテキスト言語の開発から始めることができます。次に、テキスト言語の特定の部分を表示するために設計されたグラフィカル言語構造を開発できます。または、テキスト言語の開発に先立って、または並行してグラフィカル言語構造を開発することもできます。これらの活動の順序は、言語開発者が言語要件をどの程度理解しているかに大きく依存します。これらは、グラフィカル言語設計とテキスト言語設計の両方を数回繰り返した後にのみ明らかになる場合があります。^[1]

グラフィカル言語設計は、予備的な一連の図表と、それぞれの目的または目標（方法の適用プロセスをどこでどのようにサポートするか）を特定することから始まります。各図表ごとに、中心となる項目が決定されます。たとえば、IDEF9 の代替グラフィカル言語設計の実験では、制約が適用される可能性のあるさまざまな環境コンテキストを分類するメカニズムとしてコンテキスト図表が想定されました。この図表の中心となるのはコンテキストです。図表の中心となる項目を決定した後、キャプチャまたは伝達する必要がある追加情報（概念と関係）が特定されます。^[1]

言語設計プロセスのこの時点まで、主な焦点は、図表の目標を達成するために特定の図表に表示される情報にありました。言語設計者は、図表に含める可能性があると特定された項目のうち、グラフィカルな表現に適しており、ユーザーが目的の情報コンテンツに集中し続けるのに役立つものを決定する必要があります。この一般的な理解に基づいて、以前に開発されたグラフィカル言語構造を調査し、潜在的な再利用の機会を特定します。新しい IDEF メソッドの候補となるグラフィカル言語設計を調査する中で、さまざまな図が特定され、調査されました。多くの場合、メソッドの中心概念の一部でさえ、メソッドにグラフィカル言語要素がありません。^[1]

たとえば、IDEF1情報モデリング手法にはエンティティの概念が含まれていますが、グラフィカル言語にはエンティティの構文要素がありません。8. 言語設計者がメソッドの概念に構文要素を含める必要があると決定すると、候補となるシンボルが設計され、評価されます。グラフィカル言語の設計プロセス全体を通じて、言語設計者は高品質の設計を開発するためにいくつかの指針を適用します。これらの指針の中で、言語設計者は概念クラスの重複や定義の不十分なクラスを回避します。また、図表の読み方を指示するための直感的なメカニズムを確立しようとします。^[1]

たとえば、回路図は左から右、下から上、または中央から外側に読み取れるように設計されている場合があります。回路図が乱雑になったり、1つの回路図に大量の情報が詰め込まれたりすると、回路図の読み取りと理解が非常に困難になるため、回路図も考慮する必要があります。^[1]

次に、各候補設計は、各回路図の目的に対する設計の有用性を調べるために、幅広い例を開発することによってテストされます。方法開発、特にサポート言語構造の開発における初期の試みは、通常複雑です。設計を繰り返すことで、不要で複雑な言語構造は排除されます。^[1]

グラフィカル言語の設計が成熟レベルに近づくと、テキスト言語に注目が集まります。テキスト言語の目的は、グラフィカル言語から明示的に除外された情報を表現するメカニズムを提供することから、標準的なデータ交換と自動モデル解釈のメカニズムを提供することまで多岐にわたります。したがって、この方法をサポートするテキスト言語は、単純で非構造化されている場合もあれば (コンピューター解釈の観点から)、高度に構造化された複雑な言語になる場合もあります。方法の目的によって、テキスト言語に求められる構造のレベルがほぼ決まります。^[1]

方法言語が成熟に近づくにつれて、数学的形式化技術が採用され、新しい言語は明確な構文と意味を持つようになります。方法形式化プロセスは、あいまいさを明らかにし、厄介な言語構造を特定し、言語を合理化するのに役立ちます。^[1]

これらの一般的な活動は、この方法が設計されたタスクを達成する過程で発見、分析、変換、または伝達する必要がある情報にユーザーの注意を集中させるのに役立つ言語で最高潮に達します。この方法の手順と言語の両方の要素は、ユーザーが対象のタスクに対して一貫して高品質の結果を達成するために必要なスキルと調整を開発するのにも役立ちます。^[1]

一旦メソッドが開発されると、そのメソッドをスタンドアロン モードでも他のメソッドと組み合わせてもうまく適用できるように、適用テクニックが設計されます。適用テクニックはメソッドの「使用」コンポーネントを構成し、メソッドの存続期間中、進化と成長を続けます。メソッドの手順、言語構成、適用テクニックは、メソッドを繰り返し改良するためにレビューおよびテストされます。^[1]

帰属

この記事には、現在パブリック ドメインとなっている出版物である、米国空軍の Richard J. Mayer 他による 1995 年の同時エンジニアリングのための情報統合 (IICE) 方法論概要レポートからのテキストが組み込まれています。

• Sjaak Brinkkemper、Kalle Lyytinen、Richard J. Welke (1996)。メソッドエンジニアリング：メソッド構築とツールサポートの原則：IFIP TC8、WG8.1/8.2 メソッドエンジニアリングに関するワーキングカンファレンスの議事録、1996年8月26～28日、米国アトランタ。Springer。ISBN 041279750X  doi : 10.1007 /978-0-387-35080-6
• Sjaak Brinkkemper 、Saeki、 Harmsen (1998)。メソッドエンジニアリングのためのアセンブリ技術。Advanced Information Systems Engineering、CaiSE'98 議事録。ニューヨーク: Springer。doi :10.1007/BFb0054236
• Ajantha Dahanayake (2001)。『コンピュータ支援による方法論エンジニアリング：21 世紀の CASE リポジトリの設計』 。ペンシルバニア州ハーシー：Idea Group Inc (IGI)、2001 年。ISBN 1878289942 
• ブライアン・ヘンダーソン・セラーズ、ジョリータ・ラリーテ、パー・J・オーガーフォーク、マッティ・ロッシ (2014)。状況に応じた方法工学。ベルリン：シュプリンガー。ISBN 9783642414664土居：10.1007/978-3-642-41467-1 
• Brian Henderson-Sellers、Jolita Ralyté、Sjaak Brinkkemper編 (2008)。状況的方法工学：基礎と経験：IFIP WG 8.1 ワーキング カンファレンスの議事録、2007 年 9 月 12 ～ 14 日、ジュネーブ、スイス。ニューヨーク：Springer。ISBN 0387739467 doi : 10.1007 /978-0-387-73947-2 
• Brian Henderson-Sellers、C. Gonzalez-Perez、Donald Firesmith (2004)「メソッド エンジニアリングと COTS 評価」、ACM SIGSOFT ソフトウェア エンジニアリング ノート アーカイブ。第 30 巻、第 4 号 (2005 年 7 月)。
• Manfred A. Jeusfeld、Matthias Jarke、John Mylopoulos編 (2009)。メソッドエンジニアリングのためのメタモデリング。マサチューセッツ州ケンブリッジ: MIT プレス。ISBN 0262101084 

ウィキメディア・コモンズには、方法論工学に関連するメディアがあります。

• Minna Koskinen によるメタモデリングとメソッド エンジニアリングのプレゼンテーション (2000 年)。