ソフトウェア プロダクトライン(SPL)への適用

ソフトウェアの品質と納期を守りながらバリエーションのある製品群をリリースするために、欧米ではソフトウェア プロダクトライン(SPL)手法を採用している組織が数多くあります。

ソフトウェア プロダクトライン(SPL)を始めるには

ソフトウェア プロダクトライン(SPL)は製品群の共通性と可変性分析に基づき、コア資産開発で作成した共通部品、可変点、可変部品を組み合わせて製品群を開発していく手法です。しかし、製品企画部門などのビジネスグループが考えている製品ロードマップとコア資産の開発戦略に乖離があった場合、ソフトウェア プロダクトライン(SPL)は失敗します。したがって、製品スコーピングに際しては、ビジネス側と開発側はしっかり合意する必要があります。そのためには、開発側はビジネス側が理解できるフィーチャをベースにしたバリエーションテーブルを用意し、ビジネス側の合意を得るようにすることが重要です。また、後に発生するであろう要求変更の最小化にもつながります。ビジネス側からあるフィーチャにバリエーションを持たせるように要求された場合、共通部品と考えていたモジュール内に可変点を設け、共通部分と可変部分に分けなければならないかもしれません。開発が進んでからこのような要求をされるのに比べて、バリエーションを含めたフィーチャをベースに、製品計画を早い時期から立て、開発が進むにつれ、それを見直せば(フィーチャ優先か、日程優先かも含めて)、プロジェクトが成功する確率が高くなります。

ソフトウェア プロダクトライン(SPL)はコア資産を高品質に保ちながら進化させるために、製品開発とは別組織または別チームがコア資産開発を行います。欧米では、通常、上級管理層がリスクをとり、トップダウンで組織や開発手法を変更します。日本におけるソフトウェア プロダクトライン(SPL)の成功事例が少ないのは、トップダウンで物事や手法を変更する組織が少ないからでしょう。
では、穏やかに、日本的にボトムアップでソフトウェア プロダクトライン(SPL)を始めるには、どうすればよいかを考えてみましょう。
新フィーチャを含め、今後も進化が見込まれるフィーチャに関連する部分に対して、リファクタリングを行いながら共通部分を切り出します。次期製品では、この共通部分をそのまま再利用する、または、その中に可変点を設けてバリエーションを持てるようにします。そしてさらに広く共通部品と可変部品の切り出しを続けます。この可変部分を含めた共通部分がコア資産になります。コア資産化にはソフトウェアのソースコードやバイナリモジュールだけでなく、フィーチャを起点にした外部設計、モデルを含んだ内部設計のような関連付けされた中間成果物も含まれます。加えて、テスト仕様書やテストケースもフィーチャに関連付けて、コア資産として管理します。これらを資産化することにより、ソフトウェア プロダクトライン(SPL)の成果を最大限に享受できるようになります。 

複雑なソフトウェア プロダクトライン(SPL)ライフサイクルを管理/統制するためにAccuRevを使う

ソフトウェア プロダクトライン(SPL)(以降はSPLと記載します。)はソフトウェアモジュールを組み合わせることによって、なるべく短期間、かつ、低コストで多種製品をリリースする方法論です。そのため、単一製品の開発よりもしっかりしたプロセスと構成管理能力が要求されます。不十分であった場合、逆に非効率的な開発になりかねません。また、製品ごとのブランチにフォルダーやファイルをコピーするといった従来の構成管理の手法のままSPLを導入すると、間違いも混入しやすくなります。AccuRevは構成管理とプロセス管理を同時に行えるユニークな構成管理ツールです。手動でのファイルのコピーが必要なく、共通部分と可変部分の管理負荷を大幅に軽減します。 

図1

図1

図1のように、AccuRevのストリームにより製品開発側(Prod1、2)はコア資産のモジュールをコピーすることなく、それぞれの製品開発へコア資産を展開できます。またこの例では、ロック機能により製品開発側からのコア資産化を禁止しています。※ストリームの概念は、デモムービーをご参照ください。

図2

図2

図2はSPL開発の支援ツールあるpure::variantsとAccuRevを連携させている様子です。フィーチャモデルとソフトウェアモジュールなどのソリューションを管理するファミリーモデルをコア資産とし、フィーチャが選択されている定義ファイルとコア資産から製品(variant)を導出します。この後、Outputフォルダーに導出された特定製品モジュールをリリースするためにProd1 streamに「プロモート」します。

図3

図3

SPLライフサイクルにおける進化/変化は通常の単一製品開発ライフサイクルにおける進化/変化よりも多次元的です(図3)。通常の開発と同様に、要件開発、設計、実装、テストフェーズが反復的に行われますが、その間に要件、設計、実装の変更がコア資産開発と製品系列開発にも当然存在します(反復的マルチフェーズ)。
このように複雑なSPLライフサイクルを管理/統制するには、ソースコードのバージョン管理とフォルダー単位のコピーと変更では対応不可能か極めて非効率的です。
AccuRevを使えば、そのストリーム構成によって、プロセスに沿った成果物の管理が容易にできるので、反復的マルチフェーズに伴う複雑さを簡単に解消できます。そしてストリームの継承能力とクロスリンク機能により、コア資産開発と製品系列開発との間に起きる不整合、さらに保守時の変更漏れを防止できます。
AccuRevでは、スナップショットという変更不可能な成果物としてベースラインを作成し、このスナップショットを元に次リリースを開発します。各マイルストーンでのスナップショットとAccuRevの追記型データベースにより、ベースライン間の成果物の変更に対する完全なトレーサビリティが提供されます。
変更に際して、変更原因元から影響を受ける成果物(要件定義書~テストケース/テスト結果まで)のトレーサビリティは、影響分析と品質を担保するレビュー/単体テスト/結合テスト/システムテストの効率化に必須です。そのような中で、課題間の依存関係定義および課題と成果物の関連付けができる課題管理ツールAccuWorkを内蔵しているAccuRevは大きな力となります。
AccuRevの持つユニークで柔軟なストリームベースのアーキテクチャが複雑なSPLライフサイクルの管理と統制を可能にし、中長期的な組織の競争力アップに貢献します。

構成管理・変更管理ツール AccuRevに
関するお問い合わせ

  • テクマトリックス株式会社
    東京本社

    ソフトウェアエンジニアリング事業部

    03-4405-7853

メールでのお問い合わせ
accurev-info@techmatrix.co.jp

CONTACT

製品についてやテクマトリックスについてなど、
こちらよりお気軽にお問い合わせいただけます。