講演の様子

講演

1. 開会の挨拶：大規模化､複雑化､短納期化､多機種化する開発にどのように立ち向かうべきか
2. 組込みソフトウェア開発のスピードアップ 〜 これで良いのか？組込みソフトウェア開発 〜
3. 組み込み分野へのソフトウェアエンジニアリングの活用法
4. モデル駆動型開発の導入による生産性向上の事例
5. 組込み製品のテスト効率化・合理化への取組み

1. 開会の挨拶：JEITAソフトウェア事業基盤専門委員会活動から
   大規模化､複雑化､短納期化､多機種化する開発にどのように立ち向かうべきか

• 前半は、JEITAソフトウェア事業基盤専門委員会が2005年度から取組んでいる組込み系ソフトウェア開発の 課題分析と提言活動に関して、2007年度までの活動内容の要点と今年度(2008年度)の活動の狙いが、 同専門委員会委員長より紹介された。
• 後半は、IPAソフトウェアエンジニアリングセンター(SEC)の概要と組込み系プロジェクトの活動の概要や狙いが、 同センターの組込み系プロジェクトリーダー門田氏より紹介された。

■ JEITAソフトウェア事業基盤専門委員会の活動について：

• 組込み系ソフトウェア開発に関する問題意識
  • ソフトウェア開発力が国際的に見ても本当に強いのであろうか?
  • 現在でも｢擦り合わせ｣が強みになっているのであろうか?
  • 何を強くすれば、真に「我が国の強みの源泉」たりうるものにできるのであろうか?
• 開発現場の現状 と 現場から見た課題
  • コード中心の開発
  • 有効に機能しない再利用、不明確な全体構造
  • 全体構造が把握されないまま進行する開発
  • 有効な施策と現実のギャップ
• 課題解決に向けての本専門委員会の取組み
  • 2005年度の活動： “足元を知る”
    • 日本の開発現場が抱える問題点、課題、今後の方向性の把握と分析
    • 組込み系ソフトウェア開発に関するアンケート調査 （JEITA参加企業：30社、70プロジェクト）
      • 品質確保、外部委託活用、OSS利用
  • 2006年度の活動： “品質確保”問題に集中
    • ドイツ・ Fraunhofer IESEソフトウェア工学研究所と2回に渡るディスカッション
    • ソフトウェアの品質劣化要因の把握と分析： 品質確保の問題に焦点を絞り込みアンケート調査（ JEITA参加企業：32社、 59プロジェクト）
      • 品質の計測と管理の仕組みとしての「品質施策」
      • 大規模化/多機種開発/システム化を見据えた「品質プロセス」
  • 2007年度の活動： “効果的な取組み”の実態把握
    • 課題解決に向けた先進的事例・成功事例の調査・収集
    • 大規模化、複雑化、短納期化、多機種化に立ち向かう具体的な取組みのアンケート調査（関西経済連合会「組込みソフト産業推進会議」参加企業、JEITA参加企業：57社、69プロジェクト）
      • ハードウェア部門等との連携/自動化/上流工程重視/多機種開発の取組み
• 今後強化すべき施策
  • アーキテクチャ主導開発（トップダウンアプローチ）
  • 上流工程重視開発（フロントローディング）
  • トップダウンアプローチとボトムアップアプローチの融合
  • それらを遂行できる能力のある技術者チームの構築
  • 戦略的・長期的な視点に立ったアーキテクトの育成
• 2008年度の活動： 組込み系ソフトウェアの開発スピードアップに向けて
  • ｢開発スピードアップ｣の主要課題の検討
  • ｢開発スピードアップ｣に関するワークショップ
  • ｢開発スピードアップ｣に関するアンケート調査
  • ｢開発スピードアップ｣の取組みに関する海外調査

■ IPA SECの概要と組込み系プロジェクトの活動について：

• SECの設立と組織
  • 設立目的
  • 組織情報
• 組込みシステム関連産業構造
  • 最終的な川下産業の「組込みシステム製品」の機能実現のため、 川上側の「組込みソフトウェア技術開発」を起点に、「ソフトウェア製品・ツール」、 「受託、サービス」というフローを経る
