1、 IEEE Recommended Practice for Software Acquisition Sponsored by the Software fitness for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effo
2、rt. IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.” Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of
3、 the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. In publishing and making its standards available, IEEE is not sugge
4、sting or rendering professional or other services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exerci
5、se of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
6、, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE
7、 OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE. Translations The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only th
8、e English version published by IEEE should be considered the approved IEEE standard. Copyright 2016 IEEE. All rights reserved. 4 Official statements A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered or inferre
9、d to be the official position of IEEE or any of its committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views
10、 should be considered the personal views of that individual rather than the formal position of IEEE. Comments on standards Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consultin
11、g information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that any response
12、s to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to comments or questions except in those cases where the matter has previously
13、been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join the relevant IEEE working group. Comments on standards should be submitted to the following address: Secretary, IEEE-SA
14、Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA 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. Impleme
15、nters of the standard are responsible 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 IEEE
16、draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws. They are made available by IEEE and are adopted 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, sta
17、ndardization, and the promotion of engineering practices and methods. By making these documents available for use and adoption by public authorities and private users, IEEE does not waive any rights in copyright to the documents. Photocopies Subject to payment of the appropriate fee, IEEE will grant
18、 users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual, non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danve
19、rs, MA 01923 USA; +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. Copyright 2016 IEEE. All rights reserved. 5 Updating of IEEE Standards documents Users of IEEE Standards documents
20、 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 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 w
21、ith any amendments, corrigenda, or errata then in effect. Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not who
22、lly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata,
23、 visit the IEEE-SA Website at http:/ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more information about the IEEE SA or IEEEs standards development process, visit the IEEE-SA Website at http:/standards.ieee.org. Errata Errata, if any, for all IEEE standa
24、rds can be accessed on the IEEE-SA Website at the following URL: http:/standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically. Patents Attention is called to the possibility that implementation of this standard may require use of subject matter
25、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 in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the
26、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 Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and condi
27、tions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be requir
28、ed, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standa
29、rd are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. Copyright 2016 IEEE. All rights reserved. 6 Participants At th
30、e time this IEEE recommended practice was completed, the RP of the Software Acquisition Working Group had the following membership: Marcus Hervey, Chair Paul Bishop, Vice Chair Philip Bernick, Secretary Angela Anuszewski Taohong Chang Milton Concepcion Steve Cropper Suellen Eslinger Michael George G
31、uy Goodwin Jay Griesser Leslie Holloway Thomas Howard Kathleen Kaplan Ronald Kohl Dana Kusumo Mario Lozano Linda Martinez Winifred Menezes Zvikomborero Murahwi Lori Naiberg-Olson Annette Reilly Alberto Sampaio Rob Schaaf Mike Smith Joan Williamson Sharon Young The following members of the individual
32、 balloting committee voted on this recommended practice. Balloters may have voted for approval, disapproval, or abstention. Johann Amsenga Bakul Banerjee Pieter Botman Susan Burgess Juan Carreon Sue Carroll Suresh Channarasappa Keith Chow S Claassen Raul Colcher Paul Croll Geoffrey Darnton Ronald De
33、an Sourav Dutta Andrew Fieldsend Eva Freund David Fuschi Gregg Giesler Randall Groves Louis Gullo John Harauz Mark Henley Richard Hilliard Werner Hoelzl Bernard Homes Noriyuki Ikeuchi Atsushi Ito Mark Jaeger Cheryl Jones Adri Jovin Piotr Karocki Yuri Khersonsky Thomas Kurihara Dewitt Latimer Claire
34、Lohr Edward Mccall James W. Moore Michael Newman Olileanya Ogbonna Robert Peterson Annette Reilly Robert Robinson Randy Saunders Bartien Sayogo Robert Schaaf Hans Schaefer Maud Schlich Carl Singer Michael Smith Kendall Southwick Luca Spotorno Thomas Starai Eugene Stoudenmire Walter Struppler Marcy S
35、tutzman Michael Swearingen Thomas Tullia John Vergis David Walden Michael Waterman Stephen Webb Jian Yu Oren Yuen Daidi Zhong Copyright 2016 IEEE. All rights reserved. 7 When the IEEE-SA Standards Board approved this recommended practice on 5 December 2015, it had the following membership: John D. K
36、ulick, Chair Jon Walter Rosdahl, Vice Chair Richard H. Hulett, Past Chair Konstantinos Karachalios, Secretary Masayuki Ariyoshi Ted Burse Stephen Dukes Jean-Philippe Faure J. Travis Griffith Gary Hoffman Michael Janezic Joseph L. Koepfinger* David J. Law Hung Ling Andrew Myles T. W. Olsen Glenn Pars
37、ons Ronald C. Petersen Annette D. Reilly Stephen J. Shellhammer Adrian P. Stephens Yatin Trivedi Phillip Winston Don Wright Yu Yuan Daidi Zhong *Member Emeritus Copyright 2016 IEEE. All rights reserved. 8 Introduction This introduction is not part of IEEE Std 1062-2015, IEEE Recommended Practice for
38、 Software Acquisition. This introduction provides some background on the rationale used to develop this recommended practice. This information is meant to aid in the understanding and usage of this recommended practice. This recommended practice describes the management and execution of software acq
39、uisition activities. It is intended for the following: Individuals or organizations that acquire software from suppliers Individuals or organizations that acquire software from a developer for resale to other individuals or organizations Individuals or organizations that influence how software is ac
40、quired from suppliers Suppliers interested in providing high-quality software to acquirers This recommended practice is designed to help organizations and individuals Incorporate quality considerations during the definition, evaluation, selection, and acceptance of supplier software for operational
41、use Determine how supplier software should be evaluated, tested, and accepted for delivery to end users This recommended practice is intended to satisfy the following objectives: Promote consistency within organizations in acquiring third-party software from software suppliers Provide useful practic
42、es on including quality considerations during software acquisition planning Provide useful practices on evaluating and qualifying supplier capabilities to meet user software requirements Provide useful practices on evaluating and qualifying supplier software Assist individuals or organizations judgi
43、ng the quality of supplier software for referral to end users Copyright 2016 IEEE. All rights reserved. 9 Contents 1. Overview 11 1.1 Scope . 11 1.2 Purpose 12 2. Normative references 12 3. Definitions and terms . 13 3.1 Definitions . 13 3.2 Use of should, may, and can 13 4. Software acquisition alt
44、ernatives 13 4.1 Introduction . 13 4.2 Custom-developed software 14 4.3 Off-the-shelf (OTS) software. 14 4.4 Software as a service (SaaS) 15 5. Software acquisition process 18 5.1 Purpose 18 5.2 Eight steps in acquiring quality software . 19 5.3 Step 1: Planning the software acquisition strategy 22
45、5.4 Step 2: Defining the acquisition and software requirements . 24 5.5 Step 3: Identifying potential suppliers . 26 5.6 Step 4: Preparing contract requirements 28 5.7 Step 5: Evaluating proposals and selecting the supplier 30 5.8 Step 6: Managing for supplier performance 32 5.9 Step 7: Accepting th
46、e software 33 5.10 Step 8: Evaluating the process and identifying improvement opportunities 34 6. Quality assurance for software acquisition . 36 6.1 Objectives of quality assurance in software acquisition 36 6.2 Implementing quality assurance in software acquisition . 36 Annex A (informative) Check
47、lists for quality software acquisition processes . 38 A.1 Checklist 1: Organizational strategy 39 A.2 Checklist 2: Define the software 40 A.3 Checklist 3: Supplier selection evaluation . 42 A.4 Checklist 4: Supplier and acquirer obligations 44 A.5 Checklist 5: Quality and maintenance plans 45 A.6 Ch
48、ecklist 6: User survey 46 A.7 Checklist 7: Supplier performance standards . 49 A.8 Checklist 8: Contract payments . 50 A.9 Checklist 9: Monitor supplier progress 51 A.10 Checklist 10: Software evaluation . 52 A.11 Checklist 11: Software testing . 55 A.12 Checklist 12: Software acceptance 56 Annex B
49、(informative) Software safety assurance and software information security assurance 57 B.1 Software safety assurance . 57 B.2 Software information security assurance 58 Annex C (informative) Rights in technical data and software usage 61 Copyright 2016 IEEE. All rights reserved. 10 Annex D (informative) Acquisition plan guidelines . 62 D.1 (AP Section1) Introduction . 62 D.2 (AP Section 2) References 63 D.3 (AP Section 3) Definitions 63 D.4 (AP Section 4) Software acquisition overview . 63 D.5 (AP Section 5) Software acquisition process 64 D.6 (AP Se