組込み系ソフトウェア開発の
課題分析と提言
社団法人
電子情報技術産業協会
ソフトウェア事業委員会
ソフトウェア事業基盤専門委員会
2007年7月3日
~大規模化、短納期化、多機種開発における
課題分析とその解決方法~
2006年度活動報告
1
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
1. 複雑化するソフトウェア事業環境
ハードウェア
(メインフレーム、サーバ、PC)の日本国内出荷実績:
2兆6,500億円余り
(JEITA 2005年度統計)
日本国内主要ベンダによる
ソフトウェア・サービス
(システム開発、ミドルウェア、アウトソーシング等)の市場規模:
5兆3,000億円余り
(JEITA 2005年度統計)
組込みソフトウェア開発規模
(内製を含む):
2005年度 約2.7兆円
(経済産業省推定)
ソフトウェア事業の事業基盤の複雑さが益々増大:
オープン化の進展
IT とネットワークの融合の進行
オープンソースソフトウェア活用の高まり
オフショア等のソフトウェアリソースの新たな段階への対応 等々
情報端末機器、デジタル家電、携帯電話、カーエレクトロニクス等を中心に、
組込み系ソフトウェアの領域・開発規模・開発速度が急激に増加。
組込み系ソフトウェアが事業全体の成否を決める鍵となりつつある。
組込みシステムの開発費の40%が組込みソフトウェア開発費
2
2. ソフトウェア事業基盤専門委員会
ソフトウェア事業委員会
:
ソフトウェア業界の共通課題を、
ソフトウェア事業の視点で日本の産業力強化の観点から検討
2005年4月、活動開始
3つの専門委員会:
①
ソフトウェア事業戦略専門委員会
:
・ソフトウェア産業の国際競争力向上と市場活性化のための課題
②
ソフトウェアリソース対応専門委員会
:
・ソフトウェア開発に必要な要員リソースに関する諸問題
③
ソフトウェア事業基盤専門委員会
:
・ソフトウェア事業運営の基盤を確立・強化する共通的な課題
⇒
我が国の強みの源泉・価値創出のキーと言われる
「組込み機器のソフトウェア(組込み系ソフトウェア)」に焦点
⇒この分野での開発力強化等を図るための調査活動を実施
3
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
2.1 組込み系ソフトウェアに関する活動
2005年度
の活動:
組込み系ソフトウェア開発に関する
基本的な実態調査
とその分析・提言
ー 品質確保
- 外部委託活用
- OSS(オープンソースソフトウェア)
2006年度
の活動:
品質確保の問題に焦点を絞り込み、
アンケート調査を実施し、
実態把握、課題分析、課題解決に向けての提言:
◇ 品質の計測と管理の仕組みとしての「品質施策」
◇ 大規模化/多機種開発/システム化を見据えた「品質プロセス」
ドイツ・フラウンホーファー協会IESE(実験的ソフトウェア工学研究所)と
2回に渡るディスカッション
を実施
(6月、11月)
◇ ソフトウェア工学分野の研究で欧州No.1との評価
2007年度
の活動:
課題解決に向けた先進的事例・成功事例の調査・収集
その一環として・・・
IESE/JEITA共同ワークショップ開催
4
「組込み系ソフトウェアは
我が国の強みの源泉であり価値創出のキー」
と言われているが、
組込み対象となるハードウェア機器は強いとしても、
その
ソフトウェア開発力が国際的に見ても本当に強いのであろうか。
「擦り合わせ」
なるものが日本の開発力の強みと言われているが、
急激に増大している開発規模や短納期化の状況の中で、
現在でもそれが強みになっているのであろうか。
何を強くすれば、
我が国の組込み系ソフトウェア開発力の
国際競争力を強化し、
真に「我が国の強みの源泉」たりうるものに
できるのであろうか。
3.組込み系ソフトウェアに関する問題認識
5
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
大規模化、短納期化、多機種開発等の組込み系システム開発の
環境変化に対して、
品質施策の面で対応できているのであろうか
品質施策全般
目的や投資対効果を明確にして運用しているか
品質施策の標準化は行われているか
具体的な品質施策や利用ツールについても調査
特に、品質計測 に重点をおいて
開発規模の増大に対する計測対象や計測工程の変化
外部委託企業との品質計測の連携
短納期化に対する品質計測の効率化
多機種開発に対する品質計測の共通化や水平展開
3.1 品質施策
6
大規模化、短納期化、多機種開発、システム化に対応すべき
組込み系システム開発での
品質プロセスはどうなっているのか
大規模化・短納期化
大規模なソフトウェアに対処するための開発プロセス、
上流工程
での品質の作りこみの施策
ソフトウェア
全体を俯瞰する技術
、
ソフトウェアアーキテクト
の育成方法
多機種開発
差分開発の状況や再利用の方法
プロダクトラインエンジニアリング
の日本における取り組み状況
システム化
ハードウェアとソフトウェアの
擦り合わせ
の実態と方法
「メカニクス/エレクトロニクス/ソフトウェアの
3層化されたV字モデル
」
「システムとしての品質を段階的に検査する
品質ゲートモデル
」も意識
3.2 品質プロセス
7
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
4. アンケート調査の概要
組込み系ソフトウェアの開発に関する以下の設問で構成:
回答対象プロジェクトの概要に関する設問(23問)
品質施策の課題
に関する設問(24問)
品質プロセスの課題
に関する設問(26問)
2005年度アンケート調査に比べ、意識的に自由記述回答の設問を増し、
できる限り開発現場の生の声を調査結果の反映するようにした。
アンケート調査期間:2006年10月20日~11月上旬
アンケート調査対象プロジェクトの範囲:
情報家電機器、携帯機器、自動車や産業機器等の組込みソフトウェアが
搭載された機器(組込み機器)を開発するプロジェクト
組込み機器に搭載されるソフトウェア(組込みソフトウェア/OS/ミドルウェア等)
10名以上の要員規模の開発プロジェクト
(新規開発、既存製品の改良、機種展開等)
アンケート調査の回収結果:
回答社数:JEITAの関連委員会参加企業32社
回答プロジェクト数:59プロジェクト
8
DOS 1% Lynx 1% その他 10% Symbian 3% Windows XP Embedded 5% Windows CE 10% 内製OS 11% VxWorks 12% Linux 19% μITRON 28% SH 23% MIPS 20% x86 15% ARM 13% PowerPC 11% 内製プロセッサ 7% その他 11%
対象とする製品分野
AV機器
(TV、DVD、デジタルカメラ等):
20プロジェクト
コンピュータ周辺機器/OA機器
(プリンタ、スキャナ、複写機等):
16プロジェクト
通信端末機器
(固定電話機、携帯電話等):
6プロジェクト
その他:17プロジェクト
プロセッサ種別
「SH」「MIPS」「x86」
「ARM」「PowerPC」など
種々のプロセッサを対象
組込みOS
「μITRON」、「Linux」、
「VxWorks」の順に多い
2005年度に比べて、
Linuxの割合が増加
Windows系も合わせて15%
と2005年度より増加
5.回答プロジェクトの概要
5.1 製品分野、プロセッサ種別、組込みOS
図5.1 対象プロセッサ
図5.2 対象とする組込みOS
9
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association C 50% C++ 30% Java 4% アセンブラ 16%
図5.3 開発言語
1 15 28 13 3 0 5 10 15 20 25 30 ~3ヶ月 ~6ヶ月 ~1年 ~2年 2年~ 0 9 24 20 3 2 0 0 1 16 19 19 0 1 0 1 1 9 13 15 7 5 6 2 0 5 10 15 20 25 30 なし ~10K ~100K ~1,000K ~2,000K ~3,000K ~5,000K 5,000K~ プロジェクト数 6 12 12 8 8 5 8 0 2 4 6 8 10 12 14 ~100K ~500K ~1,000K ~2,000K ~3,000K ~5,000K 5,000K~ プロジェクト数5.2 開発言語、開発規模、開発期間
開発言語
2005年度と比べて、
Cの比率は同程度、
C++が微増、
アセンブラが微減
開発規模
約半数(49%)のプロジェクトが
1,000K SLOCを超える規模
5,000K SLOCを超える規模の
プロジェクトが8プロジェクトもある
開発期間
回答プロジェクトの
3/4近くが
1年以下の開発期間
図5.4 開発規模(完成規模)
図5.4 開発規模(新規作成、変更、流用)
図5.5 開発期間
10
5.3 開発対象製品数、対象ハードウェアの新規性
図5.6 開発対象製品(機種)数(ハードウェア、ソフトウェア)
図5.7 開発対象ハードウェアの新規率
開発対象製品
(機種)数
回答プロジェクトの8割近く
が
2機種以上のハードウェア
を対象
回答プロジェクトの2/3近く
が
2機種以上のソフトウェア
を開発
1プロジェクトで複数機種のソフト
ウェアを開発する
多機種開発
の
実態が浮き彫りに
対象ハードウェアの新規性
新規開発:改造:市販品:その他=
39% :45%:
16%: 0%
新規開発+改造が主要な部分を占め、
独自のハードウェアが依然として差別
化要因となっている
1製品 23% 11製品~ 10% 2~3製品 42% 4~5製品 12% 5~10製品 13% ハードウェア 4~5製品 12% 11製品~ 14% 5~10製品 12% 2~3製品 29% 1製品 33% ソフトウェアその他
0%
標準品・
市販品
16%
改造
45%
新規開発
39%
11
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
ソフトウェア 技術者 65% 機械系 ハード技術者 10% 電気系 ハード技術者 25% 27 14 7 2 22 10 8 7 10 10 0 5 10 15 20 25 30 ~10人 ~50人 ~100人 ~200人 200人~
5.4 投入要員数、投入工数比率、分野別技術者構成
投入要員数
回答プロジェクトの
85%が
100名以下の要員
15プロジェクト(26%)で
ピーク時要員が100人超
工程別投入工数比率
設計:実装:テスト:保守=3:3:3:1
保守工数が小さく、テスト工数が大きめ
分野別技術者構成
回答プロジェクトでは、
システム全体の開発要員の
2/3がソフトウェア技術者
設計 29% 実装 32% テスト 31% 保守 8%図5.9 工程別の工数投入比率
図5.10 分野別技術者構成
図5.8 開発プロジェクトの平均要員数、ピーク時要員数
12
25%~50%未満 24% 25%未満 31% 75%~ 16% 50%~75%未満 29%5.5 外部委託工数の利用比率、外部委託工程
外部委託工数の利用比率
約7割(69%)のプロジェクトで、
全体工数の25%以上を外部委託に依存
全体工数の50%以上を外部委託に依存
しているプロジェクトが、回答プロジェクト
の45%に及んでいる
外部委託工程
コーディング・デバッグからテストに至る
下流工程の外部委託が大きな割合
を
占めている
仕様設計、基本設計などの
上流工程
にも外部委託が採用
されている。
2005年度と同様の傾向だが、
テスト仕様設計工程での使用比率が
6%から10%に増加
。上流工程へのシフト
傾向とテスト工数増大に対する施策の
影響が出ている可能性も考えられる
図 5.12 外部委託する工程
図 5.11 外部委託工数の利用比率
6
10
6
21
43
48
36
31
8
6
3
0
10
20
30
40
50
60
仕様検討 基本設計 ハードウェア性能評価 テスト仕様設計 詳細設計 コーディング・デバッグ 単体テスト 結合テスト フィールドテスト 保守・サポート その他13
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
5.6 外部委託先、海外の外部委託先
外部委託先
外部委託先の7割が国内企業
海外企業への外部委託は2割程度
グループ会社でない受託開発会社
への外部委託が5割
海外の外部委託先
中国
(12プロジェクト)が最多、
次いで
北米
(6プロジェクト)、
インド
(5プロジェクト)
北米、西欧への外部委託
は、
コア技術の開発委託の可能性が
うかがえる
図5.13 外部委託先比率
図 4.14 海外の外部委託先
その他 1% 社内別部門 9% 受託開発会社 (海外) 10% グループ会社 (海外) 9% グループ会社 (国内) 30% 受託開発会社 (国内) 41%その他
6%
台湾
6%
西欧
9%
韓国
9%
インド
15%
北米
18%
中国
37%
14
5.7 OSSの利用状況
OSSの利用状況
製品での利用は 31%、2005年度より増加傾向
開発環境での利用も含めると 52%
になる
製品で利用している大半のプロジェクトでは、
全プログラム規模の10%程度
に利用
全プログラム規模の60%超にOSSを利用して
いるプロジェクトもある
図5.15 OSSの利用状況
製品での利用率
利用していない
48%
製品に利用
31%
開発環境だけで
利用
21%
9 4 4 1 1 0 0 2 4 6 8 10 ~10%未満 10%~20%未満 20%~40%未満 40%~60%未満 60%~80%未満 80%以上製品での利用率
15
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
品質状況
回答プロジェクトの
半数強(54%)で、出荷後に重度障害
を検出、依然として品質確保困難
品質要求レベル
回答プロジェクトの
2/3で
「最重要」・「重要」レベル
品質問題の重要度
回答プロジェクトの
9割が
ビジネス上の大きな課題と認識
スケジュール遅れ、競争力低下、
コスト上昇、ブランド価値低下
5.8 品質状況、品質要求レベル、品質問題の重要度
図5.16 出荷前障害件数
図5.17 出荷後障害件数(軽度)
図5.18 出荷後障害件数(重度)
12 10 14 21 0 5 10 15 20 25 ~100件 ~500件 ~1,000件 1,000件~ 28 23 1 3 0 10 20 30 ~10件 ~50件 ~100件 100件~ 26 26 1 3 0 10 20 30 0件 ~5件 ~10件 10件~ 19 19 20 1 0 5 10 15 20 25 最重要(社会問題) 重要(企業内で問題) 通常(平均的レベル) 緩和(緩和されたレベル) 33 25 24 5 2 0 5 10 15 20 25 30 35 スケジュール遅れ 競争力低下 コスト上昇 法規制などの問題 その他図5.19 品質要求レベル
図5.20 品質問題に起因する
ビジネス上の課題
16
品質の要因
最も重要な要因は 「大規模化」
次に重要な要因は 「短納期化」
重視する品質項目
最も重視する項目は 「機能安全性」
次に重視する項目は 「ユーザビリティ」
機能保証は当然となり、さらにその先の
安全性、ユーザビリティに重点がシフト
5.9 品質の要因、重視する品質項目
図5.22 重視する品質項目
図5.21 品質の要因
22 15 19 5 2 1 9 25 12 8 11 1 0 5 10 15 20 25 30 開発規模の大規模化 短納期化 開発ソフトウェアの複雑化 多機種製品シリーズへの対応 ハードウェア品質の安定度 その他 最重要 次に重要 27 26 8 4 2 8 17 18 13 7 0 5 10 15 20 25 30 機能安全性 機能性 ユーザビリティ 効率性 セキュリティ最重視
次に重視
17
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
6. 品質施策の状況と課題分析
品質施策は下流工程から上流工程へ
要求分析・設計工程重視へ
現状は下流(試験工程重視・不具合情報)中心
品質計測は、リスク対策を目的として一定のコストを掛けている
生産性計測とは連携していない
仕様変更の計測は半数以下で、品質との関係を重視していない
多機種開発に対する施策が弱い
具体的品質施策
ツールの利用状況
コードメトリクスツールの使用は多いが、その他のテストツール使用は少ない
プロジェクト管理ツールや構成・版数管理ツールの使用は多い
テスト項目数の削減により、品質施策の実施を効率化している
コーディング規約など、標準化の重要性は認識されている
外部委託先との共有も進んでいる
18
9
27
22
30
53
38
34
2
0
10
20
30
40
50
60
要
求分
析
設計
作成
単
体試
験
シ
ス
テ
ム
試験
製
品検
査
リリー
ス
後
そ
の他
22 42 15 18 34 15 6 36 45 20 20 17 4 50
10
20
30
40
50
要求 分析 設計 作成 単体 試験 シ ステ ム 試 験 製品 検査 リリ ー ス 後 現状 将来6.1 品質計測 (1)
重点は下流工程から上流工程へ
設計工程は現在も将来も重視する
現在71%、将来76%
品質施策は要求分析工程重視へ
現在13%、将来21%
システム試験重視から当たり前の段階へ
現在58%、将来29%
品質計測実施は下流(試験工程)中心
設計46%、試験90%で計測実施
設計工程は重視するが、品質計測は
未実施が多い
図6.1 品質で重視する工程
図6.2 品質計測をしている工程
19
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
いいえ, 49,
84%
はい, 9, 16%
件数 11 39 6 3 0 0 10 20 30 40 50 コスト以上の効果 リスク対策 効果とコストは同じ その他 効果なし 件数 5 3 7 28 10 3 0 5 10 15 20 25 30 計測 な し 1日以 内 1% 以 内 1% ~ 5% 5%~ その 他6.1 品質計測 (2)
計測は一定のコストを掛け、
その目的はリスク対策
計測コストは一定量掛ける
半数が全体の1~5%の計測コストを掛ける
リスク対策として実施
リスク対策66%
生産性計測と連携していない 84%
図6.5 生産性計測との連携
図6.3 品質計測のコスト
図6.4 品質計測のコスト効果
20
はい
60%
いいえ
40%
40
15
10
13
13
7
9
30
17
21
15
17
0
10
20
30
40
50
単に管理
要求や仕様、テストケースとリンク
構成・版数管理の一部として管理
不具合とさらにメトリクスも管理
統計データとして管理
品質の相関関係を定量的分析
現在
将来
6.1 品質計測 (3)
仕様変更の計測意識不足
40%で未実施
品質に与える影響をあまり考慮していない
不具合情報と他の情報との連携は将来に
現在 22%、将来51%
図6.6 仕様変更の計測
図6.7 品質計測の手法
21
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
6.2 品質計測の傾向
品質計測の傾向
品質計測の調査で、選択回答の多かった(50%以上)主な項目
計測対象は不具合情報
単体試験~リリース後の各工程で品質を計測
リスク対策のため、全体の1%~5%のコストをかけて計測
不具合情報として、作り込んだ工程、発見したバージョン、対策内容を記録
将来は仕様やコード、テストケースと連携させて不具合情報を管理
品質施策として重視している工程は、現在は設計とシステム試験の工程で、
将来は要求分析と設計の工程を重視する
22
3 3 18 6 2 1 14 4 0 5 10 15 20 テストフレームワーク 単体テスト自動生成ツール メトリクスツール テスト自動実行ツール 負荷テスト セキュリティテスト 独自ツール その他の分野のツール 件数 26 9 14 9 38 2 0 5 10 15 20 25 30 35 40 プロジェクトツール 要求分析・管理ツール 設計支援ツール コード自動生成ツール 構成・版数管理ツール その他6.3 具体的品質施策 (1)
ツールの利用状況
コードメトリクスツールを35%が使用
独自ツールを27%が使用
それ以外のテストツールの使用は少ない
プロジェクト管理ツールは52%が使用と多い
構成・版数管理ツールは76%が使用と多い
図6.8 テストツールの使用
図6.9 その他のツールの使用
23
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
2 4 1 3 1 7 2 1 0 5 10 15 20 25 3 0 標 準 規 約 ツ ー ル 委 託 元 に 品 質 保 証 ( 検 査 ) の 一 元 化 委 託 先 に 品 質 保 証 ( 検 査 ) も 委 託 そ の 他 はい 95% いいえ 5% 20 22 10 28 3 0 5 10 15 20 25 30 直交表 変更影響度 テスト自動ツール 新規・変更限定テスト その他
品質施策の実施効率化
テストケースの項目数削減は
高い実施率
標準化の重要性を91%が認識
コーディング規約は品質課題に有益
外部委託先と規約共有は41%
複数同時並行開発のためには施策を水平展開
製品全体の品質向上にはプロセス改善
6.3 具体的品質施策 (2)
図6.10 テストの効率化施策
図6.11 品質に関する標準化が課題解決に役立つか
図6.12 外部委託先と共有する品質施策
24
6.4 具体的品質施策の傾向
具体的品質計測の傾向
具体的品質施策の調査で、選択回答の多かった(50%以上)主な項目
品質の計測はExcelや独自ツールで行う
品質の計測と分析はともに開発メンバが行っている
異常データは通常データと同様に扱う
構成・版数管理ツールを使用
テスト品質向上のために、設計者とテスト担当者との相互レビューを実施
テスト品質向上のために、新規・変更部分のテストケース作成に留意
大規模化・複雑化のため、テストは十分とは言えない
品質施策に関する標準化は重要で、外部委託先と共有している
25
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
6.5 品質施策に関する提言
コストと効果を考慮した品質施策
効果に見合ったコストで品質施策を実施する
明確なゴールを設定して、効果を検証しながら実施する
プロジェクトの規模に応じたツールを積極的に利用する
ソフトウェア開発の上流工程へのシフト
品質施策は、効果が大きい上流工程へシフトする
上流工程での品質の定量化とその計測および分析が重要
多機種開発への適用
多機種開発を前提として、各プロジェクトへの水平展開を促進するツー
ルを利用する
品質関連標準化の共有
品質施策に関する手法やツールは、費用対効果の面からも、
外部委託先と共有する
26
7. 品質プロセスの状況と課題分析
ソフトウェアの大規模化
開発体制や開発プロセスの整備が追いついていない
設計の文書化/モデル化を行い、上流工程を重視していく方向である
ソフトウェア全体を統括する仕組みが弱く、人を介したコミュニケーションが中心
で、開発手法として定式化されていない
多機種開発
従来型のウォーターフォールプロセスの採用が多く、もはや実態に合わないプロセ
スを、現場開発者が適時、工夫変更しながら開発を続けている
プロダクトラインエンジニアリングという体系的な技法はには期待が大きいが、本
格的な導入はまだこれから
システム化と擦り合わせ
ハードウェアの仕様決定時期は開発の後半でも発生している
仕様や、ハードウェアとソフトウェア双方に関わる活動の計画策定と管理もハード
ウェアが主導している
ソフトウェア開発を配慮した形の、ハードウェアとソフトウェアの統合開発プロセス・
開発方法論が必要となっている
27
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
7.1 ソフトウェアの大模化 (1)
大規模化の状況とその対策
88%のプロジェクトで規模増大傾向
プロジェクト管理手法の導入には効果もあ
るが、課題もあり
図7.1 ソフトウェア規模の増加傾向
図7.2 ソフトウェア開発規模増加に対する施策
増加傾向有り 8 8 % 増 加傾向 無し 12% 8 3 5 23 29 0 5 10 15 20 25 30 35 その他 会議の効率化 外部委託による開発スタイル刷新 プロジェクト管理手法の導入 詳細な計画策定28
1 6 15 34 0 5 10 15 20 25 30 35 40 その他 自然言語による自由記述 UML等による図解表現 自社内の独自フォーマット 0 2 2 2 3 3 3 9 9 9 15 16 18 22 28 29 0 5 10 15 20 25 30 35 配置図 コンポーネント図 その他 SDL パッケージ図 コミュニケーション図 アクティビティ図 オブジェクト図 タイミング図 データフロー図 ユースケース図 クラス図 モジュール構造図 状態遷移表 状態遷移図 シーケンス図7.1 ソフトウェアの大規模化 (2)
図解表現 (モデリング) 使用 79% 図解表現 (モデリング) 未使用 21%図7.3 全体構造を表記した設計書の記法
図7.4 図解表現(モデリング)の使用
図7.5 図解表現(モデリング)の表記法
全体を把握する仕組み(文書化)
全体構造を表記したドキュメントは
83%が保有
図解表現は79%が採用
可視化意識は高いが、ツールを利
用した体系的設計には至らず
29
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
3 2 26 30 6 0 5 10 15 20 25 30 35 その他 コーディング時 詳細設計時 基本設計時 仕様策定時
7.1 ソフトウェアの大規模化 (3)
図7.6 設計工程から次工程への移行判断方法
図7.7 ソフトウェアのモジュール間インタフェース仕様が決まる工程
図7.8 ソフトウェアのモジュール間
インタフェース仕様を決定する人
開発全体を統括する仕組み
工程の移行は60%が責任者の総合判断
モジュール間インタフェースは、設計を進めなが
ら、担当者同士や会議で決められる
55%のプロジェクトでソフトウェア
アーキテクトが存在
全体統括を意識するも、アーキテクトの育成は
手つかずの状況
参考とする指標 保有 23% 責任者による 総合判断 60% その他 6% 厳密な判断基準 保有 11% 担当者同士 42% 会議で決定 35% 設計リーダー 23%30
4 8 5 6 17 21 0 5 10 15 20 25 その他 多機種開発は行っていない 同時期リリースに向けて テスト工程から分離して並行開発 同時期リリースに向けて 実装工程から分離して並行開発 同時期リリースに向けて 設計工程から分離して並行開発 リリース時期をずらして順次開発
多機種開発の方法
差分開発は77%のプロジェクトで
行われている
多機種開発へは共通化により対応している
工程の共通化を含むリソースの共通化
ソフトウェア資産の共通化・再利用
7.2 多機種開発 (1)
図7.10 多機種開発の方法
図7.9 差分開発の実施状況
差分開発を実施 77% 差分開発を 実施していない 23%31
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
3 0 2 1 1 10 15 34 0 5 10 15 20 25 30 35 40 その他 ライフサイクルマネジメント型(PLM) プロダクトライン型 モデル駆動型(MDA) アジャイル型(XP/SCRUM) 反復型(繰り返して洗練) 増分型(インクリメンタルに積上げ) ウォーターフォール型
多機種開発の開発プロセス
開発プロジェクトの82%で開発プロセスがある
ウォーターフォールプロセスの採用が最も多い。
増分型、反復型を併用するケースも多い。
画一的な開発プロセスモデルが、プロジェクトに
必ずしも適合しない状況がうかがえる
伝統的、制度的な理由で、特定の開発プロセス
モデルが採用される場合、現場が不適合を訴える傾
向が強くなる
7.2 多機種開発 (2)
図7.11 導入している開発プロセスの有無
図7.12 導入している開発プロセス
導入開発プロセス 有り 8 2% 導入開発プロセス 無し 18 %32
7.2 多機種開発 (3)
図7.13 プロダクトラインエンジニアリング
導入状況
図7.14 多機種開発での工夫点
多機種開発のこれからの取組み
プロダクトラインエンジニアリングの導入は
11%と、まだ多くはない
プロダクトラインエンジニアリング実践の要件
としては、再利用への取り組みが最も進んでいる
プロ ダクトライン を 導入している 11 % プロダクトラインを 導入していない 89 % 2 14 6 7 11 29 0 5 10 15 20 25 30 35その他
特に無し
共通部開発と個別商品開発の組織を独立化
複数機種統括のプロジェクト管理の仕組み保有
変動部分を特定して管理
共通モジュールを部品化して再利用
33
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
多機種開発のプロジェクトマネジメント
ハードウェアとソフトウェアを一体で
管理しているプロジェクトは41%
開発メンバーがプロジェクト管理者を
兼任するケースが52%
ソフトウェア担当者による兼任が半数
7.2 多機種開発 (4)
図7.15 プロジェクト管理はハードウェア
とソフトウェアで一体か?
図7.16 プロジェクト管理者は専任か?
開発メンバー兼任か?
図7.17 プロジェクト管理者が兼任の場合、ハード
担当者、ソフト担当者のどちらが担当か?
一体で実施 41% 一体で実施して いない 59% 専任 48 % 開発メンバー 兼任 52% ハード担当者 23% ソフト担当者 46% どちらとも言えない 31%34
ハードウェアとの協調
ハードウェアとのインタフェース仕様決定は、
1/4のプロジェクトで、詳細設計以降に
仕様決定者はハード担当者が多い
ハードの変更はコーディング時まで発生し、
ソフトが対応している
ハードウェア主導の開発体制が多い
7.3 システム化と擦り合わせ (1)
図7.18 ハードウェアとのインタフェース仕様の決定工程
図7.19 ハードウェアとのインタフェース仕様の決定者
図7.20 ハードウェアの仕様変更時期はどの工程まで発生?
4 15 37 17 0 5 10 15 20 25 30 35 40 コーディング時 詳細設計時 基本設計時 仕様策定時 2 17 19 14 30 5 0 5 10 15 20 25 30 35 その他 担当者同士 会議で決定 ソフトウェアの設計リーダー ハードウェアの設計リーダー 全体の設計リーダー 8 34 12 9 4 0 5 10 15 20 25 30 35 40 その他 コーディング時 詳細設計時 基本設計時 設計構想時35
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association
ハードウェアとソフトウェアを統合する開発プロセス
ハードウェアに起因する不具合をソフトウェアで対応するケースがある
インタフェース仕様の不備
ハードウェア性能や機能の補完
ソフトウェア側でハードウェアへの依存度を下げる工夫も
ハードウェア側との全体プロセスを考慮した工夫は少ない
ハードウェアとソフトウェアを統合した開発プロセスが存在していない
7.3 システム化と擦り合わせ (2)
図7.21 システム総合試験で発生するソフトウェア問題点の
うち、ハードウェアに起因する問題点
図7.22 ハードウェアの影響を局所化し、
ソフトウェアの品質を確保する工夫
3 25 17 31 0 5 10 15 20 25 30 35 その他 元々のハードウェア機能をソフトウェアでカバー 不十分なトータル性能をソフトウェア性能アップ インタフェース仕様書の問題 5 12 20 38 0 5 10 15 20 25 30 35 40 その他 ハードエラー検出用プログラム(アサーション)を 挿入 シミュレータ上でソフトウェアの品質を確保 ソフトウェア構造のレイヤ化によるハードウェア 依存部を局所化36
4 1 8 1 12 0 2 4 6 8 10 12 14 特定していない プロジェクトリーダ ハードウェア・ソフトウェア部門双方の合議 ソフトウェア担当部門 ハードウェア担当部門
ハードウェアとソフトウェアの擦り合わせ方法
34%のプロジェクトでは、ハードウェアとソフトウェアが
関連する活動が事前に計画されていない
76%のプロジェクトでは、ハードウェアとソフトウェアの
部門が一緒に、計画策定や各工程での確認をする機会
がある
システムアーキテクトは25%のプロジェクトで存在
システムアーキテクト不在の場合は、ハードウェア
担当部門が主導
システムアーキテクトを育成する仕組みはない
7.3 システム化と擦り合わせ (3)
図7.23 ハードウェアとソフトウェアの両方が関連す
る活動が事前に計画され明確になっているか?
図7.24 ハードウェアと
ソフトウェアの担当部門が
一緒になっての計画策定等を
実施する機会
図7.25 システムアーキテクトの存在
図7.26 システムアーキテクト不在の場合、ハードウェア
とソフトウェア間の機能分担等に責任を持つ部門は?
明確 63% 不明確 37% 一緒の策定・確認 等の機会 無し 24% 一緒の策定・確認 等の機会 有り 76% システムアー キ テ クトが存在 25 % システム アーキテ ク トが存在しない 7 5%37
2007/7/3 IESE/JEITA共同ワークショップ
Copyright (C) 2007 Japan Electronics and Information Technology Industries Association