木村/Research Subject/学士論文の履歴(No.12)

木村/Research Subject

人と非機能要件に関する分類器の比較分析†

日本語の非機能要件分類ツールがどれほど作業を効率よくするのか？

↑

Background†

非機能要件の分類器の性能を評価することはできるが，実際の作業において分類器がどのくらい役に立つのかは明らかでない

↑

Goal・Contribution†

分類器と人の能力の違いを明らかにし，分類器の設計の改善を図る？
分類器を実際の現場で使用するにはどのような問題が存在するのかを明確にする

↑

Approach†

ユーザスタディの実施
- 最低でも10人は必要
- 非機能要件分類チュートリアルを実施
- 実際に用意した要件をラベリングしてもらう
- （ツールができれば）
  - ツール有無で時間を測定
  - 数をこなすと時間が短縮する可能性を考慮して交差実験をする
一人に対し2つの要件書を割り当てる
組み合わせによるバイアスの低減？
イメージ
Aさん Bさん Cさん

要件書A ○ ○

要件書B ○ ○

要件書C ○ ○

↑

Experiment†

知りたいこと
- 分類器で分類したものと人の手作業で分類されたものの違いはあるか？
- 品質特性ごとにラベリングされたもののバラツキはどのようなものか？
  - バラツキが多い品質特性は曖昧度が高い
  - 学習させる際に考慮すべき事柄が見つかるかも？

（分類器をツール化した場合の予定）
- ツールの有無で時間はどのくらい違うのか？
- 要件ごとに時間の短縮度合いに違いはあるか？（一度に分類するため測定するのは難しいかも）
- 手動で分類した時とツールを使って分類した時で要件の分類のばらつきはどうか？
  - ツールを使用した時にばらつきが少なければ，非機能要件の分類
[旧]
（RQ1）人と人の分類結果の一致具合はどうか？
- 1つの要件書に複数人割り当てたグループを複数作る
  - たまたま分類がしやすい要件書だった可能性をなくすため
- 各グループごとに相関分析を行う
  - 人の分類結果にバラツキが大きければ，高精度のモデルを作るのは難しいのでは？
  - 分類器を使う場面を考え，設計の見直しが必要になるかも
- 品質特性の区別なしの相関と品質特性ごとの相関を表に表す
（RQ2）人と分類器の分類結果の一致具合はどうか？
- 各要件書に対し複数のモデルで分類を行う
  - それぞれ試行回数は100回試行
- 100回の分類結果を1つずつ，人の分類結果と相関分析を行う
- RQ1と同様に品質特性の区別有無と各モデルの相関を表で表す
（RQ3）RQ1の結果がRQ2にどのように影響しているか？
- RQ1の相関の値が適切なモデルの選択に関係しているかどうか？
[新]
（RQ1）人と分類器の分類はどのくらい一致しているか？
（RQ2）表現の曖昧さは分類器の分類精度にどのくらい影響しているか？
- （RQ2-1）各要件の曖昧さはどのくらいか？
- （RQ2-2）表現の曖昧さと分類精度にどのくらい関係があるか？
- （RQ2-3）表現の曖昧さが高い文は見逃す，あるいは間違いやすく，表現の曖昧さが低い文は正しく分類されやすい
曖昧さの定義
- 人が分類したときの結果の一致の度合いのこと．
- 一致しやすいものはわかりやすい文であり理解の仕方にブレがなく，一致しづらい文はわかりにくく理解の仕方が複数ある
RQ2-2やRQ2-3で曖昧さが分類精度に影響していた場合，分類器の設計を変える必要があると述べられる
単語の類似度ではなく，文章の類似単語の組み合わせや文構造，あるいは前後の文脈を加味した設計を作る必要がある
一回の分類ではなく複数回ループさせるとか面白そう

↑

To Do†

どの時点の分類器と比較するのかを決める
未来と一緒に分類器の性能向上を目指す
実験環境の設定を定める
- 要件書の規模，日程調整など
データ分類における規約の設定
- 正解集合が正解でない可能性がある
ノイズとなっている単語の特定
- 学習データと精度を比較しながらどの文章，あるいは単語がノイズになっているかを特定する
とりあえず目視

↑

Done†

分類器の改良
- 前処理部分を追加
品詞を限定した時としていない時では，品詞を限定していない時の方が全体的に精度がいい
- 機能適合性・性能効率性・互換性が終了

↑

Memo†

秋頃を過ぎると被験者の方々も忙しくなるので，ユーザスタディは夏までに実施しデータを獲得する
RQ1とRQ2の順序を逆にした方が自然な流れになりそう

↑

Reference†

~~Are Automated Debugging Techniques Actually Helping Programmers? [parnin.orso.ISSTA11.pdf]~~
Goal-Centric Traceability for Managing Non-Functional Requirementsのイントロダクションで，
非機能要件をきちんと管理できていないとシステムの品質に壊滅的な影響を及ぼし，システム障害を引き起こす可能性があることを示している
と書かれていて，その引用論文が下のもの
[1]Brooks Jr., F.P., “No Silver Bullet: Essences and Accidents of Software Engineering,” IEEE Computer., 4, (Apr. 1987), 10-19.