Pモデリングフレームワーク

Pモデリングフレームワークは、開発プロセス改善のためのガイドライン、手法、ツール、テンプレートをパッケージ化したものです。Pモデリングフレームワークは、MSF Agile、MSF CMMI、RUPなど、 現在使用されている他のSDLCに統合できます。

歴史

P モデリング フレームワークの起源は、2001 年に Vladimir L. Pavlov がソフトウェア エンジニアリングの学生向けのトレーニング プログラムとして設計した「バベル実験」にあります。このプログラムの目的は、学生にソフトウェア開発に典型的なコミュニケーションの問題の「凝縮」バージョンを体験させ、これらの問題を克服するためにUMLを適用する経験を積ませることでした。

この実験は次のように行われました。学生チームに、プロジェクト作業中のコミュニケーション言語としてUMLのみを使用するという制約付きのソフトウェアシステムを設計する課題が与えられました。この実験の目的は、学生にソフトウェア開発に典型的なコミュニケーション問題の「凝縮版」を体験させ、UMLを用いてこれらの問題を克服する経験を積ませることでした。この実験の結果、学生は非常に明確で簡潔なモデルを開発しました。

その後、設計セッション中に、2つの独立したチームが同じタスクに取り組んでいました。最初のチームのコミュニケーション手段は前述の通りUMLのみに制限されていましたが、もう1つのチームは自然言語を用いた口頭でのコミュニケーションが許可されていました。その結果、より制限の厳しい最初のチームが、もう1つのチームよりも効率的にタスクを遂行することが判明しました。最初のチームが作成したUML図は、より堅牢で、詳細かつ読みやすく、精緻なものでした。

その後、ウラジミール・L・パブロフは、「沈黙」モデリングセッションが従来のものよりも生産的であるかどうかを明らかにするため、いくつかの追加実験を行いました。これらの実験では、沈黙したチームは少なくとも他のチームと同等の効率を示し、場合によっては沈黙したチームが従来のチームを上回る成果を上げました。

これらの結果の解釈の一部は次のとおりです。

  • 自然言語の使用を制限することで、デザイナーの創造性が刺激されるだけでなく、仕事に集中し続けるよう強制される可能性があります。
  • 言葉を使わないモードでの作業では、設計者は設計プロセスの非常に早い段階で、すべての根本的な仮定を明示的に明らかにしなければならない場合があります。
  • UML は、実際のニーズとは無関係な余分な負担として扱われるのではなく (「書き込み専用」言語として)、むしろ、設計者はモデルの品質と読みやすさについてより大きな関心を示すようになるかもしれません。

その後、UMLと自然言語を比較する方法を見つけることを目的とした、新たな実験を行うためのアイデアが構築されました。これらの実験の前提は、プロのソフトウェア設計者からなる2つのチームに、順方向（自然言語からUMLへ）と逆方向（UMLから自然言語へ）の「翻訳」タスクを設定することでした。これは、一方のチームが順方向翻訳を行い、もう一方のチームが逆方向翻訳を行うというものです。その目的は、逆方向翻訳の結果が元のテキストにどの程度近いかを観察し、UMLモデルの正確性を検証することでした。

実験の結果、ソフトウェアシステムを記述する情報に関して、UMLはモデルの内容を維持するのに十分な表現力を備えていることが示されました。UMLからの逆変換によって得られたテキストは、元のテキストと意味的に同等でした。

実験の結果、ソフトウェア開発サイクル全体のモデルは一連の翻訳として存在することが示唆されました。その後の実験では、各開発ステップの成果物が前のステップで生成された内容を失ったり、誤解されたりしていないことを保証する方法として、逆翻訳検証が実証されました。この手法は「逆セマンティックトレーサビリティ」と名付けられ、Pモデリングフレームワークの第二段階として確固たる地位を築いています。

基本原則

逆セマンティックトレーサビリティ

