Acceptance Test (ISO 2382-20)

The test of a system or functional unit usually performed by the purchaser on his premises after installation with the participation of the vendor to ensure that the contractual requirements are met.

Acquirer (ISO 12207)

Stakeholder that acquires or procures a product or service from a supplier.

Note: The acquirer could be one of the following: buyer, customer, owner, or purchaser.

Agreement (ISO 15288)

Mutual acknowledgement of terms and conditions under which a working relationship is conducted.

Alpha testing (ISO 24765)

First stage of testing before a product is considered ready for commercial or operational use (cf. beta testing).

Note: Often performed only by users within the organization developing the software.

Assurance case (ISO 15026-1)

A reasoned, auditable artifact created that supports the contention that its top-level claim (or set of claims), is satisfied, including systematic argumentation and its underlying evidence and explicit assumptions that support the claim(s).

Note 1 to entry: An assurance case contains the following and their relationships:

• – one or more claims about properties;
• – arguments that logically link the evidence and any assumptions to the claim(s);
• – a body of evidence and possibly assumptions supporting these arguments for the claim(s);
• – justification of the choice of top-level claim and the method of reasoning.

Audit

1. An independent examination of a software product, software process, or set of software processes performed by a third party to assess compliance with specifications, standards, contractual agreements, or other criteria (IEEE 1028).

 Note: An audit should result in a clear indication of whether the audit criteria have been met.

2. Independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria (ISO 12207).

3. Systematic, independent, and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled.

Note 1: Internal audits, sometimes called first party audits, are conducted by the organization itself, or on its behalf, for management review and other internal purposes (e.g., to confirm the effectiveness of the management system or to obtain information for the improvement of the management system). Internal audits can form the basis for an organization's self-declaration of conformity. In many cases, particularly in small organizations, independence can be demonstrated by the freedom from responsibility for the activity being audited or freedom from bias and conflict of interest.

Note 2: External audits include second- and third-party audits. Second-party audits are conducted by parties having an interest in the organization, such as customers, or by other persons on their behalf. Third-party audits are conducted by independent auditing organizations, such as regulators or those providing certification.

Note 3: When two or more management systems of different disciplines (e.g., quality, environmental, occupational health, and safety) are audited together, this is termed a combined audit.

Note 4: When two or more auditing organizations cooperate to audit a single auditee, this is termed a joint audit.

4. An objective examination of a work product or set of work products against specific criteria (e.g., requirements). (See also “objectively evaluate.”) This is a term used in several ways in CMMI^®, including configuration audits and process compliance audits (CMMI-DEV).

Audit criteria (ISO 19011)

Set of policies, procedures, or requirements used as a reference against which audit evidence is compared.

Note: If the audit criteria are legal (including statutory or regulatory) requirements, the terms “compliant” or “noncompliant” are often used in an audit finding.

Audit evidence (ISO 19011)

Records, statements of fact, or other information that are relevant to the audit criteria and verifiable.

Note: Audit evidence can be qualitative or quantitative.

Audit findings (ISO 19011)

Results of the evaluation of the collected audit evidence against audit criteria.

Note 1: Audit findings indicate conformity or nonconformity.

Note 2: Audit findings can lead to the identification of opportunities for improvement or recording good practices.

Note 3: If the audit criteria are selected from legal or other requirements, the audit finding is termed compliance or non-compliance.

Base measure (ISO 15939)

Measure defined in terms of an attribute and the method for quantifying it.

Note: A base measure is functionally independent of other measures.

Baseline (ISO 12207)

Formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item's life cycle.

Beta testing (ISO 24765)

Second stage of testing when a product is in limited production use (cf. alpha testing).

Note: often performed by a client or customer.

Bidirectional traceability (CMMI-DEV)

An association among two or more logical entities that is discernable in either direction (i.e., to and from an entity). (See also “requirements traceability” and “traceability.”)

Black box (ISO 24765)

1. A system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant.
2. Pertaining to an approach that treats a system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant (cf. glass box).

Brainstorming (PMBOK^® Guide)

A general data gathering and creativity technique that can be used to identify risks, ideas, or solutions to issues by using a group of team members or subject-matter experts.

Branch (ISO 24765)

1. A computer program construct in which one of two or more alternative sets of program statements is selected for execution.

2. A point in a computer program at which one of two or more alternative sets of program statements is selected for execution.

Note: Every branch is identified by a tag. Often, a branch identifies the file versions that have been or will be released as a product release. May denote unbundling of arrow meaning, that is, the separation of object types from an object type set. Also refers to an arrow segment into which a root arrow segment has been divided.

Business model (Wikipedia)

A business model describes the rationale of how an organization creates, delivers, and captures value (economic, social, or other forms of value).

The essence of a business model is that it defines the manner by which the business enterprise delivers value to customers, entices customers to pay for value, and converts those payments to profit: it thus reflects management's hypothesis about what customers want, how they want it, and how an enterprise can organize to best meet those needs, get paid for doing so, and make a profit.

Catastrophic (IEEE 1012)

Loss of human life, complete mission failure, loss of system security and safety, or extensive financial or social loss.

Change control board (CCB) (PMBOK^® Guide)

A formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions. See also Configuration Control Board.

Change control procedure (ISO 24765)

Actions taken to identify, document, review, and authorize changes to a software or documentation product that is being developed.

Note: The procedures ensure that the validity of changes is confirmed, that the effects on other items are examined, and that those people concerned with the development are notified of the changes.

Change management (ISO 24765)

Judicious use of means to effect a change, or a proposed change, to a product or service.

Checklist [GIL 93]

A specialized set of questions designed to help checkers find more defects, and in particular, more significant defects. Checklists concentrate on major defects. A checklist should be no more than a single page per subject area. Checklist questions interpret specified rules.

Commit (ISO 24765)

To integrate the changes made to a developer's private view of the source code into a branch accessible through the version control system's repository.

Commit privileges (ISO 24765)

A person's authority to commit changes.

Note: Sometimes privileges are associated with a specific part of the product (e.g., artwork or documentation) or a specific branch.

Commit window (ISO 24765)

A period during which commits are allowed for a specific branch.

Note: In some development environments, commit windows for a maintenance branch might only open for short periods a few times a year.

Concept of operations (ConOps) document (IEEE 1362)

A user-oriented document that describes a system's operational characteristics from the end-user's viewpoint.

Configuration (ISO 24765)

The functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product.

Configuration audit (CMMI-DEV)

An audit conducted to verify that a configuration item or a collection of configuration items that make up a baseline conforms to a specified standard or requirement. (See also “audit” and “configuration item.”)

Configuration baseline (ISO 24765)

Configuration information formally designated at a specific time during a product's or product component's life.

Note: Configuration baselines, plus approved changes from those baselines, constitute the current configuration information.

Configuration control (ISO 24765)

An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. Synonym: change control.

Configuration control board (CCB) (ISO 24765)

A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes. See also Change Control Board.

Configuration identification (ISO 24765)

1. An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation.
2. The current approved technical documentation for a configuration item as set forth in specifications, drawings, associated lists, and documents referenced therein.

Configuration item (CI) (ISO 12207)

Item or aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process.

Configuration management (CM)

1. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, verify compliance with specified requirements (ISO 24765).
2. A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change processing and implementation status, and (4) verify compliance with specified requirements (CMMI-DEV).

Configuration status accounting (ISO 24765)

An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively.

Note: This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.

Conflict (ISO 24765)

A change in one version of a file that cannot be reconciled with the version of the file to which it is applied.

Note: can occur when versions from different branches are merged or when two committers work concurrently on the same file.

Conformity (ISO 9000)

Fulfilment of a requirement.

Contract (ISO 12207)

See Agreement.

Corrective action (PMBOK^® Guide)

An intentional activity that realigns the performance of the project work with the project management plan.

Critical (IEEE 1012)

Major and permanent injury, partial loss of mission, major system damage, or major financial or social loss.

Critical software (IEEE 610.12)

Software whose failure could have an impact on safety, or could cause large financial or social loss.

Criticality (IEEE 1012)

The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system.

Deactivated code (DO-178)

Executable Object Code (or data) that is traceable to a requirement and, by design, is either (a) not intended to be executed (code) or used (data), for example, a part of a previously developed software component such as unused legacy code, unused library functions, or future growth code; or (b) is only executed (code) or used (data) in certain configurations of the target computer environment, for example, code that is enabled by a hardware pin selection or software programmed options. The following examples are often mistakenly categorized as deactivated code but should be identified as required for implementation of the design/requirements: defensive programming structures inserted for robustness, including compiler-inserted object code for range and array index checks, error or exception handling routines, bounds and reasonableness checking, queuing controls, and time stamps.

Dead code (DO-178)

Executable Object Code (or data) which exists as a result of a software development error but cannot be executed (code) or used (data) in any operational configuration of the target computer environment. It is not traceable to a system or software requirement. The following exceptions are often mistakenly categorized as dead code but are necessary for implementation of the requirements/design: embedded identifiers, defensive programming structures to improve robustness, and deactivated code such as unused library functions.

Debug (ISO 24765)

1. To detect, locate, and correct faults in a computer program.
2. To detect, locate, and eliminate errors in programs.

Defect

1. A problem which, if not corrected, could cause an application to either fail or to produce incorrect results (ISO 20926).
2. An imperfection or deficiency in a project component where that component does not meet its requirements or specifications and needs to be either repaired or replaced (PMBOK^® Guide).
3. A generic term that can refer to either a fault (cause) or a failure (effect) (IEEE 982.1).

Derived measure (ISO 15939)

