...

ソフトウェア品質監査制度(仮称)とトレーサビリティについて

by user

on
Category: Documents
6

views

Report

Comments

Transcript

ソフトウェア品質監査制度(仮称)とトレーサビリティについて
Software
Engineering
Center
Information-technology Promotion Agency, Japan
ソフトウェア品質監査制度(仮称)とトレーサビリティについて
~第三者の検証・妥当性確認による品質説明力の強化~
独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター
統合系プロジェクト&組込み系プロジェクト サブリーダー
工学博士 田丸 喜一郎
Software Engineering Center
0
0
日銀短観(1988年3月~2011年9月:四半期毎)と輸出金額の推移(1988年~2010年暦年)
大企業/製造業
大企業/非製造業
60
40
20
中小企業/製造業
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
中小企業/非製造業
注)日銀短観では資本金2,000万円~1億円の企業を中小企業と定義
バブル経済
崩壊
1998年
不況
ITバブル
崩壊
リーマン
ショック
東日本
大震災
0
- 20
- 40
- 60
198819891990199119921993199419951996199719981999200020012002200320042005200620072008200920102011
輸出総額
組込み関連製品の輸出金額 組込み関連製品の割合
兆円
70%
100
80
65%
60
60%
40
55%
20
50%
0
19881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010
Copyright © 2011 Ministry
of Economy Trade and
Software Engineering Center
1
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
2
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
3
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
4
組込みソフトウェア開発を取巻く事業環境の変化(1)
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
„ 機能安全、第三者検証・妥当性確認など品質説明力の向上
z 機能安全規格と第三者検証・妥当性確認の両者に対応した組込みソフトウェア開発
(組込みソフトウェア開発に関わる全ステークホルダの対応が必要)
z 対応した開発情報管理
„
„
開発情報のトレーサビリティーの確保
開発に関わる技術活動記録、組織活動記録などのエビデンス収集
z 開発に使用する開発ツールの認証取得
z 説明力(証明力)の高い開発技術の適用
„ 形式手法、モデルベース手法など
„ 実装中心から設計中心のソフトウェア開発への移行
z 実装工程の海外アウトソースと機械化(自動コード生成ツール)の拡大により国内の
開発は上流工程中心に移行
z 上流工程の中核技術はモデルベース(モデル駆動)開発技術
„
„
„
開発プロセスのモデルベース開発への適応(上流工程での設計検証など)
開発ツール等の導入(モデルベース開発技術はツール支援を前提とした開発技術)
モデルベース開発技術を扱える上流工程技術者の育成
z
基礎的な学力(数学、論理学など)が不足しているソフトウェア技術者の育成
z 利用者情報、利用情報の活用
„ 要求獲得、要件定義、・・・
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
5
組込みソフトウェア開発を取巻く事業環境の変化(2)
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
„ 組込みシステムの他システムとの統合化(統合システム化)
z 自動車の例:車載システムの統合化と並行して、車外システムとの統合化が進行
„ 電動機の採用による、スマートエネルギーシステムと統合化
„ インターネット等との接続による、情報システムと統合化
„ ITSなどの高度交通システムへの対応による、交通インフラや他の車両と統合化
„ 他産業との連携したシステム開発
z
住宅産業、電力産業、家電産業、情報サービス産業など
z 全体システムとしての安全性・信頼性の確保
„ 共通モデルによる上流段階での検証 など
„ 開発拠点のグローバル化
z リーマンショック後の円高に対応するため開発拠点の海外展開が進行
„ プラザ合意以降の円高に対応して生産拠点については海外展開が進行した(自動車産業
では約4割が海外生産)
„ 2008年度までの国内組込みソフトウェア技術者の不足(約10万人不足と言われた)に対
応するため海外拠点での技術者確保、海外へのアウトソーシングが拡大した
„ 既に海外拠点が存在し、海外でのソフトウェア開発経験も積んでおり、開発拠点の海外展
開を進める土壌はできている
„ 今後、国内の開発リソース需要は減少(特に、ソフトウェア実装・テストの外部委託は、海
外移転と自動化などにより国内市場は消滅)
z 国内組込みソフトウェア産業の構造改革が急務
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
6
SEC
ソフトウェア品質監査制度(仮称)検討の背景と経緯
第三者の検証・妥当性確認による品質説明力強化の必要性
Software Engineering
for Mo・No・Zu・Ku・Ri
品質説明に対する市場意識の変化
品質説明力の不足: 当事者企業の技術的主張だけでな
く、第三者の裏付け(検証、妥当性確認)による品質説明
への要求の増大
利用者
製品と利用者とのギャップの拡大
利用品質低下の懸念: 製品・システムの高度化・複雑化
と利用者の多様化により、製品・システムと利用者との間
のギャップが拡大
製品・サービス
監査結果・意見表明
技術説明
先端技術製品の潜在リスクへの不安
製品品質低下の懸念: 技術の急速な進歩により技術標
準(規格)に基づく規格認証の対象範囲外となる領域が
拡大
品質文化の異なる業界を跨るシステム
残存する潜在リスクの増加: 複数の業界を跨るシステム
の拡大に伴い、全体システムとしての品質確認の精度が
低下
IPA/SECでの活動経緯
„ 2010年3月:産構審情報システム・ソフトウェア小委員会にて第三
者による検証・妥当性確認の枠組みの必要性が示される
„ 2010年4月:IPA/SECの統合系プロジェクト内に検討チームを発足
„ 2010年7月:調査活動開始
„ 2010年11月:制度検討委員会発足(主査:名古屋大学高田教授)
„ 2011年6月:中間報告
Copyright © 2011 IPA, All Rights Reserved
事業者
監査機関
技術ドキュメント
開発エビデンス
第三者による検証・妥当性確認
事業者の技術的主張の妥当性を、監査機関
が開発技術水準と利用技術水準を考慮して
第三者の立場で評価し、技術に関する専門知
識のない利用者にも理解できる形で情報提
供する仕組み
(会計処理における会計監査と同等の役割)
Software Engineering Center
7
ソフトウェア品質監査制度(仮称)の狙いと効果
国民生活の安全・安心・快適の向上と我が国産業の国際競争力の強化
ソフトウェア品質監査制度(仮称)の狙い
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
8
SEC
ソフトウェア品質監査制度(仮称)の特長
„ 独立検証機関による検証と妥当性
確認を包含
Software Engineering
for Mo・No・Zu・Ku・Ri
利用者・市場が期待する第三者による確認範囲
z 事業者の主張を高度な専門技術を
持った独立検証機関で再確認
„ 利用情報や利用者情報に基づく利
用品質の確認
規格認証
z すべての開発ライフサイクルでの利
„ 既存の認証制度や監査制度を補完
重複した監査を簡略化
プロセス認証
アシュアランスケース
用情報、利用者情報の活用を確認
z 既存の認証結果・監査結果を確認し、
利用品質
互換性認証
型式認証
機能安全認証
形式手法
„ 開発ライフサイクルに合わせて開発
と並行して監査を実施
z 指摘事項への対応による手戻りが
防止でき、出荷時期等への影響を
最小化
個人情報保護
セキュリティ監査
„ 機密情報の拡散リスクを低減できる
内部審査官と外部審査官が連携
z 外部審査官の管理下で内部審査官
が機密情報を直接アクセスする監
査業務を実施
法令・条約等
システム監査
ソフトウェア品質監査制度(仮称)で監査する範囲
他の認証・監査の結果を確認する範囲
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
9
SEC
ソフトウェア品質監査制度(仮称)の枠組み
産業・製品分野別への対応と内部監査を考慮したフレームワーク
Software Engineering
for Mo・No・Zu・Ku・Ri
下記の要件を満たす「公認審査官」が、産業分野あるいは製品分野毎に定められた「審査基準」を基に、
「監査基準」に従って監査業務を遂行し、「監査結果」を利用者にも理解できる形で情報提供する制度
要件1. 専門性:情報の信頼性を保証できる専門知識と能力を有していること
要件2. 独立性:監査対象の事業者・利用者から身分的・経済的・精神的に独立していること
民間主体
利用者・利用情報
障害情報
収集
企業に所属する公
認審査官による内
部審査も考慮
活用
利用品質も考慮し
た品質監査のため
の基礎情報
審査基準
策定
活用
利用者
参照
製品・サービス
監査結果
公認審査官協会
事業者
参照
公認審査官
認定
公認審査官の業務査察、
能力維持のための継続的
な教育研修を提供
監査に必要な高度で専門的
な検証サービスを提供
監査
認定
参照
監査機関
審査基準策定機関
参照
産業・製品別の審査
基準の策定と維持
参照
公認審査官
認定
認定
報告
参照
認定
参照
認定
監査基準
審査基準策定指針
認定機関
認定基準
Copyright © 2011 IPA, All Rights Reserved
独立検証機関
政府
注:名称等は仮称です
Software Engineering Center
10
従来型開発プロセス(仕様ベース)のソフトウェア品質監査における課題
大規模ソフトウェアではソフトウェア開発工程も階層化されるが工程間は仕様で受渡し
設計結果同士の場合、
項目数が多いため、紐
付けに膨大なコストが掛
かる
要求
要件
要件は明確に定義
されず、設計者の
頭の中だけにある(
暗黙知)
システム総合
結合テスト
設計
結果
システム・
アーキテクチャ設計
ソフトウェア
要求定義
要件
Software Engineering
for Mo・No・Zu・Ku・Ri
テスト時に、テスタが要件を想
像しながらテストケースを作成
するため、テストケースの品質
にバラツキがでる
システム要求定義
要件
SEC
前工程からの入力情
報と照らし合わせての
確認が困難
設計
結果
ソフトウェア
総合テスト
設計
結果
ソフトウェア・
アーキテクチャ設計
要件
システム結合
結合テスト
ソフトウェア
結合テスト
設計
結果
ソフトウェア
詳細設計
単体テスト
設計
結果
最上位要求に合致して
いるかの評価が困難
実装
11
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
11
SEC
ソフトウェア品質監査を効率的に実施できる開発プロセス(要件ベース)
階層化されるソフトウェア開発工程を要件で受渡し
Software Engineering
for Mo・No・Zu・Ku・Ri
要求
上下の要件間の確
認が容易
システム要件定義
設計
結果
要求分析
暗黙知から
形式知化
従来、要件は暗黙知で
あったが、
本プロセスでは、
要件を形式知とする
それぞれ要件があるため、
要件と出来たものの通り
振る舞うかの検証が容易
システム要件
システム
サブシステム要件定義
システムアーキテクチャ設
計
運用テスト
要件と仕様の確認が
容易
設計
結果
サブシステム
サブシステム要件
コンポーネント要件定義
サブシステムアーキテク
チャ設計
システム結合テスト
サブシステム結合テスト
設計
結果
コンポーネント
コンポーネント要件
コンポーネント実装
コンポーネント設計
/実装/デバッグ
外部に発注する際にも要件でや
りとりした方が良い
(要件を実現する仕様は数多くあ
るため、要件を明確に定義してお
く必要がある)
12
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
12
要件ベース開発プロセスの各要件定義工程のタスクモデル
外部設計、内部設計(構造設計)、下位要件の検証・妥当性確認を工程内で閉じて実施可能
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
上位要件
××要件定義
レビュー
レビュー結果
外部設計(仕様設計)
外部設計書
外部設計検証
外部設計検証結果
内部設計(構造設計)
内部設計書
内部設計検証
内部設計検証結果
下位要件
13
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
13
ご参考:米連邦航空局製品認証における開発プロセスARP4754A(
Guidelines for Development of Civil Aircraft and Systems)
FIGURE 5-INTERACTION BETWEEN SAFETY AND DEVELOPMENT PROCESSES
Copyright © 2011 IPA, All Rights Reserved
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
出典:SAE
ARP4754A
Software Engineering Center
14
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
製品・サービスの企画からシステム要件まで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
組織活動記録等
・各種規定類の整備状況
・従事者の教育研修状況 など
活動記録
製品・サービス企画
・製品・サービスの企画が妥当か
・製品・サービスに関連する規定類は妥当か
・製品・サービスに関わる従事者は妥当か
製品・サービス企画検証
製品・サービス企画
要求獲得
システム要件定義
活動記録
要求分析
・システム要件は製品・サービスの企画
と整合しているか
・要求獲得は妥当か
・要求分析は妥当か
・システム要件の検証は妥当か
・システム要件は妥当か
システム要件検証
システム要件
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
15
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
システム要件からソフトウェア要件まで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
システム要件
活動記録
・システム外部仕様はシステム要件を満
たしているか
・システム外部設計の検証は妥当か
・システム外部仕様は妥当か
活動記録
・システム内部仕様はシステム外部仕様
と整合しているか
・システム内部設計の検証は妥当か
・システム内部仕様は妥当か
活動記録
システム外部仕様設計
・ソフトウェア要件はシステム内部仕様と
整合しているか
・ソフトウェア要件の検証は妥当か
・ソフトウェア要件はシステム要件を満足
しているか
・ソフトウェア要件は妥当か
システム外部仕様検証
システム外部仕様
システム内部(アーキテクチャ)設計
システム内部設計検証
システム内部仕様
ソフトウェア要件定義
ソフトウェア要件検証
ソフトウェア要件
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
16
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
ソフトウェア要件から下位ソフトウェア要件まで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
ソフトウェア要件
活動記録
・ソフトウェア外部仕様はソフトウェア要件
を満たしているか
・ソフトウェア外部設計の検証は妥当か
・ソフトウェア外部仕様は妥当か
活動記録
・ソフトウェア内部仕様はソフトウェア外部
仕様と整合しているか
・ソフトウェア内部設計の検証は妥当か
・ソフトウェア内部仕様は妥当か
活動記録
ソフトウェア外部仕様設計
・下位フトウェア要件はソフトウェア内部
仕様と整合しているか
・下位ソフトウェア要件の検証は妥当か
・下位ソフトウェア要件はソフトウェア要
件を満足しているか
・下位ソフトウェア要件は妥当か
ソフトウェア外部仕様検証
実装単位のコンポネントまで繰返し
ソフトウェア外部仕様
ソフトウェア内部(アーキテクチャ)設計
ソフトウェア内部設計検証
ソフトウェア内部仕様
下位ソフトウェア要件定義
下位ソフトウェア要件検証
下位ソフトウェア要件
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
17
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
コンポネント(実装単位となるソフトウェア部分)要件からコンポネントまで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
コンポネント要件
活動記録
・コンポネント外部仕様はコンポネント要
件を満たしているか
・コンポネント外部設計の検証は妥当か
・コンポネント外部仕様は妥当か
活動記録
・コンポネント内部仕様はコンポネント外
部仕様と整合しているか
・コンポネント内部設計の検証は妥当か
・コンポネント内部仕様は妥当か
活動記録
コンポネント外部仕様設計
・コンポネント実装はコンポネント内部仕
様と整合しているか
・コンポネント実装の検証は妥当か
・コンポネント実装はコンポネント要件を
満足しているか
・コンポネント実装は妥当か
コンポネント外部仕様検証
コンポネント外部仕様
コンポネント内部設計
コンポネント内部設計検証
コンポネント内部仕様
コンポネント実装
コンポネント実装検証
コンポネント
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
18
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
コンポネントからシステムまで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
コンポネント
・コンポネント結合は妥当か
・コンポネント結合の検証は妥当か
・結合された下位ソフトウェアは下位ソフ
トウェア要件を満足しているか
活動記録
すべてのソフトウェア結合まで繰返し
活動記録
コンポネント結合
・下位ソフトウェア結合は妥当か
・下位ソフトウェア結合の検証は妥当か
・結合されたソフトウェアはソフトウェア要
件を満たしているか
コンポネント結合検証
下位ソフトウェア
下位ソフトウェア結合
下位ソフトウェア結合検証
ソフトウェア
システム結合検証
活動記録
システム結合
・システム結合は妥当か
・システム結合の検証は妥当か
・結合されたシステムはシステム要件を
満たしているか
システム
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
19
製品・システムのライフサイクル毎のソフトウェア品質監査(仮称)の業務
システムから廃棄まで
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
システム
活動記録
システム運用試験
・システム運用試験は妥当か
・システム運用試験の評価は妥当か
・システムは企画を満足しているか
システム運用試験評価
製品・サービス
・製品・サービスのマニュアルは製品・サ
ービスと整合しているか
・製品・サービスのマニュアルは妥当か
・利用者への提供情報は妥当か
製品・サービスマニュアル
利用者への提供情報
保守
活動記録
運用
・製品・サービスの運用は妥当か
・製品・サービスの保守は妥当か
・製品・サービスの廃棄は妥当か
廃棄
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
20
SEC
ご参考:米連邦航空局製品認証におけるDERのレビュータイミング
Software Engineering
for Mo・No・Zu・Ku・Ri
„ DERの公式レビューは以下に示した「DO-178Bソフトウェア認証プロセス」のSOI#1、 SOI#2、 SOI#3、
SOI#4のタイミングで実施
„ DERは上記の4つの公式レビューの他に、以下のプロセスの の14のタイミングで机上レビューを
実施
DO-178Bソフトウェア認証プロセス
システム適合確認&妥当性確認
認証
SOI#4
適合レビュー
SOI#3
統合
SOI#2
SOI#2:SW開発レビュー
SOI#3:SW適合確認レビュー
コード
設計
下流要求仕様
上流要求仕様
SOI#1
構成管理
開発トレーサビリティ
開発計画、基準、
チェックリスト
システム要求事項
品質保証活動開始
安全評価及び要求事項
SOI#1:SW計画レビュー
SOI:Stage of Involvement
SOI#4:最終認証SWレビュー
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
21
品質監査と技術ドキュメント/開発エビデンスの品質
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
„ ソフトウェア品質監査 ≒ 技術ドキュメント/開発エビデンスを精査し妥当性を確認
文法が間違っている
単語が間違っている
監査できない > 監査以前の問題
曖昧で正確に理解できない
必要なことが記述されていない
内容をすぐに理解できない
監査効率低下 > 監査コスト、期間増大
必要な情報がすぐに見つからない
分かり易く効率的に読める
効率的な監査
Copyright © 2011 IPA, All
Software Engineering Center
22
SEC
技術ドキュメント/開発エビデンスの高品質化に向けて
Software Engineering
for Mo・No・Zu・Ku・Ri
国語力の修得
文法が間違っている
未言語
単語が間違っている
分野知識の獲得
曖昧で正確に理解できない
論理的な思考
形式的記述手法
未文書
記述項目の定義
必要なことが記述されていない
アシュアランスケース
内容をすぐに理解できない
未技術文書
文書構造の設計
必要な情報がすぐに見つからない
分かり易く効率的に読める
利用者・利用シーン
の明確化
理想的な技術文書
利用品質
情報アーキテクチャと
トレーサビリティ
品質メトリックス
Copyright © 2011 IPA, All
Software Engineering Center
23
ESEC(2011年5月)のIPA/SECブース来場者へのアンケート結果
品質監査制度(仮称)に関心がありますか?
(回答数:2154名)
あまり関心がない
14%
関心がない
2%
SEC
Software Engineering
for Mo・No・Zu・Ku・Ri
どのような観点で関心がありますか?
(回答数:1985名)
新しい関連事業を その他
展開したいから
2%
5%
関心がある
31%
品質の向上に
有効そうだから
50%
市場で要求されているから
19%
品質説明力を
強化したいから
24%
やや関心がある
53%
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
24
Software
Engineering
Center
Information-technology Promotion Agency, Japan
ご清聴ありがとうございました
Software Engineering Center
25 25
Fly UP