リバース セマンティック トレーサビリティは、翻訳の各ステップの出力をテストできる品質管理手法です。次のフェーズに進む前に、現在の成果物を「リバース エンジニアリング」し、復元されたテキストを元のテキストと比較します。これら 2 つのテキストに違いがある場合、テストされた成果物は問題を排除するように修正されます (または最初のテキストが修正されます)。その結果、各ステップは、一歩下がって開発が正しい軌道に乗っていることを確認することで確認されます。このようにして、問題を遅滞なく発見して修正できるため、問題が蓄積されず、開発サイクルの後続のフェーズに波及することもありません。 この手法の名前のキーワードは「セマンティック」です。これは、テキストの元のバージョンと復元されたバージョンを意味的に比較し、テキストで使用されている特定の「単語」ではなく、テキストの「意味」に焦点を当てるという事実に基づいています。

リバース セマンティック トレーサビリティ メソッドの早期導入者によって報告された最も使用頻度の高いシナリオは次のとおりです。

  • UML モデルの検証:品質エンジニアがドメインのテキスト記述を復元し、元の記述と復元された記述を比較します。
  • 新しい要件に対するモデルの変更の検証: モデルの元のバージョンと変更されたバージョンが与えられ、品質エンジニアは要件のテキスト記述を復元し、元の記述と復元された記述を比較します。
  • バグ修正の検証: 元のソース コードと修正されたソース コードが与えられ、品質エンジニアは修正されたバグのテキスト記述を復元し、元の記述と復元された記述を比較します。
  • 新しいソフトウェア エンジニアをチームに統合する: 新しいチーム メンバーに、現在のプロジェクトの主要な成果物に対するリバース セマンティック トレーサビリティを実行する割り当てが与えられます。

言葉を失うモデリング

スピーチレス・モデリングは、もともとUMLを用いたオブジェクト指向分析設計を学生に教えるための高度なトレーニングとして考案されましたが、本質的には、自然言語を直接的または間接的に含むコミュニケーション手段の使用を制限するものです。これにより、設計チームは設計セッション中に、モデリング言語を唯一のコミュニケーション言語として使わざるを得なくなります。

Pモデリングフレームワークをソフトウェア開発ライフサイクル（SDLC）に組み込む

組織で使用されている開発プロセスのタイプ（ウォーターフォール、スパイラル、さまざまな反復増分など）に関係なく、ソフトウェア設計、品質管理、人材管理、リスク管理、コミュニケーション管理など、P モデリング フレームワークの原則を適用できるプロセスが存在します。特に、品質管理アクティビティがほとんどないか、（事実上）存在しない プロジェクトの初期段階では、P モデリング フレームワークの原則を適用できます。

要件と制限

  1. P モデリング セッションのメンバー全員が、何らかのグラフィカル モデリング言語を流暢に話せる必要があります。
  2. 本格的な P モデリング セッションには、最低 8 人の資格のある人が必要です。
  3. 効率的な RST セッションには、最低 3 人の有資格者が必要です。
  4. P モデリング フレームワークでは、要件またはクライアント要求内の曖昧、矛盾、不完全な側面を検出する機能が提供されません。
  5. 言葉のないモデリングセッションでは、参加者に多大なエネルギーと努力が求められます。

批判

Pモデリングフレームワークには、明らかにさらなる改善の余地があります。例えば：

  • P モデリング セッションでは、元の成果物に関する知識がなくても追加のリソースが必要となり、プログラマーに余分な作業負荷がかかります。
  • RST を実行する際は、テキストを手動で比較する必要があるため、フレームワークには自動化が欠けています。
  • RST で起こり得る結果の 1 つは、人々が「RST​​ 向けに設計する」状況です。つまり、新しい価値を追加することなく、簡単に再構築できる方法で成果物を作成します。
  • P モデリング フレームワークの有効性を示す信頼できる統計的証拠はありません。
  • 「サイレント設計セッション」の適用範囲は非常に限定的で、グラフィカルモデリング言語でシステムを文書化でき、またその必要があるシステムと組織にのみ適用されます。ただし、以下の場合には当てはまりません。
    • 会社には、「あらゆるグラフィカル モデリング言語を流暢に話し」、それをいつどのように適用するかを知っている、つまり非常に高い資格を持つ開発者が十分にいません。
    • 当社ではグラフィカルモデリング言語を広範には使用していません。
  • P モデリング セッションでは、良いデザインと悪いデザインを区別することはできません。

参考文献

「 https://en.wikipedia.org/w/index.php?title=P-Modeling_Framework&oldid=953621795」から取得