「組込みソフトウェア開発データ白書」発行への取 … P25 p ¸ P75 6 9 1.09 1.46 2.72 è V 6 7 2.60 4.34 4.77 è V 6 11 5.15 8.21 9.50 è V 28 0.83 2.61 6.35 ・再利用率98％以上のもの

All rights reserved, Copyright © IPA 2015

定量データに基づく開発マネジメントでIoT時代の信頼性・生産性向上を目指せ！

～「ソフトウェア開発データ白書」と「組込みソフトウェア開発データ白書」から

垣間見える信頼性の実態～

「組込みソフトウェア開発データ白書」

発行への取組みと分析結果例

独立行政法人情報処理推進機構（ＩＰＡ）

技術本部ソフトウェア高信頼化センター（ＳＥＣ）

研究員松田充弘

SECセミナー＠千石 2015.12.18（金）16:30～17:30

WEB掲載用

2Software Reliability Enhancement CenterCopyright© 2015 Information-technology Promotion Agency, Japan. All rights reserved.

「組込みソフトウェア開発データ白書」公開

2015年11月18日公開予定

・組込み分野のプロジェクトデータ174件

（10社）

・2013年4月～2015年3月までの収集分

・Ａ４版１８０ページ

・既刊行の「ソフトウェア開発データ白書」と同様の構成

【公開の目的】・組込み業界へ定量データ活用を啓発するため

組込みソフトウェア開発データ白書2015


「定量データ活用ガイド」を同時公開

2015年11月18日公開予定

（組込みデータ白書公開に合わせて）

・経営者向けに定量データ活用を解説

・コストを掛けないデータ収集の仕組みを紹介

・組織の開発力・管理力の向上方法を紹介

・Ａ５版：90ページ

組込みソフトウェア向け

プロジェクトマネジメントガイド[定量データ活用編]～定量データ活用による組織の開発・管理力向上～

ＥＳＭＲ-2

【公開の目的】・経営者に定量データ活用の必要性・利点・方法を知ってもらうため（データ白書を公開しただけでは、伝わらない）


公開に至るまでの経緯

SEC設立当初（10年前）

業界が未成熟• プロジェクトの定量的管理の土台が固まっていない

• 実のところ定量的管理が出来ていない

SECは、ソフトウェアエンジニアリング手法

• 先進企業のベストプラクティスを収集・整備

• 開発現場への導入推進

ESxRシリーズがV字をカバー2013年までに


▌組込みシステム開発技術リファレンスＥＳｘＲシリーズ

開発プロセスガイド ESPR

プロジェクト計画ガイドESMG ESMR

コーディング作法ガイド ESCR

品質作り込みガイド ESQR

設計ガイドESDR

テスト事例集ESTR

バグ管理手法ガイドESBR

（C言語）

（C++言語）

英語版

英語版

英語版

英語版

定量データ活用ガイド ESMR-2


ＥＳｘＲシリーズとＶ字モデル

ESQR（品質作り込みガイド）

マネージャ

経営者

コーディング

要求定義

アーキテクチャ設計

単体テストソフトウェア詳細設計

結合・統合テスト

システムテスト

What

【プロセス定義】

開発担当

ESMR（マネジメントガイド）・ESMG（開発計画書作成ガイド）

マネジメント指針

ESDR（設計ガイド事例編）

ESBR（バグ管理手法）

ESPR（プロセスガイド）

要求仕様書の評価指標

ソースコードの品質評価

テスト作業の評価指標

設計書の評価指標

システムの品質評価指標

How

【品質指標】

ESCR（コーディング作法ガイド）

ESTR（テスト事例集）

ＥＳＭＲ-2（定量データ活用ガイド）


0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

組込みスキル標準ETSS

組込みコーディング作法ESCR

組込み開発プロセスESPR

組込みプロジェクトマネジメントESMR

導入済み導入検討中導入は未定わからない

SEC成果の活用状況 2007年度調査2008年報告

1.3%

出典：経済産業省 2008年版組込みソフトウェア産業実態調査報告書－プロジェクト責任者向け調査－