Measure that is defined as a function of two or more values of base measures.

Development testing

1. Formal or informal testing conducted during the development of a system or component, usually in the development environment by the developer (ISO 24765).
2. Testing conducted to establish whether a new software product or software-based system (or components of it) satisfies its criteria. The criteria will vary based on the level of test being performed (IEEE 829).

Effectiveness (ISO 9000)

Extent to which planned activities are realized and planned results achieved.

Efficiency

1. The degree to which a system or component performs its designated functions with minimum consumption of resources (ISO 24765).
2. Relationship between the result achieved and the resources used (ISO 9000).

Effort (PMBOK^® Guide)

The number of labor units required to complete a schedule activity or work breakdown structure component. Usually expressed in hours, days, or weeks.

Error (ISO 24765)

1. A human action that produces an incorrect result, such as software containing a fault.
2. An incorrect step, process, or data definition.
3. An incorrect result.
4. The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.

Evaluation (ISO 12207)

Systematic determination of the extent to which an entity meets its specified criteria.

Exit criteria (CMMI-DEV)

States of being that must be present before an effort can end successfully.

Failure

1. Termination of the ability of a product to perform a required function or its inability to perform within previously specified limits (ISO 25000).
2. An event in which a system or system component does not perform a required function within specified limits (ISO 24765).

Financial independence (IEEE 1012)

This requires that control of the IV&V budget be vested in an organization independent of the development organization. This independence prevents situations where the IV&V effort cannot complete its analysis or test or deliver timely results because funds have been diverted or adverse financial pressures or influences have been exerted.

Firmware

1. Combination of a hardware device and computer instructions or computer data that reside as read-only software on the hardware device (IEEE 1012).
2. An ordered set of instructions and associated data stored in a way that is functionally independent of main storage, usually in a ROM (ISO 2382-1).

Note 1: The software cannot be readily modified under program control (ISO 24765).

Note 2: This term is sometimes used to refer only to the hardware device or only to the computer instructions or data, but these meanings are deprecated (IEEE 1012).

Note 3: The confusion surrounding this term has led some to suggest that it be avoided altogether (IEEE 1012).

Functional configuration audit (FCA) (ISO 24765)

An audit conducted to verify that the development of a configuration item has been completed satisfactorily, that the item has achieved the performance and functional characteristics specified in the functional or allocated configuration identification, and that its operational and support documents are complete and satisfactory.

Functional requirement (IEEE 1220)

A statement that identifies what a product or process must accomplish to produce required behavior and/or results.

Glass box (ISO 24765)

1. A system or component whose internal contents or implementation are known.

2. Pertaining to an approach that treats a system or component as in (1).

   Synonym: white box.

Hazard (IEEE 1012)

1. An intrinsic property or condition that has the potential to cause harm or damage.
2. A source of potential harm or a situation with a potential for harm in terms of human injury, damage to health, property, or the environment, or some combination of these.

Independent (ISO 24765)

Performed by an organization free from control by the supplier, developer, operator, or maintainer.

Independent verification and validation (IV&V) (ISO 24765)

Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization.

Indicator (ISO 15939)

Measure that provides an estimate or evaluation of specified attributes derived from a model with respect to defined information needs.

Information Management Process (ISO 15289)

The documentation management process shall include these activities:

1. identify the documents to be produced by the organization, service, process, or project;
2. specify the content and purpose of all documents and plan and schedule their production;
3. identify the standards to be applied for development of documents;
4. develop and publish all documents in accordance with identified standards and in accordance with nominated plans;
5. maintain all documents in accordance with specified criteria.

Integration testing (IEEE 1012)

Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them.

Integrity level (IEEE 1012)

A value representing project-unique characteristics (e.g. complexity, criticality, risk, safety level, security level, desired performance, and reliability) that define the importance of the system, software, or hardware to the user.

Integrity level scheme (IEEE 829)

A set of system characteristics (such as complexity, risk, safety level, security level, desired performance, reliability, and/or cost) selected as important to stakeholders, and arranged into discrete levels of performance or compliance (integrity levels), to help define the level of quality control to be applied in developing and/or delivering the software.

Internal audit (ISO 9001)

The organization shall conduct internal audits at planned intervals to determine whether the quality management system:

1. conforms to the planned arrangements to the requirements of this International Standard and to the quality management system requirements established by the organization;
2. is effectively implemented and maintained.

An audit programme shall be planned, taking into consideration the status and importance of the processes and areas to be audited, as well as the results of previous audits. The audit criteria, scope, frequency, and methods shall be defined. The selection of auditors and conduct of audits shall ensure objectivity and impartiality of the audit process. Auditors shall not audit their own work.

A documented procedure shall be established to define the responsibilities and requirements for planning and conducting audits, establishing records and reporting results.

Records of the audits and their results shall be maintained.

