変更の影響範囲を特定するための「標準調査プロセス」の提案 2014年ソフトウェア品質管理研究会（30SQiP-A）

Size: px

Start display at page:

Download "変更の影響範囲を特定するための「標準調査プロセス」の提案 2014年ソフトウェア品質管理研究会（30SQiP-A）"

あいぞうたみや
7 years ago
Views:

1 変更の影響範囲を特定するための標準調査プロセスの提案 2014 年ソフトウェア品質管理研究会 [ 第 6 分科会 A グループ ] リーダー : 宇田泰子 ( アンリツエンジニアリング株式会社 ) 夛田一成 ( アンリツエンジニアリング株式会社 ) 川井めぐみ ( サントリーシステムテクノロジー株式会社 ) 伊藤友一 (TIS 株式会社 )

2 1. 研究の動機研究員の現場では調査を行なっているにも関わらず影響範囲の調査漏れによる不具合が後を絶たないなぜ変更の影響範囲を特定できないのか? 研究スタート当初我々が思っていたこと担当者がシステム全体を把握し切れていない調査のやり方が担当者の力量 ( 経験 ) に依存調査結果が担当者以外と共有できない影響調査漏れどうにかして影響範囲の特定の抜け漏れによる手戻りを防げないだろうか

3 2. 現状分析 (1/2) 115 件の不具合事例を分析不具合の内訳 A. 変更要求 B. 変更内容 ( 件数多 ) C. 調査方法 ( 手戻り大 ) D. 実装原因として考えられること図 1. 不具合件数と手戻り工数 A. 変更要求の理解不足 XDDP(USDM 等 ) で改善 B. 仕様変更の検討が不十分 XDDP( 変更要求仕様 ) で改善 C. 調査方法調査結果に不備着目! D. 実装ミス XDDP( レビュー強化等 ) で改善

4 2. 現状分析 (2/2) 変更の影響範囲を特定する調査方法のヒヤリング (1) やったこと実態を把握するため開発者 27 名にアンケート実施 (2) わかったこと調査の一括りで色々な作業をしている ( ムリ ) 例. 基本的な構造の理解変更箇所の特定影響箇所の特定調査のしかたが人それぞれ ( ムラ ) など例. 調査結果の残し方 ( 文書化していないメモ程度残す内容も様々 ) 調査にムダが多い例. 変更が変わる度もしくは同じ変更でも調査タイミングの度に箇所を調査するいつ不具合が起きてもおかしくない!

3. 解決策 (1/6) 調査プロセスの比較 ( 初心者熟練者 XDDP) 調査の問題点を明らかにするため比較検討を実施項目初心者熟練者 XDDP 変更要求理解するプロセスがない ( 言葉のままに調査を実施 ) XDDP と同じ理解するプロセスがある調査目的明確になっていない ( 複数の調査を一緒に実施 ) XDDP と同じ明確になっている ( 複数の調査を別々に実施 )

5 3. 解決策 (1/6) 調査プロセスの比較 ( 初心者熟練者 XDDP) 調査の問題点を明らかにするため比較検討を実施項目初心者熟練者 XDDP 変更要求理解するプロセスがない ( 言葉のままに調査を実施 ) XDDP と同じ理解するプロセスがある調査目的明確になっていない ( 複数の調査を一緒に実施 ) XDDP と同じ明確になっている ( 複数の調査を別々に実施 ) ソースコードの探索ルート関数を順に辿り処理の経路を調べる XDDP と同じ一つの関数を最後まで確認した後次の関数を確認する調査資料の残し方メモ書きもしくはなしメモ書き構造図チャート構造図 PAD ソースコードの理解の仕方ソースコードを読みながら理解初心者と同じ構造図や PAD などに変換し書き出してから理解変更による影響範囲の特定で抜けや漏れに気付きにくい原因はソースコードを調べる際の探索ルートに問題あり

3. 解決策 (2/6) 探索ルートの問題探索ルート B: 関数を順に辿り処理の経路を調べる XX func1(xx, ) XX func2(xx, ) XX func3(xx, ) XX func4(xx, ) XX func8(xx, ) func2(); func4(); func6(); func8(); func3(); func5(); func7(); func9();

6 3. 解決策 (2/6) 探索ルートの問題探索ルート B: 関数を順に辿り処理の経路を調べる XX func1(xx, ) XX func2(xx, ) XX func3(xx, ) XX func4(xx, ) XX func8(xx, ) func2(); func4(); func6(); func8(); func3(); func5(); func7(); func9(); 探索ルート B 以下が内部データ保持の処理 func1() // 受信データ設定 func2() 次に各大項目レベルでの値格納処理に飛ぶ func4() 図 3. 探索ルート B の成果物 ( メモ ) 図 2. ソースコードの探索探索ルート B の悪い点 (1) 範囲が狭い ( 線で捉えている ) (2) 目的 / ステージを意識していない (3) 構造を把握できない (4) 活用できる調査結果が残らない

7 3. 解決策 (3/6) 探索ルートの問題探索ルート A: 個々の関数ごとに最後まで調べる (XDDP 推奨 ) XX func1(xx, ) XX func2(xx, ) XX func3(xx, ) XX func4(xx, ) XX func8(xx, ) func2(); func4(); func6(); func8(); func3(); func5(); func7(); func9(); 探索ルート A 探索ルート B func2() func1() func3() func4() func5() func6() func7() 図 4. 探索ルート A の成果物 ( 構造図 ) 図 2. ソースコードの探索探索ルート A の良い点 (1) 漏れを起こす状況を改善できる (2) 調べる時間を短縮できる 1 関数 1 分など見積もりが可能となる (3) 全体の構造を把握できる (4) 調査結果を活用再利用できる

