«前の日記(2008-01-04) 最新 次の日記(2008-01-27)» 編集

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2008-01-18 [長年日記]

_ 実験のやり方

みんなで一斉に同じ作業をやって時間を計測するという実験で気づいたことと,過去のメモを合わせて軽く整理してみました.

良い実験のやり方というのをきちんと習ったことがないか,あるいは忘却したので,間違ったことを書いてるかもしれません.

実験関連では,プログラム理解に関する実験のやり方についての論文もあったりします.

  • [環境] 作業環境のうち,個人でインストールするもの(JDKなど)は 事前に通知してバージョンを確認させておく.
  • [環境] Eclipse はコピーで配れるので非常に便利.自分で別PCにコピーして確認し,入力すべき workspace の位置などを確認する.
  • [環境] ノートPC持ち寄りでツールを実験する場合,たとえばディスプレイの大きさやCPU性能などがツールの使いやすさに影響しないか検討が必要(データの可視化系や解析系だと影響がありそう).
  • [計画] 事前説明+トレーニング用の練習問題で,1時間半程度はかかる.たとえば,比較対象としたい手法A,Bのどちらにも馴染みがなく,それらを使って課題X,Yを解くという場合,A,B の説明とトレーニングに加えて課題 X,Y の説明するので,時間はかなり必要となる.トレーニング部分(手法A, B の説明)だけを切り離して実施するという手もある.
  • [計画] 課題をクリアしたことを本人が確認する方法があると,明確に作業時間を計測できてよさそう(デバッグなら JUnit の通過とか).
  • [計画] 作業時間を,どの程度細かい作業単位で記録してもらうかの判断が必要.課題単位よりは,その中の作業単位ぐらいのほうが良さそう(たとえばデバッグ作業の実験では,原因解明までと修正の時間は分けていたほうが考察がしやすい).
  • [計画] 作業時間は,普通に時計を見てその時刻を記録する(分単位で計測する)ので十分.資料(あるいは作業記録シート)には,あらかじめ作業手順と,各ステップでの記入欄を用意しておくというのが良さそう.
  • [計画] 作業時間で評価するなら,予定よりも時間がかかっても大丈夫かどうかを考えておく.長時間作業になりそうな場合,適宜休憩を入れられるか考えておく.
  • [資料] ツール使用の実験などでは,操作手順を聞き逃しても追いつけるように(あるいは説明を省略できるように),操作手順を積極的にスクリーンショットなどで撮影しておき,資料に含めておく.
  • [実施] 誰がどの課題を解くかを,直前に改めて確認する.
  • [実施] 細かい質問(ツールの使い方等)はちゃんとサポートする.トレーニング用の問題を用意しておくと,課題に取り組んでいる最中でも,具体例をその問題のデータを使って示せるので楽になる.
お名前:
E-mail:
右の画像に書かれている文字列を入力してください:
コメント: