ソフトウェアプロダクトラインエンジニアリングをプロセステーラリングに応用する...

ソフトウェアプロダクトラインエンジニアリングをプロセステーラリングに応用する

日本科学技術連盟第25回ソフトウェア品質シンポジウム September 14, 2006 林好一 [email protected] SRA 先端技術研究所

September 14, 2006 SRA Key Technology Laboratory, Inc. 2

すじはこび

ソフトウェアプロセスのテーラリング、普通はどうやっているかそのやり方、ソフトウェアプロダクトラインエンジニアリングに似てはいないかソフトウェアプロダクトラインエンジニアリングではこうやって最終製品を得る実は同じやり方で、プロセスも得られる例えば、こんな風に… あとは、関連研究と参照資料のご紹介


ソフトウェアプロセスをテーラリングする際の典型的なシナリオ

ソフトウェアプロジェクトの立ち上げが決まるそのプロジェクトの特質を分析するその特質に対応させて、標準プロセスの構成要素を選択・調整し、または新たに作り、統合する統合したプロセスを検証し妥当性を確認する同じようなやり方がソフトウェアプロダクトラインエンジニアリング (SPLE) で取られている


ソフトウェア製品派生 - SPLE のやり方

ソフトウェア製品計画が提示されるその製品の要求を分析するその要求に対応させて、SPLコア資産の要素を選択・調整し、または新たに作り、統合する統合した製品を検証し妥当性を確認する

似ていませんか？


ソフトウェアプロダクトラインとは?

ビジネス目標に則り、類似のソフトウェア製品群を効率的に開発するためのパラダイム

計画的、体系的な、つまり最大限の再利用に基づく高品質、低コスト、そして速さに寄与

米ソフトウェア・エンジニアリング研究所 (SEI) によると…

ソフトウェア・プロダクト・ラインとは、共通で管理されたフィーチャの集合を共有するソフトウェア集約的なシステムの集合であり、それらのシステムは特定の市場セグメントまたはミッションの具体的なニーズを満足し、規定された方法で共通コア資産の集合から開発される [Clem01] 簡単に言えば、フィーチャを共有するソフトウェア（集約的）システム群


フィーチャ – プロダクトラインを捉える単位

要求に対する一つの視点を与える「フィーチャとは、あるアプリケーション領域の、ユーザまたは開発者に可視な特徴の『抽象概念』である」 [Kang90]

共通フィーチャ対応するコードが全ての製品に含まれる

選択肢フィーチャ一つのフィーチャに複数の変異体がある場合にはそれぞれ異なるコードに対応する

オプションフィーチャ一部の最終成果物にしか含まれないフィーチャもある

これらを用いて製品のバリエーションを表現することができる


フィーチャモデル例

共通フィーチャ

オプションフィーチャ

[LeeJ04]より編集

選択肢フィーチャ選択肢フィーチャ

ありうる複数の製品を表現


最終製品の派生

調整 as is

as is

調整

調整

対応していない


個別開発

対応

ソフトウェア製品調整

コア資産

レポジトリ

フィーチャ選択


では、ソフトウェアプロダクトラインをソフトウェアプロセスに応用するとどうなるのか？


ソフトウェアプロセスライン

SPLEの目的は、ビジネス目標に則った高生産性と高品質対象がソフトウェアプロセスであっても、コア資産に基づいて同様の効果を挙げることができる。何故ならソフトウェアプロセスもまたソフトウェアであるから [Oste87] ソフトウェアプロセスに応用したプロダクトラインを「ソフトウェアプロセスライン」と呼ぶ[Romb05 etc]


ソフトウェアプロセスラインとソフトウェアプロダクトラインの対照

ソフトウェアプロダクトラインソフトウェアプロセスライン

最終製品ソフトウェア

プロセス

フィーチャ最終ソフトウェア製品が持つべき特徴

個別ソフトウェアプロセスが持つべき特徴

コア資産プロダクトラインソフトウェアアーキテクチャ、ソフトウェアコンポーネント、他関連ドキュメント

標準ソフトウェアプロセスアーキテクチャ、プロセスコンポーネント、他関連ドキュメント


ソフトウェアプロセスのフィーチャモデル例


個別プロセスの派生

調整 as is

as is

調整

調整

調整



個別定義

プロセス

コア資産

レポジトリ

フィーチャ選択対応


プロセスアーキテクチャ例

上位管理活動

エンジニアリング

活動

プロジェクト管理活動

プロセス改善・

展開活動

ソフトウェア

品質保証活動構成管理活動


プロセスアーキテクチャ例（エンジニアリングコンポーネント）


エンジニアリング活動

エンジニアリング

ライフサイクル

供給者エンジニア

リング活動

ウォーター

フォール型反復型


プロセスアーキテクチャ例（プロジェクト管理コンポーネント）



プロセス改善・展開活動

ソフトウェア品質保証活動

構成管理活動

供給者プロジェクト管理活動

プロジェクト

計画策定リスク

監視・制御

プロジェクト進捗管理

プロジェクト完了

上位管理活動


フィーチャモデル、アーキテクチャ、コンポーネントからどうやって個別プロセスを得るのか？前掲のフィーチャモデルでフィーチャを以下のように選択した例を見てみる

ライフサイクルスタイル = ウォーターフォール型外注 = なし再利用 = あり