• SEC 組込みソフトウェア・エンジニアリング領域の狙い
  • 公的な支援機関(SEC)として、組込みソフトウェア開発に適したソフトウェアエンジニアリング技術の整備・普及推進を図る
    • 標準的な手法の整備・開発
    • 手法普及のためのマテリアル整備
• SEC 組込みスキル領域の狙い
  • 公的な支援機関(SEC)として、組込みソフトウェア（システム）開発に必要とされるスキルの見える化、キャリアの定義と意味づけを行い、それに基づく人材育成教育の促進を図る
    • 新しいスキル標準ETSSと診断方法
    • 教育カリキュラムガイドの開発
    • 手法普及のためのマテリアル整備
• 組込み系プロジェクトの活動概観
• 普及のための業界協業
  • 自動車 − 企業 −JasPar
  • 情報家電、OA − 企業 − JEITA
  • 工業制御 − 企業 − JEMIMA、NECA等
  • 携帯機器 − 企業 − CIAJ等
• SEC活動への参加方法

2. 組込みソフトウェア開発のスピードアップ
〜 これで良いのか？組込みソフトウェア開発 〜

• 組込みシステム開発の限界に近づきつつある現状に対する問題提起がなされた後に、 日本のものづくりの強みと弱みの理解に向けて、日本のものづくりの特性について指摘がなされた。 それを受けて、組込みソフトウェア開発が目指すべき方向や課題解決に向けての方向性など、 組込みソフトウェア開発スピードアップに向けての提案が述べられ、最後に、 産学連携の必要性とTOPPERSとNCESと取組みが紹介された。

• 組込みシステム開発の現状と問題提起
  • 組込みシステム開発を取り巻く状況
    • 従来からの組込みシステムの大規模化・複雑化
    • 組込みシステムの適用分野が拡大
    • 開発期間の短縮やコストダウンに対する要求
    • (単一の) プロセッサの高速化の限界
  • 組込みシステム開発のアチーブメント
    • レクサスLS460
  • 組込みシステム/ソフトウェア開発の課題
    • 設計品質・信頼性・安全性の確保／向上
    • 設計資産の再利用の促進
    • その他にも多くの課題
    • その背景にある深刻な問題
      • 組込みシステム技術者(人材)不足
  • 組込みソフトウェアに関する政府の動き
    • 総合科学技術会議
    • 第3期科学技術基本計画の分野別戦略(情報通信分野)
      • 高信頼・高安全・セキュアな組込みソフトウェア設計開発技術
      • System-on-Chip技術と組み込みソフトウェア技術
    • 2008年5月採択の「革新的技術戦略」
      • 組込みソフトウェア技術(高信頼ソフトウェア)
  • 組込みシステム/ソフトウェアの多様化と分類
    • 組込みシステムの多様性と分化
    • 組込みシステム/ソフトウェアの大分類
      • 制御系組込みシステム
      • 情報系組込みシステム
      • システムLSIへの組込みソフトウェア
  • 組込みソフトウェア開発の方向性
    • 応用分野毎のプラットフォーム構築
    • モデルベースのアプリケーション設計
    • プラットフォーム開発とアプリケーションソフトウェア開発を明確に分離する
  • 応用分野毎のプラットフォームの共通化・標準化の例
    • 社内共通プラットフォーム
      例) 松下電器のUniPhier (ユニフィエ)
    • 業界内でのプラットフォーム標準化活動
      例) JASPAR、 CE Linuxフォーラム
    • 業界内でのプラットフォームのデファクト標準
  • 近付く組込みシステム開発の限界
    • これで良いのか？ 組込みソフトウェア開発
      • 人海戦術的な開発体制
      • 開発管理にかかるオーバヘッドが大きい
      • レベルの高い技術者が開発管理だけやっていてよいのか？
      • ソフトウェア技術者の能力をちゃんと活かせているか？
  • 次に起こると思われること
    • これで良いのか？ 組込みソフトウェア開発
      • 現状： 組込みソフトウェアの開発期間は、製品の出荷時期から、ハードウェア(メカ、エレキ) の開発期間を考慮して決定されている。
      • 次には： 組込みソフトウェアの開発期間が、製品の開発期間 (＋製品の出荷時期) を決定するようになる。
