講演の様子

講演

1. ソフトウェア事業基盤専門委員会2006年度活動報告
2. Trends in Embedded Software Development in Europe
3. Product Line Software Engineering in Europe - Fundamental Concepts and Case Study
4. 組込み系ソフトウェア開発現場におけるプロセス改善
5. 組込み系ソフトウェアの様々な開発現場における共通課題と技術施策を中心とした解決事例

1. ソフトウェア事業基盤専門委員会2006年度活動報告：
      組込み系ソフトウェア開発の課題分析と提言

• 組込み系ソフトウェア開発における品質施策および品質確保のための開発プロセスについて の調査結果の分析および課題解決に向けた提言。 ソフトウェア事業基盤専門委員会の 2006年度報告書 の要点を紹介したものである。

• 品質施策への提言
  • コストと効果を考慮した品質対策要
    • 費用対効果
    • 「品質とは何か」というゴールを設定した上での効果検証
  • 上流工程へシフトすべき
    • 品質対策はより効果の大きい上流工程へとシフト
    • 品質の定量化と計測・分析
  • 多機種開発への適用
    • 複数の派生製品開発を前提として、水平展開可能なツール整備
  • 品質関連標準化の共有
    • 品質に関する手法・ツールは外部委託先と共有
• 開発プロセスに対する提言
  • 大規模化に対応する開発プロセスの事例収集・展開
    • 88%のプロジェクトでソフトウェア規模は増加
    • 実践的な大規模化・再利用性向上の事例収集が必要
  • 多機種開発を考慮した開発プロセスの研究取組み
    • アーキテクチャ指向、ソフトウェアプロダクトライン等
  • アーキテクト育成が急務
    • 役割明確化と育成プログラム整備によって、戦略的に養成すべき

2. Trends in Embedded Software Development in Europe

• 欧州における組込み系ソフトウェア開発の技術的トレンドに関して、システム工学、 ソフトウェアアーキテクチャとシステムアーキテクチャ、分散開発、モデル駆動開発、 オープンソースソフトウェア、品質工学、プロダクトライン工学について、 それらの状況が紹介された。

• 欧州においてもソフトウェア開発は年々困難になっている。主な原因は次のようなものである。
  • プロジェクト管理が役に立たないか、または無い
  • 開発プロセスが定義されず、計画・予測ができない
  • 仕様が曖昧、ソフトウェア構造が無い、標準化されない開発手順
    ⇒ システム工学アプローチの導入が必要不可欠である。
• 「アーキテクチャ」が中心的な役割を演じる。
  • 「問題空間＝ビジネス」と「解空間＝ソフトウェア工学」の分離と橋渡し役
  • プロジェクト計画・管理、コンポーネント構成、品質、構成管理を局所化
• アーキテクチャ定義プロセス
  • 計画→実現→文書化→評価→(最初に戻る)
  • 計画時の視点：ビジネスゴール、機能要件、品質目標
  • 評価は上記視点に基づいて実施
• アーキテクチャ型開発(プロダクトライン)を実現する要件
  • コンポーネント指向開発
  • モデル駆動型開発
  • 可変性管理
• 組込み系ソフトウェア開発のツボ
  • 品質保証：ソフトウェア工学技術で対応
  • 開発効率：プロダクトライン型開発で対応(ロードマップ指向)

【Q&A】

• なぜアーキテクチャ型開発でモデル駆動型開発(MDD)が必要なのか?
  • 抽象化のため。ソースコードではアーキテクチャを記述できない。 モデル化は機械語→アセンブラ→Cという抽象化の流れの延長線。
• アーキテクチャが不確定だとどうなるのか? どのようにソフトウェアプロダクトライン(SPL)に移行するのか?
  • アーキテクチャが無いと、非機能要件を局所化出来ない。 そのため、品質要件を 満足しているかどうかが不確定になる。 SPLへの移行は、アーキテクチャ中心で行うべき。コード中心では失敗する。

