XDDPは、派生開発の要求に対して必要不可欠なプロセスと成果物の連鎖で構成しており、短納期という状況に対応させるために無駄をそぎ落とした開発アプローチになっています。
以下にXDDPの主な特徴について説明します。
1. 変更プロセスと追加プロセスを別々のプロセスで対応する
派生開発には「変更の要求」と「機能追加の要求」があります。変更の要求は、現状すなわちbeforeの仕様をafterの仕様に変更する方法で実現しますが、機能追加の要求は新しい機能の要求仕様を作成し、設計し実装するというステップで実現します。つまり両者の要求の性質は全く異なるのです。
このため、XDDPでは「変更要求」を実現するプロセスと「機能を追加する要求」を実現するプロセスを別々のプロセスで対応します。これによって機能追加の要求を実現するために、ベースのソースコードをどのように変更して実現するかということを、「変更要求仕様」を対応させる方法で扱うことができます。
一般には機能追加を受け入れるためのベースのソースコードの変更方法は追加機能の担当者に任されています。派生開発のデグレードの多くはこの状況から発生しているのです。
2. 「変更要求」と「変更仕様」を階層構造の中で扱う
「USDM(Universal Specification Describing Manner)」では「仕様は要求の中の動詞にある」というのが基本的な考えであり、この考えの下で「要求」と「仕様」を階層構造で表現して仕様を漏れなく抽出します。XDDPでは、この考え方を「変更」の世界に適用します。つまり、「変更要求の中で表現された”変更する”という行為に変更仕様がある」と考えることで、具体的な変更箇所を抽出しやすくします。
3. 変更仕様をソースコードのレベルで捉える
新規開発や機能追加では、そこで求められている「仕様」を実現する方法はこの後の「設計プロセス」の中で考えられ、レビューのようにその方法が適切かどうかを評価する機会がありますが、変更には通常は「設計プロセス」がなく、変更の実現方法を評価するタイミングがありません。そのため、一般には最後にソースコードレビューを行っているのですが、その効果は限定的なものに成らざるを得ません。
XDDPでは、変更仕様としてソースコードのレベルで記述しますが、そのことによって早い段階で変更の実現方法を評価する機会を確保し、より適切な変更方法の選択を可能にします。
4．基本的に「差分」で作業を進める
ベースのソースコードやこれに対応する機能仕様書や各種の設計書は「公式文書」であるにもかかわらず、一般にはこれらの公式文書を変更しながら作業を進めていて、このことが多くの混乱の元にもなっているのです。
XDDPでは、変更作業は原則として「差分」で進めていきます。ソースコードの変更も事前に差分情報を揃えておいて一気に作業に着手し１回で変更作業が終了します。その結果、ソースコードの変更し直しがなく、必要最小限の工数でソースコードの変更が可能となります。なお公式文書の更新はテストで変更の正しさが確認されてから行います。
5. 「変更３点セット」の成果物で協同作業を円滑にする
変更する箇所の情報を「変更要求仕様書」「ＴＭ(Traceability Matrix)」「変更設計書」の「変更３点セット」の成果物に記述することで、各担当者が予定している変更内容や変更箇所、具体的な変更方法をお互いに知ることができ、早い段階で調整することができます。しかもこの時点では、ソースコードを含めて公式文書は一切変更していませんので、各担当者が参照する情報に混乱は生じません。さらに担当者が変更設計書を揃えて一気にソースコードを変更することで、結合後の混乱もほとんどありません。
一般に行われているような各担当者が該当する箇所を見付け次第に変更してしまう方法では、他の担当者が自分に影響する情報を事前に知る方法がなく、最後にそれぞれの担当範囲を合わせてテストしたところで変更箇所の食い違いや考え方の違いが一気に噴き出すのです。
派生開発推進協議会 初代代表 清水 吉男