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

逆セマンティックトレーサビリティ( RST ) は、ソフトウェア開発プロセスの各段階で逆変換を行うことで成果物の高品質を保証する、検証改善のための品質管理手法です。

開発プロセスの各段階は、ある言語から別の言語への一連の「翻訳」として扱うことができます。プロジェクトチームは、最初に、自然言語で表現された顧客の要件と期待に対処します。これらの顧客要件は、不完全であったり、曖昧であったり、互いに矛盾している場合もあります。最初のステップは、顧客の期待を仕様化して形式化し、将来のシステムの正式な要件ドキュメントに移行 (「翻訳」) することです。次に、要件はシステム アーキテクチャに翻訳され、プロジェクト チームは段階的に、非常に形式的なプログラミング言語で記述されたコードを生成します。翻訳中に間違いが挿入されたり、誤解されたり、何かが失われたりする可能性は常にあります。要件または設計 仕様の小さな欠陥でさえ、プロジェクトの後期段階で大量の欠陥を引き起こす可能性があります。場合によっては、このような誤解がプロジェクトの失敗や顧客の完全な不満につながることがあります。

リバース セマンティック トレーサビリティ メソッドが最もよく使用されるシナリオは次のとおりです。

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

RST セッションに関与する主な役割は次のとおりです。

• プロジェクト成果物（入力と出力の両方）の作成者
• リバースエンジニア、
• 専門家グループ、
• プロジェクトマネージャー。

検証方法としての逆セマンティック トレーサビリティは、あらゆるプロジェクト成果物、プロジェクト成果物のあらゆる部分、さらにはドキュメントやコードの小さな部分にも適用できます。ただし、すべての成果物に対して RST を実行するとオーバーヘッドが発生する可能性があり、十分に正当化される必要があることは明らかです (たとえば、情報損失の可能性が非常に重大な医療ソフトウェアの場合)。

どの程度のプロジェクト成果物を「リバース エンジニアリング」するかを決定するのは、企業とプロジェクト マネージャーの責任です。この量は、トレードオフマトリックス、プロジェクトと企業の品質保証ポリシーなど、プロジェクト固有の詳細によって異なります。また、プロジェクトの成功に対する特定の成果物の重要性と、この成果物に適用される品質管理のレベルによっても異なります。

プロジェクトの RST セッションの量は、プロジェクト計画段階で定義されます。

まず、プロジェクト マネージャーは、プロジェクト チームがプロジェクト中に持つすべての成果物のリストを作成する必要があります。これらは、依存関係と関係性を持つツリーとして表すことができます。成果物は、1 つの発生 (ビジョン ドキュメントなど) または複数の発生 (リスクやバグなど) に存在する可能性があります。このリストは、プロジェクトの途中で変更される可能性がありますが、RST アクティビティに関する決定の背後にある考え方は同じです。

2 番目のステップは、プロジェクトの成果物の重要性と各プロジェクト成果物の品質管理レベルを分析することです。

ドキュメントの重要性は、プロジェクトの成功と最終製品の品質に対する成果物の影響の度合いです。次の尺度で測定されます。

• 重要 (1): 成果物の品質は、プロジェクト全体の品質、さらにはプロジェクトの成功にとって非常に重要です。例:機能要件、システム アーキテクチャ、重大なバグ修正 (ショーストッパー)、発生確率が高く重大な影響を与えるリスク。
• 高 (2): 成果物は最終製品の品質に影響を与えます。例:テストケース、ユーザーインターフェイス要件、重大なバグ修正、露出度の高いリスク。
• 中程度 (3): 成果物は最終製品の品質に中程度または間接的な影響を及ぼします。例:プロジェクト計画、中程度の重大度のバグ修正、中程度の露出を伴うリスク。
• 低 (4): アーティファクトは最終製品の品質にほとんど影響を与えません。例: 従業員のタスク、外観上のバグ、低確率のリスク。

品質管理のレベルは、成果物に適用される検証および検証アクティビティの量と、成果物の作成中に誤解が生じる可能性を定義する尺度です。

