秩序あるプロダクトラインの持続的な進化と保守 を支援するバリアント管理ツール pure::variants と IBM 社製開発ツール Maintain and sustain a product line over time to not stay in the chaos with pure::variants - Variant Management & IBM tool Danilo Beuche / Robert Hellebrand
Introduction Product Line Engineering (PLE) は 再利用資産を運用するための技術的な取り組みであり 継続的に変化する市場要求や技術革新と それに伴う製品 ( バリアント ) の進化に柔軟に応じることのできる 開発プロセスや手法を伴う全体的なアプローチです
プロダクトラインの例 : シンプルで似ているが違いも多い 見た目は右ハンドル車の違いくらい でも中身の違いや その詳細はわからない 要件からテストに至る様々な成果物に多大な影響を与えているかも
Product Line Engineering Variation Dimensions Technical Dimension その理由は 同時に対応すべき 2 つの方向があるからです 技術的な側面で 一番上の製品は右ハンドルで 下の 3 つは同様に見えるが違いもある ただこの段階ではテクニカルなバリエーションのみ
Product Line Engineering Variation Dimensions Technical Dimension これら製品はそれぞれ時間をかけて開発されて進化する 最初からこうなることを予測できない 備えはいるが どうなるか将来はわからない 継続的に変化する市場要求や技術革新 それに対応する製品 ( バリアント ) の進化を支えるプロセスやツール無しではバリエーションの適正な管理はできません 時間的な変化には IBM の Continuous Engineering テクニカルな側面は DOORS Rhapsody や それに連携されるバリアント管理ツール pure::variants があります Time Dimension
pure-systems
Variant Management Solution for Systems & Software Engineering
pure::variants プロダクトラインライフサイクルをサポート Customer Definition Requirement Definition Model and Simulate Develop Test Deploy Customer Definition Requirement Definition Model and Simulate Develop Test Deploy Integrate engineering tools and management systems throughout lifecycle of product line DOORS 9 DOORS Next Rhapsody Design Manager Rhapsody RTC Rational Quality Manager C/C++/Java medini analyze AUTOSAR EMF MS Word / Excel IBM Jazz Global Configurations, Streams, Change Sets Simulink Reporting あらゆるツールとの連携をサポート
pure-systems Customers Product Domains
Variant Management
Ad-hoc Strategic Variant Management Approaches Independent Platform-based Product Line (90%) Production Line (150%) S Managed Cloning Platform (50%) Configurable Product (150%) S S Clone&Own Reuse Repository S バリアント管理と体系的再利用には様々なアプローチがあります 本日焦点にする右上の 4 つは 再利用資産のカバレッジが異なります プラットフォームは共通部分のみの再利用です これらの取組みは pure::variants のバリアント管理ツールと IBM のような適正なツールとの連携によって支援することができますが 再利用が増えると複雑性が増すことも留意する必要があります
バリアントの数 Variants!= Variants 適正な取り組みを選択するときに 考えるべき多くの側面のひとつはバリアント数対バリアントごとの製品数です 自動車なら顧客要求を満たすために多くのバリアントが必要で その分製品数は多くありません 対して電動ドリルの場合は バリアント数は少ないが沢山出荷されます このようにプロダクトラインに違いがあるので PLE の取組みも様々になるということです バリアントごとの製品数
Selecting The Perfect Solution 以上から どれを選べば良いというパーフェクトな解はありません 様々な要因を考慮に入れて 状況に応じた現実的な取り組みを選択して それをより良く改善することが賢明です
TruckLight Inc.
( 例 ) トラックライト社 : 各トラックメーカに様々なヘッドライトを提供
ヘッドライトの制御 :HW SWなどから構成される
全てが再利用可能 System Requirements System Test System Design System Validation HW/SW Requirements HW/SW Test HW/SW Design HW/SW Integration Test Implementation Unit Test
Reuse of Standard Assets
Building From Standard Assets 比喩として これらの形は似てるが全て同じでは無く でも実は 7 つの部品で作られています
Building From Standard Assets 標準化された資産だけでは再利用は難しい
Building From Standard Assets (Building Blocks) 標準部品の一覧から妥当なブロックを選択して プロジェクト固有の機能を開発する
結果 標準化された資産が増えすぎて こうなってしまうと探すのも大変で 無駄も多くあるはずで 拡張性もない こうならないように 考え方を変える必要があります
Challenge: Variability across the Lifecycle Assets ある自動車メーカの でも一般によくある単純な再利用 各成果物で個別にコピペが繰り返され 体系的な再利用には程遠い こうなると複数バリアント間で同一の問題の修正は困難 またテストは特定の熟練者の経験に頼ることになる
Variable Systems
バリエーションポイント Problem Space/ 問題空間 Solution Space/ 解決空間 問題空間上のロジカルなバリエーションポイントは 解決空間上のテクニカルなそれと結びつき バリエーションの複雑さを軽減してバリアントの決定項目を削減できる
Feature Model System Requirements System Test System Design System Validation HW/SW Requirements HW/SW Design Implementation HW/SW Integration Test Unit Test HW/SW Test フィーチャモデルにプロダクトラインの問題空間のバリエーションを表現して 解決空間上のあらゆる資産と紐付けられる
Feature Model Legend: = Mandatory ( 必須 ) = Optional( 選択自由 ) = Alternative ( どれか一つ ) = Or( 少なくとも一つ )
Feature Model - Dependencies Legend: = Mandatory ( 必須 ) = Optional( 選択自由 ) = Alternative ( どれか一つ ) = Or( 少なくとも一つ )
Feature Model - Attributes Legend: = Mandatory ( 必須 ) = Optional( 選択自由 ) = Alternative ( どれか一つ ) = Or( 少なくとも一つ )
Product Line Engineering & Global Configuration Overview
Global Configuration (Product Line) Requirements Architecture Test Cases Code Feature Model Derive Variant Global Configuration (Variant A) Global Configuration (Variant B) Global Configuration (Variant C) Global Configuration (Variant D) Requirements Architecture Test Cases Requirements Architecture Test Cases Requirements Architecture Test Cases Requirements Architecture Test Cases Code Code Code Code 1 IBM Jazz では全てのソフトウエア資産はストリームに保存されます そしてソフトウエア製品を形成するストリームは グローバル構成に割当てられます そして僅かにでも異なる複数の製品バリアントからなるポートフォリオがあれば 製品バリアントごとのグローバル構成をマニュアルで作成して 保守することになります 2 それに対して pure::variants が有れば ひとつのグローバル構成に プロダクトライン全体の資産のスーパーセットを伴うストリームを持たせることができます 加えて pure::variants のフィーチャモデルもストリーム内に保存することができます 3 そして このグローバル構成のスーパーセットを基にして 各製品のバリアント固有のグローバル構成を pure::variants から生成することができます
Global Configuration (Product Line) External Car Light System Feature Model Role: Product Line Engineer
動画 :Feature Model http://www.fuji-setsu.co.jp/demo/pvibm/pv1featuremodel.wmv
Global Configuration (Product Line) Configuring a new Variant Error Markers and Auto-Resolve Role: Application Engineer
動画 :Add Variant BaseLight_Sweden http://www.fuji-setsu.co.jp/demo/pvibm/pv2variantconfig.wmv
Global Configuration (Product Line) Comparing and Analyzing Variants Variants, Versions & Matrix View Role: Product Line Engineer / Product Line Analyst
動画 :Compare View & Matrix View http://www.fuji-setsu.co.jp/demo/pvibm/pv3comparematrix.wmv
Global Configuration (Product Line) Restricting Superset Requirements DOORS NG Integration Role: Requirements Engineer
動画 :Restricting Superset Requirements http://www.fuji-setsu.co.jp/demo/pvibm/pv4dngrestrict.wmv
Global Configuration (Product Line) Global Configuration (Variant) Deriving Variant-Specific Requirements Transformation Role: Requirements Engineer
動画 :Deriving Variant-Specific Requirements http://www.fuji-setsu.co.jp/demo/pvibm/pv5dngtransform.wmv
Global Configuration (Product Line) Restricting Superset Architecture Rhapsody Integration Role: System Architect
動画 :Restricting UML/SysML Elements http://www.fuji-setsu.co.jp/demo/pvibm/pv6rhapsodyrestrict.wmv
Global Configuration (Product Line) Preview Variant-Specific Architecture Load and Preview Variant Configurations Role: System Architect
動画 :Variant Preview http://www.fuji-setsu.co.jp/demo/pvibm/pv7rhapsodypreview.wmv
Global Configuration (Product Line) Global Configuration (Variant) Deriving Variant-Specific Architecture Transformation Role: System Architect
動画 :Stream Transformation http://www.fuji-setsu.co.jp/demo/pvibm/pv8rhapsodytransform.wmv
BaseLight_Sweden
BaseLight_EMEA
Global Configuration (Product Line) Global Configuration (Variant) Global Configuration Generate Variant-Specific Global Configurations Role: Product Line Engineer / Application Engineer
Global Configuration (Product Line) Requirements Architecture Test Cases Code Feature Model pure::variants transformation Global Configuration (Variant A) Global Configuration (Variant B) Global Configuration (Variant C) Global Configuration (Variant D) Requirements Requirements Requirements Requirements Architecture Architecture Architecture Architecture Test Cases Test Cases Test Cases Test Cases Code Code Code Code
Global Configuration of Product Line
Transformation
Global Configuration of Variant
Global Configuration (Product Line) Global Configuration (Variant) Coevolution of Product Line and Variants Update Variant Role: Product Line Engineer / Application Engineer
IBM DOORS NG Jazz と pure::variants の連携継続的エンジニアリングとバリアント管理の相乗効果 Stream (150%) Stream (150%) Requirements 3 change Requirements DOORS NG と pure::variants の連携例 1 プロダクトライン全体の資産 (150%) から バリアント固有の要求仕様を生成したものがあります 2 もしバリアントへの固有の変更と同じタイミングで 3 プロダクトライン全体への変更が発生した場合 1 Stream (100%) Requirements 2 change Stream (100%) Requirements 4 merge Stream (100%) Requirements 4 双方の変更をマージして プロダクトラインの持続的な進化に応じて バリアント管理が行えます Time
動画 :Coevolution of Product Line and Variants http://www.fuji-setsu.co.jp/demo/pvibm/pv9gc_coevolution.mp4
Variant Management Use Cases
(Automotive) OEM Variant Management Challenges Each Project may have its own way of writing specifications プロジェクトごとに独自のやり方で仕様書が記載される Similar behavior / UI makes for strong brand experience ブランドイメージを強固にする類似した振舞いやUI Least Possible Amount of variability gives biggest economies of scale バリアビリティを最小限にすることによるスケールメリット Continuous Innovation and Variation sells 継続的な革新とバリエーションがセールスポイント Each Project has its own time line プロジェクトごとで納期が定まっている Often requirements and V&V tests and calibration are main focus areas 要求仕様 V&Vテスト キャリブレーションが主な関心領域
Benefits of Using pure::variants Supports full tool chain (Doors, Simulink, Enterprise Architect, standard calibration data formats via extension, custom transformation generates code) 全ての開発ツールをサポートできる Uniform Variability Concept over all asset types 全ての資産に対して共通したバリアビリティのコンセプト Uniform approach across different tools 異なるツールに対して共通した扱い Migration of home-grown approach to COTS tool based approach 自社製の取組みから汎用ツールへの移行をサポート DOORS Variant Matrix Simulink Variability Calibration Tool-independent Calibration Data Reuse controlled via pure::variants Extension
(Automotive) Supplier Variant Management Challenges Each Customer in a Customer Project may have its own way of writing specifications 顧客のプロジェクトごとに独自のやり方で仕様書が記載される Least Possible Amount of variability gives biggest economies of scale バリアビリティを最小限にすることによるスケールメリット Continuous Innovation and Variation sells 継続的な革新とバリエーションがセールスポイント Each Customer Project has its own time line 顧客のプロジェクトごとで納期が定まっている Anything from requirements over code assets to tests and documentation needs to be handled 要求仕様からコード テストやドキュメントなど全てに対処しなければならない
Benefits of Using pure::variants Supports full tool chain (Doors/Doors NG, Enterprise Architect, Rhapsody, Custom Tools via API, RQM, RTC, custom transformation generates code) 全ての開発ツールをサポートできる Uniform Variability Concept over all asset types 全ての資産に対して共通したバリアビリティのコンセプト Uniform approach across different tools (Easy from Migration from DOORS to DOORS NG) 異なるツールに対して共通した扱い ( 例 :DOORS から DOORS NG への移行も容易 ) pure::variants Update allows to quickly address project needs プロジェクトごとの需要に即座に応じた更新をサポート
Getting Started
Starting and Running Success Product Lines Real World Data Industry / Product Starting Point Industry Automation Frequency Converters Transportation Railway Signaling Systems Automotive Transmission Systems Automotive Airbag Systems Clone and Own Code Requirements (Catalog Approach) Component Selection and #ifdef Clone and Own (Req), #ifdef (Code) First Assets maintained in PL Full Coverage 2 Months (Code) 4-5 Years (Req, Code, Parameter Database) 3-6 Months (Requirements) 18 Months (Req, Code, Tests, other assets) Number Variants ~10-20 at any point in time Initially 2, more added over time Tools ClearCase, ClearQuest, Caliber, BuildForge, Inhouse, C++, pure::variants Doors, Inhouse, C/C++, pure::variants 3 Months 6 Months >50 ClearCase, ClearQuest, make, C, pure::variants 9 Months In progress >100 Doors, RTC, Inhouse tools, pure::variants
Summary
Ad-hoc Strategic Summary Variant Management Approaches Independent Platform-based 5Product Line (90%) 6Production Line (150%) 2Managed Cloning 4Platform (50%) S 7Configurable Product (150%) S S 1Clone&Own 3Reuse Repository S Diversification of reuse approach Evolution of reuse approach Lean & agile reuse approach
pure::variants について : http://www.fuji-setsu.co.jp/products/purevariants/index.html Dr.Danilo の実践的ソフトウエアプロダクトライン開発 http://www.fuji-setsu.co.jp/products/purevariants/danilo_blog.html