ISO/IEC DIS 20246 について( ごく簡単な ) 説明

2016 年 11 月 12 日＠ワークプラザ勝田すずき しょうご

NaITE #18

自己紹介• すずき しょうご • 某メーカ系関連企業の企業向けソフトウェアの品質保証部

門• 設計レビュー / プロセス改善 / ソフトウェアテスト

• JCSQE 初級、 JSTQB FL/AL(Test Manager)• 「バグ票ワーストプラクティス検討プロジェクト」メンバ

– 「バグレポートの改善に向けた問題事例の調査とアンチパターン化」ソフトウェア品質シンポジウム 2013(Best Paper Future Award 受賞 )JaSST’14 Tokyo 経験発表

– 「バグレポートの改善に向けた問題事例の調査とアンチパターンの作成」ソフトウェア品質シンポジウム 2014 招待講演

Twitter ： @rin2_

今日お伝えしたいこと• ソフトウェア評価の規格の流れ• 規格を知る意義• 規格について– 国際規格について– ISO / IEC

• 作業成果物レビューの国際規格について– ISO/IEC DIS 20246

目次• レビューについて思うこと• 今日のテーマ• ソフトウェアの評価の規格のトレンド– ISO/IEC/IEEE29119 ファミリ– ISO/IEC DIS 20246

• ISO/IEC DIS 20246 の内容説明• まとめ

レビューについておもうこと• 集まって話せば欠陥がでてくる？• レビューの目的はなにか？レビューを行なうことが目的になっていないか？• 他の組織やプロジェクトのレビューは知らないことが多い？• いいレビューと、そうでないレビューの違い？

今日のテーマ• なぜ、規格か？– 評価 ( テスト、レビュー ) のやり方を知る• 他の組織ではどうやっているか？• テスト・レビューの共通認識はどのようなものか？

– 共通認識から、自分たちのプロセス改善を行なう• 0 から作るよりも効率的• パートナー企業も同じ認識だと、仕事が楽になる、カモ

ISO/IEC/IEEE29119ファミリー• ソフトウェアテストに関する国際規格

(2013 年 9 月 1 日初版発行 )– ISO/IEC/IEEE29119 Part1 概念と定義– ISO/IEC/IEEE29119 Part2 テストプロセス– ISO/IEC/IEEE29119 Part3 テストの文書– ISO/IEC/IEEE29119 Part4 テスト技法– ISO/IEC/IEEE29119 Part5 　　　　　　　　キーワード駆動テスト– ISO/IEC 33063 　　　　　　　　　テストプロセスアセスメント– ISO/IEC 20246(DIS) 　　　　　　　　作業成果物のレビュー

ISTQB• ソフトウェアテストに関するスキル認定の枠組み

(2002 年 11 月設立 )– Foundation Level(FL)– Advanced Level(AL)

• Test Manager• Test Analyst• Technical Test Analyst

– Expert Level• Test management• Improving the Test Process

• 日本においては、 JSTQB

国際的なソフトウェアテスト共通認識2 つのトレンド

ISO/IEC/IEEE 29119 ファミリーPart.1 Concept & Definitions

Part.2 Test Process

Part.3 Test Documentation

Part.4 Test Techniques

Part.5 Keyword Driven Testing

ISO/IEC 33063Process assessment model for

software testing

参考：ソフトウェアテストの国際標準 (ISO/IEC/IEEE29119 シリーズ ) の活用 ( 情報処理学会 短期集中セミナー 2016/7/15)

ISO/IEC 20246Work Product Reviews

IEEE829Test Documentation

IEEE1008Unit Testing

ISO/IEC/IEEE29119

動的テスト

静的テスト

統合

ご参考： ISO/IEC/IEEE29119

• IVIAからの日本語補助資料• 勉強会– 第1回 規格の全体構成と各規格の概要– 第2回 テストプロセス– 第3回 テストドキュメント

• WACATE– 1時間でわかった気になるISO29119

規格名の説明• ISO/IEC DIS 20246 – ISO : International Organization for Standardization

• 国際標準化機構• 国際間の取引をスムーズにするために共通の基準策定

– 例： ISO 9000 シリーズ（品質マネジメントシステム）　　 ISO 14000 シリーズ ( 環境マネジメントシステム )

– IEC : International Electrotechnical Commission• 国際電気標準会議• 電気工学、電子工学、および関連した技術を扱う国際的な標準化団体

– DIS : Draft International Standard• 国際規格案• 案なので、今後内容等が変わることもありえる。

国際規格のステータス• 20246 の現在状況（ 2016/11/12 ）– DIS はドラフト版– まだ正式には国際規格とはなっていない– 現在、 DIS 投票中

出典： http://www.jsa.or.jp/wp-content/uploads/1_08.pdf

ISO/IEC DIS 20246 とは• システム開発、テスト、保守、管理に関する作業成果物のレビューのための汎用フレームワーク• レビュー時の一般的な事項について記載– 用語 / プロセス / アクティビティ / タスク / レビュー技法 / ドキュメントテンプレート

