--------------------------------------
【派生開発の問題点】
 派生開発の工数見積もりの精度が上がらない。頻繁にスケジュールの遅延が発生する。

【原因】
 既存モジュールを修正する工数を見積もる際に、直接的な変更箇所しか考慮しておらず、影響範囲を精査していない。

【対策】
 変更の影響範囲を調べる方法を確立する。ツールを導入するなどして、調査の手間と人的ミス(もれ・ぬけ)を減らす。
--------------------------------------

 
ソフトウェア開発において、工数やコスト、スケジュールなどを正確に見積もることが重要であることは、言うまでもありません。見積もりの正確さは、プロジェクトの成否に影響します。ただし、正確な見積もりを行うことは容易ではありません。例えば、以下のような課題があります。

・見積もりの根拠があいまい
・影響を及ぼす要因が複雑で、定量化するのが難しい
・仕様の細部がいつまでも確定しない
・見積もりのための調査・分析に時間をかけられない etc.

 こうした課題に対処するため、ソフトウェア工学の世界では、古くから工数を見積もるための算定モデルが提案されています。
このようなモデルを活用している企業様もあるかと思います。やっかいなことに、派生開発の場合は、上述の項目に、以下の課題が加わります。

・元のプログラムの構造や細部の処理を、派生開発の担当者が理解できない状況がある
・わずかなコード変更がプログラム全体に影響を及ぼすことがある

 派生開発の担当者が、元のプログラムの開発者と異なることは珍しくありません。その場合、派生開発の担当者が事前に設計書やソースコードを読み込んで、ソフトウェアの構造などを理解するための時間が必要です。

派生開発の工数は、新規モジュールの開発工数と、既存モジュールの修正にかかる工数に分けて考えます。新規モジュールについては、おおむね従来の見積もりの考え方を適用できます。問題となるのは、既存モジュールです。

既存モジュールに変更を加えたときの影響範囲を、1つ1つ調べていく必要があります。例えば、ソースコードの文字列検索(grep)を繰り返すなどして、影響範囲を確認します。根気のいる作業ですが、これを怠ると工数見積もりの精度は上がりません。

このような作業を肩代わりしてくれるツールがソフトウェア影響分析ツール「Re:Zolver(リゾルバー)」です。このツールは、プログラム内部の関数や変数の依存関係をグラフ表示する機能と、内部で使用されている関数や変数、ソース、ラベルなどをリスト表示する機能を備えています。これにより、プログラムのおおよその規模感が分かります。

また、依存関係を示すグラフにおいて、特定の関数(または変数)を選択すると、その関数と呼び出し関係にある関数のみを抽出して表示できます。これにより、特定の関数や変数に変更を加えたときの影響範囲が分かり、派生開発の“隠れた”工数を直感的に理解できます。

尚、Re:Zolverは、オブジェクトコードとシンボル情報、ICE用のデバッグ情報からソフトウェアの構造を分析しています。ソースコードからソフトウェアの構造情報を抽出するタイプのツールと異なり、無効コードやコンパイルスイッチ(#ifdef)などの情報を事前に設定する必要がない、という特徴があります。

次回は、設計書やドキュメントにまつわる問題を取り上げます。

モジュール変更の影響がプログラム全体へ
関数/変数 影響グラフで、影響範囲を把握