Online-Demo

Size: px

Start display at page:

Download "Online-Demo"

みそらゆきしげ
4 years ago
Views:

1 ソフトウエアプロダクトライン開発再利用の秘訣バージョン地獄で苦しんでませんか?

2 課題 : 再利用が上手くいかない 120% 100% 80% 60% 40% 20% 0% Diagnosis & Repair Testing New Function Development 元となる製品次の製品その次の製品新機能は 10% < コストは 80%

3 バリアント ( 機種 ) 既存製品のコピーを修正して開発 v1.0 v1.2 v1.3 v1.4 v2.0 バージョン

4 バージョン地獄 : 同じコンポーネントの異なるバージョンで構成機種 ( バリアント ) ごとに機能追加や修正を受けて進化を続ける Component A Component B Component C 修正を他機種に反映させることは困難

5 バージョンとバリアントの違いバージョンあるタイミングで記録されたオブジェクトの状態内容バージョン 1.10 をバグフィックスしてバージョン 1.11 をリリースバリアントユーザーによって識別可能な互いに異なる属性を持ったオブジェクトこれらはプロダクトラインに共通の基本オブジェクトを基にして異なるプロパティによって提供される自動車の色タイプ ( セダンスポーツワゴン ) など実践的プロダクトライン開発 Dr.Danilo のブログ

6 課題 : バージョンとバリアントの混同バリアントはバージョンの変更で提供されることがある ( オブジェクトを修正し機能を加える場合など ) バリアントは単一バージョンのオブジェクトからも作られる ( コンフィグレーションなどで振舞いを切り替える場合など ) 1 バリアントが 1 オブジェクトの異なるバージョンで構成され続ける単一のシステム開発に於いてはバリアントとバージョンは同等に扱われることが多いバリアントが直接変更されることなくバリアントは特定のバージョンと言うことになる

7 バージョンとバリアントを区別するバリアントこのような環境を継続的に管理維持することのほうが個々の製品に使用される異なるバージョンの資産間で修正をマージするよりずっとシンプル v1.0 v1.2 v1.3 v1.4 v2.0 v2.2 バージョン各バリアントの機能は使用するプロダクトラインのバージョンから得られる

8 こんな症状でお悩みでは? 並行して開発されているブランチ数が増えつつある並行して開発されているブランチのコード量が増えつつある同じバグを修正したり同じ改善を複数回実施している単一ブランチに実施されるバグ改修や改善策が他のブランチに反映されないコンポーネント間の依存関係が不明確このコンポーネントがこのように組み込まれなければならない理由を説明できない失敗した統合が増えているなぜこれらが失敗するのか説明できないメンテナンスコストが増加の一方出典 : Variant Management 3rd British Computer Society Configuration Management Specialist Group Conference

9 こんな症状でお悩みでは? 顧客から直近のリリースではなく以前のリリースの新しいバージョンを求められる顧客から以前のリリースにそれ以降のリリースからの機能をバックポートするように求められる出典 : Variant Management 3rd British Computer Society Configuration Management Specialist Group Conference

10 こんな症状でお悩みでは? また経験的に以下のような徴候が見られることもある : 構成管理やビルドプロセスがどんどん複雑になったり保守が難しくなってきている製品のビルドは熟練者にしかできない既にいくつかの製品バリアントがあるがそれらに共通するプラットフォームは無くそれらは無計画に進化しているすでにいくつかの製品バリアントがあるが製品の差別化要求が高まっているさらなるバリアントの追加あるいはバリアント間の違い原因 : 構成管理ツールでバリアントを管理出典 : Variant Management 3rd British Computer Society Configuration Management Specialist Group Conference

11 バージョンコントロールシステムから派生されるブランチング / マージのログ全てのブランチされたインスタンスに変更をきちんと同期させ続けることは全く厄介であることは明らかマージするために必要な作業量から多くの場合 2 つの製品間のみでマージが取られることになる ( いくつかのパーツを別の製品から取ってくるだけ ) システマチック ( 体系的 ) な再利用とは言えそうに無い

12 V1~V4( 製品バリアント ) が共通のベースから生産 pure::variants のような適正なバリアント管理ツールによって独立した活動として実施されるこの派生導出 / インスタンス化の活動はバージョン管理される成果物の上で取り計らわれるそこでバージョン管理システムはインスタンスの記録に使われはするがバリエーションポイントの仕組みは提供しない

13 Cost of Reuse: Common Solutions Tweaking existing engineering tools SILO processes EXCEL Outsourcing and off-shoring traditional development process

バリアント管理? : Excel バリアント管理能力を比較 http://www.fuji-setsu.

14 バリアント管理? : Excel バリアント管理能力を比較

15 バリアント管理? 要件設計コードテストなど個々のツールで別々に開発管理される成果物

16 再利用アイテム Test Cases Models Estimates Code Architecture Requirements Subsystems Rules Documentation

17 再利用が高くつく理由ソフトウエア部品の依存関係が高い機能追加で依存関係複雑性バライアビリティが指数関数的に増える既存ツールでバリアント管理はサポートされない製品開発ライフサイクルを通してバライアビリティが管理されない

18 プロダクトライン開発バージョンとバリアントを区別バリアント管理製品間のバリエーションポイント

19 バリエーションポイント問題空間解決空間

20 バリエーションポイント系列製品間で異なる全ての場所問題空間解決空間の両方にあるリンク時コンパイル時実行時などに解決される例えば : 問題空間 : 車は 2つ又は4つのドアをもつ解決空間 :#ifdef / #else / #endif で囲まれたコード領域

21 SPLE の戦略 : 関心事の分離ドメインエンジニアリングフィーチャ群と関係性製品ファミリーの資産問題空間解決空間単一バリアントの機能バリアントアプリケーションエンジニアリング

22 バリアント管理ツール

23 問題空間モデル化し解決空間フィーチャーとリレーションの集合 Feature Model マッピングします資産コードなどファミリー部品の集合 Family Model Production Plan バリアントモデル必要なフィーチャーを選択しバリアントを自動生成 Variant Model

pure::variants 各種開発成果物のバリアントを管理要件管理設計構成管理変更

.. PTC Source Rational ClearCase CVS Subversion.

24 pure::variants 各種開発成果物のバリアントを管理要件管理設計構成管理変更品質管理 PTC Requirements Borland Caliber RM Rational DOORS MS Word Excel... Mathworks Simulink openarchitectureware Enterprise Architect. Rational SW. Architect All EMF Model Rational Rhapsody... PTC Source Rational ClearCase CVS Subversion... PTC Integrity Rational ClearQuest Atlassian JIRA Polarion Bugzilla Softtest... 製品ライフサイクルの全段階でバリアント管理するフレームワーク

25 フィーチャモデル : ツリー構造とグラフ表示

26 新フィーチャにコンポーネントをマップ

27 フィーチャモデル : フィーチャ間の依存排他関係

28 フィーチャの排他関係をグラフ表示

29 バリアントモデルからコードを生成

30 フィーチャ選択により make ファイルにフラグを設定

31 Bugzilla 統合フィーチャ間のバグを登録

32 トレーサビリティバグの影響を受ける製品を抽出

33 Excel 統合テスト仕様ケースの管理など

34 UML 統合 Enterprise Architect の例 (1/2)

35 UML 統合 Enterprise Architect の例 (2/2)

36 バリアント管理ツールに必要なことツールに合わせる必要の無いこと既存のプロジェクトの構成成果物をツールやその手法に合わせることなくインクリメンタルにバリアント管理を安全に取り入れることが出来ること既存のビルドやその他のプロセスへの変更は最小限に大規模複雑なシステムへの対応追加のフィーチャにより取り得るバリアントは簡単に倍増することを考慮に入れて複雑で規模の大きいバライアビリティのモデリングにも対応できること派生製品開発への対応資産プラットフォームなどの変更修正進化に順応できること *Eclipse のような共通のツールプラットフォームユーザインターフェイスバグ管理追跡ツールのようなツールとはリアルタイムな協調が取れること *API を介してあらゆるツールとの統合が誰にでも出来ること

37 pure::variants 問題 / 解決空間の両モデルで関係性を管理機能間の矛盾不一致を自動検出 ( 形式手法の活用 ) 低い導入障壁 : ツールに合わせなくて良い! 既存資産ファイルシステム構造を変えることなく導入できる製品バリアントは制約無しに自在に生成できる複数のバリアントを同時に生成できるファイル構造の仕組みに非依存コア資産を完全に独立部品として管理クライアント / サーバでマルチユーザ大規模システムにもフィット Eclipse ベース : あらゆる開発環境ツールに統合

38 体系的再利用製品構成の知識情報を記録管理製品バリアントを明解に表現 pure::variants 組織内で共有活用製品バリアントを生成納期短縮高品質工数削減

39 pure::variants 適応範囲とアプローチ顧客市場からの要求要求仕様書モデリングシミュレーション開発実装テスト出荷顧客市場からの要求要求仕様書モデリングシミュレーション開発実装テスト出荷プロダクトラインライフサイクルで一貫して用いる Top Down Adoption Design for Reuse Combination of Both Bottom Up Adoption Refactor for Reuse

40 pure::variants 適応範囲とアプローチ顧客市場からの要求要求仕様書モデリングシミュレーション開発実装テスト出荷顧客市場からの要求要求仕様書モデリングシミュレーション開発実装テスト出荷プロダクトラインライフサイクルで一貫して用いるトップダウン再利用の為のデザインプラットフォームアーキテクチャコンポーネントを再利用を意図して設計する PLE, SPL で提唱される戦略に習うプロセスの開始次期からバリアント管理を用いる Siemens Medical( 医療機器 ): 新しいプラットフォームの共有資産バライアビリティ機能を pure::variants にモデル化ボトムアップ再利用の為にリファクタリング開発チームによる課題への取組み既存ツールの統合既存のレガシーコード成果物をリファクタリング Danfoss Drives( モータ制御用インバータ ): 4 つのマーケットのコードを共通プラットフォームに統合

41 pure::variants 組込み機器を中心に広く採用

42 Case study Danfoss Drives Migration

43 OEM 及び顧客向けの製品 4 つのビジネスドメインがある Power Range 0.18 kw 1.2 MW Danfoss Drives Migration 電子モータ制御システム

44 5 地域で開発されている 100 人の開発者行のコード 20 以上の製品群

45 HVAC Feature Requirements AQUA Industry/Automation SPLE プロジェクト ( ) ボトムアップアプローチを採用 2006 年に SPL スタートして 2 か月後には 60% が SPL から生成できた (40% はレガシーからの個別のコード ) Danfoss Drives Platform Feature Model 2008 年には 80% が SPL から (20% はレガシーからの個別のコード ) フィーチャモデルコードの統一化データベースの統一化 FC-101 FC-202 FC-302 Product Code Asset

46 Case study: ダイムラー社

47 Case study: ダイムラー社

Practical pairwise testing for SPL SPLC 2013 @ 東京より大手通信機器メーカのビデオ会議システムプロダクトライン開発のペアワイズテスト生成結果 :

2% の組み合わせでしかなかったのに 17% 少ない組み合わせ数で全ペアワイズテストを短時間に生成できるようになった Practical pairwise testing for SPL http://hal.

48 Practical pairwise testing for SPL SPLC 東京より大手通信機器メーカのビデオ会議システムプロダクトライン開発のペアワイズテスト生成結果 : マニュアル作業では 19.2% の組み合わせでしかなかったのに 17% 少ない組み合わせ数で全ペアワイズテストを短時間に生成できるようになった Practical pairwise testing for SPL Automated Test Case Selection using Feature Model: An Industrial Case Study Certus V&V Centre, Simula Research Lab

49 まとめバライアビリティは少ない目に小さいところから始める段階的に整備する短期的な投資対効果を求める適切なツールを活用すること

50 ご清聴ありがとうございました富士設備のブース (E-01) で展示しています富士設備工業株式会社電子機器事業部

51 付録進路 : SPLE へ移行

52 SPLE へ移行基本的に移行プロセスは既存製品からバリエーションポイントと必要なモデルを抽出する作業 1から始めるのとなにが違うのか? 非常に有用な情報が既に提供されている ( 隠れているだけ ) プロセスや成果物への変更は簡単ではないでも適切なプロセスや成果物を始めから導入することはもっと難しい

53 SPLE へ移行 SPLE 導入前現状を調査して目標を定める移行のシナリオを特定バライアビリティの解析バライアビリティをモデル化 SPL を開始して活用する

54 プロダクトの相関パターン : プロダクトフォレスト共有するコア資産が無い (UI の部品や計算処理程度 ) ユーザーに見える機能は似通っているが同じドメインで同時期に別々に開発されている P 3 P 2 P 1 P '' 1 P''' 1 P 0 P ' 0 Time

55 プロダクトの相関パターン : プロダクトブッシュコア資産を共有しているが開発経路の分岐によりプロダクトバリエーションが作成されている (Clone and own ) あるブランチの変更を全てに反映させるには手作業で同じ変更を加える必要がある安上がりに見えるが後からのしっぺ返しが大きい P 2 P 3 P 1 P '' 1 P''' 1 P 0 P ' 0 Time

56 プロダクトの相関パターン : プロダクトギャングソフトウエアのコア資産を共有ソリューションの構成によるプロダクトバリエーションで体系的なバリアント管理が無い PF の各メンバー ( 部品 ) は個々に進化独立しある部分のプログラムの修正が他のどの部分に影響するかわからない PV ''' 3 街のギャングと同じでメンバー間の結びつきは強いが個々の素性は謎につつまれて PV ' 2 PV '' 2 PV 1 PV 0 PV ' 0 PV ''' 0 PF 0 PF 01 PF ' 01 PF ' 012 PF '' 012 PF ''' 012 PF ''' Time

