読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

IPA/SEC「ソフトウェア開発データが語るメッセージ2015」を読む

Project Management

IPA/SECさんではソフトウェア開発に関するデータ収集を行っており、その結果は毎年公表される「ソフトウェア開発データ白書」に反映されている。ソフトウェア開発プロジェクトの見積りや品質管理でいろいろ活用できて便利なデータ集であるけれども、なかなか俯瞰して読み解くのは難しい。今回、かわりにIPA/SECさんが分析して有用なメッセージを説明してくれるという「ソフトウェア開発データが語るメッセージ2015」が発表された。というわけで内容をナナメ読み。

この度、信頼性向上のために有用と考えられる新たな項目を中心に分析を行い、それらの分析結果と定量的管理への助言(以下、メッセージ)とを纏めた「ソフトウェア開発データが語るメッセージ2015」(以下、本書)を作成した。本書は、次のようにエンジニアリング編、マネジメント編及びトレンド編の三編から成っており、それぞれ主に開発プロジェクトのプロジェクト・マネジャー及び担当者、開発組織の管理層の方々、業界や国等の政策立案担当者の方々に活用していただくことを意図している。ソフトウェアの信頼性及び生産性の向上に向けた定量的管理推進のご参考になれば幸いである。
「ソフトウェア開発データが語るメッセージ2015」 1.はじめに、より

「ソフトウェア開発データが語るメッセージ2015」ナナメ読み

非常に乱暴に興味のある範囲で要約しているので、詳細は現物を確認すること推奨。だってナナメ読みだもの。

エンジニアリング編

  • レビュー工数比率が低すぎると死ぬ。工数比率7%以上は必要。
  • 設計文書が少ないとレビュー効果は低い。一般的には新規開発なら15.8ページ/KSLOCくらい設計書書け。
  • レビューをやればやるほど指摘は増えるが、やりすぎると検出効率は落ちる。新規開発なら9.8人時/KSLOCくらいで。
  • テスト密度が低く不具合検出密度が高いのは危険信号。新規開発なら、テスト密度30.8ケース/KSLOC、不具合密度1.6件/KSLOCが目安。
  • テスト検出能率が低いほうが信頼性が高い傾向がある。検出能率が低下しているかをチェックすべき。
  • テストを増やせば増やすほど不具合は発見できるが、検出能率は下がっていく。新規開発なら58.6ケース/KSLOCくらいまでの強化にしておく。
  • 上流工程で不具合摘出比率が多いほうが信頼性は多い。上流重視で設計レビューをした方が良い。
  • 開発規模と成果物量、工数は強い相関があるので、見積りと計画評価時に留意すべき。

改めて考えると、非常に当たり前の事が書かれているが数値は参考になる印象。
例えば100KSLOC規模のソフトウェアで考えるとこんな感じ。

  • FP … 約1800程度 (言語がJavaであると仮定して、マコネルの見積り本を参考に1FPあたり55SLOCで換算)
  • レビュー時間 … 980人時程度 = 7人月程度
  • 設計書 … 1580ページくらい = コピー用紙で暑さ16cmくらいorz
  • テストケース … 3000ケース程度から、6000ケースくらいまで
  • 摘出不具合 … 160件程を目標に

マネジメント編

  • ユーザ担当者の要求仕様関与度が高いと、生産性が1.7倍増し、稼動後の不具合が8分の1になる。
  • 要求仕様が明確な場合、あいまいな場合に比べて稼動後の不具合が9分の1になる。
  • 品質保証の専門スタッフが参加すると、稼動後の不具合が15分の1になる。
  • 生産性や信頼性は業種によって違う。
  • 設計文書化密度、レビュー工数密度、レビュー指摘密度、テスト密度などにより生産性は変動する。
  • 信頼性の高いプロジェクトは、レビュー工数密度、上流工程不具合摘出比率が高く、テスト検出不具合密度とテスト検出能率が低い。

後半の品質関連は「あたりまえだ」という気もするが、具体的な差異なども分析結果として示されているので興味があれば現物を確認してほしい。ユーザ担当者の参画や品質専門スタッフの参加による稼動後不具合の変動は割と興味深く、プロジェクト立上時に知っておくとよさそうな気がする。

トレンド編

  • 2004年~2012年の間で、稼動後不具合の密度は少しずつ低下している。
  • 2004年~2012年の間で、SLOC生産性は変化していない(生産性向上も低下もない)

ソフトウェア開発プロジェクトは、低価格と短納期の強いプレッシャーに晒されることが多々ある。また、予算管理や価格交渉等の場面で、年率5%の開発コスト削減や前年度比10%のライン単価低減等が要求されるケースが散見される。しかし、データによる裏付け等の根拠が希薄であると、このような状況は開発プロジェクトのリスク増大や品質低下を招く恐れがある。

割と最後の分析は重要で、覚えておくとよいと思う。ソフトウェア開発の相対的な難易度が高まっていく傾向がある中で、善戦していると解釈するのでいいような気がする。まぁ、銀の弾丸は無いということだ。

「ええ、わたくしどもの国では、ふつうはどこかよそにたどりつくんです――もしいまのわたしたちみたいに、すごく速く長いこと走ってたら」 「グズな国じゃの! ここではだね、同じ場所にとどまるだけで、もう必死で走らなきゃいけないんだよ。そしてどっかよそに行くつもりなら、せめてその倍の速さで走らないとね!」
鏡の国のアリス

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす