本連載では、組込みシステムの派生開発で起こりがちな問題とその対策について説明していきます。今回は、工数見積もりの問題を取り上げます。

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

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

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

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

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


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

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

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

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

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

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

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

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

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




デモやお見積りのご依頼などのお問い合わせへのリンク

既存モジュール変更の影響がプログラム全体へ波及




デモやお見積りのご依頼などのお問い合わせへのリンク