3. Product Line Software Engineering in Europe - Fundamental Concepts and Case Study

• ソフトウェアプロダクトライン(SPL)の基本的な考え方と欧州の実際のプロジェクトでの実施例が紹介された。

• 実施例：
  • 社名：Testo AG
  • 製品分野：気象測定器、排ガス測定器
  • ソフトウェア規模：C言語で100〜600 K SLOC(Source Lines Of Code)
  • 年表：
    • 2002： スコーピング
    • 2003： アーキテクチャ開発(実装の40%をカバー)
    • 2004： SPLに基づく初製品(3機種)を開発
    • 2005： コア資産のアップデート
    • 2006： 7機種を新たに開発
    • 2007： 効果測定中…
    • 2009： SPL基盤の第2世代化
• アーキテクチャ検証ツールの適用： SAVE (Software Architecture Visualization and Evaluation)
  • アーキテクチャ設計と、実際のコンポーネント間接続関係とを可視化し検証。 設計に違反している箇所を発見する。
  • EclipseのPlug-inとしてFraunhofer IESEが開発。

【Q&A】

• スコーピングとアーキテクチャ定義に2年もかかるものなのか?
  • アーキテクチャの将来予測・分析は工数大。 また、製品開発と並行しての活動なので リソースが十分ではなかったのも一因。
• SPL導入による定量的な効果は?
  • 企業側の意向で数値は公開できないが、定性的には開発期間短期化、テスト性向上の効果が出た。
• フィーチャモデリングの説明が無かったが、使っていないのか?
  • 当然使っている。スコーピングに活用。

4. 組込み系ソフトウェア開発現場におけるプロセス改善

• セイコーエプソン(株)の開発現場における品質向上・生産性向上を図る プロセス改善施策と今後の課題が紹介された。

• 対象システム
  • 業務用プリンタのファームウェア(レシート、ラベル等)
  • 特徴：顧客別の派生製品開発、ハードウェア依存
• 知識・技術の導入
  • 自前技術への固執からの脱皮→外部の優れた技術に触れる
• 取得→練習→実践で定着を目指す
  • 取得： 外部講師を招いてのセミナー(２年間で延べ600名に講習実施)
  • 練習・実践： 実プロジェクトを対象にして、新技術の練習・実践
  • 対象者は実力者を選抜し、トップ判断で実施(現場は抵抗)
• プロセスの設計
  • 個人スキル依存からの脱却
  • 優秀なリーダの暗黙知から形式知へ
• 要求の仕様化
  • 曖昧性の排除
  • 要求仕様と設計仕様を対応付けて、設計漏れを検証
• 計測
  • 結果のよしあしを判断できるように→自分の実績を数値で残す
• 改善の継続
  • データを基にした改善： 設計→計測→見直し
  • 改善の仕組み自体も改善対象

5. 組込み系ソフトウェアの様々な開発現場における共通課題と技術施策を中心とした解決事例

• 沖グループ内外の複数の組込み系開発プロジェクトにおいて経験された類似の課題、 その課題に対する共通的な技術的施策、組込み系固有の施策、非組込み系との共通施策 などが紹介された。

• 組込み系の課題の特徴
  • 属人的、非標準、職人文化
  • 機種依存、小メモリ、実機テストの高コスト
• 現場主導でのツール、ガイドラインの導入
  • 情報展開が重要
  • 良い運用方法とツールが必要
• 少数のコストパフォーマンスの良いツールを厳選
  • 初期コストと運用コストを意識して導入
  • 効果がないツール適用は止める勇気が必要
• プロジェクト、製品の目的にあったツールを導入
  • ツールありきではうまくいかない
  • ツールの品揃えは必要
• メカ、エレキ、ソフトの橋渡しが出来るアーキテクトを育成
  • 現場部門に応じた教育、育成
  • 育成コースや教育の品揃えは必要
• ツール導入の失敗事例
  • 効果に見合わないコストを掛けるツール適用