• 日本のものづくりの特性 〜強みと弱みを知るために〜
  • 製品アーキテクチャと比較優位
    • 組み合わせ型と擦り合わせ型
  • 日本企業は擦り合わせ型の製品が得意(仮説)
  • 各国の得意なアーキテクチャ(ラフな議論)
    • 日本： 統合力⇒擦り合わせ(オペレーション重視)
    • 米国： 構想力⇒オープン・組み合わせ(知識集約型)
    • 中国： 動員力⇒オープン・組み合わせ(労働集約型)
    • 韓国： 集中力⇒オープン・組み合わせ(資本集約型)
    • 欧州： 表現力⇒擦り合わせ(デザイン・ブランド重視)
  • 組込みソフトウェアと擦り合わせ
    • ソフトウェア技術の特性
    • 組込みソフトウェアは擦り合わせ型(に近い)： ソフトウェアモジュールと1対1に対応しない(対応させるのが難しい)非機能制約の存在
  • 擦り合わせが過剰になってはならない
    • 過剰な擦り合わせは、過剰品質・高コストにつながる
    • 組み合わせ型の製品に追い付かれないためには、ユーザ要求を引き上げる必要がある
  • 日本のものづくりはなぜ品質が高いか？
    • 技術者の品質意識/士気(morale)に支えられた品質
    • 日本の技術者はなぜ品質意識/士気が高いのか？
      • 研究者／設計者であっても、製品に問題があった場合には、ものづくりの現場までフォローさせられる
      • 擦り合わせ型の開発体制
    • 日本(自社) に向いた開発プロセスと人材育成
  • 部分から全体へ
    • 日本の芸術 (特に建築？) の特徴
    • そう言われてみれば･･･
  
  
• 組込みソフトウェア開発スピードアップに向けての一提案
  • 組込みソフトウェア開発の目指すべき方向
    • 基本方針： 日本のものづくりの強みと弱みを理解して、弱いところをカバーしつつ、強いところを活かす
    • 大きい流れ： 組込みシステムおよびソフトウェアの大規模化・複雑化が進行する中で、組み合わせ型のアーキテクチャへの転換なしには、開発が立ち行かなくなる状況
    • 弱いところをカバー： 組み合わせ型アーキテクチャのトップダウン(全体から部分へ)の構築にどう取り組むか？
    • 強いところを活かす： 擦り合わせ型のコア資産をボトムアップ開発する？
  • スピードアップに向けての提案
    • 人(技術者)の重視
    • 開発できる部分は先に開発しておく
      • プロダクトライン開発
      • コンポーネントベース開発
      • プラットフォームベース開発
    • 開発管理をアウトソースする
  • 開発できる部分は先に開発しておく
    • 基本的な考え方
    • 先行開発の課題
    • 先行開発できる部分
    • 先行開発の特性とその活用
      • レベルの高い技術者だけで開発することが可能
      • 職人的/芸術的なソフトウェア開発が許容できる
      • 管理オーバヘッドとリスクが低い開発プロセスを採れる
  • 職人的/芸術的ソフトウェア開発の見直し
    • 基本的な考え方： ソフトウェア生産性が極めて高い職人的/芸術的なソフトウェア技術者を活用する
    • 品質確保のための施策： 職人的/芸術的なソフトウェア技術者の意識改革(教育)、ツールの活用(職人芸の工学的支援)
• 産学連携の必要性と取組み 〜TOPPERSとNCES〜
  • 日本における組込みシステム技術の重要性と現状
    • 組込みシステム研究・開発活性化の必要性
    • 組込みシステム研究に関する国際的な状況
    • 日本における取組み
  • 組込みシステム分野における産学連携の必要性
    • 組込みシステム技術に取り組む際の障害
      • 組込みシステムは古くて新しい技術分野
    • この状況を打破するには･･･
  • 組込みシステム研究/教育活性化のための取り組み
    • 名古屋大学組込みシステム研究センター (NCES)
    • TOPPERSプロジェクト
    • 情報処理学会組込みシステム研究会
    • SWEST (組込みシステム技術に関するサマーワークショップ)
    • CEST (組込みシステム開発技術研究会)
    • SESSAME (組込みソフトウェア管理者・技術者育成研究会)
  • TOPPERSプロジェクトとは？
    • Toyohashi Open Platform for Embedded and Real-Time Systems
    • プロジェクトの活動内容： ITRON仕様の技術開発成果を出発点として、組込みシステム構築の基盤となる各種のオープンソースソフトウェアを開発するとともに、その利用技術を提供
    • プロジェクトの推進主体： 産学官の団体と個人が参加する産学官民連携プロジェクト、2003年9月にNPO法人として組織化
  • TOPPERSプロジェクトの狙い
    • 現世代のリアルタイムOSの決定版の構築
    • 次世代のリアルタイムOS技術の開発
    • 組込みシステム技術者の育成への貢献
  • TOPPERSプロジェクトの主な開発成果
  • TOPPERSプロジェクト開発成果物の主な利用事例
  • TOPPERS新世代カーネルロードマップ
  • 名古屋大学 組込みシステム研究センター(NCES)
    • 設立目的： 組込みシステム分野の技術と人材に対する産業界からの要求にこたえるために、組込みシステム技術に関する研究・教育の拠点を名古屋大学に形成
    • 活動領域(スコープ)
    • NCESの組織

【Q&A】

• （ソフトウェア部品の先行開発について） ソフトウェア部品を先行開発するのは良いアイデア。 OSは競争力はあると思うが、ミドルウェアに競争力があるとは思えない。 競争力のあるミドルウェアを開発できる人材を育成するにはどうしたら良いか？
  • OS、ミドルウェアは汎用化が重要、100％のお客様には対応できないが、 90％のお客様に対応できるような開発をしなければならない。 日本では不得意な領域である。OSは過去の積み重ねでそうなってきている。 ミドルウェアも粘り強く開発し続けることが必要で、人材育成もそれに合わせて粘り強くやっていくことだと思う。
• （組込みLinuxについて） 携帯電話やデジタル家電ではITRONから組み込みLinux が 使われるようになってきているが、それはなぜか？
  • そのような状況を「ITRON卒業現象」と呼んでいる。ITRONは高い信頼性やリア ルタイム性が必要とされる組み込みシステム向けの用途に作ったOS仕様であっ て、携帯電話やデジタル家電は、よりPCのような領域に移ってきているので、 ITRONの技術特性と合わなくなってきているからである。ITRONをそういう方向 に拡張しようという試みとして、T-Kernelがある。

3. 組み込み分野へのソフトウェアエンジニアリングの活用法

• 初めに組込みシステム開発の現状の問題点が指摘され、その解決策として、 ソフトウェアエンジニアリングの活用戦略が紹介された。 そして、開発工程を大きく遅らせかねない「要求仕様の変更」への対応、 ソフトウェアエンジニアリング手法導入の考え方が紹介された。

• 組込みシステム開発の現状
  • プロジェクトの人数規模：人数が20〜30人を超えると全体の把握が難しくなる
  • 開発規模：規模が大きくなるほど隅々まで目がとどかなくなる
  • 不具合発見工程別の修正工数：上流フェーズ起因の後戻り作業が開発全体の足を引っ張っている
  • プロジェクトの開発計画に対する結果：結果的に開発の遅れが頻発
  • ソフトウェア開発の遅延の仕組み
    • 急激な増大・肥大化に開発手法が追いついていない
    • ソフトウェアエンジニアリングを活用したシステマティックな開発へ
