Comments
Description
Transcript
設計者自身による設計品質作り込み
SQiP シンポジウム 2011 ソフトウェア品質シンポジウム2011 設計者自身による設計品質作り込み ～ テストエンジニア視点の活かし方 ～ ソフトウェア品質シンポジウム２０１１ 招待講演資料 - 2010年度SQiP Effective Award 受賞 - ２０１１年９月９日 ベックマン・コールター（株） 大立 薫 目次 第１部： ■ メンバー紹介 ■ 研究の背景・目的 ■ テストエンジニアの視点を活用する方法の探索 ・ テストエンジニアによる機能仕様書の作成 ・ Wモデルに従った、設計者による機能仕様とテスト仕様の同時設計 ■ 実験結果 第２部： ■ 事例紹介 1 1 SQiP シンポジウム 2011 メンバー紹介 2009年度（第25年度）ソフトウェア品質管理研究会 第3分科会 組込みソフトウェアの品質作り込みと評価の研究成果 研究員 ★大立 薫 (ベックマン・コールター株式会社) 千葉 美千代 (株式会社エス・キュー・シー) (★発表者) 主査 飯泉 紀子 副主査 田所 孝文 (株式会社日立ハイテクノロジーズ) (株式会社山武) 2 第１部 研究の背景・目的 -機能仕様書の品質と設計品質を向上させる解決方法3 2 SQiP シンポジウム 2011 組込みソフトウェア開発の実態 開発現場で発生している不具合について原因解析を行った結果、 機能仕様書の「仕様記載漏れ」が、「テスト項目漏れ」を引き起こす 割合（53%）が最も高いことが分かった 不具合の内訳は・・・ テスト設計時に発見された不具合の内訳 テスト項目漏れを引き起こす仕様不具合原因 テスト項目漏れの内訳 仕様不具合：86% テスト設計不具合：14% 「設計品質」を向上させるには 機能仕様書の品質を上げることが最重要である！ 4 機能仕様書と設計品質の関係 ■機能仕様書の役割 ・「設計するもののイメージを共有する」 ・「実装するものを伝達する」 ・「テストするもののあるべき姿を伝達する」 システム方式設計 システム結合テスト (1.4.3 - 1.4.5) (1.4.11 - 1.4.12) ソフトウェア方式設計 ソフトウェア結合テスト (1.4.9 - 1.4.10) (1.4.6) ソフトウェア詳細設計 単体・組合せテスト (1.4.7) ここで作成するドキュメントを 『機能仕様書』とする 設計品質に直結！ (1.4.8) コーディング (1.4.8) ※プロセスの番号は ISO/IEC12207の定義による 5 3 SQiP シンポジウム 2011 テストエンジニアの視点を活用した品質向上（最近の動向） ■最近では、テストエンジニアが設計工程のレビューに参画して、テ ストエンジニア視点を活かした品質作り込みが多く報告されている 先行研究事例として・・・ ・テストエンジニアの視点をレビュー時の欠陥検出に生かす ・機能仕様とテスト仕様を同時に同一人物が設計すれば、仕様 の誤りや不備を認識できるようになる いずれも検証可能性の観点を活用した施策である 我々の問題意識は、 「テストエンジニアがテスト仕様を設計するときに気づけることを、 なぜ設計者は設計段階で気づけないのか？」 ということである 6 テストエンジニア視点を活用する方法の探索 -テストエンジニアの視点と設計者が不足しがちな観点7 4 SQiP シンポジウム 2011 テストエンジニアの視点のメリット（仮説１） 先行研究事例として・・・ ・テストエンジニアの視点をレビュー時の欠陥検出に生かす 仮説１： ■テストエンジニアが機能仕様書の欠陥を検出できるのであれば、 テストエンジニア自身が機能仕様書を設計した場合にテストの 観点が自動的に補完されるのではないか？ 実験１： テストエンジニアによる機能仕様書の作成 8 テストエンジニアによる機能仕様書作成の試み ■身近である比較的機能をイメージしやすいシュレッダーを例として、 機能仕様書を作成することとした 被験者： 中級レベルのテストエンジニア１名 目的 ・設計者の心理をテストエンジニアが理解する ・設計者が記述漏れを起こす原因を探る 設計者が記述漏れを起こす原因を探る 9 5 SQiP シンポジウム 2011 機能仕様書作成で気付いたこと（結果） ■設計者の心理 ・設計者が記述漏れを起こす原因 ・視野が狭まる： 対象機能が「正しく動作すること」に焦点を当てながら 記述してしまう ・曖昧な表現を多様 ： 「など」という言葉の使用に抵抗がなくなる ・時間的な問題： 必要最小限の事項のみ記述 ⇒ 記述漏れの一因 転換 しかし、テスト設計時には欠陥を検出できた NG? ⇒設計者の思考からテストエンジニアの思考へ テストエンジニア 転換されたといえる の視点 OK！ 設計者 の視点 10 機能仕様書作成で気付いたこと（仮説１の実証） 仮説１： ■テストエンジニアが機能仕様書の欠陥を検出できるのであれ ば、テストエンジニア自身が機能仕様書を設計した場合にテスト の観点が自動的に補完されるのではないか？ 実証１： 実験結果より・・・ 機能仕様書を作成しているときは、テストエンジニアの視点を 無意識に補完することは困難！ 意識的に補完するしくみが必要 11 6 SQiP シンポジウム 2011 テストエンジニアの視点のメリット（仮説２） 先行研究事例として・・・ ・機能仕様とテスト仕様を同時に同一人物が設計すれば、仕様 の誤りや不備を認識できるようになる 仮説２： ■機能仕様とテスト仕様を同時設計することで、仕様の誤りや不 備を認識できるようになるならば、設計者自ら不足しがちな観 点に気づけるのではないか ？ 実験２： Ｗモデルに従った設計者による機能仕様とテスト仕様の同時設計 12 Wモデルに従った機能仕様とテスト仕様の同時設計 ■Ｗモデルとは、 開発とテストを上流から並行して進めるプロセスモデルである テスト設計を上流工程で行うことで、テスト実施前に、仕様の漏れ、 曖昧な点 矛盾点などを見つけることができること 曖昧な点、矛盾点などを見つけることができること、 そして、すぐに仕様の欠陥を修正できることである ■同時設計とは、 機能仕様とテスト仕様を同時並行して実施し、更に機能仕様と テスト仕様を関連づけする仕組みによって、テスト項目漏れを防止 テスト仕様を関連 けする仕組みによって、テスト項目漏れを防止 することができる 13 7 SQiP シンポジウム 2011 Wモデルに従った機能仕様とテスト仕様の同時設計 ■先行研究事例の同時設計との違い ・設計工程で機能仕様とテスト仕様を設計するが、そのとき、機能 仕様設計者とテスト仕様設計者を別の人で同時設計を行う 機能仕様設計者が 足 がちな観点を見 ける と 機能仕様設計者が不足しがちな観点を見つけること ・テスト設計で検出した欠陥を、確実に仕様書へフィードバック する仕組みがある 機能仕様書の品質を上げることで、設計品質を向上させる 先行研究事例の同時設計 設計者A 機能仕様書 本実験における同時設計 設計者A テスト設計 設計者A 機能仕様とテスト 仕様の同時設計 設計者B 機能仕様書 機能仕様書 同一設計者による同時設計 設計支援 ツールの導入 テスト設計 仕様不明瞭箇所 の明確化 14 Wモデルに従った機能仕様とテスト仕様の同時設計 ■組込みソフトウェア開発プロジェクトで、「同時設計」を試行し、類 似のプロジェクトと比較して効果を評価することとした プロジェクト 同時設計 開発規模 担当者レベル 製品A 未 ベースプログラム： 約1,000KStep 変更規模： 約50～100KStep 類似開発の経験者 製品B 適用 ベースプログラム： 約1,000KStep 変更規模： 約50～100KStep 類似開発の経験者 被験者： 中級レベルの設計者２名 初級レベルの設計者３名 15 8 SQiP シンポジウム 2011 開発現場へ適用した結果 「同時設計」を適応した場合、約50件/仕様書の欠陥を検出でき、 以下の結果となった Wモデル適用前後の検査工程における機能仕様書に起因する不具合件数の比較 仕様記載漏れによる 仕様記述不明瞭による 仕様記載間違いによる 合計 テスト項目抜け テスト項目抜け テスト項目ミス 適用前 15 8 5 28 適用後 0 3 0 3 仕様記述漏れによるテスト項目漏れを防止できたことから 機能仕様書の記述漏れを防止できたと言える 16 テストエンジニア視点を活用する方法の探索 -実験結果17 9 SQiP シンポジウム 2011 設計者が機能仕様書作成時に不足しがちな観点 ■機能仕様書を書くときは誰でも、要求(要件)を機能に展開することに 注力する思考となる ■設計者は開発対象について知識を持っているため、自分自身の価値 基準で考えてしまう 意図的に書かないケース 結果として・・・ 無意識に漏れてしまうケース ・「正常系」の仕様が中心となる ・機能に注力することで視野が狭くなる 機能に注力することで視野が狭くなる これなら わかるだろう ・他機能との関連を見落としがちになる これで十分だ！ という思い込み ？ 18 実験結果 - 総括 実験１: テストエンジニアによる機能仕様書の作成 実証１：機能仕様書を作成するときは、テストの視点を 無意識に補完することは困難である 実験２: Ｗモデルに従った、設計者による機能仕様とテスト仕様 の同時設計 実証２：同時設計を行うことで、 設計者の不足しがちな観点に気づけた テストの観点が 自動的に補完される仕組み として・・・ 機能仕様とテスト仕様の同時設計が効果的！ 19 10 SQiP シンポジウム 2011 第２部 Wモデルに従った機能仕様とテスト仕様の同時設計 -事例紹介20 対象とした開発分野および開発規模 ■被験者： 中級レベルの設計者２名 初級レベルの設計者３名 ■医療機器の計測機器 ■開発規模 ベースプログラム： 約1,000KStep 変更規模： 約50～100KStep 臨床検査システム 組込みソフトウェアの構造 LAN / RS-232C USB 装置制御用 ソフトウェア ユーザ操作用 ソフトウェア 汎用OS リアルタイムOS LAN プリンタ 制御指示/ パラメータ 測定結果 21 11 SQiP シンポジウム 2011 機能仕様とテスト仕様の同時設計プロセス（変更前） ■ウォーターフォールモデルをベースとした開発プロセス ■下流工程でテスト設計とテストの実施 独立したテスト組織がない 設計者自身によるテスト設計の実施 システム方式設計 システム結合テスト (1.4.3 - 1.4.5) (1.4.11 - 1.4.12) ソフトウェア方式設計 ソフトウェア結合テスト ((1.4.6)) ((1.4.9 - 1.4.10)) 単体・組合せテスト ソフトウェア詳細設計 (1.4.7) (1.4.8) テスト 設計書 コーディング (1.4.8) ※プロセスの番号は ISO/IEC12207の定義による 22 機能仕様とテスト仕様の同時設計プロセス（変更後） ■設計支援ツールを上流工程に導入し、同時設計を行える プロセスに変更 独立したテスト組織がない 設計者自身によるテスト設計の実施 システム方式設計 システム結合テスト (1.4.3 - 1.4.5) ソフトウェア方式設計 ((1.4.6)) (1.4.11 - 1.4.12) テスト 設計書 ((1.4.9 - 1.4.10)) 単体・組合せテスト ソフトウェア詳細設計 (1.4.7) （設計支援ツール） 同時設計 ソフトウェア結合テスト (1.4.8) コーディング (1.4.8) ※プロセスの番号は ISO/IEC12207の定義による 23 12 SQiP シンポジウム 2011 現場適用上の工夫 Wモデル導入時の問題 △ ？ ○ × 工数増 導入効果・価値 (1)自分以外が書いた機 能仕様書をテスト設計し、 欠陥を指摘する (2) 仕様書の欠陥により発 生する事象を説明し、設 計者自らが欠陥検出する 価値を共有する (3) どのような欠陥が見つ かったのかメンバー同士 で意見を出し合い、振り返 りを行う 設計者間でテスト設計を試み、これではテストできないという 事態を経験し意識させることが重要！ 24 設計支援ツールの特徴 ■Microsoft Excelで作成したテスト設計書を用いた機能仕様とテスト 仕様の併記 Excelの マクロを ク を 実行 設計支援ツール 機能仕様 リンク貼り付け テスト仕様 Microsoft Wordで機能仕様書を作成 ■設計支援ツールの効果 機能仕様とテスト仕様の対応が明確 ツール開発コスト：５人／日 ・機能仕様とテスト仕様のトレーサビリティが取れる ・機能仕様書へフィードバックできる仕組みがある ※Microsoft Word および、Microsoft Excelは、米国Microsoft Corp.の商標名称です 25 13 SQiP シンポジウム 2011 機能仕様とテスト仕様の同時設計 事例① ■１つの機能仕様書に同時設計を適用するケース この仕組みは、機能仕様とテスト仕様の対応が明確にできるため、機能 仕様に対するテスト設計が漏れなくテストできる 設計支援ツール 機能仕様Ａ Microsoft Wordで 機能仕様書を作成 自動生成 Microsoft Excel マクロ 仕様欠陥の気づきポイント 機能仕様Ａ １ページ目 テスト仕様 １シート目 ・テスト仕様のレビュー ・機能テストの実施 ・３回以上テスト仕様を見る 「集計シート」に、各ページ ごとのテスト項目数を集計 機能仕様Ａ テスト仕様 ２ページ目 テスト管理が可能 2シート目 ・・・ ※Microsoft Word および、Microsoft Excelは、米国Microsoft Corp.の商標名称です 26 機能仕様とテスト仕様の同時設計 事例② ■複数の機能仕様書に同時設計を適用するケース 変更要求と機能を視覚化し、影響を受ける機能仕様書に同時設計を加え ることで、機能間テストも可能となる 設計支援ツール 画面仕様書 仕様書 Microsoft Wordで 仕様欠陥の気づきポイント 通信仕様書 機能仕様書を作成 ・・・ 画面仕様書 テスト仕様 変更要求マトリクス ・機能テストの実施 自動生成 Microsoft Excel マクロ １シート目 定義されている 設計書を展開 ・テスト仕様のレビュー ・機能間テストの実施 ・３回以上テスト仕様を見る 「集計シート」に、各ページ ごとのテスト項目数を集計 通信仕様書 テスト仕様 テスト管理が可能 2シート目 機能 ・・・ 変更要求 ※Microsoft Word および、Microsoft Excelは、米国Microsoft Corp.の商標名称です 27 14 SQiP シンポジウム 2011 テストエンジニア視点の有効活用 設計者が陥りがちな観点とは・・・ 機能仕様作成時 テスト設計時 機能を展開することに注力！ 間違いや漏れがあるはずだ！ 思考の転換 これで十分だ！ という思い込み テスト設計 できない・・・ 第３者による テスト設計 実績・経験による 思い込み 思い込みが 排除される テストの観点が 自動的に補完される仕組み として・・・ 機能仕様とテスト仕様の同時設計が効果的！ 28 機能仕様とテスト仕様の同時設計の効用 機能仕様とテスト仕様の同時設計 設計者A 機能仕様書 機能仕様書 設計支援 ツールの導入 設計者B 別の人による 同時設計 テスト設計 フィードバックする 仕組み 「設計者の思考がリセットさせること」と 「テストの観点」が同時設計によって 自動的に補完されて・・・ 内容を理解するために、 語 句 内容を理解するために、一語一句 読んだり、図解で表現するといった 行動をする 結果として・・・ ・仕様書の欠陥に気づきを与えてくれる 加えて・・・ ・機能仕様書へフィードバックする仕組みにより、機能仕様書の品質が 機能仕様書 フ ドバ クする仕組みにより 機能仕様書の品質が 向上（設計支援ツールによる効果） 同時設計を導入したことで・・・ 仕様もテストも相乗的に品質が向上することを実感！ 29 15 SQiP シンポジウム 2011 設計者がテスト設計する効用 ・設計者間の同時設計により、各設計者が持っている知識で補完すること で仕様書の欠陥を検出できた ・仕様設計者あるいはテスト設計者自ら仕様の欠陥を修正し、再テスト設計 を行うことで、機能仕様書の品質が向上 ・設計者自身がテスト工程も含めて責任を持って作業するようになった Bさんの 知識 Aさんの 知識 テスト者の立場で 機能仕様書がチェックされ 仕様書の欠陥を補完する 機能 仕様 書 仕様作成者の立場で 機能仕様書を自己チェックする テスト者の 視点 実績・経験による 思い込み ＋ テスト設計 思い込みが 取り除かれる 30 まとめ 同時設計の導入により ・設計者の思考の転換、テスト観点の補完 ⇒ 仕様書の欠陥を検出 ・確実に仕様書にフィードバック ⇒ 仕様品質向上、検査工程の不具合削減 ・テストの指摘を仕様書へフィードバック テ 指摘を仕様書 ィ ック ⇒ 設計者 設計者の意識向上 意識向 設計者視点 同時設計 設計者A テストエンジニア視点 自分以外の設計書をテスト設計 設計者B 思考の転換 機能仕様作成 テスト設計 フィードバックする仕組み 機能仕様書の 機能仕様書 品質向上 補完 仕様書の欠陥例 ・条件漏れ、処理漏れ ・処理順序の定義漏れ ・異常ケースの記載漏れ 設計支援 ツールの導入 手法 検査工程の 検査 程 不具合低減 ・状態遷移図（トリガと状態を整理） ・ディシジョンテーブル（時系列整理） ・過去トラ 31 16 SQiP シンポジウム 2011 今後の課題 ■以下のような変動要因を考慮した、効果的な適用ノウハウを継続して 研究する ●対象となる機能仕様書の記載レベル ●設計者のスキルレベル ●対象製品（専門的な知識を有する製品） ■本施策の継続的な推進 32 ご清聴ありがとうございました 17