Reengineering Software Evolution Technology
ソフトウェア進化技術の実践に関する調査研究
ソフトウェアプロダクトラインパターン
ソフトウェアプロダクトライン(SPL: Software Product Line)とは，共通の特性を持ち，特定の市場やミッションのために，共通のコア資産から規定された方法で作られる，ソフトウェア中心システムの集合を指す[10][11]．
ここで，ソフトウェアプロダクトラインパターンを紹介する前に，簡単に用語を整理しておく[12]．コア資産(core asset)とは，プロダクトラインの基盤を形成する成果物(artifact)のことを指す．コア資産は，複数の製品系列に対して適用可能なように，あらかじめ共通部分と可変部分を織り込んで構築される．可変ポイント(variation point)とは，コア資産において，特定の製品系列に固有な部分とすべての製品系列に共通な部分との分岐点を指す．バリアント(variant)とは，可変ポイントに対する選択肢を指す．共通可変分析(commonality and variability analysis)とは，特定の製品系列の固有部分とすべての製品系列に共通の部分を分析し決定することを指す．
また，フィーチャー(feature)とは，ソフトウェアシステムにおける，突出したまたは他と明確に区別でき目に見える側面，品質，特徴のことを指す[13]．この定義は，The American Heritage Dictionaryからの引用である．補足すると，フィーチャーとは，プロダクトが提供するサービス，操作性や性能などの非機能要求などのそのプロダクトの代表的な特性のことである．フィーチャーモデリング(feature modeling)とは，プロダクトライン型開発において，ドメインの共通／可変部分を抽出するための代表的な手法を指す[14]． フィーチャーモデリングと他のさまざまなモデリング技術を融合させ，プロダクトラインの構築，運用，進化への研究が取り組まれている．フィーチャーマトリクス(feature matrix)とは，フィーチャーとコア資産の要素との対応関係をトレースしやすくするための情報をマトリクス形式で記述した仕様のことを指す．
ここでは，プロダクトライン開発に特化した5つのパターンを紹介する．
- パターン2.1 プロダクトラインに移行すべきかを判断しよう
- パターン2.2 コア資産を浄化しよう
- パターン2.3 「石ころ」に投資してはいけない
- パターン2.4 レガシーの現状を分析しよう
- パターン2.5 コア資産への再生シナリオを決定しよう
パターン 2.1
プロダクトラインに移行すべきかを判断しよう
Launch Product Line
開発プロセスをプロダクトラインに移行すべきかどうかを，製品ライフサイクルに基づいて判断することで，投資対効果を高める．
問題
- 開発プロセスをプロダクトラインに移行すべきかどうかの意思決定ができない．
解法
- 自社製品が製品ライフサイクル[15]のどのステージにいるかを分析し，開発アプローチをプロダクトラインに変換すべき/すべきでないかを判断すべきである．
- 図2.1に示すように，製品ライフサイクルの段階は導入期(Introduction)，成長期(Growth)，成熟期(Maturity)，衰退期(Decline)の4つがある．導入期は，新製品を開発し，消費者に宣伝・紹介している段階である．成長期は，競合他社との差別化のために新機能を開発し，先進的な消費者に販売している段階である．成熟期は，製品の開発コストを削減し，多くの消費者に販売している段階である．衰退期は，最小限のプロモーションにより，販売を継続している段階である．
- プロダクトラインへの変換は成長期から成熟期への移行時期が望ましい．なぜなら，成熟期では，消費者ニーズに応じた機能を低コストで提供することが重要であり，コア資産と消費者個別機能を管理しながら開発するプロダクトラインが適しているためである．成長期と成熟器の比較を表2.1に示す．
トレードオフ
-利点
- 製品ライフサイクルの段階に応じて開発アプローチを変更することで，投資対効果を向上できる．
- レガシー資産をコア資産に変換する技術は増えつつあるが，変換作業のリスクは小さくない．変換作業が失敗した場合，競争力が低下してしまう．
関連するパターン
コア資産に移行する場合には，コア資産は今すぐリファクタリングしよう (パターン6.1) が利用できる．
パターン 2.2
コア資産を浄化しよう
Detox Core Assets
肥大化したコア資産をスリムにして価値を高める．
問題
- プロダクトライン型の開発（コア資産の開発と進化）が3年以上などの長期間に渡り，技術，市場，組織の変化に応じて，コア資産を拡張し続けた結果，コア資産が肥大化し，コア資産内に製品開発で利用されない要素が存在するなどして，却って保守拡張のコストが増大している．
- プロダクトライン型の製品開発では，コア資産の可変ポイントから可変部分を選択または開発するが，コア資産が複雑化/肥大化して可変ポイントや可変部分が不明確になり，これらの選択が困難になっている．
- 複雑化/肥大化したままコア資産を保守拡張すると，一カ所の拡張の影響が多大な範囲に及ぶことや，そもそも影響範囲が把握できないまま拡張することになり，品質保証のためには膨大なテストを実行する必要があるなど，保守コストが増加している．
解法
- 不必要で製品開発に問題をもたらすコア資産を浄化(detox)し，製品開発時の可変ポイントや可変部分の選択をしやすくする．
- 図2.2にコア資産を浄化する際の3つの方法を示す．いま，カバー率（コア資産が十分な要素を備えている/いない）と対応度（コア資産の要素間の整合がとれている/いない）の2つの指標をそれぞれ2値で表す．このとき，コア資産は次に示すA～Dの4つのタイプに分けることができる．
- タイプA：コア資産が十分な要素を備えている，かつ，コア資産の要素間の整合性がとれている
- タイプB：コア資産が十分な要素を備えている，かつ，コア資産の要素間は整合性がとれていない
- タイプC：コア資産が十分な要素を備えていない，かつ，コア資産の要素間は整合性がとれている
- タイプD：コア資産が十分な要素を備えていない，かつ，コア資産の要素間は整合性がとれていない
- 問題で示したコア資産は，コア資産は肥大化するほどの十分な要素があるが，成果物間は整合が十分ではないため，タイプBに分類できる．コア資産をDetoxするとは，不要な要素を減らした上で，整合がとれた状態にすることである．そのようなコア資産は，タイプCに分類できる．
- 肥大化したコア資産，すなわちタイプBのコア資産から，適切な状態であるタイプCに状態を変化させるには，図 2.2に示す (1)～(3)のパスが考えられる．
- (1) コアアセットの削除 → 整理統合
- (2) コアアセットの整理統合 → 削除
- (3) 整理統合されたコアアセットの削除
- コア資産内は要素が複雑に結合している場合が多いので，不要な要素を単純に削除することは難しい．よって，コア資産の状態を把握するためにも，（２）のコアアセットを整理統合したのち，不要な要素を削除するパスを優先することがリスク回避のために有効である．
トレードオフ
-利点
- 長年活用されてきた複雑なコア資産を容易にスリム化することは困難であるので，整理統合の作業を実施して，コア資産の性質を把握することによって，安全に不要な要素を特定することが可能である．
- 過去の製品開発で活用された要素がコア資産の浄化により削除される．これによって，既に納入された製品の保守管理が不可能になるリスクがある．
関連するパターン
コア資産の品質が不適切な場合には，コア資産を浄化しても効果が得られないケースがあるので，「石ころ」に投資してはいけない (パターン2.3)を参照のこと．
パターン 2.3
「石ころ」に投資してはいけない
Don’t Invest in Stone
既存のコア資産の中から投資リスクが高いものを除外する．
問題
- ある組織内では，複数のプロダクトラインが維持管理されている．例を表2.2に示す．この表において，投資順位とは投資申請額の順位を指す．投資回収時期とは，ROIがプラスに転じるまでの想定期間を指す．ROI順位とは，回収額の想定順位を指す．また，タイプA～Dとは，コア資産を浄化しよう (パターン2.2)にて示したコア資産のタイプのことを指す．
- 事業計画において，既存のプロダクトラインを拡張して，今後の市場，技術，環境の変化に対応させ，事業を拡大していくことを望んでいる．しかし，投資額には限度があるため，どのプロダクトラインに投資すべきか，またはすべきでないかを決めなければならない．
- それぞれのプロダクトラインを持つビジネスユニットから，投資回収計画が出されたが，ROI順位を投資判断の要素にすることが妥当であるのかどうかを判断できない．
解法
- ビジネスユニットが提出したROI順位よりも，コア資産の整合性の度合いに着目して，投資対象を判断すべきである．
- 各プロダクトラインのコア資産が肥大化して整合がとれていない場合には，コア資産の拡張のための投資を実行しても，肥大化した部分の整理統合にコストがかかり，想定している投資効果が得られないリスクが高まる．よって，このようなプロダクトラインに投資してはいけない．
トレードオフ
-利点
- 肥大化し整合性が保てていないコア資産は，拡張に着手しても，肥大化して複雑な部分の解析に時間がかかり，市場，技術，環境の変化に俊敏に対応することが困難になるため，こうしたプロダクトラインへの投資は，投資効果が期待できない．こうしたコア資産へ投資しない決断をすることは無駄な投資の防止につながる．
- これまで実績を出してきたプロダクトラインへの投資を凍結することによって，対象製品の価値が低下し，新しい顧客獲得や既存顧客の囲い込みなどの機会を損失してしまう．
関連するパターン
SPLコア資産パターン全般を適用する前に，本パターンの適用を検討すべきである．
パターン 2.4
レガシーの現状を分析しよう
Analyze Legacy Software Assets
長期に渡って改造を繰り返してきたレガシーソフトウェア資産を再生し高品質なコア資産を構築したい．
問題
- 長期に渡って改造を繰り返してきたレガシーソフトウェア資産の中には，コア資産としてふさわしくない低品質な成果物が含まれている．
- 品質の良くない成果物をそのままコア資産に組み入れるとコア資産全体の品質が低下してしまう．
解法
- ソースコード解析技術などを利用し，ソースコードやドキュメントなどレガシーシステムの成果物の現状を客観的に分析・評価する．表2.3に現状分析の進め方を示す．
- レガシー資産の成果物の現状を分析しておくことで，品質の低い成果物をそのままコア資産として組み込んでしまうリスクが低下する．
- 分析対象の成果物が大量にある場合には，分析を効率的に行わないと分析自体のコストが大きくなりすぎてしまう．
- どのような方法でコア資産として再生すればよいかわからない．
- コア資産として再生するためのシナリオとしてどのような選択肢があるかわからない．
- 選択肢が提示されても，その中からどのシナリオを選択すれば良いかわからない．
- レガシー資産をコア資産として再生するための代表的なシナリオを表2.4に示す．この表に示すシナリオからどのシナリオを選択するかについては，レガシー現状分析の結果や再生コスト，リスク，もたらされる効果を考慮して決定する．
- 既存の成果物の現状態に応じて適切な再生シナリオを選択することができる．
- 市場の成熟度，トレンドの変化などによっては，コスト，リスクの高いシナリオをとった場合に投資を回収できない恐れがある．
- [1] M. M. Lehman, M. M., “Programs, Life Cycles, and Laws of Software Evolution”, Proc. IEEE, Vol.68, No. 9, pp. 1060-1076 (1980)
- [2] 大森隆行, 丸山勝久, 林晋平, 沢田篤史, “ソフトウェア進化研究の分類と動向”, コンピュータソフトウェア, Vol.29, No.3, pp.3-28 (2012)
- [3] W. M. Ulrich, P. H. Newcomb, “Information Systems Transformation: Architecture-Driven Modernization Case Studies”, Morgan Kaufmann (2010)
- [4] D. L. Parnas, “Software Aging”, Proc. ICSE'94, pp.279-287 (1994)
- [5] M. Jazayeri, “Species Evolve, Individuals Age”, Proc. IWPSE'05, 2005, pp.3-12 (2005)
- [6] E.J. Chikofsky, and J. H. Cross II, “Reverse Engineering and Design Recovery: A Taxonomy”, IEEE Software, Vol.7, No.1, pp.13-17 (1990)
- [7] S. Demeyer, S. Ducasse, O. Nierstrasz, “Object-Oriented Reengineering Patterns”, Morgan Kaufmann (2002) （ダウンロード）
- [8] M. Fowler, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley (1999)
(訳) 児玉公信, 平澤章, 友野晶夫, 梅沢真史, “リファクタリング”, ピアソンエデュケーション (2000) - [9] パターンワーキンググループ, “ソフトウェアパターン入門”, ソフト・リサーチ・センター (2005)
- [10] P. Clements and L. Northrop, “Software Product Line: Practices and Patters”, Addison Wesley (2001)
- [11] K. Pohl, G. Böeckle, F. J. van der Linden, “Software Product Line Engineering: Foundations, Principles and Techniques”, Springer (2005)
(訳) 林好一, 吉村健太郎, 今関剛, “ソフトウェアプロダクトラインエンジニアリング ― ソフトウェア製品系列開発の基礎と概念から技法まで”, エスアイビーアクセス (2009) - [12] J. McGregor, D. Muthig, K. Yoshimura, P. Jensen, “Successful Software Product Line Practices”, IEEE Software, Vol. 27, No. 3, pp.16–21 (2010)
- [13] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, A. S. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility Study”, CMU/SEI-90-TR-21 (1990)
- [14] K. C. Kang, V. Sugumaran, S. Park, “Applied Software Product Line Engineering”, Auerbach Publications (2010)
- [15] L. Gorchels, “The Product Manager's Handbook: The Complete Product Management Resource”, McGraw-Hill (2000)
- [16] 位野木万里, 杉本信秀, 深澤良彰, “ステークホルダの意思決定を支援するプロダクトライン再生シナリオの提案”, ソフトウェア工学の基礎ワークショップ(FOSE2008), pp.75–80 (2008)
- [17] 神谷年洋, 肥後芳樹, 吉田則裕, “コードクローン検出技術の展開”, コンピュータソフトウェア, Vol.28, No.3, pp.29–42 (2011)
- [18] J. Humble, D. Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley Professional (2010)
(訳) 和智右桂, 高木正弘, “継続的デリバリー： 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化”, アスキー・メディアワークス (2013) - [19] P. M. Duvall, S. Matyas, A. Glover, “Continuous Integration: Improving Software Quality and Reducing Risk”, Addison-Wesley Professional (2007)
(訳) 大塚庸史, 丸山大輔, 岡本裕二, 亀村圭助, “継続的インテグレーション入門”, 日経BP社 (2009) - [20] S. Thangthumachit, S. Hayashi, M. Saeki, “Understanding Source Code Differences by Separating Refactoring Effects”, Proc. APSEC'11, pp.339–347 (2011)
- [21] K. Herzig, A. Zeller, “The Impact of Tangled Code Changes”, Proc. MSR'13, pp. 121–130 (2013)
- [22] KDE TechBase, “Policies/Commit Policy”,
http://techbase.kde.org/Policies/Commit_Policy#Commit_complete_changesets - [23] S. Appleton, B. Berczuk, “Software Configuration Management Patterns”, Addison-Wesley (2002)
- [24] S. Person, M. B. Dwyer, S. Elbaum, C. S. Păsăreanu, “Differential Symbolic Execution”, Proc. FSE'08, pp.226–237 (2008)
- [25] S. Lahiri and C. Hawblitzel, “Symdiff: A Language-Agnostic Semantic Diff Tool for Imperative Programs”, Proc. CAV’12, pp.712–717 (2012)
- [26] D. Jackson and D. A. Ladd, “Semantic Diff: A Tool for Summarizing the Effects of Modifications”, Proc. ICSM’94, pp. 243–252 (1994)
- [27] 角田雅照, 門田暁人, 松本健一, 押野智樹, “受託開発ソフトウェアの保守における作業効率の要因”, コンピュータソフトウェア, Vol.29, No.3, pp.157–163 (2012)
トレードオフ
-利点
パターン 2.5
コア資産への再生シナリオを決定しよう
Decide Reengineering Scenarios
レガシーソフトウェア資産をコア資産として再生するためのシナリオを決定したい．
問題
解法
トレードオフ
-利点