派生開発における調査プロセスについて、提言を見つけました。
導入にあたり、特殊なツールを使用するわけでもなく、開発現場で活用しやすい内容だと思えたため、整理して共有させて頂きます。
「調査」というプロセスそのものは、あらゆる業務で必要かと思います。
ここでは派生開発という文脈でそのプロセスを考察し、改善案の導入を試みます。
###参考文献
こちらの論文を拝読しました。
ただし、本記事の内容は論文そのままではなく、少し執筆者個人の見解を混ぜています。
https://www.juse.or.jp/sqip/workshop/report/attachs/2014/sqip6-a.pdf
##背景：不具合分析から見える開発プロセス上の問題点
各開発プロセスにおける不具合の関連、影響は以下のようになっています。
※ここではテスト設計などの工程は含まれていない
（A）変更要求（要求分析）の問題：変更要求を正しく捉えられなかったことに起因する不具合
不具合発生率：低い
手戻り工数：小さい
（B）変更内容（仕様設計）の問題：変更仕様を正しく設計できなかったことに起因する不具合
不具合発生率：高い
手戻り工数：大きい
（C）調査方法の問題：変更の影響範囲の特定、変更による影響を正しく洗い出すことができなかったことに起因する不具合
不具合発生率：高い
手戻り工数：大きい
（D）実装の問題：正しく実装できていなかったことに起因する不具合
不具合発生率：低い
手戻り工数：小さい
「B」と「C」はともにQCDへ与える影響が大きいようです。
「B」に関しては、派生開発に特化したプロセスであるXDDPによって解消する可能性があります。
そこで今回は「C」を解消するためのプロセスを説明していきます。
#派生開発における調査プロセス上の問題点とそれに対する解決策
派生開発の調査プロセスにおいて、問題点は2つあります。
それぞれ、提言を述べた後に問題点を説明していきます。
1．調査時のソースコードリーディング（深さ優先探索 vs 幅優先探索）
2．調査目的の整理、調査結果の記録
##1．調査時のソースコードリーディング（深さ優先探索 vs 幅優先探索）
ソースコードリーディングをする際は、1つの関数を最後まで見てから次の関数を見るべきです。
調査している関数内に新たな関数が現れても、個々の関数ごとに最後まで調査するアプローチです。
つまり以下のようにしましょう。
ソースコードリーディングは、深さ優先探索ではなく幅優先探索で行う
これはソースコードリーディングに関する多くの記事で言われていることで、XDDPでも推奨しているアプローチです。
初めから詳細に処理を追っていくアプローチは、あまり効果的ではありません。
※もちろん、既にある程度把握しているソースコードが対象であればこの限りではない
1つの関数毎に処理内容を調査するため、関数の構造図やPADをスムーズに作成できます。
そのため、調査進捗が明確に表現でき、調査の中断/再開や引継ぎが容易になります。
一方、深さ優先探索は、関数が現れるたびにその関数の中に次々と入って調査を行います。
深さ優先探索の問題点を4つ記載します。
###深さ優先探索の問題点
#####問題点1：処理の捉え方による問題
以下2つの探索法は、それぞれ処理の捉え方が異なります。
A．幅優先探索 ・・・ 処理を構造（面）で捉える
B．深さ優先探索 ・・・ 処理を順番（線）で捉える
このことから、BはAに比べると調査時の視野が狭くなります。
そのため、より効果的な変更箇所が他に存在することに気付けない可能性が高くなってしまいます。
また、Bだと関数群の役割を把握できないため，変更に対する影響箇所の特定が困難になります。
※一般に、機能を実現するのに 10 数個から数 10 個の関数がそれぞれの役割を分担して組み立てられていると言われている
#####問題点2：処理の把握コストに関する問題
深さ優先探索だと、複数の関数を往来するなど、ソースコードを辿ることに時間がかかります。
対象の関数ネストに対して、脳内メモリのスタックを割り当てることになるため、調査時の負荷も大きくなります。
#####問題点3：目的の異なる調査を同時実施することによる問題
変更箇所や方法によって影響を受ける箇所が変わります。
そのため、調査は「変更箇所の特定」⇒「影響を受ける箇所の特定」の順に実施する必要があります。
しかし深さ優先探索での調査では、目的別に調査を区別して実施できません。
そのため、変更箇所が変わった時、それによる影響箇所の変化に気付かず、影響箇所を誤認してしまったり、抜けてしまったりします。
#####問題点4：調査結果に関する問題
深さ優先探索では、調査している関数の中に新たな関数が現れると、その関数の中に入っていくことになります。
そのため、調査時に辿った経路を記録することしかできません。
これでは、調査結果がレビュー時や次の派生開発時にも使えるような調査資料になりません。
##2．調査目的の整理、調査結果の記録
目的が異なる調査を同時に行ってしまうことで、調査結果がQCDに致命的な影響を与えてしまいます。
そこで、目的ごとに調査を3フェーズに分けて行いましょう。
A．事前調査：システム構造を理解するための調査
B．変更箇所特定調査：変更箇所を特定するための調査
C．影響調査：影響範囲を特定するための調査
###A．事前調査
要求内容、そして開発対象システムを理解するために実施します。
予め知っておくべきシステムの構造や動作を把握する調査、調査範囲を決めて調査し、成果物を残します。
この調査では、変更箇所を特定しません。
つまりソースコードの詳細を理解するフェーズではありません。
構造図を作成する際には、1つの関数に対して1分程度の時間となります。
調査対象の関数の数と調査に使える工数から、どの程度の数だけ関数を調査できるかを計算し、調査範囲を決定します。
※1つの関数が大きい場合はより時間がかかるが、それは設計の問題である
###B．変更箇所特定調査
変更要求を実現するために必要な、システムの変更箇所を特定するために実施します。
※XDDPの「スペックアウト」に相当する
ソースコードを追って、詳細を理解しながら変更箇所を探します。
###C．影響調査
システムの変更によって、影響が及ぶ箇所を特定するために実施します。
※XDDPの「スペックアウト」に相当する
変更方法や変更箇所によって影響の内容が変わるため、変更箇所特定調査が完了した後に実施します。
#まとめ
1．ソースコードリーディングは、深さ優先探索ではなく幅優先探索で行う
2．調査は、「事前調査」⇒「変更箇所特定調査」⇒「影響調査」の3フェーズに分けて行う
ソースコードリーディングの方法論については、別途記事にする予定です。