The management responsible for the area being audited shall ensure that any necessary corrections and corrective actions are taken without undue delay to eliminate detected nonconformities and their causes.

Follow-up activities shall include the verification of the actions taken and the reporting of verification results.

Issue (PMBOK^® Guide)

A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.

Lessons learned (PMBOK^® Guide)

The knowledge gained during a project that shows how project events were addressed or should be addressed in the future with the purpose of improving future performance.

Life cycle

1. Evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO 12207);
2. The system or product evolution initiated by a perceived stakeholder need through the disposal of the products (IEEE 1220).

Life cycle processes (IEEE 1012)

A set of interrelated or interacting activities that result in the development or assessment of system, software, or hardware products. Each activity consists of tasks. The life cycle processes may overlap one another. For verification and validation (V&V) purposes, no life cycle process is concluded until its development products are verified and validated according to the defined tasks in the verification and validation plan (VVP).

Managerial independence (IEEE 1012)

This requires that the responsibility for the IV&V effort be vested in an organization separate from the development and program management organizations. Managerial independence also means that the IV&V effort independently selects the segments of the software, hardware, and system to analyze and test, chooses the IV&V techniques, defines the schedule of IV&V activities, and selects the specific technical issues and problems to act on. The IV&V effort provides its findings in a timely fashion simultaneously to both the development and program management organizations. The IV&V effort is allowed to submit to program management the IV&V results, anomalies, and findings without any restrictions (e.g., without requiring prior approval from the development group) or adverse pressures, direct or indirect, from the development group.

Marginal (IEEE 1012)

Severe injury or illness, degradation of secondary mission, or some financial or social loss.

Master library (ISO 24765)

A software library containing master copies of software and documentation from which working copies can be made for distribution and use. (cf. production library, software development library, software repository, system library.)

Measure (noun) (ISO 15939)

Variable to which a value is assigned as the result of measurement.

Note: The plural form “measures” is used to refer collectively to base measures, derived measures and indicators.

Measure (verb) (ISO 15939)

Make a measurement.

Measurement function (ISO 15939)

Algorithm or calculation performed to combine two or more base measures.

Measurement information model (ISO 15939)

A structure linking information needs to the relevant entities and attributes of concern. Entities include processes, products, projects, and resources. The measurement information model describes how the relevant attributes are quantified and converted to indicators that provide a basis for decision making.

Measurement method (ISO 15939)

Logical sequence of operations, described generically, used in quantifying an attribute with respect to a specified scale.

Note: The type of measurement method depends on the nature of the operations used to quantify an attribute. Two types can be distinguished:

1. subjective: quantification involving human judgment;
2. objective: quantification based on numerical rules.

Measurement process (ISO 15939)

Process for establishing, planning, performing, and evaluating measurement within an overall project, enterprise, or organizational measurement structure.

Measurement process owner (ISO 15939)

Individual or organization responsible for the measurement process.

Medical device (ISO 13485)

Instrument, apparatus, implement, machine, appliance, implant, reagent for in vitro use, software, material, or other similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of: diagnosis, prevention, monitoring, treatment, or alleviation of disease; diagnosis, monitoring, treatment, alleviation of or compensation for an injury; investigation, replacement, modification, or support of the anatomy or of a physiological process; supporting or sustaining life; control of conception; disinfection of medical devices; providing information for medical purposes by means of in vitro examination of specimens derived from the human body; and which does not achieve its primary intended action in or on the human body by pharmacological, immunological, or metabolic means, but which may be assisted in its function by such means.

Microcode (IEEE 1012)

A collection of microinstructions, comprising part of, all of, or a set of microprograms.

Microprogram (ISO 24765)

A sequence of instructions, called microinstructions, specifying the basic operations needed to carry out a machine language instruction.

Negligible (IEEE 1012)

Minor injury or illness, minor impact on system performance, or operator inconvenience.

Nonconformity (ISO 9000)

Non-fulfilment of a requirement.

Nonfunctional requirement (ISO 24765)

A software requirement that describes not what the software will do but how the software will do it. Synonym: design constraints, non-functional requirement. (cf. functional requirement.)

Example: software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Non-functional requirements are sometimes difficult to test, so they are usually evaluated subjectively.

Objectively evaluate (CMMI-DEV)

To review activities and work products against criteria that minimize subjectivity and bias by the reviewer (See also “audit.”). An example of an objective evaluation is an audit against requirements, standards, or procedures by an independent quality assurance function.

Operational testing (IEEE 829)

Testing conducted to evaluate a system or component in its operational environment.

Opportunity (PMBOK^® Guide)

A risk that would have a positive effect on one or more project objectives.

Organizational policy (CMMI-DEV)

A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions.

Organization's process asset library (CMMI-DEV)

A library of information used to store and make process assets available that are useful to those who are defining, implementing, and managing processes in the organization. This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons learned documents, templates, standards, procedures, plans, and training materials.

