ET-West2011 コミュニティーセッション 『組込みソフトウェアでの 品質保証の方法論』 ～品質保証活動の再生に向けて～ ２０１１年６月１６日 ソフトウェア技術者協会（SEA) ＮＡＲＡコンサルティング 奈良 隆正 1 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 2 ソフト開発のプロフェッショナルとは； ①仕事の成果（物）の品質を保証できること、 ②結果に対して責任を持つこと、 ⇒その為には「最適なプロセス、トレーニングされた 要員、適切なツール、品質の監視・改善の仕組み」を 整えたうえでソフトウェア開発を行うこと。 ⇒能力、経験だけでなく取組む姿勢（やる気）が 品質につながることを認識する。 しかしながらソフト開発者は； 品質や品質保証について殆ど教育されていない 3 さらに、ソフト開発者は； ①品質や品質保証について技術教育が不十分である ②品質や品質保証についてマインドが低い とも言われている。 という訳で； 組込みソフト開発者にソフトウェア品質や品質保証 の技術、品質マネジメントの方法論を学んでもらい、 基本的な知識を習得して頂きたい。 4 ソフトウェア品質知識体系ガイドとは？ SQuBOK ガイド ® Guide to the Software Quality Body of Knowledge Qu 日本発のＢＯＫ！ SQuBOK策定部会 編 2007年11月 オーム社より出版 3500円 ® cf. PMBOK ガイド : プロジェクトマネジメント知識体系ガイド （A Guide to the Project Management Body of Knowledge） SWEBOK ® : ソフトウェアエンジニアリング基礎知識体系 （Guide to the Software Engineering Body of Knowledge） 5 ソフトウェア品質の考え方 品 質＝ユーザの満足度 満足度 ユーザ 適合 製品規格 適 ユーザ （市場･特定顧客)の 要求 適合 設計品質 外部仕様 製 品 適合 合（広義） ソフトウェア の 仕様書 適合（狭義） プログラム プログラム品質 内部仕様 6 ＜ソフトウェア品質 二つの条件＞ １、設計仕様がユーザ要求に合致していること。 ２、プログラムが設計仕様を実現化し、仕様通りに正しく動作すること。 設計品質は外部仕様の解釈により定まり、 プログラム品質は内部仕様の正確性によって定まる。 さらに最終成果物のプログラムが 顧客の要求を満たしていること。 7 ソフトウェアの特徴 項 番 特徴と問題点 １ ＜論理の集合であること＞ ・論理の正確な設計が困難 ・論理の信頼性の高いテストが困難 ・正確な開発規模の見積りが困難 ２ ＜目に見えないこと＞ ・品質管理が困難 ・工程管理が困難 ３ ＜個人への依存が高いこと ＞ ・個人差が大きい ・多人数の共同作業 ４ ＜ユーザニーズと直結していること ＞ ・ユーザニーズの正確な理解が困難 ・使用条件の正確な把握が困難 ・なかなか仕様が決まらない ・システムは生き物である（成長する） 信頼性向上への配慮 (1)構造設計とそれに基づくレビュー (2)システムマチックなテスト (1)品質のビジュアル化 (2)開発工程のビジュアル化 (1)開発手法の標準化と自動化 (2)再利用技術 (3)教育 (1)要求仕様分析手法 (2)実使用条件でのテストによる検証 （ex. System Simulation Test） 8 ソフトウェア工学の問題 • ソフトウェアには； – 複雑性がある •ソフトウェア開発の難しさの元 – 順応性がある •如何なる課題にも対応できる – 不可視性である •目に見えない – 変更可能性がある •仕様が決らなくても先に進める 99 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 10 品質保証活動の始まり（‘７０年代） ハードウェア品質管理手法の導入 ←ソフトウェア品質管理未熟 ソフトウェア工場（ファクトリー）制度導入 標準化されたプロセス（手順）を繰り返すことで組織に 開発のノウハウを蓄積し製品の品質を向上させていく手法。 ソフトウェア検査部門の独立化（確立期） 最終成果物の検査：①不良品を出荷しない水際作戦 （開発とＱＡの仁義無き戦い、体力勝負） ⇒物は出来たが殆どは「納期遅れ」であった ＊＊＊この時代の開発エンジニアはエキサイティングであった＊＊＊ ⇒現在の開発エンジニアはどうか？ 11 ソフトウェア工場制度における検査( ‘７０年代) 設計部門 設計開発 テスト 検査部門 不合格 ドキュメント 検査 検査項目 作成 ﾌﾟﾛｸﾞﾗﾑ 検査 合否 合格 判定 出荷 設計工程と検査工程の関係 始まりは幹部の一言、ソフトウェアは製品⇒出荷前に検査せよ 12 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 13 ＳＷ品質保証技術.方法論の確立 【現在の品質保証技術の基礎は‘８０代に開発された】 背景：ソフトウェア開発量の爆発 → 水際作戦（完成品検査重視）から開発フェーズの 品質管理重視へ ソフトウェア工場（ファクトリー）制度の定着、隆盛期 製品完成度重視 日本的品質管理（PDCA、QC７つ道具、全員参加、小集団活動） ソフトウェア検査部門の独立（発展、定着期） 検査部門は開発の全プロセスに対して関与 ☆☆☆クスマノ（MIT）は「日本のソフトウェア戦略」で 日本の高品質ソフトウェアの源と評価 ☆☆☆ 14 ソフトウェア品質管理の体系化と普及 Ⅴ字モデルに基づく管理体系の構築、普及 メトリックスや管理技法の開発、普及 基幹３大メトリックス（バグ、規模、工数） バグ数、テストの目標値の採用 品質目標値管理手法 ＳＲＧＭ，抜取り検査法（探針） バグ分析と水平展開 15 ソフトウェア開発の体系構築 70年代の経験を開発標準として定義、体系化 要求定義から総合テストまでの一通りのプロセスの定義 局面に対応したプロセスの詳細定義（開発部門が主体） 品質改善プロセスの採用 Ｖ＆Ｖに基づく品質確認プロセス採用 各種レビューの適用、定着 ＊品質管理の隆盛期、現在の手法はこの時代に 確立された＊ ＊＊これが現在に継承され、進化しているか（？）＊＊ 16 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 17 ソフトウェア品質保証のフレームワーク 不具合を 作り込まない 活動 ソフトウェア 不良入り 込み分布 設計活動 プロセスの構築 要件分析 プロセスで 押さえる ソフトウェア 開発 プロセス システムテスト 外部設計 内部設計 結合テスト 単体テスト プログラミング 不具合を 摘出する活動 （１）品質作り込みの 手順や標準の確 立： 不良摘出 分布 摘出活動 （２）プロセスが機能し 成果物が正しいことを 確認： 公式レビュー、 監査など （３）成果物の確認： 検証と妥当性確認 ソフトウェア開発プロセスを中心に、３つの側面を重視して ソフトウェアの品質保証を行う 出典：「ソフトウェア品質保証入門」、保田勝通、奈良隆正 日科技連出版社、２００８.０４ 「組込みプレス Vol.2:商品の価値として、ソフトウェアの品質を作り込む」、技術評論社、2005.10。 18 1.ソフトウェア開発プロセスの定義 （１）ウォータフォールモデル 計画 フェーズ 設計 フェーズ 経営情報化 業務 開発 戦略 構想 改善 計画 製造 フェーズ 移行運用 保守フェーズ プログ ﾃｽﾄ 品質 ラム 改善 要求 外部 内部 NW ﾃｽﾄ 定義 設計 設計 設計 計画 移行 運用 性能 資源 障害 ｾｷｭ AP ｼｽﾃﾑ 管理 管理 管理 管理 ﾘﾃｨｰ保守 保守 開発方法論の基本はウォータフォールモデル ⇒８０年代に基本形確立、以降徐々に詳細化が進んだ 19 （２）スパイラルモデル 累積コスト 選択肢評価、 リスク分析と解決 目的、選択肢、 制約の決定 リスク分析 リスク分析 リスク分析 リスク分析 操作可能なプ ロトタイプ プロトタイプ3 プロトタイプ2 プロトタイプ１ ライフサイクルの 計画 レビュー シミュレーション、ﾓﾃﾞﾙ、ベンチマーク 運用の概念 ソフトウェア要求 詳細設計 開発計画 統合とテスト の計画 要求の有効性 評価 設計の有効性 評価と検証 単体 統合と ｺｰﾃﾞｨﾝｸﾞ テスト テスト 受入テスト 次のフェーズの計画 本番 次レベルプロダクトの開発と検証 20 2.デザインレビューと監査 公式レビュー 合格 → 次工程開始 達成度を審査 不合格 → 再審査 利害関係者が 実施 分析 設計 実装 テスト ソフトウェア開発プロセス 基準の遵守 状況を確認 遵守 非遵守 → 是正処置 監 査 客観的に 第三者が実施 ※公式レビューと監査を組み合わせて実施する場合もある □ 品質作り込みのプロセスが機能していることの確認が重要 出典：小笠原他、東芝におけるSPI活動事例～現在・過去・未来～、第3回ソフトウェアプロセス改善 ワークショップ(JASPIC主催)、2006.6 21 ３． V＆V（検証と妥当性確認） 妥当性確認 要求定義 検証 機能設計 機能テスト 検証 構造設計 検証：正しく作ったか ①デザインレビュー ②ソフトウェアインスペクション V＆V 結合テスト 検証 モジュール設計 受入テスト コーディング モジュールテスト 妥当性確認：正しく作られたか ①動的テスト （verification＆validation） 22 KYASUDA Copyright (c) 2005 TIU • 「検証」と「妥当性確認」とは？ – 検証（Verification） • 「検証」の目的は、選択された作業成果物が、指定された 要件を満たすことを確実にすることである – 「それを正しく構築した」ことを保証する making the thing right – 妥当性確認（Validation） • 「妥当性確認」の目的は、成果物または成果物構成要素 が、意図した環境に設置されたときにその使用意図を充 足することを実証することである – 「正しいものを構築した」ことを保証する making the right thing • IＶ＆Ｖと呼ばれることも – 検証の独立性を重視する観点から、IV&V（ Independent Verification and Validation：独立検証と妥当性確認） と呼ばれることもある 23 4.Ｖ字モデル 品質を作り込む工程 品質を確認する工程 要求の検証 要求分析・定義基本設計 製品検査 ユ－ザニ－ズ分析結果の妥当性 要求定義の正当性 機能設計 各工程の製品評価 製品のできばえの評価 総合テスト 機能の検証 機能の十分性 プログラム全体の確認（機能、性能 等） 動作性の評価、性能の評価 検出バグ数の妥当性、バグ分析 構造設計 構造の検証 組合せテスト 機能の十分性 モジュール間インターフェース確認 動作性の評価、性能の評価 検出バグ数の妥当性、バグ分析 論理設計 論理の検証 論理設計 詳細ロジックの保証 モジュールテスト単体でのテストによる確認 性能目標値の保証 検出バグ数の妥当性、バグ分析 コーディング 詳細ロジックとソースが等価性の保証 V字モデル 24 (1)組込みソフトのテストのフェーズ：上位Ｖモデル 要求分析 requirement システム設計 system architecture 量産実機テスト 試作機テスト ソフトウェア設計 software シミュレータテスト architecture 出展：SESSAME 25 (2)組込みソフトのテストのフェーズ：下位Ｖモデル 要求分析 基本設計 requirement architecture 詳細設計 structure システムテスト 結合／機能テスト 単体テスト logic コードインスペクション 実装 code 出展：SESSAME 26 (3)不良の作込みと摘出の関係 設計努力 不良作り込み分布 検 証 総 合 結 合 運用開始 テスト 単 体 コーディング 構造設計 計 機能設計 開発工程 基本設計 設 作り込み不良の低減 不良摘出分布 摘出努力 品質リスクを最小 にする努力が必要 不良の早期摘出 不良分布 27 （参考１）不良修正のコスト（国内の例） 50 20 相対コスト ¥ 10 5 2 1 0.5 受 入 れ テ ス ト 用 計 開 発 テ ス ト 運 設 コーディング 要求設計 0.2 0.1 コーディング工程で作り込んだ不良 テストで発見 ： 相対コストは、約２倍 運用テストで発見： 相対コストは、約１０～５０倍 一番コストがかかるのは、下流のテスト工程での不良発覚 （社外事故の場合、コストはＭａｘとなる。） 28 出展：日本規格協会 「ソフトウェア品質ガイドブック」 （参考２）不良修正のコスト（国外の例） 「ソフトウェア開発 201の鉄則(日経BP社)」では、原理41で要求仕様誤りの 修正コストについて述べられている。 要求仕様誤りを「１」とした場合の修正コスト 設計段階..........5倍 コーディング時...10倍 テスト段階.......20倍 納入時点........200倍 ※修正コスト以外に、日程遅延や信用失墜などの損失あり 要求仕様 設計段階 コーディング テスト 納入時点 29 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 30 １．レビューの技術 １．１ レビューの定義と概要 （１）デザインレビューとは －設計工程の主要な切れ目で行われる見直し作業 －審査で設計上の欠陥を摘出、修正と改善余地の検討 （２）デザインレビューの目的 ①成果物の品質評価（不良摘出を含む）による品質向上 ②成果物の評価による進捗状況の把握 ③上流工程での品質作り込みによる、手戻り削減と生産性向上 ④レビュー結果を開発技術／技法やプロセス改善に役立てる ⑤担当者以外の仕様理解者を増やす、レビュー参加者のOJT 31 （１）レビューの目的 １．成果物の品質の早期向上⇒開発の早い段階での発見 ２．技術やプロセスの早期改善 (技術：設計、コードの実現手段、方法） ３．プロジェクト／組織のマネジメント⇒進捗、ルールの適正運用 ４．利害関係者の合意形成とコミュニケーション⇒コンフリクト解消 ５．メンバーの教育⇒必要知識の共有、レビュー技法 ■ 一言でいうと、成果物の品質向上は勿論、教育、知識共有、 組織（ティーム）文化浸透などの効果的仕掛け 32 （２）デザインレビューの要点 工程 デザインレビュー 基本／機能設計 構造設計 詳細設計 機能ＤＲ 構造ＤＲ 詳細ＤＲ ・機能 ・信頼性 ・性能 ・保守性 ・使用性 ・移植性 ・プログラム構造 ・インタフェース ・ファイル構造 ・障害処理 ・テーブルの使用方法 ・入出力の妥当性 ・テスト項目内容 信頼性ＩＲの活用 ＤＲチェックリストの活用 図7.1 デザインレビュー（ＤＲ）の要点 33 （３）デザインレビュー成功のポイント ①開発スケジュール表にレビュー工程と日程を明示する ②タイムリーに明確な仕様書（成果物）が作成されること ③適切なメンバーの参画 ④レビューチェックリストの整備と活用 ⑤過去の不良事例の整備（編集）、容易な検索、活用 ⑥レビューの事前準備として各種資料が必要 34 １．２ レビューの実際 １．２．１ 色々なレビュー No. 名称 目的 １ ウォークスルー 成果物のエラーの発見 ２ ピアレビュー 不明点や間違（勘違）いの発見 ３ ソフトウェアインスペクション （Faganのインスペクション） 対象の合否判定とプロセス改善 ４ 公式レビュー （節目レビュー） プロジェクトとしての合否判定 ５ コードインスペクション コード上のエラーの発見 35 １．２．２ ウォークスルー （１）ウォークスルーとは⇒成果物のエラーの発見 □ マシンテストに先立って同様の方法でレビューする、すなわち手に よるシミュレーションを行うこと □ 何らかの成果物を開発チーム内の仲間のグループでレビュー すること ⇒ 公式レビューとの違い □ 討議内容、制限時間、合意手続きなどの運営方法は公式レビューと同じように 決めておく （２）実施方法 □ 説明者（＝開発者）、ファシリティータ、レビューア、記録者の５～６名で構成、 担当者が説明、他の参加者がチェックする。実施時間は１～２時間が望ましい □ 原則、参加者に管理者は入れない ⇒結果を個人評価に利用しないための配慮 36 □ レビューアは、エラーを発見できる能力を持つと判断されたひと １．２．３ ピアレビュー （１）ピアレビューとは⇒不明点や間違（勘違）いの発見 □ チーム内の同僚間で行う不明点や間違い、バグなどの検出を目的とする レビューのこと、一般に作業成果物の評価は含まない □ レビューアは担当者以上の能力をもつものが作業経緯や結果精査する □ 誤りの検出だけでなく、さらにより良い成果物を生み出すための方法を提案し 当事者間で議論する （２）実施方法 □ 開発の各プロセス（要求定義、設計、コード作成など）において、その途中段階や 担当者の完了時点で必要に応じて適宜行う。 □ 上司、管理者は参加しない、作業実績に対する評価は行わない 37 １．２．４ ソフトウェアインスペクション （１）ソフトウェアインスペクションとは ⇒対象の合否判定とプロセス改善 □ レビュー対象仕様書（成果物）と当該仕様書作成作業の入力資料（ソース文書）を 比較しながらレビューを行う □ ソフトウェア要素が、その仕様を満足していること、適用標準に従っていることの確 認、標準および仕様からの逸脱が無いこと □ ソフトウェア工学データの収集（例；工数、欠陥のデータ） （２）実施方法 □ 基本的な方法はウォークスルーと類似、但しルールは厳密 □ モデレータと呼ばれる実施責任が、会議を計画／実施、レビューアの選定、結果報 告書、指摘事項の修正確認まで全てを取り仕切る □ 結果の収集分析と有効活用（エラーの分類、タイプの分類、エラーの記録、をして 開発者にフィードバック、類似エラーの摘出を支援） 38 １．２．５ 公式レビュー（節目レビュー） （１）公式レビューとは ⇒プロジェクトとしての合否判定 □ 開発（プロセスの結果）の達成度合いを審査（合否判定）、当該工程のフェーズアウトと 次工程の開始可否を判定する □ レビューの主体は開発部門であり、技術上の総合評価が主題であるが、審査は技術面 のみならず、プロジェクトマネージメント面（管理面、進捗面など）も対象になる □ 参加者（レビューア）はプロジェクトの利害関係者（ＱＡ，ＰＭ，ＳＥ，営業、顧客 、など） 全て、さらに外部の有識者や専門家 （２）実施方法 □ 開発者（＝説明者）が説明、他の参加者がチェックし、不具合を指摘する □ 指摘事項の処置は、後日別途検討し、再審査を受ける □ 関連（必要）資料の事前準備と事前配布 仕様書類のみならず検討に必要な資料（背景、機能概要、方式概要、など） 39 １．２．６ コードインスペクション （１）コードインスペクションとは ⇒コード上のエラーの発見 □ プログラムコードのレビューであり、机上デバッグの一方法論 □ モデレータが居ることで個人のバラつきを排除し、レビューの質を向上する （２）実施方法 □ 説明者（＝開発者）はモデレｰﾀのもと、特定テスト項目、データを想定しプログラ 動作をコード上で追跡する ムの □ 結果（バグ）の収集分析と有効活用（ソフトウェアインスペクションと同じ）により効 （効率）がさらに向上する 果 ◆先人の教訓 （１）他のいかなる手法より欠陥除去の効果が大きい、除去率が常に６０％を超える のはこの手法だけである（Capers Jones） （２）「コード審査」と題する論文では、これで見つけたエラーは全体の８０％を占め た、さらにFagan流の審査では開発資源の１５％を費やすがトータル開発コスト を正味２５～３０％を低減する（アランデービス著、ソフトウェア開発２０１の鉄則） 40 １．２．７ その他のレビュー（IEEE 1028-2008） （１）テクニカルレビュー □ 参加者役割、指摘事項の記録などはインスペクションとほぼ同じ。厳格なルー ルは無く 進行の自由度が高い。 □ 各工程の終盤で行われ、欠陥検出、次工程移行への合否判定、品質管理のための情報 収集などが主な目的 （２）パスアラウンド □ 会議を召集せず、使用書類を紙又は電子ファイルで配布しレビューして貰う。締め切りを 日を設定し、指摘事項を集約する。 □ 対象のシステムを熟知した人をレビーアに選ぶのが基本で有るが、専門分野の有識者に 依頼することもある。欠陥検出、代替案の検討、意見聴取が主な目的となる。 （３）アドホックレビュー □ 疑問や確認事項などが生じたとき、担当者やリーダが他のメンバーに声をかけて少人数 のミーティングで行うレビュー。意見聴取、意識合わせ、が目的 41 １．３ デザインレビュー失敗の要因（１／２） ①論争の場となる ＤＲは問題発掘の場であり、指摘事項に対する評価は 別の場で行うのが原則 ②一方的な説明会となる ドキュメント配布の遅れ、レビュー担当者の準備不足、 ファシリテータの拙さなど ③おざなりなドキュメントで潜在障害要因の指摘が 困難,過去事例からの拡張と負の論理による解析が重要 42 １．３ デザインレビュー失敗の要因（２／２） ④初歩的なミスの持ち込み（予め内部レビューで除去が必要） 開発側がもつ自己審査機能を第３者にシフトでず設計の 考え落し、ミスを他人の目で発見するのが目的 ⑤テーマの山かけ 心配だと思うテーマに絞るのではダメ、障害は騒いでいる ポイント以外で発生しやすい。 ⑥言い放し、聞き放し 指摘事項、問題点は結論が曖昧のまま放置せず徹底的に フォローする ～ つるし上げ、思いつき、数字合わせ、は厳禁 ～ 43 ２． テストの概要 ２．１ ソフトウェアテストの定義 （１） IEEEの定義 「（テスト(testing)とは）、手作業又は自動化された方法で、それが規定された要求事項 を満たすかどうかを検証し、あるいは期待される結果と実際の結果との際を識別する ために、システム又はシステム構成要素を実行し、又は評価する過程。」（IEEE標準『ソ フトウェア工学用語集（ANSI／IEEE Std 729)』） （２） G. J. Myersの定義 「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」（Myers, G.J. （著）『ソフトウェア・テストの技法』） （３）玉井他の定義 「テストとは、エラーをなるべく見つけること、そしてエラーが見つからなければそのプロ グラムの品質に対する確信が増すこと、を目的として、プログラムを選んだデータを実 行し、その結果を評価する作業である。」（玉井哲雄ほか『ソフトウェアのテスト技法』） 44 （補足１） ソフトウェアテストの主な標準（１） ■ ISTQB-FL ●世界で最も普及しているソフトウェアテスト資格認定制度 ⇒LevelはFoundation,Advance,Expertの３段階 ⇒テストは重要なソフトウェアエンジニアリングの一部であり、テス ト技術者のキャリア形成の規準を示す ●テストの定義 テストとはソフトウェアの実行であることが多い。 ソフトウェアの実行はテストの一部であり、全部ではない。 ー 欠陥を摘出する － 品質レベルが十分であることを確認し、その情報を示す － 欠陥の作り込みを防ぐ 45 ２．２ テストプロセス テスト戦略 テスト分析 テスト計画 テスト設計 テスト実行 テスト結果評価 終了判定 テストコントロール 課題：テストアクティビティ早期開始 如何に担保するか！ 46 （補足２） ISTQBのテストプロセスとその定義 (1) テスト計画と作業とコントロール （２） テストの分析と設計 （３）テストの実装と実行 （４）終了基準の検証とレポート （５） 終了作業 47 （１） テスト戦略策定の例 テスト分析が必要！ 品質目標値の設定 テスト完了基準の設定 総摘出目標値の50%以上。 70～80%を目指す。 レビュー/ 机上テストの重視 系統的テストの実施 テスト方式の 選択 外部仕様ﾃｽﾄと内部仕様ﾃｽﾄの併用 テスト項目設定技法の採用 テスト+分性尺度の採用 システムテストの実施 テスト作業の省力化の実現 48 （２）テスト分析とテスト設計の視点 （１）テスト分析の視点 ①ソフトウェアの重要性（社会的影響、使われ方／局面、複雑さ） ②開発の難易度 ③開発方法論 ④開発期間 （２）テスト設計の視点 ①ユーザの視点（どう使うか） ②バグの視点（バグで困ること、影響） ③仕様の視点（何を、何故） ④設計の視点（どのように実現したか） 49 (補足３） SQuBOKにおけるのテストの設計技法（１/3) （１） 経験及び直観に基づいた技法 ⇒アドホックテスト、探索的テスト （２） 仕様に基づいた技法 ⇒各種の仕様書に基づく、ブラックボックス型テスト （３） コードに基づいた技法 ⇒ホワイトボックステスト、制御フロー、データフロー、トランザクション フロー、コールフローテスト （４） フォールトに基づいた技法 ⇒作り込まれるホルトに注目、エラー推測、ミューテーションテスト 50 （補足３） SQuBOKにおけるのテストの設計技法（2/3） （５） 利用に基づいた技法 ⇒利用者、利用環境、に基づく運用、ローカライゼーションテスト （６） ソフトウェアの形態に基づいた技法 ⇒ドメイン、開発パラダイムに注目。オブジェクト指向テスト、Webシステムテス ト、GUIテスト、プロトコル適正テスト、DBテスト （７） 組合せの技法 ⇒テスト条件（パラメータ）の組合せに注目。直交配列表,All-Pair （８） リスクにも基づいた技法 ⇒リスク分析に基づくテスト。 リスクベースドテスト（テストマネジメント、テスト設計） 51 （補足３） SQuBOKにおけるのテストの設計技（3/3） （９） テスト技法の選択と組合せの技法 ⇒機能的テストと構造的テストの組合せ、確定的テストと非 確定的テストの組合せ （１０） テスト自動化技法 ⇒テストツールによる自動化、省力化、人的誤りの排除（テ ストの質の確保） 52 （３） 目標値設定（テスト工程）の具体例 ﾊﾞｸﾞ摘出／テスト項目設定目標値の例（ＫＬＯＣベ－ス）→８０年代 単 体 テ ス ト 結 合 テ ス ト 総 合 テ ス ト 1.ＰＣＬ件数： 100件／kloc 1.ＣCL件数： 20～25件/ kloc 1.ＳCL件数： 5～10件/ kloc 2.ＰＣＬ質的内容 正常 ：70％以下 異常 ：10％以上 限界/境界：15％以上 ｲﾝﾀﾌｪ-ｽ ：5％以上 2.バグ摘出件数： 1～2件/ kloc 2. バグ摘出件数： 0.5件/ kloc 3.バグ摘出件数： 8～10件/ kloc ＊ＰＣＬ：単体テスト項目、ＣＣＬ：結合テスト項目、 ＳＣＬ：総合テスト項目 53 （４） 目標値設定（テスト工程）の具体例 ﾊﾞｸﾞ摘出／テスト項目設定目標値の例（ＦＰベ－ス）→９０年代 単 体 テ ス ト 結 合 テ ス ト 総 合 テ ス ト 1.ＰＣＬ件数： 4.1件／FP 1.ＣCL件数： 1.0件／FP 1.ＳCL件数： 0.4件／FP 2.バグ摘出件数： 0.34件/ＦＰ 2.バグ摘出件数： 0.04件/ＦＰ 2. バグ摘出件数： 0.02件/ＦＰ ※この目標値は統計的手法により求めた値であり、各プロジェクトにおいては その特性を考慮しプロジェクト毎に設定する必要がある。 ＊ＰＣＬ：単体テスト項目、ＣＣＬ：結合テスト項目、 ＳＣＬ：総合テスト項目 54 （５） テストの完了基準 （１） 基準１（摘出バグ） バグ摘出目標値で設定したバグ数が摘出されていること。 最低でも８０％以上を目標とし、１００％に達しない理由を評価し ておくこと。 （２） 基準２（テスト項目） テスト項目が目標値通りに設定され、全てのテスト項目が実施さ れていること。 （３） 基準３（バグ対策） テストで摘出されたバグが、原則として全件修正されていること。 修正を後工程に繰り越すときは、その理由と時期を明確にする こと。 （４） 基準４（品質改善） 当該テスト工程で指摘されたバグを分析、評価し、それに基づく 品質改善（追加テスト）が行われていること。この作業を後工程 に繰り越すときは、その理由と時期を明確にすること。 55 ２．３ テストの種類 テストの種別 １．静的テストと動的テスト ２．ホワイトボックステストとブラックボックステスト ３．網羅的テストとピンポイントテスト ４．フェーズドテスト：単体テスト、結合テスト、総合テスト 56 ２．３．１ 静的テストと動的テスト 静的テスト プログラムの実行を伴わないで、プログラムのエラーや構造上の問題を検 出する (例：UNIXのLint、日立システムアンドサービスのInspect Pro等) 動的テスト プログラムを実行させて、その正しさをチェックする。 通常テストと呼ばれるのは、この動的テストのことを言う。 57 ２．３．２ ホワイトボックステストとブラックボックステスト ホワイトボックステスト プログラムの内部構造を調べて、論理が正しいか否かをチェックする。 (プログラムの内部構造を知ることができる場合のみ実施可能) ブラックボックステスト プログラムの内部構造には関知せずに、仕様通りの動きをするか否かを チェックする。 58 ２．３．３ 網羅的テストとピンポイントテスト 網羅的テスト 要求仕様や機能要求を全般的にわたり、網羅的にテストする。 ピンポイントテスト 経験などに基づきバグの存在しそうな部分を探し出し、そこを重点的に テストする。 （エラー推測法、探索的テスト 等） 59 ２．３．４ フェーズドテスト 単体テスト モジュール内のアルゴリズム、データ構造、実行パス、エラー処理パスの チェックを行う。 結合テスト モジュール間のインタフェースのチェックを行う。 総合テスト 全てのモジュールを結合した最終的なシステムレベルでの実運用を 想定した機能のチェックを行う。 60 ２．４ 品質評価の方法 ソフトウェア品質の測定とメトリックス 先達の過去の経験とノウハウは「SQuBOK」に纏められている。 こいう物をベースに次の展開を計ることが重要。 計測は品質管理、プロジェクト管理のみならず、あらゆる管理（制御） の基本である 「測れないものは制御できない（トム．デマルコ）」 （１）ソフトウェア品質の測定と結果の活用は高品質なソフトウェアの開発に必要 不可欠です。 （２）目的が明確ではない測定や、測定条件が異なる他の組織の基準値の安易 な利用は、必ずしも高品質なソフトウェア開発にはつながってはいきません。 (3)メトリックスを用いる目的は、製品やプロセスの品質を定量的に把握．評 価し、それらを継続的に改善することです。 61 （１）ソフトウェア品質の測定とメトリックス 製品開発における測定はコアコンピタンス 「物、事を計測し評価する能力」 NASAが使う部品の信頼度はsix nine⇒計測できたことが凄い 計測と評価を確実にするために メトリックスが必要 計測結果は活用されなければ意味がない ソフトウェアメトリックスは代用特性である メトリックスは必要性と目的に合わせて定義されなければ成らない メトリックスは常に見直しが不可欠である 活用の基本はプロセスへのフィードバックである 活用されないデータは精度が劣化してゆく 最近散見される問題 慣習によって意味を理解せず計測していないか？ 62 （２）ＩＳＯ/ＩＥＣ9126 品質評価プロセスモデル 明示的または 暗示的必要性 管理上の要求 X0129およびその他技術情報 要求定義 品質要求仕様 品質要求定義 ソフトウェア 測定法 評定水準 総合評価 選択 設定 基準設定 準備 製品または中 間製品 開発 測定値 測 メトリックスが必要 定 評 定 設定された 水準 総合評価 評価 結果（受入れ可否） 出典）東基衛（他編）：『ソフトウェア品質評価ガイドブック』、日本規格協会、1994年。 63 （参考１）メトリックス作成の代表的な技法例 GQMパラダイム Basili教授らによって提案された総合的なソフトウェア計測 の枠組み “計測はトップダウンに行われるべきである” まず計測目標があって，その目標を遂行するために尺度 （メトリクス）が定義され，計測されるべき “データ分析は何らかの目的や仮説に基づいて行われるべき である” 例）コスト予測，コスト改善，品質改善 etc. PS:最近ではGQMパラダイムの派生的モデルも発表されている GQM+M(Mechanism=収集責任者、収集頻度、報告頻度） 64 （参考２）GQMパラダイムの事例 「ソフトウェアの修正依頼処理」の「適時性（処 理にかかる時間の妥当性）」を「プロジェクトマ ネージャ」の立場から「改善」する Goal Question ソフトウェアの修正依頼処理に かかる時間は？ 平均処理時間 処理時間は改善されたか？ 処理時間の標準偏差 Metric 処理時間が上限を超 える場合の割合は？ マネージャの満足度 の主観的評価値 平均的な処理時間／ 標準的な平均処理時間 *井上克郎, 松本健一, 飯田元 著 「ソフトウェアプロセス」 共立出版，2000. 65 （３）品質管理図 テスト管理の代表的手法として品質管理図がある。 テストの進捗に併せ、テスト項目消化の予実績，障害発生・対策 件数の推移をグラフ化し、傾向把握と状況管理を行う。 残 不 テスト消化線 存 不良摘出予想線 良 テ 摘 ス 出 ト 件 項 数 目 件 テスト消化予想線 不良摘出実績線 数 件 数 未解決不良件数曲線 日程 品質管理図 66 （４）品質目標値管理の概念図 １．品質目標設定 ２．管理曲線の設定 ６．稼動管理 ３．実績の監視 ５．品質改善 ４．目標値管理 異常値管理 収束状況管理 実績が管理曲線から外れた場合／原因究明と対策 ５．品質予測と評価 収束率(＊)による品質評価、管理 信頼性成長曲線に基づくバグ件数の予測 ／探針（ＱＰ） ※収束率＝実績バグ件数／予測バグ件数 品質目標値管理 67 （６）探針（QP:Quality Probe） 探針は、検査項目をサンプリングし、その結果から全体の母不 良率を求め残バグ件数を推定する方法である。 ① 探針項目として、検査項目数（Ａ）の10％～20％をサンプリングする。 ② 探針項目から出た不良に対して不良率を次の式で求める。 標本不良率：ρ’ = ｒ／ｎ （ｎ：探針項目数 ｒ：不良件数 ） ③ 二項確率紙または次の近似式により母不良率の信頼限界の上限値と下限 値を求める。 ※ 危険率：αは通常５％としている。 上限値：ＰU＝ ρ’＋ｕ（α） ρ’（１－ ρ’ ）／ｎ ｕ（α）=1.9 下限値：PＬ＝ ρ’－ｕ（α） ρ’（１－ ρ’ ）／ｎ ④ 残バグ数＝ （PＬ×Ａ）～（ＰU ×Ａ） 68 （７）信頼性成長モデルの具体例 時間計測モデル ソフトウェア故障発生時間あるいはエラー発見時間に基づく確率・統計モデル。 個数計測モデル 発生したソフトウェア故障数、あるいは発見されたエラー数に基づく確率・統計モデル。 代表的なものに、ＮＨＰＰモデルや超幾何分布モデルがある。 アベイラビリティモデル ソフトウェアの時間的挙動を、ソフトウェア故障の発生しない動作状態と、ソフトウェア 故障の発生した不動作状態により記述する確率モデル。 傾向曲線モデル 累積バグ発生数がＳ字形成長曲線に類似しているという事実を利用し、バグの総 出現数や、デバッグの完了時期等を推定する。ゴンベルツ曲線モデルや、ロジス ティック曲線モデルがある。 69 （８）信頼性成長モデルの具体例 信頼度成長モデル 70 （９）開発工程とテスト／検査の関係（８０年代以降） （１）ウォーターﾌｫール型の開発 設 計 工 程 検 査 工 程 基本設計 機能設計 構造設計 ﾚﾋﾞｭｰ レビュー ﾚﾋﾞｭｰ ｺｰﾃﾞｨﾝｸﾞ ﾚﾋﾞｭｰ テスト／デバッグ 単体 結合 総合 ﾃｽﾄ 項目 ﾏﾆｭｱ ﾙ 基本設計 機能仕様 構造設計書 ﾏﾆｭｱ ﾙ検 書検査 書検査 検査 査 ドキュメント検査 ﾃｽﾄ 項目 検査 品質監 査・探針 製品 検査 検査準 備作業 ｼｽﾃ ﾑﾃｽ ﾄ 設計工程と検査工程の関係 71 （１０）QC7つ道具 # 項目 内容 １ 特性要因図 品質の特性と要因の関係を表す。普通、魚の骨に類似した形状となる。 ２ パレート図 項目を横軸とし、度数の多い項目から順に度数を縦軸にとり、累積相 対度数曲線を併用した図。 ３ チェックシート データの分類項目別分布を知るために使う。要因の系統的整理に際 して、効率よくデータを取るのに有効。 ４ ヒストグラム データのばらつきの姿を知る。 ５ 散布図 2変数を横軸と縦軸にとり、値を打点して作られる図。相関性など、二 つの対になったデータの検討に使う。 ６ 管理図 工程が安全な状態にあるかどうかを調べるため、または工程を安定な 状態に保持するために持ちる図。 ７ グラフ データを数字ではなく図に表して、見やすくするために使われる。 表１ ＱＣ７つ道具 72 （補足１）QC七つ道具の使い分け ステップ1 数値データを集めているが，有効利用されていない．現状把握ができていない． チェックシート ヒストグラム 管理図 散布図 現状は把握できているが，問題がどこにあるのかわからない ステップ2 原因と結果の 関係が不明 特性要因図 問題の影響 度が不明 パレート図 問題点について，解析を行う 散布図（相関） ステップ3 散布図（層別） 管理図 ヒストグラム 問題点の対策の効果が不明 パレート図 管理図 ヒストグラム QC７つ道具の使い分け グラフ 73 （補足２）問題解決手順とQC手法の適用 主なQC手法 問題解決手法 パレート図 特性要因図 QC グラフ 七つ チェックシート 道具 ヒストグラム 散布図 管理図 親和図法 新 連関図法 QC 系統図法 七つ マトリクス図法 道具 アローダイアグラム法 PDPC法 マトリクスデータ解析図法 統計 推定/検定 的手 実験計画法 法 多変量解析 信頼 FMEA/FTA 性工 ワイブル解析 問 題 の 把 握 テ ｜ マ 設 定 活 動 計 画 立 案 現 状 の 把 握 要 改 目 因 善 標 の 案 設 分 検 定 析 討 ◎ ◎ ○ ○ ◎ ○ ◎ ◎ ◎ ◎ ○ ○ ◎ ○ ○ ◎ ○ ◎ ◎ ◎ ○ ◎ ◎ ○ ◎ ◎ ○ ○ ◎ ○ ◎ ○ ◎ ○ ○ ○ ◎ ◎ ◎ ○ ◎ ◎ ○ ○ ◎ ◎ ◎ ◎ ◎ ◎ ○ ○ ◎ ○ ◎ 改 善 案 実 行 計 画 改 善 案 実 施 改 善 効 果 の 確 認 ◎ ○ ◎ ◎ ○ ○ ◎ ○ ○ ○ ◎ ◎ ◎ ◎ ○ ○ ◎ ◎ ○ ◎ ○ ○ ◎ ◎ ○ ◎ ○ ◎ ○ ◎ 改 管 今 善 標 理 後 の 準 の の 反 化 定 課 省 着 題 ○ ○ ○ ◎ ○ ○ 74 今日お話すること ソフトウェア（SW)品質やその特徴 ＳＷ品質保証活動の始まり ＳＷ品質保証技術.方法論の確立 ＳＷ品質保証方法論のフレームワーク SW品質保証方法論の内容 SW品質保証のこれから 75 ＳＷ品質保証活動のこれから（１/2) 更なる上流プロセスの強化 創造的仕事の再生 品質作り込みの重視（手戻りのない少ない開発） 開発管理の大政奉還（主体を支援部門から開発部門へ） 過剰管理からの脱却 やる気になるマネージメントの方法の実現 ソフトウェア人材の育成（ハイレベルＳＷ工学の習得、専門家集 団育成）⇒次のスライド参照 「人月の神話（ブルックス）」からの脱却 開発技術/管理技術の伝承（積み木崩しからの脱却） →例：SQuBOK（品質保証技術） 76 （１）人材の育成（1/2) 人材の育成 これからの企業における人材育成は平均値を上げる底上げ教育から 精鋭を養成する教育と自己啓発を支援する方向に向かうべきあろう。 （１）ソフトウェア工学の基礎理論 開発エンジニアは「何をしなければ」成らないのか、「何が出来なければ」ならな いのかという、ソフトウェア開発者の【ディシプリン】を再定義または再確認する 必要が有る。 ＊＊＊＊＊一つ例としてＰＳＰ（ＰＳＰ入門）＊＊＊＊＊＊＊＊ ① 時間管理 ②時間の追跡 ③期間計画と製品計画 ④製品計画 ⑤製品規模 ⑥時間の自己管理 ⑦コミットメントの管理 ⑧スケジュール管理 ⑨プロジェクト計画 ⑩ソフトウェア開発プロセス ⑪欠陥 ⑫欠陥の発見 ⑬コードレビューチェックリスト ⑭欠陥の予測 ⑮欠陥除去の経済学 ⑯設計欠陥 ⑰製品品質 ⑱プロセス品質 ⑲品質に対する個人的コミットメント 77 （１）人材の育成(2/2) （２）周辺/関連技術の習得 社会学や心理学などの情報システムの開発に必要となる分野の知識 及びドメイン（業種）知識の習得。 （３）温故知新的な視点の育成 大きく物事が変化する時代には、過去の流れを見据えて現在から将 来を展望できる思考の養成が必要。 （４）他分野成果の活用能力育成 特にソフトウェア品質管理、品質保証において他分野で成功した技 法の吸収と積極的な活用能力の育成。 （５）情報収集能力の育成 短期開発ニーズが高まりスピードが要求される。これに打ち勝つ ためには情報収集納能力の向上が必須である。 78 (2)品質保証プロセスの再構築（画一から部門最適へ） 国際的な デファクトスタンダード ISO9001:2000 CMM/CMMI 参照 各社の技術標準 基準として参照 各ソフトウェア部門の 品質マネジメント システム（QMS：Quality Management System） Ａ部門の ＱＭＳ 技術標準 Ｂ部門の ＱＭＳ 部門毎のＱＭＳ プロセスの構造 出典：小笠原他、東芝におけるSPI活動事例～現在・過去・未来～、第3回ソフトウェアプロセス改善 ワークショップ(JASPIC主催)、2006.6 79 （参考１）ISO9000に基く品質システム 品質マネジメントシステム 顧客 経営者 満足 品質方針 品質目標 ソフトウェア開発 要求 出荷 マネジメントレビュー 設計 合否判定後 出荷 保守 テスト 実績 検査 共通 教育 文書管理 内部監査 etc 障害/対策 ISO9000の概要 80 ＳＷ品質保証活動のこれから（2/2) 有用な開発技術へのチャレンジ（大企業病からの脱却） 革新的管理技術の開発とチャレンジ（大企業病からの脱却） テスト技術の更なる進化 モデル検証の実用化 開発経験、失敗経験の共有 → エンピリカル工学？ 81 (3) ダブルＶ字モデル（テストファースト） 要求分析 システムテストの設計 基本設計 結合/機能テストの設計 詳細設計 単体テストの設計 実装 コードミスの逐 次検出 システムテストの実施 結合/機能テストの実施 単体テストの実施 コードインスペクションの実施 電通大 西先生 講演資料より 82 (4) W-model（テストアクティビティの早期開始） レビュー 要求（RFP） テスト テストアクティビティ開始 要件定義 システムテスト計画 基本設計 詳細設計 結合テスト計画 コンポーネントテスト 計画 受入テスト実行 デバッグと変更 デバッグと変更 システムテスト実行 結合テスト実行 コンポーネントテスト 実行 デバッグと変更 デバッグと変更 コーディング／レビュー テストの関与を早め、テストフェーズの課題を取り除く 出展：JaSST’08チュートリアルTsuyoshiYUMOTO 83 (2)有用な開発技術へのチャレンジ 段階的（インクリメンタル）開発⇒All in one の回避 開発対象を多数の小さな機能に分割し、1つの反復で1機能を 開発する。 この反復のサイクルを継続して行い、1つずつ機能 追加開発してゆく開発スタイル⇒次のスライド参照 SPLE(Software Product Line Engineering)⇒再利用の新しい道 □ 作らずして創る方向へ □ ’90のコンポーネントウェアは何処へ行った？ 保守開発、派生開発の斬新的技法の開発 ソフトウェア保守からソフトウェア進化へ □ ITIL,SOAは有効な方法論になりえるか 84 （５）ラショナル統一プロセス（ＲＵＰ） ［出典］］ソフトウェア・プロジェクト管理-RUPとPMBOKとのマッピング、 http://www-06.ibm.com/jp/developerworks/rational/library/pm/0407b.html 85 有用な開発技術へのチャレンジ② モデル検証を前提とした開発 作る前に実現性と有効性を検証 形式手法（形式記述言語） 仕様書の記述に形式記述言語を使用し、仕様のあいま い性を排除する⇒如何すれば定着するか プラットホームの統合を目指して Javaの統合開発環境。オープンソース 86 温 故 知 新 そして 温 顧 創 新 ご清聴ありがとう御座いました 87 著書紹介「ソフトウェア品質保証入門」 ソフトウェア品質保証入門 高品質を実現する考え方とマネジメントの要点 保田 勝通著 奈良 隆正著 A5 判 248 頁 定価 2940 円（税込） ISBN978-4-8171-9263-9 出版社：(株)日科技連出版社 URL http://www.juse-p.co.jp 【連絡先】 〒240-0113 130336 神奈川県三浦郡葉山町長柄 奈良隆正 TEL/FAX:046-875-6711 E-mail:nara@consul21.com またはt-nara@mx4.ttcn.ne.jp 本書は、「組織としてソフトウェアの品質保証をどのように確保すれば良いのか」という課題に“初め て”品質保証を担当する方々にもわかるように、基礎的な知識からていねいに解説しています。今 後、ますます激化するグローバルな競争の中で生き残るために「何を」、「どうすべきか」についても 解説します。さらに、品質を確保するために役立つ、ツール、手法、指標、メトリックスなどについて 例をあげながら紹介します。 88
© Copyright 2024 Paperzz