• ソフトウェアエンジニアリングの活用戦略
  • プロジェクトの人数規模：人数が20〜30人を超えると全体の把握が難しくなる
  • ソフトウェアエンジニアリング：高品質なソフトウェアを効率的に開発するための技術
  • どの技術をどのように活用するかが大きなポイント
  • エンジニアリング手法導入のステップ
    • Step-1： プロジェクト/組織の特性把握
    • Step-2： プロジェクトの状況の可視化
    • Step-3： プロジェクト状況の診断と適切な治療の実施
  • Step-1： プロジェクト/組織の特性の把握
    • 個々のプロジェクト,組織はそれぞれ固有の特性を持つ
    • プロジェクト/組織の特性を明らかにする必要性
    • システム特性の把握
      • 求められる信頼性レベルに応じた開発方法の検討が必要
    • 開発ビューから見たシステム特性
      • 様々なビューから開発の特性を把握する
      • 対象システムの実装上の特性
      • 組織・プロジェクトの特性
      • ビジネス面の特性
  • Step-2： プロジェクトの状況の可視化
    • プロジェクトの状況を可視化し開発のどの部分に問題があるかを把握する
    • 現象の可視化： 実際の開発の状況を可視化
    • 原因の可視化： 開発技術面、開発管理/プロジェクト管理面、人材・スキル面
    • 進捗遅れから読み取れる遅延要因
  • Step-3： プロジェクト状況の診断と適切な治療の実施
    • プロジェクトの不調は複合的な原因による結果
    • 主たる要因の把握
    • 解決可能な原因と解決不可能な原因の区別
    • 解決すべき要因の優先度付け
    • 最も効果的な手法・ツールを選択
• 要求仕様の変更への対応
  • 要求定義の段階で全ての要求を決めているか？
    • 決めない： 本来決められるところがあるのに決めていない（意思決定の問題）
    • 決めたつもりが： 決められたつもりが、実は曖昧なところが多く残っていた
    • 決められない： 特別な事情により決めることができない部分がある（仕様変更を予想した開発プロセスで対処）
    • 決めたが変わった：いったん決めたものの事情により変更が生じた（仕様変更を予想した開発プロセスで対処)
  • 曖昧な要求仕様による開発への影響
    • 顧客要求の把握不十分
    • 要求の不確定性
    • 不適切な要求に基づくソフトウェア設計・実装
    • システム不具合
    • 要求不備に伴う後戻り作業
  • 要求仕様定義フェーズの問題
    • 仕様分析の不完全性
    • 仕様記述の不完全性
  • 仕様分析の不完全性
    • 仕様の曖昧性： 決めたつもりが実は決まっていない、仕様の行間が埋まっていない
    • 仕様の暗黙の了解事項： ｢自明なこと｣は技術者により異なる
    • システム利用者像の特定
      • システムの典型的な利用者像(ペルソナ)を検討
    • システムの利用コンテキスト
      • システムの動作環境条件：どこまでを想定するか
    • 機能要求 vs 非機能要求
      • ｢機能的要求｣は当たり前
      • どこまで｢非機能的要求｣を事前に抽出できるかがポイント
  • 仕様記述の不完全性
    • システム/プロジェクト特性と仕様表現と確認手法の選択
    • 仕様の表現形
      • Semi Formal： 要求仕様書テンプレート
      • Formal Specification： UML他のモデリング技法
  • システム全体像の把握
    • システム全体を見通して如何に矛盾のない“形“を作り上げるか
      • システムの性能＆信頼性側面から
      • 再利用性・移植性側面から
    • 機能ユニットの整理と優先順位付け
    • 並行動作整理 ＆ エラーハンドリング
  • Formal Specification： 組込みシステムのモデリング
    • ソフトウェアのモデリング
    • ハード ＆ ソフト ＆ 外部環境の接点を明確化
    • 信頼性/安全性を実現する信頼性保証手法の導入
  • モデリング手法の課題
    • モデルの記述能力
      • リアルタイム性/リアクティブ性
      • ハードウェア依存要素
      • 外部環境要因の表現
    • 利用者側の課題
      • 設計スキル（抽象化する能力）
  • Model Checkingの適用事例、適用結果
  • Model Checking 適用に関する考慮点
