この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序文
ISO (国際標準化機構) と IEC (国際電気標準会議) は、世界標準化のための専門システムを形成しています。 ISO または IEC のメンバーである国家機関は、技術活動の特定の分野を扱うために、それぞれの組織によって設立された技術委員会を通じて、国際規格の開発に参加しています。 ISO と IEC の技術委員会は、相互に関心のある分野で協力しています。 ISO および IEC と連携して、政府および非政府の他の国際機関もこの作業に参加しています。情報技術の分野では、ISO と IEC が合同技術委員会 ISO/IEC JTC 1 を設立しました。
この文書の開発に使用された手順と、今後の維持のために意図された手順は、ISO/IEC 指令で説明されています。 1. 特に、さまざまなタイプの文書に必要なさまざまな承認基準に注意する必要があります。この文書は、ISO/IEC 指令の編集規則に従って作成されました。 2 ( www.iso.org/directives を参照)
このドキュメントの要素の一部が特許権の対象となる可能性があることに注意してください。 ISO および IEC は、そのような特許権の一部またはすべてを特定する責任を負わないものとします。ドキュメントの開発中に特定された特許権の詳細は、序文および/または受信した特許宣言の ISO リストに記載されます ( www.iso.org/patents を参照)
このドキュメントで使用されている商号は、ユーザーの便宜のために提供された情報であり、保証を構成するものではありません。
適合性評価に関連する ISO 固有の用語と表現の意味に関する説明、および技術的貿易障壁 (TBT) における世界貿易機関 (WTO) の原則への ISO の準拠に関する情報については、次の URL を参照してください: www.iso .org/iso/foreword.html .
この文書は、技術委員会 ISO/IEC JTC 1, 情報技術、小委員会 SC 7, ソフトウェアおよびシステム工学によって作成されました。
序章
このドキュメントの目的は、ソフトウェアとシステムのライフサイクルのどの段階でも使用できる検査、レビュー、ウォークスルーなどの作業成果物のレビューを定義する国際標準を提供することです。これは、システムまたはソフトウェアの作業成果物をレビューするために使用できます。このドキュメントは、レビューの目的とレビューを行う組織の制約に基づいて構成できる作業成果物レビューの一般的なプロセスを定義します。その意図は、あらゆる組織があらゆる作業成果物に効率的かつ効果的に適用できる一般的なプロセスを説明することです。
レビューの主な目的は、問題を検出し、代替案を評価し、組織的および個人的なプロセスを改善し、作業成果物を改善することです。ライフサイクルの早い段階でレビューを適用すると、通常、レビューはプロジェクトの不要なやり直しの量を減らすことが示されています。このドキュメントで紹介する作業成果物のレビュー手法は、一般的なレビュー プロセスのさまざまな段階で使用して、欠陥を特定し、作業成果物の品質を評価できます。
作業成果物のレビュー中に作成されるレビュー文書は、付録 A で定義されています。
1 スコープ
このドキュメントは、システムおよびソフトウェアの管理、開発、テスト、および保守に関与するすべての組織が参照および使用できる作業成果物レビューの一般的なフレームワークを確立します。これには、作業成果物のレビュー中に適用される一般的なプロセス、アクティビティ、タスク、レビュー手法、およびドキュメント テンプレートが含まれています。作業成果物は、プロセスによって生成される成果物です。このドキュメントは、作業成果物のライフ サイクルのあらゆる段階で使用できる作業成果物のレビューを定義します。このドキュメントは、プロジェクト マネージャー、開発マネージャー、品質マネージャー、テスト マネージャー、ビジネス アナリスト、開発者、テスター、顧客、およびシステムとソフトウェアの開発、テスト、保守に携わるすべての人を対象としていますが、これらに限定されません。
2 参考文献
以下のドキュメントは、その内容の一部またはすべてがこのドキュメントの要件を構成するように、本文で参照されています。日付のある参考文献については、引用された版のみが適用されます。日付のない参照については、参照文書の最新版 (修正を含む) が適用されます。
- ISO/IEC/IEEE 24765, システムおよびソフトウェア工学 - 語彙
3 用語と定義
このドキュメントの目的のために、ISO/IEC/IEEE 24765 に記載されている用語と定義、および以下が適用されます。
ISO と IEC は、次のアドレスで標準化に使用する用語データベースを維持しています。
3.1
アドホックレビュー
構造化されていない独立したレビュー手法
3.2
著者チェック
成果物の作者によって行われる非公式のレビュー
3.3
バディチェック
著者の同僚によって独立して行われた非公式のレビュー
3.4
チェックリストに基づくレビュー
質問または必須属性のリストに基づいたレビュー手法
3.5
正式な審査
正式に文書化された出力で定義されたプロセスに従うレビューの形式
3.6
非公式レビュー
定義されたプロセスに従わず、正式に文書化された出力がない形式のレビュー。
3.7
非公式グループレビュー
3人以上による内定審査
3.8
検査
問題を特定するための作業成果物の正式なレビュー。これは、定義されたチームの役割と測定を使用して、レビュー プロセスを改善します。
例：
Fagan インスペクション[7]は特定のタイプのインスペクションであり、コード インスペクションはプログラムのソース コードをレビューするために使用されます。
3.9
問題
期待を裏切る観察
例：
潜在的な欠陥、改善点、または説明が必要な点。
3.10
マイルストーンレビュー
作業成果物の正式なレビューと、開発の次の段階での使用または納品の受け入れ可能性を判断するために使用される裏付けとなる証拠
注記 1:この形式のレビューの要件は、通常、プロジェクト計画で指定されます。
3.11
ページごとのレビュー
レビュアーが作業成果物を順番にレビューする手法
3.12
ペアレビュー
共同で作業する著者以外の 2 人の適切な資格を持つ人々によって実行される作業成果物の非公式のレビュー
3.13
ピアデスクチェック
著者と同僚が作業成果物をウォークスルーする非公式のレビュー
3.14
査読
同じ作業を行う資格のある他の人によって実行された作業成果物のレビュー
3.15
視点に基づく読書
チェックリストを使用し、作業成果物の完全性およびその他の品質特性をチェックするためのプロトタイプの成果物の作成を伴う、役割ベースのレビューの形式。
3.16
ロールベースのレビュー
レビュー担当者がさまざまな利害関係者の役割の観点から作業成果物をレビューする手法
例：
典型的な利害関係者の役割には、作業成果物の保守担当者、テスター、開発者などの特定のユーザー タイプが含まれます。
3.17
シナリオベースのレビュー
特定のシナリオに対処する作業成果物の能力を判断することによってレビューが導かれる手法
3.18
テクニカルレビュー
意図された用途に対する作業成果物の適合性を検査し、仕様および標準との不一致を特定する、技術的に資格のある担当者のチームによる作業成果物の正式なピア レビュー。
注記 1:技術レビューは、代替案の推奨とさまざまな代替案の検討も提供する場合があります。
3.19
ウォークスルー
正式なレビューでは、著者が作業成果物を通じてレビューのメンバーを導き、参加者が質問をしたり、考えられる問題についてコメントしたりします
3.20
成果物
プロセスによって生成されたアーティファクト
例：
プロジェクト計画、要件仕様、設計文書、ソース コード、テスト計画、テスト会議の議事録、スケジュール、予算、インシデント レポート。
注記 1:作業成果物のサブセットをベースライン化して、さらなる作業の基礎として使用することができ、一部はプロジェクトの成果物のセットを形成します。
参考文献
| [1] | ISO/IEC 12207, システムおよびソフトウェア工学 — ソフトウェア ライフ サイクル プロセス |
| [2] | ISO/IEC/IEEE 15288, システムおよびソフトウェア工学 — システム ライフ サイクル プロセス |
| [3] | ISO/IEC TR 19759, ソフトウェア エンジニアリング — ソフトウェア エンジニアリング知識体系ガイド (SWEBOK) |
| [4] | ISO/IEC TS 24748-1, システムおよびソフトウェア工学 — ライフサイクル管理 — 1: ライフサイクル管理のガイドライン |
| [5] | ISO/IEC 25010, システムおよびソフトウェア工学 — システムおよびソフトウェアの品質要件と評価 (SQuaRE) — システムおよびソフトウェアの品質モデル |
| [6] | ISO/IEC 25030, ソフトウェア工学 — ソフトウェア製品の品質要件と評価 (SQuaRE) — 品質要件 |
| [7] | M Fagan, プログラム開発のエラーを減らすためのデザインとコード インスペクション。 IBM システム。 J.__ 1976年、15(3) |
| [8] | Gawande A.チェックリスト マニフェスト。メトロポリタンブックス、2009 |
| [9] | Gilb T, Graham Dソフトウェア検査。アディソン・ウェズリー、1993年 |
| [10] | Hass AMJ 著、 『高度なソフトウェア テストのガイド』 。アーテックハウス、2008年 |
| [11] | IEEE 1028-2008, ソフトウェアのレビューと監査に関する IEEE 規格 |
| [12] | IEEE 15288.2-2014, 防衛プログラムの技術レビューおよび監査に関する IEEE 規格 |
| [13] | Kaner Cテスト コンピューター ソフトウェア。 TABブックス、1998年 |
| [14] | Kit E実世界でのソフトウェア テスト: プロセスの改善. ACMプレス、1995 |
| [15] | Laitenberger O, DeBaud J, 1998 年。ソフトウェア検査に関する包括的なライフサイクル中心の調査。テックレポート番号ISERN-98-32, フラウンホーファー実験ソフトウェア工学研究所、カイザースラウテルン、ドイツ |
| [16] | マイヤーズ G.ソフトウェア テストの技術。ジョン・ワイリー・アンド・サンズ社、1979年 |
| [17] | Sauer C et al.、ソフトウェア開発技術レビューの有効性: 行動に動機付けられた研究プログラム。 IEEE Trans.Softw.タイト。 2000 年 1 月 26 日 (1) |
| [18] | Shull F, Rus I, Basili V, 2000 年 7 月。パースペクティブ ベースの読み取りが要件検査をどのように改善できるか。 IEEE コンピューター |
| [19] | Wiegers K.、ソフトウェアのピア レビュー — 実践ガイド。アディソン・ウェズリー、2001年 |
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, 2 (see www.iso.org/directives ).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents ).
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html .
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering.
Introduction
The purpose of this document is to provide an International Standard that defines work product reviews, such as inspections, reviews and walkthroughs that can be used at any stage of the software and systems life cycle. It can be used to review any system or software work product. This document defines a generic process for work product reviews that can be configured based on the purpose of the review and the constraints of the reviewing organization. The intent is to describe a generic process that can be applied both efficiently and effectively by any organization to any work product.
The main objectives of reviews are to detect issues, to evaluate alternatives, to improve organizational and personal processes, and to improve work products. When applied early in the life cycle, reviews are typically shown to reduce the amount of unnecessary rework on a project. The work product review techniques presented in this document can be used at various stages of the generic review process to identify defects and evaluate the quality of the work product.
Review documents that are produced during work product reviews are defined in Annex A.
1 Scope
This document establishes a generic framework for work product reviews that can be referenced and used by all organizations involved in the management, development, test and maintenance of systems and software. It contains a generic process, activities, tasks, review techniques and documentation templates that are applied during the review of a work product. A work product is any artefact produced by a process. This document defines work product reviews that can be used during any phase of the life cycle of any work product. This document is intended for, but not limited to, project managers, development managers, quality managers, test managers, business analysts, developers, testers, customers and all those involved in the development, testing and maintenance of systems and software.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
- ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 24765 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
3.1
ad hoc reviewing
unstructured independent review technique
3.2
author check
informal review performed by the author of the work product
3.3
buddy check
informal review performed independently by a colleague of the author
3.4
checklist-based reviewing
review technique guided by a list of questions or required attributes
3.5
formal review
form of review that follows a defined process with formal documented output
3.6
informal review
form of review that does not follow a defined process and has no formal documented output
3.7
informal group review
informal review performed by three or more persons
3.8
inspection
formal review of a work product to identify issues, which uses defined team roles and measurement to improve the review process
EXAMPLE:
Fagan Inspections[7] are a specific type of inspection and code inspections are used to review program source code.
3.9
issue
observation that deviates from expectations
EXAMPLE:
Potential defect, improvement or point needing clarification.
3.10
milestone review
formal review of a work product and supporting evidence used to determine its acceptability for use in the next stage of development or for delivery
Note 1 to entry: The requirement for this form of review is normally specified in the project plan.
3.11
page-by-page reviewing
technique where reviewers review a work product in a sequential order
3.12
pair review
informal review of a work product performed by two suitably qualified people other than the author working together
3.13
peer desk check
informal review where the author and a colleague walk through a work product
3.14
peer review
review of work products performed by others qualified to do the same work
3.15
perspective-based reading
form of role-based reviewing that uses checklists and involves the creation of prototype deliverables to check the completeness and other quality characteristics of the work product
3.16
role-based reviewing
technique where reviewers review a work product from the perspective of different stakeholder roles
EXAMPLE:
Typical stakeholder roles include specific user types, such as work product maintainer, tester and developer.
3.17
scenario-based reviewing
technique where the review is guided by determining the ability of the work product to address specific scenarios
3.18
technical review
formal peer review of a work product by a team of technically-qualified personnel that examines the suitability of the work product for its intended use and identifies discrepancies from specifications and standards
Note 1 to entry: Technical review may also provide recommendations of alternatives and examination of various alternatives.
3.19
walkthrough
formal review in which an author leads members of the review through a work product, and the participants ask questions and make comments about possible issues
3.20
work product
artefact produced by a process
EXAMPLE:
Project plan, requirements specification, design documentation, source code, test plan, test meeting minutes, schedules, budgets, and incident reports.
Note 1 to entry: A subset of the work products can be baselined to be used as the basis of further work and some will form the set of project deliverables.
Bibliography
| [1] | ISO/IEC 12207, Systems and software engineering — Software life cycle processes |
| [2] | ISO/IEC/IEEE 15288, Systems and software engineering — System life cycle processes |
| [3] | ISO/IEC/TR 19759, Software Engineering — Guide to the software engineering body of knowledge (SWEBOK) |
| [4] | ISO/IEC/TS 24748-1, Systems and software engineering — Life cycle management — 1: Guidelines for life cycle management |
| [5] | ISO/IEC 25010, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models |
| [6] | ISO/IEC 25030, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements |
| [7] | Fagan M., Design and Code Inspections to Reduce Errors in Program Development. IBM Syst. J. 1976, 15 (3) |
| [8] | Gawande A., The Checklist Manifesto. Metropolitan Books, 2009 |
| [9] | Gilb T., Graham D., Software Inspection. Addison-Wesley, 1993 |
| [10] | Hass A.M.J., Guide to Advanced Software Testing. Artech House, 2008 |
| [11] | IEEE 1028-2008, IEEE Standard for Software Reviews and Audits |
| [12] | IEEE 15288.2-2014, IEEE Standard for Technical Reviews and Audits on Defence Programs |
| [13] | Kaner C., Testing Computer Software. TAB Books Inc, 1998 |
| [14] | Kit E., Software Testing in the Real World: Improving the Process. ACM Press, 1995 |
| [15] | Laitenberger O., DeBaud J., 1998. An Encompassing Life-Cycle Centric Survey of Software Inspection. Tech. Report No. ISERN-98-32, Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany |
| [16] | Myers G., The Art of Software Testing. John Wiley and Sons Inc, 1979 |
| [17] | Sauer C. et al., The Effectiveness of Software Development Technical Reviews: A Behaviourally Motivated Program of Research. IEEE Trans. Softw. Eng. 2000 January, 26 (1) |
| [18] | Shull F., Rus I., Basili V, July 2000. How Perspective-Based Reading can improve Requirement Inspections. IEEE Computer |
| [19] | Wiegers K., Peer Reviews in Software — A Practical Guide. Addison-Wesley, 2001 |