Path (ISO 24765)

In software engineering, a sequence of instructions that may be performed in the execution of a computer program.

Personal Process [SEI 09]

A defined set of steps or activities that guide individuals in doing their personal work. It is usually based on personal experience and may be developed entirely from scratch or may be based on another established process and modified according to personal experience. A personal process provides individuals with a framework for improving their work and for consistently doing high-quality work.

Physical configuration audit (PCA) (ISO 24765)

An audit conducted to verify that a configuration item, as built, conforms to the technical documentation that defines it.

Policy (ISO 24765)

1. A set of rules related to a particular purpose.
2. Clear and measurable statements of preferred direction and behavior to condition the decisions made within an organization.

Note: A rule can be expressed as an obligation, an authorization, a permission, or a prohibition. Not every policy is a constraint. Some policies represent an empowerment.

Post-mortem [DIN 05]

A collective learning activity that can be organized for projects either when they end a phase or are terminated. The main motivation is to reflect on what happened in the project in order to improve future practice for the individuals that have participated in the project and for the organization as a whole. The physical outcome of a meeting is a post-mortem report.

Preventive action (PMBOK^® Guide)

An intentional activity that ensures the future performance of the project work is aligned with the project management plan.

Procedure

1. Ordered series of steps that specify how to perform a task (ISO 26514).
2. Specified way to carry out an activity or a process (ISO 9000).

Note 1: Procedures can be documented or not (ISO 9000).

Process (ISO 9000)

Set of interrelated or interacting activities that use inputs to deliver an intended result.

Process approach (ISO 9000)

Any activity, or set of activities, that uses resources to transform inputs to outputs can be considered as a process.

For organizations to function effectively, they have to identify and manage numerous interrelated and interacting processes. Often, the output from one process will directly form the input into the next process. The systematic identification and management of the processes employed within an organization and particularly the interactions between such processes is referred to as the “process approach.”

The intent of this International Standard is to encourage the adoption of the process approach to manage an organization.

Process asset (CMMI-DEV)

Anything the organization considers useful in attaining the goals of a process area.

Process description (ISO 24765)

Documented expression of a set of activities performed to achieve a given purpose.

Note: A process description provides an operational definition of the major components of a process. The description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior, or other characteristics of a process. It also may include procedures for determining whether these provisions have been satisfied. Process descriptions can be found at the activity, project, or organizational level.

Process owner (ISO 24765)

Person (or team) responsible for defining and maintaining a process.

Product

1. Output of an organization that can be produced without any transaction taking place between the organization and the customer (ISO 9000).

