Download 講演資料 - IPA 独立行政法人 情報処理推進機構

Transcript
Software
Engineering
Center
Information-technology Promotion Agency, Japan
第三者の検証・妥当性確認による品質説明力の強化
~組込み産業の現状とソフトウェア品質監査制度'仮称(~
独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター
統合系プロジェクト&組込み系プロジェクト サブリーダー
東海大学 専門職大学院組込み技術研究科 客員教授
九州工業大学 情報工学部 客員教授
工学博士 田丸 喜一郎
Software Engineering Center
0
SEC
組込みシステム製品開発費と組込みソフトウェア開発費・開発費比率の
推移
100
組込み製品開発費(1,000億円)
1000億円
組込みソフトウェア開発費(1,000億円)
Software Engineering
for Mo・No・Zu・Ku・Ri
製品開発費に占める組込みソフトウェア開発費の割合
60%
組込みソフトウェア開発費の割合:49.6%
2004-20011年平均成長率'CAGR:Compound Annual Growth Rate(:5%
49.6%
49.0%
80
50%
46.2%
43.6%
42.4%
40.6%
40.4%
40%
36.3%
60
30%
85.9
82.8
40
73.9
70.8
67.5
20%
59.4
57.2
54.9
42.1
20
20.7
24.1
27.3
32.7
35.1
30.4
27.4
0
10%
0%
2004年版
2005年版
2006年版
2007年版
2008年版
2009年版
2010年版
2011年版
(社)日本機械工業連合会(平成21年度生産額実績統計)、組込みシステム産業の実態把握調査
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
1
SEC
製品出荷後の丌具合発生製品率の推移
なし
10%未満
Software Engineering
for Mo・No・Zu・Ku・Ri
10~20%未満
20~30%未満
30%以上
2011
2010
2009
2008
2007
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
2
SEC
製品出荷後の丌具合の原因と「対策費+損失」
Software Engineering
for Mo・No・Zu・Ku・Ri
丌具合の原因'製品数ベース(
運用・保守の不具合
2.0%
取扱説明書・表示等
その他
の不具合
6.6%
2.6%
操作・使用環境等使用者
に起因する不具合
3.7%
他製品・他システムとの接続
に起因する不具合
4.1%
5億~10億円未満 10億円以上
5.3%
1.1%
ソフトウェアの不具合 2億~5億円未満
5.3%
42.2%
なし
29.8%
1億~2億円未満
5.3%
5,000万~1億円
4.3%
未満
システム設計の不具合
7.6%
2,000万~
5,000万円
未満
11.7%
製品企画・仕様の不具合
8.8%
ハードウェアの不具合
11.2%
「対策費+損失」
100万~200万円
未満 8.5%
1,000万~
2,000万円未満
9.6%
製造上の不具合
11.2%
500万~1,000万円
未満
7.4%
200万~500万円
未満
11.7%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
3
SEC
事業部門における2009会計年度の開発費用の内訳
開発対象別と費用別
Software Engineering
for Mo・No・Zu・Ku・Ri
開発対象別の内訳
費用別の内訳
その他の費用
(共通費用等)
7.7%
その他の経費
5.8%
ソフトウェア開発費
49.6%
ハードウェア購入費
7.0%
ソフトウェア購入費
4.9%
システム開発費
17.6%
社内人件費
62.6%
外部委託費
14.7%
ハードウェア(機構系)
開発費
9.1%
2007会計年度
開発対象別の内訳
人材派遣費
5.0%
ハードウェア(電子系)
開発費
16.0%
2007会計年度
費用別の内訳
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
4
SEC
工程別丌具合発見件数比率と丌具合1件あたりの修正工数
工程別丌具合発見件数比率
企画・仕様 システム設計 ソフトウェア設計
ソフトウェア実装・デバッグ ソフトウェアテスト
Software Engineering
for Mo・No・Zu・Ku・Ri
丌具合1件あたりの修正工数
1人月以上
15.5%
システムテスト
0.1人月未満
32.4%
0.8~1人月未満
5.6%
企画・仕様
0.6~0.8人月未満
8.5%
システム設計
0.4~0.6人月未満
14.1%
ソフトウェア設計
0.1~0.2人月未満
11.3%
0.2~0.4人月未満
12.7%
ソフトウェア実装・デバッグ
工程別不具合発見件数比率の推移
2010
ソフトウェアテスト
2009
システムテスト
0%
5%
10%
15%
20%
25%
注) 2009、2010は開発工程を7工程で分類
30%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
5
SEC
使用しているプログラミング言語
Software Engineering
for Mo・No・Zu・Ku・Ri
使用しているモデルベース言語'自動コード生成(
使用しているプログラミング言語'人手(
Java
7.9%
その他
6.0%
アセンブリ言語
5.1%
UML
14.2%
その他
15.5%
C
57.3%
コンフィギュレータ系
6.4%
連続系
(MATLAB、
Simulink等)
XML系
1.6%
C++/C#
23.7%
23.9%
画面・HMI作成系
14.2%
形式手法系
(B、VDM等)
0.6%
ADL系
3.3%
状態遷移系(SDL、図、表等)
20.4%
プログラムコード作成方法
人手
自動コード生成
その他
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
6
SEC
モデルベース開発技術の利用状況
ほとんどのプロジェクトで使用
Software Engineering
for Mo・No・Zu・Ku・Ri
一部のプロジェクトで使用
試験的に使用したことがある
使用していない
状態遷移モデル(図/表等)
UML/SysML
制御モデル
形式的仕様記述
ユーザモデル/運用モデル
形式検証(含モデル検証)
アーキテクチャ記述(ADL等)
SILS(SW In the Loop Simulation)
HILS(HW In the Loop Simulation)
外界モデル/プラントモデル
その他
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
7
SEC
モデルベース開発技術を利用した理由と課題
モデルベース開発技術の利用状況
1番目
2番目
Software Engineering
for Mo・No・Zu・Ku・Ri
3番目
モデルベース開発技術利用の課題
品質向上のため
モデルベース開発技術を扱える技術者が少ない
上流工程で検証を行うため
既存のソースコード資産の移行が困難
開発期間短縮のため
モデルベース開発ツールの導入コストが高い
高度で複雑な機能を実現するため
適切なモデルベース開発技術の選択が難しい
開発コスト削減のため
期待した効果を得られない
差分/派生開発の効率化のため
開発プロセスの変更・改訂に手間がかかる
自動コード生成を利用するため
モデルベース開発できる外部委託先が少ない
トレーサビリティを確保するため
開発現場が保守的で新しい技術に消極的
認証取得(機能安全等)に有効なため
経営者のモデルベース開発への理解が不足
その他
その他
0%
20%
40%
60%
0%
80%
20%
40%
60%
80%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
8
マルチコア/メニーコアプロセッサを使用したプロジェクトと使用した製品
マルチコア/メニーコアプロセッサを
使用したプロジェクト
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
マルチコア/メニーコアプロセッサを使用した製品
その他の応用機器製品
4.5%
マルチコア/
メニーコア使用
25.0%
分析機器・計測機器等
11.1%
AV機器
22.2%
設備機器
2.2%
個人用情報機器
4.5%
工業制御/FA
機器/産業機器
13.3%
教育機器、娯楽機器
2.2%
コンピュータ周辺機器
OA機器
11.1%
運輸機器/建設機器
6.7%
マルチコア/メニーコア
使用なし
75.0%
回答企業全体の
製品カテゴリ
通信設備機器等
11.1%
民生用通信
端末機器
6.7%
業務用端末機器
4.5%
全体の製品カテゴリに対して、マルチコア/メニーコアを使用した製品が
多いカテゴリは、AV機器、分析機器・計測機器、通信設備機器、工業制
御/FA機器/産業機器、コンピュータ周辺機器/OA機器。
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
9
SEC
マルチコア/メニーコアプロセッサ使用の課題
Software Engineering
for Mo・No・Zu・Ku・Ri
1番目
マルチコア・メニーコアを使用
2番目
3番目
マルチコア・メニーコアを使用していない
複数のコアを有効に使うのが難しい
コア間の通信量を考慮した設計が難しい
個々のコアに載せる機能・処理の割付が難しい
ソフトウェアのデバッグが難しい
ソフトウェアを複数のコアに分割するのが難しい
全体としての性能や信頼性の確保が難しい
対応したOS・開発環境の整備が必要
デバイスの選択肢が少ない
消費電力の制御が難しい
その他
特に課題はない
わからない
0%
10%
20%
30%
40%
50%
60% 0%
10%
20%
30%
40%
50%
60%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
10
SEC
海外開発拠点所在地及び国内と海外の開発拠点数比率
海外開発拠点所在地
国内と海外の開発拠点数比率
東欧・ロシア
その他
2.4%
3.2%
インド
3.2%
欧州
25.8%
韓国
4.0%
Software Engineering
for Mo・No・Zu・Ku・Ri
海外開発拠点
44.8%
国内開発拠点
55.2%
東南アジア
19.4%
米国
21.0%
中国
21.0%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
11
SEC
1開発拠点当りの開発技術者数
Software Engineering
for Mo・No・Zu・Ku・Ri
国内開発拠点
海外開発拠点
500~1000人未満
1000人以上
3.1%
0.5%
200~500人未満
5.1%
10人未満
17.9%
100~200人未満
8.2%
200人以上
3.7%
100~200人未満
14.8%
10人未満
25.9%
10~20人未満
17.4%
50~100人未満
20.0%
50~100人未満
18.5%
20~50人未満
27.7%
10~20人未満
11.1%
20~50人未満
25.9%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
12
SEC
開発拠点の海外展開'回答企業全体と企業規模別(
Software Engineering
for Mo・No・Zu・Ku・Ri
従業員301人以上
開発拠点は海外に
移転する予定
0.9%
わからない
21.1%
コア技術の開発拠点は国内に
残すがそれ以外は海外にも
展開する予定
15.6%
コア技術の開発拠点は国内に
残すがそれ以外は海外にも展
開する予定
15.6%
海外への拠点展開
の予定あり:50%
従業員300人以下
海外への拠点展開
の予定あり:22%
海外に開発拠点を展開
する予定はない
47.7%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
13
SEC
組込みソフトウェア開発の課題
Software Engineering
for Mo・No・Zu・Ku・Ri
2011年組込みソフトウェア開発の課題
1番目
2番目
1番目の課題Top10の推移
'2007~2011(
3番目
設計品質の向上
2008
2009
2010
2011
設計品質
設計品質
設計品質
設計品質
設計品質
新製品
新製品
開発期間
開発コスト
新製品
開発期間
開発期間
生産性
新技術
開発コスト
開発能力
開発能力
開発コスト
新製品
市場拡大
生産性
開発コスト
開発能力
市場拡大
開発能力
開発コスト
生産性
新技術
開発能力
新技術
市場拡大
市場拡大
製造品質
開発期間
開発期間
新技術
新技術
新製品
製品安全
生産性
製品安全
製品安全
市場拡大
生産性
製造品質
製造品質
製造品質
製品安全
製造品質
事業環境
変化対応
2007
新製品の開発
開発コストの削減
市場の拡大
開発能力(量)の向上
新技術の開発
開発期間の短縮
生産性の向上
製造品質の向上
事業環境の変化への対応
製品安全性の確保
規格認証等への対応
海外拠点・海外企業との連携
その他
0%
10%
20%
30%
40%
50%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
14
SEC
組込みソフトウェア開発課題に有効な解決手段
2011年:課題に有効な解決手段の合計
1番目
2番目
1番目の解決手段Top10の推移
'2007~2011(
3番目
2007
技術者のスキル向上
Software Engineering
for Mo・No・Zu・Ku・Ri
2008
2009
2010
2011
技術者
スキル向上
技術者
スキル向上
技術者
スキル向上
技術者
スキル向上
技術者
スキル向上
技術者の
確保
技術者の
確保
PMのスキ
ル向上
PMのスキ
ル向上
開発技術の
向上
PMのスキ
ル向上
PMのスキ
ル向上
開発技術の
向上
開発技術の
向上
PMのスキ
ル向上
開発技術の
向上
開発技術の
向上
PMの確保
技術者の
確保
技術者の
確保
PMの確保
PMの確保
技術者の
確保
新技術
開発・導入
新技術
開発・導入
管理技術の
向上
管理技術の
向上
PMの確保
PMの確保
開発製品数・開発量の削減・最適化
管理技術の
向上
経営者・投資家の理解
新技術
開発・導入
新技術
開発・導入
新技術
開発・導入
管理技術の
向上
管理技術の
向上
現場の理解
開発環境の
整備
開発環境の
整備
開発製品数
最適化
委託先の
確保
委託先の
確保
語学力の向上
開発製品数
最適化
委託先の
確保
開発環境の
整備
開発環境の
整備
開発製品数
最適化
経営者の
理解
経営者の
理解
委託先の
確保
経営者の
理解
経営者の
理解
開発手法・開発技術の向上
プロジェクトマネージャのスキル向上
技術者の確保
新技術の開発・導入
プロジェクトマネージャの確保
管理手法・管理技術の向
上
委託先の確保・能力向上
開発環境(ツール等)の整備・改善
その他
0% 10% 20% 30% 40% 50% 60% 70%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
15
SEC
組込みソフトウェア開発課題に有効な解決手段'課題別(
有効な解決手段
課題
技
術
者
の
ス
キ
ル
向
上
の開
向発
上手
法
・
開
発
技
術
ジプ
ャ ロ
のジ
スェ
キク
ルト
向マ
上ネ
ー
新
技
術
の
開
発
・
導
入
技
術
者
の
確
保
Software Engineering
for Mo・No・Zu・Ku・Ri
等開 の管 向委 ジ プ の開 解経
営
) 発 向理 上託 ャ ロ 削発
の環 上手
先 の ジ 減製
者
整境
法
の 確ェ ・ 品
・
備(
・
確 保 ク 最数
投
・ ツ
管
保
ト 適・
資
ー
改
理
・
マ 化開
家
善ル
技
能
ネ
発
の
ー
術
力
量
理
現
場
の
理
解
語
学
力
の
向
上
そ
の
他
設計品質の向上
68
44
31
15
27
19
27
10
14
10
6
5
2
1
新製品の開発
45
20
31
53
24
7
8
13
13
4
8
5
4
8
開発コストの削減
53
53
41
9
7
25
32
21
7
18
3
4
1
0
市場の拡大
28
9
17
39
20
4
11
20
17
9
15
9
7
20
開発能力(量)の向上
68
44
24
13
43
21
12
15
7
4
3
4
6
1
新技術の開発
66
30
14
70
38
5
0
9
7
5
7
4
4
2
開発期間の短縮
57
46
28
9
29
34
35
15
5
14
0
1
3
0
生産性の向上
73
55
32
11
9
43
25
9
5
5
2
7
0
2
製造品質の向上
73
36
32
36
32
0
32
14
18
23
9
14
0
5
事業環境の変化への対応
34
14
24
45
14
7
7
17
3
7
38
21
14
10
製品安全性の確保手段
88
13
25
13
25
25
38
0
0
13
0
0
0
0
規格認証等への対応手段
38
0
25
0
13
38
50
50
0
0
25
0
25
0
海外拠点・海外企業との連携手段
17
0
33
17
17
0
0
33
0
0
0
33
100
17
全体の平均
58
39
28
26
25
20
20
14
9
9
5
5
3
4
注:枠内の数字は課題に有効な解決手段として挙げられた1番目から3番目の合計の%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
16
SEC
SEC成果の導入状況
Software Engineering
for Mo・No・Zu・Ku・Ri
導入した
参考にした
検討中
未定
組込みスキル標準(ETSS)
組込みソフトウェア開発向けコーディング作法(ESCR)
組込みソフトウェア向け開発プロセスガイド(ESPR)
組込みソフトウェア向けプロジェクトマネジメントガイド(ESMR)
組込みソフトウェア開発向け品質作りこみガイド(ESQR)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
出典:「経済産業省 平成22年度 組込みシステム産業の実態把握調査」
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
17
組込みソフトウェア開発を取巻く事業環境の変化'1(
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
 機能安全、第三者検証・妥当性確認など品質説明力の向上
 機能安全規格と第三者検証・妥当性確認の両者に対応した組込みソフトウェア開発
'組込みソフトウェア開発に関わる全ステークホルダの対応が必要(
 対応した開発情報管理
開発情報のトレーサビリティーの確保
 開発に関わる技術活動記録、組織活動記録などのエビデンス収集

 開発に使用する開発ツールの認証取得
 説明力'証明力(の高い開発技術の適用
 形式手法、モデルベース手法など
 実装中心から設計中心のソフトウェア開発への移行
 実装工程の海外アウトソースと機械化(自動コード生成ツール(の拡大により国内の
開発は上流工程中心に移行
 上流工程の中核技術はモデルベース'モデル駆動(開発技術
開発プロセスのモデルベース開発への適応'上流工程での設計検証など(
 開発ツール等の導入'モデルベース開発技術はツール支援を前提とした開発技術(
 モデルベース開発技術を扱える上流工程技術者の育成


基礎的な学力'数学、論理学など(が丌足しているソフトウェア技術者の育成
 利用者情報、利用情報の活用
 要求獲得、要件定義、・・・
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
18
組込みソフトウェア開発を取巻く事業環境の変化'2(
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
 組込みシステムの他システムとの統合化'統合システム化(
 自動車の例:車載システムの統合化と並行して、車外システムとの統合化が進行
 電動機の採用による、スマートエネルギーシステムと統合化
 インターネット等との接続による、情報システムと統合化
 ITSなどの高度交通システムへの対応による、交通インフラや他の車両と統合化
 他産業との連携したシステム開発

住宅産業、電力産業、家電産業、情報サービス産業など
 全体システムとしての安全性・信頼性の確保
 共通モデルによる上流段階での検証 など
 開発拠点のグローバル化
 リーマンショック後の円高に対応するため開発拠点の海外展開が進行
 プラザ合意以降の円高に対応して生産拠点については海外展開が進行した'自動車産業
では約4割が海外生産(
 2008年度までの国内組込みソフトウェア技術者の丌足'約10万人丌足と言われた(に対
応するため海外拠点での技術者確保、海外へのアウトソーシングが拡大した
 既に海外拠点が存在し、海外でのソフトウェア開発経験も積んでおり、開発拠点の海外展
開を進める土壌はできている
 今後、国内の開発リソース需要は減尐'特に、ソフトウェア実装・テストの外部委託は、海
外移転と自動化などにより国内市場は消滅(
 国内組込みソフトウェア産業の構造改革が急務
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
19
SEC
ソフトウェア品質監査制度'仮称(検討の背景と経緯
第三者の検証・妥当性確認による品質説明力強化の必要性
Software Engineering
for Mo・No・Zu・Ku・Ri
品質説明に対する市場意識の変化
品質説明力の丌足: 当事者企業の技術的主張だけでな
く、第三者の裏付け'検証、妥当性確認(による品質説明
への要求の増大
利用者
製品の利用者が感じる違和感
利用品質低下の懸念: 製品・システムの高度化・複雑化
と利用者の多様化により、製品・システムと利用者との間
のギャップが拡大
製品・サービス
監査結果・意見表明
技術説明
先端技術製品の潜在リスクへの丌安
製品品質低下の懸念: 技術の急速な進歩により技術標
準'規格(に基づく規格認証の対象範囲外となる領域が
拡大
品質文化の異なる業界を跨るシステム
残存する潜在リスクの増加: 複数の業界を跨るシステム
の拡大に伴い、全体システムとしての品質確認の精度が
低下
IPA/SECでの活動経緯
 2010年3月:産構審情報システム・ソフトウェア小委員会にて第三
者による検証・妥当性確認の枠組みの必要性が示される
 2010年4月:IPA/SECの統合系プロジェクト内に検討チームを発足
 2010年7月:調査活動開始
 2010年11月:制度検討委員会発足'主査:名古屋大学高田教授(
 2011年4月:中間報告(予定(
Copyright © 2011 IPA, All Rights Reserved
事業者
監査機関
技術ドキュメント
開発エビデンス
第三者による検証・妥当性確認
事業者の技術的主張の妥当性を、監査機関
が開発技術水準と利用技術水準を考慮して
第三者の立場で評価し、技術に関する専門知
識のない利用者にも理解できる形で情報提
供する仕組み
'会計処理における会計監査と同等の役割(
Software Engineering Center
20
ソフトウェア品質監査制度'仮称(の狙いと効果
国民生活の安全・安心・快適の向上と我が国産業の国際競争力の強化
ソフトウェア品質監査制度'仮称(の狙い
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
ソフトウェア品質監査制度'仮称(の効果
企業の製品・システムに関する利用者や
市場への品質説明力の強化
技術の専門家ではない利用者の安心感
の向上
国際市場における日本製品・システムの品
質に対する正当な評価の確立
我が国産業の国際競争力の維持・強化
産業界の枠を超えた品質の見える化によ
る複数の産業界を跨り構成される高度なシ
ステムの開発加速 '例:スマートコミュニ
ティシステムなど(
国民生活の快適性・利便性の向上
新成長戦略分野における我が国産業の
国際優位性の確保
製品・システムの本質的な品質向上
国民生活の安全性の確保
ご参考:米国の状況
 2010年日本製自動車の制御システムに対する丌具合の疑念が拡大。米国政府の要請で、NASAの独立検証・妥当性
確認'IV&V)センターが第三者の立場で、制御システムの検証ならびに妥当性確認を実施。2011年2月、丌具合が発
見されなかったとの最終報告が公開。
 当事者企業の主張だけでなく、第三者の主張がないと説明力が丌充分との意識
'会計処理における会計監査の必要性と同等の意識(。
 国防省やNASAのシステムの調達、航空機分野、医療機器分野で類似した仕組みを運用している。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
21
SEC
規格認証とソフトウェア品質監査'仮称(の関係
システム・ライフサイクル
規
格
認
証
設計
実装
試験
製造
販売
利用
運用
プロセス認証
組織が規定のプロセスを実施できる能力
を持っているか
機能安全認証
組織・製品・従事者が安全度水準に応じた安全要求事項を満足
しているか
製品認証・型式認証
ソ
フ
ト
ウ
ェ
ア
品
質
監
査
(仮
称
)
企画
Software Engineering
for Mo・No・Zu・Ku・Ri
プロセス実施の
妥当性
採用規格・技術の
妥当性
従事者の妥当性
利用者・利用状況
との妥当性
例:ISO9000、ISO14000、・・・
ISO12207、ISO15504、ISO13407、・・・
製品が規定された基準を満た
しているか
例:IEC61508、ISO26262、・・・
例:ISO9126、ISO9241、・・・
特定の製品に関しプロセスが規定通りに
実施されたか
特定の製品に関しタスク、アクティビティ
が確実に実施されたか
特定の製品に関し適切な規格が採用さ
れ、認証取得されたか
特定の製品に関し技術が適切に採用さ
れ利用されたか
特定の製品に関し従事者のスキル・適性は適切か
特定の製品に関し利用者情報・利用情報が適切に収得され、利
用されたか
利用者への情報
提供は適切か
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
22
ESEC'2011年5月(の来場者へのアンケート結果'回答数:2154名(
「品質監査制度'仮称(に関心がありますか?」
あまり関心がない
14%
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
関心がない
2%
関心がある
31%
やや関心がある
53%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
23
ESEC'2011年5月(の来場者へのアンケート結果'回答数:1985名(
「どのような観点で関心がありますか?」
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
その他, 2.3%
新しい関連事業を展開
したいから, 5.2%
市場で要求されている
から, 19.0%
品質の向上に有効そう
だから, 49.4%
品質説明力を強化した
いから, 24.1%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
24
SEC
制度設計に際しての産業界からの要望事項と対応方針
Software Engineering
for Mo・No・Zu・Ku・Ri
制度設計に際しての産業界からの主な要望事項







国際的に認知される制度であること
先端開発にも適応できる高い機密保持性を持てる制度であること
要求される品質説明力とコストとのバランスが取れる制度であること
義務ではなく任意の制度であること
既存の規格認証との重複が尐ない/しない制度であること
複数の業界を跨ぐシステムに関係する全業界間で共有・支持できる制度であること
認証取得だけでなく品質向上にも有効な制度であること
要望事項への対応方針











ISO国際認証'ISO/IEC 17011など(の枠組みとの整合性を確保する
国際的に認知されている他の仕組み'宇宙分野のIV&V、会計監査制度など(を参考にする
機密保持性を持つ他の仕組み'米連邦航空局製品認証のDER制度など(を参考にする
要求される品質説明力に応じてレベル分けし、レベル毎に監査コストも考慮して監査範囲を定める
利用者等に対して監査の有無や監査結果を分かり易く告知するための統一的な表示方法を定める
ソフトウェア品質監査と同一の規格認証の審査項目については、その結果を監査で利用する
規格認証と同一のソフトウェア品質監査の審査項目については、規格認証でその結果を利用できるよ
うにする
異なる製品・産業分野でも同等の監査精度を担保できるようにする
製品・産業分野で異なる分野依存部と共通な分野非依存部を別けて審査基準を定義できるようにする
分野依存部については分野を所管する業界団体等が主体となって審査基準が策定できるようにする
分野非依存部については利用者や国民の観点に立った審査基準を策定する
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
25
要望事項への対応方針に従った制度に対する要件
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
要望事項への対応方針'再掲(











ISO国際認証'ISO/IEC 17011など(の枠組みとの整合性を確保する
国際的に認知されている他の仕組み'宇宙分野のIV&V、会計監査制度など(を参考にする
機密保持性を持つ他の仕組み'米連邦航空局製品認証のDER制度など(を参考にする
要求される品質説明力に応じてレベル分けし、レベル毎に監査コストも考慮して監査範囲を定める
利用者等に対して監査の有無や監査結果を分かり易く告知するための統一的な表示方法を定める
ソフトウェア品質監査と同一の規格認証の審査項目については、その結果を監査で利用する
規格認証と同一のソフトウェア品質監査の審査項目については、規格認証でその結果を利用できるよ
うにする
異なる製品・産業分野でも同等の監査精度を担保できるようにする
製品・産業分野で異なる分野依存部と共通な分野非依存部を別けて審査基準を定義できるようにする
分野依存部については分野を所管する業界団体等が主体となって審査基準が策定できるようにする
分野非依存部については利用者や国民の観点に立った審査基準を策定する
対応方針に従った制度に対する要件






認定機関、試験機関、認証機関を分離すること
試験機関、認証機関については民間の参入を可能とすること
監査基準は単一の基準'分野非依存の基準(とすること
単一の公的資格'分野非依存の資格(を持った適性な'利害関係の無い(審査官が監査を実施すること
要求される品質説明力に応じたレベル分けの基準は単一の基準'分野非依存の基準(とすること
分野依存の審査基準は民間主体'産業別業界団体等(で策定できること'当該分野で要求される既存
の規格認証なども考慮して審査基準を策定できること(
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
26
SEC
品質問題に起因する影響の度合いに応じて監査内容を定義
要求される品質説明力と監査コストとのバランス
Software Engineering
for Mo・No・Zu・Ku・Ri
利用者・国民への影響度と産業界・経済への影響度によりレベル分け'監査レベル(し、監査レベル毎に監
査内容を定義する。
監査レベル
産
業
・経
済
影
響
レ
ベ
ル
監査レベルに対応した監査内容
4
4
4
4
4
4
監査レベル
3
3
3
3
3
4
4
全項目
網羅監査'全件監査(
必須
2
2
2
2
3
4
3
重要項目
網羅監査'全件監査(
必須
1
1
1
2
3
4
その他の全項目
抜取監査'サンプル監査( 任意
0
0
1
2
3
4
2
全項目
抜取監査'サンプル監査( 任意
0
1
2
3
4
1
重要項目
抜取監査'サンプル監査( 任意
利用者・国民影響レベル
0
非対象
非対象
産業・経済影響レベル
レベル
4
監査する審査項目
監査方法
独立検証
非対象
利用者・国民影響レベル
影響の範囲
我が国の産業への広範囲な影響
レベル
4
影響の範囲・程度
当該利用者ならびに当該利用者以外への重大な
影響'代替手段による影響軽減が困難な影響(
国民への広範囲で重大な影響
当該利用者への重大な影響に加え、当該利用者
以外への軽微な影響'代替手段による影響軽減が
容易な影響(
当該利用者に限定された重大な影響
当該利用者に限定された軽微な影響
影響はない/ほとんど影響はない
3
当該産業に限定された影響
当該企業以外の同一・類似産業のへの影響
2
当該企業に限定された影響
当該製品・サービス以外の他事業への影響
3
1
当該製品・サービス事業に限定された影響
0
影響はない/ほとんど影響はない
2
1
0
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
27
SEC
ソフトウェア品質監査制度'仮称(の枠組み
産業・製品分野別への対応と内部監査を考慮したフレームワーク
Software Engineering
for Mo・No・Zu・Ku・Ri
下記の要件を満たす「公認審査官」が、産業分野あるいは製品分野毎に定められた「審査基準」を基に、
「監査基準」に従って監査業務を遂行し、「監査結果」を利用者にも理解できる形で情報提供する制度
要件1. 専門性:情報の信頼性を保証できる専門知識と能力を有していること
要件2. 独立性:監査対象の事業者・利用者から身分的・経済的・精神的に独立していること
民間主体
利用者・利用情報
障害情報
利用品質も考慮し
た品質監査のため
の基礎情報
収集
企業に所属する公
認審査官による内
部審査も考慮
活用
参照
活用
公認審査官の業務査察、
能力維持のための継続的
な教育研修を提供
製品・サービス
公認審査官協会
事業者
公認審査官
審査基準
策定
利用者
認定
参照
監査結果
監査
監査機関
審査基準策定機関
報告
独立検証機関
公認審査官
認定
認定
産業・製品別の審査
基準の策定と維持
参照
認定
認定機関
Copyright © 2011 IPA, All Rights Reserved
監査に必要な高度で専門的
な検証サービスを提供
認定
監査基準
認定基準
政府
注:名称等は仮称です
Software Engineering Center
28
内部監査を適用する場合の外部審査官と内部審査官の役割
監査計画の立案:
・内部審査官が審査対象組織と
協議し、開発情報の機密性を評
価し、内部監査での実施と外部
監査での実施に峻別して、監査
計画案を策定する
・監査計画案の外部審査官の合
意を得て監査計画を確定する
外部審査官
内部審査官
監査計画の確定
内部監査1の確認
開発計画案の策定
開発計画の確定
内部監査1の実施
内部監査1の報告
内部監査1の対応
・
・
・
内部監査Nの確認
内部監査Nの実施
内部監査Nの報告
監査結果の表明:
公開
審査対象組織
監査計画案の策定
外部監査1の実施
監査結果の表明は外部審査官
が行うが、内部審査官に意見を
求めることができる
Software Engineering
for Mo・No・Zu・Ku・Ri
事業者
監査の実施:
・内部監査は、内部審査官と審査
対象組織で実施されるが、監査
の実施状況については外部審査
官に報告し、外部審査官が確認
する
・外部監査は、外部審査官と審査
対象組織で実施されるが、内部
審査官は外部監査を支援するこ
とができる
SEC
内部監査Nの対応
外部監査1の対応
・
・
・
最終監査の実施
最終監査の対応
監査結果の表明
監査結果の受領
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
29
SEC
独立検証機関を有する企業の他事業との関係
Software Engineering
for Mo・No・Zu・Ku・Ri
 事業者向け受託開発サービス事業、事業者向けIV&Vサービス事業、その他の事業を実施する企業等も、それらの
事業と独立性を担保することで独立検証機関として認定
 独立した意思決定機構'独立した事業責任者の設置等(、独立した予算、独立性に関する内部監査など
 独立検証機関としての業務査察、能力維持のための継続的な教育研修については関連の業界団体の実施を想定
企業
利用者
下記以外の
その他の事業
製品・サービス
事業者向け
受託開発サービス事業
事業者
公認審査官
認定
事業者向け
IV&Vサービス事業
監査
監査機関
監査機関向け
IV&Vサービス事業
公認審査官
認定
認定
認定機関
認定
監査基準
認定基準
Copyright © 2011 IPA, All Rights Reserved
民間主体
独立検証機関として事業
を認定された企業
独立検証機関としての業務
査察、能力維持のための継
続的な教育研修を提供
業界団体
独立検証機関とし
て認定された事業
政府
注:名称等は仮称です
Software Engineering Center
30
SEC
ソフトウェア品質監査制度'仮称(の「Whole Product」
Software Engineering
for Mo・No・Zu・Ku・Ri
 制度の構築
 制度設計、各種規定類の整備
 審査基準、監査基準の整備
 実施組織の構築
⇒ IPA/SEC部会・WG活動等
 制度実施のための環境整備
 独立検証機関の育成・確保
 公認審査員・監査機関の育成・確保
 支援ツールの整備 '主管:経済産業省(
平成23年度産業技術実用化開発事業費補助金:組込みシステム基盤開発事業
'品質説明力向上に向けたオープンツールプラットフォーム構築事業(
⇒ 関係団体・関連機関への情報発信と協力関係の樹立
⇒ 民間活動・企業活動に対する支援等
 制度の認知度の確立
 利用者・消費者に対する認知度の確立
 産業界に対する認知度の確立
 国際的な認知度の確立 '主管:経済産業省(
⇒ 諸外国を含む関係団体・関連機関への情報発信と協力関係の樹立
⇒ セミナー、展示会、イベントでの講演、新聞・雑誌への発表等
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
31
従来型開発プロセス'仕様ベース(のソフトウェア品質監査における課題
大規模ソフトウェアではソフトウェア開発工程も階層化されるが工程間は仕様で受渡し
設計結果同士の場合、
項目数が多いため、紐
付けに膨大なコストが掛
かる
要求
要件
要件は明確に定義
されず、設計者の
頭の中だけにある
'暗黙知(
システム総合
結合テスト
設計
結果
システム・
アーキテクチャ設計
ソフトウェア
要求定義
要件
Software Engineering
for Mo・No・Zu・Ku・Ri
テスト時に、テスタが要件を想
像しながらテストケースを作成
するため、テストケースの品質
にバラツキがでる
システム要求定義
要件
SEC
前工程からの入力情
報と照らし合わせての
確認が困難
設計
結果
ソフトウェア
総合テスト
設計
結果
ソフトウェア・
アーキテクチャ設計
要件
システム結合
結合テスト
ソフトウェア
結合テスト
設計
結果
ソフトウェア
詳細設計
単体テスト
設計
結果
最上位要求に合致して
いるかの評価が困難
実装
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
32
ソフトウェア品質監査を効率的に実施できる開発プロセス'要件ベース(
階層化されるソフトウェア開発工程を要件で受渡し
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
要求
上下の要件間の確
認が容易
システム要件定義
設計
結果
要求分析
暗黙知から
形式知化
従来、要件は暗黙知で
あったが、
本プロセスでは、
要件を形式知とする
それぞれ要件があるため、
出来たものが要件の通り
振る舞うかの検証が容易
システム要件
システム
サブシステム要件定義
システムアーキテクチャ設
計
運用テスト
要件と仕様の確認が
容易
設計
結果
サブシステム
サブシステム要件
コンポーネント要件定義
サブシステムアーキテク
チャ設計
システム結合テスト
サブシステム結合テスト
設計
結果
コンポーネント
コンポーネント要件
コンポーネント実装
コンポーネント設計
/実装/デバッグ
Copyright © 2011 IPA, All Rights Reserved
外部に発注する際にも要件でや
りとりした方が良い
'要件を実現する仕様は数多くあ
るため、要件を明確に定義してお
く必要がある(
Software Engineering Center
33
要件ベース開発プロセスの各要件定義工程のタスクモデル
外部設計、内部設計'構造設計(、下位要件の検証・妥当性確認を工程内で閉じて実施可能
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
上位要件
××要件定義
レビュー
レビュー結果
外部設計'仕様設計(
外部設計書
外部設計検証
外部設計検証結果
内部設計'構造設計(
内部設計書
内部設計検証
内部設計検証結果
下位要件
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
34
SEC
ソフトウェア品質監査制度'仮称(の特長
 独立検証機関による検証と妥当性
確認を包含
Software Engineering
for Mo・No・Zu・Ku・Ri
利用者・市場が期待する第三者による確認範囲
 事業者の主張を高度な専門技術を
持った独立検証機関で再確認
 利用情報や利用者情報に基づく利
用品質の確認
規格認証
 すべての開発ライフサイクルでの利
 既存の認証制度や監査制度を補間
重複した監査を簡略化
プロセス認証
アシュアランスケース
用情報、利用者情報の活用を確認
 既存の認証結果・監査結果を確認し、
利用品質
互換性認証
機能安全認証
型式認証
 開発ライフサイクルに合わせて開発
と並行して監査を実施
 指摘事項への対応による手戻りが
防止でき、出荷時期等への影響を
最小化
 機密情報の拡散リスクを低減できる
内部審査官と外部審査官が連携
 外部審査官の管理下で内部審査官
が機密情報を直接アクセスする監
査業務を実施
個人情報保護
セキュリティ監査
法令・条約等
システム監査
ソフトウェア品質監査制度'仮称(で監査する範囲
他の認証・監査の結果を確認する範囲
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
35
Software
Engineering
Center
Information-technology Promotion Agency, Japan
ご清聴ありがとうございました
Software Engineering Center
36