• システムやソフトウェアに関わる全ての人が利用可能

ISO/IEC DIS 20246 の内容 (1/2)• スコープ• 使用目的• 用語定義• 作業成果物レビュー

– レビューの属性– レビュータイプ

• レビュープロセス– モデル– 目的– 結果– アクティビティ・タスク

• 計画• レビュー開始• 個人レビュー• 問題の議論と分析• 修正と議事録作成

– レビューに関する項目

• レビュー技法– 個人レビューの技法

• アドホックレビュー• チェックリストを使ったレビュー• シナリオを使ったレビュー• 観点を使ったレビュー• ロールを使ったレビュー

– 問題分析の技法– レビューミーティング技法

• ページ毎レビュー• チェックリスト使ったレビュー• ロールを使ったレビュー• シナリオを使ったレビュー

ISO/IEC DIS 20246 の内容 (2/2)

• 問題の記録– ドキュメントの ID– 発行者– 承認権限– 変更履歴

• インシデントレポート– ドキュメントの ID– 発行者– 承認権限– 変更履歴

• レビュードキュメントのフロー• レビュー属性– 目的– ロール

• IEEE1028 とのマッピング• ツールサポート

作業成果物とは• 作業成果物

– 契約– 設計仕様– 開発計画– 保守計画– コード– プロジェクト計画– RFP/ 要求仕様– テスト計画 / テスト仕様– ユーザマニュアル

• フォーマット– テキスト

• 自然言語、コード– シナリオ

• ユースケースフロー– モデル– 形式手法– UML

ソフトウェア開発工程のすべての成果物が対象にできる

レビュープロセスとドキュメントの例レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

問題記述深刻さステータス分担

レポート

インシデントレポート問題記録

参考： ISO/IEC DIS 20246 AnnexB Figure B.1 (20ページ )

レビューにあるもの• レビューを考えるうえで必要なこと– 目的– 役割– レビュー技法– レビューワとレビューワ数– レビュー計画とレビュー数– レポート– 教育– レビューの改善– 開始・終了基準

レビューのタイプ• 作成者チェック• 同僚のチェック• 非公式なグループレビュー• インスペクション• ピアレビュー• ピアデスクレビュー• テクニカルレビュー• ウォークスルー

• どのタイプを使うかは限定されない• 組み合わせてもよい

アクティビティとタスク

• レビューが成功した結果– 欠陥や問題点の検出・識別– 品質特性の評価– レビューワが新しい知見を得る– 新たなアイディアが湧く– 成果物のアップデート– 作業に関する改善の可能性を認識する

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

得られることが良いレビュー？

アクティビティとタスク

• レビュー計画– 作業成果物の定義– レビューで行なうこと、役割、技法、使用するするチェックリスト等の合意– レビューにおける役割と参加者の特定

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

アクティビティとタスク

• レビュー開始– レビューに必要な資料の配布

• レビュー対象、チェックガイドライン・チェックリスト 等– レビューリーダーは範囲、レビューに考慮することを参加者へ通知– 役割、責任、焦点を参加者に通知– レビュー時に、作成者は成果物について説明してもよい

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

アクティビティとタスク

• 個人レビュー– レビューワは、気になる点を特定する

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

アクティビティとタスク

• ディスカッションと分析– 識別された気になる点について通知する– 気になる点は、割り当てのために分析される– 気になる点は、個人やチームに割り当てられる– 成果物の品質特性を基準とともに評価する

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

アクティビティとタスク

• 修正とレポート– インシデントレポートが作成され、割り当てられた人やチームに通知される– 変更が必要なものについて対応する– 修正終了時、確認が行われ、最新版に更新される– レビュー結果が満足されると、成果物が受け入れられる– 結果の報告

レビュー計画 レビュー開始 個人レビュー 議論分析 修正報告

レビュー技法• 個人レビュー– アドホックレビュー–チェックリストベースドレビュー– シナリオベースドレビュー– パースペクティブレビュー– ロールベースドレビュー

アドホックレビュー• もっとも一般的なアプローチ• 構造化されていない• ガイドなどが提供されさない• レビュー対象を順番に読んで欠陥を検出する• レビューワのスキルに大きく依存• 複数のレビューワで同じ問題が指摘される

チェックリストベースドレビュー• チェックリストに基づいたアプローチ• レビューワ毎に異なるチェックリストが割り当てられる–広いカバレッジ

• チェックリストに限定されるあまり、他の問題を見逃してしまう (無視されてしまう )• レビューワの責任はチェックリストだけでないことを認識してもらう必要がある

シナリオベースドレビュー• レビュー対象を読むためのガイドラインがある• シナリオに記載されていない欠陥は見落とす危険がある• リスク情報を付加することによりレビュー対象をより深く検討することが可能

パースペクティブレビュー (PBR)• 異なるステークホルダの視点でレビュー対象を読む• 視点の例

– ビジネスアナリスト– 経営者– 設計者– 保守担当者– マーケティング担当– オペレータ– プログラマ– 装置– テスター– ユーザ