Note: Hardware is tangible and its amount is a countable characteristic (e.g., tyres). Processed materials are tangible and their amount is a continuous characteristic (e.g., fuel and soft drinks). Hardware and processed materials are often referred to as goods. Software consists of information regardless of delivery medium (e.g., computer programme, mobile phone app, instruction manual, dictionary content, musical composition copyright, driver's license).

2. An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item (PMBOK^® Guide).

Production library (ISO 24765)

A software library containing software approved for current operational use.

Program librarian (ISO 24765)

The person responsible for establishing, controlling, and maintaining a software development library.

Prototype (ISO 15910)

1. A preliminary type, form, or instance of a system that serves as a model for later stages or for the final, complete version of the system;
2. Model or preliminary implementation of a piece of software suitable for the evaluation of system design, performance or production potential, or for the better understanding of the software requirements.

Prototyping (ISO 24765)

A hardware and software development technique in which a preliminary version of part or all of the hardware or software is developed to permit user feedback, determine feasibility, or investigate timing or other issues in support of the development process.

Qualification (ISO 12207)

Process of demonstrating whether an entity is capable of fulfilling specified requirements.

Qualification testing (ISO 12207)

Testing, conducted by the developer and witnessed by the acquirer (as appropriate), to demonstrate that a software product meets its specifications and is ready for use in its target environment or integration with its containing system.

Quality (ISO 9000)

Degree to which a set of inherent characteristics of an object fulfills requirements.

Note 1: The term “quality” can be used with adjectives such as poor, good or excellent.

Note 2: “Inherent.” as opposed to “assigned,” means existing in the object.

Quality assurance (QA)

1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements (ISO 24765).
2. A set of activities designed to evaluate the process by which products are developed or manufactured (ISO 24765).
3. Part of quality management focused on providing confidence that quality requirements will be fulfilled (ISO 12207).

Quality audits (PMBOK^® Guide)

A quality audit is a structured, independent process to determine if project activities comply with organizational and project policies, processes, and procedures.

Quality model (ISO 25000)

Defined set of characteristics, and of relationships between them, which provides a framework for specifying quality requirements and evaluating quality.

Quality policy (ISO 9000)

Intentions and direction of an organization as formally expressed by top management related to quality.

Note 1: Generally, the quality policy is consistent with the overall policy of the organization, can be aligned with the organization's vision and mission and provides a framework for the setting of quality objectives.

Note 2: Quality management principles presented in this International Standard can form a basis for the establishment of a quality policy.

Release

1. A delivered version of an application which may include all or part of an application (ISO 24765).
2. Particular version of a configuration item that is made available for a specific purpose (e.g., test release) (ISO 12207).

Request for information (RFI) (PMBOK^® Guide)

A type of procurement document whereby the buyer requests a potential seller to provide various pieces of information related to a product or service or seller capability.

Request for proposal (RFP) or Tender (ISO 12207)

Document used by the acquirer as the means to announce its intention to potential bidders to acquire a specified system, software product, or software service.

Request for proposal (RFP) (PMBOK^® Guide)

A type of procurement document used to request proposals from prospective sellers of products or services. In some application areas, it may have a narrower or more specific meaning.

Request for quotation (RFQ) (PMBOK^® Guide)

A type of procurement document used to request price quotations from prospective sellers of common or standard products or services. Sometimes used in place of request for proposal and, in some application areas, it may have a narrower or more specific meaning.

Requirements traceability (CMMI-DEV)

A discernable association between requirements and related requirements, implementations, and verifications.

Reusable product (IEEE 1012)

A system, software, or hardware product developed for one use but having other uses, or one developed specifically to be usable on multiple projects or in multiple roles on one project. Examples include, but are not limited to, commercial off-the-shelf (COTS) software products, acquirer-furnished software products, software products in reuse libraries, and preexisting developer software products. Each use may include all or part of the software product and may involve its modification. This term can be applied to any software product (e.g., requirements, architectures), not just to software itself.

Reuse (ISO 24765)

The use of an asset in the solution of different problems.

Review

1. A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval (ISO 24765).
2. A process or meeting during which a software product, set of software products, or a software process is presented to project personnel, managers, users, customers, user representatives, auditors or other interested parties for examination, comment, or approval (IEEE 1028).

Risk

1. The combination of the probability of an event and its consequence (ISO 16085).

Note 1: The term “risk” is generally used only when there is at least the possibility of negative consequences.

Note 2: In some situations, risk arises from the possibility of deviation from the expected outcome or event.

2. An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives (PMBOK^® Guide).

Risk action request (ISO 16085)

The recommended treatment alternatives and supporting information for one or more risks determined to be above a risk threshold.

Risk management plan (ISO 16085)

A description of how the elements and resources of the risk management process will be implemented within an organization or project.

Risk management process (ISO 16085)

A continuous process for systematically identifying, analyzing, treating, and monitoring risk throughout the life cycle of a product or service.

Risk mitigation

1. A course of action taken to reduce the probability of and potential loss from a risk factor (ISO 24765).
2. A risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk (PMBOK^® Guide).

Risk profile (ISO 16085)

A chronological record of a risk's current and historical risk state information.

Risk state (ISO 16085)

The current project risk information relating to an individual risk.

Note: The information concerning an individual risk may include the current description, causes, probability, consequences, estimation scales, confidence of the estimates, treatment, threshold, and an estimate of when the risk will reach its threshold.

Risk threshold (ISO 16085)

A condition that triggers some stakeholder action.

Note: Different risk thresholds may be defined for each risk, risk category, or combination of risks based upon differing risk criteria.

Risk treatment (ISO 16085)

The process of selection and implementation of measures to modify risk.

Note 1: The term “risk treatment” is sometimes used for the measures themselves.

Note 2: Risk treatment measures can include avoiding, optimizing, transferring or retaining risk.

Security branch (ISO 24765)

A branch, created at the time of a release, to which only security commits are made.

Service Management System (SMS) (ISO 20000-1)

Management system to direct and control the service management activities of the service provider.

Note 1: A management system is a set of interrelated or interacting elements to establish policy and objectives and to achieve those objectives.

Note 2: The SMS includes all service management policies, objectives, plans, processes, documentation, and resources required for the design, transition, delivery, and improvement of services and to fulfill the requirements in this part of ISO/IEC 20000.

Note 3: Adapted from the definition of “quality management system” in ISO 9000:2005.

Software (ISO 24765)

All or part of the programs, procedures, rules, and associated documentation of an information processing system. Example: command files, job control language.

Note: includes firmware, documentation, data, and execution control statements.

Software development library (ISO 24765)

A software library containing computer readable and human readable information relevant to a software development effort. Synonym: project library, program support library.

Software engineering (ISO 24765)

The systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software.

Software library (ISO 24765)

A controlled collection of software and related documentation designed to aid in software development, use, or maintenance.

Software Package (AQAP 2006)

A software package is already developed and usable as is or after adaptation. This type of software can be designated as reusable software, software provided by the state, or commercial software, depending on its origin.

Software quality (ISO 25000)

Capability of software product to satisfy stated and implied needs when used under specified conditions.

Software quality assurance (IEEE 730)

A set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes. A key attribute of SQA is the objectivity of the SQA function with respect to the project. The SQA function may also be organizationally independent of the project; that is, free from technical, managerial, and financial pressures from the project.

Software repository (ISO 24765)

A software library providing permanent, archival storage for software and related documentation.

Examples include inadequate staffing levels, insufficient resources, and lack of training. Also included in this section are actions taken to mitigate identified project risks.

Stable branch (ISO 24765)

A branch where stability-disrupting changes are discouraged.

Note: the branch used for releasing the product's stable production version.

Staff-hour (ISO 24765)

An hour of effort expended by a member of the staff.

Statement of work (SOW) (ISO 12207)

Document used by the acquirer to describe and specify the tasks to be performed under the contract.

Supplier (ISO 12207)

Organization or an individual that enters into an agreement with the acquirer for the supply of a product or service.

Note 1: Other terms commonly used for supplier are contractor, producer, seller, or vendor.

Note 2: The acquirer and the supplier sometimes are part of the same organization.

Synchronize (ISO 24765)

1. To pull the changes made in a parent branch into its (evolving) child (e.g., feature) branch.
2. To update a view with the current version of the files in its corresponding branch.

System (ISO 15288)

Combination of interacting elements organized to achieve one or more stated purposes.

System library (ISO 24765)

A software library containing system-resident software that can be accessed for use or incorporated into other programs by reference.

Systems integration testing (IEEE 829)

Testing conducted on multiple complete, integrated systems to evaluate their ability to communicate successfully with each other and to meet the overall integrated systems' specified requirements.

Tag (ISO 24765)

A symbolic name assigned to a specific release or a branch.

Note: provides developers and end-users with a unique reference to the code base they are working with.

Technical independence (IEEE 1012)

Technical independence requires the V&V effort to use personnel who are not involved in the development of the system or its elements. The IV&V effort should formulate its own understanding of the problem and how the proposed system is solving the problem. Technical independence (“fresh viewpoint”) is an important method to detect subtle errors overlooked by those too close to the solution.

For system tools, technical independence means that the IV&V effort uses or develops its own set of test and analysis tools separate from the developer's tools. Sharing of tools is allowable for computer support environments (e.g., compilers, assemblers, and utilities) or for system simulations where an independent version would be too costly. For shared tools, IV&V conducts qualification tests on tools to assure that the common tools do not contain errors that may mask errors in the system being analyzed and tested. Off-the shelf tools that have extensive history of use do not require qualification testing. The most important aspect for the use of these tools is to verify the input data used.

Template

1. An asset with parameters or slots that can be used to construct an instantiated asset (IEEE 1517).
2. A partially complete document in a predefined format that provides a defined structure for collecting, organizing, and presenting information and data (PMBOK^® Guide).

Test (IEEE 829)

1. An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.
2. To conduct an activity as in (1).
3. A set of one or more test cases and procedures.

Threat (PMBOK^® Guide)

A risk that would have a negative effect on one or more project objectives.

Traceability

1. The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another (ISO 24765).

    Example: the degree to which the requirements and design of a given system element match; the degree to which each element in a bubble chart references the requirement that it satisfies.

2. A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks. (See also “bidirectional traceability” and “requirements traceability.”) (CMMI-DEV).

Traceability matrix (ISO 24765)

A matrix that records the relationship between two or more products of the development process.

Example: a matrix that records the relationship between the requirements and the design of a given software component.

Trunk (ISO 24765)

The software's main line of development; the main starting point of most branches.

Note: One can often distinguish the trunk from other branches by the version numbers used for identifying its files, which are shorter than those of all other branches.

Unit test

1. Testing of individual routines and modules by the developer or an independent tester.
2. A test of individual programs or modules in order to ensure that there are no analysis or programming errors (ISO/IEC 2382-20).
3. Test of individual hardware or software units or groups of related units (ISO 24765).

Validation

1. Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled (ISO 15288).
2. (A) The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. (B) The process of providing evidence that the system, software, or hardware and its associated products satisfy requirements allocated to it at the end of each life cycle activity, solve the right problem (e.g., correctly model physical laws, implement business rules, and use the proper system assumptions), and satisfy intended use and user needs (IEEE 1012).

Vendor branch (ISO 24765)

A branch for keeping track of versions of imported software.

Note: Differences between successive versions can then be readily applied to the locally modified import.

Verification

1. Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled (ISO 12207).
2. (A) The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. (B) The process of providing objective evidence that the system, software, or hardware and its associated products conform to requirements (e.g., for correctness, completeness, consistency, and accuracy) for all life cycle activities during each life cycle process (acquisition, supply, development, operation, and maintenance); satisfy standards, practices, and conventions during life cycle processes; and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities. Verification of interim work products is essential for proper understanding and assessment of the life cycle phase product(s) (IEEE 1012).

Version (ISO 24765)

1. An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item.
2. An initial release or complete re-release of a document, as opposed to a revision resulting from issuing change pages to a previous release.
3. An operational software product that differs from similar products in terms of capability, environmental requirements, and configuration.
4. An identifiable instance of a specific file or release of a complete system.

Note: Modification to a version of a software product, resulting in a new version, requires configuration management action.

Version control (ISO 24765)

Establishment and maintenance of baselines and the identification and control of changes to baselines that make it possible to return to the previous baseline.

Very Small Entity (VSE) (ISO 29110)

A VSE is an entity (enterprise, organization, department, or project) having up to 25 people.

View (ISO 24765)

A developer's copy of a branch.

Abbreviations – Acronyms

AAR

After Action Review

ACM

Association for Computing Machinery

AECL

Atomic Energy Canada Limited

ASQC

American Society for Quality Control

BPMN

Business Process Modeling and Notation

CAR

Causal Analysis and Resolution

CASE

Computer Aided Software/System Engineering

CCB

Configuration Control Board

CEO

Chief Executive Officer

CI

Continuous Improvement

CI

Configuration Item

CM

Configuration Management

CMM^®

Capability Maturity Model

CMMI^®

Capability Maturity Model Integration (www.sei.cmu.edu/cmmi)

CMMI–DEV

CMMI for Development

CMMI–ACQ

CMMI for Acquisition

CMMI–SVC

CMMI for Services

CobiT

Control Objectives for Information and related Technology

COCOMO

COnstructive COst MOdel (http://sunset.usc.edu/csse/research/ COCOMOII/cocomo_main.html)

COTS

Commercial off the shelf

DP

Deployment Package

EIA

Electronic Industries Alliance

ÉTS

École de technologie supérieure (www.etsmtl.ca)

FDA

Food and Drug Administration

FEMA

Failure Mode and Effect Analysis

FSM

Finite State Machine

GE

General Electric

GSEP

Generic Systems Engineering Process

HRMS

Human Resource Management System

IV&VI

Independent Verification and Validation

IBM

International Business Machines

IDEAL

Initiating, Diagnosing, Establishing, Acting, Learning

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers (www.ieee.org)

INCOSE

International Council on Systems Engineering (www.incose.org)

IS

Information System

ISACA

Information Systems Audit and Control Association

ISBG

International Software Benchmarking Standards Group (www.isbsg.org)

ISM

Integrated Software Management

ISO

International Organization for Standardization (www.iso.org). Note: ISO is not an abbreviation.

ISO/IEC

International Organization for Standardization/ International Electrotechnical Commission

ISO/IEC JTC 1 SC 7

Sub committee 7 Software and systems engineering

ISSEP

Integrated Systems and Software Engineering Process

IT

Information Technology

JTC 1

Joint Technical Committee 1 (of ISO/IEC)

KLOC

Thousand lines of source code

MLOC

Million lines of source code

MR

Modification Request also Change Request (CR) or Problem Report (PR)

NASA

National Aeronautics and Space Administration (www.nasa.gov)

OO

Object Oriented

OPD

Organization Process Definition

OPF

Organization Process Focus

PAL

Process asset library

PDCA

Plan–Do–Check–Act

PM

Project Management

PMI

Project Management Institute (www.pmi.org)

PMBOK^®

Project Management Body of Knowledge (www.pmi.org)

PODCAST

Portable media player digital audio file made available on the Internet

PPQA

Process and Product Quality Assurance

PR

Peer Review

PR

Problem Report

QE

Quality Engineering

QMS

Quality Management System

RAMS

Reliability, Availability, Maintainability, and Safety

RFI

Request For Information

RFP

Request For Proposal

RTCA

Radio Technical Commission for Aeronautics

S^3m

Software Maintenance Maturity Model (www.s3m.org)

SAP

System, Anwendunsgen, Produkte/Systems Applications and Products

SCAMPI

Standard CMMI Appraisal Method for Process Improvement

SCE

Software Capability Evaluation

SCM

Software Configuration Management

SCR

Software Change Request

SEI

Software Engineering Institute (www.sei.cmu.edu)

SOX

Sabarnes-Oxley

SOW

Statement of work

SPA

Software Process Assessment

SPICE

Software Process Improvement and Capability dEtermination

SQA

Software Quality Assurance

SQM

Software Quality Management

SRA

Society for Risk Analysis (www.sra.org)

S/W

Software

SW– CMM

Software Capability Maturity Model

SWEBOK^®

Software Engineering Body of Knowledge (www.swebok.org)

TOMS

Total Ozone Mapping Spectrometer

TDD

Test Driven Development

TQM

Total Quality Management

VSE

Very Small Entity

V&V

Verification and Validation

WBS

Work Breakdown Structure