• エンジニアリング手法導入の考え方
  • ソフトウェアエンジニアリング手法
    • 様々なものが出回っている
    • 効果が立証されていないものも少なくない
    • 手法の利用者(開発技術者)は忙しく、保守的
    • どのような“治療“を目指すかの戦略が必要
      • 外科手術
      • 投薬治療・・・西洋医学 vs. 東洋医学
  • エンジニアリング手法導入のステップ
    • Step-1： 他ドメインや類似ドメインでの手法・ツールの効果を定量的に見せる
    • Step-2： 自部門の過去の製品などを対象にサンプル適用する
    • Step-3： 自部門の開発の中で適用する(並行適用)
    • Step-4： 自部門の開発の中で本格適用する
    • Point-1： 投資対効果を考慮。ロングスパンでの計画的導入が必須
    • Point-2： 技術導入計画を実行する人材(技術者、マネージャ)の育成が前提

【Q&A】

• (ソフトウェア・エンジニアリングの投資対効果について) エンジニアリングができていないと投資対効果が計れないのでは？
  • 投資対効果を計るには現状の開発をきちんと計っていくことが必要だが、 メトリックスはあるが計り方が定まっていない。 SECでも議論していて、計り方を 一意に決めようとしている。今年の秋に最初のバージョンの仕組みが発表できる。
• (エンジニアリング手法の導入について) エンジニアリングの手法を企業に導入していく際に、どういう人が引っ張っていけばよいか？
  • 導入するための部門を作るのが一つの方法だが、現場に入り込んでやっていく必要がある。 外部のコンサルを使うのも一つの方法だが、社内の具体的の事情をどこまで把握するかは難しい。 前者のように社内で育てて行くのが良いと思う。

4. モデル駆動型開発の導入による生産性向上の事例

• 講師が所属する松下電器産業(株) [※1] パナソニックAVCネットワークス(PAVC)社におけるソフトウェア開発力強化の取組みのポイントが紹介され、エンジニアリング領域強化による生産性向上の取組みの一つとして、モデル駆動型開発(MDD：Model Driven Development)の導入の事例とその効果について、具体的に紹介された。
  ※1： 2008年10月1日付けで、パナソニック(株)に社名変更。

• 松下電器PAVC社の事業領域と事業戦略
• AV機器向け組込みソフト開発を取り巻く環境変化
  • ソフトウェア開発の重要性が10〜20年で急激に高まる
  • グローバルでの急激な価格下落への対応
    • グローバル多機種展開・グローバル同時立上げの事業戦略
    • ソフトウェア開発へのプレッシャーが増大
• PAVC社のソフトウェア開発の特徴
  • PAVC社商品のソフトウェア規模は数千〜数百万行と幅広く開発形態も多様
  • 機器のデジタル化・ネットワーク化に伴い、ソフトウェア規模は増加傾向
• グローバル機種増への対応
  • デジタルTV、DVD、SD関連機器を中心に機種数が増大
  • 世界同時垂直立上げに伴う機種開発の同時化
  • 機器の多機能化・ネットワーク化に伴う検証項目数の急増
• 松下電器・PAVC社ソフトウェア開発力強化の取組み
  • 組織横断のソフトウェアプロセス改善
  • プラットフォーム型開発
  • 検証体制の強化
  • エンジニアリング領域強化による生産性向上
    • モデル駆動型開発(MDD)の試行導入（2005年より）
    • 静的コード解析などのツール活用促進