8 3. 解決策 (4/6) 問題解決のため標準調査プロセスを定義プロセスの統一および調査結果記録のテンプレート作成標準調査プロセス調査ステージプロセス定義明文化熟練者のノウハウチェックポイント調査プロセスガイドライン変更による影響範囲の特定漏れを低減できる現場で標準調査プロセスを効果的に活用できる初心者の調査を支援できる初心者の育成に効果が期待できる現段階では処理の流れなどの静的な構造の理解を目的としており動的な振る舞い ( 例 : 状態遷移タイミングチャート ) の理解については対応していない

9 3. 解決策 (5/6) 調査ステージの定義 No 調査ステージ説明 1 事前調査 2 変更箇所調査 3 影響調査依頼内容を理解するためや予め知っておくべきシステム構造や動作を把握するために実施する調査調査範囲を事前に決める把握した構造などを成果物として残す変更箇所は探さない変更要求を実現するためやシステムの変更箇所を特定するための調査 XDDP でいうスペックアウトに相当するソースコードを理解しながら変更箇所を探すひととおり変更仕様が抽出できたら調査を終了するシステムの変更によって影響が及ぶ箇所を特定するための調査 XDDP でいうスペックアウトに相当する変更方法や変更箇所により影響を受ける箇所が変わるため変更箇所調査が完了した後に実施する変更箇所があるとは限らない調査ステージを定義することで変更による影響範囲の特定漏れを低減できる

10 3. 解決策 (6/6) 調査プロセスのステップステップ 1 基本パターン 1 か 2 を決定する変更箇所を特定できる構造や処理の流れを理解している基本パターン 1 事前調査変更箇所調査影響調査を実施基本パターン 2 変更箇所調査影響調査を実施基本パターン 1 基本パターン 2 判断 No Yes ステップ 2 調査プロセスのテンプレート ( 調査テーマ記入シート ) を記載する事前調査を実施するステップ 3 プロセスチェックポイントと調査実施事例 ( 探索ルートと成果物 ) を参考にし変更箇所調査と影響調査を実施する事前調査変更箇所調査影響調査ソースコードを効率よく漏れなく調査変更による特定漏れを低減有用な資料が残せる

11 4. 解決策の評価 (1/3) 検証方法標準調査プロセスと調査プロセスガイドラインの有用性を判断するために不具合事例を用いてシミュレーションを実施検証内容 (1) 調査のステージを意識して調査を行なうことができるか (2) 不具合事例の原因となった影響を受ける範囲や変更箇所を特定できるか (3) メモ書きではない調査結果が残せるか

12 4. 解決策の評価 (2/3) 結果不具合事例変更の影響範囲調査のステージ結果成果物調査工数構造図作成工数事例 1 無知見事前調査特定できた構造図 5 時間 5 時間 (64 関数 ) 事例 2 無知見事前調査特定できた構造図 4 時間 1.4 時間 (70 関数 ) 事例 3 知見事前調査変更箇所調査特定できた構造図フローチャート 3 時間 1.8 時間 (104 関数 ) 事例 4 知見変更箇所調査特定できたフローチャート 2 時間作成していない事例 5 知見事前調査変更箇所調査特定できなかった構造図フローチャート 1 時間 0.5 時間 (28 関数 ) 調査ステージを意識して調査ができた! 5 件中 4 件特定できた! 構造図フローチャートを残せた!

13 4. 解決策の評価 (3/3) 検証の考察 (1) 調査のステージの意識づけで変更による影響範囲の特定漏れを低減できる! (2) 調査結果が残せレビューのインプットとなる! 課題動的な振る舞い ( 例 : 状態遷移タイミングチャート ) は別の調査方法が必要となる

14 5. まとめ研究の成果標準調査プロセスと調査プロセスガイドラインを作成したその結果以下の成果が得られた適切な調査のステージで適切な調査を行なえる処理の流れなど静的なケースにおける変更による影響範囲の特定漏れを低減できるレビューのインプットになる調査結果を残せる今後の課題動的な振る舞いの理解を目的とする調査方法についても着目し標準調査プロセスと調査プロセスガイドラインを改良していく

15 ご清聴ありがとうございました変更の影響範囲を特定するための標準調査プロセスの提案 Unified investigating process to Detect the range Affected by specification changes 2014 年ソフトウェア品質管理研究会 (30SQiP-A)

短納期開発現場への XDDP 導入手法

短納期開発現場への XDDP 導入手法日本科学技術連盟ソフトウェア品質管理研究会 2012 年度第 6 分科会 B グループ富士ゼロックスアドバンストテクノロジー株式会社南迫祐樹メンバー紹介 2/18 日本科学技術連盟ソフトウェア品質管理研究会 2012 年度第 6 分科会 B グループ < 主査 > 清水吉男 < 副主査 > 飯泉紀子足立久美株式会社システムクリエイツ

変更の影響範囲を特定するための 「標準調査プロセス」の提案 2014年ソフトウェア品質管理研究会（30SQiP-A）

変更の影響範囲を特定するための「標準調査プロセス」の提案 2014年ソフトウェア品質管理研究会（30SQiP-A）