57 プロダクトの相関パターン : プロダクトファミリコア資産を共有体系的なバリアント管理ある時点の PF に対する変更が関わる全ての製品に正しく反映される仕組み PV ''' 3 ファミリーメンバー間の素性が明確で製品と資産が双方向にリンク PV ' 2 PV '' 2 PV ''' 2 PV ''' 2 PV 1 PV ' 1 PV ' 1 PV '' 1 PV ''' 1 PV ''' 1 PV 0 PV 0 PV ' 0 PV ' 0 PV '' 0 PV ''' 0 PV ''' 0 PF 0 PF 01 PF ' 01 PF ' 012 PF '' 012 PF ''' 012 PF ''' Time

58 移行シナリオ現状の資産個別製品をマージ再利用の改善解決空間の資産が同じで無いプロダクトフォレスト型一部のプロダクトブッシュ型解決空間が同じかほぼ同等プロダクトブッシュ型プロダクトギャング型

59 SPLE へ移行 SPLE 導入前現状を調査して目標を定める移行のシナリオを特定バライアビリティの解析バライアビリティをモデル化 SPL を開始して活用する

60 バライアビリティの解析やるべきことプロダクトラインのバリエーションポイントの抽出と特定バリエーションポイントの制約の抽出見るべき場所ソースコード構造アルゴリズムテクノロジードキュメントユーザーマニュアル内部ドキュメントコードのコメント管理方法バージョン管理コンフィグレーション

61 バライアビリティの解析マニュアルドメインエンジニアリングソースコードバージョン管理要求仕様コンフィグファイル変更要求バライアビリティモデル

62 バライアビリティの解析 (2) 得られた情報から以下の手掛かりの定義を始めてみるプロブレムスペースの最初のバリエーションポイントソリューションスペースの最初のバリエーションポイントバリエーションポイントの最初の制約プロダクトラインを進めていく上でこれらバリエーションポイントの情報は変化し続ける結果として以下の準備ができるようになるプロダクトラインの範囲を特定プロブレムスペースの定義コア資産の特定生産計画の作成

63 バリエーションポイントバリエーションポイントの定義有効な選択肢 ( フィーチャー ) バリエーションの制約 (requires/conflicts) 帰属するスペース ( プロブレム / ソリューション ) プロダクトラインのバライアビリティに関する関連性 / 重要性解決されるタイミング製品構成時コンパイル時リンク時インストール時ユーザーによる構成時実行時解決方法スタティックダイナミック使用するバライアビリティーのパターン

64 解析の方向 Docs, Specs, FORWARD Variability BACKWARD Code, Configs, Models

65 解析の方向 FORWARD 問題空間のバライアビリティーから始めるユーザーマニュアルや製品仕様が既存製品間のバライアビリティーの実態を上手く反映している場合に最適 : プロダクトフォレストに向く既存のコア資産を確認すること無しにプロダクトラインを適用できる BACKWARD 解決空間のバライアビリティーから始めるソフトウェアのデザインやアーキテクチャーがプロブレムスペースを上手く反映している場合に最適 : 特にプロダクトブッシュとプロダクトギャングに向くプロブレムスペースのバライアビリティーを抽出する事でプロダクトラインの適用が始められる

66 解析の方向ドメインエンジニアリング問題空間解決空間マニュアルソースコードバージョン管理マニュアルソースコードバージョン管理要求仕様コンフィグファイル変更要求要求仕様コンフィグファイル変更要求モデルモデル

67 問題空間の VP 抽出典型的な入力ユーザードキュメントインストール / ユーザーマニュアルホワイトペーパー開発ドキュメント要求仕様ユーズケースアーキテクチャー設計ドキュメントバージョン管理システムのログ ( 特にプロダクトブッシュ ) コンフィグレーションファイル ( 特にプロダクトギャング ) 顧客とのコミュニケーション ( 機能要求等 )

問題空間のモデリングフィーチャモデルフィーチャーモデルはバリエーションポイントをフォーマルに記載するために最も頻繁に用いられる - フィーチャーモデルのコンセプトは分かりやすい - 複雑なフィーチャーモデルでさえ扱いが簡単 - 殆どの実社会の課題を表現する十分な能力を持つ一つのフィーチャは問題空間の特性であり当該するバライアビリティを表現する

68 問題空間のモデリングフィーチャモデルフィーチャーモデルはバリエーションポイントをフォーマルに記載するために最も頻繁に用いられる - フィーチャーモデルのコンセプトは分かりやすい - 複雑なフィーチャーモデルでさえ扱いが簡単 - 殆どの実社会の課題を表現する十分な能力を持つ一つのフィーチャは問題空間の特性であり当該するバライアビリティを表現するツリー構造であるフィーチャの選択肢には (mandatory 全て必須 ), (optional いくつでも ), (alternative どれか一つ ) (or 少なくとも 1 つ ) があるフィーチャはコンストレインツを取ることがある ( フィーチャ X には Y が必須など ) 必須排他など推奨阻止などフィーチャは値や特性値も持ち得る

69 解決空間の VP の抽出典型的な入力アーキテクチャー設計ドキュメントソースコードコンフィグレーションスクリプトプロジェクトのビルド定義 ( 例えば makefile) バージョン管理システムの構造と用法コンフィグレーションファイルとファイルフォーマット

70 解決空間の VP をパターンから検出殆どの場合少しのコードを良く見ると使用されているパターンが明確になる ( プログラマーは繰り返しパターンを使いがちであるので小さな範囲内で得られるパターンは限られる ) 大抵コード構造が限定された構文に組み込まれるのでソリューションスペースのパターンは単純なツールを使ってより簡単に検出できる問題はソリューションから得られるバリエーションポイントの数は大抵非常に多くなる

71 解決空間の基本設計参照される基準としてのアーキテクチャープロダクトから復元できるプロダクトギャングプロダクトブッシュ単一のプロダクト又はスクラッチから構築が必要プロダクトフォレストコア資産の特定コンポーネントにアーキテクチャー特定の重み付け将来の製品での使用可能性既存製品での使用率適用により期待できる効果全ての既存資産を使う必要は無い!

73 組織内の役割分担ドメインエンジニアリングドメインの熟練者アーキテクト開発者問題空間解決空間アプリケーション分析担当アプリケーションエンジニアアプリケーションエンジニアリング

74 プラットフォームセントリック Project Team 1 Project Team 2 Project Team 3 Project Team 4 Project Team 5 Project Team 6 PL Team プラットフォームセントリックなアプローチ各プロジェクトチームより多くの人員 ( リソース ) を得てプロダクトラインチームを組むそして PL のコア資産をはじめに作成し管理する一旦 PL 開発環境が構築されるとコア資産は盤石であるがそれまでは各プロジェクトが進まない各プロジェクトのバス幅が細いことに注目 PL Core Assets

75 進化型プラットフォームセントリック Project Team1 Project Team 2 Project Team 3 各プロジェクトチームから少数の人員を得て PL チームを組むプロジェクト開発を進めながらそこで得られた資産をコア資産に登録していくゆっくりと時間をかけて PL チームは大きくなりコア資産は更に増加し各プロジェクトはより少ない人員で開発できるようになっていく Product Line Team PL Core Assets Project Team 5 Project Team 4 Project Team 6

76 プロジェクトセントリック Project Team 1 Project Team 2 Project Team 4 Project Team 5 Project Team 3 Project Team 6 Product Line Management Team 各プロジェクトチームからの人員は最小限 PL チームではなく PL マネージメントチームを組むこのチームは管理に専念し各プロジェクトチームとコミュニケーションを図りながらプロジェクトチームの成果物を資産登録管理する PL Core Assets

77 アプローチの比較プラットフォームセントリック進化型プラットフォームセントリックプロジェクトセントリック + 長所 + 長所 + 長所プロジェクトへの影響が最小限定的なリスク最小のリスクレガシーが無くても始められる徐々に組織を変えて行ける組織的な変更が少ない - 短所 - 短所 - 短所投資回収が早い組織への影響大再利用性の向上が遅い目最善の再利用規則が求められる開始に時間がかかるレガシーシステムを再利用する必要があるリスクが高い

78 再利用改善活動が開始されると各関係者ごとで得られる個別の成果についての情報交換意思疎通が重要だれもその取り組みに興味を持たなければ協調連携が複雑であることから成果は容易に妨げられる再利用性の無いコードを開発者が生成したらそれが拡散してしまうことで望ましくない結果が待ち受ける成功を目指し意思疎通を図りましょう

79 計画を貫くことは良いことですが定期的に調整するとより良いでしょう全ての障害は予測できませんし耳を傾け関係者からのフィードバックを集めましょう取り得る改善策を協議し長期的なものと急ぎの対策の両方を得ることをいつも求めましょう

80 Trap /catch

< 使用されない資産を開発するケース > コア資産開発チームが開発した資産を他のチームが使わないケースがあります

使わないというケースがありましたまたコア資産が十分でない為に使われなかった例もありました < 開発が外部委託される場合 >

彼らは再利用から得られる利益について興味が無く顧客が再利用を推進するように依頼しても再利用を成功させようとは考えない <

技術の再利用が非常に困難な場合 2 つ目は利害関係者に対する再利用の教育が不十分なケース管理の立場から見て全利害関係者に

異なるプロジェクトチームが同じような機能を沢山開発しているケースこれらのプロジェクトでは少しずつ違う機能が実装されており

81 < 使用されない資産を開発するケース > コア資産開発チームが開発した資産を他のチームが使わないケースがありますこれは組織上の問題で何処でも起こることではありませんあるチームが他のチームが開発したコンポーネントや資産を信頼できない為に使わないというケースがありましたまたコア資産が十分でない為に使われなかった例もありました < 開発が外部委託される場合 > プロジェクト費用が工数から算出される為再利用によって開発時間が短くなっても利益にならない彼らは再利用から得られる利益について興味が無く顧客が再利用を推進するように依頼しても再利用を成功させようとは考えない < 再利用可能な資産を作成保守しようとするとコストが嵩むケース > 1 つはそのドメインや組織に於いて技術の再利用が非常に困難な場合 2 つ目は利害関係者に対する再利用の教育が不十分なケース管理の立場から見て全利害関係者に再利用に関する十分な知識を与える為のコストがかかりすぎる 3 つ目は異なるプロジェクトチームが同じような機能を沢山開発しているケースこれらのプロジェクトでは少しずつ違う機能が実装されておりこれを再利用する場合プロジェクト間の調整が困難です < 管理側が再利用の為の開発体制を十分にサポートできないケース > 非常に重要な問題なぜなら高い再利用性を実現するプロジェクトを始めようとすると単一のプロジェクトを開発するよりコストが嵩み開発者が低コストで生産することを要求するとトラブルになるからです

82 まとめレガシーソフトウェアをプロダクトラインに転換可能移行を始める前に念入りなリスク評価が必要抽出できる知識の量と質移行チームのスキルと管理者のサポート

83 富士設備工業株式会社電子機器事業部

Online-Demo

Online-Demo ソフトウエアプロダクトライン開発セミナーレガシーな資産からの移行について "Transforming Legacy Systems into Software Product Lines" Dr. Danilo Beuche 講師 Dr. Danilo Beuche 2001-: ドイツマグデブルグ pure-systems 社代表取締役組込みソフトウェア開