アンケート数：330社519プロジェクト


SEC成果の活用状況 2012年度調査2013年報告

0% 20% 40% 60% 80% 100%

30

%

出典：独立行政法人情報処理推進機構 2012年度「ソフトウェア産業の実態把握に関する調査」調査報告書

アンケート数：143社


現在の組込み開発

そして現在

定量データによる開発の基礎となる開発プロセスの導入が進んでいる

定量データを活用したプロジェクトマネジメントの導入する企業が増加している。⇒ 他社と比べたい

組込みデータ白書公開への期待が高まって来ている

ＩｏＴ時代に向けて

「製品の信頼性について説明する義務と責任」認識広まる

接続相手の多様性、相互接続による影響の検証⇒エビデンス？

ＳＥＣの役割：定量データ活用を広く業界に促すこと


「組込みソフトウェア開発データ白書2015」紹介



（１）

2015年度版では、主に

改良開発、派生開のプロジェクトデータを

分析


収集データの紹介（２）

注）第２回答、第３回答は複数言語を使っている場合の回答

2015年度版では、主にC及びC++言語のプロジェクトデータを

分析


収集データの紹介（３）

N P25 中央値 P75SLOC規模 173 2.4 6.1 24

SLOC規模(母体含む)

173 61 249 511

収集データのSLOC規模

[単位：KSLOC]

2015年度版プロジェクトデータのSLOC規模は大半が２.４K～２４KSLOC（中央値6.1K）

母体含むSLOC規模は大半が６１K～５１１KSLOC（中央値２４９K)


8.7%

63.6%

3.1%

77.5%

16.6%

78.0%

8.1%

19.9%

11.0%

2.9%

6.3%

2.9%

1.6%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

実績の評価

