派生開発に特化した「XDDP」は新規開発と何が違うのでしょうか？

• 「ソースコードに展開された仕様」を変更する
• 今回の担当者が書いたソースコードではないことがあり、ソースコードを理解する必要がある
• さらに、時間的な制約が強いため、ソースコード全てを理解してから作業に取りかかるのではなく、変更部分だけを正確に理解する必要がある
• 既存資産に対する「差分」を明らかにし、レビューでモレやミスを防ぐ
• 稼働しているソフトウェアに対して上記「差分」の変更を行う

このような特徴が派生開発にはあります。図で表現すると以下のようになります。

XDDPは、この差分に特化した「変更プロセス」と「追加プロセス」が特徴です。

変更プロセス

変更プロセスは大きく以下の5つのフェーズに分かれます。

＜要求獲得＞
　ステークホルダからの変更要求、変更仕様を獲得します。変更に関する書面だけでなく、インタビューなどを通じて変更の背景や理由を聞き出します。

＜調査＞
　変更が現状の資産（設計仕様やソースコードなど）のどこにあたるのか、 現状の使用がどうなっているのかを確認します。

＜変更要求仕様の定義＞
　ステークホルダの変更要求と現状の資産から、今までの仕様がどう変わるのかをBefore/Afterの形式で「USDM*」のフォーマットで記述します。
　　　　*USDM：Universal Specific Describing Manner　正確な要求仕様を定義するための仕様化の技法。「表記法」＋「考え方」

＜変更箇所の特定と影響確認＞
　表にて、変更要求仕様を「行」に、既存資産（ソースレベル）を「列」にとり、変更に対する既存資産の影響を確認します。この表はトレーサビリティ・マトリクスと呼ばれています。行と列の「交点（セル）」毎に変更設計書を定義します。

＜変更設計＞
　ソースコードレベルの日本語で、既存のコードをどう直すかをBefore/Afterの形式で記述します。

＜実装＞ 
　変更設計書に従ってソースコードを変更します。

追加プロセス

追加プロセスは基本的に”新規開発”のプロセスと同じです。 機能追加によって既存資産が変更になる部分は変更プロセスで対応します。

＜調査＞
　追加プロセスの調査は、既存資産への追加方法を調査し、スペックアウト資料としてまとめます。

＜追加機能要求仕様の定義＞
　追加する機能の要求仕様書をUSDMで記述します。

＜追加機能の設計＞
　世の中にある設計手法（オブジェクト指向、構造化手法など）を用いて設計を行います。

＜実装＞
　設計に基づいてソースコードを作成します。