• モデル駆動型開発(MDD)の導入事例
  • モデル駆動型開発手法導入の背景
    • グローバル機種展開の拡大、開発リードタイム短縮に向けて更なる効率化が必要
    • ソフトウェア再利用率が高レベルになってきた現状を踏まえ、効率化に向けた新たな開発方法論・手法の導入が必要
  • モデル駆動型開発概要
    • ツールを用い、モデル(図)で構造設計・動作設計を行い、モデルで動作検証まで実施
    • モデルからプログラムコードを自動生成し、そのまま実機のソフトとして利用 (手作業の排除)
  • MDDツール Rational Rose Realtime概要
  • モデル駆動型開発手法導入 サマリ
    • 検証フェーズ： 検証プロジェクトを立ち上げ、手法の有効性を検証。その結果、手法の有効性を確認、商品開発への導入を決定
    • 導入フェーズ： 事業場メンバーによる商品開発への手法導入。その結果、ソフト日程遅れ無しで無事商品化を完了
  • 検証プロジェクトと商品開発プロジェクトとの関係
    • PAVC社商品開発と並行して、検証プロジェクトにて同じ商品のソフトウェア開発をモデル駆動型開発手法にて実施
  • MDDプロジェクトのソフトウェアアーキテクチャ
    • 商品ソフトウェアを分析し、アーキテクチャの再設計を実施
    • MDDプロジェクトがモデル駆動型開発で開発したのはソフトウェア全体の約50％
  • 検証フェーズでの評価結果
    • モデル駆動型開発導入により開発効率向上の効果(見込)を確認
    • 懸念されていたHWリソース・性能への影響が小さいことを確認
    • 次年度商品開発への｢モデル駆動型開発手法｣導入を決定
  • 導入フェーズ： 商品開発プロジェクトへの手法導入
    • 課題： 商品開発へ手法導入にあたってのリスク
      • ウォーターフォール的プロセスの採用への不安
      • 細かい商品仕様のノウハウに関わるモジュールのモデル化の労力
      • 特定のモジュールの巨大化・複雑化
    • 取組み： 上記課題に対して、以下の3点の対策を実施
      • インクリメンタル型開発プロセスの導入
      • 実績のあるC言語資産の有効活用
      • 製品動作仕様の再分析と基本アーキテクチャの変更
  • 導入フェーズ：評価結果
    • ほぼ検証プロジェクトと同等の結果が得られた
    • 本製品のソフトウェア開発では、今後もモデル駆動型開発を継続しさらなる効率化を目指す
• 考察： モデル駆動型開発の効果
  • トップダウン設計が強制される＝｢いきなりコーディング｣が出来ない
    • 付け焼刃的対応が難しく、必ず設計段階に立戻る必要がある
  • ソフトウェア構成が整理される
    • 全体構造(アーキテクチャ)設計の方針を誤ると、実装が複雑化する
  • 開発者間での設計レビューが容易になる
    • ｢レビューしやすい図｣を書くための｢設計・表記ルール｣の徹底が重要
  • ツール上でモデルベースのデバッグが可能(実機レス)
• まとめ： モデル駆動型開発は有効な手法であるが・・・
  • モデル駆動型開発を使えば、何でも誰でも効率化が出来るというわけではない
    • MDDは有効なツールだが、重要なのはやはり 『良い設計』と『良いプロセス』
    • モデリングと商品アーキテクチャの両面に精通した人が必要(＝アーキテクト)
    • 自動コード生成によるコーディング作業省力化、設計と実装の同期は効果有り
  • プラットフォーム化が既に進んでいるときなどは投資効果の事前検証が重要
    • 導入オーバーヘッド(教育・ツール投資・既存ソフトの置換え)と導入リスク
    • トップダウンでの方針／段階的な導入計画・目論見が無いと、なかなか導入は難しい
  • 一気に全体をモデル駆動型開発に移行するのは難しい
    • 現状課題の解決に向け出来るところから少しずつ導入し、アーキテクチャ改良のサイクルを廻す
  • 狼人間を倒す銀の弾丸など無い

【Q&A】

• (ソフトの再利用とモデル駆動開発の関係について) ソフトの再利用とモデル駆動開発の共存はどうなっているか？
  • 既存のミドルウェアには多くのノウハウがたくさん入っている。今回はそのミドルウェアを活かして、 変動の多いアプリケーションをモデル駆動で開発した。 そうできるようにミドルウェアも整理したのでシステム全体としても良くなったと実感している。
