IEEE 1012-2012 en System and Software Verification and Validation (IEEE Computer Society)《软件和系统的鉴定和认证IEEE标准》.pdf

《IEEE 1012-2012 en System and Software Verification and Validation (IEEE Computer Society)《软件和系统的鉴定和认证IEEE标准》.pdf》由会员分享，可在线阅读，更多相关《IEEE 1012-2012 en System and Software Verification and Validation (IEEE Computer Society)《软件和系统的鉴定和认证IEEE标准》.pdf（223页珍藏版）》请在麦多课文档分享上搜索。

1、 IEEE Standard for System andSoftware Verification and Validation Sponsored by the Software +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2012 IEEE. All rights reser

2、ved. Notice to users Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsi

3、ble for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights This document is copyrighted by the IEE

4、E. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adopti

5、on by public authorities and private users, the IEEE does not waive any rights in copyright to this document. Updating of IEEE documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to

6、 time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition an

7、d whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http:/standards.ieee.org/index.html or contact the IEEE at the address listed previously. For more information about the IEEE Standards Association or the IEEE standards development

8、process, visit IEEE-SA Website at http:/standards.ieee.org/index.html. Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically. v Copyright 2012 I

9、EEE. All rights reserved. Patents Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights i

10、n connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http:/standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitt

11、er is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a

12、Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connec

13、tion with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own respons

14、ibility. Further information may be obtained from the IEEE Standards Association. vi Copyright 2012 IEEE. All rights reserved. Participants At the time this standard was submitted to the IEEE-SA Standards Board for approval, the Std for Software Verification and Validation Working Group (C/S2ESC/101

15、2_WG) Working Group had the following membership: Roger U. Fujii, Chair Kenneth A. Costello, Vice Chair Edward A. Addy, Secretary Stephen Allott Susan M. Burgess Tiffany Burgess William Burgess Milton Concepcion Darrell Cooksey Paul D. Croll David H. Daniel Taz Daughtrey Jon Davis Ronald Dean Josiah

16、 Devasirvatham Harpal Dhama Stephen Driskell Christof Ebert Uma Ferrell Kevin R. Finlay Eva Freund Ron Greenthaler Jon D. Hagar George Hughes Lisa A. Jensen Lance Kelson Thomas M. Kurihara Carol Long Charles R. Martin Dan McCaugherty Robert R. Moniri James W. Moore Kevin Morgan Jeff Northey Nitin Pa

17、tel Robert A. Peterson Michael D. Prendergast Laura Pullum Steven R. Rakitin Scott W. Schield Raymond Senechal Luca Spotorno Eric Sylvania Gina To Hasso Von Bredow Michael E. Waterman Kurt Woodham Steve YangThe following members of the individual balloting committee voted on this standard. Balloters

18、 may have voted for approval, disapproval, or abstention. Edward A. Addy Johann Amsenga T. Ankrum Chris Bagge Charles Barest H. Stephen Berger Juris Borzovs Pieter Botman Susan M. Burgess Mark Bushnell Juan Carreon Sue Carroll Lawrence Catchpole Keith Chow Darrell Cooksey Kenneth A. Costello Paul D.

19、 Croll David H. Daniel Geoffrey Darnton Ronald Dean Joseph Decuir Thomas Dineen Randall Dotson Sourav Dutta Andrew Fieldsend Gregory Fleming Andre Fournier Eva Freund David Friscia Roger U. Fujii David Fuschi Lewis Gray Ron Greenthaler J. Gregory Randall Groves Jon D. Hagar John Harauz Mark Henley D

20、avid Herrell Rutger A. Heunks Frank Hill Werner Hoelzl George Hughes Peter Hung Noriyuki Ikeuchi Atsushi Ito Mark Jaeger Cheryl Jones Anatol Kark Piotr Karocki Yuri Khersonsky Dwayne Knirk Thomas M. Kurihara George Kyle Susan Land Claude Laporte J. Dennis Lawrence David Leciston Daniel Lindberg Vinc

21、ent Lipsio Greg Luri Wayne W. Manges Edward Mccall Dan McCaugherty Robert R. Moniri James W. Moore Michael S. Newman Warren Odess-Gillett Robert A. Peterson William Petit Michael D. Prendergast Iulian Profir Laura Pullum Steven Rakitin Annette Reilly Robert Robinson Keith Roseberry Terence Rout Rand

22、all Safier Bartien Sayogo Robert Schaaf Hans Schaefer Scott W. Schield David Schultz Stephen Schwarm Raymond Senechal John Short vii Copyright 2012 IEEE. All rights reserved. Gil Shultz Carl Singer James Sivak Michael Smith Kapil Sood Luca Spotorno Friedrich Stallinger Thomas Starai Walter Struppler

23、 Gerald Stueve Marcy Stutzman Steven Tilden Thomas Tullia Vincent Tume Mark-Rene Uchida John Vergis David Walden Charlene Walrad John Walz Michael E. Waterman Stephen Webb Simone Youngblood Jian Yu Oren Yuen Janusz Zalewski Daidi Zhong When the IEEE-SA Standards Board approved this standard on 29 Ma

24、rch 2012, it had the following membership: Richard H. Hulett, Chair John Kulick, Vice Chair Robert Grow, Past Chair Judith Gorman, Secretary Satish Aggarwal Masayuki Ariyoshi Peter Balma William Bartley Ted Burse Clint Chaplin Wael Diab Jean-Philippe Faure Alexander Gelman Paul Houz Jim Hughes Young

25、 Kyun Kim Joseph L. Koepfinger* David J. Law Thomas Lee Hung Ling Oleg Logvinov Ted Olsen Gary Robinson Jon Walter Rosdahl Mike Seavey Yatin Trivedi Phil Winston Yu Yuan *Member Emeritus Also included are the following nonvoting IEEE-SA Standards Board liaisons: Richard DeBlasio, DOE Representative

26、Michael Janezic, NIST Representative Don Messina IEEE Standards Program Manager, Document Development Malia Zaman IEEE Standards Program Manager, Technical Program Development viii Copyright 2012 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 1012-2012, IEEE Standa

27、rd for System and Software Verification and Validation. Verification and validation (V however, not all life cycle models use all of the life cycle processes described in this standard. x Copyright 2012 IEEE. All rights reserved. Contents 1. Overview 1 1.1 Scope . 1 1.2 Purpose 2 1.3 Field of applic

28、ation 3 1.4 V however, not all life cycle models use all of the processes listed in this standard. V however, the methods and purpose will differ for each organizations functional objectives. ISO/IEC 15288:2008 B16 and ISO/IEC 12207:2008 B11 require that the developer perform various testing and eva

29、luation tasks as an integral part of implementation. The techniques described in this standard may be useful in performing the developers tests and evaluations. Therefore, whenever this standard mentions the developers performance of a verification or validation activity, it is to be understood that

30、 the reference applies to the test and evaluation tasks of implementation. 1.2 Purpose The purpose of the standard is to perform the following: Establish a common framework of the V however, this standard does not prescribe any normative references. Clause 3 provides a definition of terms, abbreviat

31、ions, and conventions. Clause 4 describes the relationships between the V that is, tasks that are common across application of this standard to system, software, or hardware. 1) Table 1a contains the V in order not to repeat these V therefore, a corresponding adaptation of the minimum V satisfy stan

32、dards, practices, and conventions during life cycle processes; and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities. Verification of interim work products is essential for proper understanding and assessment of the life cycle

