デバッグ工程は計画するの？(ソフトウェア分析)
このように現状では、デバッグ工程はテスト工程の陰に隠れてしまいます。テスト工程よりも多く掛かるデバッグ工程が隠れてしまい、その結果、隠れてしまったデバッグの本質が失われてしまいます。
デバッグ工程は最初から計画するの？
ソフトウェア開発で多くの時間を要するデバッグを、最初からプロジェクト計画に明記するのでしょうか。
バグは必ず出る
ソフトウェア開発では、バグは必ず出ます。リリース後の運用中のバグは大問題になりますが、開発中のバグがある程度出るのは問題ではありません。
どのくらい出るかと言うと以下のような感じに出ます。
出典：IPA ソフトウェア開発分析データ集2022
（ちなみに私がこのデータ集を担当していました。って宣伝？）
https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf
p.57 表5-1-1 SLOC 規模あたりのテストケース数、検出バグ数(全開発種別)
このようにソフトウェア開発での開発中のバグは必ず出ます。逆に出さないと、リリース後の運用中に未発見のバグが出てしまうかもしれません。
このバグをデバッグする工程、期間、要員は、プロジェクト計画の最初から計画しているのでしょうか。
テスト工程は大きい
ソフトウェア開発のプロジェクト計画で、各工程の割合は概略以下のようになります。
https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf
p.167 図A3-3-8 工程別の実績工数の比率(新規開発)の箱ひげ図
このようにテストは、プロジェクト全体の1/3近くの工数を要します。
これは、既に伝説となったCOCOMOの工程比率である「設計：製造：テスト＝3:4:3」とほぼ一致します。
例えば、1億円の開発であれば、3000万円はテストに掛かります。これは他の開発と比較して、大きいものになる。
デバッグはテストに隠れる
単体テストを除くデバッグは、このテスト工程に含まれます。このようにテストとデバッグは一体化しています。デバッグはその名前も奪われて、テストの陰に隠れます。
この結果、どのくらいデバッグに掛かっているかは不明です。純粋なテスト工数も不明になります。
またテストをする要員とデバッグする要員は一般的に別々になり、両者は並列して実施する場合が多くます。この結果、両者の区別が面倒になるのも事実です。 両者の実際の線表は以下のような感じになるでしょう（これは決して表には出ないかもしれませんが）。
テスト ：--- --- ---
デバッグ：--------------------------
デバッグは計画的に
今日の結論は「デバッグは計画的に」です。
開発中のバグは必ず出ます。出さなければいけません。このバグをデバッグする工数は必要です。計画が必要です。工程としてテスト工程と独立して計画する必要があります。
これによってデバッグを定量的に科学的に管理する最初のステップになります。これがやがて、本当のバグ＝リリース後の運用中のバグを定量的に評価することに繋がります。
ソフトウェア開発のデータ引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
# 私が担当していましたので、上記に関する質問やコメントなどもここで受け付けています。
いいなと思ったら応援しよう！
