株式会社 エーアイネット・テクノロジ 川村廉平 ソフトウェアメトリクス による品質管理 株式会社　エーアイネット・テクノロジ 　　　川村廉平

テーマの動機 開発研修で指導員にレビューしてもらった際、 バグ密度やチェックリスト密度の話を聞いて 　ソフトウェア品質管理に興味をもった。

近年、デジタル化の波と共にソフトウェアの 重要性が高まってきている。 品質管理が重要視される背景 近年、デジタル化の波と共にソフトウェアの 重要性が高まってきている。 社会的に大きな影響を及ぼす システム障害が多く発生している。

最近の主なシステム(ソフトウェア) トラブル事例 最近の主なシステム(ソフトウェア)　トラブル事例 2007/3/2 au3機種64万台に不具合 フル充電できず、電池劣化が進行 充電機能のソフトウェア不具合 2007/5/23 NTTひかり電話が３時間半にわたり不通 中継機器交換時にコマンド誤入力 2007/5/27 全日空国内線予約システム故障 130便が欠航、損失4.5億円 ルータ管理プログラムの設定ミス 2007/10/12 2007/10/18 自動改札機起動せず PASMO-Suica窓口処理機で異常発生 中央コンピュータからのデータをIC カードに書き込むプログラムにミス 2008/7/22 東京証券取引所のシステム障害 単純なプログラムミス(4けたの数字を入力する箇所に「4」と入力) 2008/9/14 全日空搭乗システム障害 63便が欠航し、277便が遅延、損失2億円 暗号化機能の有効期限設定ミス

ソフトウェアメトリクス ソフトウェアの品質管理が重要 「見える化」＝定量化 「測定できないものは管理できない」 You cannot manage what you can’t measure ソフトウェアメトリクス

ソフトウェアメトリクスの目的 目に見えないシステム開発プロジェクトを数値データにより可視化して評価 成果物に対する目標設定（予測） プロジェクトの進捗度 問題を見つけ出すための分析 成果物のリリース基準 経験としてデータベース化

事例 不具合データの分析 時系列による、不具合の発生数 重要度毎の発生率 ソフトウェア信頼性成長曲線 バグ発生率 バグ発生数 時間 重要度 Minor Major Fatal 時間 重要度 時系列による、不具合の発生数 重要度毎の発生率 バグの摘出状況の監視 引用： SRA-KTL技術セミナー, 20080521 ソフトウェア信頼性成長曲線

-マイクロソフト社の事例- 引用： http://diamond.u-gakugei.ac.jp/~hazeyama/Lecture/system-design/SoftwareMetrics.ppt　

-オムロン社の事例- 引用： http://diamond.u-gakugei.ac.jp/~hazeyama/Lecture/system-design/SoftwareMetrics.ppt　

メトリクスの分類 成果物メトリクス プロセスメトリクス 資源メトリクス コードメトリクス 設計メトリクス 作業効率（時間・コスト工数） 人的資源 生産性 例計測対象 コードメトリクス：コード行数・複雑さ・バグ数 設計メトリクス ：モジュール結合度 ・ファンクションポイント プロセスメトリクス：設計変更・コード修正・欠陥発見のイベント数 生産性：投入した工数と結果として得られた出力

実際何を測定すれば・・・ ボトムアップアプローチ トップダウンアプローチ テスト密度、バグ密度etc　一定の範囲におさまっていなければ、会議の議題にあげたり、再チェックしたり。 トップダウンアプローチ GQM ISO15939 CMMI 測定と分析 ボトムアップ 　計測可能なメトリクスをまず計測 　評価したい特性との関連を調べる トップダウン 　まず目的を決めて、メトリクスは目的が達成されているかどうかを評価する道具

GQM 目標 目標 質問 質問 質問 質問 質問 メトリクス メトリクス メトリクス メトリクス メトリクス メトリクス

「ソフトウェアの修正依頼処理」の 「適時性（処理にかかる時間の妥当性）」を 「プロジェクトマネージャ」の立場から「改善」する ソフトウェアの修正依頼処理 にかかる時間は？ 処理時間は改善されたか？ マネージャ満足度の 主観的評価値 処理時間の標準偏差 平均処理時間 多種多様なメトリクスの中から，その使用目的や特性に応じたものを選択し，組み合わせる 平均処理時間 / 標準的な平均処理時間 処理時間が上限を 超える場合の割合

定量管理企業の増加 引用： 日経コンピュータ＇2008年12月1日号（：第2 回プロジェクト実態調査) URL:http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323664/?ST=pm&P=2 引用：　日経コンピュータ＇2008年12月1日号（：第2 回プロジェクト実態調査)

測る企業は成功率が2倍に 引用： 日経コンピュータ＇2008年12月1日号（：第2 回プロジェクト実態調査) URL:http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323664/?ST=pm&P=2 引用：　日経コンピュータ＇2008年12月1日号（：第2 回プロジェクト実態調査)

問題点 計測するためのコストがかかってしまう プロジェクト全体の7-9%（収集3%,処理分析4-6%） 大まかな状況や傾向を数値から把握 ：by SEL（Software Engineering Laboratory） 必要以上に高い精度を求めると逆効果 大まかな状況や傾向を数値から把握

ソフトウェアメトリクスを調査した結果 今まで成果物の品質を意識したことがなかった バグは発見して修正すればいいと考えていた 　バグは発見して修正すればいいと考えていた 成果物の品質を意識し、自分の能力向上を図りたい 　　　　 第一歩として、作成したソースコードのバグ密度を 　 　　　 記録し改善を試みる 目標：キロステップあたり20件 → キロステップあたり10件 ソフトウェアやその開発過程の現状を把握し，将来を予測することで，不確実性の高いソフトウェアプロジェクトの品質，コスト，進捗をコントロールする．

ご清聴ありがとうございました