UNLIMITED FREE ACCESS TO THE WORLD'S BEST IDEAS

close
Already an Engineering360 user? Log in.

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

Customize Your Engineering360 Experience

close
Privacy Policy

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

Webinars & White Papers

IEEE - J-STD-016

Standard for Information Technology Software Life Cycle Processes Software Development Acquirer- Supplier Agreement

inactive, Most Current
Organization: IEEE
Publication Date: 30 September 1995
Status: inactive
Page Count: 160
scope:

Purpose

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.

Application

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.

Candidate uses

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.

Contract-specific application

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.

In-house application

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.

Tailoring

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

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.

Compliance stipulation

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.

Document History

J-STD-016
September 30, 1995
Standard for Information Technology Software Life Cycle Processes Software Development Acquirer- Supplier Agreement
Purpose This standard establishes uniform requirements for software development activities and resulting software products. It is also intended to merge commercial and Government software development...

References

Advertisement