『変更の影響範囲を特定するための「標準調査プロセス」の提案』

影響調査に関連する論文

変更の影響範囲を特定するための「標準調査プロセス」の提案, 2014

変更の影響範囲を特定するための「標準調査プロセス」の提案

1. どんなもの？

精度の高い「標準調査プロセス」について

調査者の調査スキルのバラツキを抑えて調査するにやり方について

2. 先行研究と比べてどこがすごい？

先行研究はXDDP

3. 技術や手法のキモはどこ？

関数の探索ルートは、幅優先探索のような図を作って調査結果を残す

4. どうやって有効だと検証した？

5. 議論はある？

6. 次に読むべき論文は？

本の方

『「派生開発」を成功させるプロセス改善の技術と極意』

『【入門+実践】要求を仕様化する技術・表現する技術 -仕様が書けていますか?』

『「派生開発」を成功させるプロセス改善の技術と極意』

派生開発における影響箇所の把握改善によるテスト範囲の特定方法の提案

ソースコードの探索ルート

これは良いパターン

https://gyazo.com/10fed925ce4dc18aa086578a670275fd

図5-1 関数の探索ルート (P21)

https://gyazo.com/94bcfdf285b893e8302700dec67e798f

図 5-2．調査で残される func1()の構造図 (P21)

この図は構造図という名前になっている。

↓これはダメなパターン

https://gyazo.com/18f69b448c50238e85308e1587507c70

図 5-3. 調査に時間がかかる探索ルート (P22)

PAD(Program Analysis Diagram)

標準調査プロセス

標準調査プロセスを3つのステージに分ける

事前調査

変更箇所調査

影響調査

事前調査

依頼内容を理解するために実施する、予め知っておくべきシステムの構造や動作を把握する調査。調査範囲を決めて調査し、成果物を残す。この調査では変更箇所は探さない。

構造図を作成する際には、1関数に対して大体1分程度の時間となる。その値と調査対象の関数の数と調査に使える工数から、何関数を調査できるかを計算し、調査範囲を決定する。

変更箇所調査

変更要求を実現するために必要な、システムの変更箇所を特定する調査（ XDDP でいう「スペックアウト」に相当する）。

ソースコードを追って理解しながら変更箇所を探す

ひととおり変更仕様が抽出できたら調査を終了する

影響調査

システムの変更によって、影響が及ぶ箇所を特定する調査。（XDDP でいう「スペックアウト」に相当する）

変更箇所があるとは限らない

変更箇所調査が完了した後に実施する。理由としては、変更方法や変更箇所によって影響の仕方が変わるため。

調査プロセス

付録 2：調査プロセスのテンプレート（調査テーマ記入シート)

https://gyazo.com/70e1122580befb11494cd66618e67a0e

https://gyazo.com/09d3822f83744a5b64924a23ff80bca0

(P19)

https://gyazo.com/38f4f5db69519de2432d75618e9ae9bf

https://gyazo.com/1490e0f66519a56c905c31ef4c69420a

(P20)

メモ

プログラム構造表記法（PAD）