COTS = あり




ウォーターフォール型

エンジニアリングライフサイクル

供給者エンジニア

リング活動

フィーチャの固定 (1) →クラス特化による調整

注：ライフサイクルスタイルの変異によって影響を受ける他のコンポーネントも調整する

ライフサイクルスタイル = ウォーターフォール型




プロセス改善・展開活動

ソフトウェア品質保証活動

構成管理活動

プロジェクト

計画策定リスク

監視・制御

プロジェクト進捗管理

プロジェクト完了

上位管理活動

フィーチャの固定 (2) →コンポーネント I/F 削除による調整

外注 = なし




ウォーターフォール型

エンジニアリングライフサイクル

フィーチャの固定 (2) 続き

注：他のコンポーネントでも供給者の活動との I/F を削除する

外注 = なし


フィーチャの固定 (3) プロセス記述の追加・削除・変更による調整

ソフトウェア要求定義フェーズ (1) エンジニアリング … (b) ソフトウェア要求仕様の妥当性 (b-1) 上位システムの要求仕様根拠を当作

業で参照する。 (b-2) 上位システムにおける当作業対象ソフ

トウェアの役割を把握する。 #再利用品目の有無による変異始まり #再利用品目がある場合 (b-6) 再利用品目が利用される場合には、

以下を、当作業完了前に実施する。 #COTS利用の有無による変異始まり #COTS利用がある場合・COTS に対して：＋機能試験・当社内で開発されたものに対して：＋機能試験結果の確認＋C0 カバレージの達成・いずれに対しても：＋利用条件の参照と確認＋ソフトウェア耐性試験

#COTS利用がない場合＋利用条件の参照と確認＋機能試験結果の確認＋C0 カバレージの達成＋ソフトウェア耐性試験 #COTS利用の有無による変異終わり但し、利用する版の試験結果が参照できる

試験を省略してよい。試験でパスしてない試験ケースがあった場

合には、当該再利用品目管理者に試験環境情報と共に通達し、…

#再利用品目がない場合 (b-6) 当プロジェクト以外で開発された成果

物の利用が決定されていないことを確認する。

#再利用品目の有無による変異終わり …

再利用 = あり COTS = あり


むすび

ソフトウェアプロセスもソフトウェアであるので、ソフトウェアプロダクトラインエンジニアリング (SPLE) を適用することができる SPLE の適用によって、コア資産からソフトウェアプロセスを派生させてコスト低減、納期短縮、品質向上 (QCD向上）を達成することができるあらかじめ計画すること、しかも体系的に計画することによって QCD の利得（ROI）が予測可能になり、ビジネスの中に、ソフトウェアプロセスの策定も位置づけることができるただし、当発表では言及していない「ソフトウェアプロセスのコア資産」を別途準備することが必要である

謝辞独立行政法人宇宙航空研究開発機構の片平真史氏より励ましと、当発表中の題材に関するヒントをいただきました。ここに感謝の意を表します。


関連研究

米ソフトウェアエンジニアリング研究所による SPLE [Clem01 etc] SEI による SPLE の定義ではソフトウェア製品派生のプロセスが言及されている

これによってプロセスの変異が示唆されるが、明示的ではない

プロセス自体の派生には焦点が当たっていない但し製品派生の標準プロセスというようなものは定義されるかも知れない

独フラウンホーファ IESE [Jauf05, Romb05] ソフトウェアプロセスラインの概念を整理して提示した

鷲崎弘宜 [Wash06] ソフトウェアプロセスラインエンジニアリングに関して研究を継続中 [Wash06] ではプロセスラインアーキテクチャとそれに関連する技法がソフトウェア・ハードウェアのコデザインプロセスの例も用いて述べられている


参照資料

[Clem01] P. Clements and L. Northrop, “Software Product Lines: Practices and Patterns,” Addison-Wesley, Boston, 2001

(Related Web page: http://www.sei.cmu.edu/productlines/framework.html) [Jauf05] O. Jaufman and J. Muench, “Acquisition of a Project-Specific Process,” Proc. 6th

International Conference on Product Focused Software Process Improvement, 2005 [Kang90] K. Kang, S. Cohen, J, Hess, W. Nowak, and S. Peterson, “Feature-Oriented Domain

Analysis (FODA) Feasibility Study,” Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, November 1990.

(Related Web page: http://www.sei.cmu.edu/domain-engineering/FODA.html) [LeeJ04] J.J. Lee, K.C. Kang, and S.J. Kim, "A Feature-Based Approach to Product Line

Production Planning," Proc. Software Product Line Conference 2004 [Oste87] L. Osterweil, "Software processes are software too," Proc. 9th International

Conference on Software Engineering, Monterey, California, U.S.A., March 1987, pp. 2-13. [Romb05] D. Rombach, “Integrated Software Process and Product Lines,” Post-Proceedings

of Software Process Workshop 2005, LNCS Vol.3840, 2005 [Wash06] H. Washizaki, “Building Software Process Line Architecture from Bottom Up,” Proc.

7th International Conference on Product Focused Software Process Improvement, June 2006, pp. 299-313.

http://www.sei.cmu.edu/productlines/framework.html

http://www.sei.cmu.edu/domain-engineering/FODA.html



ソフトウェアプロダクトラインエンジニアリングをプロセステーラリングに応用する...

Design