IEEE - J-STD-016
Standard for Information Technology Software Life Cycle Processes Software Development Acquirer- Supplier Agreement
|Publication Date:||30 September 1995|
This standard establishes uniform requirements for software development activities and resulting software products. It is also intended to merge commercial and Government software development requirements within the framework of the software life cycle process requirements of the Electronic Industries Association (EIA), Institute of Electrical and Electronics Engineers (IEEE), and International Organization for Standardization (ISO). The term "software development" is used as an inclusive term encompassing new development, modification, reuse, reengineering, maintenance, and all other processes or activities resulting in software products.
The requirements in this standard are intended for application to the development of systems that contain software (such as software embedded in hardware-software systems), to systems consisting of software alone, and to stand-alone software products. This standard is intended to be applied as follows.
This standard can be:
a) Included or referenced in contracts or similar agreements, with the parties (called the acquirer and the developer) agreeing that the developer will perform software development in accordance with the standard
b) Adopted as an in-house standard by a project or organization that decides to perform software development in accordance with the standard
c) Used as the basis for an organization's software development process
Organizations and agreements
This standard can be applied to contractors, subcontractors, or in-house organizations performing software development. For uniformity, the term "acquirer" is used for the organization requiring the technical effort, "developer" for the organization performing the technical effort, "contract" for the agreement between these parties, "Statement of Work" (SOW) for the list of tasks to be performed by the developer, "subcontractor" for any organization tasked by the developer to perform part of the required effort, "user" for the persons or organizations that will operate and/or use the software, and "maintenance organization" for the organization that will have responsibility for modifying and otherwise maintaining the software after transition from the development organization.
When this standard is invoked in a contract, it applies to each software product and to each type of software covered by the contract, regardless of storage medium, to the extent specified in the contract. Examples of types of software include deliverable versus non-deliverable, software designed to meet user needs versus software in the engineering and test environments, and software designed to meet one user need versus software designed to meet another. The acquirer is expected to specify the types of software to which the standard applies. Software installed in firmware is subject to all of the aforementioned provisions. This standard does not apply to the hardware element of firmware.
When this standard is used to assist an organization in defining and establishing its software development process, it is intended for reference as a source of recommended software development activities and products on which to build specific organizational practices and procedures. When the standard is applied on an in-house development project, it is intended to be used as a source for selecting software development activities and products to satisfy specific project needs.
This standard is meant to be tailored for each type of software to which it is applied. The standard is to be tailored to the specific requirements of a particular program, program phase, or contractual structure. Tailoring takes the form of deletion of unnecessary requirements, alteration of requirements to more explicitly reflect the application to a particular effort, or addition of requirements as needed. Care is to be taken to eliminate tasks and data that add unnecessary costs or that do not add value to the activity or the product for the project. The tailoring requirements of this standard are normative (that is, binding) to be performed in accordance with this standard. Tailoring requirements, specified in annex A, are not subject to tailoring. All other requirements of this standard are considered tailorable. While final tailoring decisions are the responsibility of the acquirer, tailoring may be performed jointly with prospective or selected developers. Tailoring guidance can be found in annexes B and C.
Compliance with this standard means "compliance with the standard as tailored for the project and recorded in the contract."
NOTE - Regulatory and legal requirements are invoked separately through the contract.
Compliance with the "as tailored" standard
Compliance with the "as tailored"standard is defined as:
a) Performing the activities that resulted from tailoring this standard for a specific project as recorded in the contract
b) Recording applicable information resulting from the performance of the selected activities
Activity completion criteria
An activity is complete when all items constituting the activity, as specified in the contract, have been accomplished and applicable information has been recorded.
Any entity (such as, person, company, Military Service, industrial association, organization) imposing this standard as a condition of trade is responsible for identifying and making public the minimum set of activities and resulting software products that is required to be fulfilled by a developer.
Interpretation of selected terms
The following terms have a special interpretation as used in this standard. These are not "definitions" of the terms, but clarifications of their use.
Interpretation of "system"
The following interpretations apply:
a) The term "system," as used in this standard, may mean: (1) a hardware-software system (for example, a radar system) for which this standard covers only the software portion, or (2) a software system (for example, a payroll system) for which this standard governs overall development.
b) If a system consists of subsystems, all requirements in this standard concerning systems apply to the subsystems as well. If a contract is based on alternatives to systems and subsystems, the requirements in this standard concerning the system and its specification apply to these alternatives and their specifications.
Interpretation of "participate" in system development
The term "participate" in subclauses regarding system-level activities is to be interpreted as follows: if the software covered by this standard is part of a hardware-software system, the term "participate" is to be inter preted as "take part in, as described in the Software Development Plan." If the software (possibly with its computers) is considered to constitute a system, the term "participate" is to be interpreted as "be responsible for." If the software in a hardware-software system is changed, but the hardware is not, the term "participate" may also be interpreted as "be responsible for."
Interpretation of "develop," "define," etc.
Throughout this standard, requirements to "develop," "define," "establish," or "identify" information are to be interpreted to include new development, modification, reuse, reengineering, maintenance, or any other activity or combination of activities resulting in software products.
Interpretation of "record"
Throughout this standard, requirements to "record" information are to be interpreted to mean "set down in a manner that can be retrieved and viewed." The result may take many forms, including, but not limited to, hand-written notes, hard-copy or electronic documents, and data recorded in computer-aided software engineering (CASE) and project management tools.
Interpretation of "applicable"
Throughout this standard, requirements to provide "applicable" information and perform "applicable" activities are to be interpreted to mean "provide the information and perform the activities that are natural by-products created by performing the activities required for the project in accordance with the tools, methods, and procedures described in the software development plan." The term "applicable" conveys the meaning that not all projects will generate the information or require the activity. "Applicability" is to be agreed upon jointly by the acquirer and developer.