IEEE 1062-1998 pdf download IEEE Recommended Practice for Software Acquisition
1.Overview
This recommended practice is divided into six clauses. Clause 1 provides the scope of this recommendedpractice. Clause 2 lists references to other standards that are useful in applying this recommended practiceclause 3 provides definitions that are either not found in other standards. or have been modified for use withthis recommended practice. Clause 4 establishes the nine steps involved in a software acquisition processrelates each of these steps to a major acquisition phase, and identifies the key inputs and outputs of each stepClause 5 describes the nine steps in a software acquisition process and the related quality practices that applyto acquiring software. In order to be in compliance with this recommended practice, an implementation mustadhere to Clause 5.Clause 6 summarizes the successful way to acquire high-quality products and servicesfrom software suppliers.
This recommended practice also contains three annexes. Annex A provides a set of checklists that individuals or organizations may elect to adapt to their specific needs, Annex B provides acquisition plan guidelinesand Annex C provides guidelines for compliance with IEEE/EIA 12207.1-1997.
1.1 Scope
This is a recommended practice for performing software acquisitions. It describes a set of useful qualitypractices that can be selected and applied during one or more steps in a software acquisition process.
In this recommended practice, software products have been classified according to the degree to which theacquirer may specify the features of the software. They are: commercial-of-the-shelf (COTS), modified-off.the-shelf (MOTS), and fully developed item.
COTS software is stable and is normally well-defined in terms of documentation and known capabilities andimitations. It usually comes with “how to operate” documentation. COTS software is defined by a marketdriven need. It is commercially available and its fitness for use has been demonstrated by a broad spectrumof commercial users. Also, the COTS software supplier does not advertise any willingness to modify thesoftware for a specific customer.
MOTS software is similar to COTS software: however. MOTS software does advertise services to tailor thesoftware to acquirer-specific requirements.
Fully developed software will often be unique for a specific application and will be produced on a one-of-akind or low-volume basis. The software typically will have the potential for future modification by theacquirer to meet changing needs. As a result, most of the documentation will be special to the project (withthe exception of the supplier’s standard documentation for the operating system, any standard applicationpackages,and programming languages).
This recommended practice can be applied to software that runs on any computer system regardless of thesize. complexitv. or criticality of the software, However. this recommended practice is more suited for use orMOTS software and fully developed software. Each organization using this recommended practice will neecto identify the classes of software to which this recommended practice applies and the specific quality characteristics and activities that need to be included within the acquisition process
1.2 Terminology
The words shall and must identify the mandatory (essential) material within this recommended practice. Thewords should and may identify optional (conditional) material. The terminology in this recommended prac.tice is based on IEEE Std 610.12-1990. New terms and modified definitions as applied in this recommendedpractice can be found in Clause 3
2.References
The following standards are directly referenced in this recommended practice. Table 1 provides a crossreference of standards that address topics related to software acquisition. These standards are binding to theextent relerenced within the text of this recommended practice and are relerenced to avoid duplication olrequirements.
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
IEEE Std 730-1998,IEEE Standard for Software Quality Assurance Plans.
IEEE Std 829-1998.IEEE Standard for Software Test Documentation.
IEEE Std 830-1998,IEEE Recommended Practice for Software Requirements Specifications.
IEEE Std 1012-1998,IEEE Standard for Software Verification and Validation.
IEEE Std 1012a-1998,IEEE Standard for Software Verification and Validation: Content Map to IEEE/EIA12207.1-1997.
IEEE Std 1016-1998,IEEE Recommended Practice for Software Design Descriptions.
IEEE Std 1028-1997,IEEE Standard for Software Reviews.
IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software Configuration Management.
IEEE 1062-1998 pdf download
PS:Thank you for your support!
