IEEE 1062-1998 pdf download

01-07-2023 comment

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.

                                           Related Information                                             Download
PS:Thank you for your support!
IEEE C63.19-2011 pdf download IEEE Standards

IEEE C63.19-2011 pdf download

IEEE C63.19-2011 pdf download American National Standard Methods of Measurement of Compatibility between Wireless Communications Devices and Hearing Aids .3 Organization and use of the standard These technical requirements specify the measurement methods and categorical levels to...
Read More
IEEE 1609-4-2011 pdf download IEEE Standards

IEEE 1609-4-2011 pdf download

IEEE 1609-4-2011 pdf download IEEE Standard for Wireless Access in Vehicular Environments (WAVE)— Multi-channel Operation control channel (CCH) interval: A specified periodic interval of time with respect to CoordinatedUniversal Time (UTC). During the CCH interval a device...
Read More
IEEE 1725-2012 pdf download IEEE Standards

IEEE 1725-2012 pdf download

IEEE 1725-2012 pdf download IEEE Standard for Rechargeable Batteries for Cellular Telephones 3. Definitions For the purposes of this document, the following terms and definitions apply. The IEEE StandardsDictionary: Glossary of Terms & Definitions should be consulted...
Read More

LEAVE A REPLY

Anonymous netizen Fill in information