IEEE 1062:2016 pdf free download – IEEE Recommended Practice for Software Acquisition
4.1 Introduction
Software can be acquired in three different ways or a combination of the three. It is acknowledged that anycombination of these three alternatives will make the overall software project more complex and likely tobe different from each other. This document does not attempt to address the combinations of these threebasics software acquisition options. The software acquisition alternatives include contracting custom-developed software，obtaining the right to use off-the-shelf (OTS) software and renting software as aservice(SaaS). The advantages and disadvantages of each option are summarized in Table i.
4.2 Custom-developed software
Reaching an agreement, often a formal contract for the custom development is an acquisition approachwhere the solution to an acquirer ‘s need is provided via hiring a supplier (outsourcing) or using an internalteam to custom develop a software solution that is built to a specification or set of requirements. Followingsoftware development standards and known methods, the acquirer oversees the development, test activities,and products performed by the supplier.At acceptance, the acquirer takes ownership of the solution andpossibly some of the supporting tools/methods in order to support ops/maintenance of the solution. Thisoption includes software built from scratch andor integrated from other existing components (e.g., reuse,modified FOSS).
4.3 Off-the-shelf (OTS)software
This is an acquisition approach where the solution to an acquirer’s need is provided via purchasing andtaking possession of an already built solution from a software supplier. The acquirer agrees to the seller’slicense agreement to use the “executable”version of the solution but typically does not have access to thesource code or other information about the solution or the processes used to produce that product. Inaddition, the acquirer typically takes possession of the software solution and installs in on assets owned bythe acquirer. In addition, the solution is typically acquired in”as is” condition, unless the supplier offersbuilt-in tailoring of the product (and this more common than not).This option includes commercial off-the-shelf (COTS), free and open source software(FOSS) products acquired in “as is”condition, and other non-developmental items (NDI).
4.4 Software as a service (Saas)
Software as a service(SaaS) is an acquisition approach where the solution to an acquirer’s need is providedvia an agreement with a supplier for access to a software product for a fixed amount of time and to use thatsoftware product remotely， via connection (wired, wireless， etc.) to the supplier’s assets. Inputs to theremote software product are transmitted to the supplier and outcomes/results/products from using thesoftware product are transmitted back to the acquirer. This acquisition option is part of the CloudComputing approach (NIST Special Publication 800-145 [B12]) to software (aka renting access toproducts, services, infrastructure, etc.) and is frequently referred to as software as a service(SaaS).
5.1.2 Activities and tasks
Software can be acquired as a stand-alone product, as a service, or embedded in a system consisting of asingle processor or a large, complex system with many hardware items. This clause describes the activitiesin the software acquisition process and is applicable to the acquisition of developed software，non-developmental software (CoTs, reuse, or FOSS), and software services.
5.1.3 Principal acquisition roles
There are three principal roles involved: acquirer, supplier, and end user. These roles may be performed bya single individual in a small business or by multiple people representing organizations in a large corporateor government environment. The acquirer develops the method to satisfy the identified need and thesupplier provides the required product or service to the end user.