33、 phase product(s). NOTEFor (A), see ISO/IEC/IEEE 24765-2010 B19. verification and validation (V a hazard analysis for integrity level 3 software may consider only significant software failures and be documented informally as part of the design review process. Use the integrity schema established for

34、 the system, software, or hardware, if one exists. An integrity-level scheme shall be specified if one is not already defined. Establish gradations of criticality and integrity to assure complete partitioning of the potential effects space from “no effect” to “worst case.” The integrity levels estab

35、lished for a system element by the developer should result from agreements among the acquirer and the supplier and remain consistent with the regulatory requirements. This standard was developed with a four-level schema to explain the minimum normative V&V requirements. Other integrity schemas are a

36、cceptable. For any selected integrity schema, the selected integrity levels shall be mapped into this standards four-level schema to demonstrate that the minimum V&V requirements are satisfied. Because V&V is applied recursively from the system of interest down to each of the subsystems or elements

37、at the next level, it is not necessary to use the same integrity-level schema for all the subsystems or elements of the system of interest. NOTEA process for developing an integrity schema can be found in ISO/IEC 15026-2011 B12. The V&V criticality analysis task is used to classify the integrity lev

38、el of every system (e.g., subsystem) or element in the system of interest. Integrity levels are assigned to requirements, functions, groups of functions, components, or subsystems. The integrity levels characterize and quantify the potential for undesirable effects and consequences resulting from in

39、tegrity lapse, unintended effects, failure mode effects, and unverified performance effects. The characteristics that determine integrity level vary depending on the intended application and use of the system. Integrity-level assignments shall be applied recursively to the components of each system

40、element. As the development stages progressively decompose the solution into more details, the criticality analysis performed at each development stage assigns integrity levels to each function. By recursively assigning integrity levels to individual solution parts, greater rigor and intensity is ap

41、plied to the higher integrity level elements. Progressive decomposition for criticality analysis and assignment of integrity levels shall be applied to segregate parts that warrant high-integrity V&V tasks from those parts that do not. This recursive assignment of integrity levels to solution parts

42、keeps the V&V effort focused on the high-integrity elements, making the V&V effort cost efficient and technically effective. From the system perspective, during integrity-level analysis, software and hardware are treated as functional elements. Subsystem components cannot have a higher criticality o

43、r integrity level than the parent subsystem. The system shall be assigned the same integrity level as the highest level assigned to any IEEE Std 1012-2012 IEEE Standard for System and Software Verification and Validation 16 Copyright 2012 IEEE. All rights reserved. individual element. The integrity

44、level assigned to the parent shall be as high as the highest integrity level of the system elements. The system elements can have the integrity level of the system parent or lower depending on the critical functions it supports. The integrity level assigned to reused, COTS, and government off-the-sh

45、elf (GOTS) components shall be in accordance with the integrity-level scheme adopted for the system element into which COTS or GOTS may be integrated for the project. The reused COTS or GOTS component shall be evaluated for use in the context of its application. The design, development, procedural,

46、and technology features implemented in the system can raise or lower the assigned integrity levels. The V&V criticality analysis task is used to classify the integrity level of enabling systems. The tools that insert or translate code (e.g., optimizing compilers and auto-code generators) shall be as

47、signed the same integrity level as the integrity level assigned to the software element that the tool affects. If the tool cannot be verified and validated, then the output of the tool shall be subject to the same level of V&V as the software element. The mapping of the integrity-level scheme and th

48、e associated minimum V&V tasks shall be documented in the VVP. The basis for assigning integrity levels to components shall be documented in a V&V task report and V&V final report. Table 2a through Table 2d of this standard identify the necessary and sufficient V&V activities and tasks to perform fo

49、r each integrity level. Once the integrity levels have been determined, Table 2a through Table 2d are used to identify the activities and tasks to adapt and plan the V&V effort. High integrity requires a larger set of V&V processes and a more rigorous application of V&V tasks. The V&V processes should be tailored to specific system elements with a combination of the minimum V&V tasks and addition of optional V&V tasks. The addition of optional V&V tasks allows the V&V effort to address application-specific characteristics. Table 3a through Table 3d provid