機能実現期間の測定による プログラマ能力の実験的評価 井上研究室 三谷　幸久

研究の背景(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 挙げられた機能をチェックリストにする

確認の手順（Step1,Step2） Step1:プログラムの機能を洗い出す 　　(1)プログラムレビューのチェックリスト 　プログラムの基本的な処理(タイプ1) (2)Work Breakdown Structure 仕様の機能を満たすのに必要な処理（タイプ2） (3):テスト仕様書 仕様の機能を守るのに必要な処理(タイプ3) 　 (不適切な入力をはじく等) Step2:これらの機能を全てまとめてチェック　　　　リストを作成する

確認の手順（Step3） チェック項目の確認作業 ΣtCi 評価値の値は赤い期間の合計 tC1 C1 × ○ tC2 C2 × ○ 機能実現期間 tC1 C1 × ○ tC2 C2 × ○ チェック項目 tC3 C3 ○ C4 tC4 × ○ ………… ……….. tCn Cn × ○ 時刻 t ΣtCi ×:機能作成開始時刻 評価値 ○:完成時刻

評価実験概要 ある企業の新人研修で行われた、2つ の演習課題について、提示したモデル に当てはめて能力値を求めた 今回の実験では ある企業の新人研修で行われた、2つ　　の演習課題について、提示したモデル　　に当てはめて能力値を求めた 今回の実験では 被験者数は11人 使用言語：C言語 課題1:トークン分割プログラム プログラムの規模：約300行 チェック項目：19項目 課題作成期間:3日間 課題2:トークン識別プログラム プログラムの規模：約500行 チェック項目：32項目 課題作成期間:3日間

利用したチェック項目 チェック項目の内容の具体例 タイプ1 タイプ2 タイプ3 ファイルを開いたら閉じているか 確保した記憶領域は開放しているか タイプ2 プログラム内でのソートは機能しているか 文字判別は仕様通りに行われているか タイプ3 仕様書の設定から外れた入力をはじいているか 仕様書の不備に対して適切な対応をしているか 　例:トークン識別のプログラムにおいて、トークンの種類が、　指定されていない文字が存在したが、それに対して　　　　　エラーメッセージを出力する等

計測データ 作成者 課題1 課題2 A 75 142 B 84 138 C 100 240 D 82 163 E 87 173 F 120 223 G 263 H 93 218 I 101 185 J 104 196 K 217 215

提案したモデルの妥当性の確認 プログラマ性能を決定する要素 ・プログラマとしての経験(experience) [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 D 80 4 82 2 B 83 84 3 E 87 G 77 7 H 76 8 93 6 C 100 I 101 J 63 10 104 9 F 120 K 58 11 217 順位相関係数 0.70

分析(課題2) 作成者 課題2の成績 課題2の順位 モデルの評価 モデルの順位 B 95 1 138 A 88 2 142 D 84 6 163 3 E 86 173 4 I 185 J 82 7 196 K 80 9 215 H 85 5 218 8 F 79 10 223 C 240 G 51 11 263 順位相関係数 0.79

考察 機能の実現期間に対する観察は教育機関での成績評価や課題作成の計画を確認する方法に使えるのではないか 課題の規模の大きさや作業時間の長さによって、各機能のプログラムの重要度も変わってくる 　プログラムの規模によっては、レベルごとに重みを付ける必要も出てくる

まとめ・今後の課題 チェック項目を利用した機能実現期間の測定によりプログラマ能力を求めるモデルを提案した 評価実験を行って、モデル評価値の妥当性を確認した 今後の課題として、チェック項目作成方法の簡略化と機能実現期間の測定の自動化を行えば、より簡潔なモデルとなる

説明資料の補足

コードレビューチェックリスト 目的 －プログラムの全ての欠陥を発見して修正する事が 必要な場合において正確な手順に従っているかを 確認する方法

コードレビューチェックリスト 具体例

WBS（Work Breakdown Structure） 定義 －必要な作業項目をトップダウン方式で、細かく 分析し、階層構造として表現したもの －プロジェクトの全体スコープを定義し、体系化 するためのプロダクト指向のツリー構造体

WBSの具体例 レベル0 0.0 システムAの開発 レベル1 1.0 2.0 3.0 4.0 5.0 6.0 要求分析 システム仕様 設計 コーディング テスト 運用 レベル2 3.1 3.2 コマンド処理 ユーザインタフェース 3.2.1 3.2.2 レベル3 入力 出力

WBS（Work Breakdown Structure） 手法 －ツリー構造体では下位レベルになるほど 詳細な内容を表示 －示されていない作業は当該プロジェクトの スコープ外の作業 －最下位レベルの作業要素をワークパッケージと 　 呼ぶ －ワークパッケージは、さらに作業（アクティビティ） に分解