********************************************************************** チュートリアル S2-b テーマ：プロダクトラインへの道のり ?実践するためのキーポイント講師：安部田章(九州日立マクセル) 宇佐見雅紀(イーソル) 佐藤洋介(デンソー) 山崎進(北九州カーエレセンター) 吉村健太郎(日立研究所) ********************************************************************** 1st Presenter 山崎進(北九州カーエレセンター) 題目:プロダクトライン概論 ◎組み込みシステム開発の現状組み込みシステムの大規模化・複雑化・バリエーション化傾向 ↓ 既存資産を生かした開発へ ◎プロダクトライン（PL）とは何？・特定のニーズを満たす共通特徴を有する製品系列・SPLE(Software Product Line Engineering)を指すことも (プロダクトライン開発方法論) ◎SEIが定める基本活動（３つの歯車) コア資産開発：基本コンポーネントを開発する製品開発：コア資産をいかに利用するか？管理： ◎サブテーマの紹介と、本チュートリアルの進め方の紹介 PLの入力 (コア資産となる前の)既存資産(吉村さん) プロダクトラインへの移行戦略と、投資効果について既存資産(PL前)のPLへの移行マーケティング(安部田さん) アーキテクチャが実現すべき相違性の範囲のスコープ設定 PLの出力製品(品質保証、運用=佐藤さん) PL以外の一般的な品質、運用の重要性 PLならではの品質確保、運用について PLの入力and出力コア資産(アーキテクチャ=宇佐美さん) コンポーネントの共通化製品ごとの相違性 ◎PL概論スタート・プラクティスパターンとは？ PLを支える具体的な活動を分類し、パターン化したもの・「統合運営パターン」(プラクティスパターン中の一つ）製品、プロセス、組織にまたがったプロダクトラインの総合的なパターン　　（プラクティスパターンの集合) ・「統合運営パターン」を用いて、他のパターンの位置づけを行う。詳細は「組み込みプレスvol 4」にて紹介されている。・プラクティスエリアとは？プラクティスパターンに所属する29種類のエリア既存資産移行、マーケティング、アーキテクチャ、品質保証・運用を考慮 2nd Presenter 吉村健太郎(日立研究所) 題目：既存資産の移行 ◎SPLE移行フレームワークの大まかな紹介 ROIの推定移行戦略の決定既存資産のSPLE移行 ◎SPLE(Software Product Line Engineering)とは？大規模・多品種のソフトウェア開発戦略の一つソフトウェア構成(アーキテクチャ)を生かした製品開発ソフトウェア部品群を選択して開発 ◎SPLEの効果についての現状怪しいイメージ（効果あるの？）今ある資産は捨てちゃうの？ ◎投資効果の推定・製品系列を差分開発とSPLE型開発のコストを比較コア資産の開発コスト部品開発（非コア資産)コスト教育コストなど ↓ ・投資回収時期を推定 ↓ ・経営層の説得 IEEE Softwareの資料を元に差分開発とSPLE型開発コストの比較資料を公開 SPLEが常に有利なわけではない製品系列の開発間隔に関係する可能性もある ◎代表的な移行戦略・戦略の種別ビッグバン戦略：全て一からSPLE移行（現行のリソースを破棄？）段階以降戦略：一部のみ選択してSPLE移行スタート選考開発戦略：試作品開発時SPLE導入前線型戦略：前線のエンジニアによる導入(現場でこっそり導入) ・戦略の選択基準ファクタ現行との共存総投資額初期ハードルの高さ移行期間リスク軽減各ファクタに応じて戦略を選択する ◎既存資産のSPLEへの移行法移行プロセス 1.既存構造の抽出 2,構造のSPLE型変換 3,構造変換したものを、既存資産の実装変換へブレークダウン 4.既存資産のSPLE化既存ソフトウェアのSPL化ソースコードの類似性に基づく共通性・可変性分析手法吉村さんの論文に詳細は記載 (プロダクトライン導入に向けたレガシーソフトウェアの共通性・可変性分析法, 情報処理学会論文誌 Vol 48, No.8, 2007) 3rd Presenter 安部田章(九州HITACHIマクセル) 題目：QFDを応用した要求分析に基づくコア資産戦略 ◎マーケティングとは？・定義は？正確な定義はない AMA(アメリカマーケティング協会)による定義がある・マーケティングをどうすればいいのか？「利益を上げるために効率的に売れる仕組みを考え、実行する」市場分析、需要の創出開発、生産業務の効率化社会に反しないこと(CSR:Corporate Social Responsibility) ・マーケティグの位置づけの変遷顧客を中心としたマーケティングへ傾きつつある・結局マーケティングとは？考え方であり、プロセスであり、戦略である ↓ 結局プロダクトラインエンジニアリングも同じである。企業経営のプロセスにおける重点の違い ◎企業経営・ビジネスプロセス：技術開発、商品企画、製品開発、調達、生産、営業・販売、顧客サポート・経営的視点：費用対効果に関心が偏る(売れる商品企画) ・マーケティング：売れる仕組みを考えること(4P,Product, Price, Promotion, 流通) ・製品開発：商品企画、技術開発、製品設計、生産設計、品質保証・プロダクトライン：製品開発を中心に製品開発の効率化 ↓ マーケティングと密接な関係 ◎QFDとは？・顧客と設計者を結びつける手法（実際に使われている手法) ・製品に特性を確実に結びつけるための方法論・品質表を用いた手法・品質顧客の声としての要求品質技術的特性（設計品質) ・品質表要求品質と設計品質の対応表設計のインプットとして役立てる・事例紹介例：要求品質（縦軸)：早く沸く設計品質：沸騰時間、加熱力、熱変換効果 ◎プロセス管理ツールとしてのQFD ・品質機能展開の指針(JIS Q 9825 2003) ・QMS(Quality Management System)のプロセス管理としてのQFD活用・プロダクトラインのプロセス管理ツールとしてQFDを活用できないか？ ◎プロダクトラインとQFD ・プロダクトラインのプロセスをサポートするためにQFDが使えないか？プロダクトラインの課題コア資産の特定 -設計状況の見える化が課題 -市場要求を分析し、市場競争力の向上という観点から判断共通性と可変性の管理が必要 ↓ QFDが使えないか？なぜ? 2元表により市場要求を設計、実装、検証工程へ伝えることができる相互関連を明示することができる How? 技術戦略の策定市場分析により機能要件、技術課題の抽出開発プロセスの改善システム品質表によるハードウェアとソフトウェアの協調開発支援顧客の品質要求を確実に組み込むコスト設計の支援コスト展開により目標をコストを設定し、コスト課題の導出コア資産戦略の策定顧客要求から、企画品質を設定し、重要品質を抽出する顧客重要度、実現難易度、変動性分析からコア資産戦略の策定 4th Presenter 宇佐美雅紀(イーソル) 題目：プロダクトラインへの道のり(アーキテクチャ編) ◎アーキテクチャとは？ Q.組織内にアーキテクトがいますか？(To質問) いる=１人→何をしていますか？→ソフトウェアの戦略を考えています。 Q.アーキテクチャが分かってる人(To会場) 分かっている=0人 Q.じゃ、アーキテクチャとは何ですか？実は、コンセンサスがとれている定義はない (定義は、いろいろな人がしていますが決定版がない) SEIは定義を集めている(百個以上定義があるらしい・・・) ◎本チュートリアルでのアーキテクチャ定義・品質属性に決定的な影響を与えるソフトウェア構造 ◎アーキテクチャのうれしさ・アーキテクチャは品質属性に決定的な影響を与える・品質属性とは？可用性、変更容易性など(非機能要求 ISO/IEC 9126) ・アーキテクチャは機能属性に直交しているどういうこと？アーキテクチャがめちゃくちゃでもとりあえず動く ↓ 機能的には問題なし ◎品質属性をアーキテクチャで実現する・パターンの活用(Architecture Pattern) 例：レイヤパターン：変更容易性の向上・パターンを使うことによるリスク（メリットとのトレードオフ）例：レイヤの乱用→パフォーマンスリスクの上昇・機能に置き換えられる品質もある(置き換えられない品質もある)(QFD参照) ・アーキテクチャ駆動開発(ADD) ◎アーキテクチャを評価する・作ったアーキテクチャを評価した人いますか？(To会場) いる＝0人・実は評価手法があります例：ATAM,ARID:軽量評価手法,ADLも評価に使える ◎アーキテクチャの特性を定義する・非機能要求定義の難しさ性能って何ですか？→結局よくわからない・ではどうすればいいのか？特性を詳細に定義するシナリオの記述時間的な経過を記述する（アーキテクチャ評価に対して有効) ◎アーキテクチャとSPL ・アーキテクチャはSPLEの命である！・再利用性を上げるためのアーキテクチャは必要である・プロダクトラインアーキテクチャは、複数製品を考慮する必要がある。アーキテクチャの可変性分析・管理 ◎可変性管理フィーチャ分析が使える製品系列を特徴づけるものとして、通常フィーチャがよく使われる対象ドメインにおける専門家やエンドユーザの語彙に相当する 5th Presenter 佐藤洋介(DENSO) 題目：運用・品質保証編 ◎イントロダクション製品の管理ビジネスのコンテキストはどこか？ ◎現状と課題・現状組み込み開発の中心はソフトウェアである大規模化・複雑化傾向にある・課題大規模・複雑化するソフトウェアの管理・開発・保守複雑化によって混入する不具合の除去＆品質の維持・向上品質は製品価値に直結 ◎事例を用いた連続的製品開発の説明製品仕様競争が激化売れる商品の企画マーケティング関心事のギャップ頭出し開発：機能優先展開開発：保守優先（短納期で開発) ◎課題解決への方向標準化戦略・アーキテクチャの標準化 AUTOSAR VFB(Virtual Functional Bus) できる限り前工程で企画を行うコンセプト非競争領域の共通化コンポーネントの運用先行開発・量産開発どういうコンポーネントを載せればいいのか？どういうコンポーネントを蓄積するか？どうやってコンポーネントを取り出すか？ Jaspar スーパーエンジニアが持つノウハウの標準化/共有 ◎実践のためのキーポイント・量産開発の課題要件仕様のトレーサビリティインテグ時の品質保証・先行開発の課題アーキテクトの育成再利用資産開発・保守のドキュメント・課題を正しく認識しなければならない ◎ADL(SysML) UMLでは弱かったメカエレキをモデリング可能ハードウェア、ソフトウェアにまたがった分析 ◎機能安全の本質インテグ時の品質保証アーキテクチャのトレーサビリティはとれていますか？ ◎形式手法とは数理的な考え方を用いて記述し、検証を行う手法最近事例が増えており、流行ってきた分類(流派) モデル指向型代数仕様型時相論理型平行プロセス型 ↑ それぞれ特徴があり、適切に選択しなければならない書籍：実践アーキテクチャ RAS(OMGが提供するデータベース) 質疑応答： Q.全てのコンポーネントがタイムトリガに対応することはできるのか？ A.検討中だと思います Q.ソフトの機能安全をコンポーネントに分離することは可能なのか？ A.システムアーキテクチャを正しく設計することが重要です。