オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

テキスト処理でできるレビュー支援

»

2020年2月と2020年5月にテキスト処理を使ったレビュー支援手法の論文が掲載されたので紹介します。1つは設計書での記載、検討漏れのチェックに使うためのもので、要求仕様書と設計書に出現する単語の差分を目視でチェックします。もう一つは、ドメイン固有でチェックすべき点を見つけるためのもので、ドメインが違うレビュー指摘で共通に出てくる単語を同じドメインのレビュー指摘から取り除くものです。

MeCabのような形態素解析ツールを使えば、簡単に適用できる方法になっています。また、シンプルな原理で商用ソフトウェア、システムで一定の効果が確認できていますので、導入のために説明がたくさん必要というわけではありません。

仕様書と設計書の単語の差分から抜けを見つける

記載、検討漏れのチェックに単語の差分を使う手法は、要求仕様書の単語と設計書の単語をテキスト処理ツールで取り出します。要求仕様書にあって設計書にないものが記載、検討漏れの候補です。候補なので、たまたま設計書にない単語も含まれています。たとえば、要求仕様書で「アカウント」と呼んでいて設計書では「ユーザID」と言い換えられた場合です(厳密にはそれ以外にアカウントとユーザIDが要求仕様書、設計書に出現しないことが前提になります)。

論文では、漏れも含めて設計書になかった単語をグループ化して、4種類(機能要求、非機能要求、ソフトウェア以外の設計要素、プロジェクトや体制に関する記述)を示しています。

実際に要求仕様書と設計書を使った開発において、レビュー時点では指摘されなかったけれどテストで見つかったバグを対象として、単語から見つけることができそうかどうかを確かめたところ、数件ありました。評価に使ったソフトウェアは、通信システムに使われるソフトウェアだったので「切替え」「接続の優先順位」といったバグがあり、それを指定する単語が要求仕様書にはあったのですが、設計書に記述がありませんでした。単語の詳細や評価方法の詳細は以下の論文に書いています。

Tool Supported Detection of Omissions by Comparing Words between Requirements and Design Document
https://www.jstage.jst.go.jp/article/ipsjjip/28/0/28_136/_article/-char/ja/

ドメイン固有のチェック項目を見つける

システムインテグレーション等のプロジェクトでのレビューを実施していて様々なドメインでのレビュー指摘があることが前提です。プロジェクトごとにレビュー指摘の記録に出現する単語を取り出しておきます。ここでの似たようなドメインというのは、公共分野の業務システム、人事系の社内システム、生産管理システム、顧客管理システムといったものを想定していて、同じドメインのレビューでは、同じような業務に関する指摘があることが条件です。もしも実現方法(同じようなデータベースでテーブル定義が同じであったり、同じようなネットワークインフラやサブシステムを使っていると)それらに対しても同じような指摘があるかもしれません。

論文では、今後レビューの予定のある公共分野の業務システムPと類似の過去の公共分野の業務システムの開発プロジェクトP1, P2を選んで、そのレビュー指摘に含まれていた単語の集合を形態素解析ツールで抽出しています。その単語から交通システムG1と開発支援システムG2のレビュー指摘に含まれていた単語を取り除いています。その結果、公共システムの業務に関する単語を取り出せています。論文では、単語の一覧がTable 6にあります。「年度」や「扶養」といった単語が含まれていました。対象ドメインに知識のあるレビューアだと、これらの単語のリストから「これをチェックできていないな」というチェック項目に気づくことができると考えられます。

論文は以下にあります。

A Method to Remove Extraneous Words in Defect Log by Using Common Vocabulary
https://www.jstage.jst.go.jp/article/jssst/37/2/37_2_120/_article/-char/ja

私の研究グループでは、有償の共同研究としてこうした過度に凝っていない方法で効果が得られるテーマをご一緒しています。

Comment(0)