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

ソフトウェアプロダクトライン
エンジニアリングを
プロセステーラリングに応用する
日本科学技術連盟
第25回ソフトウェア品質シンポジウム
September 14, 2006
林好一
yosikazu@sra.co.jp
SRA 先端技術研究所

すじはこび

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

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

ソフトウェアプロセスをテーラリングする
際の典型的なシナリオ
ソフトウェアプロジェクトの立ち上げが決まる
そのプロジェクトの特質を分析する
その特質に対応させて、標準プロセスの構
成要素を選択・調整し、または新たに作り、
統合する
統合したプロセスを検証し妥当性を確認する

同じようなやり方がソフトウェアプロダクトライ
ンエンジニアリング (SPLE) で取られている


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

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

似ていませんか？


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

ビジネス目標に則り、類似のソフトウェア製品群を効
率的に開発するためのパラダイム
計画的、体系的な、つまり最大限の再利用に基づく
高品質、低コスト、そして速さに寄与
米ソフトウェア・エンジニアリング研究所 (SEI) による
と…
ソフトウェア・プロダクト・ラインとは、共通で管理されたフィーチャ
の集合を共有するソフトウェア集約的なシステムの集合であり、そ
れらのシステムは特定の市場セグメントまたはミッションの具体的
なニーズを満足し、規定された方法で共通コア資産の集合から開
発される [Clem01]
簡単に言えば、フィーチャを共有するソフトウェア（集約的）システ
ム群


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

要求に対する一つの視点を与える
「フィーチャとは、あるアプリケーション領域の、ユーザまた
は開発者に可視な特徴の『抽象概念』である」 [Kang90]
共通フィーチャ
対応するコードが全ての製品に含まれる
選択肢フィーチャ
一つのフィーチャに複数の変異体がある場合にはそれぞれ異な
るコードに対応する
オプションフィーチャ
一部の最終成果物にしか含まれないフィーチャもある
これらを用いて製品のバリエーションを表現することができる


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

フィーチャモデル例
オプション
フィーチャ

共通フィーチャ

選択肢フィーチャ

September 14, 2006 SRA Key Technology Laboratory, Inc. [LeeJ04]より編集 7

最終製品の派生
as is 個別開発
ソフトウェア製品
調整
調整

調整
調整 as is

フィーチャ選択
対応

対応していない
コア資産
レポジトリ対応していない


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


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

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


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

ソフトウェアプロダクトラインソフトウェアプロセスライン
最終製品ソフトウェアプロセス

フィーチャ最終ソフトウェア製品が持つ個別ソフトウェアプロセスが持
べき特徴つべき特徴

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


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


個別プロセスの派生
as is 個別定義

調整
調整

調整
as is
調整

フィーチャ選択
対応

プロセス対応していない

コア資産
レポジトリ対応していない


プロセスアーキテクチャ例
上位管理活動

プロジェクト管理活動

エンジニアリングソフトウェアプロセス改善・
構成管理活動
活動品質保証活動展開活動


（エンジニアリングコンポーネント）
プロジェクト
管理活動

エンジニアリング活動

エンジニアリング供給者エンジニア
ライフサイクルリング活動

ウォーター
反復型
フォール型


（プロジェクト管理コンポーネント）
上位管理活動


プロジェクト
計画策定
リスク
監視・制御

供給者プロジェプロジェクトプロジェクト完
クト管理活動進捗管理了

構成管理活動


フィーチャモデル、アーキテクチャ、コン
ポーネントからどうやって個別プロセス
を得るのか？
前掲のフィーチャモデルでフィーチャを
以下のように選択した例を見てみる
ライフサイクルスタイル = ウォーターフォール型
外注 = なし
再利用 = あり
COTS = あり


フィーチャの固定 (1)
→クラス特化による調整
プロジェクトライフサイクルスタイル = ウォーターフォール型
管理活動


ウォーターフォール型
供給者エンジニア
エンジニアリング
リング活動
ライフサイクル

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


→コンポーネント I/F 削除による調整
上位管理活動外注 = なし


プロジェクト
計画策定
リスク
監視・制御

プロジェクトプロジェクト完
進捗管理了

構成管理活動


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

プロジェクト外注 = なし
管理活動


ウォーターフォール型
エンジニアリング
ライフサイクル

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

プロセス記述の追加・削除・変更による調整
ソフトウェア要求定義フェーズ再利用 = あり
(1) エンジニアリング COTS = あり
…
(b) ソフトウェア要求仕様の妥当性
(b-1) 上位システムの要求仕様根拠を当作
業で参照する。 #COTS利用がない場合
(b-2) 上位システムにおける当作業対象ソフ＋利用条件の参照と確認
トウェアの役割を把握する。＋機能試験結果の確認
#再利用品目の有無による変異始まり＋C0 カバレージの達成
#再利用品目がある場合＋ソフトウェア耐性試験
(b-6) 再利用品目が利用される場合には、 #COTS利用の有無による変異終わり
以下を、当作業完了前に実施する。但し、利用する版の試験結果が参照できる
#COTS利用の有無による変異始まり試験を省略してよい。
#COTS利用がある場合試験でパスしてない試験ケースがあった場
・COTS に対して：合には、当該再利用品目管理者に試験環
＋機能試験境情報と共に通達し、…
・当社内で開発されたものに対して： #再利用品目がない場合
＋機能試験結果の確認 (b-6) 当プロジェクト以外で開発された成果
＋C0 カバレージの達成物の利用が決定されていないことを確認す
・いずれに対しても：る。
＋利用条件の参照と確認 #再利用品目の有無による変異終わり
＋ソフトウェア耐性試験 …

むすび

ソフトウェアプロセスもソフトウェアであるので、ソフトウェアプロダクトラ
インエンジニアリング (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.


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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

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

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