CACMの特集記事:ソフトウェアプロダクトライン工学(1)

いつも(1)しかなくぜんぜん続かないと評判の俺のエントリ。またやってきました。Communications of the ACM 2006/12の特集記事、Software prductline engineeringの各記事を読んで気になった部分をメモするというコーナーの第一回目です。パチパチ。
今日は、特集記事のEditor Sugumaranらによる、特集の狙いなどを記述した部分を紹介しましょう。なお、いつものように網羅性は気にしていませんので、網羅的にソフトウェアプロダクトライン工学を知りたい方は別に自分でどうぞ。

記事概要

SPECIAL ISSUE: Software product line engineering
Introduction

オーサー

  • Vijayan Sugumaran Oakland University, Rochester, MI
  • Sooyong Park Sogang University, Seoul, Korea
  • Kyo C. Kang POSTECH, Pohang, Korea

*1

ソフトウェアプロダクトライン工学の歴史

  • イデアは1969年のMcIlroyの記事。この記事の内容が、1)成果物の再利用と2)ドメイン分析をソフトウェア工学のテーマのひとつとして認識させた。
  • 関連するアプリケーションを効率よく作るため再利用とドメイン分析をうまく組み合わせたプロダクトライン手法を提案したのはSEI。特に、技術的側面、ソフトの資産化の側面だけでなく、managementの側面を強調していることが特徴。(CMUのSoftware Engineering Institute)。*2
  • 産業界に目をやると、1977年に発表された"Toshiba Software Factory"がプロダクトライン開発に近い。*3
  • 現在でも技術的な問題がソフトウェアプロダクトライン工学の中心である。しかし、ビジネスとの関係、組織のあるべき姿なども研究エリアに入ってきている。

現在の問題

  • 当たり前だが、ソフトウエアプロダクトライン工学の最終目標は、企業の提供するシステムやサービスの開発生産性をあげ、品質を上げること。
  • この目標を考えると、この工学において「再利用率を上げる方法を考えることが目的」と考えるのは間違い。「通常開発のコストより、この工学を用いた開発が、ソフトウェアの資産化による開発、管理コストの増加を考えても得である」ということを示せなければならない
  • そのため、プロセス、組織、技術について、どの問題も重要。この特集記事もその分配に配慮したつもり。
  • プロセスの側面: プロダクトライン開発を行うことをいつ、誰が決めて初期投資(capital investiment)を行うかという問題は非常に悩ましい問題である。*4*5現在は3つモデルが提案されている。Proactiveモデル、Reactiveモデル、Extractiveモデルである。要するに、先にすべての計画をしてプロダクトライン(以降SPL)開発にするか、再利用する必要性が起こったときに考えるか、すでに存在しているシステムから共通部分を割り出しプロダクトライン化するか。Extractiveモデルでは、convetionalな開発手法からSPLへの変更の進め方がポイントになる。
  • 組織の側面: 集中組織vs分散組織。集中的にSPLを管理する部門を置く体制か、各プロジェクトの自主性に任せるか。分散組織は、資産化作りのコストは低いが、効果の薄い資産しかできない。集中はその逆。あと、個々の組織が、全体でSPLを成功させることに対する効果を明示的に示せないと、みんなフリーライド化する場合が多いという点も問題である。
  • 技術的側面: 3つに分けることができる。コア資産開発手法、実プロダクト開発手法、そしてruntime dynamism(なんかいい訳が思いつかない、実行時に変更可能なアーキテクチャにすることをさしているみたい)。 コア資産開発手法の主な話題は、ドメイン分析と可変性管理。実プロダクト開発手法の主な話題は、具体化した場合に選択すべき資産間の干渉、矛盾解決とか(?)。顧客からの要求変更への変更方式。SPLは一から作り変える戦略を取らないため、変更に対する慎重かつ周到な用意が求められる。そのため、テスト方式、トレーサビリティ、品質評価方式の確立は重要。runtime dynamismは、システム実行中に資産を変更できるアーキテクチャにするという問題。自己修正機能とかも範疇。なんでこんなことが必要かというと、サービスとして提供するシステムが今後重要になるから。アスペクト指向はそのキーかもしれない。

将来の研究テーマ

  • 複雑性の管理。実際に使ってみると、数千の可変性を管理するようなモデルになることが報告されている。それで本当にうまくいくには複雑性を管理できなければならない。
  • フィーチャ相互作用問題: 資産が更新された場合の、その資産を使っていたシステムが以前と同じ動作をするかを確かめる問題。特に高品質、高信頼が求められるプロダクトで重要(なんか名前と内容の関係がよくわからん。俺の理解が違うか)
  • runtime dynamism: これはいくらでもテーマがありそうでみんながんばろう
  • 技術以外のテーマ: SPLに最適な組織とは? SPLに最適なプロセスモデル、エンピリカルからのフィードバックが足りない。

というわけで、以降これらのテーマの詳細な記事が続きます。(1)以降がほんとに続けば、皆さんysakata先生の次回作をお楽しみに!(少年ジャンプ風)(#BSCとBPOの解釈問題がぜんぜん進まないなあ。。。時間がほしい。けど、あれって、経済学の基礎を先に知らないとぜんぜん枠として理解できない罠があってすすまない。)

*1:韓国の方が多いが,サムソンの影響?日本でCACMのエディタがはれる人ってどれぐらいいるのかな

*2:Clements, P. and Northrop, L. Software Product Lines. Addison-Wesley,2002.

*3:Matsumoto,Y. A software factory: An overall approach to software production. In P. Freeman, Ed., Tutorial on Software Reusability, Computer Society Press, D.C. 1987, 155-178

*4:Frakes, W.B. and Kang, K.C. Software reuse research: Status and future.IEEE Transactions on Software Engineering 31, 7 (July 2005), 529–536.

*5:Krueger, C. Eliminating the adoption barrier. IEEE Software 19, 4 (Apr.2002), 29–31.