(コスト）

実績の評価

(品質）

実績の評価

(工期）

a b c d e

（４）

計画より良い計画通り計画より少し悪い計画より悪い計画よりかなり悪い

今回の収集データの

８割は計画通りのプロジェクト2割は計画通り

に行かなかったプロジェクトのデータ

プロジェクト成否


収集データの紹介（５）

ａ：強(μ秒オーダー),

16 , 11%

ｂ：普通(m秒オーダー),

110 , 77%

ｃ：気にしなくて良い,

17 , 12%

製品の特性:リアルタイム性(時間制約）

※集計対象データ： 3-1-1_ 製品の特性:リアルタイム性(時間制約）

N=143（未回答：31 件）


収集データの紹介（６）

ａ：有り,

42 , 35%

ｂ：無し,

79 , 65%

製品の特性:自然環境からの影響度合い

※集計対象データ： 3-1-2_ 製品の特性:自然環境からの影響度合い

N=121（未回答：53 件）


収集データの紹介（７）

ａ：有り,

77 , 54%

ｂ：無し,

66 , 46%

製品の特性:法規等による規制度合い

※集計対象データ： 3-1-4_ 製品の特性:法規等による規制度合い

N=143（未回答：31 件）


収集データの紹介（８）

ａ：有り,

103 , 73%

ｂ：無し,

39 , 27%

製品の特性:Ｍ２Ｍの有無

※集計対象データ： 3-1-5_ 製品の特性:Ｍ２Ｍの有無

N=142（未回答：32 件）


収集データの紹介（９）

ａ：非停止,

131 , 78%

ｂ：オンデマンド,

38 , 22%

製品の特性:稼動(非停止、オンデマンド）

※集計対象データ： 3-1-7_ 製品の特性:稼動(非停止、オンデマンド）

N=170（未回答：4 件）


収集データの紹介（１０）

ａ：可,

69 , 48%

ｂ：否,

74 , 52%

製品の特性:オンライン保守の可否

※集計対象データ： 3-1-8_ 製品の特性:オンライン保守の可否

N=143（未回答：31 件）


0

10

20

3KSLOC未満 3KSLOC以上

10KSLOC未満

10KSLOC以上

40KSLOC未満

40KSLOC以上

SLOC

生産性

[SLOC／

人時]

（１）規模別SLOC 生産性

・生産性は規模に比例してよくなる傾向が見えている。

・規模の小さいものは管理工数の比率が高くなるため、生産性が上がらないと考えられる。

SLOC規模別SLOC生産性開発５工程言語C/C++（改良・派生開発）箱ひげ図

[SLOC／人時]

N P25 中央 P75

3KSLOC未満 20 0.31 0.68 1.48

3KSLOC以上 10KSLOC未満 18 1.81 2.92 6.29

10KSLOC以上 40KSLOC未満 18 3.30 4.72 7.77

40KSLOC以上 6 4.90 7.03 10.16


0

2

4

6

8

10

12

14

16

18

20

50%未満 50%以上

90%未満

90%以上

98%未満

98%以上

SLOC生

産性

[SLOC／

人時

]（２）再利用率別SLOC生産性

再利用率別のSLOC生産性開発５工程言語C/C++（改良・派生開発）箱ひげ図

[SLOC／人時]

N P25 中央 P75

50%未満 9 1.09 1.46 2.72

50%以上90%未満 7 2.60 4.34 4.77

90%以上98%未満 11 5.15 8.21 9.50

98%以上 28 0.83 2.61 6.35

・再利用率98％以上のもの

を除けば、再利用率が高ければ生産性も高くみえる。

・再利用率98％以上のものは、SLOC規模が小さい。生

産性が上がらないのは、管理工数の比率が高くなっていると考えられる。


0

2

4

6

8

10

12

14

16

18

20

有り無し

SLOC生

産性

[SLOC／人時]

法規等による規制度合い開発５工程

言語Ｃ／Ｃ++（改良開発）箱ひげ図

（３）製品特性別SLOC 生産性

法規制のある機器を開発する方が制約が多いため、生産性は低くなると考えたが、中央値では、大きな差は見られない。

法規制が開発プロセス文書等に関するものではないのか？ただし、バラつきは、小さい。

[SLOC／人時]

N P25 中央 P75

有り 21 0.79 1.85 3.58

無し 25 0.63 2.14 6.46


0

5

10

15

20

25

30

35

40

有り無し

SLOC生

産性

[SLOC／人時

]

Ｍ２Ｍの有無開発５工程

言語Ｃ／Ｃ++（改良開発）箱ひげ図

（４）製品特性別SLOC 生産性

Ｍ２Ｍの有りの場合のほうが生産性が落ちるのは、新規の技術が使われているからだろうか？

[SLOC／人時]

N P25 中央 P75

有り 39 0.62 1.80 3.71

無し 7 2.57 4.81 5.14


0

10

20

0 50 100 150 200

結合テスト検出バグ密度

[件／

KSLOC]

SLOC実績値 [KSLOC]

ｂ：言語Cｃ：言語C++ｂ,ｃ以外

N=147

（１）信頼性

SLOC規模と結合テスト検出バグ現象密度（改良派生開発、言語別）

バグ密度は規模の小さいところではバラつく傾向が見えている。

[件／KSLOC]

N P25 中央 P75

ｂ：言語C 80 0.28 1.48 3.18

ｃ：言語C++ 51 0.00 0.68 1.76

ｂ,ｃ以外 16 1.04 2.30 4.25


0

10

20

0 50 100 150 200

総合

テス

ト検

出バ

グ密

度[件

／KSLOC]

SLOC実績値 [KSLOC]

ｂ：言語Cｃ：言語C++ｂ,ｃ以外

N=107

（２）信頼性

・結合テスト同様にバグ密度は規模の小さいところではバラつく傾向が見えている。・総合テストの考え方には、バグ取りの場合とバグが無いことを確認する場合が見える

SLOC規模と総合テスト検出バグ現象密度（改良派生開発、言語別）

[件／KSLOC]

N P25 中央 P75

ｂ：言語C 47 0.01 0.44 1.70

ｃ：言語C++ 44 0.00 0.09 0.50

ｂ,ｃ以外 16 0.00 0.04 1.10


（１）結合テスト、総合テスト

※表示されていないものが1点ある。総合テスト(約175,000付近)。

0

5,000

10,000

15,000

20,000

25,000

30,000

結合テスト

（テストケース）

総合テスト


工数

あた

りの

テス

トケ

ース

数［

件／

160人

時］

0

10

20

30

40

50

60

70

80

90

100

結合テスト

検出バグ数

（現象）

総合テスト

検出バグ数

（現象）

工数

あた

りの

検出

バグ

数［

件／

160人

時］

・工数あたりのテストケース数は、総合テストよりも結合テストの方が大きい。言い換えると、テストケース1件当たりのコストは、総合テストの方が高い。

・工数あたりの検出バグ数は、総合テストよりも結合テストの方が大きい。言い換えると、バグ1件を見つけるコストは、結合テストよりも総合テストの方が高い。

工数あたりのテストケース数、検出バグ数：改良(派生)開発

●工数あたりの検出バグ数（改良(派生)開発）箱ひげ図

●工数あたりのテストケース数（改良(派生)開発）箱ひげ図


0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

アーキテク

チャ設計

詳細設計

実装・単体

テスト

結合テスト

総合テスト

比率

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

アーキテク

チャ設計

詳細設計

実装・単体

テスト

結合テスト

総合テスト

比率

改良、派生開発の工程別工数比率改良、派生開発の工程別工期比率

組込み組込み

紹介（２）工程別工数・工期比率比率

基本設計詳細設計製作結合テスト総合テスト

比率

基本設計詳細設計製作結合テスト総合テスト

エンタエンタ

・工数・工期ともに実装工程

の比率が目立って大きい

・詳細設計よりもアーキテクチャ設計の比率が工数・工期ともに大きい

・実装の期間が工数の割りに短い

アーキテク

チャ設計

詳細設計

実装・単体

テスト

結合テスト

総合テスト

アーキテク

チャ設計

詳細設計

実装・単体

テスト

結合テスト

総合テスト


SLO

Cテストケース密度［件

/KSLO

C］

結合テスト


総合テスト


53

17

0

2

4

6

8

10

12

14

16

18

結合テスト

検出バグ数

（現象）

総合テスト

検出バグ数

（現象）

SLOC検出バグ密度

［件／

KSLOC］

1.1 0.3

0

500

1,000

1,500

2,000

2,500

3,000

結合テスト


総合テスト


SLOCテストケース密度

［件／

KSL

OC］

15683

改良、派生開発（C/C++）の検出バグ数/規模

組込み

（３）規模あたりのテストケース数、検出バグ数

改良、派生開発（C/C++）のテストケース数/規模

組込み

SLOC検出バグ密度［件

/KSL

OC］

結合テスト

検出バグ数

（現象）

総合テスト

検出バグ数

（現象）

結合テスト

検出バグ数

（原因）

総合テスト

検出バグ数

（原因）

1.3

0.3

主開発言語（COBOL,C,VB,Java）

組込みのほうが

テストケース密度が高い

エンタ主開発言語（COBOL,C,VB,Java）

組込み、エンタとも

バグ検出密度は同じ

エンタ

結合テスト（テストケース）

総合テスト（テストケース）

結合テスト（検出バグ数）

総合テスト（検出バグ数）


ＥＳＭＲ-2

組込みソフトウェア向け

プロジェクトマネジメントガイド[定量データ活用編]～定量データ活用による組織の開発・管理力向上～

ここからの話は、

定量データ収集の仕組みが出来ていない組織向けのお話です。

32Software Reliability Enhancement CenterCopyright© 2015 Information-technology Promotion Agency, Japan. All rights reserved.32

2章

まずは経営者に知ってもらう

3章コストを掛けずに定量データを収集する

4章PMOが支援するプロジェクトマネジメントの例

5章PMOが支援する組織の開発力の測定、作業量の目安


経営判断、開発力改善の判断 ⇒ 的確・迅速

経営者の行動に役立つ定量データの活用

（例）フェイスチャート月次報告


経営者の行動に役立つ定量データの活用

（例）マクロ分析 4半期報告

経営判断、開発力改善の判断 ⇒ 的確・迅速

※この例ではKSLOC当たりの開発費


定量データ収集と管理指標

（１）収集すべきデータ項目

（３）収集データから導く管理指標

（２）データ収集方法



（１）収集すべきデータ項目と収集先

工数（社内、社外）（工程別）は管理の仕組みがいる

バグ件数、テスト件数の管理は定着している？

プログラムソースコード行数は、フリーソフトで数える



（２）データ収集方法

● コストを掛けないで収集。MS-Office 等の既存ツールやオープンツールの活用。● PMOは収集したいときにタイムリーに収集できること。● バッチファイル等ツールを作り出来る限り自動収集。※プロジェクト側に負担を掛けるとデータ収集は定着しない。● プロジェクト側とPMO 側が共有できる作業フォルダ※成果物ファイルの命名ルール・版数管理ルール・置き場所● 管理帳票類はExcel で作成すれば、データ収集ユツール作成が容易● 工数は勤怠管理システムから採れば良い。誤差は構わない。8 割くらいの正確さで良い。● ソースコード行数の収集はビルドに組み込む。



（３）収集データから導く管理指標

活用場面プロジェクトマネジメント組織改善

紹介する指標 SECBOOKS 「組込みソフトウェア開発品質作り込みガイド」ESQRに定義された指標

その他よく活用されている指標



工程別の管理指標


（１）計画作成（Plan）

• 開発規模・工数・リソースの見積もり

⇒ 目安となる組織の指標を活用

• 品質、コスト、生産性、進捗の目標値・管理限界値（上限、下限）の設定

⇒ 過去データをベースにカスタマイズ

（２）管理指標のモニタ（Check）

（３）プロジェクトコントロール（Act）

プロジェクトマネジメントにおける定量管理

次ページ



バグ曲線による進捗判断の例（未解決バグ数の変化）

【指標のモニター状況と判断】

(a)未解決バグ数の変化量増加のままで減少に転じない場合：・想定以上のバグがある・バグの内容が難しくて修正が進まない⇒大幅な遅延の可能性あり

(b)一定の範囲に留まったままで減らない場合：・原因特定が困難なバグ・修正してもその影響でバグが出続けている（もぐら叩き）状態⇒修正不可能なソフトウェアである可能性が高い

(c)(d)減少傾向が続いている場合：・グラフの延伸が未解決バグ０に到達⇒未解決バグの収束が予測できる。※(c)は目標期日を遅延



アクションリスク

1. リソース追加弱点部分（チーム、WBS）に投入費用の追加を伴う

2. リソース入替え

・担当者に負荷がかかりすぎている場合は、担当パートの一部を他の担当者に移す・担当者のスキルが低い場合は、スキルの高い別担当者と入れ替える

一時的にスローダウンする

3. リソース強化エキスパート投入し、支援・指導に当たらせる

指導に費用の追加が発生する場合がある

4. WBS 削減

機能を落とす顧客又は商品企画部門と交渉が必要である

標準プロセスの一部を省き、作業をショートカットする

品質低下による納期遅延・費用追加リスクがある

5. WBS 入替え WBS の順序変更（含先送り）を行う全体としてスケジュール不整合の発生リスクがある

後々品質低下による納期遅延・費用追加リスクがある

6. リスケジュールマイルストーンを変更する全体としてスケジュール不整合の発生リスクがある

結局遅延するリスクがある

7. 作り直し別リソースを投入して当該部分（モジュール、コンポーネント）を再開発する

追加費用を伴う

全体としてスケジュール不整合の発生リスクがある

継続する場合との納期遅延・追加費用リスクの比較必要で、作り直しの判断時期を誤ることが多い

納期遅延を回避するアクション（例）


指標活用による組織の開発力改善

（１）見積もりの適正化• 全体コスト見積もり

SLOC規模（経験と勘での見積もり）

SLOC生産性（組織の指標）

工数=SLOC規模÷生産性

• テスト工数の見積もりテスト密度（SLOC規模当たりのテスト項目数）

バグ密度（SLOC当たりのバグ検出件数）

テスト項目消化平均工数（項目当たりの必要工数）

バグ解決に要する平均工数（1件あたりの必要工数）

（２）品質（信頼性）向上

（３）生産性向上


まとめ

「組込みソフトウェア開発データ白書」の狙い

【社会背景】

• IoTの時代。どんなものが（に）繋がっても問題を起こさない強い製品・システム

• 経営トップは「知らない」では済まされない社会の変化

【備えるべきこと】個人に依存した開発から組織的な開発へ

見えないものを見えるようにする

⇒ケルビン卿の言葉「測れないものは、予測したり管理したりすることが出来ない」

【今なら出来るのでは】

ベテラン技術者が居る。若い世代の技術者のために良い導きができるはず。


最後に


ご参加いただける企業を募集いたします

• もっと深い統計分析ができるほどのデータ件数が必要

◆データ提供企業目標数20社以上◆

⇒ 分析結果の信頼性を向上させるため

⇒ 複数カテゴリでのクロス分析を可能にするため

• データ白書の利便性を向上

◆参加企業募集◆「製品・制御システム定量データ収集分析WG」


活動の進め方

◆WG参加企業の利点◆

① WG内限定の分析レポートを提供

② WG参加企業独自の分析が可能なツールの利用

WGを設置し継続的改善を進める

※参加企業名と委員名は非公開

秘密保持契約締結

※厳重なデータの管理実施


活動の進め方


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



「ｉパス」は、ITを利活用するすべての社会人・学生が備えておくべきITに関する基礎的な知識が証明できる国家試験です。

ITパスポート公式キャラクター上峰亜衣（うえみねあい）

【プロフィール：マンガ】 https://www3.jitec.ipa.go.jp/JitesCbt/html/uemine/profile.html


Windows Server 2003のサポートが2015年7月15日に終了しました。

サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功する可能性が高まります。

周辺ソフトウェアもサポートが順次終了していくため、あわせて対策が必要です。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの影響調査や改修等について迅速な対応をお願いします。

会社の事業に悪影響を及ぼす被害を受ける可能性があります

IPA win2003 検索詳しくは

なおWindowsXPを利用されている方はサポートが継続しているOSへの移行検討をお願いします

脆弱性が未解決なサーバ

脆弱性を悪用した攻撃

ホームページの改ざん

重要な情報の漏えい

他のシステムへの攻撃に悪用

業務システム・サービスの停止・破壊

データ消去

Windows Server 2003のサポート終了に伴う注意喚起


IPA ソフトウェア高信頼化センター(SEC)

Software Reliability Enhancement Center , Information-technology Promotion Agency , Japan

で、

IPA/SECの事業内容やセミナー動画をCheck！

●SEC事業紹介http://www.ipa.go.jp/sec/about/index.html

●SECセミナーオンデマンドhttp://sec.ipa.go.jp/seminar/ondemand/

Twitterで、

IPA/SECの最新情報をCatch！

https://twitter.com/IPA_SEC

アカウント名：＠IPA_SEC

SWE iPediaで、

IPA/SECの事業成果をSearch！

探したい情報を

分類やキーワードで検索！

http://sec.ipa.go.jp/sweipedia/

IPA/SECウェブサイトで利用者登録！

IPA/SECウェブサイトから利用者登録（無料）をすると、

メルマガ・DMの購読や、セミナーの参加申込み、ツールの

利用などができます。

是非、ご登録ください！

https://sec.ipa.go.jp/entry/index.html

↓詳しくは、SECウェブサイトをClick！

ソフトウェア高信頼化センター検索

Documents

「組込みソフトウェア開発データ白書」 発行への取 … P25 p ¸ P75 6 9 1.09 1.46 2.72 è V 6 7 2.60 4.34 4.77 è V 6 11 5.15 8.21 9.50 è V 28 0.83 2.61 6.35 ・再利用率98％以上のもの

「組込みソフトウェア開発データ白書」発行への取 … P25 p ¸ P75 6 9 1.09 1.46 2.72 è V 6 7 2.60 4.34 4.77 è V 6 11 5.15 8.21 9.50 è V 28 0.83 2.61 6.35 ・再利用率98％以上のもの