• レビュー対象に適したバランス– 要件文書：ユーザ、設計者、テスターの視点– 規制区域内のシステム：機器– 長期間運用されるシステム：保守担当者

• アプローチの 3 つのポイント– レビューで考えるべきステークホルダの視点を考える– ステークホルダが期待している高品質な製品を考える– 上記を説明するためのチェックリストを考える

• 再利用を考慮する

ロールベースドレビュー• 異なるステークホルダーのロールから、レビュー対象を評価する。

パースペクティブベースドレビューとの違い？

アドホックレビュー

チェックリストベースドレビュー

シナリオベースドレビュー

パースペクティブベースドレビュー

ガイドラインの有無

× ○(チェックリスト )

○( シナリオ ) ○( ステークホルダーの視点・観点 )

長所 ・多くの欠陥を検出可能

・チェックリストによる割当てにより、拾いカバレッジが確保可能・指摘項目が重複しにくい・リスク情報を付加することでより深くチェック可能

・シナリオをレビューワで分担するので、指摘事項が重複しにくい・「ドライラン」(予行 ) により、利用時の欠陥を検出できる・狙った欠陥を検出しやすい・リスク情報を付加することでより深くチェック可能

・ステークホルダーの観点で分担して評価する評価するため、指摘事項が重複しにくい・観点のバランス、組み合わせを考慮する・再利用できる

短所 ・レビューワのスキル依存・指摘項目が重複する恐れ

・チェックリストにない不具合については見落とす・チェックリストが長くなりがち

・シナリオに含まれていない不具合は見落とす・狙っていない欠陥は検出にくい

・レビューワによっては、観点を利用にしくい

その他 ・レビュー対象 ( ドメインごと、製品ごと、文書ごと )に異なるチェックリスト・定期的な更新

レビュー技法• レビューミーティングでの技法–ページ毎レビュー–チェックリストベースドレビュー– ロールベースドレビュー– シナリオベースドレビュー

レビューの計測と改善• レビュープロセス改善の必要性– 短期的な目標• 製品の欠陥検出　などなど

–長期的な目標• 開発とテストの実践• 製品の品質の向上 実践結果からプロセス改善

定量的なメトリクスを収集し、レビュープロセスの改善に繋げる

レビューのメトリクス• 欠陥密度– レビュー対象物の質– ページあたりの欠陥数、 FP あたりの欠陥率

• 欠陥混入率– 工程別の開発プロセスの質– ページあたりの欠陥数、機能あたりの欠陥数

• 欠陥検出率– レビュー時間当たりの欠陥検出数

• レビュー進度– ページあたりの時間

ツールによるサポート• ツールによる効率化

– レビューワ間のコラボレーション・コミュニケーション– 作業成果物のコメントをハイライトする– コメント・修正と作業成果物のトレーサビリティ管理– レビューメトリクスの自動収集– 他ツールとの連携

• テスト管理ツール、 BTS 、 VCS 、 IDE との統合

• 具体的なツール– 文書のレビューツール

• C-Review Support( クライム )• Review Coordinator

( 日立ソリューションズ )– コードレビューツール

• Redmine Code Reviewプラグイン• Review Board

コードレビューツールについては、IDE 統合、 ITS ・ BTS ・ VCS 連携等ふくめていろいろ出ている。

まとめ• ソフトウェア評価の規格の流れ– ISO/IEC/IEEE29119 シリーズ– ISTQB

• 作業成果物のレビューの規格の紹介– ISO/IEC DIS 20246

ご参考：レビューア心得十ヶ条とレビューアべからず集• レビューア心得十ヶ条

1. 技術に厳しく、人には優しく、楽しくやろう2. 付加価値をつけて設計者を助けよう3. 設計者の説明を最後まで聞こう4. 設計者の考えを引き出す質問をしよう5. できたことを認めて、ほめよう6. 設計者が考えていない領域に視野を広げよう7. その場で決着をつける努力をしよう8. 結果をみて、レビューの成果を真摯に振り返ろう9. 重大不具合から学んだことをすべて頭に入れておこう10. お客様の信頼を得るころを最後まであきらめない

• レビューアべからず集1. やっていないことを責めてはいけない2. ワークシートの書き方を指導してはいけない3. 言葉だけで確認するな　図面やモノをみよ4. DR は設計者にお墨付きを与える場ではない5. 説明者と同じ目線になるな6. 知識や経験があることを誇示するな7. 謙虚であれ (反り返るな、怒鳴るな、意地を通すな )

出典：日産自動車における未然防止手法 Quick DR  日科技連出版社 (2012/02)

レビューワが常に念頭におく心得 レビューワがやってはいけないタブー

参考文献• ソフトウェアインスペクション ( 共立出版 )

Tom Gilb, Dorothy Graham• ピアレビュー 高品質ソフトウェア開発のために

( 日経 BP ソフトプレス )Karl. E. Wiegars

本資料のイラストの一部は以下のサイトから利用しました• いらすとや

• http://www.irasutoya.com/