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

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

簡単な紹介

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

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

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

RST の役割

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

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

RSTプロセス

すべてのプロジェクト成果物とその関係を定義する

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

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

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

まず、プロジェクトマネージャーは、プロジェクト期間中にプロジェクトチームが作成するすべての成果物のリストを作成する必要があります。これらは、依存関係と関係性を示すツリー構造で表すことができます。成果物は、ビジョンドキュメントのように1回だけ作成することも、リスクやバグのように複数回作成することもできます。このリストはプロジェクトの途中で変更される可能性がありますが、RST活動に関する決定の背後にある考え方は変わりません。

優先順位をつける

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

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

重要事項（1）：成果物の品質は、プロジェクト全体の品質、ひいてはプロジェクトの成功にとって非常に重要です。例：機能要件、システムアーキテクチャ、重大なバグ修正（ショーストッパー）、発生確率が高く重大な影響を与えるリスク。
高（2）：成果物が最終製品の品質に影響を与える。例：テストケース、ユーザーインターフェース要件、重大度の高いバグ修正、リスクの高いリスク。
中程度（3）：成果物が最終製品の品質に中程度または間接的な影響を与える。例：プロジェクト計画、中程度の深刻度のバグ修正、中程度の露出を伴うリスク。
低（4）：最終的な製品の品質への影響は軽微です。例：従業員の作業、外観上のバグ、発生確率の低いリスクなど。

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

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

責任者を定義する

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

成果物の逆セマンティックトレーサビリティを実行する

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

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

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

品質レベルを評価して決定を下す

RSTセッションを完了するには、復元された遺物のテキストとオリジナルのテキストを比較し、遺物の品質を評価する必要があります。この評価に基づいて、遺物の再作業とその量を決定します。

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

RST 評価基準:

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

各専門家が評価を行い、平均値が算出されます。この平均値に基づいて、プロジェクトマネージャーは両方の成果物を修正するか、どちらか一方、あるいは手直しは不要かを決定します。

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

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

参照

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

参考文献

Vladimir Pavlov および Anton Yatsenko、「バベル実験: UML を使用した OOA および OOD の高度なパントマイムベースのトレーニング」、第 36 回 ACM コンピュータサイエンス教育技術シンポジウム (SIG CSE 2005)、セントルイス (ミズーリ州、米国)。

外部リンク