View
212
Download
4
Embed Size (px)
DESCRIPTION
Citation preview
発表論文
• タイトル
「Five Years of Product Line Engineering
in a Small Company」
(小規模企業におけるプロダクトライン開発の五年間)
• 著者– Martin Verlage, Thomas Kiesgen
• 出典– 27rd International Conference
on Software Engineering
(ICSE 2005)0
year accept rate
2004 13%
2005 14%
2006 9%
• ICSE(ソフトウェア工学系最強の学会)だから
→ 高級な学会の論文を調査することで、
自分も高級な着眼点で研究ができそう
• SPLを実際の企業に適用しているから
→ SPLを使うことで、企業がどうなったのかが
非常に興味深い
選定理由
1
概要
• 目的
→開発プロセスをSPLに変更するとどうなるのか、
実際の企業における適用結果から教訓を得るため
• 手法
→ MARKET MAKERがSPLを導入したことによって
変更した部分(開発プロセス・組織)を分析
• 結論
→ SPLを企業に適用することにおける教訓と、
今後の研究へのフィードバックを示した2
SPL導入のきっかけ
• 市場で優位に立ちたかった
• 将来を見据えた開発を行いたかった
• 仲がいいフランホーファー研究所で、
PuLSETMというSPLのアプローチを研究していた
• 企業:SPLのアプローチが好都合
• 研究所:SPLのアプローチの検証に好都合
互いにWin-Win な関係!3
i*PrudocutLineの概要
インターネット技術を利用した製品ファミリーを開発したい
既存システム(株式市場データとニュースを
管理・分析するためのツールセット)を再利用
5年かけて、
万能再利用資産 i*PrudocutLine を開発4
i*PrudocutLineのインスタンス
– WIP:
株式市場のデータやニュースを提供
– INFO-AGENT:
銀行員が市場データを調べ、顧客に助言
– XML-Market:
データの評価・表示・配信のための
XMLインターフェース
– Publisher:
登録しているユーザだけがアクセスできる
WEBサービス上のデータを抽出 5
i*PrudocutLineのINFO-AGENT
6
i*PrudocutLineの可変性
• 画面
– 共通:HTML
– 可変:色、フォント、データ項目の位置
• データ構造
– 共通:単一のデータパッケージ
– 可変:なし
• データ品質
– 共通:一定時間経過後の取引データ(安価)←ほとんどコッチ
– 可変:リアルタイムの取引データ(高価)
• 機能性
– 共通:基本的な機能(安価)
– 可変:高度な検索機能、価格データのグラフ(高価) 7
導入初期の意思決定1
• 市場投入までの時間を短縮
– 顧客の要求により、最初の製品はプロジェクトの
開始後12カ月以内にカットオーバー
– ドメインエンジニアリングに時間をかけれなかった
• 新しくチームを編成
– i*PL開発用に新たな人材を採用
– 既存システムを見直す、いい機会になった
• ドメインではなく技術に焦点を当てる
– ドメインエンジニアリングを停止
– スコーピングで要件を識別、参照アーキテクチャを定義8
導入初期の意思決定2
• ドメインエンジニアリングとアプリケーションエンジニアリングを分離しない
– 一つのチームが、ドメインエンジニアリングとアプリケーションエンジニアリングの両方を行った
– アイディアの分離を回避するため
• 既存システムをカプセル化
– Delphiで書かれた既存システムをJAVAで
カプセル化し統合できるようにする
• 設計様式を単純化
– RMI(Remote Method Invocation)により高いスケーラビリティを可能に
– 任意機能はコンポーネントのインスタンス化と設定ファイルでとったりつけたり 9
導入初期の意思決定3
• 意思疎通を効果的に
– 意思決定者は直接開発者に提案
– 営業担当者が中心となって顧客の考えを共有
• 信頼性の高い意思決定を素早く
– 最初にビジョンを立て、意思決定の方向性が合理的だったかを判断
– チームのモチベーションの維持に役立った
• SPLを導入するためのコーチング
– フランホーファー研究所が協力的でサポート
• 投資を最小限に
– 市場投入まで時間がないという圧力が、投資を尐なくした10
SPL導入による開発プロセスの変化1
• スコーピング
– SPL化にあたり新しく導入されたプロセス
– 系図学図表をもとに、共通部分と可変部分を明確化
• アーキテクチャの評価
– 2年後には参照アーキテクチャが複雑になると予測
– フランホーファー研究所のM-Systemで定期的に構造的品質を評価
• 再利用資産の設計
– SPL化にあたり新しく導入されたプロセス
– 普通の開発ではかからないコストがここではかかるため、ガイドラインに沿ってきっちりやる必要があった
11
SPL導入による開発プロセスの変化2
• 再利用資産の実装と新システムの実装時の単体テスト
– 伝染するので、特に再利用資産のバグは致命的
– Junitのテストフレームワークを使用
• ビルドプロセスの自動化
– コンパイラであるファウラーのCruise Controlが自動でコンポーネントテストを行い、エラーはメールで送られる
• 変更管理と問題管理
– 再利用先で大きなバグに化ける可能性があるため、顧客からのバグ報告は慎重に分析する必要がある
– 報告された問題は2人の上級スタッフに送られ、変更計画が立てられる
12
SPL導入による組織の構造1
• スコーピングチーム
– プロセスが行われるたびに、経験豊かな人が集められ形成される
– ビジョンを共有し、開発目標について合意する
• ドメインの専門家
– ドメイン知識があるシニアSEがコンポーネントとフレームワークを開発・保守・機能強化
• アーキテクチャーマネージャー
– 上級従業員がシステム全体の設計をM-Systemで監督・評価
• コンポーネント開発者
– 経験の浅い開発者がアプリケーションエンジニアリングを行う 13
SPL導入による組織の構造2
• 変更管理マネージャー
– 影響分析に基づき変更要求を評価し変更スケジュールを決める
• リクエストディスパッチャー
– マイナーでマニアックな問題は変更管理マネージャーではなくリクエストディスパッチャーに送られる
– システムに関する深い知識が必要
• 問題追跡者
– 問題を追跡・管理・分析する
– 開発チームとは別に構成される
• 構造マネージャー– Junitテストと自動ビルドプロセスを監視し、維持し続けさせる
14
SPL導入による教訓1
• メンテナンスの労力が60%、カットオーバーまでの時間が50%削減
• 小さなチームによるSPL開発は組織構造の欠落に注意する必要がある
• 株式市場のドメインは新機能を頻繁に要求しないためSPLに向いている
• 既存システムのカプセル化は非常に有用で、成功した1番の要因となった
• シンプルなアーキテクチャーが、保守や変更・拡張を容易にした 15
SPL導入による教訓2
• 可変部分の変更・拡張はコンポーネントレベル(粗い粒度)がほとんど
• 緊急時で再利用資産をうまく利用できない場合があった
• ビジョンが定まっていないので、SPLの最初の顧客は危険かもしれない
• 再利用資産と製品が乖離しないよう管理する必要がある
• プロセス定義がしっかりしていると、開発者の能力やチームの大きさに開発が左右されない 16
SPL導入による教訓3
• JUnitを用いたテストを含むビルドの自動化は、より高い品質のための鍵となる
• 単一のシステム開発に比べ慎重に影響分析をする必要があり、問題解決に時間がかかる
• 顧客は開発プロセスに興味がないので、労力に応じた価格ではなく固定価格方式でプロジェクトを行う必要がある
17
SPL研究に対するフィードバック
• PuLSETMのアプローチは実際の開発現場で貢献した
• 試験用に製品実例の情報を提供した
• 開発者とマネージャーのインタビューから、PuLSETMの小さな会社向けのバージョンが定義された
• 既存システムをコンポーネント化するリバースエンジニアリングのアプローチは想定どおりには行かず、もっと研究の余地がある
• 企業目標とアーキテクチャー要素を関連付けることが重要
• SPLにおいて静的なコード分析ではクラス関係を検地することができないため、ランタイム情報に基づいた動的分析が必要となる
18
まとめ
実際の企業にSPLAを適用させた
SPLのために開発プロセスと組織が変更された
SPLを企業に適用することにおける教訓と、
今後の研究へのフィードバックを示した19
私見
• 長所
– SPLを実際の企業に適用している
–現状を研究にフィードバックしている
• 短所(要望)
–大規模企業にもSPLを導入して、今回の結果と比較して欲しい
20