機能実現期間の測定によるプログラマ能力の実験的評価井上研究室三谷幸久研究の背景(1/2) 近年、社会の中でソフトウェアの果たす役割が大きくなっており、それに伴いソフトウェアの欠陥や故障が社会に与える影響も大きくなってきた信頼性の高いソフトウェアが求められているソフトウェアは、大規模化、複雑化、多様化しているのに開発期間は短縮化されているソフトウェア開発においてプログラマ能力は、開発期間やコスト、信頼性に高い影響力を持つプログラマ能力の正確な測定は、開発の見積もりを行う上で必要不可欠だが困難研究の背景(2/2) プログラマ能力と評価法プログラマ能力の差による作業時間の差デバッグ作業時間が28倍[1] COCOMOモデルによると、最大で生産コストが2倍になる[2] デバッグに着目したプログラマ能力の判定モデルエラー寿命による評価キーストロークによる評価判定には膨大な時間とコストがかかってしまう [1] H.Sackman W.J.Erickson and E.E.Grant:”Exploratory experimental studies comparing online and offline programming performance”,Commun.ACM,11,1,pp.3-11(1968) [2]山田茂･高橋宗雄著ソフトウェアマネジメントモデル入門,共立出版、1999 研究の目的プログラマ能力を簡潔に評価するためのモデルを提案する提案したモデルの評価実験を、ある企業の開発プロジェクトで収集したデータを用いて行うモデルのキーアイディアプログラム中で実現すべき機能に対して、それぞれの機能の作業開始時間と実現した時間を用いて評価する確認方法チェックリストを利用して確認する方法を提案する具体的観測方法確認の手順 Step1 作成するプログラムの機能を洗い出す Step2 挙げられた機能をチェックリストにする Step3 実際の開発過程からデータを収集して各チェック項目を確認していく確認の手順（Step1,Step2） Step1:プログラムの機能を洗い出す (1)プログラムレビューのチェックリストプログラムの基本的な処理(タイプ1) (2)Work Breakdown Structure 仕様の機能を満たすのに必要な処理（タイプ2） (3):テスト仕様書仕様の機能を守るのに必要な処理(タイプ3) (不適切な入力をはじく等) Step2:これらの機能を全てまとめてチェックリストを作成する確認の手順（Step3）チェック項目の確認作業 Cn ……….. ………… チェック項目 C1 C2 C3 C4 評価値の値は赤い期間の合計機能実現期間 tC1 × ○ tC2 × ○ tC3 ○ tC4 ○ × × ×:機能作成開始時刻 ○:完成時刻 ○ 時刻 t tCn ΣtCi 評価値評価実験概要ある企業の新人研修で行われた、2つの演習課題について、提示したモデルに当てはめて能力値を求めた今回の実験では •被験者数は11人 •使用言語：C言語課題1:トークン分割プログラム課題2:トークン識別プログラムプログラムの規模：約300行プログラムの規模：約500行 •チェック項目：19項目 •チェック項目：32項目 •課題作成期間:3日間 •課題作成期間:3日間利用したチェック項目チェック項目の内容の具体例タイプ1 • ファイルを開いたら閉じているか • 確保した記憶領域は開放しているかタイプ2 • プログラム内でのソートは機能しているか • 文字判別は仕様通りに行われているかタイプ3 • 仕様書の設定から外れた入力をはじいているか • 仕様書の不備に対して適切な対応をしているか例:トークン識別のプログラムにおいて、トークンの種類が、指定されていない文字が存在したが、それに対してエラーメッセージを出力する等計測データ作成者課題1 課題2 A 75 142 B 84 138 C 100 240 D 82 163 E 87 173 F 120 223 G 87 263 H 93 218 I 101 185 J 104 196 K 217 215 提案したモデルの妥当性の確認プログラマ性能を決定する要素 [3] ・プログラマとしての経験(experience) 学生や研修生の場合、これまでに習得したコンピューターサイエンスやプログラミングの講義の総数・プログラマとしての素質(aptitude) 学生や研修生の場合、これまでに習得したコンピューターサイエンスやプログラミングの講義の成績研修生のプログラマ性能は講義の成績と関係を持っている[4] 評価値と成績の相関を取る [3]T.Moher and G.M.Schneider:”Methods for improving controlled experimentation in software engineering”,Proc.5th ICSE [4]松本健一、井上克郎、菊野亨、鳥居宏次、“エラー寿命に基づくプログラマ性能の実験的評価”電子情報尾通信学会分析(課題1) 作成者課題1の成績課題１の順位モデルの評価モデルの順位 A 90 1 73 1 D 80 4 82 2 B 83 2 84 3 E 80 4 87 4 G 77 7 87 4 H 76 8 93 6 C 83 2 100 7 I 76 8 101 8 J 63 10 104 9 F 80 4 120 10 K 58 11 217 11 順位相関係数 0.70 分析(課題2) 作成者課題2の成績課題2の順位モデルの評価モデルの順位 B 95 1 138 1 A 88 2 142 2 D 84 6 163 3 E 86 3 173 4 I 86 3 185 4 J 82 7 196 6 K 80 9 215 7 H 85 5 218 8 F 79 10 223 9 C 82 7 240 10 G 51 11 263 11 順位相関係数 0.79 考察機能の実現期間に対する観察は教育機関での成績評価や課題作成の計画を確認する方法に使えるのではないか課題の規模の大きさや作業時間の長さによって、各機能のプログラムの重要度も変わってくるプログラムの規模によっては、レベルごとに重みを付ける必要も出てくるまとめ・今後の課題チェック項目を利用した機能実現期間の測定によりプログラマ能力を求めるモデルを提案した評価実験を行って、モデル評価値の妥当性を確認した今後の課題として、チェック項目作成方法の簡略化と機能実現期間の測定の自動化を行えば、より簡潔なモデルとなる説明資料の補足コードレビューチェックリスト目的－プログラムの全ての欠陥を発見して修正する事が必要な場合において正確な手順に従っているかを確認する方法コードレビューチェックリスト具体例 WBS（Work Breakdown Structure）定義－必要な作業項目をトップダウン方式で、細かく分析し、階層構造として表現したもの－プロジェクトの全体スコープを定義し、体系化するためのプロダクト指向のツリー構造体 WBSの具体例レベル0 レベル1 0.0 1.0 5.0 設計コーディングテスト 3.2 3.1 コマンド処理レベル3 4.0 3.0 2.0 要求分析システム仕様レベル2 システムAの開発ユーザインタフェース 3.2.1 3.2.2 入力出力 6.0 運用 WBS（Work Breakdown Structure）手法－ツリー構造体では下位レベルになるほど詳細な内容を表示－示されていない作業は当該プロジェクトのスコープ外の作業－最下位レベルの作業要素をワークパッケージと呼ぶ－ワークパッケージは、さらに作業（アクティビティ）に分解