• 低（1）：成果物のレビューは想定されておらず、誤解や情報損失の可能性が高い、情報チャネルが分散している、言語の壁が存在するなど。
• 中程度 (2): 成果物のレビューは想定されておらず、情報チャネルは分散されていません (例: 成果物の作成者と情報提供者は 1 つのチームのメンバーです)
• 十分（３）：ペア開発やピアレビューは行われ、情報チャネルは配布されていない。
• 優秀 (4): ペア開発、ピアレビュー、テストが実施されているか、自動化または単体テストが実施されているか、成果物の開発と検証のためのツールがいくつかある。

RST セッションの成功は、責任者の正しい割り当てに大きく依存します。

リバース セマンティック トレーサビリティは、RST を実行する必要があるという決定が下され、そのためのリソースが利用可能になったときに開始されます。

プロジェクト マネージャーは、RST セッションの入力となるドキュメントを定義します。たとえば、復元するアーティファクトだけでなく、プロジェクトの背景情報も入力できます。リバース エンジニアに元のテキストの単語数を伝えて、結果として得られるテキストの量を把握できるようにすることをお勧めします。テキストは 1 文でも複数ページでもかまいません。復元されたテキストには元のテキストと同じ単語数が含まれない場合もありますが、それでも値は比較できるはずです。

その後、リバース エンジニアがアーティファクトを取得し、そこから元のテキストを復元します。RST 自体は、1 ページのテキスト (750 語) に対して約 1 時間かかります。

RST セッションを完了するには、アーティファクトの復元されたテキストと元のテキストを比較し、アーティファクトの品質を評価する必要があります。アーティファクトの再作業とその量に関する決定は、この評価に基づいて行われます。

評価のために、専門家のグループが結成されます。専門家は、プロジェクト ドメインを認識し、比較された成果物の品質レベルを評価できる十分な経験を持っている必要があります。たとえば、ビジネス アナリストは、ビジョン ステートメントとシナリオから復元されたビジョン ステートメントの比較の専門家になります。

RST 評価基準:

1. 復元されたテキストと元のテキストには意味に大きな違いがあり、重要な情報が失われている。
2. 復元されたテキストと元のテキストには意味に若干の違いがあり、重要な情報が失われている
3. 復元されたテキストと元のテキストには意味に多少の違いがあり、重要でない情報の損失もある。
4. 復元されたテキストと元のテキストは非常に近いが、若干の情報は失われている
5. 復元されたテキストと元のテキストは非常に近く、情報は失われていません

各専門家が評価を行い、平均値が計算されます。この値に応じて、プロジェクト マネージャーは両方の成果物を修正するか、どちらか一方またはやり直しが必要ないかを決定します。

平均 RST 品質レベルが 1 ～ 2 の範囲にある場合、成果物の品質は低く、欠陥をなくすために検証済み成果物を作り直すだけでなく、誤解を解くために元の成果物を修正することが推奨されます。この場合、成果物を作り直した後に、もう 1 つの RST セッションが必要です。欠陥を修正し、情報の損失をなくすために、検証済み成果物の修正が 2 回以上 3 回未満の成果物については、欠陥を修正し、情報の損失をなくす必要がありますが、誤解を招くような曖昧な情報がないか調べるために元の成果物を確認することが推奨されます。追加の RST セッションは必要ありません。平均マークが 3 回以上 4 回未満の場合、欠陥と重要でない情報の損失を取り除くために、検証済み成果物を修正することが想定されます。マークが 4 より大きい場合、成果物の品質は良好であり、特別な修正や作り直しは必要ないことを意味します。

当然のことながら、成果物の再作業に関する最終決定はプロジェクト マネージャーによって行われ、テキストの相違の理由の分析に基づいて行われる必要があります。

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

• Vladimir Pavlov と Anton Yatsenko、「The Babel Experiment: An Advanced Pantomime-based Training in OOA&OOD with UML」、第 36 回 ACM Technical Symposium on Computer Science Education (SIG CSE 2005)、セントルイス (ミズーリ州、米国)。

• ウラジミール・L・パブロフのウェブサイト
• P モデリング フレームワークのホワイトペーパー
• Pモデリングフレームワーク