ニュース

【ベリサーブ ナビゲーション2014年秋号】掲載記事「派生開発の世界と検証」No.2

2014.11.20

ベリサーブ ナビゲーション2014年秋号掲載記事

「派生開発の世界と検証」
派生開発とXDDP

派生開発とXDDP(*1)(eXtreme Derivative Development Process)については、AFFORDD(派生開発推進協議会:http://www.xddp.jp/index.shtml)のHPを参照すると詳しく紹介されています。ここでは検証の視点で、派生開発とXDDPを解説したいと思います。最近では、新製品の開発といっても0から全てを設計するスクラッチ開発はほとんどありません。新製品の開発であっても、既成のソフトウェアを部分的に手を加えた変更開発です。それらに加え短納期での開発が要求され、このことが派生開発に注目があつまる背景となっています。ここに発生するのが変更部分にフォーカスした部分理解による開発ですが、なぜ部分理解で開発することが可能なのでしょうか。

構造的に作成されたソフトコードは、呼び出し型の関数(型)になっています。部分的な理解を進めるには、変更対象となるソフトコードが含まれる関数とその引数を理解することから始まります。そして、対象となるのソフトコードを変更することによる影響範囲の考慮を広げていきます。影響範囲を検討することは、検証でも実施されています。例えば、不具合修正後の回帰テストでは、影響がありそうな部分を中心にデグレードを起こしていないことを確認します。回帰テストを計画する場合に、影響範囲はどのように考えられているでしょうか。”全テストのやり直し”を実施しているプロジェクトは少ないと思います。参考ですが私の場合は、次のような影響分析を実施しています。

  1. 変更モジュール(ソースコード)の対象部分
     変更したプログラムのアルゴリズムや、コードカバレッジなど
  2. 変更モジュールと直接I/Fをとる関数群
     変更したプログラムを呼び出す関数との関係など
  3. 呼び出し/復帰I/F周辺
     変更したプログラムの呼び出し変数の型式など
  4. 状態の変化および状態が関連する機能群
     変更したプログラムに影響する状態の変化など
  5. グローバル変数で関連する機能群(要注意)
     変更したプログラムが利用するグローバル変数など

上記は、序列になっていて、後半部分の分析では、広範囲に及びます。気づいた方も多いと思いますが、私の回帰テストの分析方法は、俗に「グレーボックステスト」に近い分析を行います。

(*1)XDDPは、株式会社システムクリエイツの清水吉男氏が提案された開発プローチ

開発環境の変化にどう対応するか?

派生開発での成果物の分析方法を解説する前に、開発環境の変化と検証についてお話します。開発環境などを説明するのには理由があります。検証にとって、「開発環境の変化にどのように対応すれば良いのか」が、大きな課題です。
XDDPをはじめとする派生開発やリーンスタートアップ開発、イテレート開発などのアジャイル開発がとり沙汰されていますが、検証がテストに対応できていないとよく聞かれます。実は・・・

・・・続きを読む・・・

「続きを読む」をクリックすると「資料ダウンロード」ページへ遷移します。

【関連ページ】

VsAutoStudio

テスト自動化ソリューション

【バックナンバー】

ベリサーブ ナビゲーション 2014年夏号「派生開発の世界と検証」No.1