機能実現期間の測定による
プログラマ能力の実験的評価
井上研究室
三谷 幸久
研究の背景(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の
成績
課題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)
手法
-ツリー構造体では下位レベルになるほど
詳細な内容を表示
-示されていない作業は当該プロジェクトの
スコープ外の作業
-最下位レベルの作業要素をワークパッケージと
呼ぶ
-ワークパッケージは、さらに作業(アクティビティ)
に分解
ダウンロード

卒業論文中間発表 - Software Engineering Laboratory