• (開発者のスキルについて) モデリングと商品アーキテキチャに通じた人が必要なのでは？
  • 商品に精通した人は必ずいる。モデリングについては1ヶ月のトレーニングをした。 モデルについてはRationalのノウハウを頂いた。 モデリングの際に商品アーキテクチャのわかる人と上手くコミュニケーションして進めることができた。

5. 組込み製品のテスト効率化・合理化への取組み

• ｢組込み系｣の多様性と難しさの指摘に続いて、テストプロセスの課題と改善への提案が述べられた。そして、講師が所属する日立グループでの取組み事例として、組合せ条件テストでのPair-Wise法の活用が紹介され、最後に、テスト技術の最新動向と今後の方向性についてのまとめが述べられた。

• 背景 〜 “組込み系”の多様性と難しさ
  • 我々のミッション：組込みソフト開発の課題の解決
    • ソフトウェア開発視点での解決(プロセス改善、開発環境改善、品質マネージメント、教育など)
    • ソフトウェア要素視点での解決(ＯＳやミドルウェアの開発・利用、ソフト設計技法、再利用技法)
    • ソフトウェア工学の成果をソフトウェア開発の現場へ
  • 日立グループにおける“組込み系”とは？
    • 幅広い事業フィールドと製品
  • 例えば、｢情報系組込みシステム｣の例をとってみても･･･
    • 車載端末、A/V機器、携帯電話、医療機器
  • 改めて、｢組込み系ソフト｣開発の課題とは？
    • そもそも『組込みソフト』のくくりに意味があるのか？
    • 『組込みソフトの課題』とされてきたことが本当に問題か？
    • 共通的な課題を解決すれば良いのか？
      • 共通課題の解決そのものは重要
      • しかし、固有の課題こそが解決したい難しい課題
        ⇒テスト・検証技術がその代表例
• テストプロセスの課題と、改善への提案
  • ｢テスト・検証プロセス｣の実情
    • テスト･検証に関して実施すべき活動内容は、共通に理解されているか？
  • 従来のプロセスモデル： V字モデル
• 近年のプロセスモデル： W字プロセス(タイプ�T)
  • ｢テスト設計の上流化｣を指向
• 近年のプロセスモデル： W字プロセス(タイプ�U)
  • ｢開発プロセスの各活動の検証｣を指向
• 提案モデル(その1)： V3モデル
  • 設計構築・テスト・活動検証の各プロセスを融合
    • (V1) 設計構築プロセス
    • (V2) テストプロセス
    • (V3) 検証プロセス
• 提案モデル(その2)： ∀モデル
  • 従来のテスト工程軸に加え、テスト手順軸が重要
• テスト指向開発プロセス
  • テストの改善が、全ての改善への道
    • IEEE829 “Standard for Software Test Documentation”

【Q&A】

• (スライド中の記号について) スライド13ページ「2.6提案モデル(その2)：∀モデル」の∀の意味は、何と呼んでいるのか？
  • 数学的にはFor all、全てに対してという意味。テストと言っても、これだけたくさんのテストをしなければならないということを意味している。なので、For allモデルと呼ぶ。 （補足：∀は全称記号 Allzeichen という記号で ∀x という形で｢総ての x について｣とか、｢任意の x について｣と読まれる。∀x を全称作用素 universal quantifier という。∀xF(x) とは、｢総ての x について F(x) が成り立つ｣ということを意味している。）
• (テストとその活動の検証について) スライド12ページ「2.6提案モデル(その1)：V3モデル」で各々のテストについて活動の検証という機能が示されているが、どういう視点で、どういう立場の人がやるのか？
  • 基本的にはSEPGが関わるのが適切。理想的にはV1、V2、V3の三つの活動は独立し連携した別々の人が違う観点で行うことで品質が確保されると考える。実際には人的コストや体制の問題などで３つの独立した機関でやることは厳しいかもしれない。しかし、3つの別の活動があるということを意識することによって、同じ人がやっても、観点を変えていくことで品質が確保されると考える。